소프트웨어 아키텍처 the hard parts는 2021년도에 출판된 소프트웨어 아키텍처 101 책의 후속 편이다. 저자 닐포드, 마크 리처즈의 책으로써 이번 hard parts에서는 프라모드 세달라지, 세약 데그하니가 저자로 추가되어 총 4명의 저자가 쓴 현대적인 소프트웨어 아키텍처의 advanced 기술 서적이다.

모든 문제가 하나하나 새로운 도전을 요하기에 어떻게든 문제를 해결하려는 중대한 의사 결정의 양편에 치우친 수많은 트레이드오프를 냉정하게 판단하고 평가할 때 아키텍트의 진가가 드러납니다.

소프트웨어 아키텍처에서는 최고의 설계를 고집하지 마세요. 그 대신 나쁜 것 중에서 제일 나은(least worst) 트레이드 오프 조합을 찾으세요.
26p

책 시작부에 나오는 이야기로써, 사실 시스템 또는 서비스 아키텍처란 작은 범위의 문제를 해결하는 알고리즘 수준이 아닌 좀 더 큰 범위의 문제 또는 도메인을 다뤄야 하기 때문에 모든 문제를 같은 해법으로 해결할 수 없는 경우가 대부분이다. 전반적으로 트레이드오프를 어떻게 분석하고 활용하는지를 서술해 나간다.

무엇보다 한빛가이버 티켓팅 애플리케이션팀의 이야기를 엿볼 수 있다. 한빛가이버란 가상의 애플리케이션으로 운영상 발생한 문제에 대해서 문제가 무엇이고 담당자들 간 의견의 차이점을 설명한다. 상황 및 트레이드오프를 위한 기반 내용 설명을 해주게 되는데 이후 나오게 되는 기술 설명들에 대해 몰입할 수 있게 해주는 중요 역할을 맡고 있다.

책은 Part1 따로 떼어놓기 Part2 다시 합치기 두 개의 파트로 나누어져 있다. 하나의 모놀리식 애플리케이션을 어떻게 분할하여 확장해나 가는지에 대한 Part1 그리고 운영하는 데 있어 분할이 끝이 아니라 적절한 크기의 서비스를 만들어가기 위한 다시 합치는 과정 그리고 마이크로서비스에서 피할 수 없는 분산 트랜잭션에 대한 이야기로 가득하다.

초기 스타트업에서 살아남아 조직이 확대되고 마이크로서비스를 준비하고 있는 개발조직에서 읽으면 꽤 유용할 것이라고 생각한다. 참고로 도메인 주도 설계에 대해서 미리 학습하고 본다면 이해하는데 더욱 도움이 될 것이다.

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

gutss***l2023-03-30

어렵지만 성장할 제 자신이 기대되는 책

SW architecture The Hard Parts.jpg

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

현재 재직 중인 직장에서는, 운영 중인 거대한 시스템을 재구축하는 프로젝트도 병행으로 진행 중입니다.

현행의 시스템(이하 v1)을 운영하면서, 재구축하는 프로젝트(이하 v2)도 진행하고 있고 아마 몇 년이 지나면 이 재구축하는 시스템을 현행 기반으로 재구축의 대상(이하 v3)이 될 것입니다.

현재 저는 소프트웨어 아키텍처에 관여할 수 있는 위치도, 권한도 없기도 하지만 그 몇 년이 지났을 때엔 이후의 프로젝트에 일조할 위치까진 갈 것이라 생각합니다.

그를 위해 이 책을 읽기 시작했는데.. 내용이 상당히 어렵다, 개념적이라서 와닿지가 않는다는 생각을 많이 하면서 읽었습니다. V1 시스템을 생각하면서 어떻게 하면 v1의 아키텍처를 잘 분해해서 재사용성을 높이는 한편, 현재 여러 장애의 원인이기도 한 유지보수성, 시험/배포의 용이함 같은 내용들을 잘 이해해보려했는데 아직 제 내공이 부족한지 이해도가 낮다는 느낌을 받았습니다.

하지만 이 책이 포괄하는 범위는 제가 꼭 이해하고싶은 내용인지라 책의 부분부분을 지금 운영 중인 시스템에 대입하면서 반복해서 읽어야 할 중요한 내용들이라 느꼈습니다.

한편으로는 잘 이해가 안갔다는 건 앞으로 더 이해할 일만 남았으니 제가 더 성장할 기회가 많다는 반증이겠지요.

아키텍처는 한번 결정이 되면 시간이 흐를수록 바꾸기 정말 힘들어지므로 처음에 잘 설계되어야 하는 특징이 있고 ‘좋은’ 아키텍트는 참 드문지라.. 언젠가는 이 책을 완벽히 이해하고 싶습니다.

tkxkd0***l2023-03-27

항상 멀게만 느껴지는 시스템 아키텍처

bae***l2023-03-27

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

소프트웨어 아키텍처 The Hard Parts는 소프트웨어 아키텍처 문제,해결을 위한 지식과 실용적 프레임워크를 다루는 안내서이다. 분산 아키텍처를 구축할 때, 아키텍트가 트레이드오프를 객관적으로 분석하여 의사 결정을 내리기까지의 모든 과정을 상세히 가이드한다. 또한 리팩토링을 앞둔 가상 애플리케이션 서비스 팀의 이야기를 따라가며, 고민과 인사이트, 팁까지 다룬다.

분산 아키텍처를 구축할 때 서비스를 나눠야 하는 경우와 합쳐야 하는 경우를 어떻게 하면 아키텍트가 객관적으로 트레이드오프를 분석해서 올바른 의사 결정을 내릴 수 있는지 이야기한다. 소프트웨어 아키텍처 The Hard Parts는 제목에 걸맞게 실무 아키텍처링을 할 때 가장 난해한, 그러나 한번 결정되면 바꾸기 어렵고 근본적인 영향을 미치는 부분(hard part)을 면밀히 살펴볼 수 있다.

주요 내용

- 트레이드 오프 분석과 함께 의사 결정을 효과적으로 문서화하기

- 서비스 세분화를 통해 더 나은 결정을 내리는 방법

- 모놀리식 애플리케이션 분리의 복잡도

- 서비스간 게약 관리 및 분리

- 고도로 분산된 아키텍처에서 데이터 처리하기

- 애플리케이션을 분리할 때 워크플로와 트랜잭션을 관리하는 패턴 학습

소프트웨어 아키텍처 The Hard Parts는 책의 'hard'는 어려울 뿐만 아니라, 한 번 잘못된 결정을 내리면 단단하게 굳어져 다시 뜯어내고 고치는 것조차 어려운 아키텍처의 본질을 담고 있다. 분산 시스템 구축을 위해 필요한 다양한 패턴과 사례, 인사이트, 프랙티스를 살펴볼 수 있으며, 가상 애플리케이션 사례로 구체적이고 실질적인 문제 해결방안을 제시한다.

소프트웨어 아키텍처 The Hard Parts를 읽고 나면, 효과적인 트레이드오프 분석 기술을 확보해 더 나은 의사 결정을 내리게 된다. 또한 분산 아키텍처에 관한 기본 개념과 함께 실용적인 조언을 익힐 수 있으며, 어떤 서비스를 따로 빼내야 하고, 어떤 서비스를 함께 두는게 좋을지 배울 수 있다. 즉, 현대 소프트웨어 아키텍처의 난제들을 해결하기 위한 이론적 배경 지식과 프레임워크를 모두 다루는 책이다.

imjihye***l2023-03-26

소프트웨어 아키텍처 서평

dhan***l2023-03-26

분산 아키텍처를 위한 모든 개발자(아키텍트)의 필독서

제목의 The Hard Parts는 아키텍처를 설계할 때 가장 난해한, 그리고 한번 결정되면 쉽게 바꾸기 어려운 아키텍처에서 근본적인 영향을 미치는 부분을 의미한다. 최근 제일 뜨거운 마이크로서비스 아키텍처를 고민 중인 아키텍트와 개발자, DBA 모두에게 이 책은 모든 활용 가능한 방법과 장단점, 실용적인 접근 방법까지 사례를 들어 자세히 설명한다. 매우 훌륭한 안내서가 될 것이다.

책에서 다루는 용어들이 평소 잘 사용하지 않는 아키텍트의 단어라서 이해하는 어려움은 있었지만, 그림과 한빛가이버 대화로 의미는 충분히 전달되어 어려움은 없었다.

특히 책에서 표현하는 그림과, 트레이드오프 분석 방법, ADR(아키텍처 의사결정 레코드)은 업무에 바로 적용할 수 있을 만큼 심플하면서도 일목요연하게 잘 정리되었다.

분산 아키텍처에서 고민해야 할 각각의 사례에 대해 빠짐없이 이론적으로 알려주고, 각 패턴에 대한 장단점 설명과 마지막으로 패턴이 사용될만한 사례까지 알려주기까지 하니, 마이크로서비스 아키텍처에 관련된 분은 꼭 읽어보길 추천한다.

구축하는 아키텍처에서 미처 생각하지 못한 부분과 트레이드오프 분석 스킬 및 사례만 보아도 이미 절반은 성공하지 않을까?

책의 구성은 크게 3개의 파트로 구분하고 있는데,

CHAPTER 1에서는 앞으로 다루게 될 내용에 대한 간단한 소개와 용어 설명, 한빛가이버 아키텍처(앞으로 점점 개선할 초기 모델)에 관해서 설명하고

'PART 1. 따로 떼어놓기'는 총 6개의 CHAPTER로 분산 아키텍처(마이크로서비스 아키텍처)로 가기 위한 아키텍처 분석, 분해, 컴포넌트, 데이터, 서비스를 효과적인 구조로 분해하는 방법에 관해서 설명하며,

'PART 2. 다시 합치기'에서는 앞 장에서 나뉜 구조들의 효율적인 상호 작용(통신)에 방법과 분석을 위한 데이터 관리 방안 및 다양한 트레이드오프 기법으로 마무리한다.

PART 1의 CHAPTER 2는 아키텍처 퀀텀(나눌 수 있는 최소 단위)에 관해서 설명하며,

CHAPTER 3에서는 아키텍처가 가져야 할 특성(유지 보수성, 시험성, 배포성, 확장성, 가용성/내고장성)을 살펴본다.

CHAPTER 4는 아키텍처를 분해할 때 고려사항과 방식에 대해서 설명하고

CHAPTER 5에서는 6가지 컴포넌트 기반 분해 패턴에 관해서 살펴본다,

CHAPTER 6은 데이터 분해 방법과 그에 맞는 8개의 데이터베이스 타입 선택 방법을 알아보고

CHAPTER 7에서는 서비스를 나눠야 할 때와 합쳐야 할 사례에 관한 가이드라인을 설명한다.

PART 2의 CHAPTER 8은 코드를 재사용하는 방법을 설명하고

CHAPTER 9는 데이터데이트의 트랜잭션 처리를 위한 설계 기법에 관해서 살펴본다.

CHAPTER 10은 분산된 데이터의 통신하는 방안을 설명하고

CHAPTER 11은 분산된 환경에서 워크플로를 처리하는 방법에 관해서 살펴본다.

CHAPTER 12는 트랜잭션 처리와 관련된 8개 패턴의 장단점을 알아보고

CHAPTER 13은 계약(통신 데이터)과 관련된 방법을 살펴본다.

CHAPTER 14는 운영과 다른 분석을 위한 효과적인 데이터 관리 방법에 관해 알아보고

마지막, CHAPTER 15는 아키텍처 선정에 가장 중요한 트레이드오프 평가 방안과 기법, 주의 사항에 관해서 알아본다.

각 장의 시작은 한빛가이버 아키텍처 팀의 에피소드(문제점)를 이용하여 이번 장에서 다룰 주제를 알려 주고, 이어서 여러 해결 방안에 관한 설명과 해당 해결 방안에 대한 트레이드오프(장단점)를 표로 정리한 후 이 해결 방안을 효과적으로 사용되는 사례를 알려준다. 마지막에는 다시 한빛가이버 팀의 훈훈한 대화로 마무리하고, 결정된 내용을 ADR로 기록한다.

다른 책에 비해 그림과 표가 월등히 많았는데, 개인적으로 이해가 바로바로 되었으며, 그 그림들과 표는 실제 업무에 활용할 수 있을 수 있을 만큼 간단하면서도 효과적이었다. (당장에라도 책을 덮고 바로 사용하고 싶은 심정이다)

그리고 이 책에서 한빛가이버 팀을 빼놓을 수 없겠다. ^^

