한빛미디어

[선정 이유]

 

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

 

[구성 및 주제]

 

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

 

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

 

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

 

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

 

[유익한 점]

 

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

 

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

 

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

 

[아쉬운 점]

 

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

 

[총평]

 

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

 

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

 

[추천 대상]

 

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

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

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

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

 

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