여러 마이크로서비스가 하나의 업무(예: 주문 → 결제 → 재고 → 알림)를 함께 처리할 때, “이 흐름을 누가, 어떻게 이어 붙이느냐”는 두 갈래로 나뉜다. 오케스트레이션(orchestration)과 코레오그래피(choreography)다. 다음 편에서 다룰 분산 트랜잭션 이야기의 토대가 되는 개념이라, 먼저 이 둘부터 정리한다.

1. 한 장으로 보는 차이

2. 코레오그래피 (안무) — 중앙 없이 이벤트로 연쇄

지휘자가 없다. 각 서비스는 다른 서비스가 낸 이벤트를 듣고 자기 일을 한 뒤, 다음 이벤트를 낸다. Order가 OrderCreated를 내면 Payment가 그걸 듣고 결제한 뒤 PaymentSettled를 내고, Inventory가 다시 그걸 듣는 식이다. (EDA 편에서 본 pub/sub 구조 그대로.)

• 장점 — 서비스 간 결합이 느슨하다. 소비자를 새로 붙여도 기존 서비스는 그대로다.
• 단점 — 전체 흐름이 어디에도 한눈에 안 보인다. 로직이 여러 서비스에 흩어져, “지금 이 주문이 어디까지 갔지?”를 추적하기 어렵고 순환 의존이 생기기도 한다.

3. 오케스트레이션 (지휘자) — 중앙이 순서를 지시

오케스트레이터(orchestrator)라는 중앙 조율자가 흐름을 지휘한다. “Payment 호출 → 성공하면 Inventory 호출 → 실패하면 이렇게” 같은 순서와 분기를 한곳에서 관리하고, 각 서비스를 명령으로 부르고 결과를 취합한다.

• 장점 — 전체 흐름이 한곳에 모여 보이고, 바꾸기·모니터링하기 쉽다. 실패 처리·재시도·타임아웃을 중앙에서 일관되게 건다.
• 단점 — 오케스트레이터가 결합점이 된다. 이 지점의 설계·가용성이 전체를 좌우한다.

4. 언제 무엇을

둘은 배타적이지 않다. 큰 시스템은 대개 섞어 쓴다 — 느슨한 파급은 이벤트로, 순서가 중요한 핵심 업무는 오케스트레이터로. 다음 편에서 다룰 분산 트랜잭션이 바로 이 “순서가 중요한 핵심 업무”의 대표 사례다.

참고

• microservices.io — Saga pattern