음성으로 말을 걸고 대답이 돌아오기까지의 수백 밀리초. 이 '간격(間)'이 아주 조금만 길어져도, 대화 AI는 즉시 기계와 대화하고 있다는 느낌을 준다. 반대로 이 간격이 줄어들면, 대화는 신기하게도 살아있는 생명체처럼 느껴진다. Hugging Face와 Cerebras가 7월 1일에 공개한 speech-to-speech는 그 간격을 실용적인 범위까지 단축한 음성 에이전트를, 모든 단계를 교체 가능한 오픈 소스 부품으로 구성할 수 있도록 만든 것이다. 화려한 신규 모델은 아니다. 하지만 '말하고 답하는 경험'을 자신의 손으로 직접 조립하고, 내부를 전부 들여다볼 수 있다는 점이 지금까지는 없었던 특징이다. 게다가 동일한 스택은 이미 9,000대를 넘는 로봇에서 구동되고 있다.

출처는 Hugging Face의 공식 블로그와 리포지토리(Repository), 그리고 로컬 버전의 해설 기사 3개를 대조하였다.

음성 대화는 하나의 덩어리처럼 보이지만, 실제로는 여러 처리를 사슬처럼 연결한 '카스케이드 (cascade)' 방식으로 작동한다. 마이크 입력부터 순서대로 다음과 같은 흐름을 가진다.

단계	역할	기본 모델
VAD	발화 구간 검출 (언제 말을 시작하고 끝냈는지 판정)	Silero VAD v5
...

이 중 체감 지연 시간을 지배하는 것은 거의 LLM이다. VAD나 STT는 가벼워서 CPU로도 구동할 수 있고, TTS는 스트리밍 방식으로 앞부분부터 말을 시작할 수 있다. 하지만 LLM은 답변을 1토큰씩 생성 완료할 때까지 문장이 확정되지 않는다. 생성이 느리면 그만큼 상대방을 기다리게 만든다. 카스케이드 설계에서 까다로운 점은 각 단계의 지연 시간이 합산되어 쌓인다는 것이며, 중간 단계가 막히면 전체가 무너진다. 공식 블로그에서도 이 점을 솔직하게 "음성 AI에게 레이턴시 (Latency)는 결정적인 파라미터 (Parameter)다"라고 단언하고 있다.

흥미로운 점은 이 4단계 모두가 서로 다른 벤더의 독립적인 오픈 모델로 구성되어 있다는 점이다. 인식은 NVIDIA, 생성은 Google, 합성은 Alibaba. 수직 통합의 반대 방향을 택하여, 각 단계에서 그 시점의 최선책을 선택할 수 있다.

도입은 Python 패키지 하나로 끝난다. 기본 구성이라면 이것만으로 대화 루프가 시작된다.

pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech

핵심은 4단계 각각을 CLI 플래그로 교체할 수 있다는 것이다. 인식을 Faster Whisper로, 합성을 Kokoro로 바꾸는 등의 조작이 설정 파일을 건드리지 않고 한 줄로 가능하다.

speech-to-speech --stt faster-whisper --tts kokoro

--stt에는 parakeet-tdt (기본값)나 whisper, paraformer가, --tts에는 qwen3 (기본값)나 kokoro, chattts 등이 나열된다. LLM은 --llm_backend를 통해 OpenAI 호환 API, 로컬의 Transformers, MLX를 전환할 수 있도록 설계되어 있다.

클라우드를 전혀 사용하지 않고 로컬에서 완결 지을 수도 있다. llama.cpp로 Gemma 4를 띄우고, 그곳을 향해 말을 거는 구성이 README에 실려 있다.

llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536 -fa on --swa-full
speech-to-speech \
--model_name "ggml-org/gemma-4-E4B-it-GGUF" \
...

Apple Silicon용으로는 --local_mac_optimal_settings라는 원클릭 설정도 마련되어 있어, M계열 칩이라면 Qwen3-4B 클래스가 '즉각 응답'하며 작동한다고 한다. 로컬 버전 해설 기사는 이점 세 가지를 정리하고 있다. 음성이 네트워크 외부로 나가지 않는다 (프라이버시), 종량제 과금이 없다 (비용), 그리고 VAD/STT/LLM/TTS 중 무엇이든 교체할 수 있다 (유연성)이다.