팀 간의 대화에서 재미와 묘한 긴장감을 느낄 수가 있었으며, 책에서 잘 이해가 되지 않는 부분도 한빛가이버 팀들의 대화 속에서 자연스럽게 이해될 수 있었다. 긴장감이란 팀 간의 대립하는 상황(팀별 이해 관계)을 매우 사실적으로 표현한 부분이며, 특히 노건우 팀장의 단계별 세부 정리 기술은 정말 대단했다. ㅎㅎ

아키텍처 설계 방법이 왜 구글에 없는지, 그리고 어떻게 설계해야 하는지를 설명하는 아래의 인용 문구로 리뷰를 마무리한다.

읽어주셔서 감사합니다.

아키텍트 여러분이 무언가를 전도하려 하지 않고, 객관적인 트레이드오프 중재자가 되고자 노력하길 바랍니다.

아키텍트는 은제 탄환을 쫓는 사람이 아니라, 있는 그대로의 트레이드오프를 분석하는 스킬을 연마해서 조직에 진정한 가치를 더하는 사람입니다.

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

sangj***l2023-03-26

소프트웨어 시스템의 구성 요소와 그들 간의 상호작용, 그리고 시스템의 동작 방식 등을 결정하는 데 사용되는 설계 원칙과 전략의 집합

소프트웨어 아키텍처는 소프트웨어 시스템의 구성 요소와 그들 간의 상호작용, 그리고 시스템의 동작 방식 등을 결정하는 데 사용되는 설계 원칙과 전략의 집합이다. 이는 소프트웨어 시스템을 구성하는 다양한 요소들 간의 관계와 상호작용을 명확하게 정의하고 시스템의 기능을 충족시키는 데 필요한 속성을 고려하여 시스템을 설계하도록 하는 근간이 된다.

또한 소프트웨어 아키텍처는 시스템의 확장성, 유지 보수성, 재사용성, 이식성 등의 측면에서도 매우 중요하다. 잘 설계된 아키텍처는 시스템을 더욱 유연하고 확장 가능하게 만들어주며 소프트웨어 개발의 생산성을 향상시키고 이는 곧 개발 비용과 시간을 절감할 수 있도록 한다.

<소프트웨어 아키텍처 The Hard Parts>는 <소프트웨어 아키텍처 101>의 후속작으로, 이전 작에 비해 더 실무적이고 특히 분산 아키텍처를 다루고 있다. "소프트웨어 아키텍처 The Hard Parts" 도서의 부제는 "분산 아키텍처를 위한 모던 트레이드오프 분석"이다. 내용은 부제 그대로 분산 아키텍처를 생성하기 위해 모든 것을 분산하는 것이 정말 옳은 판단인지를 평가하고 그 결과를 예측하여 결정하는 것을 다루고 있다.

분산뿐만 아니라 합쳐야 하는 경우를 분해인/통합인 두 가지 관점에서 아키텍트가 올바른 의사 결정을 내릴 수 있도록 도움이 되는 실무의 내용을 다루고 있다.

책은 파트 1과 파트 2로 구분되어 있는데 파트 1은 떼어놓기 과정이다. 분산 아키텍에서 트레이드오프를 분석하기 위해 아키텍처를 하나씩 떼어내어 이해하고 구조 측면에서 각 요소가 정적으로 결합되는 방식을 학습한. 분산 아키텍처에서 데이터의 중요성이 커지고 있기에 데이터를 다룬 내용들이 뒤를 잇는다.

파트 2는 다시 합치기이다. 시스템을 분해하여 분산시키고 때에 따라 다시 시스템을 합쳐 하나의 응집된 단위로 구동해야 하는 경우가 있다. 이때 서비스 통신, 계약 분산, 분산 워크플로, 분산 트랜잭션, 데이터 오너십, 데이터 액세스, 분석 데이터 관리 등 다양한 어려운 관계를 어떻게 풀어갈 것인지를 설명한다.

내용의 레벨은 제목 그대로 딱딱하고 어려움이 공존한다. 기존의 101 도서를 미리 읽지 못한 독자라면 이 책과 병행하여 학습하기를 권고한다.

yisu***l2023-03-26

무엇을 포기할까 고민된다면

[선정 이유]

사실 이번 책의 선정 이유는 특별할 것이 없는데 고를 수 있는 책 중에 끌리지 않는 책을 소거법으로 지우다 보니 선택되었다. 하지만 벌써 실망하고 뒤로 갈 필요는 없다. 책 내용이 생각보다 흥미로웠기 때문이다. 늘 새롭고 정답이 없는 문제에 맞닥뜨리는 기술자들이 최선의 선택을 내리고자 고군분투하는 이야기다.

[구성 및 주제]

책 표지에도 나와 있지만 이 책은 『소프트웨어 아키텍처 101』이라는 책의 심화 편으로 실무에서 분산 아키텍처를 설계할 때 트레이드오프 측정에 도움이 되는 심층적인 가이드를 제공한다. 코드 변동성, 확장성, 유지보수성 등 분해할 때 고려해야 할 지침과 트랜잭션, 워크플로, 공유 코드 등 통합할 때 고려해야 할 지침을 각각 제시하고 둘 사이의 균형점을 찾기 위한 분석 방법을 상세히 소개하고 있다.

그뿐만 아니라 상황에 따라 선택할 수 있는 트랜잭셔널 사가 패턴을 제공하는데 이 패턴들은 통신, 일관성, 조정이라는 세 가지 커플링 힘의 조합에 따라 생성된다. '하드 파트'라는 부제가 붙은 이유는 이렇게 다양한 힘들 사이에서 소프트웨어 아키텍처에 대한 결정을 내리는 것은 '어렵고' 이 구조를 한 번 정하면 '단단해서' 쉽게 바뀌지 않기 때문이다.

책은 크게 1부 따로 떼어놓기와 2부 다시 합치기로 나뉜다. 1부에서는 구조(structure)를 중심으로 아키텍처를 이루는 부품들을 한 조각씩 분리해 구성 요소를 이해할 수 있도록 돕는다. 한편 2부에서는 통신(communication)을 중심으로 구성 요소들이 어떻게 상호작용하고 하나의 단위로 작동하는지 살펴볼 수 있도록 한다.

마지막으로 한빛가이버 사가라는 책 속의 이야기를 통해 기술적인 선택에 대해 이해관계자들과 소통하고 설득하는 모습을 엿볼 수 있도록 한다. 이야기에 수반되는 아키텍처 결정 레코드(ADR)를 곰곰이 읽어 보면 아키텍처 결정을 효과적으로 문서화하는 방식까지 함께 배울 수 있다.

[유익한 점]

가장 유용했던 것을 꼽으라면 풍부한 도표였다. 그림을 통해 개념에 대해 정말 명확하게 전달하기 때문에 아키텍처에 대해 배경지식이 거의 없는 사람도 이해하기 쉬웠다. 다양한 데이터나 트레이드오프를 정리한 표도 패턴 간에 비교를 용이하게 해 장단점을 따져보는 것을 돕는다.

