비싼 Fable 5, 토큰 아껴 쓰는 법
effort 설정과 모델 역할 분배로 Fable 5 비용 절감하는 방법
Fable 5는 뛰어난 성능만큼이나 비싼 모델입니다. 입력 100만 토큰당 $10, 출력은 $50인데요. Opus 4.8의 딱 두 배죠. 이번 글에서는 Fable 5를 좀 더 효율적으로 사용해서 비용 절약을 어떻게 하면 좋을지에 대해 이야기해보려고 합니다. 과지출은 대개 더 비싼 모델을 써서가 아니라 같은 모델을 비효율적으로 쓴 영향이 더 클 수 있거든요.
effort에 대해
Claude 모델은 답하기 전에 얼마나 깊게 "생각"할지를 다섯 단계로 조절할 수 있습니다. 이 "생각(extended thinking, 확장 추론)"이라는 것은 모델이 내부에서 문제를 고민하고 먼저 풀어보는 과정이고, effort는 여기에 얼마의 예산을 줄지를 정하는 값입니다. 예전에는 이런 확장 추론을 할지 말지, 켜고 끄는 방식이었는데 이제는 강도를 고르는 방식으로 바뀌었습니다. 참고로 Fable 모델은 다른 모델과 달리, "생각"을 완전히 끌 수 없도록 되어 있습니다.
| effort | 언제 쓰나 |
|---|---|
| low | 대량 처리, 단순 분류·조회. 빠르고 쌈 |
| medium | 비용 절감형. 무난한 작업 |
| high (기본) | 복잡한 추론, 까다로운 코딩 |
| xhigh | 반복 탐색이 필요한 고난도 에이전트 작업 |
| max | 토큰 제약 없이 최고 능력이 필요할 때 |
effort는 high면 충분하다
전부터 effort 설정에 따른 실질적인 성능 차이가 어떻게 달라지는지 궁금했는데요. 그걸 잘 보여주는 벤치마크 그래프가 있어서 가져와봤습니다.

