Claude Code에서 Fable 오케스트레이션으로 토큰 최대 5~10배 절약하기

Claude Code에서 Fable Orchestration으로 토큰 절약하기

1. 왜 토큰이 문제가 되는가

Claude Code로 하루 종일 작업하다 보면 어느 순간 “왜 이렇게 한도가 빨리 닳지?”라는 생각이 든다. 원인은 단순하다. 가장 똑똑한 모델일수록 토큰 단가가 비싸고, 코딩 작업의 대부분은 사실 그 정도의 추론 능력을 필요로 하지 않기 때문이다.

Anthropic 공식 가격 정책 기준으로 보면 격차가 뚜렷하다.

모델	입력 (1M 토큰당)	출력 (1M 토큰당)
Claude Fable 5	$10	$50
Claude Opus 4.8	$5	$25
Claude Sonnet 5 (2026년 8월 31일까지 도입가)	$2	$10

Fable 5는 Opus 4.8의 2배, Sonnet의 5배에 달하는 단가다. 게다가 Fable 5를 포함한 최신 모델은 이전 세대보다 약 30% 더 많은 토큰을 소모하는 토크나이저를 쓰기 때문에, 같은 텍스트라도 체감 비용은 더 커진다.

문제는 단가만이 아니다. Claude Code에서 세션 하나가 파일을 읽고, 테스트를 돌리고, 로그를 확인하고, 다시 코드를 고치는 과정을 전부 최상위 모델 혼자 처리하면, 정작 “판단”에 쓰이는 토큰보다 “노동”에 쓰이는 토큰이 훨씬 많아진다. 파일 40개짜리 리팩터링을 처음부터 끝까지 Fable 혼자 맡기면, 정작 어려운 설계 판단을 하기도 전에 일일 한도나 주간 사용량을 다 써버리는 일이 흔하다.

그래서 나온 발상이 “오케스트레이션(orchestration)”이다. 비싼 모델은 생각만 하고, 실제 손을 쓰는 작업은 싼 모델에게 맡기자는 것이다.

2. Fable 오케스트레이션이란 무엇인가

핵심 아이디어는 간단하다.

비싼 모델(Fable 5, 필요하면 Opus 4.8)은 오케스트레이터(orchestrator) 역할만 맡는다. 목표를 이해하고, 작업을 쪼개고, 누구에게 무엇을 맡길지 정하고, 결과를 검토한다. 실제 코드를 타이핑하고 파일을 뒤지는 워커(worker/subagent) 역할은 Sonnet이나 Haiku 같은 저가 모델이 맡는다.

이 구조가 토큰을 절약하는 경로는 두 가지다.

모델 단가 차이: 서브에이전트는 메인 세션과 다른 모델로 돌릴 수 있다. 몇 백 줄짜리 코드를 실제로 타이핑하는 손이 많이 가는 작업을 Sonnet·Haiku가 맡으면, 같은 작업을 Fable이 직접 할 때보다 소모되는 비용이 크게 줄어든다.
컨텍스트 격리: Claude Code의 서브에이전트는 각자 독립된 컨텍스트 창에서 실행된다. 테스트 로그, 파일 탐색 결과 같은 장황한 출력은 서브에이전트 쪽에만 쌓이고, 메인 대화에는 요약된 결과만 돌아온다. 메인 컨텍스트가 가벼워지면 이후 매 요청마다 다시 읽어들이는 입력 토큰도 함께 줄어드는 복리 효과가 생긴다.

비유하자면 수석 엔지니어가 모든 코드를 직접 짜는 대신 설계와 코드 리뷰만 맡고, 실제 타이핑은 주니어 팀에게 맡기는 조직 구조와 같다. Anthropic도 Fable 5를 소개하면서 이 모델이 에이전트 하네스 안에서 여러 날에 걸쳐 작업을 계획하고, 서브에이전트에 위임하고, 스스로 결과를 검증하도록 설계됐다고 밝힌 바 있다. Claude Code의 서브에이전트 기능은 정확히 이 용도로 만들어졌다.

3. 실제로 어떻게 셋팅하는가

3-1. 오케스트레이터 모델 선택

Claude Code 세션에서 /model 명령으로 Fable 5(또는 접근 권한이 없다면 Opus 4.8)를 메인 모델로 선택한다.

/model
> Claude Fable 5

Fable 5는 추론을 끌 수 없고 항상 켜져 있는 대신, /effort 명령으로 추론 깊이를 조절한다. 오케스트레이터는 계획을 잘 세우는 것이 핵심이므로 high 정도를 기본값으로 두고, 정말 복잡한 설계 판단이 필요할 때만 xhigh나 max로 올리는 편이 낫다. 무조건 최고 단계로 고정해두면 실제 품질 향상 없이 토큰만 많이 쓰는 경우가 흔하다는 사용자 보고가 많다.

