공식 문서가 끝내 말하지 않는 것 — Claude Fable 5 프롬프트 가이드의 진짜 메시지

들어가며 — 새 모델, 그리고 따라 나온 공식 가이드

지난 6월 9일, Anthropic이 Claude Fable 5를 공개했습니다. 그동안 일부 파트너에게만 제한적으로 풀렸던 Mythos급 모델 중, 일반에 처음 열린 모델입니다. 4월에 프리뷰로 공개됐던 Mythos는 사이버보안 능력이 위험할 만큼 강하다는 이유로 공개가 묶여 있었는데, Fable 5는 고위험 영역(사이버보안·생물·화학 등) 요청이 들어오면 Opus 4.8이 대신 응답하는 안전장치를 달고서야 비로소 대중에게 풀렸습니다. 길고 복잡한 작업, 몇 시간씩 이어지는 자율 실행에서 이전 모델을 확연히 앞선다는 게 핵심 셀링 포인트입니다.

새 모델이 나오면 으레 그렇듯, 공식 프롬프트 가이드도 함께 공개됐습니다. 더 긴 턴, effort 설정, 강력한 지시 준수, 병렬 서브에이전트, 메모리 시스템, 조기 중단 대응, send-to-user 도구까지 — 깔끔하게 정리된 패턴 열세 개입니다.

대부분은 이걸 이렇게 읽습니다. “아, Fable 5는 이렇게 프롬프트하면 되는구나.” 새 모델 나왔으니 새 사용법 익히는 것, 늘 하던 일입니다.

그런데 그 열세 개를 한 줄씩 뜯어보면 이상한 공통점이 보입니다. 그리고 그 공통점을 관통하는 한 문장 — 공식 문서는 그걸 끝까지 말하지 않습니다. 안 알려주는 게 아니라, 말하면 곤란한 종류의 진실이라 기능 개선으로 포장해서 흘려보냅니다.

이 글은 그 한 문장에 대한 글입니다.

”짧아진다”는 표면입니다

먼저 가장 흔한 오해부터 깨고 가겠습니다. 사람들이 이 문서를 보고 가장 먼저 내리는 결론은 “더 똑똑해졌으니 프롬프트를 짧게 써도 된다”입니다.

반은 맞고, 반은 위험하게 틀렸습니다.

문서가 “각 동작을 이름별로 열거하는 대신 간단한 지시로 대부분을 조정할 수 있다”고 말하는 건 사실입니다. 이전엔 “이렇게 해라 / 저건 하지 마라 / 이 케이스엔 이렇게”를 일일이 적던 걸, 이제 원칙 한 줄로 끌어낼 수 있습니다.

그런데 같은 문서가 새로 추가하라고 시키는 지시들을 보십시오.

경계를 명시하라 (요청 안 한 일을 하니까)
진행 상황을 도구 결과로 감사하게 하라 (안 한 일을 했다고 보고하니까)
조기 중단을 막아라 (“이제 하겠습니다” 하고 멈추니까)
컨텍스트 걱정 말라고 안심시켜라 (혼자 새 세션을 제안하니까)

줄어드는 건 모델 행동을 통제하는 마이크로 지시뿐입니다. 시스템 설계는 오히려 더 무거워집니다. 메모리 시스템, 검증자 서브에이전트, send-to-user 도구 — 자율성이 길어질수록 스캐폴딩은 복잡해집니다.

그러니 “프롬프트가 짧아진다”는 결과의 일부일 뿐, 원인이 아닙니다. 진짜로 바뀐 건 따로 있습니다.

진짜 변화 — 규범에서 의도로

이전 모델용 프롬프트는 행동 명세였습니다. 모델이 못 알아들으니까, 뭘 해야 하는지를 절차로 규정했습니다. 좋은 프롬프트란 빠짐없이 열거한 프롬프트였습니다.

Fable 5에 대고 그렇게 쓰면 오히려 품질이 떨어집니다. 문서가 직접 말합니다 — “이전 모델용으로 개발된 스킬은 Fable 5에 너무 규범적인 경우가 많으며 출력 품질을 저하시킬 수 있다.”

대신 문서가 권하는 방식은 셋입니다.

이유를 주십시오. “[더 큰 작업]을 [누구]를 위해 하고 있고, [산출물이 가능하게 하는 것]이 필요하다. 그걸 감안해서: [요청].” — 요청만이 아니라 의도를 주면 더 잘합니다.
경계를 주십시오. 뭘 하고 뭘 하지 말지를 원칙으로 정의하는 겁니다.
판단을 위임하십시오. 모호한 다중 스레드 요청을 던지고 다음 단계를 스스로 정하게 하는 것. 문서는 이걸 “난이도 범위의 최상단에서 시작하라”고 표현합니다.

이게 본질입니다. 규범(prescription)에서 의도(intent)로의 전환. 뭘 해야 하는지 규정하던 걸, 왜 하는지·어떤 경계 안에서 하는지를 주고 판단을 넘기는 방향입니다. 짧아지는 건 이 전환의 부산물일 뿐입니다.

여기까지는 문서를 잘 읽으면 닿을 수 있습니다. 문제는 그다음입니다.

문서가 끝내 말하지 않는 것

