서론

2026/6/9, Anthropic이 Claude Fable 5 (claude-fable-5)를 일반 제공(GA)하기 시작했습니다. 지금까지 초대제로 운영되었던 Mythos 계열의 능력을 안전장치를 탑재하여 누구나 사용할 수 있도록 만든 모델로, Anthropic은 이를 "일반 제공된 모델 중 가장 고성능"이라고 정의하고 있습니다.

필자도 첫날부터 하루 동안 사용해 보았습니다만, 솔직히 말해 Opus 4.8과의 차이를 "체감"하기는 어려웠습니다. 이 위화감에는 명확한 이유가 있으며, 그것은 Fable 5의 설계 그 자체에서 기인합니다. 본 기사는 그 이유를 기점으로, API를 호출하는 개발자의 시선에서 "Opus 4.8에서 무엇이 바뀌었는가"를 파괴적 변경(Breaking Changes)과 코드를 중심으로 정리합니다.

왜 "하루 동안 써봐도 차이를 모르겠는가"

결론부터 말씀드리면, Fable 5가 Opus 4.8에 대해 가지는 우위는 "어렵고, 장시간이며, 자율적인 태스크"에 집중되어 있으며, 범위가 명확하고 짧은 태스크에서는 양자 간의 차이가 매우 적기 때문입니다.

공개된 벤치마크를 나열해 보면 차이가 발생하는 영역이 명확해집니다.

장시간 에이전트 코딩 (SWE-bench Pro, FrontierCode)에서는 10~16포인트의 차이가 발생하는 반면, 일상적인 "짧은 질문·요약·단발성 구현"에서는 Opus 4.8과 체감 차이가 나기 어렵습니다. 즉, 평소의 사용 패턴을 하루 동안 반복해도 차이가 드러나지 않는 것은 오히려 정상적인 관측 결과입니다.

차이를 끌어내는 조건은 후술하겠지만, 여기서는 "Fable 5는 난제에 대해 첫 수부터 전력을 다할 때 비로소 Opus를 따돌린다"는 점만 기억해 두시기 바랍니다.

기본 스펙과 위치 선정

Opus 4.8이 $5 / $25이므로, 요금은 단순 비교 시 2배입니다. 게다가 후술할 토크나이저(Tokenizer) 변경으로 인해 토큰 수 자체가 늘어나기 때문에, 비용 체감은 그 이상으로 벌어집니다.

참고로 claude-mythos-5라는 동등한 모델이 Project Glasswing을 통해 존재하지만, 능력·요금·API 동작은 Fable 5와 동일하며 ID만 다릅니다. 일반적인 개발자는 claude-fable-5를 사용합니다.

thinking은 생략한다

파괴적 변경 ①: 사고(Thinking)는 상시 ON. Opus 4.7/4.8에서는 thinking을 생략하면 사고 없이 동작했습니다. Fable 5에서는 사고가 상시 켜져 있으며, thinking 파라미터의 취급 방식이 달라집니다.

• thinking을 생략하면 adaptive thinking이 자동으로 적용됨
• {"type": "adaptive"}를 명시해도 됨
• (Opus 4.8에서는 허용되지만 Fable 5에서는 거부) {"type": "disabled"}는 400 에러 발생
• {"type": "enabled", "budget_tokens": N} 역시 400 에러 (budget_tokens는 완전히 폐지됨)

사고의 "깊이"는 thinking이 아니라 output_config.effort로 제어합니다.

import anthropic
client = anthropic.Anthropic()
# 최소 형태: thinking은 쓰지 않는다. 깊이는 effort로 조절한다.
...

effort 선택 방법

effort는 비용·지연 시간(Latency)·지능의 메인 스위치입니다. Anthropic의 권장 사항은 다음과 같습니다.

중요한 점은, Fable 5는 low 설정에서도 이전 세대의 xhigh/max를 상회할 수 있다는 것입니다. 높은 effort 설정으로 인해 "작업에 불필요한 심층 분석이나 리팩토링"을 시작한다면, effort를 낮추는 것이 정답입니다.

파괴적 변경 ②: Protected thinking — 가공되지 않은 사고 과정은 반환되지 않음

Fable 5는 protected_thinking 정책을 가지며, 가공되지 않은 사고 연쇄 (raw chain of thought)는 응답에 일절 포함되지 않습니다. 다만 반환되는 것은 암호화된 블록이 아니라, 일반적인 thinking 블록입니다.

• display: "summarized" → 읽을 수 있는 **요약 (summary)**이 반환됨
• display: "omitted" (기본값, Opus 4.8/4.7과 동일) → thinking 필드는 빈 문자열로 반환됨

