클라우드 애플리케이션 아키텍처 패턴 - 클라우드 전환은 서버 이전이 아니라 설계의 문제

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

들어가며

클라우드 애플리케이션 아키텍처 패턴 도서

“클라우드 전환”이라는 말을 들었을 때, 처음에는 인프라 이전을 먼저 떠올렸다.
온프레미스 서버를 AWS나 Azure 같은 환경으로 옮기면 클라우드 전환이 된다고 생각했다.

그런데 실무에서 시스템을 오래 운영하다 보면, 어느 순간 변경이 두려워지는 시기가 온다.
주문 로직을 손봤는데 결제 영역에서 예기치 못한 문제가 발생하고, 상품 옵션 구조를 바꿨더니 정산 로직까지 영향이 번지는 일이 반복된다.
이런 문제는 단순히 코드량이 많아서 생기는 것이 아니라, 시스템의 책임 경계가 명확하지 않아서 생기는 문제라고 어렴풋이 느끼고 있었다.

한빛미디어의 클라우드 애플리케이션 아키텍처 패턴 은 그런 고민에 대한 답을 정리해 준 책이다.
특정 클라우드 서비스의 사용법을 알려주는 책이 아니라, 클라우드 환경에서 애플리케이션을 어떻게 설계하고 점진적으로 현대화할 것인가를 다룬다.

이 책은 “무엇을 누르세요” 가 아니라 “왜 이렇게 나누어야 하는가” 를 묻는다.
그 점에서 기술 매뉴얼이라기보다 아키텍처 사고방식을 다루는 책에 가까웠다.

마이크로서비스, 크기보다 중요한 것

마이크로서비스라고 하면 흔히 “큰 시스템을 작은 서비스 여러 개로 쪼개는 구조”라고 이해한다.
나 역시 한동안 그렇게 생각했고, 컨트롤러 단위나 기능 단위로 서비스를 나누면 그것이 마이크로서비스라고 여겼다.

이 책은 그 통념을 차분히 짚어준다.
마이크로서비스의 본질은 크기를 작게 만드는 것이 아니라, 비즈니스 책임과 도메인 경계로 시스템을 나누는 것이라는 점이다.

크기만으로 분리한 시스템은 오히려 복잡도를 키운다.
서비스 간 호출이 많아지고, 한 곳의 장애가 다른 영역으로 쉽게 번진다.
결국 그것은 마이크로서비스가 아니라 분산된 형태의 모놀리식이 되어버린다.

바운디드 콘텍스트, ‘조의 피자’에서 정리된 개념

이 책에서 가장 인상 깊었던 개념은 단연 바운디드 콘텍스트(Bounded Context) 였다.

바운디드 콘텍스트는 특정 도메인 안에서 용어, 규칙, 데이터, 행위가 일관되게 적용되는 논리적 경계를 의미한다.
같은 단어라도 어떤 도메인에 속해 있느냐에 따라 의미가 달라질 수 있고, 시스템 설계는 바로 그 경계를 명확히 잡는 데에서 출발해야 한다는 것이다.

말로만 설명하면 추상적인 개념이지만, 책에 등장하는 ‘조의 피자’ 예시를 따라가다 보면 자연스럽게 이해된다.

조의 피자 도메인 예시

피자 주문이라는 하나의 업무도 자세히 들여다보면 다음과 같이 나눌 수 있다.

하위 도메인	피자가 의미하는 것
Order Pizza	“주문 대상” — 피자 종류, 배송 주소, 결제 정보가 중요한 영역
Prepare Pizza	“조리 대상” — 준비, 굽기, 포장 상태가 중요한 영역
Deliver Pizza	“배송 대상” — 출발, 이동, 도착 여부가 중요한 영역

같은 “피자”라는 단어를 사용하더라도 영역마다 의미하는 상태와 책임이 다르다.
주문 영역에서의 피자와 조리 영역에서의 피자, 배송 영역에서의 피자는 결국 다른 모델로 다루어져야 한다는 뜻이다.

이 부분을 읽으면서 그동안 작성했던 코드가 자연스럽게 떠올랐다.
하나의 Order 객체에 주문, 결제, 배송, 정산 정보를 모두 담아두고 사용해 왔는데, 시간이 지날수록 이 객체가 손대기 어려워지던 이유가 분명해졌다.
여러 도메인의 책임이 하나의 모델에 섞여 있었기 때문이었다.

이 책은 그런 모호한 경험에 이름을 붙여준다.
바운디드 콘텍스트는 단순한 기술 용어가 아니라, 복잡한 시스템을 이해하기 위한 사고의 도구라는 점을 다시 확인할 수 있었다.

마이크로서비스가 정답이 아닐 때

이 책에서 좋게 느낀 또 하나의 지점은, 저자가 마이크로서비스를 만능 해법으로 제시하지 않는다는 점이다.

“잘못 나누면 오히려 복잡도만 늘어난다.”

서비스를 분리할수록 새로운 문제들이 함께 따라온다.

서비스 간 네트워크 통신과 지연
데이터 정합성 유지의 어려움
장애 전파와 회복 전략
배포 단위의 증가
분산 추적과 모니터링 비용

저자는 이러한 트레이드오프를 회피하지 않고, 언제 나누지 않는 것이 더 나은가까지 함께 고민하게 한다.
“작게 나누는 것”이 아니라 “잘 나누는 것”이 본질이라는 메시지가 책 전체에 일관되게 흐른다.

이런 분께 추천합니다

모놀리식 시스템을 마이크로서비스로 점진적으로 전환하려는 백엔드 개발자
“마이크로서비스 = 작게 나누기”로 이해하고 있는 2~5년 차 개발자
회사에서 클라우드 전환 논의가 시작된 시점에 있는 개발자
도메인 주도 설계(DDD)를 들어보았지만, 실무에 어떻게 적용할지 막막한 분
시스템 설계에 대한 답변이 자꾸 추상적으로 흐르는 것이 고민인 분
사수 없이 혼자 아키텍처를 고민하고 있는 1인 백엔드 또는 작은 팀의 리드 개발자

반대로, 특정 클라우드 서비스의 실습(Docker 명령어, Kubernetes 배포, Spring Cloud 예제)을 기대하는 분에게는 다른 실습서가 더 적합할 수 있다.
이 책은 도구의 사용법보다, 시스템을 어떤 기준으로 설계하고 나눌 것인지를 다룬다.

정리

클라우드 애플리케이션 아키텍처 패턴 은 한 문장으로 정리하면 다음과 같다.

“클라우드 전환은 서버를 옮기는 일이 아니라, 애플리케이션의 책임과 경계를 다시 설계하는 일이다.”

이 책은 마이크로서비스를 단순히 “작게 자르는 기술”이 아니라, 도메인과 책임을 기준으로 시스템을 나누는 사고방식으로 다시 보게 해주었다.
특히 바운디드 콘텍스트라는 개념 하나만으로도, 그동안 모호하게 느꼈던 설계 문제들에 이름을 붙일 수 있게 됐다.

읽는 내내 그동안 짜온 코드와 운영해 온 시스템이 머릿속에 함께 떠올랐다.
좋은 기술서는 정보를 전달하는 데서 그치지 않고, 자신의 경험을 다시 보게 만든다고 생각한다. 이 책은 그런 책이었다.

다음 설계 회의에서는 기능을 어디에 둘지 묻기 전에, 그 기능이 어느 도메인의 책임인지부터 묻게 될 것 같다.

피드백은 언제나 환영합니다.