서장: 소프트웨어 아키텍처와 문서화 <br/> P1: 아키텍처의 역할 <br/> 용어 설명: 소프트웨어 아키텍처 <br/> 견해 소개: 아키텍처는 설계와 어떻게 다른가? <br/> 용어 설명: 문서화, 설명, 표현, 명세 <br/> P2: 아키텍처 문서 활용방안 <br/> P3: 인터페이스 <br/> P4: 뷰 <br/> 용어 설명: 아키텍처 뷰 <br/> P5: 뷰타입과 스타일 <br/> P.5.1 뷰타입 <br/> P.5.2 스타일 <br/> P.5.3 뷰타입, 스타일, 뷰에 대한 요약 <br/> 용어 설명: 모듈과 컴포넌트 <br/> P6: 좋은 문서를 만드는 7가지 규칙 <br/> P.6.1 규칙 1: 읽는 사람의 관점에서 문서를 작성한다 <br/> P.6.2 규칙 2: 불필요한 반복을 피한다 <br/> P.6.3 규칙 3: 모호함을 피한다 <br/> P.6.4 규칙 4: 표준 체계를 따른다 <br/> P.6.5 규칙 5: 근거를 남겨둔다 <br/> P.6.6 규칙 6: 문서를 항상 최신으로 유지하되 너무 앞서나가지 않는다 <br/> P.6.7 규칙 7: 목적에 맞게 작성됐는지 사후 검토한다 <br/> 견해 소개: 화살표에 대한 고민 <br/> P7: 요약정리 <br/> P8: 토론 문제 <br/> P9: 더 읽을거리 <br/><br/>1부: 소프트웨어 아키텍처 뷰타입과 스타일 <br/> 1.1 뷰타입과 스타일 목록 <br/> I.1.1 모듈 뷰타입 <br/> I.1.2 컴포넌트와 커넥터 뷰타입 <br/> I.1.3 할당 뷰타입 <br/> 1.2 스타일 지침 : 스타일 문서화 표준 구조 <br/><br/>1장 모듈 뷰타입 <br/> 1.1 개요 <br/> 1.2 모듈 뷰타입의 요소, 관계, 속성 <br/> 1.2.1 요소 <br/> 1.2.2 관계 <br/> 1.2.3 속성 <br/> 용어 설명: 교체가능성 <br/> 1.3 모듈 뷰타입이 적합한 상황 <br/> 1.4 모듈 뷰타입 표기법 <br/> 1.4.1 비공식 표기법 <br/> 1.4.2 UML <br/> 1.5 다른 뷰타입과의 관계 <br/> 1.6 요약정리 <br/> 1.7 토론 문제 <br/> 1.8 더 읽을거리 <br/><br/>2장 모듈 뷰타입 스타일 <br/> 2.1 분할 스타일 <br/> 2.1.1 개요 <br/> 2.1.2 요소, 관계, 속성 <br/> 2.1.3 분할 스타일의 용도 <br/> 2.1.4 분할 스타일 표기법 <br/> 2.1.5 다른 스타일과의 관계 <br/> 2.1.6 분할 스타일의 예제 <br/> 용어 설명: 하위시스템 <br/> 2.2 사용 스타일 <br/> 2.2.1 개요 <br/> 2.2.2 요소, 관계, 속성 <br/> 2.2.3 사용 스타일의 용도 <br/> 2.2.4 사용 스타일 표기법 <br/> 2.2.5 다른 스타일과의 관계 <br/> 2.2.6 사용 스타일의 예제 <br/> 용어 설명: 사용 <br/> 2.3 일반화 스타일 <br/> 2.3.1 개요 <br/> 2.3.2 요소, 관계, 속성 <br/> 2.3.3 일반화 스타일의 용도 <br/> 2.3.4 일반화 스타일 표기법 <br/> 2.3.5 다른 스타일과의 관계 <br/> 용어 설명: 일반화 <br/> 2.3.6 일반화 스타일의 예제 <br/> 2.4 계층 스타일 <br/> 2.4.1 개요 <br/> 2.4.2 요소, 관계, 속성 <br/> 2.4.3 계층 스타일의 용도 <br/> 2.4.4 계층 스타일 표기법 <br/> 2.4.5 다른 스타일과의 관계 <br/> 2.4.6 계층 스타일의 예제 <br/> 용어 설명: 가상 기계 <br/> 견해 소개: 거슬러 올라가는 소프트웨어 <br/> 견해 소개: '수준' 때문에 생기는 혼란 <br/> 견해 소개: UML 클래스 다이어그램 남용금지! <br/> 2.5 요약정리 <br/> 2.6 토론 문제 <br/> 2.7 더 읽을거리 <br/><br/>3장 컴포넌트와 커넥터 뷰타입 <br/> 3.1 개요 <br/> 3.2 C&C 뷰타입의 요소, 관계, 속성 <br/> 3.2.1 요소 <br/> 3.2.2 관계 <br/> 3.2.3 속성 <br/> 견해 소개: 커넥터가 정말 필요한가? <br/> 견해 소개: 커넥터 추상화 하기 <br/> 3.3 C&C 뷰타입의 용도 <br/> 견해 소개: 데이터 흐름과 제어 흐름 투영 <br/> 3.4 C&C 뷰타입 표기법 <br/> 3.5 다른 뷰타입과의 관계 <br/> 3.6 요약정리 <br/> 3.7 토론 문제 <br/> 3.8 더 읽을거리 <br/><br/>4장 컴포넌트와 커넥터 뷰타입 스타일 <br/> 4.1 파이프와 필터 스타일 <br/> 4.1.1 개요 <br/> 4.1.2 요소, 관계, 속성 <br/> 4.1.3 파이프와 필터 스타일의 용도 <br/> 4.1.4 다른 스타일과의 관계 <br/> 4.1.5 파이프와 필터 스타일의 사례 <br/> 4.2 공유 데이터 스타일 <br/> 4.2.1 개요 <br/> 4.2.2 요소, 관계, 속성 <br/> 4.2.3 공유 데이터 스타일의 용도 <br/> 4.2.4 다른 스타일과의 관계 <br/> 4.2.5 공유 데이터 스타일의 사례 <br/> 4.3 발행 구독 스타일 <br/> 4.3.1 개요 <br/> 4.3.2 요소, 관계, 속성 <br/> 4.3.3 발행 구독 스타일의 용도 <br/> 4.3.4 다른 스타일과의 관계 <br/> 4.3.5 발행 구독 스타일의 사례 <br/> 4.4 클라이언트 서버 스타일 <br/> 4.4.1 개요 <br/> 4.4.2 요소, 관계, 속성 <br/> 4.4.3 클라이언트 서버 스타일의 용도 <br/> 4.4.4 다른 스타일과의 관계 <br/> 4.4.5 클라이언트 서버 스타일의 사례 <br/> 4.5 피어 투 피어 스타일 <br/> 4.5.1 개요 <br/> 4.5.2 요소, 관계, 속성 <br/> 4.5.3 피어 투 피어 스타일의 용도 <br/> 4.5.4 다른 스타일과의 관계 <br/> 4.5.5 피어 투 피어 스타일의 사례 <br/><br/>2부 실전 소프트웨어 아키텍처 문서화 <br/><br/>6장 고급 개념 <br/> 6.1 정보 분할과 뷰 패킷, 정제, 설명적 완결성 <br/> 6.1.1 뷰 패킷 <br/> 6.1.2 정제 <br/> 6.1.3 설명적 완결성 <br/> 6.2 컨텍몽트 다이어그램 사용 <br/> 6.2.1 최상위 수준 컨텍스트 다이어그램 <br/> 6.2.2 컨텍스트 다이어그램의 내용 <br/> 6.2.4 컨텍스트 다이어그램 표기법 <br/> 6.2.5 컨텍스트 다이어그램에 대한 예제 <br/> 6.3 결합 뷰 <br/> 6.3.1 결합 뷰를 사용해야 하는 경우 <br/> 6.3.2 대응의 유형 <br/> 6.3.3 요소, 관계, 속성 <br/> 6.3 결합 뷰 문서화 <br/> 6.3.5 결합 뷰 예제 <br/> 6.3.6 그 밖의 예제 <br/> 6.4 가변성과 역동성 문서화 <br/> 6.4.1 가변성 <br/> 6.4.2 역동성 <br/> 6.4.3 정보 기록 <br/> 6.4.4 가변성과 역동성 표기법 <br/> 견해 소개: 시점이란 무엇인가? <br/> 6.5 새로운 스타일 작성과 문서화 <br/> 용어 설명: 스타일과 패턴 <br/> 6.6 요약정리 <br/> 6.7 토론 문제 <br/> 6.8 더 읽을거리 <br/><br/>7장 소프트웨어 인터페이스 문서화 <br/> 7.1 개요 <br/> 7.2 인터페이스 명세 <br/> 7.3 인터페이스 문서 표준 구성 <br/> 용어 설명: 예외와 오류 처리 <br/> 7.4 인터페이스 문서와 관련된 이해관계자 <br/> 7.5 인터페이스 문서 표기법 <br/> 7.5.1 인터페이스의 존재 제시 <br/> 7.5.2 형태정보 전달 <br/> 7.5.3 의미정보 전달 <br/> 7.5.4 요약 <br/> 견해 소개: 다중 인터페이스 <br/> 용어 설명: 호출규약, 인터페이스, API <br/> 7.6 인터페이스 문서화 예제 <br/> 7.6.1 SCR 스타일의 인터페이스 <br/> 7.6.2 IDL <br/> 7.6.3 맞춤형 표기법 <br/> 7.6.4 XML <br/> 7.7 요약정리 <br/> 7.8 토론 문제 <br/> 7.9 더 읽을거리 <br/><br/>8장 행위 문서화 <br/> 8.1 구조를 넘어서 <br/> 8.2 행위 문서화 위치 <br/> 8.3 행위 문서화 필요성 <br/> 8.3.1 시스템 분석 <br/> 8.3.2 개발 작업 추진 <br/> 8.4 문서화 내용 <br/> 8.4.1 통신 방식 <br/> 8.4.2 순서 제약사항 <br/> 8.4.3 시간에 따라 발생하는 자극 <br/> 8.5 행위 문서화에 쓰이는 언어와 표기법 <br/> 8.5.1 추적trace <br/> 8.5.2 정적 모델 <br/> 8.6 요약정리 <br/> 8.7 토론 문제 <br/> 8.8 더 읽을거리 <br/><br/>9장 뷰 선택 <br/> 9.1 이해관계자들에게 필요한 문서 <br/> 견해 소개: 아키텍처 트레이드오프 분석 방법 <br/> 9.2 선택하기 <br/> 9.3 두 가지 예제 <br/> 9.3.1 소규모 프로젝트 A-7E <br/> 9.3.2 대규모 프로젝트 ECS <br/> 9.4 요약정리 <br/> 9.5 토론 문제 <br/> 9.6 더 읽을거리 <br/><br/>10장 문서 패키지 작성 <br/> 10.1 문서를 하나로? 여러 개로? <br/> 견해 소개 'is'의 의미 <br/> 10.2 뷰 문서화 <br/> 견해 소개: 표현 방법도 중요해 <br/> 10.3 여러 뷰를 고려한 문서화 <br/> 10.3.1 어떻게 문서가 구성됐는가: 구성 정보 <br/> 10.3.2 무엇을 아키텍처로 봤는가: 구성 내용 <br/> 10.3.3 왜 아키텍처가 현재의 모습을 하고 있는가: 배경, 근거, 설계 제약사항 <br/> 견해 소개: 전역 분석Global Analysis <br/> 10.4 소프트웨어 아키텍처 문서의 검증 <br/> 견해 소개: 용어집을 만들면 좋았을 텐데 <br/> 10.5 요약정리 <br/> 10.6 토론 문제 <br/> 10.7 더 읽을거리 <br/><br/>11장 여러 뷰를 고려한 문서 작성에 대한 다양한 시각 뷰에 대한 다양한 시각 <br/> 11.1 개요 <br/> 11.2 래셔널 통합 프로세스(RUP)/크루첸 4+1 <br/> 11.3 UML <br/> 11.3.1 클래스 다이어그램과 객체 다이어그램 <br/> 11.3.2 컴포넌트 다이어그램 <br/> 11.3.4 행위 다이어그램 <br/> 11.4 지멘스 4 뷰 <br/> 11.4.1 전역 분석 <br/> 11.4.2 개념적 아키텍처 뷰 <br/> 11.4.3 모듈 아키텍처 뷰 <br/> 11.4.4 실행 아키텍처 뷰 <br/> 11.4.5 코드 아키텍처 뷰 <br/> 11.4.6 요약 <br/> 11.5 C4ISR 아키텍처 프레임워크 <br/> 11.5.2 공통 산출물 <br/> 11.6 ANSI/IEEE-1471-2000 <br/> 11.7 데이터 흐름과 제어 흐름 <br/> 11.7.1 데이터 흐름 뷰 <br/> 11.7.2 제어 흐름 뷰 <br/> 견해 소개: 그거 전부 다 추측이잖아요! <br/> 11.8 RM-ODP 371<br/> 11.9 아키텍처 문서화의 결말 <br/> 11.9.1 아키텍처 설명 언어 <br/> 11.9.2 상용 컴포넌트 <br/> 11.9.3 하이퍼텍스트 문서 <br/> 11.9.4 형상 관리 <br/> 11.10 당부의 말 <br/> 11.11 더 읽을거리

