마이크로서비스 환경에서 SAGA 패턴을 도입하는 순간, 자연스럽게 하나의 질문과 마주하게 된다.
"Orchestration으로 구현할 것인가, Choreography를 선택할 것인가?"
두 방식 모두 여러 서비스가 하나의 비즈니스 프로세스를 협력해 처리한다는 공통점을 갖지만, 흐름을 어떻게 제어하느냐와 운영 전략을 어떻게 가져가느냐에 따라 분명한 차이가 드러난다.
Orchestration vs Choreography 비교 분석
1. 트랜잭션 흐름 관리 방식
두 패턴의 가장 큰 차이는 트랜잭션의 흐름을 누가 통제하는가이다.
| 패턴 | 제어 방식 |
| Orchestration | 중앙 Orchestrator가 전체 흐름을 직접 제어한다. "다음 단계 실행"과 같은 명령(Command) 형태로 서비스에 지시한다. |
| Choreography | 각 서비스가 이벤트(Event)를 구독해 스스로 다음 단계를 수행한다. 트랜잭션은 이벤트의 연쇄 반응(E -> E -> E)으로 이어지며, 중앙 제어자는 존재하지 않는다. |
👉 Orchestration = 중앙 집중형, Choreography = 분산 · 자율형
2. 상태 추적 및 모니터링
| 패턴 | 상태 파악 방식 |
| Orchestration | Saga 상태가 Orchestrator 내부에 명확히 저장되므로 전체 흐름을 한눈에 파악 가능하다. |
| Choreography | 상태가 여러 서비스에 분산되며, 이벤트 로그를 모아야 전체 상태를 복원할 수 있다. 장애 분석 난이도가 높다. |
👉 운영 편의성과 상태 추적은 Orchestration이 월등히 유리
3. 서비스 간 결합도
| 패턴 | 결합도 |
| Orchestration | 각 서비스는 Orchestration의 명령을 따르므로 Orchestrator와의 결합이 존재한다. |
| Choreography | 서비스 간 직접 호출 없이 이벤트 기반으로 연결된다. 가장 느슨한 결합 구조를 제공한다. |
👉 확장성 · 변경 용이성은 Choreography가 뛰어남
4. 복잡성의 위치: 중앙 집중 vs 서비스 간 연결
두 방식 모두 복잡성이 존재하지만, 복잡성이 집중되는 지점이 다르다.
| 패턴 | 복잡성이 쌓이는 지점 |
| Orchestration | 모든 흐름과 로직이 Orchestration에 모이며, 중앙에 복잡성이 집중된다. |
| Choreography | 서비스 간 이벤트 의존 관계가 많아지면 이벤트 스파게티(Event Spaghetti) 형태로 복잡해질 수 있다. |
👉 Orchestration = 중앙 집중 복잡성, Choreography = 서비스 간 연결 복잡성
5. 관측성(Observability)
| 패턴 | 특징 |
| Orchestration | 중앙에서 전체 단계를 알고 있어 관측·디버깅이 쉽다. |
| Choreography | 이벤트 기반 분산 구조로 인해 전체 흐름 추적이 어렵다. 추가적인 모니터링 전략이 필요하다. |
6. 실패 및 보상 트랜잭션 처리
| 패턴 | 보상 처리 방식 |
| Orchestration | Orchestrator가 전체 순서를 알고 있어 정확한 역순 보상이 가능하다. 안정적이고 예측 가능하다. |
| Choreography | 각 서비스가 보상 이벤트를 구독해 스스로 수행한다. 유연하지만 추적 및 관리 난이도가 높다. |
👉 보상 로직의 명확성과 안전성은 Orchestration이 우세하다
7. 확장성과 변경 용이성
| 패턴 | 특성 |
| Orchestration | 새로운 단계 추가·변경이 용이하다. 오케스트레이터 로직만 수정하면 되지만, 중앙 집중 구조로 인해 병목(Bottleneck) 위험이 존재한다. |
| Choreography | 서비스 수가 많아질수록 자연스럽게 확장된다. 중앙 제어자가 없어 단일 장애점(SPOF)도 없다. 그러나 플로우 변경·디버깅 시 여러 서비스를 추적해야 하므로 난이도가 높다. |
언제 어떤 방식을 선택해야 하는가?
Orchestration이 적합한 경우
- 전체 비즈니스 흐름을 명확히 제어해야 하는 경우
- 복잡한 실패 시나리오와 보상 로직을 안정적으로 관리해야 하는 경우
- 상태 추적, 모니터링, 운영 안정성이 중요한 시스템
Choreography를 선택하면 좋은 경우
- 서비스 간 결합도를 최소화하고 확장성을 극대화하고 싶은 경우
- 서비스가 비교적 독립적이고 변경이 잦은 환경
- 일부 흐름은 이벤트 기반 비동기로 자연스럽게 흘러가는 경우
실무에서 자주 사용되는 SAGA 패턴의 응용 구조
SAGA 패턴은 기본적으로 Orchestration 또는 Choreography 중 하나를 선택해 트랜잭션을 구성하지만, 실제 운영 환경에서는 두 방식을 그대로 단일 형태로만 사용하지 않는 경우가 많다. 서비스 규모가 커지고 연관된 도메인들이 얽히기 시작하면, 자연스럽게 다양한 변형·혼용 형태가 등장한다.
1. Orchestration + Choreography 혼용 패턴
이 방식은 핵심 트랜잭션만 Orchestration이 담당하고, 그 이후의 부가적이지만 중요하지 않은 후처리 흐름은 Choreography로 처리하는 구조다.
왜 이런 구조가 필요한가?
핵심 트랜잭션은 일관성과 안정성이 중요하기 때문에 Orchestration이 적합하다.
반면 후처리 로직은 시스템 확장에 따라 계속 추가되기 때문에 Choreography 기반 이벤트 구독 방식이 훨씬 유연하다.
즉, "핵심은 중앙에서 통제하고, 부가는 자유롭게 확장한다"는 실무적인 균형점이다.
장점
- 핵심 트랜잭션의 신뢰성과 안정성 확보
- 후처리 기능을 자유롭게 추가(Subscriber 추가만 하면 됨)
- Orchestrator가 불필요한 책임을 떠안지 않음
2. Choreography + Saga Tracker 패턴
순수 Choreography는 모든 서비스가 이벤트를 기반으로 흘러가기 때문에 상태 추적이 어렵다는 단점이 있다.
이를 해결하고자 등장한 것이 Saga Tracker 기반 구조다.
핵심 아이디어
- SAGA의 실제 실행은 Choreography 방식으로 진행된다.
(Order_Created -> Inventory_Reserved -> Payment_Processed 순으로 자연스럽게 이벤트가 흐름) - 각 서비스는 자신의 상태를 이벤트로 발행하고, Saga Tracker가 이를 가로채 현재 SAGA의 상태를 중앙에서 기록한다.
Saga Tracker는 무엇을 하는가?
- SAGA의 현재 단계
- 성공/실패 여부
- 어떤 서비스까지 프로세스를 진행했는지
- 보상 트랜잭션이 필요한지 여부
이 모든 정보를 중앙에서 관측 가능하게 만들어준다.
장점
- 순수 Choreography의 장점(느슨한 결합, 유연성)을 그대로 유지
- Orchestration 수준의 상태 가시성 확보
- 장애 분석 및 모니터링이 매우 수월해짐
언제 유용한가?
- 자율성이 중요한 대규모 분산 시스템
- 이벤트 기반 설계를 이미 사용하고 있는 환경
- 주문-재고-결제 등 다수 도메인이 얽히는 복잡한 흐름
3. Bounded Context 내부 Orchestration + 서비스 간 Choreography
대규모 시스템에서는 단일 Orchestrator로 모든 비즈니스를 통제하는 것은 오히려 비효율적이다.
그래서 도메인(Bounded Context) 별로 자체 Orchestrator를 두고, 도메인 간 연결은 이벤트 기반 Choreography로 풀어내는 방식이 널리 쓰인다.
핵심 아이디어
- "주문 BC", "재고 BC", "결제 BC", "배송 BC" 등 각 도메인 내부는 Orchestration
- 도메인 간 협업은 이벤트 기반 Choreography
예를 들면,
- 주문 Bounded Context 내부 Orchestrator -> 주문 생성, 승인, 취소 로직 통제
- 재고 Bounded Context 내부 Orchestartor -> 재고 차감/환원 로직 통제
- 결제 Bounded Context 내부 Orchestartor -> 결제 승인, 포인트 사용 로직 통제
- 그리고 이들 BC 간에는 Order_Confirmed, Inventory_Allocated, Payment_Complted와 같은 이벤트로 연결된다.
왜 이러한 구조가 필요할까?
- 대규모 시스템은 도메인마다 처리해야 할 복잡성이 다르다.
- 한 Orchestrator가 모든 도메인을 통제하면 단일 장애점(SPOF)이 될 뿐 아니라, 유지보수도 매우 어렵다.
- 도메인 주도 설계(DDD)의 기본 원칙인 도메인 독립성과도 자연스럽게 맞아떨어진다.
장점
- 각 도메인은 고도로 일관된 비즈니스 상태 관리 가능
- 도메인 간 결합도를 낮추고 독립적으로 확장 가능
- 새로운 도메인 추가 시 전체 구조 수정 최소화
'아키텍처 & 설계(Architecture & Design) > MSA' 카테고리의 다른 글
| Orchestration 기반 SAGA 패턴 (0) | 2025.11.23 |
|---|---|
| Choreography 기반 SAGA 패턴 이해하기 — 분산 환경에서의 트랜잭션 처리 방식 (0) | 2025.11.17 |
| SAGA 패턴과 에서의 격리성(Isolation) 문제 (0) | 2025.11.10 |
| SAGA 패턴과 멱등성 – 분산 트랜잭션에서 꼭 짚고 넘어가야 할 관계 (0) | 2025.11.10 |
| 분산 트랜잭션의 한계와 SAGA 패턴 (0) | 2025.11.07 |
