AI 에이전트가 내가 작성한 지침 파일을 무시하는 이유 (2026)

1. 파일이 전혀 로드되지 않음

가장 흔하면서도 당혹스러운 원인입니다. 보통 아무런 에러도 발생하지 않기 때문입니다.

Cursor는 이에 대해 가장 명확하게 설명합니다. ".cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 frontmatter가 없기 때문에 규칙 시스템에서 무시됩니다." 파일이 올바른 디렉토리에 그럴듯한 이름으로 존재하더라도, 아무런 경고 없이 건너뛰게 됩니다. 이는 규칙이 일반 마크다운이었던 다른 도구에서 마이그레이션한 직후에 가장 자주 겪는 문제입니다. 폴더를 그대로 복사해 왔고 모든 것이 올바르게 보이지만, 실제로는 아무것도 적용되지 않는 상황입니다.

Zed는 결과는 같지만 다른 형태의 함정을 가지고 있습니다. Zed의 프로젝트 지침은 .rules, .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, GEMINI.md와 같은 파일 이름 목록에서 가져오는데, 문서에 따르면 "Zed는 이 목록에서 가장 먼저 일치하는 파일을 사용합니다"라고 되어 있습니다. 병합되거나 가장 구체적인 파일이 적용되는 것이 아니라, '가장 먼저 일치하는' 파일 하나만 적용됩니다. 6개월 전 실험용으로 남겨둔 .cursorrules 파일이 어제 작성한 AGENTS.md보다 우선순위가 높아지는 것입니다.

GitHub Copilot은 위치 문제로 사람들을 혼란스럽게 만듭니다. 문서에 따르면 리포지토리 내 어디에나 AGENTS.md 파일을 둘 수 있으며 디렉토리 트리에서 가장 가까운 파일이 우선 적용되지만, CLAUDE.md나 GEMINI.md는 리포지토리 루트에 있는 대안으로만 나열되어 있습니다. 모노레포 환경에서 이 차이점은 루트에 있는 파일은 잘 작동하더라도 하위에 중첩된 CLAUDE.md 파일들은 Copilot에게 전혀 보이지 않는다는 것을 의미합니다.

이 세 가지 경우를 확인하는 방법은 동일합니다. 내용을 수정하기 전에 파일 이름, 위치, 그리고 도구에서 요구하는 경우 frontmatter가 제대로 작성되었는지 확인하는 것입니다.

2. 로드는 되었으나, 현재 컨텍스트에 없음

이 원인은 더 교묘합니다. 파일이 유효하고 읽히고는 있지만, 정작 중요한 순간에 컨텍스트에 포함되어 있지 않기 때문입니다.

범위가 지정된 규칙은 일치하는 작업에만 적용됩니다. Cursor의 네 가지 적용 모드는 규칙이 컨텍스트에 들어가는 시점을 결정합니다. 항상 적용되는 alwaysApply: true, 지능적 적용을 위한 description, 특정 파일을 위한 globs, 그리고 명시적인 @-mention이 필요한 수동(manual) 규칙이 있습니다. 수동으로 설정된 규칙은 스스로 삽입되지 않습니다. Claude Code의 .claude/rules/도 비슷하게 작동합니다. paths: frontmatter 필드가 있는 규칙은 Claude가 일치하는 파일로 작업할 때 적용되는 반면, "paths 필드가 없는 규칙은 무조건 로드됩니다." Cline의 조건부 규칙도 동일한 방식으로 작동하여 열려 있는 파일, 보이는 탭, 언급된 경로, 편집 중인 파일 등 현재 작업에 대해 평가된 frontmatter glob 패턴을 기반으로 활성화됩니다.

