소프트웨어 아키텍처 : 이론과 실제

1부 개요
1장. 소프트웨어 아키텍처의 의미
__1.1 무엇이 소프트웨어 아키텍처이고, 무엇이 아닌가?
__1.2 아키텍처 구조와 뷰
__1.3 아키텍처 패턴
__1.4 좋은 아키텍처를 만드는 법
__1.5 정리
__1.6 참고 문헌
__1.7 생각해볼 문제

2장. 소프트웨어 아키텍처가 중요한 이유
__2.1 시스템의 품질 속성 억제 또는 가능
__2.2 변경 근거와 관리
__2.3 시스템 품질 예측
__2.4 이해당사자 의사소통 향상
__2.5 초기 설계 결정 수용
__2.6 구현 제약사항 정의
__2.7 조직 구조 영향
__2.8 발전적 프로토타이핑
__2.9 비용과 일정 산정 향상
__2.10 이전 가능한 재사용모델 공급
__2.11 독립적으로 개발된 컴포넌트 통합 허용
__2.12 설계 선택 대상 제한
__2.13 훈련 기초 제공
__2.14 정리
__2.15 참고 문헌
__2.16 생각해볼 문제

3장. 소프트웨어 아키텍처 컨텍스트
__3.1 기술적 컨텍스트에서의 아키텍처
__3.2 프로젝트 라이프사이클 컨텍스트에서의 아키텍처
__3.3 비즈니스 컨텍스트에서의 아키텍처
__3.4 전문성 컨텍스트에서의 아키텍처
__3.5 이해당사자
__3.6 아키텍처는 어떻게 영향을 받는가
__3.7 아키텍처가 무엇에게 영향을 주는가
__3.8 정리
__3.9 참고 문헌
__3.10 생각해볼 문제

2부 품질 속성
4장. 품질 속성의 이해
__4.1 아키텍처와 요구
__4.2 기능성
__4.3 품질 속성 고려사항
__4.4 품질 속성 요구 명세
__4.5 전술을 통한 품질 속성 달성
__4.6 품질 설계 결정 가이드
__4.7 정리
__4.8 참고 문헌
__4.9 생각해볼 문제

5장. 가용성
__5.1 가용성 일반 시나리오
__5.2 가용성 전술
__5.3 가용성 설계 체크리스트
__5.4 정리
__5.5 참고 문헌
__5.6 생각해볼 문제

6장. 상호운영성
__6.1 상호운영성 일반 시나리오
__6.2 상호운영성 전술
__6.3 상호운영성 설계 체크리스트
__6.4 정리
__6.5 참고 문헌
__6.6 생각해볼 문제

7장. 변경용이성
__7.1 변경용이성 일반 시나리오
__7.2 변경용이성 전술
__7.3 변경용이성 설계 체크리스트
__7.4 정리
__7.5 참고 문헌
__7.6 생각해볼 문제

8장. 성능
__8.1 성능 일반 시나리오
__8.2 성능 전술
__8.3 성능 설계 체크리스트
__8.4 정리
__8.5 참고 문헌
__8.6 생각해볼 문제

9장. 보안
__9.1 보안 일반 시나리오
__9.2 보안 전술
__9.3 보안 설계 체크리스트
__9.4 정리
__9.5 참고 문헌
__9.6 생각해볼 문제

10장. 테스트 용이성
__10.1 테스트 용이성 일반 시나리오
__10.2 테스트 용이성 전술
__10.3 테스트 용이성 설계 체크리스트
__10.4 정리
__10.5 참고 문헌
__10.6 생각해볼 문제

11장. 사용편의성
__11.1 사용편의성 일반 시나리오
__11.2 사용편의성 전술
__11.3 사용편의성 설계 체크리스트
__11.4 정리
__11.5 참고 문헌
__11.6 생각해볼 문제

12장. 기타 품질 속성
__12.1 기타 중요한 품질 속성
__12.2 기타 품질 속성 카테고리
__12.3 소프트웨어 품질 속성과 시스템 품질 속성
__12.4 품질 속성 표준 목록 사용
__12.5 ‘-성’ 다루기: 새로운 품질 속성 도입
__12.6 참고 문헌
__12.7 생각해볼 문제

