Claude Fable 5는 작업이 모호하거나, 실행 시간이 길거나, 트레이드오프(tradeoffs)가 많을 때—단계별 계획 수립, 복잡한 목표의 실타래 풀기, 설계 선택 사항의 무게 측정, 긴 세션이 올바른 방향을 유지하도록 하는 것 등—Claude Code에서 제가 가장 먼저 찾는 모델입니다. 이 모델은 정말 어려운 부분들을 진정으로 잘 수행합니다.

그렇기 때문에 저는 이 모델에게 쉬운 작업을 맡기는 것을 그만두었습니다. 입력 토큰 100만 개당 10달러, 출력 토큰 100만 개당 50달러라는 비용은 Opus 4.8의 5달러/25달러보다 두 배나 높습니다. 보일러플레이트(boilerplate) 코드 작성이나 린트(lint) 수정에 이 비용을 쓰는 것은 마치 수석 엔지니어(principal engineer)에게 임포트(import) 형식을 다시 맞추라고 돈을 지불하는 것과 같습니다. 작업은 여전히 필요하지만, 그 사람이 할 필요는 없다는 뜻입니다.

Claude Code의 작업은 단일 작업인 경우가 드뭅니다. 다음과 같은 한 줄짜리 명령을 예로 들어보겠습니다:

Add rate limiting to our API.

작아 보이지만, 이는 매우 다른 비중을 가진 작업들로 펼쳐집니다:

• 알고리즘 결정 — 토큰 버킷(token bucket), 슬라이딩 윈도우(sliding window), 고정 윈도우(fixed window)
• 카운터가 위치할 곳 선택 — 인메모리(in-memory) 방식, 또는 여러 인스턴스를 실행하므로 Redis 사용 여부
• 버스트(burst) 발생 시 어떤 일이 일어나는지, 그리고 클라이언트가 429 에러를 받았을 때 무엇을 보게 될지 심도 있게 생각하기
• 미들웨어(middleware) 작성
• 모든 라우트(route)에 연결
• 테스트 작성
• 린트(lint) 및 타입(type) 에러 수정
• 엣지 케이스(edge cases) 확인 — 시계 왜곡(clock skew), 리미터 자체의 실패, 키의 만료 미발생 등

처음 세 가지는 실제 설계 결정(design decisions)입니다. 잘못된 결정을 내리면 비용이 많이 들고 6개월 후에 이를 되돌리기가 매우 까다로운 종류의 작업입니다. 나머지는 실행(execution)입니다. 주의 깊은 작업이긴 하지만, 단순히 '매우 뛰어난' 모델보다 '프런티어(frontier)' 모델에 보상을 줄 만큼의 작업은 아닙니다.

그래서 저는 Fable 5를 대체하려고 하지 않습니다. 그저 결정 사항에는 Fable 5를 사용하고, 나머지 모든 것은 더 저렴한 모델에게 맡길 뿐입니다.

Fable 5를 노동자가 아닌 리더로 만드세요

구체적으로 말하자면, Fable 5를 테크 리드(tech lead)처럼 대하라는 의미입니다. 즉, Fable 5는 계획을 세우고 위임하며, 실제 구축은 다른 모델들이 수행하게 하는 것입니다.

• Fable 5 (reasoning effort: max) = 오케스트레이터 (orchestrator) — 계획을 세우고, 분해하며, 종합합니다. 코드는 작성하지 않습니다.
• Opus = 심층 추론 서브에이전트 (deep reasoning subagent) — 아키텍처, 복잡한 디버깅 (debugging), 리뷰 수행
• Sonnet = 기계적 작업 서브에이전트 (mechanical work subagent) — 구현 (implementation), 보일러플레이트 (boilerplate), 테스트, 잡무 수행
• (선택 사항) Codex = 동료 시니어 엔지니어 (peer senior engineer) — 다른 모델 제품군으로부터 얻는 독립적인 제2의 의견

Fable 5는 생각하고, 위임하며, 결과물들을 하나로 엮습니다. 더 저렴한 모델들은 이미 잘 수행할 수 있는 작업들을 처리합니다. 따라서 비용이 많이 드는 모델은 실제로 그 판단력이 보상으로 이어지는 단계에서만 가동됩니다.

제가 목표로 했던 것은 토큰 절약이었습니다. 예상하지 못했던 두 번째 효과는 다음과 같습니다. Fable 5는 원본 파일 내용이나 스택 트레이스 (stack traces)를 직접 건드리지 않기 때문에 컨텍스트 (context)가 깨끗하게 유지되며, 세션이 6시간 동안 지속되어도 미완성된 편집 사항들에 파묻히는 대신 여전히 날카로운 판단을 내릴 수 있습니다.

