Siri로 충분하다고 생각했지만, 5단계 음성 파이프라인을 설계하며 에이전트 워크플로우에는 클라우드 전용보다 로컬 우선 방식이 더 낫다는 것을 깨달았습니다

핸즈프리(hands-free) 설정을 시작한 지 3시간째, Siri가 또 다른 명령을 놓쳤을 때, 저는 음성을 UX(사용자 경험)의 문제로 취급하는 것을 멈췄습니다.

이것은 아키텍처(architecture)의 문제입니다.

전체 파이프라인을 매핑하고 나니, 실패 모드(failure mode)가 명확해졌습니다:

웨이크 워드 (Wake word)
음성-텍스트 변환 (Speech-to-text, STT)
의도 라우팅 (Intent routing)
모델/도구 호출 (Model/tool call)
응답 (Response)

이러한 분리는 자동화를 위한 음성 에이전트(voice agents)를 바라보는 저의 관점을 바꾸어 놓았습니다.

만약 여러분이 Home Assistant, OpenClaw, n8n, Make, Zapier 또는 커스텀 에이전트 스택을 사용하여 상시 가동되는 워크플로우를 구축하고 있다면, 질문은 "어떤 어시스턴트가 가장 똑똑하게 들리는가?"가 아닙니다.

진짜 질문은 이것입니다:

무엇을 로컬(locally)에서 실행해야 하고, 무엇을 클라우드(cloud)로 보내야 하며, 워크플로우가 하루 종일 버텨야 할 때 무엇이 가장 먼저 고장 나는가?

이를 조사하던 중, RSI를 위한 로컬 우선 음성 기반 에이전트에 관한 r/openclaw의 스레드를 접하게 되었습니다. 눈에 띄었던 점은 단순히 접근성만이 아니었습니다. 동일한 설계 압박이 에이전트 시스템의 모든 곳에서 나타난다는 점이었습니다. 무언가가 항상 듣고 있는 상태가 되면, 모델의 명성보다 지연 시간(latency)과 신뢰성(reliability)이 더 중요해집니다.

5단계 음성 파이프라인

대부분의 음성 설정은 다음과 같습니다:

[wake word] -> [STT] -> [router] -> [LLM/tool] -> [TTS or action]

많은 팀이 실수로 파이프라인의 너무 많은 부분을 클라우드로 보냅니다.

데모에서는 잘 작동합니다.

하지만 실제 사용 환경에서는 무너집니다.

이제 제가 신뢰하는 버전은 다음과 같습니다:

local:  wake word -> STT -> intent routing -> simple actions
cloud:                              -> hard reasoning -> optional response generation

전반부는 반복적이며 지연 시간에 민감합니다.
후반부는 비용이 많이 들고 때때로 모호합니다.

이러한 구분은 사람들이 생각하는 것보다 훨씬 더 중요합니다.

왜 로컬 웨이크 워드 감지가 하루 종일 사용하기에 Siri보다 나은가

웨이크 워드(Wake word) 감지는 지능의 문제가 아닙니다.

그것은 속도의 문제입니다.

Siri, Gemini, 그리고 다른 클라우드 중심의 어시스턴트들은 모든 상황이 이상적일 때는 세련되게 느껴질 수 있습니다. 하지만 음성 시스템의 승패는 첫 번째 단계(first hop)에서 결정됩니다.

만약 웨이크 워드(Wake word) 감지가 느리다면, GPT, Claude, 또는 Grok이 등장하기도 전에 전체 시스템이 고장 난 것처럼 느껴집니다.

항상 켜져 있는(always-on) 시스템의 경우, 로컬 웨이크 워드 감지가 다음과 같은 이유로 승리합니다:

더 빠르게 반응함
네트워크가 불안정할 때도 계속 작동함
사소한 명령을 위해 원격 의존성(remote dependency)을 피함
전체 스택(stack)을 안정적으로 느끼게 함

이것이 Home Assistant Assist가 처음 보이는 것보다 더 흥미로운 이유입니다. 이 시스템은 분할(split)을 대부분 올바르게 수행합니다. 즉, 웨이크 워드와 로컬 제어 경로를 장치 근처에 유지하고, 필요할 때만 상위 단계로 에스컬레이션(escalate)합니다.

