오래 실행되는 AI 작업의 취소: 멈추기와 되돌리기를 나누기

취소 요청과 강제 종료가 다른 이유

Temporal의 공식 문서는 협력적으로 취소를 처리하는 방식과 실행을 종료하는 방식을 구분합니다. 보상 작업에 대한 공식 글은 여러 서비스의 변경을 되돌리는 행동을 업무별로 정의해야 한다고 설명합니다. 이 구분은 AI 작업에도 적용할 수 있습니다. 모델 호출을 멈추더라도 이미 만들어진 예약이나 보낸 메시지가 없어지는 것은 아닙니다.

• Temporal · Cancellation and Termination
• Temporal · Compensating Actions with Sagas

토핑의 운영 설계에서는 취소를 하나의 완료 상태보다 처리 과정으로 봅니다. 새 작업의 시작을 막고 진행 중인 외부 요청을 확인한 뒤, 이미 반영된 변경에 필요한 보상을 수행합니다. 사람에게는 취소 접수, 중단 확인, 되돌리는 중과 수동 확인 필요를 구분해 보여주는 편이 실제 상태를 이해하기 쉽습니다.

장소와 물품을 확보한 뒤 요청이 바뀌면

가상의 행사 준비 에이전트가 장소를 예약하고 장비 재고를 확보한 뒤 초대장을 작성한다고 가정합니다. 사용자가 행사를 취소하면 아직 작성 중인 문서는 멈출 수 있지만 장소 예약과 재고 확보는 별도의 취소가 필요합니다. 초대장이 이미 발송되었다면 발송 기록을 삭제하는 대신 취소 안내가 필요한지 사람이 결정해야 합니다.

각 단계의 실행 기록에는 외부 거래 번호와 현재 상태, 되돌리는 방법을 연결합니다. 예약 취소가 가능한 기한, 재고 확보 해제와 실제 출고 후 반품은 서로 다르므로 같은 복구 함수로 처리하기 어렵습니다. 자동 보상할 수 있는 항목과 비용·대외 안내 때문에 별도 판단이 필요한 항목을 사전에 나눕니다.

보상은 과거 상태를 무조건 덮어쓰는 작업이 아닙니다

보상은 업무 의미를 되돌리는 행동입니다. 재고를 확보한 뒤 다른 주문도 같은 품목을 처리했다면 예전 재고 수량을 덮어쓰는 방식은 다른 거래를 훼손할 수 있습니다. 해당 작업이 확보한 수량만 해제하도록 식별자를 사용하고, 이미 해제된 요청을 다시 처리해도 추가 변경이 생기지 않는지 확인합니다.

취소 요청 뒤 늦게 도착하는 성공 응답도 처리해야 합니다. 예약 API의 응답이 늦었다고 실패로 단정하고 끝내면, 사용자는 취소했다고 생각하지만 외부에는 예약이 남을 수 있습니다. 취소 의도와 마지막 확인 상태를 저장하고 지연 응답이 도착했을 때 보상 대상에 포함할 수 있도록 실행 기록을 유지합니다.

업무 단계 사이에서 취소를 넣어 봅니다

검수는 마지막 단계에서만 취소 버튼을 누르는 것으로 충분하지 않습니다. 예약 직전, 외부 응답 대기 중, 재고 확보 직후와 보상 도중 서버가 재시작되는 상황을 시험합니다. 중단된 작업을 재개하더라도 원래 구매를 계속하지 않고 취소 절차를 이어가는지, 보상도 중복 실행되지 않는지를 확인하세요.

최종 보고에는 중지한 작업, 되돌린 변경과 남아 있는 외부 상태를 남깁니다. 모든 것을 자동으로 원상 복구할 수 없을 때에는 완료로 숨기지 않고 담당자가 이어받을 번호와 연락 경로를 제공합니다. 장기 실행의 도입 범위에 취소와 보상 검수를 포함하면 사용자의 변경된 의사가 실제 시스템 상태에 반영되는지 확인할 수 있습니다.