이펙티브 소프트웨어 아키텍처

1장 소프트웨어 아키텍처
1.1 기본 구조
1.2 시스템
1.3 구성 요소
1.4 구성 요소 간 관계
1.5 환경과의 관계
1.6 설계를 통제하는 원칙
1.7 시스템 진화
1.8 요약

2장 맥락
2.1 콘셉트
2.2 신뢰도
2.3 아키텍처적으로 중요한 요구 사항
2.4 제품 계열
__2.4.1 하나의 제품, 여러 플랫폼
__2.4.2 제품 라인
__2.4.3 제품군
__2.4.4 크로스 플랫폼
2.5 플랫폼 구축
2.6 표준
2.7 요약

3장 변화
3.1 변화의 단계
3.2 변화의 유형
3.3 제품 중심 변화
3.4 기술 중심 변화
3.5 단순화
3.6 투자 마인드
3.7 점진적 배포
3.8 아키텍처 진화
3.9 요약

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 점진적 접근
5.7 병렬 처리
5.8 조직 구조
5.9 개방적인 작업
5.10 포기하기
5.11 완료
5.12 요약

6장 의사 결정
6.1 추가 정보는 도움이 되는가?
6.2 그동안 어떤 일이 일어났는가?
6.3 얼마나 많은 의사 결정을 하고 있는가?
6.4 아무것도 하지 않을 경우 비용은 얼마인가?
6.5 변경을 수용할 수 있는가?
6.6 결정을 잘못 내렸을 때 비용은 얼마인가?
6.7 얼마나 더 확신할 수 있는가?
6.8 이 결정은 내 책임인가?
6.9 일관성이 있는가?
6.10 문서화할 수 있는가?
6.11 요약

7장 실무 방식
7.1 백로그
7.2 카탈로그
7.3 템플릿
7.4 검토
7.5 진행 상태
7.6 진행 속도
7.7 집중 시간
7.8 요약

8장 커뮤니케이션
8.1 정신 모델
8.2 문서 작성
8.3 대화
8.4 정보 아키텍처
8.5 네이밍
8.6 용어집
8.7 경청
8.8 요약

9장 아키텍처 팀
9.1 전문화
9.2 팀 구조
9.3 리더십
9.4 책임
9.5 인재
9.6 다양성
9.7 조직 문화
9.8 모임
9.9 세미나와 서밋
9.10 요약

10장 제품 개발 조직
10.1 개발 방법론에 따른 작업
10.2 제품 관리 팀과 협업
__10.2.1 도와주기
__10.2.2 다양한 결말
__10.2.3 작업 범위의 한계 설정
10.3 UX 팀과 협업
10.4 프로그램 관리 팀과 협업
10.5 엔지니어링 팀과 협업
__10.5.1 끝까지 참여하기
10.6 테스팅 팀과 협업
10.7 운영 팀과 협업
10.8 요약

부록 결론
A.1 비전
A.2 아키텍처 복구
A.3 조직 변화
A.4 변경 프로세스
A.5 맺음말

이 책은 아키텍처 기술과 지식을 훨씬 더 크고 복잡한 제품 개발 프로세스에 어떻게 적용할 수 있는지 설명하는 것이 목표입니다. 특정 아키텍처 스타일에 초점을 맞추지 않고 소프트웨어 아키텍처를 정의하며, 제품 개발 팀의 다른 전문 분야 사이에서 아키텍처의 위치와 역할을 규정합니다. 또 아키텍처가 개념, 프로세스, 표준 등과 어떻게 연관되는지 다양한 접점을 알아봅니다.
다음으로 시스템 변경이라는 주제를 자세히 살펴볼 것입니다. 아키텍처 실무에서 핵심은 시스템 변경 사항을 식별하고 관리하며 설계하는 것입니다. 설계 과정은 종종 블랙박스처럼 보일 수 있습니다. 마치 아이디어와 요구 사항을 입력하면 완성된 설계가 자동으로 나오는 것처럼 인식되기도 합니다. 하지만 실제로 시스템 변경 과정은 연속적이면서도 구분 가능한 여러 단계로 구성되어 있습니다. 이러한 단계들을 명확히 하고 가시화하며, 각 변경 단계를 체계적으로 관리하는 모든 노력이 전체 프로세스 개선으로 이어질 것입니다.
엔지니어링 핵심은 트레이드오프(trade-offs)를 다루는 것이며, 변경으로 시스템을 개발하고 발전시키는 과정에는 끊임없는 설계 결정이 따릅니다. 각 결정은 어떤 경로를 열거나 닫기도 하며, 막다른 길에 이르렀을 때 이전 결정을 번복하기도 합니다. 이러한 결정을 내리는 방법 자체가 핵심 기술입니다. 프로젝트 팀이 올바른 결정을 더 많이 내릴수록 이전 결정을 번복하는 데 낭비하는 시간은 줄어듭니다. 좋은 결정을 빨리 내릴수록 프로젝트를 신속하게 진행할 수 있습니다.
대규모 프로젝트에서는 프로젝트 관리와 원활한 의사소통이 중요한 고려 사항입니다. 이미 내려진 결정과 보류 중인 결정, 시스템을 설명하는 용어, 현재 사용 중인 아키텍처를 선택한 이유 등은 모두 도구와 프로세스, 의사소통의 핵심 요소가 됩니다.
마지막으로 소프트웨어 아키텍트의 독립적인 역할을 정의하고, 조직 내에서 아키텍처 팀을 어떻게 운영하는지 살펴봅니다. 아키텍처 팀을 구성하는 선택지와 아키텍처가 조직 내 다른 분야와 어떻게 협력해야 하는지도 알아볼 것입니다. 아울러 이 장에서는 아키텍처 인재를 어떻게 발굴하고 효과적으로 육성할 수 있는지도 다룰 것입니다.

_책 소개 중에서