AI 에이전트는 어떻게 안전하게 재시도해야 할까

들어가며

도구를 사용하는 AI 에이전트에게 “실패하면 다시 시도하라”는 지시는 단순한 동작이 아니다. 로컬 애플리케이션이 응답을 기록하지 못했더라도 외부 시스템에는 요청이 이미 도착했을 수 있다. 복구가 시작될 때는 최초 실행 당시의 권한이 바뀌었을 가능성도 있다. 이 상태를 구분하지 않고 재시도하면 작업이 중복 실행되거나 새로운 권한 경계를 넘을 수 있다.

arXiv 논문 「Permission to Retry」는 언어 모델의 생성 능력과 분리해 에이전트 워크플로의 실행 시점 신뢰성을 분석했다. 핵심 질문은 모델이 올바른 도구 호출을 작성하는지가 아니다. 중단이나 불확실한 결과 이후 시스템이 계속 실행할지, 거부할지, 아니면 해결되지 않은 의무를 남길지를 제대로 판단하는지에 있다.

핵심 내용

• 네 가지 의무를 분리해야 한다. 체크포인트는 애플리케이션이 무엇을 저장했는지를 보여준다. 현재 실행 권한은 지금 호출할 수 있는지를 판단한다. 외부 효과의 증거는 제공자가 이미 처리했는지를 확인한다. 효과가 확인됐다고 해서 후속 정산이나 완료 처리 권한까지 자동으로 생기는 것은 아니다.
• 다양한 실행 조건을 검증했다. 사전에 고정한 336개 이력을 네이티브 LangGraph와 Temporal 호스트, 14개 스케줄, 3개 제공자 계약, 4개 대응 애플리케이션 정책에 걸쳐 실행했다. 168개 호스트 쌍의 확인 결과는 모두 일치했다.
• 기록 보존 후 대조하는 방식이 가장 완전했다. 복구 애플리케이션에는 제공자의 실제 효과 원장을 공개하지 않고, 숨겨진 원장과 결과를 대조했다. 호스트별 42개 이력을 모두 통과했으며, 21개는 완료 확인, 15개는 거부, 6개는 예약을 보존한 미확정 결과였다.
• 일반적인 재시도 방식에는 빈틈이 있었다. 캐시 재시도는 30개, 재시도 전 권한 재검증은 36개, 안정 키 재시도는 31개 이력을 통과했다. 현재 권한을 다시 확인하는 일은 중요하지만, 외부에서 이미 일어난 일을 지속적으로 기록하는 장치를 대신할 수는 없다.
• 구성요소 수준의 추가 검증도 진행했다. InfinityOS의 권한 내보내기, 워커, 복구, 정산 코드를 저장소 페이크로 실행하는 16개 사례를 별도로 검사했다. 이는 전체 운영 환경의 벤치마크가 아니라 핵심 구성요소를 확인하는 보완 연구다.

의미와 영향

이 연구는 에이전트 인프라의 책임을 명확히 나눈다. 권한은 “지금 이 작업을 시도해도 되는가”를 결정하고, 효과의 증거는 “외부에서 이미 처리됐는가”를 보여주며, 정산 권한은 “그 결과를 후속 흐름에서 확정해도 되는가”를 결정한다. 이 질문들을 하나의 불리언 상태로 합치면 복구 시 가장 필요한 정보가 사라진다.

구현 관점에서는 검증 가능한 외부 관찰 결과를 보존하고, 안정적인 멱등 키를 사용하며, 복구 시점에 현재 권한을 다시 평가해야 한다. 평가 지표도 단일 성공률에 의존하기보다 안전성, 완료 여부, 미해결 의무를 분리해 보고할 필요가 있다. 이번 연구는 유한한 적합성 검증이며 InfinityOS 부분은 저장소 페이크에 의존하므로, 모든 에이전트 플랫폼의 보편적 순위라기보다 설계 원칙과 점검 기준으로 보는 것이 타당하다.

에이전트가 메시지 전송, 데이터 변경, 거래, 업무 흐름 실행을 맡게 될수록 중요한 능력은 무조건 다시 시도하는 것이 아니다. 증거가 부족할 때 멈추고, 해결되지 않은 의무를 명확하게 남기는 능력이다.

arXiv