평범한 하드웨어로도 사람들이 기대하는 것보다 더 많은 일을 할 수 있습니다. 여러 개의 스트리밍 Home Assistant 음성 새틀라이트(voice satellites)를 처리하는 Raspberry Pi 4만으로도 이미 진지한 홈 또는 오피스 자동화 설정을 구축하기에 충분합니다.

클라우드 전용 음성 스택이 실제로 실패하는 지점

벤치마크에서 실패하는 것이 아닙니다.

키노트(keynote)에서 실패하는 것도 아닙니다.

그들은 지루한 경로에서 실패합니다:

그 시간 동안 반복된 다섯 번째 명령
오케스트레이션 (orchestration)을 위한 Home Assistant Assist
로컬 STT (Speech-to-Text)를 위한 whisper.cpp 또는 Whisper
로컬 TTS (Text-to-Speech)를 위한 Piper
에이전트 라우팅 (agent routing)을 위한 OpenClaw 또는 로컬 자동화 레이어

이러한 부분들을 클라우드로 전송합니다

모호한 요청
다단계 추론 (multi-step reasoning)
요약 (summarization)
더 큰 워크플로우 전반에 걸친 도구 선택 (tool selection)
긴 컨텍스트 합성 (long-context synthesis)
더 강력한 모델로부터 실제로 이득을 얻을 수 있는 에이전트 작업

구체적인 API/모델:

OpenAI 호환 엔드포인트 (OpenAI-compatible endpoints)
GPT-5.4
Claude Opus 4.6
Grok 4.20

그것이 바로 말이 되는 실제 하이브리드 방식입니다.

로컬 전용도 아닙니다.
클라우드 전용도 아닙니다.

클라우드 폴백 (cloud fallback)을 갖춘 로컬 우선 (Local-first) 방식입니다.

실질적인 라우팅 규칙

명령이 짧고, 반복적이며, 결정론적 (deterministic)이라면 로컬에 유지하세요.

명령에 판단, 합성 또는 다단계 계획이 필요하다면 에스컬레이션 (escalate) 하세요.

다음은 Python 스타일의 의사코드 (pseudocode)로 작성된 간단한 라우터입니다:

def route_voice_command(text: str):
    simple_commands = [
        "turn on office lights",
...

이것이 화려할 필요는 없습니다.

많은 팀이 라우터를 지나치게 복잡하게 만들고, 지연 시간 (latency)에 민감한 경로에는 투자를 소홀히 합니다.

예시: 클라우드 폴백을 갖춘 로컬 우선 음성 에이전트

실제 시스템의 형태는 다음과 같습니다:

Mic
 -> local wake word
 -> whisper.cpp
...

그리고 이를 연결하는 접착제 (glue)는 매우 단순할 수 있습니다.

로컬에서 n8n 워크플로우 트리거하기

curl -X POST "http://localhost:5678/webhook/start-backup" \
  -H "Content-Type: application/json" \
  -d '{"source":"voice","command":"start backup job"}'

어려운 요청에 대해서만 클라우드 LLM 호출하기

curl https://api.standardcompute.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $STANDARD_COMPUTE_API_KEY" \
...

이러한 API 형태가 중요합니다.

클라우드 폴백이 OpenAI 호환 방식이라면, 나머지 음성 스택을 다시 구축할 필요 없이 기존 SDK 및 에이전트 프레임워크에 바로 끼워 넣을 수 있습니다.

올바르게 라우팅하면 경제성이 변하는 이유

이 부분은 사람들이 청구서가 나올 때까지 보통 무시하는 부분입니다.

모든 음성 상호작용이 무거운 클라우드 모델(heavyweight cloud model)에 도달한다면, 다음과 같은 문제가 발생합니다:

불필요한 지연 시간 (latency)
불필요한 비용
불필요한 운영상의 불안감

어려운 요청(hard requests)만 클라우드에 도달하게 한다면, 아키텍처는 더 저렴해지고 안정적이 됩니다.

그리고 에이전트가 항상 듣고 있는 상태가 되면, 예측 가능한 가격 책정(predictable pricing)이 모델 품질만큼이나 중요해지기 시작합니다.

이것이 많은 경우에서 토큰당 과금(per-token billing) 방식보다 정액제 컴퓨팅(flat-rate compute)이 음성 트리거 자동화에 더 적합한 이유입니다.

시스템이 지속적으로 낮은 수준의 리스닝(listening), 라우팅(routing), 재시도(retries), 그리고 더 강력한 모델로의 주기적인 에스컬레이션(escalations)을 수행하고 있다면, 누군가 모호한 말을 할 때마다 토큰 미터기를 지켜보고 싶지는 않을 것입니다.

Standard Compute는 한 가지 이유로 여기서 흥미롭습니다. GPT-5.4, Claude Opus 4.6, Grok 4.20과 같은 모델들 사이를 동적으로 라우팅하면서, 월정액으로 무제한 컴퓨팅을 제공하는 OpenAI 호환 API를 제공하기 때문입니다.

에이전트 빌더(agent builders)들에게 이는 로컬 우선(local-first) 아키텍처를 유지하면서도, 요청이 어려워질 때 예측 가능한 클라우드 폴백(fallback) 레이어를 가질 수 있음을 의미합니다.

이는 모든 음성 이벤트에 토큰당 과금 방식의 클라우드 모델을 억지로 붙이는 것보다 훨씬 더 나은 운영 방식입니다.

간단한 결정 테이블

요청 유형	처리하기 가장 좋은 곳
"사무실 불 켜줘"	로컬
...

직접 테스트해 볼 수 있는 최소한의 로컬 구성 요소

실용적인 주말 프로토타입을 만들고 싶다면, 여기서부터 시작하는 것을 추천합니다:

# STT
brew install whisper-cpp

...

그런 다음 다음과 같이 구성 요소들을 연결하세요:

웨이크 워드(Wake word)가 로컬에서 실행됨
whisper.cpp가 전사(transcribes) 수행
로컬 라우터가 의도(intent)를 확인
단순한 경우: Home Assistant, n8n 또는 OpenClaw 호출
복잡한 경우: OpenAI 호환 클라우드 엔드포인트로 전송
Piper를 통해 응답 반환

이렇게 하면 거대한 프레임워크를 구축하지 않고도 대부분의 이점을 얻을 수 있습니다.

파이프라인을 설계한 후의 나의 견해

지연이 실제로 어디에서 발생하는지 확인하기 전까지 Siri는 충분히 괜찮아 보였습니다.

승자는 로컬 전용(local-only)이 아니었습니다.
승자는 클라우드 전용(cloud-only)도 아니었습니다.

승자는 하이브리드(hybrid)였습니다:

속도를 위한 로컬 우선 (local-first)
신뢰성을 위한 로컬 우선 (local-first)
실제 심층 추론 (deep reasoning)이 필요한 소수의 요청을 위한 클라우드 폴백 (cloud fallback)

만약 하루 종일 작동해야 하는 음성 트리거 자동화 (voice-triggered automations)를 구축하고 있다면, 이러한 트레이드오프 (tradeoff)는 데모에서 어떤 어시스턴트가 가장 똑똑하게 들리는가보다 훨씬 더 중요합니다.

그리고 만약 이러한 자동화가 정기적으로 클라우드 모델 (cloud models)로 에스컬레이션 (escalate)된다면, 가격 모델 (pricing model) 또한 중요해집니다.

그 지점에서 Standard Compute와 같이 OpenAI 호환이 가능한 정액제 폴백 (flat-rate, OpenAI-compatible fallback)이 깔끔하게 들어맞습니다. 속도가 중요한 곳에는 로컬 (local)을, 추론이 중요한 곳에는 클라우드 (cloud)를 사용하며, 그 중간 단계에서 토큰당 비용 (per-token)에 대한 스트레스가 없습니다.

만약 제가 이 스택 (stack)을 처음부터 다시 구축한다면, 그것이 제가 가장 먼저 선택할 아키텍처 (architecture)입니다.

Insights

Siri로 충분하다고 생각했지만, 5단계 음성 파이프라인을 설계하며 에이전트 워크플로우에는 클라우드 전용보다 로컬 우선 방식이 더 낫다는 것을

요약

핵심 포인트