오후 2시, 로봇 연구실.

Reachy Mini 로봇이 개발자와 대화를 나눈다. 인터넷 연결선은 뽑혀 있고, 옆에 놓인 노트북 팬만 빠르게 돌아간다. 외부 서버로 데이터를 보내지 않고도 로봇은 질문을 알아듣고 즉각적으로 대답한다.

지금까지 로봇의 음성 인터페이스는 거대 기업의 클라우드 API에 의존했다. 마이크로폰으로 입력된 음성이 서버로 전송되고, 텍스트로 변환된 뒤, LLM이 답을 생성해 다시 음성으로 내려오는 구조였다. 이 과정에서 네트워크 지연 시간은 피할 수 없는 숙명이었고, 기업의 기밀 데이터가 외부 서버로 유출될 위험은 상존했다. 보통의 음성 AI는 네 단계의 과정을 거친다. 목소리가 들리는지 감지하는 VAD(Voice Activity Detection), 소리를 글자로 바꾸는 STT(Speech-to-Text), 답을 생각하는 LLM(Large Language Model), 다시 목소리를 만드는 TTS(Text-to-Speech)다. 이 네 가지 도구를 하나로 묶어 빠르게 실행하는 것이 핵심이다. 하지만 각 단계마다 서로 다른 클라우드 서비스를 이용하면 데이터 전송 시간이 누적되어 대화의 흐름이 끊긴다.

Reachy Mini는 이 연결 고리를 끊었다. 음성 인식부터 언어 모델 추론, 음성 합성까지 모든 과정을 로컬 머신에서 처리하는 '풀 로컬(Fully Local)' 스택을 구현했다. 이제 API 키를 발급받거나 매달 사용료를 낼 필요가 없다. 내 컴퓨터의 GPU 성능이 곧 로봇의 지능과 반응 속도가 되는 구조다. 클라우드라는 거대한 뇌 대신, 내 책상 위의 작은 서버가 로봇의 사고 체계를 완전히 대체하는 장면이 현실이 됐다.

VAD부터 TTS까지, 로컬 스택의 구성 요소

인터넷 연결이 끊기는 순간 클라우드 기반 AI 비서는 무용지물이 된다. Reachy Mini는 외부 서버 연결 없이 동작하는 4단계 음성 파이프라인을 구축했다. 이 파이프라인은 VAD(Voice Activity Detection, 음성 활동 감지)에서 시작해 STT(Speech-to-Text), LLM(Large Language Model), TTS(Text-to-Speech) 순으로 데이터가 흐른다. 인터페이스는 /v1/realtime 경로의 WebSocket 서버를 통해 제공된다. 이 서버는 Realtime API와 호환되는 프로토콜을 사용하여 로봇과 통신한다. 사용자는 외부 API 키를 입력하거나 데이터를 외부로 전송하지 않고 로컬 환경에서 음성 대화 시스템을 완결한다.

LLM 추론을 위해 하드웨어 특성에 맞춘 다양한 실행 라이브러리를 지원한다. 로컬 실행 라이브러리인 llama.cpp를 비롯해 애플 실리콘 최적화 프레임워크인 MLX, 고성능 서빙 엔진인 vLLM, 그리고 Transformers 라이브러리를 선택해 사용할 수 있다. llama.cpp는 다음 명령어로 설치한다.

bash
brew install llama.cpp 또는 winget install llama.cpp

전체 음성 루프를 구동하는 라이브러리는 pip를 통해 설치한다.

bash
pip install speech-to-speech

맥 사용자는 MLX를 통해 지연 시간을 낮추고, 리눅스나 CUDA 환경에서는 vLLM이나 Transformers를 사용해 추론 성능을 극대화한다. vLLM의 경우 0.21.0 버전 이상부터 툴 콜 스트리밍을 포함한 Responses API 프로토콜을 완전히 지원한다. 하드웨어 환경에 따라 추론 도구를 선택해 지연 시간을 제어한다.

기본 탑재 모델은 실시간 대화에 최적화된 조합으로 구성했다. STT에는 Parakeet 모델을 사용하며, TTS는 Qwen3TTS를 탑재했다. 핵심인 LLM으로는 Qwen3-4B-Instruct-2507 모델을 기본값으로 설정했다. 이 모델은 단일 소비자용 GPU에서도 빠른 응답 속도를 유지하면서 대화 능력을 확보한 모델이다. 사용자는 필요에 따라 Gemma나 Mistral 같은 다른 오픈소스 모델로 교체할 수 있다. 각 단계의 모델은 속도와 품질 사이의 트레이드오프가 존재하며, 사용자는 자신의 목적에 맞춰 이를 조정한다. 로컬 스택의 구성 요소를 자유롭게 교체하는 캐스케이드(Cascade) 구조를 통해 매주 출시되는 최신 모델을 즉각 적용한다.

