Jun 6, 2026

AI 전화 상담원이 대답하기까지: STT·LLM·TTS 지연시간 해부하기

1. 전화에서 1초의 침묵은 생각보다 길다

환자가 병원 AI 상담원에게 묻는다.

환자: 내일 오후에 진료 예약이 가능한가요?

환자가 말을 마친 뒤 아무 소리도 들리지 않는다.

짧은 침묵이 이어지면 환자는 생각하기 시작한다.

내 말을 제대로 들었을까?
전화가 끊긴 것은 아닐까?
다시 말해야 할까?
AI가 대답하지 못하는 질문이었을까?

화면이 있는 서비스라면 로딩 표시로 처리 중임을 알릴 수 있다. 전화에는 그런 시각적 신호가 없다. 사용자는 상대방의 숨소리, 맞장구와 답변만으로 연결 상태를 판단한다. 그래서 Voice AI에서 지연시간은 단순한 성능 숫자가 아니라 대화가 살아 있다는 신뢰와 연결된다.

AI가 늦게 대답하는 이유를 “LLM이 느려서”라고만 설명하기 쉽다. 실제로는 환자의 음성이 들어온 뒤 여러 단계가 이어진다.

음성을 문자로 변환한다.
환자가 말을 끝냈는지 판단한다.
답변할 내용이나 실행할 업무를 결정한다.
생성된 문장을 다시 음성으로 바꾼다.
만들어진 오디오를 전화망으로 전달한다.

각 단계의 작은 대기시간이 쌓여 환자가 경험하는 하나의 침묵이 된다.

TL;DR

Voice AI의 지연시간은 STT, Turn Detection, LLM, TTS와 실제 재생 시작 시간이 함께 만든다.

전체 생성 완료 시간보다 첫 transcript, 첫 token, 첫 audio가 언제 도착하는지가 대화 경험에 더 중요하다.

Streaming을 사용하면 각 단계는 완전히 순차적으로 기다리지 않고 일부가 겹쳐 실행된다.

최종 품질은 각 단계의 평균보다 서버 측 E2E latency와 느린 일부 턴, 즉 tail latency로 판단해야 한다.

Tool과 외부 API가 포함된 턴은 대화 응답시간과 업무 완료시간을 나누어 측정해야 한다.

2. 환자의 목소리가 AI의 목소리로 돌아오는 길

Wise AI 인바운드 에이전트는 STT-LLM-TTS 형태의 순차적 pipeline을 사용한다.

STT(Speech-to-Text): 환자의 음성을 문자로 변환한다.
LLM(Large Language Model): 전사된 문장을 이해하고 답변이나 Tool 호출을 만든다.
TTS(Text-to-Speech): LLM이 만든 문장을 환자가 들을 음성으로 변환한다.

그 사이에는 환자의 발화가 끝났는지를 판단하는 VAD와 Turn Detection도 있다. 마지막에는 생성된 오디오가 LiveKit과 SIP 전화 연결을 통해 실제 환자에게 전달된다.

LiveKit은 Voice Agent pipeline을 STT, LLM과 TTS라는 교체 가능한 전문 모델의 조합으로 설명한다. 이 방식은 각 단계의 텍스트와 결과를 관찰하고, 업무별 Tool 호출을 통제하며, 문제가 생긴 구간을 분리해 분석하기 쉽다. 대신 여러 단계가 이어지는 만큼 각 지연시간을 관리해야 한다. 참고: LiveKit pipeline types

3. Latency는 하나의 숫자가 아니다

“우리 AI의 응답속도는 몇 초인가요?”라는 질문에 숫자 하나로 답하면 많은 정보가 사라진다.

우선 시작점부터 정해야 한다.

환자가 말을 시작한 순간부터 측정할 것인가?
환자가 마지막 음절을 말한 순간부터 측정할 것인가?
STT가 final transcript를 만든 순간부터 측정할 것인가?

끝점도 여러 개다.

LLM이 첫 token을 만든 순간
TTS가 첫 audio chunk를 만든 순간
Agent가 audio frame을 출력으로 전달한 순간
환자의 전화기에서 실제 음성이 들린 순간

Voice AI의 대화 경험을 볼 때 가장 직관적인 기준은 다음이다.

환자가 말을 멈춘 순간부터 AI가 첫 음성으로 응답하기 시작하는 순간까지

LiveKit의 per-turn metric에서는 이를 서버 측 e2e_latency로 제공한다. 다만 이 값은 환자 단말의 스피커에서 소리가 난 시점을 직접 재는 것이 아니라, Agent가 응답을 시작한 시점을 기준으로 한다. 동시에 어느 단계가 시간을 사용했는지 알아보기 위해 세부 metric도 함께 기록한다. 참고: LiveKit data hooks and per-turn latency

