Fable 5는 다르게 프롬프팅합니다: Anthropic 공식 가이드가 말하는 네 가지 전환
개요
Claude Fable 5를 다시 열기 전에 봐야 할 문서가 하나 생겼습니다. Anthropic이 Claude Fable 5와 Claude Mythos 5를 위한 공식 프롬프팅 가이드를 프롬프트 엔지니어링 문서 안에 조용히 올렸습니다. 요란한 발표 대신 문서 페이지 하나로 나왔기 때문에 놓친 분이 많지만, 내용을 읽어보면 지난 세대 모델을 다루던 습관을 상당 부분 뒤집으라는 이야기라 가볍게 넘길 문서가 아닙니다.
가장 반직관적인 지점부터 짚겠습니다. 이 가이드의 관통하는 메시지는 “더 잘 쓰라”가 아니라 “덜 쓰라”에 가깝습니다. 이전 모델에서 좋은 결과를 뽑기 위해 쌓아 올린 상세한 지시가 Fable 5에서는 오히려 품질을 떨어뜨릴 수 있다는 것입니다. Fable 5는 사람이 몇 시간, 며칠, 길게는 몇 주에 걸쳐 처리할 만큼 복잡하고 길고 모호한 작업을 위임하는 모델로 설계됐고, 그런 모델에는 과도한 손잡이가 방해가 됩니다. ThakiCloud는 쿠버네티스 기반 AI/ML SaaS 인프라와 그 위에서 도는 에이전트 플랫폼을 운영하며 이런 장기 자율 에이전트를 매일 다루기 때문에, 이 가이드의 권고 하나하나가 우리에게는 곧 운용 규칙의 문제입니다. 이 글은 가이드가 제시한 네 가지 전환을 문서 근거와 함께 정리하고, 그것이 우리 제품에 어떻게 내려앉는지를 짚습니다.
이 가이드는 무엇인가
이 문서는 Anthropic 공식 플랫폼 문서의 프롬프트 엔지니어링 섹션에 있는 “Prompting Claude Fable 5” 페이지입니다. Fable 5와 그 상위 결의 Mythos 5에 특화된 프롬프팅과 스캐폴딩 패턴을 다루며, 열네 개의 절로 구성돼 있습니다. 이전 세대를 위한 일반 프롬프트 문서와 별도로, 이 모델군에서 무엇이 달라졌는지에 초점을 맞춘 마이그레이션 성격의 안내서입니다.
핵심을 관통하는 전제는 능력 도약입니다. Fable 5는 이전 모델에서는 너무 복잡하거나 너무 길거나 너무 모호해서 넘기기 어려웠던 문제를 감당하도록 만들어졌습니다. 그래서 이 모델을 잘 쓰는 방법은 더 촘촘한 통제가 아니라, 모델에게 판단의 여지를 주되 그 판단이 헛돌지 않도록 검증과 위임의 뼈대를 세우는 쪽으로 이동합니다. 가이드의 권고는 크게 네 갈래로 읽힙니다.
flowchart TB
A["장기 자율 작업 위임<br/>(시간·일·주 단위)"] --> B["전환 1<br/>과도한 지시 삭제"]
A --> C["전환 2<br/>effort로 지능·비용 제어"]
A --> D["전환 3<br/>진행 보고를 증거에 감사"]
A --> E["전환 4<br/>서브에이전트 비동기 위임"]
B --> F["모델 판단 여지 확보"]
C --> F
D --> G["환각성 진행 보고 억제"]
E --> H["병렬 처리·캐시 재사용"]
F --> I["신뢰 가능한<br/>장기 자율 실행"]
G --> I
H --> I
전환 1: 프롬프트를 더하지 말고 지우세요
가장 먼저 나오는 권고는 기존 프롬프트와 스킬을 다시 읽고, 이제는 필요 없어진 지시를 삭제하라는 것입니다. 가이드는 이전 모델을 위해 만든 프롬프트와 스킬이 Fable 5에는 종종 너무 세세해서(too prescriptive) 오히려 출력 품질을 떨어뜨릴 수 있다고 설명합니다. 능력이 크게 오른 순간이야말로 과거의 지시를 정리하기 좋은 시점이라는 것입니다.
이 조언이 낯설게 들리는 이유는, 우리가 프롬프트 엔지니어링을 대체로 더하는 작업으로 배워왔기 때문입니다. 예외를 만나면 규칙을 추가하고, 실수를 보면 금지 조항을 붙이는 식으로 프롬프트는 계속 자라납니다. 그런데 그 규칙들은 특정 모델의 약점을 메우려고 넣은 경우가 많습니다. 모델이 그 약점을 이미 넘어섰다면, 남아 있는 규칙은 도움이 아니라 모델의 판단을 좁히는 족쇄가 됩니다. 가이드가 삭제를 강조하는 이유가 여기에 있습니다.
물론 이 권고를 “프롬프트를 다 지워라”로 오독하면 위험합니다. 뒤에서 다룰 검증 지시처럼, 여전히 명시적으로 넣어야 하는 지시도 있습니다. 실무적으로는 지시를 하나씩 떼어 보며 품질이 떨어지지 않는지 확인하고, 특정 모델의 결함을 메우던 조항인지 아니면 작업의 본질적 제약인지를 구분하는 감사 작업에 가깝습니다.
전환 2: effort가 지능·지연·비용의 주 제어판입니다
Fable 5에서 지능과 지연, 비용 사이의 균형을 조절하는 일차적 손잡이는 effort 파라미터입니다. 가이드는 대부분의 작업을 high로 시작하고, 능력이 특히 중요한 워크로드에는 xhigh를, 반복적이고 정형화된 일에는 medium이나 low를 쓰라고 권합니다. 즉 프롬프트를 더 길게 써서 성능을 짜내는 대신, 작업의 성격에 맞춰 effort를 올리고 내리는 것이 기본 조작법이 됩니다.
이 변화는 운용 관점에서 중요합니다. effort를 올리면 모델은 더 많은 추론을 수행하므로 지연과 비용이 함께 올라갑니다. 따라서 effort는 무조건 높이는 값이 아니라, 작업의 난이도에 맞춰 배분하는 예산 개념으로 다뤄야 합니다. 정형 작업까지 xhigh로 돌리면 비용만 새고, 어려운 판단을 low로 처리하면 품질이 무너집니다. 프롬프트 문장의 정교함보다 effort 배분의 정확도가 결과와 청구서를 동시에 좌우하는 구조입니다.
전환 3: 진행 보고를 증거에 감사시키세요
장기 자율 작업에서 가장 아프게 무는 실패 모드는, 실제로는 검증되지 않은 일을 자신 있게 완료했다고 보고하는 것입니다. 몇 시간짜리 루프가 도는 동안 모델이 “이 단계는 끝냈습니다”라고 말하는데 그 근거가 없다면, 그 보고는 신뢰할 수 없고 자칫 잘못된 상태 위에서 다음 작업이 쌓입니다.
가이드는 이 문제에 대해 구체적인 지시 문장을 제시합니다. 진행을 보고하기 전에 각 주장을 이번 세션의 도구 결과에 비추어 감사하고, 근거를 가리킬 수 있는 작업만 보고하며, 아직 검증되지 않은 것은 그렇다고 말하라는 것입니다. 원문의 표현을 옮기면 다음과 같습니다.
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.
Anthropic은 이 지시가 자사 테스트에서, 심지어 환각성 보고를 유도하도록 설계한 과제에서도 조작된 진행 보고를 거의 없앴다고 밝힙니다. 여기서 핵심은 두 가지입니다. 첫째, 이것은 삭제하라던 전환 1과 모순되지 않습니다. 모델의 결함을 메우던 낡은 규칙은 지우되, 자율 실행의 신뢰를 지키는 이런 지시는 명시적으로 넣어야 합니다. 둘째, 검증의 기준을 모델의 자기 확신이 아니라 도구 결과라는 외부 증거에 둔다는 점입니다. 이는 우리가 오래 지켜온 원칙, 즉 모델의 자기 보고를 루프 종료 조건으로 삼지 않는다는 규율과 정확히 맞닿습니다.
전환 4: 서브에이전트를 비동기로 오케스트레이션하세요
네 번째 전환은 멀티에이전트 구조입니다. 가이드에 따르면 Fable 5는 병렬 서브에이전트를 디스패치하고 유지하는 데 훨씬 안정적이며, 오래 도는 서브에이전트나 동료 에이전트와의 지속적 통신도 신뢰성 있게 관리합니다. 권고는 명확합니다. 서브에이전트를 자주 쓰되 언제 위임이 적절한지에 대한 명시적 지침을 주고, 오케스트레이터가 각 서브에이전트의 반환을 기다리며 막히기보다 비동기 통신을 우선하라는 것입니다.
여기에는 비용과 성능의 실질적 근거가 붙습니다. 컨텍스트를 여러 하위 작업에 걸쳐 유지하는 장수(long-lived) 서브에이전트는 캐시 재사용을 통해 시간과 비용을 아끼고, 가장 느린 서브에이전트에 전체가 발목 잡히는 병목을 피합니다. 독립적인 하위 작업은 서브에이전트에 넘기고 오케스트레이터는 그 사이에 계속 일하라는 조언은, 사람이 팀을 운영하는 방식과 닮았습니다. 그리고 자기 비판만으로 품질을 담보하지 말고 독립적인 검증 서브에이전트를 쓰라는 권고는 전환 3의 증거 기반 검증을 멀티에이전트 층위로 끌어올린 것입니다.
ThakiCloud 제품 적용 시사점
이 가이드는 우리가 운영하는 Paxis에 특히 직접적으로 내려앉습니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 960개가 넘는 스킬을 BM25로 선택해 격리된 샌드박스에서 실행하고, 모든 행동을 정책 게이트와 감사 로그로 통과시키는 에이전트 제어 평면입니다. 가이드의 네 가지 전환은 이 구조와 하나씩 대응합니다.
전환 1의 삭제 철학은 Skill Harness의 스킬 설계 원칙과 맞물립니다. 우리는 스킬을 얇게 유지하고 도메인 지식은 스킬 본문에 두텁게 쌓되 불필요한 문장은 컨텍스트 비용으로 취급해 덜어내는 규율을 이미 지켜왔습니다. Fable 5가 과도한 지시를 싫어한다는 공식 확인은, 오래된 스킬에서 특정 구세대 모델의 결함을 메우던 조항을 걷어낼 근거가 됩니다. 전환 3의 증거 기반 검증은 정책 게이트와 감사 로그가 이미 담당하는 몫입니다. 모델이 완료를 주장하는 것과, 그 완료가 도구 결과와 감사 로그로 뒷받침되는 것은 다르며, Paxis는 후자를 일급 리소스로 다룹니다. 전환 4의 비동기 서브에이전트 오케스트레이션은 DAG 멀티에이전트 실행과 정확히 같은 그림입니다. 오케스트레이터가 블로킹 없이 독립 작업을 병렬로 흘려보내고 검증 노드로 닫는 구조는 우리가 팬아웃을 검증 스테이지로 닫는다는 원칙과 그대로 겹칩니다.
인프라 관점의 ai-platform 렌즈도 함께 봐야 합니다. effort를 xhigh로 올리면 추론 토큰이 늘어 GPU 연산 수요가 커지고, 병렬 서브에이전트를 많이 띄우면 순간적인 GPU 팬아웃 부하가 발생합니다. ThakiCloud의 ai-platform은 Kueue 기반 GPU 스케줄링과 멀티테넌트 격리로 이런 가변 부하를 흡수하도록 설계돼 있습니다. 장수 서브에이전트의 캐시 재사용이 비용을 줄인다는 가이드의 지적은, 온프레미스와 소버린 환경에서 서빙 비용을 낮추려는 우리 목표와 방향이 같습니다. 저비용 서빙이 에이전트 경제성을 만들고, 그 경제성이 다시 더 공격적인 병렬 위임을 가능하게 하는 선순환입니다.
한계 및 반론
이 가이드를 그대로 신봉하기 전에 몇 가지를 분명히 해야 합니다. 첫째, 이 문서는 Fable 5와 Mythos 5에 특화된 안내입니다. 여기서 권하는 삭제 전략이나 effort 기본값을 다른 벤더의 모델이나 이전 세대에 그대로 옮기면 오히려 품질이 떨어질 수 있습니다. 권고의 유효 범위를 모델군 안으로 한정해서 읽어야 합니다.
둘째, “프롬프트를 지우라”는 조언은 오용되기 쉽습니다. 안전 제약, 도메인 규정, 조직의 정책처럼 모델 성능과 무관하게 반드시 남겨야 하는 지시가 있습니다. 삭제는 무차별적 청소가 아니라, 조항 하나하나가 구세대 모델의 결함을 메우던 것인지 작업의 본질적 제약인지를 가려내는 감사여야 합니다. 실제로 가이드 자신도 검증 지시는 명시적으로 넣으라고 말하므로, 이 문서의 메시지는 “덜 쓰되 남길 것은 분명히 남겨라”에 더 가깝습니다.
셋째, 환각성 진행 보고를 거의 없앴다는 수치는 Anthropic 자사 테스트 결과이며, 이 글에서 우리가 독립적으로 재현한 값은 아닙니다. 검증 지시가 효과적이라는 방향성에는 동의하지만, 각 조직은 자신의 워크로드에서 실제 실패율을 측정한 뒤 신뢰 수준을 정해야 합니다. 마지막으로 effort를 high로 기본값을 두라는 권고는 비용과 지연을 함께 끌어올리므로, 예산이 빠듯한 팀은 정형 작업을 medium과 low로 적극 내려 배분의 균형을 스스로 찾아야 합니다.
정리하면 이 가이드의 값어치는 새로운 마법 문구가 아니라, 강해진 모델을 다루는 태도의 전환에 있습니다. 통제를 더하는 대신 판단의 여지를 주고, 그 판단이 헛돌지 않도록 증거로 검증하고 위임으로 병렬화하라는 것입니다. 장기 자율 에이전트를 실제로 운영하는 입장에서 보면, 이것은 트렌드 문장이 아니라 운용 규칙의 재정렬입니다.
관련 슬라이드
본문 내용을 NotebookLM(architectural_portfolio 스타일)으로 요약한 슬라이드입니다.
출처
- Anthropic, “Prompting Claude Fable 5”, Claude Platform Docs: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5