Claude Fable 5 완전 정리 — 재제공 경위부터 장시간 태스크 운용술, 프롬프트 14종 사용법까지

Claude Fable 5는 그냥 "새 고성능 모델 나왔네"로 넘기기엔 정보량이 좀 많은 모델이다.

재제공 경위, Mythos 5와의 차이, Opus 4.8로의 폴백, 이용 한도의 변화, 안전 분류기 강화, 장시간 태스크용 프롬프트 설계, 서브에이전트 운용, 기존 스킬 재점검까지 — 이야기할 게 꽤 있다.

특히 실무 눈높이에서 중요한 건, Fable 5를 "평소의 일문일답을 조금 똑똑하게 해 주는 모델"로 보는 게 아니라 길고 복잡한 작업을 끝까지 밀고 나가기 위한 모델로 보는 것이라고 생각한다.

이 글에서는 Fable 5의 전체 그림을 정리한 다음, 장시간 태스크에서 쓸 때 뭘 바꾸면 좋을지 정리한다. 벤치마크만 구경하고 끝이 아니라, 실제로 프롬프트, 하네스, 스킬, 서브에이전트 설계에 떨어뜨리는 데까지 이야기해 보자.

주로 참조한 것은 Anthropic의 재제공 발표 「Redeploying Fable 5」와 Claude Platform Docs의 「Claude Fable 5 프롬프팅」이다. 이용 한도와 안전 분류기 주변은 바뀔 수 있으니, 실운용 전에 최신 공식 정보도 확인하길.

3줄로 짚고 가자

• Fable 5는 길고 복잡하고 애매함을 품은 엔드투엔드 작업에 강한 모델이다. 짧은 질문만으로 시험하면 값어치를 놓치기 쉽다.
• 한편 높은 effort level 에서는 작업이 길어지고, 과잉 조사, 요구 밖의 정리, 조기 정지, 읽기 힘든 보고가 일어나기도 한다.
• 실무에서는 스코프 제약, 진척 감사, 정지 조건, 서브에이전트 분담, 자기 검증, 메모리 운용을 세트로 설계하는 게 중요하다.

먼저 Fable 5의 자리부터 짚고 가자

Fable 5는 Claude.ai / Claude Platform / Claude Code / Claude Cowork에서 일반 사용자용으로 쓸 수 있는 모델로 정리되어 있다. 한편 Mythos 5는 같은 기반 모델을 공유하면서 제공 범위와 안전책의 취급이 다른, 일부 신뢰 조직용의 자리다.

이번에 헷갈리는 건 "Fable 5", "Mythos 5", "Opus 4.8"이 각자 다른 역할을 갖고 있다는 점이다. 대략 표로 만들면 이렇다.

여기서 착각하면 안 되는 건, Fable 5가 Opus 4.8의 단순한 상위 호환이 아니라는 점이다. Fable 5는 길고 복잡한 태스크에 강한 한편, 안전 분류의 영향을 강하게 받는다. Fable 5에서 차단되는 종류의 의뢰는 Opus 4.8로 돌려지는 경우가 있다.

즉 실무에서는 "Fable 5에 전부 맡기기"보다, 태스크의 성질, 안전 분류, 속도, 비용, 이용 한도를 보고 나눠 쓰는 게 현실적이다.

재제공 경위도 가볍게 보고 가자

Fable 5는 2026년 6월 30일에 수출 규제가 해제되고, 2026년 7월 1일부터 Claude.ai / Claude Platform / Claude Code / Claude Cowork에서 글로벌 제공이 재개됐다는 정리다.

이 이야기는 단순한 제공 재개 뉴스가 아니라, 모델의 안전책, 정부와의 연계, 사이버 보안 주변의 취급과 세트로 이해할 필요가 있다.

큰 흐름은 이렇다.

1. Fable 5와 Mythos 5가 릴리스된다
2. 미국 정부의 수출 규제로 일시적으로 접근이 제한된다
3. 안전책과 분류기의 재점검이 진행된다
4. 2026년 6월 30일에 수출 규제가 해제된다
5. 2026년 7월 1일부터 Fable 5의 제공이 재개된다
6. Mythos 5는 일부 조직·제휴처용으로 다뤄진다

