프롬프트 부채: Claude Fable 5에서 공들여 쌓은 프롬프트가 독이 되는 이유

여러분이 몇 달간 공들여 쌓은 프롬프트가, Claude Fable 5에서는 ‘부채’가 됐을 수 있습니다.

도발적으로 들리겠지만 제 개인적인 경험담만은 아닙니다. Anthropic이 공식 프롬프팅 가이드 Prompting Claude Fable 5에 직접 적어둔 내용이거든요. 이 글에서는 세 가지를 정리해보겠습니다. 첫째, 공식 문서가 정확히 무엇을 경고하는지. 둘째, 왜 잘 만든 프롬프트일수록 부채가 되기 쉬운지. 셋째, 무엇을 지우고 무엇을 남겨야 하는지. 실무에서 바로 쓸 수 있는 청산 체크리스트까지 담았습니다.

Anthropic이 공식 문서에 적어둔 경고

Fable 5 프롬프팅 가이드의 “Recommended scaffolding changes” 섹션에는 이런 문장이 있습니다.

Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better.

이전 모델용으로 개발된 스킬은 Fable 5에는 과도하게 규정적(too prescriptive)인 경우가 많아 출력 품질을 떨어뜨릴 수 있다. 기본 성능이 더 우수하다면 오래된 지시의 제거를 검토하라.

문장을 뜯어보면 세 가지 조건이 붙어 있습니다. 이전 모델용으로 개발된 프롬프트·스킬이, 과도하게 규정적일 때, 품질을 떨어뜨릴 수 있다(can)는 거죠. 무조건 프롬프트를 지우라는 얘기가 아닙니다. 구모델 기준으로 설계된 지시가 새 모델에서는 역효과일 수 있으니, 기본 성능과 비교해보고 제거를 검토하라는 마이그레이션 지침입니다.

같은 문서는 그 이유도 설명합니다. Fable 5는 지시 이행(instruction-following) 능력이 충분히 좋아져서, 행동을 하나하나 이름 붙여 나열하지 않아도 짧은 지시 하나로 대부분의 행동을 조정할 수 있습니다.

Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name.

심지어 “짧은 간결성 지시 하나가 패턴을 일일이 나열하는 것만큼 효과적”(A short brevity instruction is as effective as listing each pattern)이라고 명시합니다. 패턴 열거와 짧은 원칙 지시의 효과가 같다면, 유지보수 비용이 낮은 쪽이 이기는 거죠.

‘프롬프트 부채’는 어떻게 쌓이나

기술 부채는 코드에만 있는 게 아닙니다.

우리가 프롬프트와 스킬, 에이전트 규칙을 키워온 과정을 돌아보면 패턴이 보입니다. 모델이 엣지 케이스를 놓친다 → 케이스별 예외 지시를 추가한다. 모델이 멋대로 행동한다 → 금지 행동 목록을 늘린다. 모델이 절차를 건너뛴다 → 단계별 절차를 하나하나 적어 넣는다. 전부 구모델의 빈틈을 사람이 지시로 메운 흔적입니다.

문제는 모델이 좋아질수록 이 흔적이 자산에서 부채로 바뀐다는 점입니다. Anthropic의 프롬프팅 베스트 프랙티스 문서는 사람이 손으로 짠 단계별 계획보다 일반적인 지시가 더 나은 추론을 끌어내는 경우가 많다며, 그 이유를 이렇게 설명합니다.

Claude’s reasoning frequently exceeds what a human would prescribe.

Claude의 추론이 사람이 처방하는 수준을 넘어서는 경우가 많다.

구모델의 빈틈을 메우려고 덧붙인 행동 지시, 케이스별 예외, 단계별 절차. 모델이 스스로 더 나은 경로를 찾을 수 있게 된 시점부터, 이것들은 오히려 모델의 손발을 묶는 제약으로 작동합니다. 코드의 기술 부채가 “당시에는 합리적이었던 결정”의 누적이듯, 프롬프트 부채도 당시에는 전부 필요했던 지시의 누적이죠. 그래서 더 위험합니다. 하나하나가 멀쩡해 보이거든요.

사실 Fable 5가 처음이 아니다

이 흐름을 Fable 5의 돌발 변화로 읽으면 곤란합니다. Anthropic은 Opus 4.5/4.6 가이드에서도 이미 “over-prompting을 제거하라”(Remove over-prompting), “공격적인 지시 언어를 완화하라”(dial back any aggressive language)고 권고했습니다. 구모델에서 도구 호출을 안 하던 버릇을 고치려고 “CRITICAL: 반드시, 무조건!” 같은 강조를 쌓아왔다면, 지시를 잘 따르는 새 모델에서는 그 강조가 오히려 과잉 행동을 유발한다는 맥락이었죠.

Fable 5는 이 방향이 한층 강해진 것뿐입니다. 모델 세대가 올라갈 때마다 “사람이 메워야 할 빈틈”은 줄어드는데, 프롬프트만 그대로면 격차는 벌어질 수밖에 없습니다. 분기마다 의존성을 업데이트하듯, 모델 업그레이드 시점마다 프롬프트도 리팩토링 대상이 된다는 얘기입니다.

