13. 고객 사례: 실시간 음성 AI 에이전트

실시간 음성 에이전트의 품질은 모델 성능이 아니라 사용자가 말을 멈춘 순간부터 에이전트가 말을 시작하기까지의 지연과, 언제 말하고 언제 멈출지의 판단이 결정합니다. FDE가 고객의 콜센터·예약·상담 시나리오에서 "어디가 느리고 어디서 사용자를 끊는가"를 짚어 내는 언어가 여기서 나옵니다.

학습 동기: 이 장을 읽으면 음성 에이전트를 STT·LLM·TTS 파이프라인으로 그려 단계별 지연 예산을 매기고, 말 끊김·끼어들기·긴 침묵·느린 도구 호출 같은 현장 불만을 원인 단계까지 추적해 해법을 고를 수 있습니다.
선행 가정: LLM이 토큰을 하나씩 스트리밍으로 내보낸다는 2.15, 도구를 호출하는 함수 호출 6.2의 개념을 알고 있으면 충분합니다. 음성 신호 처리 지식은 필요하지 않으며, 지연은 밀리초(ms) 단위의 덧셈과 백분위 읽기만 사용합니다.

13.1 실시간 음성 AI 에이전트 설계

원문: Design a Real-Time Voice AI Agent

음성 에이전트는 마이크와 스피커를 단 챗봇이 아니라, 1초 안팎의 시간 예산 안에서 오디오를 끊임없이 흘려보내는 스트리밍 시스템입니다. 이 절은 2026년 9월 글 기준으로 전체 설계를 한 번에 훑고, 13.2 이후의 절이 각 부분을 깊이 다루는 순서를 잡아 줍니다.

13.1.1 요구사항과 핵심 지표

음성 AI 에이전트(Voice AI Agent)는 음성 + AI + 에이전트의 합입니다. 입력과 출력이 소리이고, 이해와 판단은 LLM이 하며, 주문 조회·예약·구독 해지·상담원 연결 같은 행동은 도구(tool) 호출로 수행합니다(6.2 참조). 고객 지원 전화, 식당 예약, 드라이브스루 주문, 어학 튜터, 약속 확인 아웃바운드 전화가 대표 사례입니다.

실시간(Real-Time)의 기준은 사람의 대화입니다. 사람은 상대가 말을 멈춘 뒤 대략 200~500ms 안에 답하고, 1초를 넘기면 느리다고 느끼며, 2~3초가 되면 "여보세요?"가 나옵니다. 그래서 목표는 사용자가 말을 마친 뒤 약 800ms 안에 에이전트가 말을 시작하는 것이고, 이 숫자 하나가 설계 결정 대부분을 끌고 갑니다.

텍스트 챗봇과 다른 어려움은 일곱 가지입니다.

요구사항은 다음과 같이 나뉩니다. 기능 요구는 음성 대화, 같은 통화 안의 다중 턴 기억, 도구 실행, 끼어들기 허용, 전화와 앱·브라우저 겸용, 상담원 이관, 다국어(선택)입니다. 비기능 요구는 지연(말 시작 800ms, 최대 1.5초), 가용성 99.9% 이상, 수천 동시 통화, 문장을 반쯤 끝내거나 이유 없이 침묵하지 않는 신뢰성, 분당 비용, 음성이라는 개인정보의 보호, 통화별 단계 추적 가능성입니다.

가장 중요한 지표는 음성-대-음성 지연(Voice-to-Voice Latency), 즉 사용자가 말을 멈춘 순간부터 에이전트 응답의 첫 소리가 들릴 때까지의 시간입니다(13.15 참조). 이후의 모든 설계는 정답을 유지한 채 이 숫자를 줄이는 일입니다.

규모는 다음처럼 어림합니다. 하루 100만 통화, 평균 5분을 가정하면 초당 약 12통(100만÷86,400≈11.6)이고 동시 통화는 12×300=3,600건(정확히는 약 3,470건)입니다. 피크를 3배로 보아 약 10,000건으로 잡습니다.

대역폭과 저장은 현대 서버로 감당되며, 병목은 연산입니다. 동시 통화마다 스트리밍 STT, LLM 세션, 스트리밍 TTS가 하나씩 필요하고 셋 다 GPU에서 돌기 때문에(12.2 참조) 비용의 대부분이 GPU이며, 가능한 곳마다 작고 빠른 모델을 쓰는 이유가 여기 있습니다.

FDE는 고객이 "음성 봇을 만들고 싶다"고 할 때 먼저 용도(지원·예약·동반자), 채널(전화·앱), 도구 필요 여부, 언어, 동시 통화 규모를 묻고, 800ms 지연 목표에 합의한 뒤 설계에 들어갑니다.

13.1.2 오디오 전송: 프레임·코덱·AEC

마이크는 초당 수천 번 공기 압력을 재어 숫자(샘플)를 만들고, 초당 샘플 수가 샘플링 레이트입니다. 전화는 8kHz라서 목소리가 약간 먹먹하고, 음성 AI 모델은 16kHz면 충분하며, 음악용 44.1/48kHz는 음성에 과합니다. 샘플은 16비트(2바이트)로 저장하며 이 날것의 숫자열이 PCM입니다.

오디오는 샘플 하나씩도, 문장 전체도 아닌 보통 20ms 청크(프레임)로 잘라 보냅니다. 16kHz에서 20ms는 320샘플이고 초당 50개이며, 시스템의 모든 구성 요소가 이 청크 단위로 일합니다. 전송 전에는 코덱으로 압축합니다. 인터넷 실시간 음성에는 손실에 강한 Opus(16kHz 음성은 16~20kbps가 균형점이고 앱은 최대 32kbps까지 사용)가, 전화망에는 오래된 G.711(64kbps)이 쓰입니다.

전송 방식은 셋입니다.

에코 제거(AEC, Acoustic Echo Cancellation)는 이 절에서 가장 놓치기 쉬운 부분입니다. 에이전트 목소리가 사용자 스피커로 나오면 마이크가 그것을 다시 집어 서버로 보내고, 시스템은 사용자가 말한다고 오해해 에이전트가 스스로 끼어듭니다. AEC는 재생 중인 오디오를 알고 있으므로 마이크 입력에서 빼고 사용자 목소리만 남깁니다. WebRTC는 클라이언트에서 자동으로 하고 전화망은 대부분을 처리하지만, 직접 클라이언트를 만든다면 AEC를 켜 두지 않을 경우 끼어들기 처리가 제대로 동작하지 않습니다.

모두 폰에서 돌리지 않는 이유는 좋은 STT·LLM·TTS가 크고 GPU를 요구하기 때문입니다. 기기에서 돌릴 수 있는 것은 작은 VAD뿐이며, 배포 위치 판단은 클라우드 대 온디바이스 기준을 따릅니다(12.6 참조). 고객 앱이 모바일·웹이면 WebRTC, 전화면 텔레포니 공급자의 SIP/RTP, 내부 서비스 간이면 WebSocket으로 구간마다 다르게 고르는지를 확인합니다.

13.1.3 VAD·턴 감지·STT

VAD(Voice Activity Detection)는 20ms 청크마다 "지금 사람이 말하는가"를 예/아니오로 답하는 작은 모델이며 1ms 미만으로 돕니다. 에너지 기반 VAD는 큰 소리면 말로 보므로 문 닫는 소리나 TV도 통과시키고, 모델 기반 VAD는 사람 말소리와 키보드·음악을 구분하므로 운영에서 이쪽을 씁니다. 출력은 speech started와 speech ended 두 이벤트이며 나머지 로직이 이것으로 굴러갑니다. 클라이언트 VAD는 무음 전송을 막아 대역폭과 STT 비용을 아끼고, 서버 VAD는 전체 그림을 보므로 턴 감지와 끼어들기의 기준이 됩니다. 스마트 스피커 같은 상시 대기 기기는 VAD 앞에 "Hey Assistant" 같은 문구만 듣는 웨이크 워드 감지가 하나 더 있고, 전화는 통화 자체가 깨움이므로 필요 없습니다.

VAD의 침묵은 사용자가 순서를 마쳤다는 뜻이 아닙니다. "제 주문번호는..." 하고 1초 동안 이메일을 확인하는 사용자에게 "주문번호를 못 들었습니다"라고 끼어들면 불만이 생깁니다. 턴 감지(Turn Detection, End-of-Turn, 엔드포인팅)는 말을 마치고 응답을 기다리는지 잠시 멈춘 것인지 판단하는 일이며 음성 에이전트의 가장 어려운 문제입니다(13.4, 13.5 참조). 접근은 다섯 가지입니다.

시맨틱 턴 감지는 "I want to book a flight to"는 미완(도시가 올 것이므로 오래 대기), "I want to book a flight to Delhi tomorrow morning."은 완료(빠르게 응답), "Umm, so, the thing is"는 미완, "Yes."는 완료로 판정합니다. 침묵 타임아웃이 동적으로 바뀌어 완료 판정이면 약 200ms, 미완이면 최대 2초가 되어 속도와 인내를 모두 얻습니다. 일부 구현은 오디오도 입력해 문장 끝의 음높이 상승(질문)과 하강(끝)을 활용합니다. 투기적 처리는 확정 대기 시간 중 보통 150~300ms를 절약하지만 돈을 속도와 바꾸는 선택입니다. 음성-대-음성 모델은 수많은 실제 대화에서 턴 감지를 직접 학습하므로 별도 모듈이 없습니다.

백채널(Backchannel)은 듣는 사람이 내는 "음", "네", "맞아요" 같은 소리로 말하겠다는 뜻이 아닌데 VAD는 말로 잡습니다. 모두 끼어들기로 처리하면 에이전트가 이유 없이 문장 중간에 멈추므로, 500ms 미만의 짧은 발화를 백채널(무시)과 실제 끼어들기(중단)로 가르는 작은 분류기를 둡니다(13.13 참조).

STT(ASR)는 오디오를 텍스트로 바꾸는 모델입니다. 배치 STT는 완성된 파일을 받아 정확하지만 느리고(회의록용), 스트리밍 STT는 청크를 받는 대로 텍스트를 내며 실시간 에이전트에 필요합니다. 출력은 바뀔 수 있는 중간(interim) 전사("I want to book" → "I want to book a fly" → "I want to book a flight")와 확정되어 바뀌지 않는 최종(final) 전사입니다. 중간 전사는 화면 표시, 시맨틱 턴 감지 입력, LLM 호출 사전 준비에 쓰입니다. 모델이 수백 ms 창으로 일하므로 사용자가 마지막 단어를 말할 때 문장 대부분은 이미 전사된 상태이고, 최종 전사 대기는 턴 감지 대기와 동시에 진행되어 턴 종료 후 추가 지연은 약 50~150ms입니다.

STT가 어려운 지점은 다음과 같습니다.

• 단어 오류율(WER): 100단어 중 5개가 틀리면 5%입니다. 깨끗한 오디오에서 5~10% 미만이 좋은 모델이나, 억양 있는 소음 전화 회선에서는 20%를 넘길 수 있습니다.
• 이름·숫자·코드: 이메일 낭독이나 항공편 번호가 가장 흔한 실패이며, 도메인 단어 목록(제품명·도시명·회사명)을 주는 키워드 부스팅(커스텀 어휘)과 철자·숫자 전용 모드로 대응합니다.
• 억양과 언어: 사용자 억양으로 학습된 모델을 고르고, 인도처럼 힌디어와 영어가 한 문장에 섞이는 코드 스위칭도 처리해야 합니다.
• 소음과 다화자: STT 앞 노이즈 억제가 효과가 크고, 여러 화자는 화자 분리(diarization)가 필요하지만 1:1 통화에는 보통 불필요합니다(회의 보조에는 필요).
• 신뢰도 점수: 단어별 확신도가 낮은 중요한 값(주문번호)은 "4 5 6 7 8로 들었는데 맞습니까?"로 재확인합니다.

FDE는 고객의 통화 오디오 샘플로 WER과 숫자·이름 정확도를 먼저 측정하고, 실패가 많은 값에는 키워드 부스팅과 재확인 흐름을 요구사항에 넣습니다.

13.1.4 LLM 두뇌와 TTS

LLM은 에이전트의 두뇌입니다. 입력은 시스템 프롬프트(정체성·능력·말투), 통화 내 대화 이력, 최신 사용자 전사, 호출 가능한 도구 목록이며 출력은 텍스트 응답, 도구 호출, 또는 둘 다입니다. 도구는 우리가 작성하고 LLM에 설명해 주는 함수로, 예를 들어 get_order_status는 이름·설명·order_id: string 파라미터로 정의됩니다. 사용자가 "45678번 주문 어디 있죠?"라고 하면 LLM이 {"tool": "get_order_status", "arguments": {"order_id": "45678"}}을 내고, orchestrator가 실제 DB를 조회해 결과("배송 중, 내일 도착")를 돌려주면 LLM이 최종 답을 씁니다. 이 LLM → 도구 호출 → 결과 → LLM → 응답 순환이 챗봇과 에이전트를 가릅니다(6.3 참조). 통화 자체를 제어하는 end_call, transfer_to_human, send_sms 도구도 필요하며, end_call이 없으면 에이전트가 작별 시점을 모릅니다.

LLM은 토큰을 하나씩 생성하므로 전체 응답을 기다리지 않고 스트리밍하여 TTS로 넘깁니다(2.15 참조). 핵심 수치는 TTFT(Time To First Token)이며 음성에서는 300ms 미만이 목표입니다(10.2 참조). TTS는 문장 끝을 알아야 리듬이 맞으므로 orchestrator가 마침표·물음표나 긴 구 뒤 쉼표 같은 문장 경계까지 토큰을 모아 TTS에 보냅니다(13.17 참조). TTS가 1번 문장을 말하는 동안 LLM이 2번 문장을 쓰는 겹침이 지연을 낮추는 핵심 요령입니다.

gantt
    dateFormat X
    axisFormat %s
    section LLM
    문장 1 생성 :0, 2
    문장 2 생성 :2, 4
    문장 3 생성 :4, 6
    section TTS
    오디오 1 :2, 4
    오디오 2 :4, 6
    오디오 3 :6, 8
    section 재생
    재생 1 :3, 5
    재생 2 :5, 7
    재생 3 :7, 9

그림 13.1.4 — 사용자는 LLM이 문장 2, 3을 쓰는 동안 문장 1을 듣습니다. 겹침이 없으면 전체 응답을 쓰고 변환하는 시간만큼 침묵이 늘어납니다.

LLM은 텍스트 위주로 학습되어 기본적으로 긴 문단·불릿·마크다운·표를 쓰는데 음성으로는 최악입니다. 따라서 시스템 프롬프트에 다음 규칙을 넣습니다.

• 한두 문장으로 짧게 답한다(전화이지 에세이가 아님).
• 불릿·번호 목록·마크다운·이모지를 쓰지 않습니다.
• 숫자는 말하는 대로 쓴다("$45"가 아니라 "forty five dollars").
• 질문은 한 번에 하나만 합니다.
• 시간이 걸리는 도구를 부르기 전에 "네, 확인해 보겠습니다" 같은 짧은 말을 먼저 합니다.
• 주문번호·날짜·이름은 되읽어 확인합니다.
• 모르면 모른다고 말하고 상담원 연결을 제안합니다.

모델 선택은 속도와의 균형입니다. 큰 모델은 추론이 좋지만 느리고, 3초 늦은 똑똑한 답은 전화에서는 나쁜 답이므로 작고 빠른 모델(3.1 참조)이 흔한 정답입니다. 보조 기법은 다음과 같습니다.

• 프롬프트 캐싱: 매 턴 동일한 시스템 프롬프트와 도구 정의를 캐시해 TTFT를 크게 줄입니다(4.6 참조).
• 컨텍스트 단축: 입력 토큰이 적을수록 응답이 빠릅니다.
• 모델 라우팅: "네", "감사합니다", "잠시만요" 같은 단순 턴은 작은 모델, 도구 호출이나 복잡한 추론이 필요할 때만 큰 모델을 씁니다(3.6 참조).
• 특화 에이전트 분리: 결제·기술지원·예약 에이전트를 짧은 프롬프트와 소수 도구로 나누고 라우터가 배정하면 더 빠르고 정확합니다(6.12 참조).
• 공동 배치(co-location): LLM을 orchestrator와 같은 데이터센터에 둡니다.

TTS는 텍스트를 음성으로 바꾸며, 스트리밍 TTS는 문장 하나를 받고 생성이 끝나기 전에 약 80~200ms 안에 첫 오디오 청크를 내보냅니다. 지표는 TTFB(Time To First Byte of audio)입니다(13.18 참조). 좋은 TTS의 조건은 사람 같은 자연스러움(운율, 쉼표의 쉼, 질문의 올림조), 첫 바이트 200ms 미만, 오발음·단어 누락이 없는 안정성, 통화 안팎에서 일관된 목소리, 언어·억양 지원입니다.

텍스트 정규화(Text normalization)는 문어를 구어로 바꾸는 단계입니다. "15/09/2026, 3:30 PM, Dr. Sharma, $45.50"을 그대로 넣으면 약한 TTS는 "fifteen slash zero nine slash..."처럼 읽으므로 "September fifteenth ... three thirty PM ... Doctor Sharma ... forty five dollars and fifty cents"로 바꿔야 합니다. 좋은 TTS가 대부분 처리하지만 전화번호·주문번호·이메일·URL은 도메인 규칙을 직접 추가해야 하며, AB12345는 "A, B, one, two, three, four, five"처럼 짧은 쉼과 함께 글자·숫자 단위로 읽어야 합니다. 대부분의 TTS가 지원하는 SSML(쉼·철자 읽기·강조·발음을 지정하는 태그 집합)로 <say-as interpret-as="characters">AB12345</say-as>처럼 글자 단위 낭독을 강제할 수 있습니다. 오디오는 반대 경로(Orchestrator → Media Gateway → WebRTC/텔레포니 → 스피커)로 돌아가며 게이트웨이가 사용자 연결에 맞는 코덱과 샘플링 레이트로 변환합니다. 이때 orchestrator는 실제로 어디까지 재생되었는지를 정확히 추적해야 하며 끼어들기에 쓰입니다(13.1.6 참조).

FDE는 고객 시스템 프롬프트가 텍스트 챗봇용 그대로 복사된 것은 아닌지, 주문번호·금액을 읽는 규칙과 정규화가 있는지를 가장 먼저 점검합니다.

13.1.5 캐스케이드 vs 음성-대-음성 vs 하이브리드

시스템 전체를 묶는 방식은 크게 둘이고 실무에서는 섞기도 합니다. 선택 기준의 심화는 13.2 참조.

flowchart LR
    subgraph 접근1[접근 1: 캐스케이드]
    A1[오디오 입력] --> B1[VAD + 턴 감지] --> C1[STT] --> D1[LLM + 도구] --> E1[TTS] --> F1[오디오 출력]
    end
    subgraph 접근2[접근 2: 음성-대-음성]
    A2[오디오 입력] --> M[단일 S2S 모델] --> F2[오디오 출력]
    end

그림 13.1.5 — 캐스케이드는 중간이 모두 텍스트이고, 음성-대-음성은 텍스트 변환 없이 오디오가 모델을 통과합니다.

접근 1: 캐스케이드 파이프라인(STT → LLM → TTS)은 세 모델을 사슬로 연결한 고전 방식이며 중간이 전부 텍스트입니다. LLM 이전의 전화 봇(IVR 봇)도 STT와 TTS를 썼지만 중간은 "where is my order"를 ORDER_STATUS 같은 의도로 바꾸는 의도 분류기와 손으로 쓴 흐름이었습니다. 예측 가능하고 저렴했으나 경직되어, "두 개를 주문했는데 하나만 왔고 나머지는 선물이었어요" 같은 대본 밖 말은 처리하지 못했습니다. 분류기와 고정 흐름을 LLM과 도구로 바꾼 것이 봇을 에이전트로 만들었습니다.

한 턴의 타이밍을 추적해 봅니다(사용자가 마지막 말을 끝낸 시점이 0ms).

음성-대-음성 지연은 약 850ms로 목표 선에 걸립니다. 필러가 시간을 사 주는 구조입니다(13.20 참조).

캐스케이드의 장점은 일곱 가지입니다. STT·LLM·TTS를 따로 고르고 교체하는 모듈성, 중간 텍스트를 로그·가드레일·민감정보 가림(redaction)·업무 규칙으로 통제하는 완전한 제어(9.1 참조), 성숙한 도구 호출, 단계별 전사 덕분의 쉬운 디버깅, 작은 전문 모델이라 저렴한 비용, 언어별 STT·TTS 선택, 기존 텍스트 에이전트의 재사용입니다. 단점은 여섯 가지입니다. 지연이 단계마다 누적되어 800ms 미만에 많은 공학이 필요하고, 텍스트 변환에서 어조·감정·망설임·웃음이 사라져 같은 "I am fine"의 기쁨과 분노를 구분하지 못하며, 앞 단계 오류가 뒤로 전파되고(STT 오류 → 잘못된 답 → TTS가 자신 있게 낭독), TTS가 텍스트만 보므로 웃거나 속삭이거나 공감하는 표현이 어렵고, 턴 감지를 직접 만들고 튜닝해야 하며, 구조상 한쪽씩만 말하는 하프 듀플렉스라서 사용자가 말하는 중 에이전트가 "음-음"하는 겹치는 대화가 어렵습니다(13.3 참조).

접근 2: 음성-대-음성(S2S) 모델은 오디오를 받아 중간 텍스트 없이 오디오를 내는 단일 모델이며 엔드투엔드·오디오 네이티브·실시간 모델로도 부릅니다. OpenAI Realtime API 뒤의 모델, Google Gemini Live, 오픈소스인 Kyutai Moshi가 예입니다. LLM이 다음 텍스트 토큰을 예측하듯(2.3 참조) 오디오 토크나이저(신경 오디오 코덱)가 소리를 오디오 토큰(코덱에 따라 약 10~80ms 분량)으로 바꾸고, 대규모 대화 오디오로 학습된 하나의 모델이 사용자 오디오 토큰에서 에이전트 오디오 토큰을 예측합니다. 말뜻만이 아니라 어조·감정·휴지·웃음·배경까지 듣고 따뜻한 톤이나 웃음, 공감의 쉼까지 생성합니다. 다수가 풀 듀플렉스라서 동시에 듣고 말하며 언제 시작하고 멈추고 "음-음"하고 양보할지를 실제 대화에서 배웁니다. 대부분의 상용 모델은 오디오와 함께 전사 텍스트도 내므로 로그는 남지만 이는 부산물이지 사슬의 한 단계가 아닙니다.

S2S의 장점은 여섯 가지입니다. 단일 모델이라 300~500ms의 사람에 가까운 지연, 감정·어조 보존(화난 사용자에게 미안한 목소리), 백채널·겹침·웃음·끼어들기의 자연스러움, 내장 턴 감지, 단계 간 오류 누적 없음, 단순한 운영입니다. 단점은 열 가지입니다. 말하기 전에 텍스트를 검사·수정할 수 없어 가드레일·redaction·엄격한 규칙 적용이 어렵고, 받는 전사가 정답이 아니라 모델이 생각한 자기 발화여서 디버깅과 평가가 어려우며, 도구 호출이 덜 성숙하고, 최고의 추론 모델은 텍스트 모델이어서 복잡한 논리·수학·다단계 작업이 약하고(3.2 참조), 오디오 토큰이 텍스트 토큰보다 훨씬 많아 분당 비용이 몇 배이며, 학습 가능한 회사가 적어 STT나 목소리를 따로 교체할 수 없는 벤더 종속이 있고, 목소리·언어 선택이 제한되며, 환각(2.18 참조)이 따뜻한 목소리로 확신 있게 말해지고(텍스트 LLM은 텍스트에서 잡을 수 있음), 목소리 모방과 원치 않는 오디오 유도라는 안전 문제가 있으며, 오디오 토큰이 컨텍스트 윈도우(2.16 참조)를 훨씬 빨리 채워 긴 통화가 어렵습니다.

접근 3: 하이브리드는 현업에서 흔한 혼합입니다.

비교는 다음과 같습니다.

기본값은 통제·규정 준수·도구 중심 워크플로·저비용·모델 교체 가능성이 필요한 대다수 업무에서 캐스케이드이고, 자연스러운 대화 자체가 제품이거나 감정이 중요하고 통제 저하와 높은 비용을 받아들일 수 있다면 S2S이며, 앞단은 S2S의 감각을 뒤는 텍스트 에이전트의 신뢰성을 원하면 하이브리드입니다. 원문은 인터뷰에서도 두 방식과 장단점을 제시하고 요구사항으로 고르라고 권합니다. FDE는 고객의 규제 수준·도구 수·자연스러움의 가치를 묻고, 가드레일을 말하기 전에 걸 수 있어야 하는 업종이면 캐스케이드를 기본으로 제안합니다.

13.1.6 지연 예산과 끼어들기(Barge-in)

캐스케이드의 지연 예산은 800ms 목표 아래 구간별로 쪼갭니다(13.14 참조).

최선과 최악을 단순 합산한 값이며, 한 턴에서 모든 단계가 동시에 최선이나 최악일 가능성은 낮아 잘 최적화된 캐스케이드는 700ms~1.2초에 안착합니다. 어느 단계도 무시할 수 없고 규칙은 다음과 같습니다.

• 모두 스트리밍: 전체 전사, 전체 LLM 응답, 전체 TTS를 기다리지 않습니다.
• 단계 겹치기: TTS가 문장 1을 말하는 동안 LLM이 문장 2를 씁니다.
• 공동 배치: 같은 데이터센터 안의 hop은 약 1ms이지만 다른 데이터센터는 10~50ms를 더합니다.
• 연결 예열: STT·TTS 웹소켓을 통화 전에 열어 둡니다. 턴 중에 열면 100~300ms가 듭니다.
• 인사말 사전 생성: 첫 인사("전화 주셔서 감사합니다...")는 늘 같으므로 오디오를 캐시해 연결 즉시 재생합니다.
• 평균이 아니라 p95: p50은 절반의 턴이 그보다 빠르다는 뜻이고 p95는 100턴 중 95턴이 빠르다는 뜻입니다. 사용자는 평균이 아니라 느린 턴을 기억합니다.
• 필러로 시간 벌기: "확인해 보겠습니다"라는 한마디가 2초 도구 호출을 괜찮게 만듭니다.

바지인(Barge-in)은 에이전트가 말하는 중에 사용자가 말을 시작하는 상황이며 필수 기능입니다(13.11 참조). 긴 반품 정책을 읽는 중 "아니, 환불만 해 주세요"라고 하면 그 자리에서 멈추고 들어야 합니다. 흐름은 다섯 단계입니다.

def on_user_speech_started(session):
    if session.agent_is_speaking:
        session.tts.cancel(); session.llm.cancel()          # 1. 생성 중단
        session.client.send("clear_audio_buffer")            # 2. 재생 대기 버퍼 비우기
        played = session.get_text_played_until(session.playback_position)  # 3. 재생 위치 추적
        session.history.truncate_last_agent_turn(played)     # 4. 이력 수정
        session.agent_is_speaking = False
    session.start_listening()                                # 5. 청취

• 1단계 생성 중단: TTS와 LLM 스트림을 취소해 새 오디오가 만들어지지 않게 합니다.
• 2단계 버퍼 비우기: 가장 많이 잊는 단계입니다. 이미 클라이언트 버퍼에 몇 초 분량이 쌓여 있으므로 비우지 않으면 사용자가 끼어든 뒤에도 2초를 더 말합니다. 앞서 본 clear_audio_buffer 메시지가 이 역할입니다.
• 3단계 재생 위치 추적: 클라이언트가 재생한 청크 수(playback_progress)를 돌려보내면 어느 단어에서 끊겼는지 텍스트에 매핑합니다.
• 4단계 이력 수정: 전체 응답이 "Your order was shipped yesterday and will arrive tomorrow by 5 PM"이었는데 사용자가 "Your order was shipped"에서 끼어들었다면 이력에는 그 부분만 남겨야 합니다. 그렇지 않으면 다음 턴에서 LLM이 사용자가 오후 5시 도착을 들은 줄 알고 혼란을 겪습니다.
• 5단계 청취: 새 발화를 평소처럼 처리합니다.

거짓 끼어들기(기침, "okay" 같은 백채널, 개 짖는 소리)에 VAD만으로 반응하면 문장 중간에 계속 멈춥니다(13.12 참조). 그래서 발화가 200~300ms 이상 이어지거나 STT가 실제 단어를 한두 개 내놓을 때까지 기다리고, 짧은 발화를 백채널 분류기에 통과시켜 "mm-hmm", "okay", "right", "yeah"는 확인으로 취급하며, 확정 후에 끼어듭니다. 약간의 지연을 내고 불안정한 에이전트를 피합니다. 에이전트와 사용자가 동시에 말을 시작하면 사람은 한쪽이 물러서므로, 규칙은 에이전트가 항상 양보하는 것이며 응답 시작 후 수백 ms 안에 사용자 발화가 감지되면 중단합니다. S2S 모델은 이 판단을 학습하지만, 모델은 서버에 있고 오디오 버퍼는 기기에 있으므로 클라이언트의 버퍼 비우기는 여전히 우리 책임입니다.

FDE는 고객이 끼어들기를 구현했다고 할 때 버퍼 비우기와 이력 자르기까지 했는지, 지연을 평균이 아니라 p95로 보는지를 확인합니다.

13.1.7 텔레포니·스케일링·엣지 케이스

도구 호출에는 음성 특유의 문제가 여섯 가지 있습니다(13.21 참조).

기억과 컨텍스트는 세 층입니다. 통화 내에서는 이력을 orchestrator 세션 메모리에 두고 매 턴 LLM에 보내지만 30분 같은 긴 통화에서는 느려지고 비싸지므로, 10~15턴마다 작은 모델이 오래된 부분을 몇 줄로 요약하고 최근 턴만 원문으로 둡니다. 통화 간에는 전화번호나 인증으로 고객 프로필을 찾아 시스템 프롬프트에 "Amit, 프리미엄 고객, 3일 전 지연된 주문 45678(현재 배송 완료) 문의"처럼 짧은 요약을 넣습니다(6.7 참조). 지식은 프롬프트에 통째로 넣지 않고 search_knowledge_base 도구가 관련 단락만 찾아 주는 RAG로 처리하며, 음성에서는 검색 지연이 중요하므로 인덱스가 100ms 미만이어야 합니다. 세션 상태(검증된 고객 ID, 논의 중인 주문, 워크플로 단계)는 메모리에 두고 매 턴 Redis 같은 빠른 저장소에 체크포인트하여 orchestrator가 죽어도 다른 서버가 이어받습니다.

텔레포니는 일반 전화번호에서 일하는 모든 업무용 에이전트의 관문입니다.

• PSTN과 SIP: Twilio·Vonage·Plivo 같은 공급자나 전화망과 직결된 SIP trunk가 전화를 받아 SIP(통화 제어)와 RTP(오디오)로 미디어 게이트웨이에 스트림을 엽니다.
• 인바운드·아웃바운드: 아웃바운드에는 두 문제가 추가됩니다. 음성사서함이 받았을 때 2분간 녹음에 말하지 않도록 자동응답기 감지로 메시지를 남기거나 끊어야 하고, 사람이 "여보세요"라고 말할 때까지 기다린 뒤 시작해야 합니다.
• DTMF: 키 입력음("1번은 영업")도 지원합니다. 키를 선호하는 사용자가 있고 PIN은 말하기보다 누르는 편이 안전합니다.
• 상담원 이관: 콜드 트랜스퍼는 상담원 대기열에 그냥 연결하고, 웜 트랜스퍼는 LLM이 만든 지금까지의 요약을 상담원 화면에 먼저 전달해 사용자가 반복하지 않게 합니다.
• 오디오 품질: 8kHz 구형 코덱이므로 STT를 전화 오디오로 학습하거나 시험하고, 필요하면 STT 전에 8→16kHz로 업샘플합니다.
• 녹음 동의: 많은 국가에서 시작 시 "통화가 녹음될 수 있습니다" 안내가 필요하며 사전 생성한 오디오 파일을 씁니다.

확장은 세 가지 사실에서 출발합니다. 통화는 웹 요청(100ms)이 아니라 5분 동안 상태와 연결을 쥐고 있으므로 한 통화의 오디오가 같은 orchestrator 인스턴스로 가는 스티키 세션이 필요합니다. orchestrator 서버 한 대는 수백 통화를 감당하고(무거운 일은 GPU 서비스), 부하 분산기가 최소 부하 서버에 배정합니다. STT·LLM·TTS는 각자의 GPU 풀과 독립적인 오토스케일링을 가지며, STT와 TTS는 작아서 GPU 한 장에 많은 스트림을 얹을 수 있고 LLM이 최대 비용이어서 연속 배칭(10.5 참조)과 빠른 추론 엔진을 씁니다. 인도 사용자가 미국 서버에 연결하면 왕복 200~300ms가 더해져 예산이 무너지므로 전체 스택을 여러 리전에 두고 가장 가까운 곳으로 라우팅합니다.

장애 대응은 다음과 같습니다.

• orchestrator 장애: 체크포인트가 없으면 통화가 사라지지만, 있으면 미디어 게이트웨이가 새 orchestrator에 오디오를 재연결하고 상태를 불러와 이어가므로 사용자는 짧은 멈춤만 겪습니다.
• STT/TTS 공급자 장애: 두 번째 공급자로 전환합니다. 캐스케이드의 큰 이점입니다.
• 과부하: 통화를 끊는 대신 더 작은 LLM으로 전환하고 컨텍스트를 줄이며, 최악에는 "모든 상담원이 통화 중입니다"를 틀고 대기열에 둡니다.
• 외부 공급자 한도: 분당 호출·동시 스트림 한도를 추적해 용량을 확보하고 백업 공급자를 둡니다.

프로덕션에서 시스템을 깨뜨리는 엣지 케이스와 해법은 다음 표에 모았습니다.

FDE는 이 표를 고객 현장 점검표로 쓰되, 우선 침묵 종료·카드번호·환각 근거·장애 전환 네 가지가 정의되어 있는지부터 묻습니다.

13.1.8 관측성·안전·비용

관측성의 출발은 한 턴 단위 가시성입니다. 턴마다 사용자 발화 종료, 턴 감지, STT 최종, LLM 첫 토큰, LLM 완료, TTS 첫 바이트, 오디오 재생 시각을 기록하는 턴별 추적으로 느린 턴의 지연 위치를 찾으며, 음성-대-음성 지연은 사용자가 실제 느끼는 지점인 클라이언트의 귀에서 측정해야 합니다(13.15 참조). 추적할 지표는 다음과 같습니다.

• 음성-대-음성 지연의 p50·p95·p99
• 첫 토큰까지 시간, 첫 오디오 바이트까지 시간
• 턴 감지 오류(조기 끊김, 늦은 응답)
• 끼어들기 횟수와 거짓 끼어들기 횟수
• 표본 통화의 STT WER(사람 전사 대비)
• 과업 완료율, 상담원 이관율, 평균 통화 시간
• 도구 호출 실패율, 분당 비용

녹음과 전사는 동의 아래 보관해 디버깅·품질 검토·학습에 씁니다. 프롬프트나 모델을 바꾸기 전에는 개인정보를 제거한 실제 통화 전사·오디오 테스트 세트로 새 버전을 돌려 비교하는 오프라인 평가를 하고, "파손 상품을 반품하려는 화난 고객" 같은 목표를 가진 LLM인 시뮬레이션 호출자로 수천 건의 테스트 대화를 자동 생성합니다. 또 매일 일부 통화를 사람이 평가해 무례한 어조처럼 지표가 못 잡는 문제를 잡습니다.

안전·보안·개인정보 항목은 아홉 가지입니다.

• 암호화: 전송 중(WebRTC와 전화는 SRTP, 웹소켓은 TLS)과 저장 시.
• 동의와 고지: 법이 요구하는 곳에서 녹음을 알리고 AI와 통화 중임을 알립니다.
• PII 삭제: 이름·전화번호·카드번호·주소를 로그와 전사에서 제거하거나 별도 보호 저장소에 둡니다.
• 보존: 일정 기간 후 녹음을 삭제합니다.
• 인증: 목소리만으로 신원을 확인하지 않습니다. 목소리는 복제될 수 있으므로 OTP, DTMF PIN, 검증된 번호를 씁니다.
• 음성 복제: 동의 없이 실존 인물의 목소리를 복제하지 않고 라이선스된 합성 음성을 씁니다.
• 프롬프트 인젝션: 업무 규칙은 프롬프트에만 두지 않고 백엔드 도구에 둡니다.
• 요금 사기(toll fraud): 아웃바운드에서 공격자가 고액 요금 번호로 발신하게 만들 수 있으므로 속도 제한과 모니터링을 둡니다.
• 콘텐츠 안전: 출력의 위험 내용을 검사하는 가드레일 모델이며, 텍스트를 볼 수 있는 캐스케이드에서 특히 쓸 수 있습니다.

비용은 원문이 밝힌 대략의 공개 가격(2026년 9월 글 기준, 공급자별 편차 큼)으로 분당 어림합니다. 이 숫자는 휘발성이 크므로 구조만 참고합니다. 이 가격대는 원문의 설명이며 외부 출처로는 확인하지 못했습니다.

TTS를 통화 시간 기준으로 환산해 재계산하면 최저 0.01+0.005+0.01+0.005+0.005=$0.035, 최고 0.01+0.01+0.03+0.015+0.005=$0.07로, 원문의 $0.04~0.07과 거의 같습니다. S2S는 오디오 토큰이 비싸서 분당 $0.10~0.30로 몇 배이고, 비교 대상인 사람 상담원은 많은 시장에서 분당 $0.50~1.00입니다. 절감 방법은 작은 모델과 필요할 때만 큰 모델로 라우팅(3.6 참조), 시스템 프롬프트·도구의 프롬프트 캐싱(4.6 참조), 긴 컨텍스트 요약, VAD가 정한 구간만 STT로 전송(무음 제외), 대규모에서 오픈소스 STT·TTS 자체 호스팅, 죽은 통화의 빠른 종료입니다.

