클라우드 네이티브 애플리케이션 디자인 패턴: AI 플랫폼 개발자의 아키텍처 성찰

https://www.oreilly.com/library/view/design-patterns-for/9781492090700/

들어가며: 쿠버네티스를 쓴다고 모두 '클라우드 네이티브'는 아닙니다.

저는 GPU 기반의 LLM 학습 및 서빙 플랫폼을 개발하고 있습니다.
GPU 리소스 집약적인 로직을 다루다 보니 당연히 쿠버네티스 환경을 사용하고 있으며, 나름대로 클라우드 네이티브한 환경에서 개발하고 있다고 생각했습니다.

그러나 구현에만 집중한 나머지 결합도가 높아 문제가 발생했습니다.
예를 들어 학습과 서빙 파트를 분리하고 싶은데, 현재 개발된 내용으로는 어렵습니다. 
만약 MSA (MicroService Architecture)를 고려하여 느슨하게 서비스들을 개발했다면 어렵지 않게 문제를 해결했을 것 같다는 생각이 들었습니다.

단순히 툴을 사용하는 것을 넘어, 클라우드 환경에 최적화된 설계의 본질을 이해하고 싶어 이 책을 접했습니다.

 

클라우드 네이티브 애플리케이션이란?

이 책에서 가장 처음 다루는 내용입니다. CNCF에서는 아래와 같이 클라우드 네이티브를 정의합니다.

https://www.cncf.io/about/who-we-are/#:~:text=Cloud%20Native%20Definition

Who We Are

 

클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다.
이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화 기능을 함께 사용하면, 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다.

 

간단히 말해 "기존 애플리케이션 개발/배포 관행을 벗어나, 클라우드 인프라의 유연함과 확장성을 최대한 살릴 수 있는 접근 방법"이라 할 수 있습니다.

클라우드 네이티브 애플리케이션은 클라우드 네이티브의 요구 조건을 충족하는 애플리케이션이며, 독립적으로 만들어진 서비스들을 느슨하게 결합하는 것으로 설계됩니다.
그리고 이런 조건을 만족하는 서비스들을 마이크로서비스(MSA)라고 합니다.

이 개념은 기존의 구조의 한계를 개선하고자 고안되었으며, 차이점은 아래와 같습니다.

비교 항목	SOA (서비스 지향 아키텍처)	MSA (마이크로서비스 아키텍처)
서비스 크기	크고 포괄적	작고 세분화됨
통신 방식	ESB(Enterprise Service Bus)라는 거대한 통로를 통해 통신	API Gateway 또는 가벼운 REST/메시징 프로토콜 활용
데이터 공유	여러 서비스가 하나의 데이터베이스를 공유	각 서비스가 전용 데이터베이스를 가짐
배포 방식	서비스 간 의존성이 높아 일괄 배포가 잦음	각 서비스가 독립적으로 빌드 및 배포 가능

MSA에서는 서비스가 작고 세분화되어 있기 때문에 서비스 간에 통신이 자주 발생하게 됩니다.
이 책에서는 이러한 문제를 다루기 위한 6가지 핵심 설계 패턴을 설명합니다.

 

---

아래 내용은 책을 다시 읽어보며, 간단히 정리한 내용입니다.
책에는 좀 더 상세한 내용과 그림으로 이해를 도우니 참고 부탁드립니다. 😊

1. 통신 패턴 🪡

기존의 서비스를 여러 개의 마이크로서비스로 분리하여 개발되기 때문에 마이크로서비스 간에 통신을 필수적으로 이루어집니다.
서비스 간에 통신을 구현하기 위한 방법을 소개합니다.

동기 메시징 패턴

• 하나 이상의 다른 마이크로서비스가 제공하는 기능을 호출하고 지정된 시간 내에 응답을 받는 방식
• REST나 gRPC가 대표적
• 설계가 직관적이지만, 서비스 간의 의존성이 생긴다는 단점

비동기 메시징 패턴

• 메시지 큐(Kafka, RabbitMQ 등)를 사이에 둠
• 서비스 간의 결합도를 낮추는 가장 강력한 방법

 

---

2. 연결성 및 조합 패턴 🪢

마이크로서비스의 수가 급증하고 비즈니스 요구사항이 많아지면 이를 구현하기 위해 짜임새있는 내부 통신 구조를 설계할 필요가 있습니다.