Metric	시작	끝	알 수 있는 것
STT transcription delay	환자 발화 종료	transcript 확보	음성 인식 결과가 얼마나 늦게 도착했는가
End-of-turn delay	환자 발화 종료	turn 확정	AI가 얼마나 기다린 뒤 대답하기로 했는가
LLM TTFT	LLM 요청	첫 token	답변이 시작되기까지 모델이 생각한 시간
TTS TTFB	첫 text 입력	첫 audio chunk	음성 합성이 시작되기까지 걸린 시간
Playback latency	첫 audio frame 전달	실제 재생 시작 보고	출력 경로가 추가한 대기시간
E2E latency	환자 발화 종료	AI 발화 시작	환자가 체감하는 전체 응답 지연

여기서 full response 생성시간보다 TTFT(Time To First Token)와 TTFB(Time To First Byte 또는 Audio)가 중요한 이유가 드러난다. 긴 답변 전체가 완성될 때까지 기다릴 필요 없이 첫 부분부터 음성으로 재생할 수 있기 때문이다.

4. 첫 번째 대기: STT와 발화 종료 판단

STT는 통화가 끝난 뒤 한꺼번에 녹음을 처리하지 않는다. Streaming STT는 환자가 말하는 동안 interim transcript를 계속 갱신하고, 발화가 끝나면 확정된 final transcript를 전달한다.

환자 음성     내일 / 오후에 / 진료 예약이 / 가능한가요?
STT interim   내일   내일 오후   내일 오후 진료 예약이
STT final                                   내일 오후에 진료 예약이 가능한가요?

따라서 STT 처리시간 전체가 환자의 발화 뒤에 그대로 더해지는 것은 아니다. 상당 부분은 환자가 말하는 동안 이미 처리된다. 중요한 것은 마지막 음절 이후 final transcript와 turn 확정이 얼마나 늦게 도착하는가다.

하지만 너무 빨리 확정하면 환자의 말을 끊는다.

환자: 내일 오후에…

AI: 내일 오후 몇 시를—

환자: 세 시쯤 가능한가요?

반대로 너무 오래 기다리면 transcript가 이미 준비됐는데도 AI가 침묵한다. 이 구간은 지난 글에서 다룬 VAD, Endpointing과 Turn Detector의 영역이다.

LiveKit의 transcription_delay는 발화 종료 후 transcript 확보까지, end_of_utterance_delay는 VAD가 감지한 발화 종료부터 user turn을 끝내기로 결정할 때까지를 나타낸다. 두 값은 일부 같은 시간을 포함할 수 있으므로 무조건 더하면 안 된다. 하나는 STT 결과의 도착을, 다른 하나는 최종 turn 결정을 보는 진단 지표다. 참고: Pipeline EOU metrics

5. 두 번째 대기: LLM이 첫 단어를 만들기까지

User turn이 확정되면 LLM은 대화 기록과 병원별 instruction, 사용할 수 있는 Tool 정보를 받아 다음 행동을 결정한다.

LLM latency를 볼 때는 두 시간을 구분해야 한다.

TTFT: 첫 token이 나오기까지

TTFT는 요청을 보낸 뒤 첫 token이 도착할 때까지 걸린 시간이다. Voice AI는 첫 token이 도착하면 TTS 단계로 넘길 준비를 시작할 수 있으므로 대화의 첫 반응 속도와 직접 연결된다.

전체 생성시간: 답변을 모두 만들기까지

긴 안내 문장을 끝까지 만드는 데는 더 많은 시간이 필요하다. 하지만 streaming pipeline에서는 전체 문장이 완성되기를 기다리지 않고, 문장이나 구절 단위로 TTS에 전달한다.

LLM TTFT에 영향을 주는 요소는 다양하다.

모델과 provider의 처리 속도
system prompt와 누적 대화의 길이
사용할 수 있는 Tool schema의 크기
동시 요청량과 provider 상태
Agent와 model endpoint 사이의 네트워크 거리
prompt caching 적용 여부
첫 답변이 text인지 Tool 호출인지

무조건 작은 모델을 선택한다고 좋은 서비스가 되는 것은 아니다. 빠르지만 예약 조건을 잘못 이해하면 재질문과 수정이 늘어나 통화 전체가 더 길어진다. Voice AI에서는 첫 token 속도, 답변 정확도, Tool 사용 안정성을 함께 봐야 한다.

