Claude Code에서의 Claude Fable 5: Opus 5와의 실전 테스트

Fable 5란?

Fable 5는 Anthropic의 Claude 5 패밀리 중 코딩에 특화된 모델로, 2026년 6월 9일 출시되었습니다. 안전성 분류기가 없는 자매 모델 Mythos 5와 함께 공개되었고, Anthropic은 이를 심사된 소수의 기관에만 제공했습니다. 릴리스 전반과 벤치마크에서의 Fable 5 성능을 자세히 보려면 Fable 5 전용 가이드를 참고하세요.

Fable 5는 가격 면에서 Opus 5보다 위에 있고, 더 어려운 코딩 작업을 겨냥합니다. 체감상 가장 큰 차이는 모든 요청에서 '생각하기'가 항상 실행되고 끌 수 없다는 점입니다. 그래서 더 느리고 신중하게 보입니다. Opus 5는 추가적인 사유가 필요한지 여부를 자체적으로 판단합니다.

사양 및 가격

두 모델은 컨텍스트 윈도우와 최대 출력 크기를 공유합니다. 가격과 '생각하기' 동작에서 차이가 납니다.

Fable 5의 토큰당 비용은 Opus 5의 약 2배입니다. '생각하기'가 항상 켜져 있기 때문에 한 번의 실행에서도 더 많은 토큰을 내보내는 경향이 있어, 실제 사용 시 가격 격차는 표면적인 토큰 단가보다 더 벌어집니다. 이 가이드 후반의 맞대결 빌드에서, Fable은 더 작은 프로그램임에도 Opus보다 출력 토큰을 74% 더 많이 생성했습니다.

벤치마크 차이를 포함한 심층 비교는 Claude Opus 5 vs Claude Fable 5 가이드를 읽어 보세요.

코드에 반영해야 하는 거부 동작

Fable 5에서 보편적으로 성가신 부분은 내장 안전성 분류기입니다. 모델이 너무 강력하다고 간주되어, 생물학이나 사이버보안처럼 아주 약간만 연관되어도 해당 요청을 처리하지 않습니다.

한 면역학자의 경우, "cancer"라는 단어만으로도 바이오시큐리티 필터가 발동하여 Claude Code가 Opus 4.8로 폴백했습니다.

저도 최근 개인 프로젝트의 로그인 버그에서 이 문제를 겪었습니다. Telegram Gateway API를 이용해 OTP로 로그인하는 흐름이었는데, Fable 5는 아예 다루기를 거부했습니다. Opus 5는 문제없이 해결했죠. 이것이 바로 문제의 핵심입니다. 그 버그에는 보안 위험 요소가 전혀 없었습니다.

자동 폴백은 설정 없이 Claude Code와 Claude 앱 내부에서만 일어납니다. API로 Fable을 사용하는 경우 성공 코드 200을 받더라도 응답에 stop_reason 필드가 포함됩니다.

응답은 다음과 같습니다:

{
  "stop_reason": "refusal",
  "stop_details": {
	"category": "bio",
	"explanation": "The request was declined by a safety classifier."
  }
}

따라서 응답 본문을 처리하기 전에 stop_reason을 반드시 확인해야 합니다. 

서버 측 폴백을 활성화하려면 fallbacks 배열(예: "fallbacks": [{"model": "claude-opus-4-8"}])을 전달하고, anthropic-beta: server-side-fallback-2026-06-01 헤더를 함께 보내세요. 계정 단위 스위치는 없으므로, 모든 요청에 설정해야 합니다.

폴백 모델에 대한 참고

어떤 출처는 Fable 5가 Opus 4.8로 폴백한다고 하고, 또 다른 곳은 Opus 5로 간다고 합니다. 둘 다 맞습니다. 카테고리와 환경에 따라 대상이 달라지기 때문입니다. 

