내 음성 에이전트가 8초 만에 응답한 이유: 모델 문제가 아닌 두 가지 설정 때문

저는 OpenClaw를 주요 에이전트 하네스로 사용하며, 음성 레이어는 Discord에서 작동합니다. 처음 음성을 켜고 'hello'라고 말한 후 약 8초 동안 기다렸습니다. 8초는 작동하지 않는다고 가정하기에 충분히 긴 시간이었습니다.

하지만 실제로 작동했습니다. 지연 시간은 모델 때문이 아니라 두 가지 설정 기본값(default) 때문이었습니다.

OpenClaw는 제가 워크플로우를 실행하는 오픈 소스 에이전트 하네스이며, 음성 레이어는 Discord에 있습니다. 설정 키들은 OpenClaw의 것이지만, 원인인 대화 순서 처리(turn-taking defaults)는 일반적입니다.

지연을 유발한 두 가지 기본값

고정된 침묵 대기 시간 (A fixed silence wait). captureSilenceGraceMs가 기본값으로 2000ms로 설정되어 있습니다. 이는 사용자가 말을 멈춘 후 2초 전체를 기다린 후에야 자신의 차례가 끝났다고 판단합니다. 일반적인 대화는 몇 백 밀리초(milliseconds)만 남깁니다. 2초는 일시 정지처럼 인식됩니다.

매 턴마다 발생하는 전체 에이전트 왕복 처리 (A full-agent round-trip on every turn). 실시간 음성 모델은 말하기 전에 전체 에이전트를 참조했습니다. 제가 'hello'라고 말하면, OpenClaw는 도구(tools), 메모리(memory) 등 전체 에이전트를 실행한 후에야 음성 레이어가 말을 했습니다. 이 왕복 처리가 지연 시간의 더 큰 절반을 차지합니다. 이는 제가 이론적인 측면에서 작성했던 실패 사례와 같습니다: 일시 정지는 LLM에 있는 것이 아니라 대화 순서 처리(turn-taking)에 있다.

이 두 가지 모두 모델의 품질 문제가 아닌, 대화 순서 처리 설정 문제입니다.

설정 변경 (The config)

모든 것은 ~/.openclaw/openclaw.json 파일 내의 channels.discord.voice 아래에 있습니다. 이전 → 이후:

The 가장 중요했던 것은 `consultPolicy:

"channels": {
"discord": {
"voice": {
...

실시간 제공업체(realtime provider)를 사용하려면 API 키가 필요합니다. OpenAI를 사용할 수도 있고, 그쪽 비용을 고려한다면 Grok도 있습니다.

결과 (Result)

실시간 모델이 먼저 답변하고, 자신이 무엇을 호출했는지 보고합니다. 일시 정지(pause)는 사라졌고 주고받는 대화가 반응성이 좋아졌습니다.

비용 (Cost)

집에서 사무실까지의 왕복 시간 동안 한 세션에 $3.25가 발생하며, 이는 주로 입력(input)—즉 기본 청취 기능—에 대한 비용입니다. 실시간 모델을 사용하는 동안 대화하는 분당 약 30센트 정도입니다.

알려진 문제 (Known issues)

• 블루투스(Bluetooth)를 통해 들을 경우, 음악이 끊기는 방식과는 다르게 음성 답변이 잘립니다. 연결 안정성이 충분하지 않습니다.
• 긴 받아쓰기(dictation)와 빠른 주고받는 대화는 다른 모드입니다. 이 설정은 주고받는 대화에 강점이 있으며, 긴 받아쓰기의 경우 별도의 받아쓰기 도구를 사용합니다.

만약 에이전트의 음성 기능이 느리다고 느껴진다면, 모델을 탓하기 전에 무음 간격(silence grace)과 음성 계층(voice layer)이 매 턴마다 전체 에이전트를 참조하는지 확인해 보세요. 만약 다른 종류의 대화 순서 병목 현상(turn-taking bottleneck)에 부딪혔다면, 어떤 것인지 알려주시면 좋겠습니다.

더 알아보기 (More on this)

• AI 에이전트 작업용 기본 모델 스택 — 저렴하고 빠른 모델을 실시간 프론트엔드 뒤에 배치하는 것이 어떻게 작동하는지 설명합니다.
• 유능한 AI 에이전트를 매월 운영하는 데 드는 비용 — $3.25 세션 비용의 더 자세한 버전입니다.
• AI 작업 하네스란 무엇인가 —