AI 에이전트 재시도 설계 — 중복 실행과 무한 반복 막는 법

에이전트가 보고서를 만든 뒤 메일을 보내다가 멈췄습니다. 다시 실행하면 해결될까요? 메일 서버가 이미 발송을 접수했는데 응답만 끊겼다면, 재실행은 복구가 아니라 중복 발송이 될 수 있습니다.

재시도를 설계할 때는 오류 메시지보다 실제 작업이 어디까지 반영됐는지를 먼저 봐야 합니다. 에이전트 실행 로그 읽는 법에서 실패 지점을 찾았다면, 이번에는 그 지점에서 안전하게 멈추고 재개하는 기준을 정리해 보겠습니다.

실패와 결과 불명을 다른 상태로 기록하세요

아래는 설명을 위해 만든 주간 보고서 발송 사례입니다. 실제 운영 사고나 특정 서비스의 측정 결과가 아닙니다.

실행: weekly-report-demo
1. 통계 읽기 → 성공
2. 보고서 저장 → 성공, 파일 ID 확인
3. 최종 내용과 수신자 승인 → 완료
4. 메일 발송 → 응답 시간 초과

네 번째 단계는 발송 실패로 단정하지 않고 결과 불명으로 남깁니다. 타임아웃은 기다리는 시간이 끝났다는 뜻이지, 상대 시스템의 작업이 취소됐다는 증거는 아닙니다.

발송 요청 ID로 처리 상태를 조회할 수 있다면 먼저 확인합니다. 접수 기록이 있으면 다시 보내지 않고 그 결과를 연결합니다. 조회 기능이 없고 중복 방지도 보장되지 않으면 자동 재시도를 멈추고 담당자 확인으로 넘깁니다.

오류 유형별 재시도 판단표

관측한 상황	먼저 확인할 것	처리 방향
검색 API의 일시적인 연결 오류	읽기 전용인지, 서비스 상태	제한된 횟수로 재시도
호출 제한 응답	제공자의 대기 안내·한도 종류	안내에 맞춰 대기하거나 중단
인증·권한 오류	계정·토큰·허용 범위	같은 요청 반복 대신 담당자 확인
잘못된 도구 인수	필수 필드·대상·형식	입력 수정 후 다시 검증
쓰기·발송 응답 시간 초과	원격 작업의 실제 상태	결과 조회 후 재시도 여부 판단
승인 거절·보안 차단	차단 사유·승인 범위	재시도로 우회하지 않고 종료

일시 오류를 구분하고 제한된 재시도 정책을 두는 기본 원칙은 Microsoft의 Retry 패턴을 참고할 수 있습니다. 에이전트에서는 여기에 도구의 영향 범위와 승인 상태를 함께 붙여야 합니다.

중복 실행 방지는 프롬프트 밖에 두세요

멱등성은 같은 작업을 반복 요청해도 의도한 효과가 추가로 발생하지 않게 다루는 성질입니다. 모델에게 “한 번만 보내”라고 지시하는 것만으로는 네트워크 오류나 여러 작업자의 동시 실행을 통제할 수 없습니다.

지원하는 API라면 한 논리적 작업에 하나의 중복 방지 키를 발급하고, 재시도에는 같은 키와 같은 입력을 사용합니다. 호출할 때마다 새 키를 만들면 다른 작업으로 처리될 수 있습니다. Stripe의 멱등 요청 문서는 이 동작을 확인할 수 있는 구체적인 예입니다. 다른 도구의 지원 여부와 키 보존 기간은 별도로 확인해야 합니다.

다음은 특정 SDK 코드가 아닌 애플리케이션 내부 기록 예시입니다.

operation_id=op-demo-042
run_id=weekly-report-demo
tool=email.send
payload_version=approved-v1
approval_id=approval-demo-017
state=unknown
remote_request_id=request-demo-083
attempt_count=1

중복 방지 기록은 run_id만으로 묶지 않습니다. 한 실행에서 서로 다른 메일 두 통을 보내야 한다면 각각 별도 작업 ID가 필요합니다. 반대로 같은 메일을 복구하는 시도라면 작업 ID를 바꾸지 않습니다.

도구가 중복 방지 키를 지원하지 않는 경우에는 내부 작업 원장과 동시 실행 잠금으로 위험을 줄일 수 있습니다. 다만 외부 발송과 내부 기록 사이에서 장애가 날 수 있으므로, 이 장치만으로 외부 시스템까지 정확히 한 번 실행된다고 보장하지 마세요.

