Claude Fable 5, Claude Code는 모델보다 작업 설계가 먼저다

Claude Fable 5를 단순히 “새로 나온 고성능 모델”로 보면 중요한 것을 놓친다. 내가 보기엔 이번 변화의 핵심은 모델 성능보다 개발자가 Claude Code 안에서 일을 나누고, 검증하고, 실패를 회수하는 방식에 있다.

 

공식 이름은 Claude Fable 5다. API ID는 claude-fable-5이고, Claude Code에서는 v2.1.170 이상에서 /model fable 별칭으로 선택할 수 있다. 컨텍스트는 1M, 출력은 128k까지 지원한다. 가격은 100만 토큰 기준 입력 10달러, 출력 50달러다. 숫자만 보면 “큰 컨텍스트와 긴 출력이 가능한 비싼 모델”처럼 보인다. 하지만 개발 워크플로우 관점에서는 이 숫자가 곧 작업 단위의 재설계를 요구한다.

나는 Fable 5를 Claude Code의 기본 모델로 두는 접근을 조심해야 한다고 본다. Fable은 기본값이 아니며, 이 사실이 오히려 중요하다. 모든 작업을 Fable로 밀어 넣는 순간 비용, 보안, 실패 범위, 검증 책임이 한꺼번에 커진다. 좋은 개발자는 더 강한 모델을 쓰는 사람이 아니라, 어떤 작업에 어떤 모델을 태울지 결정하는 사람이다.

Fable 5의 핵심은 “많이 넣고 길게 받는 능력”이다

Fable 5의 스펙에서 먼저 봐야 할 것은 1M 컨텍스트와 128k 출력이다. 이 조합은 단순 질의응답보다 코드베이스 이해, 대규모 리팩터링 계획, 장문 분석, 여러 파일을 넘나드는 설계 검토에 맞다. 기존에는 컨텍스트가 부족해서 파일을 잘라 넣고, 요약을 만들고, 다시 이어 붙이는 삽질이 많았다. Fable 5는 그 일부를 줄여준다.

하지만 컨텍스트가 커졌다고 해서 생각까지 자동으로 정리되는 것은 아니다. 1M 컨텍스트는 잘못 쓰면 거대한 쓰레기통이 된다. 관련 없는 로그, 오래된 문서, 실패한 시도, 중복된 파일을 전부 넣으면 모델은 똑똑해지는 것이 아니라 판단 비용이 커진다. 큰 컨텍스트는 “많이 넣어도 된다”가 아니라 “작업 맥락을 덜 잘라도 된다”에 가깝다.

128k 출력도 마찬가지다. 긴 출력을 받을 수 있다는 것은 장문의 설계서, 마이그레이션 계획, 코드 리뷰 리포트, 테스트 전략을 한 번에 만들 수 있다는 뜻이다. 동시에 잘못된 방향의 긴 답변도 한 번에 받을 수 있다는 뜻이다. 그래서 Fable 5를 쓰는 순간 완료 기준이 더 중요해진다. “잘 분석해줘”가 아니라 “이 기준을 만족하면 완료”라고 못 박아야 한다.

Claude Code에서 Fable은 기본값이 아니다

Claude Code에서 Fable 5는 /model fable로 선택하는 모델이다. 여기서 내가 보는 메시지는 분명하다. Fable은 모든 작업의 기본 엔진이 아니라, 특정 작업에 올리는 고비용 고성능 경로다. 개발자가 해야 할 일은 모델을 바꾸는 명령어를 외우는 것이 아니라, 언제 모델을 올릴지 기준을 세우는 것이다.

내 기준은 단순하다. 작은 수정, 단일 파일 변경, 명확한 버그 수정, 테스트 이름 변경 같은 작업은 굳이 Fable까지 올릴 필요가 없다. 반대로 여러 패키지가 얽힌 리팩터링, 기존 설계의 문제를 찾아야 하는 작업, 긴 이슈 스레드와 코드베이스를 함께 읽어야 하는 작업, 출력물 자체가 장문의 계획서나 검토 리포트인 작업은 Fable 후보가 된다.