13장. 아키텍처 전술과 패턴
__13.1 아키텍처 패턴
__13.2 패턴 목록 개요
__13.3 전술과 패턴 사이의 관계
__13.4 전술 종합 사용
__13.5 정리
__13.6 참고 문헌
__13.7 생각해볼 문제

14장. 품질 속성 모델링과 분석
__14.1 품질 속성 분석을 가능하게 하는 아키텍처 모델링
__14.2 품질 속성 체크리스트
__14.3 사고 실험과 대략 분석
__14.4 실험, 시뮬레이션 및 프로토타입
__14.5 라이프사이클 단계에서의 분석
__14.6 정리
__14.7 참고 문헌
__14.8 생각해볼 문제

3부 라이프사이클에서의 아키텍처
15장 애자일 프로젝트에서의 아키텍처
__15.1 어느 정도의 아키텍처일까?
__15.2 애자일과 아키텍처 방법론
__15.3 애자일 아키텍팅의 간단한 사례
__15.4 애자일 아키텍트 가이드라인
__15.5 정리
__15.6 참고 문헌
__15.7 생각해볼 문제

16장 아키텍처와 요구
__16.1 요구 문서로부터 ASR 수집
__16.2 이해당사자 인터뷰로 ASR 수집
__16.3 비즈니스 목표 이해에 의한 ASR 수집
__16.4 유틸리티 트리 ASR 수집
__16.5 방법론 결합
__16.6 정리
__16.7 참고 문헌
__16.8 생각해볼 문제

17장 아키텍처 설계
__17.1 설계 전략
__17.2 속성 주도 설계 방법론
__17.3 ADD 단계
__17.4 정리
__17.5 참고 문헌
__17.6 생각해볼 문제

18장 소프트웨어 아키텍처 문서화
__18.1 아키텍처 문서 사용과 독자
__18.2 아키텍처 문서 표기법
__18.3 뷰
__18.4 뷰 선택
__18.5 뷰 결합
__18.6 문서 패키지 구축
__18.7 행위 문서화
__18.8 아키텍처 문서와 품질 속성
__18.9 문서화보다 빨리 변경되는 아키텍처의 문서화
__18.10 애자일 개발 프로젝트에서 아키텍처 문서화
__18.11 정리
__18.12 참고 문헌
__18.13 생각해볼 문제

19장 아키텍처, 구현과 테스팅
__19.1 아키텍처와 구현
__19.2 아키텍처와 테스팅
__19.3 정리
__19.4 참고 문헌
__19.5 생각해볼 문제

20장 아키텍처 재구성과 순응
__20.1 아키텍처 재구성 프로세스
__20.2 원시 뷰 추출
__20.3 데이터베이스 구축
__20.4 뷰 융합
__20.5 아키텍처 분석: 위반 사항 찾기
__20.6 가이드라인
__20.7 정리
__20.8 참고 문헌
__20.9 생각해볼 문제

21장 아키텍처 평가
__21.1 평가 요인
__21.2 아키텍처 트레이드오프 분석 방법론
__21.3 경량 아키텍처 평가
__21.4 정리
__21.5 참고 문헌
__21.6 생각해볼 문제

22장 관리와 거버넌스
__22.1 계획
__22.2 조직
__22.3 구현
__22.4 측정
__22.5 거버넌스
__22.6 정리
__22.7 참고 문헌
__22.8 생각해볼 문제

4부 아키텍처와 비즈니스
23장 아키텍처 경제적 분석
__23.1 의사 결정 배경
__23.2 경제적 분석 기초
__23.3 이론에서 실제로: CBAM
__23.4 사례 연구
__23.5 정리
__23.6 참고 문헌
__23.7 생각해볼 문제

24장 아키텍처 역량
__24.1 개인 역량: 아키텍트의 의무, 기능, 지식
__24.2 소프트웨어 아키텍처 조직 역량
__24.3 정리
__24.4 참고 문헌
__24.5 생각해볼 문제