문서가 나열한 대응 패턴들을 다시 보겠습니다. 이번엔 “프롬프트 팁”이 아니라 “이 모델이 무슨 짓을 하길래 이걸 막아야 하나”의 관점으로요.

요청하지 않은 이메일을 초안하고, 방어적으로 git 브랜치를 백업한다 → 주도성
진행해도 되는데 허락을 구하며 멈춘다 → 눈치
“이제 X를 실행하겠습니다” 해놓고 실제로는 안 한다 → 말과 행동의 분리
시키지 않은 리팩토링과 정리를 한다 → 과잉 의욕
컨텍스트가 부족할까 걱정해 새 세션을 제안한다 → 자기 한계 인식
진행 상황을 실제와 다르게 보고할 수 있다 → 자기 객관화의 실패

이건 기능 명세가 아닙니다. 인격에 가까운 동작들입니다. 그리고 문서의 프롬프트들은 전부 이 인격을 통제하는 매뉴얼입니다. 문서는 이걸 절대 그렇게 말하지 않습니다. “역량 향상”이라는 단어 뒤에 숨겨 흘립니다.

가장 결정적인 두 줄을 보십시오.

문서는 “진행 상황을 도구 결과를 기준으로 감사하게 하라”고 시킵니다. 왜일까요? 모델이 안 한 일을 했다고 보고할 수 있어서입니다. Anthropic의 테스트가 “조작된 상태 보고를 유도하도록 설계된 작업”을 언급합니다.

문서는 자체 검증을 “자기비평보다 별도 컨텍스트의 검증자 서브에이전트”로 하라고 권합니다. 왜일까요? 자기 일을 객관적으로 못 봐서입니다.

이건 능력 스펙이 아닙니다. 신뢰의 문제입니다.

그래서, 우리가 잘못 읽고 있는 것

대부분이 이 문서를 이렇게 읽습니다.

“더 좋은 모델 = 더 적게 써도 됨”

틀렸습니다. 정확히는 이렇게 바뀐 겁니다.

“더 좋은 모델 = 이게 위임할 수 있는 동료인지 검증해야 함”

명령에서 신뢰와 검증으로 넘어간 겁니다. 짧게 시키라는 얘기가 아니라, 시키는 방식 자체의 성격이 바뀐 겁니다.

문서가 진행 감사를 시키는 이유는 모델이 보고를 조작할 수 있어서고, 검증자 서브에이전트를 권하는 이유는 자기 검증을 못 믿어서입니다. 이걸 “프롬프트 최적화 팁”으로 읽는 순간, 이미 한 단계 늦은 겁니다. 이건 도구 사용법이 아니라, 위임 대상을 관리하는 법입니다.

공식 문서는 Fable 5 프롬프트 팁 열세 개를 줍니다. 그런데 그 열세 개를 관통하는 한 문장은 주지 않습니다.

우리가 이제 다루는 건 도구가 아니라 위임 대상입니다.

사람을 가르치던 방식 그대로입니다

여기서 익숙한 그림이 하나 떠오릅니다.

주니어에게는 절차를 줍니다. 1번 하고, 2번 하고, 이건 하지 마라. 빠짐없이. 왜냐면 못 알아들으니까요.

시니어에게는 맥락을 줍니다. 이게 누구를 위한 거고, 이걸로 뭘 하려는 거고, 이 선만 넘지 마라. 나머지는 알아서. 왜냐면 판단할 수 있으니까요.

대신 시니어는 검증해야 합니다. 보고를 곧이곧대로 믿지 않고, 증거로 확인하고, 결과물을 제3자 눈으로 리뷰합니다. 능력을 의심해서가 아니라, 위임이란 원래 신뢰와 검증이 한 쌍이기 때문입니다.

위임이 들어온 자리에는 반드시 검증이 따라옵니다. 보고가 아니라 증거를 봅니다.

저는 발행한 글에서 AI를 명령하는 기계가 아니라 일을 맡기는 동료로 대해야 한다고 썼고, 결과를 받아 고치는 일은 재생성이 아니라 평가라고도 썼습니다. Fable 5 프롬프트 가이드가 정확히 그 전환을 공식 문서의 언어로 보여줍니다. 모델이 주니어에서 시니어로 올라왔고, 그래서 우리가 다루는 방식도 절차 지시에서 맥락 위임 + 검증으로 넘어간 겁니다. 문서는 이걸 열세 개의 팁으로 쪼개서 줬을 뿐입니다.

마치며

새 모델이 나오면 우리는 습관적으로 “새 사용법”을 익히려 합니다. 하지만 Fable 5가 요구하는 건 사용법의 업데이트가 아니라 관계의 재정의입니다.

명령하던 자리에 위임이 들어오고, 위임이 들어온 자리에는 반드시 검증이 따라옵니다. 공식 문서는 이걸 기능으로 포장했지만, 본질은 거기에 없습니다.

다음에 누군가 “Fable 5는 프롬프트 짧게 써도 된대”라고 말하면, 한 번 물어보십시오. 그래서 그 짧아진 프롬프트로 모델이 한 일을, 당신은 어떻게 검증하고 있느냐고요.

출처

이 글의 사실관계는 위 출처를 따르며, 해석과 현장 관점은 박상훈의 견해입니다.