원문은 45분 시스템 설계 면접 흐름도 제시합니다. 요구사항 확인 5분(용도·채널·도구·언어·규모와 800ms 지표), 상위 아키텍처 5분, 두 접근 비교 10분, 턴 감지·지연 예산·끼어들기·도구 호출 심화 10분, 확장과 신뢰성 10분, 엣지 케이스·관측성·안전·비용 5분입니다. 평가 포인트는 음성 에이전트를 지연 예산이 엄격한 실시간 스트리밍 시스템으로 이해하는지입니다.

자주 묻는 질문 다섯 가지의 답은 다음과 같습니다.

고객과의 비용 대화에서는 분당 단가가 아니라 통화당 과업 완료율과 이관율을 같이 놓고, 사람 상담원 대비 절감분과 지연·통제 요건의 균형으로 캐스케이드와 S2S를 가립니다.

13.2 캐스케이드 vs 음성-대-음성 아키텍처

원문: Cascaded vs Speech-to-Speech: How to choose the right voice agent architecture?

음성 에이전트는 매 턴 듣기, 생각하기, 말하기 세 가지 일을 하며, 이 세 일을 모델 몇 개에 어떻게 나누느냐가 지연, 어조, 통제력, 비용을 결정합니다. 이 절은 2026년 10월 글 기준으로 13.1의 접근 1·2·3(캐스케이드, 음성-대-음성, 하이브리드)을 고르는 기준을 한 단계 더 구체화합니다.

13.2.1 캐스케이드 에이전트의 강약

캐스케이드(Cascaded) 음성 에이전트는 앞 모델의 출력이 뒤 모델의 입력이 되는 세 모델의 사슬입니다. cascade는 물이 계단을 따라 한 단씩 흘러내리듯 각 단계가 다음 단계로 흐른다는 뜻입니다. 세 모델은 STT(음성을 텍스트로, ASR이라고도 부름), LLM(텍스트를 읽고 텍스트 응답을 작성), TTS(응답 텍스트를 음성으로)입니다. 예컨대 사용자가 "월요일에 예약할 수 있나요?"라고 말하면 STT가 같은 문장의 텍스트를 내고, LLM이 "네, 월요일 오전 10시가 비어 있습니다. 예약해 드릴까요?"라는 텍스트를 쓰고, TTS가 이를 읽습니다.

flowchart TD
    A[사용자 음성] --> B[STT]
    B -->|텍스트| C[LLM]
    C -->|텍스트| D[TTS]
    D --> E[에이전트 음성]

그림 13.2.1 — 세 모델을 잇는 공통 언어는 텍스트입니다.

세 부분이 각각 성숙하고 검증된 모델이라는 점이 이 방식이 흔한 이유입니다. 강점은 다섯 가지입니다.

• 모든 것이 보입니다. 사슬 중간이 평문이라서 에이전트가 무엇을 들었고 무엇을 말하기로 했는지 그대로 읽을 수 있으며, 문제가 생기면 로그에서 원인을 찾습니다.
• 일마다 최고의 모델을 고릅니다. A사의 STT, B사의 LLM, C사의 TTS를 조합할 수 있고, 더 나은 TTS가 나오면 그 부분만 교체합니다.
• 강한 추론과 도구 사용. 가운데 LLM은 가장 유능한 텍스트 LLM일 수 있고, 긴 지시를 따르고 어떤 도구를 쓸지 정하는 일(예: "일정 확인", "주문 찾기")에 뛰어납니다. 도구는 우리 코드가 실행해 결과를 LLM에 돌려줍니다(6.2 참조).
• 쉬운 안전 검사. TTS로 넘기기 전에 응답 텍스트를 우리 규칙으로 검사합니다. 허용되지 않은 환불을 약속하지 못하도록 차단하는 식입니다(9.1 참조).
• 목소리의 완전한 통제. 다양한 목소리나 맞춤 목소리를 고르고, 브랜드명 발음을 바로잡고, 말하는 속도를 TTS 단계에서 조절합니다.

약점은 네 가지입니다.

• 지연이 합산됩니다. 사용자는 STT, LLM, TTS를 차례로 기다리며 총 지연은 각 단계의 합입니다(13.14 참조). 대화에서는 1초의 틈도 느립니다.
• 어조가 사라집니다. STT가 목소리를 텍스트로 바꾸면 어조가 없어집니다. 화난 목소리로 "Great..."라고 해도 LLM은 단어 "Great"만 봅니다.
• 오류가 사슬을 따라 내려갑니다. STT가 "two fifteen"을 "two fifty"로 들으면 LLM은 틀린 숫자를 받고 에이전트는 잘못된 시간으로 예약하며, LLM은 원래 오디오를 들을 방법이 없습니다.
• 턴테이킹에 별도 부품이 필요합니다. 사용자가 말을 끝냈는지 먼저 판단해야 하므로 침묵 감지와 턴 감지 모델을 따로 붙입니다(13.4, 13.5 참조).

수치로 보면 STT가 끝나는 데 300ms, LLM이 응답을 시작하는 데 500ms, TTS가 말하기 시작하는 데 200ms가 걸린다고 가정할 때 사용자는 300+500+200=1,000ms, 즉 꼬박 1초를 기다린 뒤에야 소리를 듣습니다. 좋은 캐스케이드는 스트리밍으로 이를 줄입니다. STT는 들리는 대로 단어를 보내고(2.15 참조), LLM은 텍스트가 오는 즉시 쓰기 시작하며, TTS는 LLM이 나머지를 쓰는 동안 첫 문장을 말합니다(13.16 참조). 지연이 크게 줄지만 모델 간 인계에서 오는 지연은 남습니다.

FDE는 캐스케이드를 제안받은 고객에게 단계별 지연 로그를 요청하고, 어느 단계가 합산 1초를 만드는지 먼저 확인합니다.

13.2.2 음성-대-음성 에이전트의 강약

캐스케이드의 가장 큰 두 문제는 쌓이는 지연과 사라지는 어조이고, 이 둘을 풀려고 나온 것이 음성-대-음성(Speech-to-Speech) 에이전트입니다. 사용자 오디오를 입력으로 받아 중간에 텍스트로 바꾸지 않고 응답을 오디오로 바로 내는 단일 모델을 씁니다. 듣기·생각하기·말하기가 한 모델 안에서 일어납니다.

flowchart TD
    A[사용자 음성] --> B[음성-대-음성 모델: 듣고 생각하고 말함]
    B --> C[에이전트 음성]

그림 13.2.2 — 모델 사이의 인계가 없고, 오디오가 들어가 오디오가 나옵니다.

모델은 대량의 음성으로 학습되며, 보통 들어오는 오디오를 오디오 토큰(소리의 단어에 해당하는 작은 조각)으로 바꿔 직접 이해하고 응답용 새 오디오 토큰을 생성한 뒤 다시 소리로 되돌립니다. 많은 모델이 내부적으로 오디오와 함께 텍스트도 만들어 더 잘 생각하게 하고 전사를 제공하지만, 우리가 듣는 목소리는 별도 TTS가 아니라 모델 자체에서 나옵니다. 강점은 다섯 가지입니다.

• 낮은 지연: 세 모델 사이의 인계가 없어 응답이 빨리 시작되고 실제 사람과 말하는 느낌에 가깝습니다.
• 어조 유지: 단어가 아니라 실제 목소리를 듣기에 사용자가 화났는지, 혼란스러운지, 기쁜지 알아채고 맞는 어조로 답합니다.
• 자연스러운 말투: 완성된 텍스트를 읽는 대신 응답의 일부로 목소리를 생성하므로 웃고, 쉬고, 속도를 바꾸고, 따뜻하게 말하는 모델이 많습니다.
• 끼어들기 처리: 일부 모델은 말하면서 들을 수 있어(13.3 참조) 사용자가 끼어들면 감시용 별도 시스템 없이 빠르게 알아채고 멈춥니다(13.11 참조).
• 간편한 구성: 모델 셋을 엮는 대신 하나에 연결합니다.

약점은 여섯 가지입니다.

• 내부가 잘 안 보입니다. 전사를 주더라도 부산물이어서 모델이 응답을 정할 때 쓴 정확한 입력이 아니므로 잘못 들었는지 잘못 이해했는지 가리기 어렵습니다.
• 선택지가 적습니다. 목소리만 또는 생각하는 부분만 교체할 수 없고 그 모델이 가진 목소리와 사고력을 통째로 받습니다.
• 복잡한 작업에 약한 경우가 많습니다. 긴 지시 따르기, 신중한 추론, 올바른 도구를 안정적으로 고르기에서는 최강 텍스트 LLM이 대개 더 낫습니다.
• 목소리 통제가 약합니다. 보통 고정된 목소리 목록만 있고 브랜드명이나 약 이름의 정확한 발음을 강제하기 어렵습니다.
• 안전 검사가 어렵습니다. 오디오가 직접 생성되어 곧바로 재생되므로 사용자가 듣기 전에 전체 응답을 검사하기 힘듭니다.
• 비용: 오디오 토큰은 보통 텍스트 토큰보다 비싸서 긴 통화는 더 들 수 있으며, 예상 통화 길이로 두 구성의 분당 총비용을 비교해야 합니다.

FDE는 S2S 후보를 평가할 때 "잘못 말했을 때 왜 그랬는지 추적할 수 있는가"를 먼저 시험하고, 도구 호출이 많은 업무라면 같은 시나리오를 텍스트 LLM 기반 구성과 나란히 돌려 비교합니다.

13.2.3 하프 캐스케이드(Half-Cascade)

두 방식 사이의 세 번째 선택이 하프 캐스케이드입니다. 모델이 사용자 오디오를 직접 들어 어조를 지키되 응답은 텍스트로 쓰고, TTS가 그 텍스트를 음성으로 바꿉니다. 오디오를 직접 입력으로 받아 이해하고 텍스트로 응답하는 오디오-입력 모델(3.4 참조)과 TTS, 두 개의 모델로 구성됩니다.

flowchart TD
    A[사용자 음성] --> B[오디오-입력 모델: 듣고 생각함]
    B -->|응답 텍스트| C[TTS]
    C --> D[에이전트 음성]

그림 13.2.3 — 입력은 오디오로, 출력은 텍스트를 거쳐 음성으로 갑니다.

얻는 것은 세 가지입니다. 실제 목소리를 들으므로 사용자 어조가 사라지지 않고, 응답이 텍스트이므로 검사하고 기록하고 말하는 방식을 통제할 수 있으며, 응답이 텍스트 단계를 거치기에 도구 호출이 완전한 S2S보다 흔히 더 안정적입니다. 대가는 응답 목소리가 보통 완전한 S2S보다 덜 표현적이고 TTS 단계가 지연을 일부 되돌린다는 점입니다.

세 구성은 다음과 같이 다릅니다.

FDE는 고객이 "어조를 듣고 싶지만 응답은 검사해야 한다"고 할 때 하프 캐스케이드를 먼저 후보에 올립니다.

13.2.4 아키텍처 선택 기준

선택 전에 던질 질문은 하나입니다. 이 에이전트에서 틀린 답이 더 나쁜가, 느리고 밋밋한 답이 더 나쁜가. 틀린 답이 더 나쁘면 캐스케이드, 느리고 밋밋한 답이 더 나쁘면 음성-대-음성 쪽으로 기웁니다. 세 가지 예가 있습니다.

일반 규칙은 다음과 같습니다.

• 캐스케이드를 고르는 경우: 도구를 많이 호출하거나 긴 엄격한 지시를 따를 때, 사용자가 듣기 전에 응답을 검사하거나 차단해야 할 때, 특정 목소리나 이름·브랜드의 정확한 발음이 필요할 때, 나중에 더 낫거나 싼 TTS로 바꾸는 식으로 부품을 교체하고 싶을 때.
• 음성-대-음성을 고르는 경우: 낮은 지연과 사람 같은 자연스러운 대화가 가장 중요할 때, 사용자의 어조와 감정에 반응해야 할 때, 도구와 엄격한 규칙이 적은 단순 작업일 때.
• 하프 캐스케이드를 고르는 경우: 사용자의 어조를 들려주고 싶으면서 검사 가능한 텍스트 응답과 통제 가능한 목소리를 원할 때, 도구를 호출하지만 사용자 기분도 중요할 때.

이 선택은 영구적이지 않습니다. S2S 모델은 추론과 도구 호출 능력이 빠르게 개선되고 있습니다(2026년 10월 글 기준). 그러므로 도구, 지시문, 테스트 통화를 모델과 분리해 두면 나중에 다른 구조를 시도하고 실제 통화에서 두 구성을 비교할 수 있습니다. 두 접근의 전체 항목별 비교와 하이브리드 다섯 패턴은 13.1.5에 있습니다.

자주 묻는 질문은 다음과 같이 답합니다. 캐스케이드가 어조를 잃는 이유는 STT가 목소리를 텍스트로 바꾸는 순간 어조가 빠지고 LLM이 원래 오디오를 들을 방법이 없기 때문입니다. 스트리밍은 지연을 크게 줄이지만 모델 간 인계 지연은 남습니다. 오디오 토큰은 소리의 단어에 해당하는 작은 조각이며, S2S는 이를 직접 이해하고 응답 토큰을 생성해 소리로 되돌리므로 별도 TTS가 필요 없습니다. S2S가 더 비쌀 수 있는 이유는 오디오 토큰이 텍스트 토큰보다 비싸기 때문이며, 긴 통화에서는 예상 통화 길이 기준 분당 총비용을 비교해야 합니다. 캐스케이드에서 S2S로의 전환은 나중에도 가능합니다.

고객이 "한 번 정하면 못 바꾸나요"라고 물으면, 도구·지시문·테스트 통화를 모델과 분리한 구조라면 바꿀 수 있고 실제 통화로 비교해 결정한다고 답합니다.

13.3 하프 듀플렉스 vs 풀 듀플렉스

원문: How do half-duplex and full-duplex voice agents differ?

음성 에이전트가 무전기처럼 동작하는지 전화 통화처럼 동작하는지는 "듣기와 말하기가 동시에 가능한가"로 갈립니다. 이 절은 2026년 11월 글 기준으로 두 방식의 동작 원리와 한계를 같은 대화로 비교합니다.

13.3.1 하프 듀플렉스의 동작과 문제

통신에서 듀플렉스(duplex)는 대화하는 양쪽이 서로 정보를 보내는 방식을 가리킵니다. 하프 듀플렉스(half-duplex)는 양쪽이 말할 수 있되 한 번에 한쪽만 말하는 방식이고, 풀 듀플렉스(full-duplex)는 양쪽이 동시에 말할 수 있는 방식입니다. 무전기는 버튼을 누르고 말하는 동안 상대 말을 들을 수 없고 버튼을 놓아야 상대가 말하므로 하프 듀플렉스입니다. 일반 전화는 말하면서 들을 수 있어, 상대가 내 말 중에 "음" 하면 들리고 둘이 동시에 말하면 한쪽이 멈추므로 풀 듀플렉스입니다.

gantt
    dateFormat X
    axisFormat %s
    section 하프 듀플렉스(무전기)
    A 발화 :0, 3
    B 발화 :3, 6
    section 풀 듀플렉스(전화)
    A 발화 :0, 6
    B 맞장구 :2, 3
    B 발화 :4, 6

그림 13.3.1 — 하프 듀플렉스는 두 선이 겹치지 않고, 풀 듀플렉스는 언제든 겹칠 수 있습니다.

하프 듀플렉스 음성 에이전트는 어느 순간에도 듣거나 말하거나 둘 중 하나만 하는 에이전트입니다. 사용자가 끝내기를 기다리고, 생각하고, 말하며, 말하는 동안에는 사용자 말을 실제로 듣지 않고 턴 단위로 일합니다(13.4 참조). 상용 음성 에이전트의 상당수가 핵심 구조에서 이 방식이며 앞뒤로 이어진 부품의 사슬로 만들어집니다. 5단계로 돕니다.

실제 시스템은 시간을 아끼려고 부품끼리 부분 결과를 넘기지만, 사용자 턴이 끝날 때까지 기다린 뒤에 응답한다는 점은 같습니다. 어느 순간에도 한 방향만 활성화되며, 사용자가 말하고 에이전트가 듣거나, 에이전트가 말하고 사용자가 듣기를 기대받는 것이 무전기 동작입니다.

설계는 단순하고 동작하지만 사람 같은 대화를 흉내 내려 하면 네 가지 문제가 생깁니다.

• 문제 1 대기 틈: 침묵 타이머가 끝나기를 기다린 뒤 ASR, LLM, TTS가 차례로 시간을 쓰고 이 지연들이 합쳐져(13.14 참조) 사용자가 멈춘 순간과 에이전트가 말하기 시작하는 순간 사이에 눈에 띄는 틈이 생깁니다(13.15 참조). 사람 대화의 틈은 보통 200ms 안팎입니다.
• 문제 2 말 끊기: 가장 단순한 형태는 침묵만 보고 턴 종료를 판단합니다. "제 번호는 98765..." 하고 나머지를 기억하려 멈추면 에이전트는 끝났다고 보고 문장 중간에 응답하기 시작합니다(13.8 참조). 단어와 어조까지 보는 턴 감지 모델이 이를 줄이지만(13.6 참조), 응답하려면 턴이 끝났다고 결정해야 하는 구조는 그대로입니다.
• 문제 3 말하는 동안 듣지 못함: 긴 항공편 목록을 읽는 중에 원하는 편을 이미 들은 사용자가 "두 번째요"라고 해도 순수 하프 듀플렉스 에이전트는 말하는 동안 듣지 않으므로 목록 전체를 끝까지 읽습니다.
• 문제 4 작은 청취 소리가 없음: 실제 대화에서는 상대가 말하는 동안 "음", "네", "맞아요"라고 합니다. 이 백채널(backchannel)은 "따라가고 있으니 계속하세요"라는 신호입니다(13.13 참조). 하프 듀플렉스 에이전트는 사용자 턴 동안 말할 수 없으므로 내지 못하고, 에이전트가 말하는 중에 사용자가 "음"이라 하면 무시하거나 새 턴으로 처리합니다.

네 문제의 뿌리는 같습니다. 에이전트가 한 번에 한 가지만 할 수 있다는 점입니다.

FDE는 고객 통화 녹음에서 응답 전 틈, 중간에 끊긴 발화, 목록 낭독 중 사용자 개입 횟수를 세어 어느 문제가 우세한지 찾습니다.

13.3.2 하프 듀플렉스 위의 바지인

문제 3을 풀려고 많은 하프 듀플렉스 에이전트가 바지인(barge-in), 곧 에이전트가 말하는 중에 사용자가 끼어들 수 있는 기능을 얹습니다(13.11 참조). 에이전트가 말하는 동안 보통 같은 VAD인 청취기가 마이크에서 계속 켜져 있다가 사용자가 말을 시작한 것을 감지하면 에이전트 목소리를 즉시 멈추고 듣기로 돌아갑니다. 예를 들어 "Flight one is at 9 AM, flight two is at--" 하는 중에 사용자가 "the first one"이라고 하면 에이전트가 멈춥니다.

바지인은 도움이 되지만 에이전트를 풀 듀플렉스로 만들지는 않습니다. 말하는 동안의 청취기는 끼어들기를 감지하고 에이전트를 멈추는 한 가지 일만 하며, 사용자가 한 말은 에이전트가 이미 멈춘 뒤에 새 턴으로 처리됩니다. 에이전트는 여전히 사용자 말을 이해하면서 계속 말할 수 없고 말하기에서 듣기로 더 빨리 전환할 뿐입니다.

바지인 자체의 문제도 있습니다.

• 기침, 문 닫는 소리, 배경 사람 말소리가 에이전트를 잘못 멈출 수 있습니다(13.12 참조).
• "계속하세요"를 뜻하는 사용자의 단순한 "음"도 에이전트를 멈출 수 있습니다.
• 에이전트 자신의 목소리가 마이크로 되돌아와 거짓 끼어들기를 일으킬 수 있습니다. 이를 막으려면 마이크 신호에서 에이전트 자기 목소리를 제거하는 에코 제거가 필요합니다.

바지인은 하프 듀플렉스를 낫게 하지만 한 번에 한 방향이라는 기본 규칙은 그대로이므로, FDE는 바지인이 있다는 말을 풀 듀플렉스라는 뜻으로 받아들이지 않고 끼어든 말을 이해하고 이어 가는지를 시험해 봅니다.

13.3.3 풀 듀플렉스의 동작

풀 듀플렉스 음성 에이전트는 전화 통화 속 사람처럼 듣기와 말하기를 동시에, 계속 수행합니다. 사용자 턴이 끝나기를 기다렸다가 생각하기 시작하지 않고, 말하는 동안에도 사용자 말을 계속 듣습니다. 두 방향이 항상 열려 있어서 사용자가 말하는 중에 "음"이나 "네"를 말할 수 있고, 말하는 동안 사용자가 한 말을 이해(단순 감지가 아니라)할 수 있고, 사용자가 겹쳐 말하면 멈출지 계속할지 응답을 조정할지 스스로 정할 수 있으며, 내내 듣고 생각해 왔으므로 아주 빨리 응답을 시작할 수 있습니다. 대표 사례는 AI 연구소 Kyutai가 2024년에 공개한 풀 듀플렉스 음성 모델 Moshi입니다.

많은 풀 듀플렉스 에이전트는 부품의 사슬이 아니라 오디오 위에서 직접 일하는 단일 모델입니다(13.2 참조). Moshi 기준으로 핵심 아이디어는 다음과 같습니다. 먼저 오디오를 짧은 시간 조각으로 자릅니다. Moshi의 한 조각은 80ms이며 초당 1,000÷80=12.5조각입니다. 각 조각은 오디오 토큰이라는 작은 숫자 묶음으로 바뀌는데, 토큰은 LLM이 텍스트 토큰(2.4 참조)을 읽고 쓰듯 모델이 읽고 쓰는 작은 단위입니다. 모델은 두 오디오 토큰 스트림을 나란히 유지합니다. 사용자 스트림은 지금 사용자가 말하는 것이고 에이전트 스트림은 지금 에이전트가 말하는 것입니다. 모델은 매 조각마다 사용자 스트림의 최신 조각을 읽고 에이전트 스트림의 다음 조각을 쓰며 이를 초당 12.5번 쉬지 않고 반복합니다. 두 스트림을 함께 보므로 두 목소리가 언제 겹치는지 정확히 압니다.

조각당 단어 하나로 단순화해 보면 다음과 같습니다(-는 침묵).

• 조각 1·2: 사용자가 말하고 에이전트는 침묵합니다.
• 조각 3: 사용자가 계속 말하는 중에 에이전트가 동시에 "hmm"이라고 하며 이것이 백채널입니다.
• 조각 4: 둘 다 잠시 침묵하고 모델이 사용자가 끝냈다고 판단합니다.
• 조각 5부터: 에이전트가 응답을 시작합니다.

핵심은 침묵도 출력이라는 점입니다. 에이전트가 말하지 말아야 할 때 모델은 에이전트 스트림에 침묵처럼 들리는 오디오 토큰을 씁니다. 따라서 모델은 매 조각마다 조용히 있을지 말할지를 정하고, 사용자 턴이 끝났는지 정하는 별도의 침묵 타이머가 없습니다. 모델은 사람 간 실제 녹음을 포함한 대화 학습에서 이 동작을 배웁니다. Moshi는 또 자기 말의 텍스트를 해당 오디오 토큰보다 약간 앞서 예측하며 Kyutai는 이를 Inner Monologue라고 부릅니다. 소리를 만드는 동안 말의 의미를 유지하는 데 도움이 됩니다. Moshi 논문 기준으로 이 설계의 이론적 지연은 160ms, 단일 GPU에서 실제 약 200ms이며 사람 대화의 틈과 가깝습니다.

FDE는 풀 듀플렉스 모델을 도입하려는 고객에게 겹치는 발화가 들어 있는 학습 및 평가 데이터가 있는지, 도구 호출을 어떻게 붙일지(13.1.5의 하이브리드)를 먼저 묻습니다.

13.3.4 같은 대화의 비교와 선택

식당 예약 대화를 두 에이전트로 돌려 봅니다.

차이는 세 가지입니다. 하프 듀플렉스는 침묵만 봐서 멈춘 지점에 끼어들었고, 풀 듀플렉스는 문장이 끝나지 않았음을 이해해 "hmm" 하고 기다렸습니다. 하프 듀플렉스는 응답 전에 틈이 있었고 풀 듀플렉스는 빨리 응답했습니다. 사용자가 끼어들었을 때 하프 듀플렉스는 멈추고 새 턴을 시작해야 했지만 풀 듀플렉스는 사용자의 말을 이해하고 그에 답했습니다.

하프 듀플렉스의 장점은 부품을 따로 고르고 바꿀 수 있어 최고의 ASR·LLM·TTS를 조합하는 것, LLM이 텍스트로 일하므로 도구 호출(6.2 참조)·DB 연결·업무 규칙이 쉬운 것, 각 단계의 입출력 텍스트로 디버깅이 쉬운 것, 구조화된 작업에서 성숙하고 안정적인 것입니다. 단점은 모든 응답 앞의 틈, 멈춤 구간에서 사용자를 끊을 수 있는 것, 백채널 불가, 바지인이 에이전트를 잘못 멈출 수 있는 것입니다. 풀 듀플렉스의 장점은 사람과 말하는 듯한 자연스러움, 아주 짧은 응답 틈, 잘 학습되었을 때 멈춤·끼어들기·겹침 발화를 자연스럽게 처리하는 것, 백채널입니다. 단점은 모두 모델 안에 있어 말하는 내용을 통제하기 어렵고, 모델이 주로 오디오로 작업하기에 도구와 업무 규칙을 붙이기 어렵고, 두 사람의 겹치는 발화가 담긴 학습 데이터가 구하기 어렵고, 타이밍을 잘 못 배웠다면 사용자 위에 말을 얹거나 엉뚱한 때 침묵할 수 있는 것입니다.

선택은 업무 성격으로 정리됩니다. 주문을 확인하고 API를 호출하고 엄격한 규칙을 따라야 하는 고객 지원 에이전트에는 좋은 턴 감지와 바지인을 갖춘 하프 듀플렉스가 실용적인 선택인 경우가 많고, 동반자·어학 파트너처럼 자연스러운 흐름이 가장 중요한 경험에는 풀 듀플렉스가 더 나은 경우가 많습니다.

자주 묻는 질문의 답은 다음과 같습니다. 바지인은 풀 듀플렉스와 같지 않으며, 바지인은 사용자 발화 시작을 감지해 에이전트 목소리를 멈출 뿐이고 사용자의 말은 이후 새 턴으로 처리되지만 풀 듀플렉스 에이전트는 계속 말하면서 사용자를 듣고 이해합니다. 백채널은 상대가 말하는 동안 하는 "음", "네", "맞아요"로 "따라가고 있다"는 신호이며 하프 듀플렉스는 사용자 발화 중 낼 수 없고 풀 듀플렉스는 낼 수 있습니다. Moshi는 Kyutai가 2024년 공개한 풀 듀플렉스 음성 모델로 80ms 조각 위에서 사용자 스트림과 에이전트 스트림을 나란히 돌리며 논문 기준 단일 GPU에서 실제 지연이 약 200ms입니다. 풀 듀플렉스 에이전트는 침묵을 출력으로 다루어 매 조각마다 조용히 있을지 말할지를 정하고, 말하지 말아야 할 때 침묵 같은 오디오 토큰을 쓰며 별도 침묵 타이머는 없습니다.

고객 요구가 "도구 호출이 많고 규칙이 엄격하다"면 하프 듀플렉스의 지연과 말 끊김을 턴 감지와 바지인으로 줄이는 쪽을, "자연스러운 흐름이 곧 제품"이라면 풀 듀플렉스를 권하고 도구 연동 방식을 따로 설계합니다.

13.4 턴테이킹(Turn-Taking)

원문: What is turn-taking in a voice AI agent?

음성 에이전트의 품질은 모델 성능 못지않게 "언제 말하고 언제 멈추는가"에서 갈립니다. 이 절은 2026년 10월 글 기준으로 턴테이킹의 입문 개념을 잡고, 세부 기법은 13.5 이후 절의 주제입니다.

13.4.1 사람이 순서를 주고받는 방식

턴테이킹(turn-taking)은 두 화자가 누가 언제 말할지 정해 서로 말을 겹치지 않고 어색한 긴 침묵도 만들지 않는 방식입니다. 턴(turn)은 한 화자의 한 덩어리 발화이며, "오늘 날씨 어때?"가 턴 1이고 "맑고 28도예요."가 턴 2인 식으로 대화는 턴의 사슬입니다. 음성 AI 에이전트(콜센터 봇, 음성 비서, AI 리셉셔니스트)에게 턴테이킹은 세 질문에 반복해서 답하는 일입니다. 사용자가 말을 끝냈는가, 지금이 내가 말할 차례인가, 내가 말하는 중에 사용자가 다시 말하기 시작했는가.

사람은 턴테이킹에 아주 능숙합니다. 10개 언어의 대화를 조사한 연구에서 한 사람이 끝나고 다른 사람이 시작하기까지의 가장 흔한 간격은 0~200ms였습니다. 이 간격은 문장을 끝까지 듣고 답을 생각해 말하기 시작하기에는 너무 짧으므로, 사람은 상대가 아직 말하는 동안 답을 준비하며 상대가 끝날 시점을 예측합니다. 쓰는 신호는 세 가지입니다.

여기에 사람은 두 가지를 자연스럽게 합니다. 상대가 중요한 말로 끼어들면 멈추고, 상대가 말하는 동안 "응", "맞아", "그래" 같은 작은 소리로 듣고 있음을 보이되 이는 턴을 가져가지 않습니다. 음성 AI 에이전트는 이 전부를, 그것도 사용자를 볼 수 없는 전화선 위에서 배워야 합니다. FDE는 고객에게 "사람 대화의 틈이 200ms 안팎이니 우리 에이전트는 어디서 그 격차가 벌어지는지 보자"고 말하며 대화 기준선을 잡아 줍니다.

13.4.2 기계에게 어려운 이유

전형적인 음성 에이전트는 세 부분의 파이프라인입니다(13.2 참조). STT(ASR)는 사용자 목소리를 텍스트로, LLM은 텍스트를 읽고 응답을, TTS는 응답을 다시 목소리로 바꿉니다. 여기서 사용자의 말을 언제 LLM에게 보낼지 결정하는 무언가가 있어야 하는데, 너무 일찍 보내면 LLM이 반쪽짜리 질문에 답하고 너무 늦으면 사용자가 침묵 속에서 기다립니다(13.16 참조). 그 결정이 바로 턴테이킹입니다.

기계는 대화를 사람처럼 듣지 못하고, 예컨대 20ms마다 한 조각씩 잘린 연속 소리 스트림을 받을 뿐입니다. 문제는 같은 소리가 여러 뜻일 수 있다는 점입니다. 사용자가 꼬박 1초 조용하다면 다음 세 가지 중 하나입니다.

• 말을 끝내고 답을 기다리는 중입니다.
• 다음에 할 말을 생각하는 중입니다.
• 종이에 적힌 카드 번호를 읽어 보는 중입니다.

세 경우의 침묵은 소리로는 똑같고 맥락만이 구분해 줍니다. 그래서 에이전트는 두 종류의 실수를 합니다.

좋은 턴테이킹은 두 실수를 모두 최대한 낮추는 것이며 한쪽을 줄이면 다른 쪽이 늘어나는 균형입니다. 둘 중 어느 실수가 더 비싼지는 업무마다 다르므로, FDE는 고객 업무에서 끊기는 비용(예: 번호 수집)과 느린 비용(예: 간단한 문의)을 구분해 묻습니다.

13.4.3 침묵 대기 vs 의미 이해

턴테이킹은 두 가지 일로 나뉩니다. 발화 종료 감지(End-of-turn detection)는 사용자가 끝났음을 알아 에이전트가 말하기 시작하게 하는 일이며, 사용자 발화의 끝점을 찾는다는 뜻에서 엔드포인팅(endpointing)이라고도 합니다(13.5 참조). 끼어들기 처리는 에이전트가 말하는 중 사용자가 말을 시작하면 멈추게 하는 일입니다.

접근 1: 침묵 대기. 가장 단순한 생각은 사용자가 일정 시간 소리를 내지 않으면 턴이 끝났다고 보는 것입니다. 이를 위해 사용자가 말하고 있는지 알아야 하는데, 여기에 VAD(Voice Activity Detection)가 쓰입니다. VAD는 작고 빠른 구성 요소(보통 작은 모델)로, 아주 짧은 오디오 조각마다 사람 말이 있는지만 답합니다. 단어는 이해하지 못합니다.

VAD 위에 규칙을 얹습니다. VAD가 고정 시간(예: 700ms) 이상 무음을 보고하면 턴이 끝난 것으로 봅니다. 이 고정 시간이 침묵 임계값(silence threshold, silence timeout)입니다. 흐름은 "What is the weather today?" 발화 → VAD가 말, 말, 말 뒤 무음 → 무음 700ms 지속 → 발화 종료 감지 → 텍스트를 LLM으로 전송입니다. 이 방식은 단순하고 빠르고 쌉니다. 하지만 타임아웃에 숫자 하나를 골라야 하고 모두에게 맞는 숫자는 없습니다.

침묵은 문장이 완성되었는지 모릅니다. "제 번호는 98765" 뒤의 휴지와 "감사합니다" 뒤의 휴지는 똑같이 보입니다. 소리만 듣고 의미는 듣지 않는 것이 이 접근의 한계입니다. 이 대기 시간이 다른 모든 단계와 어떻게 맞물리는지는 지연 예산이 정합니다(13.14 참조).

접근 2: 의미 이해. 사람은 고정된 침묵을 기다리지 않고 말의 내용을 듣습니다. 시맨틱 턴 감지(semantic turn detection)는 모델이 단어(때로는 어조까지)를 읽고 사용자가 턴을 끝냈을 확률을 0~1로 예측하는 방식입니다. 1에 가까우면 끝났을 가능성이 높습니다.

실제로는 두 접근을 결합합니다. VAD가 무음을 감지하고, 턴 감지 모델이 그때까지의 단어를 읽어 문장이 완결로 보이면 짧게, 미완으로 보이면 길게 기다린 뒤 발화 종료를 선언합니다. 침묵 타임아웃은 고정 숫자가 아니라 사용자가 끝난 듯하면 짧고 생각의 중간이면 긴 값이 됩니다(13.6, 13.7 참조). 어떤 모델은 STT 텍스트만 읽고, 어떤 모델은 오디오를 직접 들어 평서문 끝의 하강 음높이 같은 어조까지 씁니다. 이 대기 중에 에이전트가 응답을 미리 준비하는 방식이 투기적 생성입니다(13.19 참조).

FDE는 고객 에이전트가 고정 타이머만 쓰는지 의미 모델을 쓰는지를 확인하고, 카드 번호처럼 미완 확률이 높은 구간을 골라 시험합니다.

13.4.4 끼어들기와 소음 구분

에이전트가 긴 항공편 목록을 읽는 중에 사용자가 "잠깐, 오전 항공편만 원해요"라고 하면 에이전트는 멈추고 들어야 합니다. 에이전트가 말하는 중에 사용자가 말하는 것을 바지인(barge-in)이라 합니다(13.11 참조). 처리하려면 에이전트는 말하는 동안에도 VAD를 켜 둡니다. 흐름은 에이전트 발화 → VAD가 사용자 발화 감지 → 에이전트 오디오 즉시 중단 → 사용자의 새 턴 청취 → 새 요청으로 LLM 응답입니다. 중요한 세부가 세 가지 있습니다.

• 빨리 멈춰야 합니다. 사용자가 말을 시작한 뒤에도 2초 더 말하면 사용자는 무시당했다고 느낍니다.
• 자기 목소리를 들으면 안 됩니다. 마이크가 스피커에서 나오는 에이전트 목소리를 집어 사용자로 오인하면 스스로 끼어드는데, 마이크 입력에서 에이전트 목소리를 제거하는 에코 제거로 해결합니다.
• 사용자가 실제로 들은 것을 기억해야 합니다. 다섯 문장을 계획했다가 두 문장 뒤에 끼어들렸다면 대화 이력(6.7 참조)에는 그 두 문장만 기록되어야 합니다. 그렇지 않으면 LLM이 말한 적 없는 정보를 사용자가 들었다고 가정합니다.

그렇다면 사용자가 소리를 낼 때마다 멈춰야 할까요. 아닙니다. 에이전트가 말하는 동안 사용자는 "으응", "네", "맞아요", "음-음"이라고 할 수 있고 이를 백채널(backchannel)이라 하며 "듣고 있으니 계속하세요"라는 뜻이지 턴을 가져가려는 시도가 아닙니다(13.13 참조). 또 기침, 문 닫는 소리, 배경 TV, 방 안의 다른 사람 말처럼 사용자의 말이 아닌 소리도 있습니다. 이 모두에 멈추면 문장이 계속 끊기므로 구분해야 합니다(13.12 참조).

일반적 방법은 멈추기 전에 조금 기다리는 것입니다. 사용자가 최소 시간(예: 0.5초) 이상 계속 말할 때만 멈추거나, 사용자의 말이 단순한 "네" 이상일 때만 멈춥니다. 백채널을 인식하도록 학습된 모델을 쓰는 시스템도 있습니다.

파이프라인 에이전트는 하프 듀플렉스로 동작해 대화를 엄격한 턴으로 다룹니다. 사용자 차례 아니면 에이전트 차례이고 턴테이킹 시스템이 전환을 정하며, 바지인이 있어도 말하는 동안 듣는 이유는 언제 멈출지 알기 위해서일 뿐입니다. 풀 듀플렉스 에이전트는 두 사람의 전화처럼 항상 동시에 듣고 말합니다(13.3 참조). Kyutai의 Moshi 같은 풀 듀플렉스 음성 모델은 사용자 오디오를 받아 에이전트 오디오를 병렬 스트림으로 함께 내므로 "이제 턴이 끝났다"고 말하는 별도 구성 요소가 없고, 언제 말하고 침묵하고 "으응" 하고 멈출지를 대량의 대화 오디오 학습에서 모델이 배웁니다.