연결성 패턴

마이크로서비스 간, 혹은 다른 시스템 간에 연결성을 확보하는 방법입니다.

서비스 연결성 패턴

• 고수준 패턴으로 서비스 간, 서비스와 외부 시스템 간 연결성을 확보
• 하나 이상의 통신 패턴으로 클라우드 네이티브 애플리케이션 내의 연결성을 만듬

서비스 추상화 패턴 

• 개별 서버의 IP가 아닌, '서비스 이름'이라는 고정된 인터페이스 뒤로 구현을 숨기는 것
• 쿠버네티스와 같은 플랫폼은 서비스 추상화 기능을 기본적으로 제공함

서비스 레지스트리 및 검색 패턴 

• 동적으로 변하는 서비스 인스턴스들의 주소를 등록하고(Registry), 호출자가 이를 찾는(Discovery) 메커니즘
• 쿠버네티스에서는 DNS 이름을 통해서 서비스를 검색할 수 있음 (etcd가 실질적인 서비스 레지스트리 역할을 수행)

탄력적인 연결성 패턴

• 만약 연결에 문제가 발생할 경우 이를 처리하거나 복구할 수 있도록 함
• 타임아웃, 재시도, deadline, 회로 차단기 , fail-fast 등의 방법을 통해서 구현 가능

사이드카 패턴

• 마이크로서비스 런타임과는 별개의 다른 런타임에 서비스간 통신 로직을 구현
• 각 서비스의 비즈니스 로직에서는 네트워크 통신(보안, 트래픽 라우팅, 서비스 검색 등)에 대해서 신경 쓸 필요가 없는 장점이 있음
• 관리 포인트가 늘어나는 문제가 있음

서비스 메시 패턴

• 사이드카 패턴을 확장한 것으로 모든 서비스 간 통신은 사이드카 프록시를 통해 이루어짐
• 마이크로서비스의 수가 증가함에 따라 배포/관리가 복잡해질 때 사용
• 대표적으로 Istio, Linkerd가 널리 사용되고 있음

사이드카 없는 서비스 메시 패턴 (아직 개발 초기 단계)

• 마이크로서비스별로 사이드카를 둬야하기 때문에 성능 부하가 발생할 수 있어 이를 극복하기 위해 사용함
• 마이크로서비스 내부에 사이드카 프록시 로직을 내장함

 

서비스 조합 패턴

비즈니스 기능은 마이크로서비스 간의 상호작용을 통해서 완성됩니다.
여러 서비스와 시스템들을 통합하고 연결해서 어떻게 비즈니스 기능을 구현하는지 다룹니다.

서비스 오케스트레이션 패턴

• 단일 서비스에 조합 로직을 구현하고 여러 서비스와 시스템을 호출해서 비즈니스 기능을 구현함
• 결합도가 상대적으로 높아, 여러 다운스트림 기능을 조합해서 특정 비즈니스 기능을 만들 수 있을 경우만 적용해야 함

서비스 코레오그래피 패턴

• 마이크로서비스와 시스템 간 비동기 통신을 통해 서비스를 조합하고 비즈니스 기능을 만듬
• 브로커를 통해 생산되거나 전달된 이벤트를 기반하여 서로 상호작용함
• 비동기 통신을 통하기 때문에 결합도가 낮음

사가 패턴

• 서비스 간 상호작용을 트랜잭션으로 동작
• 모든 트랙잭션은 전체가 성공해야 트랜잭션이 완성되며, 하나라도 실패하면 보상 트랜잭션을 실행해 전체 하위 트랜잭션들을 취소하고 원래 상태로 복구

 

---

3. 데이터 관리 패턴 📊

애플리케이션 뿐만 아니라, 데이터 관리도 클라우드의 이점을 최대한 살리는 방향으로 구조를 설계할 수 있습니다.

데이터 관리

중앙 데이터 관리

• 모든 데이터를 단일 데이터베이스에서 저장
• 아주 높은 데이터 일관성
• 애플리케이션을 독립적으로 개선하기 어려우며, 클라우드 네이티브 애플리케이션에서 피해야 할 패턴

분산 데이터 관리

• 각 마이크로서비스가 별도의 데이터 스토어를 사용
• 개발 팀이나 소유자가 별도로 나누어져 있어 데이터 소유권 문제를 쉽게 해결할 수 있음
• 서비스 별로 데이터에 더 적합한 데이터 스토어를 사용할 수 있음

