소프트웨어 아키텍처를 다루는 실무자들이 꼭 읽어야 할 책. 소프트웨어 아키텍트로서 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여준다.


[ 소개 ]

정말 간단한 것 외에 모든 소프트웨어 시스템을 수립할 때는 아키텍처에 큰 관심을 기울여야 한다. 프로젝트에 관련된 많은 이해관계자 입장에서 프로젝트의 모든 단계를 연결해 주는 개념적 접착제 역할을 하는 바로 그 소프트웨어 아키텍처 말이다. 문제를 제대로 해결할 수 있는 아키텍처가 없으면 프로젝트는 휘청거리다가 결국 실패하고 말 것이다. 물론 뛰어난 아키텍처가 있다고 해도 그것을 사람들에게 제대로 이해시키거나 전달하지 못한다면, 다시 말해 제대로 문서화하지 못한다면, 프로젝트가 제대로 성공한다고 보기 어렵다.

요즘 들어서 아키텍처가 매우 중요한 요소로 널리 받들어지기는 하지만, 언어나 표기법에 얽매임 없이 제대로 포착해내는 방법이나 지침이 아직은 뚜렷이 없었다. 이 책 『소프트웨어 아키텍처 문서화』에서는 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여준다. 강력한 아키텍처를 만들어내려면 그 결과로 나올 아키텍처를 설명하는 일도 매우 상세하고도 깔끔하게 해낼 수 있어야 하고, 아키텍처의 구성도 잘해야 한다. 그래야 사람들이 필요한 정보를 빠르게 찾아낼 수 있다.


[ 이 책에서 다루는 내용 ]

■ 좋은 문서를 만드는 일곱 가지 규칙
■ 소프트웨어 아키텍처를 활용하는 용도, 목표, 전략
■ 아키텍처 뷰와 스타일에 대한 일반적인 소개와 구체적인 예제
■ 소프트웨어의 인터페이스와 행위에 대한 문서화하는 방법
■ 정보를 수집해서 일관성을 갖춘 패키지로 만드는 데 도움이 되는 문서 양식


[ 이 책의 구성 ]

서장에서는 이 책을 읽는데 꼭 필요한 개념과 용어에 대해 정리한다. 여기서는 소프트웨어 아키텍처 문서를 어떻게 사용할 것이고, 그것이 왜 중요한지를 살펴본다. 그리고 아키텍처 뷰타입과 스타일과 뷰라는, 이 책에서 채택한 문서화 접근법의 근간을 이루는 세 가지 개념을 정의한다. 또한 좋은 문서를 만드는 7가지 규칙에 대해서도 소개한다.

1부. 소프트웨어 아키텍처 뷰타입과 스타일에서는 소프트웨어 아키텍처 문서화에 쓰이는 기본적인 도구인 뷰타입을 소개한다. 뷰타입이란 뷰에서 제공되는 정보의 종류를 명세해 놓은 것이다. 뷰타입은 기본적으로 모듈, 컴포넌트와 커넥터, 할당이라는 세 가지가 있다. 개별 뷰타입 내에는 여러 가지 아키텍처 스타일이 있다. 아키텍처 스타일은 뷰타입을 특화 시켜 놓은 것으로 보면 된다. 1부 도입부에 1장부터 5장에 걸쳐 설명할 스타일들에 대한 간략한 목록을 넣어 놓았다.

2부. 실전 소프트웨어 아키텍처 문서화에서는 제대로 된 아키텍트라면 반드시 만들어 내야 하는 완전한 구성의 아키텍처 문서 패키지에 중점을 둔다. 다시 말해 2부에서는 1부에서 제시한 그림을 완성하는 과정을 설명한다.


[ 이 책의 대상 독자 ]

