Anthropic이 공개한 Claude Fable 5 프롬프팅 가이드: 강력해진 모델에 맞춰 프롬프트 다시 쓰기

9bow · 7월 3, 2026, 4:30오전

Claude Fable 5 프롬프팅 가이드 소개

Anthropic이 Claude Fable 5와 Claude Mythos 5를 공개하면서, 이 모델을 실제로 잘 쓰기 위한 별도의 프롬프팅 가이드(Prompting Claude Fable 5)도 함께 내놓았습니다. Claude Fable 5 는 이전 모델인 Claude Opus 4.8로는 너무 복잡하거나, 너무 오래 걸리거나, 지시가 모호해서 다루기 어려웠던 문제까지 맡을 수 있도록 설계된 모델입니다. 사람이 몇 시간, 며칠, 심지어 몇 주에 걸쳐 처리하는 종단간(end-to-end) 작업에서 특히 강점을 보입니다.

이 가이드가 흥미로운 이유는, 단순히 "새 기능을 어떻게 쓰는가"를 다루는 문서가 아니기 때문입니다. 오히려 핵심 메시지는 조금 역설적입니다: 모델이 충분히 똑똑해졌으니, 지금까지 촘촘하게 쌓아 올린 지시와 가드레일(guardrail) 중 상당수는 이제 걷어내는 편이 낫다는 내용을 담고 있습니다. 이전 모델을 붙들기 위해 만들었던 장황한 규칙들이 오히려 Fable 5의 성능을 떨어뜨릴 수 있고, 능력이 크게 오른 지금이야말로 프롬프트와 스캐폴딩(scaffolding, 모델을 감싸는 실행 구조)을 원점에서 다시 점검할 좋은 기회라는 이야기입니다.

이 글은 그 가이드를 한국어로 정리하되, 각 권고안이 왜 필요한지, 그리고 Anthropic이 제시한 실제 프롬프트 문구를 함께 담아 여러분이 자신의 에이전트 하네스(harness)나 시스템 프롬프트에 바로 적용할 수 있도록 구성했습니다. 모든 Claude 모델에 공통으로 적용되는 일반 원칙은 Claude 프롬프트 엔지니어링 모범사례에서 이미 다룬 바 있으므로, 이 글은 그 위에 얹히는 Fable 5 고유의 행동 차이에 집중해 보도록 하겠습니다.

한 가지 미리 알아둘 점이 있습니다. Claude Fable 5는 공격적 사이버 보안 기법(익스플로잇, 멀웨어, 공격 도구 제작 등), 생물학 및 생명과학 콘텐츠(실험 방법, 분자 메커니즘 등), 그리고 모델의 요약된 사고 과정(summarized thinking) 추출을 겨냥한 안전 분류기(safety classifier)를 상시 구동합니다. 선의의 보안 연구나 유익한 생명과학 작업도 이 안전장치를 건드릴 수 있으며, 이 경우 요청은 stop_reason: "refusal" 로 반환됩니다. 이런 요청을 자동으로 우회하려면 서버 측 또는 클라이언트 측 폴백(fallback)을 Claude Opus 4.8로 설정하면 됩니다.

능력이 오르면 프롬프트도 다시 짜야 합니다

Anthropic은 Claude Opus 4.8과 비교해 Fable 5가 특히 개선된 영역을 다음과 같이 정리합니다. 각 항목은 단순한 벤치마크 상승이 아니라, 프롬프트를 다시 손봐야 하는 행동상의 변화 와 직결됩니다.

