VAPI 음성 에이전트를 프로덕션 환경에서 운영 중인데, IVR을 탐색하고 상담원에게 연결된 직후 에이전트가 갑자기 침묵한다면 — 연결 전까지는 모든 것이 정상이었음에도 불구하고 에이전트가 사람의 말을 듣지 못하는 상황이라면 — 이는 프롬프트(Prompt)나 설정(Config)의 실수가 아니라 거의 항상 전송 계층(Transport-level)의 문제입니다. 이를 찾아내고 해결하는 방법을 소개합니다.

증상

에이전트가 전화를 걸고, DTMF 톤을 사용하여 전화 메뉴를 올바르게 탐색하며, 상담원에게 연결(Bridge)됩니다. 그 직후 에이전트가 침묵합니다. 에이전트의 목소리는 잘 들리지만, 에이전트가 사람의 말을 듣지 못합니다. 전화 제공업체(Twilio 등) 자체의 녹음본에서는 사람의 오디오가 명확하고 완전하게 들립니다. 하지만 VAPI 내부에서는 오디오가 파편화되어 있거나 아예 들리지 않습니다.

실제로 일어나고 있는 일

상대측에서 전화를 상담원에게 연결하는 순간, 오디오 전송(Audio transport)이 재연결됩니다. 이 재연결 직후, 인바운드 오디오(Inbound audio)가 깨진 조각 형태로 들어오기 시작합니다. 몇 밀리초(ms)마다 매끄러운 스트림이 흘러야 할 자리에 큰 공백이 생기는 것입니다. 전사기(Transcriber)가 사용할 수 있는 데이터를 받지 못하므로, 에이전트는 아무도 말하지 않는 것처럼 동작합니다. 오디오는 전화 계층(Telephony layer)까지는 잘 도달하지만, 재연결 이후 파이프라인(Pipeline) 내부에서 끊어집니다. 이것이 핵심 결함입니다. 즉, 에이전트가 누군가를 "무시"하는 것이 아니라, 핸드오프(Hand-off) 시점의 전송 재연결(Transport reconnect) 문제입니다.

진단 방법 (추측하지 말고 확인하세요)

1. 실패한 통화 로그를 가져와 한 줄씩 읽어보세요. 전환(Transfer) 시점에 전송 재연결(Transport reconnect) 이벤트가 있는지 확인하고, 그 직후에 인바운드 오디오 타임스탬프(Timestamps)가 불규칙해지는지 체크하세요.
2. 제어 가능한 환경에서 동일한 패턴을 재현해 보세요. 메뉴를 탐색하고, 상담원에게 연결된 후 대화를 나누어야 하는 에이전트를 구성합니다. 현재 사용 중인 전송 경로(Transport path)로 한 번 실행해 보고, 다른 전송 경로로도 한 번 실행해 보세요.
3. 비교하세요. 만약 한 전송 경로에서는 핸드오프가 깨지고 다른 경로에서는 정상적으로 작동한다면, 결함의 원인이 VAPI 전체나 프롬프트가 아닌 특정 전송 구간(Transport leg)에 있음을 격리(Isolate)할 수 있습니다.

해결 방법

• 동일하게 실패하는 흐름을 가져온 번호(Imported number) 대신, VAPI 네이티브 경로(VAPI-native path) 또는 깨끗한 SIP 트렁크(SIP trunk) 상의 근단 번호(Near-end number)로 테스트해 보세요. 만약 네이티브 경로에서 전환 후 에이전트가 상대방의 말을 들을 수 있다면, 작동하는 경로를 찾은 것입니다.
• 현재 설정에서 해당 구간(Leg)의 오디오 처리(Audio processing) 가능성을 배제하세요. 배경 소음 필터링(Background noise filtering)을 완전히 끄고 한 번 실행해 보십시오. 손상된 인바운드 오디오(Inbound audio)는 때때로 파이프라인(Pipeline)의 바로 그 부분에서 발생합니다.
• 만약 전송 계층(Transport-level) 문제임이 확인되었다면, 두 개의 통화 ID(실패한 통화와 깨끗하게 재현된 통화)와 함께 한 줄의 설명을 덧붙여 플랫폼 측에 문제를 제기하세요: "원단(Far-end) 브릿지(Bridge) 이후, 전송(Transport)이 재연결되면서 이 전송 경로에서는 인바운드 오디오가 끊기지만 네이티브 경로에서는 끊기지 않습니다." 이는 깔끔하고 재현 가능한 보고서가 되어 실제 해결책을 이끌어낼 수 있습니다.

핵심 요약 (The takeaway)

음성 에이전트가 특히 전환(Transfer)
_직후_에 침묵한다면, 프롬프트(Prompt)를 튜닝하는 것을 멈추세요. 프롬프트는 괜찮습니다. 모든 전송(Transport)에서 발생하는지 아니면 현재 사용 중인 특정 전송에서만 발생하는지 격리(Isolate)하십시오. 그 단 한 번의 비교가 실제 해결책이 어디에 있는지 알려줍니다. 운영 환경에서 발생하는 대부분의 "에이전트가 응답을 중단함" 사고는 지능의 실패가 아니라 전송 재연결(Transport reconnects) 문제입니다.

자주 묻는 질문 (FAQ)

왜 IVR 전환 후 VAPI 에이전트가 침묵하나요?
보통 통화가 실제 사람에게 브릿지(Bridge)될 때 오디오 전송(Audio transport)이 재연결되며, 재연결 후 인바운드 오디오가 파편화되어 도착하기 때문입니다. 따라서 전사기(Transcriber)가 아무것도 받지 못하게 되고 에이전트가 듣지 못하는 것처럼 보이게 됩니다.

이것이 프롬프트 문제인가요?
아니요. 전환 전까지 에이전트가 정상 작동했다면 프롬프트는 문제가 없습니다. 이것은 핸드오프(Hand-off) 시 발생하는 전송 계층(Transport-level)의 오디오 문제입니다.

VAPI 자체의 문제가 아니라 전송 문제임을 어떻게 확인하나요?
직접 제어할 수 있는 환경에서 동일한 전환 흐름을 다시 구축하고 두 가지 다른 전송 경로(Transport paths)를 통해 실행해 보세요. 한 곳에서는 끊기고 다른 곳에서는 정상이라면, 해당 전송 구간(Transport leg)이 원인입니다.

이런 운영 환경의 VAPI 음성 에이전트 문제를 누가 해결할 수 있을까요?
단순히 퀵스타트(Quickstart) 가이드를 따르는 사람이 아니라, 전송 계층(Transport level)에서 통화 로그(Call logs)를 읽을 수 있고 통제된 재현(Controlled reproductions) 환경을 구축할 수 있는 엔지니어입니다. 이러한 운영 환경의 음성 에이전트 디버깅(Debugging)이 바로 제가 하는 일입니다. 저에게 연락하시려면 https://www.linkedin.com/in/assadua/를 이용해 주세요.