Claude Fable 5와 Mythos 5 재배포: API 운영자가 확인할 위험 신호

Anthropic이 2026년 7월 1일 Claude Fable 5와 Claude Mythos 5 접근을 복구했다고 공지했다. 이 소식은 “모델이 다시 열린다” 정도로 끝낼 일이 아니다. Fable 5와 Mythos 5는 1M context window, 128k max output, adaptive thinking, 새로운 tokenizer, refusal 처리 방식 등 운영자가 반드시 확인해야 할 변화가 많다.

이미 Claude 계열을 API로 쓰고 있다면 이번 재배포는 두 가지 관점에서 봐야 한다. 첫째, 고성능 모델 접근이 다시 가능해지면서 장문 분석·에이전트 작업의 선택지가 늘었다. 둘째, 모델별 제약과 retention 요구사항이 달라졌기 때문에 기존 코드가 그대로 맞지 않을 수 있다.

재배포 소식에서 놓치기 쉬운 부분

Anthropic release notes에 따르면 Fable 5와 Mythos 5는 기본 1M context window와 128k max output token을 지원한다. 장문 문서 분석, 대형 코드베이스 요약, 여러 회의록 통합 같은 작업에서는 매력적이다. 그러나 큰 context window는 공짜가 아니다. 입력이 길어질수록 비용, latency, 실패 복구 난이도가 같이 증가한다.

또 하나 중요한 변화는 adaptive thinking이다. Fable 5와 Mythos 5에서는 adaptive thinking이 핵심 동작 방식으로 소개됐고, 일부 수동 thinking 설정이나 assistant prefill이 제한된다. 예전 모델에서 쓰던 prompting 패턴을 그대로 가져오면 400 에러나 품질 저하를 만날 수 있다.

운영자는 모델을 “더 좋은 Claude”로 보지 말고 “계약이 다른 Claude”로 봐야 한다. context, tokenizer, thinking, retention, refusal, fallback 각각이 기존 모델과 다르게 작동할 수 있기 때문이다.

토큰 증가가 비용에 주는 영향

Fable 5와 Mythos 5는 Claude Opus 4.7 계열에서 도입된 tokenizer를 사용하며, 이전 모델 대비 같은 텍스트가 약 30% 더 많은 토큰으로 계산될 수 있다고 안내됐다. 실제 증가폭은 문서 종류와 언어에 따라 다르지만, 한국어·코드·마크다운이 섞인 입력에서는 반드시 측정해야 한다.

예를 들어 기존 모델에서 100k 토큰으로 처리되던 고객 로그 묶음이 새 tokenizer에서 130k 토큰이 될 수 있다. 1M context window가 있으니 “넣을 수 있다”는 사실은 맞지만, 비용과 latency는 별개 문제다. 특히 max output을 크게 열어두면 입력 토큰 증가와 출력 토큰 증가가 동시에 발생한다.

운영 팁은 간단하다. 모델 교체 전에 token counting API로 대표 샘플을 측정한다. 샘플은 짧은 프롬프트가 아니라 실제 운영 입력이어야 한다. 고객 문의, 코드 diff, PDF 추출 텍스트, 내부 문서, JSON 로그를 따로 재야 한다. 평균만 보면 안 되고 p90, p95 입력 길이도 봐야 한다.

retention과 compliance 체크

Fable 5에는 데이터 retention 요구사항이 있다는 점도 중요하다. Anthropic 문서에는 Fable 5가 30-day data retention을 요구하며 zero data retention에서는 사용할 수 없다고 안내되어 있다. 이건 단순 설정 차이가 아니라 고객 계약과 보안 정책에 걸릴 수 있는 항목이다.

B2B SaaS에서 고객 데이터, 소스코드, 금융 정보, 의료 정보, 내부 전략 문서를 처리한다면 모델 성능보다 retention 정책 확인이 먼저다. “기술적으로 호출 가능하다”와 “계약상 사용 가능하다”는 다르다.

확인해야 할 질문은 다음과 같다.