장기 자율성(Long-horizon autonomy): 오랜 시간에 걸쳐 생산적인 출력을 유지하며, 며칠 단위의 목표 지향 실행에서도 길고 복잡한 작업 내내 지시를 잘 붙들고 있습니다.
복잡하고 잘 정의된 문제에서의 첫 시도 정확도(First-shot correctness): 초기 테스터들은 이전이라면 며칠씩 반복해야 했던 시스템을 단일 패스로 구현했다고 보고했습니다.
비전(Vision): 조밀한 기술 이미지, 웹 애플리케이션, 세밀한 스크린샷을 훨씬 높은 정확도로, 그것도 더 적은 출력 토큰으로 해석합니다. 뒤집히거나 흐릿하거나 노이즈가 낀 이미지를 다루기 위해 bash와 crop 도구를 쓰도록 학습되어 있습니다.
엔터프라이즈 워크플로우(Enterprise workflows): 지시를 따르고 범위를 벗어나지 않으면서, 재무 분석, 스프레드시트, 슬라이드, 문서에서 전문가 수준의 결과물을 냅니다.
코드 리뷰와 디버깅(Code review and debugging): 버그 발견 재현율이 Opus 4.8보다 눈에 띄게 높으며, 코드베이스와 저장소 히스토리 전체를 가로지르는 탐색도 포함됩니다.
모호함 헤쳐 나가기(Navigating ambiguity): 복잡하고 여러 갈래로 얽힌 요청을 받고 다음 단계를 스스로 판단해야 할 때 잘 동작합니다.
위임과 협업(Delegation and collaboration): 병렬 서브에이전트(subagent)를 훨씬 안정적으로 파견하고 유지하며, 오래 도는 서브에이전트나 동료 에이전트와의 지속적인 소통도 신뢰성 있게 관리합니다.

이러한 개선을 넘어, Fable 5는 거의 모든 작업에서 이전 모델보다 전반적으로 더 유능합니다. 그래서 Anthropic은 마이그레이션 시점에 "어떤 지시, 도구, 가드레일이 여전히 필요한가" 를 다시 물어보라고 권합니다. 아래에서는 실제로 튜닝이 가장 자주 필요한 행동들을 하나씩 살펴봅니다.

오래 도는 것이 기본값이 되었습니다

Fable 5에서 팀들이 가장 먼저 부딪히는 변화는, 어려운 작업 하나가 몇 분씩 걸릴 수 있다는 점입니다. 높은 노력(effort) 수준에서는 컨텍스트를 모으고, 무언가를 만들고, 스스로 검증하는 과정을 거치느라 개별 요청 하나가 오래 이어질 수 있고, 자율 실행은 몇 시간까지도 확장됩니다.

이는 프롬프트보다 오히려 인프라의 문제입니다. 마이그레이션 전에 클라이언트 타임아웃, 스트리밍, 사용자에게 보이는 진행 표시기를 먼저 조정해야 합니다. 나아가 각 실행이 끝날 때까지 블로킹(blocking)하며 기다리기보다, 예약 작업(scheduled job) 같은 방식으로 실행 상태를 비동기적으로 확인하도록 하네스 구조를 다시 설계하는 편이 좋습니다.

또한 작업이 모호할 때 Fable 5가 과도하게 계획만 세우는 것을 막으려면, 다음과 같은 지시를 시스템 프롬프트에 넣습니다.

When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue in user-facing messages. If you are weighing a choice, give a recommendation, not an exhaustive survey. This does not apply to thinking blocks.

핵심은 "충분히 알면 행동하라" 입니다. 이미 결론 난 사실을 다시 유도하지 말고, 사용자가 이미 내린 결정을 다시 논쟁하지 말며, 추구하지 않을 선택지를 굳이 나열하지 말라는 것입니다. 다만 이 제약은 사용자에게 보이는 메시지에만 적용되고, 사고 블록(thinking block) 내부의 자유로운 탐색은 예외로 둡니다.

노력(effort) 수준을 상황에 맞게 고르기

노력(effort)은 Fable 5에서 지능, 지연 시간, 비용 사이의 균형을 조절하는 가장 핵심적인 손잡이입니다. Anthropic의 권장은 명확합니다. 대부분의 작업에는 high를 기본으로 쓰고, 능력이 특히 중요한 워크로드에는 xhigh를, 일상적인 작업에는 medium이나 low를 씁니다. 중요한 점은, Fable 5는 낮은 노력 수준에서도 잘 동작하며 종종 이전 모델의 xhigh 성능을 넘어선다 는 것입니다. 작업이 완료되긴 하는데 필요 이상으로 오래 걸리거나, 더 빠르고 대화형에 가까운 작업 방식을 원한다면 노력 수준을 낮추면 됩니다.

한 가지 부작용도 있습니다. 일상적인 작업을 높은 노력 수준으로 돌리면, Fable 5는 작업이 요구하는 것 이상으로 컨텍스트를 모으고 깊이 숙고할 수 있습니다. 물론 높은 노력은 훌륭한 검증 행동과 정교한 추론, 가장 엄밀한 결과물을 만들어 내는 장점이 있지만, 요청하지도 않은 정리나 리팩터링(refactoring)까지 하게 되는 경향이 있습니다. 이를 막으려면 다음 지시를 넣습니다.

Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.

