저렴한 모델이 OpenClaw 비용을 아껴줄 줄 알았는데, 이틀 만에 100달러가 사라지는 것을 목격했습니다

저는 에이전트 스택 (agent stacks)에서 동일한 실패 패턴을 계속 보고 있습니다:

누군가 OpenClaw로 멋진 무언가를 만듭니다.
그들은 Claude Opus, Claude Sonnet, 또는 GPT급 모델들을 사용합니다.
첫 번째 청구서가 도착합니다.
그들은 당황하여 찾을 수 있는 가장 저렴한 모델로 모든 것을 교체합니다.

이것이 비용 최적화 (cost optimization)처럼 느껴질 수 있습니다.

하지만 대부분의 경우, 그렇지 않습니다.

그것은 단지 비용을 토큰 가격에서 재시도 (retries), 잘못된 도구 호출 (bad tool calls), 복구 루프 (recovery loops), 그리고 감독자 에스컬레이션 (supervisor escalations)으로 옮기는 것뿐입니다.

예산에 맞춘 OpenClaw 설정을 조사하던 중, r/openclaw의 한 스레드에서 한 사용자가 다음과 같이 말하는 것을 발견했습니다:

"Opus, Sonnet, Haiku를 사용하여 OpenClaw에서 이틀 만에 100달러를 날렸습니다. DeepSeek으로 옮겼더니 몇 센트 정도만 소비하고 있습니다."

이것은 깔끔한 교훈처럼 들립니다: 비싼 모델을 사용하지 마라.

하지만 저는 진짜 교훈은 다르다고 생각합니다.

에이전트 시스템 (agent system)에서 가장 큰 비용은 종종 모델의 공시 가격이 아닙니다. 그것은 모델이 무언가를 약간 잘못했을 때 발생하는 일입니다.

토큰당 비용은 저렴할 수 있지만, 성공적인 작업당 비용은 비쌀 수 있습니다

챗봇 (chatbot)은 평범한 답변에도 살아남을 수 있습니다.

하지만 에이전트 (agent)는 대개 그럴 수 없습니다.

OpenClaw가 도구 (tools)를 구동할 때, 약한 모델은 단순히 나쁜 문장을 생성하는 데 그치지 않습니다. 다음과 같은 일을 할 수 있습니다:

추가적인 도구 호출 (tool calls)을 유발함
동일한 단계를 세 번 재시도함
상태 (state) 추적을 놓침
행동해야 할 때 설명을 요구함
잘못된 행동을 하여 정리 작업 (cleanup pass)을 강제함
시간과 토큰을 이미 낭비한 후 더 강력한 모델로 에스컬레이션함

이것이 바로 "그저 가장 저렴한 모델을 사용하라"는 논리가 무너지는 지점입니다.

만약 저비용 모델이 3번의 시도를 필요로 한다면, 결국 더 강력한 모델이 해당 실행을 구조해야 하므로 돈을 아낀 것이 아닙니다. 실패 오버헤드 (failure overhead)를 추가한 것뿐입니다.

에이전트 워크로드 (agent workloads)에서 중요한 지표는 호출당 비용 (cost per call)이 아닙니다.

그것은 완료된 작업당 비용 (cost per completed task)입니다.

OpenClaw는 이미 올바른 추상화인 라우팅 (routing)을 제공합니다

이것이 제가 단일 모델 OpenClaw 설정이 보통 나쁜 기본값이라고 생각하는 이유입니다.

저렴한 모델이 쓸모없기 때문이 아닙니다.

왜냐하면 OpenClaw는 세션 (sessions), 라우팅 (routing), 장애 조치 (failover), 그리고 멀티 에이전트 패턴 (multi-agent patterns)을 중심으로 구축되었기 때문입니다. 이것은 단순한 채팅 래퍼 (chat wrapper)가 아니라, 에이전트 실행을 위한 인프라 (infrastructure)입니다.

따라서 올바른 질문은 다음과 같습니다:

어떤 모델이 가장 저렴한가?

이것이 아니라:

어떤 단계가 저렴하게 사용해도 될 만큼 충분히 안전한가?

이것이 훨씬 더 나은 최적화 목표입니다.

Reddit이 소형 모델에 대해 옳게 짚은 점

또 다른 r/openclaw 스레드에는 대부분의 벤치마크 차트보다 더 유용한 댓글이 있었습니다:

"저는 간단한 도구 작업에는 Gemma 4 E4B를 사용하지만, 메인 에이전트로 Gemma 4 모델 중 그 어떤 것을 사용하려 하는 것에는 심각한 의구심이 듭니다. 거의 확실하게 끔찍하고 예측 불가능한 방식으로 실패할 것입니다."

다소 가혹하게 들릴 수도 있습니다.

