목차
코레오그래피는 결합이 낮은 대신, 전체 흐름이 코드 어디에도 없어 커지면 아무도 못 본다. 그 흐름을 한곳에 쥐는 반대편 방식이 오케스트레이션이다.
흐름이 안 보이는 값을 치른다
코레오그래피에선 각 서비스가 자기 앞 이벤트를 듣고 반응할 뿐, “주문 사가가 결제 → 재고 → 배송 순으로 흐른다”를 적어둔 곳이 없다. 단계가 늘고 보상 경로까지 얽히면 흐름을 머릿속으로 재구성해야 하고, 어디서 멈췄는지 추적하기도 어렵다.
오케스트레이션은 이 문제를 정면으로 뒤집는다 - 흐름을 한 곳에 몰아 적는다.
오케스트레이터: 흐름을 한곳에 쥔다
오케스트레이터(orchestrator) 라는 지휘자를 하나 둔다. 사가의 전체 순서를 아는 건 오직 이 지휘자뿐이다. 각 서비스는 시키는 일만 하고, 다음이 뭔지는 모른다.
코레오그래피의 화살표가 서비스끼리 옆으로 오갔다면, 여기선 모든 화살표가 오케스트레이터를 거쳐 오간다. 지휘자가 하나씩 시키고, 응답을 받아, 다음을 시킨다.
명령을 보내고 응답을 기다린다
방향이 바뀐 걸 눈여겨보자. 코레오그래피는 “결제 완료됨” 같은 이벤트를 알리는 방식이었다. 오케스트레이션은 “결제하라” 같은 명령을 시키는 방식이다.
- 이벤트(알림) - “일어난 일”을 방송한다. 누가 듣는지 발행자는 모른다.
- 명령(시킴) - “이걸 해라”를 특정 서비스에게 지목해 보낸다. 응답을 기다린다.
오케스트레이터는 누구에게 무엇을 시킬지를 알기 때문에 명령을 쓴다. 그래서 흐름이 오케스트레이터 코드 안에 “결제 시키고 → 되면 재고 시키고 → 되면 배송 시킨다”로 또렷이 적힌다.
실패도 한곳에서 지휘한다
보상도 오케스트레이터가 지휘한다. 재고 단계가 실패하면, 그 응답을 받은 오케스트레이터가 앞 단계들의 취소를 역순으로 시킨다.
코레오그래피에선 각 서비스가 “내 앞이 실패했으니 나도 되돌려야 하나”를 스스로 판단해야 했다. 오케스트레이션에선 그 판단이 한 곳에 있다. “어디까지 갔고 무엇을 되돌려야 하는지”를 오케스트레이터가 다 안다.
상태 기계로 본다
오케스트레이터 안의 사가는 사실상 상태 기계다. 지금 어느 단계인지 상태로 들고, 응답이 올 때마다 다음 상태로 옮긴다.
이렇게 상태로 들고 있으면 좋은 점이 크다 - 멈춘 사가를 찾아 이어가거나 되돌릴 수 있다. “재고확보중에서 두 시간째 멈춘 주문들”을 상태로 조회해 손볼 수 있다. 흐름이 데이터로 남는 셈이다.
코레오 vs 오케: 무엇을 언제
둘은 우열이 아니라 트레이드오프다.
- 코레오그래피가 맞을 때 - 단계가 적고(두셋), 서비스를 느슨하게 두고 싶고, 새 반응을 자유롭게 끼우고 싶을 때. 지휘자라는 중심점을 안 만든다.
- 오케스트레이션이 맞을 때 - 단계가 많고, 흐름이 복잡하고, 실패·보상 경로가 얽히고, “지금 어디까지 갔나”를 봐야 할 때. 흐름을 한곳에서 읽고 싶을 때.
경험칙은 이렇다 - 단순한 사가는 코레오로 시작하고, 흐름이 안 보여 아프기 시작하면 오케로 옮긴다. 처음부터 오케스트레이터를 세우면 단순한 일에 지휘자라는 무게가 얹힌다.
대가: 지휘자가 중심이 된다
오케스트레이션의 대가는 오케스트레이터가 중심점이 된다는 것이다. 모든 흐름이 그를 거치니, 그가 죽으면 사가가 멈추고, 그가 너무 많은 사가를 알면 모든 걸 아는 거대 서비스로 부푼다. 코레오그래피가 피하려던 바로 그 중심 결합이 여기서 생긴다.
그래서 오케스트레이터는 흐름의 조율만 하고 비즈니스 로직은 각 서비스에 남겨둬야 한다. 지휘자가 결제 로직까지 품기 시작하면, 쪼갠 의미가 사라진다.
실무에서: 오케스트레이터도 안전해야 한다
- 오케스트레이터의 상태도 아웃박스로 - 지휘자가 “다음을 시켰다”는 기록과 명령 발행이 어긋나면 사가가 샌다. 아웃박스로 상태 전이와 명령 발행을 묶는다.
- 명령도 멱등하게 - 오케스트레이터가 응답을 놓쳐 같은 명령을 재전송할 수 있다. 받는 서비스는 멱등해야 한다.
- 타임아웃을 둔다 - 어느 단계가 응답이 없으면 영원히 기다리지 말고, 정해진 시간 뒤 보상하거나 재시도하도록 상태 기계에 시간 축을 넣는다.
정리
- 코레오그래피의 “흐름이 안 보임”을 뒤집어, 오케스트레이터 하나가 흐름을 한곳에 쥔다.
- 지휘자는 각 서비스에 명령을 시키고 응답을 받아 다음을 시킨다 - 흐름이 코드에 또렷이 적히고, 상태 기계로 멈춘 사가를 추적·복구할 수 있다.
- 대신 오케스트레이터가 중심점이 되어, 죽으면 멈추고 방치하면 거대 서비스로 분다 - 조율만 시키고 로직은 남긴다.
- 둘은 우열이 아니다 - 단순하면 코레오, 흐름이 복잡하고 봐야 하면 오케.
다음 글은 트랜잭션에서 조회로 눈을 옮긴다 - 쓰는 모델과 읽는 모델을 가르는 CQRS다.