버그 하나를 고치는 데 주변 코드까지 청소하지 말고, 일회성 작업에 굳이 헬퍼 함수를 만들지 말라는 취지입니다. "일어날 수 없는 시나리오에 대한 에러 처리를 넣지 말고, 시스템 경계(사용자 입력, 외부 API)에서만 검증하라" 는 원칙은 특히 실무에서 유용합니다.

짧은 지시 한 줄로 행동을 조종하기

Fable 5는 지시 따르기(instruction following) 능력이 충분히 좋아져서, 원하는 행동을 하나하나 이름 붙여 열거하지 않아도 짧은 지시 한 줄로 대부분 조종할 수 있습니다. 예를 들어 별다른 조종이 없으면 Fable 5는 작업이 요구하는 것보다 장황해질 수 있습니다. 추구하지도 않을 선택지를 훑거나, 근본 원인을 길게 설명하거나, 지나치게 구조화된 PR 설명을 쓰거나, 다음 줄이 무슨 일을 하는지 그대로 읊는 주석을 답니다. 이때 패턴을 일일이 나열하는 대신, 다음처럼 간결성 지시 하나만 주면 충분합니다.

Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more.

The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations, arrow chains like A → B → fails, or jargon.

여기서 눈여겨볼 대목은 "읽기 쉬운 것과 간결한 것은 다르며, 읽기 쉬움이 더 중요하다" 는 구분입니다. 출력을 짧게 만드는 올바른 방법은 문장을 조각내거나 약어와 화살표 사슬로 압축하는 것이 아니라, 포함할 내용을 선별 하는 것이라고 못 박습니다.

같은 원리는 오래 도는 워크플로우에서 언제 멈춰야 하는지(checkpoint)에도 적용됩니다. 멈춰야 할 모든 경우를 열거할 필요 없이, 다음 한 문단이면 됩니다.

Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise.

"파괴적이거나 되돌릴 수 없는 행동, 실제 범위 변경, 또는 사용자만이 줄 수 있는 입력" 이 필요할 때만 멈추고, 그 외에는 계속 진행하라는 것입니다. 이 checkpoint 지시는 뒤에서 다룰 조기 종료 문제와 짝을 이룹니다.

긴 자율 실행을 신뢰할 수 있게 만들기

Fable 5의 진짜 가치는 오래 도는 자율 실행에서 나오지만, 바로 그 지점에서 새로운 신뢰성 문제가 생깁니다. 아래 네 가지 패턴은 긴 실행을 실제로 믿고 맡길 수 있게 만드는 안전장치입니다.

진행 상황 주장에는 반드시 근거를

긴 자율 실행에서는 모델이 실제로 한 일과 "했다고 말하는 일"이 어긋날 수 있습니다. Anthropic은 진행 상황을 보고하기 전에 각 주장을 이번 세션의 실제 도구 결과 와 대조하도록 지시하라고 권합니다. 테스트에서 이 지시는 일부러 허위 상태 보고를 유도하도록 설계된 작업에서조차 조작된 보고를 거의 없앴다고 합니다.

Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.

"증거를 가리킬 수 있는 작업만 보고하고, 아직 검증되지 않았으면 그렇다고 명시하라" 는 원칙입니다. 테스트가 실패하면 실패했다고 출력과 함께 말하고, 단계를 건너뛰었으면 건너뛰었다고 말하라는 부분이 특히 중요합니다.

해도 되는 것과 안 되는 것의 경계를 명확히

Fable 5는 이따금 요청하지 않은 행동을 합니다. 요청도 없었는데 이메일 초안을 작성한다거나, 방어적으로 git 브랜치 백업을 만드는 식입니다. 이를 막으려면 무엇을 해야 하고 무엇을 하지 말아야 하는지 명시적으로 정의합니다.

