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

클라우드 애플리케이션 아키텍처 패턴(한빛미디어, 2026)

Saas 가 보편화 된 오늘, AX 열풍만큼 뜨겁던 CX가 떠올랐다. 과거 IT 업계의 주요 화두였던 '클라우드 네이티브', 이 책은 패턴을 통한 아키텍처 구성으로 클라우드 상의 더 좋은 애플리케이션 구현을 설명한다.

클라우드 네이티브 애플리케이션은
클라우드 컴퓨팅 모델의 특장점을 충분히 활용할 수 있도록
설계 및 구현된 애플리케이션이다.

클라우드 기반 애플리케이션은 클라우드에 호스팅되어 서비스를 제공하지만, 클라우드 아키텍처의 내재적 설계를 완전히 활용하지는 못한다. 여기서 클라우드 네이티브 애플리케이션과 클라우드 기반 애플리케이션이 차이를 나타낸다.

(클라우드 네이티브 애플리케이션은 여러 기술로 구성되는데,마이크로서비스, 컨테이너, API, 동적 오케스트레이션, 서비스 메쉬, 백킹 서비스 등이 대표적이다.)

이 책의 핵심은 애플리케이션이 클라우드와 함께 작동하도록 하는 것으로, 클라우드 환경에서 원활하게 동작하며 클라우드 컴퓨팅의 모든 장점을 활용하면서도 클라우드 환경의 한계를 회피하거나 보완할 수 있도록 설계 및 구현 하는 70개의 패턴을 안내한다.

패턴을 통해 직면한 문제에 어떤 디자인을 어떻게 적용할지 그리고 패턴 언어를 통해 패턴을 특정 순서로 적용하고 자신만의 디자인을 만드는 과정을 저자는 설명한다.

(~8장까지는 그린필드 개발로, 클라우드용 에플리케이션을 설계하고 아키텍처를 구성할 때 처음부터 새로운 개발을 가정하며

9장 이후는 기존 에플리케이션을 클라우드 환경으로 이전하고, 더 잘 실행할 수 있도록하는 애플리케이션 이전과 현대화를 중심으로 한다)

클라우드 플랫폼 하드웨어와 클라우드 네이티브 애플리케이션의 시작부터 모범 사례 활용 방법까지 폭 넓게 클라우드 애플리케이션 아키텍처의 다양한 관점과 구성을 학습하고 싶은 모든 개발자에게 일독을 추천한다.

저자 : 카일 브라운(Brown, Kyle), 바비 울프(Woolf, Bobby), 조셉 요더(Yoder, Joe)

역자 : 박수현

제목 : 클라우드 애플리케이션 아키텍처 패턴

출판사 : 한빛미디어

출간 연도 : 2026.03.30

페이지 : 724쪽

