Cursor가 매번 새로 시작하는 이유와 실제로 유지되는 것
규칙이 위치할 수 있는 네 가지 장소
Cursor 문서에 정의된 세트는 다음과 같습니다:
Project rules는 .cursor/rules 폴더에 .mdc 파일로 저장되며 버전 관리됩니다. 이 규칙들은 "경로 패턴을 사용하여 범위를 지정하거나, 수동으로 호출하거나, 관련성에 따라 포함"됩니다.
User Rules는 Customize → Rules에서 정의하는 "모든 프로젝트에 적용되는 전역 기본 설정"입니다. Agent (Chat)에서 사용되며, 소통 스타일이나 개인적인 컨벤션을 저장하기에 적합한 곳입니다.
Team Rules는 "대시보드에서 관리되는 팀 전체 규칙"으로, Team 및 Enterprise 플랜에서 사용할 수 있습니다.
AGENTS.md는 "마크다운 형식의 Agent 지침으로, .cursor/rules를 대체하는 간단한 대안"으로 설명됩니다. 중첩 지원이 가능하여, 하위 디렉토리에 AGENTS.md를 배치하면 해당 디렉토리나 그 하위 파일에서 작업할 때 자동으로 적용됩니다. 이때 지침은 "상위 디렉토리의 지침과 결합되며, 더 구체적인 지침이 우선 적용"됩니다.
대부분의 사람들은 이 중 딱 하나만 작성해 두고 모든 것이 해결될 것이라 가정합니다.
오직 하나의 규칙 유형만 항상 적용이 보장됩니다
이것이 핵심입니다. 문서에 따른 Cursor의 네 가지 규칙 유형은 다음과 같습니다:
| 규칙 유형 | 적용 시점 |
|---|---|
| Always Apply | "모든 채팅 세션에 적용" |
| Apply Intelligently | "설명을 바탕으로 Agent가 관련이 있다고 판단할 때" |
| Apply to Specific Files | "파일이 지정된 패턴과 일치할 때" |
| Apply Manually | "채팅에서 @로 언급될 때" |
내부적으로는 세 가지 frontmatter 필드가 이를 결정합니다. alwaysApply: true는 "항상 포함됨을 의미하며, glob 패턴과 설명은 무시"됩니다. alwaysApply: false이고 glob 패턴이 제공되면, 규칙은 "일치하는 파일이 컨텍스트에 있을 때 자동으로 첨부"됩니다. 설명은 있지만 glob 패턴이 없으면 "Agent가 설명을 읽고 관련이 있을 때 규칙을 가져옵니다." 둘 다 없으면 "채팅에서 규칙을 @-mention으로 언급할 때만 포함"됩니다.
따라서 3주 전에 frontmatter 필드를 설정하지 않고 작성한 규칙은 여러분이 한 번도 입력한 적 없는 @-mention을 기다리고 있는 중입니다. 규칙이 사라진 것이 아니라, 애초에 호출되지 않은 것입니다.
Cursor 자체 FAQ의 답변이 가장 빠른 진단 방법입니다: "규칙 유형을 확인하세요. Apply Intelligently인 경우 설명(description)이 정의되어 있는지 확인하세요. Apply to Specific Files인 경우 파일 패턴이 참조된 파일과 일치하는지 확인하세요."
.cursor/rules 안의 일반 .md 파일은 소리 없이 무시됩니다
아무런 경고도 주지 않기 때문에 가장 많은 시간을 낭비하게 만드는 실패 사례입니다. 문서에 명시되어 있습니다: ".cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 frontmatter가 없기 때문에 규칙 시스템에서 무시됩니다. 일반 마크다운을 선호한다면 대신 AGENTS.md를 사용하세요."
만약 .cursor/rules 내부에 notes.md를 유지하면서 왜 아무것도 바뀌지 않는지 궁금해하셨다면, 바로 이 때문입니다. 파일 확장자를 .mdc로 변경하고 frontmatter를 추가하거나, 내용을 AGENTS.md로 이동하세요.
규칙은 로드되었지만, 규칙이 참조하는 대상이 로드되지 않았습니다
규칙은 의도적으로 짧게 설계되었습니다. Cursor의 가이드라인에 따르면 규칙을 500행 미만으로 유지하고, 큰 규칙은 조합 가능한 작은 규칙으로 분할하며, 특히 "콘텐츠를 복사하는 대신 파일을 참조하세요. 이렇게 하면 규칙을 짧게 유지하고 코드가 변경됨에 따라 규칙이 오래된 상태가 되는 것을 방지할 수 있습니다"라고 권장합니다. @filename.ts를 통해 파일을 가져올 수 있습니다.
이로 인해 이차적인 격차가 발생합니다. "우리 서비스 컨벤션을 따르라"는 지침은 그 컨벤션에 접근할 수 있을 때만 작동합니다. 규칙은 포인터와 방향일 뿐이며, 지식 그 자체가 아닙니다. 도구 전반에 걸친 이러한 차이가 바로 why agents ignore the instruction files you wrote의 이유입니다.
규칙이 저장된 위치가 항상 생각한 곳은 아닙니다
규칙은 git에 커밋되어 팀원들과 공유되지만, 새로운 규칙은 현재 작업 중인 폴더의 .cursor/rules에 저장됩니다. 하위 폴더를 프로젝트로 열면 규칙의 범위가 해당 하위 폴더로 제한됩니다. 5초만 투자해 확인하면 반나절을 아낄 수 있습니다.
사람들이 시도하는 방법들
매 채팅을 시작할 때마다 프로젝트를 다시 설명하기. 작동은 하지만, 매번 동일한 비용이 영구적으로 발생합니다. 이는 how to stop re-explaining context to AI에서 다루는 굴레와 같습니다.
하나의 거대한 항상 켜져 있는(always-on) 규칙 작성하기. 모든 세션에 적용되며 매 메시지마다 모델 컨텍스트의 시작 부분에 포함됩니다. Cursor가 피해야 할 사항으로 꼽은 목록에는 "스타일 가이드 전체를 복사하는 것"(대신 linter를 사용하세요)과 "가능한 모든 명령어를 문서화하는 것"(Agent는 이미 npm, git, pytest를 알고 있습니다)이 포함되어 있습니다.
하나의 채팅창을 영원히 열어두기. 세션 경계를 넘어서는 것이 아니라 단지 미루는 것뿐입니다.
모든 것을 Apply Intelligently로 설정하기. 그럴듯하게 들리지만, 5초 만에 대충 작성한 설명에 결정을 맡기게 됩니다. 설명이 모호하면 규칙이 적용되지 않습니다.
아키텍처 결정을 규칙에 붙여넣기. 직관은 맞았으나 그릇이 틀렸습니다. 규칙은 짧게 유지되고 다른 대상을 가리키도록 설계되었습니다. 이것이 바로 why Cursor forgets architectural decisions의 배경입니다.
기기 간에 규칙을 수동으로 동기화하기. 흔히 쓰이지만 버전이 어긋나기 쉽습니다. 기기 간 경계에 대한 내용은 how to stop Cursor forgetting across machines에서 다룹니다.
해결책: 규칙의 유형을 정의하고, 추론은 규칙 외부에 보관하기
두 단계로 진행됩니다. 첫 번째 단계는 Cursor가 작성된 내용을 로드하도록 만드는 것이고, 두 번째 단계는 500행이라는 제한에 담을 수 없는 지식을 보관할 공간을 마련하는 것입니다.
기기 기존 규칙을 점검하고 확장자를 수정하세요. .cursor/rules를 엽니다. .md로 끝나는 파일은 모두 무시되고 있으므로, frontmatter를 포함한 .mdc로 변환하거나 AGENTS.md로 이동하세요.
각 규칙에 항상 올바르게 작동하는 가장 좁은 범위의 유형을 할당하세요. 보편적인 제약 조건에는 alwaysApply: true를 부여합니다. 특정 언어나 디렉토리에 국한된 컨벤션에는 globs를 지정합니다. 상황별 가이드에는 구체적인 설명을 작성하여 Agent가 실제로 관련성을 판단할 수 있도록 합니다. 거의 사용되지 않는 절차는 수동으로 유지하고 필요할 때 @-mention으로 호출합니다.
전역적인 것과 로컬적인 것을 분리하세요. 소통 스타일과 개인적인 컨벤션은 Customize → Rules 아래의 User Rules에 위치해야 합니다. 리포지토리 컨벤션은 프로젝트 규칙이나 AGENTS.md에 포함되어 git에 커밋되어야 팀원들도 함께 사용할 수 있습니다.
복잡한 glob 패턴 대신 중첩된 AGENTS.md를 사용하세요. 루트 파일 하나와 주요 디렉토리별로 하나씩 배치하면 frontmatter 없이도 범위를 지정할 수 있으며, 더 구체적인 지침이 우선 적용됩니다.
코드를 복사하는 대신 표준 예시 파일을 가리키도록 하세요. @file 참조를 사용하세요. Cursor 문서에서는 그 이유를 명확히 밝히고 있습니다. 코드가 변경됨에 따라 복사본은 낡은 정보가 되기 때문입니다.
여기까지가 로딩 문제를 해결하는 방법입니다. 하지만 규칙이 의도적으로 배제하는 레이어, 즉 아키텍처가 왜 그렇게 설계되었는지, 이미 시도했다가 포기한 접근 방식은 무엇인지, 특이한 결정이 왜 올바른 선택이었는지에 대한 제약 조건 등은 규칙으로 해결할 수 없습니다. Cursor의 가이드는 Agent가 실수를 반복할 때 규칙을 추가하라고 조언합니다. 이는 좋은 조언인 동시에, 규칙이 추론 과정이 아닌 결론만을 담아낸다는 점을 인정하는 것이기도 합니다.
바로 이 부분을 MemoryLake가 해결해 줍니다. 도구들이 읽을 수 있는 레이어에 프로젝트의 지속적인 지식을 보관하므로, 규칙은 짧게 유지하면서도 추론 과정은 언제든 활용할 수 있습니다. 설정은 세 단계로 진행됩니다.
1단계: API 키 생성
MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 모든 도구에서 이 하나의 자격 증명을 공유하여 사용합니다.
2단계: 첫 번째 메모리 업로드
규칙 파일에 담기에는 적합하지 않은 내용들을 하나의 주장씩 짧은 항목으로 작성합니다:
제약 조건이 포함된 결정 사항. "ORM의 즉시 로딩(eager loading)이 페이지네이션을 망가뜨렸기 때문에 쿼리는 리포지토리 레이어를 거쳐야 합니다." 규칙은 앞부분만 명시할 수 있습니다. 오직 이 버전만이 잘못된 제안이 다시 나오는 것을 방지합니다.
이미 기각한 접근 방식. 가장 가치 있는 범주이자 리포지토리 그 어디에도 존재하지 않는 정보입니다. 새로운 세션이 시작될 때마다 AI는 이를 다시 제안하곤 합니다.
교차 리포지토리 지식. 여러 프로젝트에 걸쳐 적용되는 도메인 용어 및 표준입니다. 프로젝트 규칙은 설계상 리포지토리별로 적용되지만, 이는 그렇지 않습니다.
두 번 이상 수정한 사항. 규칙을 작성하기 위한 Cursor 자체의 휴리스틱이며, 수정 뒤에 숨겨진 추론 과정이 바로 여기에 함께 위치해야 합니다.
3단계: AI 및 Agent 연결
사용하는 도구들을 연결합니다. MemoryLake는 MCP 및 API를 통해 접근할 수 있으므로, Claude Code, Codex, OpenClaw 등 MCP를 기본 지원하는 Agent들은 MCP 서버를 가리켜 연결하고, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽습니다.
세 가지 솔직한 한계가 있습니다. MemoryLake는 Cursor 규칙을 대신 작성해 주지 않으며, 규칙을 대체하지도 않습니다. 규칙은 Agent를 제어하는 수단이므로 여전히 올바르게 작성해야 합니다. 또한 사용자가 직접 또는 Agent가 기록한 내용만 보관하므로 2단계는 수동으로 진행됩니다. 마지막으로, 규칙은 강제된 설정이 아니라 프롬프트 수준의 컨텍스트이며, 이는 저희가 아닌 Cursor의 프레임워크입니다. 메모리 레이어가 이를 바꾸지는 못합니다.
실제 작업에서 달라지는 점
"왜 규칙을 따르지 않았지?"에 대한 확인이 2초 만에 끝납니다. 확장자, 규칙 유형, 패턴 순으로 확인하면 됩니다. 거의 항상 이 세 가지 중 하나가 원인입니다.
항상 켜져 있는 규칙이 짧아집니다. 핵심 내용이 다른 곳에 보관되면, 항상 켜져 있는 파일은 매 메시지마다 전송되는 방대한 문서가 아니라 몇 가지 실질적인 제약 조건만 담은 가벼운 파일로 돌아갑니다.
새로운 리포지토리가 완전히 새로운 시작을 의미하지 않습니다. 프로젝트 규칙은 리포지토리 간에 이동하지 않지만, 규칙 외부에 보관된 지식은 이동합니다.
팀 온보딩이 구전 역사에 의존하지 않게 됩니다. 커밋된 규칙은 컨벤션을 제공하고, 메모리 레이어는 그 이유를 제공합니다. 신규 팀원에게는 둘 다 필요하지만, 보통 둘 중 하나만 문서화되어 있기 마련입니다.
다른 도구들도 동일한 컨벤션을 공유합니다. Cursor, Claude Code, Codex 중 어떤 도구가 읽든 아키텍처 뒤에 숨겨진 추론 과정은 동일합니다. 이는 what persistent memory actually means에서 다룬 형태입니다.
오래 지속되는 Cursor 규칙을 위한 모범 사례
.cursor/rules 안에서는 .mdc를 사용하거나 AGENTS.md를 사용하세요. 규칙 디렉토리 내부의 일반 .md 파일은 무시됩니다.
각 규칙마다 유형을 의도적으로 한 번씩 설정하세요. frontmatter를 비워두고 알아서 작동하기를 바라지 마세요. 비어 있으면 수동(manual)을 의미합니다.
처음 보는 사람도 분류할 수 있을 정도로 설명을 작성하세요. "백엔드를 위한 RPC 서비스 컨벤션 및 패턴"은 분류 가능하지만, "백엔드 관련"은 그렇지 않습니다.
규칙을 500행 미만으로 유지하고, 커지면 분할하세요. 이는 Cursor가 제시한 수치이며, 조합 가능한 규칙은 범위가 변경될 때 수정하기가 더 쉽습니다.
파일을 복사하지 말고 참조하세요. 복사본은 낡은 정보가 되지만, @file 참조는 그렇지 않습니다.
규칙은 사후 반응적으로 추가하세요. 문서에 명확히 나와 있듯이, Agent가 동일한 실수를 반복하는 것을 발견했을 때 규칙을 추가하고, 자신의 패턴을 파악하기 전에 과도하게 최적화하지 마세요.
규칙을 git에 커밋하고 지속적으로 업데이트하세요. GitHub 이슈나 PR에서 @cursor를 태그하여 Agent가 대신 규칙을 업데이트하도록 할 수도 있습니다.
디렉토리 범위 지정을 위해 중첩된 AGENTS.md를 우선 사용하세요. 유지 관리할 frontmatter가 적고 우선순위를 예측하기 쉽습니다.
이유는 규칙 외부에 저장하세요. 규칙은 방향과 포인터를 위한 것입니다. 이유(why)는 Agent가 예상치 못한 상황을 처리할 수 있게 만드는 열쇠이며, 이는 500행 안에 다 들어가지 않습니다. 이는 why RAG isn't memory에서 다루는 일반적인 문제입니다.
결론
Cursor는 모델이 완료(completion) 간에 메모리를 유지하지 않으며, 규칙(Rules)이 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공하는 메커니즘임을 명시하고 있습니다. 따라서 세션 간에 컨텍스트를 유지하는 것은 파일 확장자, 규칙 유형, 범위, 그리고 규칙이 저장된 위치라는 네 가지를 올바르게 설정하는 문제입니다. 이 부분들을 해결하면 "까먹었다"는 문제의 대부분이 사라집니다.
남은 부분은 규칙이 의도적으로 담지 않도록 설계된 영역입니다. 규칙은 용량 제한이 있고, 파일을 복제하기보다는 가리키도록 설계되었으며, 논증보다는 결론을 포착합니다. 결정 사항, 제약 조건, 기각된 접근 방식을 도구가 읽을 수 있는 레이어에 배치하고, 규칙을 짧고 올바른 유형으로 유지하세요. 그러면 새로운 세션이 시작될 때마다 지침과 그 뒤에 숨겨진 이유를 모두 가지고 시작할 수 있습니다.