소프트웨어 아키텍처를 다루는 실무자들이 꼭 읽어야 할 책. 소프트웨어 아키텍트로서 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여준다. <br/><br/>정말 간단한 것 외에 모든 소프트웨어 시스템은 아키텍처에 큰 관심을 기울여야 한다. 프로젝트에 관련된 많은 이해관계자 입장에서 프로젝트의 모든 단계를 연결해 주는 개념적 접착제 역할을 하는 바로 그 소프트웨어 아키텍처 말이다. 문제를 제대로 해결할 수 있는 아키텍처가 없으면 프로젝트가 휘청거리다가 결국 실패하고 말 것이다. 물론 뛰어난 아키텍처가 있다고 해도 그것을 사람들에게 제대로 이해시키거나 전달하지 못한다면, 다시 말해 제대로 문서화하지 못한다면, 프로젝트가 제대로 성공한다고 보기 어렵다.<br/> <br/>요즘 들어서 아키텍처가 매우 중요한 요소로 널리 받들어지기는 하지만, 언어나 표기법에 얽매임 없이 제대로 포착해내는 방법이나 지침이 아직은 뚜렷이 없었다. 이 책 『소프트웨어 아키텍처 문서화』에서는 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여주고 있다. 강력한 아키텍처를 만들어내려면 그 결과로 나올 아키텍처를 설명하는 일도 매우 상세하면서 깔끔하게 해낼 수 있어야 하고, 아키텍처의 구성도 잘해야 한다. 그래야 사람들이 필요한 정보를 빠르게 찾아낼 수 있다.<br/> <br/>■ 좋은 문서를 만드는 일곱 가지 규칙<br/>■ 소프트웨어 아키텍처를 활용하는 용도, 목표, 전략<br/>■ 아키텍처 뷰와 스타일에 대한 일반적인 소개와 구체적인 예제<br/>■ 소프트웨어의 인터페이스와 행위에 대한 문서화하는 방법<br/>■ 정보를 수집해서 일관성을 갖춘 패키지로 만드는 데 도움이 되는 문서 양식<br/><br/>서장에서는 이 책을 읽는 데 꼭 필요한 개념과 용어에 대해 정리한다. 여기서는 소프트웨어 아키텍처 문서를 어떻게 사용할 것이고, 그것이 왜 중요한지를 살펴본다. 그리고 아키텍처 뷰타입과 스타일과 뷰라는, 이 책에서 채택한 문서화 접근법의 근간을 이루는 세 가지 개념을 정의한다. 또한 좋은 문서를 만드는 7가지 규칙에 대해서도 소개한다.<br/><br/>1부 소프트웨어 아키텍처 뷰타입과 스타일에서는 소프트웨어 아키텍처 문서화에 쓰이는 기본적인 도구인 뷰타입을 소개한다. 뷰타입이란 뷰에서 제공되는 정보의 종류를 명세해 놓은 것이다. 뷰타입에는 기본적으로 모듈, 컴포넌트와 커넥터, 할당이라는 세 가지가 있다. 개별 뷰타입 내에는 여러 가지의 아키텍처 스타일이 있다. 아키텍처 스타일은 뷰타입을 특화시켜 놓은 것으로 보면 된다. 1부 도입부에 1장부터 5장에 걸쳐 설명할 스타일들에 대한 간략한 목록을 넣어 놓았다.<br/><br/>2부 소프트웨어 아키텍처 문서화의 이론과 실제에서는 제대로 된 아키텍트라면 반드시 만들어 내야 하는 완전한 구성의 아키텍처 문서 패키지에 중점을 둔다. 다시 말해 2부에서는 1부에서 제시한 그림을 완성하는 과정을 설명한다.<br/><br/>이 책은 소프트웨어 프로젝트에서 아키텍처 문서를 작성하는 책임을 진 아키텍트와 기술문서 작성자들을 주 대상으로 해서 썼다. 물론 아키텍처 문서를 받아서 활용하는 입장에 있는 사람들도 함께 염두에 뒀다. 소프트웨어 아키텍트들은 이 책을 자신이 작성한 아키텍처 문서와 함께 제공하고 문서화 구성 원칙, 표기법, 개념, 관례 등을 설명한 해당 절을 적어놓는 방식을 활용하면 좋을 것이다.<br/><br/>이 책은 기본적으로 독자들이 소프트웨어 아키텍처 개념과 친숙한 상태에 있다고 가정하고 썼다. 물론 관련 배경지식을 어디서 얻을 수 있는지도 정보를 제공했다. 앞으로 여러 차례에 걸쳐, 독자들이 이미 친근할 만한 아키텍처 뷰, 아키텍처 스타일, 인터페이스 등과 같은 기본 개념들에 대해 좀 더 명확하게 다듬어서 설명할 것이다.

