Warp 에이전트가 프로젝트 규칙을 실제로 적용하게 만드는 방법 (2026)

파일 이름은 대소문자를 구분하며, 오직 하나의 케이스만 작동합니다

프로젝트 규칙(Project Rules)은 "코드베이스에 상주하며 해당 프로젝트 내에서 작업할 때 자동으로 적용"되며, "AGENTS.md 파일(또는 하위 호환성을 위한 WARP.md)"에 저장됩니다. 새로운 프로젝트를 위한 Warp의 가이드는 AGENTS.md를 권장합니다.

대문자 필수 요구 사항은 문서에서 '주의(Caution)'로 표시되어 있으며, 이는 적절한 심각도입니다. 이 오류는 아무런 표시 없이 조용히 실패하기 때문에, 파일 이름보다는 기능 자체를 의심하게 만듭니다. 규칙을 작성해도 아무것도 바뀌지 않으니 에이전트가 규칙을 무시한다고 결론을 내리게 되는 것이죠.

WARP.md도 여전히 작동하지만, 이는 하위 호환성을 위한 것으로 문서화되어 있습니다. 기존에 이 파일이 포함된 리포지토리를 이어받았다면 로드되겠지만, 새로 시작하는 경우라면 AGENTS.md를 사용하세요.

하위 디렉터리 규칙은 조건부로만 로드됩니다

이것은 가장 미묘한 원인이며, 문서에 명확히 명시되어 있습니다. "Warp는 루트 및 현재 디렉터리에 있는 AGENTS.md(또는 WARP.md)를 자동으로 적용합니다." 그리고 이어서 "다른 하위 디렉터리의 파일을 편집하는 경우, Warp는 해당 하위 디렉터리의 규칙 파일도 포함하도록 최선의 노력(best-effort)을 다합니다."

두 위치에 대해서는 자동 적용되지만, 그 외의 모든 위치에 대해서는 최선의 노력(best-effort)으로 처리됩니다.

Warp의 실제 예시를 보면 구조가 명확해집니다. 현재 디렉터리가 ui/로 설정되어 있으면 자동으로 적용되는 규칙은 project/AGENTS.md와 project/ui/AGENTS.md입니다. 반면 project/api/AGENTS.md는 최선의 노력으로 처리되어, 해당 디렉터리의 파일을 편집할 때만 포함됩니다. 현재 디렉터리를 api/로 전환하면 역할이 반대로 바뀝니다.

따라서 패키지별 규칙이 있는 모노레포에는 신뢰할 수 있는 계층과 신뢰할 수 없는 계층이 존재하게 되며, 이는 세션을 어디서 시작했는지에 따라 달라집니다. 규칙이 리포지토리 전체에 중요하게 적용되어야 한다면, 루트 파일이 로드를 보장할 수 있는 유일한 장소입니다.

가장 구체적인 규칙이 우선하며, 이는 항상 의도한 바와 다를 수 있습니다

Warp는 문서화된 순서에 따라 충돌을 해결합니다. 현재 하위 디렉터리 파일의 규칙이 가장 먼저 적용되고, 그 다음이 루트 파일의 규칙, 마지막이 글로벌 규칙(Global Rules)입니다. 명시된 의도는 "가장 구체적이고 프로젝트와 관련된 규칙이 더 광범위한 규칙보다 우선순위를 갖는다"는 것입니다.

이는 합리적이지만, 루트 수준의 표준이 조용히 적용되지 않게 만드는 원인이 되기도 합니다. 18개월 전에 특정 패키지를 위해 작성된 하위 디렉터리 파일이 지난주에 루트에 추가한 규칙보다 우선하게 됩니다. 오직 해당 디렉터리에서만 그렇게 작동하기 때문에, 문제가 간헐적으로 발생하는 것처럼 보입니다.

글로벌 규칙은 가장 마지막 순위입니다. 여기에 넣는 모든 내용은 가장 먼저 덮어씌워집니다.

Warp가 읽도록 설정하지 않은 파일에 규칙이 있을 수 있습니다

Warp는 이 부분에서 이례적으로 관대하며, 이 관대함은 선택 사항(opt-in)입니다. /init을 실행하면 "기존 규칙 파일을 AGENTS.md에 연동"할 수 있으며, 지원하는 목록은 다른 유사 도구들보다 훨씬 깁니다: "CLAUDE.md, .cursorrules, AGENT.md, GEMINI.md, .clinerules, .windsurfrules, .github/copilot-instructions.md."