DeepSWE(코딩 에이전트 성능 벤치마크) 점수 대비 과제당 평균 비용. 오른쪽 위로 갈수록 효율적입니다.
Fable 5의 곡선(맨 위)을 보면요. 점수는 어느 모델보다 높은 70% 부근인데, 왼쪽 끝 세 지점(max·xhigh·high)이 거의 평평합니다. effort를 max까지 끌어올려도 점수(성능)가 사실상 안 오른다는 뜻이죠.
- max: Task당 약 20달러가 넘습니다. 하지만 점수(성능)는 xhigh와 같고요.
- xhigh: 점수는 max와 사실상 같은데 비용은 더 쌉니다.
- high(기본값): xhigh보다 점수는 1~2%포인트 낮은 정도인데, 비용은 절반 안팎으로 떨어집니다.
정리하면 우리는 max보다는 다른 옵션을 선택하는 게 이득이라는 의미입니다. high 대비 두 배가 넘는 비용을 쓰지만 얻는 성능 차이는 고작 1~2%포인트뿐이거든요. 그래서 이 벤치마크만 보면 답은 명확합니다. 기본값인 high를 쓰고, 마지막 1~2%포인트가 아쉬운 작업에서만 xhigh를 사용하는 거죠.
코딩이 아닌 작업에서도 비슷합니다. 일반적인 실무에서 문서 작성, 분석, 기획 등에 사용을 해보면 effort 어느 단계든 결과물은 비슷했습니다. 제가 느끼기엔, 단계를 올려서 달라진 점은 재검증과 부연 설명 정도였습니다. Anthropic에서도 낮은 effort의 Fable이 이전 세대 모델의 xhigh보다 나은 경우가 많다고 적고 있고, 기본값인 high에서 시작하라고 권하고 있습니다.
참고로 effort에 따라 토큰 단가가 달라지지는 않습니다. $10/$50은 어느 단계든 동일합니다. 단계를 높일수록 비용이 올라가는 이유는 모델이 토큰을 더 많이 출력하기 때문입니다. 이것이 같은 프롬프트여도 high와 low 비용 차이가 대략 7배까지 나는 이유입니다. 상한이 필요할 때는 max_tokens로 따로 설정하면 됩니다.
계획은 Fable, 실무는 저렴한 모델
토큰을 절약하는 또 다른 방법은 Fable을 처음부터 끝까지 다 사용하지 않는 것입니다.
모든 일을 Fable에 맡기면 비싼 토큰이 잡일하는 것에 다 녹아버립니다. 회사라고 생각해보면 좋은데요. 회사에서 임원이나 직책자가 복사나 인쇄까지 다 하진 않잖아요? 통찰력과 경험을 풍부하게 가진 직책자가 방향을 딱 잡고 그 방향에 맞게 실무자들이 착착 업무를 진행하죠. 똑같습니다. Fable이 잘하는 건 판단입니다. 설계하고, 방향을 잡고, 애매한 걸 정리하는 직책자 같은 역할이죠. 그러니 판단만 Fable에 맡기고, 실무는 더 싼 모델에 내리는 구조가 좋습니다.
저는 다음과 같이 모델별로 역할을 나눠서 많이 사용하고 있습니다.
| 역할 | 모델 | 하는 일 |
|---|---|---|
| 지휘 | Fable 5 | 전체 계획, 작업 분배, 중요한 결정 |
| 실무 | Opus 4.8 | 실제 코드 작성·수정 |
| 잔무 | Haiku | 파일 찾기, 정보 조회 같은 단순 작업 |
Opus 4.8은 Fable의 절반 가격($5/$25)이고, Haiku는 그보다 훨씬 싼 모델인데요. 판단은 비싼 모델이 제대로, 체계적으로 처리하고, 반복되는 실무와 잔무는 더 저렴한 모델이 처리하는 거죠. Claude Code에서는 메인 루프를 Fable로 두고, 하위 에이전트(subagent)를 Opus·Haiku로 지정하는 식으로 꾸릴 수 있습니다. CLAUDE.md에 규칙을 적어두는 방법도 있는데, 이것만으로는 잘 안 먹힐 때가 있어서 더 확실하게는 훅(hook)으로 모델 선택을 강제하기도 합니다.
Anthropic이 이 구성을 측정한 수치도 있는데요. BrowseComp 기준으로, Fable이 지휘하고 Sonnet이 실무를 맡는 구성이 Fable 단독 성능의 96%를 절반도 안 되는 46% 비용으로 해냈다고 합니다.
추가적인 절약 방법
토큰 비용을 절약하기 위한 몇 가지 방법이 더 있습니다.
출력 토큰을 줄이면 비용을 크게 줄일 수 있습니다. 토큰 비용 구조가 출력 대 입력 5:1이라, 모델이 답을 장황하게 뽑을수록 돈이 빠르게 나가는데요. 필요한 형식과 분량을 프롬프트나 CLAUDE.md로 미리 정해두면 출력을 확 줄일 수 있습니다. (딱 필요한 말만 하도록)
입력 쪽에서도 비용 절약을 할 수 있습니다. 전달하는 컨텍스트에서 군살을 빼는 거죠. 안 쓰는 MCP 서버, 자동 메모리, 비대해진 CLAUDE.md가 매 요청마다 입력 토큰으로 넘어가서 비용이 나가거든요. 반복되는 큰 컨텍스트는 프롬프트 캐싱으로 재사용하면 입력 비용을 줄일 수 있습니다.
effort도 작업 성격과 단위별로 다르게 주는 게 중요합니다. 계획 단계만 high로 두고, 나머지는 낮추는 식으로요.
다음 글에서는 이렇게 아껴 쓴 Fable로 사람들이 실제로 뭘 만들었는지, Fable의 놀라운 사례들을 모아보려고 합니다.