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

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

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

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

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

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

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

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

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

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

1챕터 : '베스트 프랙티스' 가 없다면?

이 장에서는 소프트웨어 아키텍처링이 무엇인지에 대한 저자들의 생각을 잘 표현했다. 특히 필자의 경우 가장 마음에 드는 코멘트는 바로 아래의 내용이었다.

"최상의 것을 선택하려 하지 말고, 최악의 경우를 피하는 데에 가장 최선이 되는 것들로 구성하라"

왜 필자가 해당 코멘트에 대해 적극 지지를 보냈나 면, 아키텍처링을 막 시작한 초보자들의 경우, 본인의 사랑에 빠질 서비스의 초기 아키텍처에 너무나 공을 들인 나머지 시작도 하기 전에 지처 버리는 경우를 종종 보았기 때문이다.

무엇보다, 아키텍처를 설계하는 일에서 최상의, ultimate의 솔루션은 없다. 왜냐하면 서비스를 운영하다 보면 틀림없이 완벽하다고 생각한 이키텍처에서 홀이 발생할 가능성이 높고, 내가 예상하지 못했던 이슈에 봉착할 가능성이 10000% 존재하기 때문이다.

그렇기에, 서비스 아키텍처링을 시작할 때는, 최악의 경우가 무엇인지를 나열하고, 그다음에는 가장 필요한 기능과 조건이 무엇인지를 나열한 다음, 이것들이 상호 완충하며 만족할 수 있는 아키텍처를 설계하기 위해 분투하는 것이 중요하다.

3챕터 : 아키텍처 모듈성

이 장에서는 아키텍처 모듈성에 대해서 설명한다. 크게 5가지로, 유지 보수성, 시험성, 배포성, 확장성, 가용성/내고장성 등이 있다.

유지 보수성은 말 그대로 아키텍처를 유비 보수가 용이하게 구성해야 함을 의미한다. 이 말이 무엇인고하면, 가령 기능을 추가, 삭제, 혹은 변조를 해야 할 때, 얼마나 기존의 로직에 영향도 없이 적용할 수 있느냐를 의미한다.

시험성은 특정 기능이 추가되거나 혹은 수정, 삭제되었을 때 이러한 기능들을 단위 테스트하거나 통합 테스트할 때, 각각이 독립된 환경상에서 수행하여 효율을 높일 수 있게 하는 것이 중요함을 의미한다. 즉, 상당히 미미한 수정을 했음에도 해당 변경에 의한 영향도를 파악하기 위해 전체 테스트를 수행해야만 한다면 이는 시험성이 떨어진다고 볼 수 있다.

배포성은 소프트웨어 아키텍처링을 모듈 단위, 작은 단위로 하여 배포 주기를 적정 수준으로 가져갈 수 있는 환경의 척도를 의미한다. 가령 어떤 서비스의 경우 1달에 한 번 배포를 진행하는데, 해당 아키텍처가 너무나 모놀리틱해서 조그마한 한곳을 수정하였을 뿐이데, 상당히 까다로운 테스트를 거치고, 배포하는 데에 전체 모든 모듈들을 재배포해야 한다면 이는 배포성이 상당히 떨어지는 서비스 / 아키텍처라 할 수 있다.

확장성은 탄력성과도 관련이 있다. 가령 특정 트래픽이 순간적으로 치솟는 스포츠와 같은 서비스에서, 순간적으로 늘어나는 트래픽을 감당하기 위한 "탄력성"을 갖는 것은 굉장히 중요하다고 할 수 있다. 또한 게임 서비스와 같이 점진적으로 늘어나는 사용자들을 감당하기 위해서 전체적인 서비스의 처리량을 쉽게 확장할 수 있는 아키텍처도 상당히 중요하다고 할 수 있다. 따라서 이러한 두 가지 측면을 모두 가진 서비스 / 아키텍처의 경우 확장성이 좋다고 할 수 있다.

가용성/내고장성은 서비스의 에러 저항도를 의미한다. 이에 대한 자세한 설명은 책을 참고해 보자

5챕터 : 컴포넌트 기반 분해 패턴

이 장에서는 한곳에 복잡하게 얽히고설켜있는 기능들을 어떤 식으로 적당히 나누어 효율적인 아키텍처를 구성할지 설명한 챕터이다.

공통 도메인 수집 패턴과, 컴포넌트 디펜던시 결정 패턴, 컴포넌트 도메인 생성 패턴과 같은 실무에서도 많이 사용되는 패턴? 들이 언급된다. (필자는 그것들이 패턴인지도 몰랐다..)

그렇기에 잘 알아두면 필시 실무에서 도움이 될법한 내용들이라 장담한다.

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

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

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

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

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

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

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

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

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

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

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

읽어주셔서 감사합니다.

아키텍트 여러분이 무언가를 전도하려 하지 않고, 객관적인 트레이드오프 중재자가 되고자 노력하길 바랍니다. 
아키텍트는 은제 탄환을 쫓는 사람이 아니라, 있는 그대로의 트레이드오프를 분석하는 스킬을 연마해서 조직에 진정한 가치를 더하는 사람입니다.

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

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

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

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

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

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

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

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

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

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

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

주요 내용
- 트레이드 오프 분석과 함께 의사 결정을 효과적으로 문서화하기
- 서비스 세분화를 통해 더 나은 결정을 내리는 방법
- 모놀리식 애플리케이션 분리의 복잡도
- 서비스간 게약 관리 및 분리
- 고도로 분산된 아키텍처에서 데이터 처리하기
- 애플리케이션을 분리할 때 워크플로와 트랜잭션을 관리하는 패턴 학습

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