단수형인 AGENT.md가 목록에 있으며, 이는 AGENTS.md와 다른 파일이라는 점에 유의하세요. 리포지토리에 단수형 파일이 있다면, 이는 Warp의 네이티브 파일이 아니라 연동 가능한 외부 파일로 취급됩니다.

여기서 함정은 파일이 존재하면 자동으로 감지할 것이라 가정하는 것입니다. CLAUDE.md로 가득 찬 리포지토리가 자동으로 Warp에 입력되지는 않으며, 직접 연동해야 합니다. 다른 에이전트에서 마이그레이션하는 팀들이 이 문제를 자주 겪습니다. 파일 변환에 대한 내용은 CLAUDE.md를 AGENTS.md로 마이그레이션하는 방법에서 다루고 있습니다.

그리고 직접 작성하지 않은 규칙이 존재할 수 있습니다

알아두어야 할 한 줄이 있습니다: "Warp는 향후 상호작용을 더 스마트하고 일관되게 만들기 위해 사용 패턴을 기반으로 글로벌 규칙을 제안할 수도 있습니다." 제안된 규칙은 편리하지만, 글로벌 규칙 패널을 한 번도 열어보지 않았다면 그 안에 무엇이 들어있는지 알 수 없습니다. 규칙이 무시된다고 결론 내리기 전에 먼저 확인해 보세요. 읽어본 적도 없는 규칙에 의해 덮어씌워지고 있을 수 있습니다.

규칙을 더 강한 어조로 다시 작성하기. 본문에 대문자를 남발하거나 느낌표를 더 많이 붙이는 방법입니다. 하지만 파일 이름이 소문자이거나 파일이 로드되지 않은 하위 디렉터리에 있다면, 아무리 강조해도 아무것도 바뀌지 않습니다.

모든 내용을 하나의 거대한 루트 파일로 이동하기. 이 방법은 로드 문제를 해결해 주지만, 다른 문제를 야기합니다. 이제 건드리지도 않는 패키지에 대한 수십 줄의 규칙을 포함하여 모든 규칙이 매 요청마다 로드됩니다.

프롬프트에 규칙을 직접 붙여넣기. 확실하지만 수동적인 방법이므로, 한 번이라도 깜빡하면 작동하지 않습니다.

Warp가 CLAUDE.md를 무시한다고 가정하기. 무시하지 않습니다. 다만 단순히 존재하는 것만으로는 안 되고 /init을 통해 연동해야 합니다.

프로젝트 지식을 Warp Drive에 넣기. Warp Drive는 팀 전체에 실시간으로 동기화되어 정말 유용하지만, 문서상으로는 "워크플로우, 노트북, 프롬프트, 환경 변수"를 위한 작업 공간으로 정의되어 있습니다. 이는 규칙이나 지식을 저장하는 곳이 아니며, 그 안에 있는 규칙 패널은 UI 편의상 제공되는 것일 뿐 Drive가 보관하는 데이터의 성격을 바꾸지는 않습니다.

규칙을 문서화 프로젝트로 만들기. 직관은 맞았으나 그릇이 잘못되었습니다. 규칙 파일은 행동을 제어하는 역할을 할 뿐이며, 규칙이 만들어진 배경이나 논리를 담을 공간은 없습니다.

Warp는 대부분의 도구가 제공하지 않는 확인 방법을 제공합니다. "상호작용에 사용된 규칙은 대화창의 References 아래에 표시되거나 특정 규칙에서 파생된 것으로 표시됩니다."

무언가를 변경하기 전에 이 기능을 활용해 보세요. 에이전트에게 규칙이 적용되는 작업을 수행하도록 요청한 다음, References를 확인합니다. 규칙이 목록에 없다면 로드 문제입니다. 먼저 파일 이름의 대소문자를 확인하고, 그 다음 파일이 루트에 있는지 아니면 현재 디렉터리에 있는지 확인하세요. 규칙이 목록에 있음에도 에이전트가 다른 행동을 했다면, 이는 로드 문제가 아니므로 파일을 다시 작성해도 해결되지 않습니다.