이 책은 소프트웨어 프로젝트에서 아키텍처 문서를 작성하는 책임을 진 아키텍트와 기술문서 작성자들을 주 대상으로 해서 썼다. 물론 아키텍처 문서를 받아서 활용하는 입장에 있는 사람들도 함께 염두에 뒀다. 소프트웨어 아키텍트들은 자신이 작성한 아키텍처 문서와 함께 이 책을 제공하고 문서화 구성 원칙, 표기법, 개념, 관례 등을 설명한 해당 절을 적어놓는 방식을 활용하면 좋을 것이다.

이 책은 기본적으로 독자들이 소프트웨어 아키텍처 개념과 친숙한 상태에 있다고 가정하고 썼다. 물론 관련 배경지식을 어디서 얻을 수 있는지 정보도 제공했다. 앞으로 여러 차례에 걸쳐, 독자들이 이미 친근할 만한 아키텍처 뷰, 아키텍처 스타일, 인터페이스 등과 같은 기본 개념들에 대해 좀 더 명확하게 다듬어서 설명할 것이다.


[ 추천의 글 ]

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

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

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

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

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

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

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

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

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

[ 한국어판 출간에 부쳐 ]

이 자리를 빌려 한국어판으로 이 책을 읽으실 독자께 따뜻한 환영과 감사의 말씀을 전합니다. 2002년에 출간된 이래로 영어권 독자들에게서 뜨거운 호평을 받아 온 이 책의 한국어판 출간을 맞아 한국에 계신 독자들께서도 충심으로 지지해 주시리라 기대합니다.

개인적으로 지난 15년간 소프트웨어 아키텍처 분야를 발전시키는 데 깊이 관여해온 저는 이 책에 엄청난 열성을 쏟았습니다. 몇 년 전부터 업계의 관심을 모으기 시작한 후 지금까지 소프트웨어 아키텍처 분야는 놀라운 속도로 성장했습니다. 『소프트웨어 아키텍처 문서화』의 출간은 소프트웨어 아키텍처 분야가 중요한 반환점을 돌아 새로운 지평을 열었음을 뜻합니다. 이 책에서는 주요 기본 개념들을 정의했을 뿐 아니라 실무자들이 꼭 필요로 하는 실용 지침을 제시했습니다. 카네기멜론대학교(CMU, Carnegie Mellon University) 컴퓨터과학과 교수라는 직책에 있다 보니 자연스레 훌륭한 연구 과제에 참여할 기회가 많았습니다. 그에 비해, 실무 업계에 의미 있는 방식으로 기여할 기회는 드물었다는 생각이 들기는 합니다.

한국어판이 나온다는 소식을 듣고 매우 기뻤는데, 그 작업을 해낸 이들이 예전에 제가 가르쳤던 학생들이라는 얘기까지 들으니 더욱 흐뭇하고 반가웠습니다. 이 책의 번역을 맡은 학생들은 CMU에서 저희 교수진들이 가르치는 소프트웨어공학 석사MSE 과정의 혹독한 수련을 거쳤습니다. 참고로 이 책에 나오는 많은 사상들도 바로 CMU의 MSE 과정을 통해 형성되고 또 검증된 것들입니다. 제가 가르친 제자들에 의해 제 이론과 사상이 더욱 많은 사람들에게 다가가는 모습을 보니, 스승으로서의 자부심과 기쁨을 느끼지 않을 수 없습니다.

끝으로, 이 책의 한국어판 출간이 한국의 소프트웨어 개발 역사에서 큰 획을 긋는 시점이라는 사실을 말씀 드리고 싶습니다. 제가 개인적으로 한국의 교육 기관은 물론, 삼성전자, LG 전자, SK C&C 등 한국 유수의 기업들과 함께한 경험에 비춰보면, 한국도 이제는 소프트웨어 아키텍처의 개념을 받아들여서 소프트웨어 개발과 보수 방식에 변화를 주기 시작하는 시점에 이르렀다고 생각합니다. 그렇게 보면 아키텍처를 문서화하는 데 있어 실용 지침을 확보하는 일이야말로 가장 중요한 일이라 하겠습니다. 저는 이 책 『소프트웨어 아키텍처 문서화』가 한국의 실무자들에게 매우 유용한 책으로 자리매김하리라 확신하며, 몇 년 내에 실무 환경에 커다란 변혁을 끌어내는 모습을 확인할 수 있기를 기대합니다.