내가 쓰는 모델 라우팅 기준

1. 작업 범위가 작은가
- 단일 파일, 명확한 수정, 짧은 diff면 기본 모델이나 더 가벼운 경로로 충분하다.

2. 맥락이 넓은가
- 여러 디렉터리, 과거 의사결정, 긴 문서, 대형 로그가 필요하면 Fable을 고려한다.

3. 출력이 길어야 하는가
- 구현 계획, 마이그레이션 전략, 리뷰 리포트처럼 긴 산출물이 필요하면 Fable의 128k 출력이 의미 있다.

4. 실패 비용이 큰가
- 인증, 결제, 데이터 삭제, 배포 파이프라인처럼 잘못 고치면 위험한 영역은 Fable 단독이 아니라 verifier와 함께 써야 한다.

5. 비용 대비 결과가 남는가
- 한 번의 긴 분석이 팀의 기준 문서나 반복 가능한 워크플로우로 남는다면 Fable 비용은 납득된다.

진짜 변화는 프롬프트가 아니라 작업 설계다

Fable 5를 잘 쓰려면 프롬프트를 길게 쓰는 것보다 작업을 잘게 설계해야 한다. 나는 Claude Code 안에서 작업을 네 단계로 나누는 편이 맞다고 본다. 첫째, 라우터가 작업 유형을 판단한다. 둘째, 구현 에이전트가 제한된 범위에서 변경한다. 셋째, verifier가 테스트와 diff를 검증한다. 넷째, 필요할 때만 Fable로 escalation한다.

이 구조가 중요한 이유는 간단하다. 큰 모델은 실수를 안 하는 존재가 아니라, 더 넓은 범위에서 그럴듯한 판단을 내릴 수 있는 존재다. 그래서 Fable에게 처음부터 모든 것을 맡기면 결과물은 커지지만 통제력은 줄어든다. 반대로 작업 단위를 나누고 검증자를 붙이면 Fable은 “만능 작업자”가 아니라 “고난도 판단 엔진”으로 쓸 수 있다.

Claude Code 워크플로우는 이렇게 바뀐다

요청 수신
→ 작업 분류
→ 기본 모델로 시도
→ 테스트/검증
→ 실패 원인 분류
→ Fable로 escalation
→ 별도 verifier로 재검증
→ worktree에서 안전하게 병합

이 흐름에서 핵심은 Fable을 첫 번째 선택지가 아니라 escalation 경로로 두는 것이다. 기본 모델이 처리할 수 있는 작업은 싸고 빠르게 끝낸다. 실패했거나 맥락이 부족하거나 설계 판단이 필요한 작업만 Fable로 올린다. 이렇게 해야 비용이 통제되고, Fable의 강점이 진짜 필요한 지점에 집중된다.

Subagent와 verifier 없이는 Fable도 위험하다

Claude Code에는 sub-agents 기능이 있다. 이 기능은 Fable 5와 함께 볼 때 의미가 커진다. 큰 모델 하나가 모든 역할을 수행하게 하는 대신, 역할을 나눠야 한다. 구현 에이전트, 리뷰 에이전트, 테스트 에이전트, 문서화 에이전트, 보안 검토 에이전트를 분리하면 모델 성능보다 워크플로우 안정성이 올라간다.

내가 특히 중요하게 보는 것은 verifier다. 구현한 에이전트가 스스로 “완료했다”고 말하는 것은 검증이 아니다. 테스트를 돌리고, diff를 읽고, 요구사항과 완료 기준을 대조하고, 위험한 변경을 표시하는 별도 검증자가 있어야 한다. Fable 5처럼 긴 컨텍스트와 긴 출력을 다루는 모델일수록 verifier의 필요성은 더 커진다.