이용자 쪽에서 중요한 건 "쓸 수 있게 됐다"만이 아니다. 안전 분류기가 강해진 상태로 재제공되고 있다는 점이다.

그래서 Fable 5는 고도의 능력을 널리 쓸 수 있는 한편, 통상의 개발이나 디버그 맥락에서도 내용에 따라서는 안전 분류에 걸릴 수 있다. 여기는 뒤에서 자세히 이야기한다.

이용 한도와 과금 보는 법도 중요하다

Fable 5는 이용 한도의 취급도 조금 주의가 필요하다.

내가 정리한 자료에서는, 2026년 7월 7일까지는 Pro / Max / Team / 일부 Enterprise에서 다른 모델과는 별도 한도에 가까운 형태로 주간 이용 상한의 최대 50%까지 쓸 수 있다고 되어 있다. 중요한 건 2026년 7월 7일 이후에 "못 쓰게 된다"가 아니라, 통상의 구독 한도가 아닌 추가 이용 크레딧 중심의 취급으로 옮겨 간다는 점이다.

대략 정리하면 이렇다.

여기는 날짜와 계약 상태에 의존한다. 공개 전이나 도입 전에는 반드시 자기 관리 화면과 공식 정보를 확인하는 편이 좋다.

특히 팀 운용에서는 "고성능이니 전부 Fable 5로 몰자"고 하면 이용 한도와 크레딧 설계가 먼저 막힐 수 있다. 모델 선택은 성능만이 아니라 실행 시간, 이용 한도, 재실행의 용이함까지 넣어 생각해야 한다.

뭐가 강한지 구체적으로 보자

Fable 5의 강점은 짧은 답변의 능란함보다 긴 작업을 놓지 않고 끝까지 끌고 가는 힘에 있다.

자료상 강조되는 능력은 주로 이 언저리다.

• 장기적인 자율성
• 복잡하고 명확하게 사양화된 문제에 대한 초회 정확성
• 밀도 높은 기술 이미지와 스크린샷을 읽는 비전 능력
• 재무 분석, 스프레드시트, 슬라이드, 문서 같은 업무 성과물
• 코드 리뷰와 디버그
• 애매한 의뢰에서 다음 스텝을 판단하는 힘
• 병렬 서브에이전트의 유지와 협조

이걸 실무의 말로 바꾸면, Fable 5는 "대화에서 조금 똑똑하게 답한다"보다 다음 같은 일에서 잘 듣는다.

• 조사하고, 방침을 정하고, 구현하고, 검증하고, 보고한다
• 리포지토리 전체를 읽고 설계상의 문제와 버그를 찾아낸다
• 여러 서브태스크를 병렬로 나누고 결과를 통합한다
• 스크린샷과 웹 UI를 보며 상태를 판단한다
• 기존 프롬프트와 스킬을 지금 모델용으로 재점검한다
• 긴 성과물을 만들며 도중에 자기 검증을 끼운다

거꾸로 말하면, 단순한 치환, 짧은 요약, 자잘한 바꿔 말하기만으로 평가하면 Fable 5의 본령은 보이기 어렵다. 오히려 가벼운 작업에서는 low 나 medium 쪽이 체험으로는 좋은 경우도 있다.

대표 벤치마크는 "방향감"으로 보는 거다

내 자료에는 Fable 5 / Mythos 5와 다른 모델의 대표 벤치마크도 정리되어 있다. 숫자는 공개 전에 최신 소스로 확인해야 하지만, 방향감으로는 코딩, 지식 노동, 비전, 툴 이용, 컴퓨터 조작에서 강하다는 정리다.

대푯값을 추리면 이런 느낌이다.

이 표에서 읽어야 할 것은 "모든 숫자에서 압승"이라는 거친 이야기가 아니다. 오히려 긴 에이전트형 작업, 코드베이스 탐색, 지식 노동, 비전이 낀 작업에서 차이가 나기 쉽다는 점이다.

벤치마크는 어디까지나 입구다. 실무에서는 다음 3가지를 보는 편이 좋다.

1. 그 태스크는 길고 복잡한가
2. 여러 공정을 넘나드는가
3. 자기 검증과 서브에이전트 분담으로 품질이 오르는가

