본문으로 건너뛰기
Koding

Claude Fable 5 제대로 쓰는 법 — 엔지니어를 위한 프롬프트·스캐폴딩 실전 가이드

Jaewoo KimJaewoo Kim · 조회 3 · 8분 읽기
목차

Claude Fable 5 이야기가 나오면 "벤치마크가 높다"는 쪽으로만 흐르기 쉬운데, 정작 매일의 에이전트 개발에서 체감되는 변화는 프롬프트와 스캐폴딩(scaffolding: 모델을 움직이는 주변 구조)의 작법이 달라졌다는 점이에요. 구모델(Opus 4.8 등)을 쓰던 감각 그대로 프롬프트를 던지면 오히려 품질이 떨어지는 경우까지 있습니다.

이 글은 Anthropic 공식 문서 Prompting Claude Fable 5를 축으로, 엔지니어가 오늘부터 바로 써먹을 수 있는 포인트만 추려 정리했습니다. 입문용 글은 아니고, Claude Code나 API로 에이전트를 짜고 있다는 전제로 이야기할게요.

Claude Fable 5 엔지니어 가이드

1. 성능을 좌우하는 건 budget이 아니라 effort

먼저, 인터넷에 돌아다니는 "Fable 5는 budget_tokens로 사고량을 4000~6000 정도로…" 같은 해설은 그대로 믿지 않는 게 좋습니다. 공식 문서를 보면 Fable 5는 adaptive thinking(적응형 사고)만 지원하고, 확장 사고의 예산 지정(budget_tokens)은 폐지됐거든요.

대신 지능·레이턴시(응답 지연)·비용의 트레이드오프를 조율하는 주역은 effort(노력도) 파라미터입니다.

  • high를 기본값으로 두는 것이 무난하다. 고민되면 이걸 쓴다.
  • 가장 정밀도가 필요한 작업에만 xhigh.
  • 정형 작업이나 인터랙티브하게 빠르게 돌리고 싶을 때는 medium / low.

재미있는 건, Fable 5는 낮은 effort로도 구모델의 xhigh를 넘어서는 경우가 많다는 점이에요. 그러니 무턱대고 올릴 필요가 없습니다. "태스크는 완료되는데 느리다" 싶으면 일단 effort부터 낮추는 게 정답입니다.

공식 문서 일부에는 xhigh 위에 max 단계도 언급됩니다. effort 단계 명칭은 문서 갱신에 따라 달라질 수 있으니 적용 전에 최신 공식 문서를 한 번 확인하는 것을 권합니다.

한편 높은 effort에서는 요청하지 않은 포맷 정리나 리팩터링까지 손대기 쉽습니다. 이를 억제하려면 동작을 하나씩 금지하는 대신, 짧게 이렇게 한 줄 덧붙이는 것만으로 충분합니다(공식 예시 요약).

버그 수정에 주변 청소는 필요 없다. 원샷 처리에 헬퍼는 필요 없다. 가상의 미래 요건을 위해 설계하지 마라. 동작하는 최소한을 하라.

2. 구모델용 지시는 오히려 "지운다"

여기가 가장 놓치기 쉬운 전환 포인트입니다. Fable 5는 지시 추종(instruction following)이 강화되어 있어, 동작을 하나씩 나열하지 않아도 짧은 한마디로도 대체로 steer(유도)가 됩니다.

뒤집어 말하면, 구모델용으로 잔뜩 쌓아 올린 장대한 프롬프트나 Skill은 Fable 5에서는 오히려 출력 품질을 낮추는 경우가 있습니다. 공식 문서도 "오래된 지시는 재검토하고, 기본 동작으로 충분하면 지우라"고 못 박고 있습니다.

예를 들어 "장황하게 설명하지 마라·불릿을 과도하게 쓰지 마라·PR 설명을 부풀리지 마라…"를 개별로 나열하는 대신, 이렇게 한 문장만 넣어도 같은 효과가 납니다.