선과 도형으로 표현한 다이어그램은 오랜 동안 시스템 구현을 설명하는 글을 더 의미 있게 만드는 존재였다. 사람들은 이런 다이어그램들을 보고 깨우침을 얻기도 하고, 영감을 받기도 하며, 필요한 정보를 찾기도 하지만, 이 다이어그램들은 완전무결하다고 할 만큼 정확한 것도 완전한 것도 아니다. 최근 몇 년 사이 시스템 구조를 설계하거나 아키텍처를 수립하는 작업의 중요성에 관심이 모이기 시작했다. 이제 이 책 『소프트웨어 아키텍처 문서화』가 제공하는 지침에는 설계에 도움이 될 뿐만 아니라, 시스템의 소프트웨어 비용 전체에서 절반 정도를 차지하는 유지보수 인력들에 유용한 정보들이 정리돼 있다. 유지보수 비용의 절반은 시스템이 어떻게 구성돼 있고 어디를 고쳐야 하는지 알아내는 데 쓰인다는 사실을 고려하면, 문서화된 아키텍처는 시스템 유지보수 인력들이 구현이라는 밀림을 헤쳐나가기 위해 반드시 지니고 다녀야 하는 지도라고 할 수 있다.
매리 셔 (카네기 멜론 대학교 컴퓨터 공학과 앨런 J. 펠리스 석좌교수)