그 밖에 생각을 전환시켜준 것을 딱 하나 꼽자면 중복을 죄악시하지 않는 점이다. 유명한 원칙 중에 DRY(Don't Repeat Yourself)라는 원칙이 있는데 말 그대로 반복하지 말라는 뜻이다. 물론 이 말을 절대적으로 받아들이지는 않았지만 중복이 없어야 더 좋은 코드라는 것이 기본적인 사고방식이었는데 분산 아키텍처에서는 중복을 오히려 권장하는 것을 알고 깜짝 놀랐다. 물론 중복을 허용하면 동기화 문제가 따르게 되지만 분산 아키텍처에서는 중복보다 커플링이 더 나쁜 영향을 끼칠 수 있기 때문에 WET(Write Every Time or Write Everything Twice)하라고 역 조언하기도 한다.

프론트엔드 개발자로서 뷰와 로직의 분리, 클라이언트 상태와 서버 상태의 분리, 컴포넌트 재사용 등 다양한 문제에 대한 해결책으로 분리와 재사용이 최고의 해결 방법이라 생각해왔다. 하지만 이 책 덕분에 현재 구조에서 해결할 수 없는 문제에 맞닥뜨렸을 때 좌절하지 않고 다른 구조(예를 들면, MFA)로 변경해볼 수 있다는 점을 알게 되어 안심이 된다.

[아쉬운 점]

놀랍게도 크게 아쉬운 점이 없었다. 아마 백엔드 개발자도 아니고 아키텍트도 아니라서 부족한 점이나 허점을 눈치채지 못한 게 아닌가 싶다. 그래도 굳이 꼽아보자면 모놀리식 아키텍처를 분산 아키텍처로 분해할 수 있는 Playground를 제공했다면 좋았을 것 같다. 요구사항에 따라 아키텍처를 변경하고 토론을 나누고 ADR까지 남길 수 있게 한다면 책을 넘어서 더 생생한 가치를 제공할 수 있지 않을까?

[총평]

개발 도서들을 읽다 보면 항상 '은 탄환은 없다'라는 말을 자주 보게 된다. 이 책에서는 특히나 이 점을 경계하고 있는데 모든 문제를 해결하는 마법 같은 아키텍처가 없기 때문이다. 마치 리팩터링이 개발과 별개로 독립되어야 하는 것이 아니라 일부여야 하는 것처럼 자신이 맡은 시스템을 분석하고 반복해서 설계함으로써 점진적으로 더 좋은 아키텍처를 만들어 나갈 수 있다고 강조한다.

사실 정답이 있는 문제라면 이미 딱 맞는 솔루션이 나와서 개발자나 아키텍트를 대체했을 텐데 그런 점에서 정답이 없는 것을 부정적으로 바라볼 필요는 없다.

[추천 대상]

- 현재 아키텍처 구조의 한계를 느껴 다양한 아키텍처의 장단점을 알고 싶은 사람

- 커플링을 확인하고 결합점을 분석해서 트레이드오프를 평가하는 방법을 배우고 싶은 사람

- 난해하고 답이 없는 문제를 맞닥뜨렸을 때 최선의 선택을 찾아가는 방법을 배우고 싶은 사람

- 기술을 모르는 이해관계자들에게 의사 결정을 도울 수 있는 기준을 제시하는 방법을 익히고 싶은 사람

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

yee0***l2023-03-26

The Hard Parts 리뷰

jrcfore***l2023-03-26

소프트웨어 아키텍터를 꿈꾸는 자여! 이 책을 손에 들라!

time1***l2023-03-26

최근의 소프트웨어 아키텍처를 이해하기 위한 심화과정

간만에 볼만한 책을 접했다. 기존의 아키텍처 개론서들은 약간 뜬구름 이야기, 그리고 장황한 설명으로인하 졸음에 견디기 어려운 사투를 벌여야 했다. 소프트웨어 아키텍처를 배운다는 것 자체가 초급 개발자는 넘어서야 하는 단계이기는 하다. 단순히 로직을 어떻게 짜는게 좋다는 개념만 갖고 아키텍처를 만들지는 않는다. 경험, 노하우도 필요하다. 그런 차원에서 이 책은 최근에 지배적인 분산형 마이크로서비스 아키텍처 중심으로 다른 아키텍처를 비교해 가면서 설명을 해주었다.

전반적으로 간결하게 설명한 것도 좋았지만 더 나가서 상황극을 만들어서 디테일을 풀어준 점이 인상적이다. 대개 아키텍처는 이러이러한 점을 고려해야 한다! 하고 끝나는 경우들이 많다. 참 재미없다. 반면 상황극은 실무의 어떤 상황에서 이런 아키텍처를 적용할 수 있다는 점을 잘 설명해 준다. 물론 하나의 시나리오일 뿐 실전에서 쓰인 상황은 아니란 점이 아쉽기는 하지만 볼만한 책이었다.

『소프트웨어 아키텍처 101』의 심화과정이라 하는데 맞는 말 같다. 101 책은 보지 못하고 서점에서 훑어 봤는데 예전 학창시절 배웠던 교과서와 별반 차이 없는 것 같아서 보진 않았다. 시간 날 때 어떤 차이인지 확인해 보겠다.

TMI이지만 오늘날 대형 프로젝트에 참여해 보면 틀에 박힌 아키텍처에다가 무조건 쑤셔 넣으라고 강요받기 일색이다. 큰 장벽에 부딪힐 때 현장 개발자로서 합리적인 대안을 제시해 보기도 하지만 수용될 일은 어림 반푼어치도 없다. PM, PL, AA ... 누구의 책임일까? 아키라는 직책은 있는 것 같은데 예전처럼 실체(?)를 본 적이 근래에는 없다. 예전처럼 눈에 띄는 아키를 만날 수 있는 날을 고대해 본다.

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

jiyoon0***l2023-03-26

아키텍처가 궁금한 사람이라면 꼭 읽기를

<소프트웨어 아키텍처 The Hard Parts>는 <소프트웨어 아키텍처 101>의 후속작으로, 이전 작에 비해 더 실무적인 내용을 다룬다고 한다. <소프트웨어 아키텍처 101>을 읽어보지는 않았지만, 분산 아키텍처에 관심이 많았기에 <소프트웨어 아키텍처 The Hard Parts>를 읽게 되었다.

여기서 쓰인 Hard의 의미는 어려울 뿐만 아니라, 한 번 정하면 이후에는 고치기 어려운, 단단하다는 뜻을 내포하고 있다. 실제로 책에서 어떤 상황을 가정하면서 해당 상황에 대한 분석하고, 어떤 것들을 해야하는지 잘 설명하고 있다. 단순히 줄글로 상황이 주어졌다면 이해하기 어려웠을 수도 있겠으나, 실무자들이 이야기하는 내용들로 구성되어 있어 어떤 상황인지 쉽게 파악할 수 있다. 또한 각 상황에 대해서 파악해야 하는 것들을 무엇인지, 생각할 수 있는 방안들과 각 방안들의 장단점이 무엇인지 잘 설명해주고 있다.

상황도 굉장히 다양한 상황을 예시로 들어주고 있어 아키텍처를 설계할 때 적합한 사례를 찾기 좋다고 생각한다. 데이터베이스나 서버 같은 백엔드 아키텍처뿐만 아니라 데이터 웨어하우스, 데이터 레이크 등 데이터 기반 아키텍처에 대해서도 잘 설명이 되어 있어 다양한 분야에 있는 아키텍처를 고민하는 사람들에게 큰 도움이 될 것이라고 생각한다.

처음에 <소프트웨어 아키텍처 101>의 후속작이라고 하여 읽는데 어려움은 없을지 걱정은 많이 하였으나 다행스럽게도 저자분이 신경 써서 설명해주신 덕분에 <소프트웨어 아키텍처 101>을 읽지 않아도 책을 읽는데는 큰 어려움은 없었다. 다만 자세한 이론 등은 <소프트웨어 아키텍처 101>을 참고하라고 되어있기 때문에, 읽으면서 이론이 궁금해진 나는 <소프트웨어 아키텍처 101>도 구매하여 함께 읽을 생각이다.

실제 아키텍처를 설계할 때 할 수 있는 고민들과 그에 대해 떠올릴 수 있는 방안들을 그림과 함께 잘 설명해주고 있고, 각 패턴의 장단점을 설명해주어 실제로 아키텍처를 설계할 때 어떠한 방식이 적절할지 참고할 수 있는 좋은 책이라고 생각한다. 실무를 진행하면서 아키텍처를 고민하는 사람들은 물론이고, 아키텍처는 어떻게 설계해야하는지 궁금한 사람들이라면 꼭 읽어볼 것을 추천한다.

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

mapos***l2023-03-26

소프트웨어 아키텍쳐 The Hard Parts 리뷰

dada3***l2023-03-25

아키텍처의 단비와 같은 책

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

분산 아키텍처의 가장 큰 문제는 어떤 한가지의 완벽한 솔루션이 없다는 것입니다.

그렇기 때문에 이 세상에는 분산 아키텍처에 대한 파편적인 지식이 넘쳐납니다. 그리고 그러한 아키텍처를 경험적으로 깨닫고 내제화하여 제대로 운영하는 아주 소수의 회사에서 일을 하는게 아니라면, 이러한 지식은 정확하게 알 수 없으며 외부의 사람들은 말 그대로 파편화된 지식의 부스러기에 지나지 않는 정보를 주으러 다닐 수 밖에 없습니다.

저도 그런 부스러기를 주으러 다니는 사람 중에 한명이었습니다만, 정말 우연히 이 책을 접하고 나서 제가 가진 분산 아키텍처에 대한 많은 질문들을 놀라울정도로 해소할 수 있어 정말 기뻣습니다.

흔히 분산 아키텍처에 대해 말을 할 때 단순히 유의미한 레벨로 쪼개고 그 쪼갠 것들 간의 통신은 '적절하게' 동기와 비동기를 섞어 하면 그게 바로 적절한 아키텍처이다 라는 말을 하지만, 정작 정확한 그 방법에 대해 설명하는 곳은 보지 못했습니다.

이 책은 바로 그러한 점에서 단비와 같은 책이라고 생각됩니다. 이 책의 장점을 정리하면 다음과 같습니다.

- 어떤 하나의 정답을 강요하는게 아닌 현실적으로 접근하는 부분이 많습니다. 가장 이상적인 방법도 제시하지만 여러 요소면에서 각각의 경우의 수의 장단점을 소개합니다. 이는 우리가 현실에서 부딪힌 문제를 단계적으로 풀어나가는데에 매우 큰 도움이 될 것이라고 생각합니다.

- 분산 아키텍처에 대하여 매우 체계적으로 접근합니다. MSA에 대하여 파편적으로 알고 있던 지식을 명확하게 정리할 수 있었습니다.

- 규모가 크지만 기술적 부채에 치인 상황의 한 회사를 예로 들며 '점진적으로' 분산 아키텍처를 도입하는 흐름으로 이 책은 흘러갑니다. 그렇기 때문에 각 챕터마다 이 가상의 회사의 상황에서 기술적 화두를 던지고 하나하나 문제점들을 부러뜨려 나가기 때문에 그 내용에 비하여 매우 읽기 쉽고 몰입하기 좋습니다.

반면, 이 책을 온전히 이해하려면 넓은 분야에 대한 기술적 사전지식과 아키텍처 자체에 대해서 어느정도 지식이 요구 됩니다.

따라서 전반적인 지식을 사전에 습득하고 이 책을 보는 것이 조금 더 나은 결과를 낼 수 있으리라 생각됩니다

그럼에도 불구하고 전체를 다 이해하지는 못하더라도 부분적인 이해를 바탕으로도 현실의 문제 해결에 상당히 도움은 되리라 생각됩니다.

hji7***l2023-03-25

닐 포드는 정말 어려운 개념들을 이해하기 쉽게 정리하는 능력이 있는 것 같아요.

" <소프트웨어 아키텍처 101> 심화편 "이라는 딱지가 책표지에 찍혀있는 책입니다. 저는 <소프트웨어 아키텍처 101>도 읽고 리뷰했었는데요. 1년 4개월여 만에 그 다음 책을 만나보게 된 것입니다.

부제가 "The Hard Parts"라고 되어있지만, 읽기 어려운 책은 아니었습니다. 이는 소프트웨어 아키텍처로서 일을 할때 어려운 부분을 해결할 수 있는 내용을 설명하겠다는 의도로 보는 쪽이 합당한 것 같습니다. 닐 포드는 어려운 이야기를 쉽게 풀어 주는 능력이 탁월한 저자인것 같습니다. 이 책을 포함해서 닐 포드의 책을 4권 읽었는데요. 모두 꽤 심도깊은 이야기를 다루는 책이었지만 쉽게 쉽게 읽어 내려갔던 기억이 있군요.

"소프트웨어"라는 말은 "부드러운 제품"이라는 뜻을 가진 말입니다. 다른 산업의 "제품"들은 출시하고 나면 바꾸는 것 자체가 불가능하지만, 소프트웨어는 가능하거든요. 그래서, 소프트웨어는 고객의 니즈를 가장 잘 반영할 수 있는 체계를 가진 상품이 아닐까 싶습니다. 하지만, "소프트웨어"를 제품으로 출시하는 다양한 프로세스들은 다른 공학분야에서 차용한 경우가 많았습니다. 그래서, 근본적으로는 맞지 않는 옷을 입은 셈이 되었죠. 변경이 불가능한 제품을 만들기 위해서 진화해온 프로세스에 변경이 너무 쉬운, 아니 지속적으로 변화/진화해 나가야 하는 소프트웨어를 올리는 꼴이 된 것입니다. 그래서, 소프트웨어 개발자들은 상당히 많은 불편함을 겪으면서 일할 수 밖에 없었습니다. 그리고, 잘못된 프로세스에서 오는 괴리는 결국 프로젝트 진행에 어려움으로 나타나고, 그 어려움은 소프트웨어 개발자들의 추가근무와 소모적인 시간투자로 메우는 식으로 해결하곤 했었습니다.

하지만, 안 맞는 프로세스를 적용하다가 문제점을 간파하고 이를 해소하려는 노력을 했던 사람들이 은근히 많았고, 그들은 모여서 애자일 선언을 하기에 이릅니다. 기존 프로세스에서 "변화"는 "리스크"와 동치어 였습니다. "변화"가 일어나면 리스크가 발생하고, 변화가 많이 일어나면 프로젝트는 카오스 상태로 빠져서 실패에 이르게 되는 거죠. 하지만 애자일에서 "변화"는 "일상"입니다. 당연한 것이고, 리스크 요소가 아니게 됩니다. 그럼 이게 가능한 다양한 도구가 모든 파트에서 필요하게 될텐데요.

"소프트웨어 아키텍처"도 마찬가지입니다. 특히 "소프트웨어 아키텍처"는 변화하기 좋은 소프트웨어를 개발하기 위해서 뼈대와 프레임워크가 되는 역할을 하는 파트이기 때문에, 모든 소프트웨어 개발 파트 중에는 가장 변화하기 힘든 파트인데요. 그럼에도 불구하고 아키텍처 자체도 변화 요구를 받아들여서 변화해갈 수 있는 장치를 만들어 두어야 하기 때문에, 상당히 골치아픈 분야가 아닐까 싶습니다.

<소프트웨어 아키텍처 The Hard Parts>는 이 부분을 이야기하고 있는 책입니다. 그리고 그 핵심을 찌르는 말로 이 책을 시작하고 있군요.

" 소프트웨어 아키텍처에서는 최고의 설계를 고집하지 마세요. 그 대신에 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾으세요 ( - 26 페이지 )"

현 시점에서 최선을 선택할 수 있는 안목과 이를 실행할 수 있는 용기가 소프트웨어 아키텍트에게 필요한 기본적인 소양인 것이죠. 그 다음 필요한 것은, 바로 변화를 이끌어나갈 "도구"입니다. 안정적으로 다음 소프트웨어 아키텍트를 구성해 낼 방법이죠.

저자는 이 부분에 대해서 상당히 역동적으로 서술하고 있는데요. 먼저 소프트웨어 아키텍처 개발자들이 소프트웨어 아키텍처를 변경시켜야 할 때 나눌만한 대화를 소개하며, 어떻게 대응해 나가는지를 보여주는 방식을 취하고 있다는 것입니다. 정말 딱딱할 것 같은 주제들이 소개되고, 중간중간에 개발자들 사이 대화들이 들어가니 이해하기 쉽고 읽기도 더 수월했습니다.

각 장(chapter)들은 소프트웨어 아키텍처 개발자들이 소프트웨어 아키텍처를 변경시켜나갈때 고민하게되는 순서로 아키텍트에 대한 주제를 하나씩 다루고 있습니다. 소프트웨어 아키텍처가 다소 개념적인 이야기이지만, 이런식으로 설명해 나가니 이해하기 좋았던것 같네요.

특히 요즘은 마이크로 서비스 아키텍처로 기존 소프트웨어 아키텍처를 수정해 나가야 하는 경우가 많을 텐데요. 그런 상황에서 어떻게 시작하고 전개해 나가야 하는지 갈피를 잡지 못하고 있는 개발자들이 있다면, 이 책은 바이블 역할을 할 수 있을 거라 장담합니다.

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

hbko***l2023-03-24

분산 아키텍처를 위한 모던 트레이드오프 분석

< 소프트웨어 아키텍처 The Hard Parts > | 닐 포드 외 3인 지음 | 이일웅 옮김 | 한빛미디어

이 책은 분산 아키텍처를 구축할 때 아키텍트가 트레이드오프를 객관적으로 분석하여 의사 결정을 내리기까지의 전 과정을 상세히 설명한다. 그렇다면 소프트웨어 아키텍처를 이야기하면서 Hard parts를 언급한 이유는 무엇일까? 이 책에서 hard는 어렵다라는 의미와 단단하다는 의미를 내포하고 있다. 즉 소프트웨어 아키텍처, 특히 분산 아키텍처는 일반적인 방법론이나 모범 사례가 존재하지 않는다. 따라서 모든 분산 아키텍처는 각각 유일한 사례가 되는 경우가 많다. 그만큼 어렵다는 의미라고 볼 수 있다. 한편으로는 처음 설계가 잘못되어 구축이 되고 나면 그 상태로 단단하게 굳어져 다시 고치는 작업이 어렵다는 의미도 있다.

소프트웨어 아키텍처에 대해 소개하는 많은 책들은 대부분 이론적인 사례를 많이 다룬다. 따라서 개념적인 부분은 이해하지만 실제 필드에서 적용하기 위해서는 또 다른 고민이 필요한 것이 사실이다. 이 책은 그런 면에서 현실적인 도움을 주는 책이라고 볼 수 있다. IT 서적이지만 책을 읽고 이해하는 데 별 어려움이 없을 정도로 글이 매끄럽고 번역이 잘 되어 있는 것 같다. 또한 가상의 시스템을 사례로 들어 분산 아키텍처를 구성해 가면서 발생하는 다양한 트레이드오프와 접근 방법, 그리고 문제점에 대해 설명한다. 또한 문제점을 해결하기 위한 구체적인 방안을 자연스럽게 이어가고 있어서 실제 업무를 진행하는 것과 유사한 느낌을 가지게 한다.

책은 크게 2개의 파트로 구성되어 있다. 파트 1은 따로 떼어놓기이다. 분산 아키텍에서 트레이드오프를 분석하기 위해 아키텍처를 하나씩 떼어내어 완전히 이해하는 과정이 필요하다. 아키텍처 구조 측면에서 각 요소가 정적으로 결합되는 방식을 설명하고, 아키텍터의 정적 커플링과 동적 커플링의 범위를 정의하면서 이를 분해하면서 생기는 문제를 살펴본다. 그리고 이를 바탕으로 실제 분해 프로세스를 시작하고 코드 베이스를 평가하고 해체하는 도구를 알아보고, 이를 위해 사용할 수 있는 다양한 패턴을 설명한다. 또한 분산 아키텍처에서 데이타와 트랜젝션의 중요성이 점점 커지고 있음에 따라 이를 위한 다양한 주제에 대해 언급한다.

파트 2는 다시 합치기이다. 시스템을 분해해 놓고 나면 곧 시스템을 다시 합쳐 하나의 응집된 단위로 작동시켜야 할 필요성을 느끼게 된다. 이 측면에서 서비스 통신, 계약 분산, 분산 워크플로, 분산 트랜젝션, 데이터 오너십, 데이터 액세스, 분석 데이터 관리 등 다양한 어려운 난제를 극복하는데 필요한 기술을 설명한다.

책에서 설명되는 개념 하나 하나가 실제 업무에 도움이 되는 유용한 정보를 포함하고 있다. 기술은 지속적으로 발전하고 변화하는 현 환경에서 가상의 실 사례를 들어 분산 아키텍처를 분해하고 결합하는 과정을 살펴 봄으로 현실적인 조언과 더불어 각자의 시스템에 활용할 수 있는 소중한 정보를 얻을 수 있는 책이라고 생각한다.

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

rudfla4***l2023-03-23

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

stylep***l2023-03-22

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

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

제목 : 소프트웨어 아키텍처 The Hard Parts

- 대상독자

아키텍처에 관심이 있는, 어느정도 아키텍처를 다뤄 본 아키텍트 또는 개발자.

- 책의 내용 및 구성

1. 이 책은 소프트웨어 아키텍처 101 의 후속작(전작을 딱히 안읽어도 됨)

2. 전작이 소프트웨어 아키텍처의 중심 철학과 다양한 아키텍처의 세계를 빠르게 훑어보는 개론서였다면, 이 책은 실무 아키텍처링을 할 때 가장 난해한, 그러나 한번 결정되면 바꾸기 어렵고 근본적인 영향을 미치는 부분에 대해 살펴봄(한빛 미디어 지정 '중급' 난이도, 전작은 '초중급' 난이도).

3. 가상 애플리케이션(한빛 가이버 등) 사례로 구체적이고 실질적인 문제 해결방안 제시

4. 가상 애플리케이션에 맞춰 아키텍처를 완성해가는 과정을 좀 더 실감나게 표현하기 위해 가상의 기업과 조직, 인물들을 창조한 원서의 내용에 맞게 사명과 등장인물들을 로컬화 함(한국식 상황극으로 만듬)

5. 각 장별로 지정된 주제에 대한 개념 소개와 해당 개념에 대한 실제 사례를 통한 설명으로 이루어져 있음.

6. 총 508쪽, 2개의 파트와 15개의 챕터로 구성.

- 책에서 눈에 띄는 점

1. 깔끔한 책의 색상 구성이 눈에 띔. 눈에 편안한 푸른색 배경과 도형, 어두운 색을 잘 조합하여 눈에 확 띄지 않으며 글을 읽는데 방해하지 않는 이모티콘(그림) 등을 활용, 코드 설명이 필요한 경우엔 과하지 않은 간결한 코드로 형식을 보여줌.

2. 깔끔한 진행 방식. 각 장별 어떤 상황에 대한 상황극을 시작으로 특정 상황이나 문제에 대해 물음을 던져 놓고 그 내용을 살펴보는 방식으로 진행

- 총평

어렵다. 라고 한마디로 끝내기엔 초반 부분은 술술 읽힌다. 상황극 때문일까? 팀원들이 별거아닌 대화 시작으로 책의 내용을 유도하며 대화를 나누는 것이 마치 예전 팀원들과 일 시작전 나누던 잡담이 개발 관련 이야기로 번지는 기분을 받았기 때문일 것 같기도 하다. 일상생활 잡담을 시작으로 번역을 하면서 로컬화 하시며 얼마나 고생했는지가 눈에 훤하다(고생하셨습니다).

아키텍처 라는 분야에 관심이 많은 것은 아니지만 일단 개발과 관련된 부분이 많고 앞으로 개발을 해 나가면서 또는 앞으로 개발자 외의 진로를 선택할 때 도 도움이 될 내용이 많을테니까 조심스럽게 읽어 내려갔다.

저자는 이 분야에 대해 확실한 지침서 같은 책이 없는것 같다고 말한다. 확실히 it 기술은 빠르게 변하고, 혁신적이었던 기술이 몇 년 뒤엔 쓰레기 취급을 당하며 버려질 수도 있으니 이해가 간다, 그렇기에 이 책이 '실습'이라는 내용을 타겟으로 잡은 것이 납득이 된다.

한빛미디어에서 지정한 '중급' 서적은 이번이 두번째 인 것 같다. 첫번째 책은 제목과 내용은 기억이 안나지만 무척이나 어렵고 지루했던 것 같은데, 이 책은 그정도로 지루하진 않다. 하지만 모르거나 아리송한 용어가 많이 튀어나오고, 후에 설명하는 방식과 중간중간 내용과 관련없는 팁들이 나오는 것들이 방해 요소이자 난이도를 올리는 요소인 것 같다(팁들은 분명 필요한 내용이니 들어갔겠지만 '이게 왜 여기서 나오지?' 하는 부분들이 조금 있다).

책장에 넣어놓고 어려운 뒷부분을 한번씩 읽어나가며 아무 도움없이 이해가 된다면 초급딱지를 뗀 자신을 자랑스러워 해도 될 만한 책이 아닐까 싶다.

cdfg***l2023-03-20

[소프트웨어 아키텍처 The Hard Parts] 리뷰

yjm950***l2023-03-19

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

이 책은 소프트웨어 아키텍처에 대한 깊이 있는 이해를 제공하며, 다양한 주제와 사례를 통해 아키텍처의 중요성과 세부 사항을 상세하게 설명한다. 주요 장점은 다음과 같다.

1) 철저한 구성과 깊이 있는 내용: 각 장은 명확한 개념 소개와 실제 사례를 통한 설명으로 이루어져 있으며, 이를 통해 독자가 소프트웨어 아키텍처의 복잡한 주제를 쉽게 이해할 수 있다. 한빛가이버 사가를 통해 독자는 실제 상황에서 어떻게 아키텍처 원칙과 패턴을 적용하는지 이해할 수 있다.
2) 아키텍처와 설계의 차이점: 아키텍처와 설계의 차이를 명확하게 정의하여, 독자가 두 개념을 적절하게 활용할 수 있도록 돕는다.
3) 아키텍처 퀀텀, 모듈성, 분해 및 재사용 패턴: 이 책에서는 아키텍처의 핵심 개념인 퀀텀, 모듈성, 분해 및 재사용 패턴을 체계적으로 소개하고, 이를 실제 사례와 연결하여 설명한다.
4) 데이터 분리, 오너십, 분산 트랜잭션 및 워크플로 관리: 이 책은 데이터 분리, 오너십, 분산 트랜잭션 및 워크플로 관리와 같은 핵심 아키텍처 이슈에 대한 실용적인 가이드를 제공한다.
5) 트레이드오프 분석: 마지막 장에서는 독자들이 소프트웨어 아키텍처의 다양한 트레이드오프를 이해하고 분석하는 방법을 제시하여, 독자가 실제 프로젝트에 적용할 수 있도록 돕는다.
6) 부록: 이 책의 부록은 중요 개념, 용어, 아키텍처 결정 레코드 및 트레이드오프에 대한 색인을 제공하여, 독자가 쉽게 참고할 수 있는 핵심 정보를 제공한다.