Claude Code에서는 생물학으로 표시된 요청은 이제 Opus 5에서 재실행되고, 사이버보안으로 표시된 요청은 여전히 Opus 4.8에서 재실행됩니다. API에서는 서버 측 fallbacks 기능이 현재 Opus 4.8만 지원합니다. 

이 분리는 시점의 문제입니다. Fable이 6월에 출시될 당시에는 모든 폴백이 Opus 4.8로 갔고, 7월 24일 Opus 5가 출시된 후 생물학 경로만 Opus 5로 재지정되었습니다.

Fable 5를 둘러싼 논란

안전성 분류기를 빼고도, Fable 5의 출발은 평탄하지 않았습니다.

조용한 스로틀링과 잘못된 거부

출시 며칠 후 Fortune 보도에 따르면, Anthropic이 아무에게도 알리지 않은 채 AI 및 ML 인프라 트래픽의 약 0.03%에서 Fable 5의 응답을 은밀히 약화시켰다고 합니다.

연구자들과 개발자들은 월 $200 구독료를 내고 어떤 작업이든 처리할 수 있는 프런티어 모델을 기대했기 때문에 크게 분노했습니다.

Anthropic은 하루 만에 커뮤니티 압박에 굴복하며 "잘못된 균형점"을 택했다고 밝혔습니다. 바뀐 것은 스로틀링이 아니라 가시성이었습니다. 이제 표시된 요청은 거부와 같은 방식으로 드러나고, 성능 저하는 그대로 유지됩니다. Anthropic의 논리는 이미 자사 약관에 Claude를 경쟁 AI 시스템 구축에 사용하는 것을 금지하고 있다는 것이고, 이 점은 변론의 여지가 있습니다. 다만 이를 한 달간 조용히 진행한 것은 잘못이었습니다.

수출통제에 따른 중단

그다음 더 큰 일이 벌어졌습니다. 공개된 탈옥(jailbreak)으로 인해 6월 12일 상무부의 수출통제 명령이 발동되면서, Anthropic은 전 세계에서 Fable 5와 Mythos 5를 19일간 오프라인으로 내렸습니다.

Anthropic은 내내 강하게 반발했습니다. 해당 탈옥이 보편적이라기보다 협소하며, 더 약한 모델로도 찾을 수 있다며, 회수 기준이 자사 입장에서는 불투명하다고 주장했습니다. 기준 자체에 대한 문제 제기는 일리가 있었습니다. 보편적 탈옥은 아직 누구도 만들지 못했고, 오늘날 어떤 모델도 그 기준을 넘지 못합니다. 영국 AI 안전 연구소는 이와 관련한 진전을 보고했지만, 실제로 동작하는 것은 없습니다.

다만 표현 방식은 별개로, 기준 자체에 대한 지적에는 일리가 있었습니다. 보편적 탈옥은 존재합니다. 영국 AI 보안 연구소는 테스트한 모든 프런티어 시스템에서 이를 발견했다고 보고했고, Fable 5의 모델 카드에 따르면 레드팀이 Fable 5 자체에 대해 수 시간 내 단일 턴으로, 며칠 내 멀티턴 에이전트 워크플로까지 확장되는 탈옥을 구축했습니다.

진짜 쟁점은 그런 기준이 회수를 촉발해야 하는가이지, 그런 탈옥이 가능한가의 여부는 아닙니다.

복구, 그리고 새로운 제한

Anthropic은 더 강한 분류기를 선보이며 차단율 99% 이상을 보고했고, 이를 근거로 상무부는 6월 30일경 통제를 해제했습니다.

일반 접근은 7월 1일에 돌아왔지만 조건이 더 엄격해졌습니다. 약속했던 2주 무제한 창구는 약 1주로 줄었고, 새로운 주간 50% 상한이 생겨 이를 넘기면 이후 Fable 5 사용분은 토큰당 $10과 $50의 정가 크레딧으로 청구되었습니다. 이로 인해 구독자들이 Reddit에서 불만을 터뜨리기 충분했습니다.

