한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
선정 이유
사실 이번 책의 선정 이유는 특별할 것이 없는데 고를 수 있는 책 중에 끌리지 않는 책을 소거법으로 지우다 보니 선택되었다. 하지만 벌써 실망하고 뒤로 갈 필요는 없다. 책 내용이 생각보다 흥미로웠기 때문이다. 늘 새롭고 정답이 없는 문제에 맞닥뜨리는 기술자들이 최선의 선택을 내리고자 고군분투하는 이야기다.
소프트웨어 아키텍트 같은 기술자가 콘퍼런스에 참석하거나 책을 쓰는 이유는 뭘까요? … 용어야 어쨌든 기술자는 일반적인 문제에 대한 새로운 솔루션(해결책)을 찾고 그것을 더 많은 사람에게 알리고자 책을 씁니다.
하지만 솔루션이 없는 문제들은 어떻게 다뤄야 할까요? 소프트웨어 아키텍처 분야는 하나같이 모든 영역에 걸쳐 제네릭한 솔루션이 없습니다. 온갖 지저분한 문제투성이에 거의 똑같이 지저분한 트레이드오프(상충 관계)만 잔뜩 널려 있죠.소프트웨어 개발자는 인터넷을 검색해 자신이 맞닥뜨린 문제를 해결하는 데 일가견이 있는 사람들입니다. 가령, 자신의 개발 환경에서 어떤 플러그인을 설정하는 방법이 궁금하면 재빨리 구글에서 답을 찾아낼 수 있죠.
그러나 아키텍트는 그렇게 할 수가 없습니다.
… 아키텍트는 일반적인 문제보다는 새로운 상황에서 창의적인 의사 결정을 하느라 끊임없이 고군분투하는 사람들입니다. 그들에게 모든 문제는 마치 눈송이와도 같아서 어떤 조직은 물론 전 세계적으로도 새로운 것들이 대부분입니다.— p. 25-26
주제 및 구성
책 표지에도 나와 있지만 이 책은 『소프트웨어 아키텍처 101』이라는 책의 심화 편으로 실무에서 분산 아키텍처를 설계할 때 트레이드오프 측정에 도움이 되는 심층적인 가이드를 제공한다. 코드 변동성, 확장성, 유지보수성 등 분해할 때 고려해야 할 지침과 트랜잭션, 워크플로, 공유 코드 등 통합할 때 고려해야 할 지침을 각각 제시하고 둘 사이의 균형점을 찾기 위한 분석 방법을 상세히 소개하고 있다.
그뿐만 아니라 상황에 따라 선택할 수 있는 트랜잭셔널 사가 패턴을 제공하는데 이 패턴들은 통신, 일관성, 조정이라는 세 가지 커플링 힘의 조합에 따라 생성된다. '하드 파트'라는 부제가 붙은 이유는 이렇게 다양한 힘들 사이에서 소프트웨어 아키텍처에 대한 결정을 내리는 것은 '어렵고' 이 구조를 한 번 정하면 '단단해서' 쉽게 바뀌지 않기 때문이다.
책은 크게 1부 따로 떼어놓기와 2부 다시 합치기로 나뉜다. 1부에서는 구조(structure)를 중심으로 아키텍처를 이루는 부품들을 한 조각씩 분리해 구성 요소를 이해할 수 있도록 돕는다. 한편 2부에서는 통신(communication)을 중심으로 구성 요소들이 어떻게 상호작용하고 하나의 단위로 작동하는지 살펴볼 수 있도록 한다.
마지막으로 한빛가이버 사가라는 책 속의 이야기를 통해 기술적인 선택에 대해 이해관계자들과 소통하고 설득하는 모습을 엿볼 수 있도록 한다. 이야기에 수반되는 아키텍처 결정 레코드(ADR)를 곰곰이 읽어 보면 아키텍처 결정을 효과적으로 문서화하는 방식까지 함께 배울 수 있다.
유익한 점
가장 유용했던 것을 꼽으라면 풍부한 도표였다. 그림을 통해 개념에 대해 정말 명확하게 전달하기 때문에 아키텍처에 대해 배경지식이 거의 없는 사람도 이해하기 쉬웠다. 다양한 데이터나 트레이드오프를 정리한 표도 패턴 간에 비교를 용이하게 해 장단점을 따져보는 것을 돕는다.
그 밖에 생각을 전환시켜준 것을 딱 하나 꼽자면 중복을 죄악시하지 않는 점이다. 유명한 원칙 중에 DRY(Don't Repeat Yourself)라는 원칙이 있는데 말 그대로 반복하지 말라는 뜻이다. 물론 이 말을 절대적으로 받아들이지는 않았지만 중복이 없어야 더 좋은 코드라는 것이 기본적인 사고방식이었는데 분산 아키텍처에서는 중복을 오히려 권장하는 것을 알고 깜짝 놀랐다. 물론 중복을 허용하면 동기화 문제가 따르게 되지만 분산 아키텍처에서는 중복보다 커플링이 더 나쁜 영향을 끼칠 수 있기 때문에 WET(Write Every Time or Write Everything Twice)하라고 역 조언하기도 한다.
프론트엔드 개발자로서 뷰와 로직의 분리, 클라이언트 상태와 서버 상태의 분리, 컴포넌트 재사용 등 다양한 문제에 대한 해결책으로 분리와 재사용이 최고의 해결 방법이라 생각해왔다. 하지만 이 책 덕분에 현재 구조에서 난항을 겪고 있을 때 좌절하지 않고 분산이라는 다른 해결책을 떠올려볼 수 있다는 점을 알게 되어 안심이 된다.
아쉬운 점
놀랍게도 크게 아쉬운 점이 없었다. 아마 백엔드 개발자도 아니고 아키텍트도 아니라서 부족한 점이나 허점을 눈치채지 못한 게 아닌가 싶다. 그래도 굳이 꼽아보자면 모놀리식 아키텍처를 분산 아키텍처로 분해할 수 있는 Playground를 제공했다면 좋았을 것 같다. 요구사항에 따라 아키텍처를 변경하고 토론을 나누고 ADR까지 남길 수 있게 한다면 책을 넘어서 더 생생한 가치를 제공할 수 있지 않을까?
총평
개발 도서들을 읽다 보면 항상 '은 탄환은 없다'라는 말을 자주 보게 된다. 이 책에서는 특히나 이 점을 경계하고 있는데 모든 문제를 해결하는 마법 같은 아키텍처가 없기 때문이다. 마치 리팩터링이 개발과 별개로 독립되어야 하는 것이 아니라 일부여야 하는 것처럼 자신이 맡은 시스템을 분석하고 반복해서 설계함으로써 점진적으로 더 좋은 아키텍처를 만들어 나갈 수 있다고 강조한다.
사실 정답이 있는 문제라면 이미 딱 맞는 솔루션이 나와서 개발자나 아키텍트를 대체했을 텐데 그런 점에서 정답이 없는 것을 부정적으로 바라볼 필요는 없다.
추천 대상
- 현재 아키텍처 구조의 한계를 느껴 다양한 아키텍처의 장단점을 알고 싶은 사람
- 커플링을 확인하고 결합점을 분석해서 트레이드오프를 평가하는 방법을 배우고 싶은 사람
- 난해하고 답이 없는 문제를 맞닥뜨렸을 때 최선의 선택을 찾아가는 방법을 배우고 싶은 사람
- 기술을 모르는 이해관계자들에게 의사 결정을 도울 수 있는 기준을 제시하는 방법을 익히고 싶은 사람
사족
이번 책은 500여 쪽인 데다 그림이 많아서 읽기 수월한 편이었다. 처음에 너무 어려운 책을 골랐더니 상대적으로 쉽게 느껴져서 오히려 좋다고 할까? 물론 오늘 하루를 다 바치긴 했지만 서평을 쓸 때도 지난 글보다 조금은 술술 써 내려가는 느낌이 들었다.
팀을 꾸리는 것도 분산 아키텍처를 제대로 작동시키는 것만큼이나 답이 없고 트레이드오프가 존재하는 문제가 아닐까 하는 생각이 들었다. 팀원 한 사람은 각자의 지식(데이터베이스)을 가지고 저마다 특화된 기능(서비스)을 제공하며 이러한 여러 사람들이 직접(동기) 또는 메신저(비동기)로 소통하면서 조직이 굴러가게 된다. 모든 팀원을 슈퍼스타로 채운다고 승리를 보장하지 않는 것처럼 과제에 따라 적절한 조합이 중요하다는 점이 재미있는 포인트다.