[ 저자 서문 ]

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

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

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

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

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

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

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

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

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

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

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

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



[ 저자 소개 ]

폴 클레멘츠, 펠릭스 바흐만, 렌 베스, 데이비드 갈란, 제임스 이버스, 리드 리틀, 로버드 노드, 주디스 스태포드는 모두 소프트웨어 아키텍처 분야의 영향력 있는 인사들이다. 이들은 소프트웨어 공학 연구소(SEI) 내에서 팀을 이뤄 소프트웨어 아키텍처를 다루는 데 필요한 효과적인 방법이나 기법을 개발하고 서로 의견을 주고받는 작업을 했다. 저자들은 모두 시스템 아키텍처를 구축하는 데 삶을 바쳐온 사람들이고, 그 중에는 특히 소프트웨어 아키텍처를 주제로 많은 갈채를 받은 선도적인 책을 쓴 사람들도 있다.


[ 옮긴이의 말 ]

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

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

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

문서화 작업은 따분하고 재미없는 데서 그치지 않고, 하기 싫어서 미루다 보면 종국에는 고통스럽기까지 하더군요. 부처는 고통이 무지에서 비롯된다고 했습니다. 그 말이 사실이라면, 제대로 지식을 쌓고 난 후에는 따분하고 재미없고 심지어 고통스럽기까지 한 문서화 작업이 재미있게 다가올까요? 전적으로 그런지는 모르겠지만, 알고 나면 흥미가 일고, 흥미는 곧 재미를 불러올 것입니다.

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

아키텍처 문서를 만드는 목적은 다른 사람들에게 시스템의 기본 개념을 명확하게 전달하는 데 있습니다. 그런데 아키텍처는 시스템의 다양한 측면을 입체적으로 살펴보지 않으면 전달하기도, 이해하기도 쉽지 않기 때문에 아키텍처를 다룰 때는 복수의 뷰View라는 개념을 동원해야 합니다. 이렇듯 아키텍처를 문서화할 때 핵심이 되는 뷰를 그 다양한 종류에 따라 유형별로 나눠 놓으면 이해하거나 다루기가 쉽습니다. 이 책에서는 뷰를 세 가지 타입으로 나누고 각 타입마다 다시 몇 개씩의 스타일로 분류해 놓음으로써, 유형별로 손쉽게 작성할 수 있도록 자세히 설명했습니다.

한편, 아키텍처 문서에 뷰만 잔뜩 모아 놓으면 논의가 너무 개별적이어서 활용하기가 쉽지 않습니다. 따라서 이 책에서는 많은 뷰를 묶어서 안내 지침으로 삼을 수 있도록 각 뷰를 간략하게 종합해 놓은 뷰 개괄 문서를 함께 만들어 아키텍처 문서화에 활용하도록 권고합니다. 이렇게 아키텍처 문서를 여러 뷰를 다루고 그 뷰들을 엮어주는 개괄문서를 함께 만드는 방법을 일컬어 V&B(Views and Beyond) 접근법이라고 합니다.

이 책은 원저자들이 직접 고안한 V&B 접근법을 설명하면서 소프트웨어 아키텍처가 무엇이고, 소프트웨어 아키텍처 문서화란 무엇이며, 소프트웨어 아키텍처를 문서화하려면 어떤 내용을 어떻게 구성해야 효과적인가에 대해 설명합니다. 그리고 대규모 프로젝트에서 V&B 접근법을 실제로 적용해 작성한 소프트웨어 아키텍처 문서 사례를 부록으로 담았습니다. 다만 한 가지 아쉬운 점은, ‘대규모 프로젝트 문서화 이렇게 한다!’를 매우 사실적으로 보여주는 이 90페이지 가까운 방대한 예제에서 다루는 분야가 인공위성에서 데이터를 수집해 가공, 배포하는 내용인지라 범례로 삼기에는 워낙 생소하고 국내 실정과도 거리가 있다는 사실입니다. 하지만 사례 자체보다는 문서를 구성하는 방식을 익힌다는 생각으로 접근하면 매우 요긴하게 활용할 수 있을 것입니다.

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



