컨텍스트 손실 없이 Cursor에서 Roo Code로 마이그레이션하는 방법 (2026)

Cursor의 규칙 문서는 형식 요구사항에 대해 명확히 규정하고 있으며, 그 명확성이 핵심입니다:

"프로젝트 규칙은 .cursor/rules에 .mdc 파일로 저장되며 버전 관리됩니다. 이 규칙들은 경로 패턴을 사용하여 범위를 지정하거나, 수동으로 호출하거나, 관련성에 따라 포함됩니다."

"프로젝트 규칙은 반드시 .mdc 확장자를 사용해야 합니다. .cursor/rules에 있는 일반 .md 파일은 규칙 시스템에서 무시됩니다. description, globs, alwaysApply를 지정하는 프론트매터가 없기 때문입니다. 일반 마크다운을 선호한다면 대신 AGENTS.md를 사용하세요."

세 개의 프론트매터 필드가 모든 조건성을 담당합니다. 문서에서는 핵심 분기점을 다음과 같이 설명합니다:

"alwaysApply가 true이면 규칙이 모든 채팅 세션에 적용됩니다. 그렇지 않으면 규칙의 description이 Cursor Agent에게 제공되어 적용 여부를 결정하게 합니다."

여기에 일치하는 파일로 규칙 범위를 제한하는 globs가 추가되며, "규칙을 500행 미만으로 유지하라"는 권장 사항이 있습니다.

이 확장자 요구사항은 잠시 짚고 넘어갈 가치가 있습니다. 마이그레이션을 시작하기도 전에 사람들이 가장 흔하게 좌절하는 원인이기 때문입니다. 해당 디렉토리에 .md로 저장된 규칙은 깨진 규칙이 아니라, 아예 규칙으로 인식되지 않으며 그에 대한 아무런 안내도 제공되지 않습니다. Cursor forgetting project rules에 대한 보고의 절반은 규칙 시스템이 아예 감지하지 못한 파일에서 비롯됩니다.

이제 Roo Code를 살펴보겠습니다. 워크스페이스 규칙은 .roo/rules/에 들어가며, 문서에서는 이를 권장하는 방법으로 설명하고 워크스페이스 루트에 있는 단일 .roorules 파일을 폴백(fallback)으로 제시합니다. 글로벌 규칙은 ~/.roo/rules/에 들어가며, 이 위치는 "고정되어 있어 맞춤 설정할 수 없습니다." 로드 순서는 명확히 문서화되어 있습니다. 글로벌 규칙이 먼저 로드되고, 그 다음 프로젝트 규칙이 로드되며, "충돌이 발생하는 경우 워크스페이스 규칙이 우선합니다."

고정된 글로벌 경로는 팀에게 실질적인 영향을 미칩니다. 홈 디렉토리 위치이므로 머신별로 적용되며 버전 관리 시스템 외부에 존재합니다. 여기에 넣는 모든 것은 단 하나의 노트북에만 존재하게 되며, 이는 Cursor forgetting settings across machines의 원인이 되는 비대칭성과 동일합니다. 팀과 관련된 규칙은 글로벌 디렉토리가 아닌 워크스페이스 디렉토리에 넣으세요.

그리고 여러분의 계획을 바꾸게 될 문장이 나옵니다:

"Roo Code는 파일 이름의 알파벳 순서에 따라 파일 내용을 시스템 프롬프트에 추가하며, 하위 디렉토리를 포함하여 파일을 재귀적으로 읽습니다."

재귀적, 추가(appending), 알파벳 순, 파일 이름 기준. 디렉토리의 모든 것이 적용되기 때문에 alwaysApply가 없습니다. 파일 범위가 지정되지 않기 때문에 globs도 없습니다. 모델이 결정하도록 요청받지 않기 때문에 모델이 평가할 description도 없습니다.

따라서 마이그레이션되는 것과 되지 않는 것은 다음과 같습니다. 모든 규칙의 본문(prose)은 그대로 유지됩니다. 어느 쪽이든 마크다운이기 때문입니다. Roo Code도 하위 디렉토리를 읽으므로 디렉토리 구조도 그대로 유지됩니다. 사라지는 것은 세 가지 프론트매터 필드 전체이며, 이와 함께 항상 적용되는 규칙과 src/api/**/*.ts에만 적용되는 규칙 간의 모든 구분이 사라집니다.

