여러 서비스의 업무 순서를 중앙에서 관리하고 싶다면 Temporal은 검토할 만한 후보다. 하지만 오케스트레이션이 적합하다는 판단만으로 Temporal 도입까지 자동으로 결정되지는 않는다. 단순한 상태 관리로 충분한지, 중단 복구와 긴 대기 때문에 실행 관리 도구가 필요한지 구분해야 한다. 도구 선택은 기대하는 기능뿐 아니라 받아들여야 하는 제약과 운영 책임까지 포함한다.
이 시리즈의 출발점도 중앙 오케스트레이션을 원해 Temporal을 선택했다는 개인 개발자의 판단이다. 그 동기는 설명할 수 있지만 당시 선택이 최선이었다거나 운영 성과가 입증됐다고 가정하지 않는다. 앞으로 가상 문서 처리 예제를 직접 구현하고 실패를 넣어 처음 판단을 다시 평가한다. 이 글은 그 평가 기준을 미리 고정하는 학습 초안이다.
필요한 것은 어떤 종류의 실행 관리인가
요청 하나가 짧은 로컬 DB 트랜잭션으로 끝나면 별도 Workflow 플랫폼이 제공하는 이점이 작을 수 있다. 반면 문서 변환이 오래 걸리고, 승인 메시지를 기다리며, 실패한 외부 호출을 일정한 정책으로 재시도하고, 프로세스가 바뀌어도 계속 진행해야 한다면 직접 관리할 상태가 늘어난다. 정상 흐름의 단계 수보다 기다림과 복구 책임을 세어 보는 편이 유용하다.
| 질문 | 도입을 검토할 근거 | 먼저 단순화할 수 있는 부분 |
|---|---|---|
| 프로세스보다 업무가 오래 사는가 | 재시작 후 대기·순서를 복원해야 함 | 한 번의 짧은 요청으로 끝나는지 |
| 분기와 승인 대기가 있는가 | 현재 단계와 메시지를 함께 관리해야 함 | 불필요한 중간 단계를 없앨 수 있는지 |
| 외부 실패가 자주 고려되는가 | 재시도·보상·관측의 공통 기능 필요 | 참여자 계약이 먼저 불명확하지 않은지 |
| 실행 중 코드가 바뀌는가 | 기존 실행과 새 코드의 호환성 필요 | 실행 수명과 배포 방식을 단순화할 수 있는지 |
이 표의 항목을 많이 만족한다고 무조건 도입하는 것은 아니다. 현재 팀이 사용하는 작업 처리 기반이 이미 상당 부분을 제공할 수 있다. 반대로 처음에는 짧은 업무라도 동일한 복구 코드를 여러 서비스에서 반복 구현하고 있다면 공통 실행 관리의 이점이 있을 수 있다. 실제 사용 사례와 변경 빈도를 적고 판단한다.
맡겨도 남는 책임을 적는다
Temporal은 업무에 맞는 예약 해제 정책을 자동으로 알아내지 못한다. 같은 업무 요청이 여러 번 들어왔을 때 사용량을 중복 확정하지 않는 계약도 애플리케이션이 정한다. 외부 호출이 timeout됐다고 상대 작업이 강제로 중지되는 것도 아니다. Workflow 이력과 외부 원장의 결과를 함께 이해해야 한다.
Workflow 코드에는 재생 규칙이 있다. 새로 시작한 실행이 정상 동작한다고 기존 실행 이력에도 호환된다는 뜻은 아니다. 개발자는 어떤 코드가 Workflow에 들어갈 수 있고 어떤 작업을 Activity로 분리할지 배워야 한다. 실행 중인 업무를 유지하면서 코드를 바꾸는 테스트와 배포 절차도 필요하다. Workflow 정의는 이 제약을 이해하는 기준이다.
운영 방식도 선택해야 한다. Service를 직접 운영하면 저장소, 스키마 변경, 용량, 인증·인가, 백업과 복구를 관리한다. Cloud를 사용하면 Service 운영 책임 일부를 맡길 수 있지만 사용자 Worker 배포, 업무 코드, 외부 효과, 애플리케이션 관측은 여전히 필요하다. 실제 요금과 요구 조건을 조사하지 않은 상태에서 어느 쪽이 더 싸거나 안전하다고 결론내리지 않는다.
비교 실험의 조건을 같게 만든다
코레오그래피판에는 장애를 많이 넣고 Temporal판에는 정상 실행만 넣으면 공정한 비교가 아니다. 세 구현에서 예약·변환·저장·확정의 참여자 계약과 업무 식별자를 같게 둔다. 간단한 조정자판, 이벤트 반응판, Temporal판이 동일한 외부 응답 유실을 만났을 때 무엇이 남는지 확인한다. 전송 수단의 차이가 있다면 그 차이를 기록한다.
첫 비교의 대표 실패는 예약 성공 후 응답 유실이다. 예약 원장에는 기록이 있지만 호출자는 성공을 확인하지 못하게 만든다. 이후 각 구현에서 재시도와 상태 조회가 어떻게 이어지는지 본다. 성공률 숫자를 만들기보다 중복 예약 여부, 결과를 모르는 상태의 표현, 운영자가 읽어야 할 정보, 추가로 작성한 복구 코드를 비교한다.
- 세 구현에 같은 예약 API와 업무 키를 사용한다.
- 첫 예약 성공 직후 응답을 유실시키는 실패를 넣는다.
- 재시도 후 예약 수와 최종 문서 상태를 확인한다.
- 도구가 제공한 기능과 직접 작성한 책임을 각각 적는다.
이 실험은 아직 수행하지 않았다. 따라서 현재 결론은 ‘실행 관리 부담을 줄일 가능성이 있는 후보’다. 멱등한 예약 API가 없다면 어느 조정 방식을 써도 문제가 남을 수 있다는 예상도 함께 둔다. 결과가 나오면 이 예상이 맞았는지 수정한다.
채택과 보류의 이유를 모두 남긴다
채택 이유는 유명해서, 코드로 작성할 수 있어서 같은 선호에서 멈추지 않는다. 승인 대기 중 Worker 재시작을 직접 처리하지 않아도 되는지, 장애 추적에 필요한 이력이 제공되는지처럼 확인 가능한 요구로 바꾼다. 보류 이유도 막연한 복잡성보다 결정성 학습, 추가 저장소 운영, 배포 검증 비용처럼 구체화한다.
팀 역량은 단순히 라이브러리를 사용할 줄 아는지에 한정되지 않는다. 실패 결과를 해석하고, 재시도 폭주를 막고, 데이터 노출을 점검하고, 실행 중 코드 변경을 검증할 수 있어야 한다. 자기 호스팅을 선택했다면 백업을 만들었다는 사실보다 격리 환경에서 복원해 열린 실행을 재개할 수 있는지를 확인한다. 운영 준비 안내는 이후 학습할 책임을 점검하는 데 활용할 수 있다.
다음 글부터는 최소 Java Workflow를 준비하기 전에 Client·Service·Worker의 실행 위치를 구분한다. 선택의 정당화를 위해 기능을 모으는 대신 하나씩 실험하고, 시리즈 후반에서 같은 판단표를 다시 작성한다. 필요했던 기능과 감당한 비용이 실제로 맞아떨어졌는지가 그때의 결론이다.
이해 확인
오케스트레이션을 원한다는 요구와 Temporal이 필요하다는 판단 사이에는 어떤 추가 근거가 있어야 할까? Cloud를 사용하더라도 애플리케이션이 반드시 책임져야 할 항목을 두 가지 골라 예제와 연결해 보자.
참고 자료
- Workflow Definition: 실행 관리의 이점과 코드 제약을 함께 확인.
- Worker 배포: 사용자 Worker의 배포 책임.
- Self-hosted production checklist: 운영 준비와 검증 항목.
- Temporal Cloud 안내: 관리형 Service의 역할을 확인할 출발점.