소프트웨어 아키텍처 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의 아키텍처를 잘 분해해서 재사용성을 높이는 한편, 현재 여러 장애의 원인이기도 한 유지보수성, 시험/배포의 용이함 같은 내용들을 잘 이해해보려했는데 아직 제 내공이 부족한지 이해도가 낮다는 느낌을 받았습니다.

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

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

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

joengg***l2023-03-27

분산아키텍쳐 끝판왕

호기심으로 읽어보기 시작한 이 책은 생각한거보다 더 섬세하게 아키텍쳐를 다룬다.

이 책의 한 챕터당 전개는 등장인물이 등장해 어떤 문제에 대해서 실제 일어날법한 대화를 합니다. 그 대화를 잘 읽다보면, 현업에서도 언급될 수 있는 부분입니다.

특히 흥미로웠던 것은 대부분의 회사가 겪을 수 있는, 모놀리틱 시스템에서 > 마이크로 서비스 시스템으로 점진적으로 전환을 시작하는 과정에서 발생할 수 있는 문제에 대해서다. 회사에서는 마이크로서비스로 전향한다고 해서 돈이 생기는게 아니다보니 더 고민이 될 수 밖에 없는 문제이다. 이 문제도 이 책에서 다룬다. 개발책임에도 불구하고.

이런 내용이 이 책을 더 매력적으로 느껴지게 하는게 아닐까? 분산 아키텍쳐에서 일어날 수 있는 많은 일들을 이야기하고있다.

그러나, 이 책에서 사용되는 용어는 우리가 보편적으로 많이 알려진 용어가 아니다. 그러다보니, 이 책을 읽는데 있어서 용어에 대한 거부감이 점점 커지는 것이 있다. 아니면 번역하는 과정에서 한글 단어로 번역되면서 이상해진 것 일수도 있다.

그럼에도 불구하고, 사가 패턴이라던가 마이크로서비스의 크기라던가 이런 고민을 해본 사람이라면 이 책을 추천하고 싶다.

tkxkd0***l2023-03-27

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

오랜만에 책 리뷰가 기다려지는 도서가 선정되었다. 백엔드 개발자로써 일하고 있기 때문에 항상 확장성 있으면서도 견고하게 잘 짜여신 시스템 구조에 대해서 스스로 고민하고 점차적으로 개선하는 것에 관심이 많은 편이다. 책의 읽기 시작한 후 서두에 나오는 최고의 설계를 고집하지 말고 제일 나은 트레이드 오프 조합을 찾으라는 말부터 뇌리에 강렬하게 박혔다. 항상 이 구조로 서버 구조를 짜면 나중에 트래픽이 증가해도 문제가 없을지, 이 구조가 정말 최선인지 고민하게 되는 순간이 오는 것 같다. 특히 나의 경우 스프링으로 대표되는 범용적인 템플릿 스타일의 웹서버 구조가 아닌 Go나 Rust같은 시스템 언어를 기반으로 좀 더 로우레벨의 시스템들을 다루기 때문에 구글링해서도 딱 떨어지는 정답을 찾기가 정말 어려웠었다. 특히, MSA 구조에서 데이터 오너십이나 액세스, 로직 플로우 등을 어떻게 가장 효율적으로 가져갈 수 있을지에 대한 고민을 최근에 많이 하였는데 이번에 책을 리뷰하면서 9~12 단원에서 관련하여 유용한 정보를 많이 얻을 수 있었다. 백엔드 개발자라면 언제가는 한번쯤 꼭 읽어야 되는 도서라고 생각하며 리뷰를 마친다.

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

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

소프트웨어 아키텍처 서평

프로젝트에서 PM의 역할은 광범위한 범위에 걸쳐져 있다. 그중에서도 전체 시스템을 관망할 수 있는 아키텍트의 역할이 가장 크지 않을까 싶다. 어떻게 하면 좋은 아키텍트가 될 수 있을까 고민해보곤 했다. 시스템적인 차원에서 개발을 공부하는 것이 큰 도움이 될 것처럼 느껴지기도 했다. 주위에 조언을 구한 결과, 단순히 개발을 공부하는 것만이 답이 되지 않는다는 것을 쉽게 알 수 있었다. 그렇다면 어떻게 아키텍처를 공부할 수 있을까.

책 소프트웨어 아키텍처는 수십년 간의 아키텍트 경력이 있는 저자들이 모여 자신의 지식과 경험을 토대로 글을 썼다. 목차를 살펴보면 패턴별로 설명이 되어있음을 확인할 수 있다. The Hard Parts 이전의 조금 더 쉬운 버전의 책도 있어 너무 어렵진 않을까하고 우려스러웠다. 하지만 생각보다도 개념이 친절하게 설명되어 있고 예시와 그림을 사용하여 쉽게 이해할 수 있었다. 아주 뛰어난 아키텍트가 아니더라도 평소 SW 트렌드와 시스템 용어를 자주 접해보았던 이라면 흥미롭게 책을 읽을 수 있을 것이다.

하지만 피트니스 함수는 대부분 코드 형태입니다! 빌드된 프로젝트를 상대로 언제든지 검증할 수 있는, 아키텍처의 실행 가능한 명세를 구축함으로써 아키텍트는 시스템을 이해하고 그것이 잘 발전되고 있는지 지켜볼 수 있습니다. 이는 점점 늘어나는 프로젝트 코드의 흐름을 계속 따라가야 하는 아키텍트의 핵심 목표와 부합합니다.

40쪽, 소프트웨어 아키텍처.

요즘 대표적인 사상으로 꼽히는 MSA가 책의 주요한 근간을 자리하고 있다. 거의 모든 아키텍처가 MSA 기반이라 분산 시스템에 대해 많은 설명을 하고 있다. 아키텍처 퀀텀이란 높은 기능 응집도, 높은 정적 커플링, 동기적 동적 커플링의 특성을 띤, 독립적으로 배포 가능한 아티팩트라고 한다. 양자 컴퓨팅으로만 익숙했던 단어인 Quantum을 아키텍트 트렌드를 상징하는 단어로 쓰인 다는 것 또한 깨닫게 되었다.

아키텍트는 장기적인 영향도가 있는 의사 결정을 할 때 그 기준 자체를 변경해야 할 새로운 기능이 최근에 등장하지 않았는지 계속 확인해야 합니다. 즉, 의미 있는 탐구를 하려면 비교 기준이 전체 포괄적이어야 합니다.

467쪽, 소프트웨어 아키텍처.