각자의 시각에서 소프트웨어 아키텍처를 이해하고 활용해야 하는 이해당사자들(사용자, 인수자, 개발자, 테스터, 유지보수 담당자, 상호운용 담당자, 기타 인력)이 다양하게 존재하는 상황에서 다중 소프트웨어 아키텍처 뷰는 필수 불가결한 존재이다. 따라서 자연히 여러 개의 아키텍처 뷰 사이에서 어떻게 일관성을 확보할지 고민하게 되고, 이는 소프트웨어 아키텍처 분야에서 가장 중요하면서도 어려운 과제로 남는다. 이 책은 분석 가능한 소프트웨어 아키텍처 뷰를 정의하고, 그런 뷰를 통합할 수 있는 틀을 만드는 데 매우 소중한 첫발을 내딛고 있다.
배리 보엠 (TRW 소프트웨어 공학 교수, 남가주대학(USC) 소프트웨어 공학 센터 책임자)

이 책의 저자들보다 이 책을 더 잘 쓸 수 있는 사람들은 아마 없을 것이다. 우선 글의 내용이 읽기 쉬운데다, 군데군데 유머도 효과적으로 활용하고 있다. 필요할 때는 적당히 관찰자의 입장에 있다가도 끝으로 가면 직접적이면서도 명확한 결론을 내려준다. 이 책에 담긴 철학적인 요소들도 눈길을 끈다. 이 책에서 저자들은 다른 사람들이 인식하지 못한 개념들을 고찰하고, 그런 개념들과 관련된 문제점들을 제시한 후, 그 문제들을 해결해 버린다. 가히 아키텍처 문서화라는 주제에 해결사 같은 책이라 하겠다.
로버트 글래스 (Journal of Systems and Software 지 수석 편집자)

