매우 간단한 소프트웨어 시스템이 아닌 다음에야, 아키텍처에 세심한 주의를 기울이지 않은 상태로 개발에 성공하기란 쉽지가 않다. 여기서 아키텍처란 시스템을 서로 관련된 부분들로 나누는 방식과 그 부분들이 상호작용하는 방식을 일컫는다. 당면한 문제를 해결할 적당한 아키텍처가 없다면 프로젝트는 실패하고 말 것이다. 또한 매우 훌륭한 아키텍처가 있다 하더라도 이해하기 어렵거나 의미를 전달하기 어려울 때는, 다시 말해 문서화가 잘 안 돼 있을 때는 프로젝트가 혼란에 빠지게 된다.

최근 들어 소프트웨어 아키텍처가 뭇 사람들의 관심을 끌게 됐고, 이를 반영하듯 아키텍처를 다룬 책도 매달 새로이 등장하고 있다. 업계의 요구에 부응해 대학들도 소프트웨어 공학 과정에 소프트웨어 아키텍처 과목을 집어넣고 있다. 이제는 조직 내에 "소프트웨어 아키텍트"라는 구체적인 직책이 일반적으로 받아들여지는 경우가 많아졌고, 소프트웨어 아키텍트로 이루어진 전문적인 실무 그룹도 생겨나게 됐다. 소프트웨어 아키텍처는 주류 국제 학술대회와 워크샵의 주제로도 자리 잡고 있다. 통합 모델링 언어(UML)를 공급하는 회사들은 자신들의 제품을 "소프트웨어 아키텍처를 나타내는 표준 표기법"으로 내세우고 있다. 이런 것을 보면 아키텍처가 최소한 UML과 비슷한 정도로 자리 잡고 있음을 알 수 있다. 카네기 멜론 대학교(CMU)의 소프트웨어 공학 연구소(SEI)에서는 소프트웨어 아키텍처 관련해서 학술지나 학술대회 발표 자료를 1000여 개 가까이 모아 놓았다.

한 가지 안타까운 점은 언어나 표기법과 무관하게 아키텍처를 잡아낼 수 있는 실용적인 지침이 아직 부족하다는 것이다. 좀 더 명확히 말하자면 특정 언어(UML이라고 생각해 보자)를 사용하는 방법을 다루는 책들은 수없이 많다. 그러나 실제로 아키텍트가 요구하는 것은 아키텍처를 최우선 요소로 다루고 그와 관련된 언어는 그것을 지원하는 보조적인 역할로만 보는 지침서라고 봤을 때, 이를 다루는 책은 드물다.

일단 기본적인 배경지식을 살펴보자. 이 분야에서는 아직 소프트웨어 아키텍처에 대한 정의가 하나로 수렴되지 않고 여러 정의가 난립해 있기는 하지만, 이 책에서는 그중에서 하나를 골라 일관되게 사용할 것이다. 바로 베스, 클레멘츠, 캐즈먼(1998)에게서 가져온 정의이다. 비록 이 책에서 주로 다루는 내용이 요소와 관계의 의미에 대한 것이기는 하지만, 여기서 이 정의를 사용하는 이유는 아키텍처에는 매우 다양한 종류의 구조가 있음을 강조하기 위해서다. 구조에는 저마다 다양한 종류의 요소와 관계가 있고, 따라서 이런 구조를 통해 아키텍처의 특정 측면을 파악할 수 있는 시각을 얻을 수 있다.

"외부에 드러나는 속성"이란 어떤 컴포넌트에 대해 다른 컴포넌트들이 두고 있는 가정을 말한다. 예를 들어 컴포넌트에서 제공하는 서비스나 품질속성의 특성, 공유자원에 대한 사용 등을 일컫는다.

아키텍처는 시스템과 그 시스템을 개발하는 프로젝트 양쪽 모두에 대해 청사진의 역할을 한다. 특히 개발 프로젝트에서는 설계나 구현팀에서 수행해야 할 작업할당 내용을 정의할 때 쓰인다. 아키텍처는 성능, 변경용이성, 보안 등과 같은 시스템의 품질을 보장하는 최선의 방법이다. 이런 품질들은 하나같이 통합적인 아키텍처적 시각 없이는 달성할 수 없는 것들이다. 아키텍처라는 산출물은 채택한 설계 안을 가지고 수용 가능한 시스템을 만들어 낼 수 있는지를 확인하는 데 필요한 초기 분석에도 쓸 수 있다. 아키텍처는 배포가 끝난 상황에서 시스템을 이해하고, 유지보수하며, 정보를 뽑아내야 하는 경우에도 핵심적인 역할을 한다. 간단히 말해서 아키텍처는 프로젝트 상의 모든 단계와 프로젝트와 관련된 모든 이해관계자들을 연결해 주는 개념적인 접착제라고 할 수 있다.

