AI 활용 · 지침 파일 정리법

AI가 멍청해진 게 아닙니다
반년 전에 쓴 지침이 발목을 잡는 겁니다

클로드 코드가 시스템 지침 2,686단어를 514단어로 줄인 사건과,
내 지침을 정리하는 5가지 기준·프롬프트 3종을 정리했어요.
(2026년 8월 기준)

2,686→514

클로드 코드가 줄인
시스템 지침 단어 수 [2]

68.9%

지시 500개를 줄 때
가장 잘 지킨 모델의 준수율 [3]

30배

대놓고 틀리는 오류보다
조용히 빼먹는 오류가 [3]

🧹 핵심을 한 문장으로 풀면요

지침을 지웠더니 성능이 좋아진 게 아니라 아무 일도 일어나지 않았습니다. 그게 발견이에요.
그 규칙들이 애초에 하고 있던 일이 없었다는 뜻이거든요. 읽어 보면 다 그럴듯하고, 지워 봐야 드러납니다.

① 무슨 일이 있었나 ② 많을수록 나빠지는 이유 ③ 왜 길어졌나 ④ 지울 것과 남길 것 ⑤ 5가지 기준 + 예시 ⑥ 프롬프트 3종 ⑦ 지우기 전에

1 지침이 자산이라는 착각

2026년 7월 27일, 클로드 코드를 만든 보리스 체르니가 와이컴비네이터 스타트업 스쿨 무대에서 이렇게 말했어요. "6개월마다 여러분의 claude.md 파일을 지우고, 스킬을 지우고, 훅을 지우세요. 그러고 나서 모델이 어떻게 하는지 보세요. 놀랄지도 모릅니다" [1].

말만 한 게 아닙니다

오푸스 5 출시에 맞춰 클로드 코드의 시스템 지침 자체를 대폭 덜어 냈어요. 공개된 프롬프트를 실측하니 약 2,686단어에서 514단어로 줄었습니다. 메모리 기능을 켠 상태를 기준으로 해도 약 830단어이니, 어느 쪽으로 재든 원래 분량의 대부분이 사라진 셈이에요 [2].

그런데 이 절제된 사실이 오히려 더 무섭습니다

성능이 좋아졌다는 이야기라면 "더 잘 쓰는 방법이 있구나" 정도로 끝납니다. 손실이 없었다는 이야기는 다릅니다. 그 지침들이 애초에 아무 일도 하고 있지 않았다는 뜻이니까요. 몇 달에 걸쳐 쌓아 온 규칙 스무 줄이, 실은 읽히지도 지켜지지도 않은 채 자리만 차지하고 있었을 가능성이 열립니다.

📌 체르니가 권한 건 삭제가 아니라 측정입니다
"전체를 지운 다음, 한 줄씩 다시 넣으면서 각 줄이 실제로 어떤 영향을 주는지 보라"는 것입니다 [1]. 이건 이진 탐색이에요. 지침을 자산으로 여기면 절대 못 하는 실험이고, 부채로 여겨야 비로소 가능한 실험입니다.

2 왜 지침이 많을수록 나빠지는가

1) 지시 개수 자체가 준수율을 깎습니다

Distyl AI 연구진의 IFScale 벤치마크는 지시를 10개에서 500개까지 10개 단위로 늘려 가며 20개 모델을 측정했습니다 [3]. 500개 지시에서 가장 잘 지킨 모델이 68.9%, 그다음이 62.8%, 61.9%였어요. 가장 약한 모델은 6.7%까지 떨어졌습니다. 같은 모델이 250개에서는 84.8%를 지켰으니, 지시를 두 배로 늘리는 동안 준수율이 16%포인트 깎인 셈입니다 [3]. 덧붙이면, 지시를 잘 지키는지는 눈대중으로 잴 수 없어서 기계로 채점 가능한 지시 유형만 모아 평가하는 방식이 따로 만들어졌을 만큼, 이건 오래된 문제예요 [6].

2) 실패하는 방식이 더 문제입니다

같은 연구가 오류 종류를 나눠 보니, 지시가 많아질수록 모델은 잘못 수행하는 쪽이 아니라 아예 빠뜨리는 쪽으로 기울었습니다. 가장 극단적인 경우 누락 오류가 수정 오류보다 약 34.9배 많았어요 [3].

이게 실무에서 가장 위험한 대목입니다. 모델이 "지시가 너무 많아 다 못 지키겠습니다"라고 말해 주면 우리는 지침을 줄일 겁니다. 그런데 모델은 그렇게 말하지 않아요. 조용히 빼먹고, 나머지를 매끄럽게 완성해서 내놓습니다. 사용자는 무엇이 무시됐는지 알 방법이 없습니다.

