에이전트의 중복 결제, 멱등성 키는 어디에 둬야 하나
MCP 툴과 에이전트 하네스에서 타임아웃 후 중복 쓰기를 막기 위한 계약과 재시도 규칙을 설계한다.
2026-10-01
타임아웃 뒤에 무엇을 알 수 있는가
결제 툴 호출이 타임아웃됐을 때 에이전트가 아는 것은 응답을 받지 못했다는 사실뿐이다. 요청이 실행되지 않았을 수도 있고, 결제는 끝났지만 응답만 사라졌을 수도 있다. 원래 요청이 아직 처리 중이라 나중에 결제될 수도 있다. 이 상태에서 같은 쓰기를 새 요청으로 보내면 중복 결제가 생긴다.
이 구분은 Where Does Exactly-Once Live?의 핵심이다. 이 글에서 사용하는 판본은 **arXiv:2609.29095v1 (2026-09-24)**이다. 논문은 쓰기 결과를 최종 화면이 아니라 실제로 확정된 효과의 원장으로 판정한다. 두 번 결제한 뒤 한 건을 환불해도 중복 실행은 사라지지 않는다.
아래 비교는 같은 타임아웃과 빈 조회 결과를 보고도 재시도의 안전성이 달라지는 이유를 보여 준다.
따라서 빈 조회 결과를 곧바로 “실행되지 않음”으로 해석해서는 안 된다. 조회 시점에 원래 요청이 아직 처리 중이거나, 조회 경로에 반영 지연이 있다면 빈 결과는 판단 근거가 되지 못한다.
툴 계약에 넣을 것
비멱등 쓰기 툴을 설계한다면 먼저 같은 작업 의도를 안전하게 반복할 수 있는 계약을 만든다. 논문이 증명한 멱등성 키의 효과에는 조건이 있다. 서비스가 같은 키를 최대 한 번만 실행하고 반복 요청에는 원래 결과를 반환해야 한다. 중단된 배치 작업이라면 같은 키로 이어서 처리할 수 있어야 한다. 키를 인자로 받기만 하고 반복 실행을 막지 못한다면 이 보장은 성립하지 않는다.
쓰기 결과를 확인할 수 있는 상태 조회 경로도 계약에 명시한다. 운영자가 확인해야 할 항목은 다음과 같다.
| 계약 항목 | 확인할 동작 | 없거나 불명확할 때 |
|---|---|---|
| 멱등성 키 | 같은 작업 의도의 반복 요청이 같은 키로 처리되는가 | 재전달이나 재시도가 효과를 중복시킬 수 있다 |
| 결과 조회 | 쓰기의 실행 결과를 조회할 수 있는가 | 응답을 잃은 뒤 결과를 판별하기 어렵다 |
| 조회 반영 지연 | 확정된 효과가 언제 조회에 보이는가 | 빈 조회 결과를 잘못 믿을 수 있다 |
| 처리 중 요청의 시간 경계 | 원래 요청이 언제까지 확정될 수 있는가 | 기다린 뒤 조회하는 방식의 안전성을 판단할 수 없다 |
논문에서 즉시 조회로 결과를 판별할 수 있는 장애에서는 정확히 한 번 실행하라는 지시를 받은 상위 모델의 중복률이 0.5%였다. 반면 원래 요청이 처리 중인 장애에서는 같은 모델도 56%, 요청 재전달에서는 74%의 에피소드에서 중복을 냈다. 조회로 알 수 있는 영역과 툴 계약이 해결해야 하는 영역을 구분해야 하는 이유다.
논문의 실험에서 모든 쓰기에 멱등성 키를 제공하자 에이전트는 98%의 에피소드에서 키를 붙였고, 중복률은 28%에서 4%로 줄었다. 남은 중복은 첫 시도에 키를 붙이지 않았거나 재시도 때 키를 바꾼 경우였다. 툴을 제공하는 쪽은 키 지원을 선택적 장식으로 두지 말고, 반복 실행을 어떻게 처리하는지까지 계약으로 정해야 한다.
하네스에서 재시도를 통제할 것
하네스가 모델에게 보이지 않게 비멱등 쓰기를 재시도하면 모델은 중복 요청을 검토할 기회조차 없다. 논문에서는 투명한 클라이언트 재시도를 적용했을 때 정확히 한 번 성공한 비율이 72%에서 50%로 떨어졌다. 하네스가 재시도를 맡는다면 개별 호출마다 새 키를 만들지 말고 하나의 작업 의도에 키 하나를 고정해야 한다. 결과가 불명확한 쓰기도 기억해야 한다.
다음 판단 흐름은 하네스가 툴 계약을 보고 재시도를 허용할 범위를 나타낸다.
여기서 “조회로 판별할 수 있는가”는 조회 API가 존재하는지만 묻는 말이 아니다. 처리 중 요청과 조회 반영 지연까지 고려해야 한다. 논문은 처리 중 요청에 알려진 시간 상한이 없다면 조회만 사용하는 정책으로 정확히 한 번 실행을 보장할 수 없다고 증명한다. 알려진 짧은 상한이 있으면 그 시간이 지나고 조회하는 방법을 쓸 수 있지만, 기다리는 비용이 든다.
모델과 사용자에게 남길 상태
모델에게는 타임아웃을 실패 확정으로 취급하지 말고, 판별 가능한 결과를 확인하도록 지시할 수 있다. 하지만 결과를 판별할 수 없는 키 없는 쓰기에서는 모델의 추론만으로 작업 완료와 중복 방지를 동시에 보장할 수 없다. 이때는 추가 쓰기를 멈추고 결과가 불확실하다고 보고하는 편이 맞다.
완료 보고만 믿어서는 중복을 발견하기 어렵다. 논문의 중복 발생 에피소드 중 90%에서 에이전트는 작업을 완료했다고 보고했다. 운영 화면과 최종 응답에는 요청의 성공 여부뿐 아니라 결과를 확인하지 못한 쓰기가 있는지 드러내야 한다. 실무 점검의 순서는 분명하다. 툴에서 반복 실행을 안전하게 만들고, 하네스에서 키와 재시도를 관리하며, 모델이 끝내 알 수 없는 결과는 불확실한 상태로 전달한다.