6. 세 번째 대기: TTS의 첫 음성이 만들어지기까지

LLM의 text가 준비되면 TTS가 이를 오디오로 합성한다. 이 단계에서도 전체 문장의 생성 완료보다 첫 audio chunk가 언제 나오는지가 중요하다.

TTS TTFB는 TTS가 첫 text를 받은 뒤 첫 audio chunk를 반환할 때까지 걸린 시간이다. 첫 chunk가 준비되면 LiveKit은 뒤쪽 음성을 계속 생성하는 동시에 앞부분을 재생할 수 있다.

LLM token   안녕하세요 | 내일 오후 | 예약 가능한 시간을 | 확인해 볼게요
TTS audio        █████████   ███████████   ████████████████
재생                  ▶──────── 환자에게 먼저 들리기 시작 ────────▶

TTS latency와 품질에는 다음 요소가 영향을 준다.

음성 model과 provider
streaming 지원 여부
첫 chunk를 만들기 위해 기다리는 text 길이
발음 사전과 text normalization
숫자, 날짜, 전화번호를 읽는 방식
음성 속도와 sample rate
provider까지의 network latency

너무 작은 text 조각을 바로 TTS로 보내면 빠르게 시작할 수 있지만 문맥이 부족해 억양이 부자연스럽거나 단어 사이가 끊길 수 있다. 너무 많은 text를 모은 뒤 보내면 발음은 안정적일 수 있지만 첫 음성이 늦어진다. 빠른 TTS는 model 선택뿐 아니라 text를 어디에서 끊어 streaming할지의 문제이기도 하다.

7. 실제 Pipeline은 단순한 덧셈이 아니다

다음처럼 계산하고 싶을 수 있다.

전체 지연 = STT 시간 + LLM 시간 + TTS 시간

하지만 streaming pipeline에서는 단계가 부분적으로 겹친다.

STT는 환자가 말하는 중 실행된다. Preemptive generation을 사용하면 final transcript가 도착했지만 turn이 완전히 확정되기 전 LLM을 시작할 수 있다. 우리 서비스는 LLM뿐 아니라 TTS도 preemptive하게 시작해 대기시간 일부를 겹친다.

이 방식에는 trade-off가 있다. 환자가 다시 말을 이어가 transcript가 바뀌면 미리 생성한 LLM과 TTS 결과를 취소하고 버려야 한다. Latency는 줄어들 수 있지만 불필요한 model 호출과 비용이 생긴다. 따라서 preemptive generation을 켰다는 사실보다 실제 E2E metric이 개선됐는지 확인해야 한다. 참고: Turn-taking tuning, Preemptive generation options

8. Tool을 호출하는 순간 Latency의 모양이 달라진다

병원 Voice AI는 질문에 말로만 답하지 않는다.

예약 가능한 일정 조회
기존 예약 확인
예약 생성·변경·취소
병원 FAQ 검색
상담원 연결

LLM이 Tool을 선택하면 외부 API와 database, network가 새로운 대기 구간으로 들어온다.

이때는 두 종류의 시간을 분리해야 한다.

대화 응답시간: 환자가 말한 뒤 AI가 처음 반응하기까지
업무 완료시간: 예약 조회나 등록 결과가 확정될 때까지

외부 API가 오래 걸릴 때 아무 말 없이 기다리면 환자는 통화가 멈췄다고 느낀다. “예약 가능한 시간을 확인하고 있습니다”와 같은 짧은 진행 안내를 먼저 재생하면 업무 완료시간 자체는 같아도 체감 대기시간은 줄어든다.

다만 모든 Tool에 filler speech를 넣으면 대화가 장황해진다. 빠른 읽기 요청에는 바로 결과를 말하고, 몇 초 이상 걸릴 수 있는 작업에만 진행 상태를 알리는 식으로 구분해야 한다.

또한 timeout, retry와 fallback provider는 평균시간을 조금 늘리는 대신 실패율을 줄일 수 있다. 성공한 요청만 모아 latency를 계산하면 이런 긴 fallback 턴이 보이지 않는다. 실패와 재시도 횟수도 함께 기록해야 하는 이유다.

9. 우리는 Turn마다 어떤 시간을 기록하는가

Wise AI 인바운드 에이전트는 통화 transcript의 user와 assistant message에 metric을 함께 저장한다. 분석 도구는 각 user-assistant turn을 연결해 다음 항목을 읽는다.

