이 기사에서 알 수 있는 것

• 2026년 6월 9일에 공개된 Claude Fable 5 (Mythos 클래스)의 실무적 위치
• API 통합 시 사전에 결정해야 할 거부(Refusal)・폴백(Fallback)・과금・데이터 보유의 경계선 - Claude API / Claude Platform on AWS / Amazon Bedrock에서 달라지는 fallback 및 데이터 보유 처리 방식

정보원은 Anthropic 공식 발표, Claude API release notes, Claude API migration guide, stop reasons 공식 문서, Amazon Bedrock의 Fable 5 모델 카드입니다. 2026년 6월 11일 JST 시점에서 확인할 수 있는 1차 정보만을 사용하였으며, 확인되지 않은 수치나 루머는 포함하지 않았습니다.

이 기사는 Zenn 측에서는 「업무 시스템에 도입하기 전의 경계선」에 집중합니다. TypeScript/Python 구현 예시, Bedrock 경로, platform별 fallback의 세부 체크리스트는 Qiita의 완전판 「Claude Fable 5를 API에 도입하기 전 확인해야 할 7가지 운영 체크리스트」에 집약되어 있습니다.

결론

벤치마크 이야기가 앞서기 쉽지만, 업무 시스템에 구축하는 입장에서 읽어야 할 것은 성능표보다 「운영의 경계선」입니다.

Fable 5와 Mythos 5의 위치

Fable 5는 Opus 클래스 위에 신설된 「Mythos 클래스」 모델로, 모델 문자열은 claude-fable-5입니다.

동일한 기반 모델에서 안전 대책(Safeguard)을 일반 제공용으로 활성화한 것이 Fable 5이며, 사이버 방어 기관 등 한정된 파트너를 위해 일부 해제한 것이 Mythos 5로서 제공됩니다.

공식 문서상의 통합 전제는 다음과 같습니다.

성능 면에서 공식이 강조하는 점은 「태스크가 길고 복잡해질수록 기존 모델과의 차이가 벌어진다」는 점입니다. 공식 발표에서는 Stripe의 대규모 Ruby 코드베이스 이관 사례 등이 소개되었습니다. 짧은 단발성 태스크에서는 Opus나 Sonnet과의 차이가 작을 가능성이 있으며, 후술할 비용을 고려하면 「장시간・자율형 태스크에만 Fable을 할당하는」 라우팅(Routing)이 현실적입니다.

경계선 1: 거부와 폴백을 전제로 파이프라인을 설계하기

Fable 5에는 새로운 분류기(Classifiers)가 부착되어 있어, 특정 영역의 요청을 감지하면 응답 동작이 변합니다. Anthropic 공식 발표에서는 사이버 보안, 생물학・화학, 증류와 관련된 입력에서 일반 사용자용 보호 동작이나 다른 모델로의 전환이 일어날 수 있다고 설명하고 있습니다.

API 문서에서는 Fable 5가 거부한 경우 HTTP 에러가 아니라, Messages API의 성공 응답으로서 stop_reason: "refusal"

라고 설명되어 있습니다. stop_details.category에는 cyber / bio / reasoning_extraction 등의 분류가 들어갈 수 있으며, fallback(폴백) 구현 방법은 Claude API, Claude Platform on AWS, Amazon Bedrock, Vertex AI, Microsoft Foundry에 따라 차이가 있습니다.

즉, 구현 측면에서는 다음 두 가지를 구분하여 처리합니다.

공식 데이터에 따르면 폴백이 발생하지 않는 세션이 95% 이상이라고 하지만, 실무상의 논점은 발생률이 아니라 "Fable 5가 반드시 끝까지 답변한다"라는 전제가 무너졌다는 것입니다.

• 보안 진단 도구 해설, 의존성 패키지 취약점 조사, 의약·화학 계열 도메인 업무 등 정당한 용도에서도 분류기(classifier)에 걸릴 가능성이 있습니다 (공식 측에서도 "무해한 요청을 오탐지할 수 있다"라고 명시하고 있습니다).
• 품질 평가나 회귀 테스트(Regression Test)에서 "Fable 5의 출력"을 비교할 경우, 폴백 발생 여부를 기록하지 않으면 비교가 성립하지 않습니다.
• 사용자용 프로덕트에 통합하는 경우, "응답이 Opus 4.8로 전환될 수 있다"라는 동작을 사양(specification)으로 포함해야 합니다.

최소한 다음 항목을 로그에 남겨야 합니다.