3) 위치에 따라 지켜지는 정도가 다릅니다

같은 연구는 지시 밀도가 중간(150~200개) 구간일 때 앞쪽 지시를 더 잘 지키는 경향이 정점에 이르고, 밀도가 극단으로 가면 그마저 평평해진다고 보고합니다 [3]. 긴 입력에서 앞과 뒤는 살아남고 가운데가 묻히는 현상은 이미 여러 번 관찰됐어요. 리우 등은 관련 정보가 입력 한가운데 놓일 때 성능이 뚜렷하게 떨어진다는 것을 보였고, 이 U자 곡선은 긴 문맥용으로 설계된 모델에서도 사라지지 않았습니다 [4]. 홍 등의 Context Rot 보고서는 18개 최신 모델에서, 입력이 길어지기만 해도 성능이 균일하지 않게 무너진다는 것을 보였습니다. 문맥 창의 한계에 닿기 훨씬 전부터 시작되는 열화예요 [5].

세 가지를 합치면

지침을 늘리는 행위는 지시를 강화하는 게 아닙니다. 지시들끼리 자리를 다투게 만드는 일이에요. 스무 줄짜리 지침에 한 줄을 더하면, 그 한 줄이 지켜질 확률만 생기는 게 아니라 기존 스무 줄이 지켜질 확률도 함께 깎입니다.

3 그런데 왜 우리 지침은 계속 길어졌을까

이유는 단순합니다. 지침은 대부분 사고 대응으로 쓰이기 때문이에요.

모델이 한 번 엉뚱하게 굴면 우리는 그 자리에서 한 줄을 씁니다. "코드 블록 밖에 설명 쓰지 마." "임의로 파일 만들지 마." "한국어로 답해." 각각은 그 순간 합리적인 대응이었어요. 문제는 이 규칙들이 그때 그 모델의 약점을 겨냥해 쓰였고, 약점이 사라진 뒤에도 남는다는 데 있습니다.

추가에는 계기가 있는데, 삭제에는 계기가 없습니다. 체르니가 제시한 절차가 정확히 이 비대칭을 겨냥해요. "같은 지점에서 반복해서 넘어지는 걸 봤을 때, 그때 다시 넣으세요" [1]. 한 번의 실수는 규칙을 만들 근거가 되지 못한다는 뜻입니다. 재발이 근거예요.

회계로 바꿔 보면 이해가 빠릅니다
지침은 자산이 아니라 부채입니다. 쌓아 두면 그냥 늘어나는 게 아니라, 모델 세대가 바뀔 때마다 이자가 붙어요. 그리고 그 이자는 ②에서 본 대로 다른 지침들의 준수율로 갚아집니다.

4 지울 것과 남길 것, 단 하나의 판별 질문

지침 한 줄을 앞에 두고 이렇게 물으면 됩니다

"이 줄은, 모델이 더 똑똑해지면
저절로 알게 될 내용인가?"

예 → 지웁니다

그 줄은 특정 시점 모델의 약점을 메우려던 임시 조치입니다. 최신 모델은 이미 알아서 합니다.

예: "단계별로 생각해", "코드 블록을 닫아", "설명을 장황하게 쓰지 마", "마크다운 형식을 지켜", "답을 지어내지 마".

아니오 → 남깁니다

그 줄은 모델의 지능과 무관한 외부 정보예요. 크게 네 종류입니다.

1) 보안·컴플라이언스 규칙(접근 금지 경로, 다루면 안 되는 데이터)
2) 팀의 합의(코드 컨벤션, 브랜치 전략처럼 정답이 아니라 약속인 것)
3) 우리 사업만의 사실(제품명 표기, 가격 정책, 금지 표현)
4) 되돌리기 어려운 행동의 차단선(배포, 결제, 삭제)

ℹ️ 삭제를 권하는 조언이 퍼지면서 "보안 정책이나 파괴적 명령 차단까지 지우면 안 된다"는 단서가 여러 해설 글에 붙었습니다. 다만 밝혀 둘 것이 있어요. 이 단서는 체르니 본인의 발언이 아니라 기자와 실무자들이 덧붙인 논평입니다. 그럼에도 타당합니다. 위 네 종류는 "모델의 약점을 메우는 규칙"이 아니라 모델이 알 도리가 없는 외부 사실이기 때문입니다.

