한빛미디어

아키텍처 결정 앞에서 망설이는 순간, 펼쳐보게 되는 책

시니어 개발자로서 팀을 이끌다 보면 어느 순간 코드를 넘어선 질문들과 마주하게 된다. "이 기능을 새로운 서비스로 분리해야 할까, 아니면 기존 모놀리스에 추가해야 할까?" "이벤트 기반으로 전환하면 정말 나아질까?" 같은 질문들 말이다. 이런 질문 앞에서 확신을 갖기란 쉽지 않다. 특히 그 결정이 향후 몇 년간 팀 전체의 생산성을 좌우할 수 있다는 걸 알기에 더 신중해진다.

​

"소프트웨어 아키텍처 The Basics 2판"은 바로 그런 순간을 위한 책이다. 이 책을 읽으면서 가장 먼저 든 생각은 "이런 책을 5년 전에 읽었더라면"이었다. 물론 그때 읽었어도 지금만큼 와닿지는 않았을 것 같다. 실제로 삽질을 해봐야, 잘못된 결정의 대가를 치러봐야 이 책의 가치를 제대로 느낄 수 있다.

​

트레이드오프라는 불편한 진실

책을 관통하는 핵심 메시지는 간단하지만 강력하다. "소프트웨어 아키텍처의 모든 것은 트레이드오프다." 처음엔 너무 당연한 얘기 아닌가 싶었는데, 책을 읽다 보니 우리가 얼마나 이 원칙을 무시하고 있었는지 깨닫게 됐다.

예를 들어 우리 팀은 작년에 마이크로서비스 전환을 검토했다. 당시 팀원들과 나눈 대화를 떠올려보면 "마이크로서비스로 가면 확장성도 좋아지고, 배포도 독립적으로 할 수 있고, 팀 자율성도 높아진다"는 장점만 나열했던 것 같다. 책에서는 이런 접근을 정확히 짚어낸다. 분산 아키텍처로 가면 네트워크 지연, 데이터 일관성 문제, 운영 복잡도 증가라는 대가를 치러야 한다고.

​

실제로 4장부터 7장까지 아키텍처 특성을 다루는 부분을 읽으면서, 우리가 얼마나 많은 것들을 간과했는지 새삼 느꼈다. 성능과 보안, 확장성과 단순성, 가용성과 비용... 이 모든 것을 동시에 만족시키는 아키텍처는 없다. 결국 비즈니스 우선순위에 따라 무엇을 취하고 무엇을 포기할지 결정해야 하는데, 이 책은 그 판단 기준을 제시한다.

​

현장에서 바로 써먹을 수 있는 실용성

이론서가 아니라는 점이 이 책의 가장 큰 강점이다.

​

PART 02에서 다루는 각 아키텍처 스타일마다 동일한 구조로 설명하는데, 이게 정말 실무적이다.

⦁ 토폴로지: 실제 구조가 어떻게 생겼는지

⦁ 데이터 토폴로지: 데이터는 어떻게 흐르는지

⦁ 클라우드 고려 사항: 클라우드 환경에서 주의할 점

⦁ 일반적인 위험: 이 스타일의 함정은 무엇인지

⦁ 팀 토폴로지: 이 아키텍처에 맞는 팀 구성은?

특히 '일반적인 위험' 부분이 유용했다. 예를 들어 계층형 아키텍처(Chapter 10)에서 "싱크홀 안티패턴"을 설명하는데, 우리 레거시 시스템에서 정확히 이런 문제가 있었다. 요청이 각 레이어를 그냥 통과만 하면서 아무 의미 있는 처리도 안 하는... 이걸 읽으면서 "아, 이게 안티패턴이었구나" 하고 무릎을 쳤다.

​

11장의 모듈형 모놀리스는 개인적으로 가장 인상 깊었던 부분이다. 요즘 분위기가 "무조건 마이크로서비스"인 것 같은데, 이 책은 현실적인 대안을 제시한다. 모놀리스지만 내부를 모듈로 잘 나누면 대부분의 이점을 가져갈 수 있다는 것. 실제로 우리 팀도 서비스 분리 전에 먼저 모듈화를 시도해보기로 했는데, 이 챕터가 큰 도움이 됐다.

​

클라우드 시대를 제대로 반영한 2판

1판과 비교했을 때 2판의 가장 큰 변화는 클라우드 관련 내용이 대폭 강화됐다는 점이다. 각 아키텍처 스타일마다 '클라우드 고려 사항' 섹션이 추가됐고, 아키텍처 특성에도 클라우드 네이티브 특성들이 포함됐다.