최적화된 아키텍처를 위한 아키텍트 간의 대화를 생생하게 풀어내기도 했다. 덕분에 현업들의 생각을 헤아려볼 수 있었고, 신선하기도 해서 기억에 오래 남을 것 같다. Kafka와 ESB, 커플링과 디커플링 등 다양한 주제에 대해 논한다. 흔히 MSA 기반이라면 잘개 쪼개는 것을 능사로 여기곤 한다. 하지만 무조건 쪼갰을 경우 오케스트레이션과 트랜잭션, 비동기성의 문제가 발생할 수 있다고 한다. 어떤 시스템에도 최적화가 될 수 있는 아키텍처는 없다는 것, 트레이드 오프 분석이 아키텍처의 가장 큰 부분이라는 것을 명심하는 것만으로도 충분한 교훈이라 생각한다. 나를 포함하여 아키텍트를 꿈꾸는 이들에게 이 책을 읽으며 실무를 미리 경험해볼 것을 추천하고 싶다.

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

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로 기록한다.

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

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

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

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

읽어주셔서 감사합니다.

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

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

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

krispedi***l2023-03-26

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

최근 업무에서 모놀리식 시스템으로 고통받던 중 이 책을 읽었고 시스템을 분해하는 방법에 대해 많은 도움을 받았다.

이 책의 내용은 크게 시스템을 분해하는 방법에 관한 part1 따로 떼어놓기와 분해된 시스템을 하나의 단위로 합치는 방법에 관한 part2 다시 합치기로 구성되어있다. 분산 아키텍쳐 구성을 위해 아키텍트로서 고려해야하는 사항에 대한 개념뿐만 아니라 한빛가이버 사가에서 구체적인 상황에 대한 적절한 전략 선택에 대한 인사이트를 얻을 수 있었다.

분산 아키텍처, 마이크로서비스 그리고 클라우드 등이 트렌드인 현재 기존의 시스템에서 어떤 과정을 거쳐 분산시스템으로 재구성할 수 있을지에 대해 구체적인 방안을 알려주는 좋은 안내서라 생각한다.

다만, 『소프트웨어 아키텍처 101』의 심화 편인 만큼 개인적으로는 『소프트웨어 아키텍처 101』을 먼저 읽고 용어 및 개념에 친숙해진 후 이 도서를 읽는 것을 추천한다.

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

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까지 남길 수 있게 한다면 책을 넘어서 더 생생한 가치를 제공할 수 있지 않을까?

[총평]

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

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

[추천 대상]

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

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

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

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

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

kimin5***l2023-03-26

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

분산 아키텍처를 구축할 때 서비스를 나눌 때와 합칠 때는 각각 언제인지, 어떤 점을 고려해서 수행해야 하는지를 다루고 있다.

각 챕터는 실무자들이 기존 아키텍처의 문제점을 찾아서 무엇이 문제인지, 어떻게 개선할 수 있을지 대화하는 것으로 시작된다. 그 다음에 해당 내용에 대해 도표 등 여러가지 자료와 함께 자세히 설명하고 챕터 끝에서는 각 챕터의 내용을 대화 형식으로 정리하는 형식으로 되어 있다. 아키텍처에는 정답이 없고 모든 것은 트레이드 오프라는 점을 계속 말하면서 상황별로 어떤 방식이 더 적합한지에 대해서 설명해준다.

실무자들의 대화가 들어가는 형식의 다른 책(자바 성능을 결정짓는 코딩 습관과 튜닝 이야기)도 그렇고 이런 형식의 책은 개인적으로 뭔가 현장감이 느껴져서 좀 더 몰입하게 된다.

그리고 책 내용 중에 101 책을 참고하는 부분이 종종 나온다. 소프트웨어 아키텍처 101(이하 101로 줄인다)의 후속작으로 나온 책이다보니 이미 101을 읽었다는 전제 하에 진행되는 이야기들이 많다. 만약에 101을 아직 안읽은 사람이라면 먼저 101 책을 한번 빠르게 읽고 이 책을 보면 좀 더 도움이 될 것 같다.

gdtbg***l2023-03-26

아키텍처 변경을 고민하는 분들을 위한 최고의 책

들어가며

소프트웨어의 세계에서 변화는 필연적이다. 어떤 천재가 나타나도 기막힌 코드를 작성하더라도, 코드가 살아가는 세계의 변화에 따라 언젠가는 변경이 일어날 수 밖에 없다. 그 변경 중에서도 쉽게 변경할 수 있는 부분과 어렵게 변경할 수 있는 부분이 있다. 특히 아키텍처는 가장 변경하기 어려운 부분 중 하나이다.

물 위에서 뗏목을 만들고 침몰되지 않도록 발버둥 치며 결국 거대한 함선으로 진화시켜 나가야 하는 숙명을 가진 소프트웨어 개발에서, 아키텍처의 변경은 배의 구조를 바꾸는 것 같다. 배의 외관을 조금 바꿨다고 침몰하지는 않지만, 아키텍처를 잘못 바꾸면 배는 즉시 침몰한다. 이 책은 그 힘든 소프트웨어의 추상적 아키텍처의 변경을 다룬다. 흥미가 좀 생기는가?

이 책이 말하는 것

이 책은 여러가지 소프트웨어 아키텍처를 보여준다. 그리고 어떤 아키텍처가 현 소프트웨어에 적합한지 평가할 수 있는 방법을 알려준다. 이 책에서 중요하게 말하는 것은 바로 트레이드 오프(trade-off)다. 무작정 좋은 아키텍처는 존재하지 않으며, 모든 아키텍처는 장단점을 가지고 있고 나의 상황에 적절한 것을 고르는 것이다.

yee0***l2023-03-26

The Hard Parts 리뷰

"소프트웨어 아키텍처 101"의 후속작으로 MSA 아키텍처를 위한 모놀로식 아키텍처의 서비스를 시나리오를 들어 문제점을 분석하고 MSA 아키텍처의 소개와 설계상 어떤 특징을 가지는지 실제 시나리오를 통해 설명하고 있습니다.

이 책에서 마음에 들었던 점은 다양한 개념을 설명하기 위해 실제 사례를 많이 사용한다는 것입니다. 저자는 또한 레거시 시스템을 처리하는 방법 및 기술 부채를 관리하는 방법과 같은 소프트웨어 아키텍처의 일반적인 문제에 접근하는 방법에 대한 실용적인 조언도 포함합니다. 이런 과정을 통해 아키텍처를 완성해 나가는지 이해하고 학습할 수 있습니다. 이런 간접적인 경험은 신선하고 좋은 경험이었습니다.

전반적으로 "소프트웨어 아키텍처 The Hard Parts"는 소프트웨어 아키텍처에 대해 자세히 알아보고자 하는 모든 사람을 위한 훌륭한 책입니다. 주제에 대한 명확하고 실용적인 소개를 제공하며 이해하기 쉬운 방식으로 작성되었습니다. 챕터 단위로 잘 나뉘어 있어 단계별로 접근하면 좋을 것 같습니다.

추가로 "소프트웨어 아키텍처 101"을 꼭 먼저 읽을 필요는 없다고 느꼈습니다. "소프트웨어 아키텍처 The Hard Parts" 먼저 보고 실습 후 "소프트웨어 아키텍처 101"을 보며 개념을 익히고 한 번 더 "소프트웨어 아키텍처 The Hard Parts"를 보며 실습하면 좋을 것 같다고 생각합니다.

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

per***l2023-03-26

