AI 에이전트는 더 똑똑해질 필요가 없습니다. 멱등성을 갖춰야 합니다.
대부분의 프로덕션 AI 에이전트가 실패하는 이유는 추론 능력이 부족해서가 아닙니다. 바로 네트워크 오류 때문입니다.
모델은 올바른 도구를 선택하고, 올바른 세부 정보를 입력합니다. 하지만 그 결과로 고객에게 비용을 두 번 청구하게 됩니다.
이는 쓰기 권한이 있는(write-capable) 에이전트가 신뢰할 수 없는 네트워크 환경에서 작동하기 때문에 발생합니다.
- 요청 시간 초과(timeout).
- 연결 끊김.
- 프레임워크가 이미 완료된 단계를 재시도함.
읽기 전용(read-only) 에이전트에게 재시도는 비용이 들지 않습니다. 하지만 쓰기 권한이 있는 에이전트에게 재시도는 되돌릴 수 없는 두 번째 동작이 됩니다.
해결책은 멱등성(idempotency)입니다.
흔히 발생하는 실패 사례를 살펴보겠습니다:
- 에이전트가 송장을 보내는 함수를 호출합니다.
- 서비스가 송장을 생성합니다.
- 응답이 에이전트에 도달하기 전에 연결이 끊깁니다.
- 에이전트는 타임아웃을 감지하고 재시도합니다.
- 이제, 송장이 두 개가 생성되었습니다.
더 똑똑한 모델이라고 해서 이 문제를 해결할 수는 없습니다. 오히려 더 똑똑한 모델은 재시도를 더 공격적으로 수행하여 상황을 악화시킬 수도 있습니다.
Stripe와 같은 결제 시스템에서 힌트를 얻을 수 있습니다. 이들은 Idempotency-Key를 사용합니다. 서버는 첫 번째 요청의 결과를 저장합니다. 클라이언트가 동일한 키를 다시 보내면, 서버는 동작을 두 번 실행하는 대신 저장된 결과를 반환합니다.
AI 에이전트의 경우, 이 키를 의도(intent)로부터 도출해야 합니다.
무작위 ID를 사용하지 마세요. 도구 이름과 안정적인 파라미터의 해시(hash) 값을 사용하세요.
예시:
- Tool:
charge_customer - Params:
{customer_id: 42, amount: 500} - Key:
hash(tool + params)
에이전트가 정확히 동일한 결제를 재시도하면 키는 동일하게 유지됩니다. 시스템은 이를 인식하여 중복 결제를 방지합니다.
주의할 점이 있습니다. 키의 효용성은 '단일 동작'을 어떻게 정의하느냐에 달려 있습니다.
- 해시에 타임스탬프를 포함하면 재시도할 때마다 새로운 키가 생성됩니다. 이 경우 보호 기능이 작동하지 않습니다.
- LLM이 작성한 메시지 본문을 포함하면, 모델이 단어 하나만 바꿔도 새로운 키가 생성되어 중복 동작이 발생할 수 있습니다.
항상 고객 ID나 송장 ID와 같이 변하지 않는 안정적인 데이터를 기준으로 키를 생성하세요. 모델이 변경할 가능성이 있는 요소는 제외해야 합니다.
더 나은 프롬프트로 에이전트의 신뢰성을 높이려는 시도는 이제 그만두세요.
신뢰성이란 반복된 결정의 비용을 '0'으로 만드는 것입니다. 에이전트가 동일한 동작을 두 번 수행하더라도 아무런 문제가 발생해서는 안 됩니다.
Optional learning community: https://t.me/GyaanSetuAi