본문 바로가기

소프트웨어아키텍트

내가 가장 눈부시던 20대! 그당시 최고의 기억... 그리고... 뉴욕! 더보기
[SA강좌] Part 1 - 소프트웨어 아키텍처 개념에 대한 이해 소프트웨어아키텍트와 관련된 지식이 널리 퍼지기를 기원하며... 만들었던 초안 그대로 오픈합니다. 소프트웨어아키텍트를 꿈꾸는 분들에게 도움이 되었으면 합니다. 나름 괜찮게 만들어진 내용이라서리... 주변 사람들에게 널리 읽혔으면 좋겠다라는 개인적인 바램이 조금 있습니다. ~.~ [SA강좌] Part 1-20 SA기초강좌 맺음말… [SA강좌] Part 1-19 아키텍처가 바라보는 View [SA강좌] Part 1-18 간단한 ADD방법 [SA강좌] Part 1-17 간단한 아키텍처링 예제 [SA강좌] Part 1-16 서비스 시스템의 목표 [SA강좌] Part 1-15 소프트웨어 아키텍처의 참고사항 [SA강좌] Part 1-14 소프트웨어 아키텍처 팀 운영 시 문제점에 대한 해결방안 [SA강좌] Part 1.. 더보기
[SA강좌] Part 1-20 SA기초강좌 맺음말… 개념 설명 SOA와 CBD를 혼동하는 분을 위한 간단히 구분법을 설명드린다. 두 가지 모두 Reusable(재가용성)에서 중요한 개념이다. 하지만 중요하게 다른 점은 서비스가 서비스 소비자가 원하는 궁극의 결과를 얻기 위해 서비스 제공자가 처리해주는 한가지 일의 단위(W3C, Dr.Hao he)라고 보는 것이 SOA이고 컴포넌트는 다른 컴포넌트와 상호 작동하기 위해 만들어진 것으로 특정기능(functionality)또는 일련의 기능을 담고 있으며 명확히 정의된 인터페이스를 가지는 소프트웨어 객체(W3C WS-glossary) 라고 보는 것이다. 또한 가장 큰 차이점은 컴포넌트는 이미 구현된 것이기에 프로그래밍 언어에 중립적이지 않다는점이며 CORBA의 대표적인 실패원인 이기도하다. 1회강의 맺음말 소프트.. 더보기
[SA강좌] Part 1-19 아키텍처가 바라보는 View 내가 예전에 만들었던 소프트웨어에 이런 것이 있었다. AutoCad에 애드인하는 소프트웨어 였는데. 건축설계사무소에서 Cad에 설계를 할때에 정의된 클립아트 형태 ( 계단, 지붕, 문 등등 )를 사용해서 아파트나 주유소와 같은 건축물을 설계하면 관련 클립아트들이 컴포넌트 형태로 건축 일위대가라는 속성과 연결되어져서 실제 건축에서 산정되는 단가를 추출해주는 프로그램이었다. 건축가의 처음 '투시도'하나에서… 실제 '건축내역서'까지 파생되는 과정을 보면, 현재의 소프트웨어의 구상과 참으로 유사한듯 하다. 아마도, 완성된 프로그램을 빠르게 도식화해서 '고객'과 협의에 사용하게 하는 프로그램이 만들어진다면, 정말 괜찮을 듯 하다. 말이 조금 빗나갔지만, 아키텍쳐를 바라보는 View에 따라서 다 다르다. 업무관점에.. 더보기
[SA강좌] Part 1-18 간단한 ADD방법 간단하게 ADD 방법을 살펴보면 다음과 같다. ( 상세한 것은 www.sei.cmu.edu/architecture/add_method.html 에 있다. ) 간단한 방법에 대한 설명이다. 시스템을 분할해서 구성하는 방법을 간단하게 도식화 한것이다. 아주 좋은 이야기 하나 소개. [브라이언 푸트의 패턴이야기] 이렇게 분할 하는 방법이 여러가지 view로 시스템을 바라보면서 아키텍쳐를 만들어 나아가는 것이기 때문이다. 따지고 보면, 건축물도 디자인을 먼저하고 세부적인 공정작업에 들어가는 것이기 때문이다. 가장 완성도가 높은 것은 고객에게 '완성'된 프로그램의 형태를 보여주고 그 형태를 만들기 위해 애쓰는 것이 아닐까? 결국 건축아키텍트는 수많은 투시도를 그리게 되고 설계도로 분화되면서 최후에 실제 프로그램을.. 더보기
[SA강좌] Part 1-17 간단한 아키텍처링 예제 간단한 아키텍쳐링 예제 가장 먼저 아키텍트가 할일은 '시스템'이란 무엇인가?를 찾고 식별해야한다. 첫째. 정치활동을 충실히 하라! 정치적인 변수들 ( 고객, 사업관리 조직 등등 – 심지어 고객의 사모님의 취향~ )을 비밀문서에 잘 체크해두어야 한다. 간혹, 화면의 색만 가지고 시비거는 고객도 있다. ( 아예… 레이어를 분리해버리는 것도 방법이다.!) 정치활동을 통하여 아키텍트가 가진 컨셉을 모든 이해관계자들에게 설득하고 조율해야 한다. 당연히 엄청난 구강신공은 필수가 된다. 가장 뛰어난 아키텍트는 그 사람이 결정한 것이 아니라 그 결정 마져도 해당 관계된 사람들 사이의 회의에서 얻어진 결과물로 착각하게 만드는 것이 최선이기 때문이다. 둘째로 시스템의 구축 범위를 명확히 하라. 외부 시스템과 내부 시스템을.. 더보기
[SA강좌] Part 1-16 서비스 시스템의 목표 서비스 시스템의 목표 아키텍트는 소프트웨어 복잡도를 해결하면서 시스템의 품질 속성을 획득해야 한다. 이 서비스 시템은 물론 변경도 용이해야 한다. 유지보수성, 확장성, 재구조화성, 이식성을 가져야 한다는 점이기도 한다. 소프트웨어 복잡도 해결 시스템의 품질 속성 획득 변경용이성 유지보수성, 확장성, 재구조화성, 이식성 상호운영성 효율성 안정성 고장 감내, 강건성 시험요잉성 재사용성 문제를 해결하기 위한 기본 테크닉들 추상화, 캡슐화, 정보은폐, 모듈화, 고려사항의 분리, 결합력과 응집력, 충분-완전-원시성, 정책과 구현의 분리, 인터페이스와 구현의 분리, 한번의 참조, 분할 정복 그러나, 아키텍트들이 주의하여야할 점들이 있다. 가장 훌룡한 아키텍쳐는 목표시스템과 어울려야 한다는 것이다. 그렇다면. 반문할.. 더보기
[SA강좌] Part 1-15 소프트웨어 아키텍처의 참고사항 소프트웨어 아키텍처의 참고사항 서비스 지향 아키텍트는 소프트웨어의 환경이 변화되고 있는 것을 감지해야 한다. 그것은 비즈니스의 신속성( business velocity )를 증가시킨다. '기업이 올바른 방향을 설정하는 한편, 그 운영 속도를 가속화 할 수 있는 능력' 그것을 빠르게 표현하는 것이다. 90년대의 소프트웨어의 화두는 '얼마나 빠르게 소프트웨어를 구축하는가?'라는 것이 최고의 목표였었다, 그러나 21세기의 화두는 '올바른 방향을 유지하는 동시에 신속하고 품질을 보장할 수 있는 소프트웨어를 만들것인가?'이다. 90년대의 소프트웨어는 '목표'만 정확하면 그 품질을 개량화 하기 수월한 소프트웨어들이 대다수였다. 일반 패키지들이 그러했고, 일반 업무들도 단위업무 중심이었기 때문이다. 이제 21세기 소.. 더보기