책소개

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

『소프트웨어 아키텍처 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 책 과 이 책은 개발자가 좀 더 나은 아키텍트로 성장할 수 있는 발판을 마련해 줄 수 있을 것같다

moonlight***l2022-10-16

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

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

Software Architect - The Hard Part.png

0. 소개

Software Architect는 끊임없는 결정의 연속입니다.

복잡하고 다양한 구성 요소들의 상충관계를 파악하고 그에 맞는 의사 결정을 내려야 하는 선택들만이 남아 있는 'Hard Parts'입니다.

이 책은 분산 Architecture를 구성할 때 Architect가 각 결정이 가지고 Tradeoff를 분석하여 객관적으로 의사 결정을 내리는 모든 과정에 대한 Know-How가 녹아있습니다.

Architecture 결정에 필요한 지식 , 각 Architecture 장단점 , 다양한 Pattern 설명 , 큰 그림을 보는 안목 등을 구체적인 사례를 통해서 공유합니다.

또한, 최신 Software Architecture의 다양한 난제들에 대한 결정을 어렵게 만드는 이유에 대해서 분석과 소개를 하고 자신이 처한 문제에 대해서 적용하는 방법을 소개해 줍니다.

모든 방법에 통용되는 만능 Solution이라는 것은 세상에 존재하지 않기 때문에 각 방법론과 Pattern의 장단점을 모아놓았습니다.

주요하게 다루는 내용으로는 Tradeoff 분석을 하여 의사 결정을 내리기 위한 자료를 효과적으로 정리하는 방법, Service를 필요에 따라 다양하게 세분화하여 결과적으로 더 나은 결정을 내리는 방법론, Service들 사이의 계약 관리 및 각 Service를 어떻게 분리할 것인가에 대한 고찰 , 복잡하게 분산된 Architecture 구조에서 Data를 관리하고 처리하는 방법론 , Application을 쪼갤 때 Workflow와 Transaction을 관리하는 Pattern들의 방법들에 대해서 알아봅니다.

이러한 내용들을 가상의 팀인 '한빛가이버 사가'의 팀원들이 좌충우돌하는 이야기와 함께 풀어나가고 있어서 자칫 지겨울 수 있는 이야기를 재미있게 풀어나갑니다.

1. 구성

PART 1 따로 떼어놓기

이 책의 목표는 분산 Architecture에서 Tradeoff를 분석하는 것이므로 Architecture의 각 부분을 따로 떼어놓는 것부터 시작합니다. 그 후에 각 요소가 정적으로 결합하는 방식에 대한 설명을 중점적으로 합니다.

chapter 1 ‘Best Practice’가 없다면?

모든 Architecture 문제에서 하나의 만병통치약같은 Solution은 없으며, 제목이 Hard Part인 이유에 대해서 알아보고, Data의 중요성 , Architecture 결정 Record , Architecture와 설계의 차이와 같은 기본적인 개념들을 설명합니다.

chapter 2 Architecture 퀀텀

Architecture의 정적 커플링 & 동적 커플리의 범위 정의 문제에 대해서 다룬다

chapter 3 Architecture 모듈성

Architecture 모듈성이 무엇인지를 정의하고 실제 분해 프로세스를 시작합니다.

chapter 4 Architecture 분해

Codebase를 평가하고 해제하는 도구에 대한 설명을 합니다.

chapter 5 컴포넌트 기반 분해 Pattern

Architecture 분해 프로세스에서 사용할 수 있는 유용한 다양한 Pattern에 대한 설명

chapter 6 운영 Data 분리

Service와 Data를 조정하는 방법 등을 사용해 보면서, Data가 Architecture에 어떤 영향을 끼치는지 확인해 봅니다.

chapter 7 Service 세분도

Architecture 커플링과 Data 관심사를 통합해서 통합인과 분해인에 대해서 이야기 합니다.

PART 2 다시 합치기

Service , 통신 , 계약 , 분석 Workflow, 분산 Transaction, Data Ownership, Data 액세스 , 분석 Data 관리 등과 같이 분산 Architecture에서 Hard Part를 어떻게 극복할지에 대한 다양한 예를 보여줍니다.
PART 2의 핵심은 각 분산 개체들간의 '통신(Communication)'입니다.

chapter

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개월간)

BOOK

CONTENTS

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

책소개

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

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

결론

이 책의 매력은?

마치면서

마이크로서비스 시대

(중략)

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

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

Why hard parts? 라고 했을까?

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

아키텍처에 대한 이야기

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

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

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

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

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

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

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

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

이 책의 흥미로운 진행 방법

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

마지막으로

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

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

도서판매처