풀 듀플렉스가 사람의 말하기에 더 가깝지만 파이프라인이 만들고 통제하고 도구(6.2 참조)와 업무 로직을 붙이기 쉬우므로, 상용 음성 에이전트 다수는 세심한 턴테이킹을 갖춘 파이프라인을 씁니다.

식당 예약 전화로 전체를 따라가 봅니다.

자주 묻는 질문의 답은 다음과 같습니다. 엔드포인팅은 발화 종료 감지의 다른 이름이며 사용자 발화의 끝점을 찾아 에이전트가 말을 시작하게 하는 일로, 단순형은 고정 침묵을 기다리고 나은 형은 단어도 읽어 문장 완결을 판단합니다. 좋은 침묵 타임아웃이라는 단일 숫자는 없고 300ms처럼 짧으면 빠르지만 생각 중에 끼어들고 1,500ms처럼 길면 끼어들지는 않지만 모든 응답이 느리며, 시맨틱 턴 감지가 문장이 완결로 보이면 짧게, 아니면 길게 만들어 해결합니다. 에코 제거가 필요한 이유는 에이전트 자신의 목소리를 사용자로 오인해 계속 스스로 끼어들기 때문입니다. 사용자가 끼어들면 에이전트는 오디오를 즉시 멈추고 이력에는 사용자가 실제로 들은 부분만 남깁니다. 사람의 턴 간격은 10개 언어 연구에서 가장 흔하게 0~200ms였습니다.

고객과의 대화에서는 "끝났나, 내 차례인가, 다시 말하기 시작했나" 세 질문을 에이전트가 각각 어떤 신호(침묵, 의미, 어조)로 답하는지 짚어 보면 현재 구현의 수준이 드러납니다.

13.5 엔드포인팅(Endpointing)

원문: How does endpointing decide when the user has finished speaking?

음성 에이전트의 응답은 "사용자가 말을 마쳤다"는 판단이 내려진 뒤에야 시작되므로, 이 판단이 느리면 전체 응답이 느리고 틀리면 문장 반쪽에 답합니다. 이 절은 2026년 10월 글 기준으로, 발화 종료를 판단하는 네 가지 접근(침묵 타이머, 단어, 목소리, 신호 결합)을 단순한 것부터 차례로 비교합니다. (턴테이킹 전반은 13.4 참조)

13.5.1 고정 침묵 타이머

엔드포인팅(Endpointing)은 사용자가 자기 차례의 발화를 끝낸 시점을 찾아내는 과정이며 end-of-turn detection, turn detection이라고도 부릅니다. 가장 단순한 구현이 고정 침묵 타이머입니다. "사용자가 700ms 동안 조용하면 발화가 끝난 것"이라는 규칙이며, 700ms는 이해를 돕기 위한 예시값입니다. 실제 시스템은 수백 ms에서 1초 안팎 사이에서 값을 고릅니다.

"오늘 델리 날씨 어때?"라는 질문에서 동작은 다음 순서입니다.

1. 사용자가 말하는 동안에는 타이머가 돌지 않습니다.
2. "오늘"에서 말을 멈추면 타이머가 0ms에서 시작합니다.
3. 침묵이 이어져 700ms에 도달하면 에이전트가 발화 종료로 판정합니다.
4. 700ms 전에 사용자가 다시 말하면 타이머는 0으로 돌아갑니다.

이 방식의 장점은 구현이 쉽고 빠르게 돈다는 점입니다. 약점은 숫자 하나로 모든 상황을 감당할 수 없다는 점입니다.

• 짧게 잡으면 생각하느라 멈춘 사용자를 끊습니다.
• 길게 잡으면 "네" 한마디에도 응답이 느려집니다. 사용자가 분명히 끝냈는데도 에이전트는 700ms를 다 기다려야 하므로, 모든 응답이 최소한 대기 시간만큼 늦어집니다.

타이머는 침묵만 듣고 침묵은 끝을 보증하지 않으므로, 고객 시나리오가 단답형이면 짧은 값, 긴 설명형이면 긴 값이 필요하다는 점부터 확인합니다. (고정 값의 한계를 사용자별로 풀어내는 방식은 13.7 참조)

13.5.2 VAD의 작동 방식

침묵 타이머가 돌려면 기계가 침묵과 발화를 구분해야 하며, 그 일을 VAD(Voice Activity Detection, 음성 활동 감지)가 맡습니다. VAD는 오늘날 대개 작은 신경망이며, 매 순간 사람이 말하고 있는지를 알려줍니다.

• 마이크의 연속 오디오를 프레임(frame)이라는 20~30ms 정도의 조각으로 자릅니다.
• 프레임마다 0~1 사이 점수를 냅니다. 1에 가까우면 "누군가 말한다", 0에 가까우면 "아무도 말하지 않는다"입니다.
• 임계값(예: 0.5)보다 높으면 발화, 낮으면 침묵으로 라벨을 붙입니다.

표 13.5.2 — 프레임 1~3은 발화, 4부터 침묵이 시작된 예시입니다.

여기서 침묵은 소리가 0이라는 뜻이 아닙니다. 방에는 대개 선풍기나 도로 소음이 있고, 좋은 VAD는 사람 말소리와 배경 소음을 구분하도록 학습됩니다. 오디오의 크기만 보던 예전 방식은 시끄러운 방에서 자주 실패했습니다. 타이머와의 관계는 단순합니다. 타이머는 VAD가 "침묵"이라고 말한 시간을 셉니다. 프레임이 30ms이면 700ms는 700 / 30 = 23.3, 즉 연속 약 23개의 침묵 프레임입니다.

고객 환경이 소음이 큰 매장이나 차량이라면 VAD의 소음 구분 성능이 침묵 타이머 전체의 품질을 좌우하므로, 그 환경의 녹음으로 VAD를 먼저 시험해 봅니다.

13.5.3 단어를 읽는 방식

사람은 소리가 멈추기 전에도 문장이 끝났는지 알 수 있습니다. "오늘 델리 날씨 어때"는 완결이고 "오늘 날씨가 어디"는 장소를 기다리는 미완성입니다. 에이전트도 같은 판단을 할 수 있습니다. 사용자가 말하는 동안 음성 인식이 오디오를 조각 단위로 텍스트로 바꾸는 스트리밍 음성 인식이 돌고 있으므로, 지금까지의 텍스트가 항상 손에 있기 때문입니다.

이 텍스트를 작은 모델에 넣어 "문장이 완결인가, 더 말할 것인가"를 묻는 모델이 턴 감지기(turn detector), 또는 end-of-turn 모델입니다. 실제 대화에서 각 텍스트에 "끝남/안 끝남"을 붙인 데이터로 학습하며 확률을 냅니다. 아래 숫자는 이해를 위한 예시입니다.

표 13.5.3 — 미완성 문장에는 낮은 확률, 완결 문장에는 높은 확률이 나옵니다.

많은 턴 감지기는 현재 문장만이 아니라 대화의 마지막 몇 개 메시지도 읽습니다. 에이전트가 "전화번호가 어떻게 되시나요?"라고 물은 뒤 사용자가 "98765"에서 멈추면, 질문을 아는 모델은 전화번호가 보통 더 긴 숫자라는 점을 알고 아직 끝나지 않았다고 판단합니다. (구조화 입력은 13.10 참조) 확률은 대기 시간으로 이어집니다. 확률이 높으면 200ms처럼 짧게, 낮으면 2초처럼 길게 기다립니다. "항공편을 예약하고 싶은데 ... 음 ... 뭄바이"에서 "to" 뒤에 멈추면 모델이 미완성으로 보고 오래 기다리므로, 사용자가 "뭄바이"를 말한 뒤에야 빠르게 응답합니다.

• 장점: 분명히 끝나지 않은 문장을 알아보므로 끊는 빈도가 줄어듭니다.
• 단점 1: 음성 인식 텍스트에 의존하므로 텍스트가 틀리거나 늦으면 판단도 틀리거나 늦습니다.
• 단점 2: 텍스트는 말투를 잃습니다. 구두점 없는 인식 결과에서 "You are coming."과 "You are coming?"은 같게 보이지만 소리는 크게 다릅니다.

텍스트 기반 감지기를 도입할 때는 고객 환경에서 음성 인식 지연과 오인식률이 얼마인지 먼저 묻습니다. 판단의 품질이 그 텍스트의 품질을 넘지 못하기 때문입니다.

13.5.4 목소리를 듣는 방식

문장을 끝낼 때 목소리 자체가 단서를 줍니다. 이 단서가 운율(prosody)이며 음의 높낮이, 말의 속도, 소리를 늘이는 방식 같은 말의 선율과 리듬을 가리킵니다.

• 하강 음높이: 평서문 끝에서는 보통 내려갑니다. "집에 가요."는 낮게 끝납니다.
• 상승 음높이: 의문문 끝에서는 보통 올라갑니다. "집에 가요?"는 높게 끝납니다.
• 느려짐: 끝낼 때 마지막 단어를 조금 늘이는 경향이 있습니다.
• 필러 소리: "음", "어"는 대개 아직 생각 중이라는 뜻입니다. 많은 음성 인식 모델이 이 소리를 텍스트에서 빼므로 오디오만 이를 간직합니다.
• 숨 들이쉬기: 짧은 들숨은 곧 이어 말한다는 신호인 경우가 많습니다.

오디오 기반 턴 감지기는 텍스트가 아니라 오디오를 직접 듣고, 녹음된 대화에서 "여기서 차례가 끝났다/아니다"를 붙인 데이터로 단서를 배웁니다. 사용자가 "택시가 필요한데"라고 말하고 "그리고 호텔 방도"를 덧붙이려고 멈추었다면, 텍스트만 보면 완결된 요청처럼 보이지만 목소리는 떨어지지 않고 평평하게 유지되므로 오디오 모델은 이어질 것으로 판단합니다.

• 장점: 질문의 어조나 생각하는 멈춤처럼 텍스트에 없는 단서를 잡고, 음성 인식이 끝나기를 기다리지 않아도 됩니다.
• 단점: 운율은 사람, 언어, 억양마다 달라서 한 집단으로 학습한 모델이 다른 집단에서는 성능이 떨어질 수 있습니다.

고객 사용자의 언어와 억양 분포가 학습 데이터와 다를 때는 오디오 모델의 성능이 낮아질 수 있으므로, 실제 사용자 샘플로 평가해 본 뒤에 도입합니다.

13.5.5 신호 결합

세 신호는 각기 강한 곳과 약한 곳이 있습니다.

표 13.5.5 — 세 신호의 강점과 약점은 서로를 보완합니다.

그래서 많은 현대 음성 에이전트가 세 신호를 결합합니다(침묵 기반과 모델 기반의 비교는 13.6 참조). 구조는 아래와 같습니다.

flowchart TD
    A[마이크 오디오] --> B[VAD: 발화 / 침묵]
    B -->|침묵 감지, 타이머 시작| C[턴 감지기: 단어, 목소리, 또는 둘 다]
    C --> D[사용자가 끝냈을 확률]
    D -->|높음| E[짧은 대기]
    D -->|낮음| F[긴 대기]
    E --> G[타이머가 대기 시간에 도달]
    F --> G
    G --> H[엔드포인트 확정, 에이전트 응답]
    B -.->|대기 중 발화 재개| I[타이머 리셋]

그림 13.5.5 — VAD가 타이머를 시작하고, 턴 감지기의 확률이 대기 시간을 정합니다.

• VAD는 가벼우므로 항상 돌고 턴 감지기를 언제 부를지 정합니다.
• 많은 시스템에서 턴 감지기는 침묵이 시작될 때만 돌아서, 무거운 모델이 계속 돌지 않게 합니다.
• 침묵 타이머는 남아 있지만 길이가 고정이 아니라 턴 감지기의 확신도에 따라 바뀝니다.
• 대기 중 사용자가 다시 말하면 VAD가 발화를 감지하고 타이머를 리셋합니다.
• 보통 최대 대기 시간이 있습니다. 턴 감지기가 "안 끝났다"고 해도 무한정 기다리지 않고, 침묵이 오래가면 에이전트가 차례를 가져갑니다.

"알람 좀 맞춰줘 ... 음 ... 아침 일곱 시로?"를 처음부터 끝까지 따라가 봅니다.

1. "알람 좀 맞춰줘 ... 음 ..." 뒤에 멈춥니다. VAD가 침묵을 감지하고 타이머가 시작됩니다.
2. 턴 감지기가 미완성 문장과 "음" 소리를 확인하여 낮은 확률을 내므로 대기 시간이 길어집니다.
3. 긴 대기가 끝나기 전에 사용자가 다시 말하면 VAD가 발화를 감지해 타이머가 리셋되고, 사용자는 "아침 일곱 시로"를 말합니다.
4. 다시 멈추면 VAD가 침묵을 감지하고 타이머가 새로 시작됩니다.
5. 턴 감지기가 완결된 질문과 끝의 올라가는 음높이를 확인하여 높은 확률을 내므로 대기 시간이 짧아집니다.
6. 짧은 대기가 끝나 엔드포인트가 확정되고 에이전트가 "알겠습니다, 오전 7시 알람을 맞췄습니다"라고 답합니다.

멈춤에서 끊기지 않았고 진짜 끝에서 빠르게 응답한 것입니다. 결합 구조를 평가할 때는 최대 대기 시간이 설정되어 있는지, 대기 중 발화 재개 시 타이머가 리셋되는지를 가장 먼저 확인합니다.

13.5.6 너무 오래 vs 너무 일찍

엔드포인팅 시스템은 두 종류의 실수 사이에서 균형을 잡아야 합니다.

• 이른 엔드포인트(끊기): 사용자는 멈춘 것뿐인데 끝났다고 판단합니다. 에이전트가 반쪽 요청에 답하여 사용자를 짜증나게 하고 틀린 답을 내기 쉽습니다.
• 늦은 엔드포인트(오래 기다림): 사용자는 끝났는데 에이전트가 계속 기다립니다. 느리고 부자연스럽게 느껴집니다.

대기를 줄이면 늦은 엔드포인트는 줄고 이른 엔드포인트는 늘며, 늘리면 반대가 됩니다. 그래서 팀은 두 지표를 모두 잽니다.

• 지연: 사용자가 실제로 끝낸 시점부터 에이전트가 끝났다고 판단하기까지 걸린 시간입니다.
• 끊김률(cut-off rate): 에이전트가 너무 일찍 판단해 사용자의 말을 끊은 빈도입니다.

이 둘을 보며 용도에 맞게 대기 시간과 확률 임계값을 조정합니다. "불 꺼줘" 같은 빠른 명령용이면 대기를 짧게 잡을 수 있고, 사용자가 긴 문제를 설명하는 고객 지원용이면 길게 잡아야 합니다. (대기가 전체 응답 단계에서 차지하는 몫은 13.14 참조)

오류는 완전히 없앨 수 없으므로 엔드포인트 주변에 안전장치를 둡니다.

• 다시 말하기 시작할 때: 엔드포인트를 너무 일찍 잡았고 사용자가 이어 말하면, VAD가 발화를 다시 감지하여 에이전트가 응답을 멈추고 나머지 요청을 계속 듣습니다. 사용자가 언제든 에이전트에 끼어들 수 있는 이 동작이 바지인(barge-in)입니다. (13.11 참조)
• 작업을 미리 시작하기: 일부 시스템은 엔드포인트의 첫 징후에서, 확신이 서기 전에 답변 준비를 시작합니다. 사용자가 계속 말하면 그 작업은 버려져 계산 비용이 들고, 실제로 끝났다면 답이 이미 일부 준비되어 대기 시간이 가려집니다. (13.19 참조)

고객과 정할 일은 두 지표의 목표치입니다. "지연 몇 ms 이하, 끊김률 몇 % 이하"처럼 숫자로 합의해 두면 대기 시간 조정이 감이 아니라 측정의 문제가 됩니다.

보충: 자주 나오는 질문

• 엔드포인팅과 VAD는 같은가: 같지 않습니다. VAD는 작은 오디오 프레임마다 사람이 말하는지만 알려주고, 엔드포인팅은 그 침묵 신호에 더해 단어와 목소리까지 보아 차례가 끝났는지 결정합니다. VAD가 침묵으로 표시한 멈춤이 항상 차례의 끝은 아닙니다.
• 얼마나 기다려야 하나: 단일 정답이 없습니다. 고정 타이머는 수백 ms에서 1초 안팎이고, 턴 감지기를 쓰면 끝났을 가능성이 높을 때 200ms 정도의 짧은 대기, 미완성으로 보일 때 2초 정도의 긴 대기로 바뀝니다.
• 필러 소리가 왜 중요한가: "음", "어"는 아직 생각 중이라는 신호인데 많은 음성 인식 모델이 이를 텍스트에서 빼므로, 텍스트 기반 감지기는 이를 보지 못하고 오디오 기반 감지기만 들을 수 있습니다.

13.6 침묵 기반 vs 모델 기반 턴 감지

원문: How do silence-based and model-based turn detection differ?

턴 감지(turn detection)를 구현하는 길은 크게 "일정 길이의 멈춤을 기다리는 방식"과 "학습된 모델로 끝날 확률을 예측하는 방식" 두 갈래이며, 어느 쪽을 고르느냐가 응답의 속도와 끊김을 함께 결정합니다. 이 절은 2026년 10월 글 기준으로 두 방식의 동작, 한계, 병행 구조, 선택 기준을 비교합니다. (엔드포인팅의 네 접근은 13.5 참조)

13.6.1 침묵 기반의 동작과 문제

턴 감지는 사용자가 자기 차례를 끝낸 시점(end of turn)을 정해서 에이전트가 언제 말을 시작할지 알려주는 일이며, end-of-turn detection, 엔드포인팅(13.5 참조)과 같은 일을 가리킵니다. 실패 방식은 두 가지입니다. 너무 일찍 판단하면 문장 중간에 끼어들고, 너무 늦게 판단하면 대화가 느려집니다.

침묵 기반 방식은 사용자가 충분히 오래 말소리를 내지 않으면 끝났다고 가정합니다. 구성 요소는 둘입니다.

• VAD: 마이크 오디오를 예컨대 30ms 조각으로 받아 조각마다 "발화/비발화"를 말하는 작은 모델입니다.
• 침묵 타임아웃(silence timeout): VAD가 "비발화"를 연속으로 말한 시간이 이 값에 도달하면 차례가 끝났다고 선언합니다. 예시값은 700ms입니다.

식당 예약 "4명 자리를 예약하고 싶어요" 흐름은 다음과 같습니다.

1. 사용자가 말하는 동안 VAD는 모든 조각을 "발화"로 판정합니다.
2. 사용자가 멈추면 "비발화"가 나오고 타이머가 시작됩니다.
3. 200ms 시점에는 아직 침묵이므로 계속 기다립니다.
4. 700ms에 도달하면 타임아웃이 됩니다.
5. 시스템이 턴 종료를 선언하고 음성을 다음 단계로 넘겨 응답을 만듭니다.
6. 700ms 전에 다시 말하면 타이머가 0으로 돌아가 턴이 이어집니다.

핵심 로직은 카운터 하나입니다.

if vad.is_speech(chunk):
    user_spoke = True; silence_ms = 0      # 말하는 중이면 리셋
elif user_spoke:
    silence_ms += CHUNK_MS                 # 말한 뒤의 침묵만 누적
    if silence_ms >= SILENCE_TIMEOUT_MS:
        end_of_turn()

user_spoke 플래그는 사용자가 한 번이라도 말한 뒤의 침묵만 세게 하는 장치입니다. 이것이 없으면 조용한 방에서 빈 턴이 끝없이 반복해서 끝납니다. 장점은 구현이 쉽고, VAD가 작은 모델이라 빠르고 싸며, 단어를 보지 않으므로 거의 모든 언어에 통하고, 조절할 숫자가 하나뿐이라 튜닝이 쉽다는 점입니다.

문제는 이 방식이 멈춤의 길이 하나만 본다는 데 있습니다. 사람은 문장 중간에서도 자주 멈춥니다. "4명 자리를 ... 음 ... 예약하고 싶어요"에서 "자리를" 뒤의 멈춤이 700ms를 넘으면 에이전트는 미완성 문장에 답하고 사용자를 끊습니다. 이를 막으려고 타임아웃을 2초로 늘리면 완결된 문장 뒤에도 2초를 기다립니다. 짧은 타임아웃은 빠르지만 생각하는 사용자를 끊고(13.9 참조), 긴 타임아웃은 끊김은 줄지만 모든 응답이 느립니다. 한 숫자가 모든 사용자와 문장에 맞을 수 없습니다. (사용자별 적응은 13.7 참조) 고정 멈춤이 실패하는 사례는 더 있습니다.

• 숫자 읽기: "내 번호는 98765 ... 43210"처럼 자릿수 묶음 사이에서 멈춥니다(13.10 참조).
• 소리 내어 생각하기: "금요일로, 음, 잠깐 확인해 보고, 금요일."
• 짧은 완결 답: "확정할까요?"에 "네"라고 해도 타임아웃을 끝까지 기다립니다.
• 배경 소음: 시끄러운 방에서는 VAD가 계속 말하는 중으로 오인하여 턴 종료가 늦게 감지됩니다.

고객이 "응답이 느리다"와 "자꾸 끊는다"를 동시에 말하면, 타임아웃 하나로 두 불만을 모두 풀 수 없다는 신호이므로 침묵 기반 단독 구조를 의심합니다.

13.6.2 모델 기반의 동작

사람은 밀리초를 세어 차례를 판단하지 않고 단어, 문장의 완결감, 끝에서 내려가는 음 같은 단서를 씁니다. 모델 기반 턴 감지는 대화를 보고 사용자가 차례를 끝냈을 확률을 예측하는 학습된 모델을 씁니다. "발화/비발화"의 이분법 대신 0~1 확률을 내며, 예시는 아래와 같습니다.

표 13.6.2 — 같은 발화의 앞부분과 전체에서 확률이 크게 달라집니다.

모델은 각 예시에 "턴 완료/미완료"가 붙은 대량의 대화로 학습하여 사람이 끝을 알리는 패턴을 익힙니다. 확률이 높으면 짧은 멈춤 뒤에 응답하고, 낮으면 침묵이 있어도 더 기다립니다. 앞의 예에서 "자리를" 뒤의 멈춤에서는 확률이 낮아 계속 기다리고, "4명이요"를 말하고 멈추면 확률이 높아 빠르게 응답하므로 끊지도 느리지도 않습니다.

• 장점: 생각하느라 멈추는 사용자를 훨씬 덜 끊고, 완결이 분명할 때 더 빨리 답하며, 침묵만이 아니라 단어의 의미와 목소리 톤을 씁니다.
• 단점 1: 추가 모델이 필요해서 계산 자원을 더 씁니다.
• 단점 2: 학습된 언어에서만 잘 동작합니다.
• 단점 3: 틀릴 수 있으므로 백업으로 침묵 타임아웃을 유지합니다.

다국어 고객이라면 모델이 지원하는 언어 목록이 도입의 첫 질문입니다.

13.6.3 텍스트 기반 vs 오디오 기반 모델

모델이 무엇을 보느냐에 따라 두 유형이 있습니다.

텍스트 기반 모델은 먼저 음성 인식이 사용자 말을 전사(transcript)로 만들고, 보통 작은 언어모델인 턴 감지 모델이 전사와 직전 몇 개 메시지를 읽어 문장이 완결인지 예측합니다. 에이전트가 "전화번호가 어떻게 되시나요?"라고 물었고 사용자가 "98765"라고 했다면, 질문을 아는 모델은 전화번호가 보통 더 긴 숫자라는 점으로 아직 끝나지 않았다고 판단합니다.

오디오 기반 모델은 텍스트 없이 목소리 소리를 직접 듣습니다. 음높이가 끝에서 내려가는지(끝난 평서문) 유지되는지(미완성), 문장 끝에서 느려지는지, "음", "어" 같은 필러가 있는지 같은 단서를 잡습니다. 일부 시스템은 한 모델에 단어와 소리를 함께 넣어 의미와 어조를 모두 얻습니다.

표 13.6.3 — 두 유형의 강약은 서로 반대편에 있습니다.

고객의 통화 오디오가 음성 인식에서 자주 오인식된다면 텍스트 기반의 약점이 커지므로, 전사 정확도를 먼저 측정해 유형 선택의 근거로 삼습니다.

13.6.4 파이프라인에서 병행하기

모델 기반 감지는 대개 VAD를 대체하지 않고 그 위에서 동작합니다. VAD는 싸므로 항상 돌지만, 더 큰 턴 감지 모델을 30ms 조각마다 돌릴 수는 없습니다. 그래서 VAD가 200ms 같은 짧은 멈춤을 감지했을 때만 모델을 돌립니다.

flowchart TD
    A[사용자 발화] --> B[VAD: 발화인가]
    B -->|200ms 침묵| C[턴 감지 모델: 끝났는가]
    C -->|확률 0.8 이상| D[턴 종료 후 응답]
    C -->|확률 낮음| E[더 긴 침묵을 대기]
    E -->|최대 대기 3000ms 도달| D
    E -->|사용자 재발화| B

그림 13.6.4 — VAD가 모델을 부르고, 확률이 낮아도 최대 대기가 도달하면 응답합니다.

로직은 세 상수로 요약됩니다. SHORT_PAUSE_MS = 200(모델을 부르는 최소 멈춤), THRESHOLD = 0.8(끝났다고 보는 확률), MAX_WAIT_MS = 3000(백업 타임아웃)입니다. 멈춤이 200ms보다 짧으면 계속 듣고, 확률이 0.8 이상이면 곧바로 턴을 끝내며, 확률이 낮아도 침묵이 3초에 닿으면 턴을 끝내므로 에이전트가 멈춰 서지 않습니다. 원문의 코드는 짧게 쓰려고 매 점검마다 모델을 부르지만, 실제 시스템은 한 번의 멈춤에서 모델을 한 번만 돌리고 사용자가 다시 말할 때까지 결과를 재사용합니다.

식당 예시를 파이프라인에 통과시키면 다음과 같습니다.

1. "4명 자리를"까지 말하고 생각하느라 멈춥니다.
2. 200ms 침묵 후 모델이 0.05를 내고, 0.8 미만이므로 계속 기다립니다.
3. "음... 예약하고 싶어요"를 말하면 VAD가 발화를 감지해 침묵 카운터가 리셋됩니다.
4. 다시 멈추고 200ms 후 모델이 0.92를 내면 0.8 이상이므로 턴을 끝내고 응답합니다.

700ms 타임아웃이었다면 2단계의 생각하는 멈춤이 700ms를 넘을 때 끊겼을 것이고, 4단계에서는 700ms를 기다렸을 것입니다. 병행 구조에서는 생각하는 멈춤을 견디고, 끝난 뒤 200ms의 침묵에 모델 실행 시간을 더한 시간 뒤에 응답합니다. 그 마지막 대기까지 가리는 방법이 투기적 생성입니다(13.19 참조).

13.6.5 선택 기준

두 방식의 차이는 아래 표로 정리됩니다.

표 13.6.5 — 침묵 기반은 단순하고 폭넓으며, 모델 기반은 자연스럽고 무겁습니다.

침묵 기반이 맞는 경우는 프로토타입을 빨리 띄울 때, "불 켜줘" 같은 짧은 명령이 주일 때, 기기의 계산 능력이 제한적일 때, 턴 감지 모델이 없는 여러 언어를 지원해야 할 때입니다. 모델 기반이 맞는 경우는 자연스러운 사람다운 대화가 목표일 때, 사용자가 긴 문장으로 말하거나 생각하느라 멈추거나 숫자와 주소를 말할 때, 끊김과 느린 응답이 모두 경험을 해치는 고객 지원 통화일 때입니다. 실제 시스템은 대부분 VAD를 유지하고 그 위에 턴 감지 모델을 얹으며, 긴 침묵 타임아웃을 백업으로 둡니다. 모델이 틀리거나 계속 "안 끝났다"고 해도 3초 같은 백업이 있어야 에이전트가 영원히 기다리지 않습니다.

고객과의 질문은 세 가지로 좁혀집니다. 사용자가 짧은 명령형인지 긴 서술형인지, 지원해야 할 언어가 모델의 지원 범위 안인지, 단말이나 서버에서 추가 모델을 돌릴 자원이 있는지입니다.

13.7 동적 엔드포인팅(Dynamic Endpointing)

원문: How does dynamic endpointing adapt to how fast a user talks?

같은 800ms 대기가 어떤 사용자에게는 답답하고 어떤 사용자에게는 끊김이 됩니다. 이 절은 2026년 10월 글 기준으로, 사용자 본인의 평소 멈춤 길이를 배워 침묵 대기 시간을 사용자마다 바꾸는 동적 엔드포인팅을 수치 예제와 함께 설명합니다. (엔드포인팅 개요는 13.5 참조)

13.7.1 고정 침묵 타이머의 문제

엔드포인팅은 사용자가 말을 마친 시점을 정해 에이전트가 응답을 시작하게 하는 일이며, 한 턴(turn)은 한 화자가 상대가 답하기 전까지 이어 말한 하나의 발화 덩어리입니다. "2명 자리를 예약해 주세요 ... 저녁 8시로"에서 "2명" 뒤의 짧은 침묵이 요청의 끝인지 판단하는 일이 엔드포인팅입니다. 너무 일찍 판단하면 사용자를 끊고, 너무 늦으면 사용자가 침묵 속에서 기다립니다. (이 대기가 전체 응답 단계에서 차지하는 몫은 13.14 참조)

고정 타이머는 VAD가 "발화 없음"을 말하는 순간부터 시간을 세고, 침묵이 한계(예: 800ms)를 넘으면 사용자가 끝났다고 판단합니다. 문제는 사람마다 말 속도가 다르다는 점입니다. 숫자는 이해를 위한 예시입니다.

• 사용자 A(빠른 화자): 단어 사이의 평소 멈춤이 약 200ms입니다.
• 사용자 B(느린 화자): 평소 멈춤이 약 700ms이고 생각할 때는 900ms까지 늘어납니다.

같은 800ms 한계를 적용하면 결과가 갈립니다.

• A는 400ms의 침묵도 A에게는 이미 긴데 매번 800ms를 기다리므로 에이전트가 느리게 느껴집니다.
• B는 평소의 900ms 생각 멈춤이 800ms 한계를 넘어서 문장 중간에 응답이 시작되고 끊깁니다(13.9 참조).
• 한계를 낮추면 B가 더 자주 끊기고, 높이면 A가 더 오래 기다립니다.

고정 값은 모든 사용자를 같은 사람으로 취급하는 설계이므로, 고객 사용자층의 말 속도 분산이 크다면 고정 타이머 하나로 목표를 맞출 수 없습니다.

13.7.2 말 속도 측정

동적 엔드포인팅(Dynamic Endpointing)은 대기 시간을 고정하지 않고, 현재 사용자가 어떻게 말하는지와 지금까지 무슨 말을 했는지에 따라 바꾸는 엔드포인팅입니다. 핵심 발상은 침묵의 길고 짧음이 그 사용자의 평소 멈춤과 비교해서만 정해진다는 것입니다. A에게 500ms는 아주 긴 침묵이고, B에게 같은 500ms는 두 단어 사이의 평범한 멈춤입니다. 그래서 "침묵이 800ms를 넘었는가"가 아니라 "침묵이 이 사용자의 평소 멈춤보다 훨씬 길어졌는가"를 묻습니다.

속도를 재는 신호는 둘입니다.

• 멈춤 길이: 사용자가 말하는 도중 단어 사이에 생기는 짧은 침묵의 길이입니다.
• 말하기 속도(speaking rate): 1초에 말하는 단어나 음절 수입니다.

둘은 연결되어 있어서 빠른 화자는 초당 단어가 많고 멈춤이 짧으며, 느린 화자는 그 반대입니다. 원문은 침묵 타이머와 바로 맞물리는 멈춤 길이에 집중하는데, 침묵을 침묵과 비교하기 때문입니다. 말하기 속도도 같은 방식으로 쓸 수 있으며, 속도가 높으면 대기를 짧게, 낮으면 길게 잡습니다.

수집 방법은 다음과 같습니다.

• VAD가 오디오 조각마다 발화/비발화를 표시합니다.
• 사용자가 잠깐 멈췄다가 다시 말할 때마다 그 침묵의 길이를 기록합니다.
• 이것이 문장 내 멈춤(in-sentence pause)이며, 뒤에 사용자가 이어 말했으므로 턴을 끝내지 않은 멈춤입니다. "아직 안 끝났다"는 멈춤이 이 사용자에게 어떤 모양인지를 보여줍니다.
• 가장 최근 멈춤만(예: 마지막 5개) 보관해서, 대화 중에 사용자가 빨라지거나 느려져도 따라갑니다.

수집 대상이 "다시 말을 이은 멈춤"뿐이라는 점이 중요합니다. 끝난 턴 뒤의 침묵을 섞으면 평균이 부풀어 대기 시간이 불필요하게 길어집니다.

13.7.3 휴지를 대기 시간으로 환산

최근 멈춤 목록을 대기 시간으로 바꾸는 방법은 세 단계입니다.

1. 최근 멈춤의 평균을 구합니다. 사용자의 평소 멈춤입니다.
2. 평균에 배수(예: 2)를 곱합니다. 침묵이 평소 멈춤의 두 배로 분명히 길 때만 끝났다고 보는 발상입니다.
3. 결과를 최소·최대 한계(예: 300ms~2000ms) 안에 가둡니다.

waiting_time = clamp(average_pause * 2, 300, 2000)

clamp는 값을 한계 안에 유지한다는 뜻으로, 300 미만이면 300, 2000 초과이면 2000, 나머지는 값 그대로 씁니다. 최소 한계는 너무 빨리 응답하는 것을 막습니다. 아주 빠른 화자라도 100ms의 침묵으로 판단하기엔 짧습니다. 최대 한계는 영원히 기다리는 것을 막습니다. 아주 느린 화자에게도 에이전트는 어느 시점에 응답해야 합니다. 변형도 있습니다. 단순 평균 대신 최근 멈춤에 가중치를 더 주는 이동 평균을 쓰거나, 최근 가장 긴 멈춤보다 조금 높게 잡는 시스템이 있으며, 대기 시간이 사용자의 평소 멈춤과 함께 늘고 줄어든다는 원리는 같습니다. 대화 시작처럼 멈춤을 아직 보지 못했을 때는 기본 대기 시간(예: 800ms)으로 시작하여, 몇 개가 모이면 학습된 값으로 바꿉니다.

원문의 파이썬 구현은 이 구조를 그대로 옮긴 것입니다.

class DynamicEndpointer:
    def __init__(self):
        self.pauses = deque(maxlen=5)   # 최근 5개만 유지
        self.default_wait = 800         # ms
        self.multiplier = 2
        self.min_wait, self.max_wait = 300, 2000

    def waiting_time(self):
        if len(self.pauses) < 3:
            return self.default_wait    # 데이터 부족
        wait = sum(self.pauses) / len(self.pauses) * self.multiplier
        return max(self.min_wait, min(wait, self.max_wait))

pauses는 deque라서 여섯 번째 멈춤이 들어오면 가장 오래된 것이 자동으로 빠집니다. add_pause는 사용자가 멈췄다가 다시 말할 때마다 호출되고, is_turn_over는 침묵 중에 현재 침묵이 대기 시간에 도달하면 True를 돌려줍니다. 멈춤이 3개 미만이면 기본값 800ms를 씁니다.

두 사용자에게 적용한 계산은 아래와 같습니다.

표 13.7.3 — 같은 코드가 말 속도에 따라 400ms와 1400ms를 냅니다.

B가 900ms 생각 멈춤을 가졌을 때 고정 타이머는 900 > 800이라 끊지만, 동적 방식은 900 < 1400이라 계속 듣습니다. 전체를 비교하면 다음과 같습니다.

표 13.7.3b — 빠른 화자에게는 속도를, 느린 화자에게는 끊김 방지를 줍니다.

전체 흐름은 마이크 입력, VAD의 발화/침묵 표시, 문장 내 멈춤 저장(최근 5개), clamp(avg × 2, 300, 2000) 계산, 침묵이 대기 시간 이상인지 판정(예: 턴 종료 후 응답, 아니오: 계속 듣기) 순입니다. 고객과 협의할 값은 배수, 최소·최대 한계, 초기 기본값, 보관할 멈춤 개수의 네 가지이며, 이를 사용자 샘플의 끊김률과 지연으로 정합니다.

13.7.4 문장 의미 병용

속도만으로는 부족합니다. 같은 사용자가 같은 길이로 멈춘 두 문장을 봅니다.

• "델리 날씨 어때?"(완결)
• "델리 날씨가 ..."(미완성)

앞은 빨리 답하고 뒤는 같은 침묵이어도 기다려야 합니다. 그래서 많은 시스템이 지금까지의 말을 보고 사용자가 생각을 끝냈을 가능성을 점수로 내는 작은 턴 감지 모델(end-of-turn 모델, 13.6 참조)을 함께 씁니다. 문장이 완결로 보이면 대기를 줄이고, "그리고", "~에서" 같은 말로 끝나 미완성으로 보이면 대기를 늘립니다. 이해를 위해 배수를 바꾸는 방식으로 쓰면 다음과 같습니다.

• 완결로 보일 때: clamp(average_pause * 1.5, 300, 2000)
• 미완성으로 보일 때: clamp(average_pause * 3, 300, 2000)
• 모델이 확신하지 못하면: 기본 배수 2

python3으로 재계산한 값은 아래와 같습니다. 원문이 제시하지 않은 B의 완결 문장 값(1050ms)도 같은 식으로 구했습니다.

표 13.7.4 — B의 미완성 문장 대기 2100ms는 최대 한계 2000ms에 걸려 잘립니다.

일부 시스템은 말하는 방식도 듣습니다. 목소리의 높낮이, 크기, 리듬의 패턴이 운율(prosody)이며, 평서문 끝에서는 보통 내려가고 이어 말하려 할 때는 평평하게 유지되는 식으로 끝났는지에 대한 힌트를 하나 더 줍니다(13.5 참조). 이렇게 사용자의 속도와 단어의 의미를 결합해 대기 시간을 정하는 것이 동적 엔드포인팅입니다.