25장 아키텍처와 소프트웨어 제품 라인
__25.1 제품 라인 가변성 사례
__25.2 소프트웨어 제품 라인 작동 원리
__25.3 제품 라인 범위
__25.4 가변성 품질 속성
__25.5 제품 라인 아키텍처의 역할
__25.6 가변 메커니즘
__25.7 제품 라인 아키텍처 평가
__25.8 주요 소프트웨어 제품 라인 이슈
__25.9 정리
__25.10 참고 문헌
__25.11 생각해볼 문제

5부 멋진 신세계
26장 클라우드 아키텍처
__26.1 기본적인 클라우드 정의
__26.2 서비스 모델과 배포 선택
__26.3 경제적 타당성
__26.4 기반 메커니즘
__26.5 기술의 예
__26.6 클라우드 환경에서의 아키텍팅
__26.7 정리
__26.8 참고 문헌
__26.9 생각해볼 문제

27장 엣지 아키텍처
__27.1 엣지 지배적 시스템의 생태계
__27.2 소프트웨어 개발 라이프사이클 변화
__27.3 아키텍처 의미
__27.4 메트로폴리스 모델 의미
__27.5 정리
__27.6 참고 문헌
__27.7 생각해볼 문제

28장 에필로그

★ 지은이의 말 ★

