OpenClaw의 실시간 대화: 실제 에이전트와 상의하는 인터럽트 가능한 음성

에이전트에 목소리를 입히기 위해 음성-텍스트 변환과 TTS를 연결하고 있었다면, 완전히 잘못된 길을 가고 있을 수 있습니다. r/openclaw에 올라온 글에서 한 개발자가 STT와 TTS 파이프라인에 "시간과 토큰"을 쏟아부었지만, 결과는 ChatGPT와 Gemini 앱의 실시간 음성 경험에 비하면 "몇 광년이나 뒤처져" 있었다고 설명합니다.

이 글에 따르면 해결책은 Realtime Talk, 특히 설정 키 .talk.realtime.provider입니다.

Realtime Talk가 실제로 하는 일

핵심적인 아키텍처 차이는 Realtime Talk가 에이전트 위에 덧붙인 전사(transcription) 레이어가 아니라는 점입니다. 음성 대화는 OpenClaw 에이전트를 참조하고, 에이전트의 전체 컨텍스트와 도구가 연결된 상태로 선택한 LLM을 통해 실행됩니다. 따라서 기반 모델의 추론 능력을 잃지 않으면서 실시간 음성 동작(끼어들기 처리, 스타일과 속도 지시)을 얻을 수 있습니다.

작성자가 ChatGPT/Gemini 스타일 경험에서 명시적으로 언급한 기능들:

• 문장 중간에 음성으로 끼어들기
• 특정 스타일로 응답하도록 지시하기 (작성자의 예: "드라큘라처럼 대답해")
• 더 느리게 또는 더 빠르게 말하도록 요청하기
• 응답은 여전히 에이전트 + 선호하는 LLM에서 나오며, 음성 전용으로 성능이 낮아진 모드가 아님

작성자의 평가: 음성 프런트엔드가 응답 품질과 분리되어 있기 때문에 OpenAI와 Google이 자사 앱에 탑재한 것보다 낫습니다.

설정에서 길을 잃지 마세요

작성자가 초보자에게 하는 경고는 직설적입니다. 주변에 넘쳐나는 관련성 없거나 오래되었거나 잘못된 경로의 자료들이 에이전트를 잘못된 방향으로 이끌 수 있습니다. 이 글에 따르면 다음은 무시해야 합니다:

• STT/TTS 설정
• voice-call이라고 표시된 모든 것
• ClawHub 플러그인
• 몇 달 전 YouTube 튜토리얼

설정해야 할 단 하나는 .talk.realtime.provider입니다. 이것이 실시간 경로이며, 별도의 음성 구성 요소로 조립하는 파이프라인이 아닙니다.

왜 중요한가

제대로 작동하는 음성 루프를 직접 만든다는 것은 에이전트가 생각하기도 전에 VAD, 엔드포인팅, 끼어들기(barge-in), 지연 예산을 해결해야 한다는 뜻입니다. Realtime Talk는 이미 대화 메커니즘을 처리하는 제공자에게 오디오를 라우팅하고, OpenClaw 에이전트는 기억과 도구를 계속 루프 안에 유지함으로써 이 문제를 우회합니다. 에이전트 컨텍스트에 이미 투자했고 음성 장난감이 아닌 음성 인터페이스를 원하는 개발자에게, 이는 데모와 실제로 쓸 만한 것의 차이입니다.

STT/TTS 경로를 쫓고 있었다면, 여기서의 권장 사항은 실시간 경험에 훨씬 못 미치는 파이프라인에 더 많은 토큰을 쓰기 전에 멈추고 Realtime Talk로 전환하라는 것입니다.