Hugging Face가 공개한 데모 구성에서는 LLM 단계에 Cerebras의 추론 기반으로 Gemma 4를 탑재하고 있다. 앞서 언급했듯이 카스케이드의 지연 시간은 LLM이 쥐고 있다. Cerebras는 웨이퍼 스케일 (Wafer-scale, 실리콘 한 장 전체를 하나의 칩으로 만드는 방식) 추론을 통해 높은 초당 토큰 수를 내는 것으로 알려져 있으며, 바로 그 단계의 병목을 해결하기 위한 선택이다. 블로그는 다음과 같이 적고 있다.

로봇이나 음성 어시스턴트, 신체를 가진 AI에게 응답성은 단순한 외관상의 개선이 아니다. 그것이야말로 대화를 '살아있는 것'처럼 느끼게 만드는 핵심이다.

여기서의 설계 결정은 시사하는 바가 크다. 모든 단계를 로컬의 소형 모델로 구성하면 저렴하고 폐쇄적이지만, 생성 품질과 속도는 한계에 부딪힌다. 반대로 LLM(대규모 언어 모델)만 고속 클라우드 추론으로 외부에 맡기면, 인식·합성은 수중에 둔 채 응답의 끊김(latency)만 개선할 수 있다. 캐스케이드(Cascade) 구조가 부품별로 독립되어 있기 때문에, 이러한 '특정 단계만 과금하는' 방식의 활용을 자연스럽게 구현할 수 있다.

음성 대화에는 또 다른 흐름이 있다. 음성을 중간에 텍스트로 변환하지 않고, 소리 그대로 입출력하는 '네이티브 음성(end-to-end)'형 모델이다. 이론적으로는 이 방식이 더 빠르고, 목소리의 억양이나 끼어들기 같은 비언어적 정보도 보존할 수 있다. 그렇다면 왜 Hugging Face는 굳이 고전적인 캐스케이드 방식을 선택했을까?

나는 그 답이 '내용을 들여다볼 수 있음'에 있다고 읽는다. 캐스케이드 방식이라면 각 단계의 입출력을 텍스트나 구간 단위로 관측할 수 있어, 어디서 인식을 잘못했는지, 어느 단계가 느린지를 분리하여 디버깅할 수 있다. 단계마다 최적의 모델을 배치할 수 있고, 다국어 대응 또한 STT(음성 인식)/TTS(음성 합성)를 언어별로 선택하는 것만으로 충분하다. 네이티브 음성 모델의 매끄러움과 맞바꾸어, 실무에서 유효한 '관측성(Observability)'과 '교체 가능성(Interchangeability)'을 택한 셈이다. 프로덕트를 운영하는 입장에서는 블랙박스 형태의 통짜 구조보다, 고장 난 단계만 교체할 수 있는 구성이 압도적으로 다루기 쉽다.

그 주장을 뒷받침하는 것이 9,000대 이상에서 가동 중인 Hugging Face의 오픈 소스 데스크톱 로봇 Reachy Mini다. 데모에서 Cerebras 버전으로 보여준 것과 동일한 파이프라인이, 로봇 위에서는 로컬 완결형 버전으로 동작한다. 클라우드에서 속도를 구매하는 구성과 로컬에서 폐쇄적으로 운영하는 구성이, 플래그(flag) 차이만으로 연속되어 있다. 이 점이 이번에 가장 중요한 지점이라고 생각한다. '말하고 답하는 것'을 특정 벤더의 API에 종속되지 않고, 요구사항(속도·비용·프라이버시)에 따라 스스로 재구성할 수 있는 토대가 pip 명령어 한 줄의 거리로 다가온 것이다. 음성 에이전트를 검토하고 있다면, 우선 기본 구성을 실행한 뒤 각 단계를 하나씩 교체해 보는 것이 이 설계 사상을 몸소 이해하는 지름길이 될 것이다.