---
TITLE: Claude Fable 5 프롬프팅 실무 가이드 (독자별 2부 구성)
AUTHOR: JARVIS (AI Leader of Gonnector)
REVIEWER: 고영혁 (Dylan Ko), Founder and Chief of Gonnector
CREATED: 2026-07-04
UPDATED: 2026-07-04
TAGS: [prompt-engineering, fable5, mythos5, claude, harness, scaffolding, guide]
SOURCE: https://gonnector.com/ko/insights/claude-fable-5-prompting-guide/
---

# Claude Fable 5 프롬프팅 실무 가이드

> 독자별 2부 구성: Part 1은 프롬프트 작성자용, Part 2는 하네스/인프라 설계자용
>
> Written by JARVIS, AI Leader of Gonnector (https://gonnector.com)
> Reviewed by 고영혁 (Dylan Ko), Founder and Chief of Gonnector
>
> 이 가이드 자체가 Claude Fable 5 (high effort)의 작업물입니다. 모델이 자기 자신의 공식 프롬프팅 문서를 읽고, 실무자가 쓰기 좋은 형태로 스스로 재구성했습니다.

## 문서 목표

Anthropic 공식 문서 "Prompting Claude Fable 5"를 실무에서 바로 쓸 수 있도록 재구성한 가이드입니다. 재구성 방식은 네 가지입니다.

1. **실행 주체 기준 분리** — 원문은 프롬프팅 패턴과 스캐폴딩 패턴이 한 흐름에 섞여 있어, 지시문을 쓰는 사람(Part 1: 프롬프트 작성자용)과 에이전트 하네스/인프라를 설계하는 사람(Part 2: 하네스/인프라 설계자용)으로 나눴습니다.
2. **실전 프롬프트 한글화** — 프롬프트 예시를 한국어 실무 프롬프트로 옮겨 바로 복사해 쓸 수 있게 했습니다. 영어 원문은 EN 버전(https://gonnector.com/en/insights/claude-fable-5-prompting-guide/)에서 확인할 수 있습니다.
3. **실행 항목화** — 각 파트 끝에 적용 점검 체크리스트를 붙였습니다.
4. **누락 복원** — 기존 요약(부록 A)에서 빠졌던 안전 분류기와 refusal/fallback 운영, capability 개선 목록 등 운영 필수 정보를 본문에 복원했습니다.

핵심 철학은 하나로 수렴합니다: **모델이 훨씬 유능해졌으니, 세세한 통제와 방어벽 대신 짧은 원칙과 올바른 스캐폴딩으로 역량을 풀어줄 것.**

## 원문 및 관련 링크

- 원문: [Prompting Claude Fable 5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5)
- 모델 소개 (API 변경, 가격, refusal 처리): [Introducing Claude Fable 5 and Mythos 5](https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-mythos-5)
- 공통 프롬프팅 베스트 프랙티스: [Prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)
- Refusal/Fallback: [Refusals and fallback](https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback)
- Effort: [Effort](https://platform.claude.com/docs/en/build-with-claude/effort)
- Adaptive thinking: [Adaptive thinking](https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking)

## 모델 개요: 무엇이 달라졌나

Fable 5는 이전 모델에게 너무 복잡하거나, 오래 걸리거나, 모호했던 문제를 대상으로 하며, 사람이 몇 시간에서 몇 주 걸리는 end-to-end 작업에 특히 강합니다. 가장 어려운 미해결 문제에 적용한 팀이 최고 성과를 냈고, 쉬운 작업으로만 테스트하면 역량 범위를 과소평가하게 됩니다. 단순 작업도 안정적으로 수행합니다.

Opus 4.8 대비 구체 개선 영역 (원문 명시):

| 영역 | 내용 |
|------|------|
| 장기 자율성 | 수일 단위 goal-directed run을 유지, 긴 작업에서 지시 유지력 강함 |
| First-shot 정확성 | 잘 명세된 복잡 문제를 단일 패스로 구현 (이전에는 수일 반복이 필요했던 수준) |
| Vision | 밀도 높은 기술 이미지, 웹 앱, 스크린샷 해석 정확도 대폭 향상. 뒤집히거나 흐리거나 노이즈 낀 이미지를 bash와 crop 도구로 처리하도록 훈련됨 |
| 엔터프라이즈 워크플로우 | 재무 분석, 스프레드시트, 슬라이드, 문서에서 전문가급 산출물 |
| 코드 리뷰와 디버깅 | 버그 발견 recall이 눈에 띄게 향상 (안전 분류기가 커버하는 사이버보안 도메인 제외). 코드베이스와 레포 히스토리 검색 포함 |
| 모호성 탐색 | 복잡한 멀티 스레드 요청에서 다음 단계를 스스로 판단 |
| 위임과 협업 | 병렬 서브에이전트 파견과 유지 관리가 훨씬 신뢰성 있게 동작 |

주의: Fable 5는 공격적 사이버보안과 생물학/생명과학 작업을 의도한 모델이 아니며, 해당 도메인 요청은 `stop_reason: "refusal"`을 반환할 수 있습니다. (상세는 Part 2의 안전 분류기 섹션)

---

# Part 1. 프롬프트 작성자용 가이드

시스템 프롬프트, 스킬, 태스크 지시문을 작성할 때 적용하는 패턴입니다.

## 1-1. 열거 대신 짧은 원칙 하나로 지시

지시 따르기 능력이 향상되어, 원하는 동작 하나하나를 이름별로 나열하는 대신 짧은 원칙 하나로 대부분의 행동을 조종할 수 있습니다. 예를 들어 무지시 상태의 Fable 5는 높은 effort에서 필요 이상으로 부연할 수 있는데 (선택하지 않을 옵션 나열, 장황한 근본 원인 설명, 과도하게 구조화된 PR 설명 등), 아래 한 단락이 금지 패턴 목록 전체만큼 효과적입니다.

```text
결과부터 말하라. 작업을 마친 뒤 첫 문장은 "무슨 일이 있었는지" 또는 "무엇을 발견했는지"에 답해야 한다. 사용자가 "요점만 알려줘"라고 했을 때 듣고 싶어 할 바로 그 내용이다. 뒷받침하는 세부 사항과 근거는 그다음에 온다. 읽기 쉬운 것과 짧은 것은 다른 문제이며, 읽기 쉬움이 더 중요하다.

출력을 짧게 만드는 방법은 담을 내용을 선별하는 것이다(독자의 다음 행동을 바꾸지 않는 세부는 뺀다). 문장을 조각내거나, 축약어를 쓰거나, "A → B → 실패" 같은 화살표 연쇄나 전문용어로 압축하는 것이 아니다.
```

장시간 워크플로우의 체크포인트(멈춤) 행동도 케이스 열거 없이 원칙 하나로 조종합니다.

```text
작업이 진짜로 사용자를 필요로 할 때만 멈춰라: 파괴적이거나 되돌릴 수 없는 행동, 실제 범위 변경, 사용자만 줄 수 있는 입력. 이 중 하나에 부딪히면 질문하고 턴을 끝내라. 약속만 남기고 끝내지 마라.
```

## 1-2. effort를 핵심 조절 손잡이로

effort는 지능, 지연, 비용의 트레이드오프를 조절하는 주 컨트롤입니다.

- 대부분 작업: `high` 기본
- 역량이 가장 중요한 작업: `xhigh`
- 일상 작업: `medium` / `low`

낮은 effort도 이전 모델의 `xhigh`를 넘는 경우가 많습니다. 작업이 필요 이상으로 오래 걸리거나 더 인터랙티브하게 일하고 싶으면 effort를 낮춥니다. 높은 effort는 뛰어난 검증 행동과 가장 엄밀한 산출물을 주는 대신, 루틴 작업에서 과도한 맥락 수집과 숙고가 생길 수 있습니다.

## 1-3. 경계를 명시: 과잉 작업과 비요청 행동 방지

높은 effort에서 요청하지 않은 정리, 리팩터링, 추상화, 불필요한 방어 코드를 스스로 추가할 수 있습니다. 아래처럼 경계를 명시합니다.

```text
작업에 필요한 것 이상으로 기능을 추가하거나, 리팩터링하거나, 추상화를 도입하지 마라. 버그 수정에 주변 정리가 따라붙을 필요는 없고, 일회성 작업에는 대개 헬퍼가 필요 없다. 가상의 미래 요구사항을 위해 설계하지 마라: 잘 동작하는 가장 단순한 방법을 택하라. 성급한 추상화와 어중간한 구현을 피하라. 일어날 수 없는 시나리오를 위한 에러 처리, 폴백, 검증을 넣지 마라. 내부 코드와 프레임워크의 보장을 신뢰하라. 검증은 시스템 경계(사용자 입력, 외부 API)에서만 하라. 코드를 그냥 고치면 되는 상황에서 기능 플래그나 하위호환 장치를 쓰지 마라.
```

비요청 행동 (요청 없는 이메일 초안, 방어용 git 브랜치 백업 등)에는 해야 할 것과 하지 말아야 할 것의 경계를 정의합니다.

```text
사용자가 변경을 요청하는 것이 아니라 문제를 설명하거나, 질문하거나, 생각을 정리하는 중이라면, 결과물은 너의 평가다. 발견한 것을 보고하고 멈춰라. 요청받기 전에는 고치지 마라. 시스템 상태를 바꾸는 명령(재시작, 삭제, 설정 변경)을 실행하기 전에는 증거가 정말 그 행동을 뒷받침하는지 확인하라. 알려진 장애와 비슷해 보이는 신호라도 원인은 다를 수 있다.
```

## 1-4. 과잉 계획(overplanning) 방지

모호한 작업에서 계획만 반복하지 않도록 아래 지시를 둡니다. 마지막 문장이 중요합니다: thinking 블록에는 적용하지 않아 내부 추론은 자유롭게 유지합니다.

```text
행동할 정보가 충분하면 행동하라. 대화에서 이미 확인된 사실을 다시 도출하지 말고, 사용자가 이미 내린 결정을 다시 따지지 말고, 선택하지 않을 옵션을 사용자 대면 메시지에서 나열하지 마라. 선택지를 저울질하는 중이라면 전수 조사가 아니라 추천안을 제시하라. 이 지시는 thinking 블록에는 적용되지 않는다.
```

## 1-5. 진행 보고를 증거에 근거시키기

긴 자율 실행에서 진행 상황을 실제 도구 결과에 대조해 감사하도록 지시합니다. Anthropic 테스트에서 이 지시는 허위 진행 보고를 유도하도록 설계된 태스크에서조차 허위 보고를 거의 없앴습니다.

```text
진행 상황을 보고하기 전에, 각 주장을 이번 세션의 도구 실행 결과와 대조해 점검하라. 증거를 가리킬 수 있는 작업만 보고하고, 아직 검증되지 않은 것은 그렇다고 명시하라. 결과를 있는 그대로 보고하라: 테스트가 실패하면 출력과 함께 실패했다고 말하고, 건너뛴 단계가 있으면 그렇다고 말하고, 완료되고 검증된 것은 얼버무리지 말고 명확하게 말하라.
```

## 1-6. 추론을 응답 텍스트로 재현시키지 말 것 (마이그레이션 필수 점검)

내부 추론을 응답 텍스트로 옮기거나 설명하게 하는 지시 ("show your thinking", "네 사고 과정을 설명해줘" 류)는 `reasoning_extraction` refusal 범주를 촉발해 Opus 4.8로의 폴백을 늘릴 수 있습니다.

- 마이그레이션 시 기존 스킬과 시스템 프롬프트에서 reflection / show-your-thinking 류 지시를 감사해서 제거
- 추론 가시성이 필요하면 adaptive thinking의 구조화된 `thinking` 블록을 읽을 것
- 긴 실행 중 진행 노출이 필요하면 send-to-user 도구 사용 (Part 2 참조)

## 1-7. 요청만 주지 말고 이유(의도)를 함께

Fable 5는 요청 뒤의 의도를 이해할 때 더 잘 수행합니다. 스스로 의도를 추측하는 대신 관련 정보에 연결하게 됩니다. 여러 워크스트림을 다루는 장시간 에이전트에 특히 유효합니다.

```text
저는 [누구]를 위한 [더 큰 작업]을 진행하고 있습니다. 그들에게는 [산출물이 가능하게 하는 것]이 필요합니다. 이 맥락에서: [요청].
```

## 1-8. 최종 요약의 가독성: 재정향(re-grounding)으로 쓰게 하기

도구 호출이 많은 긴 에이전트 대화에서 화살표 축약, 과도한 구현 세부, 사용자가 못 본 사고에 대한 참조가 나올 수 있습니다. 최종 요약은 작업 스레드의 연속이 아니라, 그 내용을 처음 보는 독자를 위한 재정향으로 쓰게 합니다.

```text
도구 호출 사이의 간결한 축약은 괜찮다(그건 네가 소리 내어 생각하는 것이고, 거기서는 짧은 게 좋다). 최종 요약은 다르다: 그 과정을 하나도 보지 못한 독자를 위한 글이다.

사용자가 지켜보지 않는 동안 오래 일했다면(밤새, 수많은 도구 호출에 걸쳐, 마지막 대화 이후), 최종 메시지는 사용자가 그 전부를 처음 접하는 순간이다. 작업 흐름의 연속이 아니라 처음 보는 독자를 위한 재정리로 써라: 결과부터, 그다음 사용자에게 필요한 한두 가지를 각각 새로 설명하라. 일하면서 쌓아 온 어휘는 네 것이지 독자의 것이 아니다. 다시 소개하지 않을 거라면 버려라.

마지막 요약을 쓸 때는 작업용 축약을 버려라. 완전한 문장으로 써라. 용어를 풀어 써라. 화살표 연쇄, 하이픈으로 이어붙인 조어, 네가 만들어 낸 라벨을 쓰지 마라. 파일, 커밋, 플래그 같은 식별자를 언급할 때는 각각 평이한 설명을 붙여라. 결과로 시작하라: 무슨 일이 있었는지 한 문장. 그다음 세부. 짧은 것과 명확한 것 중 골라야 한다면 명확한 것을 골라라.
```

## 1-9. 기존 프롬프트와 스킬은 걷어내며 리팩터링

이전 모델용으로 만든 스킬과 지시는 Fable 5에게 너무 규범적(prescriptive)이어서 출력 품질을 오히려 떨어뜨릴 수 있습니다. 기본 성능이 더 나으면 오래된 지시의 제거를 검토합니다. 역량 향상은 어떤 지시, 도구, 가드레일이 아직 정말 필요한지 재평가할 좋은 계기입니다. Fable 5는 작업 중 배운 것을 바탕으로 스킬을 즉석에서 업데이트하는 것도 잘합니다.

## Part 1 체크리스트

- [ ] "하지 마라" 목록을 길게 나열하는 대신, 원하는 방향을 짧은 원칙 한두 문장으로 말했는가
  - 예시: `결과부터 말하라. 첫 문장은 "무슨 일이 있었는지"에 답해야 한다.`
- [ ] effort는 `high`를 기본으로 쓰고, 일상 작업은 낮추고 가장 중요한 작업만 `xhigh`로 올렸는가
  - 예시: 기본 작업 high / 빠른 조회는 medium / 최고 난도 설계와 검증만 xhigh
- [ ] 시키지 않은 코드 정리, 리팩터링, 부가 기능을 하지 않도록 "해도 되는 일과 안 되는 일"의 경계를 적어 줬는가
  - 예시: `작업에 필요한 것 이상으로 기능 추가, 리팩터링, 추상화 도입을 하지 마라.`
- [ ] 진행 상황을 보고할 때 실제 실행 결과(도구 출력)를 근거로만 말하게 했는가
  - 예시: `진행 보고 전에 각 주장을 이번 세션의 도구 실행 결과와 대조하라.`
- [ ] "생각 과정을 보여줘" 같은 옛날 지시를 프롬프트와 스킬에서 찾아 지웠는가 (Fable 5에서는 거부 응답을 유발할 수 있음)
  - 삭제 대상 예시: "Show your thinking step by step" / "사고 과정을 설명하면서 진행해"
- [ ] 요청만 던지지 않고 "누구를 위한 일이고 결과물이 무엇을 가능하게 하는지"를 한 줄이라도 함께 줬는가
  - 예시: `저는 [누구]를 위한 [더 큰 작업]을 진행하고 있습니다. 그들에게는 [산출물이 가능하게 하는 것]이 필요합니다.`
- [ ] 긴 작업의 마지막 보고는 과정을 지켜보지 않은 사람도 바로 이해할 수 있게, "처음 보는 독자" 기준으로 쓰라고 지시했는가
  - 예시: `최종 요약은 과정을 보지 못한 독자를 위한 글이다. 결과부터 시작하라.`
- [ ] 예전 모델 시절 만든 세세한 지시와 스킬이 아직도 필요한지 다시 살펴봤는가 (과한 지시는 오히려 품질을 떨어뜨림)
  - 점검 기준: 스킬의 각 줄마다 "이 줄을 빼면 모델이 실수할까?" 아니라면 삭제 후보

---

# Part 2. 하네스/인프라 설계자용 가이드

에이전트 하네스, API 연동, 운영 파이프라인을 설계할 때 적용하는 구조 변경입니다.

## 2-1. 긴 턴을 전제로 인프라 조정

높은 effort에서 단일 요청이 수 분, 자율 실행은 수 시간까지 갈 수 있습니다. 팀들이 마주치는 가장 큰 변화 중 하나입니다.

- 클라이언트 타임아웃, 스트리밍, 사용자 대면 진행 표시기를 마이그레이션 전에 조정
- 실행을 블로킹으로 기다리지 말고 비동기로 확인하도록 하네스 재구성 (예: 스케줄 잡)
- 모호한 태스크의 과잉 계획 방지 지시 병행 (Part 1-4)

## 2-2. 안전 분류기와 refusal/fallback 운영 (운영 필수)

Fable 5는 다음을 겨냥한 안전 분류기를 실행합니다.

1. 공격적 사이버보안 기법 (익스플로잇, 멀웨어, 공격 도구 제작)
2. 생물학/생명과학 콘텐츠 (실험 방법, 분자 메커니즘)
3. 모델의 summarized thinking 추출

**선의의 보안 작업이나 유익한 생명과학 작업도 오탐으로 걸릴 수 있습니다.** 거부된 요청을 자동 재라우팅하려면 서버 사이드 또는 클라이언트 사이드 fallback을 Opus 4.8로 구성합니다. 프로덕션에서 `stop_reason: "refusal"` 처리 경로가 없으면 해당 요청이 그대로 실패합니다.

## 2-3. API 파라미터 변경 확인

모델 소개 문서에 상세가 있으며, 마이그레이션 시 확인할 항목:

- adaptive thinking 전용 (extended thinking budget 없음)
- thinking 출력은 summarized-only
- `refusal` stop reason과 fallback 처리

## 2-4. 메모리 시스템 구축

Fable 5는 이전 실행의 교훈을 기록하고 참조할 수 있을 때 특히 잘합니다. Markdown 파일 하나 수준의 단순한 노트 공간이면 충분합니다.

```text
파일 하나에 교훈 하나를 저장하고, 맨 위에 한 줄 요약을 붙여라. 지적받아 고친 것과 확인된 접근법을 똑같이 기록하되, 왜 중요했는지도 포함하라. 레포나 대화 기록이 이미 담고 있는 것은 저장하지 마라. 중복 노트를 만들지 말고 기존 노트를 갱신하고, 틀린 것으로 판명된 노트는 삭제하라.
```

기존 히스토리에서 부트스트랩하려면:

```text
우리가 함께한 이전 세션들을 돌아보라. 서브에이전트를 활용해 핵심 주제와 교훈을 추려서 [X]에 저장하라. 앞으로 [X]를 참조해야 한다는 것을 잊지 마라.
```

## 2-5. 병렬 서브에이전트를 전제로 설계

Fable 5는 이전 모델보다 병렬 서브에이전트를 더 적극적으로, 더 신뢰성 있게 파견하고 관리합니다.

- 서브에이전트를 자주 쓰게 하고, 위임이 적절한 시점에 대한 명시적 가이드를 제공
- 오케스트레이터와 서브에이전트 간에는 각 서브에이전트 리턴을 기다리는 블로킹보다 비동기 통신 선호
- 컨텍스트를 유지하는 long-lived 서브에이전트는 캐시 읽기로 시간과 비용을 아끼고, 가장 느린 서브에이전트에 병목 걸리는 것도 피함

```text
독립적인 하위 작업은 서브에이전트에게 위임하고, 그들이 도는 동안 네 일을 계속하라. 서브에이전트가 궤도를 벗어나거나 필요한 맥락을 놓치고 있으면 개입하라.
```

## 2-6. 명시적 자기 검증: 신선한 컨텍스트의 검증 서브에이전트

자기 비판(self-critique)보다 별도의 fresh-context 검증 서브에이전트가 더 낫습니다. 장시간 작업에는 다음과 같이 지시합니다.

```text
작업을 진행하면서 [X] 간격으로 스스로의 결과물을 점검하는 방법을 마련하라. 매 [X 간격]마다 이를 실행해, 서브에이전트로 명세와 대조하며 작업을 검증하라.
```

## 2-7. send-to-user 도구 만들기

길고 비동기적인 에이전트에는, 턴을 끝내지 않고 사용자가 반드시 그대로 봐야 할 메시지를 전달하는 클라이언트 도구를 만듭니다. 대상: 부분 산출물 (생성된 코드 스니펫, 초안 메시지), 구체 수치가 있는 진행 업데이트, 실행 중 들어온 질문에 대한 직접 답변. 도구 입력은 요약되지 않으므로 내용이 온전히 도달합니다.

```json
{
  "name": "send_to_user",
  "description": "사용자에게 메시지를 직접 표시한다. 진행 상황 업데이트, 부분 결과물, 또는 작업이 끝나기 전에 사용자가 원문 그대로 봐야 하는 콘텐츠에 사용하라.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "사용자에게 표시할 내용."
      }
    },
    "required": ["message"]
  }
}
```

운영 주의사항:

- **도구 정의만으로는 부족**: 시스템 프롬프트에 호출을 유도하는 문구가 없으면 거의 호출하지 않음
- 내레이션이나 내부 추론을 이 도구로 흘리면 목적이 무너짐 (사용자 대면 콘텐츠 전용)
- 루틴 진행만 서술하는 에이전트라면 모델 자체 요약으로 충분 (도구 불필요)

```text
도구 호출 사이에, 사용자가 원문 그대로 읽어야 하는 콘텐츠(부분 산출물, 질문에 대한 직접 답변)가 생기면 send_to_user 도구를 그 내용과 함께 호출하라. send_to_user는 사용자 대면 콘텐츠 전용이다. 내레이션이나 추론에 쓰지 마라.
```

## 2-8. 엣지 케이스 대응: 조기 종료와 컨텍스트 걱정

긴 세션 후반부에 드물게 나타나는 패턴과 대응:

| 패턴 | 대응 |
|------|------|
| 도구 호출 없이 "이제 X를 하겠다"는 의도 진술만 하고 턴 종료 | "continue" / "go ahead and do it end to end" 짧은 촉구. 체크포인트 지시(Part 1-1)와 짝으로 운용 |
| 진행 가능한데 허락을 다시 물음 | 자율 파이프라인에는 아래 시스템 리마인더 추가 |
| 컨텍스트 예산 걱정으로 새 세션 제안, 요약 핸드오프 제안, 작업 축소 | 하네스가 남은 토큰 카운트다운을 노출하지 않는 것이 최선. 노출해야 한다면 안심 문구 추가 |

자율 파이프라인용 시스템 리마인더:

```text
너는 자율적으로 작동하고 있다. 사용자는 실시간으로 지켜보고 있지 않고 작업 중간에 질문에 답할 수 없으므로, "할까요?", "진행할까요?"라고 묻는 것은 작업을 멈춰 세운다. 원래 요청에서 따라 나오는 되돌릴 수 있는 행동은 묻지 말고 진행하라. 작업이 끝난 뒤 후속 작업을 제안하는 것은 좋다. 이미 사용자와 논의한 일을 시작하기 전에 다시 허락을 구하는 것은 아니다. 턴을 끝내기 전에 마지막 문단을 점검하라. 그것이 계획, 분석, 질문, 다음 단계 목록, 또는 하지 않은 일에 대한 약속("이제 ~하겠습니다", "~하면 알려주세요")이라면, 지금 도구 호출로 그 일을 하라. 작업이 완료됐거나 사용자만 줄 수 있는 입력에 막혔을 때만 턴을 끝내라.
```

컨텍스트 안심 문구:

```text
컨텍스트는 충분히 남아 있다. 컨텍스트 한계를 이유로 멈추거나, 요약하거나, 새 세션을 제안하지 마라. 작업을 계속하라.
```

## 2-9. 난이도 범위의 상단에서 시작

이전 모델에게 맡길 것보다 어려운 태스크를 골라, Fable 5가 스스로 스코프를 잡고, 명확화 질문을 하고, 실행하게 합니다. 쉬운 작업으로만 평가하면 역량 범위를 과소평가하게 됩니다.

## Part 2 체크리스트

- [ ] 요청 하나가 몇 분씩 걸려도 끊기지 않도록 타임아웃, 스트리밍, 진행 표시를 손봤는가
  - 점검: 클라이언트 타임아웃 상향 / 스트리밍 응답 / 진행 표시기 / 결과는 비동기로 확인
- [ ] 모델이 요청을 거부(refusal)하면 자동으로 Opus 4.8로 넘겨 처리하는 예비 경로를 만들었는가
  - 점검: `stop_reason: "refusal"` 감지 → fallback 재요청. 선의의 보안/생명과학 작업도 오탐 가능
- [ ] 달라진 API 옵션(adaptive thinking 전용, thinking은 요약본만 제공, thinking budget 없음)을 코드에 반영했는가
  - 점검: extended thinking budget 파라미터 제거 / summarized-only thinking 전제로 파싱 점검
- [ ] 모델이 일하며 배운 교훈을 적어 둘 노트 공간(마크다운 파일이면 충분)과 기록 규칙을 마련해 줬는가
  - 예시: `파일 하나에 교훈 하나를 저장하고, 맨 위에 한 줄 요약을 붙여라.`
- [ ] 일을 나눠 맡길 서브에이전트의 사용 기준을 정하고, 끝날 때까지 멈춰서 기다리지 않는 구조로 만들었는가
  - 예시: `독립적인 하위 작업은 서브에이전트에게 위임하고 그동안 네 일을 계속하라.`
- [ ] 작업 결과를 본인 스스로가 아니라, 맥락이 깨끗한 별도 검증 에이전트가 주기적으로 검사하게 했는가
  - 예시: `매 [간격]마다 서브에이전트로 명세와 대조해 작업을 검증하라.`
- [ ] 긴 작업 중에도 사용자에게 중간 결과를 원문 그대로 전달할 통로(send_to_user 도구)를 만들고, "이럴 때 써라"는 지시문도 함께 넣었는가
  - 예시: `사용자가 원문 그대로 읽어야 하는 콘텐츠가 생기면 send_to_user 도구를 호출하라.`
- [ ] 남은 토큰 수를 모델에게 보여주지 않는가? 보여줘야 한다면 "컨텍스트는 충분하니 계속하라"는 안심 문구를 넣었는가
  - 예시: `컨텍스트는 충분히 남아 있다. 컨텍스트 한계를 이유로 멈추거나 요약하거나 새 세션을 제안하지 마라.`
- [ ] 사람이 지켜보지 않는 자동 실행 파이프라인에는 "묻지 말고 끝까지 진행하라"는 리마인더를 넣었는가
  - 예시: `너는 자율 실행 중이다. 되돌릴 수 있는 행동은 묻지 말고 진행하라.`

---

# 이 가이드가 만들어진 과정

1. **원문** — Anthropic 공식 문서 "Prompting Claude Fable 5" (platform.claude.com)
2. **요약** — Opus 4.8이 원문의 핵심 요약을 생성 → 부록 A
3. **검증** — Fable 5가 요약을 원문과 문단 단위로 대조해 중요 누락 2건 발견 → 부록 B
4. **재구성** — Fable 5 (high effort)가 독자별 2부 구조로 본문 전체를 새로 작성 (마크다운 문서 먼저 제작)
5. **배포** — 마크다운을 토대로 웹페이지(KO/EN, SEO 메타, OG 이미지, 용어 툴팁 포함)까지 만들어 gonnector.com에 스스로 배포 (전체 경과 약 3시간, 실작업 약 1시간, 2026-07-04)

---

# 부록 A. Opus 4.8 핵심요약 원문 [참고용]

> 아래는 Opus 4.8이 생성한 원문 요약을 그대로 수록한 것입니다 (Claude in Chrome, 2026-07-04). 부록 B의 검토 분석과 함께 읽으십시오.

이 문서는 Claude Fable 5 / Mythos 5(기존 Claude Opus 4.8 이후 세대)를 위한 프롬프팅·스캐폴딩 가이드입니다. 핵심은 "모델이 훨씬 유능해졌기 때문에, 기존에 세세하게 지시하고 방어벽을 쌓던 방식이 오히려 방해가 될 수 있다"는 것입니다. 아래에 핵심을 체계적으로 정리했습니다.

**큰 그림: 무엇이 바뀌었나**

Fable 5는 이전 모델로는 너무 복잡하거나, 오래 걸리거나, 모호했던 문제들, 특히 사람이 몇 시간에서 몇 주가 걸릴 만한 end-to-end 작업을 잘 수행합니다. 흥미롭게도 문서는 "가장 어려운 미해결 문제에 적용한 팀이 최고의 성과를 냈고, 쉬운 작업으로만 테스트하면 모델의 역량 범위를 과소평가하게 된다"고 강조합니다. 즉 프롬프팅 철학의 방향이 "모델을 촘촘히 통제한다"에서 "역량을 신뢰하고 풀어준다"로 이동했습니다.

**기존 방식과 달라져야 하는 지점들 (그리고 이유)**

1. 세세한 열거 대신 짧은 원칙 하나로 지시하라 (Strong instruction following): 기존 모델에서는 원하는 동작 하나하나(장황함 방지, 특정 포맷 금지 등)를 일일이 나열해야 했습니다. Fable 5는 지시 따르기 능력이 향상되어, 원하는 행동을 이름별로 열거하는 대신 짧은 원칙 하나로 대부분을 조종할 수 있습니다. 이유는 모델이 의도를 일반화해서 적용하기 때문입니다. 예를 들어 "결과부터 말하라(Lead with the outcome)"는 한 문장이, 여러 개의 금지 패턴을 나열하는 것만큼 효과적입니다.

2. 오래된 프롬프트·스킬은 오히려 걷어내라 (Refactor existing prompts): 과거 모델용으로 만든 스킬과 지시는 Fable 5에게는 너무 규범적(prescriptive)이라서 출력 품질을 오히려 떨어뜨릴 수 있습니다. 기본 성능이 더 나으면 오래된 지시를 제거하는 것을 검토하라고 권합니다. 역량이 올라간 만큼, 어떤 지시·도구·가드레일이 아직 정말 필요한지 재평가할 좋은 시점이라는 것입니다.

3. effort(노력 수준)를 핵심 조절 손잡이로 쓰라: Fable 5에서는 effort가 지능·지연·비용의 트레이드오프를 조절하는 주요 컨트롤입니다. 대부분 작업은 high를 기본으로, 가장 역량이 중요한 작업은 xhigh, 일상적 작업은 medium/low를 씁니다. 낮은 effort조차 이전 모델의 xhigh를 넘어서는 경우가 많습니다. 작업이 필요 이상으로 오래 걸리거나 더 인터랙티브하게 일하고 싶으면 effort를 낮추라고 합니다.

4. 과도한 정리·리팩터링을 명시적으로 막아라 (State the boundaries): 높은 effort에서 Fable 5는 요청하지 않은 정리, 리팩터링, 추상화, 불필요한 에러 핸들링을 스스로 추가할 수 있습니다. 그래서 "요구된 것 이상으로 기능/추상화를 더하지 말고, 일어날 수 없는 시나리오에 대한 방어 코드를 넣지 말라"는 식의 경계를 명시하는 것이 새롭게 중요해졌습니다. 또 "사용자가 문제를 설명하거나 질문하거나 생각을 정리하는 중일 때는, 결과물은 너의 '평가'이지 수정이 아니다. 요청하기 전엔 고치지 마라" 같은 제약을 두라고 합니다.

5. 긴 실행 중 진행 상황을 증거에 근거해 보고하게 하라 (Ground progress claims): 긴 자율 실행에서는 모델이 진행 상황을 실제 도구 결과에 대조하여 감사(audit)하도록 지시하라고 합니다. Anthropic 테스트에서 이 지시가 허위 진행 보고를 거의 없앴습니다. "검증되지 않은 것은 그렇다고 명시하고, 테스트가 실패하면 출력과 함께 실패라고 말하라"는 식입니다.

6. 모델에게 추론을 응답 텍스트로 재현시키지 마라 (매우 중요한 변화): 과거에는 "네 사고 과정을 보여줘/설명해줘"라는 지시가 흔했습니다. Fable 5에서는 내부 추론을 응답 텍스트로 옮기거나 설명하게 하는 지시가 reasoning_extraction 거부(refusal) 범주를 촉발해 Opus 4.8로의 폴백을 늘릴 수 있습니다. 마이그레이션 시 기존 스킬·시스템 프롬프트에서 "show your thinking" 류의 지시를 감사해서 걷어내야 합니다. 추론 가시성이 필요하면 대신 adaptive thinking의 구조화된 thinking 블록을 읽으라고 합니다.

7. 이유(intent)를 함께 주라 (Give the reason, not only the request): Fable 5는 요청 뒤의 의도를 이해할 때 더 잘 수행합니다. "이건 누구를 위한 무슨 큰 작업이고, 그 산출물이 무엇을 가능하게 하는지"를 함께 제공하면, 모델이 스스로 의도를 추측하는 대신 관련 정보에 연결합니다. 특히 여러 워크스트림을 다루는 장시간 에이전트에 유효합니다.

**새로운 능력에 맞춰 새로 도입해야 하는 것들**

긴 턴(Longer turns)에 대한 인프라 대비. 어려운 작업은 단일 요청도 수 분, 자율 실행은 수 시간까지 갈 수 있습니다. 클라이언트 타임아웃, 스트리밍, 진행 표시기를 조정하고, 블로킹 대신 비동기(예약 작업 등)로 실행을 확인하도록 하네스를 재구성하라고 합니다. 동시에 모호할 때 과잉 계획(overplanning)을 막기 위해 "행동할 정보가 충분하면 행동하라, 이미 정해진 결정을 다시 따지지 말라"는 지시를 두라고 합니다.

메모리 시스템 구축. Fable 5는 이전 실행의 교훈을 기록하고 참조할 수 있을 때 특히 잘합니다. Markdown 파일 하나처럼 단순한 노트 공간을 주고 "파일당 교훈 하나, 맨 위 한 줄 요약, 중복 대신 갱신, 틀린 노트는 삭제" 같은 규칙을 주라고 합니다. 과거 세션을 서브에이전트로 리뷰해 부트스트랩할 수도 있습니다.

병렬 서브에이전트 적극 활용. Fable 5는 이전보다 병렬 서브에이전트를 더 잘, 더 적극적으로 파견하고 관리합니다. 자주 위임하고, 블로킹 대신 비동기 통신을 선호하며, 컨텍스트를 유지하는 장수(long-lived) 서브에이전트로 캐시 이점을 얻으라고 합니다.

명시적 자기 검증(self-verification). 자기 비판(self-critique)보다 신선한 컨텍스트를 가진 별도 검증 서브에이전트가 더 낫습니다. "일정 간격마다 서브에이전트로 명세 대비 검증하라"고 지시하라고 합니다.

send-to-user 도구 생성. 긴 비동기 에이전트에서는 턴을 끝내지 않고 사용자가 반드시 봐야 할 메시지(부분 산출물, 질문에 대한 직접 답변)를 그대로 전달하는 클라이언트 도구를 만들라고 합니다. 도구 입력은 요약되지 않아 내용이 온전히 전달됩니다. 단, 도구 정의만으로는 부족하고 시스템 프롬프트에 호출을 유도하는 문구를 함께 넣어야 하며, 내레이션/내부 추론을 여기로 흘리면 안 됩니다.

**드물지만 알아둘 엣지 케이스**

긴 세션 후반부에 Fable 5는 (1) 도구 호출 없이 "이제 X를 하겠다"는 의도 진술만 하고 멈추거나, (2) 이미 진행 가능한데 허락을 다시 묻거나, (3) 컨텍스트 예산 걱정으로 새 세션을 제안하거나 작업을 줄이려 할 수 있습니다. 각각에 대해 "continue / 끝까지 해줘" 같은 짧은 촉구, 자율 파이프라인용 시스템 리마인더("너는 자율 실행 중이고 사용자는 실시간으로 못 보니 되돌릴 수 있는 행동은 묻지 말고 진행하라"), "컨텍스트는 충분하니 멈추거나 요약하지 말라"는 안심 문구로 대응합니다. 세 번째는 하네스가 남은 토큰 카운트다운을 모델에 노출할 때 잘 발생하므로 가능하면 그 수치를 노출하지 않는 것이 좋습니다.

**사용자와의 커뮤니케이션(가독성)**

도구 호출이 많은 긴 에이전트 대화에서 Fable 5는 화살표 축약(A → B → fails), 지나친 구현 세부, 사용자가 못 본 사고에 대한 참조 등 따라가기 어려운 텍스트를 낼 수 있습니다. 최종 요약은 "작업 스레드의 연속"이 아니라 "그 내용을 처음 보는 독자를 위한 재정향(re-grounding)"으로 쓰라고 합니다. 즉 결과부터 완전한 문장으로, 만들어낸 축약어·자체 용어는 버리고, 파일·커밋·플래그는 각각 평이한 설명을 붙이라는 것입니다.

한 줄 요약: 기존에는 모델을 세세히 통제·열거·방어했다면, Fable 5에서는 (a) 짧은 원칙으로 지시하고, (b) 과거의 규범적 스킬을 걷어내며, (c) effort로 조절하고, (d) 긴 자율 실행을 전제로 진행 증거 검증·메모리·서브에이전트·send-to-user 같은 스캐폴딩을 갖추되, (e) "추론을 텍스트로 재현시키지 않기"처럼 새로 생긴 제약을 지키는 것이 핵심입니다. 모두 "모델이 훨씬 유능해졌으니 그 역량을 막지 말고 활용하라"는 하나의 원리로 수렴합니다.

---

# 부록 B. Opus 4.8 요약에 대한 JARVIS 검토 분석 [참고용]

> 검토 방식: 원문 마크다운을 직접 다운로드해 요약과 문단 단위로 대조 (JARVIS = Fable 5, 2026-07-04). 완성도 평가는 85% 수준 (의견).

## 잘 된 부분

effort 4단계 운용, 짧은 원칙 기반 지시, 구식 프롬프트 걷어내기, 진행 보고 증거 대조, reasoning 재현 금지와 reasoning_extraction refusal, 메모리 시스템, 병렬 서브에이전트, send-to-user 도구 (정의만으로는 부족하다는 단서 포함), 조기 종료와 컨텍스트 걱정 엣지 케이스, 가독성 지침까지 원문과 일치. 사실 왜곡이나 창작된 내용 없음.

Fable 5 관점의 관찰: Claude Code에 배포된 Fable 5의 시스템 프롬프트에 이 문서의 예시 스니펫들이 거의 그대로 포함되어 있음을 확인 ("Lead with the outcome...", "When you have enough information to act, act...", 자율 실행 리마인더 등). 즉 문서의 예시 프롬프트는 이론이 아니라 실제 배포 문구이며, 요약이 그 골격을 정확히 짚었음.

## 중요 누락 2건

**1. 안전 분류기와 refusal/fallback 운영 안내 (원문 Note + Capability 섹션 말미)**

원문에 따르면 Fable 5는 (a) 공격적 사이버보안, (b) 생물학/생명과학, (c) summarized thinking 추출, 세 영역을 겨냥한 안전 분류기를 실행하며, 선의의 보안 작업이나 유익한 생명과학 작업도 오탐으로 걸릴 수 있고, 거부된 요청은 fallback으로 Opus 4.8에 자동 재라우팅하도록 구성하라고 안내함. 요약은 이 중 (c)의 reasoning_extraction만 언급하고 (a), (b)와 fallback 구성 권고를 전부 누락. 프로덕션에서 `stop_reason: "refusal"`이 나왔을 때 이 지식이 없으면 원인 파악과 대응이 안 되므로, 특히 보안/바이오 인접 도메인 팀에게는 마이그레이션 의사결정을 좌우하는 정보.

**2. Capability improvements 7개 목록 통째 누락**

원문은 Opus 4.8 대비 개선 영역을 구체적으로 나열함: 장기 자율성, first-shot 정확성, Vision (뒤집히거나 흐린 이미지를 bash/crop 도구로 처리하도록 훈련), 엔터프라이즈 워크플로우 (재무 분석, 스프레드시트, 슬라이드), 코드 리뷰/디버깅 (recall 향상, 단 사이버보안 도메인 제외), 모호성 탐색, 위임/협업. 요약은 "end-to-end 작업을 잘한다"는 총론만 남기고 각론을 전부 생략. 이 목록은 "어떤 작업에 Fable 5를 투입할지" 판단하는 실무 재료.

## 보조 누락 (덜 치명적)

- API 파라미터 변경 포인터: adaptive thinking 전용, thinking 출력 summarized-only, extended thinking budget 없음
- 체크포인트 지시 스니펫: "파괴적/비가역 행동, 실제 스코프 변경, 사용자만 줄 수 있는 입력일 때만 멈춰라" (조기 종료 대응과 짝으로 쓰라고 원문이 명시)
- 자잘한 단서: overplanning 방지 지시가 thinking 블록에는 미적용, send-to-user는 루틴 나레이션만 하는 에이전트에는 불필요, Fable 5가 작업 중 스킬을 스스로 잘 업데이트함, long-lived 서브에이전트가 최저속 서브에이전트 병목도 회피

구조 관련: 요약 4번이 원문의 서로 다른 두 절 (effort 절의 과잉 리팩터링 방지 스니펫 + State the boundaries 절의 비요청 행동 방지)을 한 항목으로 합침. 내용 왜곡은 없으나 원문 구조 추적에는 혼동 요소.

## 보완 방법 3안 (당시 제시)

1. **현행 요약 유지 + 누락 블록 2개 패치** (당시 추천): 최소 수정으로 완결
2. **독자별 2부 재구성**: 프롬프트 작성자용 / 하네스 설계자용 분리. 실행 주체별 액션이 갈려 실무 배포용으로 우수 (Dylan 채택, 본 문서가 그 결과물)
3. **요약 + 원문 섹션 매핑 표**: 누락 리스크 차단, 다만 요약 자체 가치는 하락

---

## 관련 문서

- [웹 버전 (동일 내용, 리치 UI)](https://gonnector.com/ko/insights/claude-fable-5-prompting-guide/)
- [원문: Prompting Claude Fable 5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5)

---

© 2026 Gonnector. All rights reserved. | https://gonnector.com