Claude Code 모델 라우팅, 멀티 에이전트는 언제 필요한가

강한 모델 하나가 모든 코딩 작업을 맡아도 될까, 아니면 Claude Code가 요청마다 모델을 골라야 할까. Agent Teams와 모델별 서브에이전트가 공식 기능으로 자리 잡은 지금, 비용 차이보다 중요한 변수는 분업의 조정 비용이다. 이 글은 OMO, Claude Code, Sakana AI 사례로 라우팅이 이득이 되는 경계를 찾는다.

모델 선택과 에이전트 분업은 같은 기술이 아니다

모델 라우팅은 요청을 보고 한 모델을 고르는 일이다. [RouteLLM](https://github.com/lm-sys/routellm)은 강한 모델과 저렴한 모델의 예상 승률을 계산해 하나를 호출한다. 2024년 논문은 MT-Bench에서 비용을 최대 75% 줄였다고 보고했다. 다만 학습 도메인과 다른 MMLU·GSM8K에서는 일부 라우터가 무작위 선택보다 못했다.

캐스케이드는 싼 모델의 답을 먼저 받고 신뢰도가 낮을 때 상위 모델로 넘긴다. [FrugalGPT](https://arxiv.org/html/2305.05176)는 세 데이터셋에서 같은 정확도를 유지하며 59.2~98.3%의 비용 절감을 보고했다. 실험은 2023년 API와 분류·독해 과제에 묶여 있어 현대 코딩 에이전트의 지연시간까지 증명하지 않는다.

오케스트레이션은 더 넓다. 작업 분해, 역할 배정, 반복 검증, 결과 합성을 여러 호출에 걸쳐 다룬다. Claude Code의 subagents와 Agent Teams, Sakana AI의 Trinity가 이 범주다.

Claude Code에서는 작은 서브에이전트부터 만들 수 있다

[Anthropic 공식 문서](https://code.claude.com/docs/en/sub-agents)는 서브에이전트마다 별도 컨텍스트, 시스템 프롬프트, 도구, 권한, 모델을 지정하게 한다. 프로젝트의 `.claude/agents/`에 Markdown 파일을 두고 YAML frontmatter에 `name`, `description`, `tools`, `model`을 적는다. 본문에는 역할과 반환 형식을 쓴다.

예를 들어 탐색자는 `model: haiku`와 읽기 도구만 받는다. 구현자는 `model: sonnet`, 검토자는 `model: opus`와 읽기 도구를 받을 수 있다. “탐색자가 관련 파일을 찾고, 구현자가 수정하며, 검토자가 명세 누락만 보고하라”고 입력한다. 산출물은 파일 요약, 코드 변경, 검토 결과다.

더 간단한 내장 선택지도 있다. [모델 설정 문서](https://code.claude.com/docs/en/model-config)의 `opusplan`은 계획 단계에 Opus, 실행 단계에 Sonnet을 쓴다. `/model opusplan`으로 켜면 된다.

처음부터 팀 기능을 켤 필요는 없다. [Agent Teams 문서](https://code.claude.com/docs/en/agent-teams)는 팀을 실험 기능으로 표시한다. 토큰과 조정 비용이 크게 늘어난다고도 경고한다. 서로 메시지를 주고받는 병렬 조사에는 맞지만 같은 파일을 고치거나 순서 의존성이 크면 단일 세션이 낫다.

‘오몬’ 대신 정확한 OMO 제품명을 확인해야 한다

조사한 공식 자료에는 ‘OMON’이나 ‘오몬’이라는 제품명이 없다. OMO 계열의 Claude Code용 배포판은 [lazyclaudecode](https://github.com/code-yeongyu/lazyclaudecode)다. 플러그인 이름은 `omo`다. 별도 프로젝트인 Oh My ClaudeCode는 약칭이 OMC다.

Claude Code 안에서 `/plugin marketplace add code-yeongyu/lazyclaudecode`를 먼저 실행한다. 이어 `/plugin install omo@sisyphuslabs`를 입력하고 일반 요청에 `ultrawork`나 `ulw`를 넣는다. 입력한 목표를 계획·실행·검토 작업으로 나눈 결과와 도구 검증 기록이 산출된다.

이 Light 에디션은 역할별 고정 배치에 가깝다. 공식 README에서 reviewer·planner·momus는 Opus, explorer·librarian은 Haiku를 쓴다. 여러 공급자를 의미 기반 category로 고르는 전체 라우터는 OpenCode용 Ultimate 설명에 해당한다.

[OmO Native](https://github.com/code-yeongyu/oh-my-openagent)는 또 다른 배포판이다. `npm i -g omo-ai@beta` 뒤 `omo`로 실행하는 독립형 beta다. Claude Code 플러그인은 아니다. 이름이 비슷해도 설치 대상과 모델 선택 범위가 다르다.

Sakana AI는 규칙표 대신 조정자를 학습시켰다

[Sakana AI의 Trinity](https://sakana.ai/trinity/)는 작은 언어 모델의 hidden state와 라우팅 헤드로 매 턴 모델과 역할을 고른다. 최대 다섯 턴 동안 Thinker, Worker, Verifier를 배치한다. 조정자는 진화 알고리즘으로 최적화했다. Sakana AI는 ICLR 2026 결과에서 LiveCodeBench pass@1 86.2%를 보고했다. 다만 여러 호출과 단일 호출의 비용·지연은 같지 않다.

상용화 단계인 [Fugu](https://sakana.ai/fugu-release/)는 모델 선택, 위임, 검증, 합성을 하나의 API 뒤에 숨긴다. 사용자가 직접 역할표를 짜는 OMO나 Claude Code subagents보다 자동화 수준이 높다. 제품 벤치마크 일부는 공급자 공개 점수를 섞었으므로 독립된 동일 조건 비교로 읽으면 안 된다.

이 접근은 증류가 아니다. [Hinton·Vinyals·Dean의 정의](https://arxiv.org/abs/1503.02531)에서 증류는 큰 교사의 출력을 작은 학생 모델에 학습시킨다. Trinity와 Fugu는 배포 중에도 여러 모델을 골라 호출한다.

모델이 평준화돼도 오케스트레이션은 완전히 사라지지 않는다

써본 사람들 사이에서는 강한 모델을 계획과 최종 검토에 두고 기계적 실행을 저렴한 모델에 맡기는 구성이 자주 거론된다. 반면 에이전트를 늘린 뒤 중복 작업과 토큰 소비만 커졌다는 반응도 있다. 구현자와 비슷한 모델이 검토하면 같은 맹점을 공유한다는 불만도 나온다.

판단 기준은 작업 이름보다 검증 비용이다. 결과를 테스트로 빠르게 판정하고 작업 경계가 분리되면 저렴한 실행자와 강한 검토자의 조합이 유리하다. 아키텍처 결정처럼 정답 판정이 어렵거나 한 파일에 맥락이 몰리면 가장 강한 단일 모델이 조정 비용을 피한다.

모델 성능이 평준화되면 Haiku·Sonnet·Opus를 고정 배치하는 정적 라우팅의 가치는 줄어든다. 그래도 별도 컨텍스트, 제한된 권한, 독립 가설 검증은 남는다. 사라질 가능성이 큰 것은 멀티 에이전트가 아니라, 모델 이름만 보고 역할을 정하는 단순한 분업표다.