Claude Fable vs Opus — 언제 2배 비용을 낼 만한 가치가 있을까
PCB 설계에서 8개 파일을 동시에 참조시키자 이전 모델에서 반복되던 맥락 누락 실수가 완전히 사라졌습니다. 제가 Fable 5를 쓰며 깨달은 건 "더 똑똑해서"가 아니라 "한 번에 더 많은 걸 볼 수 있어서" 강력하다는 점이었어요. 단일 파일 수정 같은 간단한 작업엔 Opus로 충분하지만, 여러 문서를 넘나들며 맥락을 유지해야 하는 작업이라면 Fable의 100만 토큰 컨텍스트 윈도우가 값을 합니다.
제가 세운 비교 기준은 세 가지였습니다
두 달간 Fable과 Opus를 번갈아 쓰면서 어떤 상황에서 무엇이 나은지 기준을 세웠어요. 첫째는 참조 문서 개수입니다. 파일 하나만 수정하는 작업인지, 여러 문서를 동시에 읽어야 하는 작업인지가 핵심이었거든요. 둘째는 비용, 셋째는 맥락 유지력이었죠.
| 항목 | Claude Opus 4.8 | Claude Fable 5 |
|---|---|---|
| API 가격 (입력/출력, 백만 토큰당) | $5 / $25 | $10 / $50 |
| 컨텍스트 윈도우 | 100만 토큰 | 100만 토큰 |
| 강점 | 단일 파일 작업, 빠른 응답 | 여러 문서 동시 참조, 맥락 유지 |
| 적합 작업 | 참조 문서 5개 미만 | 참조 문서 5개 이상 |
위 표 가격은 제가 확인한 시점 기준이며, 최신 정보는 Anthropic 공식 문서를 확인하세요.
제 작업 환경은 API 통합·레거시 리팩토링·기술 블로그 초안 작성 같은 1인 개발자 관점입니다. 월 API 예산은 약 $200 선이에요.
단일 파일 수정엔 Opus만으로 충분했습니다
간단한 버그 수정이나 함수 리팩토링을 먼저 시도했어요. Node.js 라우터 파일을 보여주고 "에러 핸들링 추가해줘"라고 요청했죠. Opus는 파일 구조를 파악하고 필요한 부분만 수정해줬습니다. 응답 속도도 빨랐고요.
코드 라인 200~300 정도 되는 단일 파일 작업을 양쪽으로 돌려봤는데, 품질 차이는 체감이 안 됐어요. 둘 다 맥락을 놓치지 않았고, 요청을 정확히 반영했습니다. 비용만 2배 차이 났죠. 이런 작업은 Opus가 합리적이었어요.
여러 문서를 넘나들 땐 Fable이 확실히 달랐습니다
문제는 참조 문서가 늘어날 때 생겼어요. API 통합 작업에서 공식 문서 3개(인증·엔드포인트·에러코드), 기존 통합 코드 2개, 테스트 케이스 1개를 동시에 봐야 했습니다. 총 6개 파일을 넣고 "이 에러 케이스 처리 로직을 공식 문서 권장 방식으로 수정해줘"라고 요청했죠.
Opus는 초반엔 잘 따라왔는데, 대화가 길어지면서 앞에 준 공식 문서 내용을 까먹기 시작했어요. "아까 보여준 인증 플로우 문서에서는 refresh token을 어떻게 처리하라고 했죠?"라고 재차 물어야 했습니다. 반면 Fable은 6개 파일을 모두 기억한 채로 일관된 답을 내놨죠.
출처에서 본 PCB 설계 사례도 인상적이었어요. 회로도 8개 시트와 부품 데이터시트를 한 번에 넣자 Opus 쓸 때 반복되던 "핀 번호 틀림" 실수가 사라졌다고 하더라고요. 여러 문서 간 정합성을 맞춰야 하는 작업에서 넓은 컨텍스트가 결정적 차이를 만들었습니다.
비용 함정 하나 — 100만 토큰을 항상 쓰는 건 아닙니다
Fable의 컨텍스트 윈도우가 100만 토큰이라고 해서 모든 요청이 그만큼 비용을 발생시키는 건 아니에요. 제 API 로그를 보니 파일 6개 정도 넣은 요청은 대략 3~5만 토큰이었습니다. 입력 비용은 $0.30~$0.50 정도였죠. Opus였다면 $0.15~$0.25 수준이니 실제 차이는 생각보다 크지 않았어요.
단, 출력 토큰 비용은 달랐습니다. 긴 코드 블록을 여러 개 생성하면 출력이 1~2천 토큰씩 나가는데, Fable은 토큰당 $50이라 $0.05~$0.10이 순식간에 날아가더라고요. 월 예산 $200 안에서 쓰려면 긴 출력이 필요한 작업은 Opus로, 입력 맥락이 넓어야 하는 작업만 Fable로 분리해야 했습니다.
결국 저는 두 모델을 섞어 쓰기로 했습니다
구독을 Opus로 유지하면서 특정 작업에만 Fable을 쓰게 된 계기는 레거시 리팩토링 프로젝트였어요. 파일 12개를 한 번에 참조해야 했는데, Opus로 세 번 시도했다가 매번 중간에 맥락을 잃어서 결국 Fable로 갈아탔습니다. 그때 기준이 명확해졌죠 — "참조 문서 5개 이상이면 Fable, 그 이하면 Opus".
이 기준을 한 달간 적용하니 API 비용이 $180 선에서 안정됐어요. 전체 요청의 70%는 Opus로 처리하고, 나머지 30% 중 복잡한 것만 Fable로 돌렸습니다. 비용 대비 효율이 가장 좋았던 조합이었죠.
어떤 작업에 Fable을 써야 할까요?
핵심을 정리하면, 참조 문서가 많고 맥락 유지가 중요한 작업이라면 Fable이 값어치를 합니다. API 통합 문서 여러 개를 동시에 보는 작업, 레거시 코드베이스 리팩토링, 여러 데이터시트를 교차 검토하는 설계 작업 같은 경우요. 반대로 단일 파일 버그 수정, 간단한 코드 생성, 짧은 질의응답은 Opus만으로 충분해요.
비용 관점에서 보면, 월 API 예산이 넉넉하지 않다면(예: $200 이하) 두 모델을 섞어 쓰는 게 현실적입니다. 제 경우엔 참조 파일 개수를 기준 삼아 5개 이상이면 Fable, 그 이하면 Opus로 라우팅했고, 이 방식이 예산 안에서 최대 효율을 냈거든요.
Fable이 "더 똑똑한 모델"이라는 기대로 모든 작업에 투입하면 예산만 낭비하게 됩니다. 넓은 컨텍스트 윈도우가 실제로 필요한 작업을 구분하는 게 먼저예요.
자주 묻는 질문
Q. Fable과 Opus의 응답 속도 차이는 어느 정도인가요? A. 제가 체감한 바로는 비슷했습니다. 입력 토큰이 많아질수록 초기 응답까지 시간이 조금 더 걸리긴 했지만, 초 단위 차이라 실사용에선 큰 불편은 없었어요.
Q. Opus도 컨텍스트 윈도우가 꽤 넓지 않나요? A. 둘 다 컨텍스트 윈도우는 100만 토큰으로 동일하지만, 파일 여러 개를 동시에 참조시켰을 때 맥락을 잃지 않는 정도가 달랐습니다. Fable이 더 일관되게 정보를 유지했어요.
Q. Fable을 쓰면 출력 품질도 더 좋아지나요? A. 맥락을 유지해야 하는 작업에선 그렇습니다. 하지만 단일 파일 작업처럼 맥락이 단순한 경우엔 차이가 거의 없었어요. "더 똑똑하다"기보다는 "더 많이 기억한다"에 가깝습니다.
Q. 월 예산 $100 이하로도 Fable을 쓸 수 있을까요? A. 가능은 하지만 매우 선택적으로 써야 해요. 정말 복잡한 작업 1~2건에만 투입하고, 나머지는 모두 Opus로 돌리는 식이죠. 제 경험상 $200 정도는 돼야 Fable의 이점을 제대로 누릴 수 있었습니다.