소프트웨어 아키텍처란 핵심적인 설계 결정사항 중 대부분을 추상적으로 표현해 놓은 것이다. 그래서 소프트웨어 아키텍처에서는 소프트웨어 구현상으로는 직접적으로 보이지 않는 개념들을 사용한다. 그럼 이런 결정사항들을 어떻게 찾아내서 표현할까? 복잡한 소프트웨어를 쉽게 이해할 수 있게 하는 개념들을 어떻게 찾아낼까? 이 책은 전문적인 아키텍트들이 모여 유용한 아키텍처 개념, 핵심적인 설계 결정사항, 복잡한 소프트웨어를 아키텍처 뷰로 표현하는 실무적인 방법 등에 대한 경험과 이해를 서로 공유한 끝에 나온 빼어난 결과물이라 할 수 있다.
알렉산더 란 (노키아 소프트웨어 아키텍처 책임 연구원)

10년 전에 나는 새롭고 야심 찬 제어통제 시스템을 만드는 프로젝트의 아키텍처팀을 이끌게 됐었다. 처음 시작은 별로 매끄럽지 않았지만, 아키텍처 설계 작업이 점점 제 속도를 내며 진행돼 갔다. 아키텍트들은 작업을 진행하면서 새로운 것을 고안해 내고 문제를 해결하며, 설계해서 실제로 돌려 보기도 하면서 흥미진진해했다. 우리는 브레인스토밍 회의를 여러 번 진행했고, 그때마다 화이트보드가 파편적인 설계안들로 메워졌고, 공책은 메모로 가득 차 갔다. 그 과정에서 다양한 프로토타입을 만들어 우리의 이론을 검증하거나 기각했다. 개발팀의 규모가 커짐에 따라, 아키텍트들은 점점 더 많은 사람에게 최신 아키텍처 원칙들을 설명해야만 했다. 설명을 들어야 할 사람 중에는 새로운 개발자들뿐만 아니라 개발 그룹 밖의 여러 부서에서 온 사람들도 있었다. 그 중 일부는 이런 새로운 종류의 소프트웨어 아키텍처 개념에 끌렸고, 일부는 이 아키텍처가 자신들에게 어떤 영향을 미치는지 알고 싶어 했다. 다시 말해 계획수립, 팀 또는 하부조직 구성, 시스템 납품, 시스템 부품 구매 과정에 끼치게 될 영향 등을 알고자 했다. 일부는 이 아키텍처를 설계하는 데 영향을 끼치고 싶어했다. 게다가 개발과 거리가 있는 고객이나 잠재고객들도 한자리 끼고 싶어했다. 이에 따라 아키텍트들은 짧게는 몇 시간에서 길게는 며칠까지 상당한 시간을 들여서 다양한 형태와 수준으로, 다양한 청중에게 맞는 어투로 아키텍처를 설명해야만 했다. 그 결과 각 부서에서 온 청중들이 아키텍처를 더 잘 이해할 수 있었다.

