Voice AI 장애 복구 설계: 통화가 끊기기 전에 정해야 할 5가지
Voice AI 장애 복구는 서버 이중화가 아니라 고객의 대화 맥락을 잃지 않는 운영 설계입니다.
Twilio가 2026년 6월 14일 공개한 cross-region voice disaster recovery 글은 Voice AI 운영팀에 중요한 질문을 던집니다. 음성 에이전트가 “말을 잘하는지”만 볼 것이 아니라, 통화 경로가 흔들릴 때 어떤 순서로 복구되는지 먼저 정해야 합니다.
장애 복구는 인프라 문제가 아니라 고객 경험 문제입니다
Voice AI는 웹 챗봇보다 장애의 체감 속도가 빠릅니다. 응답이 몇 초 멈추면 고객은 “시스템이 생각 중”이 아니라 “통화가 죽었다”고 판단합니다.
Voice AI의 장애 복구 목표는 완벽한 무중단이 아니라, 고객이 같은 설명을 반복하지 않게 만드는 것입니다.
Twilio의 글은 voice call resilience를 지역 단위로 설계해야 한다고 설명합니다. BringTalk 관점에서는 여기에 STT, LLM, TTS, CRM 조회, 상담원 전환까지 포함한 운영 모델이 붙어야 합니다.
먼저 정해야 할 5가지 결정
장애 복구 설계는 “나중에 자동화”가 아니라 go-live 전에 문서화해야 하는 운영 결정입니다.
- Primary region과 secondary region: 통화가 어느 지역에서 시작되고, 실패 시 어디로 이동하는지 정합니다.
- Health check 기준: SIP 응답, media path, STT/TTS 지연, LLM 오류를 각각 어떤 신호로 볼지 분리합니다.
- State handoff 범위: 고객 식별자, 마지막 의도, CRM 조회 결과, 상담 이력 중 무엇을 넘길지 정합니다.
- Human escalation 조건: 자동 복구보다 상담원 전환이 나은 시점을 정의합니다.
- Post-incident evidence: 장애 후 transcript만 볼지, 경로 전환 로그와 원인 태그까지 볼지 정합니다.
통화 상태는 “저장”보다 “재개” 관점으로 봐야 합니다
DR 문서에서 가장 자주 빠지는 항목은 call state입니다. 지역 전환은 성공했는데 고객이 다시 이름, 문의 내용, 예약 번호를 말해야 한다면 운영 관점에서는 복구가 아닙니다.
복구 우선순위 예시
1. 통화 연결 유지 또는 빠른 재발신
2. 고객 식별과 마지막 intent 유지
3. CRM / 예약 / 주문 상태 재조회
4. 동일 안내 반복 방지
5. 상담원 전환 시 요약 전달
이때 Zero Retention 원칙도 함께 설계해야 합니다. 외부 LLM 서버에 PII를 남기지 않으면서도, 내부 CRM과 세션 저장소에는 필요한 최소 상태를 짧게 유지하는 구조가 필요합니다.
Fallback과 Disaster Recovery는 다릅니다
Fallback은 대화가 빗나갔을 때의 회복입니다. Disaster Recovery는 통화 경로, 지역, 공급자, 저장소 중 하나가 흔들릴 때의 회복입니다.