[ 옮긴이 소개 ]

송재하
1992년 성균관대학교 컴퓨터 동아리에서 터보 파스칼을 배우면서 프로그래밍을 시작했다. 소프트웨어 설계와 분석에 많은 관심이 있고, 한국정보통신대학교 공학석사와 카네기멜론대 소프트웨어 공학 석사과정MSE을 졸업했다. 훌륭한 소프트웨어 아키텍트가 되고 싶어하고, 또 그 길을 가고 있다. 현재는 엔씨소프트의 오픈마루 스튜디오에서 검색 데이터 수집 팀을 이끌며 소프트웨어 공학과 아키텍처의 이론을 실제로 적용해 나가고 있다.

박미율
덕성여자대학교에서 전산학을 전공하고 한국정보통신대학교 공학석사와 카네기멜론대학 소프트웨어공학 석사과정MSIT-SE을 졸업했다. 주 관심분야는 소프트웨어 아키텍처, 소프트웨어 개발방법론 등이며, 현재 국내 전자회사에서 임베디드 소프트웨어 관련 업무를 하고 있다.

이진희
서울대학교 컴퓨터공학과를 졸업하고 카네기멜론대학 소프트웨어공학 석사를 졸업했다. 미국 오라클 본사에서 소프트웨어 엔지니어로 근무하다 현재 실리콘밸리에서 벤처기업을 창업해 CTO 겸 Vice President로 일하고 있다.

김정호
카네기멜론대학CMU에서 소프트웨어 공학석사를 졸업하고 한국정보통신대학ICU에서 소프트웨어 아키텍처 전공으로 박사과정을 수료했다. 현재 SKC&C에서 소프트웨어 아키텍트로서 활동하고 있으며 3차원 현실 환경을 복제해 서비스를 제공하는 메타버스 플랫폼의 소프트웨어 아키텍처를 수립하고 있다.

목차

• 서장: 소프트웨어 아키텍처와 문서화 ● 1
  • P.1 아키텍처의 역할 ● 1
    • [용어 설명] 소프트웨어 아키텍처 ● 2
    • [견해 소개] 아키텍처는 설계와 어떻게 다른가? ● 4
    • [용어 설명] 문서화, 설명, 표현, 명세 ● 8
  • P.2 아키텍처 문서 활용방안 ● 10
  • P.3 인터페이스 ● 12
  • P.4 뷰 ● 13
    • [용어 설명] 아키텍처 뷰 ● 15
  • P.5 뷰타입과 스타일 ● 18
    • P.5.1 뷰타입 ● 18
    • P.5.2 스타일 ● 18
    • P.5.3 뷰타입, 스타일, 뷰에 대한 요약 ● 21
    • [용어 설명] 모듈과 컴포넌트 ● 22
  • P.6 좋은 문서를 만드는 7가지 규칙 ● 24
    • P.6.1 규칙 1: 읽는 사람의 관점에서 문서를 작성한다 ● 24
    • P.6.2 규칙 2: 불필요한 반복을 피한다 ● 25
    • P.6.3 규칙 3: 모호함을 피한다 ● 26
    • P.6.4 규칙 4: 표준 체계를 따른다 ● 27
    • P.6.5 규칙 5: 근거를 남겨둔다 ● 28
    • P.6.6 규칙 6: 문서는 항상 최신 내용을 담되 너무 앞서나가지 않는다 ● 28
    • P.6.7 규칙 7: 목적에 맞게 작성됐는지 사후 검토한다 ● 28
    • [견해 소개] 화살표에 대한 고민 ● 29
  • P.7 정리 ● 30
  • P.8 생각해볼 문제 ● 31
  • P.9 더 읽을거리 ● 33
    