5 다섯 가지 기준과 before / after

기준 1. 반년마다 한 번은 비웁니다

before 반년 넘게 손대지 않은 지침 파일 20줄

after 전체를 별도 파일로 백업 → 본 파일을 비움 → 일주일 쓰면서 실제로 넘어지는 지점만 다시 추가

삭제에는 계기가 없기 때문에 달력으로 계기를 만들어 줘야 합니다.

기준 2. 새 모델이 나오면 처음부터 다시 씁니다

before "단계별로 차근차근 생각한 다음 답해."

after (삭제)

추론이 기본 탑재된 세대에서는 이 지시가 추가로 주는 이점이 없습니다. 체르니가 오푸스 5에 대해 "이전 모델에 필요했던 방대한 지침이 이제는 필요 없을 수 있다"고 말한 게 이 경우예요 [1].

기준 3. 같은 실수가 두 번 반복될 때만 추가합니다

before 실수 한 번 → 규칙 한 줄. 이 습관으로 지침이 점차 방대해집니다.

after 실수를 규칙이 아니라 메모로 먼저 남기고, 같은 메모가 두 번째 쌓이면 그때 규칙으로 승격

체르니의 표현 그대로 "반복해서 같은 지점에서 넘어질 때, 그때 다시 넣는" 것입니다 [1]. 1회성 사고에 규칙을 발행하면 부채만 늘어나요.

기준 4. 단계 대신 목표·지킬 선·잘된 기준을 줍니다

before "1단계 파일을 읽어. 2단계 함수를 찾아. 3단계 수정해. 4단계 테스트를 돌려. 5단계 보고해."

after "목표: 이 버그를 고친다 / 지킬 선: 공개 API 시그니처는 바꾸지 않는다 / 잘된 기준: 재현 테스트가 실패에서 통과로 바뀐다"

체르니의 조언은 "할 일을 설명하고, 가드레일을 설명하고, 종료 조건을 설명한 다음, 모델이 알아서 하게 두라"입니다 [1]. 단계를 못 박으면 모델이 찾을 수 있었던 더 짧은 경로가 막혀요.

기준 5. 마이크로 매니징하지 말고 맡깁니다

before 스무 개로 쪼갠 지시를 순서대로 던지기

after 한 번에 맡기고, 결과를 보고 개입할 지점만 고르기

체르니는 이 변화를 "지능 수준이 비슷한 동료를 대하듯"이라고 표현했습니다 [1]. 덧붙이면 ②에서 본 대로 지시 개수 자체가 준수율을 깎기 때문에, 잘게 쪼개는 방식은 두 번 손해예요.

6 정리 프롬프트 3종

순서대로 쓰세요. 1번으로 분류하고 → 2번으로 되돌리고 → 3번으로 남은 것을 다시 씁니다.

프롬프트 1. 지침 감사 (지울 것과 남길 것 분류)

아래는 내가 지금 쓰고 있는 AI 지침 파일이야.
---
[지침 전문 붙여넣기]
---
각 줄을 아래 세 가지 중 하나로 분류하고, 한 줄 근거를 붙여 줘.
A. 지워도 됨: 너 정도 성능의 모델이면 지시 없이도 이미 하는 내용
B. 남겨야 함: 보안·컴플라이언스, 팀 합의, 우리 사업만의 사실,
   되돌리기 어려운 행동의 차단선처럼 네가 알 수 없는 외부 정보
C. 판단 보류: 근거가 부족해 확신할 수 없음
칭찬이나 완충 표현은 쓰지 마. A로 분류한 줄은 개수를 세어서 알려 줘.

④의 판별 질문을 모델 자신에게 던지는 형태예요. "너 정도 성능이면 이미 하는 내용"이라는 조건이 핵심입니다. A의 개수를 세게 하는 것도 일부러예요. 숫자로 보면 지울 결심이 섭니다.

프롬프트 2. 이진 탐색 복원 (지운 뒤 한 줄씩 되돌리기)

방금 지침을 전부 비운 상태에서 다음 작업을 시켰어: [작업 설명]
결과에서 내가 원래 걸어 뒀던 규칙과 어긋난 지점만 찾아 줘.
① 어긋난 지점 각각에 대해, 그걸 막으려면 어떤 규칙 한 줄이 필요한지 써 줘.
② 그 규칙이 이 작업 한 번에만 해당하는 일회성인지,
   앞으로도 반복될 성질인지 구분해 줘.