아키텍처 문서화 작업은 아키텍처를 수립하는 과정에서 화룡점정에 해당한다. 완벽한 아키텍처라 하더라도 그 내용을 제대로 전달할 수 없다면 아무 쓸모가 없다. 강력한 아키텍처를 만들어 내고자 한다면 모호함 없이 충분히 자세하게 기술해야 하고, 다른 사람들이 필요한 정보를 재빨리 찾을 수 있는 형태로 내용을 구성해야 한다. 그렇게 하지 않으면 그 아키텍처를 활용할 수 없어서 결국 헛수고가 되고 만다.

이 책을 읽을 독자들은 주로 아키텍처 문서를 생산하거나 소비하는데 관련된 사람들, 즉 소프트웨어 개발자들일 것이다. 이 책의 목표는 개발자들이 아키텍처에 대한 정보 중에서 어떤 것들을 찾아내서 기록해야 하는지 결정하는 데 도움을 주고, 또 그런 정보를 기록할 때 필요한 지침, 표기법, 예제 등을 제공하는 데 있다. 저자들은 이 책이 아키텍처를 구성하는 다양한 종류의 정보를 다루는 데 있어 실무자 중심의 지침궼가 될 수 있도록 했다. 또한 저자들은 사람들이 아키텍처 기반의 업무, 즉 구현, 분석, 복구 등의 업무를 수행할 때 아키텍처를 활용할 수 있게 정보를 기록하는 방법을 UML을 비롯한 다양한 표기법으로 만든 예제를 통해 보여주고자 했다. 이에 따라 이 책에는 다음과 같은 내용이 담기게 됐다.

● 소프트웨어 아키텍처 문서 활용: 문서를 어떻게 작성하느냐는 그 문서를 어떻게 활용하기를 원하는지에 달렸다. 이 책에서는 아키텍처 문서화에 서 실현 가능한 최종 목표들을 설정하고, 그렇게 설정한 개별 목표에 맞는 문서화 전략을 제공한다.

● 아키텍처 뷰: 소프트웨어 아키텍처 문서화는 기본적으로 관련 뷰들을 문서화한 다음, 이 정보에 뷰 이외의 관련 정보를 보강하는 작업이다. 이 책의 핵심은 가장 관련이 깊은 아키텍처 뷰들을 뷰타입이라 불리는 세 가지 주요 군으로 묶고, 이를 실제 문서로 옮길 수 있는 실질적인 지침을 넣은 데 있다. 또한 각 뷰타입마다 예제도 제시해 놓았다.

● 정보 패키지화: 뷰에 대해 이해하고 나면 남는 문제는 관련 뷰들을 선택하고, 개별 뷰에 들어가지 못한 정보를 찾아낸 다음, 그 모든 정보를 모아서 일관된 하나의 패키지로 만드는 일이다. 저자들은 이 모든 측면들에 대해 실질적인 조언을 제시하고자 한다.

우리 저자들은 시스템을 성공적으로 구축하려면 아키텍처가 매우 중요하다고 굳건히 믿고 있다. 그러나 효과적으로 의사소통할 수 없는 아키텍처로는 불가능하다. 또한 성공적인 의사소통의 핵심은 문서화에 있다. 모쪼록 이 책이 현장 실무자들에게 매우 쓸모 있는 안내서가 되기를 바라 마지 않는다.

- 폴 클레멘츠, 텍사스 오스틴
- 펠릭스 바크만, 렌 베스, 데이비드 갈란, 제임스 이버스, 리드 리틀,
로버트 노드, 쥬디스 스태포드, 펜실베니아 피츠버그

소프트웨어 아키텍처를 다룬 정전들을 우리말로 옮겨서 펴내고자 마음 먹은 이래로 『소프트웨어 아키텍처: 이론과 실제』를 내고 이제 두 번째 책인 『소프트웨어 아키텍처 문서화』를 내게 됐습니다. 앞의 책이 소프트웨어 아키텍처에 대한 총론이라면, 이번 책은 소프트웨어 아키텍처 문서화에 집중한 각론에 해당합니다. 책의 구성으로 봐도 앞의 '이론과 실제' 책에서는 9장 한 장에서만 '소프트웨어 아키텍처 문서화'라는 제목으로 다뤘던 내용을 이번 책에서는 한 권 전체에 걸쳐 다루고 있습니다. 그만큼 아키텍처 문서화에 대해 필요한 거의 모든 내용을 다룬 전문서라 봐야 할 것입니다. 더불어 '이론과 실제' 11장에서 소개한, 'ATAM'을 필두로 한 소프트웨어 아키텍처 평가 방법들을 집중적으로 소개한 책도 조만간 나올 예정이라 하니, 우리 나라 업계에서도 소프트웨어 아키텍처 분야가 자리잡기 위한 구색이 점차 갖춰져 가는 느낌에 가슴이 뿌듯해 집니다.

한편, 이런 책들은 모두 원서가 2003년부터 2004년 즈음에 나온 것들로, 4~5년이나 지난 오늘에 와서 우리말로 번역돼 나온다는 사실이 안타깝기도 합니다. 어쨌든 이런 식으로 소프트웨어 아키텍처에 대한 총론서와, 세부 주제들을 집중적으로 다룬 각론서가 하나 둘씩 우리말로 소개되면서 소프트웨어 아키텍처라는 분야에 대한 지식이 대중화되고, 그로써 저희 역자들뿐 아니라 많은 독자들께서 동경하는 소프트웨어 아키텍트라는 역할이 좀 더 명확히 이해되고, 또 어떻게 하면 그 역할을 더 잘 할 수 있는지 지침이 제시되면서 업계에서 확고히 자리잡을 수 있지 않을까 기대합니다.

