AI 상담 전화 대기 시간이 어디에서 발생하는 걸까요?
전화는 먼저 통신망과 SIP/PBX 경로를 거쳐 음성 신호가 처리된 후, 시스템은 사용자가 말을 마쳤는지 판단하고, 모델을 통해 기업 도구를 호출합니다. 마지막으로, 받은 응답을 음성 신호로 변환하여 전화로 전송합니다. CRM 검색이나 작업 생성 시 대기 시간이 발생하면, 도구의 응답 시간에도 지연이 발생합니다. 모델의 첫 번째 토큰만 분석하면, 전화 사용자가 실제로 경험한 전체 경로를 파악하지 못합니다.
AI 음성 고객 서비스의 전체 흐름 분석 및 지연 요소 파악| 단계 | 측정 시작 및 종료 | 일반적인 위험 |
|---|
| 전화 통신 | 전화 통화 음성으로 진입 및 종료 음성 플랫폼 | 전화망 라우팅, 인코딩/디코딩, 네트워크 지연 및 패킷 손실 |
| 경계선 판단 | 사용자가 말을 멈추고 시스템이 종료를 확인하는 시점까지 | 너무 늦게 기다리거나 너무 일찍 중단하는 경우 |
| 예시 답변 | 유효한 입력을 통해 재생 가능한 콘텐츠를 생성 | 긴 문맥, 모델 선택, 복잡한 추론 |
| 도구 요청 | API를 통해 사용 가능한 결과를 얻습니다. | 기업 시스템의 시간 초과, 재시도 및 대기 처리 |
| 오디오 재생 | 텍스트나 음성이 전화로 전송되어 재생을 시작합니다. | 합성 버퍼, 첫 번째 패킷 대기 및 재생 취소 |
VAD는 "말하고 있는지"를 판단하는 데 사용되며, 경계선 판단은 "말을 마쳤는지"를 확인하는 데 사용됩니다.
서버 기반 VAD는 일반적으로 음량과 침묵 시간을 기준으로 음성 시작 및 종료를 판단합니다. 의미 기반 VAD는 음성의 의미가 완전히 표현되었는지 여부를 추가로 추정합니다. 너무 오래 대기하면 잘리더라도, 반대로 너무 빨리 반응하면 "음... 제가 이걸 바꿔야 하는데"와 같이 의미가 완전히 전달되지 않은 부분을 잘릴 수 있습니다. 각 파라미터는 전반적으로 동일한 값을 사용하기 어렵습니다. 이름, 주소, 코드 등과 같이 개별적인 정보에 필요한 침묵 허용 시간은 다릅니다.
"버지 인"은 통화 중 다른 사람의 참여를 허용하는 기능이며, 이는 통화 순서를 종료하는 것과는 다른 개념입니다.
"배에 탑승" 기능은 AI가 음성 재생 중 상대방의 말을 끼워 넣고 원래 답변을 중단할 수 있도록 합니다. 이는 정보 수정, 이미 알고 있는 내용 건너뛰기, 메뉴 단축 등의 용도로 활용될 수 있습니다. "배에 탑승" 기능은 시스템이 상대방의 말을 듣고 "말을 마쳤다"라고 판단하는 것과는 별개의 문제입니다. 일반적으로 대화 중 끼어드는 것은 허용되지만, 녹음 안내, 필요한 정보 공개, 중요한 항목 확인 등에 대한 중단은 기업 프로세스와 법률 요구 사항에 따라 개별적으로 결정해야 합니다. "배에 탑승" 기능을 전역적으로 끄면 대화가 어색해질 수 있으며, 전역적으로 켜면 필요한 내용이 제대로 재생되지 않을 수도 있습니다.
단순히 평균 지연 시간을 언급하는 것뿐만 아니라, p50, p95, 그리고 오류 발생 빈도를 함께 고려해야 합니다.
평균치는 극히 느린 응답 또는 매우 빠른 응답의 경우에 왜곡될 수 있습니다. p50은 일반적인 통화 경험을 나타내고, p95는 더 나쁜 경험이지만 여전히 흔하게 발생하는 경우를 나타냅니다. 또한, 사용자가 말을 멈춘 시점부터 첫 응답까지, 도구 완료 시간, 오류 발생, 오류 대기, 그리고 인터뷰 미성립 등의 정보를 기록합니다. 각 샘플은 작업, 네트워크, 언어, 그리고 기업 API 호출 여부와 같은 정보를 함께 기록해야 합니다. 그렇지 않으면 다양한 상황이 혼합되어 문제의 원인을 파악하기 어려워집니다.
지연 및 교대 근무는 함께 기록해야 합니다.| 관찰 항목 | 사건 정의 | 용도 판별 |
|---|
| 첫 번째 답변 지연 | 사용자가 응답을 듣기 전까지 진행 단계가 완료될 때까지 | 단계별, 모델, 그리고 합성 대기 구분 |
| 기기가 준비될 때까지 기다립니다. | API를 통해 얻은 결과가 사용 가능 상태 | 기업 시스템 또는 제3자 측의 병목 지점을 파악 |
| 오류로 인해 내용이 잘렸습니다. | 사용자가 말을 다 마치기도 전에 답변을 시작했습니다. | VAD, 라인 및 열 전략 조정 |
| 오류 발생 대기 | 사용자가 말을 마쳤지만 시스템은 계속해서 응답하지 않았습니다. | 종료 확인, 시간 초과 및 도구 상태 확인 |
| 성공적으로 추가 | 사용자가 입을 열고 답변을 하면, 기존 답변은 중단되고 새로운 입력만 유지됩니다. | 재생 중단 및 맥락 일치성 확인 |
실제 전화 테스트에는 소음, 반향, 억양, 긴 텍스트 필드 등을 포함해야 합니다.
웹사이트용 마이크가 조용한 사무실 환경에서 테스트되었더라도, 휴대폰, 차량, 이어폰, 블루투스 이어폰, 또는 일반 전화 통화와 같은 환경에서는 결과가 달라질 수 있습니다. 테스트는 배경 소음, 반향, 신호 불안정, 빠른/느린 속도의 음성, 일반적인 억양, 숫자, 영수 코드, 그리고 긴 주소 등을 포함해야 합니다. 중요한 항목에 대해서는 단순히 정확성을 확인하는 것을 넘어, 시스템이 내용을 재구성하고, 사용자가 수정할 수 있도록 하며, 불확실한 경우에는 테스트를 중단하는 것이 목표입니다.
오랫동안 통화가 연결되지 않을 때, 굳이 "성공"이라고 말하며 침묵을 채우지 마세요.
CRM, ERP 또는 주문 처리 API는 몇 초에서 수초까지 시간이 걸릴 수 있으며, 비동기 프로세스로 진행될 수 있습니다. 시스템은 간결한 진행 상황을 제공하여 답답함을 줄일 수 있지만, 결과가 반환되기 전에는 "완료"라고 말할 수 없습니다. 통화 시간 제한을 초과하면, 확인 상태, 수동 처리 또는 후속 알림을 설정하고, 고유 식별자를 사용하여 중복 처리를 방지해야 합니다. 지연을 최적화하는 것은 결과의 정확성을 희생하는 것이므로, 오류를 더 빨리 알리는 것일 뿐입니다.
"3초"는 GoGoCha가 공개하는 SLA(서비스 수준 합의)의 목표일 뿐입니다.
GoGoCha의 공개된 사례는 전화 기반 및 즉시 배달 워크플로우를 보여주지만, 엔드 투 엔드 지연 분포, 통신 환경, 통화 샘플 또는 SLA에 대한 공개된 정보는 제공하지 않습니다. 동일한 이벤트에 대한 정의와 실제 측정 없이, 제품 설계 목표를 이미 달성된 서비스 수준으로 명시하는 것은 적절하지 않습니다. 기업 프로젝트는 자체 PBX/SIP, API 및 피크 조건에서 p50, p95 및 실패 샘플을 재구성해야 합니다.
