Claude Fable 5 비용 아끼는 법: Advisor Strategy 실측 결과

여러분, Claude Fable 5처럼 성능이 좋은 모델이 나오면 가장 먼저 드는 생각은 단순합니다. “이제 모든 작업을 이 모델에게 맡기면 되겠네”라는 생각이죠.

그런데 실제로 코딩 에이전트 작업을 돌려보면 이야기가 조금 달라집니다. Fable 5는 분명히 강력하지만, 그 강력한 모델에게 파일 탐색, 코드 작성, 테스트 로그 확인, 재시도 같은 구현 노동까지 전부 맡기면 비용과 한도가 빠르게 녹습니다.

결론부터 말하면, 비싼 모델은 일을 직접 하는 자리보다 일을 잘 시키고 멈출 때를 판단하는 자리에 둘 때 더 효율적일 수 있습니다. 이 글에서는 Claude Fable 5를 Advisor로 두고, Opus 4.8 또는 Sonnet 5를 Worker로 둔 실험 결과를 기준으로 Advisor Strategy가 왜 비용 절감 전략이 되는지 정리해보겠습니다.

Advisor Strategy 핵심 요약

• Advisor Strategy는 고성능 모델을 구현 담당자가 아니라 조언자와 검증자로 배치하는 방식입니다.
• Fable 5는 설계, 작업 분해, 브리프 작성, 결과 검증, 중단 판단을 맡습니다.
• Opus 4.8이나 Sonnet 5 같은 Worker 모델은 실제 코드 작성, 테스트 작성, 반복 수정 같은 구현 노동을 맡습니다.
• 테트리스 봇 실험에서는 Sonnet 5 단독이 가장 저렴할 것 같았지만, 실제로는 가장 많은 요청과 가장 긴 실행 시간, 가장 높은 비용을 만들었습니다.
• Fable 5가 Advisor로 지시하고 Opus 4.8이 Worker로 구현한 조합은 결과 품질을 유지하면서 비용을 약 5.9~7.5달러 범위로 낮췄습니다.
• 핵심은 특정 모델명이 아니라 역할 분리입니다. 더 판단력이 좋은 모델을 Advisor로 두고, 구현 노동은 적절한 Worker에게 넘기는 구조가 중요합니다.
• 단순한 한두 줄 수정에는 오히려 과합니다. 긴 멀티스텝 작업, 복잡한 리팩토링, 여러 파일을 건드리는 구현에서 효과가 커집니다.

왜 Fable 5를 직접 일꾼으로 쓰면 비싸질까요

Claude Code나 Codex 같은 코딩 에이전트 세션을 떠올려보면, 토큰을 많이 쓰는 구간은 대부분 판단이 아니라 노동입니다.

예를 들면 이런 것들입니다.

1. 관련 파일을 찾고 읽습니다.
2. 코드를 작성합니다.
3. 테스트를 돌립니다.
4. 실패 로그를 읽습니다.
5. 다시 코드를 고칩니다.
6. 또 테스트합니다.
7. 마지막에 diff를 정리합니다.

이 과정은 중요하지만, 모든 단계에 최고가 모델이 필요한 건 아닙니다. 오히려 최고가 모델이 정말 빛나는 구간은 작업을 어떻게 나눌지, 어디까지 구현하면 멈춰야 할지, 결과물이 요구사항을 충족하는지 판단하는 순간입니다.

제가 말하고 싶은 건 Fable 5를 아끼자는 의미가 아닙니다. Fable 5의 판단력을 가장 값어치 있는 위치에 배치하자는 얘기입니다. 구현 노동까지 모두 Fable 5가 직접 처리하면 성능은 좋을 수 있지만, 한도와 비용 측면에서는 너무 비싼 방식이 됩니다.

테트리스 봇 실험: 다섯 가지 구성을 비교했습니다

실험 과제는 일부러 완전히 친절하게 쓰지 않았습니다. 요즘 모델은 명세를 아주 자세히 주면 대부분 잘합니다. 그래서 빈칸을 어느 정도 남겼습니다.

