본문으로 건너뛰기
BringTalk
프로그램▼
워크샵2일 — 직접 만들어보며 감을 잡습니다POC프로젝트★ 대부분 여기서 시작6주 — 빠르게 데이터로 검증합니다AX프로젝트검증한 것을 전사의 시스템으로
콘솔Alpha
인더스트리▼
자동차광고 리드, 시승, 견적, 정비 예약까지 콜을 매출 흐름으로 연결합니다.인테리어·가구상담 예약, 견적 일관성, 설치 후 CS를 한 흐름으로 묶습니다.보험 GA리드 후속, 보장 안내, 갱신 콜을 컴플라이언스 기준으로 운영합니다.금융·캐피탈납부 일정, 신청 상태, 동의 확인 콜을 신뢰 기반으로 처리합니다.통신·인터넷해지 방어, 장애 접수, 요금제 상담을 반복 가능한 운영으로 만듭니다.여행·항공·호텔변경, 지연, 리워드 문의를 고객 맥락에 맞춰 이어갑니다.법무·회계·세무첫 상담 접수와 일정·서류 안내로 전문가 시간을 회수합니다.의료·치과예약, 시술 상담, 진료 외 시간 응대를 놓치지 않고 받습니다.부동산 중개매물 매칭과 임장 일정 조율로 거래 기회를 지킵니다.교육·유학·학원상담 신청 후속과 등록 전환을 부모·학생 양쪽 톤으로 응대합니다.물류·렌탈·모빌리티배송 추적, 렌탈 일정, 차량 상태 조회 콜을 자동화합니다.B2G·공공민원 1차 분류와 인증·정책 안내로 상담 인력을 비웁니다.
솔루션▼
Vapi공식 파트너Global Top 3 Voice AI Platform
블로그
상담 신청
프로그램
워크샵POC프로젝트AX프로젝트
콘솔Alpha
인더스트리
자동차인테리어·가구보험 GA금융·캐피탈통신·인터넷여행·항공·호텔법무·회계·세무의료·치과부동산 중개교육·유학·학원물류·렌탈·모빌리티B2G·공공
솔루션
Vapi
블로그
상담 신청
설계

음성 AI 재시도 설계 — retryOnFail, idempotency key, onError

음성 AI가 요청 처리에 실패했을 때 단순 재시도는 이중 실행 위험이 있습니다. retryOnFail, idempotency key, onError=continueErrorOutput 세 옵션을 함께 설계하는 방법을 설명합니다.

Moon Kim·2026년 9월 3일·3분 읽기

목차

  1. 재시도가 안전한 경우와 그렇지 않은 경우
  2. idempotency key로 중복 실행을 막는 방법
  3. retryOnFail 설정
  4. onError=continueErrorOutput
  5. 이 방법이 통하지 않는 경우

음성 AI가 고객 요청을 처리하다가 실패했을 때, 바로 재시도하면 위험한 경우가 있습니다. 재시도가 같은 동작을 두 번 만들어 낼 수 있는 상황이라면 설계가 달라집니다. 요청의 종류에 따라 전략이 달라지는 거고요.

재시도가 안전한 경우와 그렇지 않은 경우

조회 요청은 몇 번 반복해도 결과가 달라지지 않습니다. 예약 생성이나 결제 처리처럼 상태를 변경하는 요청은 다릅니다. 재시도하면 같은 작업이 두 번 실행될 수 있습니다. 이중 실행이 발생하면 데이터가 일관성을 잃습니다.

에이전트가 오류를 받았을 때 처리가 실패했는지, 처리는 됐는데 응답만 못 받은 것인지를 알 수 없는 경우가 많습니다. 네트워크 타임아웃이나 일시적 서버 오류가 그런 상황이거든요. 성공 응답을 받지 못했다고 해서 서버 처리가 실패한 것은 아닙니다. 구분 없이 재시도하면 이중 예약이나 중복 결제가 발생합니다.

idempotency key로 중복 실행을 막는 방법

retryOnFail을 켜 두기만 하고 멱등성 처리를 하지 않으면 상태 변경 API에서 중복 실행 위험이 생깁니다. 그래서 idempotency key를 씁니다.

멱등성 키는 같은 요청을 식별하는 고유 값입니다. 요청마다 키를 함께 전달하면, 서버는 이미 처리한 키가 다시 오면 같은 결과를 돌려주고 실제 작업은 다시 수행하지 않습니다. 고객 요청 하나에 키 하나. 이 키를 재시도 전체에 걸쳐 씁니다. 재시도마다 새 키를 만들면 중복 방지 효과가 없습니다. 키 생성 시점을 요청 시작 시점으로 고정하고, 타임아웃이나 오류가 나도 같은 키를 유지해야 합니다.

retryOnFail 설정