소프트웨어 아키텍처 기술을 향상시키고 싶다면 이 책을 강력히 추천한다.

이 책은 소프트웨어 아키텍처 설계 및 구현에 대한 포괄적인 가이드!

소프트웨어 아키텍처에 대한 더 깊은 이해를 얻고자하는, 소프트웨어 아키텍처 설계 및 구현과 관련된 어려운 문제에 직면한 소프트웨어 설계자에게 매우 유용!

특히 좋았던 점은 어려운 결정에 직면하는 다양한 시나리오를 설명하기 위해 저자가 가상의 회사를 어떻게 사용했는지 예시를 들어주는 점이다.

이러한 가상의 사례들을 통해 독자들은 소프트웨어 아키텍처 개념이 실제로 어떻게 적용되는지 이해하는것에 도움을 주고, 이를 통해 내 상황에 개념을 적용할 수 있도록 충분히 이해할 수 있게 된다.

jrcfore***l2023-03-26

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

신규 소프트웨어 아키텍처를 막 적용하려 하는, 혹은 시작하려 하는 개발 팀에게 추천드리는 도서입니다.

이번에 출간된 책은, fundamentals of software architecture에 이어 출간된 아키텍처 설계 관련 심화 도서라고 생각하면 될듯싶다.

이 책이 기존의 책과 다른 점은 기존의 책들은 신규 기능이나, 최신 기술을 열거하며 설명하는 것이 주목적이 있었다면, 이 책은 그런 기술들을 이용하여 실제 있을 법한 일을 예시로 들어가며 최신의 확장과 효율 그리고 응집과 의존을 제거한 훌륭한 소프트웨어 아키텍처를 설계하는 방법에 대해서 정리했다는 점이다.

무엇보다 이 책을 읽으며 상당히 와닿았다는 점은 회사에서 있을 법한 일을 "한빛 가이버 사가"라는 가상의 프로젝트를 통해 독자에게 친숙하게 다가가려 시도했다는 점이다. 또한 가상의 (실존할지도 모르지만?) 개발자들이 서로의 의견을 주고받으며 소통하는 과정이 꽤나 실무의 모습과 그 궤를 비슷이 하고 있었다.

특히, 실무에 투입되면 경험할 법한 이사진들과 개발자들 간의 생각 차이, 관점의 차이 등을 아주 잘 묘사했다는 점에서 박수를 보내고 싶다.

【책의 구성】 "소프트웨어 아키텍처 The hard parts"의 구성은?

이 책은 크게 두 개의 파트로 구성되어 있다.

1파트에서는 "따로 떼어놓기"라는 주제로 모놀리틱하게 설계된 서비스를 보다 확장 가능하며 응집도를 잘 갖춘 형태로 서비스 아키텍처를 기획하고 구성하며 나아가 피트니스 코드 등을 통해 자동화 검증하는 과정에 대한 지식을 제공한다.

2 파트에서는 "다시 합치기"라는 제주로 분산 데이터 액세스와 분산 워크플로 관리와 같은 보다 심화된 내용에 대해서 설계 및 검증하는 과정에 대해서 정리하고 있다.

본 리뷰는 1파트의 내용을 주로 하여 리뷰하였으며, 2파트의 내용은 직접 독자분들이 읽어보시길 권장한다. (참고로 내용이 상당히 좋다.)

【 소프트웨어 아키텍처 The hard parts 읽고 나서 】

이 책은 상당히 매력적인 책이다. 특히나 각 챕터 중간중간에 "한빛 가이버 사가"라는 가상의 프로젝트를 진행하며 가상의 개발자 그룹이 대화하는 부분이 있는데, 이 부분은 정말 실무에서나 겪을 법한 일을 그대로 옮겨두었다고 해도 과언이 아닐 정도로 묘사의 퀄리티가 상당히 좋았다.

또한 아키텍처를 설계해야 할 때. 가져야 할 철학과 배경지식, 나아가 유지 보수에서 필요한 비용 관점까지 깔끔히 정리해 줬다는 점에서 몹시 만족스러웠다.

이제는 시대가 많이 변해서 main function에 10만 줄씩 코드를 넣는? 스타일의 코딩과 단일 머신을 스케일 업하는 스타일의 서비스 개발을 지향하는 시대는 아니다.

그렇기에 컨테이너 기반의 scale-out을 할 줄 아는 능력과 이때 각 서비스를 이루는 컴포넌트를 적당한 응집도로 설계할 줄 아는 능력. 마지막으로 모든 컴포넌트들이 적당한 동적 커플링과 정적 커플링을 가질 수 있게 하는 아키텍처를 구성할 줄 아는 능력이 각광받는 시대라 평하고 싶다.

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

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>도 구매하여 함께 읽을 생각이다.

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

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

jooh21***l2023-03-26

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

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

아키텍처 설계를 진행하면서 가장 어려웠던 부분이 경우의 수가 너무 많아 무엇을 우리 프로젝트에 적용시키는게 좋을지 선택하는 것이었다.

모놀리식도 이렇게 경우의 수가 많아서 어려웠는데 분산 아키텍처는 더 얼마나 어려울까..

책은 실생활에서 겪을 수 있는 논쟁과 각자의 입장을 예시로 보여 준다.

그런 다양한 논쟁과 관련된 다양한 패턴과 사례를 제시하여 가장 좋은 트레이드오프를 알려준다.

이 책은 초보자를 위한 책은 아닌 것 같다.

첫 번째 읽으면서 머릿속에 물음표가 가득 찬 책이었다.

책 내용이 좋아 한 글자도 놓치고 싶지 않은데..

전 작이 있다고 하는데 그걸 읽고 이 책을 다시 읽으면 좀 더 좋을 것 같다.

mapos***l2023-03-26

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

책에서는 한빛가이버라는 가상의 회사에서 벌어지는

아키텍쳐 변화 사건을 사례로 설명하면서 이야기를 풀어 나갑니다.

개발팀 리더를 담당하고 있는 저로써는

한빛가이버의 노건우 팀장과 같은 식견이 있었으면 하는

생각을 하면서 흥미롭게 책을 읽어 나갔습니다.

내용이 이해가 쉽지는 않았지만 아키텍쳐를 분해하는 과정에서

컴포넌트 기반 분해, 운영 데이터를 분리 하고

다시 재사용패턴을 확인하면서 합치는 부분은 단계적으로 이해가 되면서

분산 아키텍쳐에 대한 폭 넓은 이해를 가지게 됩니다.

책 이름이 왜 Hard 파트일지 궁금했는데

책에 좋은 설명이 나옵니다.

한번 잘못된 결정을 내리면 단단하게 굳어져 다시 뜯어내고 고치는 것조차 어려운

아키텍쳐의 본질을 제목에 담고 있다고 합니다.

과거 모니터링 시스템 아키텍쳐를 담당했을때

잘못된 결정으로 서비스 종료 시 까지 엄청난 고생을 했던 기억이 나면서