결론적으로 이 책은 소프트웨어 아키텍처에 대한 탁월한 가이드로, 독자들이 이 분야의 전문가가 되기 위한 필수 도서로 추천된다. 각 장에서 다루는 주제들은 실용적이고 명확하게 설명되어 있으며, 이를 통해 독자들이 현실 세계의 문제에 대처할 수 있는 능력을 키울 수 있다. 또한 이 책은 개발자, 아키텍트, 기술 리더, 프로젝트 관리자 등 다양한 직업군의 전문가들이 참고하여 도움을 받을 수 있다.

한편으로는, 이 책의 어휘 및 개념의 난이도가 다소 높을 수 있어, 아키텍처와 관련된 기초 지식이 없는 독자들에게는 다소 어려울 수 있다. 그러나 이 책을 꼼꼼하게 읽고 이해한다면, 소프트웨어 아키텍처를 적용하는데 필요한 지식과 기술을 충분히 습득할 수 있을 것이다.

전반적으로 이 책은 소프트웨어 아키텍처에 대한 심층적인 이해를 원하는 독자들에게 강력히 추천된다. 이 책을 통해 독자들은 소프트웨어 아키텍처의 복잡한 주제를 쉽게 이해할 수 있으며, 실제 프로젝트에 적용할 수 있는 기술을 습득할 수 있다.

linux***l2022-11-02

아키텍처란 트레이드 오프 분석과 결정의 완성체

책소개

소프트웨어 아키텍처 문제-해결을 위한 지식과 실용적 프레임워크를 다루는 안내서

『소프트웨어 아키텍처 101』의 실무편에 해당하는 후속작이다. 『소프트웨어 아키텍처 101』을 읽은 독자라면 누구나 관심을 가질만하다. 그 만큼 『소프트웨어 아키텍처 101』 에서 많은 것을 얻은 독자일 것이다.

이 도서는 아키텍트가 객관적으로 트레이드오프를 분석해서 올바른 의사 결정을 내릴 수 있는지 이야기한다. 고객의 요구사항을 분석하고 해당 요구사항을 만족하기 위해 FR, NFR에 대해 정리를 하고 해당 요구사항을 만족하기 위해 설계를 해 나아간다. 이 때 어떤 선택이 어떠한 아키텍처로 발전해 나아가는지 경험할 수 있다.

전작이 소프트웨어 아키텍처의 중심 철학과 다양한 아키텍처의 세계를 빠르게 훑어보는 개론서였다면, 『소프트웨어 아키텍처 The Hard Parts』는 제목에 걸맞게 실무 아키텍처링을 할 때 가장 난해한, 그러나 한번 결정되면 바꾸기 어렵고 근본적인 영향을 미치는 부분(hard part)을 진지하게 살펴본다.

다양한 패턴과 사례, 그리고 연습

이 도서에는 현업에서 접할 수 있는 다양한 패턴을 설명하고 현업에서 마주칠 수 있는 사례와 접목하여 상세하게 설명하고 있다.