결론부터 말하라. 첫 문장은 "무슨 일이 있었는가/무엇을 알았는가"에 답한다. 상세와 이유는 그 뒤에. 읽기 쉬움과 간결함은 별개이며, 읽기 쉬움을 우선한다.

전환 작업 시에는 기존 system 프롬프트와 Skill을 "빼기"의 눈으로 감사하는 것을 추천합니다. 이제는 더하는 것보다 빼는 게 효과를 내는 단계에 들어섰거든요.

3. "사고를 본문에 쓰게 하는" 지시는 지뢰

이건 모르고 있으면 그대로 당하는 부분입니다. Fable 5에는 **안전 분류기(위험한 출력을 판단하는 필터)**가 들어 있고, 그중 하나가 reasoning_extraction(모델 내부 추론의 추출) 카테고리입니다.

즉, "생각한 과정을 본문에 전부 써내라", "reasoning을 응답에 옮겨 적어라" 같은 show-your-thinking 계열 지시는 이 거부 카테고리에 걸리고, 결과적으로 Opus 4.8로의 자동 폴백이 늘어납니다.

추론 과정을 확인해야 한다면 본문에 쓰게 할 게 아니라 adaptive thinking의 thinking 블록을 읽는 게 올바른 방법입니다. 전환 시에는 기존 Skill / system 프롬프트에 "자신의 사고를 설명하라" 계열 지시가 섞여 있지 않은지 한번 점검해 두세요. 은근히 효과가 큽니다.

Fable 5는 raw chain of thought(원시 사고 과정)를 반환하지 않으며, thinking.display 설정이 "omitted"(기본값)일 때는 thinking 필드가 비어 있습니다. 요약된 추론을 받으려면 display: "summarized"를 명시적으로 지정해야 합니다.

4. 장시간 실행을 전제로 스캐폴딩을 재구성한다

Fable 5는 1개 리퀘스트가 수 분~수 시간 돌아가기도 합니다(긴 호흡의 에이전트 운용). 이때 코드 쪽 스캐폴딩이 예전 그대로면 사고가 납니다.

  • 클라이언트의 timeout·streaming·진행 표시를 먼저 고친다. 블로킹으로 기다리는 것을 그만두고, 스케줄 잡 등으로 비동기로 확인하는 구성으로 옮긴다.
  • 진행 상황 "날조" 대책. 장시간 실행에서는 모델이 실제 툴 결과와 어긋나는 진행 상황을 보고할 때가 있다. 공식 문서에 따르면 이렇게 지시했더니 크게 줄었다고 한다.

진행 상황을 보고하기 전에, 각 주장을 이 세션의 툴 결과에 비추어 감사하라. 증거를 가리킬 수 있는 작업만 보고하고, 미검증이면 미검증이라고 명시하라.

  • 임의 액션 억제. 요청하지 않은 메일 초안 작성이나 방어적인 git 브랜치 생성 같은 걸 할 때가 있으므로, 경계를 명시해 둔다.

사용자가 문제를 설명하고 있거나·질문하고 있거나·생각을 소리 내어 말하고 있을 뿐일 때는, 성과물은 "당신의 소견"이다. 소견을 보고하고 멈춰라. 부탁받을 때까지 수정을 적용하지 마라.

5. 병렬 서브에이전트 & 메모리를 적극적으로

Fable 5는 서브에이전트 위임(delegation)을 구모델보다 잘해서 일을 맡기기 쉬워졌습니다.

  • 독립적인 서브태스크는 적극적으로 서브에이전트에 위임하고, 돌려 둔 채 본체는 다음을 진행한다. 오케스트레이터와 서브는 비동기 통신으로. 수명이 긴 서브는 컨텍스트를 이어갈 수 있으므로, 캐시 읽기로 비용과 시간을 줄일 수 있다.
  • 검증은 "자기 비판"보다 "다른 서브에이전트"가 강하다. fresh context(백지 상태의 컨텍스트)의 검증 담당 서브에게, 사양에 비추어 자신의 결과물을 검증하게 하는 것이 공식 권장 방식이다.
  • 메모리 시스템을 갖게 한다. 교훈 1개 = 파일 1개, 앞머리에 요약 1줄. 과거 실행의 배움을 Markdown에 쌓아 참조하게 하면 Fable 5에서는 특히 효과가 크다.

