응답 유실 시 AI 에이전트가 중복 결제를 유발할 수 있습니다
AI 에이전트가 카드 결제를 위해 도구를 호출했는데 네트워크 문제로 응답이 유실된다면, 에이전트는 제대로 대응하지 못하고 실패합니다. 에이전트는 인지하지 못한 채 고객에게 중복 결제를 하게 됩니다.
돈은 이미 이동했습니다. 하지만 에이전트는 "ok"라는 응답을 듣지 못했습니다. 에이전트는 모든 재시도 루프가 그렇듯 다시 시도합니다. 동일한 프롬프트와 동일한 인자(arguments)를 사용하여 다시 시도하며, 이로 인해 두 번째 결제가 발생합니다.
재시도는 단순한 네트워크 이벤트가 아닙니다. 이미 발생했을지도 모르는 부수 효과(side effect)에 대한 결정입니다.
backoff나 jitter와 같은 표준 재시도 도구는 재시도를 '정중하게' 만들어 줄 뿐, 중복 결제를 막아주지는 못합니다.
멱등성 원장(idempotency ledger)이 필요합니다. 이는 고유 키를 사용하여 작업이 최대 한 번만 수행되도록 보장합니다.
도구 호출이 실패하는 방식에는 두 가지가 있습니다:
- 요청이 유실됨. 작업이 전혀 실행되지 않음. 재시도가 안전함.
- 응답이 유실됨. 작업이 이미 실행됨. 재시도 시 중복 발생.
에이전트 입장에서는 이 두 가지가 동일해 보입니다. 둘 다 타임아웃이나 연결 끊김처럼 보이기 때문입니다.
결제, 이메일 발송, 환불과 같이 부수 효과를 동반하는 도구의 경우, 단순한 재시도에 의존해서는 안 됩니다. 반드시 멱등성 키(idempotency key)를 사용해야 합니다.
해결 방법:
- 도구에 태그를 지정하세요. 어떤 도구가 되돌릴 수 없는 부수 효과를 가지는지 식별해야 합니다.
- 결정론적 키(deterministic keys)를 사용하세요. 워크플로우 ID, 단계, 인자를 기반으로 안정적인 키를 생성하십시오. LLM이 인자를 변경하기 전에 이 작업을 수행해야 합니다.
- 제공업체 키를 사용하세요. Stripe를 사용한다면 해당 서비스의 멱등성 키를 전달하십시오. 결제를 중단하려면 제공업체가 중복 요청임을 인식할 수 있어야 합니다.
- 자체 도구를 위한 원장을 구축하세요. 직접 관리하는 부수 효과에 대해서는 고유 제약 조건(unique constraint)이 있는 데이터베이스 테이블을 사용하십시오. 이를 통해 시스템이 다시 시도하기 전에 결과를 기록하도록 보장할 수 있습니다.
"at-least-once(최소 한 번 보장)"를 "exactly-once(정확히 한 번 보장)"로 착각하지 마세요. 분산 시스템에서 "exactly-once"는 at-most-once(최대 한 번 보장) 전달과 at-least-once 재시도, 그리고 중복 제거 원장을 결합하여 달성할 수 있습니다.
쓰기(write) 작업을 읽기(read) 작업처럼 취급하지 마세요. 읽기 재시도는 비용이 들지 않지만, 쓰기 재시도는 비용을 발생시킵니다.
Source: https://dev.to/0012303/your-ai-agent-will-double-charge-on-a-lost-response-5eed
Optional learning community: https://t.me/GyaanSetuAi