이런 상황을 겪어보셨을 겁니다. 코딩 에이전트에게 "내가 건드려달라고 요청하지 않은 파일은 수정하지 마세요"라는 명확한 규칙을 주었습니다. 처음에는 잘 작동합니다. 하지만 20분이 지나고 수십 번의 도구 호출 (tool calls)이 이루어진 후, 에이전트는 당신이 언급조차 하지 않은 세 개의 파일을 수정해 버리고, 테스트 스위트 (test suite)가 실패(red)로 뜨면서 그 사실을 알게 됩니다.

규칙은 프롬프트 (prompt)에서 사라진 적이 없습니다. 에이전트가 단지 그 규칙을 따르는 것을 멈춘 것뿐입니다. 오류도, 경고도 없었습니다. 조용히 수명이 다해 사라진 것입니다.

이것은 지능의 문제도 아니고 운이 나쁜 것도 아닙니다. 이것은 구조적인 문제이며, 측정 가능합니다. 일단 그 메커니즘을 이해하면 영구적으로 막을 수 있습니다. 여기 실패 사례, 효과 없는 해결책들, 진짜 원인, 그리고 재구축 방법이 있습니다.

실패 사례
당신의 CLAUDE.md (또는 .cursorrules — 내용은 동일합니다)가 다음과 같이 시작한다고 가정해 봅시다:

"먼저 묻지 않고 src/payments/ 디렉토리 외부의 파일을 절대 수정하지 마세요."

세션 초기에는 에이전트가 완벽합니다. 범위를 벗어나기 전에 먼저 물어봅니다. 그러다 당신이 다단계 작업(multi-step task)을 지시합니다. "이 파일들을 읽고, 테스트를 실행하고, 실패를 수정하고, 헬퍼(helper)를 리팩터링하세요." 각 단계마다 도구 호출 (tool calls)과 출력값이 컨텍스트 (context)에 쌓입니다. 15번째 도구 호출 즈음, 에이전트는 당신이 범위에 넣은 적도 없는 src/auth/session.ts 파일을 "임포트(import)를 수정하기 위해" 수정해 버리고, 아무 일도 없었다는 듯이 계속 진행합니다.

Cursor 포럼의 한 개발자는 제가 말하는 것보다 더 깔끔하게 표현했습니다: "우리의 규칙을 따를 것이라고 믿을 수 없다면, 어떻게 그 어떤 출력값도 신뢰할 수 있겠습니까?"

효과 없는 해결책들
대부분의 사람들은 세 가지 방법 중 하나를 시도하지만, 세 가지 모두 동일한 이유로 실패합니다.

1. 규칙을 더 크게 쓰기. 굵게(Bold) 만들기. 모두 대문자로 쓰기. "중요(IMPORTANT)"와 느낌표 세 개를 추가하기. 이렇게 하면 도움이 될 것 같지만, 그렇지 않습니다. 더 강한 어조의 표현도 원래 문장과 동일한 주의력 역학 (attention dynamics)의 영향을 받기 때문입니다 (codeongrass, 2026).
2. 시스템 프롬프트(system prompt)에 규칙을 다섯 번 반복하기. 이제 프롬프트 토큰을 더 많이 소모하게 되었고, 동일한 성능 저하가 나타나기 전까지 아주 약간의 순응(compliance)을 더 얻어냈을 뿐입니다.
3. 더 큰 컨텍스트 윈도우 (context window) 구매하기. 가장 비용이 많이 들면서도 해결책이 되지 않는 방법입니다. Chroma의 컨텍스트 부패 (Context Rot) 연구 (2025년 7월 14일)는 18개의 프런티어 모델(frontier models) — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — 을 테스트했으며, 모든 모델이 입력값이 커질수록 정확도가 떨어졌고, 특히 100K에서 500K 토큰 사이에서 가장 급격한 하락을 보였습니다. 백만 토큰 규모의 윈도우도 이 문제를 해결하지 못하며, 단지 문제를 인지하게 되는 시점을 늦출 뿐입니다.

구조적 원인
모델은 컨텍스트 내의 모든 토큰에 주의(attend)를 기울이지만, 모든 토큰에 동일하게 기울이지는 않습니다. 주의력 (Attention)은 최신성 (recency)과 밀도 (density)에 의해 형성됩니다. 당신의 규칙은 맨 위에서 단 한 번 작성되었습니다. 그 이후로 컨텍스트는 도구 호출 (tool calls), 파일 덤프 (file dumps), 그리고 에이전트 자신의 추론 (reasoning)으로 채워졌습니다. 이 수천 개의 토큰은 모두 규칙보다 더 최신입니다. 약 15번의 도구 호출이 지나면, 시스템 프롬프트는 최근 토큰들의 바다 속에 떠 있는 작고 오래된 섬이 됩니다. 그 유효한 가중치 (effective weight)는 떨어지고, 제약 조건은 더 이상 방향을 잡지 못합니다. 한 엔지니어는 이 임계값을 직접 기록했습니다: Claude 에이전트는 높은 컨텍스트 깊이에서의 주의력 희석 (attention dilution)으로 인해 약 15번의 도구 호출 이후에는 시스템 프롬프트의 제약 조건을 안정적으로 위반합니다 — 형식 요구 사항 무시, 승인 게이트 (approval gates) 건너뛰기, 자율성 규칙 우회 등이 모두 오류 없이 발생합니다 (codeongrass, 2026).