요청은 대략 이런 형태였습니다.

테트리스 게임을 웹으로 만들어줘.
표준 테트리스 가이드라인 규칙을 제대로 지켰으면 좋겠고,
스스로 플레이하는 봇도 만들어줘.
봇이 얼마나 잘하는지 재현 가능한 방법으로 측정할 수 있게 해주고,
코드 품질과 테스트도 신경 써줘.

비교한 구성은 다섯 가지였습니다.

구성	역할 배치	관찰 포인트
Fable 5 단독	Fable 5가 설계와 구현을 모두 담당	가장 넓게 챙기지만 비용이 큼
Opus 4.8 단독	Opus 4.8이 모든 작업 담당	비용과 속도 균형이 좋음
Sonnet 5 단독	Sonnet 5가 모든 작업 담당	모델 단가는 낮지만 재시도가 많음
Fable 5 Advisor + Opus 4.8 Worker	Fable 5가 지시와 검증, Opus가 구현	비용과 품질 균형이 가장 좋음
Fable 5 Advisor + Sonnet 5 Worker	Fable 5가 지시와 검증, Sonnet이 구현	Sonnet 단독보다 훨씬 안정적

결과물만 보면 모든 구성에서 기본적인 테트리스 게임과 봇은 구현됐습니다. 요즘 모델 성능이 워낙 좋아져서, 기본 기능만 놓고 보면 큰 차이가 없어 보일 수 있습니다.

차이는 디테일과 비용에서 났습니다. Fable 5와 Opus 4.8은 프롬프트에 명시하지 않은 T-spin 같은 고급 판정까지 더 잘 챙겼고, Sonnet 5 단독은 기능은 만들었지만 세부 규칙과 반복 작업에서 더 많은 시행착오를 보였습니다.

실측 결과에서 드러난 반전

가장 흥미로운 지점은 비용이었습니다. 모델 단가만 보면 Sonnet 5 단독이 가장 저렴해야 할 것처럼 보입니다. 그런데 실제 작업에서는 반대로 나타났습니다.

구성	요청 수	실행 시간	비용	해석
Fable 5 단독	약 34회	약 18.9분	약 12.04달러	품질은 좋지만 모든 노동을 직접 처리
Opus 4.8 단독	약 70회	약 15.4분	약 7.07달러	단독 모델 중 균형이 좋음
Fable 5 Advisor + Opus 4.8 Worker	약 35회	약 7.4분 + 지시 2분	약 5.9~7.5달러	품질과 비용의 균형이 가장 좋음
Fable 5 Advisor + Sonnet 5 Worker	약 143회	약 22.3분 + 지시 2분	약 8.2~10.2달러	Advisor가 시행착오를 줄임
Sonnet 5 단독	약 309회	약 59.8분	약 20.95달러	가장 싼 모델이 최종 비용은 가장 큼

여기서 중요한 건 모델 단가가 아니라 총 작업량입니다. Sonnet 5는 개별 요청 단가는 낮지만, 복잡한 과제를 만나면 요청 수가 폭증했습니다. 스스로 리뷰하고, 리팩토링하고, 다시 다듬는 과정이 길어졌습니다. 결국 가장 저렴한 모델이 가장 비싼 결과를 만든 셈입니다.

반대로 Fable 5를 Advisor로 두면 Worker가 어디까지 해야 하는지 더 빨리 정리됩니다. 브리프가 좋아지고, 검증 기준이 명확해지고, 필요 없는 반복을 줄입니다. 비싼 모델을 추가했는데도 총비용이 내려가는 이유가 여기에 있습니다.

Advisor가 실제로 하는 일

Advisor Strategy를 단순히 “비싼 모델이 싼 모델에게 일을 시킨다” 정도로 이해하면 절반만 본 겁니다. Advisor의 진짜 역할은 크게 두 가지입니다.