그 다음, 기억에 의존하지 않고 실제 상태를 볼 수 있도록 규칙 패널을 찾습니다. 문서화된 진입점은 5가지가 있습니다: Warp Drive의 Personal > Rules, 커맨드 팔레트에서 "Open AI Rules" 검색, Settings > Agents > Knowledge > Manage Rules, 메뉴 바의 AI > Open Rules, 그리고 프로젝트 규칙을 Warp 에디터에서 직접 열어주는 슬래시 명령어 /open-project-rules입니다. 글로벌 규칙을 생성하려면 /add-rule을 사용하고 실제 설명을 입력하세요. Warp의 필드 프롬프트는 "규칙이 하는 일과 적용할 시기"이며, 에이전트는 이 설명을 읽고 관련성을 판단합니다.

이것으로 로드 문제는 해결됩니다. 하지만 두 번째 문제, 즉 규칙 파일이 여러분이 알고 있는 대부분의 지식을 담기에는 적합하지 않은 형태라는 점은 해결되지 않습니다. 규칙은 요청 시점에 적용되는 지침입니다. 규칙은 필연적으로 짧아야 하며 컨텍스트를 두고 경쟁합니다. 특정 컨벤션이 존재하는 이유, 이미 거부된 접근 방식, 당연해 보이는 답을 오답으로 만드는 제약 조건 등은 지침이 아닙니다. 이를 AGENTS.md에 넣으면 파일만 길어질 뿐, 에이전트가 이를 더 잘 따르게 만들지는 못합니다.

이것이 바로 MemoryLake가 해결하는 영역입니다. 도구들이 쿼리할 수 있는 레이어에 프로젝트의 지속적인 지식을 보관하므로, 규칙은 짧게 유지되고 배경 논리는 언제든 사용할 수 있게 됩니다. 설정은 3단계로 진행됩니다.

1단계: API 키 생성

로그인하고 API 키를 생성합니다. 연결할 도구 전반에 걸쳐 하나의 자격 증명만 사용하면 됩니다.

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

각각 하나의 사실을 담은 짧은 항목들을 업로드합니다. 가장 좋은 소스는 더 길게 만들려던 바로 그 규칙 파일입니다.

모든 규칙의 배경 이유. "부하가 걸릴 때 읽기 전용 복제본(read replica)이 지연되므로 마이그레이션은 추가 전용(additive-only)으로만 진행해야 합니다." 규칙 자체는 AGENTS.md에 있어야 하지만, 이 배경 논리는 여기에 있어야 다음 분기에 규칙이 임의로 되돌려지는 것을 방지할 수 있습니다.

이 리포지토리에서 이미 거부된 접근 방식. 규칙 파일이나 커밋 메시지에는 나타나지 않지만, 새로운 세션이 시작될 때마다 계속해서 다시 제안되는 범주입니다.

아무도 알려주지 않는 환경적 사실. CI에서만 실패하는 테스트, 문서화되지 않은 속도 제한(rate limit), 두 작업 간의 순서 의존성 등입니다.

하위 디렉터리 파일 간에 의견이 일치하지 않는 부분. 패키지별 규칙이 루트 규칙과 충돌하는 경우, 어떤 것이 최신이고 그 이유는 무엇인지 기록해 두세요. 이는 규칙이 아니라 사실입니다.

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

사용 중인 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 접근할 수 있으며, Warp는 MCP 서버를 지원합니다. 여기서 알아두어야 할 세부 사항이 있습니다: "CLI는 Warp 앱과 별개로 자체 MCP 서버 구성을 유지합니다." macOS의 경우 ~/.warp_cli/.mcp.json에 저장됩니다. 둘 다 사용하는 경우 양쪽 모두 구성하세요. Claude, Codex, OpenClaw와 같은 MCP 네이티브 에이전트도 동일한 방식으로 연결되며, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽습니다.

세 가지 분명한 한계가 있습니다. MemoryLake는 AGENTS.md나 글로벌 규칙을 대신 작성해 주지 않습니다. 이는 Warp를 제어하는 방법이며, 위의 로드 동작은 Warp 자체의 기능이지 메모리 레이어가 변경할 수 있는 것이 아닙니다. MemoryLake는 사용자나 에이전트가 입력한 내용만 보관하므로 2단계는 수동으로 진행됩니다. 또한 규칙은 강제된 구성이 아니라 컨텍스트로 작용하므로, 매번 반드시 지켜져야 하는 사항은 마크다운 파일의 한 줄이 아니라 CI에서 검사하도록 설정해야 합니다.

"규칙이 로드되고 있는가?"를 2초 만에 확인할 수 있습니다. References를 확인하면 됩니다.

