핵심 인사이트 (3줄 요약)
- 본질: 오케스트레이션 사가 (Orchestration Saga)는 오케스트레이터가 분산 업무의 상태를 저장하고 다음 명령을 내려, 여러 마이크로서비스의 로컬 트랜잭션을 하나의 장기 비즈니스 흐름으로 묶는 중앙 제어형 Saga 패턴이다.
- 가치: 흐름 가시성, 감사 추적, 재시도·타임아웃·보상 통제가 쉬워져, 단계가 길고 규칙이 복잡한 업무에서 코레오그래피보다 운영성이 높다.
- 판단 포인트: 단순한 흐름에까지 무조건 적용하면 중앙 로직이 비대해지고 병목이 되기 쉽다. durable state, 멱등성 (Idempotency), 고가용성 없이 쓰면 장점보다 부담이 커진다.
Ⅰ. 개요 및 필요성
오케스트레이션 사가는 마이크로서비스 아키텍처 (MSA, Microservices Architecture)에서 주문, 결제, 재고, 배송처럼 여러 서비스에 걸친 업무를 하나의 비즈니스 트랜잭션처럼 관리하기 위한 패턴이다. 각 서비스는 자기 데이터베이스 안에서는 짧은 로컬 트랜잭션만 수행하고, 전체 순서는 오케스트레이터가 명령과 응답을 통해 통제한다. 즉 서비스가 서로를 직접 호출하며 흐름을 외우는 대신, 흐름의 기억을 중앙에 모아 두는 방식이다.
이 패턴이 필요한 이유는 전역 트랜잭션이나 순수 코레오그래피가 항상 현실적이지 않기 때문이다. 2PC (Two-Phase Commit)는 강한 일관성을 주지만 락 지속시간, 장애 전파, 운영 복잡도가 커서 대규모 MSA와 잘 맞지 않는다. 반대로 코레오그래피는 서비스 자율성은 높지만, 단계가 길어지고 분기·예외·승인 절차가 많아질수록 "지금 어디까지 왔는지"를 중앙에서 보기 어렵다. 감사, SLA (Service Level Agreement), 사람 승인, 장시간 대기 상태가 있는 업무일수록 오케스트레이션이 유리해진다.
중요한 점은 중앙 제어가 곧 물리적 단일 서버를 뜻하지는 않는다는 사실이다. 현대 구현은 대개 상태를 영속 저장소에 기록하고 오케스트레이터 인스턴스를 여러 대로 띄워 고가용성을 확보한다. 따라서 진짜 쟁점은 "한 대가 죽으면 끝난다"보다, 업무 흐름의 의사결정이 한곳에 집중되는 논리적 중앙화를 감수할 가치가 있는가다.
아래 그림은 주문 처리 흐름에서 오케스트레이터가 어떤 역할을 맡는지 보여 준다.
┌────────────────────────────────────────────────────────────────────┐
│ Orchestrated saga flow │
├────────────────────────────────────────────────────────────────────┤
│ Client request │
│ │ │
│ ▼ │
│ Saga Orchestrator │
│ ├─ Command: CreateOrder ──> Order Service ──> Reply │
│ ├─ Command: AuthorizePay ──> Payment Service ──> Reply │
│ ├─ Command: ReserveStock ──> Inventory Service ──> Reply │
│ └─ on failure ──> Compensate previous services │
│ │
│ State progression is remembered centrally │
└────────────────────────────────────────────────────────────────────┘
즉 오케스트레이션 사가의 본질은 "중앙이 다 해 준다"가 아니라, 각 서비스의 일은 분산돼 있어도 흐름의 판단과 기억은 중앙에서 관리한다는 데 있다.
- 📢 섹션 요약 비유: 여러 팀이 동시에 움직이는 결혼식 진행에서 사회자가 순서를 잡아 주는 것과 같다. 요리팀, 촬영팀, 축가팀은 각자 일을 하지만, 전체 순서를 머릿속에 담고 조율하는 사람은 따로 필요하다.
Ⅱ. 아키텍처 및 핵심 원리
오케스트레이션 사가의 핵심 구성은 워크플로 정의, 상태 저장소, 명령 채널, 응답 채널, 타임아웃·재시도 정책, 보상 로직이다. 오케스트레이터는 새 요청이 들어오면 사가 인스턴스를 만들고 현재 상태를 저장한다. 이후 각 단계마다 명령을 보내고 응답이나 이벤트를 기다린 뒤, 성공이면 다음 상태로 전이하고 실패나 시간 초과면 보상 경로로 전환한다.
| 구성 요소 | 역할 | 왜 중요한가 |
|---|---|---|
| 사가 정의 (Saga Definition) | 단계, 분기, 보상 순서를 상태 기계로 표현 | 흐름이 코드가 아닌 모델로 관리됨 |
| 상태 저장소 (Saga Store) | 현재 단계, 입력, 상관관계 ID 저장 | 재시작 후에도 복구 가능 |
| 명령 (Command) | 다음 서비스에 수행할 업무 지시 | 서비스 간 책임이 명확해짐 |
| 응답/이벤트 | 성공·실패·타임아웃 결과 전달 | 상태 전이 근거가 됨 |
| 보상 트랜잭션 | 이미 끝난 로컬 작업을 업무적으로 상쇄 | 전역 롤백 부재 보완 |
| 타임아웃·재시도 | 응답 지연, 일시 장애 대응 | 장기 실행 흐름의 안정성 확보 |
실행 흐름은 다음과 같다. 주문 생성 요청이 들어오면 오케스트레이터는 ORDER_CREATED_PENDING 같은 초기 상태를 저장하고 주문 서비스에 명령을 보낸다. 주문이 성공하면 상태를 PAYMENT_PENDING으로 바꾼 뒤 결제 서비스에 명령을 보낸다. 결제가 성공하면 재고 예약으로 넘어가고, 재고 부족이나 결제 실패가 발생하면 이미 성공한 앞 단계에 대해 취소·해제 명령을 내려 보상 트랜잭션을 수행한다.
┌────────────────────────────────────────────────────────────────────┐
│ Durable state machine │
├────────────────────────────────────────────────────────────────────┤
│ START │
│ ▼ │
│ OrderCreated? ----no----> FAIL │
│ │ yes │
│ ▼ │
│ PaymentAuthorized? --no--> CancelOrder -> FAIL │
│ │ yes │
│ ▼ │
│ StockReserved? ------no--> RefundPayment -> CancelOrder -> FAIL │
│ │ yes │
│ ▼ │
│ COMPLETE │
└────────────────────────────────────────────────────────────────────┘
여기서 중요한 것은 "오케스트레이터가 직접 비즈니스 데이터를 수정하는가"가 아니라, 상태 전이의 근거를 영속적으로 기록하는가다. 기록이 없다면 프로세스 재시작, 중복 메시지, 네트워크 장애 시 전체 흐름을 복원할 수 없다. 그래서 실무에서는 단순 HTTP (HyperText Transfer Protocol) 호출 체인보다 메시지 기반 명령·응답, 워크플로 엔진, 멱등 처리 키가 함께 쓰이는 경우가 많다.
또한 보상은 데이터베이스 ROLLBACK이 아니다. 이미 각 서비스는 자기 로컬 커밋을 끝냈기 때문에, 반대 의미의 새 업무를 실행해야 한다. 예를 들어 결제 승인 후 재고가 실패하면 "결제를 롤백"하는 것이 아니라 "환불" 혹은 "승인 취소"라는 별도 업무를 발생시켜야 한다. 이 업무 의미를 정확히 정의하지 못하면 오케스트레이션 사가는 겉보기만 깔끔한 제어기로 끝난다.
- 📢 섹션 요약 비유: 여행 일정표를 든 인솔자가 체크리스트를 보며 다음 장소로 이동시키는 것과 같다. 일정표를 잃어버리면 지금 어디까지 왔는지 아무도 기억하지 못하고, 취소가 나도 어떤 예약부터 되돌려야 할지 헷갈리게 된다.
Ⅲ. 비교 및 연결
오케스트레이션 사가를 제대로 이해하려면 코레오그래피 사가와 2PC를 함께 봐야 한다. 세 방식 모두 여러 서비스에 걸친 작업을 다루지만, 누가 흐름을 알고 있고 어떤 대가를 치르는지가 다르다.
| 방식 | 흐름 제어 주체 | 장점 | 약점 | 잘 맞는 업무 |
|---|---|---|---|---|
| 오케스트레이션 사가 | 중앙 오케스트레이터 | 추적·감사·분기 통제 용이 | 중앙 로직 비대화 위험 | 승인, 정산, 장기 워크플로 |
| 코레오그래피 사가 | 각 서비스의 이벤트 반응 | 느슨한 결합, 확장성 | 전체 흐름 가시성 약함 | 짧고 안정적인 이벤트 체인 |
| 2PC (Two-Phase Commit) | 트랜잭션 코디네이터 | 강한 일관성 | 락 지속, 장애 전파, 확장성 제약 | 제한된 수의 강결합 시스템 |
오케스트레이션은 중앙 제어 덕분에 "누가 다음 단계인지"가 명확하다. 그래서 규제 보고, 실패 원인 분석, 타임아웃 처리, 사람 승인 삽입이 쉽다. 대신 중앙에 업무 규칙이 계속 몰리면 오케스트레이터가 거대한 비즈니스 엔진이 되어 서비스 경계를 다시 흐릴 수 있다. 반면 코레오그래피는 서비스들이 이벤트만 보고 움직여 결합도는 낮지만, 흐름이 길어질수록 이벤트 소비 관계가 숨은 의존성으로 변하기 쉽다.
또 하나의 비교 포인트는 통신 스타일이다. 오케스트레이션 사가는 보통 명령 중심이고, 코레오그래피는 도메인 이벤트 중심이다. 명령은 "누가 무엇을 하라"를 명확히 지시하므로 정책 통제가 쉽고, 이벤트는 "무슨 일이 일어났다"를 알리므로 확장성이 좋다. 따라서 단순히 중앙이냐 분산이냐가 아니라, 업무를 지시형으로 모델링할지 반응형으로 모델링할지의 차이이기도 하다.
실무에서는 두 방식을 혼합하기도 한다. 핵심 결제 흐름은 오케스트레이터가 관리하고, 후행 알림이나 추천 학습 적재는 코레오그래피 이벤트로 흘려보내는 식이다. 즉 오케스트레이션 사가는 MSA에서 "모든 것을 중앙화하자"는 주장이 아니라, 복잡한 핵심 흐름만큼은 책임 있는 지휘체계가 필요하다는 선택으로 보는 편이 맞다.
- 📢 섹션 요약 비유: 작은 버스킹은 서로 눈치 보며 연주해도 되지만, 수십 명이 참가하는 오케스트라는 악보와 지휘가 있어야 엇박자가 줄어든다. 규모와 복잡도가 올라갈수록 중앙 지휘의 가치가 커진다.
Ⅳ. 실무 적용 및 기술사 판단
오케스트레이션 사가는 특히 금융 정산, 여행 예약, 보험 심사, 주문-결제-배송, B2B 승인 프로세스처럼 단계가 많고 실패 복구 규칙이 명확해야 하는 업무에 적합하다. 이들 업무는 단순히 "성공/실패"만 아는 것으로 부족하고, 현재 상태, 남은 단계, 대기 시간, 담당 서비스, 보상 여부를 한눈에 봐야 운영이 가능하다.
반대로 단계가 2~3개뿐이고 분기가 거의 없으며, 서비스 간 이벤트 의미가 안정적이라면 코레오그래피가 더 가볍다. 모든 흐름을 오케스트레이터로 끌어오면 중앙 팀이 병목이 되고, 작은 변경도 워크플로 수정과 배포 절차를 거치게 된다. 따라서 채택 판단은 "복잡하니 중앙 통제"라는 감각론이 아니라, 가시성 이득이 중앙화 비용보다 큰가로 내려야 한다.
기술사 판단 체크리스트
- 단계 수와 분기 수가 커서 중앙 타임라인과 감사 로그가 꼭 필요한가?
- 보상 트랜잭션이 기술적 롤백이 아니라 업무 규칙으로 명확히 정의돼 있는가?
- 명령 수신 서비스가 멱등 처리와 재시도를 견딜 수 있는가?
- 오케스트레이터 상태 저장소가 장애 후 복구와 중복 실행 방지를 지원하는가?
- 타임아웃, 수동 개입, 재처리, DLQ (Dead Letter Queue) 같은 운영 절차가 준비돼 있는가?
- 중앙 논리를 물리적으로도 단일 장애점으로 두지 않도록 고가용성 구성이 되어 있는가?
자주 나오는 안티패턴
- 오케스트레이터 안에 세부 업무 규칙을 끝없이 밀어 넣어 거대한 갓 서비스로 만드는 경우
- 상태 저장 없이 동기 호출만 이어 붙여 놓고 "오케스트레이션"이라고 부르는 경우
- 보상 시나리오는 문서에만 있고 실제 실패 테스트를 해 보지 않은 경우
- 상관관계 ID와 추적 로그 없이 장애가 나면 사람 기억에 의존하는 경우
특히 SPOF (Single Point of Failure) 우려는 "오케스트레이터를 쓰지 말자"의 근거가 아니라, 상태를 영속화하고 인스턴스를 이중화하라는 운영 설계 과제로 보는 편이 정확하다. 논리적 중앙 제어는 남지만, 물리적 단일 장애점은 줄일 수 있기 때문이다.
- 📢 섹션 요약 비유: 공항 관제탑이 필요하다고 해서 관제실을 한 대 컴퓨터에만 두지는 않는다. 중요한 흐름을 중앙에서 관리하되, 그 중앙 자체는 더 튼튼하게 만들어야 한다.
Ⅴ. 기대효과 및 결론
오케스트레이션 사가가 잘 설계되면 복잡한 분산 업무를 "진행 중인 하나의 프로세스"로 볼 수 있게 된다. 그 결과 운영자는 현재 단계, 실패 지점, 재시도 횟수, 보상 여부를 추적할 수 있고, 감사와 규제 대응도 쉬워진다. 비즈니스 측면에서는 승인, 유예, 예약, 만료 같은 시간 개념을 흐름에 자연스럽게 녹여 넣을 수 있다.
물론 한계도 있다. 중앙 모델이 커질수록 변경 관리가 중요해지고, 워크플로 버전 관리와 하위 서비스 계약 관리가 함께 어려워진다. 또한 모든 흐름을 중앙에 넣으면 서비스 자율성이 약해지고 팀 간 조정 비용이 늘어난다. 따라서 오케스트레이션은 복잡한 핵심 흐름에 집중하고, 단순 후행 이벤트는 분산 방식으로 남겨 두는 균형이 중요하다.
앞으로는 워크플로 엔진, 이벤트 버스, 관측성 플랫폼을 결합한 하이브리드 구조가 더 일반적일 가능성이 크다. 결론적으로 오케스트레이션 사가는 로컬 트랜잭션들의 합을 장기 비즈니스 프로세스로 묶어 주는 중앙 워크플로 두뇌로 기억하면 된다. 다만 좋은 두뇌가 되려면 상태 기록, 보상 규칙, 고가용성, 멱등성이 반드시 함께 갖춰져야 한다.
- 📢 섹션 요약 비유: 좋은 지휘자는 모든 악기를 직접 연주하지 않는다. 누가 언제 들어오고, 틀렸을 때 어떻게 수습할지만 정확히 알고 전체 합주를 완성한다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| Saga 패턴 | 분산 트랜잭션을 로컬 트랜잭션과 보상으로 푸는 상위 개념 |
| 오케스트레이터 (Orchestrator) | 전체 상태를 기억하고 다음 명령을 결정하는 중앙 제어기 |
| 명령 (Command) | 특정 서비스에 수행을 요청하는 지시형 메시지 |
| 보상 트랜잭션 (Compensating Transaction) | 앞 단계 성공을 업무적으로 상쇄하는 복구 수단 |
| 상태 기계 (State Machine) | 흐름의 단계와 분기를 모델링하는 핵심 구조 |
| 멱등성 (Idempotency) | 재시도와 중복 전달 상황에서도 결과를 안정화하는 조건 |
| 코레오그래피 사가 | 중앙 제어형과 대비되는 이벤트 자율 협업 방식 |
| 워크플로 엔진 (Workflow Engine) | 오케스트레이션 사가를 안정적으로 구현하는 실행 기반 |
📈 관련 키워드 및 발전 흐름도
Business request accepted
│
▼
Saga instance created + state persisted
│
▼
Command dispatch to service
│
▼
Reply / event received
│
├──────────────► failure or timeout -> compensation chain
▼
Next state transition
│
▼
Completed / Failed with audit trail
이 흐름도는 "요청 수락 → 상태 기록 → 명령 전송 → 응답 기반 상태 전이 → 실패 시 보상 → 최종 종료"라는 오케스트레이션 사가의 실행 리듬을 요약한다.
👶 어린이를 위한 3줄 비유 설명
- 여러 친구가 함께 큰 일을 할 때, 반장 한 명이 순서를 기억하고 "이제 너 차례야"라고 말해 주는 거예요.
- 누가 중간에 못 하면 반장은 앞에서 했던 친구들에게 다시 정리하라고 알려 줘요.
- 그래서 모두가 서로를 다 몰라도, 반장이 순서를 잘 챙기면 큰 일을 끝낼 수 있어요.