6. 어디에 쓸까: Sonnet과 Fable 5의 역할 구분

모든 걸 Fable 5로 밀어붙이는 건 비용 면에서 손해입니다. 대략적인 판단 기준은 이렇게 잡으면 됩니다.

  • 단일 턴으로 끝난다/5스텝 이하의 작업은 가벼운 모델(Sonnet 등)로 충분하다.
  • 10스텝 이상을 자율로 돌린다/실패의 대가가 크다면 Fable 5.
  • model mixing(추론이 무거운 곳만 Fable 5, 실행·정형화는 가벼운 모델)으로 비용을 크게 낮출 수 있다.

그리고 평가할 때의 철칙이 **"난이도 범위의 '위'에서부터 시험한다"**입니다. 쉬운 태스크만으로 재면 Fable 5를 과소평가하게 되거든요. 사람이라면 몇 시간~며칠 걸리는 작업(대규모 마이그레이션, 여러 단계의 분석, 복잡한 에이전트 플로)에서야말로 진짜 저력이 드러납니다.

7. 안전 분류기에 걸리는 경우가 있다

마지막으로 운용할 때 주의할 점입니다. Fable 5의 안전 분류기는 공격적 사이버보안·생물/생명과학·사고 추출을 대상으로 하고 있습니다. 골치 아픈 건, 양성 작업(평범한 보안 구현이나 유익한 생명과학 처리)도 드물게 걸린다는 겁니다.

대책은 간단합니다. 서버 사이드/클라이언트 사이드에서 Opus 4.8로의 폴백을 설정하고, stop_reason: "refusal"을 잡아서 자동으로 넘깁니다. 이 부분을 미리 짜 두면 간혹 발생하는 거부 때문에 운용이 멈추는 일은 없습니다.

서버 사이드 폴백은 베타 헤더 anthropic-beta: server-side-fallback-2026-06-01과 fallbacks 파라미터로 설정할 수 있고, 실제로 어느 모델이 응답을 서빙했는지는 usage.iterations로 확인합니다. 거부는 HTTP 200으로 돌아오므로 4xx/5xx 기반 모니터링에는 잡히지 않는다는 점에 주의하세요. 또 Claude Code에서는 세션 중 폴백으로 다운그레이드되면 /model로 복귀가 안 되는 사례가 보고되어 있어, 새 세션을 여는 것이 확실합니다.

Fable 5와 Mythos 5는 2026년 6월 12일 미국 수출 통제 지침으로 일시 중단되었다가 7월 1일 접근이 복구되었습니다(원문 공개 시점인 7월 3일은 복구 직후입니다). 복구와 함께 분류기가 조정되어, 이전에는 통과하던 보안 관련 워크로드가 새로 걸리는 사례가 보고되고 있으니 기존 루프를 한번 재점검하는 것이 좋습니다.

정리

Fable 5로 갈아탈 때 핵심을 한 줄로 말하면 **"똑똑해진 만큼, 스캐폴딩과 지시를 '빼기'하라"**입니다.

  • 사고량은 budget이 아니라 effort(budget_tokens는 폐지)
  • 구모델용 과잉 지시·Skill은 오히려 삭제
  • show-your-thinking 계열 지시는 거부에 걸리므로 제거
  • 장시간 실행 전제로 timeout / 비동기 / 진행 감사를 재구성
  • 병렬 서브에이전트와 외부 메모리를 적극 활용
  • Sonnet과 Fable 5를 구분해 쓰고, 평가는 난이도 위에서부터
  • Opus 4.8 폴백을 반드시 준비

"새 모델이니까 지금까지의 프롬프트를 더 쌓자"가 아니라 "똑똑해졌으니까 줄일 수 있다"는 방향으로 발상을 바꾸는 것, 이게 Fable 5를 제대로 쓰는 지름길입니다.

참고

이 글이 도움이 됐다면 추천해 주세요

관련 글

댓글 0