TurnLatency(
    stt_transcription_delay=user_metrics.get("transcription_delay"),
    stt_end_of_turn_delay=user_metrics.get("end_of_turn_delay"),
    llm_ttft=assistant_metrics.get("llm_node_ttft"),
    tts_ttfb=assistant_metrics.get("tts_node_ttfb"),
    e2e_latency=assistant_metrics.get("e2e_latency"),
    playback_latency=assistant_metrics.get("playback_latency"),
    interrupted=bool(assistant_item.get("interrupted")),
)

SDK가 제공하는 E2E 값과 별도로 timestamp를 이용한 값도 계산한다.

e2e_from_timestamps = (
    assistant_metrics["started_speaking_at"]
    - user_metrics["stopped_speaking_at"]
)

두 값의 차이가 일정 범위를 넘으면 e2e mismatch로 표시한다. Metric 하나를 무조건 신뢰하지 않고 이벤트 timestamp와 교차 확인하면, 누락된 event나 측정 경계의 차이를 발견할 수 있다.

분석 결과는 turn별 표로 보여준다.

Turn	User	Assistant	STT	Turn Det.	LLM	TTS	E2E	Notes
1	내일 예약 가능한가요?	가능한 시간을 확인할게요	…	…	…	…	…	-
2	오후 세 시요	오후 세 시로 확인했습니다	…	…	…	…	…	interrupted

LiveKit Agents도 per-component event, per-turn message metric, session usage와 최종 session report처럼 서로 다른 범위의 관측 지점을 제공한다. Pipeline별 metric을 별도로 모을 때는 같은 turn의 speech_id를 기준으로 연결할 수 있다. 참고: LiveKit metrics and usage data

10. 평균만 보면 느린 통화를 놓친다

열 번 중 아홉 번은 빠르지만 한 번이 매우 느린 서비스와, 열 번 모두 비슷한 속도로 응답하는 서비스가 있다고 해보자. 평균은 두 서비스를 비슷하게 보이게 만들 수 있다. 환자는 자신이 만난 한 번의 긴 침묵으로 서비스를 평가한다.

그래서 운영 환경에서는 다음을 함께 본다.

Median 또는 p50: 일반적인 통화가 경험하는 속도
p90·p95: 느린 상위 10%·5%의 턴
Maximum: timeout이나 fallback 같은 극단적인 사례
Sample count: 적은 표본으로 만든 수치인지 확인
Error·retry rate: 느려진 이유가 재시도였는지 확인
Interrupted turn: 환자가 AI를 끊어 실제 재생이 달라진 턴 구분

분포도 상황별로 나눠야 한다.

단순 FAQ 답변과 예약 Tool 호출
첫 turn과 대화가 길어진 후반 turn
짧은 “네”와 긴 설명형 발화
provider별 STT·LLM·TTS
조용한 실내와 소음이 있는 전화
정상 요청과 fallback이 발생한 요청

전체 평균이 느려졌다고 무조건 model을 교체하면 안 된다. 실제 원인이 특정 예약 API의 timeout일 수도 있고, 긴 대화에서 prompt가 커진 문제일 수도 있으며, Turn Detector가 환자의 말을 더 기다린 결과일 수도 있다.

11. Latency를 줄일 때 어디부터 볼까

측정 결과를 확보했다면 가장 큰 구간부터 개선한다.

End-of-turn delay가 크다면

Endpointing 범위가 대화에 비해 긴지 확인한다.
STT final transcript가 늦게 도착하는지 분리한다.
Turn Detector가 언어와 전화 음질에서 안정적으로 동작하는지 본다.
시간을 무조건 줄였을 때 환자의 말을 끊는 비율도 함께 측정한다.

LLM TTFT가 크다면

지나치게 긴 대화 history와 prompt를 점검한다.
사용하지 않는 Tool schema를 매 turn 보내는지 확인한다.
model과 provider의 p95를 비교한다.
prompt caching과 Agent-provider 간 network 위치를 확인한다.
빠른 model로 바꿨을 때 업무 정확도가 유지되는지 평가한다.

TTS TTFB가 크다면

streaming TTS가 실제로 활성화됐는지 확인한다.
첫 문장 경계를 만들기 위해 text를 너무 오래 모으는지 본다.
숫자와 날짜 normalization이 blocking 작업인지 확인한다.
voice와 provider별 첫 audio latency를 비교한다.

Tool 시간이 크다면

연결과 응답 timeout을 분리한다.
retry가 같은 작업을 중복 실행하지 않도록 idempotency를 확보한다.
몇 초 이상 걸리는 작업에는 짧은 진행 안내를 고려한다.
읽기 결과는 안전한 범위에서 cache할 수 있는지 검토한다.
대화 응답시간과 실제 업무 완료시간을 별도 metric으로 둔다.