가장 좋은 던 것은 트레이드 오프를 분석하고 최적 설계를 찾아 나아가는 과정을 간접적으로나마 경험할 수 있다는 것이다. 개발자가 이러한 과정에 참여하는 것은 쉽지 않고, 기회도 잘 주어지지 않는다.

이 책을 통해 아키텍트는 어떤 과정을 거쳐 아키텍처를 완성해 나아가는지 이해하고 학습할 수 있다. 간혹 개발자들은 데이트베이스는 자신이 익숙하던 것을 그대로 다음 프로젝트로 가져가거나 또는 아키텍처 설계 단계에서 이미 데이터베이스를 결정해 둔 상황일 때도 있다.

물론 친숙한 것이 좋지만, 친숙한 것이 프로젝트의 성공의 길이 될 수 는 없다. 그렇기에 왜 데이터베이스 중 어떤 데이터베이스를 어떤 과정을 거쳐 고민하고 선택하게 되는지 등 다양한 아키텍처 트레이드 오프 분석 과정을 경험해보는 것을 추천한다.

친숙한 대화형 설명, 양날의 검(?)

기술서적에서 이해를 돕기 위해 어떠한 문제를 서술하고 해결해 나아가는 방법을 대화형으로 간혹 사용하곤 한다. 실제 상황에 몰입하면 조금 더 상황 이해에 도움이 되기 때문이라고 생각한다. 이 도서는 친숙한 대화형으로 이루어져 있다. 대화형으로 구성된 대표적인 도서로는 헤드퍼스트 디자인패턴 을 떠올릴 수도 있다. 하지만 이 책은 조금 결이 다르다.

이 도서는 실제 등장인물의 대화가 소설책(?) 또는 영화 대사(?) 처럼 각 등장인물의 대화가 상세하게 작성되어 있다. 질의응답식 보다 더욱 넓게 등장인물의 짜증과 갈등, 개발자 간의 대화와 의견의 조율이 소설처럼 대화로 이루어져 있다.

이러한 방식의 도서는 처음 마주해서 조금 당황스럽긴 하지만, 누군가에게는 많은 도움이 될 수도 있을거라 생각한다. (나는 아니었다. 솔직히 더욱 산만하였다.) 문제를 제시하고, 문제가 발생한 배경과 솔루션을 찾아나아가는 점을 스토리로 풀어내는 것 보단 간결하게 요점만 작성해도 좋을 것 같다는 생각을 계속 하게 되었다.

누군가에겐 더 큰 이해를, 누군가에겐 더 큰 혼란스러움을 주지 않을까?

결론

『소프트웨어 아키텍처 101』을 읽지 않았다면, 먼저 『소프트웨어 아키텍처 101』을 읽고 이 도서를 읽었으면 한다. 왜 출판사에서 『소프트웨어 아키텍처 101』의 실무서라고 추천을 하는지를 곱씹어보고 도서의 순서에 맞게 학습을 하면 쉽게 접근 및 이해를 할 수 있다고 생각한다.

이 책은 아키텍트란 트레이드 오프를 비교 분석하고 옳은 선택을 해나아가는 존재라는 것을 조금 더 명확하게 명시하는 것 같다. 아키텍트를 목표로 하는 분들에게, 그리고 분산 아키텍처 기반에서 개발을 하는 개발자들에게 좋은 나침반이 될 것이라 생각한다.

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

yong***l2022-11-01

명불허전

한 일년전 이었을까 소프트웨어 아키텍처에 관한 근래 제일 재미난 책을 한권 읽었었다.

[서평][컴퓨터공학] 소프트웨어 아키텍처 101 / 한빛비디어

내가 IT분야의 전문 아키텍트라는 타이틀을 달만한 역할을 담당하고 있는 것은 아니지만 기간계 성격의 인프라성 시스템 설계 구축과 표준화에 제법 오랜 시간을 담당했었고, 내가 핵심이 됐던 제품과 in-house로 개발한 시스템의 아키텍팅 경험도 있고 하다보니 관심을 가지고 꾸준히 살펴보게 된다.

더군다나 클라우드 컴퓨팅이 보편화 되면서 이제 IT개발자도 아키텍처에 관해 관여하게 되는 경우가 많아진 시대적인 흐름도 내가 관심을 가지고 틈틈히 살펴보게 되게 되는 원인인 것 같다.

아무튼 "소프트웨어 아키텍처 101"은 그런 내게 "유레카"라 외칠만큼 의미있고 또 다른 영감을 준 책이 아닌가 싶다.

자, 또 한권의 책이 있다.

"소프트웨어 아키텍처 101"의 저자가 포함된 네명의 공저자가 쓴 책으로 이 책은 전작의 심화 버전이라 보면 될 듯 하다.

기본 개념을 꼼꼼하게 살펴보면서도 프랙티스와 실제 사례를 살펴보는 과정을 통해 각 아키텍처의 장단점을 정리하고 아키텍처에 결정에 대한 중요한 의사결정을 내릴 수 있는 인사이트를 얻을 수 있을듯 하다.

MSA 구조, 즉 서비스를 중심으로하는 아키텍처에 이르러서는 서비스를 어떠한 크기로 나눌 것인지 어떤 상황과 시점에 이를 통합할 것인지 참 어려운 숙제인데 이 책은 이 두가지 관점에서 트레이드오프 분석을 통해 올바른 의사결정을 내릴 수 있는가에 대한 이야기를 담고 있다. 실무적인 아키텍팅을 하면서 가장 어렵고 난해한 부분...

전작을 읽어봤다면 명불허전이 허언임을 알게될 듯 하다, 인구에 회자되는 전작보다 좋은 속편은 없다는 영화계의 속설은 출판계에는 해당하지 않는가 보다... ^^

※ 본 리뷰는 IT 현업개발자가, 한빛미디어 책을 제공받아 작성한 서평입니다.

hyeon***l2022-10-31

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

2022년 10월에 출간된 <소프트웨어 아키텍처: The Hard Parts>를 소개합니다. 이 책의 부제는 <분산 아키텍처를 위한 모던 트레이드오프 분석>입니다. 이 책은 4명이 집필했으며, 대표 저자로 닐 포드(Neal Ford) 님과 마크 리처즈(Mark Richards) 님입니다. 필자는 닐 포드 님과 마크 리처즈 님의 책을 자주 읽고 있으며, 대표적으로 몇 편을 리뷰(함수형 사고, 소프트웨어 아키텍처 101 등)했던 적이 있습니다. 이 책의 역자는 이일웅 님으로 나쁘지 않은 번역으로 새로운 책을 편하게 읽게 해주시는 매우 고마운 분입니다. 이일웅 님은 <마이크로서비스 패턴>, <스프링 5 레시피>, 등 외에도 약 20여 편을 번역하셨습니다.

이 책의 원서는 아마존에서 5점 만점에 4.6점을 받고 있으며, 원서는 2021년 11월 말에 출간된 따끈따끈한 <소프트웨어 아키텍처 101>은 소프트웨어 아키텍처의 개론서라면, 이 책은 실무에서 고려해야 하는 부분을 조금 더 깊이 있게 다룬 책으로 볼 수 있습니다.

<소프트웨어 아키텍처: The Hard Parts>는 약 500페이지로 구성되어 있어 휴대하면서 읽기에 크게 부담스럽지 않습니다. 전자책으로도 출간되어 있으므로, 전자책 뷰어가 있으시다면 전자책으로 만나보는 것도 좋을 것 같습니다.

한빛미디어 평가단에 참가하여 작성한 글이며, 한빛미디어에서 제공해준 책을 읽고 작성했음을 밝힙니다.

이 책의 매력은?

<소프트웨어 아키텍처: The Hard Parts>는 2부 15장으로 구성되어 있습니다. 1부는 따로 떼어놓기라는 제목으로 관련 내용을 기술하고 있으며, 2부는 다시 합치기라는 1부와 반대되는 제목으로 관련 내용을 기술하고 있습니다. 책의 차례를 보면 관련 내용을 어렴풋이 짐작하실 수 있을 것입니다.

이 책은 필자에게 큰 재미를 준 책입니다만, 특히 9장에서 12장까지의 내용을 재미있게 읽었습니다. 트랜잭션과 분사 트랜잭션을 다룬 이 챕터들은 제 관심사와 밀접한 관련이 있었습니다. 12장에서 다룬 내용은 사가 패턴에 대해서 조금 더 깊이 있게 다루고 있어서 사가 패턴에 대해 정리 및 요약을 잘할 수 있었습니다. 이 책을 읽으면서 제가 모르던 패턴도 알게 되어서 관련 내용을 한 번 더 숙지할 수 있는 계기를 준 고마운 책입니다.

이 책의 저자들이 이야기하는 주요 내용은 필자의 평소 생각과 거의 일치했습니다. 덕분에 공감하며 많은 것을 배울 수 있는 책이었습니다. 경험할 수 없었던 많은 내용을 이 책을 통해 스크립트로 읽었지만, 제가 얻은 지식은 단순 텍스트에 그치지 않고 이 책에서 다루고 있는 세계에 들어가서 더 많은 것을 얻을 수 있었던 것 같습니다.

이 책의 내용을 연구실에 알맞은 내용으로 각색하여 대학원 세미나에 응용해보고 싶습니다. 규모를 작게 만들어서 세미나를 진행한 후 토론해보면 구성원 모두가 조금 더 성장할 수 있을 것 같습니다.

마치면서

이 책의 소개 페이지에 제목에 어떤 의미를 담고 있는지 소개하고 있습니다. <소프트웨어 아키텍처: The Hard Parts>에서 Hard의 의미는 '어렵다', '단단하다'라는 의미가 공존한다고 합니다. 단지 어려울 뿐만 아니라, 한 번 잘못된 결정을 내리면 단단하게 굳어져 다시 뜯어내고 고치는 것조차 어려운 아키텍처의 본질을 담고 있다고 합니다.

소프트웨어 아키텍처의 모든 게 다 트레이드오프이고, 어떤 아키텍처가 최적인지는 그때그때 경우에 따라 다릅니다.

정답이 없는 문제를 탐구하고 찾아가는 과정입니다. 재미도 있지만 실제로 작업하다 보면 두렵고 어렵습니다. 이 책의 제목에서 담고 있듯이, 잘못된 선택이 돌이킬 수 없는 결과를 가져오기도 합니다. 해외 유명 아키텍처 분들이 미리 경험한 결과물을 집대성한 이 책은 꼭 한 번쯤 읽어보고 소프트웨어 아키텍처에 대한 시야를 넓히는 계기가 되었으면 좋겠습니다.

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

innur***l2022-10-31

도서 리뷰_소프트웨어 아키텍처 The Hard Parts

platanu***l2022-10-30

분산 아키텍처를 위한 모던 트레이드오프 분석

이 책은 '소프트웨어 아키텍처 101' 의 실전판이다. '소프트웨어 아키텍처 101 서평 보기' 동일한 저자가 쓴 이 책은 먼저 출간된 책을 집필하면서 부터 같이 진행됐다고 한다. 전작이 분산 아키텍처의 소개와 설계상 어떤 특징을 가지는지, 팀 리팅을 어떻게 이끄는지 개괄적으로 설명하는 책이라면, 이 책은 그것을 실제하는 아키텍처를 집대성 해놓은 책이라고 보면 될 것 같다.

'실제' 라는 말과 어울리게 모놀리식 아키텍처의 서비스를 시나리오로 들어 문제점을 분석하고 분산 아키텍처로 전환하는 과정을 소개한다. 그리고 결정에 필요한 명분과 기술적 잇점에 대한 예시도 함께 제공한다. 어느것이 절대적으로 낫다는 맹목적인 주입보다 이것을 행함으로 인해 얻는 득과 잃는 실을 납득할 수 있게 설명한다.

서비스, 어플리케이션, 컴포넌트를 분리하기 위한 분석 과정과 그 실제를 보여준다. 특히 데이터베이스를 어떻게 분리 할 것인지에 대한 아이디어가 돋보인다. DB는 외래키와 트랜잭션 같은 독립적인 기능에 많이 의존하기 때문에 분리하는 것이 쉽지 않다. 이를 고려해 단일 DBMS 내에서 스키마를 분리하고, 결과적으로 별도의 DB로 분리해내는 절차를 설명한다.

서비스를 분리함으로써 재사용성에 대한 트레이드 오프와 함께 '공유 서비스' 라는 절충안을 소개한다. 특히 공통 코드라고 일컫는 공유 라이브러리는 공유했을 경우 강한 의존성이 생기므로 REST나 gRPC로 공통 코드에 엑세스 하도록 하는것이다. 다만 단일 라이브러리, 공유 라이브러리, 공유 서비스에 대한 장단점이 공존하므로 적절한 트레이드 오프가 필요하겠다.