하지만 이것은 실제 운영 환경 (production)에서 약한 에이전트 제어가 어떻게 느껴지는지를 정확히 설명합니다.

"추론 품질이 약간 떨어지는" 수준이 아닙니다.

그보다는 다음과 같습니다:

기이한 도구 시퀀싱 (tool sequencing)
제약 조건 망각
취약한 복구 (brittle recovery)
긴 세션 이후의 무작위 붕괴

또 다른 사용자는 Gemma의 폴백 (fallback) 동작을 다음과 같이 묘사했습니다:

"겨우 불만 밝힐 수 있는 수준 (barely keep the lights on basic)"

이것은 실제로 유용한 사고 모델 (mental model)입니다.

많은 저렴한 모델이나 로컬 모델들은 워커 (workers), 폴백 (fallbacks), 파서 (parsers), 또는 제한된 도구 실행기 (bounded tool executors)로서는 괜찮습니다.

하지만 메인 컨트롤러 (main controller)로서는 종종 잘못된 선택이 됩니다.

소형 모델은 유용합니다. 다만 역할을 잘못 맡기기 쉬울 뿐입니다.

이 지점이 사람들이 성능 체크리스트 (capability checklists)에 속는 부분입니다.

Gemma 3 및 유사한 모델들은 다음과 같은 기능들을 지원합니다:

함수 호출 (function calling)
구조화된 출력 (structured output)
긴 컨텍스트 창 (long context windows)
단일 GPU 배포 (single-GPU deployment)

이 모든 것들은 중요합니다.

하지만 함수 호출을 지원하는 모델이라고 해서 OpenClaw의 메인 자율 플래너 (main autonomous planner)로서 신뢰할 수 있다는 뜻은 아닙니다.

다음 사이에는 큰 차이가 있습니다:

이메일에서 필드 추출하기
메시지가 긴급한지 분류하기
도구 호출을 위한 JSON 형식 맞추기

그리고 다음과 같은 작업 사이에는:

6단계의 도구 시퀀스 계획하기
API 타임아웃으로부터 복구하기
재시도할지, 질문할지, 아니면 에스컬레이션 (escalate)할지 결정하기
부작용 (side effects)을 안전하게 처리하기

그 격차가 바로 많은 "저렴한 모델을 통한 비용 절감"이 사라져 버리는 지점입니다.

나의 주관적인 견해: 승자는 DeepSeek나 Gemma가 아니라 라우팅 (routing)입니다

이 내용을 한 문장으로 압축해야 한다면 다음과 같습니다:

단일 모델 (Single-model) OpenClaw 설정은 예산 절감이라는 모자를 쓰고 있는 게으른 아키텍처입니다.

정답은 다음과 같은 것이 아닙니다:

항상 Claude Opus 사용
항상 Claude Sonnet 사용
항상 GPT-5 사용
항상 DeepSeek Flash 사용
항상 Gemma를 로컬에서 실행

정답은 라우팅 (routing)입니다.

실수가 저렴한 비용으로 해결될 수 있는 곳에는 저렴한 모델을 사용하세요.

실수가 연쇄적으로 발생하는 곳에는 강력한 모델을 사용하세요.

그것이 실제로 비용을 낮추는 방법입니다.

OpenClaw를 위한 실질적인 역할 지도 (role map)

| 모델 옵션 |
| --- | --- |
| DeepSeek Flash | 분류 (classification), 추출 (extraction), 포맷팅 (formatting), 그리고 재시도 (retries)가 허용되는 제한된 하위 작업 (bounded subtasks)을 위한 저렴한 작업자 |
| ... |

그 표가 진짜 최적화 전략입니다.

모델 부족주의 (model tribalism)가 아니라,

역할 설계 (role design)입니다.

무엇을 저렴한 모델에 맡겨야 하는가?

보통 다음과 같은 것들이 좋은 후보입니다:

의도 분류 (intent classification)
엔티티 추출 (entity extraction)
스키마 제약이 있는 JSON 포맷팅 (schema-constrained JSON formatting)
스팸 필터링 (spam filtering)
저위험 요약 (low-risk summarization)
단순한 라우팅 결정 (simple routing decisions)
엄격한 검증이 동반된 결과값이 낮은 도구 호출 (low-consequence tool calls with tight validation)

예시: 메인 에이전트 (main agent)에게 넘기기 전에 들어오는 웹훅 (webhook)을 분류합니다.

