177. 오케스트레이션 사가 (Orchestration Saga)

핵심 인사이트: 서비스가 수십 개로 늘어나고 로직이 꼬이기 시작하면 각자도생(코레오그래피) 방식은 디버깅의 무덤이 된다. 오케스트레이션 사가는 교향악단의 완고한 '마에스트로(지휘자)'를 딱 한 명 두고, "주문팀 먼저 연주해, 그다음 결제팀 들어가, 결제 실패했네? 주문팀 다시 취소 연주해!"라며 모든 흐름을 중앙에서 칼같이 통제하는 패턴이다.

Ⅰ. 오케스트레이션 사가 (Orchestration Saga)의 개념

마이크로서비스 아키텍처(MSA)의 Saga 패턴 구현 방식 중 하나입니다. 트랜잭션에 참여하는 모든 마이크로서비스들이 자율적으로 이벤트를 주고받는 대신, '사가 오케스트레이터(Saga Orchestrator)'라는 중앙 통제 서버(또는 모듈)를 별도로 두고, 이 지휘관이 전체 트랜잭션의 순서(State Machine)를 관리하며 각 서비스에게 "이거 해, 저거 해"라고 명시적인 명령(Command)을 내리는 중앙 집중형 방식입니다.

Ⅱ. 오케스트레이터의 동작 구조 (중앙 통제 방식)

오케스트레이터는 트랜잭션의 '설계도(State Machine)'를 쥐고 있습니다.

[ 주문 ➔ 결제 ➔ 배송 성공 및 실패 보상 시나리오 ]

         ┌─────────────── 🌟 Saga Orchestrator 🌟 ──────────────┐
         │ (전체 진행 상태를 모니터링하며 순서대로 명령을 하달함) │
         └─────┬──────────────────┬──────────────────┬────────────┘
               │ 1.주문해!        │ 2.결제해!        │ 3.배송준비해!
               ▼                  ▼                  ▼
        [ 주문 서비스 ]    [ 결제 서비스 ]    [ 배송 서비스 ]
               │                  │                  │
               │ (주문완료)       │ (🚨 잔액부족 실패!)
               └─(응답)─▶         └─(에러 응답)─▶ 

(오케스트레이터의 보상 트랜잭션 발동!)
Orchestrator: "결제가 실패했군. 주문 서비스야, 아까 했던 주문 취소해라!" (Command 전송)
주문 서비스: (주문 취소 로직 실행)

Ⅲ. 오케스트레이션 사가의 장점 (왜 대기업이 선호하는가?)

장점	설명
복잡한 비즈니스 로직 제어 완벽	트랜잭션 단계가 10단계가 넘어가거나, 분기가 꼬이는 복잡한 B2B 프로세스(예: 은행 결제망)에서 현재 트랜잭션이 어디까지 진행됐고 왜 멈췄는지 중앙에서 한눈에 모니터링(가시성 확보)이 가능합니다.
순환 참조(Cyclic Dependency) 제거	각 서비스는 오케스트레이터와만 통신할 뿐 서비스끼리는 서로를 전혀 모릅니다. 즉 서비스 간의 엉킴(스파게티 코드)이 완벽하게 해소됩니다.
로직의 중앙 집중화	새로운 서비스(예: 포인트 적립)가 추가될 때, 오케스트레이터의 룰(Rule) 로직만 한 줄 추가하면 끝납니다. 다른 개별 서비스의 코드는 단 한 줄도 손댈 필요가 없습니다.

Ⅳ. 치명적 단점 (SPOF와 갓-클래스)

모든 명령과 응답이 오케스트레이터를 거쳐 가므로 이 중앙 서버가 죽으면 회사 전체의 트랜잭션이 멈추는 단일 장애점(SPOF, Single Point of Failure) 이 됩니다. 또한 오케스트레이터 서버 안에 너무 많은 비즈니스 로직이 뭉쳐서 비대해지는 '갓 클래스(God Class, 모놀리식의 재림)' 안티 패턴에 빠질 위험을 경계해야 합니다.

📢 섹션 요약 비유: 각자 알아서 눈치껏 요리하는 주방(코레오그래피)이 너무 복잡해져서 손님이 1시간을 기다리게 되자, 결국 주방 가운데에 고든 램지(오케스트레이터)를 세운 것입니다. 램지가 "고기 구워! 야채 썰어! 고기 다 탔잖아, 전부 버리고 다시 해!(보상 트랜잭션)"라고 쩌렁쩌렁 소리치며 주방 전체의 요리 순서를 완벽하게 장악하여 사고를 막는 중앙 통제 시스템입니다.