비싼 모델은 계획만, 싼 모델이 실행한다 — 에이전트 하이브리드 라우팅이 바꾸는 비용 구조
Opus를 온종일 돌리다 월말 카드 명세서를 보고 식은땀을 흘려본 적이 있는가? (난 있다… 하루에 수십 달러씩 갈려 나가면 진짜 눈물 난다.) 그런데 최근 r/ClaudeCode에서 기가 막힌 묘수가 터져 나왔다. 머리 쓰는 복잡한 계획은 비싼 Claude Opus에 맡기고, 손발 쓰는 단순 코딩 노동은 DeepSeek V4 Pro나 MiniMax 같은 헐값 모델로 뺑뺑이 돌리는 하이브리드 라우팅이다. 결과는? 비용은 1/10 토막인데 품질은 거의 그대로다.
만능 에이전트의 한계
지금까지 AI 코딩 에이전트의 기본 전략은 단순했다. 가장 비싸고 똑똑한 모델 하나를 고르고, 그 모델에게 모든 걸 맡긴다. 파일 읽기, 코드 작성, 테스트 실행, 디버깅, 커밋 메시지 작성까지 전부 하나의 모델이 처리한다.
이 방식은 잘 작동했다. 문제는 비용이다. Claude Opus로 하루 종일 코딩 에이전트를 돌리면 하루에 수십 달러가 가볍게 깨진다. 복잡한 리팩토링 작업 하나에 5~10달러가 소모되는 건 일상이다. 더 큰 문제은 대부분의 작업이 “계획”이 아니라 “실행”이라는 점이다. 파일 세 개 읽고 패턴 파악한 뒤 보일러플레이트 코드 작성하는 데 Opus급 추론 능력은 불필요하다.
오케스트레이터-작업자 분리 패턴
r/ClaudeCode 커뮤니티에서 검증된 하이브리드 라우팅 구조는 명확하게 역할을 분리한다.
오케스트레이터 (Claude Opus)의 역할:
- 작업 분석 및 하위 작업 분할
- 각 하위 작업에 적합한 모델 선택
- 전체 아키텍처 및 의존성 파악
- 결과물 통합 및 품질 검증
작업자 (저가 모델)의 역할:
- 지시된 코드 작성
- 파일 수정 및 포매팅
- 테스트 케이스 생성
- 문서화
핵심은 프롬프트 하나로 이 구조가 자동 구성된다는 것이다. Claude Code에 “하위 에이전트에 DeepSeek 써”라고 말하면, Claude가 직접 JavaScript 오케스트레이션 스크립트를 작성하고 하위 에이전트를 띄운다. 수동 설정이 필요 없다.
실제 사용자 사례를 보면, 프롬프트에서 모델 라우팅 지시만 추가하면 Claude가 자동으로 다음과 같은 하네스를 생성한다.
// Claude가 자동 생성하는 오케스트레이션 하네스 (개념 예시)
const tasks = decompose(userRequest);
for (const task of tasks) {
if (task.type === 'architecture' || task.type === 'planning') {
await runWithModel(task, 'claude-opus');
} else {
await runWithModel(task, 'deepseek-v4-pro');
}
}
const result = integrate(results);
await verify(result, 'claude-opus');
오케스트레이터가 복잡도를 판단해 자동으로 모델을 선택하는 구조다. 단순 반복 작업은 DeepSeek V4 Pro에, 아키텍처 결정이나 크로스 파일 리팩토링은 Opus에 할당하는 식.
비용과 품질, 둘 다 잡기
이 패턴의 매력은 비용 절감만이 아니다. 품질 측면에서도 이점이 있다.
먼저 비용. DeepSeek V4 Pro의 토큰당 가격은 Claude Opus의 약 1/10~1/15 수준이다. 전체 작업의 70~80%가 “실행” 단계라는 점을 고려하면, 전체 비용을 1/5~1/10로 줄이는 건 수학적으로 당연하다. 한 사용자는 “기존엔 하루 30달러씩 쓰던 작업이 3달러로 줄었다”고 보고했다.
품질 측면에서는 “거의 차이가 없다”는 게 커뮤니티의 대체적인 평가. 이유는 명확하다. 코드 작성 자체는 이미 대부분의 중급 이상 모델이 잘하는 영역이다. 진짜 어려운 건 “무엇을 작성할지 결정하는 것”이고, 그 결정은 여전히 Opus가 담당한다. 품질 검증 마지막 단계도 Opus가 수행하므로, 저가 모델의 실수는 대부분 필터링된다.
물론 한계도 있다. 커뮤니티에서는 “아직 2~3개 세션 동시 운영이 한계”라는 의견이 지배적이다. 오케스트레이션이 복잡해지면 상태 관리와 에러 핸들링이 까다로워진다. 단일 에이전트에 비해 디버깅도 어려워진다.
왜 지금 주목할까
이 패턴은 단순한 비용 절감 팁이 아니다. 에이전트 아키텍처의 근본적 전환을 시사한다.
같은 주간, Google이 Antigravity에서 7개 전문 하위 에이전트 아키텍처를 공개했다. Sentinel, Orchestrator, Explorer, Worker, Reviewer, Critic, Auditor. 각각 명확히 제한된 역할만 수행한다. OpenClaw 커뮤니티에서도 클라우드+로컬 하이브리드 라우팅 실험이 활발하다. 모두 같은 방향을 가리키고 있다. “만능 에이전트 하나”에서 “전문화된 에이전트 팀”으로의 패러다임 전환.
이 흐름은 두 가지 맥락에서 이해할 수 있다. 첫째, 모델 간 성능 격차가 좁혀지면서 “모든 작업에 최고급 모델” 전략의 ROI가 급격히 떨어지고 있다. 중급 모델이 80%의 작업을 충분히 처리하는 시대다. 둘째, 에이전트의 자율성이 높아질수록 한 에이전트가 모든 걸 처리하는 구조의 취약성이 커진다. 역할 분리는 비용 문제뿐 아니라 안정성과 검증 가능성 측면에서도 유리하다.
정리
에이전트 하이브리드 라우팅은 2026년 하반기 에이전트 생태계의 핵심 키워드가 될 것이다. 오케스트레이터는 비싼 모델로 계획하고 검증하며, 작업자는 저렴한 모델로 실행한다. Claude Code, Google Antigravity, OpenClaw 등 주요 에이전트 도구가 모두 이 방향으로 이동하고 있다.
실무적으로 당장 시도해볼 수 있는 것은 간단하다. Claude Code 사용자라면 프롬프트에 하위 에이전트 모델 지시를 추가하는 것만으로 시작할 수 있다. OpenClaw 사용자라면 서브에이전트의 모델 설정을 분리하는 것으로 가능하다. 중요한 건 도구가 아니라 발상의 전환이다. “어떤 모델을 쓸까”가 아니라 “어떤 역할에 어떤 모델을 쓸까”로 질문을 바꾸는 것. 그것이 에이전트 비용 문제의 실질적 해답이다.
참고: Reddit r/ClaudeCode, r/LocalLLM, r/OpenClaw의 트렌드 데이터를 바탕으로 정리했다.