이렇게 의사소통을 하는 데 중심이 잡히자 우리의 역량은 서서히 강화됐다. 한쪽에서는 아키텍처를 설계하고 검증하느라 바빠졌고, 다른 한쪽에서는 가끔 많은 청중을 모아놓고 작업해 놓은 아키텍처의 내용이 무엇인지, 왜 그렇게 돼 있는지, 다른 해결책은 왜 선택하지 않았는지를 발표했다. 그러나 그것이 과했던지 프로젝트가 몇 달 정도 진행된 후에는 우리 내부에서도 스스로 결정해 놓은 아키텍처의 모습에 대해 이견이 생기기 시작했다.

이로 인해 우리는 결국 '기록되지 않은 것은 존재하지 않는다'라는 결론에 이르게 됐다. 이 원칙은 그 이후 두 해 동안 아키텍처팀 내에서 중심사상이 됐다. 고대 중국의 철학자인 노자는 도덕경에서 이렇게 설파했다.

남들이 나의 일을 궁금해하도록 놓아두라.
나중에 가서 그냥 결과만을 알려 주라.
(36장)

우리가 논의했거나 주장했거나 상상했거나 심지어 칠판에 초안까지 적어 놓았거나 상관없이 무엇이든 아키텍처가 될 수 있었다. 그러나 이 시스템에서는 오직 하나의 주력 문서에 기록된 것만이 실제 아키텍처였다. 그 문서가 바로 소프트웨어 아키텍처 문서(SAD, Software Architecture Document)이다. 아키텍처적인 요소와 아키텍처적인 결정 중에서 이 문서에 적혀 있지 않으면 실제로 존재하지 않는 것이다. "SAD에 들어 있지 않으면 실제로 존재하지 않는 것이다"라는 이 한 가지 규칙 덕택에 문서를 계속 개선하고 거의 주 단위로 갱신할 수 있게 됐다. 또한 실제로 시도해 보지 않은 의견들이 분분하게 떠돌아다니는 것이 프로젝트에서 가장 혼동을 일으키는 요소라고 봤을 때, 이런 의견들을 모두 배제할 수 있다는 점도 장점이었다.

