한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.
들어가며
소프트웨어 개발을 하다 보면 '아키텍처'라는 단어를 참 자주 듣게 됩니다.
그런데 막상 아키텍처가 정확히 무엇인지, 아키텍트는 어떤 일을 하는 사람인지 명확하게 설명하기는 쉽지 않아요.
마크 리처즈와 닐 포드가 쓴 이 책은 그 막연함을 걷어내고, 소프트웨어 아키텍처의 본질과 아키텍트의 역할을 체계적으로 정리한 책입니다.
이 책은 ‘소프트웨어 아키텍처 101’의 개정판으로 나온 것인데요.
생성형 AI와 클라우드 환경 등 최근 몇 년간 급격히 변화한 기술 환경을 충실히 반영하고 있는 듯 했어요!
목차
CHAPTER 01 서론
_1.1 소프트웨어 아키텍처의 정의
_1.2 소프트웨어 아키텍처의 법칙
_1.3 아키텍트의 기대 역할
_1.4 로드맵
PART 01 기초
CHAPTER 02 아키텍처적 사고
_2.1 아키텍처와 설계의 차이
_2.2 기술적 너비
_2.3 트레이드오프 분석
_2.4 비즈니스 동인의 이해
_2.5 아키텍처와 코딩 실무의 균형
_2.6 아키텍처적 사고의 남은 이야기들
CHAPTER 03 모듈성
_3.1 모듈성 대 세분도
_3.2 모듈성의 정의
_3.3 모듈성 측정
_3.4 모듈에서 컴포넌트로
CHAPTER 04 아키텍처 특성의 정의
_4.1 아키텍처 특성과 시스템 설계
_4.2 중요한 아키텍처 특성들
_4.3 트레이드오프와 ‘가장 덜 나쁜’ 아키텍처
CHAPTER 05 아키텍처 특성의 식별
_5.1 도메인 관심사들에서 아키텍처 특성 도출하기
_5.2 복합 아키텍처 특성
_5.3 아키텍처 특성의 추출
_5.4 카타: 실리콘 샌드위치
_5.5 아키텍처 특성의 제한과 우선순위 부여
CHAPTER 06 아키텍처 특성의 측정과 거버넌스
_6.1 아키텍처 특성의 측정
_6.2 거버넌스와 적합성 함수
CHAPTER 07 아키텍처 특성의 범위
_7.1 아키텍처 퀀텀과 세분도
_7.2 동기적 통신
_7.3 범위 지정의 영향
_7.4 범위와 클라우드
CHAPTER 08 컴포넌트 기반 사고
_8.1 논리적 컴포넌트의 정의
_8.2 논리적 아키텍처 대 물리적 아키텍처
_8.3 논리적 아키텍처의 작성
_8.4 컴포넌트 결합
_8.5 사례 연구: 고잉, 고잉, 곤-컴포넌트의 발견
PART 02 아키텍처 스타일
CHAPTER 09 아키텍처 스타일의 기초
_9.1 스타일 대 패턴
_9.2 기본적인 아키텍처 패턴
_9.3 아키텍처의 분할
_9.4 모놀리스 대 분산 아키텍처
_9.5 팀 토폴로지와 아키텍처
_9.6 구체적인 스타일로
CHAPTER 10 계층형 아키텍처 스타일
_10.1 토폴로지
_10.2 스타일 세부 사항
_10.3 데이터 토폴로지
_10.4 클라우드 고려 사항
_10.5 일반적인 위험
_10.6 거버넌스
_10.7 팀 토폴로지 고려 사항
_10.8 이 스타일의 특성들
_10.9 예시와 용례
CHAPTER 11 모듈형 모놀리스 아키텍처 스타일
_11.1 토폴로지
_11.2 스타일 세부 사항
_11.3 데이터 토폴로지
_11.4 클라우드 고려 사항
_11.5 일반적인 위험
_11.6 거버넌스
_11.7 팀 토폴로지 고려 사항
_11.8 스타일 특성
_11.9 예시와 용례
CHAPTER 12 파이프라인 아키텍처 스타일
_12.1 토폴로지
_12.2 스타일 세부 사항
_12.3 데이터 토폴로지
_12.4 클라우드 환경 고려 사항
_12.5 일반적인 위험
_12.6 거버넌스
_12.7 팀 토폴로지 고려 사항
_12.8 스타일 특성
_12.9 예시와 용례
CHAPTER 13 마이크로커널 아키텍처 스타일
_13.1 토폴로지
_13.2 스타일 세부 사항
_13.3 데이터 토폴로지
_13.4 클라우드 고려 사항
_13.5 일반적인 위험
_13.6 거버넌스
_13.7 팀 토폴로지 고려 사항
_13.8 아키텍처 특성 등급 평가
_13.9 예시와 용례
CHAPTER 14 서비스 기반 아키텍처 스타일
_14.1 토폴로지
_14.2 스타일 세부 사항
_14.3 데이터 토폴로지
_14.4 클라우드 환경 고려 사항
_14.5 일반적인 위험
_14.6 거버넌스
_14.7 팀 토폴로지 고려 사항
_14.8 스타일 특성
_14.9 예시와 용례
CHAPTER 15 이벤트 주도 아키텍처 스타일
_15.1 토폴로지
_15.2 스타일 세부 사항
_15.3 데이터 토폴로지
_15.4 클라우드 고려 사항
_15.5 일반적인 위험
_15.6 거버넌스
_15.7 팀 토폴로지 고려 사항
_15.8 스타일 특성
_15.9 예시와 용례
CHAPTER 16 공간 기반 아키텍처 스타일
_16.1 토폴로지
_16.2 스타일 세부 사항
_16.3 데이터 토폴로지
_16.4 클라우드 고려 사항
_16.5 일반적인 위험
_16.6 거버넌스
_16.7 팀 토폴로지 고려 사항
_16.8 스타일 특성
_16.9 예시와 용례
CHAPTER 17 오케스트레이션 주도 서비스 지향 아키텍처
_17.1 토폴로지
_17.2 스타일 세부 사항
_17.3 데이터 토폴로지
_17.4 클라우드 고려 사항
_17.5 일반적인 위험
_17.6 거버넌스
_17.7 팀 토폴로지 고려 사항
_17.8 스타일 특성
_17.9 예시와 용례
CHAPTER 18 마이크로서비스 아키텍처
_18.1 토폴로지
_18.2 스타일 세부 사항
_18.3 데이터 토폴로지
_18.4 클라우드 고려 사항
_18.5 일반적인 위험
_18.6 거버넌스
_18.7 팀 토폴로지 고려 사항
_18.8 스타일 특성
_18.9 예시와 용례
CHAPTER 19 적절한 아키텍처 스타일의 선택
_19.1 아키텍처 ‘유행’의 변화
_19.2 결정의 기준들
_19.3 모놀리스 사례 연구: 실리콘 샌드위치
_19.4 분산 사례 연구: 고잉, 고잉, 곤
CHAPTER 20 아키텍처 패턴
_20.1 재사용
_20.2 통신
_20.3 CQRS
_20.4 인프라
PART 03 기법과 소프트 스킬
CHAPTER 21 아키텍처적 결정
_21.1 아키텍처적 결정의 안티패턴들
_21.2 아키텍처적 중요성
_21.3 아키텍처적 결정 기록
CHAPTER 22 아키텍처 위험 분석
_22.1 위험 평가 행렬
_22.2 위험 평가표
_22.3 리스크스토밍
_22.4 사용자 스토리 위험 분석
_22.5 리스크스토밍의 예
_22.6 요약
CHAPTER 23 아키텍처 도식화
_23.1 도식화
_23.2 요약
CHAPTER 24 유능한 팀 만들기
_24.1 협업
_24.2 제약조건과 경계
_24.3 아키텍트 성향
_24.4 어느 정도까지 관여할 것인가?
_24.5 팀의 이상 징후
_24.6 체크리스트 활용
_24.7 지침 제공
_24.8 요약
CHAPTER 25 협상과 리더십 스킬
_25.1 협상과 촉진
_25.2 리더로서의 소프트웨어 아키텍트
_25.3 개발 팀에 녹아들기
_25.4 요약
CHAPTER 26 아키텍처 교차점
_26.1 아키텍처와 구현
_26.2 아키텍처와 인프라
_26.3 아키텍처와 데이터 토폴로지
_26.4 아키텍처와 엔지니어링 관행
_26.5 아키텍처와 팀 토폴로지
_26.6 아키텍처와 시스템 통합
_26.7 아키텍처와 엔터프라이즈
_26.8 아키텍처와 비즈니스 환경
_26.9 아키텍처와 생성형 AI
_26.10 요약
CHAPTER 27 다시 살펴본 소프트웨어 아키텍처 법칙들
_27.1 제1법칙: 소프트웨어 아키텍처의 모든 것은 트레이드오프이다
_27.2 제2법칙: 어떻게(방법)보다 왜(이유)가 더 중요하다
_27.3 양극단 사이의 스펙트럼
_27.4 마지막 조언
APPENDIX A 토론용 질문 모음
리뷰
제가 이 책에서 가장 인상 깊었던 부분은 "모든 아키텍처는 트레이드오프의 결과다"라는 관점이었어요.
정답을 찾으려 하기보다는, 상황에 맞는 '가장 덜 나쁜' 선택을 하는 것이 아키텍트의 핵심 역할이라는 메시지가 책 전반에 일관되게 흘렀던 것 같아요.
실제로 책에서는 소프트웨어 아키텍처의 세 가지 법칙을 제시하는데, 그 중 첫 번째가 바로 "소프트웨어 아키텍처의 모든 것은 트레이드오프"라는 것이죠.
이런 현실적인 시각이 오히려 더 와닿았습니다.
책의 구성을 보면, 기초 개념부터 시작해서 다양한 아키텍처 스타일을 체계적으로 다룹니다.
계층형 아키텍처, 마이크로서비스, 이벤트 주도 아키텍처 같은 익숙한 패턴부터 공간 기반 아키텍처처럼 낯선 개념까지 폭넓게 소개합니다.
각 아키텍처 스타일마다 토폴로지, 데이터 처리 방식, 클라우드 환경에서의 고려사항, 팀 구조까지 실무에서 마주칠 법한 내용들을 굉장히 꼼꼼하게 짚어주었어요.
특히 기술적인 내용뿐 아니라 협상, 리더십, 팀 관리 같은 소프트 스킬까지 다루고 있다는 점은 신선했던 것 같습니다.
아키텍트라는게 단순히 기술만 잘 아는 사람이 아니라, 조직과 비즈니스를 이해하고 사람들 사이에서 균형을 잡아야 하는 역할이라는 걸 보여주는 것 같았어요.
이 책은 추상적인 이론으로 끝나지 않고, 커머스나 경매 시스템 같은 구체적인 예시를 통해 아키텍처 개념을 설명해줍니다.
그래서 읽는 사람이 복잡한 내용도 좀 더 이해하기 쉽게 느껴지겠다 생각했어요.
또한 각 아키텍처 스타일의 장단점을 솔직하게 보여주면서, ‘이런 상황에서는 이 방식이 적합하다’는 식의 맥락을 함께 보여줍니다.
그리고 2판에서 새롭게 추가된 내용들이 있으니, 1판을 읽었던 분들에게도 충분히 가치있는 책일 것 같습니다.
마치며
솔직히 가볍게 읽히진 않았던 것 같아요!
제가 그만큼 지식도 부족하기 때문이겠죠.
페이지를 넘기다 보면 생소한 용어도 나오고, 한 번에 모든 내용을 소화하기는 어려웠던 것 같아요.
하지만 그만큼 깊이 있는 내용을 담고 있다는 뜻이기도 하고, 이미 지식과 흥미가 있으신 분들이라면 오히려 유익하게 다가오겠다 싶었어요. 개인적으로 저에겐 급하게 읽기보다는 천천히 읽어봐야할 책이라고 느껴졌네요.
이 책은 개발 경력이 어느 정도 쌓여서 시스템 설계에 관심이 생긴 분들, 아키텍트 역할을 맡게 되었거나 준비하고 있는 분들에게 특히 유용할 것 같아요.
또한 현직 아키텍트라면 놓치고 있던 부분을 점검하거나, 최신 트렌드를 따라잡는 데 도움을 받을 수 있지 않을까 합니다.
기술적 결정을 내려야 하는 프로젝트 리더나 팀장에게도 좋은 참고서가 될 수 있을 것 같습니다!