/effort
> high

3-2. 서브에이전트 정의하기

서브에이전트는 .claude/agents/(프로젝트 전용) 또는 ~/.claude/agents/(개인용, 모든 프로젝트에서 사용) 아래에 YAML 프런트매터가 붙은 마크다운 파일로 정의한다. 필수 필드는 name과 description 두 개뿐이고, model, tools 필드로 어떤 모델을 쓰고 어떤 도구에 접근할 수 있는지 제한할 수 있다.

예를 들어 실행을 전담하는 워커 에이전트:

---
name: fast-worker
description: 이미 결정된 구현 작업을 실행한다. 파일 편집, 테스트 실행, 리팩터링처럼
  판단이 필요 없는 반복 작업에 사용한다.
tools: Read, Edit, Bash, Glob, Grep
model: sonnet
---
너는 이미 계획이 정해진 구현 작업을 수행하는 실행 담당이다.
새로운 설계 판단을 스스로 내리지 말고, 애매한 부분이 생기면 결과 보고에
"확인 필요"로 남기고 오케스트레이터에게 돌려보내라.

탐색·조사 전용 에이전트는 쓰기 권한을 아예 주지 않는 것이 안전하다.

---
name: explorer
description: 코드베이스를 읽고 구조를 파악한다. 파일을 수정하지 않는다.
tools: Read, Grep, Glob
model: haiku
---
너는 읽기 전용 탐색 담당이다. 요청받은 내용만 조사해서 짧게 요약해 보고하라.

파일을 직접 쓰는 대신 “코드 리뷰만 하고 쓰기 권한은 없는 개인용 서브에이전트를 만들어줘, Sonnet을 쓰게 해줘” 라고 Claude에게 요청하면 Claude가 알아서 이 형식으로 파일을 작성해준다.

3-3. CLAUDE.md에 위임 원칙 박아두기

가장 중요한 설정은 프로젝트 루트의 CLAUDE.md에 위임 규칙을 명시해두는 것이다. 이걸 빼먹으면 Fable이 그냥 스스로 코드를 다 짜버리고, 한 시간 만에 월간 토큰 할당량을 소진하는 일이 실제로 벌어진다.

너는 가장 비싼 모델로 실행되는 오케스트레이터다. 스스로 코드를 타이핑하지 말고,
아래 원칙을 따라라.

- 실제 코드 작성, 파일 편집, 테스트 실행은 항상 fast-worker 서브에이전트에게 위임한다.
- 코드베이스 탐색은 explorer 서브에이전트에게 위임한다.
- 너의 역할은 목표 이해, 작업 분해, 위임, 결과 검증과 최종 리뷰로 제한한다.
- 서브에이전트가 "확인 필요"로 보고한 항목은 반드시 직접 판단해서 답을 준 뒤 다시 위임한다.

이렇게 해두면 세션마다 매번 지시하지 않아도 Fable이 자동으로 오케스트레이터 역할을 유지한다.

3-4. 병렬로 돌리기

서로 독립적인 하위 작업(예: 다섯 개 모듈 각각의 리팩터링)은 순차가 아니라 병렬로 서브에이전트를 띄우는 편이 시간과 비용 모두에 유리하다. 오케스트레이터에게 “이 다섯 개 작업을 fast-worker 서브에이전트 다섯 개로 동시에 처리해줘”라고 지시하면 된다.

3-5. 실행 결과는 사람이 검토한다

위임한 코드의 최종 검토는 여전히 상위 모델(그리고 사람)의 몫이다. 하위 모델이 짠 코드를 검토 없이 그대로 커밋하면, 절약한 토큰보다 더 비싼 대가(버그, 재작업)를 치를 수 있다. 보안이나 아키텍처처럼 판단이 중요한 작업은 애초에 위임 대상에서 제외하는 것이 안전하다.

3-6. CLAUDE.md만으로는 부족할 때: 훅으로 강제하기

CLAUDE.md에 위임 규칙을 적어둬도, 세션이 길어지면 모델이 판단에 따라 코드 파일을 직접 수정해버리는 경우가 생긴다. “규칙을 적어두는 것”과 “규칙을 어겼을 때 실제로 막히는 것”은 다른 문제라는 지적도 있다. 이를 기계적으로 강제하고 싶다면 PreToolUse 훅을 등록해서, 메인 에이전트가 한 턴에 코드 파일을 직접 수정할 수 있는 횟수를 제한하고 그 이상은 서브에이전트에게 위임하도록 차단하는 방법도 있다. ~/.claude/settings.json에 Write|Edit|MultiEdit|Bash 매처로 훅 스크립트를 등록해두면, 서브에이전트를 통한 위임 경로는 통과시키고 메인 에이전트의 직접 수정만 걸러낼 수 있다.

