|
2023년 기존 솔루션을 MSA로 전환하려고 시도한 적이 있었다. 자료 조사 과정에서 기술 부채라는 엄청난 현실과 마주한 채 포기해야만 했다. 모놀리식 애플리케이션과 클라우드 네이티브 애플리케이션은 용어부터 개념, 설계까지 근본적으로 달랐다. 중소기업에서는 전환을 위한 투자 비용도 고려해야 하기 때문에 중도에 포기할 수밖에 없었다. 그러는 동안 공공기관에서는 많은 애플리케이션이 리프트 앤 시프트 방식으로 클라우드 환경으로 전환을 진행했다. 민간뿐만 아니라 공공기관에서도 인프라 관점에서 클라우드 환경은 디폴트가 되었다. 지금은 클라우드 환경에 맞는 클라우드 네이티브 애플리케이션으로 전환을 시도하거나 준비 중인 것으로 알고 있다. 2026년 기존 솔루션을 다시 MSA로 전환하고 있다. 지금 이 책을 읽게 된 것은 개인적으로 참 행운이라고 생각한다. 내가 알지도 못했을, 앞으로 겪게 될 문제점들과 시도할 만한 해결책들이 고스란히 책에 소개되어 있다. 나도 잘 몰랐던 클라우드 애플리케이션으로 전환해야 할 이유를 설명하고, 클라우드 애플리케이션 전환을 위한 전 과정(개념, 아키텍처, 설계 패턴, 스토리지(DB), 클라이언트)을 그림과 예시로 설명한다. 각각의 모범 사례 마지막에는 실제로 구현되는 형태를 항공권 예약 시스템, 전자상거래, 금융시스템 등의 실제 상황을 예를 들어 설명함으로 해서 한결 이해가 쉬웠다. 특히, 9장과 10장의 내용이 공감이 많이 되었다. 기존 솔루션이나 서비스를 클라우드 애플리케이션으로 마이그레이션 및 클라우드 네이티브 애플리케이션(클라우드 환경에서 최적화 하는 방법)으로 고도화하는 실천적으로 내용이기 때문이다. 우버, 넷플릭스, eBay, 아마존의 사례가 포함되어 있어서 더욱 흥미를 끌었다. 이 책에서 느낀 점은 주제가 아키텍처 패턴이지만, 지루하지 않았으며 실천적인 내용으로 채워져 있어서 당장이라도 적용하고 싶은 내용이 많았다. 패턴 설명은 진행 과정을 그림으로 설명하고, 마지막에 구현 사례를 예를 들어 설명하기 때문에 이해하는데 어렵지 않았다.
＜4장 클라우드 애프릴케이션 아키텍처 패턴, p232~p233＞ ＜9장 애플리케이션 이전과 현대화, p631~p632＞
＜10장 모놀리식 점진적 대체, p655~p656＞
＜11장 총정리, p714~p715＞
우리의 애플리케이션이 구동할 클라우드 환경은 이제 성숙되었다. 우리는 그 환경에 최적화된 애플리케이션을 개발해야 한다. 2026년 클라우드 네이티브 애플리케이션은 선택이 아니라 필수다. 이 책은 분산 환경뿐만 아니라 앞으로 개발되는 모든 프로그램 설계 패턴의 기본이 될 것으로 확신한다. |
|
한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. 클라우드 애플리케이션 아키텍처 패턴(한빛미디어, 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) www.hanbit.co.kr https://www.hanbit.co.kr/store/books/look.php?p_code=B3991962451 한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
|
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장에서는 이 아키텍처 패턴이 클라우드 애플리케이션에서는 어떻게 적용될지에 대한 설명이 나온다.   책의 장수가 많아서 여전히 읽고 있는 중이다. 책이 단순히 클라우드 애플리케이션에 대해서만 다루기보다는, 이 개념을 올리기 위한 아키텍처에 대한 설명도 추가되어있다. 뒷부분에 모놀리식 점진적 대체하는 법에 대한 내용도 있다. 나는 이를 기반으로 조금씩 따라가며 사내의 시스템을 개선해보려고 한다. |
|
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.   배경내가 웹 개발을 본격적으로 배우기 시작했을 무렵에는 이미 클라우드 기반의 워크플로가 표준이었다. 특정 플랫폼에서 자원을 할당받고, 터미널로 접속하여 웹 서버를 구동했다. 방화벽과 공유기 설정으로 로컬 서버를 개방하는 방법을 안 것은 그로부터 좀 시간이 지난 후였다. 생각해보면 클라우드 환경은 내게 '당연히 그래야만 하는 것' 정도로 받아들여졌던 것 같다. 그 이전과는 어떻게 다른지, 그래서 보다 클라우드 환경에 적합한 구조는 무엇인지 생각해본 적이 없었다. 다들 AWS 쓰니까, Docker 쓰니까, Kafka 쓰니까. 마이크로서비스나 이벤트 기반, 도메인 기반 아키텍처도 마찬가지다. 별 생각 없이 막연히 좋아보인다고만 생각했던 것 같다. 첫 인상: 친절하다다루는 내용을 논하기 전에, 일단 기본적으로 이 책은 친절하다. 해결책을 패턴화해서 잘 정리해둔 것도 그렇고, 또 각 패턴에 대한 설명에 도식을 활용하여 구조적으로 이해하기 좋았다. 책, 논문 등을 통해 이미 유명한 내용들을 잘 정리했고, 그에 대한 인용이나 링크도 많아 깊게 파고들기 좋았다. 패턴으로 구성된 책들은 대게 사이 연결성이 부족해서 순서대로 읽는 것이 의미가 없는 경우도 있는데, 이 책은 일종의 기초-응용-심화의 느낌으로 각 장을 진행해서 책장을 차례대로 넘길 때 얻는 것이 더 많았다.   내용: 설계 교과서'설계 교과서'라고 표현한 이유는, 이 책이 개발이 아닌 설계에 집중하고, 저자의 개인적인 노하우보다 업계 전반에 잘 알려진 유명한 내용을 잘 종합했기 때문이다. 보통 주제를 넓게 커버하는 책들은 난해한 내용에 대해 설명이 빈약한 경우가 있는데, 적어도 나는 그런 느낌은 받지 못했다. 가령, 도메인과 관련한 내용은 보통 책 한 권의 분량으로 다룬다. 그 한 권에서도 대부분 자신의 도메인에 대한 직접적인 사례는 얻지 못하는데, 때문에 난 읽고 직접 자신의 경우에 활용할 수 있을 정도의 충분한 설명이 있는가를 중요하게 봤다. 그리고 이 책은 내 기준에는 합격했다.    반드시 알아야 하는 내용들로 꾹꾹 담은 이 책은 입문자부터 중급자까지 실무를 위해 직접 활용할 수 있는 수준의 풍부한 설명을 제공한다. 그러나 기본적으로 신선한 내용과는 거리가 있다는 것을 알아둘 필요가 있다. (물론 흐름을 놓친 누군가에게는 새로운 것들이겠지만) 적어도 나는 이 책을 읽으면서 IDEALS라는 개념은 새롭게 알게 되었다. 이는 객체 지향 원칙의 SOLID와 유사한 느낌으로, 2020년 발표된 마이크로서비스 설계 원칙이고, 이 책의 전반에 걸쳐 언급되는 유용한 개념이다.   www.infoq.com 후기: 현대화가 낯설다면'현대화'라는 단어. 막상 사용하고보니 좀 폭력적인 것 같다. 이러한 흐름에 동참하지 않으면 구닥다리 뒷방 노인네처럼 도태되어 버리는 건 아닌가 싶은 상상이 든다. 그러나 사실 책을 읽어보면 이 책은 변화를 절대 강제하지 않는다. 전통적인 구조부터 현대의 구조까지, 모든 것에는 주어진 환경에서 최선을 다한 이들의 서사가 녹아있다. 저자는 서로 다른 방법론 간에 우열을 가리지 않고, 진지하게 마주하며 장단점을 논한다. 전통적 구조의 서비스를 현대적으로 개편하기 위한 방법을 2개의 장에 걸쳐 제시하니, 우리 엔지니어들은 각자의 상황에 맞게 결정하면 된다. 필요하면 가져다 쓰는 것, 그 뿐이다. 70여개의 설계 패턴을 보며 느낀 것은, 객체 지향 언어의 디자인 패턴과 유사하게, 결국 정의된 역할을 어떻게 추상화하냐가 관건인 것 같다. 다만, 개발보다 설계 수준에서의 변경은 비용이 비싸다는 점이 차이인 것 같고, 때문에 이렇게 정형화된 방식을 익혀놓는 것이 더 의미있게 다가왔다. 클라우드가 바꾼 생태계의 모습이 낯선 이들에게 이 책은 앞으로의 개발 방향성을 올바르게 잡아나가는 데 큰 도움이 될 것이라 생각한다. #한빛미디어 #한빛미디어서평단 #클라우드_애플리케이션_아키텍처_패턴 |
|
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다." "클라우드 전환"이라는 말을 들었을 때, 처음에는 인프라 이전을 먼저 떠올렸다. 온프레미스 서버를 AWS나 Azure 같은 환경으로 옮기면 클라우드 전환이 된다고 생각했다. 그런데 실무에서 시스템을 오래 운영하다 보면, 어느 순간 변경이 두려워지는 시기가 온다. 주문 로직을 손봤는데 결제 영역에서 예기치 못한 문제가 발생하고, 상품 옵션 구조를 바꿨더니 정산 로직까지 영향이 번지는 일이 반복된다. 이런 문제는 단순히 코드량이 많아서 생기는 것이 아니라, 시스템의 책임 경계가 명확하지 않아서 생기는 문제라고 어렴풋이 느끼고 있었다. 한빛미디어의 클라우드 애플리케이션 아키텍처 패턴 은 그런 고민에 대한 답을 정리해 준 책이다. 특정 클라우드 서비스의 사용법을 알려주는 책이 아니라, 클라우드 환경에서 애플리케이션을 어떻게 설계하고 점진적으로 현대화할 것인가를 다룬다. 이 책은 "무엇을 누르세요" 가 아니라 "왜 이렇게 나누어야 하는가" 를 묻는다. 그 점에서 기술 매뉴얼이라기보다 아키텍처 사고방식을 다루는 책에 가까웠다. 마이크로서비스, 크기보다 중요한 것마이크로서비스라고 하면 흔히 "큰 시스템을 작은 서비스 여러 개로 쪼개는 구조"라고 이해한다. 나 역시 한동안 그렇게 생각했고, 컨트롤러 단위나 기능 단위로 서비스를 나누면 그것이 마이크로서비스라고 여겼다. 이 책은 그 통념을 차분히 짚어준다. 마이크로서비스의 본질은 크기를 작게 만드는 것이 아니라, 비즈니스 책임과 도메인 경계로 시스템을 나누는 것이라는 점이다. 크기만으로 분리한 시스템은 오히려 복잡도를 키운다. 서비스 간 호출이 많아지고, 한 곳의 장애가 다른 영역으로 쉽게 번진다. 결국 그것은 마이크로서비스가 아니라 분산된 형태의 모놀리식이 되어버린다. 마이크로서비스가 정답이 아닐 때이 책에서 좋게 느낀 또 하나의 지점은, 저자가 마이크로서비스를 만능 해법으로 제시하지 않는다는 점이다.
서비스를 분리할수록 새로운 문제들이 함께 따라온다.
저자는 이러한 트레이드오프를 회피하지 않고, 언제 나누지 않는 것이 더 나은가까지 함께 고민하게 한다. "작게 나누는 것"이 아니라 "잘 나누는 것"이 본질이라는 메시지가 책 전체에 일관되게 흐른다. 이런 분께 추천합니다
반대로, 특정 클라우드 서비스의 실습(Docker 명령어, Kubernetes 배포, Spring Cloud 예제)을 기대하는 분에게는 다른 실습서가 더 적합할 수 있다. 이 책은 도구의 사용법보다, 시스템을 어떤 기준으로 설계하고 나눌 것인지를 다룬다. 정리클라우드 애플리케이션 아키텍처 패턴 은 한 문장으로 정리하면 다음과 같다.
이 책은 마이크로서비스를 단순히 "작게 자르는 기술"이 아니라, 도메인과 책임을 기준으로 시스템을 나누는 사고방식으로 다시 보게 해주었다. 특히 바운디드 콘텍스트라는 개념 하나만으로도, 그동안 모호하게 느꼈던 설계 문제들에 이름을 붙일 수 있게 됐다. 읽는 내내 그동안 짜온 코드와 운영해 온 시스템이 머릿속에 함께 떠올랐다. 좋은 기술서는 정보를 전달하는 데서 그치지 않고, 자신의 경험을 다시 보게 만든다고 생각한다. 이 책은 그런 책이었다. |
|
이 책을 읽으면서 가장 먼저 들었던 생각은, “아, 이 책은 뭔가 당장 써먹는 기술 팁을 막 알려주는 책이라기보다는, 큰 그림을 보여주는 책이구나” 하는 느낌이었어요. 처음 제목만 봤을 때는 솔직히 클라우드 환경에서 개발할 때 바로 써먹을 수 있는 방법이나, 실무에서 자주 부딪히는 문제를 해결하는 요령 같은 걸 많이 알려줄 줄 알았거든요. 예를 들면 “이럴 때는 이 패턴을 쓰세요”, “클라우드에서 성능 문제는 이렇게 잡습니다” 같은 식의 꽤 날카로운 기술서를 상상했습니당. 그런데 막상 읽어보니 이 책은 그런 쪽보다는, 애플리케이션이 시대와 환경에 따라 어떻게 바뀌어 왔는지를 차근차근 설명해 주는 개념서에 더 가까웠어요 ㅎㅎ 책의 흐름은 꽤 넓고 커다란 지도를 펼쳐놓는 느낌이었어요. 예전의 모놀리식 구조에서 출발해서, 왜 사람들이 클라우드 네이티브라는 방향으로 가게 되었는지, 그리고 거기서 더 나아가 MSA, 그러니까 마이크로서비스 아키텍처까지 어떻게 이어지게 되었는지를 하나씩 보여줘요. 그냥 “요즘은 MSA가 대세입니다” 하고 끝나는 게 아니라, 왜 그런 변화가 생겼는지 맥락을 같이 설명해 주니까, 아키텍처를 처음 접하는 사람도 흐름을 이해하기가 비교적 쉬웠습니다. 예전에는 하나의 커다란 덩어리처럼 시스템을 만드는 게 자연스러웠는데, 클라우드가 등장하면서 더 유연하고 더 잘게 나뉜 구조가 필요해졌다는 점이 자연스럽게 이어져요. 그래서 읽다 보면 “아, 기술이 바뀐 게 아니라 환경이 바뀌니까 개발 방식도 같이 달라진 거구나” 하고 감이 옵니다 ^^ 특히 인상적이었던 부분은, 이 책이 단순히 모놀리식과 MSA만 이야기하지 않는다는 점이었어요. 이벤트 기반 아키텍처, 즉 서비스끼리 서로 신호를 주고받으면서 움직이는 방식도 다루는데, 이 부분은 클라우드 시대의 시스템이 얼마나 복잡해지고 또 유기적으로 연결되는지를 보여주는 느낌이었어요. 예를 들어 예전에는 한 덩어리 안에서 순서대로 처리하던 일이, 이제는 여러 서비스가 각각 역할을 맡고 이벤트를 주고받으며 협력하는 식으로 바뀌는 거죠. 이런 설명을 읽다 보면, 우리가 흔히 “서비스가 연결되어 있다”라고 말하는 게 실제로 어떤 의미인지 조금 더 생생하게 느껴져요. 그냥 기술 용어로만 들리던 EDA가, 아 이런 식으로 서로 반응하면서 돌아가는 구조구나 하고 머릿속에 그려집니당. 또 이 책은 여기서 멈추지 않고 데이터 지속성 아키텍처도 다룹니다. SQL 데이터베이스와 NoSQL 데이터베이스를 어떤 식으로 바라볼 수 있는지, 클라우드 환경에서 저장소를 어떻게 생각해야 하는지도 함께 보여줘요. 이 부분은 당장 세세한 구현법을 알려주는 느낌은 아니지만, 왜 데이터 저장 방식까지도 아키텍처의 일부로 봐야 하는지 이해하는 데 도움이 되었어요. 그냥 “DB는 DB지” 하고 넘길 수 있는 부분을, 시스템 전체의 구조 안에서 다시 보게 해준다는 점이 좋았습니당. 가상화 아키텍처나 컨테이너화 아키텍처도 간략하게 나오는데, 전통적인 베어메탈 환경과 비교하면서 각각의 장단점을 보여주니까, 클라우드 시대의 인프라가 왜 이런 방향으로 넘어왔는지도 흐름이 보였어요. 다만 읽으면서 조금 아쉽거나 지루하게 느껴지는 순간도 있었어요 ㅋㅋ 아무래도 제목 자체가 “아키텍처 패턴”이고, 내용도 아키텍처를 중심으로 흘러가다 보니, 설명이 꽤 추상적으로 느껴질 때가 있거든요. 그런데 이 추상성을 줄이려고 “애플리케이션”이라는 말을 같이 붙여 설명하다 보니, 어떤 부분에서는 비슷한 이야기가 반복되는 느낌도 있었어요. 아키텍처와 애플리케이션이 사실 완전히 떨어질 수 없는 관계이긴 한데, 그 둘을 계속 묶어서 풀어가다 보면 “어? 이 말 아까도 비슷하게 본 것 같은데?” 싶은 순간이 생겨요. 그래서 술술 읽히는 소설 같은 재미를 기대하면 조금 힘들 수도 있겠다는 생각이 들었어요. 개념서가 원래 그렇긴 하지만요 ㅎㅎ 그래도 이 책의 장점은 분명했어요. 이 책은 하나의 정답을 강요하지 않아요. “모놀리식은 무조건 나쁘고, MSA는 무조건 좋다” 같은 단순한 결론으로 몰아가지 않아서 좋았어요. 오히려 각각의 구조가 어떤 배경에서 나왔고, 어떤 장점과 한계가 있으며, 서로 어떤 관계를 맺고 있는지를 넓게 보여줍니다. 그래서 읽고 나면 “무조건 최신 구조가 최고다”라는 생각보다는, “상황에 따라 적합한 아키텍처가 다를 수 있겠구나”라는 쪽으로 시야가 넓어져요. 이건 실무를 하는 사람에게도 꽤 중요한 감각이라고 생각해요. 기술이라는 게 유행처럼 보이지만, 실제로는 문제와 환경에 맞춰 선택해야 하는 거니까요. 저는 이 책을 읽으면서 마치 개발의 역사 수업을 듣는 느낌도 조금 받았어요. 예전에는 왜 그런 방식이 자연스러웠는지, 그리고 지금은 왜 이렇게 바뀌었는지, 그 흐름이 연결되어 보였거든요. 그래서 단순히 “이 기술이 뭔가요?”를 배우는 책이라기보다는, “지금 우리가 왜 이런 기술과 구조를 이야기하고 있는가?”를 이해하게 해주는 책에 가까웠어요. 실무에서 바로 복붙해서 쓸 수 있는 팁은 많지 않을 수 있지만, 대신 머릿속에 큰 지도 하나를 그려주는 느낌이 있습니다. 그런 점에서 꽤 의미 있는 책이었어용. 추천 대상을 생각해 보면 더 분명해져요. 클라우드 환경에서 당장 문제를 해결할 수 있는 비법이나, 실전용 기술 팁을 기대하는 분이라면 약간 아쉬울 수도 있어요. “이럴 때는 쿠버네티스를 이렇게 쓰세요”, “MSA 장애는 이렇게 대응하세요” 같은 바로바로 적용 가능한 기술서를 기대했다면 살짝 방향이 다르다고 느낄 것 같습니다. 반대로, 애플리케이션이 어떤 구조로 발전해 왔는지, 모놀리식에서 클라우드 네이티브와 마이크로서비스로 가는 변화의 큰 흐름이 무엇인지 궁금한 분이라면 만족도가 높을 것 같아요. 특히 아키텍처라는 말이 늘 어렵고 멀게 느껴졌던 분들에게는, 여러 종류의 아키텍처를 한 권으로 훑어볼 수 있다는 점에서 꽤 괜찮은 입문서처럼 느껴질 수 있어요 ^^ 결론적으로 이 책은 “클라우드에서 바로 써먹는 날카로운 기술 팁 모음집”이라기보다는, “클라우드 시대에 애플리케이션 아키텍처가 어떻게 변해 왔는지를 알려주는 개념 중심의 안내서”에 가깝습니다. 모놀리식부터 시작해서 클라우드 네이티브, MSA, 이벤트 기반 아키텍처, 데이터 지속성, 가상화와 컨테이너화까지 폭넓게 다뤄서, 전체 흐름을 이해하는 데 도움을 줘요. 그래서 읽고 나면 실전 꼼수를 한가득 얻었다기보다는, 아키텍처를 바라보는 눈이 조금 넓어진 느낌이 남습니다. 저는 그래서 이 책을 “기술서”보다는 “개념서”로 기대하고 읽으면 훨씬 만족스러울 책이라고 생각했어요. 쉽게 말하면, 망치나 드라이버를 바로 쥐여주는 책이라기보다는, 집이 어떻게 지어지는지 전체 구조를 먼저 보여주는 책 같았습니당 ㅎㅎ 그런 의미에서 애플리케이션 아키텍처 자체가 궁금한 분들께는 꽤 잘 맞는 책이라고 느꼈어요. |
|
＜클라우드 애플리케이션 아키텍처 패턴＞은 모놀리식에서 클라우드 네이티브를 거쳐 MSA까지 클라우드의 등장과 함께 애플리케이션의 개발 방식이 어떻게 변했는지 설명한다. 그리고 서로 이벤트를 주고 받으며 서비스하는 이벤트 주도 아키텍처까지 이야기 후 모놀리식을 어떻게 클라우드 네이티브로 옮길 수 있을지도 살짝 언급한다. '아키텍처 패턴'이라 '아키텍처' 이야기가 나오는데 이게 또 애플리케이션을 빼고 설명하기엔 너무 추상적이지 않은가? 그래서 '아키텍처'와 '애플리케이션'이 쌍으로 나오곤 하는데 그러다보니 같은 이야기 자꾸 나오는거 같아 지루할 때가 좀 있다. 클라우드 환경에서 어떤 문제를 해결하기 위한 팁을 얻어가는 것 보다는 '개념서'로 접근하면 더 만족스러울것 같다. |
