음성 AI 신제품 소개에는 거의 항상 응답 속도가 ms 단위로 적혀 있습니다. 첫 음성이 나오기까지 몇 ms인지를 내세우고, 서로 수십 ms 차이로 경쟁하죠. 그런데 대화하는 사람에게 이 차이가 정말 중요할까요?
놀랍게도 대화에서는 1초도 안 되는 침묵까지 해석합니다. 대답이 0.7초만 늦어져도 듣는 사람은 그 침묵을 망설임으로 받아들여요. 같은 “네”라도 늦게 나오면 확신 없는 대답처럼 들립니다.
이 글에서는 사람이 대화에서 몇 초 안에 대답하는지, 그보다 늦으면 대답이 어떻게 들리는지를 연구 결과로 살펴봅니다. 침묵의 길이에 따른 실제 예시부터, 서비스마다 다른 latency 숫자를 어떻게 비교하면 될지까지 확인해보세요.
이런 분들에게 추천드립니다
✅ 음성 에이전트를 구축하면서 응답 시간 목표를 어디에 둘지 정해야 하는 분
✅ TTS를 고르는데 모델마다 다른 ms 숫자를 어떻게 비교할지 헷갈리는 분
✅ AICC·예약 자동화를 검토하면서 상담 품질에 응답 속도가 얼마나 중요한지 근거가 필요한 분
사람은 대화에서 얼마나 빨리 대답하나요?
사람은 상대의 말이 끝나고 약 0.2초 안에 대답을 시작합니다. 한국어도 예외가 아니에요.
2009년 PNAS에 실린 연구는 한국어·일본어·영어·덴마크어를 포함한 10개 언어의 실제 대화를 녹화해, 예/아니요로 답하는 질문 뒤에 대답이 나오기까지의 시간을 쟀습니다. 가장 흔한 간격은 0ms, 즉 말이 끝나자마자 대답이 시작되는 경우였고 언어 전체 평균은 약 208ms였어요. 언어마다 차이는 있었지만 그 폭은 평균에서 ±250ms 안쪽이었습니다.
흥미로운 건 사람이 말을 준비하는 데는 이보다 훨씬 오래 걸린다는 점이에요. 2015년 Frontiers in Psychology에 실린 리뷰에 따르면 단어 하나를 떠올려 말하기까지만 600ms가 넘게 걸립니다. 그런데도 0.2초 안에 대답할 수 있는 건, 상대가 말하는 도중에 이미 대답을 준비하기 시작하기 때문이에요.
결국 사람의 대화는 “듣고 나서 생각하는” 구조가 아니에요. 들으면서 준비하고, 말이 끝나는 순간 바로 이어 말하는 구조입니다. 그렇다면 이 리듬이 깨지면 어떻게 될까요?
0.7초를 넘긴 대답은 거절로 들립니다
대답이 늦어지면 듣는 사람은 그 침묵을 망설임이나 거절의 신호로 받아들입니다. 세 편의 연구가 각각 다른 방법으로 같은 결론을 보여줘요.
2015년 Discourse Processes에 실린 연구는 전화 통화에서 수락과 거절이 나온 순간을 모아 대답까지 걸린 시간을 비교했습니다. 짧은 간격에서는 둘의 차이가 뚜렷하지 않았지만, 간격이 700ms를 넘어가면 거절이 수락보다 확실히 많아졌어요.
2011년 같은 학술지에 실린 실험은 반대 방향에서 확인했습니다. 부탁이나 의견에 대답하기 전 침묵을 0ms, 600ms, 1,200ms로 바꿔 들려주고 “이 사람이 얼마나 응할 마음이 있어 보이나요?”를 물었더니, 침묵이 길수록 점수가 낮아졌어요. 영어·이탈리아어·일본어 화자 모두 같은 방향이었습니다.
2015년 PLOS ONE에 실린 뇌파 실험은 더 직접적이에요. 300ms 만에 나온 “아니요”에는 뇌가 예상 밖이라는 반응을 보였지만, 1,000ms 뒤에 나온 “아니요”에는 그 반응이 사라졌습니다. 1초의 침묵을 듣는 동안 뇌가 이미 거절을 예상하고 있었다는 뜻이에요.
정리하면 0.2초 안팎이 사람의 기본 리듬이고, 0.7초를 넘어가면 같은 대답도 다르게 들리기 시작합니다. 위 연구들은 모두 사람끼리의 대화를 잰 것이에요. 다만 전화 너머에서 대답하는 상대가 AI라고 해서 듣는 사람의 귀가 다르게 작동한다고 볼 이유는 없죠.
0.2초, 1.5초, 2.5초: 침묵 길이 비교하기
고객이 환불을 문의하고, 음성 에이전트가 “네, 가능합니다”라고 답하는 통화예요. 세 파일 모두 대사·목소리·감정이 똑같고, 바뀐 건 고객의 말이 끝나고 에이전트가 대답하기까지의 침묵뿐입니다.
고객
어제 온라인몰에서 주문한 거 환불 되나요?
에이전트
네, 가능합니다. 주문 내역 확인해서 바로 환불 접수해 드릴게요.
CASE 1침묵 0.2초 (사람의 기본 리듬)
CASE 2침묵 1.5초 (업계가 음성 에이전트 목표로 잡는 응답 시간)
CASE 3침묵 2.5초 (목표보다 1초 늦은 경우)
※ 고객과 에이전트 목소리 모두 타입캐스트 TTS API로 만들었습니다.(고객 : 타입캐스트 재호, 에이전트 : 타입캐스트 이현)
어때요, 대답은 분명히 “네”인데 뒤로 갈수록 정말 환불이 되는 건지 불안해지죠?
세 통화의 대사는 한 글자도 다르지 않습니다. 그런데 2.5초 뒤에 나온 “네, 가능합니다”는 확인해 봐야 아는 대답처럼 들려요. 앞의 연구에서 본 것처럼 듣는 사람은 침묵의 길이로 상대가 얼마나 확신하는지를 읽기 때문입니다.
상담 전화라면 고객은 대답을 듣기도 전에 그 침묵 동안 “안 되는 건가?”부터 떠올리게 돼요. 음성 에이전트에서 응답 속도는 단순히 빠르고 느린 문제가 아니라, 같은 대답이 믿을 수 있게 들리느냐의 문제입니다.
음성 에이전트가 0.7초를 넘기기 쉬운 이유
음성 에이전트의 응답 시간은 여러 단계가 나눠 쓰는 예산입니다. 고객의 말이 끝난 순간부터 첫 소리가 나오기까지 아래 단계를 모두 거쳐요.
| 단계 | 하는 일 |
|---|---|
| 말 끝 감지 | 고객이 말을 마쳤는지, 잠깐 쉬는 건지 판단 |
| 음성 인식(STT) | 마지막 말까지 텍스트로 확정 |
| LLM | 대답의 첫 토큰 생성 |
| 음성 합성(TTS) | 첫 음성 데이터 생성 |
| 네트워크·재생 | 서버 사이 왕복, 전화망·재생 버퍼 |
이 단계를 다 더하면 사람의 0.2초 안에 들어오기는 어렵습니다. 음성 에이전트 프레임워크 Pipecat을 만든 Daily는 2026년 8월 음성 에이전트용 LLM을 공개하면서 음성-to-음성 지연 목표를 약 1,500ms, 그중 LLM 첫 토큰을 650ms로 잡았어요(출처: Daily 블로그, 2026-08-27). 업계 목표조차 0.7초 선의 두 배라는 뜻이에요.
그래서 단계마다 수십 ms씩 줄이는 게 중요합니다. TTS 단계에서는 대답이 다 만들어지기 전에 고객이 첫마디를 듣게 하는 방법이 두 가지 있어요. 첫째, LLM이 대답을 끝까지 쓸 때까지 기다리지 않고첫 문장이 나오는 대로 TTS에 넘깁니다. 둘째, 스트리밍 TTS를 씁니다. 스트리밍 TTS는 문장 전체가 생성될 때까지 기다리지 않고, 만들어지는 대로 음성을 조금씩 받아 바로 재생하는 방식인데요, 스트리밍 TTS가 일반 TTS와 어떻게 다른지는 스트리밍 TTS 아티클을 참고해보세요.
TTS 응답 속도(latency), 서비스별 숫자를 제대로 비교하는 법
TTS를 응답 속도로 고를 때 서비스에서 공개한 ms 숫자를 그대로 나란히 놓으면 안 됩니다. 같은 ms라도 어느 구간을 쟀느냐에 따라 의미가 달라지기 때문이에요. 숫자를 비교하기 전에 두 가지를 확인하세요.
비교 기준서비스별 숫자를 볼 때 확인할 두 가지
| 확인할 것 | 중요한 이유 |
|---|---|
| 측정 구간 | 모델이 계산하는 시간만 잰 값(모델 지연)과, 요청을 보내고 첫 음성 데이터를 받기까지 잰 값(TTFB)은 다릅니다. 후자에는 네트워크와 서버 대기 시간이 들어가요 |
| 동시 호출 수 | 단일 호출에서 잰 값은 가장 좋은 조건의 숫자입니다. 실제 서비스처럼 여러 통화가 동시에 들어오면 늘어날 수 있어요 |
측정 결과타입캐스트 스트리밍 TTS의 응답 속도(TTFB)
타입캐스트 스트리밍 TTS API의 첫 음성 지연을 이 기준에 맞춰 재 보면 아래와 같습니다.
| 측정 조건 | 내용 |
|---|---|
| 구간 | 요청을 보낸 순간부터 첫 오디오 바이트가 도착하기까지(TTFB) |
| 문장 | 한국어 약 50자 |
| 동시 호출 | 1건(단일 요청) |
| 측정 위치 | 데이터센터 내부 서버 측. 사용자 단말과 라스트마일 네트워크는 제외 |
| 결과(p50) | SSFM 2.1 약 110ms, SSFM 3.0 약 150ms |
p50은 측정값을 순서대로 줄 세웠을 때 한가운데 있는 값입니다. 서버 안에서 잰 숫자라 실제 통화에서는 사용자까지 오가는 네트워크 시간이 더해집니다. 니다. 서버 기준으로 보면 업계 목표 1,500ms 중 TTS가 쓰는 시간은 110~150ms로, 전체의 10%가 안 됩니다.
우리 서비스에서 TTS가 실제로 몇 ms 걸리는지는 직접 재서 확인하세요. 실제로 쓸 문장 길이와 서버 위치, 예상 동시 통화 수로 조건을 맞춰 재면, 목표 1,500ms 중 나머지 단계에 얼마가 남는지 계산할 수 있습니다.
자주 묻는 질문
Q. 음성 에이전트 응답은 몇 초 안에 나와야 하나요? ＋
대화 연구 기준으로 사람의 기본 응답 간격은 약 0.2초이고, 0.7초를 넘으면 대답이 망설임이나 거절처럼 들리기 시작합니다. 다만 음성 에이전트는 말 끝 감지·STT·LLM·TTS·네트워크를 모두 거쳐야 해서, 업계에서는 음성-to-음성 기준 약 1.5초를 현실적인 목표로 잡고 있어요. 그래서 각 단계에서 줄이는 수십 ms가 쌓여 체감을 바꿉니다.
Q. TTFB와 전체 응답 시간은 뭐가 다른가요? ＋
TTFB(Time To First Byte)는 TTS에 요청을 보내고 첫 음성 데이터를 받기까지의 시간입니다. 전체 응답 시간은 고객의 말이 끝난 순간부터 에이전트의 첫 소리가 들리기까지로, TTS의 TTFB는 그중 한 구간이에요. 스트리밍 방식을 쓰면 문장이 길어져도 TTFB는 크게 늘지 않습니다.
Q. 타입캐스트 스트리밍 TTS의 응답 시간은 얼마인가요? ＋
타입캐스트 스트리밍 TTS API(POST /v1/text-to-speech/stream)의 TTFB는 단일 호출 기준 모델에 따라 110~150ms 수준입니다. 첫 청크부터 바로 재생할 수 있고, 출력은 WAV(16비트·모노·32,000Hz)와 MP3(320kbps·44,100Hz) 중 고를 수 있어요. 스트리밍 API 문서 보기 →
Q. LLM 대답을 기다리지 않고 음성을 먼저 내보낼 수 있나요? ＋
네, LLM이 스트리밍으로 내보내는 텍스트를 문장 단위로 끊어 TTS 스트리밍 API에 넘기면, LLM이 대답을 다 쓰기 전에 첫 문장부터 재생할 수 있습니다.
Q. 타입캐스트 API는 뭐가 좋은가요? ＋
타입캐스트는 320만 명의 크리에이터와 누적 3,000개 고객사가 선택한 음성·영상 생성 AI 서비스입니다. 강점은 세 가지예요. ① 자연스러움: 전문 성우 녹음을 학습한 목소리에 텍스트 맥락을 읽는 스마트 이모션이 결합됩니다. ② 다양성: API 기준 600개 이상의 보이스와 37개 언어를 같은 API로 호출합니다. ③ 안정성: 수만 명이 동시에 접속하는 라이브 환경에서 검증됐습니다.
대화의 리듬을 지키는 음성, 타입캐스트 API로
첫 음성까지 110ms.
카드 등록 없이 매월 15,000 크레딧으로 바로 연동해보세요.