• I부 소프트웨어 아키텍처 뷰타입과 스타일 ● 35
  • I.1 뷰타입과 스타일 목록 ● 35
    • I.1.1 모듈 뷰타입 ● 35
    • I.1.2 컴포넌트와 커넥터 뷰타입 ● 36
    • I.1.3 할당 뷰타입 ● 38
  • I.2 스타일 지침: 스타일 문서화를 위한 표준 문서체계 ● 39
    
• 1장 모듈 뷰타입 ● 41
  • 1.1 개요 ● 41
  • 1.2 모듈 뷰타입의 요소, 관계, 속성 ● 42
    • 1.2.1 요소 ● 43
    • 1.2.2 관계 ● 43
    • 1.2.3 속성 ● 44
    • [용어 설명] 교체가능성 ● 46
  • 1.3 모듈 뷰타입이 적합한 상황 ● 47
  • 1.4 모듈 뷰타입 표기법 ● 48
    • 1.4.1 비공식 표기법 ● 48
    • 1.4.2 UML ● 48
  • 1.5 다른 뷰타입과의 관계 ● 49
  • 1.6 정리 ● 50
  • 1.7 생각해볼 문제 ● 50
  • 1.8 더 읽을거리 ● 51
    
• 2장 모듈 뷰타입 스타일 ● 53
  • 2.1 분할 스타일 ● 53
    • 2.1.1 개요 ● 53
    • 2.1.2 요소, 관계, 속성 ● 54
    • 2.1.3 용도 ● 55
    • 2.1.4 표기법 ● 56
    • 2.1.5 다른 스타일과의 관계 ● 57
    • 2.1.6 사례 ● 57
    • [용어 설명] 하위시스템 ● 62
  • 2.2 사용 스타일 ● 64
    • 2.2.1 개요 ● 64
    • 2.2.2 요소, 관계, 속성 ● 64
    • 2.2.3 용도 ● 65
    • 2.2.4 표기법 ● 65
    • 2.2.5 다른 스타일과의 관계 ● 67
    • 2.2.6 사례 ● 67
    • [용어 설명] 사용 ● 68
  • 2.3 일반화 스타일 ● 71
    • 2.3.1 개요 ● 71
    • 2.3.2 요소, 관계, 속성 ● 72
    • 2.3.3 용도 ● 73
    • 2.3.4 표기법 ● 74
    • 2.3.5 다른 스타일과의 관계 ● 74
    • [용어 설명] 일반화 ● 76
    • 2.3.6 사례 ● 77
  • 2.4 계층 스타일 ● 77
    • 2.4.1 개요 ● 77
    • 2.4.2 요소, 관계, 속성 ● 80
    • 2.4.3 용도 ● 82
    • 2.4.4 표기법 ● 83
    • 2.4.5 다른 스타일과의 관계 ● 89
    • 2.4.6 사례 ● 92
    • [용어 설명] 가상기계 ● 93
    • [견해 소개] 거슬러 올라가는 소프트웨어 ● 94
    • [견해 소개] ‘수준’ 때문에 생기는 혼란 ● 95
    • [견해 소개] UML 클래스 다이어그램 남용금지! ● 97
  • 2.5 정리 ● 99
  • 2.6 생각해볼 문제 ● 100
  • 2.7 더 읽을거리 ● 100
    
• 3장 컴포넌트와 커넥터 뷰타입 ● 103
  • 3.1 개요 ● 103
  • 3.2 C&C 뷰타입의 요소, 관계, 속성 ● 106
    • 3.2.1 요소 ● 107
    • 3.2.2 관계 ● 110
    • 3.2.3 속성 ● 111
    • [견해 소개] 커넥터는 정말 필요한가? ● 112
    • [견해 소개] 커넥터 추상화 ● 114
  • 3.3 C&C 뷰타입의 용도 ● 116
    • [견해 소개] 데이터 흐름과 제어 흐름 투영 ● 117
  • 3.4 C&C 뷰타입 표기법 ● 118
  • 3.5 다른 뷰타입과의 관계 ● 118
  • 3.6 정리 ● 120
  • 3.7 생각해볼 문제 ● 122
  • 3.8 더 읽을거리 ● 123
    
