에이전트가 도구 실행 중 멈췄을 때: 재시작이 아니라 ‘재시도·멱등성·보상’으로 복구하는 법

장시간 실행되거나 외부 API를 호출하는 AI 에이전트라면, “다시 실행”하기 전에 중복 실행을 막고 실패 전후 상태를 복구하는 기준부터 설계해야 합니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI 에이전트 PoC는 처음엔 간단해 보입니다. 문서를 읽고, 외부 도구를 호출하고, 결과를 정리해 전달하면 됩니다. 하지만 실제 업무와 연결하는 순간부터는 이야기가 달라집니다.

도구 호출 직후 네트워크가 끊기면 요청은 실패한 걸까요? 아니면 외부 시스템에는 이미 반영된 걸까요? 승인 대기 중 담당자가 응답하지 않으면 작업은 언제, 어떤 상태로 끝나야 할까요?

이때 에이전트를 무작정 재시작하면 메일이 중복 발송되거나, 티켓이 여러 번 생성되거나, 이미 처리된 요청이 다시 실행될 수 있습니다. 에이전트 운영에 필요한 것은 “실패하면 재시작한다”는 규칙이 아니라 다음 네 가지입니다.

1. 재시도해도 되는 실패와 그렇지 않은 실패를 구분할 것

2. 같은 요청이 여러 번 실행돼도 결과는 한 번만 반영되게 할 것

3. 일부 단계가 끝난 뒤 실패했을 때 어디까지 보상할지 정할 것

4. 사람 승인 대기를 종료 조건과 감사 기록이 있는 작업 단계로 다룰 것

Temporal의 Python 오류 처리 가이드는 재시도, 멱등성, Saga 패턴을 함께 다룹니다. 이 글에서는 그 원칙을 바탕으로 외부 도구를 쓰는 에이전트 PoC의 실패 복구 기준을 어떻게 설계할지 정리합니다.

1. 재시도 횟수보다 먼저 정해야 할 것: “이 작업은 다시 실행해도 되는가”

외부 API 호출은 최소 1회(at-least-once) 실행될 수 있습니다. 호출 결과를 받기 전에 연결이 끊기면, 호출한 쪽은 성공 여부를 확신하기 어렵습니다. 이 상태에서 단순히 재시도하면 중복 실행 위험이 생깁니다.

그래서 재시도 정책은 횟수부터 정하기보다, 도구 호출을 세 종류로 나누는 데서 시작하는 편이 낫습니다.

구분	예시	운영 기준
재시도 가능한 일시적 실패	네트워크 오류, 일시적 서버 오류, 제한 초과 응답	횟수·간격·최대 대기 시간을 정해 재시도
재시도하면 안 되는 실패	권한 없음, 잘못된 입력 형식, 정책 위반	즉시 중단하고 원인을 기록하거나 사람 검토로 전환
성공 여부가 불명확한 실패	요청 후 응답 수신 전 연결 종료	새 요청을 만들기 전에 같은 요청의 처리 상태를 확인

예를 들어 “고객에게 안내 메일 발송” 작업을 생각해 보겠습니다. 전송 API를 호출한 뒤 응답을 받지 못했다고 다른 요청으로 다시 보내면, 수신자는 같은 메일을 두 번 받을 수 있습니다.

이때 필요한 것은 “최대 3회 재시도” 같은 숫자보다 같은 업무 요청을 식별하는 멱등성 키입니다. 최초 실행 때 업무 요청 ID를 만들고, 재시도할 때도 같은 ID를 사용합니다. 외부 도구가 멱등성 키를 지원한다면 그 키를 전달하고, 지원하지 않는다면 호출 이력과 결과 조회 기능을 따로 설계해야 합니다.

Temporal은 활동(Activity)이 재실행될 수 있다는 전제에서 멱등성 있는 설계를 권장합니다. 재시도 정책은 예외를 숨기는 장치가 아니라, 중복 실행을 견딜 수 있게 설계된 작업에서만 안전하게 작동하는 장치입니다.

출처: Temporal Python 오류 처리: Retry·Idempotency·Saga

2. 작업을 되돌릴 수 없다면, 보상할 수 있는 단계로 쪼개야 한다

에이전트가 여러 도구를 순서대로 호출하는 업무는 중간까지만 성공한 채 실패할 수 있습니다.

예를 들어 다음 흐름을 보겠습니다.

1. 외부 시스템에 작업 티켓 생성

2. 담당자에게 승인 요청 발송

3. 승인 후 변경 작업 실행

4. 결과를 업무 시스템에 기록

3단계에서 실패했다고 해서 1단계에서 만든 티켓까지 자동으로 사라지지는 않습니다. 많은 외부 시스템은 데이터베이스 트랜잭션처럼 전체 작업을 한 번에 되돌릴 수 없기 때문입니다.

이때 필요한 운영 관점이 Saga입니다. Saga는 각 실행 단계에 대응하는 보상 작업을 정의하는 방식입니다. 핵심은 “원래 상태로 완벽하게 되돌린다”가 아니라, 업무적으로 허용 가능한 복구 상태를 만든다는 데 있습니다.

실행 단계	실패 시 확인할 질문	보상 작업 예시
티켓 생성	생성된 티켓을 유지해도 되는가?	티켓 취소 또는 실패 상태로 변경
승인 요청	승인 요청이 중복 발송됐는가?	기존 승인 요청을 조회하고 새 요청 발송을 차단
변경 작업	일부만 적용됐는가?	가능한 범위에서 되돌리거나 수동 복구 큐에 등록
결과 기록	실제 작업은 끝났지만 기록만 실패했는가?	실행 결과를 조회한 뒤 기록만 재처리