재시도 상한은 한 곳에서 관리하세요

에이전트, SDK, 작업 큐가 각각 재시도하면 실제 호출 횟수는 생각보다 커집니다. 예를 들어 외부 계층이 총 3회 실행하고 매번 SDK가 총 3회 시도하면, 해당 API 호출은 최대 9회가 됩니다. 이는 설명용 산술 예시이며 특정 SDK의 기본 설정은 아닙니다.

운영 설정표에는 다음 항목을 분리해 적습니다.

최초 실행을 포함한 총 시도 횟수
각 시도의 타임아웃과 전체 업무의 종료 시각
대기 간격과 동시 재시도를 분산하는 임의 지연
실행 전체의 도구 호출·비용 상한
SDK와 작업 큐에 이미 설정된 재시도
한도를 넘겼을 때 넘겨받을 담당 역할

대기 시간이 남은 업무 시간을 초과하면 더 기다리지 않고 종료합니다. 실패한 호출에도 비용이 발생할 수 있으므로 성공한 시도만 집계하지 않습니다.

완료된 단계에서 재개하는 흐름

오류 감지
  → 현재 단계와 승인된 입력 확인
  → 결과 불명인 쓰기 작업인가?
      → 예: 원격 결과 조회 / 확인 불가 시 사람 검토
      → 아니오: 재시도 가능한 오류인지 판정
  → 횟수·시간·비용 상한 확인
  → 필요한 단계만 재개
  → 실제 결과 확인 후 완료 기록

보고서 파일이 이미 저장됐다면 파일 ID와 내용 버전을 확인한 뒤 재사용합니다. 복구 중 모델이 보고서 내용이나 수신자를 바꾸었다면 이전 승인을 그대로 적용하지 않습니다. 변경된 입력을 다시 검토받아야 합니다.

승인 범위와 완료 조건을 처음 정하는 방법은 AI 에이전트 업무 자동화 시작법에서 이어서 확인할 수 있습니다.

기대 결과·실패 징후·확인 순서

기대 결과: 같은 발송 요청을 반복해도 새 작업으로 분리되지 않고, 결과가 불명확한 작업은 확인 대기 상태로 남습니다. 완료된 보고서는 다시 만들지 않습니다.

실패 징후: 매 재시도마다 작업 ID가 바뀌거나, 승인 거절을 오류로 보고 반복하거나, 내부 로그는 한 건인데 실제 메일은 여러 통 도착합니다.

확인 순서

테스트 수신함과 가상 자료로만 검증합니다.
발송 접수 뒤 응답이 끊기는 상황을 시험합니다.
같은 작업을 다시 실행하고 원격 접수 건수를 확인합니다.
같은 작업을 동시에 요청해 중복 방지가 유지되는지 확인합니다.
입력이 바뀌거나 승인이 철회된 경우 재개가 차단되는지 봅니다.
상한 도달 뒤 추가 호출 없이 담당자에게 인계되는지 확인합니다.

자주 묻는 질문

Q1. 읽기 전용 도구는 마음껏 재시도해도 되나요? 데이터 변경 위험은 작지만 호출 제한과 비용, 서버 부하는 남습니다. 읽기 작업에도 상한이 필요합니다.

Q2. 실패하면 전체 실행을 처음부터 시작하는 편이 쉽지 않나요? 이미 완료한 쓰기 작업이 있으면 중복 효과가 생길 수 있습니다. 완료 기록과 실제 결과를 대조한 뒤 필요한 단계만 재개하세요.

Q3. 중복 방지 키를 붙이면 모든 도구가 안전해지나요? 아닙니다. 도구가 그 키를 처리해야 하며 지원 범위와 만료 조건도 다릅니다. 지원하지 않는 API에 임의 헤더를 붙이는 것은 보장이 아닙니다.

Q4. 결과를 확인할 수 없으면 실패로 처리하면 되나요? 실패로 단정하면 후속 자동화가 다시 실행할 수 있습니다. 결과 불명 상태와 확인 담당자를 명시하고 중복 실행을 보류하는 편이 안전합니다.

공식 자료와 확인 기준일

확인 기준일: 2026-09-06 — 작업 원장과 흐름도는 위 원칙을 업무에 적용한 설계 예시입니다. 실제 도구의 재시도·멱등성 계약을 먼저 확인하세요.