When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one. Before running a command that changes system state (restarts, deletes, config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.

사용자가 변경을 요청한 것이 아니라 문제를 설명하거나 질문하거나 생각을 소리 내어 정리하는 중이라면, 산출물은 "고침"이 아니라 "진단"이라는 점을 분명히 합니다. 시스템 상태를 바꾸는 명령(재시작, 삭제, 설정 편집)을 실행하기 전에는 증거가 정말로 그 행동을 뒷받침하는지 확인하라는 것도 좋은 습관입니다.

이따금 나타나는 조기 종료

긴 세션 깊숙한 지점에서 Fable 5는 드물게, 대응하는 도구 호출 없이 "이제 X를 실행하겠습니다" 같은 의도만 텍스트로 남기고 턴을 끝내거나, 이미 진행할 근거가 충분한데도 허락을 구하려고 멈추는 경우가 있습니다. 대화형이라면 "continue" 나 "go ahead and do it end to end" 한마디면 충분합니다. 하지만 사람이 지켜보지 않는 자율 파이프라인에서는 다음과 같은 시스템 리마인더(system reminder)를 추가합니다.

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking "Want me to…?" or "Shall I…?" will block the work. For reversible actions that follow from the original request, proceed without asking. Offering follow-ups after the task is done is fine; asking permission after already discussing with the user before doing the work is not. Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ("I'll…", "let me know when…"), do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.

이 리마인더의 마지막 문장이 특히 실용적입니다. "턴을 끝내기 전에 마지막 문단을 확인하라. 그것이 계획, 분석, 질문, 다음 단계 목록, 혹은 아직 하지 않은 일에 대한 약속이라면, 지금 도구 호출로 그 일을 하라" 는 것입니다. 앞서 다룬 checkpoint 지시와 함께 쓰면, "언제 멈춰도 되는가"와 "언제 계속해야 하는가"를 양쪽에서 정의할 수 있습니다.

컨텍스트 예산에 대한 불필요한 걱정 줄이기

아주 긴 세션에서 Fable 5는 이따금 새 세션을 제안하거나, 요약해서 넘기겠다고 하거나, 스스로 작업을 줄이려 합니다. 이런 행동은 대개 하네스가 모델에게 남은 토큰 카운트다운 을 보여줄 때 촉발됩니다. 그래서 가능하면 명시적인 컨텍스트 예산 수치를 모델에게 노출하지 않는 것이 좋고, 꼭 보여줘야 한다면 다음 같은 안심 문구를 함께 줍니다.

You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work.

위임과 병렬 서브에이전트

Fable 5는 이전 모델보다 병렬 서브에이전트(subagent)를 훨씬 적극적으로 파견합니다. Anthropic은 서브에이전트를 자주 쓰고, 언제 위임이 적절한지 명시적으로 안내하며, 오케스트레이터(orchestrator)와 서브에이전트 사이의 소통을 각 서브에이전트가 반환될 때까지 블로킹하는 방식보다 비동기 방식으로 하라고 권합니다. 특히 서브태스크(subtask)를 넘나들며 컨텍스트를 유지하는 오래 사는 서브에이전트는 캐시 읽기(cache read)를 통해 시간과 비용을 아끼고, 가장 느린 서브에이전트에 병목이 걸리는 것을 피하게 해 줍니다.

Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context.

"독립적인 서브태스크는 서브에이전트에 위임하고, 그들이 도는 동안 너는 계속 일하라" 는 이 한 문장이 병렬 실행의 핵심입니다. 서브에이전트를 어떻게 설계하고 운영할지에 대한 더 깊은 논의는 커뮤니티의 Claude Code 서브 에이전트 전략 글에서도 다룬 바 있습니다.

이전 실행의 교훈을 기록하는 메모리 시스템 구축

Fable 5는 이전 실행에서 얻은 교훈을 기록하고 다시 참조할 수 있을 때 특히 좋은 성능을 냅니다. 거창한 인프라가 필요한 것도 아닙니다. Markdown 파일 하나만큼 단순한 노트 공간을 마련해 주는 것으로 충분합니다.

Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don't save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong.

파일 하나에 교훈 하나, 맨 위에 한 줄 요약 이라는 구조가 인상적입니다. 정정 사항과 확인된 접근법을 왜 중요했는지와 함께 기록하되, 저장소나 대화 기록에 이미 있는 내용은 저장하지 말고, 새로 만들기보다 기존 노트를 갱신하며, 틀린 것으로 판명된 노트는 삭제하라는 원칙입니다. 이는 사실상 사람이 좋은 개발 노트를 관리하는 방식과 똑같습니다.

이미 쌓인 과거 기록에서 메모리 시스템을 부트스트랩(bootstrap)하고 싶다면, Fable 5에게 지난 세션들을 검토하게 할 수도 있습니다.

Reflect on the previous sessions we've had together. Use subagents to identify core themes and lessons, and store them in [X]. Make sure you know to reference [X] for future use.

에이전트 메모리를 더 본격적으로 구축하는 방법이 궁금하다면, Anthropic이 소개하는 Claude Agent SDK로 에이전트 빌드하기 글이 좋은 출발점이 됩니다.

요청만이 아니라 "이유"를 함께 전하기

Fable 5는 요청 뒤에 깔린 의도를 이해할 때 더 나은 결과를 냅니다. 맥락이 주어지면 모델은 그 작업을 관련 정보와 스스로 연결할 수 있고, 의도를 혼자 추측하지 않아도 됩니다. 여러 워크스트림(workstream)에 걸쳐 일하는 오래 도는 에이전트일수록 이 점이 중요합니다. 다음은 그 맥락을 전달하는 간단한 템플릿입니다.

I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request].