닐 포드, 마크 리처즈, 프라모드 세달라지, 세막 데그하니 저/이일웅 역 | 한빛미디어

저자 닐 포드

종단간 소프트웨어 개발과 인도를 전문으로 하는 글로벌 IT 컨설팅 회사, 쏘우트웍스(ThoughtWorks) 의 이사이자 소프트웨어 아키텍트, 밈 랭글러(meme wrangler). 이 회사에 입사하기 전에는 미국에서 유명한 교육/훈련 개발 회사인 DSW Group에서 최고 기술 책임자(CTO)를 역임했다. 웹 사이트 Nealford.com

저자 마크 리처즈

마이크로서비스 아키텍처, 서비스 지향 아키텍처, 분산 시스템 아키텍처 설계/구현/ 등 다양한 기술 실무분야를 경험한 소프트웨어 아키텍트이다.

저자 프로모드 세달라지

싱크웍스의 데이터/네브옵스 부문 이사, 애플리케이션 개발, 애자일 데이터베이스 개발, 진화적 데이터베이스 설계, 알고리즘 설계, 데이터베이스 관리 등이 전문 분야이다.

저자 세막 데그하니

쏘우트웍스의 신기술 부문 이사, 실버브록 리서치에서 수석 소프트웨어 엔지니어, 폭스 테크놀로지에서 소프트웨어 수석 소프트웨어 엔지니어로 일했다.

역자 이일용

20년 가까이 국내의 엔터프라이즈 현장에서 자바 전문 풀스텍 개발자, 소프트웨어/애플리케이션 아키텍트로 프로젝트를 수행했다.

20여 권의 IT 전문서를 번역하며 동료, 후배 개발자들과 지식과 경험을 나누는 일에도 힘쓰고 있다.

이 책을 읽으면서 IT 개발자들이 현장에서 소프트웨어 개발과정 중 제일 힘들어하는 소프트웨어 아키텍처를 구성하는 다양한 문제들을

저자들은 더 실감나게 표현하고자 가상의 기업과 조직, 인물들을 창조하였는데,

역자 또한 우리 실정에 맞게 사명과 등장인물들의 이름을 로컬화 하였다.

또 일반적인 평문으로 기술한 원서와 달리 등장인물들간의 대화 내용이나 현장 분위기를 좀 더 생동감 있게 전달하고자 대본형식으로 스토리텔링화하여 독자들의 이해를 한층 높여주고자 노력한 점에 대하여

독자로서 역자에게 고마움을 전한다.

‘한빛가이버’라는 가상의 애플리케이션을 예로 들어, 아키텍처 이야기 보따리를 풀어내고 있다

한빛가이버 사가

1. 비티게팅 워크플로

2. 티게팅 워크플로

3. 현재 문제점

4. 한빛가이버 아키텍처 컴포넌트

5. 한빛가이버 데이터 모델

순으로 생동감 있게 풀어내고는 있다

우리나라 IT 개발관련자들이 가장 어려워하는 부문이 아키텍처 구현 부문이다.

IT 개발부문에서 몸담고 있는 고급, 중급, 초급개발자들이 협업하는 모습들이 생생하게 표현되어 있다. 좋은 소프트웨어 아키텍처 구현 가이드라 할 수 있다.

개발 PM을 맡고 프로젝트를 진행하는 PM이라면, 프로젝트 착수 전에 함께하는 개발자들에게 이 책의 나누어주고 읽고 잘 협업을 할 수 있도록 안내 한다면,

맡은 프로젝트를 성공적으로 완수하는 데 일조할 것으로 판단되어 적극 추천한다.

IT 개발자로 준비하는 산업현장의 프로세스를 잘 이해하지 못하는 취업예정자라면 소프트웨어 아키텍처를 통하여 현장감을 이해하는데 많은 도움이 될 것이다.

이 책을 이해할 수 있을 때까지 정독을 하게 된다면 현장감과 자신감을 갖고 도전할 수 있을 것으로 판단되어 적극 추천한다.

대한민국! 위대한 미래를 여는 일에 IT 전문가들의 노력을 기대하며

대한민국 IT 산업 전문가들이 국제표준을 지키며 글로벌 경쟁력을 갖추어 세계로 뻗어 나가기를 기원한다.

책 소개

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

『소프트웨어 아키텍처 101』의 실무편에 해당하는 후속작이다. 분산 아키텍처를 구축할 때 서비스를 나눠야 하는 경우와 합쳐야 하는 경우를 각각 세분도(granularity) 분해인과 통합인이라는 두 가지 관점에서 바라보고, 어떻게 하면 아키텍트가 객관적으로 트레이드오프를 분석해서 올바른 의사 결정을 내릴 수 있는지 이야기한다. 전작이 소프트웨어 아키텍처의 중심 철학과 다양한 아키텍처의 세계를 빠르게 훑어보는 개론서였다면, 『소프트웨어 아키텍처 The Hard Parts』는 제목에 걸맞게 실무 아키텍처링을 할 때 가장 난해한, 그러나 한번 결정되면 바꾸기 어렵고 근본적인 영향을 미치는 부분(hard part)을 진지하게 살펴본다.

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

#소프트웨어 #아키텍처 #The_Hard_Parts # 분산_아키텍처 #모던_트레이드오프_분석 #닐_포드, #마크_리처즈, #프라모드_세달라지, #세막_데그하니 #이일웅 #한빛미디어

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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