• 4장 컴포넌트와 커넥터 뷰타입 스타일 ● 125
  • 4.1 파이프와 필터 스타일 ● 126
    • 4.1.1 개요 ● 126
    • 4.1.2 요소, 관계, 속성 ● 126
    • 4.1.3 용도 ● 127
    • 4.1.4 다른 스타일과의 관계 ● 128
    • 4.1.5 사례 ● 128
  • 4.2 공유 데이터 스타일 ● 129
    • 4.2.1 개요 ● 129
    • 4.2.2 요소, 관계, 속성 ● 129
    • 4.2.3 용도 ● 131
    • 4.2.4 다른 스타일과의 관계 ● 132
    • 4.2.5 사례 ● 132
  • 4.3 발행 구독 스타일 ● 133
    • 4.3.1 개요 ● 133
    • 4.3.2 요소, 관계, 속성 ● 133
    • 4.3.3 용도 ● 134
    • 4.3.4 다른 스타일과의 관계 ● 135
    • 4.3.5 사례 ● 135
  • 4.4 클라이언트/서버 스타일 ● 136
    • 4.4.1 개요 ● 136
    • 4.4.2 요소, 관계, 속성 ● 136
    • 4.4.3 용도 ● 138
    • 4.4.4 다른 스타일과의 관계 ● 138
    • 4.4.5 사례 ● 139
  • 4.5 피어 투 피어 스타일 ● 139
    • 4.5.1 개요 ● 139
    • 4.5.2 요소, 관계, 속성 ● 140
    • 4.5.3 용도 ● 141
    • 4.5.4 다른 스타일과의 관계 ● 141
    • 4.5.5 사례 ● 141
  • 4.6 프로세스 간 통신 스타일 ● 142
    • 4.6.1 개요 ● 142
    • 4.6.2 요소, 관계, 속성 ● 142
    • 4.6.3 용도 ● 143
    • 4.6.4 다른 스타일과의 관계 ● 143
    • 4.6.5 사례 ● 144
  • 4.7 C&C 스타일 표기법 ● 145
    • 4.7.1 비공식적 표기법 ● 145
    • 4.7.2 정형적 표기법 ● 145
    • [견해 소개] 클래스로 컴포넌트 타입과 인스턴스 표현하기 ● 160
    • [용어 설명] 컴포넌트와 UML 컴포넌트의 비교 ● 162
  • 4.8 정리 ● 164
  • 4.9 생각해볼 문제 ● 165
  • 4.10 더 읽을거리 ● 166
    
• 5장 할당 뷰타입과 스타일 ● 167
  • 5.1 개요 ● 167
  • 5.2 요소, 관계, 속성 ● 168
  • 5.3 배치 스타일 ● 169
    • 5.3.1 개요 ● 169
    • 5.3.2 요소, 관계, 속성 ● 170
    • 5.3.3 용도 ● 172
    • 5.3.4 표기법 ● 173
    • 5.3.5 다른 스타일과의 관계 ● 175
    • 5.3.6 사례 ● 175
  • 5.4 구현 스타일 ● 175
    • 5.4.1 개요 ● 175
    • 5.4.2 요소, 관계, 속성 ● 177
    • 5.4.3 용도 ● 178
    • 5.4.4 표기법 ● 178
    • 5.4.5 다른 스타일과의 관계 ● 179
    • 5.4.6 사례 ● 179
  • 5.5 작업할당 스타일 ● 179
    • 5.5.1 요소, 관계, 속성 ● 179
    • 5.5.2 용도 ● 180
    • 5.5.3 표기법 ● 181
    • 5.5.4 다른 스타일과의 관계 ● 181
    • 5.5.5 사례 ● 182
  • 5.6 정리 ● 183
  • 5.7 생각해볼 문제 ● 183
  • 5.8 더 읽을거리 ● 184
    