의미 신호까지 붙이는 비용은 턴 감지 모델의 추가 지연과 연산입니다. 고객 요구가 "자주 끊긴다"인지 "답이 느리다"인지에 따라 어느 배수를 먼저 조정할지 정합니다.

13.7.5 잘되는 곳과 실패하는 곳

잘되는 경우는 다음과 같습니다.

• 빠른 화자: 빠른 응답을 받아 대화가 자연스럽습니다.
• 느린 화자: 제2언어로 말하는 사람이나 말하면서 생각하는 사람이 덜 끊깁니다.
• 대화 중 속도 변화: 최근 멈춤만 쓰므로 사용자가 빨라지거나 느려질 때 따라갑니다.

실패하는 경우는 다음과 같습니다.

• 대화 시작: 멈춤 데이터가 없으므로 사용자의 멈춤을 배울 때까지 기본 대기 시간을 씁니다.
• 소음이 큰 방: VAD가 배경 소음을 발화로 오인하면 멈춤 길이가 틀리고 대기 시간도 틀립니다.
• 갑작스러운 긴 생각 멈춤: 평소 빠르게 말하는 사용자가 생각하느라 2초를 멈추면, 학습된 대기가 짧아서 너무 일찍 응답합니다. 문장 의미가 도움이 되지만 모든 경우를 고치지는 못합니다.

동적 엔드포인팅이 모든 오류를 없애지는 못합니다. 다만 평균보다 빠르거나 느린 사용자에게서 두 종류의 오류(끊김과 느린 응답)를 줄입니다. 파일럿에서는 첫 몇 턴의 기본값 구간과 소음 환경에서의 끊김률을 따로 측정해 보고, 이 구간이 목표 밖이면 기본 대기 시간이나 VAD 설정을 먼저 손봅니다.

13.8 말 끊김(Cutting Users Off)

원문: Why does a voice agent cut people off mid-sentence?

음성 에이전트가 문장 중간에 끼어드는 것은 고장이 아니라 침묵 타이머가 설계대로 동작한 결과입니다. 이 절은 2026년 11월 글 기준으로 끊김의 원인, 대기를 늘려도 해결되지 않는 이유, 의미 기반 해법, 끊겼을 때의 복구 절차를 설명합니다. (엔드포인팅 접근은 13.5, 침묵 기반과 모델 기반의 비교는 13.6 참조)

13.8.1 휴지는 문장 끝이 아니다

음성 에이전트는 대개 마이크, 음성 인식(STT), LLM, 음성 합성(TTS), 재생 순으로 동작합니다. LLM은 문장의 반쪽으로는 반쪽의 의미만 얻으므로 전체 문장이 필요하고, 그래서 LLM이 쓰기 전에 에이전트는 "사용자가 말을 마쳤는가"를 판단해야 합니다. 이 판단이 턴 감지이고 "끝났다"고 결론 내린 순간이 턴의 끝(end of turn)이며, 턴은 한 사람의 발화 차례입니다. 사람은 얼굴, 어조, 단어의 의미로 이를 무의식중에 판단하지만, 단순한 에이전트에게는 마이크에서 오는 소리의 흐름밖에 없습니다.

가장 단순한 방법은 침묵 타이머입니다. VAD(Voice Activity Detection)는 작고 빠른 모델로 초당 여러 번 "지금 누가 말하는가, 조용한가"에 답합니다. 규칙은 "VAD가 고정 시간보다 오래 침묵을 들으면 사용자가 끝났다"이며, 이 고정 시간이 침묵 임계값(silence threshold)으로 보통 수백 ms에서 1초 사이입니다. 임계값이 500ms이고 오디오 조각이 20ms이면, 침묵 조각이 500 / 20 = 25개 연속될 때 end_of_turn()이 호출됩니다.

for chunk in audio_stream:            # 20ms 조각
    if vad.is_speech(chunk):
        user_is_talking = True; silence_ms = 0
    elif user_is_talking:
        silence_ms += 20
    if user_is_talking and silence_ms >= 500:
        end_of_turn()                  # LLM에 넘기고 응답

단순하고 빠르지만 침묵만 볼 뿐 말의 내용은 보지 않습니다. 사람은 한 줄기로 말하지 않고 문장 한가운데에서도 자주 멈춥니다. 식당 예약 전화에서 "4명 자리를 예약하고 싶은데 ... [0.7초 멈춤] ... 내일 저녁에요"라고 말하면 흐름은 다음과 같습니다.

1. "4명 자리를 예약하고 싶은데"까지 말하는 동안 VAD는 발화를 듣고 타이머는 0입니다.
2. 생각하느라 멈추면 타이머가 20, 40, 60ms로 올라갑니다.
3. 타이머가 500ms에 닿습니다. 사용자의 멈춤은 700ms이므로 아직 끝나지 않았지만 에이전트는 이미 끝났다고 판단합니다.
4. 미완성 문장이 LLM으로 넘어가고 에이전트가 "네, 몇 분이신가요?"라고 말하기 시작합니다.
5. 사용자가 동시에 "내일 저녁에요"를 이어 말해 두 목소리가 겹칩니다.

타이머는 설계대로 동작했지만 규칙이 틀렸습니다. 500ms 멈춤이 항상 문장의 끝은 아닙니다. 끊김 불만을 받으면 먼저 로그에서 멈춤이 임계값보다 길었는지를 확인해 침묵 규칙의 한계인지 다른 원인인지 가립니다.

13.8.2 에이전트가 끊는 대표 원인

에이전트는 틈을 듣지만 그 의미는 "아직 안 끝났다"인 경우가 반복됩니다. 원인은 여섯 가지입니다.

표 13.8.2 — 여섯 원인은 모두 틈은 있지만 의미는 "계속"인 경우입니다.

여섯 원인에 공통된 점은 침묵 타이머가 의미를 볼 수 없다는 것입니다. 고객 환경이 전화망이라면 네트워크 지연이 만드는 가짜 침묵부터 확인하고, 전달된 오디오의 빠진 구간을 로그로 대조합니다.

13.8.3 더 오래 기다리지 않는 이유

가장 먼저 떠오르는 해법은 임계값을 500ms에서 2초로 늘리는 것입니다. 생각하는 멈춤 대부분이 임계값보다 짧아져서 끊김이 줄어듭니다. 그러나 사용자가 실제로 말을 마칠 때마다 에이전트가 응답 준비를 시작하기 전에 2초를 기다립니다(13.19 참조). 그 뒤에 LLM이 답을 쓰고 TTS가 음성으로 바꾸는 시간이 더해져 전체 지연이 길어지고(13.14 참조), 사용자는 에이전트가 들었는지 의심하여 "여보세요?"를 다시 말하며 상황을 더 혼란스럽게 합니다.

표 13.8.3 — 두 값은 한쪽을 얻으면 다른 쪽을 잃는 교환 관계입니다.

빠르게 느껴지게 만들려는 개발자들은 대개 임계값을 짧게 유지하고, 짧은 임계값은 더 많은 끊김을 낳습니다. 고정된 숫자 하나는 모든 멈춤에 맞을 수 없으므로 타이머보다 똑똑한 것이 필요합니다. 고객이 "그냥 더 기다리게 해달라"고 요청하면, 그 대가가 모든 응답의 고정 지연이라는 점을 수치로 보여 주고 대안을 제시합니다.

13.8.4 시맨틱 턴 감지

시맨틱 턴 감지(semantic turn detection)는 침묵만이 아니라 사용자가 한 말의 의미를 보고 턴의 끝을 정하는 방식입니다. semantic은 "의미와 관련된"이라는 뜻이며, "얼마나 조용했는가" 대신 "지금까지의 말이 완결된 생각처럼 들리는가"를 묻습니다. "4명 자리를 예약하고 싶은데"는 "for"로 끝나는 영어 문장처럼 미완성으로 들리므로 계속 들어야 하고, "4명 자리를 내일 저녁에 예약하고 싶어요."는 완결로 들리므로 응답해도 됩니다.

작고 빠른 턴 감지 모델이 지금까지의 말을 보고 끝났을 가능성을 점수로 냅니다. 음성 인식 텍스트를 읽는 모델도 있고, 목소리에 단서가 있으므로 오디오를 직접 듣는 모델도 있습니다(문장 끝에서 음높이가 보통 내려가고, 생각 중에는 평평하게 유지됩니다). 에이전트는 두 신호를 아래처럼 결합합니다.

done_score = turn_model.predict(transcript)   # 0.0 안 끝남 ~ 1.0 끝남
if done_score > 0.8 and silence_ms >= 300:
    end_of_turn()      # 완결 + 짧은 멈춤: 빠르게 응답
elif silence_ms >= 2000:
    end_of_turn()      # 미완성이지만 아주 긴 멈춤

• 문장이 완결로 보이고 멈춤이 짧으면 빠르게 응답합니다.
• 문장이 미완성으로 보이면 멈춤이 300ms를 넘어도 계속 기다립니다.
• 멈춤이 아주 길어지면 사용자가 멈췄을 가능성이 크므로 어쨌든 응답합니다.
• 0.8, 300, 2000은 이해를 위한 예시값이며 실제 시스템은 용도에 따라 조정합니다.

식당 예시에 적용하면, "4명 자리를 예약하고 싶은데"에서 점수가 낮아 침묵이 300ms를 넘어도 계속 듣고, "내일 저녁에요"를 말하고 멈추면 점수가 높아 300ms 뒤에 빠르게 응답합니다. 생각하는 멈춤은 기다렸고 진짜 끝에서는 빨랐습니다.

함께 쓰면 도움이 되는 보조 수단이 네 가지 있습니다.

• 맥락 인식 대기: 에이전트가 방금 "전화번호가 어떻게 되시나요?"라고 물었다면 숫자를 읽으며 멈추는 사람이 많으므로 더 오래 기다립니다.
• 필러 단어 인식: 마지막 단어가 "음", "어"이면 아직 생각 중이므로 더 기다립니다.
• 음성 인식의 신호: 일부 STT 서비스는 사용자가 말을 멈췄다고 판단하면 자체 신호를 보내며, 에이전트는 이를 하나의 단서로 씁니다(13.5 참조).
• 더 나은 VAD와 소음 제거: 깨끗한 오디오는 가짜 침묵과 가짜 발화 경보를 줄입니다.

시맨틱 방식을 도입할 때 고객에게 묻는 일은 어떤 입력이 많은지입니다. 숫자·주소·긴 설명이 많은 통화일수록 맥락 인식 대기의 효과가 큽니다.

13.8.5 오류 복구

어떤 턴 감지도 완벽하지 않으므로 에이전트가 너무 일찍 말을 시작하는 경우를 복구할 수 있어야 합니다. 이때 쓰는 것이 바지인(barge-in), 곧 에이전트가 말하는 도중 사용자가 끼어드는 기능입니다(13.11 참조). 에이전트가 말하다가 사용자의 음성이 다시 들리면 다음과 같이 동작합니다.

1. 즉시 말을 멈춥니다.
2. 하던 응답의 남은 부분을 버리고 사용자가 실제로 들은 부분만 기억합니다.
3. 계속 사용자의 말을 듣습니다.
4. 새 말과 이전 말을 이어 붙입니다. "4명 자리를 예약하고 싶은데"와 "내일 저녁에요"가 한 문장이 됩니다.
5. 전체 문장에 대해 새 응답을 씁니다.

사용자가 내는 모든 소리가 "멈춰"는 아닙니다. 에이전트가 말하는 동안 "응", "네", "맞아요"는 대개 "듣고 있어요, 계속하세요"라는 뜻이며, 이런 짧은 소리가 백채널(backchannel)입니다(13.13 참조). 이때마다 멈추면 이유 없이 계속 멈추므로 진짜 끼어들기와 구별해야 합니다(13.12 참조). 또 에이전트는 자기 목소리를 사용자로 오인하면 안 됩니다. 스피커폰에서는 에이전트의 목소리가 스피커로 나와 마이크로 되돌아오며, 마이크 오디오에서 에이전트 자신의 목소리를 지우는 에코 제거(echo cancellation)가 없으면 에이전트가 사용자가 말한다고 오인해 스스로를 끊습니다.

복구 설계는 두 가지를 보장해야 합니다. 끊긴 문장이 이어 붙여져 하나의 요청으로 처리되는지, 그리고 스피커폰 같은 환경에서 에코 제거가 켜져 있는지입니다. 고객 현장 시험 통화에 이 두 항목을 포함합니다.

보충: 자주 나오는 질문

• VAD는 소음에 약한가: 자동차 경적, 선풍기, 다른 사람의 말소리에 VAD가 혼동될 수 있습니다.
• 오디오를 직접 듣는 턴 감지 모델이 있는가: 있습니다. 텍스트를 읽는 모델과 오디오를 듣는 모델이 모두 있으며, 오디오는 음높이 같은 추가 단서를 줍니다.

13.9 긴 침묵(Long Pauses) 처리

원문: How does a voice agent handle long pauses when the user is thinking?

길이가 같은 2초의 침묵이 어떤 때는 "기다려 주세요"이고 어떤 때는 "이제 당신 차례입니다"입니다. 이 절은 2026년 10월 글 기준으로, 생각하는 침묵을 끝으로 오인하지 않기 위해 에이전트가 단어, 목소리, 시간을 함께 보고 대기 시간을 조절하는 방식과 그 실패 지점을 설명합니다. (끊김의 원인 일반은 13.8, 사용자별 적응은 13.7 참조)

13.9.1 생각하는 휴지

약국 음성 에이전트가 "생년월일이 어떻게 되시나요?"라고 묻고, 사용자가 "14일이고요 ... [2초 침묵] ... 3월, 1990년입니다"라고 답하는 장면을 봅니다. 가운데 2초의 침묵이 생각하는 휴지(thinking pause)이며, 사용자가 아직 자기 턴 안에 있는 침묵을 가리킵니다. 사용자는 몇 월인지 떠올리는 중입니다.

반대로 "14일, 3월, 1990년입니다." 뒤에 같은 2초가 흐르는 경우도 있습니다. 이때는 사용자가 이미 끝냈고 에이전트의 응답을 기다립니다. 두 침묵은 길이가 같지만 하나는 "기다려 주세요", 다른 하나는 "이제 당신 차례"라는 반대의 뜻입니다. 길이만 보는 시스템은 이 둘을 구분할 수 없습니다.

턴을 주고받는 구조(13.4 참조)에서 에이전트는 "사용자가 말을 마쳤는가"(end-of-turn detection, 엔드포인팅, 13.5 참조)를 계속 판단하며, 틀리면 둘 중 하나가 일어납니다.

• 너무 일찍 말하기: 사용자가 생각하는 중에 끼어들어 사용자가 끊긴 느낌을 받고, 에이전트는 반쪽 문장에 답합니다. 위 예에서는 "14일이고요"만 듣고 불완전한 날짜에 답합니다.
• 너무 늦게 말하기: 사용자가 끝낸 뒤에도 오래 기다려, 사용자는 침묵만 듣고 통화가 끊겼는지 의심합니다.

에이전트는 끊지 않는 것과 느리지 않는 것 사이에서 계속 균형을 잡습니다. 고객 시나리오에서 생년월일, 카드 번호처럼 사용자가 기억을 더듬는 질문이 있는지 먼저 목록으로 만들면, 긴 침묵 대책이 필요한 구간이 드러납니다.

13.9.2 고정·더 긴 타이머의 한계

에이전트는 먼저 VAD로 사용자가 침묵인지 압니다. VAD는 들어오는 오디오를 10~32ms 정도의 아주 작은 조각으로 받아 "이 조각에 사람이 말하는가"에 답하고, 그 결과로 "발화 발화 발화 침묵 침묵 침묵 침묵 발화 발화" 같은 신호를 만듭니다. 이 신호에서 사용자가 언제 말을 시작했는지와 얼마나 오래 침묵했는지를 알 수 있습니다. VAD는 말이 있는지만 알려주며 끝났는지는 알려주지 않습니다.

접근 1은 고정 타이머입니다. "X ms를 넘게 침묵하면 턴이 끝났다"이며 500ms를 예로 듭니다. "네", "아니요", "예약해 주세요" 같은 짧고 빠른 답에는 잘 맞습니다. 그러나 생각하는 사람은 반 초보다 오래 멈추는 일이 많습니다. 생년월일 예에서 사용자는 2초 멈췄고 에이전트는 반 초 뒤에 끼어들었습니다. 생각하는 사용자를 매번 끊는 것이 한계입니다.

접근 2는 타이머를 늘리는 것입니다. 3초로 잡으면 2초의 생각하는 휴지에는 끼어들지 않습니다. 그러나 모든 응답이 느려집니다. 사용자가 "네"만 말해도 3초를 기다리므로 통화 품질이 아주 나쁜 전화선으로 대화하는 느낌이 듭니다. 또 3초보다 긴 침묵은 여전히 끊깁니다.

표 13.9.2 — 숫자 하나는 짧은 답과 생각하는 사용자를 동시에 만족시키지 못합니다.

고정 타이머를 쓰는 기존 시스템을 인수받았다면, 응답 시간 분포에서 "네" 같은 짧은 답의 지연과 생년월일 같은 긴 답의 끊김을 따로 집계해 어느 쪽 불만이 큰지부터 봅니다.

13.9.3 단어와 억양 신호

접근 3은 단어를 봅니다. "14일이고요"처럼 "~고요"로 끝나는 문장은 뒤가 이어질 것을 알 수 있습니다. 에이전트는 이미 음성 인식(ASR, Automatic Speech Recognition)으로 말을 텍스트로 바꾸고 있으므로, 이 텍스트를 작은 언어모델에 넣어 "지금까지의 말로 보아 턴을 끝냈을 가능성은?"을 0~1 점수로 받습니다. 모델이 작은 이유는 모든 멈춤마다 아주 빨리 답해야 하기 때문입니다. 점수는 이해를 위한 예시입니다.

표 13.9.3 — 미완성 문장, 필러, 생각 표현이 낮은 점수의 단서입니다.

모델이 잡는 생각 신호는 세 종류입니다. 문장 끝의 "for", "of", "and", "but" 같은 불완전한 문장, "um", "uh", "hmm", "so" 같은 필러, "let me think", "give me a second", "let me check" 같은 생각 표현입니다. 모델은 대화 맥락도 봅니다. 에이전트가 생년월일을 물었다면 "14th of March, 1990"은 완전한 답이고, "14th of March"만으로는 연도가 빠졌으니 완결 가능성이 낮습니다.

그러나 완결된 문장이 끝이 아닌 경우도 있습니다. "2명 자리를 예약하고 싶어요." [멈춤] "아니, 4명으로 할게요." 앞부분은 완전한 문장이라 단어만 보면 "끝"이지만, 사람이 들으면 "2명"을 느리고 평평하게 말해서 아직 고민 중임을 압니다. 텍스트는 말하는 방식을 잃기 때문입니다.

접근 4가 이 간극을 메웁니다. 운율(prosody)은 말의 음높이, 속도, 크기, 소리의 길이입니다. "Okay."가 끝에서 내려가면 끝난 것처럼 들리고, "Okay..."가 평평하거나 올라가며 늘어지면 뒤가 이어질 것처럼 들립니다.

• 내려가는 음높이: 끝에서 내려가면 보통 사용자가 끝낸 것입니다.
• 평평하거나 약간 올라가는 음높이: 평서문 중간에서는 보통 이어 말할 것입니다. 영어의 많은 의문문도 끝에서 올라가므로 모델이 많은 예시로 차이를 학습해야 합니다.
• 늘어지는 소리: "sooooo", "and uhhhh"처럼 늘이면 보통 생각 중입니다.

일부 턴 감지 모델은 텍스트가 아니라 원시 오디오를 직접 듣고, 사용자 오디오의 마지막 몇 초를 보고 텍스트 모델처럼 점수를 냅니다. 수 시간 분량의 녹음된 사람 말에서 이 패턴을 학습합니다. 그러면 에이전트는 세 정보원을 갖습니다. VAD의 침묵 길이, 텍스트 모델의 단어 의미, 오디오 모델의 목소리 톤입니다. 좋은 시스템은 셋을 결합하며, "for" 뒤의 긴 침묵과 평평한 음높이는 생각하는 휴지일 가능성이 높고 "Yes." 뒤의 짧은 침묵과 내려가는 음높이는 턴의 끝일 가능성이 높습니다. 고객이 사용하는 언어가 이 모델의 학습 언어인지, 억양이 학습 분포에서 얼마나 벗어나는지를 도입 전에 확인합니다.

13.9.4 동적 대기 시간

세 신호를 행동으로 바꾸는 방법이 동적 대기 시간입니다(13.7 참조). 고정 타이머 하나 대신 에이전트가 확신에 따라 대기 시간을 고르며, 한계는 두 개입니다.

• 최소 대기: 사용자가 끝낸 것이 확실해도 기다리는 가장 짧은 시간입니다. 사용자에게 이어 말할 작은 기회를 주고, STT가 마지막 단어를 마무리할 시간을 줍니다.
• 최대 대기: 사용자가 생각 중이라고 판단해도 기다리는 가장 긴 시간입니다. 영원히 기다리는 것을 막습니다.

모델 점수로 두 한계 사이에서 대기 시간을 고릅니다. 사용자가 끝낸 것이 확실하면 최소에 가깝게, 아직 생각 중이라고 보면 최대에 가깝게 기다립니다. 최소 0.5초, 최대 4초를 가정한 두 예는 다음과 같습니다.

1. 예시 1: 사용자가 내려가는 음높이로 "Yes."라고 합니다. 모델이 턴이 끝났다고 확신하므로 에이전트는 0.5초를 기다리고 응답합니다.
2. 예시 2: 사용자가 "14일이고요 ..."에서 멈춥니다. 모델이 아직 안 끝났다고 확신하므로 대기가 4초 쪽으로 늘어납니다. 사용자가 2초 안에 "3월, 1990년입니다"를 말해 끼어들지 않았고, 문장이 완결되었으니 0.5초 근처만 기다리고 응답합니다.

대기 중에도 에이전트는 계속 점검합니다. 사용자가 다시 말하면 타이머가 리셋되고 새 단어가 같은 턴에 붙습니다. 이렇게 사용자가 확실히 끝났을 때는 빠르고 확실히 생각 중일 때는 인내합니다. 최소·최대 두 값을 고객 업무별로 다르게 둘 수 있는지가 설계 질문입니다. 숫자 입력 구간만 최대 대기를 키우는 식의 조정이 가능합니다.

13.9.5 너무 일찍 말하기 시작했을 때

어떤 감지도 완벽하지 않아서, 사용자가 생각 중인데 에이전트가 응답을 시작하는 일이 생깁니다. 이 실수를 처리하는 것이 바지인(barge-in), 곧 끼어들기 처리입니다(13.11 참조). 흐름은 다음과 같습니다.

1. 에이전트가 말을 시작합니다.
2. VAD가 사용자의 재발화를 감지합니다.
3. 에이전트가 즉시 자신의 말을 멈춥니다.
4. 응답의 남은 부분을 버립니다.
5. 사용자 턴의 나머지를 듣습니다.

사용자의 새 말은 앞의 말과 이어 붙고, 에이전트는 전체 문장으로 새 응답을 만듭니다. 대화 기록에는 사용자가 실제로 들은 부분만 남겨, 나머지를 들었다고 가정하지 않습니다. 단, 모든 작은 소리를 끼어들기로 취급하면 안 됩니다. 기침, 짧은 "음-음", 배경 소음에 에이전트가 멈춰서는 안 되므로 많은 시스템이 실제 단어나 최소 길이의 발화를 기다린 뒤에 멈춥니다(13.12 참조).

일부 에이전트는 응답을 미리 준비해 시간을 절약합니다. 침묵 중에 답을 만들기 시작하되 턴이 확정되기 전에는 말하지 않습니다. 사용자가 이어 말하면 그 초안을 버리고 새로 만들며, 사용자가 계속 말할 때마다 낭비되는 작업이 비용입니다(13.19 참조). 복구 절차를 평가할 때는 끼어들기 직후에 이전 응답이 대화 기록에 어떻게 남는지, 즉 실제로 들린 부분만 남는지를 로그로 확인합니다.

13.9.6 아주 긴 침묵의 처리

사용자가 훨씬 오래 멈추는 경우가 있습니다. 신용카드를 찾거나, 긴 ID 번호를 읽거나, 방 안의 다른 사람과 이야기하는 때입니다. 침묵이 최대 대기를 넘었는데도 말이 미완성으로 보이면, 에이전트는 반쪽 문장에 답해서도 영원히 침묵해서도 안 됩니다. 부드러운 확인 절차를 씁니다.

1. 긴 침묵 뒤 에이전트가 "천천히 하세요", "준비되시면 말씀해 주세요" 같은 짧고 친절한 말을 합니다.
2. 침묵이 계속되면 "아직 계신가요?"라고 묻습니다.
3. 몇 번 시도해도 답이 없으면 정중하게 통화를 끝내거나 다시 전화하겠다고 제안합니다.

사용자가 시간을 직접 요청할 수도 있습니다. "잠깐만요, 카드 좀 찾아볼게요"라고 하면 에이전트는 이를 대기 요청으로 받아 "네, 천천히 하세요"라고 답하고, 코드가 침묵 한계를 한동안 올려 평소보다 훨씬 오래 기다린 뒤 확인합니다.

전체 흐름은 사용자 발화, VAD의 침묵 감지, 텍스트·오디오 모델의 점검, 최소와 최대 사이의 대기 시간 선택, 대기 중 재발화 여부(있으면 새 말을 같은 턴에 붙여 계속 듣기), 단어와 목소리가 완결을 말하면 응답(사용자가 끼어들면 멈춤), 아니면 "천천히 하세요" 같은 부드러운 확인으로 이어집니다.

이 방식이 잘되는 조건은 두 가지입니다. 사용자가 필러, 생각 표현, 미완성 문장, 평평한 음높이 같은 분명한 신호를 남길 때, 그리고 에이전트가 명확한 질문을 해서 모델이 완전한 답의 모양을 알 때입니다. 실패하는 경우는 네 가지입니다.

• 완결처럼 들리는 문장 뒤에 덧붙임: 단어와 톤이 모두 "끝"을 말해 에이전트가 끼어듭니다.
• 소음이 큰 배경: VAD가 소음을 발화로 오인해 침묵을 보지 못합니다.
• 학습되지 않은 언어나 억양: 턴 감지 모델의 신호가 덜 믿을 만합니다.
• 긴 번호 읽기: 카드 번호처럼 자릿수 묶음 사이의 간격이 길면 각 묶음이 완결된 답처럼 보입니다.

마지막 경우에는 숫자를 물을 때 자릿수 묶음 사이를 더 오래 기다리거나 기대하는 자릿수가 채워질 때까지 기다리는 특별 규칙을 둡니다(13.10 참조). 고객 시험 시나리오에는 이 네 실패를 각각 재현하는 통화를 하나씩 포함합니다.

보충: 자주 나오는 질문

• VAD만으로 끝을 알 수 있는가: 없습니다. VAD는 작은 조각마다 사람이 말하는지만 알려주므로 단어의 의미와 목소리 톤을 함께 봐야 합니다.
• "음", "어" 같은 필러가 도움이 되는가: 됩니다. 필러로 끝나는 텍스트에는 턴 감지 모델이 낮은 점수를 주므로 에이전트가 끼어드는 대신 더 기다립니다.

13.10 미완성 입력: 전화번호·이메일

원문: How does a voice agent know a phone number or email is not finished yet?

전화번호와 이메일은 사람이 중간에 끊어 읽는 대표적인 구조화 입력이라, 침묵 길이만 보는 에이전트는 첫 묶음 뒤에서 끼어듭니다. 이 절은 2026년 10월 글 기준으로, 침묵 시간, 직전 질문, 값의 완성 여부, 단어를 읽는 모델을 쌓아 "아직 끝나지 않았다"를 알아내는 방법을 설명합니다. (자유 발화의 긴 침묵은 13.9 참조)

13.10.1 중간 휴지 문제

피자 가게 음성 에이전트가 "전화번호를 알려 주시겠어요?"라고 묻는 장면입니다. 대부분은 열 자리를 한 호흡에 말하지 않고 작은 묶음으로 나눕니다.

"오오오" (멈춤) "일이삼" (멈춤) "사오육칠"

각 멈춤은 1초에 가깝기도 합니다. 카드를 보고 읽거나, 기억을 더듬거나, 숨을 쉬느라 멈춥니다. 이메일도 같습니다.

"john" (멈춤) "dot smith" (멈춤) "at gmail" (멈춤) "dot com"

에이전트가 "오오오"를 전체 답으로 오인하면 첫 멈춤에서 끼어들어 "죄송하지만 유효한 전화번호가 아닙니다"라고 말하고, 사용자는 끊기고 짜증이 나서 처음부터 다시 말해야 합니다. 이 문제를 이해하려면 에이전트가 말이 끝났는지 판단하는 방식부터 알아야 합니다. 엔드포인팅(턴 감지)은 사용자가 자기 차례를 끝낸 정확한 순간을 정해 에이전트가 응답을 시작하게 하는 일이며(13.5 참조), 에이전트는 마이크 입력, 음성 인식, 엔드포인팅, LLM, 음성 합성, 재생 순으로 일합니다. "끝났다"를 너무 일찍 말하면 끼어들고 너무 늦게 말하면 느려서 사용자가 통화가 끊겼다고 생각합니다. 전화번호와 이메일 문제는 이 엔드포인팅의 특수한 경우입니다.

가장 단순한 두 접근이 왜 실패하는지가 출발점입니다.

• 접근 1, 고정 침묵: VAD가 0.6초 같은 고정 시간(보통 0.5~1초) 이상의 침묵을 들으면 끝났다고 봅니다. 코드는 silence_duration > SILENCE_LIMIT 한 줄입니다. "네", "대 사이즈 피자 주세요" 같은 일반 답에는 잘 맞지만, 전화번호에서 "오오오" 후 0.8초 멈추면 규칙은 끝났다고 판단하고 너무 일찍 응답합니다. 숫자 중간의 멈춤은 문장 끝의 멈춤과 똑같이 보이고, 침묵만으로는 둘을 구분하지 못합니다.
• 접근 2, 모두에게 더 길게: 한계를 2초로 늘리면 묶음 사이에서는 기다립니다. 그러나 모든 답의 끝에 2초 대기가 생겨 "네"에도 2초를 기다리고, 사용자는 "여보세요? 계세요?"라고 말하기 시작합니다. 몇 개의 특수한 턴을 고치려고 모든 턴을 느리게 만든 것입니다.

고객 업무에 전화번호, 이메일, 주문 번호 같은 입력이 몇 퍼센트인지를 먼저 센 뒤, 그 비율이 낮다면 전역 타이머를 건드리지 말고 해당 질문에만 별도 규칙을 둡니다.

13.10.2 직전 질문 활용

에이전트는 자기가 방금 무엇을 물었는지 압니다. "전화번호를 알려 주시겠어요?"라고 물었다면 다음 답이 전화번호라는 것을 알고, 사람들이 번호를 말할 때 멈춘다는 것도 압니다. 그래서 이 한 답에서만 더 오래 기다릴 수 있으며, 이것이 맥락 인식 엔드포인팅(context-aware endpointing)입니다. 에이전트가 기대하는 답의 종류에 따라 침묵 한계가 바뀝니다(동적 대기는 13.7 참조).

SILENCE_LIMITS = {"normal": 0.6, "phone_number": 1.5, "email": 2.0}

def is_turn_finished(silence_duration, expected_answer):
    limit = SILENCE_LIMITS.get(expected_answer, SILENCE_LIMITS["normal"])
    return silence_duration > limit

• expected_answer는 에이전트가 기다리는 답의 종류이며, 질문하는 순간 코드가 설정합니다.
• SILENCE_LIMITS는 답의 종류별 대기 시간입니다.
• 일반 답이나 목록에 없는 종류는 0.6초만 기다립니다.
• 전화번호는 더 길게, 이메일은 그보다 더 길게 기다립니다. 이메일은 일부를 글자 단위로 불러 주는 경우가 많기 때문입니다.
• 숫자는 이해를 위한 값이며 팀마다 사용자에 맞게 조정합니다.

이제 "네"는 빠르게, 전화번호는 인내심 있게 처리됩니다. 한계도 분명합니다. 이 접근도 여전히 침묵만 봅니다. 사용자가 열 자리를 빨리 말하고 멈추면 에이전트는 1.5초 전체를 쓸데없이 기다립니다. 반대로 사용자가 카드를 찾느라 2초를 멈추면 에이전트는 여전히 끼어듭니다(13.9 참조). 질문 종류별로 분리한 한계를 두는 것만으로 충분한지는 사용자가 번호를 읽는 속도의 분포를 시험 통화로 확인해서 판단합니다.

13.10.3 값이 완성된 형태인지 검사

단어 자체를 쓰는 접근입니다. 음성 인식은 사용자가 말하는 도중에도 텍스트를 내놓으며, 이 이른 조각이 부분 전사(partial transcript)입니다. 멈춤마다 지금까지의 텍스트가 "이미 전화번호 한 개처럼 보이는가"를 물을 수 있습니다.

전화번호는 자릿수를 셉니다. 10자리를 기대한다면 텍스트에서 숫자만 뽑아 길이를 비교합니다.

def phone_looks_complete(text):
    digits = [ch for ch in text if ch.isdigit()]
    return len(digits) >= 10

음성 인식은 보통 "five five five"를 숫자 "555"로 바꾸므로 세기가 가능합니다. 단어로 나오면 먼저 숫자로 바꿉니다. 번호 길이가 다른 나라라면 코드의 10을 바꿉니다. 예시 번호의 흐름은 다음과 같습니다(python3으로 재계산).

표 13.10.3 — 묶음마다 멈춰도 10자리가 채워질 때까지 계속 듣습니다.

이메일은 모양을 봅니다. 완성된 이메일은 이름 부분, "at", 도메인, "dot", com이나 org 같은 끝으로 이루어집니다. 구현은 말로 한 "at"과 "dot"을 @와 .으로 바꾸고 공백을 지운 뒤 정규식으로 모양을 검사하는 것입니다. 패턴은 영문자나 숫자, @, 도메인 이름, 점과 두 글자 이상의 끝을 요구합니다.

표 13.10.3b — 이메일은 @와 도메인 끝이 모두 있어야 완성입니다.

이 검사를 접근 3과 결합하면 규칙은 "값이 미완성으로 보이면 이 답 종류의 평소 한계를 넘어서까지 더 기다리고, 완성으로 보이면 짧은 침묵 뒤에 응답"이 됩니다. 원문 예시의 값은 전화번호가 완성이면 0.5초, 미완성이면 3.0초이고, 이메일이 완성이면 0.7초, 미완성이면 4.0초이며, 그 밖의 답은 0.6초입니다. 에이전트는 빨라지면서 동시에 참을성도 늘어납니다. 6자리를 말하고 카드를 보느라 2초를 멈춰도, 미완성 번호에는 3초까지 기다리므로 끼어들지 않습니다. 단, 최대 대기 시간은 유지합니다. 6자리만 말하고 그만큼 침묵하면 에이전트가 응답하며 나머지 번호를 요청합니다.

이 접근의 한계는 규칙이 딱딱하다는 점입니다. 나라마다 번호 길이가 다르고, 내선번호를 덧붙이고, "오오" 대신 "더블 파이브"라고 말하고, "오오 ... 아니, 오육"처럼 스스로 고치기도 합니다. 모든 경우의 규칙을 쓰기는 어렵습니다. 도입 시에는 고객의 번호 체계(자릿수, 국가 코드, 내선)를 규칙 입력값으로 먼저 확정합니다.

13.10.4 단어를 읽는 턴 모델

규칙을 손으로 쓰는 대신 학습 모델에 맡길 수 있습니다. 턴 감지 모델은 지금까지의 대화를 읽고 사용자가 차례를 끝냈을 가능성을 예측하는 작은 AI 모델입니다(13.6 참조). 많은 실제 대화로 학습하여 다음 같은 패턴을 익힙니다.

• "제 번호는 오오오"는 대개 끝나지 않은 것입니다.
• "제 이메일은 john at"은 대개 끝나지 않은 것입니다.
• "제 번호는 오오오 일이삼 사오육칠"은 대개 끝난 것입니다.

모델은 에이전트가 한 질문까지 포함한 대화를 읽고 0~1 숫자를 냅니다. 1에 가까우면 끝, 0에 가까우면 계속입니다. 일부는 음성 인식의 텍스트만 읽고, 다른 일부는 오디오도 들으며, 번호 중간의 멈춤에서는 목소리가 평평하거나 올라가고("더 있어요") 끝낼 때는 내려가는 경향이 있습니다. 이 높낮이의 오르내림이 억양(intonation)입니다. 사용 방식은 아래와 같습니다.

def is_turn_finished(silence_duration, conversation):
    done_probability = turn_model.predict(conversation)
    if done_probability > 0.8:
        return silence_duration > 0.3
    if done_probability > 0.4:
        return silence_duration > 1.0
    return silence_duration > 3.0

표 13.10.4 — 확률 구간마다 침묵 대기가 달라집니다. 임계값 0.8, 0.4는 예시입니다.

모델의 장점은 "더블 파이브", 내선번호, 스스로 고치기처럼 규칙이 놓치는 지저분한 경우를 학습 예시가 충분하다면 다룰 수 있다는 점입니다. 학습 데이터에 고객 업무의 번호 형식이 얼마나 들어 있는지가 성능을 좌우하므로, 도입 전에 고객의 실제 통화 전사로 전화번호·이메일 구간만 따로 평가합니다.

13.10.5 신호 결합과 불확실할 때의 행동

실제 음성 에이전트는 이 접근들을 쌓아 씁니다. 사용자가 말하다 멈추면 VAD가 침묵을 감지하여 타이머를 시작하고, 직전 질문(전화번호, 이메일, 일반 답)을 확인하고, 값의 완성 여부(자릿수, 이메일 패턴)를 검사하고, 턴 감지 모델의 점수를 받아 대기 시간을 정하고, 침묵이 대기 시간을 넘으면 응답하고 아니면 계속 듣습니다. 각 신호가 서로의 약점을 덮습니다.