이로 인해 두 가지 결과가 발생하며, 두 번째 결과는 사람들을 놀라게 합니다.

첫째, 컨텍스트 비용(context bill)이 증가합니다. 마이그레이션으로 범위를 제한한 긴 데이터베이스 규칙 파일이나 .tsx로 범위를 제한한 React 패턴 파일 등 조건부로 작성했던 모든 규칙이 이제 빌드 스크립트에 대한 요청을 포함한 모든 요청의 시스템 프롬프트에 포함됩니다.

둘째, 이전에는 서로 만날 일이 없었던 모순된 규칙들이 이제 충돌하게 됩니다. 앱 디렉토리로 범위를 제한한 "서버 컴포넌트 선호" 규칙과 레거시 폴더로 범위를 제한한 "이것들은 모두 클라이언트 컴포넌트임" 규칙은 Cursor에서는 결코 같은 컨텍스트에 있지 않았습니다. 하지만 플랫 추가(flat append) 방식 하에서는 두 규칙이 함께 포함되며, 프롬프트에서 어떤 규칙이 더 뒤에 위치할지는 어떤 파일 이름이 알파벳 순서상 뒤에 오는지에 따라 결정됩니다. 이것이 Roo Code forgetting project context와 같은 보고의 원인이 되는 메커니즘입니다. 규칙은 존재하지만, 서로 충돌하는 것입니다.

Roo Code에도 조건부 메커니즘이 있습니다. 단지 다른 곳에 있을 뿐입니다.

1단계: globs 범위를 모드로 재표현하기

Roo Code는 파일 경로가 아니라 모드(mode)별로 규칙의 범위를 지정합니다. .roo/rules/와 함께 .roo/rules-{modeSlug}/ 디렉토리를 생성할 수 있으며, 문서화된 예시로는 Code 모드를 위한 rules-code/, 아키텍처 작업을 위한 rules-architect/, 디버깅 워크플로우를 위한 rules-debug/, 문서 추출을 위한 rules-docs-extractor/ 등이 있습니다. 동일한 패턴이 ~/.roo/ 아래에 글로벌하게 존재합니다. 각 레벨 내에서 문서에 따르면 "모드별 규칙은 일반 규칙보다 먼저 로드됩니다."

따라서 .mdc 파일을 살펴보고 해당 globs가 실제로 무엇을 지향하고 있었는지에 따라 분류하세요. 테스트 파일로 범위가 지정된 규칙은 대개 테스트 작성 방법에 대한 규칙이므로 Code 모드 또는 Debug 모드의 관심사입니다. 아키텍처 문서로 범위가 지정된 규칙은 rules-architect/에 속합니다. alwaysApply: true였던 규칙은 변경 없이 .roo/rules/로 이동합니다. 해당 디렉토리가 바로 그 의미이기 때문입니다.

작업의 종류가 아니라 순수하게 경로에 대한 globs를 가졌던 규칙들은 마땅히 들어갈 곳이 없습니다. 대신 본문에 명시적인 조건문(해당 지침이 적용되는 디렉토리를 명시하는 문장)을 작성하세요. 파일은 어쨌든 로드될 것이므로, 모델이 텍스트를 통해 경계를 파악해야 하기 때문입니다. 이는 glob보다 신뢰성은 떨어지지만, 대상 도구가 지원하는 한계를 솔직하게 반영하는 방법입니다.

이 작업을 수행하는 동안 프론트매터 블록을 그대로 두지 말고 삭제하세요. 규칙 파일 상단에 남아 있는 YAML 헤더는 Roo Code에서 파싱되지 않으므로 일반 콘텐츠로 취급되어, 모델에게 아무런 의미도 없는 alwaysApply에 대한 지침으로 전달됩니다.

2단계: 추가 순서를 의도적으로 제어하고 두 가지 함정 주의하기

콘텐츠가 파일 이름의 알파벳 순서대로 추가되므로, 이제 파일 이름이 곧 로드 순서가 됩니다. 순서가 의도한 대로 작동하도록 이름을 지정하세요. 각 파일에 숫자 접두사를 붙이면 순서가 명확해지고, 나중에 이름을 바꿀 때 시스템 프롬프트의 순서가 무단으로 변경되는 것을 방지할 수 있습니다.

그 다음, 문서에 명시된 두 가지 동작을 확인해야 합니다.