⦁ 온디맨드 확장성

⦁ 온디맨드 탄력성

⦁ 존 기반 가용성

⦁ 지역 기반 개인정보보호

이런 특성들은 이제 선택이 아니라 필수다. 특히 AWS나 Azure 같은 클라우드 환경에서 작업하는 개발자라면 반드시 고려해야 하는 요소들이다. 우리 팀도 작년에 온프레미스에서 AWS로 마이그레이션했는데, 당시 이 책이 있었으면 훨씬 수월했을 것 같다.

​

예를 들어 16장 공간 기반 아키텍처에서 클라우드 환경의 자동 확장, 로드 밸런싱, 캐싱 전략을 다루는데, 실제 AWS 서비스들과 매핑해서 생각해보니 이해가 훨씬 잘 됐다. 책에서 제시하는 원칙들이 구체적인 클라우드 서비스 선택으로 이어지는 거다.

코드를 넘어선 영역: 사람과 조직

​

PART 03은 기술적인 내용보다 소프트 스킬에 집중한다. 처음엔 "이게 왜 아키텍처 책에 있지?" 싶었는데, 읽다 보니 이게 핵심이더라.

​

Chapter 24 '유능한 팀 만들기'는 실제로 겪은 상황들이 그대로 나온다. 아키텍트가 모든 결정을 독단적으로 내리면 팀이 무너진다는 것, 제약조건은 명확하게 주되 세부 구현은 팀에 맡겨야 한다는 것. 이런 내용들이 교과서적인 이야기가 아니라 실전 경험에서 우러나온 조언처럼 느껴졌다.

특히 '어느 정도까지 관여할 것인가?'라는 질문이 인상적이었다. 시니어 개발자로서 아키텍처 결정에 참여하다 보면, 어디까지 관여하고 어디서 멈춰야 할지 애매한 경우가 많다. 책에서는 이에 대한 실용적인 가이드라인을 제시한다. 전략적 결정은 함께하되, 전술적 구현은 신뢰하고 맡기라는 것.

​

Chapter 21의 아키텍처 결정 기록(ADR)도 당장 적용 가능한 실용적인 기법이다. 우리 팀도 중요한 기술 결정을 할 때 왜 그렇게 결정했는지 문서로 남기곤 했는데, 형식이 제각각이어서 나중에 찾아보기 어려웠다. ADR 템플릿을 적용하니 훨씬 체계적으로 관리할 수 있게 됐다.

"왜 이 결정을 내렸는가"를 명확히 문서화하면, 6개월 후 팀원이 바뀌어도, 컨텍스트를 잃어버려도 당시의 의사결정 맥락을 이해할 수 있다. 이게 레거시 시스템을 유지보수할 때 얼마나 중요한지는 다들 알 것이다.

실무에 적용하면서 느낀 점들

책을 읽고 나서 실제로 몇 가지를 적용해봤다.

1. 아키텍처 특성 우선순위 정하기

신규 프로젝트를 시작할 때 Chapter 5의 방법론을 그대로 따라해봤다. 도메인 요구사항에서 아키텍처 특성을 추출하고, 우선순위를 정하는 과정. 예전엔 "확장 가능하고, 안전하고, 빠르고..." 이렇게 모든 걸 다 만족시키려 했는데, 이제는 "우리 비즈니스에서 가장 중요한 3가지 특성은 뭔가?"를 먼저 묻는다.

결과적으로 불필요한 복잡도를 많이 줄일 수 있었다. 예를 들어 내부 관리 도구는 확장성보다 개발 속도와 유지보수성이 더 중요하다는 걸 명확히 하니, 계층형 아키텍처로 심플하게 가는 결정을 자신 있게 내릴 수 있었다.

​

2. 리스크스토밍 도입

Chapter 22의 리스크스토밍을 팀 회의에 도입했다. 새로운 아키텍처를 도입하기 전에 팀원들과 함께 포스트잇으로 리스크를 브레인스토밍하는 것. 처음엔 부정적인 얘기만 하는 것 같아 불편했는데, 실제로 해보니 사전에 많은 문제를 발견할 수 있었다.

특히 주니어 개발자들도 리스크를 제기할 수 있는 안전한 환경이 만들어졌다. "이거 괜찮을까요?"라고 조심스럽게 물었던 것들이 실제로 큰 문제가 될 수 있는 부분이었던 경우가 많았다.

