클라우드 애플리케이션 아키텍처 패턴 - 클라우드 전환은 서버 이전이 아니라 설계의 문제
“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”
목차
- 왜 이 책을 읽었나 - 클라우드 전환을 서버 이전이라고 생각했다
- 12개 장 한눈에 보기 - 이 책이 실제로 다루는 범위
- 마이크로서비스 - 크기가 아니라 경계의 문제
- 바운디드 콘텍스트 - 조의 피자에서 정리된 개념
- 마이크로서비스가 정답이 아닐 때
- 이런 분께 추천합니다
- 이런 분께는 권하지 않습니다
- 정리 - 클라우드 전환은 설계의 문제
왜 이 책을 읽었나 - 클라우드 전환을 서버 이전이라고 생각했다
“클라우드 전환”이라는 말을 들었을 때, 처음에는 인프라 이전을 먼저 떠올렸다. 온프레미스 서버를 AWS나 Azure 같은 환경으로 옮기면 클라우드 전환이 된다고 생각했다.
그런데 실무에서 시스템을 오래 운영하다 보면, 어느 순간 변경이 두려워지는 시기가 온다. 주문 로직을 손봤는데 결제 영역에서 예기치 못한 문제가 발생하고, 상품 옵션 구조를 바꿨더니 정산 로직까지 영향이 번지는 일이 반복된다.
이런 문제는 단순히 코드량이 많아서 생기는 것이 아니라, 시스템의 책임 경계가 명확하지 않아서 생기는 문제라고 어렴풋이 느끼고 있었다.
한빛미디어의 클라우드 애플리케이션 아키텍처 패턴은 그런 고민에 대한 답을 정리해 준 책이다. 특정 클라우드 서비스의 사용법을 알려주는 책이 아니라, 클라우드 환경에서 애플리케이션을 어떻게 설계하고 점진적으로 현대화할 것인가를 다룬다.
이 책은 “무엇을 누르세요”가 아니라 “왜 이렇게 나누어야 하는가”를 묻는다. 그 점에서 기술 매뉴얼이라기보다 아키텍처 사고방식을 다루는 책에 가까웠다.
12개 장 한눈에 보기 - 이 책이 실제로 다루는 범위
724쪽, 0장부터 11장까지 총 12개 장이다. 두께에 겁먹기 전에 어디까지 다루는 책인지 먼저 짚어두는 편이 낫겠다.
| 구분 | 장 | 다루는 것 |
|---|---|---|
| 출발점 | 0~2장 | 클라우드 수용 단계 / 클라우드 애플리케이션이란 / 커다란 진흙 덩어리 · 모듈러 모놀리식 · 분산 아키텍처 |
| 클라우드 네이티브 | 3장 | 애플리케이션 패키지 · 서비스 API · 스테이트리스 · 복제 가능 · 외부 설정 · 백엔드 서비스 |
| 마이크로서비스 | 4~5장 | 도메인·어댑터 마이크로서비스 · 디스패처 · 자체 관리 데이터 스토어 / 적절한 크기 · 이벤트 스토밍 · 바운디드 콘텍스트 · 애그리거트 · 오염 방지 계층 |
| 이벤트와 데이터 | 6~7장 | 이벤트 코레오그래피 · 이벤트 백본 · 이벤트 소싱 / 데이터베이스 선택 · 폴리글랏 퍼시스턴스 · 명령-질의 책임 분리(CQRS) |
| 클라이언트 | 8장 | 브라우저 · SPA · 마이크로 프런트엔드 · 모바일 · CLI · 퍼블릭 API |
| 전환 실행 | 9~11장 | 리프트 앤 시프트 · 컨테이너화 · 길 닦기 / 모놀리식 점진적 대체 · 가느다란 실금 찾기 · 컴포넌트 추출 · 플레이백 테스트 / 총정리 |
이렇게 놓고 보면 책의 성격이 분명해진다. 제목의 ‘패턴’이 그냥 붙은 말이 아니다. 각 장이 ~란 무엇인가 → 패턴 나열 → 결론: ~ 정리 구조로 똑같이 반복된다. 사실상 패턴 카탈로그에 가깝다.
그래서 처음부터 끝까지 정독할 필요가 없다. 지금 필요한 패턴을 찾아 읽고, 그 장의 결론으로 맥락을 잡는 식으로 써도 된다.
한 가지 더 눈에 띈 건 2장의 커다란 진흙 덩어리(Big Ball of Mud) 다. 공저자인 조셉 요더가 1997년 논문으로 이름 붙인 바로 그 개념인데, 자기가 명명한 안티패턴에서 출발해 12개 장에 걸쳐 그 반대편으로 걸어가는 구성인 셈이다.
그리고 이 책의 진짜 결론은 9~10장에 있다. 앞의 여덟 장이 “무엇을 지향하는가”라면, 9~10장은 “이미 돌아가는 시스템을 어떻게 거기까지 데려가는가”를 다룬다. 실무자에게 가장 아쉬운 부분이 보통 여기인데, 이 책은 여기에 두 개 장을 온전히 쓴다.
마이크로서비스 - 크기가 아니라 경계의 문제
마이크로서비스라고 하면 흔히 “큰 시스템을 작은 서비스 여러 개로 쪼개는 구조”라고 이해한다. 나 역시 한동안 그렇게 생각했고, 컨트롤러 단위나 기능 단위로 서비스를 나누면 그것이 마이크로서비스라고 여겼다.
이 책은 그 통념을 차분히 짚어준다. 마이크로서비스의 본질은 크기를 작게 만드는 것이 아니라, 비즈니스 책임과 도메인 경계로 시스템을 나누는 것이라는 점이다.
크기만으로 분리한 시스템은 오히려 복잡도를 키운다. 서비스 간 호출이 많아지고, 한 곳의 장애가 다른 영역으로 쉽게 번진다. 결국 그것은 마이크로서비스가 아니라 분산된 형태의 모놀리식이 되어버린다.
바운디드 콘텍스트 - 조의 피자에서 정리된 개념
이 책에서 가장 인상 깊었던 개념은 단연 바운디드 콘텍스트(Bounded Context) 였다.
바운디드 콘텍스트는 특정 도메인 안에서 용어, 규칙, 데이터, 행위가 일관되게 적용되는 논리적 경계를 의미한다. 같은 단어라도 어떤 도메인에 속해 있느냐에 따라 의미가 달라질 수 있고, 시스템 설계는 바로 그 경계를 명확히 잡는 데에서 출발해야 한다는 것이다.
말로만 설명하면 추상적인 개념이지만, 책에 등장하는 ‘조의 피자’ 예시를 따라가다 보면 자연스럽게 이해된다.
피자 주문이라는 하나의 업무도 자세히 들여다보면 다음과 같이 나눌 수 있다.
| 하위 도메인 | 피자가 의미하는 것 |
|---|---|
| Order Pizza | “주문 대상” — 피자 종류, 배송 주소, 결제 정보가 중요한 영역 |
| Prepare Pizza | “조리 대상” — 준비, 굽기, 포장 상태가 중요한 영역 |
| Deliver Pizza | “배송 대상” — 출발, 이동, 도착 여부가 중요한 영역 |
같은 “피자”라는 단어를 사용하더라도 영역마다 의미하는 상태와 책임이 다르다. 주문 영역에서의 피자와 조리 영역에서의 피자, 배송 영역에서의 피자는 결국 다른 모델로 다루어져야 한다는 뜻이다.
이 부분을 읽으면서 그동안 작성했던 코드가 자연스럽게 떠올랐다. 하나의 Order 객체에 주문, 결제, 배송, 정산 정보를 모두 담아두고 사용해 왔는데, 시간이 지날수록 이 객체가 손대기 어려워지던 이유가 분명해졌다. 여러 도메인의 책임이 하나의 모델에 섞여 있었기 때문이었다.
이 책은 그런 모호한 경험에 이름을 붙여준다. 바운디드 콘텍스트는 단순한 기술 용어가 아니라, 복잡한 시스템을 이해하기 위한 사고의 도구라는 점을 다시 확인할 수 있었다.
참고로 5장은 바운디드 콘텍스트 하나만 다루지 않는다. 적절한 크기, 이벤트 스토밍, 도메인 이벤트, 애그리거트, 오염 방지 계층까지 이어지는데, 실무에서 경계를 실제로 긋는 작업에는 이 조합이 함께 필요하다.
마이크로서비스가 정답이 아닐 때
이 책에서 좋게 느낀 또 하나의 지점은, 저자가 마이크로서비스를 만능 해법으로 제시하지 않는다는 점이다.
“잘못 나누면 오히려 복잡도만 늘어난다.”
서비스를 분리할수록 새로운 문제들이 함께 따라온다.
- 서비스 간 네트워크 통신과 지연
- 데이터 정합성 유지의 어려움
- 장애 전파와 회복 전략
- 배포 단위의 증가
- 분산 추적과 모니터링 비용
저자는 이러한 트레이드오프를 회피하지 않고, 언제 나누지 않는 것이 더 나은가까지 함께 고민하게 한다. 2장에 ‘모듈러 모놀리식’이 분산 아키텍처와 나란히 놓여 있는 것도 같은 맥락이다. 쪼개지 않은 상태도 하나의 선택지로 취급한다.
“작게 나누는 것”이 아니라 “잘 나누는 것”이 본질이라는 메시지가 책 전체에 일관되게 흐른다.
이런 분께 추천합니다
- 모놀리식을 점진적으로 전환하려는 백엔드 개발자 — 9~10장이 통째로 이 주제다
- “마이크로서비스 = 작게 나누기”로 이해하고 있는 2~5년 차 — 4~5장에서 그 통념이 정리된다
- 회사에서 클라우드 전환 논의가 막 시작된 개발자 — 0장의 ‘클라우드 수용 단계’가 논의의 공통 언어를 만들어준다
- DDD를 들어봤지만 실무 적용이 막막한 분 — 5장이 이벤트 스토밍부터 오염 방지 계층까지 한 흐름으로 묶어준다
- 1인 백엔드 또는 작은 팀의 리드 개발자 — 설계 판단의 근거를 패턴 이름으로 정리해두고 싶은 경우
추천하는 읽기 순서는 이렇다. 724쪽을 앞에서부터 읽을 필요는 없다.
- 0장으로 전체 지도와 용어를 잡는다.
- 2장에서 지금 우리 시스템이 어디쯤인지 확인한다. (진흙 덩어리 / 모듈러 모놀리식 / 분산)
- 5장을 정독한다. 이 책에서 가장 밀도가 높은 장이다.
- 지금 발등에 떨어진 주제로 점프한다. (데이터 → 7장, 이벤트 → 6장, 전환 → 9~10장)
이런 분께는 권하지 않습니다
- 특정 클라우드 실습을 기대하는 분 — Docker 명령어, Kubernetes 배포, Spring Cloud 예제는 없다. 도구 사용법이 아니라 설계 기준을 다룬다.
- 이미 마이크로서비스를 설계·운영해 온 아키텍트 — 패턴 카탈로그 성격이라 각 패턴의 깊이는 얕은 편이다. 다만 팀의 공통 용어집으로는 쓸 만하다.
- 처음부터 끝까지 완독할 책을 찾는 분 — 724쪽에 패턴이 촘촘히 나열되는 구성이라, 통독을 목표로 잡으면 중간에 지친다.
- 당장 코드에 붙일 답을 찾는 분 — 이 책이 주는 건 결론이 아니라 판단 기준이다.
정리 - 클라우드 전환은 설계의 문제
클라우드 애플리케이션 아키텍처 패턴은 한 문장으로 정리하면 다음과 같다.
“클라우드 전환은 서버를 옮기는 일이 아니라, 애플리케이션의 책임과 경계를 다시 설계하는 일이다.”
이 책은 마이크로서비스를 단순히 “작게 자르는 기술”이 아니라, 도메인과 책임을 기준으로 시스템을 나누는 사고방식으로 다시 보게 해주었다. 특히 바운디드 콘텍스트라는 개념 하나만으로도, 그동안 모호하게 느꼈던 설계 문제들에 이름을 붙일 수 있게 됐다.
읽는 내내 그동안 짜온 코드와 운영해 온 시스템이 머릿속에 함께 떠올랐다. 좋은 기술서는 정보를 전달하는 데서 그치지 않고, 자신의 경험을 다시 보게 만든다고 생각한다. 이 책은 그런 책이었다.
다음 설계 회의에서는 기능을 어디에 둘지 묻기 전에, 그 기능이 어느 도메인의 책임인지부터 묻게 될 것 같다.
피드백은 언제나 환영입니다.