원서명 : Cloud Application Architecture Patterns(O'Reilly Media , 2025)

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

이 책은 IBM 펠로를 포함한 수십 년 경력의 아키텍처 전문가들이 정립한 70여 개의 패턴을 통해 클라우드 환경에 최적화된 애플리케이션을 설계하고 구축하는 방법을 소개한다.

www.hanbit.co.kr

https://www.hanbit.co.kr/store/books/look.php?p_code=B3991962451

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

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

이 책은 시작부터 애플리케이션 아키텍처가 무엇인지 분명히 한다. 애플리케이션 아키텍처는 애플리케이션의 기능을 정의하는 것이 아니라, 그 기능을 어떻게 개발하고 실행할 것인가를 정의하는 것이라고 말한다. 그래서 아키텍처를 변경하면 기능을 개발하고 실행하는 방법이 바뀐다. 책은 모든 아키텍처를 세 가지 핵심 패턴으로 압축한다. 커다란 진흙 덩어리, 모듈러 모놀리식, 분산 아키텍처. 이 세 가지가 책 전체의 좌표축이다.

가장 카운터인투이티브한 메시지가 진흙 덩어리에 있다. 책은 진흙 덩어리를 "아키텍처가 없는 아키텍처"라고 부른다. 모든 구성 요소가 서로 얽혀 있고 순환 참조가 발생하며, 공유 데이터는 전부 전역 변수로 사용되는 형태다. 이 정의만 보면 안티 패턴 같지만 책은 다른 결론으로 간다. "장기간 유지 보수해야 할 애플리케이션에 커다란 진흙 덩어리 아키텍처를 적용하는 것은 재앙이겠지만 단기간 개발해야 할 애플리케이션에는 커다란 진흙 덩어리가 최적의 아키텍처다." 페이팔도 1999년 CGI 한 덩어리로 시작했고, 2007년에는 도메인 로직을 담은 C++ 클래스 하나가 5,000개가 넘는 메서드와 50만 줄짜리 코드를 갖고 있었다. 거기서 출발해서 2,500개 이상의 마이크로서비스로 진화했다. 진흙 덩어리에서 출발했기 때문에 망한 게 아니라 거기서 출발해서 진화했기 때문에 살아남은 흐름이다.

책이 클라우드 네이티브를 정의하는 방식이 흥미로웠다. IBM과 마이크로소프트의 정의를 함께 가져온 다음 책의 정의를 만든다. "클라우드 네이티브는 클라우드 컴퓨팅의 강점을 최대로 활용함과 동시에 클라우드 컴퓨팅의 한계를 피하거나 보완함으로써 클라우드에서 잘 동작할 수 있는 애플리케이션을 설계하는 접근 방식이다." 강점의 활용과 한계의 보완을 동시에 요구하는 정의다. 클라우드 네이티브 아키텍처의 구조 자체는 단순하다. 애플리케이션과 서비스 두 부분으로 나뉜다. 애플리케이션은 개발 팀이 만드는 도메인 로직이고, 서비스는 클라우드 플랫폼이나 서드파티가 제공하는 백엔드 서비스다. 미들웨어를 외부 서비스 카탈로그에 위임하라는 입장이다.

마이크로서비스의 정의도 명료하다. "마이크로서비스 아키텍처는 분산 아키텍처와 클라우드 네이티브 아키텍처의 결합으로 실현한다." 분산만 있으면 SOA에 가깝고 클라우드 네이티브만 있으면 클라우드 위에 올린 모놀리식일 뿐이다. 둘 다 갖춰야 마이크로서비스다.

마이크로서비스 설계 원칙으로 책은 IDEALS를 제시한다. SOLID의 마이크로서비스판이라고 부른다. 인터페이스 분리는 클라이언트 유형마다 다른 API를 제공하라는 원칙이다. 배포 가능성은 좋은 설계와 구현만으로 마이크로서비스의 성공을 보장할 수 없으니 컨테이너화, 서버리스, 블루-그린/카나리/롤링 같은 배포 전략이 동시에 따라와야 한다는 입장이다. 이벤트 주도는 가능한 한 동기식 호출 대신 비동기 메시지로 서비스를 활성화하라는 권장이다. 일관성보다 가용성은 CAP에서 가용성을 우선하겠다는 선언이다. 느슨한 결합은 의존성 많은 마이크로서비스가 사실상 분산형 모놀리식이라는 경고로, 책은 이런 형태를 매크로서비스 또는 마이크로덩어리서비스라고 부른다. 단일 책임은 적정 크기를 모델링하는 원칙인데, 하한은 최소 1개 애그리거트, 상한은 바운디드 콘텍스트라는 두 줄로 적절한 크기에 대한 토론이 정리된다.

마지막은 모놀리식 점진적 대체에 관한 이야기다. 책은 모놀리식 대체를 두 가지 상호 보완적인 활동으로 정의한다. 기능과 컴포넌트를 버리는 것과 이전하는 것. 모든 코드를 다 옮기겠다는 욕심부터 내려놓으라는 뜻이다. 전략의 순서는 길 닦기, 작게 시작하기, 모놀리식 감싸기, 가느다란 실금 찾기, 컴포넌트 추출, 리팩터링 후 추출, 플레이백 테스트의 순서로 패턴 카탈로그로 정돈되어 있다. 길 닦기는 컨테이너화, 모니터링, 분산 추적, CI/CD 같은 인프라 준비 단계이고, 모놀리식 감싸기는 흔히 스트랭글러 파사드라고 부르는 패턴이다. 가느다란 실금 찾기는 모놀리식 안에서 분리할 수 있는 경계 지점을 찾는 단계인데, 비즈니스 기능이 코드에 잘 정의되지 않은 경우 데이터에서 시작해 코드로 거슬러 올라가라는 조언이 따라온다. 컴포넌트 추출과 리팩터링 후 추출은 큰 기능 조각을 일단 매크로 서비스로 한 덩어리 추출한 뒤, 거기서부터 더 작은 마이크로서비스로 리팩터링하는 재귀적인 프로세스를 권한다. 플레이백 테스트는 의외의 발견이었다. 원 시스템의 입력과 동작을 캡처해서 새 시스템에서 같은 입력을 재생해 결과를 비교하는 단순한 방법인데, "기존 시스템의 미묘한 버그조차 워크플로우와 UI에 고착되어 사실상 숨겨지거나 문서화되지 않은 기능이 되었을 수도 있다"는 한 문장이 핵심을 짚는다.

책의 흐름을 한 호흡으로 정리하면 이렇다. 애플리케이션 아키텍처의 세 좌표축에서 출발해, 클라우드의 강점을 활용하기 위해 클라우드 네이티브 아키텍처가 등장하고, 분산과 클라우드 네이티브가 결합한 자리에 마이크로서비스가 자리 잡으며, 그 설계는 IDEALS와 도메인 중심 모델링으로 다듬어진다. 마지막으로 이미 존재하는 모놀리식을 어떻게 이 새 좌표계로 옮길지를 점진적 대체 패턴으로 이어간다. 70개의 패턴이 한 줄로 묶이지는 않지만 각 패턴이 어디에 자리 잡는지 동선이 그려져 있다. 작업이 막힐 때마다 해당 챕터를 펼쳐서 패턴 이름과 그림만 보고 돌아가는 방식이 자리 잡혔다. 패턴 사전이라고 생각하면 이 책을 가장 잘 쓰는 방법은 그 방식이라는 생각이 든다.

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

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

왜 우리 시스템은 클라우드에서도 여전히 불안할까?

개발 연차가 쌓이면서 단순한 기능 구현을 넘어, 시스템 전체의 큰 그림을 그려야 하는 순간이 옵니다. 특히 모놀리식 구조에서 마이크로서비스(MSA)나 클라우드 환경으로 넘어갈 때 가장 크게 착각하는 것이 있습니다. 바로 "클라우드 벤더(AWS, Azure 등)의 인프라를 쓰면 알아서 고가용성과 확장성이 보장될 것"이라는 믿음입니다.

하지만 분산 환경으로 시스템을 쪼개는 순간, 네트워크 지연, 트랜잭션 불일치, 연쇄 장애라는 새로운 지옥문이 열립니다. 한빛미디어의 신간 <클라우드 애플리케이션 아키텍처 패턴>은 바로 이 지점에서 우리가 겪게 될 필연적인 문제들과 그 해결책을 다루는 책입니다. 특정 클라우드 벤더의 사용법을 다루는 매뉴얼이 아니라, 변하지 않는 설계의 '정석'을 담고 있습니다.

복잡한 분산 환경을 통제하기 위한 아키텍트의 나침반

데이터의 늪에서 탈출하기 (CQRS와 이벤트 소싱)

책에서 가장 몰입해서 읽었던 부분은 분산 데이터 관리에 대한 패턴들입니다. 시스템이 분리되면 가장 먼저 부딪히는 문제가 "DB 트랜잭션을 어떻게 맞출 것인가?"입니다. 기존처럼 하나의 DB에서 JOIN을 걸어 해결할 수 없기 때문입니다.

이 책은 CQRS(명령과 조회의 책임 분리)와 이벤트 소싱(Event Sourcing) 패턴을 통해 이 딜레마를 우아하게 풀어냅니다. 상태를 단순히 덮어쓰는 것이 아니라, 일어난 '이벤트의 연속'으로 저장하고(Event Sourcing), 데이터를 쓰는 모델과 읽는 모델을 물리적/논리적으로 분리(CQRS)하는 과정을 매우 상세하게 다룹니다. 책의 설명을 따라가다 보면, 비동기 메시징 환경에서 발생할 수 있는 '최종 일관성(Eventual Consistency)'을 어떻게 아키텍처 수준에서 제어할 수 있는지 명확한 감을 잡을 수 있습니다.

데이터를 단순히 저장하는 것을 넘어, 데이터의 '흐름'을 설계하는 방법을 구체적인 도식과 함께 설명한다.

실패를 전제로 한 설계 (Resiliency Patterns)

클라우드 네이티브 아키텍처의 대전제는 "장애는 반드시, 언제나 일어난다"입니다. 이 책은 장애를 막는 것이 아니라, 장애가 발생했을 때 시스템 전체로 번지지 않도록 격리하는 복원력(Resiliency)에 상당한 지면을 할애합니다.

• 서킷 브레이커(Circuit Breaker): 외부 서비스에 장애가 났을 때 무의미한 호출을 차단하여 리소스 고갈을 막는 패턴.
• 재시도(Retry) 및 벌크헤드(Bulkhead): 일시적인 네트워크 오류를 극복하고, 하나의 컴포넌트 장애가 전체 시스템을 침몰시키지 않도록 격벽을 치는 방법.

이러한 패턴들을 읽으면서, 평소 코드 레벨에서 try-catch로만 방어하려 했던 제 자신을 반성하게 되었습니다. 동시에 시스템 전반의 상태를 모니터링하는 관측성(Observability)이 왜 분산 환경에서 선택이 아닌 필수인지, 그 철학적 배경을 이해할 수 있었습니다. 분산된 로그와 메트릭을 추적할 수 없다면, 서킷 브레이커가 열렸는지 닫혔는지조차 알 수 없기 때문입니다.

장애를 피할 수 없다면, 우아하게 복구하라.

- 총평 및 추천 대상

<클라우드 애플리케이션 아키텍처 패턴>은 당장 내일 복붙해서 쓸 수 있는 코드를 알려주지는 않습니다. 대신, 어떤 클라우드 환경에서든 흔들리지 않는 견고한 시스템 설계도를 그리는 법을 알려줍니다.

✅ 이런 분들에게 강력 추천합니다:

• 단일 톰캣/DB 환경을 벗어나, 본격적으로 MSA 기반 클라우드 환경을 설계해야 하는 개발자
• 트래픽이 늘어날 때마다 DB 락(Lock)과 장애 속에서 임시방편으로 대처하고 있는 백엔드 엔지니어
• 기능 구현을 넘어 시스템 전체의 아키텍처를 조망하고 싶은 주니어~중니어 엔지니어

당신의 코드가 훌륭하더라도, 아키텍처 패턴이 잘못되었다면 시스템은 결국 무너집니다. 본격적인 클라우드 네이티브로의 도약을 고민하고 있다면, 코드를 짜기 전 이 책을 먼저 펼쳐보시기를 권합니다.

클라우드 환경으로 프로젝트를 배포하고 운영하면서
'과연 올바른 클라우드 아키텍처와 설계 방법은 무엇일까? '라는 고민이 늘 깊었습니다. 
단순한 인프라 이전을 넘어 진정한 '클라우드 네이티브'로 진화하는 방법을 찾던 중, IBM 펠로를 비롯한 수십 년 경력의 아키텍처 전문가들의 실전 지침이 담긴 "클라우드 애플리케이션 아키텍처 패턴" 책을 접하게 되었습니다.

"클라우드 애플리케이션 아키텍처 패턴" 책은 기존에 클라우드 아키텍처를 공부하며 익숙했던 용어와 개념들을 다시 한번 체계적으로 정립해 줄 뿐만 아니라, 클라우드의 발전 역사와 함께 70여 가지의 아키텍처 패턴을 실무 관점에서 생생하게 경험할 수 있도록 구성되어 있습니다.

아키텍처의 진화와 70여 가지 패턴의 유기적 연결
책의 전반부에서는 커다란 진흙 덩어리, 모듈러 모놀리식, 그리고 분산 아키텍처에 이르기까지 애플리케이션 아키텍처의 발전 방향을 명확하게 짚어줍니다.

중반부에서는 마이크로서비스 아키텍처(MSA), 이벤트 주도 아키텍처(EDA), 클라우드 네이티브 스토리지 등 핵심 개념을 중심으로 각 아키텍처 패턴을 유기적으로 연결하여 설명합니다.
특히 마이크로서비스, 이벤트 주도 아키텍처, 도메인 주도 설계(DDD) 등의 서적을 따로 읽었을 때는 지식이 다소 파편화되어 있다는 느낌을 받았는데, 이 책은 그 개념들이 거대한 클라우드 환경에서 어떻게 상호작용하고 연계되는지 전체적인 숲을 보여준다는 점이 가장 큰 장점입니다.

후반부에는 애플리케이션의 이전과 현대화, 모놀리식 점진적 대체를 통해 모놀리지 프로젝트를 어떻게 클라우드 환경에 적용하고 어떤 패턴과 어떤 문제점을 고민해야 하는지 확인할 수 있도록 구성되어 있습니다.

모놀리식 환경의 실무자에게 한 줄기 빛이 되는 지침서
현업에서 기존 모놀리식 시스템을 다루는 실무자로서, Chapter 9. 애플리케이션 이전과 현대화 와 Chapter 10. 모놀리식 점진적 대체는 레거시 시스템을 유지하면서 점진적으로 클라우드 환경으로 확장하고 마이크로서비스로 전환하는 현실적인 방법론과 설계 변경 전략이 구체적으로 담겨 있습니다. 신규 프로젝트가 아닌, 기존 프로젝트를 클라우드 서비스로 마이그레이션하며 수많은 문제에 직면해 있는 엔지니어라면 이 두 챕터만으로도 이 책을 읽을 가치는 충분합니다.

효율적인 학습을 위한 가이드
총 725페이지에 달하는 방대한 분량인데 책을 순차적으로 읽어도 되지만 책의 전반부의 루트 패턴과 각 장의 관계를 읽어보고 책 시작전에 있는 구성방식의 패턴 목록을 책을 읽으면서 교차적으로 읽어보면 좋을 것 같습니다. 각 패턴을 연관관계에 맞추어 선택적으로 읽어봐도 좋을 것 같습니다.

마치며
클라우드 도입은 단순히 실행 환경을 옮기는 것이 아닙니다. 어떤 패턴과 설계 방식을 취하느냐에 따라 프로젝트의 확장성과 효율성은 완전히 다른 결과를 낳습니다. 모놀리식을 벗어나 클라우드 환경으로 성공적인 전환을 꿈꾼다면, 이 책을 통해 각 패턴의 중심 사상과 연관 관계를 정확히 인식하는 것이 첫걸음이 될 것입니다. 이 책으로 올바른 기술적 선택의 기준을 세우고, 이후 개별 주제에 대한 깊이 있는 추가 학습을 이어나가시길 추천합니다.

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

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가 모든 작업에 최적인지도 다시 검토해볼 계획이에요.
• 로깅/메트릭/트레이싱을 중앙 집중화하는 방안을 팀에 제안해볼 거예요. 현재는 콘솔 로그에만 의존하고 있거든요.
• "실금"을 찾는 관점으로, 기존 레거시 코드를 볼 때도 "여기서부터 분리하면 되겠다"는 감이 생길 것 같아요.

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

사내 레거시 시스템을 현대화하는 과정에서 실질적인 해법을 찾기 위해 이 책을 선택했습니다. 주니어로서 최신 기술을 도입하고 싶은 열정도 크지만, 그보다 중요한 것은 기존 시스템이 유지되어 온 맥락을 이해하고 비용 절감과 리소스 효율이라는 '비즈니스 임팩트'를 증명하는 것이라고 생각합니다.

특히 '9.6 작게 시작하기'와 '9.7 길 닦기' 파트는 거대한 현대화 작업을 세분화하여 리스크를 관리하는 전략적 태도를 배우기에 훌륭한 길잡이가 되었습니다. 또한 '10.6 컴포넌트 추출' 기법을 통해 거대한 진흙 덩어리(Legacy) 같은 시스템에서 어떤 부분부터 분리해야 비즈니스 가치를 극대화할 수 있을지 그 판단 기준을 심도 있게 고민해 볼 수 있었습니다.

이 책은 다양한 상황에 바로 적용할 수 있는 설계 패턴을 제시해주어, 현재 진행 중인 프로젝트에 어떤 선택지를 대입할 수 있을지 구체적으로 그려볼 수 있는 귀중한 기회가 되었습니다. 또 '기존 시스템을 그냥 클라우드 환경에 올리면 되는거 아니야?' 라고 생각하시는 분이 읽어보시면 좋을 것 같습니다.

2023년 기존 솔루션을 MSA로 전환하려고 시도한 적이 있었다. 자료 조사 과정에서 기술 부채라는 엄청난 현실과 마주한 채 포기해야만 했다. 모놀리식 애플리케이션과 클라우드 네이티브 애플리케이션은 용어부터 개념, 설계까지 근본적으로 달랐다. 중소기업에서는 전환을 위한 투자 비용도 고려해야 하기 때문에 중도에 포기할 수밖에 없었다.

그러는 동안 공공기관에서는 많은 애플리케이션이 리프트 앤 시프트 방식으로 클라우드 환경으로 전환을 진행했다. 민간뿐만 아니라 공공기관에서도 인프라 관점에서 클라우드 환경은 디폴트가 되었다. 지금은 클라우드 환경에 맞는 클라우드 네이티브 애플리케이션으로 전환을 시도하거나 준비 중인 것으로 알고 있다.

2026년 기존 솔루션을 다시 MSA로 전환하고 있다. 지금 이 책을 읽게 된 것은 개인적으로 참 행운이라고 생각한다. 내가 알지도 못했을, 앞으로 겪게 될 문제점들과 시도할 만한 해결책들이 고스란히 책에 소개되어 있다.

나도 잘 몰랐던 클라우드 애플리케이션으로 전환해야 할 이유를 설명하고, 클라우드 애플리케이션 전환을 위한 전 과정(개념, 아키텍처, 설계 패턴, 스토리지(DB), 클라이언트)을 그림과 예시로 설명한다.

각각의 모범 사례 마지막에는 실제로 구현되는 형태를 항공권 예약 시스템, 전자상거래, 금융시스템 등의 실제 상황을 예를 들어 설명함으로 해서 한결 이해가 쉬웠다.

특히, 9장과 10장의 내용이 공감이 많이 되었다. 기존 솔루션이나 서비스를 클라우드 애플리케이션으로 마이그레이션 및 클라우드 네이티브 애플리케이션(클라우드 환경에서 최적화 하는 방법)으로 고도화하는 실천적으로 내용이기 때문이다. 우버, 넷플릭스, eBay, 아마존의 사례가 포함되어 있어서 더욱 흥미를 끌었다.

이 책에서 느낀 점은 주제가 아키텍처 패턴이지만, 지루하지 않았으며 실천적인 내용으로 채워져 있어서 당장이라도 적용하고 싶은 내용이 많았다.

패턴 설명은 진행 과정을 그림으로 설명하고, 마지막에 구현 사례를 예를 들어 설명하기 때문에 이해하는데 어렵지 않았다.

<4장 클라우드 애프릴케이션 아키텍처 패턴, p232~p233>

<9장 애플리케이션 이전과 현대화, p631~p632>

<10장 모놀리식 점진적 대체, p655~p656>

<11장 총정리, p714~p715>

클라우드에서 잘 실행되는 애플리케이션보다 그냥 클라우드에서 실행‘만’ 되는 애플리케이션이 더 많다.

사실 애플리케이션을 클라우드로 옮기기 위한 리프트 앤 시프트(lift and shift) 접근법 자체에는 문제가 없다고 생각한다. 내가 반대하는 부분은 이를 초기 단계가 아닌 과정의 전부로 보는 것이다.

샘 뉴먼 추천사, p6

우리의 애플리케이션이 구동할 클라우드 환경은 이제 성숙되었다. 우리는 그 환경에 최적화된 애플리케이션을 개발해야 한다. 2026년 클라우드 네이티브 애플리케이션은 선택이 아니라 필수다. 이 책은 분산 환경뿐만 아니라 앞으로 개발되는 모든 프로그램 설계 패턴의 기본이 될 것으로 확신한다.



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

배경

내가 웹 개발을 본격적으로 배우기 시작했을 무렵에는 이미 클라우드 기반의 워크플로가 표준이었다. 특정 플랫폼에서 자원을 할당받고, 터미널로 접속하여 웹 서버를 구동했다. 방화벽과 공유기 설정으로 로컬 서버를 개방하는 방법을 안 것은 그로부터 좀 시간이 지난 후였다. 생각해보면 클라우드 환경은 내게 '당연히 그래야만 하는 것' 정도로 받아들여졌던 것 같다. 그 이전과는 어떻게 다른지, 그래서 보다 클라우드 환경에 적합한 구조는 무엇인지 생각해본 적이 없었다. 다들 AWS 쓰니까, Docker 쓰니까, Kafka 쓰니까. 마이크로서비스나 이벤트 기반, 도메인 기반 아키텍처도 마찬가지다. 별 생각 없이 막연히 좋아보인다고만 생각했던 것 같다.

첫 인상: 친절하다

다루는 내용을 논하기 전에, 일단 기본적으로 이 책은 친절하다. 해결책을 패턴화해서 잘 정리해둔 것도 그렇고, 또 각 패턴에 대한 설명에 도식을 활용하여 구조적으로 이해하기 좋았다. 책, 논문 등을 통해 이미 유명한 내용들을 잘 정리했고, 그에 대한 인용이나 링크도 많아 깊게 파고들기 좋았다. 패턴으로 구성된 책들은 대게 사이 연결성이 부족해서 순서대로 읽는 것이 의미가 없는 경우도 있는데, 이 책은 일종의 기초-응용-심화의 느낌으로 각 장을 진행해서 책장을 차례대로 넘길 때 얻는 것이 더 많았다.

내용: 설계 교과서

'설계 교과서'라고 표현한 이유는, 이 책이 개발이 아닌 설계에 집중하고, 저자의 개인적인 노하우보다 업계 전반에 잘 알려진 유명한 내용을 잘 종합했기 때문이다. 보통 주제를 넓게 커버하는 책들은 난해한 내용에 대해 설명이 빈약한 경우가 있는데, 적어도 나는 그런 느낌은 받지 못했다. 가령, 도메인과 관련한 내용은 보통 책 한 권의 분량으로 다룬다. 그 한 권에서도 대부분 자신의 도메인에 대한 직접적인 사례는 얻지 못하는데, 때문에 난 읽고 직접 자신의 경우에 활용할 수 있을 정도의 충분한 설명이 있는가를 중요하게 봤다. 그리고 이 책은 내 기준에는 합격했다.

반드시 알아야 하는 내용들로 꾹꾹 담은 이 책은 입문자부터 중급자까지 실무를 위해 직접 활용할 수 있는 수준의 풍부한 설명을 제공한다. 그러나 기본적으로 신선한 내용과는 거리가 있다는 것을 알아둘 필요가 있다. (물론 흐름을 놓친 누군가에게는 새로운 것들이겠지만) 적어도 나는 이 책을 읽으면서 IDEALS라는 개념은 새롭게 알게 되었다. 이는 객체 지향 원칙의 SOLID와 유사한 느낌으로, 2020년 발표된 마이크로서비스 설계 원칙이고, 이 책의 전반에 걸쳐 언급되는 유용한 개념이다.

후기: 현대화가 낯설다면

'현대화'라는 단어. 막상 사용하고보니 좀 폭력적인 것 같다. 이러한 흐름에 동참하지 않으면 구닥다리 뒷방 노인네처럼 도태되어 버리는 건 아닌가 싶은 상상이 든다. 그러나 사실 책을 읽어보면 이 책은 변화를 절대 강제하지 않는다. 전통적인 구조부터 현대의 구조까지, 모든 것에는 주어진 환경에서 최선을 다한 이들의 서사가 녹아있다. 저자는 서로 다른 방법론 간에 우열을 가리지 않고, 진지하게 마주하며 장단점을 논한다. 전통적 구조의 서비스를 현대적으로 개편하기 위한 방법을 2개의 장에 걸쳐 제시하니, 우리 엔지니어들은 각자의 상황에 맞게 결정하면 된다. 필요하면 가져다 쓰는 것, 그 뿐이다.

70여개의 설계 패턴을 보며 느낀 것은, 객체 지향 언어의 디자인 패턴과 유사하게, 결국 정의된 역할을 어떻게 추상화하냐가 관건인 것 같다. 다만, 개발보다 설계 수준에서의 변경은 비용이 비싸다는 점이 차이인 것 같고, 때문에 이렇게 정형화된 방식을 익혀놓는 것이 더 의미있게 다가왔다. 클라우드가 바꾼 생태계의 모습이 낯선 이들에게 이 책은 앞으로의 개발 방향성을 올바르게 잡아나가는 데 큰 도움이 될 것이라 생각한다.

AWS를 처음 접한지 10년 정도 되었다.

그동안 많은 변화가 있었고, 나는 그 전에는 리눅스 시스템 엔지니어로 활동했다.

그 기간은 사실 엄청 특별한 아키텍처가 있는게 아니었고, 파일 공유 시스템이나, 클러스터링 그렇지 않을 경우, MQTT 정도로 web was 분리하면 대부분의 프로젝트는 마무리되었다고 할 수 있다.

비록 시스템 엔지니어의 영역은 아지지만, L4에서 정상적으로 vlan 구성해서 이웃한 다른 인접한 서비스와 통신이 되면 그것도 엔지니어로써는 잘하는 영역이 되곤 했다.

​

근데 2010년도 쯤 누군가에서 KMS 라는 가상화 구현이 가능한 것을 이야기로 전달 들었다.

당시 hostway라는 idc라고 했었는데 내가 보기에는 확실하지는 않았다.

실체가 없는데, 어떻게 구현 가능할까라는 의심이 먼저 들었었다.

​

2013년도쯤 처음 시작하는 클라우드 회사는 초기에는 IDC 서버 접속하는 것과 크게 차이가 없었다. 그때는 그 정도만 되어도, 클라우드라고 했었던거 같다.

사실 초기 형태는 EC2 베이스에 가까워서 이게 클라우드인지 실체가 없어서 클라우드인지 명확하지는 않았던거 같다.

다만 우리가 서버를 설치할 필요가 없었고, WAF를 구성하는 것도 실제로는 해당 어플리케이션을 빌드만 해서 사용하면 되어서, 상대적으로 다른 보안 엔지니어와의 협업으로 일을 해결하고는 했었다.

그전에는 IDS, UTM 등 장비도 정의했었어야 했는데 그럴 필요가 없다라는게 장점이었다.

​

생각해보면 어떤 표준이 있었을까 하고 찾는게 먼저였는데, 클라우드를 도입하면서 더 많은 선택이 필요했고, 더 많은 표준에 대해서 안내를 해줬어야 했다.

책을 읽어보면서 다양한 서비스에서 컨설팅을 하고, 서비스에 부하가 일어나면 하나씩 분산을 했었고, 이를테면 메시지를 전송하거나 가지고 있는 것도 위에서 언급한 MQTT, REDIS 그리고 다른 네트워크 도구를 통해서 해결할 수 있었다.

​

책 처음에는 어플리케이션에 대한 이야기를 많이 할애한다. 물론 클라우드라던가 전통적인 모노리틱 아키텍처에 대한 설명도 한다.

책이 다소 양이 많아서 어느 정도 엔지니어 생활을 했다면 꼭 필요한 부분은 아니라서 건너 뛰어도 크게 문제가 안될 것이라고 생각이 들었다.

​

​

다음 부분은 마이크로 서비스 아키텍처에 대한 할애가 있다.

이 부분에 대한 것은 사실 이전 시대의 서비스인 모노리틱에서 마이크로 서비스의 전환을 고려해본 사람들이라면 다양하고 많은 아키텍처가 있었고, 그 선택을 실무적으로 어떻게 구현해야 할지 고민해본 사람들에게 도움이 될것이라고 생각이 된다.

초기에는 모노리틱에서 로그인 하는 과정을 분리해서 서비스에 영향이 없다면 천천히 분리하는게 순서였는데, 그럴때 각각의 인스턴스, 또는 가상화 머신의 용량 설정부터 그 로그를 어떻게 적재할지에 대한 고민이 이 부분에 녹아져 있다. 사실 모니터링은 그 어느 순간에도 부족하지 않고, 아주 중요한 영역이라고 생각이 된다.

마이크로 서비스 중에 도메인 중심 모델링으로 유용하게 설계하고 구현하는데 있어서 도움이 될 수 있을 것이다. 반드시 모든 서비스를 구현 가능한 것은 아니지만, 예를 들어서 고객과 대화를 통해서 이런 부분에 대한 고려가 가능할 것이다.

​

다음은 EDD라고 이벤트 주도 아키텍처에 대한 설명과 구현 그리고 어떤 부분을 포인트로 잡아야 하는지 설명이 나온다. 사실 아키텍처에 대해서 미국과는 좀 달라서 그런건지 내가 학문이 부족해서 그런지 파이썬 등에 대한 코드도 있기는 한데, 더 많이 배워야 하는 것일까 고민하기는 한다.

​

또한 후반부에는 스토리지에 대해서도 언급한다. 예전처럼 큰 스토리지 서비스를 이용하거나 puer storage를 이용하는 것은 아니지만, 컨테이너나 파드가 없어질 수 있어서 로그에 대한 적재는 무엇보다 중요하다. 그래서 K8S에서도 PV에 대한 이야기도 많이 할해하거나 별도의 EBS 같은 저장장치를 이용하기도 한다.

​

그리고 마지막 부분에서는 이런 이야기를 많이 한다.

모노리틱을 어떻게 하면 안전하게 클라우드로 이전할지 나는 퍼블릭 클라우드를 주로 운영해서 그럴수 있지만, 프라이빗한 클라우드를 구축할때도 마찮가지가 아닐까 한다.

​

아주 오래전 나는 무림의 숨은 비기인 규화보전을 찾으러 다닌다고 생각했지만 실제로 그런 부분은 많지 않았던거 같다. 성실하게 문제를 해결하려 할때 우리가 어떤 서비스를 운영할때 나오는 인사이트를 통해서 보다 안전하게 이관하기 위해 노력할 때 이 책이 빛을 발하는게 아닐까 생각이 든다.

​

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

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

자격증 공부를 하면서 마이크로서비스, 이벤트 기반 아키텍처, CQRS 같은 단어들을 처음 만났습니다. 개념은 외웠는데, 왜 필요하고 언제 쓰는 건지는 여전히 흐릿했습니다. 클라우드 실습을 하면서도 비슷한 답답함이 있었습니다. 서비스를 어떻게 나누고, 데이터를 어떻게 흘려야 하는지 판단하는 기준이 없었거든요. 이 책은 그 질문에 답하는 방식으로 읽혔습니다.

책은 각 장이 어떻게 연결되는지를 먼저 보여주고 시작합니다. IDEALS라는 원칙 여섯 가지(인터페이스 지향, 배포 가능성, 이벤트 주도, 가용성 우선, 느슨한 결합, 단일 책임)로 시작하는데, CAP 정리는 '셋 중 둘만 고를 수 있다'는 공식으로 외웠는데 '가용성 우선' 챕터를 읽고 나서야 장바구니에 담긴 상품 수가 잠깐 틀리더라도 서비스 자체가 죽지 않는 쪽이 낫다는 선택이 얼마나 의식적인 결정인지 감이 왔습니다. 이론으로만 알던 개념이 "왜 이 선택을 해야 하는가"라는 질문에 연결되는 순간이었습니다.

가장 알차게 읽은 파트는 데이터 저장소 챕터였습니다. CQRS가 조회와 명령을 분리하는 이유를 따라가다 보면, 바운디드 컨텍스트가 왜 필요한지로 이어지고, 이벤트 소싱이 왜 등장했는지까지 흐름이 자연스럽게 연결됩니다. 도메인 모델링 개념도 하나로 애그리거트, 엔티티, 도메인 이벤트의 관계가 한눈에 잡혔는데, 각 개념을 따로 외울 때는 보이지 않던 것들이었거든요. 육각형 아키텍처도 마찬가지였습니다. 포트와 어댑터가 왜 이렇게 나뉘는지, 클라우드 오브젝트 스토리지와 데이터베이스 서비스가 어떤 위치에 붙는지 시각적으로 확인하고 나서야 구조가 몸에 붙는 느낌이었습니다.

비유도 인상적이었습니다. 자전거 발전사가 애플리케이션 아키텍처의 진화와 나란히 놓이는 장면은, '커다란 진흙 덩어리 → 모듈러 모놀리식 → 분산 아키텍처'로 이어지는 흐름을 설명하는 데 꽤 효과적이었습니다. 같은 전자상거래 시스템이 어떻게 단계적으로 분리되는지, 기존 시스템을 한 번에 갈아엎는 게 아니라 공존 구간을 두고 조금씩 대체하는 방식까지 보여줍니다. PayPal이 몇 년에 걸쳐 이 과정을 밟아왔다는 사례도 함께 나오는데, 설계 결정 수준에서 그 선택들이 얼마나 지난했을지까지 와닿았습니다.

아쉽게도 책은 각 패턴의 트레이드오프를 잘 설명하지만 패턴을 도입한 뒤 운영 단계에서 마주치는 분산 트랜잭션 일관성 문제나 이벤트 순서 보장 같은 부분은 상대적으로 얇습니다. "어떤 패턴을 고를 것인가"에는 강하지만, "고른 뒤 어떤 함정이 기다리는가"는 실무 경험으로 채워야 하는 부분이 남아 있습니다. 각 챕터 마지막에는 핵심 내용을 짧게 요약해주는 구성이 있는데, 챕터가 끝날 때마다 요점을 한 번 훑고 나서야 내가 어디까지 알고 있는지 윤곽이 잡혔습니다.

정답보다 선택의 기준이 필요한 분들께 추천하고 싶은 책입니다.

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

클라우드 어플리케이션 아키텍처 패턴

제가 일하는 팀은 C# 같은 프로그램으로 개인 피씨에 설치하는 데스크탑 어플리케이션을 개발하여 사용했습니다.

그래서 로직의 처리를 클라이언트나 서버가 같이 부담했습니다.

그러다보니 각자의 컴퓨터 성능에 따라 속도 차이가 많이 났죠.

아래의 같은 구조를 가지고 있었습니다.

클라이언트/서버 애플리케이션 구조

시간이 지나면서 기존의 서비스들을 웹으로 전환했습니다.

그렇게 모든 사람이 프로그램을 깔아야하고 버전을 관리해야하는 부담에서 벗어났습니다.

너무 무겁게 여러명이 쓰지 않는다면 괜찮다고 생각했기에 웹으로 전환했습니다.

처음에는 하나의 웹 서비스가 하나의 PC 에 돌아갔습니다.

그런데 지금은 계속해서 서비스를 만들다보니, 공통적으로 사용해야하는 부분들이 생기기 시작했습니다.

아래와 같은 클라우드 네이티브 애플리케이션 구조를 만들어볼려고 책을 읽게 되었습니다. 

클라우드 네이티브 애플리케이션 구조

애 책에서는 패턴에 대해서 많이 알려주려고 합니다.

각 상황마다 적용해야하는 부분들이 다르기 때문입니다.

아키텍처 설계에서는 답이 없습니다. 어떤것을 내가 더 고려할것인가? 에 대한 최선의 답을 고르는 과정입니다.

책의 각 장 관계도

항상 무엇을 시작할 때든 정의가 가장 중요하다.

정의에는 추구하는 가치가 담겨있기 때문이다.

클라우드라는 것은 무엇일까?

클라우드 컴퓨팅의 정의

무엇일까? 나온 하나의 정의에서 특성이 파생된다.

클라우드 컴퓨팅의 특징

이런 클라우드는 어떤 방식의 구조로 가지면 좋을까?

클라우드 애플리케이션 아키텍처. 우측은 각 챕터별 설명 위치

클라우드 부분은 조금 설명이 필요할거 같네요.

- 디스패처 : 로드 밸런서/API Gateway 입니다. 사용자의 요청이 어떤 서비스로 가야하는지 판단합니다.

- 도메인 마이크로 서비스 : 핵심기능을 수행하는 서비스들입니다. 예를 들어, 검색 서비스, 결제 서비스 등

- 어댑터 마이크로 서비스 :  클라우드 외부에 있는 기업 내부 시스템(SoR) 과 통신하는 서비스입니다.

- 이벤트, 이벤트 백본 : 서비스는 직접 대화하는게 아니라 이벤트를 통해서 소통합니다. 예를 들어, 직접 어떤 서비스의 기능을 호출하는 것이 아니라 그 서비스의 이벤트 큐 같은 곳에 이벤트를 넣어둡니다. 그러면 그 이벤트 큐의 서비스가 이를 읽고 독립적으로 일을 수행합니다.

우리가 구조를 설계하고 적용하면 어떤 점이 좋을까요?

TDD 라는 개념에 대해서 들어보신적 있나요?

TDD 는 테스트를 먼저 작성하고 그 테스트를 통과시키는 코드를 작성해라는 것입니다.

이러한 개념을 적용하면 테스트 가능한 코드를 작성하기 위해 코드의 형태가 변하게 됩니다.

하나로 쭉 길게 작성하던 함수가 테스트를 쉽게 할 수 있도록 의존성을 지우고 분리되는거죠.

클라우드 애플리케이션의 이러한 구조도 다양한 이점을 만들어냅니다.

이 이점을 만들어내기 위해 코드 자체도 맞춰서 개선될 수밖에 없습니다.

클라우드 애플리케이션의 장점

가용성, 확장성, 유연성을 지키기 위해서 애플리케이션의 바운더리가 잘 나눠지고 모듈화가 진행됩니다.

외부와 통신하는 부분은 자주봐야하기 때문에 쉽게 보기 위해서,

인터페이스와 비즈니스 부분을 좀 더 구분하게 될수도 있습니다.

뒷장의 아키텍처 패턴의 이미지

이러한 클라우드 애플리케이션 말로만 들으면 추상적입니다.

그래서 책에서는 예시를 소개해줍니다.

클라우드 애플리케이션 예시

2장에서는 일반적인 소프트웨어 아키텍처 패턴에 대해서 설명하고,

3장에서는 이 아키텍처 패턴이 클라우드 애플리케이션에서는 어떻게 적용될지에 대한 설명이 나온다.

12팩터앱

책의 장수가 많아서 여전히 읽고 있는 중이다.

책이 단순히 클라우드 애플리케이션에 대해서만 다루기보다는,

이 개념을 올리기 위한 아키텍처에 대한 설명도 추가되어있다.

뒷부분에 모놀리식 점진적 대체하는 법에 대한 내용도 있다.

나는 이를 기반으로 조금씩 따라가며 사내의 시스템을 개선해보려고 한다.

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

"클라우드 전환"이라는 말을 들었을 때, 처음에는 인프라 이전을 먼저 떠올렸다.

온프레미스 서버를 AWS나 Azure 같은 환경으로 옮기면 클라우드 전환이 된다고 생각했다.

그런데 실무에서 시스템을 오래 운영하다 보면, 어느 순간 변경이 두려워지는 시기가 온다.
 

주문 로직을 손봤는데 결제 영역에서 예기치 못한 문제가 발생하고, 상품 옵션 구조를 바꿨더니 정산 로직까지 영향이 번지는 일이 반복된다.

이런 문제는 단순히 코드량이 많아서 생기는 것이 아니라, 시스템의 책임 경계가 명확하지 않아서 생기는 문제라고 어렴풋이 느끼고 있었다.

한빛미디어의 클라우드 애플리케이션 아키텍처 패턴 은 그런 고민에 대한 답을 정리해 준 책이다.
 

특정 클라우드 서비스의 사용법을 알려주는 책이 아니라, 클라우드 환경에서 애플리케이션을 어떻게 설계하고 점진적으로 현대화할 것인가를 다룬다.

이 책은 "무엇을 누르세요" 가 아니라 "왜 이렇게 나누어야 하는가" 를 묻는다.

그 점에서 기술 매뉴얼이라기보다 아키텍처 사고방식을 다루는 책에 가까웠다.

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

마이크로서비스라고 하면 흔히 "큰 시스템을 작은 서비스 여러 개로 쪼개는 구조"라고 이해한다.
 

나 역시 한동안 그렇게 생각했고, 컨트롤러 단위나 기능 단위로 서비스를 나누면 그것이 마이크로서비스라고 여겼다.

이 책은 그 통념을 차분히 짚어준다.

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

크기만으로 분리한 시스템은 오히려 복잡도를 키운다.
 

서비스 간 호출이 많아지고, 한 곳의 장애가 다른 영역으로 쉽게 번진다.

결국 그것은 마이크로서비스가 아니라 분산된 형태의 모놀리식이 되어버린다.

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

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

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

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

서비스 간 네트워크 통신과 지연

데이터 정합성 유지의 어려움

장애 전파와 회복 전략

배포 단위의 증가

분산 추적과 모니터링 비용

저자는 이러한 트레이드오프를 회피하지 않고, 언제 나누지 않는 것이 더 나은가까지 함께 고민하게 한다.

"작게 나누는 것"이 아니라 "잘 나누는 것"이 본질이라는 메시지가 책 전체에 일관되게 흐른다.

이런 분께 추천합니다

모놀리식 시스템을 마이크로서비스로 점진적으로 전환하려는 백엔드 개발자

"마이크로서비스 = 작게 나누기"로 이해하고 있는 2~5년 차 개발자

회사에서 클라우드 전환 논의가 시작된 시점에 있는 개발자

도메인 주도 설계(DDD)를 들어보았지만, 실무에 어떻게 적용할지 막막한 분

시스템 설계에 대한 답변이 자꾸 추상적으로 흐르는 것이 고민인 분

사수 없이 혼자 아키텍처를 고민하고 있는 1인 백엔드 또는 작은 팀의 리드 개발자

​
 

반대로, 특정 클라우드 서비스의 실습(Docker 명령어, Kubernetes 배포, Spring Cloud 예제)을 기대하는 분에게는 다른 실습서가 더 적합할 수 있다.
 

이 책은 도구의 사용법보다, 시스템을 어떤 기준으로 설계하고 나눌 것인지를 다룬다.

정리

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

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

이 책은 마이크로서비스를 단순히 "작게 자르는 기술"이 아니라, 도메인과 책임을 기준으로 시스템을 나누는 사고방식으로 다시 보게 해주었다.

특히 바운디드 콘텍스트라는 개념 하나만으로도, 그동안 모호하게 느꼈던 설계 문제들에 이름을 붙일 수 있게 됐다.

읽는 내내 그동안 짜온 코드와 운영해 온 시스템이 머릿속에 함께 떠올랐다.
 

좋은 기술서는 정보를 전달하는 데서 그치지 않고, 자신의 경험을 다시 보게 만든다고 생각한다. 이 책은 그런 책이었다.

이 책은 “클라우드를 쓴다”는 행위를 단순히 인프라 위에 코드를 올리는 수준에서 벗어나, 어떤 아키텍처적 사고를 기반으로 시스템을 설계해야 하는지에 대한 기준을 다시 잡게 만들어준 책이라고 볼 수 있다. 특히 모놀리식에서 MSA로 이어지는 흐름을 단순한 트렌드가 아닌 문제 해결의 과정으로 설명해준 점이 인상적이다.

읽기 전에는 클라우드 환경을 활용한다는 것과, 그 위에서 동작하는 애플리케이션이 가져야 할 특성 사이의 간극을 명확히 인지하지 못했지만, 이 책을 통해 그 간극이 아키텍처 설계와 선택의 문제라는 점을 이해하게 된다. 또한 클라우드 네이티브, 상태 관리, 이벤트 기반 아키텍처 같은 개념들이 단편적인 지식이 아니라 서로 연결된 맥락 속에서 정리된다는 점에서 실무적인 통찰을 제공한다.

무엇보다 “아키텍처는 트레이드오프”라는 문장을 다시 체감하게 만든 점이 가장 큰 수확이다. 특정 패턴이 무조건 옳거나 틀린 것이 아니라, 상황과 목적에 따라 선택되어야 한다는 유연한 시각을 갖게 된 것이 이 책을 읽으며 얻은 가장 중요한 변화라고 할 수 있다.

결론적으로 이 책은 클라우드를 이미 사용하고 있지만, 그 활용 방식에 대해 한 번쯤 의문을 가져본 개발자에게 기술적 선택의 기준과 사고의 깊이를 확장시켜주는 책이다.

LLM 시대에도 아키텍처 설계는 여전히 개발자의 몫이라는 걸 이 책을 통해 다시 느꼈습니다.

아키텍처의 선택은 운영 복잡도와 트레이드오프까지 현실적으로 짚어주는 점이 인상 깊었습니다.

결국 아키텍처는 트렌드가 아니라 상황에 맞게 선택해야 하며, 필요에 따라 점진적으로 발전시키는 것이 중요하다는 메시지를 주는 책이었습니다.

이 책을 읽으면서 가장 먼저 들었던 생각은, “아, 이 책은 뭔가 당장 써먹는 기술 팁을 막 알려주는 책이라기보다는, 큰 그림을 보여주는 책이구나” 하는 느낌이었어요. 처음 제목만 봤을 때는 솔직히 클라우드 환경에서 개발할 때 바로 써먹을 수 있는 방법이나, 실무에서 자주 부딪히는 문제를 해결하는 요령 같은 걸 많이 알려줄 줄 알았거든요. 예를 들면 “이럴 때는 이 패턴을 쓰세요”, “클라우드에서 성능 문제는 이렇게 잡습니다” 같은 식의 꽤 날카로운 기술서를 상상했습니당. 그런데 막상 읽어보니 이 책은 그런 쪽보다는, 애플리케이션이 시대와 환경에 따라 어떻게 바뀌어 왔는지를 차근차근 설명해 주는 개념서에 더 가까웠어요 ㅎㅎ

책의 흐름은 꽤 넓고 커다란 지도를 펼쳐놓는 느낌이었어요. 예전의 모놀리식 구조에서 출발해서, 왜 사람들이 클라우드 네이티브라는 방향으로 가게 되었는지, 그리고 거기서 더 나아가 MSA, 그러니까 마이크로서비스 아키텍처까지 어떻게 이어지게 되었는지를 하나씩 보여줘요. 그냥 “요즘은 MSA가 대세입니다” 하고 끝나는 게 아니라, 왜 그런 변화가 생겼는지 맥락을 같이 설명해 주니까, 아키텍처를 처음 접하는 사람도 흐름을 이해하기가 비교적 쉬웠습니다. 예전에는 하나의 커다란 덩어리처럼 시스템을 만드는 게 자연스러웠는데, 클라우드가 등장하면서 더 유연하고 더 잘게 나뉜 구조가 필요해졌다는 점이 자연스럽게 이어져요. 그래서 읽다 보면 “아, 기술이 바뀐 게 아니라 환경이 바뀌니까 개발 방식도 같이 달라진 거구나” 하고 감이 옵니다 ^^

특히 인상적이었던 부분은, 이 책이 단순히 모놀리식과 MSA만 이야기하지 않는다는 점이었어요. 이벤트 기반 아키텍처, 즉 서비스끼리 서로 신호를 주고받으면서 움직이는 방식도 다루는데, 이 부분은 클라우드 시대의 시스템이 얼마나 복잡해지고 또 유기적으로 연결되는지를 보여주는 느낌이었어요. 예를 들어 예전에는 한 덩어리 안에서 순서대로 처리하던 일이, 이제는 여러 서비스가 각각 역할을 맡고 이벤트를 주고받으며 협력하는 식으로 바뀌는 거죠. 이런 설명을 읽다 보면, 우리가 흔히 “서비스가 연결되어 있다”라고 말하는 게 실제로 어떤 의미인지 조금 더 생생하게 느껴져요. 그냥 기술 용어로만 들리던 EDA가, 아 이런 식으로 서로 반응하면서 돌아가는 구조구나 하고 머릿속에 그려집니당.

또 이 책은 여기서 멈추지 않고 데이터 지속성 아키텍처도 다룹니다. SQL 데이터베이스와 NoSQL 데이터베이스를 어떤 식으로 바라볼 수 있는지, 클라우드 환경에서 저장소를 어떻게 생각해야 하는지도 함께 보여줘요. 이 부분은 당장 세세한 구현법을 알려주는 느낌은 아니지만, 왜 데이터 저장 방식까지도 아키텍처의 일부로 봐야 하는지 이해하는 데 도움이 되었어요. 그냥 “DB는 DB지” 하고 넘길 수 있는 부분을, 시스템 전체의 구조 안에서 다시 보게 해준다는 점이 좋았습니당. 가상화 아키텍처나 컨테이너화 아키텍처도 간략하게 나오는데, 전통적인 베어메탈 환경과 비교하면서 각각의 장단점을 보여주니까, 클라우드 시대의 인프라가 왜 이런 방향으로 넘어왔는지도 흐름이 보였어요.

다만 읽으면서 조금 아쉽거나 지루하게 느껴지는 순간도 있었어요 ㅋㅋ 아무래도 제목 자체가 “아키텍처 패턴”이고, 내용도 아키텍처를 중심으로 흘러가다 보니, 설명이 꽤 추상적으로 느껴질 때가 있거든요. 그런데 이 추상성을 줄이려고 “애플리케이션”이라는 말을 같이 붙여 설명하다 보니, 어떤 부분에서는 비슷한 이야기가 반복되는 느낌도 있었어요. 아키텍처와 애플리케이션이 사실 완전히 떨어질 수 없는 관계이긴 한데, 그 둘을 계속 묶어서 풀어가다 보면 “어? 이 말 아까도 비슷하게 본 것 같은데?” 싶은 순간이 생겨요. 그래서 술술 읽히는 소설 같은 재미를 기대하면 조금 힘들 수도 있겠다는 생각이 들었어요. 개념서가 원래 그렇긴 하지만요 ㅎㅎ

그래도 이 책의 장점은 분명했어요. 이 책은 하나의 정답을 강요하지 않아요. “모놀리식은 무조건 나쁘고, MSA는 무조건 좋다” 같은 단순한 결론으로 몰아가지 않아서 좋았어요. 오히려 각각의 구조가 어떤 배경에서 나왔고, 어떤 장점과 한계가 있으며, 서로 어떤 관계를 맺고 있는지를 넓게 보여줍니다. 그래서 읽고 나면 “무조건 최신 구조가 최고다”라는 생각보다는, “상황에 따라 적합한 아키텍처가 다를 수 있겠구나”라는 쪽으로 시야가 넓어져요. 이건 실무를 하는 사람에게도 꽤 중요한 감각이라고 생각해요. 기술이라는 게 유행처럼 보이지만, 실제로는 문제와 환경에 맞춰 선택해야 하는 거니까요.

저는 이 책을 읽으면서 마치 개발의 역사 수업을 듣는 느낌도 조금 받았어요. 예전에는 왜 그런 방식이 자연스러웠는지, 그리고 지금은 왜 이렇게 바뀌었는지, 그 흐름이 연결되어 보였거든요. 그래서 단순히 “이 기술이 뭔가요?”를 배우는 책이라기보다는, “지금 우리가 왜 이런 기술과 구조를 이야기하고 있는가?”를 이해하게 해주는 책에 가까웠어요. 실무에서 바로 복붙해서 쓸 수 있는 팁은 많지 않을 수 있지만, 대신 머릿속에 큰 지도 하나를 그려주는 느낌이 있습니다. 그런 점에서 꽤 의미 있는 책이었어용.

추천 대상을 생각해 보면 더 분명해져요. 클라우드 환경에서 당장 문제를 해결할 수 있는 비법이나, 실전용 기술 팁을 기대하는 분이라면 약간 아쉬울 수도 있어요. “이럴 때는 쿠버네티스를 이렇게 쓰세요”, “MSA 장애는 이렇게 대응하세요” 같은 바로바로 적용 가능한 기술서를 기대했다면 살짝 방향이 다르다고 느낄 것 같습니다. 반대로, 애플리케이션이 어떤 구조로 발전해 왔는지, 모놀리식에서 클라우드 네이티브와 마이크로서비스로 가는 변화의 큰 흐름이 무엇인지 궁금한 분이라면 만족도가 높을 것 같아요. 특히 아키텍처라는 말이 늘 어렵고 멀게 느껴졌던 분들에게는, 여러 종류의 아키텍처를 한 권으로 훑어볼 수 있다는 점에서 꽤 괜찮은 입문서처럼 느껴질 수 있어요 ^^

결론적으로 이 책은 “클라우드에서 바로 써먹는 날카로운 기술 팁 모음집”이라기보다는, “클라우드 시대에 애플리케이션 아키텍처가 어떻게 변해 왔는지를 알려주는 개념 중심의 안내서”에 가깝습니다. 모놀리식부터 시작해서 클라우드 네이티브, MSA, 이벤트 기반 아키텍처, 데이터 지속성, 가상화와 컨테이너화까지 폭넓게 다뤄서, 전체 흐름을 이해하는 데 도움을 줘요. 그래서 읽고 나면 실전 꼼수를 한가득 얻었다기보다는, 아키텍처를 바라보는 눈이 조금 넓어진 느낌이 남습니다. 저는 그래서 이 책을 “기술서”보다는 “개념서”로 기대하고 읽으면 훨씬 만족스러울 책이라고 생각했어요. 쉽게 말하면, 망치나 드라이버를 바로 쥐여주는 책이라기보다는, 집이 어떻게 지어지는지 전체 구조를 먼저 보여주는 책 같았습니당 ㅎㅎ 그런 의미에서 애플리케이션 아키텍처 자체가 궁금한 분들께는 꽤 잘 맞는 책이라고 느꼈어요.

클라우드 애플리케이션 개발 시 뭔가 팁을 얻을 수 있는 ‘기술서’를 상상했는데 ‘개념서’에 가까웠다. 

모놀리식부터 시작해 MSA에 이르기까지 애플리케이션 아키텍처의 변화와 이벤트 주도 아키텍처, 모놀리식을 클라우드로 바꾸는 방법까지 살짝 알려준다. 

애플리케이션 아키텍처 그 자체가 궁금하신 분들에게 적합한 책이다.