"나는 [누구]를 위해 [더 큰 작업]을 하고 있고, 그들에게는 [이 출력이 가능하게 하는 것]이 필요하다. 그 점을 염두에 두고: [요청]" 이라는 구조입니다. 짧지만, 모델이 요청을 더 큰 그림 안에 배치하도록 돕는 강력한 패턴입니다.

사용자와 소통할 때의 가독성

도구 호출이 많고 작업 컨텍스트가 큰 확장된 에이전트형 대화에서는, Fable 5의 출력이 따라가기 어려워질 수 있습니다. 조밀한 화살표 사슬 축약, 지나치게 깊은 구현 세부, 사용자가 본 적 없는 사고 과정에 대한 언급, 과도하게 기술적인 표현 등이 그렇습니다. 이를 완화하는 소통 스타일 부록(addendum)을 붙입니다.

Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that.

If you've been working for a while without the user watching (overnight, across many tool calls, since they last spoke), your final message is their first look at any of it. Write it as a re-grounding, not a continuation of your working thread: the outcome first, then the one or two things you need from them, each explained as if new. The vocabulary you built up while working is yours, not theirs; leave it behind unless you re-introduce it.

When you write the summary at the end, drop the working shorthand. Write complete sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels you made up earlier. When you mention files, commits, flags, or other identifiers, give each one its own plain-language clause. Open with the outcome: one sentence on what happened or what you found. Then the supporting detail. If you have to choose between short and clear, choose clear.

여기서 핵심 통찰은 "도구 호출 사이의 축약은 네가 소리 내어 생각하는 것이니 괜찮지만, 최종 요약은 그 과정을 전혀 보지 못한 독자를 위한 것" 이라는 구분입니다. 밤새 혹은 수많은 도구 호출에 걸쳐 사용자 없이 일했다면, 마지막 메시지가 사용자가 처음 보는 화면이므로, 작업 흐름의 연속이 아니라 재정향(re-grounding) 으로 써야 한다는 것입니다.

사용자에게 그대로 전달하는 send_to_user 도구 만들기

오래 도는 비동기 에이전트를 운영할 때는, 에이전트가 턴을 끝내지 않고도 사용자에게 반드시 보여야 할 메시지를 정확히 작성된 그대로 노출할 방법이 필요합니다. 생성된 코드 조각이나 초안 같은 산출물, 구체적 수치가 담긴 진행 업데이트, 혹은 루프 도중 사용자가 던진 질문에 대한 직접 답변이 그런 예입니다.

원리는 이렇습니다. 도구의 입력값이 곧 표시할 메시지이고, Claude가 이 도구를 호출하면 여러분의 UI가 그 입력을 그대로 렌더링한 뒤 간단한 확인만 도구 결과로 돌려줍니다. 도구 입력값은 절대 요약되지 않으므로 내용이 손실 없이 도착합니다. 도구 정의는 다음과 같습니다.

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}

주의할 점은, 도구를 정의하는 것만으로는 부족하다는 것입니다. 시스템 프롬프트에 별도의 지시가 없으면 Fable 5는 이 도구를 거의 호출하지 않습니다. 따라서 다음과 같은 유도(elicitation) 문구를 함께 넣어야 합니다.

Between tool calls, when you have content the user must read verbatim (a partial deliverable, a direct answer to their question), call the send_to_user tool with that content. Use send_to_user only for user-facing content, not for narration or reasoning.