첫째, 일을 잘 시키는 역할입니다. Worker가 다시 코드베이스를 헤매지 않도록 필요한 맥락을 브리프에 담습니다. 어떤 파일을 봐야 하는지, 어떤 규칙을 지켜야 하는지, 어떤 테스트를 통과해야 하는지 알려줍니다.

둘째, 언제 멈출지 정하는 역할입니다. 저렴한 모델은 복잡한 작업에서 스스로 멈추는 판단이 약할 때가 있습니다. 계속 고치고, 계속 리뷰하고, 계속 리팩토링하면서 비용을 늘릴 수 있습니다. Advisor는 여기서 게이트 역할을 합니다. 충분히 됐는지, 더 해야 하는지, 요구사항을 벗어난 작업은 아닌지 판단합니다.

구현 노동은 Worker에게 맡기되, 완료 판단은 Advisor가 가져가야 합니다. 이 검증 단계가 빠지면 Advisor Strategy는 단순 위임이 되고, 단순 위임은 비용 절감으로 이어지지 않습니다.

어떤 Worker 모델을 써야 할까요

많이 궁금해할 지점은 이겁니다. Worker는 Opus 4.8이 좋을까요, Sonnet 5가 좋을까요?

이번 테트리스 봇 실험에서는 Opus 4.8 Worker가 더 좋았습니다. 시간도 더 적게 들었고, 비용도 더 안정적이었습니다. 이유는 단순합니다. 과제가 생각보다 복잡했기 때문입니다. 테트리스 규칙, 봇 플레이, 성능 측정, 코드 품질, 테스트까지 들어가면 단순 컴포넌트 작업이 아닙니다.

Sonnet 5처럼 더 저렴한 모델은 단순하고 잘 정의된 작업에서는 충분히 이길 수 있습니다. 예를 들어 작은 UI 수정, 단순 테스트 추가, 반복적인 문서 포맷 변환 같은 작업이라면 Sonnet 5 Worker가 더 효율적일 가능성이 큽니다.

하지만 작업이 길고 모호하고, 시행착오 가능성이 높다면 더 강한 Worker가 오히려 싸게 먹힐 수 있습니다. 제가 더 중요하게 보는 기준은 이겁니다.

작업 유형	추천 Worker	이유
한두 파일의 작은 수정	Sonnet 5	위임 비용이 작고 빠름
반복적인 테스트 보조	Sonnet 5 또는 Opus 4.8	실패 로그 난이도에 따라 선택
복잡한 기능 구현	Opus 4.8	시행착오를 줄이는 편이 더 중요함
긴 리팩토링	Opus 4.8	컨텍스트 유지와 설계 이해가 필요함
아키텍처 판단	Advisor가 직접 판단	Worker에게 넘기면 안 되는 영역

무조건 싼 모델을 쓰는 게 비용 최적화는 아닙니다. 작업 난이도에 맞는 Worker를 고르는 것이 비용 최적화입니다.

적용 방법: 프롬프트보다 규칙 파일이 낫습니다

Advisor Strategy는 세 가지 방식으로 적용할 수 있습니다.

1. 프롬프트로 바로 체험하기: 아래 내용을 현재 세션에 그대로 붙여 넣습니다.
2. 규칙 파일에 넣기: CLAUDE.md 또는 AGENTS.md에 넣습니다. 매 세션 자동으로 적용되기 때문에 제가 가장 권장하는 방식입니다.
3. 서브에이전트로 고정하기: .claude/agents/worker.md 파일을 만들고 frontmatter에 model: opus를 지정합니다. 이렇게 하면 Worker 모델을 잘못 지정하는 실수를 줄일 수 있습니다.

프롬프트는 아래처럼 공유했습니다.

## 모델 역할 분담: Advisor / Worker

너는 Advisor다. 판단에 집중하고, 구현 노동은 Worker에게 위임하라.

Advisor(너, 메인 세션)가 직접 하는 일:

