클라우드 애플리케이션 아키텍처 패턴 - 레거시 현대화와 클라우드 네이티브 전환을 위한 70가지 실무 전략
카일 브라운.바비 울프.조셉 요더 지음, 박수현 옮김 / 한빛미디어 / 2026년 3월
평점 :
장바구니담기


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


1. 이 책을 선택한 동기

그동안 클라우드에 배포한 경험은 많지만, '클라우드 네이티브 애플리케이션'이라는 표현으로는 생각해본 적 없었어요. 가장 많이 사용하는 GCP부터 AWS, Docker 등 활용하는 것은 많았지만 사실상 아키텍처 패턴을 잘 활용하지는 못했죠. 사용법만 알고 있었을 뿐입니다.


클리우드 애플리케이션 아키텍처 패턴은 "클리우드 네이티브"라는 말을 패턴으로 풀어준다는 점에서 저에게 매력적인 책이었어요.


2. 어떤 책인지

725페이지 분량은 어찌보면 꽤나 버거워 보이는 장수였지만, 반드시 순차적으로 각 장을 읽을 필요 없다고 서문에서 저자는 말합니다. 필요한 부분을 독립적으로 읽어도 된다고 하니 마음이 놓였고, 사실 순차적으로 흐름을 따라가기도 좋은 책이었어요.


1장: 클라우드 애플리케이션 기초 (스테이트리스, 불변성, 폴리글랏)

2장: 애플리케이션 아키텍처 패턴 (진흙 덩어리 → 모듈러 모놀리식 → 분산)

3장: 클라우드 네이티브 (12-Factor App, 컨테이너, 쿠버네티스)

4장: 마이크로서비스 아키텍처 (도메인 마이크로서비스)

5장: 마이크로서비스 설계 — DDD (엔티티, 값 객체, 애그리거트)

6장: 이벤트 주도 아키텍처 (비동기 통신, 메시지 큐)

7장: 클라우드 네이티브 데이터 관리 (폴리글랏 퍼시스턴스)

8장: 클라우드 네이티브 보안

9장: 관측 가능성 (로깅/메트릭/트레이싱)

10장: 애플리케이션 이전 및 현대화

각 장마다 항공권 예약, 피자 주문, 전자상거래 같은 구체적인 예시가 있어서 의외로 빨리 읽혔어요. 패턴 중심이라 지루할 수도 있는데 예시가 적절히 섞여 있어서 좋았어요.


3. 특히 인상적이었던 점

"큰 진흙 덩어리가 항상 나쁜 건 아니다" (2장)

진흙 덩어리(Big Ball of Mud)는 안티 패턴으로 알고 있었습니다. 그런데 저자는 초기 스타트업이나 PoC 단계에서는 오히려 진흙 덩어리가 생산성이 높다고 말해요. 중요한 건 "언제 모듈러 모놀리식으로 넘어갈지 아는 것"이라고요.


이건 마치 TDD에서 "테스트를 먼저 쓰라"가 아니라 "언제 테스트를 써야 하는지 아는 것"과 같은 맥락이었어요. 지


12-Factor App은 체크리스트다 (3장)

12-Factor App이라는 개념은 처음 알았습니다. 이 책에서 "이건 철학이 아니라 체크리스트"라고 정의한 게 와닿았어요. '설정은 환경 변수로 분리했나?', '로그는 스트림으로 처리하나?', '프로세스는 무상태인가?' 이걸 하나씩 체크하면 클라우드 네이티브 앱의 최소 기준은 충족한다는 것이죠.


도메인 마이크로서비스는 기존 시스템 뜯어내기보다 새 기능부터 시작하라 (4~5장)

5장에서 가장 와닿은 조언이었어요. 기존 모놀리식을 리팩터링하는 건 학습 곡선이 너무 가파르다고요. 새로운 비즈니스 영역의 기능을 도메인 마이크로서비스로 만들면서 패턴을 익히는 게 훨씬 현명하다고 말해요.


DDD를 패턴과 연결해서 실용적으로 설명한 점 (5장)

DDD 책 따로 읽으면 '애그리거트는 무엇인지?'에서 끝나는 경우가 많은데, 이 책에서는 항공권 예약이나 피자 주문 예시로 "왜 애그리거트고, 왜 이렇게 나누는지"를 보여줘요. 도메인 서비스 vs 애그리거트 경계도 코드 수준에서 설명해서 이해가 빨랐어요.


특히 "요금 계산 서비스는 상태를 데이터스토어에 저장하는 대신 룰 엔진을 사용한다"는 부분이 인상적이었어요. 상태가 없는(stateless) 서비스의 좋은 예시라고 생각했어요.


"실금(Seam)을 찾아라" (10장)

모놀리식을 마이크로서비스로 나눌 때 "어디서 자를까?"보다 "이미 자연스러운 경계가 어딘가?"를 찾는 게 중요하다고 하였습니다. DDD의 경계 컨텍스트를 활용해서 실금을 찾고, 거기서부터 래퍼(Wrapper)를 씌워서 점진적으로 추출하는 전략이에요.