Network와 재생 구간이 크다면

Agent, model provider와 LiveKit 배포 지역을 확인한다.
SIP provider와 전화망 구간의 packet loss와 jitter를 본다.
audio format 변환이나 불필요한 buffering이 있는지 확인한다.
서버 timestamp만으로는 환자 단말의 실제 재생 시각을 완전히 알 수 없다는 측정 경계를 명시한다.

최적화의 핵심은 모든 값을 무조건 낮추는 것이 아니다. Endpointing을 과도하게 줄이면 빠른 대신 환자의 말을 끊는다. TTS chunk를 너무 작게 만들면 빨리 시작하지만 억양이 흔들릴 수 있다. Timeout을 줄이면 평균은 좋아 보이지만 정상적으로 완료될 요청까지 실패할 수 있다.

Latency 개선은 속도와 정확성, 자연스러움과 안정성 사이의 균형을 찾는 과정이다.

12. Pipeline과 Realtime model 중 무엇이 더 빠를까

STT-LLM-TTS pipeline 외에도 음성을 직접 입력받아 음성으로 응답하는 realtime model이 있다. 중간 단계와 provider 사이의 handoff가 줄어들기 때문에 일반적으로 더 낮은 baseline latency와 풍부한 억양 이해를 기대할 수 있다.

하지만 구조 선택은 속도 하나로 결정되지 않는다.

STT-LLM-TTS Pipeline	Realtime Speech-to-Speech
각 model을 독립적으로 선택 가능	하나의 model이 음성을 직접 처리
transcript와 단계별 metric 관찰이 쉬움	중간 단계 관찰 범위가 상대적으로 제한됨
정확한 scripted speech에 유리	표현력 있는 음성 대화에 유리
text 기반 Tool calling이 성숙함	provider별 Tool 지원과 동작 차이가 있음
단계별 latency가 누적될 수 있음	inter-stage handoff가 적어 baseline이 빠름

병원 서비스에서는 예약 정보와 필수 안내를 정확히 기록하고, Tool 호출을 통제하며, 문제가 발생한 단계를 감사할 수 있어야 한다. 그래서 우리는 현재 sequential pipeline의 관찰 가능성과 제어력을 활용하면서 streaming과 preemptive generation으로 체감 지연을 줄이는 방향을 사용한다.

이는 realtime model이 적합하지 않다는 뜻이 아니다. 짧고 자유로운 대화가 중심인지, 정확한 업무 처리와 transcript가 중요한지에 따라 선택이 달라진다. 공식 비교도 latency, auditability, scripted speech와 Tool calling을 함께 고려하도록 안내한다. 참고: LiveKit pipeline architecture comparison

13. 빠른 AI보다 침묵의 이유를 아는 AI 시스템

Voice AI가 늦게 대답할 때 “LLM이 느리다”는 결론부터 내리면 개선 방향을 놓치기 쉽다.

환자의 마지막 음절 뒤에는 Turn Detection이 기다릴 수 있다. STT final이 늦을 수 있고, LLM의 첫 token이 지연될 수 있으며, TTS가 첫 audio chunk를 만들지 못했을 수도 있다. Tool과 외부 API가 응답을 기다리거나, 만들어진 음성이 실제 전화 출력에서 buffering되고 있을 수도 있다.

그래서 우리가 가장 먼저 해야 할 일은 model을 바꾸는 것이 아니라 침묵을 구간으로 나누는 것이다.

환자 발화 종료
    ├─ STT transcription delay
    ├─ End-of-turn delay
    ├─ LLM TTFT
    ├─ TTS TTFB
    ├─ Playback and network delay
    └─ 환자가 AI의 첫 음성을 들음

그다음에는 각 구간을 streaming으로 겹치고, 느린 tail을 찾아내며, 업무 유형에 맞는 latency budget을 세운다. 단순 안내와 예약 확정에 같은 기준을 적용하지 않고, 속도를 줄이는 과정에서 정확성과 자연스러움이 손상되지 않는지도 확인한다.

환자에게 중요한 것은 STT가 몇 밀리초 걸렸는지, LLM의 TTFT가 얼마인지가 아니다. 질문을 마친 뒤 적절한 순간에 AI가 자신의 말을 이해했다는 신호를 주는 것이다.

좋은 Voice AI는 무조건 빠른 AI가 아니라, 침묵이 어디에서 생겼는지 알고 계속 줄여 나갈 수 있는 시스템이다.