Anthropic은 기한을 두 차례 연장한 뒤, 7월 20일 요금제별로 정책을 분리했습니다. Max와 Team Premium은 종료 기한 없이 주간 한도의 50%까지 Fable 5를 유지하고, Pro와 Team Standard는 1회 $100 크레딧을 받으며 이후에는 API 요율로 과금됩니다. Mythos 5는 국제적으로 더 넓었던 프로그램에서 축소되어, 심사된 약 100개의 미국 기관에만 돌아갔습니다.

결국 Fable 5는 강력한 모델이지만 접근 정책이 달마다 바뀌는 상태로 남았습니다. 가끔 발생하는 오거부를 염두에 두고, 이번 달의 속도 제한이 다음 달에도 유지될 거라고 기대하지 마세요.

같은 프로젝트에서 Claude Fable 5와 Opus 5 비교

동일한 조건에서 두 모델이 어떻게 동작하는지 보기 위해, 새 Claude Code 세션에서 두 모델에 같은 작업을 부여했습니다. 이후 전체 세션 기록, 내부 JSONL 파일을 읽고, 브라우저에서 완성된 두 앱을 평가했습니다.

처음에는 URL 단축기를 과제로 썼는데, 그건 실수였습니다. URL 단축기는 모든 모델의 학습 데이터에 있는 정답이 하나뿐이라, 두 모델이 테마와 기능까지 거의 같은 앱을 만들었습니다. 시험이 아무것도 측정하지 못했죠.

Fable 5와 Opus 5에서 원샷 생태계 시뮬레이션 설정

그래서 정해진 답이 없는 과제를 골랐습니다. 살아 있는 생태계 시뮬레이션입니다. 먹이그물 속 3종, 무리지어 다니고 사냥하고 굶주리는 에이전트, 화면에 한 번에 5000개를 띄우고, 시드로부터 결정적으로 재현 가능해야 합니다. 어려운 부분을 대신해 줄 라이브러리는 금지하여, 각 모델이 공간 쿼리, 조향, 개체군 동역학을 직접 구현해야 합니다.

두 모델이 똑같이 받은 프롬프트는 다음과 같습니다.

Build a living ecosystem simulation that runs in the browser, and ship it end-to-end in one shot, without asking me any questions or pausing for confirmation. Make all decisions yourself and only stop when it is fully built, tested, and pushed to GitHub.
 
Requirements:
 
- A real-time canvas simulation of an ecosystem with at least three species in a food web (for example producers, herbivores, predators). Species interact: they eat, they are eaten, they reproduce, and they die.
- Agents move with steering behaviour — flocking among their own kind, and avoidance or pursuit across species.
- Each agent has an energy budget. Moving and reproducing cost energy, eating restores it, and running out kills the agent. Population levels must emerge from these rules rather than being scripted.
- The simulation must stay stable and interactive at 5000 agents. Show a live FPS counter and a live population graph per species.
- The whole world is generated from a numeric seed. The same seed must always produce the same run.
- Controls to pause, resume, reset, reseed, and tune the key simulation parameters live while it runs.
- Implement the simulation yourself: the steering, the spatial queries, the integration, and the population dynamics. Do not use a physics engine, a flocking library, a game engine, or a charting library. Plain canvas and your own code.
- Tests covering the core simulation logic.
- A README with setup and run instructions.
 
The simulation should run in the browser and be usable by someone who has never seen it before.
 
When it is complete, create a new GitHub repository with the gh CLI (which is already installed and authenticated) and push the project to it.

질문 금지 규칙이 핵심입니다. 잘못된 방향 전환을 아무도 잡아주지 않을 때, 각 모델이 어디까지 스스로 빌드를 밀어붙이는지를 보여줍니다. 두 모델은 서로 같은 작업을 한다는 힌트 없이 각각 빈 디렉터리에서 실행했습니다.

