핵심 인사이트 (3줄 요약)
- 본질: 마이크로서비스 아키텍처 (MSA)는 거대한 모놀리식 (Monolithic) 시스템을 작고 독립적인 서비스 단위로 분해하여 비즈니스 민첩성을 극대화하는 분산 아키텍처이며, 서버리스 (Serverless)는 인프라 관리 부담을 제거하여 이벤트 기반의 고가용성 연산을 실현하는 클라우드 네이티브의 정점이다.
- 가치: 개별 서비스의 독립적 배포와 확장을 통해 시장 변화에 즉각 대응하고, 서버리스를 통해 실제 사용한 자원에 대해서만 비용을 지불함으로써 인프라 효율성과 경제성을 극대화한다.
- 융합: 서비스 메시 (Service Mesh)를 통한 통신 제어, API 게이트웨이를 통한 통합 진입점 관리, 그리고 분산 트랜잭션 (SAGA 패턴) 처리가 결합되어 복잡한 엔터프라이즈 시스템의 현대화를 이끈다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
모놀리식의 한계와 클라우드 네이티브로의 이행
과거의 모놀리식 (Monolithic) 아키텍처는 모든 기능이 하나의 코드 베이스와 프로세스 내에 존재했다. 이는 초기 개발은 빠르지만, 시스템이 커질수록 코드의 복잡성이 기하급수적으로 증가하고 작은 변경 하나에도 전체 시스템을 다시 배포해야 하는 치명적 약점을 가진다. 특히 특정 기능에만 트래픽이 몰려도 전체 시스템을 복제해야 하는 비효율성이 발생한다.
마이크로서비스 아키텍처 (Microservices Architecture, MSA)는 이러한 문제를 해결하기 위해 등장했다. 비즈니스 기능을 중심으로 서비스를 분해하고, 각 서비스가 독자적인 데이터베이스를 가지며 API를 통해 통신하게 함으로써 유연성과 확장성을 확보한다. 여기에 더해 서버리스 (Serverless)는 개발자가 서버를 관리할 필요 없이 코드만 업로드하면 클라우드가 자동으로 실행 환경을 구성하고 스케일링을 관리하는 모델로, 클라우드의 추상화 수준을 극대화한다.
이 그림은 모놀리식과 마이크로서비스의 구조적 차이를 보여준다. 하나의 거대한 덩어리에서 작고 독립적인 서비스들의 집합으로 진화하는 과정을 시각화한다.
┌─────────────────────────────────────────────────────────────┐
│ 모놀리식 vs 마이크로서비스 (Monolithic vs Microservices) │
├─────────────────────────────────────────────────────────────┤
│ │
│ [ 모놀리식 ] [ 마이크로서비스 ] │
│ ┌────────────┐ ┌──────────┐ ┌──────────┐ │
│ │ UI 계층 │ │ UI / API │ │ UI / API │ │
│ ├────────────┤ ├──────────┤ ├──────────┤ │
│ │ 비즈니스 │ │ 서비스 A │ │ 서비스 B │ │
│ │ 로직 │ ├──────────┤ ├──────────┤ │
│ ├────────────┤ │ DB (A) │ │ DB (B) │ │
│ │ 데이터 접근│ └──────────┘ └──────────┘ │
│ └─────┬──────┘ ▲ ▲ │
│ │ │ │ │
│ ┌─────▼──────┐ ┌─────┴─────────────┴─────┐ │
│ │ 공유 DB │ │ API 게이트웨이 / 메시 │ │
│ └────────────┘ └─────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
이 다이어그램의 핵심은 '데이터베이스의 분리'이다. MSA의 가장 큰 특징은 서비스마다 전용 DB를 가진다는 점이며, 이를 통해 데이터 간의 강한 결합을 끊어내고 각 서비스의 기술 스택을 자유롭게 선택할 수 있게 된다. 실무에서 이를 관리하기 위해 API Gateway가 모든 요청의 단일 진입점 역할을 수행하며, 인증/인가, 라우팅, 부하 분산 등을 통합 처리한다.
서버리스 (Serverless): 운영 오버헤드의 제거
서버리스는 FaaS (Function as a Service)와 BaaS (Backend as a Service)를 포함하는 개념이다. 개발자는 비즈니스 로직(함수)만 작성하고, 하부 인프라의 프로비저닝, 패치, 스케일링은 클라우드 제공자가 담당한다. 이는 '이벤트 기반 (Event-driven)'으로 동작하여, 요청이 있을 때만 자원을 점유하고 요청이 끝나면 즉시 반납하는 극도의 효율성을 제공한다.
📢 섹션 요약 비유: 모놀리식이 모든 반찬이 한 그릇에 담긴 비빔밥이라면, MSA는 각 반찬이 별도의 그릇에 담긴 정식 차림과 같고, 서버리스는 내가 직접 요리할 필요 없이 주문하면 즉시 배달되는 배달 음식과 같습니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
MSA의 핵심 구성 요소 및 데이터 일관성
MSA는 단순히 서비스를 나누는 것 이상의 복잡한 관리 기술을 요구한다. 서비스가 수십 개로 늘어나면 '누가 누구와 대화하는지', '장애가 어디서 발생했는지' 파악하기 어려워지기 때문이다.
- Service Discovery: 동적으로 변하는 서비스 인스턴스의 위치(IP/Port)를 자동으로 찾아주는 기술 (Netflix Eureka 등).
- Circuit Breaker: 특정 서비스 장애 시 호출을 즉시 차단하여 전체 시스템으로의 장애 전파를 방지하는 차단기 (Hystrix, Resilience4j).
- API Gateway: 클라이언트 요청의 단일 진입점이자 라우팅, 인증 필터링을 담당.
- SAGA Pattern: 서비스별 DB 분리로 인한 분산 트랜잭션 문제를 해결하기 위해, 각 단계의 성공/실패에 따라 보상 트랜잭션 (Compensating Transaction)을 실행하는 패턴.
이 구조도는 MSA의 운영 환경을 지탱하는 클라우드 네이티브 에코시스템을 보여준다.
┌──────────────────────────────────────────────────────────────────┐
│ MSA 클라우드 네이티브 에코시스템 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ [Client] ──▶ [API Gateway] ──▶ [Service Mesh / Istio] │
│ │ │ │
│ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ │
│ │ Service A │◀────▶│ Service B │ │
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
│ [Config Server] [Service Discovery] │
│ │ │ │
│ [Distributed Tracing (Zipkin/Jaeger)] │
│ │
└──────────────────────────────────────────────────────────────────┘
이 다이어그램의 핵심은 '관측 가능성 (Observability)'이다. 분산된 서비스들 사이의 요청 흐름을 추적하기 위해 Distributed Tracing이 필수적이며, 서비스 간 통신을 미세하게 제어하기 위해 Service Mesh가 데이터 평면 (Sidecar)과 제어 평면으로 나누어 관리된다. 실무에서 MSA 도입 시 이러한 인프라 구축 비용이 비즈니스 로직 개발 비용보다 커질 수 있음을 경계해야 한다.
서버리스 아키텍처: 이벤트 기반 연산
서버리스의 핵심은 'Stateless (무상태성)'이다. 함수는 실행될 때만 생성되고 종료되면 사라지기 때문에 상태를 내부에 저장할 수 없다. 대신 외부의 DB나 스토리지 (S3, DynamoDB)를 활용한다.
이 도식은 서버리스 함수가 트리거(Trigger)에 의해 깨어나고 실행되는 과정을 시각화한다.
┌─────────────────────────────────────────────────────────────┐
│ Serverless (FaaS) 동작 시퀀스 │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Event Trigger] ──▶ [Cold Start / Warm Start] ──▶ [Execution]│
│ (HTTP, S3, SQS) │ │ │
│ ▼ ▼ │
│ [Init Environment] [Logic Run] │
│ │ │ │
│ [Download Code] [External DB] │
│ │
└─────────────────────────────────────────────────────────────┘
이 시퀀스에서 가장 중요한 기술적 쟁점은 콜드 스타트 (Cold Start) 지연 시간이다. 함수가 오랫동안 사용되지 않아 메모리에서 내려간 경우, 다시 실행할 때 컨테이너를 띄우고 코드를 로드하는 데 시간이 걸린다. 실무에서는 이를 해결하기 위해 프로비저닝된 동시성 (Provisioned Concurrency)을 사용하거나 함수를 가볍게 유지하는 전략을 사용한다.
📢 섹션 요약 비유: MSA 관리는 수많은 악기가 제 소리를 내도록 조율하는 지휘자와 같고, 서버리스는 손님이 올 때만 불을 켜고 요리를 하는 자동 로봇 주방과 같습니다.
Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)
MSA 분해 전략 및 트레이드오프
어떻게 서비스를 나눌 것인가에 대한 전략적 비교이다.
| 구분 | 비즈니스 능력 중심 (Business Capability) | 도메인 중심 (Domain Driven Design) |
|---|---|---|
| 기반 이론 | 조직의 부서/업무 기능 기준 | 도메인 모델 및 바운디드 컨텍스트 기준 |
| 장점 | 조직 구조와 일치하여 협업 용이 | 복잡한 비즈니스 로직의 명확한 경계 획정 |
| 단점 | 업무 변화 시 서비스 경계 모호 | 초기 설계 비용 및 모델링 난이도 높음 |
| 비유 | 부서별로 사무실 나누기 | 주제별로 책장 정리하기 |
서버리스 vs 컨테이너 (K8s) 비교 분석
클라우드 현대화의 두 가지 핵심 선택지이다.
| 비교 항목 | Serverless (FaaS) | Container (K8s) |
|---|---|---|
| 추상화 수준 | 극도로 높음 (코드만 관리) | 높음 (이미지 및 오케스트레이션 관리) |
| 제어권 | 낮음 (런타임 제약) | 매우 높음 (OS, 라이브러리 자유도) |
| 비용 모델 | 실행 시간/횟수 기반 (Pay-per-use) | 할당된 자원 기반 (Pay-per-allocation) |
| 상태 관리 | 무상태 (Stateless) 중심 | 상태 저장 (Stateful) 가능 |
| 적합한 워크로드 | 이벤트 처리, 배치, 가변 트래픽 | 복잡한 앱, 지속적 트래픽, 고성능 연산 |
📢 섹션 요약 비유: DDD는 성벽의 경계를 정확히 긋는 지도 제작과 같고, 서버리스와 컨테이너의 선택은 렌터카(컨테이너)를 직접 운전할지 아니면 택시(서버리스)를 탈지 결정하는 것과 같습니다.
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
MSA 전환 시나리오: 모놀리스에서 마이크로서비스로
시나리오: 거대 커머스 몰의 MSA 전환
- 판단: 한꺼번에 모든 기능을 나누는 '빅뱅' 방식은 위험하다. Strangler Fig Pattern을 사용하여, 신규 기능은 마이크로서비스로 만들고 기존 모놀리스의 기능은 하나씩 떼어내어 점진적으로 교체한다.
- 데이터 전략: DB 분리 시 발생하는 데이터 일관성 문제는 SAGA 패턴의 오케스트레이션 (Orchestration) 방식을 도입하여 중앙에서 트랜잭션을 제어한다.
이 도식은 Strangler Fig 패턴을 통한 점진적 전환 과정을 보여준다.
┌─────────────────────────────────────────────────────────────┐
│ Strangler Fig Pattern 전환 프로세스 │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Initial] [Transition] [Final] │
│ ┌─────────┐ ┌───────┐┌──────┐ ┌─────────┐ │
│ │ Monolith│ ──▶ │Proxy ││New MS│ ──▶ │New MS │ │
│ └─────────┘ └─┬─────┘└──────┘ └─────────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ Monolith│ │
│ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
이 패턴의 핵심은 '프록시 (Proxy)'나 '파사드 (Facade)'의 역할이다. 클라이언트는 시스템 내부가 변하는 것을 알 필요가 없으며, 프록시가 요청을 구형 시스템으로 보낼지 신규 마이크로서비스로 보낼지 결정한다. 기술사는 이 과정에서 데이터 동기화 지연과 네트워크 오버헤드를 최소화하는 '동기화 가드레일'을 설계해야 한다.
기술사적 제언: 마이크로서비스의 복잡성 관리
MSA는 만능이 아니다. 마틴 파울러가 주창한 **'MSA 프리미엄 (MSA Premium)'**을 고려해야 한다. 즉, 분산 시스템의 복잡성을 관리할 수 있는 역량과 인프라 자동화 체계가 갖춰지지 않은 상태에서의 MSA 도입은 오히려 생산성을 저하시킨다. 기술사는 비즈니스 복잡도가 임계치를 넘었을 때만 MSA 전환을 권고해야 한다.
📢 섹션 요약 비유: MSA 전환은 달리는 차의 엔진을 한 부품씩 새것으로 바꾸는 것과 같아, 정교한 계획과 멈추지 않는 프록시(안전장치)가 필수적입니다.
Ⅴ. 기대효과 및 결론 (Future & Standard)
정량적/정성적 기대효과 분석
| 기대효과 구분 | 세부 항목 | 효과 (ROI) |
|---|---|---|
| 정량적 효과 | 배포 주기 | 월 1회에서 일 수회로 배포 속도 향상 |
| 정량적 효과 | 인프라 비용 | 서버리스 도입 시 유휴 자원 비용 30~50% 절감 |
| 정성적 효과 | 장애 격리 | 특정 서비스 장애가 전체 시스템 셧다운으로 이어지지 않음 |
| 정성적 효과 | 기술 혁신 | 서비스별 최적의 언어와 프레임워크 도입 가능 (Polyglot) |
미래 전망: 플랫폼 엔지니어링과 서버리스 중심
향후 클라우드 아키텍처는 개발자가 인프라 걱정 없이 코드에만 집중할 수 있게 해주는 **플랫폼 엔지니어링 (Platform Engineering)**과 더 고도화된 서버리스 환경으로 진화할 것이다. 또한 에지 컴퓨팅 (Edge Computing)과 서버리스가 결합하여 사용자 가까이에서 초저지연 연산을 수행하는 구조가 확산될 것이다.
📢 섹션 요약 비유: 미래의 클라우드는 마치 공기처럼, 우리가 숨 쉬고(코드 실행) 있지만 그 존재(서버)는 의식하지 못하는 완전한 추상화의 단계로 나아갈 것입니다.
📌 관련 개념 맵 (Knowledge Graph)
- API Gateway: 클라이언트 요청을 통합 관리하는 MSA의 단일 진입점
- Service Mesh (Istio): 사이드카 패턴을 활용한 서비스 간 통신 제어 인프라 계층
- SAGA Pattern: 분산 DB 환경에서 데이터 일관성을 유지하기 위한 보상 트랜잭션 패턴
- Circuit Breaker: 장애 전파 방지를 위해 호출을 차단하는 안전 장치
- Cold Start: 서버리스 함수 최초 실행 시 발생하는 초기 로딩 지연
- Strangler Fig Pattern: 모놀리스를 점진적으로 마이크로서비스로 교체하는 전략
- DDD (Domain Driven Design): 도메인 전문가와 개발자의 협업을 통한 서비스 분해 설계 기법
👶 어린이를 위한 3줄 비유 설명
- MSA는 커다란 레고 성을 한 번에 다 만드는 게 아니라, 작은 레고 방들을 따로 만들어서 나중에 합체시키는 것과 같아요.
- 서버리스는 컴퓨터 전원을 내가 켜는 게 아니라, 내가 게임기를 잡는 순간 요정이 나타나서 순식간에 전기를 연결해주는 마법이에요.
- 이렇게 하면 한쪽 방이 무너져도 성 전체가 망가지지 않고, 필요한 만큼만 전기를 써서 돈도 아낄 수 있답니다.