이 셋에 들어맞을수록 Fable 5를 쓸 의미가 나온다.

다만 안전 분류기의 영향은 무시 못 한다

Fable 5에서 중요한 게 안전 분류기의 취급이다.

재제공 후의 Fable 5는 일반 이용용으로 강한 안전책을 넣은 모델로 정리되어 있다. 특히 사이버 보안 주변에서는 안전 쪽으로 기울인 설계다.

여기서 포인트는, "위험한 의뢰만 멈춘다"고 생각하면 어긋난다는 것이다. 안전 쪽으로 넓게 잡는 이상, 방어 목적의 조사나 통상의 개발·디버그로 보이는 의뢰라도 맥락에 따라서는 멈출 수 있다.

실무에서는 이렇게 생각하는 편이 좋다.

• 대상 범위를 쓴다
• 자신이 소유했거나 허가를 받은 환경임을 쓴다
• 방어 목적임을 쓴다
• 실행해 주길 바라는 범위와, 바라지 않는 범위를 쓴다
• 위험한 절차의 구체화를 요구하지 않는다

그래도 통하지 않는 케이스는 있다. 그런 경우에는 무리하게 Fable 5에 밀어 넣기보다, 태스크 나누는 법을 바꾸거나, 추상도를 바꾸거나, Opus 4.8 등 다른 취급이 되는 전제로 워크플로를 설계하는 쪽이 현실적이다.

장시간 태스크에서 제일 달라지는 건 "기다리는 법"이다

Fable 5에서는 어려운 태스크에 대한 1리퀘스트가 길게 달리는 경우가 있다. 특히 높은 effort level 에서는 컨텍스트 수집, 구축, 자기 검증까지 포함해 몇 분씩 움직이는 전제로 봐야 한다.

이건 쓰는 쪽의 설계에도 영향을 준다.

대화 UI에서 그냥 기다리기만 하면 긴 턴은 "느리다"고 느껴진다. 하지만 비동기 잡으로 돌리고, 도중의 진척을 확인할 수 있고, 마지막에 검증 완료된 성과물이 돌아온다면, 긴 턴은 "제대로 일하고 있다"로 바뀐다.

그러니 Fable 5를 본격적으로 쓸 거라면 모델만 갈아 끼우는 게 아니라 다음 설계도 재점검하는 편이 좋다.

• 클라이언트의 타임아웃
• 스트리밍 표시
• 진척 메시지
• 장시간 잡의 재개 방법
• 중간 성과물의 저장처
• 검증 로그 남기는 법
• 사용자에게 확인을 요구할 조건

Fable 5는 길게 움직일 수 있다. 하지만 길게 움직이는 모델에는 길게 움직이게 하기 위한 하네스가 필요하다.

effort level은 작업마다 고르는 거다

Fable 5에서는 effort level 의 구분 사용이 꽤 중요해진다.

높은 effort level 은 검증, 추론, 지시 유지를 강하게 한다. 한편 필요 이상으로 맥락을 모으거나, 부탁하지 않은 정리와 리팩터링으로 번지거나 하는 경우가 있다.

나라면 이렇게 나눠 쓴다.

여기서 중요한 건 x-high 가 항상 정답은 아니라는 것. 가벼운 작업에 높은 effort를 쓰면 작업은 꼼꼼해질지 몰라도 체험으로는 무거워진다. 거꾸로 어려운 작업에 낮은 effort를 쓰면 Fable 5의 장점을 다 못 쓴다.

작업의 무게에 맞춰 effort를 고른다. 이게 기본이다.

프롬프트 설계는 5분류로 생각하면 알기 쉽다

Fable 5용 프롬프트는 세세한 문구를 외우기보다 목적별로 분류하는 편이 쓰기 좋다.

내 자료에서는 P01부터 P14까지의 프롬프트군으로 정리하고 있는데, 이 글에서는 5가지 분류로 정리한다.

1. 나아가게 하기 위한 지시

긴 태스크에서 먼저 필요한 건, 충분한 정보가 있다면 움직여 달라는 지시다.

행동하기에 충분한 정보가 있다면 행동해 주세요. 대화 안에서 이미 확립된 사실을 다시 도출하거나, 사용자가 이미 내린 판단을 되짚거나, 사용자용 메시지에서 추구하지 않을 선택지를 이야기하지 마세요. 선택지를 비교 검토하고 있는 경우에는 망라적인 조사 결과가 아니라 추천안을 제시해 주세요.