이 책의 개정2판이 출간된 이후로 10년이 지났다. 이 시간 동안에 소프트웨어 아키텍처 분야는 기본적으로 내부적인 지향성(소프트웨어를 어떻게 설계하고 평가하며 문서화하는가?)뿐만 아니라 외부적인 영향(아키텍처에 대한 더 깊은 이해와 아키텍처가 라이프사이클, 조직, 관리에 미치는 영향의 대한 더 깊은 이해(?))을 포함하도록 초점이 확장되었다.
또한 과거 10년 동안 구축된 시스템의 유형이 극적으로 변화되었다. 대용량 데이터, 소셜 미디어, 클라우드는 10년 전에는 기껏해야 초보적이었지만, 지금은 성숙되었을 뿐만 아니라 커다란 영향력을 갖고 있다.
우리는 이전 판에서의 몇 가지 비판을 듣고 패턴에 대한 좀 더 많은 자료를 포함했으며, 품질 속성에 대한 자료를 재구성하고, 품질 속성의 상호운영성을 하나의 장에 할애했다. 또한 여러분이 선호하는 품질 속성에 대한 시나리오와 전술을 생성할 수 있는 방법에 대한 가이드도 제공한다.
새로운 많은 자료를 수용하기 위해 우리는 어려운 선택을 해야 했다. 특별히 이번 개정3판에서는 이전 판에서 있었던 확장된 사례 연구를 넣지 않았다. 또한 이러한 결정은 소프트웨어 아키텍처에서 선택할 수 있는 사례 연구가 과거 10년보다는 훨씬 더 많아졌다는 점에서, 그리고 소프트웨어 아키텍처의 중요성에 대해 이제는 그다지 강조하지 않아도 된다는 점에서 이 분야가 그만큼 성숙했음을 반영한다. 그러나 이전 두 판에 있었던 사례 연구는 이 책의 웹 사이트(https://www.informit.com/store/software-architecture-inpractice-9780321815736)에서 찾을 수 있다. 이 웹 사이트에는 프리젠테이션 슬라이드도 포함되어 있다.
이번 개정3판에서 다룬 많은 주제들은 완전히 다시 작성되었다. 특별히 우리가 제시한 방법론(아키텍처 설계, 분석 및 문서화)이 특별한 목적을 달성하는 방법에 관한 하나의 버전이지만, 다른 것도 있다는 것을 인식했다. 따라서 우리는 이들의 기반이 되는 이론으로부터 세부적인 사항을 제시하는 방법론을 분리했다. 이제 우리는 이론의 가능한 실현을 예로 제공하는 구체적인 방법론으로 먼저 이론을 제시한다. 이번 개정판의 새로운 주제에는 아키텍처 중심적인 프로젝트 관리, 아키텍처 역량, 요구 모델링과 분석, 애자일 방법론, 구현과 테스팅, 클라우드, 엣지가 포함된다.
이전 판에서와 마찬가지로 주제들이 스터디 그룹이나 강의실에서 많이 논의된다고 강하게 믿고 있으므로, 각 장의 끝에 토론할 질문들을 포함시켰다. 이들 대부분의 토론 질문들은 개방적이기 때문에 절대적인 옳고 그른 답이 없다. 따라서 독자로서 여러분은 질문 그 자체에 대해 단순히 대답을 하기보다는 여러분의 대답의 정당성을 어떻게 주장할 것인가를 강조해야 한다.

★ 옮긴이의 말 ★

나의 30년 가까운 소프트웨어 개발 경험 속에서 갖고 있는 하나의 신념은 ‘아키텍처가 튼튼한 시스템이 결국엔 성공한다’는 것이다. 아키텍처가 튼튼한 시스템은 결합성이 적고 응집력이 강한 시스템이다. 이처럼 튼튼하게 아키텍처가 설계된 시스템을 구현하는 것은 결코 실패하지 않으며, 적어도 문제를 최소화할 수 있다. 업무 로직이 변경되는 경우라도 쉽게 대응할 수 있어 생명력이 긴 소프트웨어 시스템을 만들어낼 수 있다. 이러한 신념은 이 책의 2판을 읽고 나서 더욱 커졌다. 그 이후로 내가 집필한 『CBD, What & How』(와우북스, 2008)와 『SOA, What & How』(와우북스, 2008)에서 각각 제시한 CBD와 SOA 방법론은 모두 튼튼한 아키텍처 설계를 강조하고 있다.
이 책은 2판에 비해 더 체계적인 내용을 담고 있다. 이 책의 핵심 개념인 품질 속성에 대해 좀 더 상세하고 체계적인 설명을 담고 있으며, 소프트웨어 개발 라이프사이클에서 아키텍처의 역할과 해야 할 일에 대해 체계적으로 설명한다. 특별히 애자일 접근 방법에서의 아키텍처의 역할을 설명한 장은 애자일 실천자들이 반드시 이해해야 할 좋은 내용을 담고 있다.
개발자들을 위해 이 책을 해설하는 가칭 『개발자를 위한 소프트웨어 아키텍처 해설』을 집필하고 있던 중에 출판사로부터 이 책의 번역을 의뢰받았다. 이 책의 번역본이 빨리 출간되었으면 하는 바람을 갖고 있던 터라 흔쾌히 수락하고 번역에 착수했다. 이 책의 번역이 어쩌면 내 인생에서 가장 힘들고 보람된 작업이 아니었나 싶다. 이미 이 책을 읽으면서 정리해둔 것이 있어서 가능한 일이었긴 하지만, 그래도 평균적으로 하루 20쪽 이상을 번역하는 작업이 그렇게 녹록한 일은 아니었다. 하지만 덕분에 꼼꼼히 이 책을 처음부터 끝까지 빠짐없이 읽을 수 있었기에 더할 나위 없이 보람된 작업이었다.
이미 여러 책을 집필하고 번역했기 때문에 책을 쓰고 번역하는 일이 낯설지 않았지만, 그래도 이 책을 번역하면서 어려움이 많았다. 사실 이 책이 소프트웨어 공학을 공부하는 사람들에게는 교과서와 같은 책이어서, 실무뿐만 아니라 학문적으로도 손색이 없도록 번역해야 한다는 부담감이 있었다. 그럼에도 불구하고 아무래도 이 책을 번역할 때 실무자를 향해 있음을 부인할 수는 없다. 이 책의 번역 용어는 가능한 한 실무를 반영해 선택했으며, 옮긴이 주석은 이 책을 읽는 데 이해하기 쉽도록 도움을 주는 정도로만 한정했다. 실무의 개발자들에게 좀 더 쉬운 해설을 제공하기 위해 향후 『개발자를 위한 소프트웨어 아키텍처 해설』 책을 집필할 계획이다.
이 책의 번역을 의뢰해주신 에이콘출판사에 감사드리며, 오타와 껄끄러운 문맥을 다듬느라 고생하신 편집부의 노고에 감사드린다. 이 번역본이 튼튼한 아키텍처를 갖춘 시스템을 구축하는 데 조금이라도 도움이 되었으면 한다.