하이브리드 데이터 관리

• 위 데이터 관리 방법을 함께 사용
• 예를 들어 최근의 데이터 보호 관련 법률을 적용하거나, 보안 정책을 강제하는 것은 중앙 데이터베이스를 사용

 

데이터 조합 패턴

데이터 서비스 패턴

• DB의 데이터를 서비스 형태(API)로 제공
• 보안 및 스로틀링 기능을 통해서 데이터 접근을 컨트롤 가능

조합 데이터 서비스 패턴

• 하나 이상의 데이터 서비스로부터 데이터를 읽어서 조합하여 원하는 데이터를 제공
• 사용자가 아닌 데이터 서비스에서 데이터를 조합하기 때문에 서버사이드 매시업 패턴이라 부름

클라이언트-사이드 매시업 패턴

• 클라이언트 측이 여러 데이터 서비스에서 데이터를 가져와 조합하고 사용
• 비동기 데이터 로딩을 통해서 중요한 정보는 먼저 보여주고, 세부적인 데이터를 나중에 표시하여 웹 페이지가 빨리 로드되는 인상을 주기 위해 주로 사용

 

데이터 확장 패턴

데이터 확장을 통해서 데이터를 읽고 쓰는 작업을 최적화하고, 서비스나 데이터 스토어의 병목 지점을 방지할 수 있습니다.

데이터 샤딩 패턴

• 데이터 스토어를 샤드(shard)로 나누어서 데이터 저장 및 읽기 규모를 자유롭게 조절함
  • 수평적 데이터 샤딩: 각 샤드는 같은 스키마를 사용하지만, 샤딩 키에 따라 서로 다른 데이터 레코드를 가짐
  • 수직적 데이터 샤딩: 각 샤드들이 같은 스키마를 사용하지 않으며, 서로 다른 데이터 필드를 가질 수 있음. 각 마이크로서비스마다 필요한 데이터만 조회할 수 있어 I/O 효율이 증가
• 데이터 스토어의 병목 현상을 방지할 수 있음
• 샤드의 데이터 양을 최대한 비슷하게 만들어서 부하가 고루 분산될 수 있도록 해야 함

명령과 조회 책임 분리 패턴 (CQRS)

• 데이터 셋의 변경과 질의를 분리하여 각각의 동작이 서로 다른 데이터 스토어를 다루도록 해서 빠르게 처리함
• 서로 다른 도메인 모델을 사용하고자 할 때, 성능이나 보안 문제로 데이터 변경/읽기를 분리하고자 할 때 사용
• 높은 확장성/보안성을 제공하지만, 높은 일관성은 제공하지 않음 (쓰기 전용 DB에서 읽기 전용 DB로 비동기 데이터 복제가 필요함)

 

성능 최적화 패턴

데이터 사용에서 성능을 향상시킬 수 있는 기본적인 방법은 색인을 만드는 것입니다.
그러나 과도한 색인 사용은 읽기/쓰기 성능을 저하할 수 있습니다.

색인 외의 클라우드 네이티브 환경에서 사용할 수 있는 패턴을 살펴봅니다.

구체화된 뷰 패턴

• 데이터를 처리하는 곳 가까운 곳에 미리 저장해 둠
• 서비스와 관련된 데이터를 로컬 데이터 스토어에 최적화된 형태로 저장
• 가져와야 하는 데이터 양이 아주 크거나 원천 데이터가 자주 변경될 때는 사용 X

데이터 지역성 패턴

• 데이터 처리 로직을 최대한 데이터와 가까운 곳에서 실행하여 소비하는 대역폭을 줄일 수 있음
• 데이터 노드에서 추가 코드를 실행해야 하므로 부하만 가중할 수 있음

캐싱 패턴

• 이전에 처리한 데이터를 저장하고 향후 유사한 질의에서 사용하는 방식
• 데이터 읽기 처리 시에 캐시에 있는 경우는 캐시 히트 / 캐시에 없으면 캐시 미스
• 메모리를 전부 소진한다면 새로운 데이터를 저장하기 위해 이전 캐시 데이터를 삭제하는 정책이 필요함
  • LRU (Least Recently Used)
  • FIFO (First-In, First-Out)
  • MRU (Most Recently Used)