​

3. 팀 토폴로지 재정비

각 아키텍처 스타일마다 '팀 토폴로지 고려 사항'이 있는데, 이게 생각보다 중요했다. 마이크로서비스를 제대로 운영하려면 팀 구조도 바뀌어야 한다는 것. 우리는 아키텍처만 바꾸고 팀 구조는 그대로 두려고 했는데, 책을 읽고 나니 그게 왜 문제인지 이해가 됐다.

결국 기능 중심 팀에서 서비스 중심 팀으로 재편했고, 각 팀이 자기 서비스에 대한 end-to-end 책임을 지도록 했다. 초반엔 혼란스러웠지만, 결과적으로 배포 속도도 빨라지고 팀 자율성도 높아졌다.

​

이 책이 아쉬운 점

완벽한 책은 없다. 몇 가지 아쉬운 점도 있었다.

첫째, 예제 코드가 거의 없다. 개념적인 설명은 훌륭하지만, 실제 구현 코드를 보고 싶을 때가 많았다. 특히 마이크로서비스 간 통신이나 이벤트 주도 아키텍처 같은 부분은 코드 예제가 있었으면 이해가 더 빨랐을 것 같다.

둘째, 특정 기술 스택에 대한 언급이 제한적이다. 이건 의도된 것이긴 한데(기술 중립적인 책이니까), 실무자 입장에서는 "그래서 이걸 Spring Boot로는 어떻게 구현하지?" 같은 질문이 남는다. 물론 이건 다른 책이나 문서를 참고하면 되긴 하다.

셋째, 분량이 꽤 된다. 630페이지를 다 읽으려면 시간 투자가 필요하다. 바쁜 실무자가 한 번에 쭉 읽기엔 부담스러울 수 있다. 다만 필요한 챕터만 골라서 읽어도 충분히 가치가 있으니, 레퍼런스처럼 활용하는 것도 방법이다.

​

누구에게 추천하는가

이 책은 다음과 같은 사람들에게 특히 유용할 것 같다:

시니어 개발자로서 아키텍처 결정에 참여하기 시작한 사람들

⦁ 코드 레벨을 넘어선 의사결정을 해야 하는데, 체계적인 방법론이 필요한 경우

⦁ "이게 정말 맞는 선택일까?" 하는 의구심이 들 때 판단 기준이 필요한 경우

레거시 시스템 개선을 고민하는 사람들

⦁ 모놀리스를 그대로 둘지, 모듈화할지, 서비스로 쪼갤지 결정해야 하는 경우

⦁ 현재 아키텍처의 문제점을 명확히 진단하고 싶은 경우

기술 리드나 테크 매니저

⦁ 팀의 기술 방향을 설정해야 하는 경우

⦁ 비즈니스 요구사항을 기술 결정으로 변환해야 하는 경우

반대로 프로그래밍 경험이 별로 없는 주니어 개발자에게는 너무 이른 감이 있다. 실제로 시스템을 설계하고 운영해본 경험이 있어야 책의 내용이 와닿는다. 최소 3~5년 정도 개발 경험이 있고, 시스템 전체를 바라볼 수 있는 시야가 생긴 다음에 읽는 게 좋을 것 같다.

​

결국 이 책이 주는 가장 큰 가치는 "정답"이 아니라 "사고의 틀"이다.

모든 결정에는 트레이드오프가 있고, 그 트레이드오프를 명확히 이해하고 설명할 수 있어야 한다. 기술은 수단이지 목적이 아니며, 아키텍처는 비즈니스를 위해 존재한다. 완벽한 아키텍처는 없으며, "지금 우리에게 가장 덜 나쁜" 선택을 하는 것이 현실이다.

이런 원칙들이 머릿속에 자리 잡으면, 새로운 기술이나 프레임워크가 나와도 흔들리지 않는다. "왜"를 물을 수 있기 때문이다. 그리고 그 "왜"를 팀원들에게, 경영진에게, 그리고 나 자신에게 설명할 수 있게 된다.

5년 전에 이 책을 읽었더라면 좋았을 거라고 했지만, 사실 지금 읽어서 다행이다. 이제야 이 책의 가치를 제대로 이해할 수 있으니까. 그리고 5년 후 다시 읽으면 또 다른 걸 얻을 것 같다. 경험이 쌓일수록 더 깊이 이해되는, 그런 책이다.