{
"requested_model": "claude-fable-5",
"served_model": "claude-fable-5_or_fallback_model",
...

이 로그가 없으면 품질 비교도, 비용 비교도, 고객에 대한 설명도 모호해집니다. Fable 5를 도입하는 첫 구현은 프롬프트 개선보다 먼저, 거부(refusal)와 폴백(fallback)의 관측부터 시작해야 합니다.

경계선 2: 6월 22일과 6월 23일로 세상이 바뀐다

접근 경로는 단계적입니다.

• API·종량제 Enterprise: 6월 9일부터 전면 이용 가능. $10 per 1M input tokens / $50 per 1M output tokens
• 구독(Pro / Max / Team / 시트형 Enterprise): 6월 9일~22일까지는 추가 비용 없이 이용 가능. 6월 23일에 일단 플랜에서 제외되며, 이후에는 사용 크레딧이 필요함 (용량이 확보되는 대로 플랜 복귀를 목표로 하고 있다고 공식은 밝히고 있습니다)

즉, 구독 사용자에게 지금은 "기간 한정 평가 윈도우(evaluation window)"입니다. 실무에서의 대응 방식은 다음과 같습니다.

• 6/22까지 자신의 대표적인 워크로드(workload)에서 Fable 5와 Opus 4.8을 비교하여, 차이가 발생하는 태스크와 발생하지 않는 태스크를 분류한다.
• 차이가 발생하는 태스크에 대해 API 요금($10/$50) 기준의 비용을 추산한다.
• 6/23 이후에도 계속 사용할 가치가 있는지를 크레딧 구매 전에 판단한다.

"일단 전부 Fable로 전환한다"는 전략은 6/23에 비용 구조가 급변하기 때문에 위험합니다.

간이 추산은 이 식이면 충분합니다.

1회당 개략적 비용 =
input_tokens / 1,000,000 * 10
+ output_tokens / 1,000,000 * 50

예를 들어, 1회의 조사·구현 태스크에서 input 200k tokens, output 20k tokens를 사용한다면 개략적인 비용은 $2 + $1 = $3입니다. 이를 월 100회로 확장하면 약 $300/월이 됩니다. 동일한 양을 Opus 4.8로 돌리면 단가는 대체로 절반 수준입니다.

Fable 5는 "비싸니까 피해야 하는" 모델이 아닙니다. 다만, 짧은 FAQ, 분류, 정형 요약까지 전부 돌리는 모델도 아닙니다.

경계선 3: 30일 데이터 보관이 필수 사항이 된다

간과하기 쉬운 점은 데이터 취급 방식의 변경입니다.

"Mythos-class 모델의 모든 트래픽에 대해, 퍼스트 파티(first-party) 및 서드 파티(third-party) 서피스(surfaces) 모두에서 30일간의 보관을 요구할 것입니다."

일본어 번역: 「Mythos 클래스 모델의 모든 트래픽에 대해, 퍼스트 파티·서드 파티 양측 서피스에서 30일간의 유지를 필수 사항으로 한다"

출처: Claude Fable 5 and Claude Mythos 5 - Anthropic

보관된 데이터는 안전 조치 목적으로만 제한되며, 원칙적으로 30일 후에 삭제된다고 설명되어 있습니다. 하지만 이는 제로 데이터 보관(Zero Data Retention, ZDR)을 전제로 한 운영과 양립할 수 없음을 의미합니다.

• 고객과의 계약이나 개인정보 처리방침(Privacy Policy)에서 "프롬프트는 보관되지 않는다"라고 설명하고 있는 경우, Fable 5를 이용하기 전에 문구 확인이 필요합니다.
• Bedrock에서는 anthropic.claude-fable-5 / global.anthropic.claude-fable-5가 모델 ID로 표시되며, Fable 5 이용을 위해서는 provider data share가 필요합니다. - 사내 기밀 구분에서 "외부 보관 불가"로 분류된 데이터는 Fable 5가 아닌 Opus 이하의 모델로 보내는 라우팅(routing)을 통해 대응합니다.

실무에서의 모델 라우팅

Fable 5를 도입한다면, 모델 선택을 사람의 기분이 아니라 규칙으로 만들어야 합니다.

첫 평가에서는 모든 태스크를 Fable 5로 보내지 않고, 다음과 같은 규칙으로 시작하는 것이 다루기 쉽습니다.

model_routing:
  default: claude-sonnet-4-6
  complex_reasoning: claude-opus-4-8
...

구현 체크리스트

• stop_reason: "refusal"을 HTTP 에러가 아닌 성공 응답으로 처리하고 있는가
• stop_details.category를 로그에 남겨 cyber / bio / reasoning_extraction / null을 구분하고 있는가
• 폴백(fallback) 전략을 Claude API의 fallbacks beta, SDK middleware, client-side retry 중 무엇으로 구현할지 결정했는가
• Amazon Bedrock에서는 fallbacks 파라미터를 전제로 하지 않고, 플랫폼 어댑터(platform adapter) 측의 재시도(retry)로서 설계했는가
• 응답 모델, 거부 이유, 폴백 대상, 과금 대상을 로그에 기록하고 있는가
• 폴백 발생률을 도메인별로 관측할 수 있는가
• 평가 대상 태스크를 6/22까지 Fable 5와 Opus 4.8로 비교했는가
• 6/23 이후의 비용을 $10/$50 per MTok로 시뮬레이션했는가
• 고객 계약 및 개인정보 처리방침과 30일 보관의 정합성을 확인했는가
• Bedrock을 경유할 경우 provider data share 활성화가 필요하다는 점을 운영 절차에 넣었는가
• 기밀 데이터를 Fable 5로 보내지 않는 라우팅 규칙을 정의했는가
• claude-fable-5를 전제로 하여, 1M context / 128k output / adaptive thinking 상시 ON / manual extended thinking budget 미지원 동작을 확인했는가

실패 패턴

1. 벤치마크만 보고 일괄 전환하는 경우

짧은 태스크에서는 기존 모델과의 차이가 작을 가능성이 있으며, 출력 단가는 높은 수준입니다. 장시간·자율형 태스크에 집중하여 할당하지 않으면, 품질 향상을 체감하지 못한 채 비용만 증가할 수 있습니다.

2. 거부(refusal)나 폴백을 "예외"로 취급하는 경우

거부나 Opus 4.8로의 전환은 사양(specification)이지 장애가 아닙니다. HTTP 200과 함께 stop_reason: "refusal"이 반환되는 경로도 있으므로, 일반적인 예외 핸들러(exception handler)만으로는 잡아낼 수 없습니다. 발생을 기록하고, 빈번하게 발생하는 도메인이 있다면 보내는 모델 자체를 재검토해야 합니다.

3. 데이터 보관 방식의 변경을 법무 팀에 공유하지 않는 경우

기술 측면에서만 도입을 판단하면 고객에게 설명하는 내용과 실제 상황이 어긋나게 됩니다. 30일 보관은 모델 선택의 문제가 아니라 계약의 문제이므로, 도입 전에 공유가 필요합니다.

4. 「구독으로 지금 바로 사용 가능」을 운영 환경의 가용성(Availability)으로 착각하는 경우

6/22까지는 평가 윈도우(Evaluation window)로서 유용하지만, 6/23 이후부터는 사용 크레딧(Credit)이 필요하게 됩니다. 업무 시스템에 통합하려면 Claude 앱 상에서의 일시적인 이용 가능 여부가 아니라, API, 과금, 폴백(Fallback), 데이터 보관을 전제로 판단해야 합니다.

요약

Fable 5의 본질은 "Opus보다 똑똑한 모델이 나왔다"가 아니라, "거부(Refusal)·폴백(Fallback)·단계적 제공·30일 보관이라는 새로운 운영 전제를 가진 티어(Tier)가 시작되었다"는 것입니다.

가장 먼저 해야 할 일은 모든 워크로드(Workload)를 Fable 5로 전환하는 것이 아닙니다. 대표적인 태스크를 선정하여 Opus 4.8과 비교하고, 거부와 폴백을 로그(Log)에 남기며, 30일 보관과 계약 내용이 모순되지 않는지 확인하는 것입니다.

이 4가지 사항이 갖춰진 후에야 장시간·고가치 태스크만을 Fable 5로 라우팅(Routing)합니다. 그 단계까지 완료해야 비로소 "최신 모델을 시도해 보았다"가 아니라 "업무 시스템에 도입할 수 있는 형태로 평가했다"라고 말할 수 있습니다.

모델의 구분 사용을 포함한 업무 시스템으로의 AI 도입 설계는 ITPRODX.com에서도 정리하고 있습니다.

API 코드, 플랫폼(Platform)별 폴백(Fallback), Bedrock의 모델 ID와 보관 모드까지 포함하는 구현 체크는, Qiita 완전판인 'Claude Fable 5를 API에 넣기 전에 확인해야 할 7가지 운영 체크리스트'로 나누었습니다. Zenn 측에서는 "무엇을 결정하고 도입할 것인가"를, Qiita 측에서는 "어떻게 구현하고 확인할 것인가"를 역할 분담하여 다룹니다.

참고 링크

Discussion