카네기 멜론 대학교의 소프트웨어 아키텍처 과목 교수이며, 저희 역자들에게 '저런 아키텍트가 되면 정말 멋지겠구나'라는 생각을 품게 해 준 역할 모델인 Anthony Lattanze 교수님이 했던 말이 기억납니다. "자네들 모두 소프트웨어 아키텍트가 되고 싶은 거 아네. 그런데 그거 아는가? 아키텍트가 하는 일 중에 98%는 모두 따분하고 재미없는 문서화 작업이라는 거. 나머지 한 2% 정도만 자네들이 신나고 재미있어 하는, 뭔가를 설계하고 결정하는 일이지. 힘 빠지는 얘기겠지만, 어쩌겠는가? 대부분의 전문분야가 다 이런 식으로 돌아가는걸. 약간의 매력적인 작업을 위해 하기 싫은 일을 견뎌내는 거지. 하지만 진짜 전문가는 하기 싫은 일을 효과적으로, 되도록 재미있게 하는 사람이야." 그렇지 못한 사람은 아마추어라는 말씀이시겠지요.

문서화 작업은 따분하고 재미없는 데서 그치지 않고, 하기 싫어서 미루다 보면 종국에는 고통스럽기까지 하더군요. 고통은 어디서 올까요? 부처님 말씀으로는, 무지에서 온다고 합니다. 그렇다면 혹시 제대로 알면 따분하고 재미없고 심지어 고통스럽기까지 한 문서화 작업이 재미있게 다가올까요? 전적으로 그런지는 모르겠지만, 알고 나면 흥미가 일고, 흥미가 일면 재미는 금방이지 않을까요?

이 책은 소프트웨어 문서화라는 게 무엇이고, 잘 하려면 어떤 원칙을 지켜야 하는지 설명하고, 소프트웨어 아키텍처 문서화에서 다뤄야 할 내용이 무엇인지 정리해 놨습니다. 따라서 아키텍처에는 관심이 있지만 문서화에는 관심이 없는 분들(언제까지고 그럴 수는 없겠지만!)도 아키텍처에서 다루는 내용이 어떤 것들인지 좀 더 심도 있게 살펴보거나, 아키텍처를 어떤 모습으로 구성해야 하는지 살펴보는 데 도움이 될 것입니다.

한 가지 양해를 구할 것은, 책 내용에 쉽지 않은 부분이 많아 독자들 눈에 거슬리는 부분이나 어색한 부분이 있지 않을까 하는 것입니다. 특히 90페이지 가까이 되는 소프트웨어 아키텍처 문서화 실전 예제 부록이 그런 부분이 아닐까 싶습니다. 원저자들이 '대규모 프로젝트 문서화 이렇게 한다!'를 사실적으로 보여주기 위해 전형적인 예제를 넣은 것인데, 안타깝게도 다루는 내용이 인공위성에서 데이터를 수집해 가공, 배포하는 쪽입니다. 분야가 워낙 독특하고 국내에서 접하기 힘든 내용들이라, 저희 역자들도 우리말 어휘나 표현으로 적절히 옮기기 어려운 점이 많았습니다. 간혹 틀린 데가 있더라도 독자들의 너그러운 양해 바랍니다.

끝으로 이 자리를 빌어 투박한 번역 원고를 검토해 여러 가지 고칠 곳을 지적해 주신 맹주원님과 정희종님, 엄태욱님께 감사 드립니다. 또한 원저자 중 한 분으로, 한국인 제자들이 자신이 쓴 책을 번역한다는 소식을 듣고 특별히 한국어판 추천의 글을 써 주신 카네기 멜론 대학교의 David Garlan 교수님께도 감사의 말씀을 전합니다.

2009년 1월 13일
역자 일동

소프트웨어 아키텍처를 다루는 실무자들이 꼭 읽어야 할 책. 소프트웨어 아키텍트로서 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 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그램 가까이 되는 무게의 문서를 만들어 놓으면 열어보지도 않으리라는 사실을 알았다. 게다가 이런 문서들은 갱신하기도 매우 어려워 보였다. 그리고 어떤 선택을 내렸을 때 그에 대한 근거를 제시하지 않으면 다시 재현해내기가 불가능하다는 사실도 깨달았다. 또퇇 예리한 시각을 지닌 이해관계자가 새로 등장할 때마다 이런 사실이 다시 문제가 됐다. 우리는 시각적인 표기법을 선택했다. 표기법을 고를 때는 지나치게 모호하거나 헷갈리지 않되 또한 너무 난해하거나 복잡하지도 않은 것으로 했다. 참가자들 대부분 기를 초장에 꺾어버리지 않도록 말이다.

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

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