본 Post는 서적 "소프트웨어 아키텍처 이론과 실제"에 대한 내용 입니다.
1부 아키텍처 개요
1. 아키텍처 비즈니스 사이클
이책에서는 첫 장에서 소프트웨어 아키텍처의 정의를 아래와 같이 내리고 있다.
"프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와
그들이 지니고 있는 특성 중에 외부에 드러나는 특성,
그리고 구성요소들의 관계를 표현하는 시스템의 구조나 구조체를 말한다."
위 구문에서 한가지 궁금했던 것은 외부에 드러나는 특성이란 무엇일까?
소프트웨어적인 부분을 정의하고 있기 때문에 내부적으로 구현을 이루고 있는 세세한 특징은 Architecture Core의 역할로 보고 그 보다는 외부에 표현해주어야 할 Interface의 역할 정의가 아키텍처에서 바라보아야 할 것으로 생각된다.
이로써 정의된 Interface를 제공받는 개발자가 1인칭 관점으로 보았을 때의 Software Architecture의 역할 중 하나로 보아야 하겠다.
각각 명확한 목적을 담고 있는 구성 요소를 이루어 내야 할 목표에 맞게 조합하는 구조나 구조체를 공유할 수 있는 수단으로 정의하는 것을 의미할 것으로 본다.
아키텍처의 잘못된 설계의 역사적 예로서 "스웨덴의 전함 바사"를 소개하고 있다.
바사의 예에서 아키텍트가 놓친 부분은 다음과 같이 정의하고 있다.
- 아키텍처에 적용 가능한 기술의 사례 확인
- 아키텍처를 평가할 수 있는 방법
- 문제점의 빠른 대응을 위한 아키텍처 중심 점진적 개발 기법
위 정의에 대해 아래와 같이 해석해 보았다.
사실, 프로젝트 진입 시 1. 의 경우가 상당히 중요한 작업이다. 예를 들어 DBMS OR-Mapping을 위한 기술을 적용하기 위해 IBatis 를 쓸 것인지 Hibernate를 쓸 것인지를 결정하고 나면 프로젝트 진행 도중에 변경한다는 것은 경우에 따라서는 가늠이 않될 정도의 비용을 초래할 수도 있기 때문에 신중한 결정이 따른다.
이 때, 결정자가 아키텍트가 아니라면 아키텍트는 올바른 결정을 내릴 수 있게 충분한 자료와 사례를 수집 정보화해야 할 것으로 본다. (1.의 정의에 관해)
기술 검토를 토대로 아키텍처가 생성되었다면 이 아키텍처가 우리 모두가 원하는 목표를 충족시킬 수 있을 것인지를 정량적으로 표현할 수 있는 방법을 수립해야 한다. (2.의 정의에 관해)
모두가 수용할 수 있는 아키텍처의 정의가 완성되어 구현에 들어갔을 때 완료시점까지 끊임없이 발생하는 이슈(문제점)들을 아키텍트는 아키텍처가 해결할 수 있는 방법을 제시할 수 있도록 해야 한다.
1.1 아키텍처에 영향을 주는 요인
내가 아키텍트인데 아키텍처를 만드는 작업을 할 때 만들어야 할 아키텍처에 영향, 즉 아키텍처의 결과물에 영향을 주게될 요인들은 무엇이 있을까?
책에서는 아래와 같이 나열하고 있다.
- 이해관계자
개발 시스템과 관련된 모든 (결과물을 사용할 사용자까지) 사람이나 조직.
이들에게서 요구되는 것들을 아래와 같이 리스트해볼 수 있다.
- Performance
- Reliability
- Availability
- Platform compatibility
- Memory Utilization
- Network Usage
- Modifiablity
- Usability
- Interoperability
책에서는 이와 같은 요구사항을 만족시키기 위한 아키텍트의 작업을 아래와 같이 정의하고 있다.
"아키텍트는 테스트가 가능한 수준까지 작성할 수 있어야 하고, 시스템의 품질속성 간에 상충되는 부분에 대해 합의점을 찾아야 한다." - 개발조직
단기사업, 장기 사업, 조직 구성으로 영향을 받을 수 있다.
- 단기적으로 사업을 완성할 수 있는 자산 재 사용성을 고려해야 한다.
- 장기적 목표에도 부합해야 한다.
- 특정 기술을 필요로 하는 하위 시스템 구성을 포함할 수 있는 아키텍처를 수립해야 한다. - 배경과 경험
아키텍트의 배경,경험이 수립하려고 하는 아키텍처에 영향을 미친다.
역으로 보자면 아키텍트를 고용하는 사람 입장에서는 가능하면 목표에 부합되는 경험을 가진 아키텍트를 선발하는 것이 위험 부담을 줄일 수 있다는 설명이 되겠다. - 기술적 환경
현재 적용하는 시점에서의 업계 표준, SW 공학 기법 등 기술적 환경에 영향 받는다. - 기타요인
아키텍트는 다양한 영향 요소들이 상충하여 충돌이 발생할 경우, 이해관계자가 적극적으로 문제해결에 참여할 수 있도록 유도해야 하며, 트레이드오프가 발생할 경우 절충 능력과 협상력, 대화 능력을 갖추어야 한다. - 아키텍처의 영향 요인과 순환 관계
-. 아키텍처는 개발 조직 구성에 영향을 미친다.
개발 조직으로부터 피드백을 받게 된다.
- 아키텍처는 개발 조직 목표에 영향을 미친다.
1.2 소프트웨어 프로세스와 아키텍처 비지니스 사이클
아키텍처는 상호간의 피드백 관계를 형성하는데 다음과 같은 수립 확동이 있다.
- 사업 기회 창출
미래의 요구사항을 포함할 수 있는 아키텍처 수립 - 요구사항 이해
각종 명세 언어, 현행 유사 시스템과의 비교, 프로토타입의 개발을 통해 시스템의 동작과 인터페이스를 정확히 이해 및 수립되어야 함. - 아키텍처 선택 혹은 수립
개념적 통합을 가능케할 시스템 아키텍처 수립. - 아키텍처 문서화와 의사소통
모든 이해 관계자가 이해할 수 있도록 명세 수립. - 아키텍처 분석과 평가
이해관계자들의 요구사항 반영을 확인할 수 있는 분석 기법을 활용한 평가 결과 수립. - 아키텍처 기반 시스템 개발
개발자의 아키텍처 이해 지원 방안 수립. - 아키텍처 준수 여부 확인
개발 시스템과 아키텍처 사이의 차이 확인 방안 수립.
1.3 좋은 아키텍처의 조건
어떤 아키텍처도 좋다 나쁘다 평가할 수 없으며, 단 아래와 같은 권고사항으로써 아키텍처를 점검할 수 있다.
1.3.1 프로세스 권고사항
- 아키텍처는 아키텍트를 통해 수립.
- 아키텍트는 요구사항 수집,정제,우선순위 수립.
- 아키텍처는 적어도 하나의 정적뷰,동적뷰를 포함하고 이해하기 쉬운 기호로 문서 기술 되어야 함.
- 아키텍처는 전체 이해관계자가 배포 받고 검증시 참여되어야 함.
- 아키텍처는 정량적 성능 품질로 평가되어야 하고 논리적으로 확인되어야 함.
- 아키텍처는 요구사항을 수용가능한 포함하고 점진적 기능 확장 가능해야 함.
- 아키텍처는 자원 경쟁 시에 대한 적정 제한을 제시해야 함.
1.3.2 구조적 권고 사항.
- 아키텍처는 모듈단위로 구분 가능해야 하며, 하부 구조 변경 시 유연하게 대처 가능해야 함.
- 모듈은 내부 변화(데이터나 행위 자체)를 은닉할 수 있도록 인터페이스를 제공해야 함.
- 품질 속성은 구체적이고 일반적인 기법으로 정의 되어야 함.
- 아키텍처는 특정 버전의 제품에 대한 의존도가 없어야 함.
- 데이터의 생성과 사용 모듈은 구분되어야 함.
- 병렬 처리 시스템에서 모듈은 하나의 컴포넌트나 커넥터로 표시해서는 않된다.
- 모든 태스크나 프로세스는 문서화 되어야 함.
- 아키텍처는 몇 가지(적정)의 단순한 상호작용 패턴을 정해 표시해야 함.
위 권고 사항이 절대적이지 않으나 수립과정 시 문제점을 파악할 수 있는 이정표.
※ 첨부.
아키텍처의 종류
- Business Architecture (BA)
- Application Architecture (AA)
- Solution Architecture (SA)
(Software Architecture 가 아닌가 싶은데 확인이 필요하네요..) - Data Architecture (DA)
아키텍트의 위치
- Enterprise Architect (EA)
전체 아키텍처 설계 - Solution Architect (SA)
특정 솔루션 아키텍처 설계 - Technical Architect (TA)
하드웨어 및 네트워크 아키텍처 설계 - Application Architect (AA)
어플리케이션 표준 가이드 및 아키텍처 구조 설계 - Data Architect (DA)
데이터 아키텍처 설계 - Global Architect (GA) [Optional]
대규모 프로젝트에서 EA의 역할 분담자로 나머지 아키텍트의 통제와 상세 기술 설계 영역을 담당
[참고. 조대협의 블로그 http://bcho.tistory.com/668]