• VAD는 침묵이 언제인지는 알지만 이유는 모릅니다.
• 직전 질문은 어떤 종류의 답이 올지 알려줍니다.
• 완성 검사는 값에 모든 부분이 있는지 알려줍니다.
• 턴 감지 모델은 규칙이 다루지 못하는 지저분한 경우를 처리합니다.

그래도 틀릴 때를 위해 안전장치를 둡니다.

• 값 되읽기(read back): 사용자가 끝낸 뒤 "감사합니다. 번호는 오오오, 일이삼, 사오육칠이 맞으신가요?"라고 확인합니다. 사용자가 실수를 고칠 기회가 되며, 이메일은 헷갈리는 부분을 글자 단위로 철자해 줍니다. 전화선에서는 "m"과 "n", "b"와 "d"가 아주 비슷하게 들리기 때문입니다.
• 바지인: 에이전트가 너무 일찍 응답을 시작해도 사용자가 계속 말하면 즉시 멈추고 계속 듣습니다(13.11 참조). 이른 응답이 통화를 망치지 않습니다.

잘되는 곳은 길이가 정해진 전화번호(자릿수 세기가 단순하고 신뢰할 수 있음), .com, .org 같은 흔한 끝을 가진 이메일(패턴으로 완성이 분명함), 에이전트가 한 번에 하나의 명확한 질문을 하는 통화(기대하는 답의 종류를 정확히 앎)입니다. 실패하는 곳은 다음과 같습니다.

표 13.10.5 — 완성 검사는 규칙이 가정한 모양을 벗어난 입력에서 실패합니다.

엔드포인팅이 틀린 경우를 값 되읽기와 바지인이 잡아 냅니다. 고객에게는 "번호 하나를 받는 데 몇 번 재시도하는가"를 성공 지표로 두고, 되읽기 단계의 정정 비율을 모니터링하자고 제안합니다.

보충: 자주 나오는 질문

• 불완전한 번호를 무한히 기다려야 하는가: 아닙니다. 값이 미완성으로 보여도 최대 대기 시간을 두며, 그 시간 동안 일부만 말하고 침묵하면 에이전트가 응답하며 나머지 번호를 요청합니다.
• 억양으로 번호가 끝나지 않았음을 알 수 있는가: 일부 모델은 오디오도 들으므로 가능합니다. 번호 중간의 멈춤에서는 목소리가 평평하거나 올라가고, 끝낼 때는 내려가는 경향이 있습니다.

13.11 바지인(Barge-in)

원문: What is barge-in in a voice AI agent?

고객은 에이전트의 긴 안내가 끝나기를 기다리지 않고 말을 자르며, 에이전트가 이를 듣지 못하면 "기계가 듣지 않는다"는 인상이 남습니다. 이 절은 2026년 10월 글 기준으로, 에이전트가 자기 말 도중에도 사용자를 듣는 구조와 그 세 가지 감지 접근, 끼어든 직후의 중단 절차, 사용자가 실제로 들은 내용의 기록 방식을 설명합니다. (13.1의 끼어들기 개요를 심화한 절입니다.)

13.11.1 어원

바지인(barge-in)은 사용자가 음성 AI 에이전트가 말하는 도중에 말을 시작하고, 에이전트가 즉시 자기 발화를 멈추고 듣는 것을 말합니다. 음성 AI 에이전트는 사용자가 말하면 듣고, 생각하고, 음성으로 답하는 시스템이며 고객 지원 전화 봇과 음성 비서가 해당합니다. 배달 지원 전화에서 에이전트가 "신규 주문, 주문 조회, 환불, 주소 변경, 그리고 ..."를 안내하는 중에 사용자가 "환불"이라고 말하면, 에이전트가 멈추고 듣고 환불 절차로 넘어가는 것이 바지인입니다. 친구가 길을 알려 주는데 이미 아는 곳이어서 "응, 알아"라고 하면 친구가 멈추는 것과 같습니다. 바지인은 턴테이킹이라는 더 큰 일의 한 부분입니다(13.4 참조).

"barge in"은 갑자기 들어와 끼어든다는 뜻이며, 사용자가 에이전트의 차례에 끼어든다는 의미입니다. 이 말은 옛 전화 시스템에서 왔습니다. "청구는 1번, 지원은 2번" 같은 전화 메뉴가 IVR(Interactive Voice Response, 대화형 음성 응답) 시스템입니다. 초기 IVR은 메뉴가 끝날 때까지 기다려야 키를 누를 수 있었고, 이후 발신자가 안내 도중에 키를 누르거나 말하면 시스템이 재생을 멈추게 되었는데 이 기능이 바지인이었습니다. 현대 음성 AI 에이전트는 같은 말을 같은 개념에 씁니다. 차이는 고정된 녹음 메뉴가 아니라 AI 모델이 생성한 문장을 말한다는 점입니다. 고객이 기존 IVR을 AI 에이전트로 바꾸려는 경우, IVR에서 이미 허용하던 중간 끼어들기를 새 에이전트도 같은 수준으로 지원해야 후퇴로 느껴지지 않습니다.

13.11.2 에이전트가 자기 소리를 듣는 문제

대부분의 에이전트는 사용자 발화, STT(음성→텍스트), LLM(답변 작성), TTS(텍스트→음성), 스피커 재생의 파이프라인입니다(13.2 참조). VAD는 마이크 오디오를 20~30ms 조각으로 듣고 "지금 사람이 말하는가"만 답합니다. 단순한 에이전트는 자기가 말하는 동안 마이크를 끄거나 무시합니다. 말하고, 듣고, 다시 말하는 워키토키 방식이어서 한쪽만 말할 수 있고(13.3 참조) 바지인이 불가능합니다. 바지인을 지원하려면 에이전트가 말하는 동안에도 마이크, VAD, STT가 계속 돌아야 합니다.

그러면 첫 문제가 생깁니다. 스피커폰으로 에이전트를 쓰면 마이크가 스피커에서 몇 센티미터 떨어져 있어 에이전트 자신의 목소리를 주워 담습니다. VAD는 사람 목소리가 들린다고 판단하고 에이전트는 사용자가 끼어들었다고 오인해 스스로 멈춥니다. 이렇게 에이전트가 스스로를 끊는 현상이 자기 끼어들기(self-interruption)입니다.

해법은 에코 제거(Acoustic Echo Cancellation, AEC)입니다. 에이전트는 자기가 스피커로 보내는 오디오를 정확히 알고 있습니다. AEC는 그 오디오가 마이크로 되돌아올 때의 소리를 예측하여 마이크 신호에서 뺍니다. 마이크 오디오(사용자와 에이전트의 에코)에서 에이전트 자신의 오디오를 빼면 거의 사용자의 소리만 남은 깨끗한 오디오가 VAD로 가므로, VAD는 대부분 사용자를 듣습니다.

AEC는 휴대폰, 브라우저, 운영체제가 자주 제공하지만 완벽하지 않습니다. 큰 스피커 음량, 크고 빈 방, 저품질 전화기에서는 에코가 새어 나옵니다. 그래서 좋은 에이전트는 짧은 소리 한 번을 바지인으로 믿지 않습니다. 고객의 단말이 스피커폰, 차량 블루투스, 콜센터 헤드셋 중 무엇인지에 따라 AEC의 수준이 달라지므로, 도입 전에 가장 나쁜 단말에서의 자기 끼어들기 빈도를 시험합니다. (13.12.1 참조)

13.11.3 모든 소리가 끼어들기는 아니다

깨끗한 오디오라도 마이크에 닿는 모든 소리가 "멈춰"는 아닙니다.

• 백채널(backchannel): 듣는 동안 "응", "네", "맞아요", "음" 같은 작은 말을 합니다. "듣고 있어요, 계속하세요"라는 뜻이며 "멈춰"가 아닙니다(13.13 참조).
• 배경 소음: 문이 닫히고, 개가 짖고, TV가 켜져 있고, 자동차 경적이 울립니다.
• 기침과 숨소리: 사용자가 기침하거나 목을 가다듬습니다.
• 다른 사람: 방 안의 다른 사람이 사용자에게 말합니다.

이 모두에 멈추면 에이전트가 자기 문장을 계속 끊습니다. 실제 끼어들기가 아닌 소리에 멈추는 것이 거짓 끼어들기(false interruption)입니다. 에이전트는 반대 방향의 두 실수를 모두 피해야 합니다.

표 13.11.3 — 거짓 끼어들기와 바지인 누락은 서로 반대 방향의 실패입니다.

소리를 가려내는 세부 단계는 13.12 참조. 고객이 "자꾸 혼자 멈춘다"와 "내가 말해도 안 멈춘다"를 모두 말하면, 한 임계값이 양쪽을 동시에 만족시키지 못한다는 신호입니다.

13.11.4 감지 접근 3가지: 아무 소리·충분한 발화·의미 이해

가장 단순한 것부터 완전한 것까지 세 접근이 있습니다.

표 13.11.4 — 접근 1은 반응이 빠르고 거칠며, 접근 3은 정확하지만 한 박자 늦습니다.

접근 3의 판단 예는 다음과 같습니다.

• "응", "네", "맞아요", "그래, 계속해" → 백채널, 계속 말하기
• "잠깐", "그만", "아니, 그건 틀렸어요", "사실 환불을 원해요" → 끼어들기, 멈추고 듣기

구현은 백채널 단어 목록을 쓰거나, 사용자 말을 "끼어들기"와 "계속"으로 분류하도록 학습된 작은 모델을 씁니다. 일부 새로운 시스템은 오디오와 단어를 함께 보는 모델을 씁니다. 실무에서는 접근들을 결합합니다. VAD가 빠른 첫 신호를 내서 에이전트가 멈출 준비를 하고, 최소 발화 확인과 의미 확인이 진짜 바지인인지 확정합니다. 의미 확인은 "그만"처럼 최소 길이보다 짧은 한 단어도 통과시킵니다. 고객에게는 접근 선택을 이렇게 묻습니다. 사용자가 짧은 명령어("멈춰", "잠깐")를 자주 쓰는가, 맞장구를 많이 치는 문화권·연령층인가에 따라 접근 2와 3의 비중을 정합니다.

바지인이 확정된 뒤에는 이전 응답을 만들던 모든 곳을 멈춰야 합니다. 이전 응답은 한곳에 있지 않고 파이프라인 전체에 퍼져 있기 때문입니다.

• LLM이 나머지 응답을 계속 생성할 수 있습니다.
• TTS가 계속 텍스트를 오디오로 바꾸고 있을 수 있습니다.
• 이미 만들어진 오디오가 버퍼(buffer), 즉 재생을 기다리는 작은 대기 공간에 쌓여 있을 수 있습니다.
• 스피커가 한 조각을 재생하는 도중일 수 있습니다.

LLM만 멈추면 버퍼의 오디오가 계속 재생되어 사용자가 "그만"이라고 한 뒤에도 에이전트가 말하는 것을 듣게 됩니다. 그래서 스피커, 버퍼, TTS, LLM 순으로 모두 멈추고, 그 뒤 사용자의 전체 문장을 듣고 새 응답을 시작합니다. 스피커를 먼저 멈추는 이유는 사용자가 에이전트 소리를 듣는 시간을 가장 빨리 끊기 위해서입니다. (LLM 출력이 TTS로 넘어가는 경로는 13.17 참조)

def on_user_started_speaking(agent):
    if not agent.is_speaking: return          # 일반 턴
    if not is_real_interruption(agent.user_audio, agent.user_text):
        return                                # 기침, 소음, 백채널
    agent.speaker.stop(); agent.audio_buffer.clear()
    agent.tts.cancel();   agent.llm.cancel()
    agent.mark_heard_part()                   # 실제로 들은 부분 저장
    agent.is_speaking = False; agent.start_listening()

이 코드는 이해를 위한 것이며, 실제 에이전트는 이 부분들을 별도 작업으로 동시에 실행하고 프레임워크의 취소 함수를 씁니다.

바지인은 빨라야 합니다. 사용자가 "잠깐"이라고 한 뒤 상대가 2초나 더 말하면 무시당한 기분이 듭니다. 사용자가 말을 시작한 순간부터 에이전트가 조용해지는 순간까지 짧아야 하는데, 작은 지연이 사슬로 쌓입니다. VAD가 발화를 확신하려면 오디오 조각 몇 개가 필요하고, 확인 단계(특히 단어를 기다리는 경우)에 시간이 들며, 이미 전화망이나 스피커로 보낸 오디오가 잠시 더 재생될 수 있습니다. 그래서 좋은 에이전트는 사슬의 각 부분을 짧게 유지합니다. 오디오 버퍼를 작게 해 재생 대기 중인 오디오를 줄이고, VAD가 울리는 즉시 음량을 낮추었다가 바지인이 확정되면 완전히 멈추고 오경보이면 원래 음량으로 되돌릴 수도 있습니다.

여기에는 교환 관계가 있습니다. 더 빨리 멈추면 거짓 끼어들기가 늘고, 멈추기 전에 더 기다리면 거짓 끼어들기가 줄지만 반응이 느려집니다. 배경 소음이 많은 전화 회선은 더 오래 기다려야 하고, 조용한 앱 내 비서는 더 빨리 멈출 수 있습니다.

13.11.5 사용자가 실제로 들은 내용 기억하기

바지인 뒤 에이전트는 자기 응답을 어떻게 기억해야 할까요. LLM이 "주문은 오후 7시에 도착합니다. 배달 기사는 Ravi입니다. 앱에서 주문을 추적할 수 있습니다. 합계는 450루피입니다."라는 전체 응답을 썼다고 합니다. LLM은 보통 스피커가 오디오를 재생하는 것보다 훨씬 빠르게 텍스트를 생성하므로, 전체 텍스트는 오디오 재생이 끝나기 한참 전에 준비됩니다. 그런데 사용자는 "주문은 오후 7시에 도착합니다. 배달 기사는 ..."까지만 듣고 끼어들었습니다.

에이전트가 전체 응답을 대화 기록에 저장하면 LLM은 사용자가 배달 기사 이름과 합계를 안다고 믿습니다. 나중에 사용자가 "얼마예요?"라고 묻는데 "말씀드린 대로 450루피입니다"라고 답하는 오류가 생깁니다. 사용자는 그것을 들은 적이 없습니다. 그래서 저장하는 응답을 실제 재생된 부분까지만 잘라야 합니다.

표 13.11.5 — 기록에는 쓴 것이 아니라 들린 것만 남깁니다.

재생된 부분을 아는 방법은 타이밍입니다. 에이전트는 오디오 재생이 시작된 때와 멈춘 때를 알고, 일부 TTS는 각 단어가 말해진 시각인 단어 수준 타임스탬프를 돌려줍니다. 멈춘 시각을 마지막으로 말해진 단어와 맞추면 됩니다. 2026년 10월 글 기준으로, 예컨대 OpenAI Realtime API는 conversation.item.truncate 이벤트를 제공합니다. 에이전트가 자기 오디오가 몇 ms 재생되었는지를 보내면 API가 그 응답의 나머지를, 재생되지 않은 부분의 텍스트까지 포함해 잘라 냅니다. 일부 에이전트는 기록에 "사용자가 여기서 끼어들었다"는 짧은 메모를 덧붙여, LLM이 자기 문장이 불완전한 이유를 이해하게 합니다.

전체 흐름은 다음 순서입니다.

1. 에이전트가 "주문은 오후 7시에 도착합니다. 배달 기사는 Ravi입니다. 앱에서 ..."를 말하기 시작합니다.
2. 마이크, VAD, STT가 계속 돌고 AEC가 에이전트 자신의 목소리를 지웁니다.
3. 첫 문장 뒤에 사용자가 "응"이라고 합니다. VAD가 울리지만 확인 단계가 짧은 백채널로 판정하여 에이전트는 계속 말합니다.
4. 사용자가 "잠깐, 주소를 바꿀 수 있나요?"라고 합니다. 발화가 충분히 길고 "잠깐", "주소를 바꿀"이 끼어들기를 뜻하므로 바지인이 확정됩니다.
5. 에이전트가 스피커를 멈추고 버퍼를 비우고 TTS와 LLM을 취소합니다.
6. 사용자가 들은 부분만 저장합니다. "주문은 오후 7시에 도착합니다. 배달 기사는 Ravi입니다. 앱에서 ..."
7. STT가 사용자의 전체 문장을 텍스트로 바꾸고, LLM은 갱신된 기록을 받아 "네. 새 주소가 어떻게 되시나요?"라고 답합니다.

고객 점검 질문은 세 가지입니다. 끼어든 뒤 기록에 저장되는 응답이 재생된 부분까지인지(전체 응답이 남으면 나중에 "말씀드린 대로"라는 거짓 전제가 생깁니다), 취소가 스피커, 버퍼, TTS, LLM 전부에 전달되는지, 그리고 소음 환경에서 바지인 확정 대기를 얼마로 둘지입니다.

보충: 자주 나오는 질문

• 단순한 에이전트가 바지인을 못 하는 이유: 말하는 동안 마이크를 끄거나 무시해서 자기 발화 중에는 사용자를 들을 수 없기 때문입니다. 바지인을 지원하려면 마이크, VAD, STT가 에이전트 발화 중에도 돌아야 합니다.
• 거짓 끼어들기의 원인: "응" 같은 백채널, 기침, 배경 소음, 방 안의 다른 사람, 에이전트 자신의 에코입니다. 많이 일어나면 에이전트가 자기 문장을 계속 끊습니다.

13.12 끼어들기 vs 기침·배경 소음

원문: How does a voice agent tell a real interruption from a cough or background noise?

음성 에이전트는 말하는 도중에도 마이크로 들어오는 모든 소리에 "이것이 끼어들기인가"를 초당 여러 번 판정해야 합니다. 이 절은 2026년 11월 글 기준으로, 소리를 여러 검사에 차례로 통과시켜 전부 통과한 소리에만 멈추는 구조를 단계별로 설명합니다. (바지인의 정의와 감지 접근은 13.11, 턴테이킹 전반은 13.4 참조)

사용자가 에이전트의 말 도중에 말을 시작하는 것이 끼어들기(interruption)이며 바지인(barge-in)이라고도 부릅니다. 항공편 목록을 읽어 주던 에이전트에게 사용자가 "잠깐, 아침 비행기로 해주세요"라고 말하면 즉시 멈추고 들어야 하는 진짜 끼어들기입니다. 그러나 통화 환경은 조용하지 않으며, 다음 소리도 마이크에 들어옵니다.

• 기침이나 재채기
• 문이 닫히는 소리, 개 짖는 소리
• 옆방 TV 소리, 바깥의 자동차 경적
• 듣고 있다는 표시로 내는 "음-음"

이 소리들은 "멈추라"는 뜻이 아니며, 이것에 멈추면 거짓 끼어들기(false interruption)가 됩니다.

13.12.1 에이전트 자신의 음성 제거

첫 검사는 소리가 사용자의 것이 아니라 에이전트 자신의 목소리일 가능성을 지우는 일입니다. 에이전트 음성이 사용자 휴대폰 스피커로 나오면 같은 기기의 마이크로 되돌아 들어가고, 이를 처리하지 않으면 에이전트가 자기 목소리를 사용자 발화로 착각해 스스로 말을 끊습니다.

해법은 에코 제거(Echo Cancellation)입니다. 스피커로 내보낸 소리는 에이전트가 만든 것이므로 시스템이 정확히 알고 있고, 그 소리가 마이크로 되돌아올 때의 모양을 예측해 마이크 입력에서 뺄 수 있습니다.

에코 제거는 뒤의 모든 검사의 전제이므로, 현장에서 에이전트가 아무 말 없는 사용자에게 혼자 끊긴다면 이 단계부터 점검합니다.

13.12.2 배경 소음 제거

두 번째 검사는 소음 억제(Noise Suppression)이며, 오늘날 대개 사람 말소리와 선풍기·교통·타이핑·바람 같은 흔한 소음을 구분하도록 학습된 모델입니다. 말소리는 남기고 나머지는 낮춥니다. 번화가에서 건 통화라면 억제 전에는 사용자 목소리에 엔진 소리가 섞여 있고, 억제 후에는 엔진 소리가 작아지고 목소리가 또렷해집니다. 선풍기나 교통 같은 일정한 소음은 이 단계에서 걸러져 다음 검사에 도달하지 않습니다.

일부 시스템은 한 걸음 더 나가 배경 음성 제거(background voice cancellation)를 씁니다. 마이크에 가장 가까운 주 화자의 목소리만 남기고 TV나 옆방 사람 목소리를 낮추는 방식이며, TV 속 음성은 진짜 사람 말소리이지만 우리 사용자가 아니기 때문에 필요합니다.

소음 억제로 모두 지워지지는 않습니다.

• 기침은 사람 입에서 나오므로 말소리와 음향 성질을 일부 공유합니다.
• 갑작스러운 큰 충격음은 빠져나올 수 있습니다.

따라서 뒤에 검사가 더 필요합니다. 고객에게는 소음 억제 하나로 거짓 끼어들기가 해결되지 않는다는 점을 먼저 설명해 둡니다.

13.12.3 사람 말소리 여부와 지속 시간

세 번째와 네 번째 검사는 사람 말소리인지, 그리고 충분히 오래 이어지는지를 봅니다.

VAD(Voice Activity Detection)는 대개 30ms 안팎의 짧은 오디오 조각마다 0~1 점수를 내는 작은 모델입니다. 1에 가까우면 말소리일 가능성이 높고 0에 가까우면 아닙니다. 에이전트는 컷오프(예: 0.5)를 정해 그 이상을 말소리로 취급합니다. 사람이 말소리 구간을 표시한 방대한 오디오로 학습하므로 개 짖는 소리, 문 닫히는 소리, 노래 없는 음악은 대체로 낮은 점수를 받습니다. 그러나 기침, 웃음, 큰 "흠" 소리는 사람 목에서 나오므로 높은 점수를 받을 수 있습니다. VAD는 사람 목소리와 다른 소리를 잘 구분하지만 기침과 단어는 믿을 만하게 구분하지 못합니다.

여기서 시간이 쓰입니다. 기침은 대개 1초의 일부에 그치고, "잠깐, 아침 비행기로 해주세요" 같은 진짜 끼어들기는 더 오래 이어집니다. 그래서 말소리가 최소 시간 이상 이어져야 끼어들기로 센다는 규칙을 둡니다. 일부 프레임워크는 기본값을 약 0.5초로 두며 용도에 따라 바꿀 수 있습니다.

표에서 #은 VAD가 말소리를 들은 시점입니다. 기침은 0.5초 선에 닿기 전에 끝나 최소 시간을 채우지 못하므로 에이전트가 계속 말하고, 끼어들기는 선을 넘겨 통과합니다. 대부분의 기침·재채기·박수·충격음이 짧아서 이 검사 하나로 거짓 끼어들기가 크게 줄어듭니다.

최소 시간에는 맞교환이 있습니다.

• 길게 잡으면 기침이 더 걸러지지만 진짜 끼어들기에도 더 늦게 멈춥니다.
• 짧게 잡으면 빨리 멈추지만 기침이 더 통과합니다.

소음이 많은 콜센터는 길게, 빠른 반응을 기대하는 조용한 앱은 짧게 잡습니다. FDE는 고객 통화 환경(콜센터인지 개인 앱인지)을 물어 이 값을 정합니다.

13.12.4 실제 단어 여부

시간만으로는 부족합니다. 긴 기침 발작이나 웃음 폭발은 0.5초를 쉽게 넘습니다. 그래서 가장 강한 증거인 단어를 씁니다. 대부분의 음성 에이전트는 이미 음성 인식(Speech-to-Text) 모델을 갖고 있으므로 그 텍스트로 끼어들기를 검사할 수 있습니다.

• 기침은 단어가 없어 인식 결과가 비어 있습니다.
• 배경 소음도 단어가 없거나 끊어진 조각만 나옵니다.
• 진짜 끼어들기는 "잠깐", "그만", "아니, 그거 말고" 같은 실제 단어를 냅니다.

그래서 음성 인식이 일정 개수 이상의 단어를 내야만 멈춘다는 규칙을 둘 수 있습니다. 한 단어에서 멈추는 시스템도 있고 두 단어 이상을 기다리는 시스템도 있습니다. 에이전트가 말하는 중 사용자가 0.7초 기침한 경우와 "잠깐"이라 말한 경우를 비교하면 다음과 같습니다.

기침은 시간 검사를 통과했지만 단어 검사에서 탈락하고, 끼어들기는 둘 다 통과합니다.

단어는 백채널(backchannel)을 거르는 데도 쓰입니다. 백채널은 듣고 있음을 알리는 짧은 소리("음-음", "네", "맞아요")로, 진짜 말이어서 음성 인식이 단어로 적지만 "멈추라"가 아니라 "계속하세요"를 뜻합니다(13.13 참조). 그래서 작은 목록을 두고, 사용자가 "음-음"이나 "네"만 말하면 백채널로 보고 계속 말하며, "네, 그런데 잠깐만요"처럼 이어 말하면 멈춥니다.

단어 검사의 약점은 시간입니다. 음성 인식이 첫 단어를 내기까지 잠시 걸리고, 단어가 올 때까지 아무것도 하지 않으면 사용자는 그만큼 더 오래 에이전트가 자기 위에 말하는 것을 듣습니다. 이 지연을 다음 소절의 방식으로 메웁니다.

13.12.5 일단 멈추고 결정하기

멈출지 계속할지를 즉시 고르는 대신 중간 동작인 일시 정지(pause)를 둘 수 있습니다.

• VAD가 말소리를 듣는 즉시 에이전트가 목소리를 멈추거나 낮춥니다. 말하려던 내용은 버리지 않습니다.
• 짧게 기다리며 무슨 일이 생기는지 봅니다.
• 말소리가 충분히 길고 실제 단어가 오면 진짜 끼어들기이므로 완전히 멈추고 듣습니다.
• 단어가 오지 않고 사용자가 조용해지면 거짓 끼어들기이므로 멈춘 곳에서 이어 말합니다(resume).

기침 사례는 이렇게 흐릅니다. 에이전트가 "비행기는 아침 아홉 시에 출발하고…"라고 하다가 사용자가 기침하면 에이전트는 일시 정지하고, 침묵과 무단어를 확인한 뒤 "…정오에 도착합니다."로 이어 갑니다. 사용자에게는 기침 소리를 듣고 잠시 말을 멈춘 사람처럼 느껴집니다.

일부 프레임워크는 이 대기 시간의 기본값을 침묵 약 2초로 둡니다. 대기를 짧게 하면 멈춤이 덜 눈에 띄지만, 사용자가 막 말하려는 순간에 에이전트가 다시 말을 시작할 수 있습니다. 이 방식은 첫 소리에 바로 반응하므로 빠르고, 기침이었을 때 문장을 잃지 않습니다. 고객 통화에서 기침 뒤에 에이전트가 처음부터 다시 읽는다면 이어 말하기가 구현되지 않은 것입니다.

13.12.6 학습된 끼어들기 모델

위 검사는 사람이 만든 규칙(최소 시간, 최소 단어 수, 백채널 목록)이며 설정은 쉽지만 한계가 있습니다. 기침과 "잠깐"은 둘 다 짧을 수 있고, 어떤 사용자는 동의의 뜻으로 "응"이라 하고 다른 사용자는 새 질문을 시작하려고 "응"이라 합니다.

그래서 일부 새 에이전트는 끼어들기 모델(interruption model)을 씁니다. 에이전트가 말하는 동안 사용자가 낸 소리를 실제 대화에서 모아 다음 중 하나로 라벨을 붙여 학습한 모델입니다.

• 진짜 끼어들기: 멈추기를 원한 경우
• 백채널: 듣고 있음만 표시한 경우
• 소음: 기침, 웃음, 배경 소리

이 모델은 텍스트만이 아니라 오디오 자체를 듣기 때문에 톤, 높낮이, 리듬을 쓸 수 있습니다. 날카롭게 올라가는 "잠깐"과 부드럽고 평평한 "음-음"은 둘 다 짧아도 소리가 다릅니다. 많은 예시에서 이 패턴을 배우므로 고정 규칙보다 잘 구분합니다. 규칙 기반으로 튜닝해도 오탐이 줄지 않는 고객이라면 학습 모델 도입을 검토합니다.

전체 흐름과 한계

소리 하나가 거치는 경로는 다음과 같습니다. 각 "아니오"는 소리가 흐름에서 빠지는 지점입니다.

flowchart TD
  A[소리가 마이크에 도달] --> B[에코 제거: 에이전트 음성 제거]
  B --> C[소음 억제: 선풍기·교통·다른 음성 제거]
  C --> D{VAD: 사람 말소리인가}
  D -- 아니오 --> N1[무시하고 계속 말함]
  D -- 예 --> E[에이전트 일시 정지]
  E --> F{약 0.5초 이상 이어졌는가}
  F -- 아니오 --> R1[이어 말함]
  F -- 예 --> G{"음-음"이 아닌 실제 단어인가}
  G -- 아니오 --> R2[이어 말함]
  G -- 예 --> H[진짜 끼어들기: 멈추고 듣기]

그림 13.12 — 소리는 에코 제거, 소음 억제, VAD, 시간, 단어 검사를 차례로 통과해야만 에이전트를 멈춥니다.

세 가지 소리를 흘려 보면 다음과 같습니다.

• 개 짖는 소리: 소음 억제가 낮추고 VAD 점수도 낮아 에이전트는 일시 정지조차 하지 않습니다.
• 기침: VAD가 말소리로 볼 수 있어 일시 정지하지만, 너무 짧거나 단어가 없어 이어 말합니다.
• "잠깐, 아침 비행기로 해주세요": VAD, 시간, 단어를 모두 통과해 멈추고 듣습니다.

잘 되는 경우와 어려운 경우는 다음과 같습니다.

모든 설정은 맞교환입니다. 실제 기침, 실제 TV, 실제 사용자가 담긴 통화 녹음으로 에이전트를 시험하며 최소 시간, 최소 단어 수, 일시 정지 시간을 용도에 맞게 조정해야 합니다.

FAQ에서 보태는 판단 기준

• 거짓 끼어들기: 기침, 재채기, 문소리, 개 짖는 소리, 옆방 TV, 짧은 "음-음"처럼 "멈추라"는 뜻이 아닌 소리에 에이전트가 멈추는 일입니다. 사용자는 당황해 "계속하세요"라고 말해야 합니다.
• "음-음"에 멈춰야 하는가: 멈추지 않습니다. 이런 말은 백채널이며 작은 단어 목록으로 계속 말하되, "네, 그런데 잠깐"처럼 이어지면 멈춥니다.
• 소음 억제만으로 충분한가: 충분하지 않습니다. 기침과 큰 충격음이 빠져나오므로 말소리·길이·단어 검사가 더해집니다.
• 얼마나 말해야 끼어들기인가: 일부 프레임워크의 기본값은 약 0.5초이며 길수록 기침이 걸러지지만 멈춤이 늦어집니다.

고객 현장에서 "가끔 혼자 멈춥니다"라는 불만이 나오면 에코(13.12.1), 소음(13.12.2), 최소 시간(13.12.3), 단어 수(13.12.4)의 순서로 어느 검사가 새는지 녹음으로 가려냅니다.

13.13 백채널(Backchannel)

원문: What are backchannels, and why should "mm-hmm" not stop the agent?

기침이나 소음은 사람의 발화가 아니지만 맞장구는 사람의 정상적인 발화이므로, 에이전트는 소리가 사람의 것이라는 사실만으로는 멈출 이유를 얻지 못합니다. 이 절은 2026년 11월 글 기준으로, "음-음"이 에이전트를 멈추게 하면 어떤 일이 생기는지, 맞장구와 진짜 끼어들기를 어떤 신호로 구별하는지, 확신이 서기 전에 에이전트가 어떻게 행동하는지를 설명합니다. (소음과의 구분은 13.12, 바지인은 13.11 참조)

13.13.1 정상 대화 속 백채널

백채널(backchannel)은 다른 사람이 말하는 동안 듣는 사람이 "듣고 있으니 계속하세요"라는 뜻으로 내는 짧은 소리나 단어입니다. "음-음(mm-hmm)", "응(uh-huh)", "네(yeah)", "알겠어요(okay)", "맞아(right)", "아, 그렇구나(I see)", "와(wow)"가 흔한 예입니다.

이 용어는 1970년 언어학자 Victor Yngve가 도입했습니다. 그는 대화에 두 개의 채널이 동시에 있다고 보았습니다. 주 채널(main channel)은 말할 차례를 쥔 화자의 것이고, 백채널(back channel)은 차례를 가져가지 않고 화자에게 작은 신호를 계속 돌려보내는 청자의 것입니다. 백채널은 주된 메시지가 진행되는 동안 청자에서 화자로 거슬러 가는 작은 메시지입니다. 청자는 말하게 해 달라고 요청하는 것이 아니라 "계속하세요, 저는 따라가고 있습니다"라고 말하는 것입니다.

친구가 여행 이야기를 하는 장면이 그 예입니다.

내가 두 번 말했지만 친구는 멈추지 않았고 "무슨 할 말 있어?"라고 되묻지도 않았으며 이야기를 이어 갔습니다. 사람은 생각 없이도 백채널을 계속 보내며, 전화에서 완전히 침묵하면 상대가 "여보세요? 듣고 계세요?"라고 묻기도 합니다. 백채널은 대화가 자연스럽게 느껴지게 하는 요소입니다.

백채널은 언어와 문화마다 다릅니다. 일본어에는 아이즈치(相槌, aizuchi)라는 일상적 이름이 있고, 청자가 영어권보다 훨씬 자주 씁니다. 전 세계 사람과 통화하는 음성 에이전트는 이런 소리를 많이 듣게 됩니다. 다국어 고객이라면 언어별 백채널 목록과 빈도가 다르다는 점을 요구사항에 넣습니다.

13.13.2 '음-음'에 에이전트가 멈출 때의 문제

음성 에이전트는 음성 인식(STT)이 음성을 텍스트로 바꾸고, LLM이 읽고 답을 쓰며, 음성 합성(TTS)이 답을 목소리로 바꾸는 세 부품으로 이루어집니다. 에이전트는 말하는 중에도 사용자가 끼어들 수 있도록 마이크를 켜 둡니다. 에이전트 답변 중에 사용자가 말을 시작하는 것이 바지인이며, 에이전트는 이를 감지해 멈추고 듣습니다.

바지인을 감지하는 가장 단순한 방법은 VAD입니다. VAD는 지금 사람 목소리가 있는지 예/아니오로 답하는 작은 모델이며, 그 전에 에코 제거로 에이전트 자신의 목소리를 마이크 소리에서 뺍니다. 가장 단순한 규칙은 "에이전트가 말하는 중 VAD가 사람 목소리를 들으면 즉시 멈춘다"입니다. 그러나 VAD는 사람이 소리를 냈다는 것만 알고 그 의미는 모릅니다. "멈춰"와 "음-음"은 VAD에게 똑같은 사람 목소리입니다.

인터넷 공유기를 초기화하는 방법을 에이전트에게 묻는 통화가 그 예입니다.

사용자는 따라가고 있다는 표시로 "음-음"이라고 했을 뿐인데 에이전트가 이를 끼어들기로 처리해 멈추고, 질문하고, 처음부터 다시 말했습니다. 이로 인해 다음 문제가 생깁니다.

• 대화가 계속 끊깁니다.
• 이미 한 말을 반복해 시간을 낭비합니다.
• 사용자가 에이전트가 말하는 동안 침묵하게 되어 부자연스러워집니다.
• 최악의 경우 에이전트가 남은 답변을 버리고 "음-음"을 새 질문처럼 받아 응답합니다.

이런 실수가 거짓 끼어들기(false interruption), 곧 진짜 끼어들기가 아닌 것에 멈추는 일이며, 백채널은 그 흔한 원인입니다(기침·소음 같은 다른 원인은 13.12 참조). 에이전트가 배워야 할 점은 답변 도중의 모든 목소리가 끼어들기는 아니라는 것입니다.

고객이 "에이전트가 자꾸 되묻고 처음부터 다시 말한다"고 하면 백채널 처리가 없는 VAD 단독 규칙을 의심합니다.

13.13.3 구별 신호 5종: 길이·단어·억양·타이밍·종합 모델

백채널은 짧고 새 정보가 없으며 에이전트에게 무엇을 하라고 요구하지 않습니다. 진짜 끼어들기는 정정, 질문, 멈춤 요청처럼 새 의미를 담습니다.

같은 단어도 뜻이 갈립니다. 에이전트 문장 중간에 작게 말한 "알겠어요"는 "계속하세요"인 백채널입니다. 크고 빠르게 말한 "알겠어, 알겠어, 이해했어"는 "그만하셔도 됩니다"라는 멈춤 요청입니다. "알겠어요, 그런데 가격은요?"는 백채널처럼 시작해 진짜 질문이 됩니다. 한 단어만 보고 결정할 수 없으므로 여러 신호를 함께 봅니다.

신호 1 — 길이. 백채널은 대개 1초 미만이고 진짜 끼어들기는 한 문장을 말하느라 더 깁니다. 에이전트가 사용자가 최소 0.5초 이상 말할 때까지 기다리면 간단하고 기침이나 빠른 "음" 같은 짧은 소리를 무시합니다. 단점은 진짜 "멈춰"나 "잠깐"도 짧아서 무시될 수 있고, "응, 응, 알겠어요" 같은 백채널은 기준보다 길 수 있다는 점입니다. 길이 하나로는 부족합니다.

신호 2 — 단어. 에이전트는 이미 STT로 텍스트를 얻으므로 단어를 검사할 수 있습니다. "음-음", "응", "네", "알겠어요", "맞아요" 목록의 단어뿐이면 백채널일 가능성이 높고, "멈춰", "잠깐", "아니", "잠시만요"나 새 질문이 들어 있으면 진짜 끼어들기일 가능성이 높습니다. 단순한 구현은 다음과 같습니다.

BACKCHANNELS = {"mm-hmm", "mhm", "uh-huh", "yeah", "yes", "okay", "ok", "right", "sure"}

def is_backchannel(text):
    for mark in ",.!?":
        text = text.replace(mark, " ")
    words = text.lower().split()
    if len(words) == 0 or len(words) > 3:
        return False
    return all(word in BACKCHANNELS for word in words)

