음성 AI 재시도 설계 — retryOnFail, idempotency key, onError
음성 AI가 요청 처리에 실패했을 때 단순 재시도는 이중 실행 위험이 있습니다. retryOnFail, idempotency key, onError=continueErrorOutput 세 옵션을 함께 설계하는 방법을 설명합니다.
음성 AI가 고객 요청을 처리하다가 실패했을 때, 바로 재시도하면 위험한 경우가 있습니다. 재시도가 같은 동작을 두 번 만들어 낼 수 있는 상황이라면 설계가 달라집니다. 요청의 종류에 따라 전략이 달라지는 거고요.
재시도가 안전한 경우와 그렇지 않은 경우
조회 요청은 몇 번 반복해도 결과가 달라지지 않습니다. 예약 생성이나 결제 처리처럼 상태를 변경하는 요청은 다릅니다. 재시도하면 같은 작업이 두 번 실행될 수 있습니다. 이중 실행이 발생하면 데이터가 일관성을 잃습니다.
에이전트가 오류를 받았을 때 처리가 실패했는지, 처리는 됐는데 응답만 못 받은 것인지를 알 수 없는 경우가 많습니다. 네트워크 타임아웃이나 일시적 서버 오류가 그런 상황이거든요. 성공 응답을 받지 못했다고 해서 서버 처리가 실패한 것은 아닙니다. 구분 없이 재시도하면 이중 예약이나 중복 결제가 발생합니다.
idempotency key로 중복 실행을 막는 방법
retryOnFail을 켜 두기만 하고 멱등성 처리를 하지 않으면 상태 변경 API에서 중복 실행 위험이 생깁니다. 그래서 idempotency key를 씁니다.
멱등성 키는 같은 요청을 식별하는 고유 값입니다. 요청마다 키를 함께 전달하면, 서버는 이미 처리한 키가 다시 오면 같은 결과를 돌려주고 실제 작업은 다시 수행하지 않습니다. 고객 요청 하나에 키 하나. 이 키를 재시도 전체에 걸쳐 씁니다. 재시도마다 새 키를 만들면 중복 방지 효과가 없습니다. 키 생성 시점을 요청 시작 시점으로 고정하고, 타임아웃이나 오류가 나도 같은 키를 유지해야 합니다.
retryOnFail 설정
retryOnFail은 에이전트가 도구 호출에 실패했을 때 자동으로 재시도할지 여부를 결정하는 설정입니다. 활성화하면 일시적인 네트워크 오류나 타임아웃에서 자동으로 복구합니다. 재시도 횟수와 간격도 함께 설정할 수 있고요. 연결 오류처럼 일회성 실패에서는 효과가 있습니다.
retryOnFail과 idempotency key는 함께 설계해야 합니다. 멱등성을 지원하지 않는 API라면 retryOnFail보다 idempotency key 설계를 먼저 끝냅니다.

onError=continueErrorOutput
오류가 발생했을 때 에이전트가 대화를 어떻게 이어 가는지도 미리 설계해야 합니다. 오류 처리를 나중에 추가하려면 전체 흐름을 다시 짜야 하는 경우가 생깁니다. onError=continueErrorOutput은 도구 오류 정보를 에이전트가 다음 응답에서 활용할 수 있도록 전달하는 옵션입니다.
이 설정이 없으면 에이전트는 오류가 발생했다는 사실은 알지만 어떤 오류인지 알 수 없습니다. 오류 종류를 모르면 고객에게 상황에 맞는 안내를 할 수 없습니다. continueErrorOutput을 켜면 에이전트가 오류 내용을 받아 적절한 안내를 합니다. 타임아웃이면 "잠시 후 다시 시도하겠습니다"로 넘기면 되고, 권한 오류는 다른 경로로 연결합니다. 오류 유형에 따른 응답 설계가 고객 경험에 직결됩니다.
이 방법이 통하지 않는 경우
멱등 키를 붙여도 막히지 않는 자리가 있습니다.
하위 시스템이 멱등 키를 받지 않는 경우가 가장 흔합니다. 요청에 키를 실어 보내도 서버가 그 값을 읽지 않으면 중복 요청을 구분할 방법이 없습니다. 이때는 재시도 전에 조회로 상태를 확인하는 절차를 따로 넣습니다.
키에 유효기간이 걸려 있는 경우도 있습니다. 서버가 처리한 키를 일정 시간만 기억한다면, 그 시간을 넘겨 들어온 재시도는 만료된 키를 들고 온 새 요청으로 처리됩니다. 재시도 간격을 길게 잡을수록 이 틈이 벌어지고요.
체인으로 얽힌 시스템이 제일 까다롭습니다. 앞단 API를 멱등으로 만들어도 뒤에 이어지는 호출이 그렇지 않으면 결국 그쪽에서 중복이 생깁니다. 체인 전체를 놓고 봐야 합니다.
세 옵션을 각각 독립적으로 설정할 수 있지만, 상태 변경 요청을 처리하는 에이전트라면 세 가지를 묶어서 설계해야 실무에서 안전합니다. retryOnFail만 켜고 나머지를 나중으로 미루면 장애 상황에서 빈틈이 드러납니다. 음성 AI에서 낮은 확신도 상황을 처리하는 설계 방법은 음성 AI 낮은 확신도 에스컬레이션 설계에서 이어집니다.
- 조회 API부터 연결하고, 상태 변경 API는 idempotency key 설계 후에 추가합니다.
- onError=continueErrorOutput은 오류 유형별 응답 분기를 가능하게 합니다.
재시도가 안전한지를 먼저 따져야 합니다. 멱등성 처리가 있어야 재시도가 의미가 있습니다.