'캐스케이드' 구조와 Responses API의 동작 원리

개발자가 리포지토리에서 특정 모델을 지우고 새로운 가중치 파일을 올리는 순간, 전체 시스템의 성격이 바뀐다. 이 시스템은 VAD(Voice Activity Detection, 음성 활동 감지), STT(Speech-to-Text, 음성-텍스트 변환), LLM(Large Language Model, 대규모 언어 모델), TTS(Text-to-Speech, 텍스트-음성 변환)의 네 단계로 구성된다. 각 단계의 모델은 독립적으로 작동한다. 특정 언어의 인식률을 높이려면 STT 모델만 교체하면 된다. 음성 출력의 품질을 높이려면 TTS 모델만 바꾸면 된다. 모델마다 속도와 품질의 트레이드오프가 존재한다. 빠른 TTS 모델은 품질이 낮고, 정교한 STT 모델은 처리 속도가 느리다. 모듈별 교체가 가능한 계단식(Cascade) 구조를 택해 사용자가 목적에 맞는 최적의 조합을 구성하게 했다.

LLM의 추론 지연 시간은 전체 시스템의 응답 속도를 결정하는 가장 큰 병목 지점이다. 이를 해결하기 위해 LLM을 별도 프로세스로 분리하는 Responses API 프로토콜을 도입했다. 음성 루프를 실행하는 클라이언트와 모델을 구동하는 서버가 HTTP로 통신하는 방식이다. 사용자는 서버를 하나의 터미널에서 구동하고, 음성 루프 클라이언트를 다른 터미널에서 실행한다. vLLM(vLLM, 고성능 LLM 추론 엔진)을 사용할 경우 0.21.0 이상의 버전이 필수다. 0.21.0 버전부터 툴 콜 스트리밍(Tool-call Streaming) 기능이 지원되기 때문이다. 이전 버전을 사용하면 어시스턴트가 도구를 호출하는 시점에서 시스템이 멈춘다. LLM 서버를 분리함으로써 추론 엔진의 부하가 음성 처리 루프에 직접적인 영향을 주지 않도록 설계했다.

추론 속도를 더 높이기 위해 `--speculative-config` 플래그를 사용해 MTP(Multi-Token Prediction, 다중 토큰 예측)를 활성화한다. MTP는 한 번에 여러 토큰을 예측해 생성 시간을 단축하는 기술이다. 이 설정은 모델이 지원할 때 활성화하며 전체 지연 시간을 유의미하게 줄인다. vLLM 서버 실행 시 이 플래그를 포함해 추론 효율을 극대화한다. 네트워크 설정 역시 로컬 환경을 넘어 확장했다. 기본 설정인 로컬 호스트(127.0.0.1) 외에 LAN 주소 바인딩을 지원한다. 노트북에서 엔진을 구동하고 로봇 하드웨어에서 접속하는 연결 구조를 가능하게 했다. 사용자는 192.168.x.x 또는 10.x.x.x 형태의 IPv4 주소를 확인해 로봇 UI에 입력한다. 169.254.x.x 주소가 뜨면 네트워크 연결이 되지 않은 상태다. 전체 소스 코드는 speech-to-speech 저장소에서 확인할 수 있다.

호스팅 API 대비 로컬 엔진의 실익

싸게 보이는 게 더 비쌀 수 있다. 호스팅 API는 초기 구축 비용이 없지만 토큰당 과금 체계를 따른다. 서비스 규모가 커지고 호출 횟수가 늘어날수록 비용은 선형적으로 증가한다. 로컬 엔진은 API 키와 토큰당 과금 체계를 완전히 제거한다. 데이터 보안 처리 방식에서도 차이가 명확하다. 모든 데이터가 클라우드로 전송되지 않고 로컬 머신 내부에서만 처리된다. 데이터가 기기를 떠나지 않는다는 사실은 규제 대응 비용을 낮춘다. 운영 비용을 변동비에서 고정비로 전환하고 데이터 통제권을 완전히 회수하는 선택이다.

