사람의 뇌는 400ms 이상의 침묵을 이상하게 느낀다

전화 통화의 자연스러움을 규정하는 국제 표준이 있어요. 국제전기통신연합(ITU-T)이 정한 G.114는 한쪽에서 말한 소리가 상대방 귀에 도달하기까지의 지연시간(일방향 전송 지연) 기준을 제시합니다. 1993년 처음 제정된 이후 여러 차례 개정을 거친, 통신 업계에서 가장 널리 인용되는 지연시간 표준이에요.

* G.114는 '일방향' 지연 기준이에요. 질문하고 답을 듣기까지의 왕복 대화라면 이 값의 대략 두 배, 즉 300ms 안팎을 체감 기준으로 보는 게 업계 통례입니다. 100ms 바지인(barge-in) 기준은 특정 ITU 표준이 아니라 여러 음성 AI 업체가 실사용 테스트를 통해 공통적으로 수렴한 경험적 목표치예요.

이 기준을 넘기면, 기술적으로는 정상 작동해도 사람은 "이상하다"고 느껴요. 특히 왕복 지연이 길어질수록 사람의 뇌는 "상대가 대답을 안 하네, 다시 말해야겠다"고 판단해버립니다. 그 결과가 바로 사용자가 같은 말을 반복하고, AI가 그 말 위에 겹쳐서 대답하는 어색한 순간이에요. G.114 자체도 "150ms 아래에서도 일부 고도로 상호작용적인 음성·데이터 서비스는 지연의 영향을 받을 수 있다"고 명시할 만큼, 대화형 서비스는 일반 통화보다 더 엄격한 기준이 필요하다고 봅니다.

2009년 미국국립과학원회보(PNAS)에 실린 스티버스 연구팀의 비교언어학 연구는 이 감각이 통신 표준만의 이야기가 아니라는 걸 보여줘요. 서로 다른 10개 언어권의 실제 대화를 녹음해 분석한 결과, 질문을 던지고 답이 돌아오기까지의 간격은 문화권에 관계없이 평균 약 200ms였습니다. 언어와 문화는 달라도, 대화의 리듬을 조율하는 '침묵을 못 견디는 감각'은 인류 공통이라는 뜻이에요.

결국 AI 음성 상담이 자연스럽게 느껴지려면, 통신 표준이 요구하는 최소 조건(G.114)을 지키는 것을 넘어, 사람과 사람이 실제로 주고받는 대화의 리듬(≈200ms대 응답 텀)에 최대한 가깝게 다가가야 해요. cxVisor가 목표로 하는 왕복 1초 이내 응답은 이 리듬을 완전히 재현하지는 못하더라도, 최소한 "대답을 놓쳤나" 하는 의심이 들지 않는 지점을 지키기 위한 기준선입니다.

1초 안에 세 단계를 모두 마쳐야 한다

실시간 음성 AI는 듣기(STT) → 이해하고 답 만들기(LLM) → 말하기(TTS), 세 단계를 거쳐요. 각 단계가 얼마의 시간을 쓰는지 예산을 짜듯 배분하지 않으면, 어느새 합계가 3~4초를 넘어버립니다.

세 단계를 순서대로 하나씩 끝내고 다음으로 넘어가면 이 예산은 절대 못 지켜요. 그래서 실제로는 겹쳐서 처리합니다. LLM이 답변 앞부분을 만드는 동안 TTS가 그 부분을 먼저 말하기 시작하는 식으로, 세 단계가 순차가 아니라 파이프라인처럼 흘러가야 왕복 1초 안에 들어옵니다.

세 단계 중 가장 시간을 많이 쓰는 건 LLM이에요. 이유는 서로 다른 두 시간 요소가 함께 포함되어 있기 때문입니다.

답변 전체가 다 만들어질 때까지 기다렸다가 말하기 시작하면, 문장이 길수록 대기 시간이 길어져요. 그래서 실무에서는 첫 문장이나 첫 구절이 만들어지는 즉시 TTS로 넘겨서 말하기 시작하고, 뒷부분은 LLM이 계속 생성하는 동안 이어 붙이는 방식을 씁니다. STT 쪽도 마찬가지예요. 방문자가 말을 다 마칠 때까지 기다리지 않고, 침묵이 일정 시간(보통 300~500ms) 이어지면 "말이 끝났다"고 판단하고 다음 단계로 넘어가는 엔드포인팅(endpointing) 기법을 씁니다. 이 판단이 너무 성급하면 말이 끝나지 않았는데 잘라버리고, 너무 느리면 그만큼 응답이 늦어지는 트레이드오프가 있어요.