이 책에서 가장 흥미롭게 봤던 부분인 데이터 오너십이다. 분산 아키텍처에서 트랜잭션에 따른 데이터의 일관성을 어디서 오너십을 가지는가에 대한 내용을 다룬다. 이 파트를 보면서 쇼핑몰의 경우 주문 폭주에 따른 물류 마감으로 인한 주문 종료를 예시로 들 수 있겠다는 생각을 했다. 이 경우 주문 수 집계와 물류 가용성을 고려해야 할 것이다. 주문, 배송사, 물류 세가지 데이터를 어떻게 동기화 하고 상품의 주문 여부를 컨트롤 할 인지. 이 데이터를 어떻게 일관성을 이룰 것인지 패턴에 대해 아이디어를 많이 얻을 수 있었다. 백그라운드 동기와 패턴, 오케스트레이티드 요청 기반 패턴, 이벤트 기반 패턴을 소개한다.

그외 나머지 다 소개를 하지는 못했지만 데이터 엑세스, 분산 워크플로관리, 트랜잭셔널, 계약에 대한 많은 아키텍처 패턴 을 제공한다.

그리고 마지막에는 트레이트 오프를 결정하는 방법론에 대해서도 설명한다. 앞서 설명한 여러 패턴들을 놓고 어느 것이 가장 적합한 아키텍처인가를 판단해야 할 때 각 패턴을 분석하고, 평가할 수 있는 기준을 어떻게 결정할 것인지 알려준다. 그리고 그러한 기준이 정해졌을때 판단 지표를 작성함에 있어 피해야할 태도나 편견에 대해서도 좋은 귀감이 된다. 결론을 한마디로 말하자면 '은탄환은 없다' 라는 골자이나, 생각보다 뼈아픈 직언이 많으니 많은 생각을 들게 한다.

'The Hard Parts'라는 말에 어렵다고 느낄 수 있으나 서비스를 운영하는 엔지니어 본인 입장에서는 그동안 해결하기 어려웠던 두루뭉술했던 이슈들이 교통정리가 되는 결과에 도달했다. 다시 정독하고 서비스에 어떻게 녹여낼 수 있을지 오히려 좋은 귀감이 된 책이였다.

munor***l2022-10-30

소프트웨어 아키텍처 101과 함께 보면 좋을 책

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

아키텍처라는 분야에 대해서는 항상 낯설고 어색한 감이 있기 때문에 해당 분야에 대해 한번쯤은 접해보고 싶다는 마음에 리뷰 책으로 고르게 되었습니다. 2달만에 쓰는 리뷰라 괜히 구성을 좀 다르게 작성해보겠습니다. (?) 이번 리뷰는 책 내용 중 1장 베스트 프랙티스가 없다면? 파트에 대해 중점적으로 작성했습니다. :)

마이크로서비스 시대

요즘과 같이 분산 시스템에서 가장 관심받고 있는 스타일의 아키텍처는 마이크로서비스입니다. 책에서는 아래의 3가지 배경이 공유 리소스와 중앙집중식 오케스트레이션에서 마이크로서비스 시대를 열었다고 설명합니다.

오픈소스, 리눅스(상업적으로 무료 이용 가능)
퍼핏과 셰프와 같은 형상관리 도구의 등장
컨테이너 및 오케스트레이션 도구의 인프라 등장

(중략)

이외에도 책에서는 아키텍처와 설계, 서비스, 커플링, 컴포넌트, 동기 통신, 비동기 통신, 오케스트레이션, 코레오그래피, 원자성, 계약(컨트랙트), 비티케팅 워크플로, 티케팅 워크플로와 같은 용어 정의를 짚고 넘어간다는 점이 좋습니다. 저 같은 경우 아키텍처라는 개념이 낯설었기 때문에 1장에서 용어의 정의나 비슷해보이는 용어들에 대해 다시 비교하고 설명해주는 친절함이 이 책에서 가장 좋게 본 점이었습니다. 또한 하나의 아키텍처를 예시로 하여 문제 상황 시뮬레이션, 컴포넌트, 데이터 모델과 같이 문제 상황을 구체적으로 묘사해준다는 점도 책의 장점 중 하나였습니다.

전체적인 목차를 봤을때 꽤나 구체적인 책입니다. 참고로 이 책의 전 단계에 해당하는 책은 소프트웨어 아키텍처 101이라고 합니다. 책 설명 중간중간에 몇몇 개념은 해당 책을 참고하라고 하기 때문에 소프트웨어 아키텍처 101과 소프트웨어 아키텍처 The Hard Parts를 같이 읽으면 아키텍처에 대한 지식을 더 차근차근 쌓아갈 수 있을거 같습니다. 관련해서 관심있으신 분은 두 개의 책을 함께 보는 것을 추천드립니다.

출처 - https://vg-rlo.tistory.com/304

snunc***l2022-10-30

도서 리뷰 : 소프트웨어 아키텍처 The Hard Parts

소프트웨어 아키텍트에게 트레이드오프와 관련된 고민은 늘상 있는 법이다. 효율적인 소프트웨어 설계를 위해 주어진 다양한 선택지 앞에서 과연 아키텍트는 어떤 것을 답안지로 골라야 할 것인가? 과연 무엇이 옳은 선택이고 그릇된 것인지 어떻게 판단할 수 있을까? 그렇게 판단할 수 있는 기준은 과연 무엇일까? 그 기준으로 삼을 수 있는 근거는 과연 어디서부터 구할 수 있는 것일까? 이러한 일련의 상황과 마주하게 되는 아키텍트에게 속시원한 답은 없는 것일까? 답은 쉽게 구해지지 않고, 그것을 찾아가는 여정은 고되고 그 과정에는 온갖 괴로움이 수반된다. 그럼에도 불구하고 이러한 아키텍트에게 도움이 될 수 있는 책이 한 권 존재한다면 그것은 바로 이번에 소개하게 될 서적이 되리라 생각한다.

이 책은 '소프트웨어 아키텍처 101'에 대한 후속 서적으로서 전작에서 소프트웨어 아키텍처에 대한 거대 담론을 이야기했다면, 이번엔 소프트웨어 아키텍처를 둘러싼 다양한 각론 위주로 구성된 채 저자들의 수준 높은 혜안이 듬뿍 배어 있는 게 특징이다.

본 서적은 크게 Part 1, Part 2로 구분되어 있는데 Part 1은 따로 떼어놓기, Part 2는 다시 합치기로서 이에 대한 다양한 소재를 통해 이야기가 전개된다. 따로 떼어 놓기는 쉽게 말해 쪼개고 분리하기, 다시 합치기는 통합으로 치환될 수 있겠다. 이 개념은 소프트웨어 아키텍처뿐만 아니라 현존하는 모든 아키텍처에 적용될 수 있는 핵심 원리이다.

각설하고 이 책의 부제인 '분산 아키텍처를 위한 모던 트레이드오프 분석'이 전체 내용을 관통하는 주요 핵심 메시지로서 모놀리식 아키텍처가 MSA 형태의 아키텍처로 어떻게 진화하고 변주될 수 있는지 다양한 패턴과 사례가 제시되어 어떤 상황에 어떠한 레퍼런스가 적용될 때 트레이드오프를 최소화 할 수 있는지에 대한 통찰을 여실히 제공받는다.

한빛가이버라는 가상의 애플리케이션과 이와 연관되어 있는 가상의 등장인물이 이 책 곳곳에 배치되어 보다 입체적으로 아키텍의 변화 과정을 현실감 있게 지켜보는 재미가 꽤 쏠쏠하다. 시간이 지남에 따라 한빛가이버가 완성도 있는 아키텍처로 변화하며 이를 둘러싼 트레이드오프 분석 과정이 동반될 때마다 얻게 되는 지식은 값어치를 매길 수 없을 정도로 유용하다.

전편에 비해 좀 더 난해한 내용이 많은 것이 사실이지만, 이 책은 결코 한 번 읽고 덮는 것으로 그칠 것이 아니라 곁에 두고 오랫동안 즐기고 맛보고 뜯어 보면서 내용을 음미하고 곱씹어 보는 과정이 절대적으로 필요하겠다. 전편을 통해 소프트웨어 아키텍처의 정수를 맛본 이라면 이 책은 반드시 탐독해야할 서적이다.

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

enur***l2022-10-30

시스템 구조를 개선하고자 할 때 도움되는 이미지 트레이닝 도서

한 줄 요약 : 시스템 구조를 개선하고자 할 때 도움되는 이미지 트레이닝 도서

《소프트웨어 아키텍처 : The Hard Parts》는 신규 시스템의 구조(아키텍처)를 구상하거나, 기존 시스템의 구조를 개선하고자 할 때 참고하기 좋은 책이다. 책 제목에 'The Hard Parts'가 붙은 것을 보고 이미 눈치챘겠지만 《소프트웨어 아키텍처 : The Hard Parts》는 먼저 번역, 출간된 《소프트웨어 아키텍처 101》의 심화버전이다. '심화'라고 해서 더 어렵고, 복잡한 아키텍처를 다루는 것이 아니다.

《소프트웨어 아키텍처 101》에서는 아키텍처를 구성하는 아키텍트가 성장하기 위한 마음가짐, 방향성을 일러준다. 또한 현재 많이 접할 수 있는 아키텍처들을 소개하고 특징을 비교하는 형태로 구성되어 있다. 심화판인 《소프트웨어 아키텍처 101》는 새로운 서비스를 오픈하기 전 아키텍처를 설계한다거나, 기존 운영중인 서비스를 개선하는 상황 등 아키텍트가 되고 경력이 쌓였을 때 마주할 수 있는 상황을 해쳐나가기 위한 지식과, 경험을 담고 있다.

책은 크게 1. 분리하기, 2. 합치기 두 파트로 나뉜다. 같은 문제, 즉 같은 서비스라 하더라도 하나의 시스템을 작은 서비스 여러개로 분리해서 좋은 상황이 있고, 반대로 여러 서비스를 하나로 합치는 것이 좋은 상황이 있다. 경험을 쌓고 있는 독자라면 실제로 경험해보기 전에는 구분하기 어려울 것같다. 하지만 이 책은 상황극을 통해 사례의 당사자인 것처럼 내용을 풀어간다. 그리고 수식과 의사코드(pseudo code)가 있어 아키텍처를 좀 더 직관적으로 머리속에 그려 볼 수 있다.

책을 읽으며 《리팩터링 2판》과 구성이 비슷한 것 같다는 생각을 했다. 《리팩터링 2판》은 개선이 필요한 코드를 두고 무엇이 문제인지 설명 후 리팩터링 기법을 소개하고, 그 기법을 실제로 적용해보는 형태로 구성되어 있다. 《소프트웨어 아키텍처 : The Hard Parts》에서는 코드레벨에서 좀 더 깊은 차원으로 들어가 '아키텍처'에 대해 리팩터링을 하는 기분을 느낄 수 있었다.

함께 읽으면 좋은 책
《소프트웨어 아키텍처 101》, 《리팩터링 2판》
위 두 권은 따로 읽어도 좋은 책이지만 함께 읽어보면 시너지 효과가 날 것 같은 묶음이라 메모를 남겨본다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."
리뷰를 위해 한빛미디어에서 책을 제공받았지만 주관적인 생각을 그대로 적었습니다.

hyuns***l2022-10-30

난해하고 중요한 소프트웨어 아키텍처

daso***l2022-10-30

[리뷰] 소프트웨어 아키텍처 The Hard Parts

‘소트프웨어 아키텍처 101’의 후속작이다. 분산 아키텍처를 위한 모던 트레이드오프 분석이라는 문구가 책표지에 있는 만큼 분산 아키텍처에 대한 내용이 많이 나온다. 분산 아키텍처라고 하면 언뜻 어떤 것인지 잘 생각이 나지 않을 수 있지만 쉽게 생각하면 MSA(MicroService Architecture)라고도 할 수 있을 것이다. 나는 MSA를 이야기 할 때 자주 분산환경이라고 생각하면 쉬울 것이라고 말하곤 한다. 분산 환경은 예전부터 존재했지만 트랜잭션 등의 기술을 DB가 아닌 Application에서 처리하기 힘들었으나 그 만큼 필요성과 기술이 늘어가고 있어서 주목을 받는 것이라고 말한다.