최소한의 subagent 역할 분리

• Planner

- 작업 범위, 완료 기준, 위험 영역을 정의한다.

• Implementer

- 제한된 파일 범위 안에서 실제 변경을 수행한다.

• Verifier

- 테스트, 타입체크, diff, 요구사항 충족 여부를 확인한다.

• Escalation Agent

- 기본 경로로 해결되지 않는 문제를 Fable로 올린다.

• Observer

- 비용, 실패 패턴, 반복 오류, fallback 빈도를 기록한다.

이 구조를 만들면 Claude Code는 단순한 “AI 코딩 도구”가 아니라 작은 개발 조직처럼 움직인다. 여기서 Fable 5는 가장 비싼 시니어 개발자 역할에 가깝다. 시니어에게 모든 잡일을 맡기지 않듯, Fable에도 모든 작업을 맡기면 안 된다.

Worktree는 선택이 아니라 안전장치다

Fable 5가 긴 맥락을 읽고 큰 변경을 제안할 수 있다는 점은 장점이지만, 동시에 위험이다. 한 번에 많은 파일을 건드리는 작업은 반드시 격리되어야 한다. 나는 Claude Code 워크플로우에서 git worktree를 안전장치로 보는 편이다. 기능별 worktree를 만들고, 모델별 실험을 분리하고, 검증이 끝난 변경만 본 브랜치로 가져와야 한다.

특히 Fable을 쓰는 작업은 “넓은 변경”으로 흐르기 쉽다. 모델이 더 많은 맥락을 이해할수록 더 큰 개선안을 제안한다. 이것 자체는 나쁘지 않다. 문제는 그 변경이 지금 목표와 맞는지, 테스트가 감당하는지, 리뷰 가능한 크기인지다. worktree를 쓰면 실패한 실험을 버리기 쉽고, 성공한 변경만 가져오기 쉽다.

내가 권하는 worktree 운영 방식

main 작업 브랜치
├─ wt/fix-small-bug        기본 모델 작업
├─ wt/refactor-fable       Fable escalation 작업
├─ wt/verifier-check       검증 전용 작업
└─ wt/docs-update          문서화 작업

이런 식으로 나누면 모델 실험이 코드베이스를 더럽히지 않는다. Fable로 큰 리팩터링을 시도했다가 방향이 틀렸다면 worktree를 버리면 된다. 반대로 좋은 결과가 나왔다면 diff를 줄이고, 테스트를 붙이고, reviewer가 이해 가능한 단위로 병합하면 된다.

비용은 토큰 가격이 아니라 운영 방식에서 터진다

Fable 5의 가격은 100만 토큰 기준 입력 10달러, 출력 50달러다. 단순 비교로는 비싸다. 하지만 실제 비용은 모델 단가보다 워크플로우 설계에서 더 크게 갈린다. 같은 1M 컨텍스트라도 정리된 코드 맥락을 넣는 것과 중복 로그를 통째로 넣는 것은 완전히 다르다. 같은 128k 출력이라도 바로 쓸 수 있는 설계 문서를 받는 것과 장황한 일반론을 받는 것은 비용 가치가 다르다.

그래서 나는 Fable 사용 전에 세 가지를 먼저 정해야 한다. 첫째, 이번 호출이 어떤 결정을 내려야 하는가. 둘째, 출력물이 어디에 저장되고 어떻게 재사용되는가. 셋째, 실패하면 어떤 모델이나 절차로 fallback할 것인가. 이 세 가지가 없으면 Fable 호출은 생산성이 아니라 고급형 삽질이 된다.

Fable 호출 전에 정할 것