- 요구사항 분석, 작업 분해, 설계 결정
- Worker에게 줄 작업 브리프 작성
- 결과 검증: diff 직접 확인, 테스트 직접 실행
- 최종 커밋 승인, 사용자 보고

Worker(Opus 서브에이전트)에게 위임하는 일:

- 코드 작성과 수정, 테스트 작성 등 구현 작업 전부
- Agent 도구로 위임하고 model은 "opus"를 지정한다
- 서로 독립적인 작업은 병렬로 위임한다

브리프 기준:

- 네가 이미 파악한 컨텍스트를 담아 Worker가 재탐색하지 않게 하라
- 파일 경로, 프로젝트 컨벤션, 알려진 함정, 완료 기준(통과해야 할 테스트)을 포함하라

경계:

- Worker의 완료 보고를 그대로 믿지 마라. diff와 테스트로 직접 확인한 뒤 승인하라
- 검증 실패는 수정 브리프로 재위임하라. 직접 수정은 사소한 마무리에만 허용된다
- 한두 줄 수정처럼 위임 오버헤드가 더 큰 작업은 직접 처리해도 된다

여기서 핵심은 마지막 경계 조항입니다. Worker의 완료 보고를 그대로 믿지 않고, diff와 테스트로 직접 확인한 뒤 승인해야 합니다. 이 문장이 빠지면 Worker가 만든 결과를 그대로 받아들이는 구조가 됩니다. 그러면 비용은 줄어도 품질 리스크가 커집니다. Advisor Strategy의 핵심은 위임이 아니라 위임과 검증의 분리입니다.

단순 작업에는 과하게 쓰지 마세요

이 전략이 항상 정답은 아닙니다. 한두 줄 수정이나 단순 질의응답에는 Advisor와 Worker를 나누는 오버헤드가 더 큽니다. 브리프를 쓰고, Worker를 호출하고, 결과를 다시 검증하는 비용이 작업 자체보다 커질 수 있습니다.

반대로 효과가 큰 작업은 명확합니다.

• 여러 파일을 건드리는 기능 구현
• 테스트와 리팩토링이 함께 필요한 작업
• 요구사항은 짧지만 내부 판단이 많은 작업
• 실패 로그를 보고 여러 번 수정해야 하는 작업
• 장시간 돌아가는 에이전트 세션

이런 작업에서는 잘 작성된 브리프가 계속 재사용됩니다. 작업이 쌓일수록 Advisor가 처음에 만든 판단 기준의 가치가 커집니다.

특정 모델보다 역할 분리가 핵심입니다

마지막으로 오해 하나를 짚고 싶습니다. Fable 5를 쓸 수 있는 기간이나 한도가 제한적이라면 이 전략이 의미 없다고 볼 수도 있습니다. 저는 그렇게 보지 않습니다.

Advisor Strategy의 핵심은 Fable 5라는 특정 모델이 아닙니다. 판단력이 더 좋은 모델을 Advisor로 두고, 구현 노동은 적절한 Worker에게 맡긴다는 역할 분리입니다.

지금은 Fable 5를 Advisor로 두고 Opus 4.8을 Worker로 쓸 수 있습니다. 다른 상황에서는 Opus를 Advisor로 두고 Sonnet이나 Haiku를 Worker로 쓸 수도 있습니다. 앞으로 더 강한 모델이 나오면 그 모델을 Advisor 자리에 앉히면 됩니다.

중요한 건 모델 이름이 아니라 비용 구조입니다. 판단과 노동의 단가가 다르고, 모델마다 잘하는 일이 다르다면 역할을 나누는 전략은 계속 유효합니다.

여러분이 지금 바로 적용해볼 수 있는 기준은 간단합니다. 최고가 모델에게 모든 일을 시키지 말고, 최고가 모델에게 일을 잘 시키는 역할을 맡겨보세요. 결과 품질은 유지하면서 비용과 한도를 아끼는 가장 현실적인 방법이 될 수 있습니다.