• 각 캐시 데이터 별로 유효 시간을 지정할 수 있음 
  • 유효 시간이 길 때, 캐시에서 데이터를 오랫동안 가지고 있게 되면 캐시의 데이터와 데이터 스토어 간 불일치가 있을 수 있음
  • 유효 시간이 짧을 때, 캐시 히트 비율이 적어질 수 있음

 

---

4. 이벤트 주도 아키텍처 패턴 💁‍♂️📨🙆‍♂️

이벤트 주도 아키텍처 (EDA)는 기본적으로 비동기로 동작합니다.
클라우드 네이티브 애플리케이션은 서비스 간에 결합도를 낮추고, 확장성을 높이는 것이 중요하기 때문에 클라우드 네이티브 애플리케이션의 기본이 되는 구조입니다.

이벤트 전달 패턴

생산자-소비자 패턴

• 생산자 애플리케이션과 소비자 애플리케이션이 이벤트 큐를 통해 서로 비동기로 통신함
• 메시지 브로커는 메시지 큐를 관리하며, 통상적으로 이벤트들을 내구성 있는 스토어에 영구 저장함. 소비자가 이벤트를 다 처리하면 이벤트를 삭제
• 소비자는 자신이 처리할 수 있는 이벤트만 가져가기 때문에 과부하가 발생하지 않음
• 다만 이벤트가 몰리는 경우, 소비자 수를 늘리는 등의 처리 방법이 필요함

발행자-구독자 패턴

• 토픽을 통해 모든 이벤트를 모든 구독자에게 전달
• 기본적으로 Best Effort (이벤트가 최대 한 번 전달) 으로 동작. 네트워크 문제나 구독자가 문제가 생겨 이벤트가 전달되지 않으면 영원히 받을 수 없음
  • 이벤트를 놓쳐서는 안 되는 경우, 내구성 있는 구독을 통해 최소 한 번 전달됨을 보장하며 해결할 수 있음

파이어 앤 포겟 패턴

• 메시지 브로커 없이 클라이언트가 소비자에게 최대 한 번 이벤트를 전달
• 시간이 지나면서 그 가치가 떨어지는 이벤트를 처리하기 좋음 (Ex. 현재 날씨)

스토어 앤 포워드 패턴

• 메시지 브로커 없이 클라이언트가 소비자에게 최소 한 번 이벤트를 전달
• 클라이언트가 메시지를 보내기 전 DB와 같은 내구성 있는 스토어에 우선 저장 후 성공적으로 이벤트가 전달되면 이벤트를 지움, 실패한다면 재시도를 진행
• 메시지 브로커를 사용할 수 없는데, 최소 한 번 전달 보장이 필요할 때 사용함

폴링 패턴

• 클라이언트가 작업 요청 후 작업 완료 여부를 주기적으로 확인
• 웹 브라우저와 같은 클라이언트가 긴 시간 소요되는 작업을 시작하고 주기적으로 끝났는지 확인하도록 구현
• 작업 완료 여부를 확인하기 위해 서비스를 계속 호출하는 것은 자원을 낭비하는 것이며, 웹훅 또는 웹소켓 등을 사용하는 것이 훨씬 효과적임

요청 콜백 패턴

• 서비스 요청 시 콜백 정보를 함께 제공해서 해당 콜백을 통해 비동기로 응답을 전달하도록 함
• 웹소켓: 클라이언트가 서비스 측으로 연결을 만들어 긴 시간 유지하며 이벤트를 주고받아 통신 (하나 이상의 메시지를 주고받을 때 사용하는 것이 좋음)
• 웹훅: 클라이언트가 요청과 콜백 URL을 보내고, 서비스는 콜백 URL로 응답을 보냄 (딱 하나의 메시지 또는 응답을 언제 줄 수 있을지 모를 때 사용하는 것이 좋음)

 

오케스트레이션 패턴

더 많은 마이크로서비스를 사용할 수록 이벤트를 관리하기 어려워집니다.
이벤트 흐름을 효율적으로 만들고 애플리케이션 복잡도를 관리하는 방법을 알아봅니다.

중재자 패턴

• 중재자 마이크로서비스가 협력 로직을 실행 및 상호작용하며 이벤트를 조율하고 변경함
• 이벤트를 토픽별로 분류하거나, 여러 하위 이벤트로 분할 및 순차 병렬 처리를 할 수 있음
• 시스템이 빠르게 변경될 때 중재자 마이크로서비스만 변경하기 때문에 이점이 있으나, 중재자 로직이 너무 복잡해져 관리가 어려워질 수 있음