개발자가 모델을 선택하는 기준은 이제 제공사의 정책이 아니라 순수 성능이다. Hugging Face의 Gemma, Qwen, Mistral 같은 오픈 모델을 즉시 적용할 수 있다. https://github.com/pollen-robotics/reachy_mini_conversation_app 저장소의 CLI 하나로 모델 교체 작업이 가능하다. `brew install llama.cpp` 명령어로 엔진을 설치하고 `/v1/realtime` 경로의 웹소켓 서버를 구동하는 방식이다. VAD, STT, LLM, TTS로 이어지는 계단식 파이프라인에서 LLM 레이어만 바꾸면 된다. 사용자는 모델의 가중치를 다시 변환할 필요 없이 transformers 라이브러리로 모델을 자유롭게 교체한다. 특히 Qwen3-4B-Instruct-2507 같은 모델은 단일 소비자용 GPU에서도 속도와 품질의 균형이 좋다. 특정 기업의 API 업데이트나 모델 단종 리스크에 영향을 받지 않는다.

인프라 구성은 사용자의 하드웨어 환경과 지연 시간 요구치에 따라 갈린다. 로컬 GPU를 직접 운용하거나 Hugging Face Inference Endpoints 같은 관리형 GPU를 선택한다. Together, Fireworks, Replicate 같은 추론 제공자(Inference Provider)를 통해 외부 엔진을 연결하는 방식도 지원한다. 맥 사용자는 MLX를 통해 M 시리즈 칩에서 최적화된 지연 시간을 구현한다. vLLM 0.21.0 버전 이상을 사용하면 도구 호출 스트리밍이 포함된 Responses API 프로토콜을 그대로 쓸 수 있다. 특히 `--speculative-config` 플래그를 통한 다중 토큰 예측(MTP) 기능은 전체 지연 시간을 줄이는 핵심 요소다. TTS 모델의 경우 품질을 높이면 속도가 느려지고 속도를 높이면 품질이 낮아지는 상충 관계가 존재한다. 인프라 선택지가 넓어지면서 서비스 목적에 맞는 최적의 지연 시간과 품질 지점을 직접 설계한다.

추론 지연 시간이 결정하는 로봇 인터랙션의 품질

로봇과 대화할 때 가장 먼저 느껴지는 이질감은 대답이 나오기까지의 정적이다. 음성 인터랙션 파이프라인은 VAD(Voice Activity Detection), STT(Speech-to-Text), LLM(Large Language Model), TTS(Text-to-Speech)의 네 단계로 작동한다. VAD와 STT, TTS 단계보다 LLM의 추론 지연 시간이 전체 시스템 병목의 가장 큰 비중을 차지한다. 사용자가 말을 끝낸 시점부터 로봇이 답변을 생성해 음성으로 내보내기까지의 시간이 인터랙션의 자연스러움을 결정한다. 이 찰나의 지연을 줄이지 못하면 로봇은 지능적인 비서가 아니라 느린 챗봇으로 인식된다.

하드웨어와 모델의 조합은 이 지연 시간을 직접적으로 줄이는 핵심 변수다. Mac M-시리즈 칩에서 Qwen3-4B-Instruct-2507 모델을 사용할 때 응답 속도는 사용자 체감상 즉각적인 수준으로 구현된다. vLLM 0.21.0 버전부터는 도구 호출 스트리밍을 지원하며, `--speculative-config` 플래그를 통해 다중 토큰 예측(MTP)을 활성화할 수 있다. MTP는 모델이 다음 토큰을 미리 예측해 생성 속도를 높이는 기술로, 엔드 투 엔드 지연 시간을 크게 단축한다. 적절한 파라미터 크기의 모델과 하드웨어 가속의 결합이 실시간성에 가까운 경험을 만든다.

성능 최적화 과정에서는 기능과 속도 사이의 명확한 트레이드오프가 존재한다. TTS 모델의 품질을 낮춰 단순한 음성으로 출력하면 생성 속도는 빨라진다. 반대로 STT 모델의 품질을 높여 복잡한 발음을 정확히 인식하게 하면 전체 파이프라인의 처리 속도는 느려진다. 언어 설정에서도 차이가 나타난다. 다국어 지원 기능을 유지하는 것보다 단일 언어 환경에 최적화했을 때 더 빠른 응답이 가능하다. 개발자는 서비스의 목적에 따라 인식의 정확도와 응답의 즉각성 중 하나를 선택해 최적점을 찾아야 한다.

