본문 바로가기

Dev.../소프트웨어 아키텍처

[SA강좌] Part 1-17 간단한 아키텍처링 예제

간단한 아키텍쳐링 예제

가장 먼저 아키텍트가 할일은 '시스템'이란 무엇인가?를 찾고 식별해야한다.


첫째. 정치활동을 충실히 하라!


정치적인 변수들 ( 고객, 사업관리 조직 등등 – 심지어 고객의 사모님의 취향~ )을 비밀문서에 잘 체크해두어야 한다.

간혹, 화면의 색만 가지고 시비거는 고객도 있다. ( 아예… 레이어를 분리해버리는 것도 방법이다.!)


정치활동을 통하여 아키텍트가 가진 컨셉을 모든 이해관계자들에게 설득하고 조율해야 한다. 당연히 엄청난 구강신공은 필수가 된다.


가장 뛰어난 아키텍트는 그 사람이 결정한 것이 아니라 그 결정 마져도 해당 관계된 사람들 사이의 회의에서 얻어진 결과물로 착각하게 만드는 것이 최선이기 때문이다.


둘째로 시스템의 구축 범위를 명확히 하라.


외부 시스템과 내부 시스템을 명쾌하게 구분해서 고객을 이해시켜야 한다. 또한, 솔루션이 할일과 외부 프로그램들이 할일에 대해서 명쾌하게 해야한다.

특히나 솔루션인 경우에 그 테스트 범위와 관련 일정등을 제대로 파악하지 못하면 프로젝트가 낭패를 당할 수도 있다.


결국, 이 내용들은 제안요청서(RFP), 비전기술서( 안만들기도 하지만 ), 프로젝트 계획서나 수행계획서가 만들어질때에 그 '단어'의 선정과 설명을 명확하게 해야한다는 점이다.


세번째로 기능과 비기능을 명확히 하라.


결국 품질부분이나 시스템의 구성형태에 대해서 전체적인 관련내용들에 대해서 고객만족을 위한 영역설정을 명확하게 하는 것이기 때문이다.


유스케이스로 표현되는 기능과 품질로 표현되는 비기능요소를 명확하게 구분해야 한다.


대표적으로 시스템이 높은 성능을 내어야 한다는 아주 모호한 부분을 실제 개량화하여 제시해야하는 것도 아키텍트의 임무중의 하나이다. 결국, 품질과 공정( 설계, 구현, 배치 )는 떨어질 수 없는 끊임없는 반복의 결과이기 때문이다.


카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 제안한 ADD(Attribute-Driven Design, 속성 주도 설계)방법이든 아니면, 각자 고안한 방식이든. 큰 그림을 그리고, 시스템을 분할하여 나아가는 것이 필요하기 때문이다.

이를, '아키텍처 패턴'이라고 부르기도 한다.