개발자라면 시스템을 개발하면서 어떤 방식으로 개발해야하는 지에 대한 고민을 하곤한다. 물론 대부분의 개발자들은 주어진 단위 업무만을 하는 것이 대부분이겠지만, 자신만의 토이 프로젝트라든지 아니면 연차가 올라가서 아키텍처에 대한 고민을 하는 순간이 올 것이다.

이 책을 본다고 바로 적용을 할 수 있는 것은 아니겠지만, 대부분의 사람들이 그렇듯 인터넷 검색을 통해서 수많은 얘제들을 찾아 복사 붙이고 수정을 하고 있을 것이다. 그러기 위해서는 내가 고민하고 있는 부분에 대한 어떤 아키텍처가 맞을 것인지에 대한 용어나 간단한 개념을 있어서 검색하는 데 수월할 것이다. 그런 점에서 이 책에는 많은 아키텍처들이 나와있어서 한번쯤 보고 나중에 내가 필요할 때 다시 찾아볼 수 있게 되는 좋은 책이라고 하겠다.

아키텍트를 꿈꾸는 사람이라면 꼭 봐야할 책이라고 할 수 있다.

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

han***l2022-10-30

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

lowgi***l2022-10-30

소프트웨어 아키텍처 실무편 매운맛보기

blusk***l2022-10-30

아키텍처의 길로 가기 위한 책

khs***l2022-10-30

소프트웨어 아키텍처로의 접근 방법

siv***l2022-10-30

MSA 전환을 고려한다면 읽어야 할 책

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

기존에 읽은 "소프트웨어 아키텍쳐 101"의 후속편 같은 책이네요.