이 책이 그 실무 담당자 시렂에 나왔더라면 더 좋앗을 텐데 하는 생각을 하면서

이 책의 선행 버전인 소프트웨어 아키텍쳐 101 이란 책도 같이 궁금해 졌습니다.

또한 최상의 아키텍쳐가 존재하는 것이 아니라

상황에 따라 최적화된 아키텍쳐를 위해서 소프트웨어 아키텍쳐의 다양한 트레이드오프를

이해하고 분석하는 방법을 제시하는 부분이 좋았던것 같습니다

기존 레거시 시스템의 모놀리식 아키텍쳐에서 마이크로 서비스 아키텍쳐로

전환을 생각하는 담당자라면 이책을 읽고

단계적으로 전환을 진행해 가면 좋을것 같습니다.

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

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

다양한 프로그램의 개발과 빠른 진화로 인해서

우리는 더욱 편리한 삶을 살고 있습니다.

하지만, 프로그램이 사용자에게 편리해지고, 다양한 기능이 추가됨에 따라

그만큼 규모도 커지고, 복잡도도 높아지게 됩니다.

따라서 요즘 많은 IT 회사에서는 대규모 소프트웨어의

복잡성 문제를 해결하고 높은 품질의 소프트웨어를

생산하는 데에 많은 관심을 쏟고 있습니다.

전체 시스템의 구조를 생각하며

시스템을 조화롭게 설계하는

아키텍트라면 누구나 들어봤을 법한

『소프트웨어 아키텍처 101』의 후속작

『소프트웨어 아키텍처 The Hard Parts』를 읽어보았습니다.

왜 'The Hard Parts'일까요?

첫 번째 이유로는 어려움, 두 번째 이유로는 단단함을 들고 있습니다.

소프트웨어의 특성상 한 번 정해진 아키텍처는 추후 바꾸기가 굉장히 어렵기 때문입니다.

101에서 아키텍처에 대한 감을 잡았다면,

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] 리뷰

이 책은 "소프트웨어 아키텍처 101"의 실무급 후속작이라고 한다.

http://www.yes24.com/Product/Goods/104491433

소프트웨어 아키텍처 101 - YES24

막막했던 아키텍처가 쉬워지는 실무 지침서소프트웨어 아키텍트는 전 세계 연봉 10위 안에 드는 직업이지만, 지금까지 ‘개발자가 아키텍트’로 전향하는 데 실질적으로 도움이 될 만한 지침이

www.yes24.com

사실 난 해당 책을 먼저 선행으로 보지 못했지만 읽어보고 싶긴 했다. 그만큼 해당 책이 좀 더 난이도까진 아닌데, 순차적으로 읽어보면 좋을 듯싶다.

책에서 많이 쓰는 단어로 '트레이드오프 분석'이라는 단어를 쓰는데 해당 뜻은

트레이드오프(trade-off, tradeoff) 또는 상충 관계는 다른 측면에서 이득을 얻으면서 집합 또는 디자인의 품질, 양, 속성을 없애거나 잃어버리는 일이 수반되는 상황적 결정이다. 즉, 하나가 증가하면 다른 하나는 무조건 감소한다는 것을 뜻한다. 트레이드오프는 예를 들어 단순 물리학을 포함하여, 예를 들면 특정한 양의 물체가 주어진 공간에 맞을 수 있기 때문에 무언가를 추가로 받아들이려면 전체 용기에서 일부 물건을 제해야 한다는 등 수많은 기원의 제한에서 비롯된다.
출처 : https://ko.wikipedia.org/wiki/%ED%8A%B8%EB%A0%88%EC%9D%B4%EB%93%9C%EC%98%A4%ED%94%84

라고 하는데, 개발에서 트레이드 오프란 2가지로 생각되는데 한 가지는 개발과정에서 이루어지는 개발 비용적인 측면으로 예를 들어 개발시간을 늘려서 품질이 올라갈 수도 있겠지만, 그만큼 개발비용이 올라가기도 하며, 개발시간을 줄이기 위해 제품 완성도를 조금이라도 줄여 개발비용을 줄여진다라던가

두 번째로 이런 개발비용 말고도, 어떤 아키텍처를 구성하는 데에 있어서 예를 들면, 어떤 기능을 사용하면 품질이 올라가지만 메모리는 많이 잡아먹지만, 반대로 어떤 기능을 사용하지 않으면 품질이 떨어지고 메모리 사용량이 줄어드는 점에 있어서 절충과정을 잘 선택해야 하겠다.

"나쁜 것 중에서 제일 나은(least worst) 트레이드오프 조합을 찾으세요"라고 말해주고 있다.

이 책의 특이 한 점(?) 가상의 한빛전자라는 회사에서 가상의 회사원들이 일상적인 대화를 하며 기술 토크를 자연스럽게 하며 해당 파트에 대한 주제를 이어서 얘기해주고 있다.

이 책이 왜 하드파트라는 부제를 붙였는가에 대한 대답을 해주고 있다.

나는 솔직히 선행 책인 "소프트웨어 아키텍처 101"을 읽지 않아서 해당 책을 자세히 읽어보진 못했다.

소프트웨어 아키텍처에 관심이 있다면 이전 버전인 소프트웨어 아키텍처 101을 선행으로 읽고 다음으로 읽으면 좋을 것 같다.

http://www.yes24.com/Product/Goods/104491433

소프트웨어 아키텍처 101 - YES24

막막했던 아키텍처가 쉬워지는 실무 지침서소프트웨어 아키텍트는 전 세계 연봉 10위 안에 드는 직업이지만, 지금까지 ‘개발자가 아키텍트’로 전향하는 데 실질적으로 도움이 될 만한 지침이

www.yes24.com

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

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

한빛 출판사의 " 소프트웨어 아키텍처 The Hard Parts” 를 소개합니다.

이전에 "소프트웨어 아키텍처 101"를 접했을떄도 내용이 쉽지는 않았다. "소프트웨어아키텍처 The Hard Parts"는 표지에 나와 있듯이 소프트웨어 아키텍처 101의 심화편에 해당하는 내용이기에 더욱 그러했다. 웹 플랫폼 업무로직무 전환이 오래되지 않아서 아직 SA에 대한 생각조차 하지 못했는데,우연히 접하게 된 본 도서에서 소프트웨어 아키텍트를 전혀 고려하지 않고 있다는 자아 비판과 함께, SA전문가 레벨을 꿈을 꾼다면 설계에 대한 깊은 통찰력을 가져야 한다는 목표 의식을 가지게 될 줄이야…

MSA 아키텍처를 기존Monolithic에 비해 많은 이점을 가지고 있는데, 무엇이 문제인지… MSA 아키텍처의 문제점들, 가령,복잡도나 트랜적션 문제, …등의 원인으로 구성이 쉽지 않기에 서비스를 설계할 때 많은 고찰이필요합니다. 도서에서는 실무에서 접할 수 있는 예를 들어 서비스나 DB구성 등을 예시로 설명하고 있습니다.

