길벗 27차 개발자 리뷰어 활동을 위해 책을 협찬 받아 작성된 서평입니다.
1. 책을 읽게 된 계기
점점 구현을 넘어 시스템 전체를 설계하는 관점에 관심을 가지게 되었습니다. 작게는 하나의 컴포넌트를 어떻게 조직화할지부터, 크게는 여러 팀이 협업할 수 있는 구조를 어떻게 설계해야 하는지에 이르기까지, 단순한 구현을 넘어선 더 큰 그림을 보고 싶은 호기심이 생겼죠.
단순한 기술 지식이 아닌, 아키텍처를 대하는 태도와 사고방식을 배우고 싶었기 때문에 『이펙티브 소프트웨어 아키텍처』를 읽기 시작했습니다.
2. 책의 핵심 내용
아키텍처가 제공하는 가장 핵심적인 가치를 하나만 꼽는다면 그것은 복잡성 관리라고 할 수 있습니다. 복잡성은 소프트웨어의 본질적인 기능을 저해하고 예측 불가능한 동작을 유발하며 사용자 신뢰를 떨어뜨립니다. 또 결함으로 이어져 소프트웨어 안정성을 해치 기도 하고, 장애를 전파시켜 작은 오류로 대규모 중단 사태를 만들기도 합니다. 나아가 복잡한 시스템은 이해하기 어려워 더 단순한 형태나 구조로 개선하기 어럽게 합니다. 즉, 복잡성은 소프트웨어의 가장 큰 적이며, 체계적인 아키텍처 설계야말로 이를 방어할 수 있는 최선의 방법이라고 할 수 있습니다.
『이펙티브 소프트웨어 아키텍처』, 들어가며 중에서
2.1 소프트웨어 아키텍처와 소프트웨어 설계의 구분
『이펙티브 소프트웨어 아키텍처』는 가장 먼저, "소프트웨어 아키텍처가 무엇인지"를 명확히 정의하는 것부터 시작합니다.
여기서 중요한 점은 흔히 "설계(design)"와 "아키텍처(architecture)"를 섞어 쓰지만, 두 개념은 엄연히 다르다는 걸 강조한다는 거였어요.
- 소프트웨어 설계는 시스템의 특정 릴리스(release), 특정 버전, 특정 기능 구현을 위해 구체적인 사항을 결정하고, 변경사항을 반영하는 과정을 말합니다.
- 소프트웨어 아키텍처는 이런 "구체적인 설계 작업들"이 반복될 수 있도록 만드는 기본 뼈대와 패턴, 원칙의 집합입니다. 즉, 좋은 아키텍처는 "좋은 설계"를 단발성이 아니라, 수백 번 수천 번 반복해서 만들어낼 수 있는 기반을 마련해줍니다.
책은 이 차이를 명확히 정리하면서, 아키텍처는 단순한 한 번의 설계가 아니라, 시스템이 시간이 지나면서 겪을 모든 변화와 확장을 지탱할 수 있도록 설계된 '진화 가능한 틀' 이라는 중요한 메시지를 전달합니다.
2.1 아키텍처의 본질
아키텍처를 단순히 다이어그램이나 기술 스택으로 치환하는 실수를 경계합니다.
아키텍처는 시스템의 주요 의사결정(Decisions)의 집합이라고 정의하며,
이 의사결정들이 어떻게 시스템의 유연성, 유지보수성, 확장성에 영향을 주는지를 상세히 설명합니다.
2.2 아키텍트의 역할
아키텍트는 단순히 기술적인 ‘디자인’만 하는 사람이 아니라, 비즈니스 목표를 이해하고, 이해관계자와 커뮤니케이션하며, 갈등을 조정하는 역할까지 수행해야 한다고 강조합니다. 특히 ‘커뮤니케이션의 중요성’을 반복해서 언급하는데, 이는 실제 실무에서 아키텍트가 기술자만이 아니라 "조율자"여야 한다는 현실적인 통찰을 줍니다.
2.3 아키텍처 설계 방법론
변화는 항상 예측할 수 없으며, 그렇기 때문에 아키텍처는 '완성'하는 것이 아니라 '진화'시켜야 한다는 철학을 제시합니다. 초기에 모든 것을 완벽히 설계하려는 시도는 위험하며, 오히려 중요한 결정(핵심 의사결정)은 명확히 하되, 나머지는 점진적으로 설계하는 방법을 추천합니다.
3. 좋았던 점
3.1 현실적인 시각
이 책은 아키텍처 이론서가 아니었어요. 현실 세계에서는 모든 요구사항을 처음부터 알 수 없고, 모든 기술 선택이 완벽할 수 없다는 사실을 인정하는 데서 출발합니다. 그런 ‘현실성’이 되려 이 책을 더욱 신뢰할 수 있게 만들었습니다.
3.2 변화 관리의 중요성 강조
빠르게 변화하는 시대에 맞게 아키텍처도 "변화에 강한 구조"로 설계해야 한다는 메시지가 인상 깊었습니다.
'처음에 완벽히 설계한다'는 환상을 버리고, 설계의 핵심은 "변화를 받아들일 수 있는 유연성" 이라는 것을 설득력 있게 풀어냅니다. 이 점은 특히 빠르게 변화하는 스타트업 환경이나, 제품 주기가 짧은 프로젝트에 적용할 때 큰 통찰을 줍니다.
3.3 아키텍트의 소프트 스킬 강조
기술적인 설계 능력뿐 아니라, 이해관계자와 소통하고, 팀을 설득하며, 조직 내 갈등을 중재하는 능력을 아키텍트의 핵심 역량으로 다루는 부분이 특히 좋았습니다.
기술자적 관점만으로는 해결할 수 없는 문제들이 아키텍처에서는 더 빈번하게 나타난다는 사실을 자연스럽게 받아들이게 해줍니다.
4. 아쉬웠던 점
4.1 기술적인 깊이에 대한 아쉬움
책이 지향하는 대상이 ‘개념과 철학’을 다루는 쪽이다 보니, 구체적인 시스템 설계 사례나 마이크로서비스, 도메인 주도 설계(DDD), 이벤트 소싱 같은 구체적인 아키텍처 패턴에 대한 깊이 있는 다루기는 상대적으로 부족했습니다.
실제 대규모 시스템에서 아키텍처를 어떻게 적용했는지에 대한 예시가 조금 더 많았더라면 실질적인 적용에 더 도움이 되었을 것 같다는 아쉬움이 남습니다.
4.2 분량에 따른 압축된 전개
비교적 짧은 분량 안에 아키텍처의 철학부터 조직 운영까지 담으려다 보니, 일부 챕터에서는 다소 빠르게 주제가 넘어가는 인상을 받았습니다.
특히 아키텍처를 처음 공부하는 독자에게는 약간 더 친절한 설명이나 추가적인 사례가 있었다면 더 좋았을 것 같습니다.
5. 느낀 점
『이펙티브 소프트웨어 아키텍처』는 단순히 좋은 구조를 설계하는 법을 알려주는 책이 아니었어요.
‘어떻게 하면 변화를 견딜 수 있는 시스템을 만들 수 있을지’, ‘어떻게 하면 기술과 조직 사이를 잇는 다리를 놓을지’ 함께 고민하게 만드는 책입니다.