함수는 문장 부호를 지우고 소문자로 바꾼 뒤 단어로 쪼갭니다. 세 단어를 넘으면 백채널은 짧다는 전제에 따라 진짜 끼어들기로 취급하고, 모든 단어가 목록에 있어야 참을 돌려줍니다. 그래서 "yeah okay"는 True, "okay but what about the price"는 False입니다(python3 -I로 두 입력의 결과를 확인했습니다). 실제 STT는 같은 소리를 "mm hmm", "mmhmm", "uh huh"처럼 다르게 적으므로 목록이 이 표기들을 포함해야 합니다. 장점은 단어를 이해하므로 "잠깐"과 "음-음"이 더는 같지 않다는 점이고, 단점은 STT가 단어를 내기까지 시간이 걸린다는 점과 고정 목록이 의미를 모른다는 점입니다. "맞아요"는 백채널일 수 있지만 "맞아요, 근데 그게 제 질문이 아니에요"는 아닙니다.

신호 3 — 억양. 사람은 단어만이 아니라 톤도 듣습니다. 백채널은 대개 부드럽고 작은 소리이며, 진짜 끼어들기는 에이전트를 멈추게 하려는 의도로 더 크고 빠르며 에너지가 큽니다. 일부 에이전트는 음량, 음높이, 속도를 듣는 오디오 모델을 써서, 단어는 같고 의도가 다른 작은 "알겠어요"와 큰 "알겠어, 알겠어"를 구분합니다.

신호 4 — 타이밍. 사람은 백채널을 아무 때나 보내지 않고, 구절 끝이나 화자가 짧게 숨 쉬는 작은 휴지에서 보냅니다. 여행 이야기에서 "아침 6시에 도착했는데" 직후의 "음-음"이 자연스러운 자리입니다. 에이전트는 자기 발화를 직접 만들었으므로 휴지가 어디 있는지 알며, 짧은 소리가 그 휴지에 정확히 오면 백채널일 가능성이 높습니다. 문장 중간에 시작해 계속 이어지면 진짜 끼어들기일 가능성이 높습니다.

신호 5 — 종합 모델. 신호별 규칙을 따로 쓰는 대신 실제 대화로 작은 모델을 학습시켜 오디오, 단어, 타이밍을 함께 보고 "백채널" 또는 "끼어들기" 하나로 답하게 할 수 있습니다. 사람이 백채널과 끼어들기를 표시한 많은 예시에서 배우므로 까다로운 경우를 고정 목록보다 잘 처리합니다.

flowchart LR
  A[사용자 오디오 + 단어 + 타이밍] --> B[끼어들기 모델]
  B --> C{판정}
  C --> D[백채널]
  C --> E[끼어들기]

그림 13.13 — 종합 모델은 오디오·단어·타이밍을 한꺼번에 보고 백채널과 끼어들기 중 하나로 답합니다.

더 새로운 풀 듀플렉스(full-duplex) 음성 모델은 한 걸음 더 나갑니다. 풀 듀플렉스는 두 사람이 통화하듯 듣기와 말하기를 동시에 하는 구조이며(13.3 참조), 이런 모델은 별도 규칙 없이 대화 데이터에서 언제 계속 말하고 언제 멈추고 언제 백채널로 볼지를 배울 수 있습니다. 고객 언어와 말투가 다양할수록 고정 목록보다 종합 모델이 유리하며, 그 대가는 학습 데이터와 라벨링 비용입니다.

13.13.4 불확실할 때의 행동

위 신호는 모두 시간이 필요합니다. VAD는 목소리를 거의 즉시 듣지만 STT의 단어는 조금 늦게 나옵니다. 그 틈에 즉시 멈추면 백채널에 멈출 수 있고, 너무 오래 기다리면 실제로 말하려는 사람 위에 계속 말하게 됩니다.

해법은 소프트 일시 정지(soft pause)입니다. VAD가 사용자 목소리를 처음 들으면 완전히 멈추지 않고 음량을 낮추거나 잠시 멈추며 문장 속 위치를 기억합니다. 이후 길이, 단어, 억양, 타이밍을 확인해, 백채널이면 같은 자리에서 이어 말하고 진짜 끼어들기이면 완전히 멈추고 듣습니다. 이렇게 하면 반응이 빠르면서도 답변을 실수로 버리지 않습니다.

또 하나, 백채널은 LLM에 새 메시지로 보내지 않습니다. "음-음"을 사용자가 물은 것처럼 LLM에 넘기면 LLM이 "좋습니다, 더 도와드릴 일이 있나요?" 같은 답을 하려 듭니다. 백채널이 감지되면 새 턴으로 취급하지 않고 계속 진행합니다.

공유기 예시를 백채널 처리와 함께 다시 보면 다음과 같습니다.

단계별로 풀면 다음과 같습니다.

• 첫 번째: "음-음"에서 VAD가 목소리를 들어 음량을 낮추고, STT가 "mm-hmm"을 내자 짧고 목록에 있고 자연스러운 휴지에 왔으므로 같은 자리에서 이어 갑니다.
• 두 번째: "알겠어요"도 부드럽고 짧아 같은 검사를 통과하고 에이전트는 계속합니다.
• 세 번째: "잠깐, 어느 불이 초록색이어야 해요?"는 STT가 "잠깐"과 질문이 든 더 긴 텍스트를 내므로 진짜 끼어들기입니다. 에이전트는 완전히 멈추고 LLM은 이 질문을 새 메시지로 받습니다.

잘 되는 경우와 어려운 경우는 다음과 같습니다.

FAQ에서 확인되는 판단 기준은 두 가지입니다. "알겠어요"는 항상 백채널이 아니며 여러 신호를 함께 봐야 하고, 백채널은 언어마다 다르므로 다국어 서비스는 언어별 검증이 필요합니다. 고객과 대화할 때는 소프트 일시 정지가 구현되어 있는지, 백채널이 LLM 입력으로 새어 들어가지 않는지를 로그에서 확인합니다.

13.14 지연 예산(Latency Budget)

원문: How do you build a latency budget for a voice AI agent?

음성 에이전트는 STT, LLM, TTS 등 여러 단계의 사슬이므로, 단계마다 "충분히 빠르게" 만들어도 합치면 답이 너무 늦어집니다. 이 절은 2026년 10월 글 기준으로, 응답 한 번에 허용하는 총 대기 시간을 단계별로 나누어 각 단계가 지킬 숫자를 정하는 방법과, 그 숫자를 실측하고 줄이는 순서를 설명합니다. (실측 방법 자체는 13.15 참조)

지연(latency)은 무엇을 요청한 시점부터 결과를 받을 때까지의 대기 시간이며, 음성 에이전트에서 가장 중요한 지연은 사용자가 말을 멈춘 순간부터 에이전트의 응답이 들리기 시작할 때까지의 시간인 음성-대-음성 지연(voice-to-voice latency)입니다. 지연 예산(latency budget)은 응답 하나에 허용하는 고정된 총 시간을 그 응답을 만드는 각 단계의 더 작은 시간으로 나눈 것입니다. 월 생활비 30,000루피를 월세 12,000, 식비 8,000, 교통 3,000, 저축 7,000으로 나누면 합이 30,000이고(python3 -I로 확인), 한 항목이 넘치면 어디가 문제인지 알며 총액을 맞추려면 다른 항목이 줄어야 합니다. 지연 예산은 루피 대신 밀리초(ms, 1초의 1000분의 1)를 쓰는 같은 방식입니다.

예산이 필요한 이유는 사람 대화의 간격에 있습니다. 10개 언어 대화를 비교한 잘 알려진 연구에서 한 사람이 끝내고 다른 사람이 시작하기까지의 간격은 흔히 약 200ms였습니다(가장 흔한 값이 0~200ms 구간)(13.4 참조). 뇌는 거의 즉각적인 응답을 기대하므로 에이전트가 2~3초 침묵하면 고장 난 것처럼 느껴지고, 사용자는 "여보세요?"라고 하거나 에이전트 위에 말하기 시작합니다(13.11 참조). 예산은 단계마다 넘지 말아야 할 숫자를 주어 합계가 목표 아래에 머물게 합니다.

13.14.1 총 목표 정하기

먼저 쓸 수 있는 총 시간을 정합니다. 오디오가 여러 모델과 네트워크를 거치므로 200ms 도달은 어렵고, 현실에서 음성 에이전트를 만드는 많은 팀이 음성-대-음성 지연 약 800ms 이하를 목표로 삼습니다. 1초를 한참 넘기는 응답은 느리게 느껴지기 시작합니다. 이 절의 예시는 총 목표 800ms를 씁니다.

시계를 어디서 시작하고 어디서 멈출지도 정해야 합니다.

• 시계는 사용자가 말을 멈춘 때 시작합니다.
• 시계는 에이전트 응답의 첫 소리가 사용자 귀에 닿을 때 멈춥니다.
• 전체 답이 완성되는 시점이 아니라 사용자가 첫 소리를 듣는 시점이 종료점입니다.

종료점을 "첫 소리"로 잡아야 스트리밍의 효과가 예산에 반영됩니다(13.14.5 참조). 고객이 "응답이 빠르다"고 할 때 어느 시점부터 어느 시점까지를 말하는지 먼저 합의합니다.

13.14.2 단계별 시간 배분

시계 사이에 있는 모든 단계를 나열합니다. 일반적인 음성 에이전트 파이프라인은 사용자 발화 종료 → 네트워크(위로) → 엔드포인팅 → STT → LLM → TTS → 네트워크(아래로) → 사용자가 첫 소리를 듣는 순서입니다(13.1 참조).

• 네트워크(위로): 사용자의 휴대폰·브라우저에서 서버까지 음성이 이동합니다.
• 엔드포인팅: 사용자가 차례를 끝냈는지 판단하며, 보통 짧은 침묵을 기다리거나 차례 끝을 예측하는 모델을 씁니다(13.5 참조).
• STT: 음성을 텍스트로 바꿉니다.
• LLM: 텍스트를 읽고 답을 토큰 단위로 생성하며, 첫 토큰이 나오기까지의 시간을 첫 토큰 시간(time to first token)이라 합니다(2.15 참조).
• TTS: 답 텍스트를 오디오로 바꾸며, 첫 오디오 조각이 준비되기까지를 첫 바이트 시간 또는 첫 오디오 시간이라 합니다(13.16 참조).
• 네트워크(아래로): 오디오가 서버에서 사용자에게 돌아가 재생이 시작됩니다.

나열할 때 네트워크와 엔드포인팅 대기를 빠뜨리기 쉽지만 사용자는 그 시간까지 모두 느끼므로 전부 적습니다. 별개의 STT·LLM·TTS 모델로 이어진 구조가 캐스케이드 파이프라인입니다(13.2 참조).

800ms를 나눈 예시 예산은 다음과 같습니다. 숫자는 이해를 위한 예시이며 실제 값은 모델, 하드웨어, 서버 위치에 따라 달라집니다.

합계는 python3 -I로 50+200+100+300+100+50 = 800임을 확인했습니다. 이 표에서 읽을 점은 세 가지입니다.

• LLM이 300ms로 가장 큰 몫을 가집니다. 답을 생각하는 일이 파이프라인에서 가장 무겁기 때문이며, 이 시간은 전체 답을 쓰는 시간이 아니라 첫 토큰이 나오는 시간입니다. 나머지 답은 사용자가 앞부분을 듣는 동안 계속 생성됩니다.
• 엔드포인팅이 두 번째로 큽니다. 사용자가 실제로 끝냈는지 확인하느라 예산의 큰 부분을 기다림에 씁니다.
• STT는 100ms뿐입니다. 스트리밍 STT가 사용자가 말하는 동안 이미 텍스트로 바꾸고 있어서, 말이 끝나면 마지막 몇 단어만 마무리하면 되기 때문입니다.

배분은 네트워크처럼 바꾸기 어려운 단계를 먼저 놓고 남은 시간을 통제할 수 있는 단계에 주는 순서가 좋습니다. 고객에게 예산표를 보여 줄 때는 "단계 합이 목표와 같은가"를 가장 먼저 확인합니다.

13.14.3 실측: 느린 응답 꼬리 보기

종이 위의 예산은 실제로 재지 않으면 쓸모가 없습니다. 모든 대화의 모든 턴에서 단계 경계마다 타임스탬프를 기록하고 단계별 실제 시간을 예산과 비교합니다(기록 방식은 에이전트 관측성, 8.4 참조). 단순한 구현은 다음과 같습니다.

import time

BUDGET_MS = {"endpointing": 200, "stt": 100, "llm_first_token": 300, "tts_first_audio": 100}
marks = {}

def mark(name):
    marks[name] = time.monotonic() * 1000  # ms 단위 시각

def report():
    stages = ["user_stopped", "endpointing", "stt", "llm_first_token", "tts_first_audio"]
    for prev, curr in zip(stages, stages[1:]):
        spent = marks[curr] - marks[prev]
        status = "OK" if spent <= BUDGET_MS[curr] else "OVER BUDGET"
        print(f"{curr}: {spent:.0f} ms (budget {BUDGET_MS[curr]} ms) {status}")

BUDGET_MS는 서버에서 도는 단계의 예산을 담고, mark()는 단계가 끝날 때 현재 시각을 저장하며(사용자 발화가 멈출 때 mark("user_stopped"), 턴이 끝났다고 판단할 때 mark("endpointing") 등), report()는 인접한 표시 사이의 시간을 구해 예산과 비교합니다. 출력 예는 다음과 같습니다.

LLM이 220ms 초과로 가장 큰 문제임을 바로 알 수 있습니다(520-300을 python3 -I로 확인). 네트워크 단계는 서버만으로 재기 어려우므로 사용자 기기에서도 시각을 기록하거나 양쪽을 녹음하는 테스트 통화로 음성-대-음성 전체 시간을 잽니다.

측정 한 번으로는 부족합니다. 턴마다 걸리는 시간이 다르므로 백분위(percentile)를 봅니다. p50은 응답의 절반이 그 아래에 드는 시간으로 보통의 경우를, p95는 100개 중 95개가 그 아래에 드는 시간으로 느린 경우를 말합니다. p50이 750ms인데 p95가 2000ms이면 100번 중 5번은 2초 이상 걸립니다. 턴이 많은 긴 통화에서 사용자는 이런 느린 응답을 만나기 쉽고, 하나하나가 길고 어색한 침묵으로 느껴집니다. 그래서 예산은 p50뿐 아니라 p95 기준으로도 세웁니다.

단계별 p95를 더해도 전체의 정확한 p95가 되지 않습니다. 서로 다른 단계가 느린 순간이 같은 턴에서 일어나지는 않기 때문입니다. 그러므로 음성-대-음성 전체 시간을 직접 재고 그 p95를 따로 추적합니다. 고객의 대시보드가 평균만 보여 주고 있다면 p95부터 요청합니다.

13.14.4 가장 큰 지연부터 줄이기

예산을 넘긴 단계를 알았으면 가장 큰 숫자부터 고칩니다. LLM이 220ms 초과인데 네트워크에서 20ms를 아껴도 도움이 되지 않습니다. 단계별 일반적인 방법은 다음과 같습니다.

고칠 때마다 다시 측정하고 다음으로 큰 숫자를 고치는 일을 총합이 p95에서도 목표 아래에 들 때까지 반복합니다.

엔드포인팅 단계에는 어려운 맞교환이 있습니다. 응답 전에 오래 기다리면 사용자를 거의 끊지 않지만 모든 응답이 느립니다. 짧게 기다리면 모든 응답이 빠르지만 문장 도중 생각하느라 멈춘 사람을 끊기 시작합니다(13.8, 13.9 참조). 그래서 엔드포인팅 몫을 마음대로 줄일 수 없고, 사용자를 너무 자주 끊지 않는 가장 짧은 대기를 찾아 지연과 끼어듦 횟수를 함께 측정해야 합니다. LLM 단계도 같습니다. 큰 모델은 보통 답이 좋지만 첫 토큰이 늦고, 작은 모델은 빠르지만 실수가 늘어납니다. 지연 예산은 품질에 몇 ms를 쓸 수 있는지 명확히 보여 주어 이 선택을 분명하게 합니다. FDE는 고객과 "빠르지만 가끔 끊는 에이전트"와 "느리지만 끊지 않는 에이전트" 중 어느 쪽 불만이 더 비싼지부터 합의합니다.

13.14.5 스트리밍과 도구 호출의 영향

스트리밍이 없는 느린 방식은 각 단계가 앞 단계 완료를 기다립니다. 예시 시간은 다음과 같습니다.

사용자가 아무것도 듣지 못한 채 4300ms가 지나며, 네트워크는 아직 더하지 않았습니다(합계는 python3 -I로 확인). 스트리밍 방식은 다르게 움직입니다.

• STT는 사용자가 말하는 동안 텍스트로 바꿉니다.
• LLM이 첫 짧은 구절을 만들자마자 TTS로 넘어갑니다(13.17 참조).
• TTS가 첫 오디오 조각을 만들자마자 사용자에게 갑니다.
• 사용자가 첫 문장을 듣는 동안 LLM과 TTS는 다음 문장을 계속 만듭니다.

단계들이 겹치므로 줄 서서 앞 사람을 기다리는 대기열이 아니라 조립 라인처럼 움직입니다. 그래서 예산은 LLM의 첫 토큰과 TTS의 첫 조각만 셉니다. 현실에서 TTS는 시작에 짧은 구절이 필요하므로 처음 몇 토큰도 빨리 나와야 하며, 나머지 작업은 사용자가 이미 듣는 동안 일어나 대기 시간을 늘리지 않습니다(13.16 참조).

도구 호출은 예산을 흔듭니다. 지원 에이전트가 주문 상태를 확인하듯, LLM이 도구와 입력("주문 1234의 상태 확인")을 제안하면 에이전트(우리 코드)가 도구를 실행하고 결과를 LLM에 돌려주며, 그 뒤에야 LLM이 실제 답을 씁니다(6.2 참조). 이로 인해 단계가 추가됩니다.

• LLM이 도구 요청을 만드는 시간
• 도구 자체가 실행되는 시간(데이터베이스 조회, 외부 서비스)
• 결과를 답으로 바꾸는 두 번째 LLM 호출

이 단계들은 수백 ms에서 수 초를 더해 800ms 목표를 크게 넘길 수 있으므로 도구 호출에는 별도 예산을 둡니다.

• 도구를 빠르게 유지하고 타임아웃을 두어 느린 도구가 대화를 얼리지 못하게 합니다(13.21 참조).
• 도구가 뒤에서 도는 동안 "확인해 보겠습니다" 같은 짧은 구절을 먼저 말해 예산 안에 소리를 내고 침묵을 막습니다(13.20 참조).
• 통화 시작 때 자주 필요한 데이터를 미리 불러 와 턴 중에 도구 호출이 필요 없게 합니다.

고객 시나리오에 도구 호출이 많다면 800ms 목표를 도구 없는 턴에만 적용하고, 도구가 낀 턴은 별도 목표와 타임아웃을 정하자고 제안합니다.

FAQ에서 확인되는 기준. 음성-대-음성 지연의 시계는 사용자 발화 종료에서 시작해 응답 첫 소리에서 멈추며 전체 답 완성은 종료점이 아닙니다. 예산에서 LLM이 가장 큰 몫(예시 300ms)을 갖지만 첫 토큰까지만 셉니다. p50이 750ms, p95가 2000ms이면 100번 중 5번이 2초 이상이라는 점이 p95 추적의 이유이고, 단계별 p95의 합은 전체 p95가 아니며, 네트워크는 사용자 기기 기록이나 양쪽을 녹음하는 테스트 통화로 잽니다.

13.15 음성-대-음성 지연(Voice-to-Voice Latency) 측정

원문: How does the voice-to-voice latency of a voice agent get measured?

예산을 세워도 숫자를 잘못 재면 개선이 엉뚱한 곳으로 갑니다. 이 절은 2026년 10월 글 기준으로, 음성-대-음성 지연을 "사용자가 말을 멈춘 순간부터 응답의 첫 소리가 사용자 귀에 닿는 순간까지"로 정의하고, 서버 로그가 왜 틀린 답을 내는지, 두 채널 녹음이 왜 맞는 답을 내는지, 여러 통화에 대해 어떻게 자동화하고 어떻게 요약하는지를 설명합니다. (예산 배분은 13.14 참조)

피자 가게 음성 에이전트에 전화해 "라지 치즈 피자 하나 주세요."라고 말하는 장면이 기준 예입니다. "피자"를 끝내고 조용해지면 잠시 뒤 에이전트가 "네, 라지 치즈 피자 하나요."라고 합니다. "피자"의 끝과 "네"의 첫 소리 사이의 침묵이 음성-대-음성 지연입니다. 여기서 두 가지를 짚어야 합니다.

• 시작점은 에이전트가 사용자가 끝났다고 판단한 순간이 아니라 사용자 목소리가 실제로 끝난 순간입니다.
• 종료점은 에이전트가 응답을 만든 순간이 아니라 첫 소리가 사용자 귀에 닿는 순간이며, 사용자는 에이전트가 말을 시작하는 즉시 기다림을 멈추기 때문입니다(13.16 참조).

시작점이나 종료점을 잘못 잡으면 숫자가 틀립니다. 이 숫자가 중요한 이유는 사람 대화의 간격이 10개 언어 비교 연구에서 흔히 약 200ms(1초의 5분의 1)였기 때문입니다. 응답이 너무 오래 걸리면 사용자는 "여보세요?"라고 하거나 다시 말하기 시작해 둘이 동시에 말하고 대화가 깨집니다. 개선하려면 먼저 올바르게 재야 합니다.

13.15.1 시간이 쓰이는 곳

지연은 AI 모델 세 개의 시간 합이 아닙니다. 일반적인 음성 에이전트는 음성을 텍스트로 바꾸는 STT, 텍스트를 읽고 응답을 쓰는 LLM, 응답 텍스트를 음성으로 바꾸는 TTS의 사슬이지만(13.2 참조), 한 턴의 전체 여정에는 그 밖의 시간이 있습니다. 이해를 위한 예시 숫자는 다음과 같습니다.

50+500+100+300+150+50+50 = 1200임을 python3 -I로 확인했습니다. 음성-대-음성 지연은 AI 모델만이 아니라 이 모든 단계의 합입니다. 예산 배분 방법은 13.14에서 다룬 것과 같습니다.

두 단계는 설명이 필요합니다.

• 침묵 대기: 사용자가 숨을 쉬는 중일 수 있으므로 에이전트는 목소리가 멈춘 순간 끝났다고 알 수 없고 일정한 침묵을 기다린 뒤 턴이 끝났다고 결정하며, 이 결정이 엔드포인팅(endpointing)입니다(13.5 참조). 이 대기는 합계에서 가장 큰 부분 중 하나인 경우가 많고, 잘못된 측정이 가장 쉽게 놓치는 부분이기도 합니다.
• 휴대폰 버퍼: 오디오는 인터넷에서 작은 조각으로 오고 조각의 도착 속도가 완전히 고르지 않으므로, 휴대폰은 소리가 끊기지 않도록 몇 조각을 작은 대기 공간에 모아 두었다가 재생하며, 이 대기 공간이 지터 버퍼(jitter buffer)이고 약간의 지연을 더합니다.

고객이 "AI 모델이 느린 것 같다"고 말해도 모델 밖의 대기가 절반일 수 있으므로, 합계를 단계별로 쪼개 보기 전에는 원인을 단정하지 않습니다.

13.15.2 서버 로그 방식

가장 먼저 떠오르는 방법은 서버가 이미 쓰는 로그입니다. 에이전트가 사용자가 끝났다고 결정할 때 한 줄, 응답의 첫 오디오 조각이 서버를 떠날 때 한 줄이 기록됩니다.

차이는 550ms로 좋아 보이지만 틀린 숫자입니다.

• 시계가 에이전트가 사용자가 끝났다고 결정한 시점에 시작하므로 사용자가 실제로 멈춘 뒤의 침묵 대기 500ms와 오디오가 서버에 도달하는 50ms가 빠집니다.
• 시계가 오디오가 서버를 떠날 때 멈추므로 돌아오는 50ms와 휴대폰 버퍼 50ms가 빠집니다.

예시에서 실제 지연은 1200ms인데 서버 로그는 550ms를 말합니다(850-300 = 550). 서버 로그는 대기 시간의 절반 이상을 숨깁니다. 이 방식은 여정 중 서버 안에서 일어나는 부분만 재기 때문입니다. 고객이 서버 로그 기준으로 "500ms대"라고 보고하면, 사용자가 느끼는 값은 그 두 배일 수 있다고 알려야 합니다.

13.15.3 단계별 타임스탬프 방식

해법으로 사용자 휴대폰을 포함해 여정의 모든 단계에 타임스탬프를 남길 수 있습니다(관측성은 8.4 참조). 휴대폰이 사용자 목소리가 끝난 시각을 쓰고, 서버가 단계마다 시각을 쓰고, 휴대폰이 첫 응답 소리가 재생되는 시각을 다시 씁니다. 이 방식의 장점은 단계마다 얼마나 걸리는지 알려 준다는 것입니다. LLM이 갑자기 느려지면 바로 보입니다.

그러나 문제가 있습니다. 휴대폰과 서버의 시계가 서로 다르고 완벽히 동기화되지 않습니다. 휴대폰 시계가 서버보다 수십 ms, 때로는 그 이상 앞서거나 뒤질 수 있습니다. 휴대폰 시계가 서버보다 80ms 앞선다고 하면, 휴대폰 시각에서 서버 시각을 빼 단계 시간을 구할 때 결과에 80ms 오차가 들어가고 결과는 이 오차를 보여 주지 않습니다.

휴대폰 시각 두 개만 쓰는 총합도 정확하지 않습니다.

• "사용자 목소리가 끝난 때"를 휴대폰이 정확히 알기 어렵습니다. 자체 침묵 감지기를 써야 하고 끝을 조금 늦게 또는 이르게 표시합니다.
• "첫 응답 소리가 재생된 때"도 정확하지 않습니다. 앱은 오디오를 스피커에 넘긴 시각을 기록하지만, 소리가 실제로 나오기까지 휴대폰 오디오 시스템이 작은 지연을 더합니다.

단계별 타임스탬프는 서로 다른 시계에서 나오고 총합의 시작점과 종료점도 정확하지 않으므로, 단계별 원인 파악에는 쓰되 총합의 기준값으로는 쓰지 않습니다.

13.15.4 한 타임라인에 통화 녹음하는 방식

해법은 두 채널 녹음(two-channel recording)입니다. 사용자가 듣는 그대로 전체 대화를 두 채널의 오디오 파일 하나로 녹음합니다. 왼쪽 채널에는 사용자의 목소리, 오른쪽 채널에는 사용자 쪽에서 재생되는 그대로의 에이전트 목소리가 담깁니다. 두 목소리가 같은 시계로 녹음된 같은 타임라인에 있으므로 두 시계의 차이가 없습니다.

측정은 세 단계입니다.

• 왼쪽 채널에서 사용자 목소리가 끝나는 시점을 찾습니다.
• 오른쪽 채널에서 에이전트 목소리가 시작되는 시점을 찾습니다.
• 두 번째 시점에서 첫 번째 시점을 뺍니다.

파일에서 사용자 목소리가 4.20초에 끝나고 에이전트 목소리가 5.40초에 시작하면 지연은 5.40-4.20 = 1.20초, 곧 1200ms입니다(부동소수점 표시는 1.2000000000000002이며 의미는 1.20입니다). 통화가 끝난 뒤의 녹음에서 재므로 어느 순간의 앞뒤 오디오를 모두 볼 수 있고, 라이브 통화에서 에이전트가 침묵을 기다리며 확신했던 것과 달리 사용자 목소리가 실제로 끝난 지점을 훨씬 정확히 찾을 수 있습니다.

이 방식은 여정의 모든 부분(양방향 이동 시간, 침묵 대기, 모든 AI 모델 시간, 휴대폰 버퍼)을 포착하므로 사용자 경험에 가장 가까운 값을 줍니다. 녹음은 두 방식으로 얻습니다. 사용자 기기에서 통화를 녹음하거나, 컴퓨터에서 녹음된 사용자 음성을 통화에 재생하고 돌아오는 소리를 녹음하는 테스트 통화를 겁니다. 오디오 편집기에서 소리 파형의 간격을 눈으로 읽는 것은 몇 통화에는 되지만 수천 턴에는 불가능하므로 자동화합니다.

자동화에는 말이 있는 곳과 없는 곳을 가르는 VAD(Voice Activity Detector)가 필요합니다. 20ms 정도의 오디오 조각마다 "말소리 있음/없음"을 답하며, 채널별로 따로 돌려 턴마다 사용자 발화의 끝과 다음 에이전트 발화의 시작을 찾습니다.

def measure_latencies(user_speech, agent_speech):
    # 두 인자는 초 단위 (start, end) 구간 목록
    latencies = []
    for user_start, user_end in user_speech:
        for agent_start, agent_end in agent_speech:
            if agent_start > user_end:   # 사용자가 멈춘 뒤 처음 시작한 에이전트 발화
                latencies.append(round(agent_start - user_end, 2))
                break
    return latencies

user_speech는 VAD가 왼쪽 채널에서 찾은 말소리 구간, agent_speech는 오른쪽 채널의 구간입니다. 사용자 구간마다 그 끝 뒤에 처음 시작하는 에이전트 구간을 찾아 차이를 그 턴의 지연으로 삼습니다. 입력이 user_speech = [(0.5, 2.1), (6.0, 8.3)], agent_speech = [(3.0, 5.2), (9.1, 11.0)]이면 결과는 [0.9, 0.8], 즉 첫 턴 900ms와 둘째 턴 800ms입니다(python3 -I로 실행해 확인했습니다).

이 코드는 단순화한 버전입니다. 실제 구현은 두 가지를 더 처리해야 합니다.

• 사용자가 문장 중간에 잠시 멈출 수 있으므로 짧은 간격으로 떨어진 사용자 구간 둘은 한 턴으로 합쳐야 합니다.
• 사용자가 에이전트 말에 끼어든 턴은 깨끗한 간격이 없으므로 건너뜁니다(13.11 참조).

이렇게 하면 매일 수백 개 테스트 통화에 대해 많은 지연 값을 얻습니다. 잘 되는 점과 어려운 점은 다음과 같습니다.

고객 환경에서는 녹음 채널이 둘로 분리돼 있는지부터 확인하고, 테스트 통화 수치가 실제 통화보다 낙관적일 수 있음을 보고서에 명시합니다.

13.15.5 평균이 아닌 백분위를 보는 이유

많은 수치를 하나로 요약하는 첫 아이디어는 평균이지만, 평균은 빠른 턴과 느린 턴을 섞어 어느 쪽도 잘 설명하지 못하는 숫자 하나로 만듭니다. 10개 턴을 측정해 작은 순으로 얻은 값(ms)이 다음과 같다고 합니다.

합은 10250이므로 평균은 1025ms입니다. 그러나 대부분의 턴이 1000ms 이하이므로 평균은 보통 턴을 실제보다 느리게 보이게 하고, 동시에 2400ms를 기다린 마지막 사용자 이야기는 전혀 하지 못합니다. 그래서 백분위(percentile), 곧 측정값의 주어진 비율이 그 아래에 드는 값을 씁니다.

• p50(중앙값): 턴의 절반이 이보다 빠릅니다. 가운데 두 값이 850과 900이므로 (850+900)/2 = 875ms입니다.
• p90: 턴의 90%가 이 값 이하이며, 10개 중 9개가 1100ms 이하이므로 1100ms입니다.
• p95, p99: 같은 개념의 95%, 99% 값이며 안정적으로 계산하려면 훨씬 많은 턴이 필요합니다.

p50은 전형적인 경험을, p90·p95·p99는 가장 느린 턴이 얼마나 느린지를 말합니다. 실제 테스트는 수천 턴을 재므로 p95와 p99가 2400ms 같은 턴을 뚜렷이 보여 줍니다. p50이 좋아도 p99가 아주 나쁜 에이전트는 일부 사용자에게 무시당한다는 느낌을 줍니다. 그래서 p50과 p95 같은 높은 백분위를 함께 추적하고 둘을 모두 낮춥니다.

FAQ에서 확인되는 기준. 시계는 사용자 목소리의 끝에서 시작해 귀에 닿는 첫 소리에서 멈추고, 침묵 대기는 가장 큰 부분 중 하나이면서 잘못된 측정이 가장 쉽게 놓치는 부분이며, 휴대폰과 서버의 시계를 섞으면 정확한 결과를 얻을 수 없고 두 채널 녹음으로 풉니다. 두 채널 녹음은 단일 음성-대-음성 모델에도 같게 쓰이고, 테스트 통화 수치는 깨끗한 네트워크 때문에 실제 사용자보다 대개 좋게 나옵니다. 고객에게 지연 보고를 받을 때는 시작점·종료점 정의, 측정 방식, p50과 p95의 병기를 한 번에 확인합니다.

13.16 첫 오디오까지의 시간(Time-to-First-Audio)

원문: Why does the time-to-first-audio matter more than total response time?

음성 통화에서 사용자가 느끼는 대기는 에이전트가 말을 시작하기 전의 침묵뿐이므로, 응답 전체가 완성되는 시간보다 첫 소리가 나오는 시간이 체감 속도를 정합니다. 이 절은 2026년 10월 글 기준으로, 두 시간이 각각 무엇을 재는지, 스트리밍이 어떻게 첫 소리를 앞당기는지, 나머지 응답이 따라와야 하는 조건과 총 응답 시간이 여전히 중요한 경우를 설명합니다. (측정 방법은 13.15, 예산 배분은 13.14 참조)

13.16.1 TTFA와 총 응답 시간

음성 AI 에이전트는 사용자의 음성을 듣고, 이해하고, 답을 생각해 음성으로 말하는 시스템이며, 흔한 구현은 세 단계의 사슬입니다. STT가 음성을 텍스트로 바꾸고, LLM이 텍스트를 읽어 텍스트 답을 쓰며, TTS가 답 텍스트를 음성으로 되돌립니다(13.2 참조).

첫 오디오까지의 시간(time-to-first-audio, TTFA)은 사용자가 말을 멈춘 순간부터 사용자가 에이전트 응답의 맨 첫 소리를 듣는 순간까지의 시간이며 음성-대-음성 지연이라고도 합니다. 지연(latency)은 대기 시간이고 밀리초(ms)로 재며 1초는 1000ms입니다. 사용자가 "오늘 가게는 몇 시에 닫아요?"라고 묻고 0ms에 말을 멈췄을 때, 에이전트가 "가게는 오후 9시에 닫습니다."라고 말하고 첫 소리가 700ms에 귀에 닿았다면 TTFA는 700ms입니다.

총 응답 시간(total response time)은 사용자가 말을 멈춘 순간부터 에이전트가 완전한 응답을 다 준비하는 순간까지의 시간입니다. 음성 에이전트에서는 LLM이 응답 텍스트 전체를 쓰고 TTS가 응답 오디오 전체를 만든 때입니다. 같은 예에서 문장 전체의 오디오가 1500ms에 다 만들어졌다면 총 응답 시간은 1500ms입니다. 첫 소리는 전체 응답의 일부이므로 총 응답 시간은 항상 TTFA와 같거나 더 큽니다.

고객이 "응답 속도"라고 말하면 두 시간 중 어느 것을 뜻하는지부터 확인합니다.

13.16.2 통화에서 체감하는 대기

사람들은 대화에서 차례(turn)를 주고받으며(13.4 참조), 10개 언어 대화를 비교한 잘 알려진 연구에서 한 사람이 끝내고 다음 사람이 시작하기까지의 간격은 보통 1초의 일부, 흔히 약 200ms였습니다. 뇌는 거의 즉각적인 응답을 기대합니다.

음성 통화에는 볼 것이 없습니다. 로딩 스피너도 "입력 중…" 점도 없고 소리 아니면 침묵만 있습니다.

• 침묵이 있으면 사용자는 무슨 일이 일어나는지 모릅니다. 에이전트가 들었는지, 통화가 끊겼는지, 다시 말해야 하는지 알 수 없습니다.
• 소리가 있으면 에이전트가 응답하는 중임을 알고 듣기 시작합니다.

그래서 사용자는 이 침묵의 매 순간을 느낍니다. 침묵이 2~3초 이어지면 사용자는 "여보세요?"라고 하거나 다시 말하기 시작하고, 에이전트와 사용자가 서로 겹쳐 말하게 됩니다(13.11 참조). 반대로 에이전트가 말을 시작하면 사용자에게 기다림은 끝나고 단어를 듣는 일에 몰두합니다. 사용자가 느끼는 대기 구간은 하나뿐이고, 그것은 첫 소리 전의 침묵, 곧 TTFA입니다. 총 응답 시간의 나머지는 사용자가 이미 듣고 있는 동안 일어나므로 기다림으로 느껴지지 않습니다.

길을 묻는 친구에게 "자, 먼저 쭉 가시고…"라고 말하면서 동시에 다음 길을 생각하는 상황이 그 예입니다. 말을 빨리 시작했으므로 친구는 우리가 느리다고 느끼지 않고, 설명 후반부가 시작할 때 아직 준비되지 않았다는 것도 모릅니다.

여기에 속도 차이가 더해집니다. 사람은 보통 분당 약 150단어, 곧 초당 2~3단어로 말하는 반면 LLM은 대개 초당 수십 토큰을 쓰고, 좋은 TTS는 1초 분량의 오디오를 1초보다 훨씬 짧게 만듭니다. 그래서 에이전트가 말을 시작하면 시스템은 대개 재생보다 앞서 가고 다음 단어의 오디오가 현재 단어 재생이 끝나기 전에 준비되어 있으므로, 사용자는 나머지 작업을 알아차리지 못합니다. 이것이 TTFA가 에이전트가 빠르게 느껴질지 느리게 느껴질지를 정하는 이유입니다.

두 에이전트로 비교합니다. 둘 다 말하는 데 5초 걸리는 같은 답을 합니다. 에이전트 A는 모든 것이 끝나기를 기다려 전체 전사, 전체 LLM 응답, 전체 TTS 오디오를 다 받은 뒤 재생을 시작합니다. 에이전트 B는 작은 조각이 준비되는 즉시 다음 단계로 넘기며, 청크라 부르는 첫 짧은 오디오부터 나머지가 준비되는 동안 재생합니다. 이해를 위한 단순한 숫자이며 오디오가 사용자에게 가는 네트워크 시간은 50ms로 가정합니다.