{
  "task": "classify_support_ticket",
  "input": {
...

이것이 바로 저렴한 모델이 혼란을 야기하지 않으면서 비용을 절감할 수 있는 바로 그런 종류의 작업입니다.

무엇을 저렴한 모델에 맡기면 안 되는가?

이곳들은 약한 추론 (weak reasoning)이 빠르게 비용을 발생시키는 지점들입니다:

여러 도구를 가로지르는 메인 에이전트의 계획 (main agent planning)
도구 호출 실패 후의 복구 (recovery after failed tool calls)
많은 상태 (state)를 포함하는 장기 과제 (long-horizon tasks)
이메일을 보내거나, 기록을 업데이트하거나, 트랜잭션을 트리거하는 모든 것
지저분한 컨텍스트 (context)를 가진 모호한 결정
감독 로직 (supervisor logic)
재시도 정책 결정 (retry policy decisions)

실수가 "파서 (parser)를 다시 실행하라"는 의미라면, 저렴한 모델도 괜찮습니다.

만약 실수가 "에이전트가 10분 동안 폭주하고 결국 Sonnet이 구조 작업을 해야 한다"는 의미라면, 그 저렴한 모델은 더 이상 저렴하지 않습니다.

구체적인 라우팅 패턴

여기에 제가 실제로 사용할 간단한 아키텍처가 있습니다.

Step 1: 저렴한 입력 모델 (cheap intake model)

다음 작업에는 저렴한 워커 (worker)를 사용하세요:

분류 (classification)
추출 (extraction)
정규화 (normalization)
저위험 변환 (low-risk transforms)

Step 2: 중요한 턴을 위한 강력한 플래너 (strong planner)

다음과 같은 경우에는 Claude Sonnet, Claude Opus 또는 GPT-5급 모델로 에스컬레이션 (escalate) 하세요:

작업이 여러 도구 (tools)를 사용하는 경우
컨텍스트 (context)가 모호한 경우
부수 효과 (side effects)가 수반되는 경우
이미 재시도 (retries)가 시작된 경우

Step 3: 연속성을 위한 로컬 폴백 (local fallback)

로컬 모델은 품질을 유지하기 위해서가 아니라, 시스템을 계속 가동하기 위해서만 사용하세요.

즉, 폴백 (fallback)은 가동 시간 (uptime)을 보존해야 하며, 성능 (capability)을 보존하는 척해서는 안 됩니다.

Step 4: 평균 토큰 가격이 아닌 실패 유형별로 기록할 것

이 부분이 매우 중요합니다.

토큰 지출만 추적한다면 실제 문제를 놓치게 됩니다.

다음과 같은 항목들을 추적하세요:

작업당 재시도 (retries per task) 횟수
도구 호출 (tool-call) 실패율
에스컬레이션 (escalation) 비율
성공적인 작업당 평균 단계 (average steps per successful task)
타임아웃 (timeout) 또는 잘못된 도구 출력 후의 복구율 (recovery rate)

약한 모델은 단독으로 볼 때는 저렴해 보이지만, 워크플로 (workflow) 지표상으로는 비싸게 나타나는 경우가 많습니다.

의사 라우팅 로직 (pseudo-routing logic) 예시

이것은 더 많은 팀이 구현해야 할 종류의 로직입니다.

type TaskRisk = "low" | "medium" | "high";

type Task = {
...

이것이 완벽할까요? 아닙니다.

하지만 "모든 것을 가장 저렴한 모델로 보내는 것"보다는 확실히 낫습니다.

OpenClaw 설정은 인프라입니다. 그러므로 인프라처럼 다루세요

설정 흐름만 봐도 이 점은 명확합니다:

npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw status --deep

OpenClaw는 최신 Node 버전을 권장하며 라우팅 (routing) 및 페일오버 (failover)와 같은 운영 개념을 노출합니다.

이는 여러분이 모든 것에 하나의 모델을 사용하는 지름길이 아니라, 아키텍처 (architecture) 결정을 내리도록 유도해야 합니다.

시스템이 에이전트 인프라 (agent infrastructure)가 될 때, 여러분의 비용 전략 또한 인프라 수준이어야 합니다.

워크로드 (workload)가 단순하다면, 네, 저렴한 모델로도 충분할 수 있습니다

공정하게 말하자면, 때로는 저렴한 모델이 정말로 정답일 때도 있습니다.

워크로드 (workload)가 범위가 좁고 위험도가 낮다면, DeepSeek Flash, Qwen, Gemma, GLM, MiniMax 또는 로컬 Ollama 모델이 가장 경제적인 선택지가 될 수 있습니다.

특히 다음과 같은 작업을 수행하는 경우라면 더욱 그렇습니다:

웹훅 분류 (webhook classification)
문서 파싱 (document parsing)
단순 지원 분류 (simple support triage)
구조화된 추출 (structured extraction)
저위험 내부 자동화 (low-risk internal automations)

로컬 스택 (local stacks)을 사용하면 API 비용을 거의 0에 가깝게 낮출 수 있습니다.

그렇게 되면 다음과 같은 트레이드오프 (tradeoff)가 발생합니다:

하드웨어 비용 (hardware cost)
지연 시간 (latency)
설정 복잡성 (setup complexity)
긴 에이전트 실행 시의 신뢰성 (reliability under longer agent runs)

이것은 실제적인 트레이드오프입니다.

하지만 이것은 여전히 라우팅 (routing)의 문제입니다.

가장 저렴한 모델이 에이전트 하네스 (agent harness) 전체를 실행해야 한다는 증거는 아닙니다.

에이전트 비용에 관한 기묘한 진실

더 강력한 모델은 호출당 비용 (cost per call)은 더 비쌀지라도, 성공적인 작업당 비용 (cost per successful task)은 종종 더 저렴합니다.

약한 모델이 도구 그래프 (tool graph)를 8분 동안이나 헤매는 것을 보기 전까지는 이 말이 앞뒤가 맞지 않는 것처럼 들릴 것입니다.

Opus, Sonnet, Haiku를 사용하며 이틀 만에 100달러를 쓴 사용자는 한 종류의 고통을 발견했습니다.

Gemma를 폴백 등급 (fallback-grade)이라고 설명하는 사용자들은 또 다른 종류의 고통을 발견했습니다.

이 둘을 합쳐보면 패턴은 명확합니다:

잘못된 업무를 맡길 때, 가장 저렴한 모델이 OpenClaw 스택에서 가장 비싼 부분이 됩니다.

내가 실제로 할 일

만약 내가 이번 주에 OpenClaw 스택을 최적화한다면, 다음과 같이 할 것입니다:

입력 (intake), 추출 (extraction), 그리고 단순한 스키마 기반 작업 (schema-bound tasks)에는 저렴한 모델을 배치한다.
경로 계획 (route planning), 복구 (recovery), 그리고 부수 효과를 일으키는 동작 (side-effecting actions)은 더 강력한 모델로 라우팅한다.
로컬 모델은 연속성 폴백 (continuity fallback) 용도로만 유지한다.
호출당 비용 (cost per call)이 아니라, 성공적인 작업당 비용 (cost per successful task)을 측정한다.
작업 유형별로 실패 사례를 검토한다.

이것이 대부분의 팀이 건너뛰는 부분입니다.

그들은 표면적인 가격 (sticker price)을 최적화하고 실패 비용 (failure cost)은 무시합니다.

챗봇 (chatbots)에게는 그것이 통할지 모릅니다.

하지만 에이전트 (agents)에게는 대개 실패합니다.

한 가지 더: 가격 책정 모델도 중요합니다

라우팅을 잘하더라도, 토큰당 과금 (per-token billing) 방식은 에이전트 시스템에 여전히 기묘한 인센티브 구조를 만듭니다.

당신은 모든 긴 실행 과정을 마치 택시 미터기를 보듯 감시하기 시작할 것입니다.

OpenClaw, n8n, Make, Zapier 또는 커스텀 에이전트 워크플로 (agent workflows)를 하루 종일 실행하고 있다면, 이러한 감시는 금방 지치게 됩니다.

이것이 바로 제가 에이전트에게 있어 정액제 API 액세스 (flat-rate API access)가 과소평가되어 있다고 생각하는 이유입니다.

만약 당신의 스택이 끊임없이 다음과 같은 작업을 수행한다면:

재시도 (retries)
구조화된 추출 (structured extraction)
도구 오케스트레이션 (tool orchestration)
백그라운드 자동화 (background automations)
장기 실행 워크플로 (long-running workflows)

그렇다면 개별 호출당 몇 푼을 아끼는 것보다 예측 가능한 월간 비용이 종종 더 유용합니다.

이것이 바로 여기서 Standard Compute가 흥미로운 이유이기도 합니다. 이는 토큰당 과금 (per-token billing) 대신 정액제 월간 가격으로 OpenAI 호환 API 액세스를 제공하므로, 사용량을 끊임없이 감시하지 않고도 에이전트 워크로드 (agent workloads)를 실행할 수 있습니다.

자동화를 구축하는 팀에게는 이러한 가격 모델이 모델 라우팅 (model routing)만큼이나 중요할 수 있습니다.

최종 결론 (Final takeaway)

OpenClaw 스택을 단순히 모델의 표기 가격(sticker price)이 가장 낮은 쪽으로 최적화하지 마십시오.

사후 처리(cleanup) 없이, 작업을 한 번에 정확하게 완료하는 데 드는 비용을 최소화하는 방향으로 최적화하십시오.

대부분의 경우, 이는 다음을 의미합니다:

저위험 제한적 작업에는 저렴한 모델 사용
계획 (planning) 및 복구 (recovery)에는 강력한 모델 사용
실패 비용 (failure cost)에 기반한 라우팅
긴 에이전트 루프 (agent loop)가 실행될 때마다 벌칙을 주지 않는 가격 책정

이것이 효율적으로 보이는 것과 실제로 효율적인 것의 차이입니다.