• 이번 작업의 완료 기준은 무엇인가
• 모델이 읽어야 할 파일과 읽지 말아야 할 파일은 무엇인가
• 출력물이 코드, 계획서, 리뷰, 문서 중 무엇인가
• 결과를 검증할 테스트나 체크리스트가 있는가
• 실패하면 기본 모델로 낮출 것인가, 다른 모델로 돌릴 것인가, 사람 검토로 넘길 것인가
• 비용과 토큰 사용량을 어디에 기록할 것인가

이 기준을 세우면 Fable 5는 비싼 장난감이 아니라 운영 가능한 도구가 된다. 반대로 기준 없이 쓰면 더 긴 답변과 더 큰 diff만 남는다.

보안과 데이터 보존 정책은 워크플로우 안에 넣어야 한다

Fable 5 관련 문서에서 놓치면 안 되는 부분이 데이터 보존과 zero data retention, 즉 ZDR 조건이다. 제공된 사실 기준으로 Fable 5에는 30일 retention이 있고, ZDR은 없다. 이 말은 민감한 코드, 고객 데이터, 내부 비밀, 규제 대상 정보를 다루는 팀이라면 모델 선택을 단순 성능 문제가 아니라 데이터 거버넌스 문제로 봐야 한다는 뜻이다.

여기서 삽질이 자주 생긴다. 개발자는 모델 성능만 보고 붙이고, 나중에 보안팀이나 법무팀이 “이 데이터가 어디에 저장되느냐”고 묻는다. 그때 가서 워크플로우를 뜯으면 늦다. 처음부터 Fable 경로에는 민감 정보 필터링, 로그 마스킹, 파일 범위 제한, 승인 조건을 넣어야 한다.

Fable 경로에 넣어야 할 리스크 관리

• 민감 파일은 기본적으로 제외한다.
• .env, secret, credential, 고객 데이터가 포함된 로그는 전달하지 않는다.
• Fable 호출이 필요한 작업과 금지된 작업을 문서화한다.
• 30일 retention과 no ZDR 조건을 팀의 모델 사용 정책에 반영한다.
• Claude Code 설정만 믿지 말고 실제 입력 파일 범위를 검토한다.
• 결과물에는 보안 변경 사항과 데이터 노출 가능성을 별도 표시한다.

내 판단은 명확하다. Fable 5를 도입하는 팀은 “성능 테스트”보다 “사용 정책”을 먼저 만들어야 한다. 모델이 강해질수록 잘못 넣은 데이터의 의미도 커진다.

Refusal과 fallback은 예외가 아니라 기본 흐름이다

Anthropic 문서에는 refusals and fallback 관련 가이드가 있다. 모델은 특정 요청을 거절하거나, 기대한 대로 응답하지 못하거나, fallback이 필요할 수 있다. 개발 워크플로우에서 이것을 예외 상황으로 보면 자동화가 쉽게 깨진다. 모델이 거절할 수 있다는 사실을 정상 흐름에 넣어야 한다.

예를 들어 보안 취약점 분석, 인증 우회처럼 보일 수 있는 작업, 민감한 코드 변경은 모델이 조심스럽게 반응할 수 있다. 이때 자동화가 “응답 없음”으로 죽으면 안 된다. refusal을 감지하고, 요청을 더 좁히고, 합법적 방어 목적과 검증 범위를 명확히 하고, 그래도 안 되면 사람 검토나 다른 절차로 넘겨야 한다.

fallback 설계는 이렇게 둔다

모델 응답 성공
→ verifier 검증
→ 완료

모델 응답 불충분
→ 프롬프트 범위 축소
→ 재시도

모델 refusal
→ 요청 목적/범위 재정의
→ 허용 가능한 방어적 작업으로 재구성
→ 재시도 또는 사람 검토

모델/서비스 실패
→ 다른 모델 또는 기본 모델로 fallback
→ 실패 로그 기록

이 흐름을 만들면 Claude Code 자동화가 훨씬 단단해진다. 중요한 것은 Fable이 항상 답을 준다는 가정이 아니라, 답을 못 주는 상황에서도 시스템이 다음 행동을 아는 것이다.