또한 이 작업은 겉으로 보기엔 시각적 출력 같아도, 그 안에 객관적인 테스트 네 가지가 숨겨져 있습니다. 

• 이웃 탐색은 공간 인덱스를 사용해야 합니다. 그렇지 않으면 5000 에이전트에서 프레임률이 급락합니다. 
• 세계 경계는 래핑 또는 클램핑이 올바르게 작동해야 합니다. 그렇지 않으면 에이전트가 벽을 뚫고 나갑니다. 
• 무작위성은 시드 기반 생성기를 통해야 합니다. 그렇지 않으면 같은 시드에서 다른 실행 결과가 나옵니다. 
• 출생률과 사망률의 균형이 맞아야 합니다. 그렇지 않으면 개체군이 0으로 고사하거나 폭주합니다. 

이 모든 실패는 화면에서 바로 보입니다. 보기 좋은 데모가 평가 가능해지는 이유죠.

두 빌드는 모두 라이브이므로, 제 말을 그대로 믿지 않고 직접 비교해 볼 수 있습니다. 둘을 나란히 열고 각각 reseed 하세요:

• Fable 5 빌드: ecosystem-fable-5.vercel.app (소스)
• Opus 5 빌드: ecosystem-opus-5.vercel.app (소스)

아래에는 두 빌드의 스크린샷도 있습니다. 클릭보다 읽기를 선호한다면 참고하세요. 다만 화면 전체가 보이도록 축소되어 있어, 세부가 또렷하지 않을 수 있습니다.

각 실행에 실제로 사용된 모델

결과로 들어가기 전, 해석에 중요한 방법론적 메모 하나입니다.

Claude Code는 Fable 5의 안전성 분류기가 요청을 거부할 때 Opus로 폴백할 수 있습니다. 따라서 Fable로 표시된 실행이 온전히 Fable이라고 보장할 수는 없습니다. 추측 대신, 두 기록의 모든 assistant 이벤트에서 model 필드를 기록했습니다.

다행히 제 비교에서는, Fable 실행의 모든 이벤트가 claude-fable-5로, 총 103개 모두 돌아왔습니다. Opus 실행의 모든 이벤트는 claude-opus-5로, 총 247개 모두 돌아왔습니다. 어느 쪽도 폴백은 발생하지 않았습니다. 아래 수치는 라벨의 모델을 그대로 설명합니다.

Fable 5와 Opus 5의 문제 접근 방식

Fable은 조용히 작업했습니다. 도구 호출 56회, 전체 빌드에 걸쳐 코멘트 429단어를 2개의 텍스트 블록으로 출력했습니다.

Opus는 공개적으로 일했습니다. 도구 호출 137회로 두 배가 넘고, 110개의 블록에 걸쳐 4,808단어를 출력했습니다. 작성량을 감안하면 두 모델 모두 파일당 약 2회의 수정 비율로 비슷했습니다.

툴링에서도 갈렸습니다. Fable은 순수 ES 모듈에 python3 -m http.server 시작 스크립트를 사용했고 node_modules가 전혀 없습니다. Opus는 Vite와 Vitest를 설치해 실제 툴체인으로 빌드했습니다.

아래 빌드 시간은 실제 작업 시간만 측정합니다. 첫 assistant 이벤트부터 마지막까지를 잡고, 세션이 대기만 하고 빌드하지 않은 공회전 시간은 제외했습니다.

결과: 속도, 비용, 정확성

Fable 은 비용이 43% 더 들었고, 더 작은 프로그램임에도 출력 토큰을 74% 더 많이 생성했습니다. '생각하기'를 끌 수 없으니, 작업에 필요 없을 때도 비용이 계속 청구됩니다.

두 모델은 모든 객관적 검사를 통과했습니다. 

• 같은 시드는 같은 세계를 재현합니다.
• 다른 시드는 다르게 전개됩니다.
• NaN에 도달하는 값이 없습니다.
• 최대 속도에서도 어떤 에이전트도 세계 밖으로 탈출하지 않습니다.
• 둘 다 브라우저에서 콘솔 에러 없이 60 FPS를 유지합니다.