또한 Fable을 오케스트레이터로 쓰되 실행 계층을 Claude 생태계 밖으로 확장하는 사례도 있다. Fable이 계획을 세우고, 무거운 추론이 필요한 하위 작업은 Opus가, 반복적인 실행은 다른 코딩 에이전트(Codex 등)가 나눠 맡는 식이다. 꼭 Sonnet·Haiku만 워커로 써야 하는 것은 아니고, 이미 익숙한 다른 도구를 실행 계층에 끼워 넣어도 오케스트레이션-실행 분리 원칙 자체는 그대로 적용된다.

셋팅하는 방법은 이것만 있는 것이 아니다. 아래의 참고자료를 보면 다양한 셋팅 방법이 있다. 참고자료들을 읽어보고 자신에 맞는 환경을 구성하는 것을 추천한다.

4. 실제 절감 효과는 어느 정도인가

여러 사용 사례를 종합하면 대략 이런 패턴이 반복적으로 보고된다.

잘 설계된 오케스트레이터-워커 구조에서는 전체 토큰의 80~90%가 저가 모델 쪽으로 이동하고, 전체 비용은 5~10배 줄어드는 것으로 분석된다. 품질 저하는 체감되지 않는 수준이라는 평가가 많다.
오케스트레이터가 생성하는 토큰은 한 세션에 대략 2,000~3,000개 수준에 그치는 반면, 워커들이 생성하는 토큰은 15,000~25,000개에 달한다는 사례가 보고된다. 즉 비용의 대부분이 애초에 싼 모델 쪽에서 발생하도록 구조가 짜인다.
“어드바이저-실행자” 패턴을 쓰면 전체 작업의 약 93%를 훨씬 낮은 토큰 비용으로 처리하고, 정말 어려운 판단만 다시 상위 모델로 되돌리는 식으로 할당량을 늘려 쓸 수 있었다는 사례도 있다.
40개 이상 파일이 걸린 TypeScript 마이그레이션을 Fable 혼자 처음부터 끝까지 처리하면 파일 10~15개 만에 일일 한도를 소진하지만, 오케스트레이션 구조로 나누면 같은 작업을 훨씬 더 오래, 더 많은 파일에 대해 처리할 수 있었다는 관찰도 있다.
API 종량제로 쓰는 경우에는 절감 효과가 곧바로 청구 금액 감소로 이어진다. Fable 5와 Haiku의 단가 차이(약 20배 이상)를 감안하면, 위임 비율을 조금만 올려도 총 비용 곡선이 크게 꺾인다.

다만 이 수치들은 커뮤니티와 여러 블로그에서 보고된 실측·추정치이며, 작업 종류(코드 생성 vs 조사 vs 요약)와 위임 비율에 따라 크게 달라진다는 점은 감안해야 한다. Anthropic의 공식 자료 자체는 “멀티 에이전트 워크플로우는 단일 에이전트 세션보다 대략 4~7배 더 많은 토큰을 쓴다”고 밝히고 있어, 오케스트레이션이 늘 토큰 총량을 줄여주는 것은 아니라는 점도 함께 알아둘 필요가 있다. 절감은 “쓰는 토큰의 양”이 아니라 “그 토큰이 어떤 단가의 모델에서 소모되는가”에서 나온다는 것이 핵심이다.

5. 요약 체크리스트

☐ 오케스트레이터를 Fable 5(또는 Opus 4.8)로 지정했는가 (/model)
☐ 오케스트레이터의 추론 강도를 무조건 max로 고정하지 않았는가 (/effort)
☐ 실행 전담 서브에이전트에 model: sonnet 또는 haiku를 지정했는가
☐ 탐색 전용 서브에이전트는 쓰기 권한 없이(tools: Read, Grep, Glob) 만들었는가
☐ CLAUDE.md에 “코드는 항상 서브에이전트에게 위임하라”는 규칙을 박아두었는가
☐ 독립적인 하위 작업은 병렬로 위임하고 있는가
☐ 서브에이전트 결과물을 커밋 전에 상위 모델·본인이 직접 검토하는가
☐ 보안·아키텍처처럼 판단이 중요한 작업은 위임 대상에서 제외했는가

참고자료

‘클라우드플레어(Cloudflare)’란 무엇일까? 내 블로그를 빠르고 안전하게! (무료 기능 및 티스토리 연동법)

- 6월 25, 2026

자세한 내용 보기

이 블로그 검색

해피 테크로그