반대로, 서술(narration)이나 내부 추론을 이 도구로 흘려보내서는 안 됩니다. 사용자용이 아닌 내용까지 과도하게 호출하면 도구의 목적 자체가 무너집니다.

스캐폴딩 변경 권장사항

마지막으로 Anthropic은 프롬프트 문구를 넘어, 모델을 감싸는 실행 구조(스캐폴딩) 차원의 변경을 권합니다. 아래 네 가지가 마이그레이션 시 가장 중요합니다.

난이도 범위의 최상단에서 시작하세요. 이전 모델에 맡기던 것보다 더 어려운 작업을 골라, Fable 5가 직접 범위를 잡고(scope), 명확화 질문을 던지고, 실행하게 하세요. 쉬운 작업으로만 테스트하면 이 모델의 능력 범위를 과소평가하게 됩니다.
긴 실행 프롬프트에서는 자기 검증을 명시적으로 만드세요. 자기 비판(self-critique)보다는 별도의, 신선한 컨텍스트를 가진 검증자 서브에이전트 가 더 낫다고 합니다. 긴 작업에는 다음처럼 지시합니다. Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.
기존 프롬프트와 스킬을 리팩터링하세요. 이전 모델을 위해 만든 스킬은 Fable 5에게는 종종 지나치게 규범적(prescriptive)이어서 오히려 출력 품질을 떨어뜨립니다. 기본 성능이 더 낫다면 오래된 지시는 걷어내는 것을 고려하세요. Fable 5는 작업 중 배운 것을 바탕으로 스킬을 즉석에서 갱신하는 일도 잘합니다.
Claude에게 자신의 추론을 응답에 재현하라고 지시하지 마세요. 이 항목은 특히 조심해야 합니다. 모델의 내부 추론을 응답 텍스트로 그대로 옮기거나, 받아쓰거나, 설명하라고 지시하는 프롬프트, 스킬, 하네스 지시는 Fable 5에서 reasoning_extraction 거부 범주를 촉발할 수 있고, 그 결과 Claude Opus 4.8로의 폴백이 늘어납니다. 마이그레이션할 때 기존 스킬과 시스템 프롬프트에서 "생각을 보여줘" 류의 지시를 점검하세요. 추론 가시성이 필요하다면, 그 대신 적응형 사고(adaptive thinking)가 제공하는 구조화된 thinking 블록을 읽고, 긴 실행 중 진행 상황은 앞서 소개한 send_to_user 도구로 노출하세요.

핵심 정리: Fable 5 마이그레이션 체크리스트

이 가이드를 관통하는 하나의 원칙은 "모델이 유능해질수록 프롬프트는 짧고 목적 지향적이어야 한다" 는 것입니다. 이전 모델을 붙들기 위해 쌓아 올린 촘촘한 규칙은 이제 짐이 될 수 있습니다. 실무 적용을 위해 요점을 정리하면 다음과 같습니다.

영역	이전 모델(Opus 4.8) 접근	Claude Fable 5 접근
지시 방식	원하는 행동을 하나하나 열거	짧은 의도 지시 한 줄로 조종
실행 시간	대체로 짧은 동기 실행	몇 분에서 몇 시간, 비동기 확인 전제
노력(effort)	항상 최대치	`high` 기본, 일상 작업은 `medium`/`low`로 충분
검증	자기 비판 위주	신선한 컨텍스트의 검증자 서브에이전트
진행 보고	모델의 요약 신뢰	도구 결과 대조 후 근거 있는 보고만
스킬/프롬프트	규칙을 계속 추가	불필요한 규칙을 걷어내며 단순화
추론 노출	자유롭게 재현 요청	재현 지시 금지, `thinking` 블록 활용

Fable 5로의 전환은 단순한 모델 교체가 아니라 하네스와 프롬프트를 다시 설계할 기회 입니다. 실무에서는 타임아웃과 비동기 확인 같은 인프라를 먼저 손보고, 짧은 지시로 행동을 조종하며, 긴 자율 실행에는 근거 기반 보고와 경계 정의라는 안전장치를 두고, 위임과 메모리를 적극 활용하는 순서로 접근하면 시행착오를 줄일 수 있습니다. 그리고 그 첫 단추는, 이전 모델을 붙들기 위해 만든 장황한 규칙을 용기 있게 걷어내는 것입니다.

Prompting Claude Fable 5 원문 가이드

Claude Fable 5 및 Claude Mythos 5 소개

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~