보상 작업도 외부 호출이라는 점을 놓치면 안 됩니다. “티켓 취소” 역시 중복 실행되거나 실패할 수 있으므로, 보상 작업에도 식별자와 상태 확인이 필요합니다.

PoC에서 모든 복구를 자동화할 필요는 없습니다. 대신 다음 기준은 분명히 정해두는 편이 현실적입니다.

• 자동 보상이 가능한 단계는 어디까지인가
• 자동 보상이 불가능하면 어떤 상태로 멈추는가
• 누가 어떤 정보로 수동 복구를 판단하는가
• 복구 완료 여부를 어떤 시스템 기록으로 확인하는가

Temporal의 오류 처리 문서는 장기 실행 워크플로우에서 Saga를 보상 로직으로 다루는 방식을 안내합니다.

출처: Temporal Python 오류 처리: Saga 패턴

3. 사람 승인은 “멈춤”이 아니라 타임아웃이 있는 상태 전환이다

사람 승인을 넣으면 에이전트가 안전해진다고 생각하기 쉽습니다. 하지만 승인 요청을 보낸 뒤 응답이 없을 때의 처리 기준이 없다면, 작업은 끝나지 않은 채 쌓일 수 있습니다.

승인 단계는 단순한 알림이 아니라 다음 정보를 가진 상태 전환으로 다뤄야 합니다.

• 승인 요청을 만든 시각
• 승인 대상과 요청 내용
• 승인 또는 거절 결과
• 응답 기한
• 기한 만료 시 다음 상태
• 재요청 가능 여부
• 승인 전후 작업 이력

Temporal의 Human-in-the-loop 에이전트 레시피는 사람의 입력을 기다리는 워크플로우를 다룹니다. PoC에서 특히 확인할 것은 “승인 기능이 동작하는가”보다, 승인이 오지 않아도 작업이 예측 가능하게 종료되는가입니다.

예를 들어 승인 대기 상태가 기한을 넘기면 다음 중 하나로 명시적으로 전환할 수 있습니다.

• 승인 만료: 작업을 종료하고 재요청 필요 상태로 기록
• 수동 검토 대기: 담당 운영자에게 복구 판단을 넘김
• 자동 취소: 아직 외부 변경이 일어나지 않은 경우에만 종료
• 재알림: 재알림 횟수와 최종 만료 시점을 함께 정의

승인 대기 중에도 감사 로그는 남아야 합니다. 나중에 “왜 작업이 실행되지 않았는가”를 확인할 때, 모델의 응답보다 요청·승인·만료·재시도 이력이 더 직접적인 운영 근거가 되기 때문입니다.

Temporal AI Cookbook은 도구 호출, 사람 승인, 내구성 있는 에이전트 워크플로우를 위한 예시를 제공합니다.

출처: Temporal AI Cookbook

바로 적용하는 체크리스트 또는 비교 기준

외부 도구를 하나라도 호출하는 에이전트 PoC라면, 배포 전 아래 질문에 답해 보세요.

• [ ] 각 도구 호출에 업무 요청을 식별하는 멱등성 키가 있는가?
• [ ] 재시도 가능한 오류와 즉시 중단해야 하는 오류를 구분했는가?
• [ ] 응답을 받지 못한 호출의 성공 여부를 조회하거나 확인할 방법이 있는가?
• [ ] 여러 단계 중 일부가 성공한 뒤 실패했을 때, 보상 작업 또는 수동 복구 경로가 있는가?
• [ ] 보상 작업 자체도 중복 실행과 실패를 고려했는가?
• [ ] 사람 승인 요청에 응답 기한과 만료 후 상태가 있는가?
• [ ] 승인·재시도·보상·최종 실패 이력을 감사 가능한 형태로 남기는가?
• [ ] 자동 복구가 불가능한 상태를 운영자가 확인할 수 있는 큐 또는 목록이 있는가?

이 체크리스트의 목적은 복잡한 장애 대응 체계를 한 번에 만드는 데 있지 않습니다. 먼저 대표 업무 하나를 골라, “중복 실행 없이 실패 상태를 설명하고 복구할 수 있는가”를 검증하는 데 있습니다.

마무리

에이전트 운영에서 실패는 예외적인 사건이 아니라 설계해야 하는 정상 경로입니다. 특히 외부 API와 사람 승인이 들어가는 순간, 재시작만으로는 복구 전략이 될 수 없습니다.

작은 PoC에서 먼저 만들어야 할 결과물은 화려한 자동화 화면이 아니라 다음 네 가지일 수 있습니다.

• 도구 호출별 멱등성 키 규칙
• 재시도하지 않을 오류 목록
• 단계별 보상 또는 수동 복구 기준
• 승인 만료와 감사 로그를 포함한 상태 전이표

이 기준이 있어야 장애가 났을 때 “다시 돌려도 될까?”가 아니라 “어느 상태에서, 어떤 근거로, 어떻게 복구할까?”를 판단할 수 있습니다.

생각해볼 질문: 지금 운영 중인 에이전트의 외부 도구 호출 하나를 골랐을 때, 응답을 받지 못한 직후에도 그 요청이 이미 실행됐는지 확인할 방법이 있나요?