이 대목을 읽고 나니까 우리 프로젝트에서도 "실금"이 어디에 있는지 눈에 보이기 시작했어요. 인증 모듈, 결제 모듈, 알림 모듈... 이것들은 이미 자연스러운 경계가 있는 부분이더라고요.


관측 가능성은 선택이 아니라 필수 (9장)

로깅/메트릭/트레이싱을 "삼위일체"로 묶은 게 인상 깊었어요. 분산 아키텍처에서는 디버깅이 단일 프로세스 때보다 훨씬 어려워서, "어떻게 관찰할지"를 설계 단계부터 고민해야 한다는 거예요.


특히 "멀티 채널 로깅의 복잡성" 부분에서 공감했어요. 지금까지는 콘솔 로그에 찍히면 그만이라고 생각했는데, 프로덕션에서는 중앙 집중화된 로깅이 필수라는 걸 배웠어요.


4. 덕분에 무엇을 배웠는가

점진적 전환의 중요성. 커다란 진흙 덩어리 → 모듈러 모놀리식 → 분산 아키텍처 → 마이크로서비스. 한 번에 다 옮기려 하지 말고, 단계별로 가는 게 현명하다는 걸 배웠어요.


DDD는 기술이 아니라 비즈니스 설계다. 도메인 전문가와 함께 설계해야 하고, 애그리거트 경계 = 트랜잭션 경계 = 일관성 경비라는 관점이 인상적이었어요.


12-Factor App은 지금 당장 체크할 수 있다. 이론이 아니라 지금 프로젝트에 적용해볼 수 있는 실천법이라는 점이 좋았어요.


이벤트 기반 설계의 가치. 서비스 간 직접 호출이 아니라 이벤트 발행/구독으로 느슨한 결합을 달성하는 방법을 배웠어요.


"실금"을 찾는 눈. 모놀리식 현대화는 "어디서 자를까?"가 아니라 "이미 자연스러운 경계가 어딘가?"를 찾는 문제라는 걸 배웠어요.


폴리글랏은 선택지다. 하나의 DB/언어로 모든 걸 해결하려 하지 말고, 작업별로 최적화된 기술을 선택하는 게 클라우드 네이티브의 정신이라는 걸 배웠어요.


5. 좋았던 점

패턴 중심이라 나중에 찾아보기 좋아요

각 장이 독립적으로 읽을 수 있어서, "아, API 게이트웨이 패턴이 어디 있더라?" 할 때 바로 찾아볼 수 있어요. 패턴 사전처럼 쓸 수 있다는 게 장점이에요.


예시가 구체적이에요

항공권 예약 시스템, 피자 주문, 전자상거래... 실제로 겪을 법한 예시라 이해가 쉬웠어요. 특히 항공권 예약 시스템은 4장, 5장, 6장에 걸쳐 계속 나와서 흐름을 따라가기 좋았어요.


클라우드 전체를 아우르는 개념 지도를 그려줘요

12-Factor App, 컨테이너, 쿠버네티스, 이벤트 주도, 폴리글랏 퍼시스턴스, 관측 가능성까지 흩어진 개념들을 "클라우드 네이티브 앱을 어떻게 설계/운영하는가"라는 한 줄로 연결해줘요.


6. 아쉬운 점

코드 예제가 Java 중심이에요

Java/Spring 예제가 많아서 Node.js/TypeScript 개발자인 저는 번역해서 이해해야 하는 경우가 있었어요. 클라우드가 언어를 가리지 않는다는 책의 주장과 살짝 모순되는 느낌이 들었어요.


일부 패턴은 너무 짧게 다뤄요

Saga 패턴이나 CQRS 같은 중요한 패턴은 언급만 하고 넘어가는 경우가 있어서, "그래서 어떻게 구현하는데?" 하는 아쉬움이 남았어요.


7. 이 책을 읽은 덕분에 기대되는 변화

- 12-Factor App 체크리스트로 현재 프로젝트를 점검해볼 거예요. 특히 설정 분리와 로그 스트림 처리 부분을 중점적으로 볼 예정입니다.

- 코드 리뷰할 때 "이 의존성이 정말 필요한가?"를 먼저 물어보는 습관을 들이고 싶어요. 폴리글랏 퍼시스턴스 관점에서, 지금 쓰는 RDB가 모든 작업에 최적인지도 다시 검토해볼 계획이에요.

- 로깅/메트릭/트레이싱을 중앙 집중화하는 방안을 팀에 제안해볼 거예요. 현재는 콘솔 로그에만 의존하고 있거든요.

- "실금"을 찾는 관점으로, 기존 레거시 코드를 볼 때도 "여기서부터 분리하면 되겠다"는 감이 생길 것 같아요.




댓글(0) 먼댓글(0) 좋아요(0)
좋아요
공유하기 북마크하기찜하기 thankstoThanksTo