AI 에이전트가 재시도하기 전에 근거가 필요한 이유

응답이 유실되어 중복 작업으로 이어지는 일을 막는 방법

한 번의 환불을 처리하도록 승인받은 고객 지원 에이전트가 요청을 보낸 뒤 연결이 끊긴다. 에이전트는 처리가 성공했다는 확인을 받지 못하고 환불 요청을 다시 보낸다. 원래 요청이 성공적으로 처리된 상태였다면 에이전트의 재시도로 환불이 두 번 이루어질 수 있다.

이는 전적으로 가상의 사례다. 이 사례는 모델의 정확도만으로는 해결할 수 없는 문제를 보여 준다. 에이전트가 이전 작업으로 환경의 상태가 바뀌었는지 판단할 수 없다면 어떤 조치를 취해야 할까?

Unite.AI는 모델을 넘어 에이전트의 신뢰성을 살펴봤다. 이러한 논의에서는 복구 문제도 별도의 규칙으로 다뤄야 한다. 중요한 작업을 다시 시도하기 전에 에이전트는 어떤 일이 있었는지 확인하거나, 중복 효과가 발생하지 않는다는 유효한 보장을 확보해야 한다.

응답이 돌아오지 않았다고 해서 실패가 입증되는 것은 아니다

응답이 돌아오지 않았다고 해서 작업이 실패한 것은 아니다. 실행 전에 오류가 발생했는지, 확인 응답 없이 작업이 완료됐는지, 아니면 처리가 진행 중인지는 알 수 없다.

이는 분산 시스템에서 흔히 발생하는 문제로, Amazon이 설명한 바와 같다. Amazon은 재시도 메커니즘에 부작용의 반복을 막기 위한 구체적인 보호 장치가 필요한 이유를 설명한다. 에이전트가 추가되면 시스템의 복구 경로에 새로운 의사결정 주체가 생긴다. 에이전트는 오류에서 복구하는 방법에 관해 추가로 판단을 내릴 수 있다.

이러한 판단은 업무 운영 방식의 변화로 이어질 수 있다. 예를 들어 환불 금액을 달리해 재시도하는 것은 같은 요청을 한 번 더 반복하는 것에 그치지 않는다. 마찬가지로 첫 번째 결제 서비스가 응답을 중단했을 때 두 번째 결제 서비스를 선택하는 것도 같은 요청을 단순히 반복하는 일이 아니다.

팀은 작업 실행 권한을 부여하는 것과 결과를 알 수 없는 상황에서 복구할 권한을 부여하는 것을 구분해야 한다. 처음 승인을 받았다고 해서 작업을 다시 실행해도 안전한 것은 아니다.

최근 연구가 위험을 측정하다

2026년 9월에 공개된 사전 공개 논문 「정확히 한 번 실행은 어디에서 보장되는가?」는 LIMBO 벤치마크를 도입하고 모델 9개를 대상으로 에피소드 25,930건을 테스트했다. 시뮬레이션 서비스에서는 확인 응답 유실, 처리 지연, 중복 전달 상황을 시험했다.

저자들의 주요 테스트에서 중복 효과가 발생한 에피소드 1,279건 중 에이전트는 90%에서 처리가 성공했다고 보고했다. 따라서 잘못된 처리가 발생했는데도 에이전트가 성공했다고 보고할 수 있다.

이 결과는 통제된 벤치마크를 바탕으로 한 것이며 실제 운영 환경의 실패율을 추정한 것은 아니다. 서비스는 시뮬레이션으로 구현됐고, 여러 분석은 탐색적 성격을 띠었다. 팀은 에이전트가 성공적으로 실행했다고 보고하는 내용과 실제 작업 결과를 별도로 평가해야 한다.

이 논문은 현재 상태를 확인하는 것만으로는 충분하지 않을 수 있는 이유도 다룬다. 아직 처리 중인 요청은 확인이 끝난 뒤에도 적용될 수 있다. 상태 조회 결과가 비어 있더라도 요청이 결국 적용되지 않는다는 뜻은 아니다.

재시도는 동일한 의도를 가리킨다

요청을 받는 서비스는 멱등성 키를 사용해 하나의 작업을 반복 시도하는 요청을 식별할 수 있다. 이 방식이 제대로 지원되면 반복 시도로 추가 효과가 발생하지 않도록 보장한다. 모든 재시도에서 멱등성 키는 동일하게 유지되어야 한다.

Stripe의 API 문서는 멱등성 키의 작동 방식과 한계를 모두 보여 주는 사례를 제공한다. API v1에서는 키를 최소 24시간이 지난 뒤 삭제할 수 있다. 정리되어 삭제된 키를 다시 사용하면 새 요청이 발생한다. 또한 Stripe는 요청자가 제공한 매개변수가 최초 요청의 매개변수와 일치하는지 확인한다.

멱등성을 실무에 적용하려면 프롬프트에만 의존하지 말고 통합 계층에서 구현해야 한다. 작업을 전송하기 전에 승인된 작업을 기록한다. 해당 작업의 식별자와 정확한 매개변수, 해당되는 경우 제공업체 참조값, 그리고 작업 상태를 저장한다.

환불의 경우 승인과 원래 거래의 연결 정보, 그리고 제공업체에서 반환한 환불 식별자를 모두 저장한다. 같은 금액의 환불이 있는지 검색하는 것만으로는 그다지 확실한 증거가 되지 않는다. 정당한 요청 두 건의 금액이 같을 수 있기 때문이다. 또한 환불 요청이 접수된 뒤 검색 결과에 표시되기까지 시간이 걸릴 수도 있다. 원래 요청이 여전히 처리 중일 수도 있다.