소프트웨어 아키텍처 문서는 곧 프로젝트 활동의 중심 요소가 됐다. 아키텍처 문서는 우리의 생각을 남들이 들여다볼 수 있도록 해 주는 최적의 문서일 뿐만 아니라, 우리가 자리를 비우게 되더라도 다른 사람들이 불편하지 않게 됐고, 우리의 설계가 공격받았을 때는 방패막이 역할도 했다.

그 당시 우리가 직면했던 문제 중에서 가장 핵심적인 것들은 다음과 같다. 소프트웨어 아키텍처 중에서 어떤 것을 문서화해야 하는가? 그것을 어떻게 문서화할까? 구성은 어떤 식으로 해야 할까? 표기법은 어떤 것을 사용할 것인가? 얼마나 자세히, 얼마나 추상적으로 표현해야 할까? 우리 시스템만큼 야심 찬 시스템을 기술해 놓은 아키텍처 기술서도 사실 드물었다. 우리는 필요한 것이 생길 때마다 새로 만들어냈다. 이 과정에서 아키텍처라는 것이 평면적인 것이 아니라 어떤 입체적인 실체라는 사실을 곧 깨닫게 됐다. 거기에는 여러 가지 측면이 얽혀 있었고, 그 중에서 몇 가지 측면(뷰라고도 한다)은 소수의 참가자에게만 관심을 끄는 것들이었다. 우리는 문서를 읽어야 할 많은 사람이 0.5그램 가까이 되는 무게의 문서를 만들어 놓으면 열어보지도 않으리라는 사실을 알았다. 게다가 이런 문서들은 갱신하기도 매우 어려워 보였다. 그리고 어떤 선택을 내렸을 때 그에 대한 근거를 제시하지 않으면 다시 재현해내기가 불가능하다는 사실도 깨달았다. 또퇇 예리한 시각을 지닌 이해관계자가 새로 등장할 때마다 이런 사실이 다시 문제가 됐다. 우리는 시각적인 표기법을 선택했다. 표기법을 고를 때는 지나치게 모호하거나 헷갈리지 않되 또한 너무 난해하거나 복잡하지도 않은 것으로 했다. 참가자들 대부분 기를 초장에 꺾어버리지 않도록 말이다.