A의 첫 소리는 2300+50 = 2350ms이고 B의 첫 소리는 700+50 = 750ms이며, 마지막 단어는 각각 2350+5000 = 7350ms, 750+5000 = 5750ms입니다(python3 -I로 확인했습니다). 두 에이전트의 총 응답 시간은 2초 안팎으로 비슷하지만, A의 사용자는 2.35초 침묵에 앉아 있고 B의 사용자는 0.75초에 첫 소리를 듣습니다. A의 사용자는 통화가 끊겼다고 생각하기 쉽습니다. B에서는 전체 응답 오디오가 약 2000ms에 준비되지만 사용자는 약 5750ms까지 듣고 있어, 총 응답 시간이 듣는 시간 속에 숨습니다. 고객 시연에서는 같은 응답을 전부 대기 방식과 스트리밍 방식으로 들려 주면 TTFA의 효과가 한 번에 전달됩니다.

13.16.3 스트리밍으로 첫 오디오 앞당기기

에이전트 B가 쓰는 기법이 스트리밍(streaming)이며, 각 단계가 전체 출력을 기다리지 않고 조각이 준비되는 즉시 작은 조각으로 다음 단계에 보냅니다(2.15 참조). 단계별 동작은 다음과 같습니다.

• STT: 사용자가 말하는 동안 전사하므로 말을 멈출 때 대부분의 텍스트가 이미 준비되어 있습니다.
• LLM: 응답을 토큰 하나씩 쓰며, 에이전트는 전체 응답을 기다리지 않고 첫 문장이나 짧은 구절이 될 때까지 토큰을 모읍니다(13.17 참조).
• TTS: 그 첫 문장을 즉시 오디오로 바꾸고 작은 청크로 내보내며, 첫 청크가 재생되는 동안 다음 청크가 만들어집니다.

첫 조각의 경로는 사용자 발화 종료 → 에이전트가 끝났다고 판단 → STT 최종 전사 → LLM의 첫 문장 → TTS의 첫 오디오 청크 → 사용자가 첫 소리를 들음 순서입니다. 사용자가 첫 소리를 듣는 동안 LLM은 둘째 문장을 계속 쓰고 TTS는 그 오디오를 계속 만들며, 모든 단계가 응답의 서로 다른 부분에서 동시에 일합니다. 그래서 TTFA가 전체 응답이 아니라 첫 작은 조각에만 좌우됩니다.

TTFA를 이루는 것은 첫 조각의 경로에 있는 단계뿐입니다(13.14 참조).

• 엔드포인팅: 에이전트는 사용자가 말을 마쳤는지 결정해야 합니다(13.5 참조). 사용자가 멈춘 뒤 너무 오래 기다리면 그 대기가 침묵에 그대로 더해지고, 너무 일찍 결정하면 사용자의 말을 끊습니다(13.8 참조).
• 최종 전사: STT가 마지막 몇 단어를 마무리해야 합니다.
• LLM 첫 토큰 시간(TTFT): LLM이 대화를 읽고 첫 토큰을 내야 하며, 프롬프트가 길거나 모델이 클수록 느려지기 쉽습니다.
• 첫 문장: TTS가 시작할 만큼의 토큰, 보통 첫 문장이나 구절을 LLM이 써야 합니다.
• TTS 첫 오디오 청크 시간: TTS가 첫 오디오 청크를 만들어야 합니다.
• 네트워크: 오디오가 서버에서 사용자의 휴대폰이나 브라우저까지 이동해야 합니다.

이 목록에 전체 응답의 길이는 없습니다. 모든 것이 스트리밍되면 10단어 응답과 100단어 응답의 TTFA는 거의 같습니다. 에이전트를 더 빠르게 느끼게 하려면 이 경로의 단계를 줄여야 하며, 첫 조각이 여전히 느린데 전체 응답만 빠르게 만드는 것은 거의 도움이 되지 않습니다. 일반적인 방법은 다음과 같습니다.

• 서버를 사용자 가까이에 두고 모델을 로드된 상태로 유지해 네트워크와 시작 시간을 줄입니다.
• 프롬프트를 짧게 유지해 LLM의 첫 토큰이 빨리 나오게 합니다.
• 긴 첫 문장을 기다리지 않고 첫 짧은 구절을 TTS에 보냅니다.
• 적은 텍스트에서 오디오를 만들기 시작하는 TTS 모델을 씁니다(13.18 참조).
• 사용자가 멈춘 뒤 필요 이상으로 기다리지 않도록 엔드포인팅을 조정합니다.

이 모든 것은 첫 소리 이후에 나머지 응답이 재생을 따라간다는 조건 위에서 성립합니다. 응답 중간에 오디오가 바닥나면 사용자는 틈을 듣게 되고, 문장 중간의 틈은 통화가 끊긴 것처럼 들려 사용자가 다시 에이전트를 의심합니다. 따라서 첫 소리 이후에도 두 가지가 참이어야 합니다.

• LLM이 에이전트가 말하는 속도보다 빠르게 토큰을 써야 합니다. 말하기가 느리므로 대개 쉽습니다.
• TTS가 실시간보다 빠르게 오디오를 만들어야 합니다. 1초 분량을 1초보다 짧게 만든다는 뜻이며, 이를 실시간 계수(real-time factor), 곧 오디오를 만드는 데 걸린 시간을 오디오 길이로 나눈 값으로 재고 1보다 작아야 합니다.

둘 다 참이면 재생을 기다리는 오디오가 바닥나지 않아 사용자는 매끄러운 응답 하나를 듣습니다. 고객 환경에서는 TTFA와 함께 실시간 계수가 1 미만인지, 응답 중간에 틈이 생기는 통화가 있는지를 같이 확인합니다.

13.16.4 총 응답 시간이 여전히 중요한 경우

총 응답 시간이 사라지는 것은 아니며 다음 경우에는 여전히 중요합니다.

FAQ에서 확인되는 기준은 세 가지입니다. TTFA는 음성-대-음성 지연과 같은 말이고, 모든 단계가 스트리밍되면 응답이 길어져도 TTFA는 거의 변하지 않으며, 응답에서 핵심 답을 첫 문장에 두는 것이 긴 응답에서 총 응답 시간의 부담을 줄입니다. 고객과 대화할 때는 TTFA 목표를 먼저 정하고, 도구 호출이 낀 턴과 긴 응답처럼 총 응답 시간이 지배하는 시나리오는 따로 목록으로 만들어 별도 기준을 둡니다.

13.17 TTS용 문장 청킹(Sentence Chunking)

원문: How does sentence chunking feed LLM output into TTS faster?

LLM은 토큰을 하나씩 내보내는데 TTS가 전체 응답을 기다린 뒤에야 말하기 시작하면 사용자는 그 시간 내내 침묵을 듣습니다. 이 절은 2026년 10월 글 기준으로, 토큰을 모아 문장이 끝나는 즉시 TTS로 넘기는 청커의 동작과 문장 끝을 찾는 규칙, 까다로운 경우, 첫 청크를 작게 만드는 방법, 끼어들기 때의 정리를 설명합니다. (LLM 토큰 스트리밍은 2.15 참조)

13.17.1 전체 응답을 기다리는 문제

대부분의 음성 에이전트는 세 부분의 파이프라인입니다. STT가 음성을 텍스트로 바꾸고, LLM이 텍스트를 읽어 응답을 쓰며, TTS가 응답 텍스트를 음성으로 바꿉니다(13.2 참조). LLM은 응답을 한 번에 쓰지 않고 토큰, 곧 단어나 단어 조각 단위의 작은 텍스트를 하나씩 내보내며 이를 스트리밍이라 합니다.

LLM이 "네, 도와드리겠습니다. 주문은 어제 발송되었습니다. 금요일까지 도착합니다. …"로 응답을 시작한다고 합니다. 전체 응답을 쓰는 데 3초가 걸리는데 완성될 때까지 기다렸다가 TTS에 보내면 사용자는 3초 동안 아무것도 듣지 못하고, 그 뒤 TTS가 오디오를 만드는 시간까지 더해집니다. 대화에서 이 침묵은 길게 느껴집니다. 그러나 첫 문장 "네, 도와드리겠습니다."는 1초도 안 되어 완성되므로, TTS는 LLM이 나머지를 쓰는 동안 이미 그 문장을 말할 수 있습니다. 문장 청킹이 이 문제를 풉니다.

문장 청킹(sentence chunking)은 LLM이 내보내는 토큰을 모아 문장이 끝나는 즉시 완성된 문장으로 잘라 TTS에 하나씩 보내는 단계입니다. 이 코드를 청커(chunker)라고 하며 프레임워크에 따라 애그리게이터나 문장 토크나이저라고도 합니다. 청킹을 쓰면 LLM이 토큰을 쓰고, 청커가 모으고, 문장 1이 완성되면 TTS가 말합니다. TTS가 문장 1을 말하는 동안 LLM은 문장 2를 쓰고 청커는 그것을 모으므로 세 부분이 서로 기다리지 않고 동시에 일합니다. 완성된 문장은 대기열에 들어가 LLM이 쓴 순서대로 말해지고, 사용자는 전체 응답이 아니라 첫 문장만 기다립니다. 고객의 음성 응답이 길수록 지연이 길어진다면 청킹이 없다는 신호입니다.

13.17.2 청커 동작과 문장 끝 찾기

도착하는 토큰마다 TTS로 보내면 더 빠를 것 같지만 그렇지 않은 이유는 TTS가 자연스럽게 들리려면 맥락이 필요하기 때문입니다. 영어 "read"는 "I read books every day"에서는 "리드", "I read that book yesterday"에서는 "레드"로 소리 나는데, 소리를 정하는 단어가 문장 뒤쪽에 있어 나머지를 보기 전에 말해야 하면 틀린 쪽을 고르기 쉽습니다. 목소리의 톤도 같습니다. 예/아니오 질문은 "Is it ready?"처럼 끝이 올라가고 평서문은 끝이 내려가는데, 단어가 하나씩만 오면 문장이 어떻게 끝날지 몰라 오르내림을 계획할 수 없으며 이 오르내림이 운율(prosody)입니다.

문장은 이 둘의 중간에 있어 청킹 단위로 흔히 쓰입니다.

청커는 텍스트를 담아 두는 버퍼(buffer)를 가지며 다음 순서로 일합니다.

• 단계 1: LLM에서 새 토큰이 오면 버퍼에 더합니다.
• 단계 2: 버퍼에 완성된 문장이 있는지 확인합니다.
• 단계 3: 있으면 문장을 잘라 TTS에 보내고 남은 텍스트는 버퍼에 둡니다.
• 단계 4: 없으면 다음 토큰을 기다립니다.
• 단계 5: LLM이 끝나면 버퍼에 남은 것을 마침표가 없어도 마지막 청크로 TTS에 보냅니다.

def chunk_sentences(token_stream):
    buffer = ""
    for token in token_stream:
        buffer += token
        while True:
            end = find_sentence_end(buffer)
            if end == -1:
                break
            sentence = buffer[:end].strip()
            buffer = buffer[end:]
            yield sentence          # 즉시 TTS로 전달
    if buffer.strip():              # LLM 종료: 남은 것 전송
        yield buffer.strip()

buffer는 토큰이 올 때마다 자라고, 토큰마다 find_sentence_end를 불러 문장이 끝났는지 봅니다. 끝났다면 잘라 yield로 반복을 멈추지 않고 TTS에 즉시 넘기며, 마지막에 남은 텍스트를 보내 끝 단어를 잃지 않습니다.

가장 단순한 문장 끝 규칙은 마침표, 물음표, 느낌표입니다. 그러나 청커는 텍스트를 토큰 단위로 보므로 마침표를 본 순간 다음에 무엇이 올지 모릅니다. "3."은 아직 "3.5"가 될 수 있으므로 좋은 청커는 문장 부호 뒤에 공백, 줄바꿈, 응답 끝 중 하나가 오는 것을 한 번 더 확인하고서야 문장이 끝났다고 판정합니다.

def find_sentence_end(text):
    for i, ch in enumerate(text):
        if ch in ".?!" and i + 1 < len(text) and text[i + 1].isspace():
            return i + 1   # 문장 부호 바로 뒤에서 자름
    return -1              # 아직 완성된 문장 없음

공백이 뒤따르는 마침표·물음표·느낌표를 찾으면 그 바로 뒤 위치를 돌려주고, 없으면 -1을 돌려 청커가 기다리게 합니다. 이 두 함수를 합쳐 토큰 열 ["Sure",","," I"," can"," help"," with"," that","."," Your"," order","."]을 python3 -I로 돌리면 ['Sure, I can help with that.', 'Your order.']가 나오며, 둘째는 마지막에 남은 텍스트가 전송된 것입니다. 단순한 텍스트에는 충분하지만 다음 소절의 경우에는 깨집니다.

13.17.3 까다로운 경우

모든 마침표가 문장 끝은 아니며, 잘못된 곳에서 자르면 TTS가 문장 반쪽을 말하고 멈췄다가 나머지 반쪽을 말해 부자연스럽습니다.

이를 위해 청커는 추가 규칙을 씁니다.

• "Dr.", "Mr.", "Mrs.", "etc." 같은 흔한 약어 목록을 두고 그 뒤에서는 자르지 않습니다.
• 자르기 전에 다음 단어를 기다려 대문자로 시작하는지 확인합니다. 새 문장은 대개 대문자로 시작하기 때문입니다.
• 연속된 점은 하나의 문장 부호로 취급합니다.

약어 규칙을 넣은 코드는 다음과 같습니다.

ABBREVIATIONS = {"dr.", "mr.", "mrs.", "ms.", "etc."}

def find_sentence_end(text):
    for i, ch in enumerate(text):
        if ch in ".?!" and i + 1 < len(text) and text[i + 1].isspace():
            last_word = text[:i + 1].split()[-1].lower()
            if last_word in ABBREVIATIONS:
                continue          # "Dr."은 문장 끝이 아님
            return i + 1
    return -1

문장 부호 앞의 마지막 단어가 ABBREVIATIONS에 있으면 건너뛰고 계속 찾으므로 "Dr. Sharma will call you."는 한 문장으로 남습니다. 다만 이 코드는 목록에 있는 약어만 막습니다. python3 -I로 확인하면 "10 a.m. tomorrow"의 "a.m."과 "Well..."의 점들은 이 코드에서 여전히 잘리며, 대문자 확인과 연속 점 규칙이 있어야 막을 수 있습니다. 또 "etc."가 문장 맨 끝에 오는 진짜 문장 끝도 이 목록 때문에 넘어가므로 목록은 규칙 하나로 완결되지 않습니다.

반대 문제도 있습니다. 문장이 끝나지 않고 아주 길게 이어지는 경우입니다. LLM이 쉼표가 많은 긴 문장이나 마침표 없는 목록을 쓰면 마침표만 기다리는 청커는 TTS에 오랫동안 아무것도 주지 못해 침묵이 다시 생깁니다. 그래서 최대 길이를 둡니다. 문장 끝 없이 버퍼가 너무 길어지면 버퍼 안 마지막 쉼표, 세미콜론, 콜론에서 자릅니다. 자연스러운 휴지 지점이어서 말이 여전히 괜찮게 들립니다. 최소 길이도 둘 수 있습니다. 응답 중간의 "알겠습니다." 같은 짧은 문장은 다음 문장과 합칠 수 있고, 아주 작은 조각을 TTS에 자주 보내면 말이 뚝뚝 끊기기 때문입니다.

고객 응답에 약어, 숫자, 웹 주소, 코드가 많다면 단순 마침표 규칙으로는 부족하다고 가정하고 실제 응답 샘플로 청크 경계를 확인합니다.

13.17.4 첫 청크를 작게

사용자가 침묵 속에서 기다리는 시간은 첫 오디오가 시작될 때까지입니다(13.16 참조). 그 뒤에는 TTS가 말하는 동안 LLM이 앞서 나갈 시간이 있으므로 속도에는 첫 청크가 가장 중요하고, 이후 청크는 앞 오디오 재생이 끝나기 전에 준비되기만 하면 됩니다.

LLM의 첫 문장이 "네, 계정을 확인했고 주문이 어제 우리 창고에서 발송된 것을 볼 수 있습니다."처럼 길다면, 마침표를 기다리는 동안 사용자는 이 모든 토큰을 기다립니다. 대신 청커가 첫 청크를 첫 쉼표에서 자르면 "네,"가 즉시 TTS로 가서 나머지 문장이 쓰이는 동안 말하기가 시작됩니다. 그래서 두 규칙을 같이 씁니다.

• 첫 청크: 쉼표에서 또는 적은 단어 수 뒤에 일찍 잘라 가능한 빨리 말하기 시작합니다.
• 이후 청크: 완전한 문장에서 잘라 가장 자연스러운 목소리를 얻습니다.

대가는 짧은 첫 조각이 맥락이 적어 톤이 조금 덜 자연스러울 수 있다는 점입니다.

숫자로 따져 봅니다. 가정은 첫 토큰이 질문을 받은 뒤 0.3초에 나오고, 그 뒤 0.1초마다 약 10토큰을 쓰고, TTS는 청크 길이와 관계없이 청크를 받은 뒤 0.2초에 오디오 재생을 시작하며, 응답은 문장 3개(문장당 약 10토큰)라는 것입니다(실제 값은 LLM, TTS, 하드웨어에 따릅니다).

짧은 응답과 빠른 LLM에서는 이득이 작아 보입니다. 응답이 10문장이면 청킹 없이는 LLM이 100토큰을 0.3+1.0 = 1.3초에 끝내 첫 소리가 1.5초에 들리지만, 청킹을 쓰면 첫 소리는 여전히 0.6초입니다(계산은 python3 -I로 확인했습니다). 대기가 응답 길이에 따라 늘지 않고 첫 문장에만 좌우됩니다.

첫 문장이 재생되는 몇 초 동안 LLM은 대개 다음 문장을 이미 다 씁니다. LLM이 말하는 속도보다 빨리 쓰는 한 TTS의 텍스트는 바닥나지 않고 문장 사이에 틈이 없습니다. 각 단계가 대기에 더하는 몫은 지연 예산으로 나눕니다(13.14 참조). 고객과 첫 청크의 최소 단어 수를 정할 때는 "첫 소리가 빨라지는 이득"과 "톤이 덜 자연스러워지는 비용"을 실제 통화 녹음으로 들어 비교합니다.

13.17.5 끼어들기 시 처리

사용자가 에이전트가 말하는 중에 끼어들면(13.11 참조) 에이전트는 즉시 멈춰야 합니다. 문장 청킹에서는 이전 응답이 남아 있는 곳이 여럿입니다.

• 청커 버퍼 안의 토큰
• TTS에 보냈지만 아직 오디오가 되지 않은 문장
• TTS가 만들었지만 아직 재생되지 않은 오디오

끼어들면 이 모두를 비워야 합니다. 곧 버퍼를 비우고, 대기 중인 TTS 요청을 취소하고, 오디오 플레이어를 멈춥니다. 버퍼를 잊으면 사용자가 새 턴을 시작한 뒤에도 옛 응답이 새어 나옵니다. 청킹은 여기서도 도움이 됩니다. 응답이 이미 문장 단위로 나뉘어 있으므로 에이전트는 끼어들기 전에 완전히 재생된 문장이 무엇인지 추적할 수 있고, 그 문장만 대화 기록에 저장해 LLM이 사용자가 실제로 들은 내용을 알게 합니다(13.11.5 참조).

잘 되는 경우와 어려운 경우는 다음과 같습니다.

일부 새 TTS 모델은 텍스트를 라이브 스트림으로 받고 청크 사이의 맥락을 스스로 유지하므로 청커가 더 작은 조각을 보내도 자연스러움을 잃지 않습니다(13.18 참조). 그 경우에도 원칙은 같습니다. 전체 응답을 기다리지 않고 잘 말할 만큼의 텍스트가 모이면 말하기 시작합니다. 한국어 서비스라면 한국어 문장 부호와 종결 어미 뒤에 공백이 없는 텍스트에서 청커가 문장 끝을 찾는지 고객 사례로 검증합니다.

FAQ에서 확인되는 기준. 마침표 뒤 공백을 기다리는 이유는 "3."이 "3.5"가 될 수 있기 때문이고, LLM 종료 후 버퍼에 남은 텍스트는 마지막 청크로 보내 끝 단어를 잃지 않으며, 운율은 문장 전체를 알아야 계획할 수 있는 목소리의 오르내림입니다.

13.18 스트리밍 TTS(Streaming TTS)

원문: How does a TTS model start speaking before the full sentence arrives?

문장 청킹이 TTS에 넣는 입력의 단위를 정한다면(13.17 참조), 스트리밍 TTS는 TTS 모델 자신이 문장이 다 오기 전에 말하기 시작하는 방법입니다. 이 절은 2026년 10월 글 기준으로, TTS가 왜 미래의 단어를 원하는지, 응답 전체 대기·문장 단위·단어 단위의 장단점, 몇 단어 앞만 보는 룩어헤드, 텍스트를 읽으면서 동시에 말하도록 학습된 모델을 설명합니다.

TTS(Text-to-Speech)는 텍스트를 입력받아 음성 오디오를 내는 모델입니다. 음성 비서는 사용자의 음성을 ASR이 텍스트로 바꾸고, LLM이 응답을 쓰고, TTS가 음성으로 바꿔 스피커로 내보내는 순서로 일합니다. LLM은 응답을 한꺼번에 쓰지 않고 토큰을 하나씩 쓰므로(2.15 참조) 텍스트는 TTS에 "Sure,", "Sure, the", "Sure, the weather"처럼 조금씩 도착합니다. 응답 전체를 기다리면 사용자는 침묵 속에 앉아 있고, 너무 일찍 시작하면 목소리가 어색합니다. 언제 말하기 시작할지가 이 절의 질문입니다.

13.18.1 TTS가 전체 문장을 원하는 이유

사람은 소리 내어 읽을 때 눈이 입보다 몇 단어 앞서 가며 앞을 봅니다. TTS 모델도 세 가지 이유로 미래 맥락이 필요합니다.

• 발음이 다음 단어에 달려 있습니다. "I read books every day."의 "read"는 "리드"로, "I read that book last year."의 "read"는 "레드"로 소리 납니다. 모델이 "I read"까지만 보면 어느 쪽이 맞는지 알 수 없고 답은 뒤에 오는 단어에 있습니다.
• 문장의 가락이 끝에 달려 있습니다. 목소리의 오르내림인 운율(prosody)에는 음높이, 속도, 휴지, 단어 강세가 포함됩니다. "You are coming tomorrow."와 "You are coming tomorrow?"는 단어가 같고 마지막 부호만 다르지만, 뒤의 것은 질문이므로 끝이 올라가며 모델은 맨 끝의 물음표를 볼 때에야 이를 압니다.
• 숫자와 약어가 맥락에 달려 있습니다. "Dr."은 Doctor일 수도 Drive일 수도 있고, "2025"는 "two thousand twenty-five"로도 "twenty twenty-five"로도 읽힙니다. 주변 단어가 있어야 정할 수 있습니다.

대부분의 TTS 모델은 완성된 문장으로 학습되어 항상 미래 단어를 보므로 자연스럽게 들리고, 같은 이유로 시작이 느립니다. 한국어로는 같은 철자의 숫자와 단위("3월 2일", "2025")를 어떻게 읽는지가 뒤따르는 단어에 좌우되므로 고객 응답 샘플에서 먼저 시험합니다.

13.18.2 문장 단위 vs 단어 단위 발화

세 가지 접근을 차례로 봅니다.

접근 1 — 응답 전체를 기다립니다. LLM이 3초 동안 전체 응답을 쓰고 TTS가 1초 동안 전체 오디오를 만들면 사용자는 약 4초 동안 아무것도 듣지 못합니다. 사람 사이의 일반적인 말 사이 휴지는 1초보다 훨씬 짧습니다(13.4 참조).

• 장점: TTS가 모든 것을 보므로 목소리가 가장 자연스럽습니다.
• 단점: 첫 소리 전의 침묵이 응답 길이에 따라 늘어납니다.

사용자의 질문이 끝난 시점부터 첫 소리까지의 시간이 첫 오디오까지의 시간(time to first audio)이며 줄여야 하는 숫자입니다(13.16 참조). 단계별 기여는 지연 예산으로 나눕니다(13.14 참조).

접근 2 — 문장 단위로 말합니다. 첫 완성 문장만 기다립니다. LLM 텍스트를 버퍼에 모으다가 ".", "?", "!" 같은 문장 끝 표시가 보이면 그 문장을 TTS에 보냅니다.

buffer = ""
for token in llm_stream():
    buffer += token
    if buffer.strip().endswith((".", "?", "!")):
        audio = tts.synthesize(buffer)
        play(audio)
        buffer = ""

llm_stream()은 토큰을 하나씩 주고, buffer가 토큰을 모으며, 버퍼가 문장 끝 표시로 끝나면 tts.synthesize()에 보내고 오디오를 재생한 뒤 버퍼를 비웁니다. 코드는 이해를 위해 단순화했고 실제 시스템에서 play()는 백그라운드로 돌아 오디오가 재생되는 동안에도 루프가 새 토큰을 읽습니다. 첫 문장이 재생되는 동안 LLM은 둘째 문장을 쓰므로 다음 오디오가 대개 첫 오디오가 끝날 때쯤 준비됩니다.

• 장점: 문장이 완성되어 있어 발음과 가락에 필요한 단서를 모두 얻습니다.
• 단점: 완성된 첫 문장을 기다려야 하므로 첫 문장이 길면 대기도 깁니다.

실제 시스템은 문장이 너무 길어지면 쉼표에서도 나누지만 대기는 첫 조각의 길이에 여전히 좌우되며, 위 코드 같은 단순 규칙은 "Dr."에서 잘못 나누므로 더 나은 문장 분리기를 씁니다. 이 접근은 단순하고 어떤 TTS 모델과도 쓸 수 있어 음성 비서에서 흔합니다.

접근 3 — 단어 단위로 말합니다. 반대 극단으로, 도착하는 즉시 모든 단어를 TTS에 보냅니다. "Sure,"가 오면 "Sure,"를 말하고 "the"가 오면 "the"를 말합니다.

• 장점: 첫 단어 직후부터 말하므로 첫 오디오까지의 시간이 짧습니다.
• 단점: 소리가 끊기고 로봇 같습니다.

각 단어를 다음에 올 말을 모른 채 따로 말하기 때문에 앞의 세 이유가 모두 되살아납니다. "I read"는 추측으로 발음되고 추측은 자주 틀립니다. 물음표가 아직 오지 않아 질문에서 목소리가 오르지 않습니다. "Dr."은 Doctor인지 Drive인지 모른 채 읽힙니다. 게다가 각 단어가 자기만의 시작과 끝을 가져 단어 사이의 매끄러운 흐름도 없습니다. 이 접근은 TTS가 미래를 전혀 보지 못한다는 점이 문제입니다. 고객에게 "가장 빨리 시작하는 설정"을 요청받더라도 단어 단위 발화가 음질에서 무엇을 잃는지 녹음으로 먼저 들려 줍니다.

13.18.3 작은 룩어헤드 방식

룩어헤드(lookahead)는 TTS 모델이 단어를 말하기 전에 그 뒤의 몇 단어를 더 볼 때까지 기다리는 방식입니다. 전체 문장을 기다리지도, 단어를 따로 말하지도 않고, 눈이 입보다 조금 앞서가는 사람 독자처럼 텍스트보다 몇 단어만 뒤처집니다. Baidu 연구진이 2020년 논문 "Incremental Text-to-Speech Synthesis with Prefix-to-Prefix Framework"에서 이 아이디어를 설명했습니다. 점진적 TTS(incremental TTS)는 텍스트가 도착하는 대로 조각조각 음성을 만드는 것이고, 프리픽스(prefix)는 문장의 앞부분입니다. 곧 모델이 텍스트의 앞부분만으로 오디오의 앞부분을 만들고, 텍스트가 더 오면 이어 갑니다. 영어와 중국어 실험에서 1~2단어만의 룩어헤드로도 전체 문장 TTS에 가까운 음성이 나왔다고 합니다(2026년 10월 글 기준 인용).

룩어헤드가 2단어일 때 동작은 다음과 같습니다.

"read"는 모델이 "that book"을 본 뒤에야 말해지므로 올바른 소리를 고를 맥락이 더 늘었습니다. 그러나 이 문장에서 가장 분명한 단서는 4단어 떨어진 "last year"이며, 2단어 룩어헤드는 거기까지 닿지 못해 모델은 여전히 추측해야 합니다. 모델은 이미 만든 오디오를 버리지 않고 멈춘 곳에서 매끄럽게 이어 가므로 단어 사이의 이음새가 자연스럽습니다. 또한 대기는 문장 길이가 아니라 룩어헤드에만 좌우되어, 문장이 5단어든 50단어든 처음 몇 단어 뒤에 말하기 시작합니다.

한계는 TTS 모델이 완성된 문장으로 학습되었기 때문에 반쪽짜리 문장을 주면 학습 때 보지 못한 입력을 받게 되어 품질이 떨어질 수 있다는 점입니다. 룩어헤드는 클수록 음질이 좋고 대기가 길며, 작을수록 시작이 빠르고 실수가 늘어나므로 용도에 맞춰 고릅니다.

13.18.4 읽으며 동시에 말하는 모델

더 새로운 방법은 모델 자체를 텍스트를 받으면서 동시에 오디오를 내도록 학습시키는 것입니다. 들어오는 텍스트와 나가는 오디오 두 스트림을 한꺼번에 다루므로 듀얼 스트리밍(dual-streaming) 또는 바이스트리밍 TTS라 부릅니다. 먼저 음성 토큰(speech token)을 알아야 합니다. 많은 현대 TTS는 음파를 직접 만들지 않고 조각마다 아주 짧은 소리 구간을 나타내는 작은 코드인 음성 토큰을 먼저 만들고, 두 번째 부분이 이 코드를 청크 단위로 실제 음파로 바꾸므로 소리가 일찍 재생되기 시작합니다.

두 가지 방식이 있습니다.

• 방식 1 — 텍스트 토큰과 음성 토큰을 교차로 섞습니다. Alibaba의 TTS 모델 CosyVoice 2가 이렇게 하며, 학습할 때 텍스트 토큰과 음성 토큰을 고정 비율로 섞습니다. 논문은 비율을 N:M으로 일반화해 적고, 공개 구현의 기본값은 텍스트 토큰 5개 뒤에 음성 토큰 15개이며, CosyVoice 2는 오디오 1초당 음성 토큰 25개를 만들므로 15개는 약 0.6초 분량입니다(15/25 = 0.6, python3 -I로 확인). 모델은 "텍스트를 조금 읽고 소리를 조금 내고, 또 조금 읽고 또 조금 낸다"는 습관을 배우므로 사용할 때 전체 문장이 필요 없고 다음 음성 토큰 15개를 위해 텍스트 토큰 5개만 있으면 됩니다. 더 읽을 준비가 되면 채움 토큰(filling token)이라는 특별한 토큰을 출력해 시스템에 다음 텍스트 토큰 5개를 가져오라고 알립니다.
• 방식 2 — 텍스트와 오디오 사이에 고정 지연을 둡니다. 파리의 AI 연구소 Kyutai의 Delayed Streams Modeling이 이렇게 합니다. 텍스트와 오디오를 같은 시계에 놓고 오디오 스트림을 텍스트 스트림보다 고정된 단계 수만큼 뒤에 둡니다. 모델이 한 순간의 오디오를 말할 때 그 뒤에 오는 텍스트를 조금 이미 읽은 상태입니다. 룩어헤드와 같은 아이디어이지만 처음부터 이 지연을 두고 학습되어 반쪽짜리 문장이 놀랄 일이 아니라 정상이라는 점이 다릅니다.

장점은 자연스러운 목소리와 빠른 첫 오디오입니다. 단점은 이렇게 학습된 모델이 필요하다는 점이며, 아무 TTS 모델이나 가져와서 이 동작을 얻을 수는 없습니다. 고객이 쓰는 TTS 제품이 텍스트 스트림 입력을 지원하는지, 지원하지 않는다면 문장 청킹이 필요한지를 사양서에서 먼저 확인합니다.

숫자로 비교합니다. LLM이 초당 10토큰을 쓰고, 응답이 "Sure, the weather in Delhi is sunny today, with a high of thirty degrees."이며, 이해를 위해 단어 하나를 토큰 하나로 치면 14토큰입니다. TTS는 필요한 텍스트를 얻은 뒤 첫 오디오 조각을 만드는 데 0.2초가 걸린다고 가정합니다.

몇 토큰만 앞서 읽어도 첫 소리가 1.6초에서 0.5초 또는 0.7초로 줄어듭니다. 응답이 3문장이면 접근 1은 훨씬 더 느려지지만 접근 4와 5는 같은 시점에 시작합니다.

잘 되는 경우와 어려운 경우는 다음과 같습니다.

속도와 품질 사이에는 늘 균형이 있고, 룩어헤드를 키우면 음성이 좋아지지만 대기가 길어지고 줄이면 시작이 빠르지만 실수가 늘어납니다. 어순상 동사가 끝에 오는 한국어도 같은 구조에 해당하므로 한국어 고객 사례에서는 긴 문장의 어미 억양(평서·의문)이 룩어헤드 설정에서 어떻게 들리는지를 반드시 청취 시험으로 확인합니다.

FAQ에서 확인되는 기준. 룩어헤드를 작게 쓰면 첫 오디오까지의 시간이 문장 길이가 아니라 룩어헤드에만 좌우되고, Baidu 논문에서는 1~2단어 룩어헤드로 전체 문장 TTS에 가까운 결과가 보고되었습니다. 음성 토큰은 소리 조각을 나타내는 코드이고, CosyVoice 2의 채움 토큰은 모델이 더 읽을 준비가 되었을 때 다음 텍스트 토큰 5개를 요청하는 신호입니다.

13.19 투기적 LLM 생성(Speculative Generation)

원문: How does speculative LLM generation start replying before the user finishes?

음성 에이전트의 응답 지연 가운데 침묵 대기와 LLM의 첫 토큰 대기는 순서대로 쌓이는 두 덩어리이며, 이 둘을 겹치면 사용자가 느끼는 지연이 줄어듭니다. 이 절은 2026년 10월 글 기준으로, 사용자가 말을 마치기 전에 응답을 미리 만들어 두었다가 최종 발화가 같을 때만 재생하는 기법의 동작, 실패 처리, 비용, 적용 조건을 다룹니다. (음성 에이전트의 전체 구조는 13.1 참조)

13.19.1 기다리는 시간이 생기는 곳

일반적인 음성 에이전트는 STT(Speech-to-Text, 음성을 텍스트로), LLM(텍스트를 읽고 답을 쓰는 모델), TTS(Text-to-Speech, 답을 음성으로)가 사슬처럼 이어진 구조입니다(13.2 참조). STT 옆에는 사용자가 말을 마쳤는지 판단하는 발화 종료 감지(end-of-turn detection)가 함께 돌며, 침묵과 지금까지의 단어를 보고 "이제 우리 차례"라고 알립니다(13.4, 13.5, 13.6 참조). 이 구조의 약점은 발화 종료 감지가 "끝났다"고 말하기 전에는 LLM이 시작하지 않는다는 점입니다. 모든 단계가 한 줄로 서서 기다립니다.

사용자가 "오늘 델리 날씨 어때?"라고 묻고 멈춘 상황을 봅시다. 에이전트는 멈춘 순간 바로 답할 수 없습니다. 숨을 쉬는 것일 뿐 "...내일은?"이 이어질 수 있기 때문에, 발화 종료 감지는 짧은 침묵을 확인한 뒤에야 판정합니다. 그 다음에야 LLM이 답의 첫 토큰을 만들고(2.15 참조), TTS가 첫 오디오를 만듭니다. 사용자는 세 가지 대기를 차례로 겪습니다.

• 발화 종료 감지의 침묵 대기
• LLM이 첫 토큰을 내는 시간
• TTS가 첫 오디오를 내는 시간

사람 사이의 대화에서 한 사람이 멈추고 다른 사람이 시작하기까지의 간격은 대개 1초가 되지 않습니다. 세 대기가 합쳐진 간격은 이보다 길어져 대화가 느리고 기계적으로 느껴집니다(13.14, 13.15 참조). 침묵 대기와 LLM 대기는 순서대로 일어나는 두 덩어리이므로, 고객이 "응답이 굼뜨다"고 말할 때는 이 중 어느 덩어리가 큰지부터 실측해 나눠 봅니다.

13.19.2 단계별 동작

투기적 LLM 생성(speculative LLM generation)은 사용자가 말을 마쳤다고 확신하기 전에 지금까지의 단어를 LLM에 보내고, 만들어진 응답을 재생하지 않은 채 대기시키는 기법입니다. 투기적(speculative)은 "추측에 근거한"이라는 뜻입니다. 에이전트는 현재 가진 단어가 최종 발화라고 추측하고 일을 시작하며, 나중에 발화 종료 감지가 턴 종료를 확인하면 추측이 맞았는지 검사합니다. 일부 음성 에이전트 프레임워크는 같은 아이디어를 선제 생성(preemptive generation)이라 부릅니다.

용어 주의: 투기적 디코딩(speculative decoding)은 작고 빠른 모델이 몇 토큰을 앞질러 추측해 LLM의 토큰 생성 자체를 빠르게 하는 별개의 기법입니다(10.6 참조). 여기서 말하는 것은 사용자 턴이 확정되기 전에 LLM 호출을 앞당기는 기법입니다.

비유하면 매일 가는 찻집과 같습니다. 문을 열고 "차 한 잔..."이라고 말하는 순간 주인이 물을 끓이기 시작합니다. "...차요"로 끝나면 차가 빨리 나오고, "...커피요"로 끝나면 차를 치우고 커피를 새로 만듭니다. 한 잔을 버리지만 대부분의 날에는 더 빨리 받습니다.