MSA 설계를 위해서 도서에서는 다양한 패턴들을 설명하고 있습니다. 컴포넌트 도메인 생성 패턴이나 도메인 서비스 생성 패턴, …등 MSA 서비스를 어떻게 분해하고, 충돌 문제를 어떻게 해결할 수 있는지, 패턴들의 작동 원리를 다양하게 설명하고 있습니다.

최근 카카오 사태로 서비스 설계 뿐만 아니라 유지 보수를 위한 오케스트레이션,특히 DR 등이 화두로 떠오르고 있는데, 마이크로서비스 아키텍처 구축을 위한 패턴들과 분석 기법에 대해서 깊이 있는 지식을 얻고자 한다면, 해당 목적에정말 깊이 있는 도서라고 할 수 있습니다.

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

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

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

소프트웨어 아키텍처의 난해하고 중요한 부분에 대한 책이다.

모든 소프트웨어 아키텍처가 트레이드오프라는 말에 공감한다.

현실적으로 가능한 선에서 비용과 효율을 고려해 최선의 선택을 해야 한다.

파트1 : 따로 떼어놓기

파트2 : 다시 합치기

책은 크게 2가지의 부분으로 이뤄져있다. 그리고 자바로 설명한다.

좀 더 쉽게 소프트웨어 아키텍처의 현실적인 딜레마를 설명하기 위해 가상의 애플리케이션으로 책을 진행시킨 점도 좋았다.

또 역자가 파트1부터 가상의 기업과 조직, 인물들을 한국식으로 재편성해 대본 형식으로 바꾼 것도 이해하기 편했다. ^^

은근히 영어이름과 매칭되는 한국어 이름(Logan -> 노건우) 을 택한 센스를 이해했다.

아키텍트의 대해 우리가 스택오버플로우에서 쉽게 답을 찾을 수 없는 이유는 뭘까.

각 회사마다 처한 상황과 쓸 수 있는 비용이 다르기 때문이다. 그렇기 때문에 소프트웨어 아키텍트는 커스텀하게 들어갈 수밖에 없고 그렇기에 이 부분에서 비즈니스적으로 컨설턴트가 개입될 여지가 충분히 있다고 생각한다.

어쩌면 이러한 점 때문에 소프트웨어 아키텍처가 거시적으로는 매력적이지 않나 라는 생각이 든다.

더 나은 선택을 할 수 있게끔 도와줄 수 있다면 그 자체로 시장에서 경쟁력을 가진 게 아닐까.

요점정리

- 소프트웨어 아키텍처 스타일

: 10년 전 - 오케스트레이션, 현재 - 오픈소스, 마이크로서비스

: 한번에 하나씩 아키텍처는 스스로를 완전히 대체한다.

- 데이터는 중요하다

: 운영데이터(OLTP, 일반적인 DB사용), 분석데이터(OLAP, prediction, analysis, BI, Data Science, Business Analysis, 관계형 데이터 아님)

-피트니스 함수 사용하기

: 어떤 아키텍처 특성이나 그것들을 조합한 아키텍처 특성의 무결성을 객관적으로 평가하는 임의의 메커니즘

|_'임의의 메커니즘' - 성능, 확장성 등 운영 아키텍처 특성은 아키텍처 구조를 테스트하는 전용 테스트 라이브러리로 평가.

|_'객관적인 무결성 평가' - 테스트, 모니터, 다른 피트니스 함수로 측정 가능한 객체의 값 제공

|_'어떤 아키텍처 특성이나 그것들을 조합한 아키텍처 특성' - 원자적(코드베이스의 컴포넌트 주기 확인), 전체적(서로 맞물려 있는 아키텍처 특성을 잘 조합하고 조합 결과가 아키텍처에 부정적인 영향을 미치지 않도록 보장)

-도메인 설계 검증은 단위 테스트에 해당

: 테스트에 도메인 지식이 필요하지 않으면 피트니스 함수, 필요하면 단위 테스트

|_ 예) 탄력성 - 폭증 유저수 감당하는 앱 능력. 구조에 대한 문제니 피트니스 함수에 해당

-모놀리식 아키텍처

: 모든 비즈니스 관련 사항을 함께 결합하는 하나의 코드 베이스를 갖춘 대규모의 단일 컴퓨팅 네트워크

: vs MSA(마이크로서비스 아키텍처)

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

daso***l2022-10-30

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

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

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

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

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

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

han***l2022-10-30

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

소프트웨어의 아키텍처가 중요하다는 것은 누구나 알고 있지만, 배우고, 적용하기란 여간 어려운 것이 아니다.

특히, 개발자가 아키텍처로 성장해나가기 위해서 알아야 할 내용들이 쉽지가 않고, 주변에서 배우거나 적용된 좋은 사례를

접하기가 쉽지 않은 만큼, 책으로써 아키텍처를 배울 수 있다는 점에서 추천을 한다.

책 이름에서 The Hard Parts라고 되어 있듯이 심화편으로 기본은 ‘소프트웨어 아키텍처 101’라는 책의 심화편이다.

아키텍처를 제대로 배우고 싶다면, 앞선 기본편을 한 번 읽고 보는 것이 좋을 것 같다.

http://www.yes24.com/Product/Goods/104491433

근래 아키텍처의 중요성이 높아지는 것은 마이크로서비스가 대두대면서이기도 한 것 같다.

다른 서비스에서도 물론 중요하지만, 마이크로서비스로 여러가지를 분산제공하다 보니까 아무래도 근간인 아키텍처의

중요성은 이루 말 할 것 없는 것 같다.

무엇이 정답이라고 알려주진 않지만, 다양한 패턴과 사례를 통해서 우리가 설계하는 아키텍처의

방향과 결정을 할 수 있도록 도와주는 책인 것 같다.

그리고 적절한 예시와 사진까지 우리가 이해하기 쉽도록 잘 쓰여져 있어 아키텍처를 접하기 어려웠던 사람도

1~2번씩 읽어보면 많은 도움이 될 수 있을 것이라 생각한다. 물론 어려운 부분도 있지만 이런 부분은 조금씩 인터넷에

찾아서 스스로 학습하는 것도 많은 도움이 되는 것 같다.

스스로 개발을 하다가 아키텍처에 대한 갈망과 고민을 한 번쯤 해보신 분들이라면 조금 갈증이 해소될 수 있는

책이지 않은가 싶습니다.

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

lilym***l2022-10-30

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

소프트웨어 아키텍처 101이 개론서같았다면

하드파트는 분산 시스템을 만들기 위해

어렵고 복잡한 아키텍처들을 모아 모아

각각의 장단점을 살리는 아키텍처를 결정할 수 있도록

아키텍처와 다양한 패턴들을

체계적으로 정리해놓은 아키텍트 필독서라 할만하다.

소프트웨어아키텍처TheHardParts.jpg

기본 개념은 물론 실용적인 조언까지

엔터프라이즈 애플리케이션과

고도로 결합된 마이크로서비스를 구축하기 위해

서비스를 어떤 수준으로 어떻게 나눠야 하는지