이는 코딩을 넘어 확장됩니다. 널리 인용되는 2025년의 한 분석에 따르면, 기업용 에이전트 실패의 거의 65%는 모델의 무능력이 아니라, 다단계 추론 (multi-step reasoning) 과정 중 발생하는 컨텍스트 드리프트 (context drift)와 메모리 손실 때문인 것으로 나타났습니다. 이러한 실패는 조용히 일어납니다: 에이전트는 사실상 잊어버린 규칙을 바탕으로 작동하면서도, 확신에 차 있고 그럴듯한 출력을 생성합니다. 따라서 규칙이 무시되는 것이 아닙니다. 당신이 그 이후에 추가한 모든 것들에 의해 규칙의 투표권이 밀려나는 것입니다.

재구축(The rebuild) 만약 문제가 규칙이 너무 오래되었거나 멀리 떨어져 있다는 것이라면, 해결책은 규칙을 그것이 정확히 필요한 순간에 최근의 것으로, 그리고 가깝게 만드는 것입니다. 규칙을 모델이 반드시 기억해야 하는 무언가로 취급하는 것을 멈추세요. 규칙을 모델이 반드시 수행해야 하는 단계로 만들고, 규칙을 위반하기 쉬운 동작 바로 직전에 다시 명시하세요.

4. 제약 사항을 동작 시점으로 이동시키세요.
   이전: # CLAUDE.md 묻지 않고 src/payments/ 외부의 파일을 편집하지 마십시오.
   이후: # CLAUDE.md 모든 파일 편집 전에, 다음 게이트(gate)를 출력하고 실패 시 중단하십시오:

   • 범위 내 파일들:
   • 내가 편집하려는 파일:
   • 범위 내에 있는가? 아니라면, 진행하기 전에 물어보십시오.
     이제 규칙은 가장 오래된 것이 아니라, 결정이 내려지는 순간 컨텍스트(context) 내에서 가장 최근의 것이 됩니다.

5. 바람직한 행동을 금지된 행동이 아닌, 필수적인 행동으로 만드세요. "범위를 벗어난 파일을 편집하지 마십시오"는 하지 말아야 할 일이며, 잊히기 쉽습니다. "편집하기 전에 파일을 명시하고 범위 내에 있는지 확인하십시오"는 해야 할 일이며, 이는 트랜스크립트(transcript)에서 확인할 수 있는 흔적(artifact)을 남깁니다. 금지는 퇴색되지만, 요구는 흔적을 남깁니다.

6. 경계에서 재주입(Re-inject)하세요. 만약 당신의 하네스(harness)가 허용한다면, 위험한 단계 직전의 마지막 사용자 턴(user turn)에서 가장 중요한 규칙 하나를 반복하세요. 마지막 메시지는 가장 높은 유효 주의력(effective attention)을 받습니다. 놓쳐서는 안 될 제약 사항을 위해 그 슬롯을 사용하세요. "중요한 지침을 마지막에 배치하라"는 말이 여전히 효과적인 것과 같은 이유입니다.

이 세 가지 패턴의 밑바탕에 깔린 원리는 다음과 같습니다: 모델에게 늘어나는 컨텍스트(context) 전체에 걸쳐 규칙을 유지하라고 요구하지 마세요. 결정이 내려지는 순간마다 규칙을 다시 제시하세요. 동일한 모델이라도 형태를 다르게 하면, 도구 호출(tool call) 5번째 때와 50번째 때의 규칙 준수력은 동일하게 유지됩니다. 4단계 체크리스트

모든 필수 규칙(must-hold rule)이 모델이 기억해야 할 문장이 아니라, 모델이 수행하는 단계(step)로 정의되어 있습니까? 상단에 한 번 명시된 규칙은 시간이 지나면서 효력이 약해집니다.

규칙이 제어하는 행동 바로 옆에 위치해 있습니까? 결정 지점으로부터의 거리는 곧 규칙의 퇴화(decay)와 같습니다.

준수 여부가 가시적입니까? 에이전트가 트랜스크립트(transcript) 상에서 답변해야 하는 규칙이, 단순히 묵묵히 따라야 하는 규칙보다 훨씬 효과적입니다.

도구 호출(tool call) 15회 이후에도 테스트를 진행했습니까? 규칙 누락(rule-drop)은 주로 세션의 깊은 단계에서 나타납니다. 5회 호출 정도의 데모로는 아무것도 증명할 수 없습니다.

한 가지 더

만약 시작할 때는 잘 작동하다가 끝날 때쯤 흐트러지는 프롬프트를 가지고 있다면, 그것이 바로 제가 다시 설계(rebuild)하는 실패 사례의 전형입니다. 저는 매주 한 번씩 짧은 분석(teardown)을 공유합니다. 실제로 불안정한(flaky) 프롬프트, 그것이 깨진 구조적 원인, 그리고 이를 유지해내는 재설계 방안을 다룹니다. 관심 있다면 DM 주세요.