이건 "대충 내달려라"는 뜻이 아니다. 이미 충분한 정보가 있는데도 계획이나 선택지 설명에서 멈추는 걸 막기 위한 지시다.

2. 너무 벌리지 않게 하기 위한 지시

높은 effort에서는 필요 이상의 정리와 추상화가 섞이는 경우가 있다. 구현과 수정에서는 스코프를 좁히는 지시가 잘 듣는다.

태스크에 필요한 범위를 넘어 기능 추가, 리팩터링, 추상화 도입을 하지 마세요. 가설상의 미래 요건을 위해 설계하지 말고, 잘 동작하는 가장 단순한 것을 해 주세요.

Fable 5의 능력을 깎기 위해서가 아니라, 능력을 목적으로 향하게 하기 위한 제약이다.

3. 너무 멈추지 않게 하기 위한 지시

장시간 태스크에서는 확인 때마다 멈추면 일이 안 나아간다. 한편 파괴적 조작이나 비가역 조작까지 멋대로 진행돼도 곤란하다. 그러니 멈출 조건을 먼저 정한다.

작업이 정말로 사용자를 필요로 하는 경우에만 정지해 주세요. 파괴적이거나 비가역적인 조작, 실질적인 스코프 변경, 사용자만이 제공할 수 있는 입력이 필요한 경우입니다.

이 지시는 "확인해 주길 바라는 것"과 "맡겨도 되는 것"의 경계를 만들기 위한 것이다.

4. 보고를 신용할 수 있게 만드는 지시

장시간 작업에서는 진척 보고가 붕 뜨면 위험하다. 실제 툴 결과와 확인 완료 사실에 기반해 보고하게 한다.

진척을 보고하기 전에, 이 세션의 툴 결과에 비추어 각 주장을 감사해 주세요. 근거를 제시할 수 있는 작업만 보고하고, 아직 검증하지 못한 것은 명시해 주세요.

이건 꽤 중요하다. 장시간 태스크에서 제일 곤란한 건 안 된 것을 "됐습니다"라고 말하는 것이니까.

5. 마지막을 읽을 수 있는 형태로 만드는 지시

장시간 작업의 마지막에 작업 로그의 연장 같은 보고가 나오면 읽기 힘들다. 최종 보고는 작업을 보지 않았던 독자를 향해 다시 쓰게 한다.

성과부터 시작해 주세요. 종료 후 첫 문장은 "무슨 일이 일어났는가" 또는 "무엇을 알게 됐는가"에 답하는 것으로 해 주세요. 보충 상세와 이유는 그 뒤에 이어 주세요.

짧기보다, 다음에 뭘 하면 되는지 알 수 있는 것을 우선한다. 이게 실무에서는 잘 듣는다.

14개의 프롬프트를 나눠 쓴다면 이렇게

조금 더 세세하게 나눠 쓰고 싶다면 다음 대응표로 생각하면 알기 쉽다.

전부를 매번 넣을 필요는 없다. 오히려 태스크에 맞춰 고르는 게 중요하다.

예를 들어 장시간 자율 실행이라면 P01 + P02 + P05 + P07 + P09 + P12 + P13 이 기본 세트가 된다. 코드 리뷰만이라면 P03 + P05 + P06 으로 충분한 경우가 많다. 기존 스킬 이행이라면 P02 + P08 + P13 + P14 가 잘 듣는다.

서브에이전트 운용은 Fable 5의 강점을 내기 쉽다

Fable 5는 병렬 서브에이전트의 디스패치와 유지가 특기라고 정리되어 있다. 그러니 긴 작업에서는 에이전트 하나에 전부 시키기보다 역할을 나누는 쪽이 안정된다.

나누는 법의 기본은 Planner / Generator / Evaluator다.

이 분담이 잘 듣는 이유는 생성과 평가를 나눌 수 있어서다. 에이전트 하나가 스스로 만들고 스스로 채점하면 아무래도 관대해진다. 평가 역을 나누면 누락과 제약 위반을 줍기 쉬워진다.