retryOnFail은 에이전트가 도구 호출에 실패했을 때 자동으로 재시도할지 여부를 결정하는 설정입니다. 활성화하면 일시적인 네트워크 오류나 타임아웃에서 자동으로 복구합니다. 재시도 횟수와 간격도 함께 설정할 수 있고요. 연결 오류처럼 일회성 실패에서는 효과가 있습니다.

retryOnFail과 idempotency key는 함께 설계해야 합니다. 멱등성을 지원하지 않는 API라면 retryOnFail보다 idempotency key 설계를 먼저 끝냅니다.

음성 AI 재시도 설계 — retryOnFail · idempotency key · onError 옵션 비교
음성 AI 재시도 설계 — retryOnFail · idempotency key · onError 옵션 비교

onError=continueErrorOutput

오류가 발생했을 때 에이전트가 대화를 어떻게 이어 가는지도 미리 설계해야 합니다. 오류 처리를 나중에 추가하려면 전체 흐름을 다시 짜야 하는 경우가 생깁니다. onError=continueErrorOutput은 도구 오류 정보를 에이전트가 다음 응답에서 활용할 수 있도록 전달하는 옵션입니다.

이 설정이 없으면 에이전트는 오류가 발생했다는 사실은 알지만 어떤 오류인지 알 수 없습니다. 오류 종류를 모르면 고객에게 상황에 맞는 안내를 할 수 없습니다. continueErrorOutput을 켜면 에이전트가 오류 내용을 받아 적절한 안내를 합니다. 타임아웃이면 "잠시 후 다시 시도하겠습니다"로 넘기면 되고, 권한 오류는 다른 경로로 연결합니다. 오류 유형에 따른 응답 설계가 고객 경험에 직결됩니다.

이 방법이 통하지 않는 경우

멱등 키를 붙여도 막히지 않는 자리가 있습니다.

하위 시스템이 멱등 키를 받지 않는 경우가 가장 흔합니다. 요청에 키를 실어 보내도 서버가 그 값을 읽지 않으면 중복 요청을 구분할 방법이 없습니다. 이때는 재시도 전에 조회로 상태를 확인하는 절차를 따로 넣습니다.

키에 유효기간이 걸려 있는 경우도 있습니다. 서버가 처리한 키를 일정 시간만 기억한다면, 그 시간을 넘겨 들어온 재시도는 만료된 키를 들고 온 새 요청으로 처리됩니다. 재시도 간격을 길게 잡을수록 이 틈이 벌어지고요.

체인으로 얽힌 시스템이 제일 까다롭습니다. 앞단 API를 멱등으로 만들어도 뒤에 이어지는 호출이 그렇지 않으면 결국 그쪽에서 중복이 생깁니다. 체인 전체를 놓고 봐야 합니다.

세 옵션을 각각 독립적으로 설정할 수 있지만, 상태 변경 요청을 처리하는 에이전트라면 세 가지를 묶어서 설계해야 실무에서 안전합니다. retryOnFail만 켜고 나머지를 나중으로 미루면 장애 상황에서 빈틈이 드러납니다. 음성 AI에서 낮은 확신도 상황을 처리하는 설계 방법은 음성 AI 낮은 확신도 에스컬레이션 설계에서 이어집니다.

  • 조회 API부터 연결하고, 상태 변경 API는 idempotency key 설계 후에 추가합니다.
  • onError=continueErrorOutput은 오류 유형별 응답 분기를 가능하게 합니다.

재시도가 안전한지를 먼저 따져야 합니다. 멱등성 처리가 있어야 재시도가 의미가 있습니다.

이 글 공유하기
XLinkedIn

READ NEXT

함께 보면 좋은 글

설계

전화 예약 자동화, 어디까지 가능한가

2026년 9월 2일
설계

전통 ARS, 보이는 ARS, 디지털 ARS, 음성 AI — 분기 로직이 다른 네 방식

2026년 9월 1일
설계

전화 응대, 사람이 받아야 하는 자리는 어디 남았나

2026년 8월 31일
우리 콜에서는?

같은 전환을 한국어 콜 운영에서 — 6주 안에 숫자로 확인하세요.

6주 POC 상담Vapi 도입 상담
BringTalk

콜 운영에 들어가 음성 AI 에이전트를 6주 만에 실험 가능한 시스템으로 구축합니다.

탐색
  • 브링톡 콘솔 Alpha
  • 인더스트리
  • Vapi 파트너십
  • 블로그
프로그램
  • 워크샵
  • POC프로젝트
  • AX프로젝트
연락
  • contact@bringtalk.ai
  • 070-5275-3800
  • 상담 신청
개인정보처리방침이용약관개인정보 문의
© 2026 BringTalk · Voice Agent StudioEvery call becomes revenue.