두 방식 모두 사고 과정은 실행되며 과금 방식도 동일합니다. display는 표시 여부만 변경할 뿐입니다.

# 사고 요약을 사용자에게 보여주고 싶은 경우
response = client.messages.create(
    model="claude-fable-5",
    ...
)

사고 블록의 왕복 규칙 (멀티턴에서 중요)

동일한 모델로 대화를 지속할 때는, 수신한 thinking 블록을 수정하지 않고 그대로 다시 보내야 합니다.

thinking이 빈 문자열인 블록을 포함하여 그대로 반환하십시오. API가 거부하는 것은 "수정된 블록"이지 "읽기만 한 블록"이 아닙니다. 다른 모델(예: Opus 4.8로 폴백)로 대화를 넘길 경우, Fable 5의 protected thinking 블록은 프롬프트에서 자동으로 제거됩니다. 제거 처리는 과금 전에 이루어지므로 usage.input_tokens가 줄어들 뿐, 사용자가 직접 제거(strip)할 필요는 없습니다.

파괴적 변경 ③: 새로운 토크나이저 — 동일한 내용에서 약 30% 증가

Fable 5는 새로운 토크나이저 (tokenizer)를 채택하고 있어, 동일한 내용이 Opus 계열보다 약 30% 더 많이 토큰화됩니다 (워크로드에 따라 변동 가능). 과금은 토큰 단가 기준이므로, 워크로드를 변경하지 않더라도 이전만으로 비용이 상승할 수 있습니다. 게다가 단가 자체도 2배이므로, 비용 추정치를 반드시 다시 측정해야 합니다.

count_tokens에 model: "claude-fable-5"를 전달하면, 신구 토크나이저 모두에서의 수치가 반환되므로 이전 전에 차이를 측정할 수 있습니다.

resp = client.messages.count_tokens(
    model="claude-fable-5",
    messages=[{"role": "user", "content": open("CLAUDE.md").read()}],
    ...
)

refusal stop reason 및 폴백 (Fallback)

파괴적 변경 ④: Fable 5는 수신된 요청에 대해 안전 분류기 (safety classifier)를 실행하며, 연구 수준의 생물학 및 대부분의 사이버 보안 영역을 대상으로 **거부 (refusal)**할 수 있습니다. 무해한 인접 작업(보안 도구, 생명 과학)에서도 드물게 오탐지가 발생할 수 있으므로, 프로덕션 코드에서는 반드시 핸들링이 필요합니다. Anthropic에 따르면, 이 안전 장치가 작동하는 비율은 평균적으로 세션의 5% 미만입니다.

중요한 점은, 거부는 HTTP 200으로 반환되며, stop_reason: "refusal"이 된다는 것입니다.

content[0]을 무조건적으로 읽는 코드는 작동하지 않게 됩니다.

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=1024,
    ...
)

거부된 요청을 다른 모델로 구제하는 방법은 세 가지가 있습니다. 우선순위 순으로 소개합니다.

fallbacks (권장 · 1회 왕복)

방식 1: 서버 사이드 (server-side) beta 파라미터로 대체 모델을 지정하면, 거부(refusal) 발생 시 API가 동일한 요청 내에서 다음 모델을 실행하여 반환합니다. 클라이언트 측 로직이 필요 없습니다.

