Claude Fable 5는 단순히 더 큰 모델이 하나 추가된 사건이 아닙니다. Anthropic이 2026년 6월 9일 플랫폼 릴리스 노트에서 공개한 내용의 핵심은 1M token context, 128k max output, adaptive thinking, refusal 처리 방식, 데이터 보존 조건이 한 번에 바뀌었다는 점입니다. 이미 Claude API로 RAG, 문서 분석, 코드 에이전트, 사내 업무 자동화를 운영하는 팀이라면 모델명만 바꿔서 끝낼 문제가 아닙니다. 컨텍스트 비용, 캐시 전략, 거절 응답 처리, 장문 출력 검증까지 같이 손봐야 합니다.
이 글은 “Claude Fable 5를 바로 써도 되는가”, “기존 Opus/Sonnet 기반 파이프라인과 무엇이 다른가”, “실무 개발자가 배포 전에 어떤 체크리스트를 봐야 하는가”에 답합니다. 공식 출처는 Anthropic Claude Platform release notes이며, 6월 15일에는 Claude Sonnet 4와 Claude Opus 4의 retirement도 공지됐습니다. 즉, 신규 모델 검토와 구버전 모델 마이그레이션이 같은 달에 겹친 상황입니다.
Claude Fable 5의 headline은 1M token context window입니다. 긴 계약서 묶음, 대규모 코드베이스, 수십 개 회의록, 제품 로그를 한 번에 넣고 분석하는 사용 사례가 쉬워집니다. 하지만 컨텍스트가 커졌다고 모든 요청에 큰 문서를 때려 넣으면 비용과 지연 시간이 바로 늘어납니다.
더 중요한 변화는 adaptive thinking입니다. Fable 5와 Mythos 5에서는 adaptive thinking이 유일한 thinking mode로 동작하고, thinking: {"type":"disabled"}나 수동 extended thinking budget, assistant prefill이 지원되지 않는다고 문서화됐습니다. 이전 모델에서 “이 요청은 thinking off”, “이 요청은 budget 2,000 tokens”처럼 제어하던 코드는 400 에러를 낼 수 있습니다.
따라서 마이그레이션의 첫 단계는 벤치마크가 아니라 API contract 점검입니다. 요청 payload, 응답 파서, stop_reason 처리, tokenizer 기반 비용 계산, 데이터 보존 조건을 먼저 확인해야 합니다.
큰 컨텍스트가 나오면 “이제 벡터 DB가 필요 없나?”라는 질문이 반복됩니다. 실무 답은 대부분 아닙니다. 1M 컨텍스트는 검색 단계를 완전히 대체하기보다, 검색 결과가 조금 넓게 잡혀도 모델이 맥락을 잃지 않게 해주는 안전판에 가깝습니다.
예를 들어 고객 지원 봇이 400개 문서 중 관련 후보 20개를 가져오는 구조라면, 예전에는 top 5만 넣어야 했고 누락 위험이 컸습니다. 이제는 top 20과 최근 티켓, 정책 변경 내역까지 넣을 수 있습니다. 대신 모든 요청에 전체 문서 저장소를 넣는 방식은 비효율적입니다. 캐시 가능한 고정 지식, 요청별 동적 데이터, 민감정보가 섞인 데이터는 분리해야 합니다.
권장 구조는 세 단계입니다. 첫째, retrieval 단계에서 후보를 좁힙니다. 둘째, 고정 정책이나 제품 매뉴얼은 prompt caching을 고려해 stable prefix로 배치합니다. 셋째, 사용자 질문과 최신 상태만 뒤쪽에 둡니다. 이렇게 해야 긴 컨텍스트의 장점과 캐시 효율을 동시에 얻습니다.
Anthropic은 Fable 5가 Opus 4.7에서 도입된 tokenizer를 사용하며, Opus 4.7 이전 모델 대비 같은 텍스트가 대략 30% 더 많은 token으로 계산될 수 있다고 설명합니다. 이 숫자는 운영팀에게 꽤 큽니다. 월 1억 input token을 쓰던 서비스라면 같은 원문 기준으로 1.3억 token에 가까워질 수 있다는 뜻입니다.
그래서 “모델 단가가 얼마인가”만 보는 계산은 위험합니다. 실제 비용은 다음 공식에 가깝습니다.
마이그레이션 전에는 최소 100~300개의 실제 production prompt를 token counting API로 다시 재야 합니다. 평균뿐 아니라 p95, p99도 봐야 합니다. 긴 컨텍스트 모델에서 비용 폭탄은 평균 요청이 아니라 몇 개의 초대형 요청에서 터지는 경우가 많습니다.
Fable 5는 safety classifier가 요청과 응답 생성 중에 동작하고, 거절 시 Messages API가 stop_reason: "refusal"을 반환합니다. Anthropic 문서에 따르면 output 생성 전 거절된 요청은 과금되지 않으며, beta fallback parameter로 다른 모델 재실행을 시도할 수 있습니다. 또한 stop_details.category에는 cyber, bio, reasoning_extraction 같은 범주가 포함될 수 있습니다.
이 변화는 프론트엔드 문구만 바꾸면 끝나는 문제가 아닙니다. 백엔드는 최소한 다음 상태를 분리해야 합니다.
특히 업무 자동화 에이전트에서는 refusal을 일반 실패처럼 재시도하면 안 됩니다. 같은 요청을 3번 재시도해도 결과가 바뀌지 않을 가능성이 높고, 오히려 비용과 로그 노이즈만 늘어납니다. category별로 사용자에게 수정 요청을 띄울지, 관리자 검토 큐로 보낼지, 다른 모델로 fallback할지를 나눠야 합니다.
Fable 5는 Claude API에서 30-day data retention을 요구하고 zero data retention에서는 사용할 수 없다고 문서화됐습니다. 이 조건은 성능보다 먼저 법무, 보안, 고객 계약에 영향을 줍니다. 금융, 의료, 법률, 공공 데이터처럼 보존 정책이 엄격한 환경에서는 “최신 모델이니까 적용”이 바로 막힐 수 있습니다.
실무에서는 모델 라우팅 표를 만들어야 합니다. 예를 들어 일반 문서 요약은 Fable 5, 민감 고객 데이터는 zero retention을 지원하는 다른 모델, 대량 비동기 처리에는 batch 가능한 모델처럼 나눕니다. 이 표가 없으면 개발자는 기능별로 임의의 모델을 붙이고, 나중에 보안 검토에서 다시 뜯어고치게 됩니다.
stop_reason: refusal과 stop_details.category를 별도 상태로 저장합니다.Claude Fable 5는 긴 컨텍스트와 자동 reasoning을 더 실용적으로 만든 릴리스입니다. 하지만 실무 개발자에게 중요한 결론은 “더 똑똑해졌다”가 아니라 “모델을 호출하는 방식의 전제가 바뀌었다”입니다. 안전하게 쓰려면 모델 교체 PR보다 먼저 요청/응답 계약, 비용 계측, 데이터 보존 정책을 업데이트해야 합니다.