Fable 5로 1,000억 토큰 이상 사용해 본 결과, 토큰 낭비 없이 효율적으로 사용하는 법
After over 100b tokens with Fable 5, this is how to get the most of it without burning through tokens.
핵심 요약
Fable 5를 설계와 검토에, Opus 5를 실무 구현에 배치하여 토큰 비용을 80% 절감하고 코드 품질을 높이는 전략을 공유함.
- 역할 분담 — Fable 5는 설계와 아키텍처를, Opus 5는 구현과 반복 작업을 담당함
- 비용 최적화 — 고성능 모델의 사용 범위를 제한하여 토큰 비용을 70~80% 절감함
- 정밀도 검증 — 부동 소수점 연산 등 미세한 버그를 잡아내는 Opus의 깊이 있는 추론을 강조함
- 모델 비교 — Sonnet 5는 속도는 빠르지만 잠재적인 버그를 놓칠 위험이 있어 배제함
지난 2달 동안 에이전트 코딩 메인 모델로 Fable 5를 쓰면서 토큰을 1000억 개 넘게 태웠거든. 덕분에 Fable을 메인 오케스트레이터로 써서 효율을 극한으로 뽑아내는 법을 터득했다. 내가 왜, 그리고 어떻게 했는지 알려줌. (위 사진은 내 계정 중 하나 사용량임)
Fable의 정확도랑 지능은 챙기면서 사용량은 70~80% 줄이고, Fable의 장점은 거의 다 누리는 내 세팅법이다. 블라인드 코딩 테스트도 돌려봤음. Claude Sonnet 5 vs Opus 5, 여기에 Fable 5가 계획이랑 검수를 맡는 방식이었는데, 버그 하나 때문에 승부가 갈리더라.
- Fable 5: 계획, 오케스트레이션, 아키텍처, 설계, 위임된 코드 최종 검토, 보안/결제/인증/동시성 처리, 빡센 디버깅, 머지 결정에 쓰이는 UAT/브라우저 테스트, 그리고 파운더 어조나 마케팅 문구 최종 승인.
- Opus 5: Fable이 짠 계획대로 구현, 기계적인 대량 수정, 보일러플레이트 작성, 문서 생성, 리서치/요약, 뻔한 테스트 수정, Playwright 스크립트 실행, 초안 작성.
- Sonnet 5: 안 씀. 실험 결과가 좀 있는데 아래 참고하셈.
테스트 세팅: 똑같은 구현 과제 5개(레이트 리미터, 소규모 API, 레포 스타일 변경, 대량 리팩토링, 디버깅 연습)를 준비함. Fable이 짠 상세 계획을 바탕으로, 모델들이 한 번도 본 적 없는 히든 테스트 스위트로 채점했음. 둘 다 히든 테스트는 완벽하게 통과했는데, 여기서 사고가 터짐.
백분위수 함수: Sonnet은 수학 공식을 그냥 ceil((p/100) * n)으로 짰음. 근데 이진법에서 p/100은 정확하지가 않거든. p=7, n=100일 때 7.000000000000001이 나와서 ceil 씌우면 8이 됨. 틀린 값이지. 이런 식으로 입력값 141개에서 오차가 발생함. Opus는 시키지도 않았는데 이걸 잡아내서 ceil((p*n)/100)으로 고쳤음. 이게 정확한 방식이지.
Opus의 깊이만이 이걸 잡아낸 거임. 토큰 비용은 거의 똑같았고, Sonnet이 40% 더 빨랐음. 하지만 라운드마다 하나씩 튀어나오는, 절대 못 잡을 것 같은 잠재적 버그 때문에 결론은 났다.