response = client.beta.messages.create(
model="claude-fable-5",
max_tokens=1024,
...

포인트:

• beta 헤더는 정확히 지정해야 합니다. 다른 날짜 값일 경우 400 server-side-fallback-2026-06-01 에러가 발생합니다.
• 정책 거부(policy refusal) 시에만 작동합니다. 속도 제한(rate limit), 과부하, 서버 에러 시에는 폴백(fallback)되지 않습니다.
• 한 번 폴백된 대화는 이후의 비스트리밍(non-streaming) 요청에서 약 1시간 동안 폴백 대상으로 고정됩니다 (sticky routing).
• Batches API에서는 거부 시 작동하지만, Bedrock/Vertex에서는 지원되지 않습니다 (이 경우 방식 2 사용).

방식 2: SDK 클라이언트 미들웨어 (Bedrock/Vertex용)

서버 사이드 폴백(server-side fallbacks)을 사용할 수 없는 환경에서는 SDK의 미들웨어를 등록하면, 스트리밍을 포함하여 거부 시 자동으로 재시도(retry)를 수행합니다.

from anthropic import Anthropic, BetaFallbackState, BetaRefusalFallbackMiddleware
client = Anthropic(
middleware=[BetaRefusalFallbackMiddleware([{"model": "claude-opus-4-8"}])]
...

BetaFallbackState는 대화당 1개여야 합니다. 이를 재사용하면 무관한 스레드까지 고정되어 버립니다. TypeScript / Go / C# 도 동일한 API를 제공하며, 각 SDK의 examples/ 디렉토리에 폴백 실례가 있습니다.

방식 3: 수동 재시도 + fallback credit (생 HTTP용)

stop_reason으로 거부를 감지하고, 대화를 그대로 다른 모델(예: claude-opus-4-8)로 재전송합니다. Fable 5의 protected thinking 블록은 다른 모델 측에서 조용히 무시되므로, 별도의 제거(strip) 작업이 필요 없습니다. fallback-credit-2026-06-01 헤더를 추가하면 재전송 시 캐시 쓰기 비용이 경감됩니다. 자세한 내용은 마이그레이션 가이드의 refusal 섹션을 참조하세요.

파괴적 변경 ⑤: 30일 데이터 보존 필수 (ZDR 불가)

사소해 보이지만 운영에 큰 영향을 미치는 차이점입니다. Fable 5는 제로 데이터 보존 (ZDR, Zero Data Retention) 모드에서는 사용할 수 없습니다. 안전 분류기(safety classifier) 운영을 위해 프롬프트와 출력값의 보존이 필요하기 때문입니다. 조직의 데이터 보존 설정이 30일 미만이라면, 정상적인 페이로드라도 모든 요청이 400 invalid_request_error가 됩니다.

# 마이그레이션 직후 원인 불명의 400 에러가 발생한다면, 먼저 조직의 데이터 보존 설정을 의심하십시오.
400 invalid_request_error

Opus 4.8은 ZDR이 가능하므로, 컴플라이언스 요건으로 ZDR이 필수인 조직은 애초에 Fable 5를 사용할 수 없다는 점에 주의해야 합니다. 이는 '선택의 문제'가 아니라 '사용 가능 여부'의 경계선입니다.

어시스턴트 prefill 불가

Opus 4.6 이후와 마찬가지로, 마지막 어시스턴트 턴에 대한 prefill은 400 에러를 유발합니다. JSON 등의 출력 형식을 강제하고 싶다면 output_config.format (structured outputs) 또는 시스템 프롬프트 지시사항으로 대체해야 합니다.

response = client.messages.create(
model="claude-fable-5",
max_tokens=1024,
...

"차이를 끌어내기" 위한 구현 패턴

서두에서 언급한 "차이를 느끼지 못하는" 문제에 대한 해답입니다. Fable 5의 진가는 난제에 대해 첫 수부터 전력을 다할 때 나타납니다. Anthropic의 마이그레이션 가이드에서 제시하는 전제 조건을 구현에 적용하면 다음과 같습니다.

1. 첫 번째 턴에 태스크 전체를 전달하고, high~xhigh 설정으로 실행

정보를 조금씩 나누어 전달하면 성능과 효율이 모두 떨어집니다. 모호하거나 과소 지정된 프롬프트를 여러 턴에 걸쳐 전달하는 것은 Fable 5에서 오히려 역효과를 냅니다. 목표, 의도, 제약 사항을 첫 번째 턴에 모두 집약하십시오.

response = client.messages.create(
model="claude-fable-5",
max_tokens=64000, # High effort(高 effort)에서는 넉넉하게
...

2. 1개 요청이 몇 분에서 15분간 실행되는 것이 정상

난도가 높은 태스크에서는 단일 요청이 몇 분 동안 실행됩니다 (컨텍스트 수집 → 구축 → 자기 검증). 타임아웃(Timeout), 스트리밍(Streaming), 진행 상황 UI를 전제로 설계하여, 블로킹(Blocking)되지 않고 비동기적으로 체크인하는 구조로 만들어야 합니다.

# 큰 max_tokens는 반드시 스트리밍 사용 (비스트리밍은 HTTP 타임아웃 리스크가 있음)
with client.messages.stream(
model="claude-fable-5",
...

3. 과도한 가이드 프롬프트는 오히려 품질을 저하시킴

이전 세대용인 "단계를 일일이 지시하는" 스캐폴딩(Scaffolding)은 Fable 5에서 출력 품질을 떨어뜨립니다. 마이그레이션 시에는 기존의 세세한 프롬프트를 제거하고 A/B 테스트를 수행하는 것을 권장합니다. 목표와 제약 사항만 전달하고, 절차를 나열하는 방식은 지양해야 합니다.

4. 장시간 실행의 안정화에 효과적인 시스템 프롬프트

마이그레이션 가이드에서는 구체적인 system 프롬프트 조각을 권장하고 있습니다. 대표적인 예시를 의역하여 나열합니다 (그대로 사용하기보다 워크로드에 맞춰 조정하는 것을 권장).

과도한 계획 억제: "행동할 수 있는 정보가 갖춰지면 행동한다. 이미 확정된 사실을 재도출하거나, 선택하지 않을 선택지를 나열하지 않는다" -
불필요한 뒷정리 금지: "태스크가 요구하지 않은 기능 추가, 리팩토링(Refactoring), 추상화는 하지 않는다. 버그 수정 시 주변 환경을 정리할 필요는 없다" -
진행 상황 주장 검증: "진행 상황을 보고하기 전에, 각 주장을 이 세션의 도구(Tool) 결과와 대조한다. 검증되지 않았다면 그 사실을 명시한다" -
경계 명시: "사용자가 문제를 설명, 질문, 혹은 생각을 정리하는 중이라면, 결과물은 '당신의 평가'이다. 수정 요청을 받기 전까지는 적용하지 않는다"

계승되는 것 (변하지 않는 점)

Messages API와 도구(Tool) 사용 패턴은 Opus 계열과 동일합니다. 다음은 Fable 5에서도 그대로 사용할 수 있습니다.

output_config.effort ( low ~ max )

• Task Budgets (beta task-budgets-2026-03-13)
• Compaction (beta compact-2026-01-12)
• 메모리 도구, context editing을 통한 도구 결과 삭제
• 고해상도 비전 (Opus 4.7+와 동일하게 긴 변 2576px까지 지원)

마이그레이션 체크리스트 (Opus 4.8 → Fable 5)

구현을 옮길 때의 필수 항목 ([필수]는 누락 시 400 에러 등으로 실패함)과 권장 항목 ([조정]).

• [필수] 모델 ID를 claude-fable-5로 변경
• [필수] thinking={"type":"disabled"} 삭제 (Fable 5에서는 400 에러 발생)
• [필수] thinking={"type":"enabled","budget_tokens":N} 삭제하고, 깊이는 effort로 제어
• [필수] 어시스턴트 프리필(Assistant prefill)을 구조화된 출력(Structured outputs) 또는 시스템 지시사항으로 대체
• [필수] 조직의 데이터 보유 기간이 30일 이상인지 확인 (ZDR인 경우 모든 요청이 400 에러 발생)
• [필수] content를 읽기 전에 stop_reason == "refusal" 분기 처리. 폴백(Fallback) 전략(방식 1~3) 중 하나를 선택
• [조정] 토큰 수, 컨텍스트 예산, max_tokens, 비용을 재측정 (count_tokens는 신구 모델 모두 지원)
• [조정] 추론 과정을 UI에 표시하려면 display: "summarized"를 명시
• [조정] 몇 분 단위의 턴을 전제로 타임아웃, 스트리밍, 진행 상황 UI를 준비
• [조정] low/medium을 포함하여 effort를 스윕(Sweep) 테스트. High effort에서 불필요한 뒷정리가 발생하면 억제 프롬프트 추가
• [조정] 이전 모델용 과도한 스캐폴딩을 제거하고 A/B 테스트 수행

요약: 언제 Fable 5를 사용할 것인가

• Fable 5가 효과적인 경우: "어렵고・장시간・자율적인" 태스크 — 장시간 에이전트 코딩 (Agentic Coding), 심층 분석, 프론티어 과학. 첫 단계부터 전력(full spec + high/xhigh)을 다해 던졌을 때 Opus를 앞지릅니다.
• 범위가 명확하고 짧은 태스크에서는 Opus 4.8과 거의 대등 — 게다가 비용은 절반이며, ZDR(Zero Data Retention)이 가능합니다. 일상적인 용도라면 Opus 4.8로도 충분합니다. - 현명한 운영 방법은:
  태스크별 라우팅 (Routing): 어려운 구간은 Fable 5, 그 외에는 Opus 4.8을 사용합니다. - API 레벨에서는 "상시 사고(Thinking Always ON) / 보호된 사고 (protected thinking) / 새로운 토크나이저 (New Tokenizer) / 거절 (Refusal) 분기 / 30일 보관 필수"의 5가지가 Opus 4.8과의 구현상의 주요 차이점입니다.

"하루 정도 써봐서는 차이를 모르겠다"는 것은 정확한 관찰이었습니다. Fable 5는 사용자가 진심 어린 난제를 던졌을 때 비로소 진심으로 응답하는 모델입니다.

참고

Discussion