왜 "붙여서 만든" 음성봇은 느릴 수밖에 없는가

시중의 많은 음성봇은 STT·LLM·TTS를 각각 다른 회사의 API로 가져와 이어붙여요. 문제는 이 셋이 서로 다른 서버에 있다는 거예요. 한 단계가 끝날 때마다 네트워크를 타고 결과를 주고받아야 하니, 그때마다 왕복 지연이 쌓입니다.

이 격차가 왜 생기는지 조금 더 뜯어보면, 서로 다른 서버로 결과를 넘길 때마다 다음 세 가지 비용이 매번 추가돼요.

여기에 더해, 서로 다른 벤더의 API는 대부분 스트리밍이 아니라 완료 후 응답 방식이에요. STT 벤더가 "다 들었다"고 완전한 문장을 넘겨줘야 LLM 벤더가 시작하고, LLM이 답변을 통째로 완성해야 TTS 벤더가 시작하는 식이면, 앞서 설명한 겹쳐 처리(파이프라이닝) 자체가 불가능해져요. 세 단계가 순수하게 순차적으로 더해지니 3~5초가 나오는 겁니다.

단계 사이의 네트워크 이동이 없는 구조일수록 이 격차를 줄일 수 있어요. 팀벨의 실시간 음성 에이전트 'Brain'이 STT·LLM·TTS를 하나의 엔진으로 묶어 약 600ms 왕복 응답을 내세우는 것도 같은 이유입니다. 단계 사이의 이동 비용 자체를 없애고, 각 단계가 서로의 중간 결과를 스트리밍으로 주고받을 수 있게 만드는 접근이에요.

AI가 말하는 중에 끼어들어도 자연스러워야 한다

사람의 대화는 100% 순서대로 진행되지 않아요. 상대가 말하는 도중에 "아 잠깐만요" 하고 끼어드는 게 자연스러운 대화의 일부죠. AI가 이걸 못 받아주면, 방문자는 로봇과 얘기하고 있다는 걸 곧바로 눈치챕니다.

이 흐름이 100ms 안에 처리되지 않으면, AI는 방문자의 말을 무시하고 계속 떠들거나, 뒤늦게 멈추면서 대화가 툭툭 끊기는 느낌을 줘요. 바지인(barge-in) 처리는 지연시간 최적화 중에서도 가장 체감 효과가 큰 부분입니다.

바지인(barge-in)이 기술적으로 까다로운 진짜 이유는 따로 있어요. 방문자의 마이크는 방문자의 목소리만 듣는 게 아니라, 스피커에서 나오는 AI의 목소리까지 함께 주워 담아요. 이 상태에서 "지금 들리는 소리가 방문자가 새로 말을 시작한 건지, 아니면 스피커에서 나온 AI 목소리가 마이크에 다시 들어온 것뿐인지"를 구분하지 못하면, AI가 자기 말소리에 스스로 끼어들어 멈추는 오작동이 생겨요.

이 세 가지가 함께 작동해야 "진짜 끼어든 것"과 "그냥 잡음이거나 AI 목소리의 되울림"을 구분할 수 있어요. 너무 민감하면 방문자가 헛기침만 해도 AI가 계속 멈추고, 너무 둔감하면 실제로 끼어들었는데도 AI가 계속 말해서 대화가 겹치는 문제가 생깁니다.

1초를 지키기 위한 엔지니어링 체크리스트

지연시간을 줄이는 작업은 한 가지 큰 기술이 아니라, 자잘한 최적화가 쌓여서 만들어져요.

각 항목이 실제로 무엇을 의미하는지 조금 더 풀어보면:

평균이 아니라 P95를 보는 이유도 짚을 만해요. 평균 응답속도가 아무리 빨라도, 100명 중 5명이 3초씩 기다린다면 그 5명에게는 서비스가 "느리다"로 기억돼요. 그래서 지연시간을 관리할 때는 평균값보다 P95(전체 요청 중 느린 쪽 5%가 걸리는 시간), P99(가장 느린 1%) 같은 지표를 함께 추적하는 게 실무에서는 훨씬 중요합니다. 이런 자잘한 최적화들이 쌓여야, 어쩌다 한 번 빠른 게 아니라 열 번 중 아홉 번 이상 안정적으로 1초 안에 들어오는 응답을 만들 수 있어요.