• II부 실전 소프트웨어 아키텍처 문서화 ● 185
  
• 6장 고급 개념 ● 187
  • 6.1 정보 분할과 뷰 패킷, 정제, 설명적 완결성 ● 188
    • 6.1.1 뷰 패킷 ● 188
    • 6.1.2 정제 ● 191
    • 6.1.3 설명적 완결성 ● 192
  • 6.2 컨텍스트 다이어그램 ● 195
    • 6.2.1 최상위 수준 컨텍스트 다이어그램 ● 196
    • 6.2.2 내용 ● 197
    • 6.2.3 그 밖의 보조 문서 ● 197
    • 6.2.4 표기법 ● 198
    • 6.2.5 사례 ● 200
  • 6.3 결합 뷰 ● 200
    • 6.3.1 결합 뷰를 사용해야 하는 경우 ● 201
    • 6.3.2 대응의 유형 ● 203
    • 6.3.3 요소, 관계, 속성 ● 205
    • 6.3.4 결합 뷰 문서화 ● 206
    • 6.3.5 결합 뷰 예제 ● 207
    • 6.3.6 그 밖의 예제 ● 208
  • 6.4 가변성과 역동성 문서화 ● 209
    • 6.4.1 가변성 ● 209
    • 6.4.2 역동성 ● 210
    • 6.4.3 정보 기록 ● 211
    • 6.4.4 표기법 ● 212
    • [견해 소개] 시점이란 무엇인가? ● 213
  • 6.5 새로운 스타일 작성과 문서화 ● 215
    • [용어 설명] 스타일과 패턴 ● 217
  • 6.6 정리 ● 219
  • 6.7 생각해볼 문제 ● 220
  • 6.8 더 읽을거리 ● 221
    
• 7장 소프트웨어 인터페이스 문서화 ● 223
  • 7.1 개요 ● 223
  • 7.2 인터페이스 명세 ● 226
  • 7.3 인터페이스 문서 표준 체계 ● 228
    • [용어 설명] 예외와 오류 처리 ● 233
  • 7.4 인터페이스 문서와 관련된 이해관계자 ● 237
  • 7.5 인터페이스 문서 표기법 ● 239
    • 7.5.1 인터페이스의 존재 제시 ● 239
    • 7.5.2 형태정보 전달 ● 241
    • 7.5.3 의미정보 전달 ● 242
    • 7.5.4 요약 ● 242
    • [견해 소개] 다중 인터페이스 ● 242
    • [용어 설명] 호출규약, 인터페이스, API ● 245
  • 7.6 인터페이스 문서화 예제 ● 246
    • 7.6.1 SCR 스타일의 인터페이스 ● 246
    • 7.6.2 IDL ● 252
    • 7.6.3 맞춤형 표기법 ● 252
    • 7.6.4 XML ● 255
  • 7.7 정리 ● 257
  • 7.8 생각해볼 문제 ● 258
  • 7.9 더 읽을거리 ● 258
    
• 8장 행위 문서화 ● 259
  • 8.1 구조를 넘어서 ● 259
  • 8.2 행위 문서화 위치 ● 260
  • 8.3 행위 문서화 필요성 ● 260
    • 8.3.1 시스템 분석 ● 261
    • 8.3.2 개발 작업 추진 ● 262
  • 8.4 문서화 내용 ● 263
    • 8.4.1 통신 방식 ● 264
    • 8.4.2 순서 제약사항 ● 264
    • 8.4.3 시간에 따라 발생하는 자극 ● 265
  • 8.5 행위 문서화에 쓰이는 언어와 표기법 ● 266
    • 8.5.1 추적 ● 268
    • 8.5.2 정적 모델 ● 276
  • 8.6 정리 ● 284
  • 8.7 생각해볼 문제 ● 285
  • 8.8 더 읽을거리 ● 285
    