첫 번째는 빈 디렉토리 함정입니다. ".roo/rules/ 디렉토리가 존재하지만 비어 있는 경우, Roo Code는 대신 .roorules 파일을 사용하는 방식으로 대체(fallback)합니다." 따라서 디렉토리는 생성했으나 파일은 아직 옮기지 않은 반쯤 끝난 마이그레이션 상태에서는 잊고 있었던 레거시 루트 파일이 자동으로 다시 활성화될 수 있습니다.

두 번째는 더 광범위한 레거시 파일 우선순위입니다. 문서화된 로드 순서에 따르면 워크스페이스 루트의 레거시 파일인 .roorules 및 .clinerules는 "일반 규칙 디렉토리 콘텐츠가 로드되지 않은 경우에만 사용"됩니다. Roo Code가 .clinerules를 읽는 것은 Cline에서 마이그레이션한 경우에는 편리하지만, 그렇지 않은 경우에는 혼란을 줄 수 있습니다. 규칙 디렉토리에 콘텐츠가 있는 동안에는 리포지토리에 있는 오래된 파일이 아무런 동작도 하지 않다가, 디렉토리가 비는 순간 활성화되기 때문입니다.

마지막으로, AGENTS.md 파일은 그대로 유지하세요. Cursor는 이를 .mdc 대신 사용할 수 있는 일반 마크다운 대안으로 지원하며, 이는 스택 전반에서 계속 유용하게 사용됩니다. migrating Cursor rules to a Windsurf-style setup에서는 다른 대상을 위한 동일한 변환 문제를 다루고 있으며, 공통점은 개방형 규칙(open convention)이 살아남는 부분이라는 점입니다.

1단계에서는 각 규칙이 어떤 모드에 속할지 결정하라고 했고, 2단계에서는 어떤 순서로 로드할지 결정하라고 했습니다. 두 결정 모두 각 규칙이 왜 존재하는지 알고 있을 때는 쉽지만, 그렇지 않을 때는 거의 불가능합니다.

"서버 컴포넌트 선호" 대 "이것들은 모두 클라이언트 컴포넌트임"은 알파벳 순서로 정렬된 두 개의 명령형 규칙으로서 해결할 수 없는 문제입니다. 하지만 두 번째 규칙이 아직 아무도 마이그레이션하지 않은 디렉토리를 설명하는 것이고 첫 번째 규칙이 현재의 기본 방향이라는 점을 알게 되면 문제는 아주 단순해집니다. 이러한 '이유'는 두 도구 모두에 존재하지 않으며, .mdc 프론트매터에도 없었습니다.

MemoryLake는 에디터 외부에서 이 레이어(결정 사항, 채택되지 않은 대안, 그리고 그 이유)를 유지하며, MCP 또는 API를 통해 요청하는 모든 에이전트에게 이를 제공합니다. .roo/rules/ 파일은 문서에 설명된 대로 정확히 로드되면서도 짧고 명령형으로 유지될 수 있으며, 그 뒤에 숨겨진 추론은 매 요청마다 시스템 프롬프트에 포함되지 않고도 답변될 수 있습니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 완료하세요. 위의 1단계를 진행하기 전에 이 작업을 수행하면, 파일을 분류할 때 발생하는 각 충돌을 기록할 공간을 확보할 수 있습니다.

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

유지한 각 규칙에 대해 무엇을 결정했는지, 무엇을 배제했는지, 그리고 그 이유를 기록하세요. 서로 모순되었던 쌍이 가장 가치 있는 항목입니다. 나중에 다시 표면화될 항목들이기 때문입니다. 지원 문서와 파일도 같은 위치에 저장됩니다.

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

Roo Code, Claude, Codex 및 기타 에이전트에게 MCP 또는 API를 통한 액세스 권한을 부여하세요. 규칙이 잘못된 것처럼 보일 때, "이것이 왜 여기에 있는가"에 대한 답변이 단순한 재진술이 아닌 추론과 함께 제공됩니다.

첫 번째 변화는 규칙 디렉토리를 작게 유지할 수 있다는 점입니다. 추론이 보관될 공간이 생기면 각 파일은 몇 줄의 명령형 코드로 구성되며, 이는 조건부 로드 방식보다 플랫 추가(flat append) 방식 하에서 훨씬 더 중요하게 작용합니다.