이 관점은 AI 하네스 리팩토링에서 다룬 문제의식과 정확히 같습니다. 그 글이 규칙·훅·스킬 전체 하네스 차원의 다이어트였다면, 이번 공식 가이드는 프롬프트 차원에서 같은 처방을 내린 셈이죠.

오해 주의: ‘길이’가 아니라 ‘규정성’이다

여기서 가장 흔한 오독이 “아, 프롬프트를 짧게 쓰라는 거구나”입니다. 그런데 공식 문서가 지목하는 변수는 길이(length)가 아닙니다. 규정성(prescriptiveness), 즉 모델이 ‘어떻게’ 일할지를 사람이 일일이 정해주는 정도입니다.

실제로 같은 문서는 반대 방향의 권고도 분명히 합니다.

• 경계는 명시적으로 정의하라. 해도 되는 것과 하면 안 되는 것의 제약(explicit constraints)은 분명하게 적으라고 권한다. 경계 없이 풀어두면 요청하지 않은 작업까지 알아서 해버리는 부작용이 있다.
• 요청의 의도와 맥락을 제공하라. 왜 이 작업을 요청하는지 이유를 주면 성능이 더 좋아지는 경향이 있다(tends to perform better)고 명시한다.
• 자가 검증을 명시하라. 장기 실행 작업에서는 결과를 스스로 검증하는 절차를 프롬프트에 명시적으로(explicit) 적으라고 권한다.
• 문제는 잘 명세하라. Fable 5의 강점으로 꼽히는 첫 시도 정확도(first-shot correctness)는 “잘 명세된(well-specified) 문제”라는 전제가 붙는다.

전 모델 공통 베스트 프랙티스의 대원칙인 “원하는 것을 정밀하게 설명할수록 결과가 좋아진다”(The more precisely you explain what you want, the better the result) 역시 Fable 5에도 그대로 적용된다고 명시되어 있습니다.

정리하면 이렇습니다.

구분	내용	Fable 5에서
’어떻게’	단계별 절차, 행동 패턴 열거, 케이스별 예외, 강조 반복	줄인다. 과잉 규정은 품질을 깎을 수 있다
’무엇을·왜’	작업 목표, 요청 의도·맥락, 경계 제약, 검증 기준	명확하게. 자세할수록 오히려 유리하다

프롬프트가 길어도 그 길이가 의도·맥락·경계·검증 기준으로 채워져 있다면 문제가 없습니다. 반대로 짧아도 “반드시 X 하고, Y는 절대 하지 말고, Z 다음에는 꼭 W를 해” 식의 미시 처방으로 채워져 있다면, 그게 바로 부채입니다.

프롬프트 부채 청산 체크리스트

그래서 당장 무엇을 하면 될까요. 공식 가이드의 권고를 실무 순서로 풀면 다섯 단계입니다.

1. 가장 오래 묵은 지시부터 찾는다. 시스템 프롬프트, CLAUDE.md·AGENTS.md 같은 에이전트 규칙 파일, 스킬 정의에서 작성 시점이 오래된 지시를 추린다. “이거 왜 넣었더라?”가 기억나지 않으면 1순위 후보다.
2. ‘어떻게’ 지시를 분류한다. 행동 열거(“~할 때는 ~하고, ~할 때는 ~하라”), 케이스별 예외, 단계별 절차 강제, CRITICAL/반드시 류의 강조 반복이 청산 대상이다. 의도·경계·검증 기준은 건드리지 않는다.
3. 짧은 원칙 지시로 교체해본다. 패턴 10개를 나열한 지시라면 “간결하게, 요청 범위만”처럼 원칙 한 줄로 바꿔서 동작을 비교한다. 공식 문서 기준으로 둘의 효과는 동등하다.
4. 기본 성능과 비교한 뒤 지운다. 공식 권고의 단서 조항인 “기본 성능이 더 우수하다면”(if default performance is better)이 핵심이다. 지시를 빼고 돌려본 결과가 같거나 더 좋을 때만 제거를 확정한다.
5. 한 번에 다 지우지 않는다. 부채 상환과 같다. 한 덩어리씩 제거하고 검증하는 사이클을 반복해야, 어떤 지시가 아직 필요한지(= 아직 모델이 못 하는 것이 무엇인지) 학습할 수 있다.

이 사이클을 돌리다 보면 부수 효과가 하나 생깁니다. 내 프롬프트에서 무엇이 지워지는지가 곧 모델 세대 간 능력 변화의 지도가 된다는 점이죠. 지난 세대에는 필요했지만 이번 세대에 불필요해진 지시 목록. 이것만큼 정확한 벤치마크도 드뭅니다.

맺으며

Fable 5 자체에 대한 정리는 Mythos 5 · Fable 5 완전 정리에서, 프롬프트를 줄인 자리를 채우는 자동화 설계는 루프 엔지니어링에서 다뤘습니다. 세 글을 관통하는 결론은 하나입니다. 모델이 좋아지는 속도만큼, 모델을 다루는 방식도 갱신되어야 한다는 거죠.

여러분의 프롬프트에서 가장 오래 묵은 지시는 언제 적은 건가요. 그 지시, 아직도 필요한지 이번 주에 한번 점검해보면 좋겠습니다.