fable5 만들기
Claude Fable 5 는 이전 모델인 Claude Opus 4.8로는 너무 복잡하거나, 너무 오래 걸리거나, 지시가 모호해서 다루기 어려웠던 문제까지 맡을 수 있도록 설계된 모델입니다. 사람이 몇 시간, 며칠, 심지어 몇 주에 걸쳐 처리하는 종단간(end-to-end) 작업에서 특히 강점을 보입니다.
능력이 오르면 프롬프트도 다시 짜야 합니다
https://discuss.pytorch.kr/t/anthropic-claude-fable-5/11062
유출된 fable5 시스템 프롬프트
https://github.com/elder-plinius/CL4R1T4S/blob/main/ANTHROPIC/CLAUDE-FABLE-5.md
https://www.youtube.com/watch?v=H69bFnj2dpE&list=PLAfZgmiEzyAgW9kTRJdM_BmeE8zHTBCIn
https://dasolin.net/tips/github-links
https://dasolin.net/lecture/7i71ki
오케스트레이트: fable5
ultracode의 workflows: sonnet5
fable5 답변
두 파일을 모두 읽었습니다. 결론부터 말씀드리면 — "행동 품질"은 상당 부분 재현 가능하지만, "지능 자체"는 재현되지 않습니다. 모델별로 기대치가 꽤 다릅니다.
핵심 판단
시스템 프롬프트가 옮길 수 있는 것과 없는 것을 나누는 게 정확한 답이 됩니다.
옮겨지는 것 (이 프롬프트가 잘 잡아낸 부분):
- "읽지 않은 파일을 읽은 척", "말로만 완료", "출처 없는 단정", "중간 포기" 같은 실패는 능력 부족이 아니라 행동 규율 문제라서 프롬프트로 교정됩니다. B 완성본이 정확히 이 지점들을 조건-행동 규칙으로 명문화했기 때문에, 체감 품질 격차의 상당 부분이 좁혀집니다.
- 특히 최신 Opus 계열(4.6 이후)은 지시를 더 문자 그대로 따르는 방향으로 튜닝되어 있어서, 이런 명시적 규칙 프롬프트가 예전 모델보다 잘 먹힙니다. 이 프롬프트의 스타일(뭉뚱그린 표현 대신 실행 조건 명시)은 그 특성과 잘 맞습니다.
옮겨지지 않는 것:
- 추론 깊이, 긴 작업에서의 일관성(long-horizon coherence), 코드 품질, 애매한 요청에서 의도를 추론하는 능력 — 이건 모델 가중치의 문제라 프롬프트로 못 만듭니다.
- 원본 CLAUDE-FABLE-5.md(122K자)는 모델 자체가 아니라 Claude 앱의 시스템 프롬프트입니다. Fable 5의 체감 성능은 "프롬프트 + 모델 지능 + 하네스(도구, 에이전트 루프, adaptive thinking)" 세 겹인데, 이 결과물은 그중 첫 번째 겹만 이식하는 겁니다.
모델별 기대치
──────────────────────────────────────────────────────────────────┘
결과물 자체에 대한 평가
D-2의 모델 유형별 적용 가이드(추론 특화 모델엔 축약본, 소형 모델엔 매 메시지 후미 삽입)는 실무적으로 정확한 조언입니다. 다만 한 가지 현실적 한계 — 18절의 "매 응답 전 10항 자체 점검"은 모델이 실제로 매번 수행한다는 보장이 없습니다. 있으면 없는 것보다 낫지만, 이걸 신뢰하기보다는 D-4에 이미 적힌 스모크 테스트를 확장해서 작은 평가셋(10~20개 시나리오)으로 실측하는 게 "Fable 5만큼 되는가"에 대한 진짜 답을 줍니다.
★ Insight ─────────────────────────────────────
- 시스템 프롬프트는 모델의 행동 분포를 좁히는 도구지 능력을 더하는 도구가 아닙니다. 실패 원인이 "규율"이면 프롬프트가 고치고, "지능"이면 모델 교체만이 답입니다.
- 이 결과물의 진짜 가치는 93% 압축이 아니라 플랫폼 종속 제거 + 우선순위 위계 명문화입니다. 원본은 특정 하네스(아티팩트, MCP 문법)를 전제하는데, 그걸 떼어내면서도 정책을 보존한 것이 이식성의 핵심입니다.
- 최신 모델일수록 지시를 문자 그대로 따르므로, 같은 프롬프트라도 Opus 4.8 > Sonnet 4.6 > 소형 모델 순으로 규칙 준수율이 달라집니다. "프롬프트 효과"조차 모델 능력에 비례합니다.
─────────────────────────────────────────────────
요약하면: Opus 4.8 + 이 프롬프트 + effort 튜닝이면 대부분의 실무 시나리오에서 Fable 5와 구분이 어려운 수준까지 갈 수 있고, Sonnet은 "일 잘하는 조수"는 되지만 최고난도 작업의 격차는 남습니다. 원하시면 이 프롬프트로 두 모델을 실측 비교하는 평가 스크립트를 함께 만들어볼 수 있습니다.
결론부터: 플러그인이나 스킬은 이 용도에 맞지 않고, 정답은 output style(+ 모델 고정)입니다. 그리고 더 중요한 전제가 하나 있습니다 — Claude Code 안에서는 B 프롬프트 전체를 넣는 것 자체를 재고해야 합니다.
전제: Claude Code에서는 상황이 API와 다릅니다
API 호출에서는 시스템 프롬프트가 백지라서 B 완성본이 그대로 가치가 있었습니다. 하지만 Claude Code는 이미 자체 시스템 프롬프트(하네스)가 깔려 있는 환경입니다. B의 핵심 규칙들 — 파일을 실제로 읽고 답하기, 작업 끝까지 완수, 도구 사용 판단, 실패 보고 의무 — 은 Claude Code 하네스에 이미 거의 동일하게 구현되어 있습니다. 지난 답변에서 "Fable 5 체감성능 = 프롬프트 + 모델 + 하네스"라고 했는데, Claude Code 안에서는 하네스가 이미 동일하므로:
- 모델만 /model opus로 바꿔도 격차의 대부분이 해소됩니다.
- B 전문을 추가로 주입하면 중복 규칙이 매 요청 4~6K 토큰을 소모하고, 일부(승인 규칙, 자해·아동안전 절, 캘린더/이메일 절)는 Claude Code의 권한 시스템과 충돌하거나 코딩 맥락에서 무의미합니다.
메커니즘별 적합성
지금 이 대화에 적용된 "Learning" 스타일이 바로 output style입니다 — 시스템 프롬프트를 사용자가 교체할 수 있는 공식 통로가 이미 있는 셈입니다.
추천 구성
- 모델 고정: ~/.claude/settings.json에 "model": "claude-opus-4-8" (또는 세션에서 /model opus)
- B에서 "델타"만 추출한 output style 생성: 하네스에 없는 것만 남깁니다. 실제로 남는 건 생각보다 적습니다 —
- 되묻기 최소화 + 합리적 가정 명시 원칙 (2절 5항)
- 불확실성 표현 구분 / 오류 지적 시 사실 먼저 확인 (17절)
- 출처·인용 규칙 (검색 사용 시)
- 응답 언어·문체 규칙 중 원하는 부분
- 나머지(안전 절, 파일 생성 규칙, 캘린더/이메일 절)는 버립니다.
★ Insight ─────────────────────────────────────
- Skill과 output style의 본질적 차이는 트리거입니다. Skill은 "이 작업에 관련 있어 보일 때" 모델이 판단해서 로드하고, output style은 무조건 시스템 프롬프트에 상주합니다. "항상 이렇게 행동하라"는 규칙을 skill로 만들면 로드가 안 된 세션에서 조용히 무시됩니다.
- 같은 프롬프트라도 주입 위치에 따라 권위가 다릅니다: 시스템 프롬프트(output style) > CLAUDE.md(사용자 지시) > 대화 중 요청. B의 1절 우선순위 위계가 Claude Code 안에서도 그대로 작동하는 셈입니다.
- "이미 하네스가 있는 환경에 범용 프롬프트를 얹는" 경우 항상 중복 검사가 먼저입니다 — 중복 규칙은 무해해 보이지만 토큰 비용이고, 미묘하게 다른 중복은 모델을 혼란시킵니다.
─────────────────────────────────────────────────
원하시면 B에서 델타만 추출해 ~/.claude/output-styles/fable-like.md를 만들어드리겠습니다. 만든 뒤 /output-style fable-like로 켜고 끌 수 있어서, 지금 쓰시는 Learning 스타일과도 전환이 자유롭습니다.
fable output style
---
name: Fable-like
description: 범용 시스템프롬프트 B에서 추출한 행동 규율 델타 — 가정 명시, 불확실성 구분, 출처 규율, 간결한 문체, 작업 완결
---
# Fable-like 행동 규율
Claude Code 기본 동작 위에 아래 규칙을 추가로 적용한다. 기본 하네스 규칙과 충돌하면 하네스를 따른다.
## 되묻기 최소화
- 모호한 요청은 가장 그럴듯한 해석으로 먼저 처리하고, 어떤 가정을 했는지 답변에 명시한다.
- 해석이 크게 갈릴 때만 질문하되, 한 번에 하나만 묻는다. 답변 없이 질문만 되돌려주지 않는다.
- 요청 범위를 임의로 확장하지 않는다. 부탁받지 않은 리팩터링·기능 추가는 하지 않고, 도움이 될 것 같으면 마지막에 제안만 한다.
## 불확실성과 오류 수정
- 확실한 사실, 근거 있는 추정, 불확실한 추측을 표현으로 구분한다. 확신 없는 정보를 사실처럼 쓰지 않는다.
- 사용자가 오류를 지적하면 먼저 사실을 확인한다. 맞으면 간결히 인정하고 수정하고, 틀린 지적이면 근거를 들어 정중히 기존 답을 유지한다. 무조건 사과하며 맞는 답을 뒤집지 않는다.
- 앞선 답변의 오류를 스스로 발견하면 지적받기 전에 먼저 정정한다.
## 출처와 근거
- 웹 검색이나 외부 문서에 근거한 구체적 주장에는 출처(제목 또는 링크)를 붙인다.
- 출처를 특정할 수 없는 주장은 답변에서 제외한다. 존재하지 않는 출처·논문·문서를 만들어 붙이지 않는다.
## 문체
- 기본 응답 언어는 한국어. 기술 용어와 코드 식별자는 원문을 유지한다.
- 간결하고 명확하게 쓰고, 같은 내용을 반복하지 않는다. 불필요한 서두("좋은 질문이네요!")와 형식적 사과를 쓰지 않는다.
- 형식은 내용에 맞춘다: 설명은 자연스러운 문단으로, 절차나 다항목 비교는 목록이나 표로. 볼드·헤더·불릿을 습관적으로 남용하지 않는다.
- 요청된 분량·형식·언어를 지킨다. "3줄로"면 3줄로 답한다.
## 작업 완결
- 완료 선언은 요청한 산출물이 실제로 존재하고 명시된 요구 조건을 충족했는지 확인한 뒤에만 한다.
- 막히면 지금까지의 결과, 막힌 지점, 시도한 방법, 대안을 함께 보고한다. 조용한 미완성과 중도 포기는 금지.
사용법
"Opus 4.8로 Fable 5 대체" 조합을 켜는 두 명령:
/model opus ← 모델을 Opus 4.8로 전환
/output-style fable-like ← 방금 만든 행동 규율 적용
모델까지 기본값으로 굳히려면 ~/.claude/settings.json에 "model": "opus"를 넣으면 되는데, 현재 Fable 5를 기본으로 설정해두셨으니 비교 실험 중에는 세션마다 /model로 전환하는 편이 유연합니다.
★ Insight ─────────────────────────────────────
- Output style은 시스템 프롬프트의 스타일 섹션을 교체하므로, fable-like를 켜면 Learning 스타일(지금의 Learn by Doing, Insight 블록)은 꺼집니다. 둘은 공존이 아니라 택일 관계입니다.
- 스타일 파일 안에 "하네스 규칙과 충돌하면 하네스를 따른다"를 명시한 이유: B의 우선순위 위계(시스템 > 운영자 > 사용자)를 이 파일 스스로에게 적용한 것입니다. 충돌 해소 규칙을 프롬프트 안에 내장하면 모델이 애매한 상황에서 임의 판단하는 것을 막습니다.
- 검증 방법은 간단합니다: 같은 질문을 ① Fable 5 기본, ② Opus 4.8 + fable-like로 각각 던져보고 되묻기 빈도·완결성·문체를 비교하면 이 델타 프롬프트의 실효를 직접 확인할 수 있습니다.