(https://blog.naver.com/siva6/222684162395)

기존 책도 그렇지만, 이 책 역시 '모든게 트레이드오프'이고, '최적은 그때그때 다르다'는 생각은 동일하게 견지하고 있네요.

정답을 알려주는 책이 아닌 것은 동일합니다.

소프트웨어 아키텍처가 정답이 없다고 이야기 합니다.

여러 트레이드 오프 중 최적은 항상 문제마다 다르니까요.

이 책은 전작과 같이 독자가 아키텍처를 문제상황에 맞춰서 잘 결정할 수 있도록 가이드하는 역할을 합니다.

전작이 있다보니 비교할 수 밖에 없는데요.

전작은 여러 알려지 아키텍처를 비교해 주었다면,

이번 책은 MSA로 전환하면서 생길 수 있는 문제점들에 대한 해결 방법과 어떻게 선택을 해야하는지에 대해서 이야기합니다.

예를 들어 설명하다 보니 좀 더 쉽게 접근할 수 있었습니다.

현재 제가 일하는 회사 상황과 겹쳐 보이는 부분도 많았구요.

시스템을 나눠야 할지, 합쳐야 할지 어떤 수준으로 해야 할지, 선택한게 맞는지 많은 고민이 있었는데,

이런 고민을 하고 있어서 그런지 많은 도움이 되었습니다.

다 읽지도 않은 책을 다른 사람에게 추천하지 않는데요.

이 책은 절반정도(파트1) 읽었을 때,

함께 읽어보면 서로의 생각을 조정하는데 도움이 될 것 같아서, 회사 팀원들에게 추천했습니다.

책의 목표가 아키텍처 개별적인 설명이 아닌, 여러 가지 방법 중 어떤 걸 어떻게 선택해야 하는 지 방법을 알려주는 것이기 때문에

나오는 개별 아키텍처나 패턴에 대한 이해가 어렵다는 단점이 있었습니다.

이런건 추가적인 공부가 필요하겠죠.

아마도 많은 회사들이 기존 아키텍처에서 MSA로의 전환을 생각하거나 추진할 텐데요.

좋은 가이드가 될 책이라고 생각됩니다.

whycr***l2022-10-30

소프트웨어 아키텍처, 진짜가 나타났다

진짜가 나타났습니다. 그동안 비슷한 책은 많았는데 훨씬 더 실무적인 측면에서 많은 이야기를 다루고 있는 책입니다. 책 이름이 낯익은 분들도 계실 텐데 맞습니다. 이 책은 소프트웨어 아키텍처 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 자신만의 트레이드오프 분석

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

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

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

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

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

iamdaye***l2022-10-30

[리뷰]소프트웨어 아키텍처 The Hard Parts

[도서 소개]

소프트웨어 아키텍처 문제-해결을 위한 지식과 실용적 프레임워크를 다루는 안내서. 『소프트웨어 아키텍처 101』의 실무편에 해당하는 후속작이다. 분산 아키텍처를 구축할 때 서비스를 나눠야 하는 경우와 합쳐야 하는 경우를 각각 세분도(granularity) 분해인과 통합인이라는 두 가지 관점에서 바라보고, 어떻게 하면 아키텍트가 객관적으로 트레이드오프를 분석해서 올바른 의사 결정을 내릴 수 있는지 이야기한다.

[주요 내용]

- 트레이드오프 분석과 함께 의사 결정을 효과적으로 문서화하기

- 서비스 세분화를 통해 더 나은 결정을 내리는 방법

- 모놀리식(monolithic) 애플리케이션 분리의 복잡도

- 서비스간 계약 관리 및 분리

- 고도로 분산된 아키텍처에서 데이터 처리하기

- 애플리케이션을 분리할 때 워크플로와 트랜잭션을 관리하는 패턴 학습

[서평]

마이크로서비스 아키텍처 구축을 위한 패턴과 분석 기법

소프트웨어 아키텍트에게는 그 어느 하나 쉬운 결정이 없다. 수많은 상충 관계에 맞서 의사 결정을 내리고, 선택해야 하는 '하드 파트'만이 기다리고 있을 뿐이다.

이 책은 분산 아키텍처를 구축할 때, 아키텍트가 트레이드오프를 객관적으로 분석하여 의사 결정을 내리기까지의 모든 과정을 상세히 가이드한다. 하지만 그동안 수없이 많이 다뤄졌던 ‘최고의 솔루션’이나 ‘모범 사례’가 아니라, 각 아키텍처 방법론과 패턴의 장단점을 있는 그대로 담아냈다. 또한 리팩토링을 앞둔 가상 애플리케이션 서비스 팀의 이야기를 따라가며, 그들의 고민과 인사이트, 팁까지 현장감 있게 만나볼 수 있다

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

love***l2022-10-30

분산 아키텍처를 알기 위한 필수 서적

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

아키텍처에 관한 책은 일반적으로 어렵다. 다뤄야 할 범위가 크니 알아야 할 지식도 많지만, 한 권의 책에서 설명할 수 있는 물리적인 한계가 있으니 추상적인 부분을 다뤄야 하는 경우가 대부분이라 기본적인 지식이 없으면 결국 겉핥기식으로 읽고 실제 환경에서는 적용하기 어렵게 되는 경우가 많다.

이 책이라고 해서 읽기 쉽지는 않지만 — 제목부터가 The hard Parts이니 — 다른 아키텍처 서적에 비하면 훨씬 더 구체적이다. 컴포넌트 커플링이 monolithic architecture를 분해하는데 가장 중요한 요인 중 하나이기 때문에 컴포넌트 기반 분해 패턴을 통해 컴포넌트부터 분리하고, 데이터를 나눈 후, microservice로 분해하는 과정을 그림과 말뿐만이 아니라 코드까지 예를 들며 알려준다. 또 분산 아키텍처를 설명한다고 나누는 것에만 집중하는 게 아니라(MSA가 buzzword가 된 후, 새로운 트렌드를 일단 쫓는 경우 분리를 통해 생기는 어려움을 크게 고려하지 않고, 나누는 것만 하고 싶어 하는 개발자들의 이야기를 쉽게 들을 수 있었다) 코드의 재사용성을 고려하는 서비스나 공유 라이브러리의 트레이드오프, 가장 어려운 문제가 되는 분산 트랜잭션, 서비스 간 결합도와 관계되는 느슨한/엄격한 계약 등 놓치기 쉽지만 분산 서비스 구성에 큰 영향을 미치는 나눌지 합칠지 고민해야 할 부분을 챕터별로 배울 수 있다.

구성면에서 살펴보면 매 챕터를 가상의 인물들이 아키텍처 관련 미팅을 하면서 각자의 입장에 따라 주장을 하거나 때로 논쟁을 벌이는 모습으로 시작을 하는데, 이 부분이 아키텍처 관련된 현실적인 문제를 알려주기 위해 저자들이 넣은 장치로 짐작한다. 모든 일이 그렇지만 특히 아키텍처에 대한 부분은 (정답이 아니라) 좋은 답을 찾기 위해 논의를 해야 할 주제가 더 많기 때문에 열린 마음으로 stakeholder들이 이야기를 해야 한다. 하지만 업무에 쫓기는 현실 속에서 이런 태도를 갖는 게 때론 어렵기 때문에 이런 가상의 인물들을 통해 저자들이 이런 문화의 중요성도 전달하려는 의도를 가졌을 거라고 생각한다.

한 번 읽은 걸로는 쉽게 이해하기 어려워 시간을 들여 천천히 다시 읽어볼 생각이다. amazon의 평점이 절대적인 척도가 될 수는 없지만, 많은 사람들이 평가했는데도 4.6점이라면 대부분 이 책의 장점을 인정하는 걸로 보이고 그만큼 읽을만한 가치가 있는 책이란 생각이 든다. 분산 아키텍처라는 거대한 산맥을 조금이나마 더 잘 이해하고 싶다.

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

이 책은 이전에 읽은 <소프트웨어 아키텍처 101>의 후속작으로 분산시스템을 구축할 때 서비스를 나눌지 아니면 합칠지에 대한 의사 결정을 할 수 있는 트레이드오프 분석에 대한 내용이다.

Why hard parts? 라고 했을까?

이렇게 쓴 이유는 어렵기 때문(hard == difficult)이고, 한번 정해지면 단단하게 굳어져 (hard == solid) 바꾸기 힘든 아키텍터의 본질을 나타낸다.

아키텍처에 대한 이야기

- 아키텍처의 모든 것은 트레이트오프이고 구글링 해서는 답을 찾을 수 없다. 따라서 여러가지 아키텍처 구축 방안을 모색하고 각각의 트레이드오프를 분석하는 능력을 길러야 한다.

- 아키텍처의 문제는 snowflake와도 같다. (눈송이는 다 똑같아 보이지만 현미경으로 보면 하나도 똑같은 게 없다고 한다)

- 최고의 설계를 고집하지 마라. 대신에 least worst 한 트레이드오프 조합을 찾아라.

- 아키텍처 본인의 경험도 도움이 되겠지만 가장 강력한 도구는 전체 시스템을 구축해 보지않고도 반복 설계가 가능한 시나리오 분석이다. 즉 여러가지 시나리오를 가정해서 각각의 장단점을 파악하는 것이다.

트레이드오프 분석은 다음의 3단계 분석을 거친다.

1. 어떤 부분이 서로 얽혀있는지 찾는다.

2. 그 부분이 서로 어떻게 결합돼 있는지 분석한다.

3. 상호 의존적인 시스템에 변경을 가하면 어떤 영향이 있을지 파악해 트레이드 오프를 평가한다.

이 책의 흥미로운 진행 방법

한빛가이버 어플리케이션이라는 고객관리 시스템을 예를 들어서 아키텍처를 설명하고 회사의 개발자들이 등장해서 마치 실제 있는 이야기 처럼 스토리 텔링 방식으로 매 챕터를 시작한다.

마지막으로

이 책의 15.2 트레이드오프 기법의 장에서 저자가 경험한 몇가지 유익한 조언을 읽으면 정리가 될 것이다.

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

kianms10***l2022-10-29

\\\'소프트웨어 아키텍처는 나중에 바꾸기 어렵다.\\\'

spac***l2022-10-29

쉽지 않은 아키텍처

이번에 리뷰를 위해서 받은 책은 "소프트웨어 아키텍처(The Hard Parts)" 라는 책으로 기존 "소프트웨어 아키텍처 101"의 심화편이었습니다. 아무래도 심화편이라 그런지 책의 내용이 쉽게 접근할 수 있는 내용이 아니었습니다.

책에서 많이 등장하는 단어중에 트레이드 오프라는 단어가 있는데 개발 용어에 대해서는 많이 익숙지 않다 보니 단어의 뜻을 찾아보니 "신뢰도"라는 의미로 소프트웨어 아키텍처에서의 신뢰도를 향상 시킨다는 의미인 것 같았습니다.

1장에서 이 책의 제목을 Hard Parts 라고 지었는지에 대해서 작성하였습니다. 결과적으로 한번 정한 아키텍처는 쉽게 고칠 수 없기에 이 부분에 대해서 책을 읽는 독자들이 좀 더 아키텍처에 대해서 심도 있게 접근할 수 있도록 하였습니다.

책의 구성을 소설 형식으로 팀내에서 발생할 수 있는 문제에 대해서 등장인물이 있고 각자의 등장인물들의 대화에서 현재의 문제에 대해서 제시하고 그 문제를 풀어가는 방식으로 되어 있습니다.

일반적인 이론서보다는 읽기가 편하지만 책에 나와 있는 것처럼 심화편이기 때문에 한 번만 읽어서는 이해되지 않는 부분들도 있으니 제대로 이해하고 싶으신 분들은 두어 번은 읽어야 하지 않을까 생각이 듭니다.

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

hony7***l2022-10-29

제일 나은 선택을 위한 아키텍처 소개서

sihan***l2022-10-23

나눌것인가 합칠것인

소프트웨어의 아키텍처는 프로젝트의 규모가 커지고 복잡해 질 수록 진가를 발휘하는 것 같습니다. 이번 SK IDC 화재로 카카오의 서비스들이 다운 되었을 때도 여러사람이 지적한 부분이 아키텍처 측면이었습니다. 프로젝트를 진행하다보면 초기에는 빠른 성장을 위해 사소한 것들은 뒤로 잠시 미뤄두고 진행하기도 합니다. 작은 변화는 티가 잘 나지 않는 것처럼 아키텍처의 변화는 각 단계들에서 덧 붙여지는 것은 크게 체감하기 힘듭니다. 하지만 어느 순간 돌아보면 개발 중인 사람조차 이해하기 힘들정도로 엉켜 있는경우가 있습니다.

이 책은 이런 경우 어떻게 접근하고 분해해야 할까를 다루고 있습니다. 무조건 쪼개는 것은 방법이 아닙니다. 오히려 잘못된 분할은 복잡도만 증가시키고 시스템의 안정성을 해치는 이유가 됩니다. 아키텍처를 재정비하고 분할하는 이유는 시스템의 안정도를 높이고 가용성을 높이기 위해서입니다. 그런데 오히려 유연성이 떨어지고 복잡도가 증가한다면 잘 못된 리모델링입니다.

아키텍처 리모델링을 위한 정답은 없습니다. 각 시스템에 맞게 각 단계별로 적절한 방법론을 가지고 손익 계산을 해야합니다. 우리가 고를 선택지에는 최고의 선택지는 없습니다. 우리는 차악의 선택지를 고를 뿐입니다. 7가지의 옵션 중에 모든 옵션이 좋은 선택지는 우리 앞에 쉬이 나타나지 않습니다. 그런 깔끔한 케이스는 교과서에서나 볼 법한 이야기입니다. 그래서 우리는 각 선택지의 트레이드 오프를 따져가면서 적용할 방법을 선택해야합니다.

트레이드 오프 계산을 통해 남은 선택지들 중 차악의 선택지를 선택하며 아키텍쳐의 리모델링을 진행합니다. 지우고, 분리하고 때로는 다시 합치면서 리모델일 진행합니다. 가용성 등의 문제를 겪고 있거나 프로젝트가 안정화되서 구조적인 문제를 손봐야겠다고 생각은 하고 있지만, 시작점을 못 잡고 계셨다면 좋은 출발점입니다.

한빛미디어 2022 도서 서평단 "나는 리뷰어다"의 일원으로 도서를 제공받아 작성한 리뷰입니다.

anonymousl2022-10-23

소프트웨어 아키텍처 The Hard Parts : 분산 아키텍처를 위한 모던 트레이드오프 분석 리뷰

1b***l2022-10-15

[소프트웨어 아키텍처_The Hard Parts] 소프트웨어 아키텍처 효율성을 구축하기 위해 고민하는 사람들을 위한 책

이 책은 '22년 10월 1일 발행한 책으로 현재 초판 1쇄 발행본이다. 소프트웨어 아키텍처가 중요한 이유로는 프로그램을 사용하다 보면 새로운 기능을 추가하기도 해야 하는데 이러한 아키텍처가 제대로 구축되어 있지 않다면 경제성이나 비용측면에서 효율성이 떨어지는 작업 환경으로 리팩터링에서 큰 프로젝트가 발생하는 등의 문제가 발생할 수도 있기 때문이다.

책은 4인 공저로,

저자 닐포드는 소프트웨어 회사인 쏘우트웍스(Thoughtworks)의 이사로 소프트웨어 아키텍터, 밈 랭글러(meme wrangler; 여러 사람들의 아이디어를 정리하는 역할을 하는 사람)인데 애자일 엔지니어링과 소프트웨어 아키텍트가 결합된 분야를 전문으로 하고 있습니다.

마크 리처즈는 1983년부터 소프트웨어 개발자로 활동하고 있으며 마이크로서비스 아키텍처 분야를 전문으로 하고 있으며 수많은 책과 동영상 제작과 컨퍼런스 연설자로 강연등 다양한 활동을 하고 있습니다.

프라모드 세달리지는 씽크웍스(Thinkworks)의 데이터/ 데브옵스 부문 이사로 데이터 베이스등이 전문 분야입니다.

세막 데그하니는 쏘우트웍스의 신기술 부문이사로 소프트웨어 엔지니어 입니다.

저자들의 약력에서 살펴볼 수 있듯 본 책 내용은 뜬 구름 잡는 내용이 아닌 실제 회사에서 많이 사용하는 예제와 실제 코드를 적용하여 실무자에게 많은 도움이 되어 보인다.

본문 480페이지 가량의 분량으로 보이며 책상앞에 두어도 큰 부담이 되지는 않고 총 15장으로 구성되어 있다.

책 내용은 전체적으로 3파트로 나뉘어 있으며 제1파트는 개론으로 베스트 프랙티스등에 대해 언급하며, 제2파트는 따로 떼어놓기라는 타이틀로 2~7장, 제3파트는 다시 합치기라는 제목으로 8~15장으로 구성되어 있는데 그 내용을 간단히 살펴보면

1장은 베스트 프랙티스와 관련한 이아기를 시작으로를 소개하고 있으며 아키텍처에서 데이터 중요성, 데이터 정의의 명료성에 대해 설명하고 있다.

2장은 아키텍처 퀀텀을 소개하며 독립적 배포성, 기능 응집도, 커플링, 동적 퀀텀 커를링을 다루고 있다.

3장은 아키텍처를 조각으로 나누어 살펴보는 모듈성에 대해 알아보고 있으며 모듈화 동인의 요소인 유지보수성, 시험성, 배포성, 확장성, 가용성/내고장성등에 대하 언급하고 있다.

4장은 아키텍처 분해를 이야기 하며 코드베이스의 분해가능성, 구심/원심 커플링, 추상도와 불안정도, 컴포넌트 기반분해, 전술적 분기등을 등을 설명하고 있다.

5장은 본격적으로 컴포넌트 분해 기반 패턴을 보여주고 있는데 컴포넌트 식별 및 사이징 패턴, 공통 도메인 컴포넌트 수집패턴, 눌러 펴기패턴, 디펜던시 결정 패턴, 도메인 생성패턴, 서비스 생성 패턴등을 다루고 있다.

6장은 앞에서도 언급한 데이터의 중요성을 설명하는 장으로 데이터 분해인, 모놀리식 데이터분해, 타입선택 등을 다루고 있다.

7장은 서비스 세분도를 소개하며 서비스 분해인, 세분도 통합인, 적정 균형점 등을 언급하고 있으며 장 말미에 티켓 배정 세분도, 고객 등록 세분도에 대해 추가로 설명하고 있다.

8장은 파트2 '다시합치기'의 시작이 되는 장으로 재사용 패턴을 설명하며 코드복제, 공유 라이브러리, 공유 서비스, 사이드카와 서비스 메시 등을 언급하고 있다.

9장은 데이터 오너십과 분산 트랜잭션에 관한 내용으로 오너십에 대한 전반적인 내용과 최종 일관성 패턴을 보여주고 있다.

10장은 분산 데이터 액세스를 다루고 있으며 서비스 간 통신패턴, 컬럼 스키마 복제 패턴, 복제 캐싱 패턴, 데이터 도메인 패턴 등을 다루고 있다.

11장은 분산 워크플로 관리를 보여주며 오케스트레이션, 코레오그래피 통신 스타일 및 양자간의 트레이드 오프 등을 다루고 있다.

12장은 트랜잭셔널 사가를 소개하며 다양한 트랜잭셔널 사가 패턴을 보여구조 상태관리와 일관성, 사가 관리 기법을 보여준다.

13장은 계약을 보여주고 있으며 엄격한 계약, 느슨한 계약을 비교해 설명하며 스탬프 커플링에 대해서도 설명한다.

14장은 분석 데이터 관리를 설명하며 예전 접근방법, 데이터 메시에 대해 이야기 하고 있다.

15장은 마지막 장으로 자신만의 트레이드오프 분석을 주제로 다루며 서로 연관된 차원 확인, 다양한 트레이드 오프 기법등을 다루며 간단한 에필로그를 끝으로 책 내용을 마무리 하고 있다.

전체적인 총평은 난이도는 중급으로 보이며 기본적으로 한빛가이버 사가라는 절이 삽입되어 추상적인 내용을 구체적으로 이해하도록 잘 구성되어있으며 기본적으로 프로그래밍언어, 데이터베이스, 자료구조, 알고리즘, 소프트웨어 리팩터링 등에 대한 이해가 선행되어야 할 것으로 보이며 소프트웨어 프로그래밍을 위한 기본적인 회사 업무 플로우/시스템에 대한 기초적인 내용도 본 책을 읽기전 미리 학습되어 있으면 본 책을 한장 한장 따라가며 학습하는데 도움이 될 것으로 사료된다.

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

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

들어가며

이 책이 말하는 것

- 대상독자

- 책의 내용 및 구성

- 책에서 눈에 띄는 점

- 총평

책소개

다양한 패턴과 사례, 그리고 연습

친숙한 대화형 설명, 양날의 검(?)

결론

이 책의 매력은?

마치면서

마이크로서비스 시대

(중략)

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

이 책은 이전에 읽은 <소프트웨어 아키텍처 101>의 후속작으로 분산시스템을 구축할 때 서비스를 나눌지 아니면 합칠지에 대한 의사 결정을 할 수 있는 트레이드오프 분석에 대한 내용이다.

Why hard parts? 라고 했을까?

이렇게 쓴 이유는 어렵기 때문(hard == difficult)이고, 한번 정해지면 단단하게 굳어져 (hard == solid) 바꾸기 힘든 아키텍터의 본질을 나타낸다.

아키텍처에 대한 이야기

- 아키텍처의 모든 것은 트레이트오프이고 구글링 해서는 답을 찾을 수 없다. 따라서 여러가지 아키텍처 구축 방안을 모색하고 각각의 트레이드오프를 분석하는 능력을 길러야 한다.

- 아키텍처의 문제는 snowflake와도 같다. (눈송이는 다 똑같아 보이지만 현미경으로 보면 하나도 똑같은 게 없다고 한다)

- 최고의 설계를 고집하지 마라. 대신에 least worst 한 트레이드오프 조합을 찾아라.

- 아키텍처 본인의 경험도 도움이 되겠지만 가장 강력한 도구는 전체 시스템을 구축해 보지않고도 반복 설계가 가능한 시나리오 분석이다. 즉 여러가지 시나리오를 가정해서 각각의 장단점을 파악하는 것이다.

트레이드오프 분석은 다음의 3단계 분석을 거친다.

1. 어떤 부분이 서로 얽혀있는지 찾는다.

2. 그 부분이 서로 어떻게 결합돼 있는지 분석한다.

3. 상호 의존적인 시스템에 변경을 가하면 어떤 영향이 있을지 파악해 트레이드 오프를 평가한다.

이 책의 흥미로운 진행 방법

한빛가이버 어플리케이션이라는 고객관리 시스템을 예를 들어서 아키텍처를 설명하고 회사의 개발자들이 등장해서 마치 실제 있는 이야기 처럼 스토리 텔링 방식으로 매 챕터를 시작한다.

마지막으로

이 책의 15.2 트레이드오프 기법의 장에서 저자가 경험한 몇가지 유익한 조언을 읽으면 정리가 될 것이다.

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