이제 소프트웨어 아키텍트들은 자신들이 만드는 소프트웨어 아키텍처를 어떤 식으로 문서화할지 결정하는 데 매우 좋은 시작점에 서 있다. 손쉽게 할 수 있기 때문이다. 이 책의 저자들은 내가 겪었던 것과 비슷한 경험을 수없이 겪어 오면서 그 과정에서 깨달은 중요한 내용들을 뽑아 냈다. 이 책의 저자들은 여러 소프트웨어 아키텍처 문서를 참고했다. 또한 연구 자료들을 검토하고 출간된 모든 책들을 연구한 다음, 표준적인 요소를 점검하고 그 과정에서 얻은 지혜를 모두 정리해서 이 안내서를 만들어낸 것이다. 따라서 이 책은 독자들이 소프트웨어 아키텍처 문서를 작성할 때 알아야 할 핵심적인 내용으로 가득차게 됐다. 이 책에는 소프트웨어 아키텍처의 범위나 구성, 사용하거나 사용하지 말아야 할 기법이나 도구, 표기법은 물론 비교법이나 조언, 경험법칙 등에 대한 안내도 들어 있다. 또한 이 책에는 처음 시작할 때 유용하게 활용할 수 있을 뿐만 아니라, 방향을 잃고 절망할 때도 계속해서 방향을 잡아주는 역할을 해줄 문서양식도 들어 있다.

이 책의 가치는 실로 엄청나다. 소프트웨어 아키텍처를 기술해서 여러 이해관계자에게 알리는 일은 매우 중요한 작업이라 할 수 있는데, 이 지침서가 그 과정에서 발생할 수 있는 수 개월 간의 실패와 반복의 시간을 줄이고, 쓸데없는 불편함을 많이 제거해줄 것이며, 궁극적으로 이런 모든 시도 자체를 무의미하게 만드는 값비싼 실수들을 많이 줄여줄 것이다. 이 책은 소프트웨어 아키텍트들이 책장에 꼭 갖춰 놓아야 할 중요한 참고서로 자리 잡을 것이다.
필립 크루첸 (밴쿠버 소재 래셔널 소프트웨어 캐나다의 프로세스 개발 책임자)