한빛미디어

이 책은 소프트웨어 아키텍트의 소양으로 필요한 두 가지의 스킬, 학습을 통해 배우게 되는 하드스킬(개발기술, 지식, 도구 사용법, 기성 개발 방법론 및 숙련도 등)과 시간을 통해 습득하게 되는 소프트스킬(도메인에 특화된 개발 방법론을 파악하는 방법, 효과적인 커뮤니케이션, 신뢰받는 태도 및 관용 등)을 모두 다루고 있습니다. 일반적으로 다른 도서의 경우 한 가지에 집중하여 깊게 다루는 반면 이 책은 저자의 경험을 토대로 한 관점으로 파전같이 얇고 넓지만 중간 풍미 있게 씹히는 오징어 조각처럼 필요한 부분은 구체적 예를 들어가며 설명합니다.

아키텍트 직무에 필요한 기술과 집중해야 되는 지식의 종류, 아키텍처 방향을 결정하는 방법, 의사결정/토론/문서화/개발프로세스, 각 아키텍처의 장단점 및 트레이드오프 절충 방법, 개발팀과 상호소통하는 방법, 비즈니스 관점 및 갈등을 해소하는 방법 등 쉽지 않은 주제라 두껍게 다루어도 쉽게 끝내기 어려운 내용을 솔직 담백하게 경험에 기반하여 풀어냅니다. 또한, 넓고 핵심적인 내용만을 다루어 무겁고 정답 없는 내용을 쉽고 부담 없이 읽을 수 있도록 구성하였습니다. 역자분께서는 이를 "아키텍처의 세계를 콤팩트한 분량의 책에 깔끔하게 담아냈다는 사실이 무척 존경스럽습니다."라고 표현했는데, 무척 공감합니다.

책 내용 초반 '아키텍트에게 바라는 기대치' 대해 설명하면서 아키텍트가 수행해야 하는 핵심 역할 및 요구사항을 아래와 같이 안내하고 있습니다. 이는 이 책의 목표이자 직간접적으로 책 주제를 리스트업한 것과 같고 배울 수 있는 내용과 일치합니다.

  * 아키텍처 결정을 내림

  * 아키텍처를 지속적으로 분석

  * 최신 트렌드 유지

  * 아키텍처 결정에 대한 법적 준수/감시/내부통제 보장

  * 다양한 기술과 경험 도입

  * 비즈니스 도메인 지식 보유

  * 대인 관계 기술

  * 정치 이해 및 처세 잘하기

소프트웨어 아키텍처란 무엇인지, 아키텍처 혹은 의사결정 부분에서 일반적으로 어떤 오해가 있는지에 대한 논의, 개발과 아키텍처가 어떻게 다른지, 아키텍트가 하는 일, 올바르게 고민하는 방법 등을 안내하며 아키텍트가 고려하고 다루어야 하는 기술에 대해 친절히 설명해 줍니다. 적절한 예시, 흥미로운 박스 내용, POC, 부분적인 코드의 예를 통해 구체적으로 설명하여 개발 경험이 풍부한 호기심 많은 독자가 지루해 하지 않게 구성되어 있습니다. 또한, 아키텍트 임무 특유의 트레이드오프 관계 요소들로 인해 답이 없는 문제를 생각할 경우가 생기는데, 과장하거나 치우침 없이 저자의 경험에 기반하여 솔직하고 올바른 방향이라고 생각하는 부분을 강조하여 말해주고 있습니다.

또한 마인드맵으로 만든 것 같은 경험 있는 사람의 생각을 직관적 도표로 표현한듯한 삽화는 안개같이 실체 없는 구름 속에서 목표 지향적으로 근두운을 잡길 원하는 마음의 아키텍트 입문자들이 방향을 정하는데 큰 도움이 됩니다.

도서는 크게 아래 3개의 파트로 나누어져 있습니다.

1부 기초 : 소프트웨어 아키텍처 구성하는 기본 요소와 아키텍처를 다루는 기본 소양에 대한 내용과 아키텍트와 개발자의 차이점을 설명합니다.

2부 아키텍처 스타일의 세계 : 레이어드, 파이프라인, 마이크로커널, 서비스 기반, 이벤트 기반, 공간 기반, 오케스트레이션 기반 등 서비스 전체의 구조를 결정하는 아키텍처 디자인 패턴에 대해 설명하고, 이를 선택하는 방법을 설명합니다. 각 아키텍처 특성에 대해 배포, 탄력, 진화, 모듈, 성능, 신뢰, 확장, 단순 등 각 고려 항목을 나열하고 별점으로 평가한 부분은 단연 도서 내용 중 백미라고 볼 수 있습니다.

3부 테크닉과 소프트 스킬 : 아키텍처를 결정하기 위한 회의 방법, 리스크 분석/평가, 프레젠테이션 등 개발자, 다른 이해관계자들과 협력하는데 필요한 여러 기법과 소프트스킬에 대해 설명합니다.

실제 두 저자는 소프트웨어 아키텍트로 활동하고 있고, 특히 닐 포드는 마틴 파울러로 유명한 쏘우트웍스의 컨설턴트입니다. 역자 또한 개발자로 시작한 현직 아키텍트로, 저자와 역자 모두 실제 아키텍트의 경험을 기반으로 책이 탄생했습니다.

"아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히게 마련입니다. ... 아키텍트는 회사에서 정치를 잘하면서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 합니다. ... 거의 모든 결정을 정당화하고 반대 세력에 맞서 싸울 준비를 갖추어야 합니다. ... 협상 기술은 ... 하나의 장으로 담았습니다."

이렇게 글을 쓸 수 있다는 것은 아마도 경험이 있는 저자와 역자이기에 가능했을 것입니다.

책에서도 언급되었지만 개발의 발전 속도보다 아키텍처의 발전 속도가 더 빠른 경향이 있습니다. 개발은 여전히 C/C++, Java가 필요하지만, 레거시 및 최신 기술을 모두 포용하기 위해 대두되었던 SOA(Service Oriented Architecture)는 특유의 복잡함으로 인해 이제 구시대 방식이 되었고 DevOps 등 개발과 운영을 한번에 고려하는 방식이 주목받으며 심플한 아키텍처가 대세가 되는 것이 아마도 기술과 아키텍처의 속도 차이를 단편적으로 알 수 있는 좋은 예라 생각됩니다. 따라서, 예를 들어 '이벤트 기반 아키텍처 스타일' 중 일부 내용이나 구성요소들 연결을 위해 항상 네트워크 프로토콜만을 고려하는 등 이론에 치우치거나 조금은 지난 경험인 내용이 포함되어 있기도 합니다.

이런 지엽적 부분을 제외하면, 본 도서는 방대하고 추상적이며 정답 없는 아키텍트 세계를 실제 아키텍트 선배가 진심어린 눈으로 설명해 주듯 설득력 있는 조언의 내용이 가득합니다. 이를 바탕으로, 제가 편집자였다면 "소프트웨어 아키텍트 101"보다는 "소프트웨어 아키텍트를 준비하는 히치하이커를 위한 안내서"로 정했을 것 같습니다.

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