저는 이것이 세 단계로 이루어진 간단한 설정이라고 생각했습니다. 하지만 그렇지 않았습니다.

어려운 부분은 서브에이전트입니다

이론적으로는 세 단계입니다:

1. /model → Fable 5, reasoning effort → max
2. /agents를 사용하여 Opus와 Sonnet에 고정된 서브에이전트 생성
3. CLAUDE.md에 어떤 작업이 누구에게 갈지에 대한 라우팅 규칙 (routing rules) 작성

1단계는 10초면 끝납니다.

실제 작업이 필요한 곳은 2단계와 3단계입니다. 서브에이전트를 만드는 것은 빠릅니다. 하지만 제 역할을 제대로 해내는 서브에이전트를 만드는 것은 그렇지 않습니다.

제가 고생하며 배운 세 가지는 다음과 같습니다:

• description 필드가 누가 업무를 맡을지를 결정합니다. 오케스트레이터(orchestrator)는 서브에이전트의 설명을 읽고 선택합니다. "추론 중심 작업에 사용(Use for reasoning-heavy tasks)"과 같은 표현은 너무 모호해서 라우팅(routing)이 조용히 어긋나게 만들며, 잘못된 답변이 돌아올 때까지 이를 알아차리지 못하게 합니다.
• 시스템 프롬프트(system prompt)가 무엇이 반환될지를 결정합니다. 서브에이전트는 사용자의 대화 내용을 볼 수 없습니다. 만약 프롬프트에 행동하기 전에 무엇을 읽어야 하는지, 그리고 무엇을 반환해야 하는지(결론, diff, file:line 결과물 등)가 명시되어 있지 않다면, 결국 오케스트레이터가 서브에이전트의 뒷수습을 하게 됩니다. 이는 당신이 피하려고 했던 바로 그 상황입니다.
• "생각하는 자(Thinker)"와 "행동하는 자(doer)"는 역할이 너무 적습니다. 합리적인 시작점은 될 수 있습니다. 하지만 실제 업무는 범위 설정(scoping), 설계(design), 구현(implementation), 검증(verification), 그리고 배포(shipping)로 나뉩니다. 검증 단계를 빌더(builder)에게 통합해 버리면, 자신의 코드를 스스로 리뷰하는 에이전트를 갖게 됩니다.

따라서 실제로 시간이 걸리는 결정은 모델을 고르는 것이 아닙니다. 위임(delegation)이 제대로 작동할 만큼 역할이 날카롭게 정의된 서브에이전트 팀을 작성하는 것입니다. 그리고 여기에는 놀라울 정도로 세심한 문장 작성이 필요합니다.

ccteams: 한 번의 명령으로 팀 설계를 설치하기

이 부분은 제가 직접 손으로 다시 쓰는 것에 지쳐서, 이를 위한 도구를 만들었습니다: ccteams, 바로 **Claude Code 에이전트 팀을 위한 패키지 매니저(package manager)**입니다.

npm install -g ccteams
ccteams list           # 팀 목록 확인
ccteams use generalist # 현재 프로젝트에 팀 적용

이 단 한 번의 명령으로 역할이 특화된 서브에이전트 전체 세트가 .claude/ 디렉토리에 설치됩니다. 여기에는 이미 작성된 설명(descriptions), 시스템 프롬프트(system prompts), 도구 제한(tool restrictions), 에이전트별 model: 설정이 포함되어 있으며, **오케스트레이션 규칙(orchestration rules)**도 함께 포함되어 리드 세션(lead session)이 이들을 어떻게 실행할지 알려줍니다. 위에서 언급한 3단계(CLAUDE.md에 라우팅 규칙 직접 작성하기)가 기본적으로 포함되어 있습니다. 모델 할당 역시 마찬가지입니다. 이에 대한 자세한 내용은 아래에서 다룹니다.

팀은 스택별로 즉시 사용 가능한 형태로 제공됩니다:

팀	용도
generalist	스택에 구애받지 않는 기능 팀: 범위 설정 → 설계 → 구축 → QA → 배포
...

Claude Code 내부에서 계속 작업하는 것을 선호하시나요? 플러그인이 있습니다:

/plugin marketplace add toffyui/ccteams
/plugin install ccteams@ccteams

그러면 /ccteams:choose-team something for backend API work 명령을 통해 자연어 설명으로부터 적절한 팀을 선택하고 적용할 수 있습니다.

모델은 이미 할당되어 있습니다

제가 최근에야 제대로 이해한 부분인데, 번들로 제공되는 모든 에이전트(agent)는 프론트매터 (frontmatter)에 해당 역할이 필요로 하는 추론 (reasoning) 수준에 따라 할당된 model: 값을 이미 포함하고 있습니다. 사용자가 별도로 추가할 필요가 없습니다. ccteams use generalist를 실행하면 다음과 같이 적용됩니다:

에이전트 (Agent)	역할 (Role)	모델 (Model, 프리셋)
(메인 세션)	오케스트레이터 (Orchestrator)	Fable 5 — /model로 선택 가능
...

어떤 에이전트 파일이든 열어보면 해당 라인이 바로 거기에 있습니다:

---
name: architect
description: Technical design specialist. ...
...

ccteams가 건드리지 않는 유일한 모델은 리드 세션 (lead session)의 모델입니다. 이는 /model을 통해 사용자가 직접 선택할 수 있습니다 (예: Fable 5, 최대 노력 모드). 그 아래의 모든 모델은 고정(pinned)되어 있습니다.

이는

그다음 프로젝트의 CLAUDE.md 파일에 한 단락을 추가하세요 (ccteams가 생성하는 @.claude/active-team.md 임포트 아래에 추가):

## Peer engineer (동료 엔지니어)
Codex (/codex:rescue --background)는 다른 관점을 가진 동료 시니어 엔지니어입니다. 중대한 결정이 필요한 경우, 아키텍트 에이전트와 Codex에게 ...를 맡기십시오.

핵심은 Codex를 단순히 승인만 하는 검토자(rubber-stamp reviewer)가 아니라 동료로 사용하는 것입니다. 중대한 결정이 필요한 상황에서, 저는 Opus가 고정된 아키텍트와 Codex에게 동시에 동일한 문제를 제시합니다. 이때 두 모델은 서로의 답변을 볼 수 없으며, Fable 5가 두 답변을 조정(reconcile)하도록 둡니다. 이 방식은 두 모델이 서로 다른 계보(lineage)에서 나왔을 때 가장 효과적입니다. Opus와 Codex는 충분히 다르게 학습되었기 때문에 서로 놓치는 부분이 다르며, 따라서 한 모델이 다른 모델이 간과한 것을 잡아내는 경우가 많습니다.

다시 "rate limiting 추가"로

맨 위에서 언급했던 한 줄짜리 명령어를 기억하시나요? 제가 실제로 지금 입력하는 내용은 다음과 같습니다:

목표: 우리 API에 rate limiting (속도 제한) 추가
컨텍스트: Express + Redis, 로드 밸런서 뒤에 3개의 인스턴스로 배포됨
당신은 리드(lead)입니다. 아키텍트가 알고리즘과 ...를 결정하게 하십시오.

모든 단계는 여전히 진행되지만, 각 단계가 적절한 모델에 할당될 뿐입니다. Fable 5는 깨끗한 컨텍스트(context) 위에서 계획을 세우고 종합(synthesize)합니다. Opus는 잘못된 답변의 비용이 큰 알고리즘 및 스토리지 결정(algorithm-and-storage call)을 내립니다. Sonnet은 미들웨어(middleware)와 테스트를 작성합니다. 이 환경에서 가장 비싼 모델은 실제로 판단력이 필요했던 부분에 대해서만 비용이 청구됩니다.

이것이 처음부터 목표였습니다. Fable 5에 비용을 적게 쓰는 것이 아니라, 그 비용이 가치를 발휘하는 곳에만 비용을 쓰는 것입니다.

요약하자면

• Fable 5는 판단(judgment) — 계획(planning), 설계(design), 검토(review) — 영역에서는 그 가격만큼의 가치를 하지만, 그 외의 모든 것에는 낭비적입니다.
• 이 설정을 구축할 때 어려운 점은 모델을 선택하는 것이 아니라, 모델을 둘러싼 **팀을 설계(designing the team)**하는 것입니다.
• ccteams를 사용하면 단 한 번의 명령으로 정교하게 설계된 팀을 설치할 수 있습니다. 오케스트레이션 규칙(orchestration rules)과 에이전트별 model: 프리셋(preset)이 포함되어 있어, 적용하는 즉시 Fable-lead / Opus-reason / Sonnet-build 분업 체계가 활성화됩니다.
• /model 명령어로 리드 모델(lead model)을 선택하고 Claude Code를 재시작하면 끝납니다. 다른 분업 구조를 원한다면 어떤 에이전트의 model: 라인이든 다시 지정(repin)할 수 있습니다.

이 방법이 설정 시간을 줄여주었다면, 리포지토리(the repo)에 스타(star)를 눌러주시는 것이 가장 큰 응원이 됩니다. 만약 프리셋이 사용자가 의도한 작업 분담 방식과 맞지 않는다면, 이슈(issue)를 열어 의견을 남겨주세요 🙌