추론 엔진을 분리하는 구조는 시스템의 확장성과 유연성을 동시에 확보한다. Responses API 프로토콜을 사용하면 LLM을 별도의 프로세스로 실행하고 음성 루프와 HTTP로 통신하게 할 수 있다. 한쪽 터미널에서 `llama.cpp` 서버를 실행하고 다른 터미널에서 음성 클라이언트를 구동하는 방식이다. 서버는 기본적으로 `ws://127.0.0.1:8765/v1/realtime`에서 리스닝하며, 이 구조에서는 파이프라인 전체를 수정하지 않고도 로컬 모델에서 OpenAI나 Gemini 같은 클라우드 기반 프론티어 모델로 즉시 교체할 수 있다. 추론 계층의 독립은 로컬의 저지연성과 클라우드의 고성능 사이에서 최적의 균형을 찾는 기술적 장치가 된다.

한국 AI 실무자가 주목할 SLM과 온디바이스 전략

하루 사이에 로봇 제어의 기준이 클라우드 의존형에서 로컬 스택 중심으로 이동했다. 과거에는 로봇의 음성 인식과 응답 처리를 위해 외부 서버 API 호출이 필수였으나, 이제는 소비자용 GPU와 로컬 엔진만으로 실시간 대화 파이프라인을 구축할 수 있다. 특히 Qwen3-4B와 같은 40억 파라미터급 소형 모델(SLM)은 단일 소비자용 GPU 환경에서도 응답 품질과 속도 사이의 실용적인 균형점을 제공한다. 이는 로봇이나 의료 기기처럼 데이터 유출에 극도로 민감한 산업 현장에서 클라우드 의존도를 제거할 수 있는 핵심 기술적 기반이 된다.

기업 내부 인프라에 모델을 즉시 이식할 수 있는 도구들의 성숙도가 구현 가능성을 높였다. vLLM(대규모 언어 모델을 위한 고성능 추론 및 서빙 엔진)과 llama.cpp(다양한 하드웨어에서 LLM을 구동하기 위한 오픈소스 라이브러리)는 이제 표준적인 배포 도구로 자리 잡았다. vLLM 0.21.0 버전부터는 도구 호출 스트리밍을 포함한 Responses API 프로토콜을 완벽하게 지원하여, 복잡한 로봇 제어 명령을 로컬 환경에서 지연 시간 없이 처리할 수 있다. 실무자는 별도의 복잡한 인프라 구축 없이 아래와 같은 간단한 명령어로 로컬 서빙을 시작할 수 있다.

bash

vLLM을 활용한 로컬 추론 서버 실행 예시

python -m vllm.entrypoints.openai.api_server \

--model Qwen/Qwen3-4B-Instruct-2507 \

--speculative-config '{"type": "mtp", "num_speculative_tokens": 5}'

이러한 로컬 배포 방식은 단순한 비용 절감을 넘어 비즈니스 연속성을 확보하는 전략적 선택이 된다. 클라우드 API의 응답 지연이나 네트워크 불안정성으로부터 자유로운 독립적인 음성 루프를 구성할 수 있기 때문이다. 특히 로봇과 같은 엣지 디바이스에서는 로컬 호스트와 로봇 간의 LAN 통신을 통해 외부망 단절 시에도 안정적인 동작을 보장한다. 실무자는 이제 모델의 성능뿐만 아니라, 특정 산업 도메인에 최적화된 STT(음성 인식)와 TTS(음성 합성) 모델을 조합하여 자신만의 맞춤형 캐스케이드 파이프라인을 설계하는 데 집중해야 한다.

결국 로컬 온디바이스 전략의 핵심은 하드웨어 자원과 모델 사양의 최적화에 있다. 애플의 M 시리즈 칩을 사용하는 환경에서는 MLX(애플 실리콘용 머신러닝 프레임워크)를 통해 가장 낮은 지연 시간을 확보할 수 있으며, 리눅스 기반의 CUDA 환경에서는 바닐라 트랜스포머 라이브러리를 통해 모델 교체의 유연성을 극대화할 수 있다. Qwen3-4B와 같은 모델은 단일 GPU 환경에서도 충분한 추론 성능을 발휘하므로, 기업은 더 이상 거대 모델의 클라우드 비용에 매몰되지 않고도 고성능 로봇 서비스를 구현할 수 있다. 기술의 무게 중심이 모델의 크기에서 배포의 효율성으로 옮겨감에 따라, 현장 적용 가능한 로컬 스택의 확보가 로봇 서비스의 경쟁력을 결정짓는 변수가 되었다.