파일 이름 대소문자 문제가 더 이상 미스터리한 버그가 되지 않습니다. 대문자 AGENTS.md가 아니면 존재하지 않는 것과 같습니다.

루트와 하위 디렉터리 중 어디에 둘지 의도적으로 선택하게 됩니다. 루트는 로드가 보장되며, 그 외의 위치는 최선의 노력(best-effort)으로 처리됩니다.

규칙 파일이 더 짧아집니다. 배경 논리가 다른 곳으로 이동하므로 지침만 남게 됩니다.

마이그레이션이 더 이상 재작성을 의미하지 않습니다. /init을 통해 7가지 외부 형식을 연동할 수 있습니다.

중요한 부분에서 CLI와 앱이 동기화 상태를 유지합니다. Warp 문서에 따르면 "규칙과 스킬은 마이그레이션할 필요가 없습니다." 두 환경 모두 동일한 파일 위치에서 이를 탐색하기 때문입니다. 단, MCP 구성은 예외입니다.

매번 파일 이름의 대소문자를 가장 먼저 확인하세요. 가장 비용이 적게 드는 진단이자 가장 흔한 원인입니다.

리포지토리 전체에 적용되는 규칙은 루트 파일에 넣으세요. 루트와 현재 디렉터리만 자동으로 로드됩니다.

오래된 하위 디렉터리 파일이 규칙을 덮어쓰고 있지 않은지 점검하세요. 가장 구체적인 파일이 우선하며, 오래된 파일도 구체성을 유지합니다.

글로벌 규칙 패널을 한 번 확인해 보세요. Warp가 여러분이 본 적 없는 규칙을 제안해 두었을 수 있습니다.

중복해서 작성하지 말고 연동하세요. /init은 CLAUDE.md, .cursorrules, .clinerules를 포함한 7가지 형식을 연동해 줍니다. 동일한 규칙의 복사본이 두 개 존재하면 서로 어긋나게 됩니다.

글로벌 규칙에 실제 설명을 입력하세요. 에이전트가 관련성을 판단하기 위해 읽는 내용입니다.

파일을 다시 읽는 대신 References로 검증하세요. 로드된 것은 사실이고, 여러분이 작성한 것은 의도일 뿐입니다.

규칙 파일에서 배경 논리를 제외하세요. 규칙은 요청 시점에 적용되며 컨텍스트를 두고 경쟁합니다. 이에 대한 전반적인 개념은 AI 메모리의 실제 정의에서 확인할 수 있습니다.

Warp의 규칙 시스템은 4가지 특징을 이해하고 나면 매우 잘 작동합니다. 파일 이름은 반드시 대문자여야 하며, 소문자 agents.md는 아무런 경고 없이 무시됩니다. 루트 파일과 현재 디렉터리의 파일만 자동으로 로드되며, 그 외의 파일은 사용자가 어떤 파일을 건드렸는지에 따라 최선의 노력(best-effort)으로 로드됩니다. 충돌이 발생하면 가장 구체적인 파일이 우선하므로, 오래된 하위 디렉터리 규칙이 해당 디렉터리 내에서 새로운 루트 표준보다 우선할 수 있습니다. 마지막으로, 7가지 외부 규칙 형식은 /init을 통해 연동할 수 있으며, 이는 자동 감지가 아닌 명시적 연동이 필요합니다.

가장 훌륭한 부분은 검증 경로를 제공한다는 점입니다. 실행된 규칙은 대화창의 References 아래에 표시되므로, "내 규칙이 로드되고 있는가?"라는 의문을 추측이 아닌 확인을 통해 해결할 수 있습니다. 이 카테고리의 대부분의 도구는 이러한 뷰를 제공하지 않으므로, 무언가를 수정하기 전에 이를 확인하는 습관을 들이는 것이 좋습니다.

규칙이 할 수 없는 일은 배경 논리를 담는 것입니다. 규칙은 짧고 관련 요청이 있을 때마다 로드되며, 특정 컨벤션이 존재하는 이유를 설명하기 시작하는 순간 규칙 파일 본연의 역할을 방해하게 됩니다. 대소문자를 확인하고, 리포지토리 전체 규칙은 루트에 넣고, 하위 디렉터리의 덮어쓰기 설정을 점검하고, References로 검증하세요. 그리고 결정 사항, 배경 이유, 거부된 접근 방식은 에이전트가 매번 읽어야 하는 파일 대신 쿼리할 수 있는 레이어에 보관하세요.