Claude Fable 5 프롬프팅
Claude Fable 5 프롬프팅 (Prompting Claude Fable 5)
이 문서는 Claude Fable 5와 Claude Mythos 5에 특화된 프롬프팅 및 스캐폴딩 패턴을 다루는 가이드예요. effort, 지시 이행, 장기 실행, 메모리, 스캐폴딩 변경을 중심으로, 이 모델들이 이전 모델과 어떻게 다르게 동작하는지와 어떤 프롬프트 조정이 도움이 되는지 설명해 드릴게요. 특히 장기 자율 실행에서 기대하는 행동을 끌어내는 패턴들을 차근차근 살펴볼게요.
출처: 문서
본문
이 가이드는 Claude Fable 5와 Claude Mythos 5에 특화된 프롬프팅·스캐폴딩 패턴을 다뤄요. 모델의 기능, API 변경, 가격, 가용성은 Claude Fable 5와 Claude Mythos 5 소개를, 모든 현재 Claude 모델에 적용되는 기법은 프롬프트 모범 사례를 참고하세요.
Claude Fable 5는 이전 모델들에게는 너무 복잡하거나, 오래 걸리거나, 모호했던 문제를 맡아요. 특히 사람이 몇 시간, 며칠, 몇 주 걸리는 엔드투엔드 작업에 탁월해요. 최상의 결과를 보는 팀들은 Claude Fable 5를 가장 어려운 미해결 문제에 적용해요. 더 단순한 워크로드에서만 테스트하면 그 능력 범위를 과소평가하는 경향이 있어요. 더 간단한 과제에서도 안정적으로 동작해요.
Claude Fable 5는 Claude Opus 4.8과 몇 가지 행동 차이가 있어서 프롬프트나 스캐폴딩 업데이트가 필요할 수 있어요. 이 수준의 능력 향상은 어떤 지시·도구·가드레일이 여전히 필요한지 재평가하기 좋은 계기이기도 해요. 아래 패턴들은 조정이 가장 자주 필요한 행동들을 다룹니다.
Claude Fable 5는 공격적 사이버 보안 기법(익스플로잇, 악성코드, 공격 도구 구축 등), 생물학·생명과학 콘텐츠(실험실 방법, 분자 메커니즘 등), 모델의 요약된 thinking 추출을 타겟으로 하는 안전 분류기를 실행해요. 무해한 사이버 보안 작업과 유익한 생명과학 과제도 이 안전장치를 트리거할 수 있어요. 거부된 요청을 자동으로 라우팅하려면 서버 측 또는 클라이언트 측 폴백을 Claude Opus 4.8로 구성하세요.
능력 향상 (Capability improvements)
Claude Opus 4.8과 비교해 Claude Fable 5는 다음에서 향상을 보여요:
- 장기 자율성(Long-horizon autonomy). Claude Fable 5는 긴 시간 동안 생산적인 출력을 유지하며, 길고 복잡한 과제에서 강력한 지시 유지를 갖춘 수일 걸리는 목표 지향 실행을 완료해요.
- 복잡하고 잘 명시된 문제에 대한 첫 시도 정확도. 초기 테스터들은 이전에 며칠의 반복이 필요했던 시스템의 단일 패스 구현을 보고했어요.
- 비전(Vision). Claude Fable 5는 밀도 높은 기술 이미지, 웹 애플리케이션, 상세 스크린샷을 훨씬 높은 정확도로 해석하며, 종종 더 적은 출력 토큰을 사용해요. 뒤집히거나 흐리거나 노이즈 있는 이미지를 다루기 위해 bash와 크롭 도구를 사용하도록 훈련되어 있어요.
- 엔터프라이즈 워크플로. Claude Fable 5는 지시를 따르고 범위를 유지하며 재무 분석, 스프레드시트, 슬라이드, 문서에서 전문가 수준의 출력을 내요.
- 코드 리뷰와 디버깅. 버그 발견 회상률(안전 분류기가 다루는 사이버 보안 도메인 밖)이 Claude Opus 4.8보다 눈에 띄게 높아요. 코드베이스와 저장소 기록에 걸친 검색도 포함해요.
- 모호성 탐색. Claude Fable 5는 복잡하고 다중 스레드인 요청을 받고 다음 단계를 결정하라고 요청받았을 때 잘 동작해요.
- 위임과 협업. Claude Fable 5는 병렬 하위 에이전트를 파견하고 유지하는 데 훨씬 더 신뢰할 수 있고, 장기 실행 하위 에이전트와 피어 에이전트와의 지속적 커뮤니케이션을 안정적으로 관리해요.
이 특정 향상 외에도 Claude Fable 5는 거의 모든 과제에서 이전 모델보다 일반적으로 더 유능해요. Claude Fable 5는 공격적 사이버 보안이나 생물학·생명과학 작업용이 아니에요. 그 도메인의 요청은 stop_reason: "refusal"을 반환할 수 있어요.
기본적으로 더 긴 턴 (Longer turns by default)
어려운 과제의 개별 요청은 더 높은 effort 설정에서 수 분 동안 실행될 수 있고, 특히 과제가 컨텍스트 수집, 구축, 자기 검증을 요구할 때 그렇죠. 자율 실행은 몇 시간까지 연장될 수 있어요. 이는 팀이 Claude Fable 5에 적응하며 만나는 가장 큰 변화 중 하나예요. 마이그레이션 전에 클라이언트 타임아웃, 스트리밍, 사용자 대상 진행 표시기를 조정하고, 하네스를 재구성해 스케줄된 작업처럼 비동기로 실행을 확인하는 것(블로킹 대신)을 고려하세요. 과제가 모호할 때 Claude 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.
모든 effort 수준 고려하기 (Consider all effort levels)
Effort는 Claude Fable 5에서 지능·지연·비용의 트레이드오프를 위한 주요 제어 수단이에요. 대부분의 과제에는 high를 기본으로, 가장 능력 민감한 워크로드에는 xhigh, 일상 작업에는 medium이나 low를 사용하세요. Claude Fable 5의 낮은 effort 설정도 여전히 잘 동작하고 종종 이전 모델의 xhigh 성능을 초과해요. 과제가 완료되지만 필요한 것보다 오래 걸리거나, 더 빠르고 상호작용적인 작업 스타일을 원한다면 effort를 줄이세요.
일상 작업에서 더 높은 effort로는 Claude Fable 5가 과제가 필요한 것보다 컨텍스트를 모으고 숙고할 수 있어요. 동시에 더 높은 effort는 종종 훌륭한 검증 행동, 정교한 추론, 가장 엄격한 출력을 만들어요. 더 높은 effort에서 요청하지 않은 정리나 리팩터링을 막으려면:
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.
강력한 지시 이행 (Strong instruction following)
지시 이행이 충분히 개선되어 각 행동을 이름으로 열거하기보다 짧은 지시 하나로 대부분의 행동을 이끌 수 있어요. 예를 들어 이끌지 않으면 Claude Fable 5는 과제가 필요한 것보다 부풀릴 수 있어요. 특히 더 높은 effort 설정에서요. 추구하지 않을 옵션을 조사하고, 근본 원인을 길게 설명하고, 지나치게 구조화된 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.
같은 것이 장기 실행 워크플로의 체크포인트 행동에도 적용돼요. Claude Fable 5가 진짜로 필요할 때만 멈추게 하려면 모든 경우를 열거할 필요가 없어요:
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.
장기 실행 중 진행 주장 근거 세우기 (Ground progress claims during long runs)
긴 자율 실행에서 Claude 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.
경계를 명시하기 (State the boundaries)
Claude Fable 5는 때로 요청되지 않은 행동(아무도 요청하지 않았는데 이메일 초안 작성, 방어적 git 브랜치 백업 만들기)을 할 수 있어요. Claude Fable 5가 해야 할 것과 하지 말아야 할 것에 대한 명시적 제약을 정의하세요:
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.
병렬 하위 에이전트 (Parallel subagents)
Claude Fable 5는 이전 모델보다 더 쉽게 병렬 하위 에이전트를 파견해요. 하위 에이전트를 자주 사용하고, 위임이 적절한 때에 대한 명시적 안내를 제공하며, 각 하위 에이전트가 반환할 때까지 블로킹보다 오케스트레이터와 하위 에이전트 사이 비동기 통신을 선호하세요. 하위 과제 전반에 걸쳐 컨텍스트를 유지하는 장수 하위 에이전트는 캐시 읽기를 통해 시간과 비용을 아끼고 가장 느린 하위 에이전트에서 병목을 피해요.
Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context.
메모리 시스템 구축하기 (Construct a memory system)
Claude Fable 5는 이전 실행의 교훈을 기록하고 참조할 수 있을 때 특히 잘 동작해요. 메모리 파일처럼 단순한 메모를 쓸 장소를 제공하세요:
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.
기존 기록에서 메모리 시스템을 부트스트랩하려면 Claude 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.
드문 조기 종료 (Rare cases of early stopping)
긴 세션이 깊어지면 Claude Fable 5는 때로 해당 도구 호출을 내지 않고 텍스트만으로 의도 진술("I'll now run X")로 턴을 끝내거나, 진행할 충분한 정보가 있는데 허락을 구하려 멈출 수 있어요. "continue" 또는 "go ahead and do it end to end"면 충분해요. 멈추는 것이 적절한 때를 정의하려면 강력한 지시 이행의 체크포인트 지시와 짝을 이루세요. 자율 파이프라인에는 시스템 리마인더를 추가하세요:
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.
드문 컨텍스트 예산 우려 (Rare cases of context-budget concern)
매우 긴 세션에서 Claude Fable 5는 때로 새 세션을 제안하거나, 요약 후 인계하겠다고 제안하거나, 자기 작업을 정리할 수 있어요. 이는 하네스가 남은 토큰 카운트다운을 모델에 보여줄 때 가장 자주 트리거돼요. 가능하면 명시적 컨텍스트 예산 수를 노출하지 마세요. 하네스가 보여줘야 한다면 안심시키는 말이 도움이 돼요:
You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work.
요청뿐 아니라 이유를 주세요 (Give the reason, not only the request)
Claude Fable 5는 요청 뒤의 의도를 이해할 때 더 잘 동작하는 경향이 있어요. 컨텍스트가 과제를 관련 정보에 연결하게 해서 의도를 스스로 추론하지 않게 하거든요. 왜 묻는지의 컨텍스트를 제공하세요. 특히 여러 작업 스트림을 활용하는 장기 실행 에이전트에서요:
I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request].
사용자와 소통할 때의 가독성 (Readability when communicating with the user)
확장되거나 에이전트적인 대화(많은 도구 호출, 큰 작업 컨텍스트)에서 Claude Fable 5는 따라가기 어려운 텍스트를 만들 수 있어요. 밀도 높은 화살표 체인 약어, 깊은 구현 세부사항, 사용자가 본 적 없는 thinking에 대한 참조, 지나치게 기술적인 표현. 커뮤니케이션 스타일 부록이 이를 완화해요:
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.
사용자에게 보내는 도구 만들기 (Create a send-to-user tool)
길고 비동기적인 에이전트를 실행할 때, 턴을 끝내지 않고 사용자가 정확히 그대로 봐야 하는 메시지를 표시하는 방법을 에이전트에 주세요. 산출물(생성된 코드 스니펫이나 초안 메시지), 특정 숫자가 있는 진행 업데이트, 또는 루프 중간에 사용자가 한 질문에 대한 직접 답변. 도구의 입력은 표시할 메시지이고, 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"]
}
}
UX가 과제 중간에 콘텐츠나 직접 사용자 상호작용을 그대로 전달하는 데 의존할 때마다 이 도구를 추가하세요. 일상 진행만 내레이션하는 에이전트에는 모델의 자체 요약이 보통 충분해요. 도구를 정의하는 것만으로는 부족해요. 시스템 프롬프트에 지시 없이는 Claude Fable 5가 거의 호출하지 않거든요. 도구를 유도 언어와 짝을 이루세요:
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.
내레이션이나 내부 추론을 send_to_user로 라우팅하지 마세요. 사용자 대상이 아닌 콘텐츠로 과도하게 호출하면 목적이 무너져요.
권장 스캐폴딩 변경 (Recommended scaffolding changes)
- 어려움 범위의 최상단에서 시작하세요. 이전 모델에 부여했을 것보다 더 어려운 과제를 고르고, Claude Fable 5가 그것을 범위 설정하고, 명확화 질문을 하고, 실행하게 하세요.
- 장기 실행 프롬프트에서 자기 검증을 명시적으로 만드세요. 분리되고 새 컨텍스트인 검증자 하위 에이전트가 자기 비판보다 잘 동작하는 경향이 있어요. 장기 실행 과제를 위해 지시하세요:
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. - 기존 프롬프트와 스킬을 리팩터링하세요. 이전 모델용으로 개발한 스킬은 Claude Fable 5에는 지나치게 처방적일 때가 많고 출력 품질을 떨어뜨릴 수 있어요. 기본 성능이 더 낫다면 이전 지시를 검토하고 제거를 고려하세요. Claude Fable 5는 손에 든 과제에서 배운 것을 바탕으로 스킬을 그 자리에서 업데이트하는 일도 잘해요.
- 응답에서 추론을 재현하라고 지시하지 마세요. 내부 추론을 응답 텍스트로 echo·전사·설명하라고 말하는 프롬프트, 스킬, 하네스 지시는 Claude Fable 5에서
reasoning_extraction거부 범주를 트리거해 Claude Opus 4.8로의 폴백 상승을 일으킬 수 있어요. 마이그레이션할 때 기존 스킬과 시스템 프롬프트에서 반성(reflection)이나 생각 보여주기 지시를 감사하세요. 애플리케이션에 추론 가시성이 필요하다면 적응형 thinking의 구조화된thinking블록을 읽고, 장기 실행 중 진행을 표시하는 데 사용자에게 보내는 도구를 사용하세요. - 사용자에게 보내는 도구를 만드세요. 길고 비동기적인 에이전트를 위해 클라이언트 측 도구가 턴을 끝내지 않고 메시지를 사용자에게 그대로 전달해요. 사용자에게 보내는 도구 만들기를 참고하세요.