GitHub Copilot 지원은 확산 신호다

GitHub는 2026년 6월 9일 changelog를 통해 Claude Fable 5가 GitHub Copilot에서 일반 제공된다고 밝혔다. 이건 단순한 통합 뉴스가 아니다. Fable 5가 Claude Code만의 실험 모델이 아니라, 개발자 도구 생태계 안으로 넓게 들어오기 시작했다는 신호다.

개발자 입장에서는 선택지가 늘어난다. Claude Code에서 /model fable을 쓰는 방식도 있고, GitHub Copilot 경로에서 Fable을 쓰는 방식도 있다. 하지만 도구가 늘수록 더 필요한 것은 공통 운영 기준이다. 어느 인터페이스에서 쓰든 작업 라우팅, 비용 기준, 데이터 정책, verifier, fallback은 동일하게 필요하다.

내가 실제로 설계한다면 이렇게 쓴다

내가 Claude Code에 Fable 5를 붙여 팀 워크플로우를 만든다면, 처음부터 모든 작업을 Fable로 보내지 않는다. 먼저 작업 유형을 나눈다. 작고 반복적인 작업은 기본 모델에 맡긴다. 맥락이 넓고 실패 비용이 큰 작업은 별도 worktree에서 Fable로 올린다. 그리고 결과는 반드시 verifier가 본다.

이 구조의 장점은 비용보다 통제력이다. 모델이 좋아질수록 개발자는 “무엇을 시킬 것인가”보다 “어떤 절차 안에서 시킬 것인가”를 고민해야 한다. Claude Code는 이미 모델 선택, subagent, 설정, 작업 분리 같은 운영 요소를 제공한다. Fable 5는 그 위에 올라가는 고성능 엔진이다.

추천 기본 정책

기본 작업: 기본 모델
긴 맥락 분석: Fable
대규모 리팩터링 계획: Fable + verifier
실제 코드 변경: 제한된 파일 범위 + worktree
보안/민감 데이터 포함 작업: Fable 사용 전 정책 검토
실패/거절 발생: fallback flow로 처리
완료 판단: 모델 응답이 아니라 테스트와 diff 기준

이 정도 기준만 있어도 삽질이 크게 줄어든다. Fable 5를 “더 똑똑한 모델”로만 쓰면 결과는 운에 맡긴다. Fable 5를 “작업 설계의 한 단계”로 넣으면 Claude Code는 훨씬 현실적인 개발 자동화 도구가 된다.

결론: Fable 5를 쓰기 전에 workflow부터 바꿔야 한다

Claude Fable 5의 1M 컨텍스트, 128k 출력, Claude Code /model fable 지원은 분명 강력하다. 하지만 내가 보기엔 이 모델의 진짜 의미는 성능이 아니라 운영 압력이다. 이제 개발자는 더 큰 모델을 고르는 데서 멈추면 안 된다. 작업 라우팅, 완료 기준, escalation, subagent, verifier, worktree, observability, fallback, retention 정책까지 함께 설계해야 한다.

Fable 5는 기본값이 아니다. 그래서 더 좋다. 기본값이 아니라는 사실은 개발자에게 선택 기준을 요구한다. 언제 Fable을 쓰고, 언제 쓰지 않으며, 어떤 위험을 감수하고, 어떤 검증을 붙일 것인지 정해야 한다. 그 기준을 세운 사람에게 Fable 5는 생산성 도구가 된다. 기준 없이 붙인 사람에게는 비싼 자동완성기가 된다.

참고 자료

• Anthropic — Introducing Claude Fable 5 and Claude Mythos 5
• Anthropic — Claude pricing
• Anthropic — API and data retention
• Anthropic — Refusals and fallback
• Claude Code Docs — Model configuration
• Claude Code Docs — Sub-agents
• GitHub Blog Changelog — Claude Fable 5 is generally available for GitHub Copilot