다만 서브에이전트는 늘리기만 하면 되는 게 아니다. 각 에이전트에는 다음 정보를 명확히 넘겨야 한다.

• 입력으로 읽을 자료
• 소유하는 파일과 범위
• 출력해 주길 바라는 형식
• 해서는 안 되는 것
• 남의 변경을 되돌리지 않을 것
• 언제 멈춰야 하는가

여기가 애매하면 병렬화한 만큼 사고도 는다. Fable 5가 서브에이전트에 강하다 해도, 오케스트레이션 설계는 인간 쪽 일로 남는다.

메모리와 자기 검증도 세트로 생각하자

Fable 5는 이전 실행에서 얻은 교훈을 기록하고 그걸 참조할 수 있는 경우에 강하다고 정리되어 있다. 이건 거창한 구조가 아니어도 되고, Markdown 파일 같은 단순한 메모라도 의미가 있다.

다만 뭐든 저장하면 되는 건 아니다. 저장한다면 다음 조건을 만족하는 것으로 좁힌다.

• 다음번 이후에도 같은 실패를 피하기 위해 필요하다
• 리포지토리와 대화 이력에 아직 명확히 남아 있지 않다
• 무엇을 고쳤는가뿐 아니라 왜 중요했는가를 알 수 있다
• 잘못임을 알게 되면 삭제하거나 갱신할 수 있다

자기 검증도 마찬가지다. 장시간 작업에서는 마지막에 몰아서 확인하기보다 성과물마다 확인하는 쪽이 무너지기 어렵다.

예를 들면 이렇게 넣어 둔다.

구축하면서 주요 성과물을 하나 만들 때마다 자기 작업을 확인해 주세요. 각 성과물의 완료마다 사양에 비추어 독립된 검증을 해 주세요.

이 "성과물마다"라는 단위가 중요하다. 시간으로 끊기보다 성과물 단위 쪽이 실무에서는 판단하기 쉽다.

기존 스킬은 너무 세세할 가능성이 있다

Fable 5에서 재점검하고 싶은 것이 기존 스킬과 프롬프트의 세세함이다.

종래 모델용으로 만든 스킬은 "순서대로 이걸 하고, 다음에 이걸 하고, 여기서 이렇게 판단하고"라고 축차 절차를 세세히 적은 경우가 많다. 이건 이전 모델에는 필요했을지 모른다. 하지만 Fable 5에서는 너무 세세한 절차가 거꾸로 판단력을 묶어 출력 품질을 떨어뜨리는 경우가 있다.

Fable 5용으로 스킬을 재점검한다면 나는 이 순서로 정리한다.

1. 성과물의 정의를 짧게 쓴다
2. 입력으로 읽어야 할 자료를 명확히 한다
3. 소유 범위와 금지 사항을 명확히 한다
4. 사용자 확인이 필요한 조건만 남긴다
5. 검증 방법을 구체화한다
6. 낡은 축차 절차와 중복된 주의 문구를 깎는다

포인트는 "전부를 지시한다"에서 "경계와 품질 조건을 제시한다"로 옮기는 것이다.

장시간 태스크에 강한 모델일수록 세세한 절차보다 골, 제약, 검증 방법이 잘 듣는다.

실무에서 쓸 거라면 의뢰 템플릿을 갖고 있으면 편하다

마지막으로, 실제로 쓰기 좋은 의뢰 템플릿을 3개 놓아 둔다.

장시간 태스크를 맡길 때

저는 [누구를 위한 것인가]를 위해 [더 큰 태스크]에 임하고 있습니다. 그들에게는 [출력이 가능하게 하는 것]이 필요합니다. 그 점을 감안해서, [리퀘스트].

행동하기에 충분한 정보가 있다면 행동해 주세요. 태스크에 필요한 범위를 넘어 기능 추가, 리팩터링, 추상화 도입을 하지 마세요. 독립된 서브태스크는 서브에이전트에 위임하고, 서브에이전트가 실행하는 동안에도 작업을 계속해 주세요. 진척을 보고하기 전에 이 세션의 툴 결과에 비추어 각 주장을 감사해 주세요. 주요 성과물마다 사양에 비추어 작업을 검증해 주세요.

리뷰만 맡길 때

