Claude Fable 5.1 벤치마크 분석 — 캐시 비용 75% 절감의 실체
Anthropic이 발표한 Terminal-Bench-Science 점수는 52.6%로 Fable 5 대비 두 배 이상 뛰었어요. 그런데 Reddit 커뮤니티 반응 요약봇은 "압도적으로 부정적(not great)"이라고 잘라 말했죠. 공식 발표에서 자랑한 캐시 비용 75% 절감과 성능 향상이 왜 사용자들 분노를 샀는지, 벤치마크 수치 뒤에 숨은 맥락을 파고들었습니다.
캐시 비용 75% 절감이 실제 청구서에 미치는 영향
공식 발표는 캐시 읽기 비용이 75% 줄어서 일반 워크로드는 25%, 에이전트 워크로드는 최대 45% 저렴해진다고 밝혔어요. 이 수치는 "이미 처리된 입력을 다시 읽을 때" 드는 비용이 줄어든다는 뜻입니다. 캐시가 동작하려면 같은 프롬프트나 문맥을 반복해서 호출하는 패턴이어야 하죠.
제가 확인한 시점 기준으로 보면, 이 절감 효과는 멀티턴 대화나 반복 작업에서만 체감됩니다. 한 번 쓰고 버리는 단발성 요청이라면 캐시가 쌓이지 않아요. 실제로 45% 절감이 일어나는 "highly agentic work"는 같은 코드베이스를 수십 번 읽고 수정하는 디버깅 루프 같은 상황입니다. 이런 패턴이 아니라면 체감 할인율은 훨씬 낮아요.
여기서 놓치기 쉬운 함정은 노력 수준(effort) 설정이에요. 공식 문서에 따르면 Fable 5.1은 Claude Code에서는 High 노력으로, Claude.ai와 Cowork에서는 Medium으로 기본 동작합니다. Low나 Medium으로 내리면 Fable 5와 비슷하거나 나은 결과를 더 싼값에 얻을 수 있다고 했지만, 이건 결국 성능을 깎아서 비용을 맞춘다는 뜻이죠. High 노력으로 돌린다면 토큰 소비가 늘어서 캐시 할인 효과가 상쇄될 수 있어요.
Terminal-Bench 점수가 두 배 뛴 게 의미하는 것
Terminal-Bench-Science 0.1에서 Fable 5.1이 52.6%를 기록했고, Fable 5는 24.7%였습니다. 공식 발표는 이 수치를 재현 실험으로 확인했다고 밝혔어요. Opus 5는 29.0%, GPT-5.6 Sol은 22.4%였고요. 겉보기엔 Fable 5.1이 압도적이지만, 이 벤치마크는 과학 연구 에이전트 태스크라는 걸 놓치면 안 됩니다.
저는 이 점수를 일상 코딩이나 텍스트 작업 성능으로 착각하기 쉽다고 봅니다. Terminal-Bench 4.0(에이전트 코딩)에서는 Fable 5.1이 55.8%, Fable 5가 42.0%였어요. 향상폭은 분명하지만, 이건 여러 단계를 거쳐 문제 원인을 찾고 수정하는 장기 태스크 점수입니다. 짧은 함수 하나 짜는 속도나 첫 응답 품질하고는 다른 이야기예요.
공식 발표에 실린 Jane Street Capital 인용문은 "장기 작업에서도 가독성이 유지된다"고 평가했어요. 이건 역설적으로 이전 모델들이 긴 작업에선 출력이 흐트러졌다는 뜻이기도 합니다. Millennium 사례처럼 몇 년간 못 찾던 버그를 발견한 건 인상적이지만, 이런 극단 케이스가 제 프로젝트에서도 일어날지는 별개 문제죠.
커뮤니티가 분노한 진짜 이유 — Opus 5 문제 미해결
Reddit 반응 요약은 "아무도 Opus 5가 장황한(rambling) 상태인데 비싼 새 모델 따위 신경 안 쓴다"고 잘라 말했습니다. 커뮤니티가 요구한 건 Fable 5.1 출시가 아니라 Opus 5의 과도한 설명 패턴 수정이었어요. 월 20달러 Pro 플랜 사용자들은 Fable 5.1 접근 자체가 막혀서 "이등 시민" 취급받는다고 불만을 터뜨렸고요.
저는 이 반응이 벤치마크와 실사용 체감의 괴리를 정확히 짚었다고 봅니다. Terminal-Bench 점수가 아무리 높아도, 일상 요청에서 쓸데없이 긴 답변이 나온다면 실무 생산성은 오히려 떨어져요. Opus 5가 "load-bearing mess(구조적 엉망)"이라는 표현까지 나왔는데, 이 문제를 두고 더 비싼 모델을 내놓은 게 타이밍 실책이었죠.
공식 발표는 사이버보안 오탐이 60% 줄었고, 기본 의학 질문 폴백률이 85% 개선됐다고 했어요. 이건 세이프가드 개선 성과인데, 정작 사용자들이 부딪힌 문제는 안전망이 아니라 출력 스타일이었습니다. 개선 방향과 수요가 어긋난 거죠.
어떤 상황에서 5.1로 갈아타야 하나요?
제가 확인한 시점 기준으로, Fable 5.1로 넘어가야 하는 상황은 세 가지로 좁혀집니다.
첫째, 같은 코드베이스나 문서를 반복해서 조회하는 멀티턴 작업이 주력이라면 캐시 할인이 실제로 체감돼요. 디버깅 루프를 하루 종일 돌리거나, 같은 설계 문서를 참조하며 여러 질문을 이어가는 패턴이라면 25~45% 절감 범위에 들어갑니다. 단발성 요청 위주라면 캐시 효과를 못 봐요.
둘째, Terminal-Bench 수준의 장기 복잡 태스크를 실제로 맡긴다면 성능 향상이 분명합니다. 몇 년 묵은 버그 추적이나, 여러 단계 걸쳐 가설 검증하는 연구 작업이라면 52.6% 같은 점수가 의미 있어요. 반면 "함수 하나 짜줘" 수준 요청이라면 체감 차이는 미미하죠.
셋째, 사이버보안이나 생물학 분야 질문을 자주 던지는데 이전 모델이 계속 거부했다면, 오탐 60% 감소와 폴백률 85% 개선이 직접 와닿을 겁니다. 일반 개발자라면 이 이점은 무관해요.
반대로 Pro 플랜 사용자거나, Opus 5의 장황함이 불편했던 사람이라면 지금 5.1로 가는 건 추천하지 않습니다. 접근 자체가 안 되거나, 출력 스타일 개선 없이 비용만 오를 가능성이 크거든요. 커뮤니티 반응이 부정적인 건 이 지점 때문이에요.
자주 묻는 질문
Q. 기존 Fable 5 프롬프트를 5.1에서 그대로 써도 되나요? A. 대부분 호환되지만, 노력 수준 파라미터를 명시하지 않았다면 기본값이 High로 올라갑니다. 응답 길이가 예상보다 길어지거나 토큰 소비가 늘었다면 명시적으로 Medium이나 Low를 지정해보세요.
Q. 5.1로 전환할 때 어떤 회귀 테스트를 먼저 돌려야 하나요? A. 출력 길이와 포맷 안정성을 집중적으로 봐야 합니다. 특히 JSON이나 코드 블록처럼 구조화된 응답을 기대하는 곳에서 장황한 설명이 추가로 붙는지 확인하세요. A/B 테스트 기간을 최소 일주일은 두는 게 안전합니다.
Q. API 호출 코드에서 바꿔야 할 파라미터가 있나요? A. model 이름만 "claude-fable-5-1"로 바꾸면 됩니다. 온도나 max_tokens 같은 기존 설정은 그대로 유지돼요. 노력 수준을 조정하고 싶다면 메타데이터에 effort 필드를 추가하면 됩니다.
Q. 5.1 도입 후 롤백 기준은 어떻게 정해야 하나요? A. 응답 시간이 기존 대비 1.5배 이상 늘거나, 같은 요청에서 출력 토큰이 지속적으로 30% 넘게 증가한다면 롤백 신호로 봐야 합니다. 비용 모니터링 대시보드에서 일별 토큰 소비 추이를 주시하세요.