두 번째는 모드 할당을 명확히 결정할 수 있게 된다는 점입니다. 규칙을 rules-code/와 rules-architect/ 중 어디로 분류할지는 해당 규칙이 어떤 종류의 작업을 제어하는지에 대한 판단이며, 규칙에 그 목적이 명시되어 있을 때는 이 판단이 명확해지지만 그렇지 않을 때는 추측에 의존해야 합니다.

세 번째는 파일 이름 순서가 더 이상 시스템의 핵심 하중을 받지 않는다는 점입니다. 여전히 의도적인 이름을 지정하는 것이 좋지만, 진짜 충돌을 해결하기 위해 알파벳 순서라는 우연에 의존할 필요가 없어집니다. 충돌은 이미 의도적으로 한 번 해결되어 기록되었기 때문입니다.

네 번째는 다음 도구로의 전환이 이번 마이그레이션보다 훨씬 수월해진다는 점입니다. Cursor는 조건성을 프론트매터에 두었고, Roo Code는 모드에 두었으며, 그 다음 도구는 또 다른 방식을 사용할 것입니다. 변하지 않는 것은 프로젝트가 내린 결정들의 집합이며, 이는 what coding agents actually read가 특정 도구가 요구하는 확장자가 무엇인지보다 훨씬 더 지속적이고 중요한 질문인 이유와 같습니다.

.roo/rules/에 있는 모든 것은 항상 활성화되어 있다고 가정하세요. 해당 디렉토리가 항상 활성화되는 레이어이므로 alwaysApply에 해당하는 기능이 없습니다. 모든 요청에 포함시키고 싶지 않은 내용은 모드 디렉토리에 넣거나 아예 제외해야 합니다.

모드 디렉토리를 범위 지정 도구로 사용하세요. rules-code/, rules-architect/, rules-debug/ 및 이에 해당하는 글로벌 디렉토리가 이제 조건성이 존재하는 곳입니다.

파일 이름이 로드 순서를 나타내도록 하세요. 콘텐츠는 파일 이름의 알파벳 순서대로 추가되므로, 숫자 접두사를 사용하면 암시적인 순서를 명시적인 순서로 바꿀 수 있습니다.

.roo/rules/를 절대 비워두지 마세요. 빈 디렉토리는 .roorules로 대체되므로, 마이그레이션이 불완전하게 끝난 상태에서 레거시 설정이 그대로 활성화될 수 있습니다.

방치된 .clinerules 및 .roorules 파일이 있는지 점검하세요. 이 파일들은 규칙 디렉토리에 콘텐츠가 있는 동안에는 비활성 상태이지만, 디렉토리가 비는 순간 권한을 갖게 됩니다.

변환할 때 프론트매터를 제거하세요. 파싱되지 않은 YAML은 일반 텍스트가 되며, alwaysApply에 대한 텍스트는 모델이 읽어야 하는 노이즈가 됩니다.

AGENTS.md를 리포지토리에 유지하세요. 이 파일은 두 도구 사이에서, 혹은 다음 도구로 전환할 때도 변하지 않는 영역입니다.

Cursor는 프론트매터가 포함된 .mdc 파일을 요구하며, .cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 필드가 없기 때문에 무시된다고 명시하고 있습니다. 반면 Roo Code는 .roo/rules/에서 일반 마크다운을 재귀적으로 읽어 파일 이름의 알파벳 순서대로 추가하며, 모드별 디렉토리를 범위 지정 메커니즘으로 사용하고 디렉토리가 비어 있을 때는 .roorules로 대체(fallback)하도록 문서화되어 있습니다. 둘 다 합리적인 설계입니다. 하지만 동일한 설계는 아니며, 단순히 폴더 이름을 바꾸는 것만으로는 모든 조건부 규칙이 무조건적인 규칙으로 자동으로 변환되어 버립니다.

성공적인 마이그레이션은 재모델링을 의미합니다. globs는 모드가 되고, alwaysApply는 기본값이 되며, 파일 이름은 로드 순서가 되고, 이전에는 서로 만난 적이 없어 호환되는 것처럼 보였던 규칙들은 실제로 조정되어야 합니다. 이 마지막 단계에는 단순한 규칙뿐만 아니라 '이유'가 필요합니다. 따라서 두 도구 중 어느 곳에도 속하지 않는 곳에 그 이유를 보관하세요. 그러면 다음에 도입할 규칙 시스템은 발굴 작업이 아닌 단순한 번역 작업이 될 것입니다.