파이프 앤 필터 패턴

• 분산 방식으로 이벤트를 조율함
• 마이크로서비스들이 토픽과 큐와 가은 비동기 프로토콜로 연결되기 때문에 서비스 간 결합도가 낮음
• 여러 팀이 관리하는 대규모 비동기 시스템 구현에 이점이 있음

우선순위 큐 패턴

• 이벤트를 우선순위별로 다루어서 가장 중요한 이벤트를 먼저 처리
• 모든 이벤트를 처리할 수 있을 만큼 자원이 충분하지 않은 시스템에서 몇몇 이벤트를 먼저 처리해야할 때 사용

 

---

5. 스트림 프로세싱 패턴

이벤트 주도 아키텍처에서 발전한 형태로써, 이벤트를 그때그때 분석해서 의미 있는 정보를 추출하고 실시간으로 작업을 처리하는 데에 중점을 둡니다.
성능을 높이기 위해서는 영구 데이터 스토어를 많이 사용하지 않아야 합니다. 데이터 스토어에 접근하기 위해 소요 시간/지연 시간이 발생할 수 있기 때문입니다.

스트리밍 데이터 프로세싱 패턴

실시간 이벤트들을 변환, 필터링, 집계 등을 통해서 의미있는 데이터를 도출하는 데에 중점을 둡니다.

변환 패턴

• 이벤트 소스의 이벤트를 변환해서 다른 포맷이나 구조, 프로토콜을 사용하는 다른 시스템에 발행
• 팀들끼리 다른 메시지 브로커를 사용하고 있다면 이 패턴을 통해 구조 변경 후 전달 필요

필터와 한계값 패턴

• 이벤트를 특정 조건으로 걸러내거나, 한계값 이내의 값만 사용
• 모든 이벤트를 처리하는 것이 불가능하기 때문에, 중요한 데이터를 걸러내서 처리하는 데에 사용

윈도우드 애그리게이션 패턴

• 조건에 따른 이벤트 집합을 분석 (총합, 최솟값, 최댓값, 평균값, 표준 편차, 개수 등)
• 이 패턴은 상태를 가지기 때문에, 시스템 장애 또는 재시작으로 인해 유실이 발생하면 분석 결과에 대한 무결성을 보장할 수 없음
  • 분석 결과가 아주 중요하다면 신뢰할 수 있는 패턴을 함께 사용해서 복구할 수 있어야 함

스트림 조인 패턴

• 서로 다른 스키마를 가지는 여러 스트림의 이벤트를 합칠 때 사용
• 다른 이벤트 스트림으로부터 관련 이벤트가 도착할 때까지 얼마나 많은 이벤트를 기다려야 할지 결정하는 버퍼를 정의함 (버퍼에 합칠 이벤트를 저장하고 있기 때문에 상태를 가짐)
• 시스템 장애 또는 재시작으로 인해 유실이 발생하면 분석 결과에 대한 무결성을 보장할 수 없음
• 아주 긴 시간 동안 여러 이벤트를 합치는 것은 저장 공간과 처리 시간 비용이 커지기 때문에 지양

임시적인 이벤트 정렬 패턴

• 이벤트가 도착하는 순서를 토대로 패턴을 분석하고 이벤트가 발생했는지 여부를 탐지
  • 주가 정보 이벤트에서 주가가 계속 상승하다가 한 번 하락하는 경우 이를 바로 확인할 수 있음 
• 상태를 가지며, 이벤트 도착 순서가 중요함
• 시스템 장애 또는 재시작으로 인해 유실이 발생하면 분석 결과에 대한 무결성을 보장할 수 없음
• 기대하던 이벤트가 발생하지 않는 경우도 탐지할 수 있음

 

확장성 및 성능 최적화 패턴

순차 수송 패턴

• 이벤트를 다양한 분류로 나누고 병렬 처리하는 방식
• 이벤트를 분산하기 때문에 이벤트를 더 낮은 지연 속도(Latency) 과 높은 처리량(Throughput)을 처리할 수 있음
  • 스트림 처리 마이크로서비스가 병목 지점이 된다면, 스트림 수를 확장할 수 있도록 설계