이를 위해 컴포넌트들을 나누는 패턴들과

운영 데이터를 분리하는 방법에 대해 알려주고

이들을 다시 함께 처리할 수 있도록

재사용과 트랜잭션을 묶어 데이터를 어떻게 움직이도록 해야 하는지

난해하고 바꾸기 어려운 아키텍처를

객관적이고 올바르게 연결시킬 수 있도록

실무에서 오랜 시간 갈고 닦은 노하우들을

사례를 통해 아낌없이 알려준다.

아키텍처에 은빛 탄환은 없지만

가히 은빛 탄환처럼 만병통치약스러운

사례와 패턴들 노하우들이 아닌가 싶다.

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

lowgi***l2022-10-30

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

개발하면서 저연차 때에는 크게 고민을 할 일이 없는 것이 있는데요.

바로 아키텍처입니다.

대부분 각 팀의 팀장이나 아키텍처 등 설계하는 사람들이 있어서 대부분 큰 틀은 내려주기 때문이죠

일하다 보면 내려준 아키텍처보다 내가 생각한 아키텍처가 좋은데 왜 그걸 안 했을지 의문인 적도 있었습니다.

막상 실무에 업무를 하다 보면 내가 생각이 짧았다고 하면서 이런 깊은 뜻까지 있다니 하면서 머리를 친적도 있습니다.

어느덧 직접 설계를 내려야 할 때가 되고 시스템 직접 핸들링을 하는 단계가 최근에 되어서 고민이 많습니다.

그러던 중 한빛미디어에서 ‘소프트웨어 아키텍처’란 책이 나왔습니다.

이 책은 정말 매운 맛입니다.

매운맛에 의미를 알아보도록 하겠습니다.

01 4.jpg

1. 맵지만 당기는 책

한번 읽어서는 절대 이해되지 않습니다. 매운맛에 중독된 사람처럼 그 맛을 잊지 못하고 다시 읽게끔 만드는 마성의 책인데요.

한번 컨택한 분산 아키텍처를 끝까지 만들고 싶은 욕망에 가득하기 때문입니다.

도메인별로 어떻게 나누는 방법과 패턴들을 정리해보면서 정말 계속 읽게 됩니다.

또한 직접 같이 일은 안 하지만 등장인물들이 대화를 통해서 시스템의 상황을 알려줘서 간접적으로 이해하는 폭이 넓어졌습니다.

02 4.jpg

2. 실무와 매우 유사

대부분 아키텍처 책들은 큰 범위가 누가 만들고 왜 만들고 어떻게 사용하는지까지는 말을 해줍니다.

하지만 그 이후 가장 중요한 문제점들에 대해서 쉽게 찾기는 어려웠습니다.

직접 실무에서 부딪히고 깨지면서 각 아키텍처의 문제점을 찾은 기억이 있습니다.

이 책은 베스트 핏을 찾기보다는 차선과 그 너머 최선의 트레이드 오프를 찾는 여정이라고 봅니다.

전작에서의 이론 개념과 이 책으로 실무의 기술까지 익히면서 아키텍처의 감을 잡는 데 큰 도움이 됐습니다.

03 3.jpg

PS

막상 해보기 전에는 모든 일들이 어렵다고 봅니다.

그 어렵다는 생각의 벽을 넘으면 더 큰 산이 보이고 그 산을 넘어야 발전한다고 생각하는데요.

아키텍처의 산을 함께 같이 올라 보실래요?

blusk***l2022-10-30

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

아키텍처 관련 책들을 요즘 많이 읽어보고 있다. 책을 읽는다고 완벽하게 습될수 있는 범위는 아니지만 여러번 읽으면 좋아지겠지라는 생각으로 읽고 있다.

이 책은 아래와 같이 등장인물이 나온다. 그리고 그들의 시스템을 변경시켜가는 과정을 아키텍처 이론과정과 함께 설명을 하고 있다. 아마도 우리가 관리 또는 개발하는 시스템을 변경하려 할때 이 등장인물들이 겪는 경험을 하게 되지 않을까 생각이 든다.

그리고 어떤 책이든 글과 그림이 적절히 섞여 있어야 이해하기가 쉽다. 특이 아키텍처 책들에서는 내용이 어렵다 보니 그림이나 도표를 활용한 설명들이 독자들에게는 중요한 참고 자료들이다.

내용을 이해하면서 읽어야 했기 때문에 전체를 다 읽은 상황은 아니다. 하지만 그만큼 시간을 투자해서 꼼꼼히 읽어야 하는 내용이기 때문에 급하게 읽을 필요는 없다고 생각된다. 아키텍트를 공부하는 분들은 한번쯤 읽어보면 실력향상에 도움이 될 책이다.

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

khs***l2022-10-30

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

이 책은 전작 소프트웨어 아키텍처 101의 심화라고 할 수 있다.

IMG_0472 작게.png

소프트웨어 아키텍처는 쉽지 않은 영역이라고 생각한다.

그 이유는 답이 정해져 있지 않기 때문이다.

책에서는 다음과 같이 설명한다.

“소프트웨어 개발자는 인터넷을 검색해 자신이 맞닥뜨린 문제를 해결하는 데 일가견이 있는 사람들입니다.

가령, 자신의 개발 환경에서 어떤 플러그인을 설정하는 방법이 궁금하면 재빨리 구글에서 답을 찾을낼 수 있죠.

그러나 아키텍트는 그렇게 할 수가 없습니다.

아키텍트는 조직이 처한 상황과 환경에 대해 큰 그림을 그리는 사람들이므로 거의 대부분 문제에 독특한 어려움이 도사리고 잇습니다.

누군가 지금 바로 이 상황과 정확히 똑같은 경험을 한 사람이 자기 블로그나 스택 오버플로에 글을 쓸 확률이 얼마나 될까요?”

“모든 문제가 한하나 새로운 도전을 요하기에 어떻게든 문제를 해결하려는 중대한 의사 결정의 양편에 치우친 수많은 트레이드오프를 냉정하게 판단하고

평가할 때 아케텍트의 진가가 드러납니다. 이 책의 저자들은 ‘최고의 솔루션’이란 말은 입에 담지 않습니다. ‘최고’라는 말 자체가 아케텍트가 자신의 설계에서

있을 법한 모든 경쟁 팩터를 최대화하려는 의도를 포함하고 있기 때문입니다. 그래서 우리는 이렇게 가볍게 조언합니다.”

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

최근 어떤 방송에서 최선을 찾으려 하는 것은 차선을 선택하는 것에 많은 방해가 된다는 얘기를 들은 적있다.

딱 소프트웨어 아키텍처에 적용되는 말이라고 생각된다.

이 책은 최선의 트레이드 오프를 찾기 위한 방향성을 알려주는 책이라 생각된다.

어려운 책이지만 적절한 예시를 들어가면 최대한 쉽게 접근할 수 있도록 노력한듯 하여 한번쯤 읽어보면 좋을듯 하다.

IMG_0473 작게.png