[리뷰 대상]을 리뷰해 주세요. 성과물은 당신의 평가입니다. 조사 결과를 보고하고 정지해 주세요. 의뢰받기 전까지 수정을 적용하지 마세요. 성과부터 시작하고, 독자의 다음 행동을 바꾸지 않는 상세는 덜어 내 주세요. 결과를 보고하기 전에 이 세션의 툴 결과에 비추어 각 주장을 감사해 주세요.

구현까지 맡길 때

[구현하고 싶은 것]을 구현해 주세요. 행동하기에 충분한 정보가 있다면 행동해 주세요. 태스크에 필요한 범위를 넘어 기능 추가, 리팩터링, 추상화 도입을 하지 마세요. 작업이 정말로 사용자를 필요로 하는 경우에만 정지해 주세요. 완료 후에는 무슨 일이 일어났는지를 첫 문장으로 말하고, 검증된 것과 미검증인 것을 나눠 보고해 주세요.

템플릿은 어디까지나 출발점이다. 실제로는 태스크의 성질에 맞춰 더하고 뺀다. 무거운 작업이라면 서브에이전트와 자기 검증을 더한다. 가벼운 작업이라면 스코프 제약만으로 끝낸다. 리뷰만이라면 "수정하지 않는다"를 명시한다.

정부 연계 이야기는 어떻게 읽으면 되나

Fable 5의 재제공에는 미국 정부와의 관계도 얽혀 있다.

이번 정지·재개는 Anthropic 쪽에서는 건설적인 해결에 이르렀다는 자리매김이다. 다만 이건 "항구 제도가 완전히 굳었다"는 이야기가 아니다. 앞으로의 고성능 모델에 대해 정부와의 사전 평가, 정보 공유, 공동 연구, 공통 기준 만들기를 강화하는 방향으로 기울였다는 이해가 가깝다.

이용자 눈높이에서 여기서 읽어야 할 것은 2가지다.

첫째, 프런티어 모델의 제공은 앞으로 점점 안전 평가와 정부 연계의 영향을 받는다는 것. 모델의 능력이 오를수록 단순한 프로덕트 업데이트로는 끝나지 않게 된다.

둘째, 강력한 모델일수록 "쓸 수 있는가"만이 아니라 "어느 맥락에서 쓸 수 있는가"가 중요해진다는 것. Fable 5의 안전 분류기와 이용 한도 이야기는 그 구체적 예라고 생각한다.

자, 정리해 보자

Claude Fable 5는 길고 복잡한 작업을 자율적으로 진행하는 용도에서 힘을 내기 쉬운 모델이다. 특히 조사, 설계, 구현, 검증, 보고까지 넘나드는 엔드투엔드 작업, 코드 리뷰, 비전이 낀 업무 성과물, 서브에이전트 운용에서 값어치가 나기 쉽다.

한편 사용법을 그르치면 긴 턴, 과잉 작업, 확인 대기, 읽기 힘든 보고, 안전 분류기에 의한 차단이 그대로 운용의 무게가 된다.

실무에서 쓸 거라면 다음 형태를 기본으로 하면 좋다.

• 가벼운 작업에서는 low / medium 도 쓴다
• 장시간 태스크에서는 high / x-high 를 고르고 스코프 제약을 더한다
• 진척 보고는 툴 결과와 확인 완료 사실에 묶는다
• 정지 조건을 먼저 정한다
• Planner / Generator / Evaluator처럼 역할을 나눈다
• 성과물마다 자기 검증을 넣는다
• 기존 스킬은 너무 세세한 절차보다 경계와 검증을 중시해 재점검한다
• 이용 한도와 안전 분류기의 제약을 전제로 워크플로를 짠다

Fable 5는 단순한 작업만으로 시험하면 값어치를 놓치기 쉽다. 기왕 쓸 거라면 길고 어려운 작업을 고르고, 그 대신 경계, 검증, 보고, 서브에이전트 분담을 먼저 갖춰 둔다.

모델이 똑똑해질수록 인간 쪽의 일은 "세세하게 절차를 명령하는 것"에서 "맡길 범위와 검증의 구조를 설계하는 것"으로 옮겨 간다. Fable 5는 그 변화가 꽤 뚜렷하게 보이는 모델이라고 생각한다.