이 중 어느 것도 버그가 아닙니다. 컨텍스트 크기를 작게 유지하기 위한 메커니즘입니다. 하지만 이는 "규칙이 존재한다"와 "규칙이 모델 앞에 놓여 있다"가 서로 다른 상태임을 의미합니다. src/api/**로 범위가 지정된 규칙은 에이전트가 컴포넌트를 편집하는 동안에는 실제로 로드되지 않습니다.

온디맨드 지식은 호출되기 전까지 선반 위에 머물러 있습니다. Zed의 Skills는 관련이 있거나 사용자가 호출할 때 에이전트가 로드하는 폴더입니다. 이는 효율적이지만, 항상 적용되고 있다고 생각했던 Skill이 실제로는 한 번도 로드되지 않았을 수 있음을 의미합니다. 일반적인 스킬도 마찬가지이며, 이것이 스킬이 메모리를 대체할 수 없는 이유입니다. 이에 대한 차이점은 왜 에이전트 스킬이 메모리가 아닌가에서 다루고 있습니다.

압축(Compaction) 과정에서 로드된 내용의 일부가 유실됩니다. 이 목록에서 가장 간과하기 쉬운 부분입니다. Claude Code 문서에 따르면 프로젝트 루트의 CLAUDE.md는 압축 과정에서도 살아남아 디스크에서 다시 읽혀 재주입되지만, "하위 디렉토리의 중첩된 CLAUDE.md 파일과 paths: frontmatter가 있는 규칙은 자동으로 재주입되지 않습니다. Claude가 해당 하위 디렉토리의 파일을 다시 읽거나 규칙 패턴과 일치하는 파일을 읽을 때만 다시 로드됩니다."

실제 세션 상황에 대입해 보십시오. 한 시간 동안 작업을 진행하면 컨텍스트가 압축되고, 그 시점부터 에이전트는 루트 지침만 가지고 작동하며 이전에 가지고 있던 디렉토리별 규칙은 유실됩니다. 일치하는 파일을 다시 건드리기 전까지는 말이죠. 세션 중간에 동작이 바뀌고, 에러는 발생하지 않으며, 나중에 돌아와서 확인한 규칙 파일은 완벽해 보입니다.

3. 로드는 되었으나, 다른 내용과 모순됨

이러한 시스템들은 모두 여러 소스를 계층화하여 사용하며, 충돌을 해결하는 방식도 제각각입니다.

Cline은 대체하기보다 결합합니다. "Cline은 .clinerules/ 내부의 모든 .md 및 .txt 파일을 처리하여 하나의 통합된 규칙 세트로 결합합니다." 또한 범위 전반에 걸쳐 "워크스페이스 규칙과 글로벌 규칙이 모두 존재할 때 Cline은 이를 결합합니다. 충돌이 발생하면 워크스페이스 규칙이 글로벌 규칙보다 우선합니다."라고 명시하고 있습니다. 또한 "frontmatter가 없는 규칙은 항상 활성화됩니다"라고 언급되어 있어, 오래된 항상 켜져 있는 파일이 새 파일과 영원히 충돌을 일으킬 수 있습니다.

Claude Code는 파일 시스템 루트부터 작업 디렉토리까지 디렉토리 트리를 따라 올라가며 내용을 연결(concatenate)합니다. 그리고 문서는 그 결과에 대해 직접 경고합니다. "두 규칙이 서로 모순되는 경우 Claude는 임의로 하나를 선택할 수 있습니다." 따라서 CLAUDE.md, 중첩된 파일, .claude/rules/를 주기적으로 검토할 것을 권장합니다.

Copilot은 명시된 순위에 따라 여러 레이어를 동시에 제공합니다. "개인 지침이 가장 높은 우선순위를 가집니다. 그 다음은 리포지토리 지침이며, 조직 지침이 마지막으로 우선순위를 갖습니다. 그러나 관련된 모든 지침 세트가 Copilot에 제공됩니다." 마지막 문장이 중요합니다. 우선순위가 낮다고 해서 제외되는 것은 아닙니다. 조직에 설정된 지침이 있다면, 한 번도 만난 적 없는 누군가가 작성한 지침이 조용히 포함되어 내가 설정하지 않은 방식으로 출력을 유도하고 있을 수 있습니다.

Zed는 리포지토리 파일에 대해 반대로 해결합니다. "충돌이 발생하면 프로젝트 지침이 개인 AGENTS.md보다 우선합니다."

에이전트의 동작이 일관성 없어 보일 때(월요일에는 규칙을 따르다가 화요일에는 따르지 않는 등), 모델의 변덕보다는 레이어 간의 모순을 첫 번째 가설로 세우는 것이 좋습니다.

4. 로드되었고 명확했으나, 모델이 준수하지 않음

이것은 실제 발생하는 문제이며, 벤더들의 자체 문서에서 미리 경고하는 유일한 항목입니다.

Claude Code 문서는 이 메커니즘을 다음과 같이 설명합니다. "CLAUDE.md 콘텐츠는 시스템 프롬프트의 일부가 아니라 시스템 프롬프트 뒤에 사용자 메시지로 전달됩니다. Claude는 이를 읽고 따르려고 노력하지만, 특히 모호하거나 모순되는 지침의 경우 엄격한 준수를 보장하지는 않습니다." 다른 곳에서는 지침을 "강제된 구성이 아닌 컨텍스트"로 설명합니다. Cursor도 동일한 개념을 긍정적으로 표현합니다. "대형 언어 모델은 완성(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다."

프롬프트 수준의 컨텍스트일 뿐입니다. 구성도, 정책도, 보장도 아닙니다. 따라서 절대 깨져서는 안 되는 규칙에 대한 유일하고 올바른 대응은 이를 지침으로 표현하지 않는 것입니다. 두 생태계 모두 동일한 대안을 제시합니다. 고정된 라이프사이클 이벤트에서 명령어로 실행되는 훅(hook)이나 CI에서의 검사입니다. 린트(lint) 규칙은 설득할 필요가 없습니다.

규칙을 더 강하게 강조하기. 대문자 사용, "IMPORTANT:", "MUST" 등의 표현을 쓰는 것입니다. 아주 미미하게 도움이 될 때도 있지만, 앞의 세 가지 실패 유형에는 아무런 효과가 없으며 파일 유지관리를 어렵게 만드는 노이즈만 추가할 뿐입니다.

파일을 더 길게 만들기. 규칙을 놓쳤을 때 반사적으로 더 자세히 설명하려고 하지만, 이는 파일을 더 크게 만들고 결과적으로 준수율을 떨어뜨립니다. 벤더들의 의견은 일치합니다. Cursor는 규칙을 500행 미만으로 유지하고 큰 규칙은 조합 가능한 조각으로 나눌 것을 권장하며, Claude Code는 파일당 200행 미만을 목표로 할 것을 권장하면서 "파일이 길어질수록 더 많은 컨텍스트를 소비하고 준수율이 떨어집니다"라고 지적합니다.

모든 것을 항상 적용(always-apply)으로 설정하기. 무차별 대입(brute force) 방식으로 실패 유형 2를 해결하지만, 대규모로 실패 유형 3을 만들어냅니다. 이제 모든 작업에서 모순되는 규칙을 포함한 모든 규칙이 항상 컨텍스트에 포함됩니다.

모든 도구에 대해 파일을 복제하기. 동일한 내용으로 .cursorrules, CLAUDE.md, copilot-instructions.md를 모두 만드는 것입니다. 일주일 동안은 잘 작동할 것입니다. 그러다 하나가 업데이트되면 보이지 않는 모순이 발생하고, Zed의 경우 오래된 파일이 목록의 맨 위에 있어 우선 적용될 가능성이 매우 높습니다.

모델을 탓하고 도구를 바꾸기. 비용이 많이 드는 방식입니다. 새 도구에는 자체 로딩 규칙이 있으며, 동일한 네 가지 실패 유형이 다른 형태로 다시 나타날 뿐입니다.

한 걸음 물러서서 보면, 대부분의 비대해진 지침 파일은 서로 무관한 두 가지 작업을 동시에 수행하려고 합니다. 매번 모델 앞에 반드시 놓여 있어야 하는 아주 소수의 항목(컨벤션, 금지 사항, 명령어)이 있습니다. 그 외의 모든 것은 지식입니다. 아키텍처 결정, 제약 조건이 존재하는 이유, 시도했다가 거부된 방안, 하위 시스템의 작동 방식 등입니다. 이러한 자료는 항상 상주할 필요가 없습니다. 관련이 있을 때 찾을 수만 있으면 됩니다.

이 둘을 분리하면 처음 세 가지 실패 유형을 구조적으로 해결할 수 있습니다. 항상 켜져 있는 짧은 파일은 로드 여부를 확인하기 쉽고, 모순이 발생하기 어려우며, 컨텍스트에 유지하는 비용도 저렴합니다. 그리고 지식은 도구가 읽을지 안 읽을지 모르는 파일 안에서 공간을 다투는 대신, 검색이 가능한 곳으로 이동합니다.

MemoryLake는 바로 그 두 번째 레이어입니다. 각 도구의 파일 이름 규칙이나 우선순위 규칙에 구애받지 않고, 에이전트가 읽을 수 있는 단일 메모리 저장소입니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 모든 에이전트에서 하나의 자격 증명만 사용하면 됩니다. 각 도구마다 파일 위치에 대한 기준이 다르기 때문에 이 점이 특히 중요합니다.

2단계: 첫 번째 메모리 업로드

규칙 파일에서 참고 자료를 분리해 내십시오. 아키텍처 결정과 그 근거, 컨텍스트 없이는 임의적으로 보이는 제약 조건, 시도했다가 포기한 접근 방식, 사람들이 계속해서 다시 설명해야 하는 하위 시스템의 동작 등입니다. 각 항목은 짧고 단일 주제로 유지하십시오. 규칙 파일에 남겨두어야 할 것은 코드 리뷰에서 당당하게 옹호할 수 있는 짧은 목록뿐입니다.

3단계: AI 및 에이전트 연결

도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 도구들은 API를 통해 동일한 메모리를 읽습니다. 각 도구는 항상 적용되어야 하는 규칙 세트를 위해 자체적인 작은 지침 파일만 유지하고, 서로 다르게 파편화된 5개의 복사본 대신 동일한 지식 체계를 활용하게 됩니다.

이 글의 주제와 관련된 두 가지 분명한 한계가 있습니다. 메모리 레이어는 실패 유형 4를 해결하지 못합니다. 이것은 여전히 컨텍스트일 뿐 강제 수단이 아니며, 모델의 결정과 무관하게 반드시 유지되어야 하는 것은 훅이나 CI에 속해야 합니다. 또한 파일이 로드되도록 만들어주지도 않습니다. .cursor/rules가 일반 .md 파일로 가득 차 있다면, 그것은 여전히 직접 해결해야 하는 frontmatter 문제입니다.

진단이 빨라집니다. 항상 켜져 있는 짧은 파일을 사용하면, 400행의 혼잡한 내용 속에 묻혀 있는 대신 "로드되었는가?"에 대한 답을 한눈에 확인할 수 있습니다.

모순이 줄어듭니다. 대부분의 모순은 서로 다른 사람들이 서로 다른 시기에 편집한 긴 파일에서 발생합니다. 단일 작업을 수행하는 짧은 파일은 그러한 모순이 누적될 가능성이 훨씬 적습니다.

모델을 바꾸지 않고도 준수율이 올라갑니다. 이는 직관에 반하는 부분입니다. 지침 파일에서 텍스트를 제거하면 보통 준수율이 향상됩니다. 남은 규칙들이 참고 자료와 주의 집중을 두고 경쟁하지 않기 때문입니다.

도구 마이그레이션 시 설정이 초기화되지 않습니다. 지식이 도구 전용 파일에 들어있지 않다면, 에디터를 바꿀 때 모든 것을 처음부터 다시 구성할 필요 없이 새 도구의 형식에 맞춰 짧은 규칙 파일 하나만 작성하면 됩니다. 이는 CLAUDE.md를 GitHub Copilot으로 마이그레이션하기에서 확인할 수 있는 차이점입니다.

세션 중간의 동작이 안정화됩니다. 영구적인 지식이 압축 후 우연히 상주하게 된 파일에 의존하는 대신 검색 가능해지면, 세션이 진행됨에 따라 에이전트가 조용히 정보를 잃어버리는 현상이 사라집니다.

파일이 로드되는지 확인하십시오. Claude Code는 세션 내에서 /context를 통해 로드된 메모리 파일을 보여주며, 어떤 지침 파일이 언제, 왜 로드되는지 정확히 기록하는 InstructionsLoaded 훅을 제공합니다. 모델의 잘못이라고 가정하기 전에 사용 중인 도구가 제공하는 동등한 기능을 사용해 보십시오.

필요한 곳에 frontmatter가 있는지 확인하십시오. .cursor/rules에서 일반 .md 파일은 무시됩니다. 이는 발견 확률이 높은 5분짜리 점검 항목입니다.

경쟁하는 파일 이름 목록을 확인하십시오. 특히 Zed에서는 9개의 이름 목록을 살펴보고 남은 파일들을 삭제하거나 통합하십시오. 아무런 경고 없이 첫 번째로 일치하는 파일이 우선 적용됩니다.

규칙에 범위가 지정되어 있는지 확인하십시오. paths:, globs:, 또는 applyTo 패턴이 있다면 일치하는 파일이 작업 중이지 않은 한 규칙이 누락됩니다. 수동 모드(manual-mode) 규칙은 스스로 로드되지 않습니다.

세션이 압축되었는지 확인하십시오. 긴 세션 도중에 동작이 변경되었다면, 중첩된 파일과 경로 범위 규칙이 재주입되지 않았을 수 있습니다. 새 세션을 시작하는 것이 빠른 확인 방법입니다.

한 단계 상위 레이어를 확인하십시오. Copilot에서는 개인, 리포지토리, 조직 지침이 모두 제공되며, Cline에서는 워크스페이스와 글로벌 규칙이 결합되고, Claude Code에서는 전체 디렉토리 트리가 연결됩니다. 모순을 일으키는 규칙은 내가 작성하지 않은 파일에 들어있을 수 있습니다.

그러고 나서야 비로소 구체성을 위해 규칙을 다시 작성하십시오. 구체적인 것이 추상적인 것보다 낫습니다. "코드를 올바르게 포맷팅하십시오" 대신 "2칸 들여쓰기를 사용하십시오"라고 적으십시오. 이것이 실패 유형 4에 대한 해결책이며, 앞의 세 가지 유형을 배제한 후에만 효과가 있습니다.

"에이전트가 내 규칙을 무시한다"는 같은 옷을 입은 네 가지 서로 다른 문제입니다. 그중 세 가지는 설정 문제이며 명확한 해결책이 있습니다. 파일 이름과 frontmatter를 확인하고, 규칙에 범위가 지정되어 있거나 압축 시 유실되었는지 확인하고, 모순되는 다른 내용이 로드되었는지 확인하는 것입니다. 네 번째는 모든 벤더가 미리 문서화해 둔 진정한 한계(지침은 컨텍스트일 뿐 강제 수단이 아님)이며, 이에 대한 해결책은 더 강한 형용사를 쓰는 것이 아니라 훅이나 CI 검사를 도입하는 것입니다.

이러한 일이 계속 발생하는 이유는 지침 파일이 지식 베이스처럼 사용되기 때문입니다. 이로 인해 파일이 길어지고, 네 가지 실패 유형이 동시에 악화됩니다. 항상 켜져 있는 규칙 세트는 검증하기 쉬울 정도로 짧게 유지하고, 참고 지식은 검색 가능한 곳으로 이동시키며, 타협할 수 없는 규칙은 제안이 아닌 강제되는 곳에 두십시오. 특정 도구에서 이 문제를 겪고 계신다면, 도구별 가이드가 Cursor, Claude Code, Copilot, Cline, Windsurf, Zed에 준비되어 있습니다.