③ 일회성이면 규칙으로 만들지 말라고 명시해 줘.
반복될 성질로 판정한 것만 최종 목록에 올려 줘.

체르니가 말한 "한 줄씩 다시 넣으면서 영향을 보라"를 대화로 옮긴 것입니다 [1]. ②·③이 기준 3(재발이 근거)을 강제하는 장치예요. 이게 없으면 결국 원래 스무 줄로 되돌아갑니다.

프롬프트 3. 단계형을 목표형으로 재작성

아래 지시문은 단계를 하나하나 지정하는 방식이야.
---
[단계형 지시문 붙여넣기]
---
이걸 세 부분으로 다시 써 줘.
① 목표: 무엇이 끝나면 되는가 (한 문장)
② 지킬 선: 무슨 일이 있어도 하면 안 되는 것 (3개 이내)
③ 잘된 기준: 결과가 맞는지 내가 확인할 수 있는 방법 (검증 가능한 형태로)
원래 단계 중에서 ①~③에 흡수되지 않고 남는 게 있으면,
그게 정말 필요한 제약인지 아니면 습관인지 표시해 줘.

기준 4를 실행하는 프롬프트입니다. 마지막 문장이 중요해요. "흡수되지 않고 남는 것"을 스스로 표시하게 하면, 우리가 필요하다고 믿었던 단계 대부분이 실은 습관이었다는 게 드러납니다.

7 지우기 전에 반드시

체르니의 조언에는 안전장치가 함께 붙어 있습니다. 지우기 전에 어딘가에 저장해 두라는 것, 그리고 예전에 못 풀던 어려운 문제를 다시 던져 보면서 프롬프트를 줄였을 때 어떻게 하는지 관찰해 보라는 것입니다 [1].

ⓐ 백업은 파일 복사가 아니라 버전 관리로

되돌릴 때 필요한 건 "예전 파일"이 아니라 "어느 줄을 언제 왜 넣었는지"입니다.

ⓑ 비운 직후가 아니라 일주일 뒤에 판단하기

②에서 본 누락 오류의 성질상, 지침이 있을 때 무엇이 무시되고 있었는지는 즉시 드러나지 않습니다.

두 줄을 함께 넣으면 어느 쪽이 효과를 냈는지 영영 알 수 없습니다.

⚠️ 이 이야기는 지침 파일에서 끝나지 않습니다

지침을 길게 쓰는 사람의 심리는 "내가 원하는 걸 빠짐없이 못 박아야 원하는 결과가 나온다"입니다. 기획에서 같은 심리는 "내가 답을 다 정해 두어야 시장이 따라온다"로 나타나요.
두 경우 모두, 정해 두는 항목이 늘어날수록 상대가 알려 줄 수 있는 정보가 줄어듭니다. 모델에게 스무 단계를 지정하면 모델이 찾을 수 있었던 더 나은 경로가 막히고, 기획에서 답을 다 정해 두면 고객이 실제로 무엇을 원하는지 말할 자리가 사라집니다.

💡 지침은 자산이 아니라 부채입니다

2,686단어를 514단어로 줄였을 때 벌어진 일은 성능 향상이 아니라 아무 일도 벌어지지 않았다는 것이었습니다. 그 지침들이 하고 있던 일이 원래 없었다는 뜻이니까요.
우리 파일에도 같은 줄들이 섞여 있을 가능성이 높습니다. 확인하는 방법은 읽어 보는 게 아니라 지워 보는 것이에요. 읽으면 전부 그럴듯해 보이고, 지워야 무엇이 실제로 일하고 있었는지 드러납니다.

참고 문헌 (References)

[1] B. Cherny, "Building Claude Code," Y Combinator Startup School 2026, Mountain View, CA, Jul. 27, 2026.
[2] M. Quimby, "Claude Code Cut 80% of Its Prompt. Yours Should Too," DEV Community, Aug. 2026.
[3] D. Jaroslawicz et al., "How Many Instructions Can LLMs Follow at Once?," arXiv preprint arXiv:2507.11538, 2025.
[4] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, "Lost in the Middle: How Language Models Use Long Contexts," Transactions of the Association for Computational Linguistics, vol. 12, pp. 157-173, 2024.
[5] K. Hong, A. Troynikov, and J. Huber, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," Chroma Technical Report, Jul. 14, 2025.
[6] J. Zhou et al., "Instruction-Following Evaluation for Large Language Models," arXiv preprint arXiv:2311.07911, 2023.

설정

AI가 멍청해진 게 아닙니다반년 전에 쓴 지침이 발목을 잡는 겁니다