[책] 소프트웨어 아키텍처 - The Hard Parts

소프트웨어 아키텍처 - The Hard Parts

 

진짜가 나타났습니다. 그동안 비슷한 책은 많았는데 훨씬 더 실무적인 측면에서 많은 이야기를 다루고 있는 책입니다. 책 이름이 낯익은 분들도 계실 텐데 맞습니다. 이 책은 소프트웨어 아키텍처 101 의 후속입니다. 전편에서 개념에 대한 내용을 다뤘다면 이번 편에서는 그것들을 실제로 깊이 있게 살펴본다고 보시면 됩니다. 두께도 전편 472p에서 508p로 좀 두꺼워졌네요. 목차가 이전 편과 크게 다르지는 않습니다. 대부분 중복되는 내용을 다루고 있습니다.

목차를 살펴보면 책에서 무슨 말을 전하려는지 감이 오실 겁니다. 

- chapter 1 ‘베스트 프랙티스’가 없다면?
- chapter 2 아키텍처 퀀텀
- chapter 3 아키텍처 모듈성
- chapter 4 아키텍처 분해
- chapter 5 컴포넌트 기반 분해 패턴
- chapter 6 운영 데이터 분리
- chapter 7 서비스 세분도
- chapter 8 재사용 패턴 (사이드카와 서비스 메시 등을 다룹니다)
- chapter 9 데이터 오너십과 분산 트랜잭션
- chapter 10 분산 데이터 액세스
- chapter 11 분산 워크플로 관리
- chapter 12 트랜잭셔널 사가
- chapter 13 계약 (엄격한 계약 vs. 느슨한 계약, 스탬프 커플링을 다룹니다)
- chapter 14 분석 데이터 관리
- chapter 15 자신만의 트레이드오프 분석

마이크로서비스를 설계/개발하고 있고 도메인을 어떻게 나누면 좋을지, 요즘 사용하는 패턴에는 어떤 게 있는지 등 이 책에 다 담겨있습니다. 다만, 그 내용을 쉽게 풀어내기란 여간 어려운 게 아니죠. 사실 챕터 하나하나만 해도 자세히 설명하려면 책 한 권 분량이 나오지 않을까 싶긴 합니다. 그럼에도 이 책은 훌륭합니다. 왜냐하면 조언에서 끝나지 않고 실무 레벨에서 고민할 내용들이 언급되고 있기 때문이죠.

도대체 어떤 사례가 다뤄지는지 궁금하신 분들을 위해 책 서두에 있는 내용을 첨부합니다.

컨설턴트는 '느슨하게 결합된' 시스템의 이점을 칭송하며 갖가지 조언을 쏟아내지만, 다른 어떤 것에도 연결되지 않는 시스템을 설계할 수 있을까요? 가급적 작은 단위의 마이크로서비스를 설계해서 디커플링을 추구하지만, 무작정 잘게 쪼개기만 하면 오케스트레이션과 트랜잭션, 비동기성 등이 큰 문제가 되겠죠. '디커플링'이 좋다고들 하지만, 시스템을 유용한 방향으로 구축하면서 그러한 목표를 달성하기 위한 가이드라인은 제시하지 않습니다

 

책의 초반부에 등장하는 이 글귀를 읽고 나서 뒤에서 어떤 내용을 풀어낼지 기대가 가득했습니다. "오! 내가 바로 찾고 있던 책이야" 느낌이었죠. 여러 패턴에 대해서 다뤄지고 있기 때문에 개념이나 경험이 부족하면 어렵게 느껴지실 수 있습니다. 전작을 읽고 나면 그나마 낫겠지만 그럼에도 이 책은 꼭 한번 완독 하시기를 권합니다. 아키텍트로 실무에서 고민해야 하는 것들이 꾹 담겨있으니까요. 한 번에 욕심내서 읽기보다는 챕터 단위로 정복하셔도 좋습니다.

 

---

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.