중앙에서 다음 단계를 관리하고 싶다는 이유는 오케스트레이션을 검토할 출발점이 된다. 하지만 그것만으로 Temporal이 반드시 필요한 도구라고 결론 내릴 수는 없다. 실행 상태, 재시도, 긴 대기, 변경 배포를 직접 관리하는 부담과 Temporal을 배우고 운영하는 부담을 함께 비교해야 한다. 이번 초안은 아직 실험 결과가 없는 상태에서 무엇을 비교하고 어떻게 판정할지 정한다.
공통 예제는 허용량 예약, 가상 문서 변환, 결과 저장, 예약 확정이다. 같은 업무를 이벤트 기반 코레오그래피, 간단한 직접 조정기, Temporal로 표현한다고 가정한다. 어느 구현도 이번 글에서 우위가 입증된 것은 아니다. 제목의 질문에 답할 자료를 만드는 과정 자체가 이 글의 내용이다.
비교할 가설을 먼저 적는다
첫 가설은 “다음 단계와 실패 경로를 한곳에서 읽고 싶다면 중앙 조정 코드가 이해에 도움이 될 수 있다”다. 이것은 코레오그래피보다 항상 낫다는 주장이 아니다. 독립적인 이벤트 반응이 중심인 업무에서는 참여자가 자기 책임만 처리하는 구조가 적합할 수 있다.
두 번째 가설은 “재시도와 대기, 중단 후 재개를 직접 지속적으로 구현해야 한다면 Temporal의 실행 관리가 부담을 줄일 수 있다”다. 다만 결정성, Activity 멱등성, Worker 배포, Service 운영 또는 Cloud 관리가 새로운 책임으로 생긴다. 줄어드는 구현만 보고 늘어나는 책임을 빼면 공정한 판단이 아니다.
세 번째 가설은 “업무를 로컬 트랜잭션 안에서 끝낼 수 있다면 별도 실행 플랫폼이 과할 수 있다”다. 서비스 경계를 조정할 수 있는지 먼저 검토했던 이유다. 도구를 이미 골랐다는 이유로 구조를 단순화할 가능성을 비교에서 제외하지 않는다.
가장 어려운 실패 하나를 똑같이 넣는다
첫 비교는 9편에서 정한 예약 성공 후 응답 유실로 고정한다. 다음 단계로 넘어갈지 판단하는 쪽에서는 성공을 확인하지 못했다. 그러나 예약 원장에는 이미 예약이 존재한다. 이는 전달 방식과 조정 도구에 상관없이 남는 불확실성이다.
세 구현은 같은 생성 문서, 같은 업무 키, 같은 예약 API와 저장 API를 사용한다. 예약 API는 지정된 첫 시도에서 예약을 커밋한 뒤 응답을 끊는다. 실패가 어떤 시점에 주입됐는지 로그와 원장으로 확인한다. 단순 timeout을 발생시키고 실제 예약 성공 여부를 모르면 비교 조건이 달라진다.
예상 질문은 “누가 재시도하는가”, “같은 요청임을 어떻게 알아보는가”, “최종 예약을 누가 확정하는가”, “남은 실행을 어디서 찾는가”다. Temporal이 재시도를 관리해도 예약 API가 같은 업무 키를 중복 반영한다면 업무 조건을 지키지 못할 수 있다. 이 실패에서 멱등성의 책임은 도구가 대신 없애 주지 않는다.
결과는 업무 상태와 운영 동작으로 기록한다
최종 성공 여부만 보면 복구 과정의 차이가 사라진다. 다음 항목을 같은 표에 적는다. 결과가 아직 없으므로 값은 실험 뒤 채워야 한다.
| 판정 질문 | 관찰할 증거 | 현재 상태 |
|---|---|---|
| 예약이 중복되지 않았는가 | 업무 키별 예약 건수 | 미실험 |
| 예약이 올바르게 끝났는가 | 예약 확정·해제 원장 | 미실험 |
| 조정이 자동으로 재개됐는가 | 중단·재시작 전후 진행 기록 | 미실험 |
| 실패를 발견할 수 있었는가 | 조회 방법과 필요한 로그 | 미실험 |
| 변경을 안전하게 배포할 수 있는가 | 이전 실행과 새 코드 검증 | 미실험 |
| 운영자가 무엇을 해야 했는가 | 수동 조치와 판단 정보 | 미실험 |
코드 줄 수는 보조 자료일 수 있지만 우열의 기준으로 충분하지 않다. 직접 조정기에 영속 상태와 재시도를 넣지 않은 채 Temporal과 비교하면 서로 다른 기능을 비교하게 된다. 반대로 Temporal에도 필요하지 않은 운영 기능을 모두 붙이고 작은 조정기와 비교하면 다른 방향으로 불공정해진다.
학습 비용도 구분한다. 처음 써서 오래 걸린 시간과 반복 운영에서 계속 필요한 작업은 다르다. 한 번의 구현 시간을 장기 유지보수 비용으로 일반화하지 말고 어떤 개념과 기능을 추가로 관리했는지 기록한다.
자동 복구가 업무적으로 틀릴 수도 있다
대표 실패는 재시도가 끝나 Workflow가 완료됐지만 같은 업무에 예약이 두 개 생긴 상황이다. 화면에서는 성공해도 “동일 업무의 예약은 하나이며 사용량은 한 번 확정된다”는 조건을 위반한다. 자동으로 끝났다는 장점만 평가하면 이 문제를 놓친다.
반대로 코레오그래피판에서 수동 조치가 한 번 필요했다고 그 방식 전체가 불안정하다고 결론 낼 수도 없다. 이번 구현에 어떤 전달 보장과 중복 처리가 빠졌는지 확인해야 한다. 조정 패턴의 특성과 특정 실습 구현의 부족을 분리한다.
예약 응답 유실 비교가 끝나면 결과 저장 성공 후 응답 유실, 조정 프로세스 중단, 보상 실패, 마지막 허용량의 동시 예약을 별도 실험으로 추가할 수 있다. 한 번에 여러 실패를 섞지 않아야 어떤 책임을 누가 담당했는지 설명할 수 있다. 이번 글이 제안하는 첫 실패 하나로 모든 분산 일관성 문제를 판단하지 않는다.
조건부 결론은 어떻게 쓸까
실험 뒤 결론은 “Temporal이 최고였다”보다 조건을 드러내야 한다. 예를 들어 장기 대기와 반복적인 복구가 실제 요구이고, 팀이 결정성과 멱등성을 검증하며 Worker 변경을 관리할 수 있다면 도입 근거가 강해질 수 있다. 반면 단순한 짧은 작업이며 기존 방식으로 충분한 복구가 가능했다면 추가 플랫폼의 비용을 다시 따져야 한다.
오케스트레이션이 적합하다는 결론과 Temporal이 적합하다는 결론도 나눈다. 중앙 조정은 직접 구현하거나 다른 실행 도구로 제공할 수 있다. 이번 비교에 포함하지 않은 도구의 가격과 성능, 신뢰성까지 평가했다고 주장하지 않는다.
검증 질문은 “세 구현이 모두 완료됐지만 예약 건수가 다르면 무엇을 성공으로 판정할까?”다. 또 “직접 조정기에서 생략한 복구 기능을 Temporal의 비용 비교에서는 어떻게 취급해야 할까?”를 생각해 보자. 선정 이유를 방어하기보다 같은 업무 조건으로 다시 검토해야 선택의 근거가 남는다.