Opus의 시뮬레이션은 틱당 2.3배 빠릅니다. 속성별로 하나의 평탄한 타입드 배열에 에이전트를 저장하고, 종마다 별도의 공간 격자를 유지합니다. Fable은 에이전트마다 객체를 두고, 세 종이 하나의 균일 격자를 공유합니다. 둘 다 정답이지만, Opus의 데이터 레이아웃이 더 빠릅니다.

Fable이 배포한 결함

Fable의 npm test 스크립트는 실행되지 않습니다. node --test test/를 배포했는데, Node 26에서는 이를 디렉터리가 아닌 모듈 경로로 해석해 명령이 단 하나의 테스트도 실행하지 못하고 종료됩니다. 내부의 16개 테스트는 파일을 명시하면 정상 통과합니다. 다만 package.json의 엔트리 포인트가 잘못되었습니다.

작은 버그지만 비용이 큽니다. 독자가 실제로 입력할 유일한 명령이 실패하기 때문입니다. 또한 Fable은 이를 끝내 잡지 못했습니다. 프롬프트는 테스트를 요구했고, Fable은 사용자들이 쓰지 않을 경로로 테스트를 검증했습니다.

Opus에는 동등한 실패가 없습니다. 58개 테스트가 npm test로 실행되어 통과합니다. 두 테스트 모음은 시드 기반 결정성, 에너지 보존, 토러스 래핑, 장기 생존 등 이 과제에 중요한 부분을 모두 검사합니다. 차이는 종류가 아니라 깊이입니다. Opus만 작성한 검사는 5000 에이전트 스트레스 테스트로, 요구사항 중 가장 깨지기 쉬운 항목이기도 합니다.

스크린샷이 보여주는 것

두 앱은 전혀 다르게 보입니다. 그래서 과제를 바꾼 보람이 있습니다.

Fable 5: 왼쪽에 컨트롤, 에이전트는 평면 사각형, 종 이름은 Plants, Herbivores, Predators.

Opus 5: 오른쪽에 컨트롤, 에이전트는 진행 방향을 가리키는 삼각형, 종 이름은 Plankton, Grazers, Hunters.

UI 측면의 주요 차이는 다음과 같습니다.

• Fable은 왼쪽에 패널을 두고 모든 에이전트를 평면 사각형으로 그렸으며, 종을 Plants, Herbivores, Predators로 명명했습니다.
• Opus는 오른쪽에 패널을 두고 방향성 삼각형으로 그려, 무리가 어느 쪽으로 이동하는지 읽을 수 있습니다. 수중 테마를 도입해 Plankton, Grazers, Hunters라는 이름을 붙였습니다.

개체군 그래프 읽기

개체군 그래프에서 설계 차이가 뚜렷해집니다.

Fable 5의 그래프, 선형 축척. 식물 선이 전체 높이를 차지하고 포식자 선은 축에 붙어 있습니다.

Opus 5의 그래프, 로그 축척. 세 종 모두 읽기 쉬우며, 헌터 선이 그레이저 선을 가로지릅니다.

두 시뮬레이션은 포식-피식 시스템답게 진동합니다. Fable의 식물은 5분 동안 520에서 7,061 사이를 오르내리고, 초식동물과 포식자가 그 뒤를 주기적으로 따릅니다. 포식자는 초식이 119로 바닥을 찍을 때 정확히 248에서 정점을 찍습니다.

선형 축척에서는 식물 선이 전체 세로 범위를 차지하고, 초식은 얇은 띠로 압축되며, 포식자는 축에 바짝 붙습니다.

그래서 Opus는 그래프를 로그 축척으로 두고 피크에 라벨을 붙였습니다. 세 종이 모두 읽히고, 헌터 선이 그레이저 선을 올라 교차한 뒤, 그레이저가 회복하면서 내려가는 모습을 볼 수 있습니다. 같은 종류의 데이터지만, 두 차트 중 읽을 수 있는 것은 하나뿐입니다.