사용자가 "Book a table for two at 8 PM."이라고 말하는 예로 일곱 단계를 따라갑니다. STT는 문장이 끝나기를 기다리지 않고 중간 텍스트를 계속 보내는데, 이를 중간 전사(interim transcript, partial transcript)라 하고, STT가 확신하는 구간에 내는 확정 텍스트를 최종 전사(final transcript)라 합니다.

1. 사용자가 말하는 동안 STT가 "Book a", "Book a table", "Book a table for two"를 차례로 보냅니다.
2. 사용자가 "...at 8 PM"을 말하고 멈추면 STT가 최종 전사 "Book a table for two at 8 PM."을 보냅니다.
3. 에이전트는 발화 종료 감지를 기다리지 않고 이 문장을 LLM에 바로 보냅니다. 이것이 투기적 요청입니다.
4. LLM이 "Sure, let me check if a table for two is free at 8 PM."을 쓰기 시작하고, 에이전트는 이를 버퍼(buffer, 임시 보관 영역)에 쌓습니다. 사용자에게는 아직 아무것도 재생하지 않습니다.
5. 같은 시간에 발화 종료 감지는 침묵 대기를 이어갑니다.
6. 침묵 대기가 끝나고 "사용자가 끝냈다"는 판정이 나옵니다. 이때 버퍼에는 응답의 첫 부분이 이미 있습니다.
7. 에이전트가 투기적 요청에 쓴 단어와 턴의 최종 단어를 비교하고, 같으면 버퍼의 응답을 즉시 재생합니다.

flowchart TB
    subgraph N["일반 에이전트"]
        direction TB
        n1["사용자 멈춤"] --> n2["침묵 대기"] --> n3["턴 종료 확정"] --> n4["LLM 시작"] --> n5["LLM 첫 토큰"] --> n6["TTS 첫 오디오"] --> n7["재생 시작"]
    end
    subgraph S["투기적 에이전트"]
        direction TB
        s1["사용자 멈춤"] --> s2["LLM 작업과 침묵 대기가 동시에 진행"] --> s3["턴 종료 확정, 첫 토큰은 이미 버퍼에 있음"] --> s4["TTS 첫 오디오"] --> s5["재생 시작"]
    end

그림 13.19.2 — 투기적 생성은 LLM 작업을 침묵 대기 안에 겹쳐 넣어 순차 구조를 병렬로 바꿉니다.

LLM에 필요한 시간이 에이전트가 어차피 기다리려던 시간 속에 숨는다는 것이 핵심입니다. 고객 시스템에서 이 기법을 검토할 때는 현재 침묵 대기 설정값과 LLM 첫 토큰 시간부터 받아 겹칠 수 있는 구간의 크기를 계산해 봅니다.

13.19.3 추측이 맞을 때

최종 단어가 LLM에 보낸 단어와 같으면 버퍼의 응답은 에이전트가 원래 만들었을 응답과 동일합니다. 사용자는 같은 답을 더 빨리 받을 뿐입니다. 절약되는 시간은 최대 LLM의 첫 토큰 시간이며, 이 시간은 많은 음성 에이전트에서 사슬 전체의 큰 대기 가운데 하나입니다. 이해를 돕기 위한 가정값으로 침묵 대기 500ms, LLM 첫 토큰 400ms를 두고 python3로 계산하면 다음과 같습니다.

LLM이 침묵 대기보다 오래 걸리면 겹칠 수 있는 부분이 침묵 대기까지뿐이므로 절약량은 침묵 대기 시간과 같아집니다. 같은 침묵 500ms에서 LLM이 700ms 걸리면 일반 에이전트는 1,200ms, 투기적 에이전트는 700ms 뒤에 TTS를 시작하여 500ms가 절약됩니다. 즉 절약량은 min(침묵 대기, LLM 첫 토큰 시간)입니다. 침묵 대기를 짧게 튜닝해 둔 시스템은 이 기법의 이득이 작고, 긴 대기와 느린 모델을 쓰는 시스템은 이득이 큽니다.

13.19.4 추측이 틀릴 때와 단어 변경 감지

사용자가 "Book a table for two..."라고 말하고 생각하느라 멈추는 경우(13.9 참조), STT는 이 단어들의 최종 전사를 보내고 에이전트는 이 멈춤을 끝일 수 있다고 보아 "Book a table for two"를 LLM에 보냅니다. LLM은 "Sure, for what time?"이라고 쓰기 시작합니다. 그런데 사용자가 "...at 8 PM, near the window."로 이어 말합니다. 시간을 이미 말했으므로 이 응답을 재생하면 사용자는 혼란스러워합니다. 새 단어가 STT에서 도착하는 즉시 에이전트는 다음을 수행합니다.

• 진행 중인 LLM 요청을 취소해 더 이상 토큰을 만들지 않게 합니다.
• 버퍼의 내용을 모두 버립니다.
• 전체 단어 "Book a table for two at 8 PM, near the window."의 최종 전사가 오면 새 투기적 요청으로 LLM에 보냅니다.

사용자는 틀린 응답을 듣지 않습니다. 응답이 버퍼에만 있었고 재생된 적이 없기 때문입니다. 첫 요청은 낭비되지만 새 요청도 턴 종료 확정 이전에 시작되므로 정확성에서 잃는 것은 없으며, 손실은 첫 요청의 LLM 작업뿐입니다.

단어가 바뀌었는지는 에이전트가 투기적 요청에 보낸 정확한 단어의 사본을 들고 있다가, 발화 종료 감지가 "끝났다"고 할 때 턴의 최종 단어와 비교해 알아냅니다. 같으면 버퍼의 응답을 쓰고 다르면 버리고 새로 요청합니다. 일부 에이전트는 단어뿐 아니라 요청에 함께 실린 다른 요소, 예를 들어 대화 기록과 LLM이 추천할 수 있는 도구 목록까지 비교합니다. 도구는 예약 시스템 조회처럼 에이전트 코드가 실행하는 함수이며(6.2 참조), 이들 중 하나라도 그 사이에 바뀌었다면 이른 응답은 더 이상 유효하지 않으므로 마찬가지로 버립니다.

용어 주의: 투기적 응답은 턴 종료가 확정되고 비교를 통과하기 전에는 절대 재생하지 않습니다. 이 기법이 안전한 이유는 이른 응답이 검사를 통과할 때까지 숨겨져 있다는 한 가지뿐입니다.

고객 구현을 검수할 때는 비교 대상이 단어만인지, 대화 기록과 도구 목록까지 포함하는지, 비교 실패 시 이전 요청을 실제로 취소하는지를 확인합니다.

13.19.5 음성도 미리 준비하기

같은 아이디어를 TTS에도 적용할 수 있습니다. LLM이 투기적 응답의 첫 문장을 만드는 즉시 에이전트가 그 문장을 TTS에 보내(13.17 참조) 만들어진 오디오도 버퍼에 보관합니다. 턴 종료가 확정되고 단어가 일치하면 TTS를 기다릴 필요도 없습니다. 첫 오디오가 이미 준비되어 있으므로(13.16 참조) 즉시 재생됩니다. 단어가 다르면 버퍼의 텍스트와 오디오를 모두 버립니다.

이 때문에 많은 구성은 기본적으로 LLM만 일찍 돌리고, 추가 속도가 추가 낭비를 감수할 만할 때만 TTS도 일찍 돌립니다. 고객에게는 낭비가 LLM 토큰 한 겹인지 TTS 합성까지 두 겹인지를 구분해서 비용을 설명합니다.

13.19.6 비용

투기적 생성의 대가는 틀린 추측마다 돈을 내고도 쓰지 못하는 요청이 생긴다는 점입니다. 사용자가 긴 문장 중간에 세 번 멈추면 한 턴에 투기적 요청이 네 번(멈춤마다 한 번과 실제 끝에서 한 번) 나갈 수 있고, 마지막 하나만 쓰입니다. 네 번 중 세 번, 즉 75%가 버려집니다. LLM 제공자가 토큰 단위로 과금하면 버려진 토큰도 비용이며 TTS도 같습니다. 또 하나의 비용은 부하입니다. 요청이 늘면 LLM 서버의 작업이 늘고, 동시에 많은 사용자가 말하면 이 추가 부하가 모두의 응답을 늦출 수 있습니다. 에이전트는 두 가지 사이에서 균형을 잡아야 합니다.

• 일찍 시작해서 응답을 빠르게 하는 것
• 너무 자주 시작하지 않아 낭비를 낮게 유지하는 것

낭비를 줄이는 흔한 방법은 모든 중간 전사가 아니라 STT의 최종 전사에서만 투기적 요청을 시작하는 것입니다. 중간 전사는 사용자가 말하는 동안 자주 바뀌므로 매번 시작하면 버려지는 작업이 많아집니다.

적용 조건은 다음과 같이 갈립니다.

마지막으로 투기적 요청은 응답을 준비하기만 해야 하며 현실 세계의 행동을 해서는 안 됩니다. 추측이 아직 틀릴 수 있기 때문입니다. 투기적 응답에 주문을 넣는 도구 호출이 들어 있는 경우를 봅시다. LLM은 도구 호출을 추천할 뿐이고 실행은 에이전트 코드가 하므로, 에이전트는 그 도구 호출을 붙들고 있다가 턴이 확정된 뒤에만 실행하며 투기 단계에서는 실행하지 않습니다. 어떤 도구를 일찍 시작해도 안전한지는 읽기 전용 여부로 가립니다(13.21 참조). 고객이 "주문·결제 에이전트에 이 기법을 켜도 되는가"를 물으면, 쓰기 동작이 턴 확정 이후로 지연되는지를 먼저 확인하는 것이 판단 기준입니다.

13.20 필러 구문(Filler Phrase)

원문: How do filler phrases hide latency in a voice agent?

전화 통화에서 침묵은 지연 그 자체보다 사용자의 행동을 더 크게 바꿉니다. 이 절은 2026년 10월 글 기준으로, 실제 답이 준비되는 동안 짧은 한마디로 침묵을 채우는 필러 구문의 원리, 말할 시점, 생성 방식, 대화 기록 처리, 끼어들기 대응, 그리고 해가 되는 경우를 다룹니다.

13.20.1 필러 구문이 지연을 가리는 원리

음성 에이전트는 STT, LLM, TTS 세 단계가 이어진 파이프라인이며(13.2 참조), 사용자가 말을 멈춘 시점부터 에이전트가 말을 시작하기까지의 대기가 지연(latency)입니다(13.15 참조). 여러 언어의 대화를 조사한 연구에서 사람 사이의 간격은 대개 200ms, 즉 1초의 5분의 1 안팎으로 보고되었습니다. 그런데 사용자가 "주문번호 4521 상태가 어떻게 되나요?"라고 물으면 에이전트는 기억만으로 답할 수 없고 도구를 호출해 DB나 외부 서비스에서 주문을 조회해야 하며(6.2 참조), 이 조회는 1초, 2초 혹은 그 이상 걸립니다. 그 동안 사용자는 아무것도 듣지 못합니다. 2~3초의 침묵은 통화에서 길게 느껴지고 사용자는 "내 말이 들렸나", "통화가 끊겼나", "다시 말해야 하나"를 생각하다가, 에이전트가 막 말을 시작하는 순간 "여보세요?"라고 말해 두 목소리가 겹치고 대화가 깨집니다. 도구 호출은 자기 시간이 필요하므로 대기를 항상 없앨 수는 없습니다. 바꿀 수 있는 것은 그 시간 동안 사용자가 듣는 내용입니다.

필러 구문(filler phrase)은 에이전트가 진짜 답을 준비하는 동안 사용자를 침묵에 두지 않으려고 말하는 짧고 자연스러운 한마디입니다. "Let me check that for you.", "One moment, please.", "Sure, let me pull up your order.", "Give me a second while I look that up." 같은 문장이 예입니다. 상담센터의 상담원이 컴퓨터를 입력하는 동안 말없이 있지 않고 "네, 확인해 드리겠습니다"라고 말하는 것과 같으며, 누군가 처리 중이라는 것을 알면 기다림이 견딜 만해집니다.

진짜 답이 필러 없이는 3,000ms 뒤에 시작된다고 가정하고 두 타임라인을 비교합니다.

실제 답이 도착하는 시점은 3,000ms로 같고 전체 작업은 조금도 빨라지지 않았습니다. 사용자가 에이전트의 응답 시작을 듣는 시점만 3,000ms에서 800ms로 앞당겨졌습니다. 이 예에서 800ms는 발화 종료를 확인하는 시간(13.4 참조), STT가 음성을 텍스트로 바꾸는 시간, LLM이 주문 조회를 결정하는 시간을 합친 가정값입니다. 따라서 지연은 두 가지로 구분합니다.

• 실제 지연(actual latency): 진짜 답이 준비되기까지의 시간. 필러가 바꾸지 못합니다.
• 체감 지연(perceived latency): 사용자가 에이전트가 일하고 있음을 보여 주는 소리를 듣기까지의 시간(13.16 참조). 필러가 크게 줄입니다.

필러 자체도 말하는 데 시간이 듭니다. "Sure, let me check that for you"는 보통 속도로 소리 내어 말하면 약 2초이며, 이 2초 동안 도구 호출이 동시에 진행됩니다. 위 예에서 필러는 약 800ms부터 약 2,800ms까지 재생되고 진짜 답은 3,000ms에 시작하므로, 필러 뒤의 침묵은 약 200ms로 줄어듭니다. 체감 지연은 3,000 − 800 = 2,200ms만큼 짧아진 셈입니다. 필러는 대기를 없애지 않고 말로 채웁니다. 고객 현장에서는 "응답이 느리다"는 불만이 실제 지연 문제인지 침묵 문제인지부터 나눠 묻습니다.

13.20.2 언제 말할지

모든 응답 앞에 필러를 붙이면 안 됩니다. 사용자가 "안녕하세요"라고 했는데 에이전트가 "잠시만요" 뒤에 "안녕하세요"를 말하면 어색하며, 단순한 질문은 어차피 응답이 빨라 필러가 말만 늘립니다. 그래서 규칙이 필요하고, 흔한 트리거는 두 가지입니다.

트리거 1: 도구 호출이 시작될 때. LLM이 get_order_status 같은 도구를 추천하는 순간 코드가 필러를 재생하면서 동시에 도구를 실행합니다.

async def on_tool_call(tool_name, tool_args):
    filler_task = asyncio.create_task(speak("Let me check that for you."))
    result = await run_tool(tool_name, tool_args)
    await filler_task  # 필러가 끝난 뒤 진짜 답이 나오도록 대기
    return result

speak는 한 줄을 TTS에 보내 재생하고 run_tool은 도구를 실행합니다. 필러를 별도 태스크로 시작했으므로 도구 호출을 막지 않으며, 결과를 돌려주기 전에 필러 태스크를 기다려 진짜 답이 필러를 중간에 자르지 않게 합니다. 실제 에이전트에서는 느리다고 알려진 도구에만 필러를 재생하고, 100ms에 답하는 도구에는 붙이지 않습니다.

트리거 2: 대기가 시간 한도를 넘을 때. 응답이 느릴지 미리 알 수 없다면 사용자가 말을 멈춘 때 타이머를 시작하고, 진짜 답의 첫 부분이 정한 시간(예: 1,000ms) 안에 도착하지 않으면 필러를 재생합니다.

async def reply(user_text):
    answer_task = asyncio.create_task(generate_answer(user_text))
    try:
        answer = await asyncio.wait_for(asyncio.shield(answer_task), timeout=1.0)
    except asyncio.TimeoutError:
        await speak("One moment, please.")
        answer = await answer_task
    await speak(answer)

1초 안에 답이 오면 사용자는 필러를 듣지 않고, 답이 느릴 때만 재생됩니다. asyncio.shield는 타임아웃이 아직 준비 중인 진짜 답을 취소하지 않도록 보호합니다. 이 코드는 이해를 위해 전체 답을 기다리지만 실제 에이전트는 답을 스트리밍하므로(2.15 참조) 타이머는 답의 첫 부분만 기다립니다. 한도가 너무 짧으면 빠른 응답에도 필러가 나오고, 너무 길면 필러가 나오기 전에 사용자가 이미 침묵 속에 앉아 있게 됩니다. 두 트리거는 함께 쓸 수 있어서, 느린 도구 호출이 시작될 때의 필러와 그 밖의 모든 경우를 위한 타이머 안전망을 조합합니다.

필러가 도움이 되는 곳과 해가 되는 곳은 다음과 같습니다.

필러는 에이전트를 빠르게 만드는 일의 대체재가 아닙니다. 스트리밍, 빠른 모델, 빠른 도구로 실제 지연을 먼저 줄이고(13.14 참조), 필러는 없앨 수 없는 대기 부분만 덮습니다. 또한 투기적 LLM 생성은 같은 대기를 줄이는 다른 방법입니다(13.19 참조). 문구를 설계할 때는 "확인"처럼 결과를 약속하지 않는 동사를 쓰는지 점검합니다.

13.20.3 필러 생성 방식

필러 오디오의 출처는 세 가지입니다.

방식 1: 사전 녹음 오디오. 통화가 시작되기 전에 소수의 필러 문장 오디오를 한 번 만들어 저장해 두고 통화 중에 재생합니다. 그 순간 TTS 단계가 없으므로 거의 즉시 재생됩니다. 반면 늘 같은 소리가 나고 사용자의 질문에 맞는 내용을 담지 못합니다. 사전 녹음은 에이전트의 본 목소리와 같은 음성이어야 합니다. 필러가 한 목소리, 답이 다른 목소리면 사용자가 곧바로 알아챕니다.

방식 2: 고정 목록에서 TTS로 생성. 필러 문장을 텍스트 목록으로 두고 통화 중에 하나를 골라 TTS에 보냅니다. 목록을 쉽게 바꿀 수 있고 음성도 항상 일치하지만, 필러가 시작되기 전에 약간의 TTS 지연이 더해집니다.

방식 3: LLM이 직접 생성. LLM에 지시문으로 "도구를 호출하기 전에 지금 하려는 일을 한 문장으로 사용자에게 말하라"고 알려줍니다. 도구 호출 앞의 이 짧은 한마디를 프리앰블(preamble)이라 부릅니다. 또한 하려는 행동을 설명하게 하고, 턴마다 표현을 바꾸게 하며, 직접 답할 때나 빠른 도구 호출에서는 프리앰블을 생략하게 지시해야 합니다. 주문 질문에서는 LLM이 먼저 "Sure, let me look up order 4521 for you."를 쓰고 그 뒤에 도구를 추천하는 식입니다. 필러가 질문에 정확히 맞아 더 자연스럽다는 것이 장점입니다. 단점은 LLM과 TTS를 모두 기다려야 하므로 사전 녹음보다 시작이 느리고, LLM이 지시를 항상 따르지는 않는다는 점입니다.

방식 1과 2에서는 서로 다른 필러 몇 개를 두고 돌려 써야 합니다. 한 통화에서 "Let me check that for you"가 다섯 번 나오면 기계처럼 들리므로, 같은 필러를 연속 두 번 쓰지 않는 규칙이 가장 단순한 해법입니다. 고객과는 응답 속도 요구, 질문별 맞춤 필요, 문구 통제 요구의 세 가지를 놓고 방식을 고릅니다.

13.20.4 대화 기록에 반영하기

에이전트 코드는 사용자가 한 말과 에이전트가 한 말의 목록인 대화 기록(history)을 들고 있고, 다음 응답이 필요할 때마다 이 기록을 LLM에 보냅니다(6.7 참조). 사전 녹음 오디오로 "Let me check that for you"를 재생해 놓고 코드가 이를 기록에 넣지 않으면, LLM은 이미 그 말을 했다는 것을 모릅니다. 그러면 다음 응답이 다시 "Let me check that for you"로 시작해, 사용자는 "Let me check that for you. ... Let me check that for you. Your order is out for delivery."라고 같은 문장을 두 번 듣습니다.

해법은 필러를 에이전트 메시지로 기록에 추가하는 것입니다.

history.append({ "role": "assistant", "content": "Let me check that for you." })

LLM은 에이전트가 이미 이 말을 했음을 알고 이어서 필러 반복 없이 진짜 답을 내놓습니다. 방식 3처럼 LLM이 직접 프리앰블을 쓴 경우에는 그 문장이 이미 LLM 자신의 출력의 일부이므로, 이 단계는 주로 방식 1과 방식 2에서 중요합니다. 필러를 외부에서 재생하는 구현을 점검할 때는 재생한 문구가 기록에 남는지를 확인합니다.

13.20.5 필러 중 끼어들기

에이전트가 "Let me check that for you"를 말하는 도중 사용자가 끼어들어(13.11 참조) "Actually, it's order 4522."라고 말하는 경우가 있습니다. 필러도 다른 에이전트 발화와 똑같이 취급합니다.

• 필러 발화를 즉시 멈춥니다.
• 잘못된 주문으로 실행 중인 도구 호출이 아직 끝나지 않았다면 취소합니다.
• 필러 중 사용자가 실제로 들은 부분만 대화 기록에 남깁니다.
• 새 요청을 듣고 처음부터 다시 시작합니다.

필러가 재생되는 구간은 도구가 이미 돌고 있는 구간이므로, 끼어들기에서는 발화 중단과 도구 취소를 같이 처리하는지가 점검 지점입니다. 취소를 빼먹으면 틀린 주문 번호로 조회가 끝까지 실행됩니다.

13.21 느린 도구 호출(Slow Tool Call) 가리기

원문: How does a voice agent hide the delay of a slow tool call?

채팅 화면에는 로딩 스피너가 있지만 통화에는 침묵만 있습니다. 이 절은 2026년 10월 글 기준으로, 느린 도구 호출이 만드는 침묵을 가리는 다섯 가지 기법과 도구가 너무 오래 걸릴 때의 처리를 다룹니다. 필러 구문의 일반 원리는 13.20 참조, 함수 호출 자체는 6.2 참조입니다.

음성 에이전트는 STT, LLM, TTS 세 단계 파이프라인이며(13.2 참조), 좋은 음성 에이전트는 대개 1초 안팎의 응답을 목표로 합니다(13.14 참조). 사람들은 대화에서 빠른 응답에 익숙하므로 추가되는 1초마다 눈에 띕니다. 사용자가 "Can you check if my flight AI 101 to Delhi is on time?"이라고 물으면 에이전트는 기억으로 답할 수 없고 항공사 시스템에 물어야 하며, 이 조회는 2초, 3초, 때로는 10초까지 걸립니다. 전화 통화에서 2~3초의 침묵은 "통화가 끊겼나?", "내 말이 들렸나?"라는 의문을 낳고, 사용자가 "여보세요?"라고 하거나 질문을 반복하면 에이전트가 이 새 발화를 듣고 혼란에 빠져 대화 전체가 깨집니다. 문제의 핵심은 지연이 아니라 지연이 만드는 침묵입니다.

도구 호출(tool call)은 에이전트가 LLM 밖의 코드, 예컨대 DB 조회나 다른 서비스 호출을 실행해 정보를 얻거나 행동을 하는 일입니다. LLM은 도구를 직접 실행하지 않고 어떤 도구를 어떤 입력으로 쓸지 추천만 하며(6.2 참조), 에이전트 코드가 실행해 결과를 LLM에 돌려주면(6.3 참조) LLM이 그 결과로 최종 응답을 씁니다. 항공편 예에서 흐름은 다음과 같습니다.

flowchart TB
    A["사용자: Is my flight AI 101 to Delhi on time?"] --> B["LLM 추천: check_flight_status(flight=AI 101)"]
    B --> C["에이전트가 도구 실행 (3초)"]
    C --> D["도구 결과: status=delayed, new_time=6:40 PM"]
    D --> E["LLM 응답: Your flight is delayed. It now leaves at 6:40 PM."]
    E --> F["TTS 재생"]

그림 13.21 — 도구의 3초는 STT, LLM, TTS의 기본 지연 위에 더해지며 바로 이 구간이 가려야 할 대상입니다.

13.21.1 기법 1: 짧은 한마디를 즉시

가장 단순한 기법은 에이전트가 도구가 필요하다고 아는 즉시 무언가를 말하는 것입니다. 안내 데스크 직원은 항공편을 묻는 손님 앞에서 말없이 입력하지 않고 "네, 확인해 드리겠습니다"라고 한 뒤 입력을 시작합니다. 이 몇 마디가 "들었고 처리 중"이라는 신호입니다. 구현은 두 가지입니다.

방법 1: LLM이 도구 호출과 함께 짧은 한마디를 쓴다. 지시문에 "도구를 호출하기 전에 사용자에게 한 문장을 먼저 말하라"고 적습니다. 같은 응답에서 LLM이 "Sure, let me check your flight."라는 문장과 도구 호출을 함께 내면, 에이전트가 문장을 TTS로 바로 보내면서 도구를 동시에 실행합니다. 항공편이면 "your flight", 환불이면 "your refund"처럼 요청에 맞는 문장이 나오는 것이 장점입니다. 단점은 LLM이 쓰기 시작하고 TTS가 음성으로 바꾸는 시간이 걸려 준비된 한마디보다 조금 늦게 들린다는 점입니다.

방법 2: 에이전트가 준비된 한마디를 재생한다. "One moment, please.", "Let me look that up." 같은 소수의 문장을 오디오로 미리 만들어 두었다가, LLM이 도구를 추천하는 즉시 하나를 재생합니다. 그 순간 추가 LLM이나 TTS 작업이 없어 가장 빠릅니다. 단점은 같은 문장이 반복되어 시간이 지나면 기계적으로 들린다는 점이며, 여러 문장을 돌려 써야 합니다.

어느 쪽이든 사용자는 목소리를 빨리 들어(13.16 참조) 침묵이 사라집니다. 도구가 보통 1초의 몇 분의 1 안에 돌아온다면 한마디를 생략합니다. 생략하지 않으면 사용자가 "One moment, please." 직후 곧바로 답을 듣게 되어 어색합니다. 이 판단의 근거는 도구별 평균 응답 시간이므로, 고객 도구 목록을 받으면 응답 시간 분포부터 확인합니다.

13.21.2 기법 2: 긴 대기 중 진행 상황 안내

기법 1은 도구가 2~3초 걸릴 때 효과적입니다. 티켓 예매나 긴 목록 점검처럼 10초 이상 걸리는 도구에서는 "Let me check that for you" 한마디 뒤에 8초의 침묵이 남아 문제가 되돌아옵니다. 해법이 진행 상황 안내(progress update), 즉 긴 대기 중 정해진 시점마다 작업이 계속 진행 중임을 알리는 짧은 한마디입니다. 에이전트는 단순한 타이머를 씁니다.

문장마다 달라야 하며, 같은 문장을 반복하면 지루하게 들립니다. 도구가 5초에 끝나면 타이머를 멈추고 진짜 답을 말하며, 이후 문장은 말하지 않습니다.

• 일부 에이전트는 대기 중 조용한 키보드 소리 같은 배경음을 깔아, 보류 음악처럼 회선이 열려 있음을 알립니다. 소리는 조용하고 단순해야 하며, 그렇지 않으면 거슬립니다.
• 도구가 늘 느리다고 미리 알면 처음에 "This usually takes about 10 seconds."라고 알립니다. 사용자가 기다릴 시간을 알면 대기가 짧게 느껴지는 경우가 많습니다.

13.21.3 기법 3: 도구 실행 중 계속 말하기

앞의 두 기법에서 에이전트는 기다리며 말하지만 대화는 보류 상태이고, 도구가 끝나기 전에는 사용자가 다른 것을 물을 수 없습니다. 더 나은 방법은 도구를 백그라운드에서 시작하고 사용자와의 대화를 이어가다가, 결과가 도착하면 대화에 끼워 넣는 것입니다.

사용자: "Book a table for two at 8 PM."
에이전트: "Sure, I am booking your table now."
  (예약 도구가 백그라운드에서 시작, 10초 소요)
에이전트: "While I do that, should I text you the confirmation?"
사용자: "Yes, please."
에이전트: "Sure, I will text it to you."
  (예약 도구 완료)
에이전트: "Your table for two at 8 PM is booked. The text is on its way."

사용자는 침묵 속에 있지 않으며 예약의 10초가 기다림이 아니라 유익한 질문과 대답으로 채워집니다. 이를 위해 에이전트는 두 가지를 해야 합니다.

• 도구가 도는 동안 대화를 막지 않습니다. 코드가 도구를 별도 태스크로 시작하고 LLM이 사용자에게 계속 응답하게 합니다.
• 결과가 도착하면 대화에 추가합니다. 그러면 LLM이 현재 문장이 끝난 뒤 적절한 순간에 사용자에게 알립니다.

일부 실시간 음성 모델 API는 도구 호출이 결과를 기다리는 동안 모델이 사용자와 계속 말하는 방식을 직접 지원합니다. 장점은 대화가 멈추지 않아 가장 자연스럽다는 점입니다. 단점은 구현이 어렵다는 점으로, 에이전트가 아직 도는 도구를 기억해야 하고 LLM이 도착하지 않은 결과를 지어내지 않아야 합니다. 사용자가 일찍 물으면 LLM은 아직 기다리는 중이라고 말해야 합니다. 쓰기 작업이 백그라운드로 돌 때는 "예약됐습니다"라는 말이 결과 도착 이후에만 나오는지를 반드시 점검합니다.

13.21.4 기법 4: 도구를 미리 시작

지금까지는 지연을 가렸고, 이 기법은 지연 자체를 줄입니다. 보통 에이전트는 사용자가 말을 마치기를 기다리고(13.4 참조), STT가 전체 텍스트를 주고, LLM이 읽은 뒤에야 도구를 시작합니다. 그러나 어떤 도구가 필요한지는 사용자가 말을 마치기 훨씬 전에 분명해지는 경우가 많습니다. 사용자가 "Can you check my flight AI 101... I think it leaves around six..."라고 말하는 중에도 STT는 부분 텍스트를 계속 에이전트에 주고, 에이전트는 이를 LLM에 미리 보여 줄 수 있습니다(13.19 참조). "check my flight AI 101"까지 말한 시점에 LLM은 입력 "AI 101"의 항공편 상태 도구가 필요함을 이미 알며, 나머지 문장은 도구를 바꾸지 않습니다.

그래서 사용자가 아직 말하는 동안 도구를 일찍 시작할 수 있고, 이를 투기적 실행(speculative execution)이라 부릅니다. 필요할 가능성이 높으므로 확신이 서기 전에 먼저 일을 해 두는 방식입니다. 사용자가 말을 마칠 때 도구 결과가 이미 준비되었거나 거의 준비되어 있어 에이전트는 거의 기다림 없이 답합니다. 문장 전체를 들어 보니 다른 도구가 필요하면 이른 결과를 버립니다.

용어 주의: 투기적 실행은 "헛돌려도 해가 없을 때만" 허용됩니다. 데이터를 읽기만 하는 도구는 안전합니다. 항공편 상태 조회는 결과가 필요 없어지면 버리면 그만입니다. 티켓 예매, 송금, 주문 취소는 안전하지 않습니다. 사용자가 "book a ticket... oh no, wait, do not book it"이라고 말할 수 있으므로 이미 예약해 버려서는 안 됩니다.

따라서 투기적 실행은 읽기 전용이고 아무것도 바꾸지 않는 도구에만 씁니다. 고객 도구 카탈로그를 받으면 도구마다 읽기 전용인지 상태를 바꾸는지부터 구분합니다.

13.21.5 기법 5: 도구 자체를 빠르게

도구를 빠르게 만들 수 있는 곳은 빠르게 만들어야 하며, 흔한 방법은 세 가지입니다.

• 결과 캐시: 여러 사용자가 같은 것을 물을 때, 예컨대 오늘의 매장 영업시간이면 에이전트가 답을 일정 시간 보관하고 도구를 다시 호출하지 않고 재사용합니다.
• 통화 시작 시 데이터 로드: 사용자가 자기 계정 때문에 전화했다면, 사용자가 묻기 전에 통화가 시작되자마자 계정 정보를 불러 둡니다.
• 도구 병렬 실행: 항공편 상태와 도착지 날씨처럼 도구가 둘 필요하면 하나씩 순서대로 하지 않고 동시에 실행합니다.

각각이 대기에서 몇 초를 제거하므로 가릴 지연이 그만큼 줄어듭니다. 기법 1~3은 지연을 가릴 뿐 줄이지 못하고, 지연을 줄이는 것은 기법 4와 5입니다. 순서대로 직렬 호출되는 도구 두 개가 각각 2초라면 병렬 실행만으로 4초가 2초가 됩니다(두 호출이 서로 독립일 때). 고객 워크플로에서 호출들이 서로의 결과에 의존하는지를 확인하는 것이 병렬화 가능성의 판단 기준입니다.

13.21.6 너무 오래 걸릴 때

도구가 너무 느려 진행 상황 안내로도 부족한 경우를 위해 에이전트에게 타임아웃(timeout), 즉 그 시간이 지나면 기다리기를 멈추는 시간 한도가 있어야 합니다. 한도에 닿았을 때 에이전트는 침묵하거나 "Error"라고만 말해서는 안 되며, 사용자에게 솔직하게 알리고 다음 길을 제시해야 합니다.

• "The airline system is not responding right now. Can I send you the status by text message as soon as I get it?"
• "This is taking longer than usual. Would you like me to keep trying, or can I help you with something else?"

에이전트가 실패를 명확한 다음 단계로 바꾸기 때문에 사용자는 무슨 일이 일어나는지 압니다. 앞의 기법 1, 2와 타임아웃을 한 함수로 묶으면 다음과 같습니다.

async def run_tool_with_cover(tool, args, speak):
    task = asyncio.create_task(tool(**args))           # 도구를 별도 태스크로 시작
    await speak(random.choice(QUICK_LINES))            # 기법 1
    for line in PROGRESS_LINES:                        # 기법 2: 4초마다 안내
        done, _ = await asyncio.wait({task}, timeout=4)
        if done:
            return task.result()
        await speak(line)
    done, _ = await asyncio.wait({task}, timeout=4)    # 타임아웃: 4초 더 기다린 뒤 포기
    if done:
        return task.result()
    task.cancel()
    return None

• QUICK_LINES와 PROGRESS_LINES는 에이전트가 말할 수 있는 준비된 문장 목록이며, speak는 한 줄을 TTS로 보내 재생하는 함수입니다.
• asyncio.create_task(...)를 먼저 호출하므로 에이전트가 한마디를 말하는 동안 도구가 이미 돌고 있습니다.
• asyncio.wait({task}, timeout=4)는 최대 4초 동안 도구를 기다립니다. 끝나면 결과를 바로 돌려주고, 아니면 다음 안내 문장을 말합니다.
• 안내 문장이 두 개이므로 대기는 4초씩 세 번, 총 12초입니다. 이때까지 도구가 끝나지 않으면 취소하고 None을 돌려줍니다. 위 표의 0, 4, 8초는 개념 설명용이며, 이 코드에서는 각 문장을 말하는 시간(speak가 끝날 때까지 대기)이 대기 시간 사이에 더해지므로 실제 벽시계 시간은 12초보다 길어집니다.

호출하는 쪽은 결과가 없을 때와 있을 때를 나눕니다.

result = await run_tool_with_cover(check_flight_status, {"flight": "AI 101"}, speak)
if result is None:
    await speak("The airline system is not responding right now. Would you like me to try again?")
else:
    reply = await llm_reply_with_tool_result(result)   # 결과로 LLM이 최종 응답 작성
    await speak(reply)

도구가 빠르면 사용자는 한마디와 답을 듣고, 느리면 진행 상황 안내를 듣고, 너무 느리면 다음 길이 있는 솔직한 메시지를 듣습니다. 에이전트는 항상 무언가를 말합니다. 도구 종류에 따른 선택 기준은 다음과 같습니다.

13.22 고객이 내일 묻는다면

각 질문에 소리 내어 답해보고, 막히면 표시된 절로 돌아가십시오. 로드맵이 제시한 통과 기준은 "내일 고객이 물어도 설명하고 결정할 수 있는가"입니다.

1. "음성 에이전트를 만들려는데 어떤 부품이 필요하고 응답 시간 목표는 어떻게 잡나요?" 파이프라인 단계와 지연 목표를 말해 보십시오. (13.1.1, 13.1.6)
2. "STT·LLM·TTS를 따로 쓰는 방식과 음성 모델 하나로 가는 방식 중 무엇이 낫습니까?" 업무 성격에 따라 무엇으로 고릅니까? (13.2.4, 13.3.4)
3. "사용자가 숫자를 말하다 잠깐 멈추면 에이전트가 끼어들어 버려요." 왜 일어나고 무엇을 바꿉니까? (13.8.2, 13.9.2, 13.10.1)
4. "대기 시간을 1초에서 2초로 늘리면 해결되지 않나요?" 무엇을 잃습니까? (13.8.3, 13.7.1)
5. "스피커폰으로 쓰면 에이전트가 혼자 말을 멈춥니다." 원인과 해법은 무엇입니까? (13.11.2, 13.12.1)
6. "사용자가 '네, 네' 하며 맞장구만 쳤는데 에이전트가 말을 멈춰요." 끼어들기와 어떻게 구별합니까? (13.13.2, 13.13.3)
7. "기침과 옆 사람 대화에도 에이전트가 멈춥니다." 어떤 단계로 거릅니까? (13.12.3, 13.12.5)
8. "평균 지연은 1초인데 고객 불만이 많습니다." 무엇을 어떻게 다시 측정합니까? (13.15.5, 13.14.3)
9. "응답이 시작될 때까지 3초나 걸려요. 어디부터 줄입니까?" 지연 예산표로 어떻게 판단합니까? (13.14.2, 13.14.4, 13.16.3)
10. "LLM 답변이 끝나야 TTS를 돌리는데 빠르게 만들 수 있나요?" 문장 청킹과 첫 청크 크기를 어떻게 정합니까? (13.17.1, 13.17.4, 13.18.2)
11. "사용자가 말을 끝내기 전에 미리 답을 만들어 두면 안 되나요?" 이득과 비용, 틀렸을 때의 처리는 무엇입니까? (13.19.3, 13.19.4, 13.19.6)
12. "주문 조회 API가 3초 걸려서 통화 중 침묵이 생깁니다." 필러와 도구 호출 기법 중 무엇을 어떤 순서로 쓰겠습니까? (13.20.2, 13.21.1, 13.21.4)