이 기능이 고객의 비공개 데이터를 포함하는가
고객 계약서에 zero data retention 또는 equivalent 조항이 있는가
모델별 retention 정책을 설정 화면이나 내부 문서에 기록했는가
사용자가 모델을 직접 고를 수 있다면 retention 차이를 안내하는가
로그 저장 기간과 공급사 retention 기간이 충돌하지 않는가

이 질문에 답하지 못하면 Fable 5를 기본 모델로 올리면 안 된다. 먼저 기능별 데이터 등급을 나누고, retention 허용 기능에서만 사용해야 한다.

refusal과 fallback 설계

Fable 5는 safety classifier가 요청과 응답 생성 중에 동작하며, 거절된 경우 Messages API에서 stop_reason이 refusal로 반환될 수 있다. 또한 beta fallback parameter로 거절된 요청을 다른 모델에서 재실행하는 방식도 언급됐다.

여기서 중요한 것은 fallback을 무조건 켜는 게 아니라는 점이다. 거절된 요청이 실제로 부적절한 요청이라면 다른 모델로 우회해서는 안 된다. 반대로 정상 업무인데 classifier가 과하게 막은 경우에는 더 안전한 형식으로 재구성하거나 다른 모델로 재평가하는 절차가 필요하다.

기존 Sonnet 5 마이그레이션과 다른 점

Sonnet 5는 범용 업무 모델로 볼 수 있지만, Fable 5와 Mythos 5는 더 큰 context와 강한 reasoning을 전제로 한 작업에 맞다. 따라서 전환 범위도 다르게 잡아야 한다.

Sonnet 5로는 고객 응답, 문서 요약, 일반 coding assistant를 넓게 처리할 수 있다. Fable 5는 복잡한 리서치, 다단계 계획, 대형 코드베이스 분석, 에이전트 orchestration처럼 “한 번의 실패 비용이 큰 작업”에 쓰는 편이 낫다. Mythos 5는 접근 조건과 용도가 더 제한적일 수 있으므로 내부 평가나 특수 워크로드 중심으로 접근하는 것이 안전하다.

모델 선택을 사용자가 직접 하게 만들 수도 있지만, 대부분의 제품에서는 자동 라우팅이 더 좋다. 사용자는 모델 이름보다 결과 품질과 속도를 원한다. UI에는 “빠른 답변”, “정밀 분석”, “긴 문서 분석”처럼 작업 모드로 보여주고, 내부에서 모델을 매핑하는 방식이 더 이해하기 쉽다.

운영 적용 순서

첫날부터 전체 트래픽을 옮기지 말고 다음 순서로 진행하는 것이 좋다.

먼저 token counting으로 비용 변화를 확인한다. 그다음 retention이 허용되는 기능만 후보로 추린다. 이후 offline evaluation에서 기존 모델과 Fable 5의 결과를 비교한다. 마지막으로 일부 내부 사용자나 관리자 기능에만 붙여서 실제 latency와 refusal 로그를 본다.

평가 항목은 품질만 보면 안 된다. context window가 커지면 입력 준비 코드, chunking 전략, 로그 저장량, 에러 재시도 비용까지 바뀐다. 특히 128k output을 열어둔 상태에서 요약 실패가 반복되면 예상보다 훨씬 큰 비용이 나올 수 있다.

실행 체크리스트

대표 입력 샘플을 token counting API로 재측정한다.
tokenizer 변경으로 토큰이 얼마나 늘어나는지 한국어, 코드, JSON, 문서별로 나눈다.
Fable 5의 30-day retention 요구사항이 고객 계약과 충돌하지 않는지 확인한다.
zero data retention이 필요한 기능에서는 Fable 5 사용을 막는다.
refusal 로그를 일반 4xx/5xx 오류와 분리한다.
fallback은 낮은 위험 업무에만 제한한다.
사용자가 보는 UI는 모델명보다 작업 모드 중심으로 설계한다.

출처: Anthropic Claude Platform release notes 기준.