Microservice Architecture
Microservice Architecture
마이크로서비스는 하나의 큰 애플리케이션을 작고 독립적인 서비스들로 분해하여, 각 서비스가 하나의 비즈니스 기능에 집중하고, 독립적으로 개발, 배포, 확장 가능한 아키텍처 스타일이다.
핵심 개념
| 요소 | 설명 |
|---|---|
| 작은 단위의 서비스 | 각각의 서비스는 하나의 명확한 목적(예: 주문, 결제 등)을 가짐 |
| 독립 배포 가능성 | 다른 서비스에 영향 없이 혼자서 개발/배포/운영 가능 |
| 자기 책임의 데이터 관리 | 공유 DB 없이, 각 서비스가 자신만의 데이터 저장소 가짐 |
| 경량 통신 | 서비스 간 통신은 보통 HTTP REST, gRPC, Kafka 등 경량 프로토콜 사용 |
| 도메인 중심 설계 (DDD) | 비즈니스 도메인 별로 서비스가 나뉨 (Bounded Context) |
| 기술 스택 독립 | 서비스마다 언어나 프레임워크를 자유롭게 선택 가능 (Polyglot) |
MSA 장단점
MSA의 장점은 1) 우선 빠른 배포가 가능하다는 점이다. 여기서 빠른 배포라는 건 코드 충돌없이 서비스 단위로 배포가 가능하다는 의미이다. 작은 변경사항에도 릴리즈를 생성하고, 기획 및 운영팀의 협의를 하고, QA를 진행하고, … 등 배포과정이 길다면, 더욱 효과적이다. 2) 독립 확장이 가능하다는 점도 장점이다. 예를 들어, 주문 서비스만 트래픽이 많아져서 10배 확장한다던지 하는 확장성이 유연하다. 3) 장애 격리 부분에서도 비교적 유리하다. 하나의 서비스 장애가 전체 시스템에 영향을 주지않는다. 이를 위해서 서킷 브레이커 패턴 같은 방식을 사용한다. 4) MSA에서는 자율적인 팀 운영도 가능하다. 팀 단위로 독립 개발/운영이 가능하므로 DevOps 구조에 적합하다. 5) 마지막으로 유지보수에 용이하다. 서비스가 작고 분리되어 있어 변경 영향을 최소화 할 수 있다. 이는 코드 레벨에서의 DDD나 OOP에서의 목적과 일맥상통한다.
MSA의 단점도 명확한데, 복잡하고 어렵다는 것이다. 우선 1) 복잡한 인프라이다. CI/CD, 서비스 디스커버리, 로깅, 모니터링 등 복잡도가 증가할 수 밖에 없다. 2) 데이터 일관성 문제도 있다. 분산 DB 간 트랜잭션은 불가능하다. 따라서 이벤트 기반 eventual consistency를 설계하는게 필요하며, 문제 시 트랜잭션 복구를 위해 보상 트랜잭션(Compensating transaction) 같은 방안도 마련해야한다. 3) 통합 테스트가 어렵다는 점도 단점이다. 여러 서비스를 연계해서 테스트해야 하는데, 모든 서비스를 띄워서 확인하는 것은 쉽지않다. 4) 마지막으로, 운영 비용 증가도 단점이 될 수 있다. 서비스 수 증가로 인해 컨테이너, 배포 파이프라인, 모니터링 비용이 증가하며, DevOps 엔지니어도 별도로 존재한다면 비용은 더 증가한다.
Monolithic Architecture vs Microservice Architecture
모놀리식 아키텍처(Monolithic Architecture)와 마이크로서비스 아키텍처(MSA)는 시스템을 구성하는 기반 철학이 다르며, 설계, 개발, 배포, 운영 방식에서 뚜렷한 차이가 있다.
1
2
3
4
5
6
7
8
9
10
[ 사용자 요청 ]
↓
+--------------------------+
| Monolithic Application |
|--------------------------|
| Controller |
| Service Layer |
| Repository Layer |
| 모든 기능 하나에 통합 |
+--------------------------+
우선, 모놀리식 아키텍처에서 핵심 철학은 “단일 시스템으로 통합하고 관리하면 더 단순하고 안정적이다.”라는 것이다. “복잡도를 통제하기 위해 통합된 구조와 중앙 제어가 낫다”라는 것인데, 초기에 개발하고 설정하기에는 MSA보다는 비교적 간단하다. 이는 하나의 애플리케이션 안에 모든 기능을 통합하는 구조이다.
1
2
3
4
5
6
7
8
9
[ 사용자 요청 ]
↓
+--------------------+
| API Gateway |
+--------------------+
↓ ↓ ↓
[User] [Order] [Payment]
Service Service Service
(각각 독립 배포 + 운영)
반면, 마이크로서비스 아키텍처의 핵심 철학은 다음과 같다. “복잡한 시스템은 느슨하게 결합된 자율적인 구성요소로 분산하여 다뤄야 유연하게 변화에 대응할 수 있다.” 여기서 ‘느슨하게 결합된’, ‘자율적인’이라는 단어가 반복적으로 등장하는데, 이는 실제 배포/실패/확장과도 직결된다. 자율적이고 독립적인 서비스들이 개별적인 프로세스를 가지면서 자연스레 조직의 구조도 영향을 받는다. 즉, 콘웨이의 법칙에 따라 개발조직과 시스템 구조를 정렬하여 팀의 책임을 일치시킨다.
주요 비교 항목
| 항목 | 모놀리식 | MSA |
|---|---|---|
| 코드베이스 | 하나의 프로젝트 | 여러 독립 서비스 |
| 배포 단위 | 전체 앱 한 번에 | 개별 서비스 단위 |
| 확장성 | 전체 시스템 단위로만 확장 | 필요한 서비스만 확장 (예: Order만 10배 확장) |
| 장애 영향 범위 | 전체 앱 장애 가능 | 개별 서비스 장애로 격리 가능 |
| 의존성 관리 | 하나의 의존성 트리 | 서비스별 별도 의존성 관리 |
| 데이터베이스 | 공유 DB 사용 | 각 서비스마다 독립 DB 권장 |
| 개발 팀 구조 | 기능별 수직 분할 (예: Front팀, Back팀) | 도메인별 수평 분할 (예: 주문팀, 결제팀) |
| 배포 속도 | 변경 시 전체 빌드/배포 | 변경된 서비스만 배포 가능 |
| 시작 난이도 | 빠르게 시작 가능 | 인프라 구성 복잡 (Gateway, Discovery 등 필요) |
모놀리식 장단점
| 장점 | 단점 |
|---|---|
| 구조 단순 → 빠른 초기 개발 | 하나만 바꿔도 전체 재배포 필요 |
| 테스트, 디버깅이 쉬움 | 팀 간 충돌 잦음 (공통 코드 침범) |
| 로컬 개발 환경 구성 쉬움 | 확장성과 장애 분리 어려움 |
MSA 장단점
| 장점 | 단점 |
|---|---|
| 서비스별 독립 배포/확장 가능 | 인프라 복잡 (CI/CD, 트레이싱 등) |
| 장애 격리, 자율적 팀 운영 | 분산 트랜잭션 및 데이터 일관성 문제 |
| 기술 스택 다양성 허용 | 운영, 모니터링, 디버깅 난이도 ↑ |
Microservice Architecture vs Service-Oriented Architecture
MSA (Microservices Architecture)와 SOA (Service-Oriented Architecture)는 모두 서비스 단위로 시스템을 구성한다는 점에서 유사하지만, 설계 철학, 범위, 기술 스택, 조직 구조 측면에서 본질적인 차이가 있다.
1
2
3
4
5
6
7
8
9
10
+---------+
| Client |
+---------+
↓
+-------------+
| ESB (허브) |
+-------------+
↓ ↓ ↓
[User] [Order] [Inventory]
MSA
1
2
3
4
5
6
7
+---------+ +---------+ +---------+
| User | | Order | | Product |
+---------+ +---------+ +---------+
↓ ↓ ↓
REST/gRPC Kafka/Event REST/gRPC
↓ ↓ ↓
독립 배포 독립 저장소 독립 배포
MSA는 전체 서비스를 중앙 집중식으로 관리하는(오케스트레이션) 방식이 아니라는 점에서 SOA와 확실히 구별된다. 또 큰 차이점 하나는 범위의 차이이다. SOA는 조직의 모든 서비스가 통신/통합하는 방식을 표준화하기 위한 반면, 마이크로서비스 아키텍처는 애플리케이션별로 다르다.
실생활에서의 예시에 비유해보면 다음과 같다. 도시를 설계한다고 하면 SOA는 중앙 교통 터미널에서 연결되는 버스 시스템에 비유할 수 있다. 반면, MSA는 모든 구역에 자율주행 차량이 직접 이동하는 시스템이다. 배달 시스템에서 SOA는 모든 주문이 본사 콜센터를 거친다면, MSA는 각 지점에서 바로 고객에게 전달된다. 현재 B사의 배달플랫폼이 가게에 직접 전화를 못하도록 되어있는데, 이는 MSA에서 SOA로 변경된 사례라고 볼 수 있다. 오케스트라에서 지휘자가 전체 음악을 통제하는 것은 SOA의 전형적인 예이다. 여기서 각 연주자가 악보만 보고 독립적으로 연주하면 MSA이다.
핵심 차이 요약
| 항목 | SOA (서비스 지향 아키텍처) | MSA (마이크로서비스 아키텍처) |
|---|---|---|
| 철학적 범위 | Enterprise-level 통합 (이기종 시스템 연계 중심) | Application-level 설계 (하나의 앱을 작게 쪼갠 구조) |
| 서비스 크기 | 크고 복잡한 서비스 (Coarse-grained) | 작고 단일 책임 서비스 (Fine-grained) |
| 통신 방식 | SOAP, ESB (Enterprise Service Bus) 기반 | REST, gRPC, 메시지 큐 (Kafka, RabbitMQ) 등 경량 프로토콜 |
| 서비스 조정 방식 | 중앙 오케스트레이션 (BPM, ESB에서 플로우 제어) | 분산 코레오그래피 (이벤트 기반 반응형 설계) |
| 데이터 저장소 | 중앙 DB 또는 공유 DB 사용 | 각 서비스가 DB를 독립적으로 소유 |
| 기술 스택 | XML, SOAP, WSDL, BPM, JMS 등 | REST/JSON, Kafka, Docker, Kubernetes, CI/CD 등 |
| 운영 및 배포 | 수동 운영 중심, WAS 기반 | 클라우드 네이티브, 컨테이너 기반, 자동화된 배포 |
| 목표 | 기업 시스템 통합 (Legacy 연계 포함) | 빠른 변화 대응, 배포 독립성, 도메인 기반 개발 |
| 조직 구조 연계 | 전통적 IT 부서 중심 | DevOps / 팀 단위의 독립된 서비스 개발·운영 |
활용방안
SOA는 더 오래된 방식이고 더 이상 사용되지 않는 방식일까? 그것은 아니다. 대규모 조직 간 통합에는 아직도 유효하며, 특히 보험사나 정부기관처럼 엄격하게 중앙 집중식 통제와 일관성이 중요한 조직에서 선호된다. MSA가 무조건 좋은 방식일까? 그렇지도 않다. B2C의 서비스도 아닌 백오피스에서 MSA 구조를 도입하는 것은 때로는 오버엔지니어링이 될 수 있다. MSA는 변화에 빠르게 대응하거나 독립적 배포가 중요할 때 적합하다.
좀 더 구체적인 상황에서의 예시를 살펴보자. SAP, Oracle 등 다양한 시스템을 연동해야 하는 상황이라면 SOA를 적용하는게 더 나은선택이 될 수 있다. SOA는 대규모 이기종 시스템 환경에서 호환성을 위해 표준 기반 통신을 강제할 수 있으므로 상대적으로 유리하다. 반면, Netflix, 쿠팡 같은 빠르게 진화하는 SaaS 개발에서는 MSA가 유리하다. 초기 제품(MVP)을 빠르게 만들어야할 때, 모놀리스 아키텍처로 빠르게 개발하는 것이 가장 유리할 수 있다. 특히 스타트업에서는 CI/CD 등 운영 인프라 구성이 어렵고, 개발 인력과 조직 규모도 작기 때문이다.