이 글이 정말 흥미로움. 예전에 Amazon Alexa 팀에서 이 문제를 연구했고 관련 특허도 있음
대화 중 사람 간 평균 지연은 0ms, 즉 상대가 말을 끝내기 전에 이미 다음 사람이 말을 시작함. 뇌가 상대의 말을 예측하며 동시에 답변을 준비하기 때문임
반면 사람들은 음성 비서에게는 지연을 기대함. 이유는 두 가지 — 컴퓨터가 ‘생각’해야 한다는 인식, 그리고 휴대폰 통화의 지연 때문임
Alexa의 응답 중 500ms 이하인 것은 거의 없음. 예전엔 단순히 300ms의 침묵을 ‘턴 종료’로 간주했지만, 진짜 핵심은 semantic end-of-turn임
지금은 계산 자원이 충분하니, 이 부분이 얼마나 발전했을지 궁금함. 지리적 근접 처리(엣지 컴퓨팅)가 큰 전환점이었음
휴대폰 통화의 지연은 특히 연령대가 높은 사람들에게 스트레스를 줌. 유선전화 시절엔 거의 지연이 없었기 때문에, 왜 불편한지도 모른 채 답답함을 느낌
2번 사실에는 동의하지 않음. 음성 비서의 지연 시간(latency) 은 여전히 너무 느림. “작동했나?” 하고 기다리게 됨. 휴대폰의 지연이 다른 기기에도 기대된다고 생각하지 않음
300ms 침묵을 턴 종료로 보는 건 너무 불편했음. 그래서 일부러 “음…” 같은 채움말(filler) 을 넣어야 했고, 결국 음성 채팅을 포기하게 됨
흥미로운 내용 공유에 감사함. 그런데 왜 Amazon/Google/Apple 은 최근 몇 년간 음성 비서 혁신을 멈췄는지 궁금함. 기존 사용자 기반만으로도 시장을 다시 정의할 수 있었을 텐데
LLM이 사용자의 발화를 예측적으로 이어받는 구조를 말하는 것 같음. 발화가 실제로 끝났을 때 예측과 일치하면 지연 없이 바로 응답 가능함. 여러 후보 스레드를 동시에 예측해가며 가지치기하는 방식도 가능해 보임
음성은 결국 턴테이킹(turn-taking) 문제라고 생각함. 아무도 손대지 않은 쉬운 개선점이 있음 — 바로 채움말과 템포 조절임
LLM이 잠시 침묵을 감지하면, 실제 응답이 생성되는 동안 “음”, “그렇죠” 같은 맥락 있는 채움말을 넣는 식임. 이렇게 하면 대화가 훨씬 자연스러워짐
완전 공감함. 작은 저지연 모델이 먼저 짧은 응답을 생성하고, TTS 결과를 캐시해두면 지연을 극단적으로 줄일 수 있음. “잠시만요, 생각 중이에요” 같은 문장은 밀리초 단위로 응답 가능함
하지만 ‘쉬운 개선’은 아닐 수도 있음. 로봇 같은 시스템을 인간적으로 만드는 건 어렵고, 단순히 문장 구조를 바꾸면 오히려 더 기계적으로 들림. 직접 시도해봤지만 실패했음
턴 종료를 잘못 감지했을 때, 음소 단위 filler 로 자연스럽게 이어붙이는 방법도 가능함. 반대로 너무 늦게 감지했다면, 첫 음절을 미리 정해두고 그걸로 답변을 시작하도록 프롬프트에 넣을 수도 있음
훌륭한 글임. OpenAI Responses client가 최근 웹소켓을 도입해 지연이 줄었음.
또 다른 방법은 초소형 LLM을 로컬에서 직접 실행하는 것임. 나는 ova 프로젝트를 통해 완전 로컬 파이프라인을 만들었고, 스트리밍 없이도 1초 미만의 왕복 시간을 얻었음
멋진 프로젝트라서 즐겨찾기에 추가했음. 나중에 경험을 공유하며 이야기 나누고 싶음
글의 스트리밍 파이프라인 구조와 단계별 지연 분석이 매우 유용했음. 직접 턴테이킹 루프를 구현한 점이 인상적임
다만 “Vapi보다 2배 빠르다”는 비교는 약간 부정확함. Vapi는 툴 호출, 웹훅, 멀티테넌트 라우팅 등 훨씬 많은 작업을 수행함
이 글의 진짜 가치는 ‘직접 만든 오케스트레이션 루프의 통찰’에 있음. 단순히 “직접 만들어보며 배운 점”으로 정리했다면 완벽했을 것임
나도 Twilio + Deepgram + ElevenLabs + LLM API 조합으로 상용 음성 에이전트를 구축 중임
핵심은 STT 정확도가 아니라 턴테이킹 UX였음. 고정된 침묵 임계값 대신 semantic end-of-turn 으로 바꾸자 체감이 완전히 달라졌음
지역 간 지연도 중요함. 인도에서 미국 서버로 연결할 때 Twilio 엣지 홉만으로도 150~250ms 추가됨. 지역별 라우팅으로 개선했음 Barge-in(중간 끼어들기) 처리도 복잡함. LLM과 TTS를 중단하는 것뿐 아니라, 이미 실행된 자동화 워크플로우를 되돌려야 함. 예전에 예약 확인 중 끼어들면 예약이 실제로 완료되는 버그도 있었음
Soniox Real-time(60개 언어 지원)은 endpoint detection을 모델 수준에서 처리함. VAD보다 훨씬 정확함 기술 문서, Daily의 벤치마크, 데모 페이지 참고 가능함
예전에 Soniox에서 근무했음. 실시간 endpoint detection을 최초로 구현한 서비스였음
원문을 보면 Deepgram Flux를 사용했다고 나옴. 이것도 endpointing을 지원하며 VAD보다 상위 추상화 계층임
현재 Soniox를 사용 중인데, 내부에서 일할 때 어땠는지 궁금함. 경쟁사 대비 저렴한 가격으로 SoTA 성능을 내는 비결이 무엇인지 알고 싶음
개인적으로 STT → LLM → TTS 구조는 한계가 있다고 봄. 미래는 end-to-end 음성 모델임
2년 전 Chirpy 데모를 만들어봤지만, 실제로 쓸 만한 수준으로 가려면 전용 학습이 필요했음. 사이드 프로젝트로는 감당 불가였음
나는 최근 몇 년간 음성 에이전트만 다뤘음. 계단식 모델(cascading model) 은 당분간 사라지지 않을 것임.
기업 고객은 감사 가능성(auditability) 과 신뢰성을 중시함. 의료·금융 같은 규제 산업에서는 STT와 LLM 출력을 각각 검증해야 함
반면 end-to-end 음성 모델은 인터뷰나 설문처럼 서사적 용도에 더 적합함. 실제 고객들은 최신 모델보다 엔지니어링 완성도를 원함
계단식 구조의 장점은 각 단계별로 새 모델을 교체할 수 있다는 점임. STT, TTS, LLM의 발전 속도가 다르기 때문에 유연성이 큼
최신 음성 토크나이저는 초당 약 12Hz 수준까지 도달했음. 일반 LLM보다 훨씬 많은 토큰을 사용함
이번 접근은 게임 엔진 네트코드 초기 발전을 떠올리게 함. 지연은 모델 문제가 아니라 오케스트레이션 문제임 Carmack의 2013년 VR 논문에서도 같은 주장을 했음 — 파이프라인 전체를 추적해야 밀리초 단위 병목을 찾을 수 있음 Latency Mitigation Strategies 참고할 만함. TTS 웹소켓 풀을 미리 열어 300ms를 절약한 사례가 완벽한 예시임
오픈소스 음성 인식 앱 Handy를 소개하고 싶음. 완전히 오프라인으로 동작하며 확장 가능함
나는 매일 Claude와 함께 사용 중인데, macOS 기본 받아쓰기보다 훨씬 잘 작동함
좋은 글이지만, 턴테이킹만으로 대화를 설명하는 건 너무 단순함
실제 대화에는 겹침 발화, 확인 신호, 청취 유지용 발화(phatic messages), 심지어 상대의 말을 완성해주는 협력적 행동도 있음
이런 요소들은 단순한 턴테이킹 모델로는 잘 표현되지 않으며, 모델이 이를 생성하고 이해할 수 있어야 함
Hacker News 의견들
이 글이 정말 흥미로움. 예전에 Amazon Alexa 팀에서 이 문제를 연구했고 관련 특허도 있음
대화 중 사람 간 평균 지연은 0ms, 즉 상대가 말을 끝내기 전에 이미 다음 사람이 말을 시작함. 뇌가 상대의 말을 예측하며 동시에 답변을 준비하기 때문임
반면 사람들은 음성 비서에게는 지연을 기대함. 이유는 두 가지 — 컴퓨터가 ‘생각’해야 한다는 인식, 그리고 휴대폰 통화의 지연 때문임
Alexa의 응답 중 500ms 이하인 것은 거의 없음. 예전엔 단순히 300ms의 침묵을 ‘턴 종료’로 간주했지만, 진짜 핵심은 semantic end-of-turn임
지금은 계산 자원이 충분하니, 이 부분이 얼마나 발전했을지 궁금함. 지리적 근접 처리(엣지 컴퓨팅)가 큰 전환점이었음
음성은 결국 턴테이킹(turn-taking) 문제라고 생각함. 아무도 손대지 않은 쉬운 개선점이 있음 — 바로 채움말과 템포 조절임
LLM이 잠시 침묵을 감지하면, 실제 응답이 생성되는 동안 “음”, “그렇죠” 같은 맥락 있는 채움말을 넣는 식임. 이렇게 하면 대화가 훨씬 자연스러워짐
훌륭한 글임. OpenAI Responses client가 최근 웹소켓을 도입해 지연이 줄었음.
또 다른 방법은 초소형 LLM을 로컬에서 직접 실행하는 것임. 나는 ova 프로젝트를 통해 완전 로컬 파이프라인을 만들었고, 스트리밍 없이도 1초 미만의 왕복 시간을 얻었음
글의 스트리밍 파이프라인 구조와 단계별 지연 분석이 매우 유용했음. 직접 턴테이킹 루프를 구현한 점이 인상적임
다만 “Vapi보다 2배 빠르다”는 비교는 약간 부정확함. Vapi는 툴 호출, 웹훅, 멀티테넌트 라우팅 등 훨씬 많은 작업을 수행함
이 글의 진짜 가치는 ‘직접 만든 오케스트레이션 루프의 통찰’에 있음. 단순히 “직접 만들어보며 배운 점”으로 정리했다면 완벽했을 것임
나도 Twilio + Deepgram + ElevenLabs + LLM API 조합으로 상용 음성 에이전트를 구축 중임
핵심은 STT 정확도가 아니라 턴테이킹 UX였음. 고정된 침묵 임계값 대신 semantic end-of-turn 으로 바꾸자 체감이 완전히 달라졌음
지역 간 지연도 중요함. 인도에서 미국 서버로 연결할 때 Twilio 엣지 홉만으로도 150~250ms 추가됨. 지역별 라우팅으로 개선했음
Barge-in(중간 끼어들기) 처리도 복잡함. LLM과 TTS를 중단하는 것뿐 아니라, 이미 실행된 자동화 워크플로우를 되돌려야 함. 예전에 예약 확인 중 끼어들면 예약이 실제로 완료되는 버그도 있었음
Soniox Real-time(60개 언어 지원)은 endpoint detection을 모델 수준에서 처리함. VAD보다 훨씬 정확함
기술 문서, Daily의 벤치마크, 데모 페이지 참고 가능함
예전에 Soniox에서 근무했음. 실시간 endpoint detection을 최초로 구현한 서비스였음
개인적으로 STT → LLM → TTS 구조는 한계가 있다고 봄. 미래는 end-to-end 음성 모델임
2년 전 Chirpy 데모를 만들어봤지만, 실제로 쓸 만한 수준으로 가려면 전용 학습이 필요했음. 사이드 프로젝트로는 감당 불가였음
기업 고객은 감사 가능성(auditability) 과 신뢰성을 중시함. 의료·금융 같은 규제 산업에서는 STT와 LLM 출력을 각각 검증해야 함
반면 end-to-end 음성 모델은 인터뷰나 설문처럼 서사적 용도에 더 적합함. 실제 고객들은 최신 모델보다 엔지니어링 완성도를 원함
이번 접근은 게임 엔진 네트코드 초기 발전을 떠올리게 함. 지연은 모델 문제가 아니라 오케스트레이션 문제임
Carmack의 2013년 VR 논문에서도 같은 주장을 했음 — 파이프라인 전체를 추적해야 밀리초 단위 병목을 찾을 수 있음
Latency Mitigation Strategies 참고할 만함. TTS 웹소켓 풀을 미리 열어 300ms를 절약한 사례가 완벽한 예시임
오픈소스 음성 인식 앱 Handy를 소개하고 싶음. 완전히 오프라인으로 동작하며 확장 가능함
나는 매일 Claude와 함께 사용 중인데, macOS 기본 받아쓰기보다 훨씬 잘 작동함
좋은 글이지만, 턴테이킹만으로 대화를 설명하는 건 너무 단순함
실제 대화에는 겹침 발화, 확인 신호, 청취 유지용 발화(phatic messages), 심지어 상대의 말을 완성해주는 협력적 행동도 있음
이런 요소들은 단순한 턴테이킹 모델로는 잘 표현되지 않으며, 모델이 이를 생성하고 이해할 수 있어야 함