• 9장 뷰 선택 ● 289
  • 9.1 이해관계자들에게 필요한 문서 ● 290
    • [견해 소개] 아키텍처 트레이드오프 분석 방법 ● 302
  • 9.2 선택하기 ● 305
  • 9.3 두 가지 예제 ● 306
    • 9.3.1 소규모 프로젝트 A-7E ● 306
    • 9.3.2 대규모 프로젝트 ECS ● 308
  • 9.4 정리 ● 312
  • 9.5 생각해볼 문제 ● 312
  • 9.6 더 읽을거리 ● 313
    
• 10장 문서 패키지 작성 ● 315
  • 10.1 문서를 하나로? 여러 개로? ● 315
    • [견해 소개] ‘is’의 의미 ● 316
  • 10.2 뷰 문서화 ● 317
    • [견해 소개] 표현 방법도 중요하다! ● 321
  • 10.3 뷰 개괄 문서 ● 323
    • 10.3.1 어떻게 문서가 구성됐는가: 구성 정보 ● 324
    • 10.3.2 무엇을 아키텍처로 봤는가: 구성 내용 ● 326
    • 10.3.3 왜 아키텍처가 현재의 모습을 하고 있는가: 배경, 근거, 설계 제약사항 ● 328
  • [견해 소개] 전역 분석 ● 332
• 10.4 소프트웨어 아키텍처 문서의 검증 ● 335
  • [견해 소개] 용어집을 만들면 좋았을 텐데 ● 339
• 10.5 정리 ● 340
• 10.6 생각해볼 문제 ● 340
• 10.7 더 읽을거리 ● 341
  

11장 그 밖의 문서화 기법 ● 343

• 11.1 개요 ● 343
• 11.2 래셔널 통합 프로세스(RUP)/크루첸 4+1 ● 344
• 11.3 UML ● 348
  • 11.3.1 클래스 다이어그램과 객체 다이어그램 ● 348
  • 11.3.2 컴포넌트 다이어그램 ● 350
  • 11.3.3 배치 다이어그램 ● 350
  • 11.3.4 행위 다이어그램 ● 351
• 11.4 지멘스 4뷰 ● 352
  • 11.4.1 전역 분석 ● 352
  • 11.4.2 개념적 아키텍처 뷰 ● 353
  • 11.4.3 모듈 아키텍처 뷰 ● 353
  • 11.4.4 실행 아키텍처 뷰 ● 354
  • 11.4.5 코드 아키텍처 뷰 ● 355
  • 11.4.6 요약 ● 355
• 11.5 C4ISR 아키텍처 프레임워크 ● 356
  • 11.5.1 C4ISR 프레임워크의 공통 아키텍처 뷰 ● 357
  • 11.5.2 공통 산출물 ● 358
• 11.6 ANSI/IEEE-1471-2000 ● 360
• 11.7 데이터 흐름과 제어 흐름 ● 363
  • 11.7.1 데이터 흐름 뷰 ● 363
  • 11.7.2 제어 흐름 뷰 ● 365
• [견해 소개] 그거 전부 다 추측이잖아요! ● 366

11.8 RM-ODP ● 371

11.9 아키텍처 문서화의 정리 ● 373

• 11.9.1 아키텍처 설명 언어 ● 374
• 11.9.2 상용 컴포넌트 ● 375
• 11.9.3 하이퍼텍스트 문서 ● 378
• 11.9.4 형상관리 ● 378

11.10 당부의 말 ● 379

11.11 더 읽을거리 ● 380

부록 A: 소프트웨어 아키텍처 문서 패키지 사례 ● 381

• 1권 ECS 소프트웨어 아키텍처 뷰 개괄 문서 ● 383
• 2권 ECS 소프트웨어 아키텍처 뷰 ● 410
  

용어 정리 ● 469

 1쇄 오류/오탈자 

[ p182 그림 5.6 1-2행 ]
ECS 구성요소 (모듈) | 하위시스템
조직 단위 | 영역
↓
ECS 구성요소 (모듈) | 조직 단위
영역 | 하위시스템