IMG_0474 작게.png

IMG_0475 작게.png

하지만 그전에 소프트웨어 아키텍처 101을 먼저 읽어볼 것을 추천한다.

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 자신만의 트레이드오프 분석

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

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

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

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

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

unsig***l2022-10-30

고민할 지점 알려드림

아키텍처 결정 시 어떤 부분을 고민해보면 좋을지 가이드 해주는 책.

iamdaye***l2022-10-30

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

[도서 소개]

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

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

[주요 내용]

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

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

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

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

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

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

[서평]

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

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

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

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

love***l2022-10-30

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

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

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

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

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

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

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

blueg***l2022-10-29

분석하고 찾아가는 이야기

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

소프트웨어 아키텍처.

소프트웨어에 관련 있는 분이라면 누구나 한 번쯤은 들어본 말입니다. 하지만, 막상 얘기해보면 실체나 경계가 모호하게 느껴지는 경우가 많습니다.

책에서는 아키텍처와 함께 가상의 기업과 조직, 인물을 통해 아키텍처를 다루는 현장 분위기를 전달하고자 합니다.

이야기를 읽으며 충분히 상상이 가는, 그래서 자연스럽게 감정 이입이 되어 흥분하고 있는 자신을 발견할 가능성이 높습니다.

한편으로 이야기를 재미있어 하면서도 아쉬워하는 건 과연 이런 조직이나 회사가 얼마나 될까 하는 의구심이 들기 때문입니다.

트레이드오프를 절묘하게 적용하고 있다는 생각이 듭니다.

아키텍처의 키워드: 트레이드오프

크게 두부분으로 이루어져 있습니다.

먼저 아키텍처를 나눕니다. 의도는 선했으나 여러 요구사항을 반영하면서 마구잡이로 엮여버린 구성을 어떻게 분산해야 하는지 알려줍니다. 보통은 새로 개발하는 게 더 빠르다고 얘기하곤 합니다. 하지만 새로 개발 한다한들 비슷한 모놀리식 아키텍처라면 머지않아 같은 상황을 만나게 됩니다. 이런 경우는 피하고 싶네요.

그리고 다시 합칩니다. 기껏 분해해 놓고 왜? 라고 생각할 수 있지만 분해한 이유가 문제를 풀려고 하기 때문입니다.

합치는 이유와 관련된 다양한 기술을 살펴보고, 통신, 조정, 일관성, 이 세 가지 힘을 조절하며 장단점을 알려줍니다.

트레이드오프가 스며들다

이론과 이야기를 트레이드오프 하며 내용을 풀어나갑니다. 한빛가이버 애플리케이션의 이슈가 각 장의 주제와 함께합니다.

이야기로 관심을 모으고, 전하고 싶었던 내용을 설명합니다. 이론적인 내용에 지칠 때쯤 이야기 안으로 다시 끌어들입니다.

설명한 내용을 가지고 이해관계를 가진 이들이 티격태격하는 모습을 보여주면서 같은 내용을 바라보는 여러 가지 시각을 알려줍니다. 기술이나 개념에 매몰되지 않고 무엇을 봐야 하는지 알려줍니다.

이렇게 풀어나가는 게 생각보다 힘이 있습니다.

어느 정도인가 하면, 이야기 속의 문제와 이슈를 보며 자신의 의견을 보태고 있습니다.

단순한 분산을 넘어

분산 아키텍처라고 하면 프로그램을 잘게 나누는 것만 생각하는 게 일반적입니다. 그렇게 생각하기 쉽구요.

하지만, 기능이나 서비스 단위로 묶어서 나누는 게 전부가 아닙니다.

프로그램이나 서비스 못지않게 데이터와 프로세스도 그에 맞게 분리해야 합니다. 그렇지 않으면 분산 아키텍처를 적용한 것처럼 보이기만 할 뿐, 데이터를 저장하고 서비스를 요청하는 단계에 가면 모두 묶여있는, 들춰보면 결국 단일 아키텍처에서 벗어나지 못하고 있는 모습을 발견하게 됩니다.

더하여 단일 아키텍처에서는 에러 처리나 롤백이 별 문제가 되지 않습니다만, 분산 아키텍처에서는 얘기가 달라집니다.

롤백이나 보상 요청을 처리하는 동안에도 에러가 발생할 수 있다는, 당연하지만 거의 생각하지 않았던 문제를 맞닥뜨립니다. 더 이상 당연한 건 없다는 걸 느끼는 순간이 옵니다.

읽으며 생각지 못했던 부분을 알려주는 신선한 자극도 있고,

생각보다 쉽지 않다는 어려움, 막막함을 간접적으로나마 경험해 보는 시간이었습니다.

도구나 기술에 너무 열광하거나, '다른 아키텍처는 어떻다더라'는 말에 휩쓸리지 말라.

남의 아키텍처는 내 아키텍처가 될 수 없다.

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

ohmyb***l2022-10-29

오직 트레이드오프

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

Why hard parts? 라고 했을까?

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

아키텍처에 대한 이야기

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

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

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

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

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

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

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

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

이 책의 흥미로운 진행 방법

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

마지막으로

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

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

makingf***l2022-10-29

소프트웨어 아키텍처 실무편! 최상급의 번역서!

전작 '소프트웨어 아키텍처 101'의 실무편!

기술 번역서로서의 가치도 최상급!

이보다 깔끔하게 한국어로 된 책을 접하기 힘듬

kianms10***l2022-10-29

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

'소프트웨어 아키텍트 같은 기술자가 콘퍼런스에 참석하거나 책을 쓰는 이유는 뭘까요? 이른바 "베스트 프랙티스"리고 알려진 것들이 세상에 차고 넘쳐 그 용어가 남용되다 보니 사람들은 점점 반발심을 갖게 되는 것 같습니다.'

책 표지에는 'The Hard Parts'라는 문구가 진하게 표시되어 있다.

왜 '하드 파트' 인가?

첫째는 어려움이고, 둘째는 단단함이라고 설명하고 있다. '소프트웨어 아키텍처는 나중에 바꾸기 어려운 것'이라는 약간 비틀어 표현한 듯한 정의가 가장 잘 알려져 있기 때문에, 그것이 책의 주된 내용이라고 한다.

책에는 사가(saga)라는 표현이 자주 등장한다.

- 영웅적인 업적을 기리는 긴 이야기

책에서는 다양한 예를 들어주면서 좀 더 구체적이고 실질적인 문제 해결 방안을 제시하려고 노력하고 있었다.

책을 읽다보면 관련된 내용을 등장인물들의 대화형태로 나타내고 있는 부분이 재미있었다. 대화를 통해 간접적인 이유들을 설명하고 대화 후에 자세한 설명을 통해 내용들을 설명하는 것을 볼 수 있었다.

운영 데이터의 분리, 데이터베이스의 트랜잭션 관리. 그리고 모듈을 나누다보면 결국엔 응집된 하나로 작동시켜야하는 경우들도 생기는데 이런 경우에 대한 내용을 다룬 재사용 패턴 등에 대해서 자세하게 다루고 있다.