에이전트나 작업자가 다시 시작되더라도 실행 계층은 해당 작업의 식별 정보를 유지해야 한다. 같은 작업으로 제출된 수정 요청은 거부해야 한다. 이러한 변경은 새 작업에 해당하므로 워크플로 규칙에 따라 새로 승인을 받아야 한다.

도구 설명만으로는 충분하지 않다

도구 설명뿐 아니라 요청을 받는 서비스의 멱등성 지원 계약도 확인해야 한다. 실제로 어떤 보장이 제공되는지 확인할 수 있도록 구현을 테스트한다.

불확실성을 운영 상태로 간주하라

그림 1. 중요한 작업을 위한 제안 복구 경로. 재시도할 때마다 현재 유효한 승인도 필요하다.

완료가 확인되면 워크플로에서 결과를 기록하고 해당 작업을 반복하지 않은 채 계속 진행합니다. 실행되지 않았음이 확인된 경우에는 원래 요청이 대기 중인 상태가 아니고 승인이 여전히 유효할 때만 다시 시도할 수 있습니다.

결과가 확정되지 않은 경우에는 고려해야 할 사항이 더 많습니다. 공급업체가 중복 효과가 발생하지 않는다고 보장하고 그 보장이 유효하다면, 동일한 키를 사용해 원래 요청을 다시 시도하도록 허용할 수 있습니다. 그렇지 않으면 쓰기 작업을 중단하고 상태를 조회하거나, 공급업체 지원을 받거나, 권한이 있는 담당자를 통해 문제를 해결해야 합니다. 확인 결과가 불확실하다는 이유만으로는 재시도를 승인하기에 충분하지 않습니다.

공급업체가 처리 및 결과 확인에 걸리는 시간의 한계를 문서화한 경우에도 작업을 일시 중지하는 것이 타당할 수 있습니다. 그러한 한계가 명시되지 않았다면, 시간이 흘렀다는 사실만으로 해당 작업이 실행되지 않았다고 확인할 수는 없습니다. 해결되지 않은 사례를 누가 담당할지, 그리고 담당자가 언제 검토해야 하는지를 정해야 합니다.

실패에서 복구하려면 다른 비즈니스 프로세스가 필요할 수 있습니다

환불은 성공했지만 이후 고객에게 알리는 데 실패한 경우, 워크플로 전체를 반복하면 환불이 다시 처리될 수 있습니다. 복구는 이미 완료된 작업의 증거를 보존하면서 미완료 단계를 마치는 데 초점을 맞춰야 합니다.

이미 완료된 작업을 바로잡아야 한다면, Microsoft는 보상 거래에 관한 지침을 제공합니다. 오류를 보상하는 올바른 방법은 애플리케이션마다 다릅니다. 보상을 하더라도 상황이 반드시 원래대로 돌아가는 것은 아니며, 보상 작업 자체가 실패할 수도 있습니다.

또한 거래를 취소하면 요금이 발생할 수 있습니다. 메시지를 수정하더라도 누군가가 이전 버전을 보지 않았다고 보장할 수는 없습니다. 따라서 모든 복구 작업에서 에이전트가 되돌리거나 변경하거나 실행을 확약할 수 있는 범위를 명확히 제한해야 합니다. 이러한 제한을 벗어나는 결정은 필요한 권한을 가진 사람에게 맡겨야 합니다.

배포 전에 두 번째 시도를 테스트하세요

중요한 도구 하나를 선택해 테스트 환경에서 의도적으로 복구 테스트를 진행하세요. 작업을 성공적으로 실행한 뒤 원래 요청에 대한 응답을 유실시킵니다. 상태를 확인한 다음에 첫 번째 요청이 실행되도록 지연시킵니다. 복구 중에는 작업자를 재시작합니다. 다시 시도하기 전에 키 보존 기간이 만료될 때까지 기다립니다. 반복해서 시도하는 과정에서 매개변수 하나를 변경합니다.

도구 응답에만 의존하지 말고 그 결과로 생성된 비즈니스 기록을 평가하세요. 중복 효과, 해결되지 않은 작업, 누락된 업무, 복구 시간, 추가 수동 개입을 기록합니다. 거래 취소와 고객 구제 조치를 포함한 전체 워크플로 비용을 사용해 올바르게 완료된 작업당 비용을 계산합니다.

또한 원래 요청과 유사한 실제 두 번째 요청도 테스트하세요. 시스템이 중복 생성을 방지하면서도 새로운 작업은 막지 않는지 확인합니다. 중복 방지와 최종적인 작업 완료 여부를 각각 평가하세요. 그렇지 않으면 모든 작업을 종료하는 에이전트가 안전해 보일 수 있지만, 실제로는 가치를 거의 제공하지 못하거나 전혀 제공하지 못할 수 있습니다.

평가 질문을 명확하게 제시해야 합니다. 시스템은 다음 사항을 설명할 수 있었습니까?

• 어떤 작업이 승인되었습니까?
• 작업 결과를 입증할 어떤 증거가 있었습니까?
• 재시도가 허용된 이유는 무엇입니까?

해결되지 않은 불확실성 때문에 일시 중지하는 에이전트는 시연 중에 효과가 떨어져 보일 수 있습니다. 그러나 실제 운영 환경에서 일시 중지는 고객의 본래 의도를 지켜 줄 수 있습니다. 유용한 지속성이란 승인된 작업을 완료하되, 같은 작업을 중복으로 수행하지 않는 것을 의미합니다.