• 각 이벤트는 분리하기 전 순번을 매기며 나중에 처리한 이벤트 스트림을 합칠 때 다시 순서대로 정렬함

버퍼 이벤트 순차 정렬 패턴

• 이벤트를 사용하기 전에 순서대로 정렬 (이벤트는 네트워크 지연이나 재시도 등으로 순서에 맞지 않게 도착할 수 있음)
• 시간에 따른 이벤트 집계, 이벤트 순번을 탐지해야 할 필요가 있을 때만 사용

오류 수정 패턴

• 이벤트 분석 결과를 최대한 빠르게 처리하고, 나중에 빠진 이벤트를 발견하면 이를 토대로 결과를 변경하고 다시 알려줌
• 정확도가 떨어지지만 낮은 지연 속도로 빠르게 결과를 알려주는 패턴

워터마크 패턴

• 워터마크 생성기가 주기적으로 워터마크 이벤트를 생성해서 스트림으로 보냄
• 순번이 동기화에서 벗어난 것을 발견하면 이벤트 처리를 중단하고, 낮은 순번의 이벤트를 기다림

 

---

6. API 관리 및 사용 패턴 👷‍♂️

마이크로서비스 형태로 각각 개발된 API들은 외부 혹은 내부에 통합되어 제공될 필요가 있습니다.
이는 API 사용을 촉진할 뿐만 아니라, 보안, 스로틀링, 버전 관리 등의 기능을 합니다.

API 게이트웨어 패턴

• 비즈니스 기능을 전면에 별도의 계층을 두어서 사용자에게 서비스를 제공
• API 사용자는 직접 API 게이트웨이와 연결되며, API 게이트웨이는 API 호출별 쿼터나 속도 제한, 캐싱, 버전 관리와 같은 정책을 적용
• API 개발자 포털에서 개발자들은 API를 소개 받으며, API 프로덕트를 구독하고 평점/의견을 남길 수 있음

API 마이크로게이트웨이 패턴

• API 게이트웨이를 분산해서 API 게이트웨이의 각 API를 독립적인 실행 환경으로 배포
  • API 게이트웨이 패턴은 API 수가 증가함에 따라 모놀로식 애플리케이션이 보여주는 단점을 그대로 보여주게되며, 클라우드 네이티브 애플리케이션의 핵심적인 정책과 상충되게 됨
• 마이크로게이트웨이는 가벼운 게이트웨이 런타임을 통한 컨테이너로 배포되며, 특정 API에 요청이 몰리면 독립적으로 확장 가능

서비스 메시 사이드카 게이트웨이 패턴

• API 게이트웨이 기능을 사이드카 프록시로 옮겨서 마이크로서비스와 함께 실행
• 이미 서비스 메시를 사용해서 마이크로서비스를 실행 중일 때 API 관리 기능을 추가하여 패턴을 사용하는 것이 권장됨

 

 

---

마치며: "어떻게(How) 만들 것인가?"에 대한 답

이 책을 읽기 전까지만 해도 클라우드 네이티브라는 개념은 제게 다소 모호했습니다.
이 책을 읽으며 바쁘다는 핑계로 당장의 기능 구현에만 매몰되어, 정작 중요한 설계의 본질을 놓치고 있었던 것은 아닌지 스스로를 되돌아보는 계기가 되었습니다.

물론, 현재 개발한 플랫폼은 문제없이 잘 동작하며 여러 사이트에 서비스되고 있습니다. 오히려 이러한 패턴들에 매몰되어 과하게 적용하면 관리 포인트가 걷잡을 수 없을 정도로 커질 수 있습니다.
하지만 패턴을 '알고 선택하지 않는 것'과 '몰라서 못 하는 것'은 하늘과 땅 차이일 것입니다.
결국 클라우드 네이티브는 단순히 특정 기술 스택을 도입하는 문제가 아니라, 주어진 환경에 최적화된 시스템을 고민하는 '설계의 문화'에 가깝습니다.

AI가 산업의 중심이 된 지금, 이를 뒷받침할 인프라를 클라우드 네이티브하게 구축하는 역량은 선택이 아닌 필수입니다.
그런 의미에서 이 책은 단순한 기술서를 넘어, 미래의 인프라를 고민하는 모든 엔지니어에게 충분한 가치를 제공할 것입니다.

 

 

감사합니다.