두 생태계의 동작 차이

기저 생태계도 다릅니다. Opus는 생산자 층을 플랑크톤 4,229개로 상한을 두어, 그 개체군은 천장에 붙고 상위 두 종만 순환합니다. Fable은 세 종을 모두 결합 상태로 두어 더 넓은 진폭과 더 생동감 있는 세계가 됩니다. 프롬프트에서 요구하지 않았지만 안정성과 역동성의 차이가 생겼습니다.

Fable 5의 파라미터 패널: 시뮬레이션 고유 단위로 된 13개 슬라이더.

Opus 5의 파라미터 패널: 1.00 배율로 정규화된 9개 슬라이더, World와 Behaviour 그룹으로 묶임.

Fable은 실제 단위로 13개 파라미터를 노출합니다. 예: 식물 성장 5, 지각 반경 60, 분리 1.5, 종별 대사율. Opus는 모두 1.00에서 시작하는 정규화된 배율의 9개를 World와 Behaviour 그룹으로 나눠 노출합니다. 

한 문장으로 정리하면: Fable은 더 많은 제어를 제공하고, Opus는 생태계 균형을 쉽게 깨지 않도록 설계된 패널을 제공합니다.

Fable 5와 Opus 5, 무엇을 선택할까?

기본값으로는 Opus 5를 쓰세요. 이번 빌드에서 비용은 30% 더 저렴했고, 시뮬레이션은 2.3배 빨랐으며, 테스트 커버리지가 더 좋았습니다. 속도에서는 Fable이 우세해, 절반가량의 시간에 마무리했습니다.

감독을 최소화한 원패스 빌드를 원하거나, 의존성 풋프린트가 중요할 때는 Fable 5를 쓰세요. Fable은 의존성 없는 프로그램을 대안보다 42% 더 작게 배포했으며, assistant 턴 103회로 247회 대비 훨씬 적은 상호작용으로 도달했습니다. 이 간결함은 이후 직접 코드를 읽을 계획인 작업에서 실제 가치를 가집니다.

마무리 생각

동일한 유형의 프로젝트 두 건만으로는 아직 벤치마크라 보기 어렵습니다. 실제 성능은 기존 벤치마크와 무관하게 크게 달라질 수 있습니다.

예를 들어, 이번 비교에서는 Fable이 Opus보다 더 많은 토큰을 사용했지만, 대부분의 개발자는 반대 사례를 공유하고 있습니다. 유사 과제에서 Opus 5가 Fable이나 Sol보다 훨씬 더 많은 토큰을 소모한다는 것입니다. 의심되는 부분은 Opus 5의 RL 사전학습이 간결하고 유용하기보다 토큰 비용을 늘리는 방향으로 과도하게 최적화되었다는 점입니다. 비교 외 제 작업에서도 분명 그렇게 느낀 바 있습니다. Opus 계열 모델은 표면적으로 점점 더 장황해지고, 읽기 어려워지고 있습니다.

개인적으로는 대부분의 코딩 프로젝트(클라이언트 작업 포함)에 여전히 Fable 5를 사용할 생각입니다. 장기적으로 정확도에서 승리하기 때문입니다. 저는 최신 Max 요금제인데, 여러 세션에서 Fable을 사용해도 아직 사용 한도에 걸린 적이 없습니다(Claude Code를 내내 돌리지는 않습니다). 토큰 비용이 중요할 때나, 제 이해를 위해 작업 진행에 대한 러닝 코멘터리가 필요할 때 Opus를 사용할 것입니다.

모델과 주변 도구에 대해 더 알아보려면, 전체 Claude Fable 5 가이드와 Claude Code, Claude Code 모범 사례 튜토리얼을 읽어 보시기 바랍니다.