이 책을 먼저 읽고 소프트웨어 아키텍처를 설계 해본다면 설계하는데 있어서 많은 도움이 될 것 같다.

'소프트웨어 아키텍처는 나중에 바꾸기 어렵다.' 그래서 사람들은 베스트 프렉티스를 통해 아키텍처를 구성하려고 한다. 잘 짜여진 아키텍처는 잘 동작하지만 처음부터 제대로 설계 되지 못한 아키텍처를 평생 문제를 안고 운영하게 된다. 그렇기 때문에 설계 이전에 이 책을 통해 조금 더 생각의 폭을 넓힐 수 있었으면 좋겠다.

이 리뷰는 한빛미디어 <나는 리뷰어다>를 통해 도서를 지원받아 작성되었습니다.

spac***l2022-10-29

쉽지 않은 아키텍처

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

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

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

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

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

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

hony7***l2022-10-29

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

> 책의 구성 및 내용

이 책은 특정 소프트웨어 아키텍처를 주장하는 형태의 책은 아닙니다.
분산 아키텍처를 구성하며 고려되어지는 다양한 요건들에 대해,
고민해 볼 수 있도록 환경을 구성하고 균형을 맞추도록 조언해주는 책입니다.

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

만물은 독일지니, 독이 없는 건 하나도 없다. 오직 용량만이 독성을 없앨 수 있다.
- 파라켈수스

기본적인 전제는 분산 아키텍처 입니다.

근래에는 예전과 다른 IT 환경변화로
MSA , Cloud 환경이 기본적으로 고려되어지는 것 같습니다.
책에서는 MAS를 위해 모든걸 디커플링하는 것도 옳지 않다,
제일 나은 트레이드 오프 세트를 찾아야 한다는 것이 이 책의 주요 주장입니다.

실제와 비슷한 사례를 통해, 분산 아키텍처로 개선해 나가며, 각 결정에 대한 트레이드 오프를 적절하게 잘 설명하고 있습니다.

Part 1 따로 떼어놓기, 에서는 각 서비스와 데이터를 어떻게 나누어 설계할 지에 대한 내용을 주로 설명하고 있습니다.

Part 2 다시 합치기, 에서는 나누어 놓은 서비스와 데이터를 효율적으로 사용하기 위해 공유할 것은 무엇인지, 공유데이터에 어떻게 접근할 것인지에 대해 설명하고 있습니다.

책에서는 한빛전자라는 가상의 회사를 기준으로,
기사 출장서비스의 아키텍처를 구성하는 것을 통해 다양한 것을 설명하고 있습니다.

단순하게 각 아키텍처에 따른 트레이드 오프만을 설명하는게 아니라,
실제 시스템을 구축하는 사례를 통해 설명하니 좀 더 편안하고, 재미있고, 이해하기 쉽게 읽을 수 있었습니다.

아키텍처 퀀텀 : 높은 기능 응집도, 높은 정적 커플링, 동기적 동적 커플링의 특성을 띈, 독립적으로 배포 가능한 아티팩트

퀀텀에 대한 설명도 아래와 같이 개발자들의 대화를 통해 차례대로 설명하니 쉽게 이해하기 편합니다.
(다만, 기본적으로 독자들이 개발 프로세스나 기술에 대한 기본적인 이해가 필요합니다.)

책의 제목에서 얘기하는 바와 같이 트레이드 오프에 대해 계속 설명합니다.

하나의 주장만 있는 것이 아니라, 각 각의 트레이드 오프에 대한 설명이 더 마음에 들었습니다.

솔루션 아키텍트로서 실제 프로젝트를 분산 환경으로 변경할 때 고려해야될 사항들을 적절히 한 권에 알차게 넣어 놓은 책이었습니다.

> 장점

실제 사례를 가상으로 구성하고, 가상 등장인물들의 대화를 통해 재미있게 볼 수 있습니다.
트레이드 오프에 대해, 아키텍트의 결정에 따른 장단점을 깔끔하게 정리해 주고 있습니다.

> 아쉬운 점

없음

> 책읽기 필요사항

솔루션 개발 경험

> 추천 독자

분산환경을 고려하고 있는 솔루션 아키텍트

> 정보

저자: 닐 포드, 마크 리처즈, 프라모드 세달라지, 세막 데그하니
옮긴이: 이일웅
출판사: 한빛미디어
전체 페이지: 484페이지

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

sihan***l2022-10-23

나눌것인가 합칠것인

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

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

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

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

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

bcd3***l2022-10-23

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

이 책을 한빛미디어로부터 제공받아 작성한 리뷰입니다.

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

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

분산 처리를 하고자하는 개발자를 위한 소프트웨어 아키텍처를 알려주는 책이다.

개발 시 많은 사용자가 한번에 몰릴 경우를 위해 분산 처리는 거의 필수적인데,

초급 개발자에게 쉬운 내용은 아니다.

하지만 백엔드 / 서버 개발자라면 분명히 알아두어야하는 내용이고

이 책 ' 소프트웨어 아키텍처 The Hard Parts : 분산 아키텍처를 위한 모던 트레이드오프 분석'이 그에 대해 알려준다.

분산처리를 위해 소프트웨어를 어떻게 구성해야할지,

그때의 장단점 즉 트레이드오프는 무엇인지 깊게 알려주는 책이다.

아무래도 난이도가 좀 있고, 초급보단 중급/고급 서버 개발자가 읽는게 좋을 것 같다.

쉽지 않은 책이지만

분산 처리를 시도할때 생각해봐야하는 것들을

자세하게 생각하는데 도움을 주는 책

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

더 유능한 서버 개발자가 되고자하는,

분산 처리를 위한 소프트웨어 아키텍처와 그에 따른 장단점을 고민하시는 분들은 꼭 읽어보세요!

rock1***l2022-10-16

경력 개발자와 시스템 아키텍트를 꿈꾸는 사람들에게 강력 추천

개발 경력이 쌓이면 레거시 시스템을 개선하거나 신규 시스템을 구성하기 위해서 아키텍트 능력을 요구하는 업무들이 많아지는 데

한빛미디어에서 최근에 출간된 소프트웨어 아키텍처 101 책 과 이 책은 개발자가 좀 더 나은 아키텍트로 성장할 수 있는 발판을 마련해 줄 수 있을 것같다

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

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

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

한빛출판네트워크

인기 검색어 (최근 1개월간)

책

강의/세미나

채널.H

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

들어가며

이 책이 말하는 것

- 대상독자

- 책의 내용 및 구성

- 책에서 눈에 띄는 점

- 총평

책소개

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

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

결론

이 책의 매력은?

마치면서

마이크로서비스 시대

(중략)

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

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

Why hard parts? 라고 했을까?

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

아키텍처에 대한 이야기

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

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

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

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

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

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

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

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

이 책의 흥미로운 진행 방법

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

마지막으로

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

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

최근 본 상품1