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

콘텐츠로서의 CLAUDE.md 텍스트. 빌드 명령, 컨벤션, 아키텍처 노트, "항상 X를 수행하라"는 규칙 등입니다. Cursor는 프로젝트 루트 및 하위 디렉터리에서 AGENTS.md("마크다운 형식의 에이전트 지침. .cursor/rules에 대한 간단한 대안")를 읽습니다. 이름을 바꾸거나 복사하기만 하면 끝납니다. 이는 Claude Code 측의 제약 사항과 정반대라는 점에 유의하세요. Claude Code 공식 문서에는 "Claude Code는 AGENTS.md가 아닌 CLAUDE.md를 읽습니다"라고 명시되어 있습니다.

일대일 매핑이 완벽하게 지원되는 경로 범위(Path-scoped) 규칙. 이는 전체 마크다운 마이그레이션에서 가장 깔끔한 부분이지만 대부분의 사람들이 놓치는 부분입니다. Claude Code의 .claude/rules/ 파일은 glob 패턴의 paths: 프론트매터 필드를 사용하며, "paths 필드가 없는 규칙은 무조건 로드되어 모든 파일에 적용"됩니다. Cursor의 프로젝트 규칙도 동일한 의도로 .mdc 프론트매터의 globs를 사용합니다. alwaysApply: false로 설정하고 globs를 제공하면, 해당 규칙은 "일치하는 파일이 컨텍스트에 있을 때 자동으로 첨부"됩니다. 따라서 Claude Code에서 src/api/**/*.ts 범위로 지정된 규칙은 Cursor에서 src/api/**/*.ts 범위의 규칙이 됩니다. 동일한 패턴 구문과 동일한 개념입니다.

개인 선호도 설정. Claude Code의 사용자 수준 레이어는 ~/.claude/CLAUDE.md 및 ~/.claude/rules/입니다. Cursor의 대응 기능은 User Rules(사용자 규칙)로, "모든 프로젝트에 적용되는 Customize → Rules에 정의된 글로벌 선호도"입니다. 동일한 역할을 수행합니다. 단, 의존하기 전에 알아두어야 할 한 가지 주의 사항이 있습니다. "User Rules는 Inline Edit(Cmd/Ctrl+K)에는 적용되지 않으며, Agent(Chat)에서만 사용됩니다."

조직 전체 지침. Claude Code는 IT 부서에서 OS 수준 경로에 배포하는 관리형 정책 CLAUDE.md를 지원합니다. Cursor의 대응 기능은 Team Rules(팀 규칙)로, Team 및 Enterprise 플랜의 Cursor 대시보드에서 생성할 수 있으며, "Enforce this rule(이 규칙 강제 적용): 활성화되면 모든 팀원에게 규칙이 필수로 적용되며 Customize에서 비활성화할 수 없습니다."

그 외에는 아무것도 전송되지 않습니다. 구체적인 목록은 다음과 같습니다.

자동 메모리는 갈 곳이 없습니다. Claude는 각 파일 프론트매터의 type 필드에 기록되는 네 가지 종류의 노트를 스스로 저장합니다. user(사용자의 역할 및 작업 선호도), feedback(사용자가 Claude에게 제공한 수정 사항 및 확인한 접근 방식), project(코드나 git 기록에서 도출할 수 없는 진행 중인 작업 및 결정 사항), reference(프로젝트 외부에서 리소스를 찾을 수 있는 위치)입니다. Claude는 코드베이스에서 읽을 수 있는 내용과 "이미 CLAUDE.md 파일에 명시된 내용"은 의도적으로 생략합니다. 즉, 설계상 자동 메모리에는 다른 어디에도 기록되지 않은 내용만 담기게 됩니다. 그리고 이 메모리는 이동하지 않습니다. "자동 메모리는 로컬 머신에 종속됩니다. 동일한 git 리포지토리 내의 모든 작업 트리(worktree)와 하위 디렉터리는 하나의 자동 메모리 디렉터리를 공유합니다. 파일은 머신 간 또는 클라우드 환경 간에 공유되지 않습니다." 떠나기 전에 꼭 읽어보세요.

@path 임포트는 Cursor에 상응하는 기능이 없습니다. CLAUDE.md는 @path/to/import 구문을 사용하여 "최대 4단계 깊이"까지 재귀적으로 다른 파일을 가져올 수 있으며, 가져온 파일은 "실행 시 확장되어 컨텍스트에 로드"됩니다. Cursor에서 이와 가장 유사한 메커니즘은 규칙 내부의 @filename.ts입니다. FAQ에서도 "규칙의 컨텍스트에 파일을 포함하려면 @filename.ts를 사용하세요"라고 확인해 주지만, 이는 임포트 체인이 아니며 4단계 깊이로 구성할 수 없습니다. 4단계 임포트 트리는 하나의 파일로 병합(flatten)하거나 여러 규칙으로 분할해야 합니다.

CLAUDE.local.md는 형태를 잃게 됩니다. 이는 프로젝트 루트에 있는 gitignore 대상 개인 레이어로, "버전 관리에 커밋해서는 안 되는 프로젝트별 비공개 선호도 설정"을 위한 것입니다. Cursor의 User Rules는 프로젝트별이 아닌 글로벌 단위이므로, 특정 리포지토리에서만 의미가 있었던 개인 노트는 글로벌 설정이 되거나, 스테이징(stage)하지 않도록 주의해야 하는 커밋되지 않은 AGENTS.md 파일이 되어야 합니다.

충돌 처리가 다르게 작동하며, 이는 동작 방식을 변화시킵니다. Claude Code의 경우, "발견된 모든 파일은 서로를 덮어쓰는 대신 컨텍스트에 결합(concatenate)"되며, 파일 시스템 루트부터 아래로 정렬됩니다. 두 파일이 충돌하는 경우 "Claude가 임의로 하나를 선택할 수 있습니다." 반면 Cursor는 명확한 우선순위를 명시합니다. "규칙은 Team Rules → Project Rules → User Rules 순서로 적용됩니다. 적용 가능한 모든 규칙이 병합되며, 지침이 충돌할 경우 이전 소스가 우선합니다." Claude Code가 동전 던지기 식으로 해결하던 모순을 안고 지내왔다면, Cursor는 이를 일관되게 해결할 것입니다. 어쩌면 익숙했던 방식이 아닐 수도 있습니다.

훅(Hooks)은 함께 이동하지 않습니다. Claude Code는 탈출구에 대해 명확히 설명합니다. "Claude의 결정과 관계없이 작업을 차단하려면 대신 PreToolUse 훅을 사용하세요." 이는 컨텍스트라기보다는 강제 실행에 가까우며, 마이그레이션하려는 규칙 시스템의 일부가 아닙니다.

서브에이전트 메모리는 이미 분리되어 있었습니다. "메인 대화의 자동 메모리는 서브에이전트에 로드되지 않으며", 서브에이전트 자체의 자동 메모리는 자체 디렉터리에 저장되는 서브에이전트별 상태로 남게 됩니다. 이 경계에 대해서는 Claude Code 서브에이전트가 메모리를 공유하지 않는 이유에서 다루고 있습니다.

1단계: 변경하기 전에 실제로 로드된 내용 덤프하기

읽어보지 않은 설정을 마이그레이션할 수는 없습니다. Claude Code에서 실제로 로드된 세트는 여러분이 작성한 기억과 다른 경우가 많습니다.

세션에서 /context를 실행하고 Memory files 아래의 목록을 읽어보세요. 이것이 어떤 CLAUDE.md 및 CLAUDE.local.md 파일이 실제로 반영되었는지 보여주는 기준(ground truth)입니다. 공식 문서에서도 이를 첫 번째 디버깅 단계로 사용하는데, "해당 목록에 파일이 없으면 Claude가 볼 수 없기 때문"입니다. 작업 디렉터리 상위의 파일은 실행 시 로드되고, 하위 디렉터리의 파일은 "Claude가 해당 디렉터리의 파일을 읽을 때 필요에 따라 로드"되므로, 한 번도 일치하지 않은 하위 디렉터리 규칙은 나타나지 않습니다.

그 다음 /memory를 실행하세요. 이 명령은 CLAUDE.md, CLAUDE.local.md 및 기타 메모리 파일 위치를 나열하고, 자동 메모리 폴더를 열 수 있는 옵션을 제공합니다. 폴더를 여세요. 그 안의 모든 것은 읽고, 편집하고, 삭제할 수 있는 일반 마크다운 파일이며, feedback 및 project 파일은 대개 전체 설정에서 가장 가치 있는 단락들입니다. 즉, 여러분이 제공한 수정 사항, 마감일, 코드에 없는 결정 사항들입니다. 여전히 중요한 내용을 이식 가능한 형태로 복사해 두세요. 이 내용은 자동으로 Cursor로 이동하지 않습니다.

폴더를 살펴보는 동안 주목해야 할 두 가지가 있습니다. MEMORY.md는 "MEMORY.md 파일의 처음 200줄 또는 처음 25KB 중 먼저 도달하는 기준"까지만 로드되므로, 파일이 길다면 뒷부분은 어차피 읽히지 않고 있었던 것입니다. 또한 주제(topic) 파일은 시작할 때 전혀 로드되지 않으며, Claude는 "표준 파일 도구를 사용하여 필요에 따라 읽습니다." 눈으로 확인하는 대신 로그 형태로 감사를 원한다면, InstructionsLoaded 훅이 "정확히 어떤 지침 파일이 언제, 왜 로드되는지" 기록합니다.

2단계: Cursor에서 레이어 재구축 및 포맷 결정하기

다음 순서대로 네 가지를 결정해야 합니다.

리포지토리 지침: AGENTS.md 또는 .cursor/rules. CLAUDE.md를 AGENTS.md로 복사하면 즉시 작동합니다. 조건부로 로드하려는 내용만 .cursor/rules로 변환하세요. 이것이 바로 .mdc 프론트매터가 제공하는 기능입니다. Cursor의 네 가지 규칙 유형은 Always Apply(항상 적용), Apply Intelligently(지능적 적용 - "설명을 바탕으로 에이전트가 관련이 있다고 판단할 때"), Apply to Specific Files(특정 파일에 적용 - "파일이 지정된 패턴과 일치할 때"), Apply Manually(수동 적용 - "채팅에서 @로 언급될 때")입니다. 이미 paths: 범위의 규칙이 있었다면 이를 변환해야 하며, 나머지는 일반 텍스트로 유지해도 됩니다.

확장자에 주의하세요. ".cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 프론트매터가 없기 때문에 규칙 시스템에서 무시됩니다. 일반 마크다운을 선호한다면 대신 AGENTS.md를 사용하세요." 기존 규칙 파일을 변경 없이 해당 디렉터리에 그대로 넣는 것은 마이그레이션 시 규칙이 작동하지 않게 만드는 가장 흔한 실수입니다.

임포트 병합(Flatten). 모든 @path 체인을 이를 참조하는 파일로 병합하거나 별도의 규칙으로 분리하세요. 이 작업을 수행할 때 길이에 주의해야 합니다. Cursor의 가이드는 "규칙을 500줄 미만으로 유지"하고 "콘텐츠를 복사하는 대신 파일을 참조하여 규칙을 짧게 유지하고 코드가 변경됨에 따라 규칙이 낡아지는 것을 방지"하는 것입니다. Claude Code도 마찬가지로 "CLAUDE.md 파일당 200줄 미만"을 목표로 제시합니다.

글로벌과 로컬 분리. 개인 선호도는 Customize → Rules로 이동합니다. 리포지토리 컨벤션은 AGENTS.md 또는 .cursor/rules로 이동하여 커밋됩니다. 중첩된 AGENTS.md를 사용하면 프론트매터 없이도 디렉터리 범위를 지정할 수 있습니다. 이 경우 지침은 "상위 디렉터리와 결합되며, 더 구체적인 지침이 우선 적용"됩니다.

팀원들과 규칙을 공유한다면 Remote rules(원격 규칙)를 사용하세요. Cursor는 GitHub 리포지토리에서 규칙을 가져올 수 있습니다. Customize → Rules → Add Rule → Remote Rule (Github)로 이동하여 리포지토리 URL을 붙여넣으면, "Cursor가 리포지토리 내의 모든 .mdc 파일을 스캔"하여 상대 경로를 유지한 채 .cursor/rules/imported/<repoName>에 배치합니다. 이는 .mdc 전용 기능이므로 일반 텍스트를 유지하는 대신 변환해야 하는 이유가 되며, 두 도구 중 공유 및 업데이트가 가능한 규칙 소스에 가장 가까운 방식입니다.

당분간 두 도구를 모두 실행하게 된다면, 반대 방향의 마이그레이션은 Cursor에서 Claude Code로 마이그레이션하기에 작성되어 있으며, 파일 표준에 관한 질문은 CLAUDE.md를 AGENTS.md로 마이그레이션하기에서 다루고 있습니다.

1단계에서 수행한 작업을 돌아보세요. Claude가 수개월 동안 프로젝트에 대해 작성한 노트 폴더를 열고, 직접 읽어본 뒤 유용한 부분을 다른 곳으로 복사했습니다. 이 방법은 작동하지만, 딱 한 번만 유효한 임시방편입니다.

이 작업이 수동일 수밖에 없는 이유는 구조적인 한계 때문입니다. 자동 메모리는 설계상 로컬 머신에 종속됩니다. Cursor의 규칙은 설계상 리포지토리별로 버전 관리됩니다. 두 도구 모두 항상 켜져 있는 콘텐츠가 모든 요청과 함께 전송되기 때문에, 한 곳에서는 200줄, 다른 곳에서는 500줄과 같이 전송 용량을 제한합니다. 어느 도구도 아키텍처가 왜 그렇게 설계되었는지에 대한 영구적인 저장소가 되도록 설계되지 않았으며, 스스로 그렇다고 주장하지도 않습니다.

바로 이 역할을 MemoryLake가 수행합니다. 도구들이 읽을 수 있는 레이어에 프로젝트의 영구적인 지식을 보관하므로, 도구를 전환하더라도 지식을 다시 전송할 필요가 없습니다. 설정은 다음 세 단계로 진행됩니다.

1단계: API 키 생성하기

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 모든 도구에서 이 하나의 자격 증명을 공유하여 사용합니다.

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

하나의 사실만 담은 짧은 항목으로 작성합니다. 방금 읽은 자동 메모리 폴더가 훌륭한 원천 자료가 되며, 이미 대략적인 카테고리로 분류되어 있습니다:

두 번 이상 제공해야 했던 수정 사항. 이는 Claude Code 자체의 feedback 카테고리에 해당하며, 디렉터리에서 가장 가치 있는 정보입니다. 두 도구 모두 읽을 수 있는 곳으로 이동시키세요.

결정을 강제했던 제약 조건이 포함된 결정 사항. "부하가 걸리면 읽기 복제본(read replica)이 지연되므로 마이그레이션은 추가 전용으로만 진행됩니다." 규칙은 정책을 명시할 뿐이며, 오직 이러한 제약 조건만이 다음 주에 대안이 다시 제안되는 것을 방지합니다.

이미 거부한 접근 방식과 그 이유. 규칙 파일이나 커밋 메시지 어디에도 나타나지 않는 카테고리입니다. 새로운 에이전트가 투입될 때마다 이 방식을 다시 제안하곤 합니다.

어렵게 배운 환경적 사실들. CI에서만 실패하는 테스트, 문서화되지 않은 속도 제한(rate limit), 최근 데이터가 없는 스테이징 데이터베이스 등입니다.

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

사용 중인 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽습니다. 덕분에 전환 과정을 언제든 되돌릴 수 있습니다. 아직 도구를 결정하는 중이더라도 두 에디터 모두 동일한 레이어를 읽을 수 있습니다.

세 가지 명확한 한계가 있습니다. MemoryLake는 자동 메모리 폴더를 읽지 않으며, CLAUDE.md나 Cursor 규칙을 작성하지 않습니다. 즉, 1단계는 여전히 수동으로 읽어야 하며, 규칙 파일은 각 도구를 제어하는 수단입니다. MemoryLake는 오직 사용자나 에이전트가 입력한 내용만 보관합니다. 또한 규칙과 메모리는 강제된 설정이 아닌 컨텍스트에 해당하므로, 상황에 관계없이 매번 특정 작업이 실행되어야 한다면 메모리 레이어가 아닌 훅(hook)이나 CI 검사를 사용해야 합니다.

전환이 일방통행이 아니게 됩니다. 두 에디터가 동일한 외부 메모리를 읽는다는 것은 Claude Code 설정을 해체하지 않고도 2주 동안 Cursor를 사용해 볼 수 있음을 의미합니다.

그대로 머물더라도 자동 메모리를 읽어볼 가치가 있습니다. 대부분의 사람들은 이 폴더를 열어본 적이 없지만, project 및 feedback 파일은 지난 6개월 동안의 놀랍도록 훌륭한 요약본입니다.

새 도구에서 규칙 파일이 더 짧아집니다. CLAUDE.md가 200줄 이상으로 늘어나는 이유는 제어와 기억이라는 두 가지 역할을 동시에 수행하기 때문입니다. 이를 한 번 분리하면 두 도구의 용량 제한에 얽매이지 않게 됩니다.

"에이전트가 아직 내 프로젝트를 모른다"는 질문에 대한 진짜 해답을 얻을 수 있습니다. "규칙을 더 작성하라"가 아니라 "그 지식은 애초에 규칙에 없었다"가 답이 됩니다. 이에 대한 일반적인 사례는 RAG가 메모리가 아닌 이유에서 다룹니다.

다른 작업을 하기 전에 자동 메모리 폴더를 먼저 여세요. 상대측에 임포터가 없는 유일한 설정 영역이자, 여러분이 직접 작성하지 않은 부분입니다.

작성한 기억이 아닌 /context를 신뢰하세요. Memory files 목록이 실제로 로드된 내용입니다. 일치한 적이 없는 하위 디렉터리 파일은 목록에 나타나지 않습니다.

paths: 규칙은 globs로 변환하고, 나머지는 일반 텍스트로 유지하세요. 매핑이 직접적으로 이루어집니다. 그 외의 모든 것은 AGENTS.md로 유지하는 것이 효율적입니다.

.cursor/rules 안에 일반 .md 파일을 그대로 두지 마세요. 아무런 경고 없이 무시됩니다. 프론트매터가 포함된 .mdc를 사용하거나 AGENTS.md를 사용하세요.

@path 임포트를 재현하려 하지 말고 병합(flatten)하세요. Cursor의 @filename 참조는 4단계 깊이의 임포트 체인을 지원하지 않습니다.

충돌이 발생했을 때의 우선순위를 결정하세요. Cursor는 Team Rules, Project Rules, User Rules 순으로 병합하는 반면, Claude Code는 단순히 결합한 뒤 임의로 선택했습니다. 그동안 대충 넘어가던 충돌을 해결해 두세요.

글로벌 선호도는 User Rules에 넣고, Inline Edit과의 차이점에 유의하세요. 프로젝트 전반에 적용되지만 Cmd/Ctrl+K에는 적용되지 않습니다.

의사 결정의 배경이 되는 논리는 두 규칙 시스템 외부에 보관하세요. 규칙은 방향과 포인터일 뿐입니다. 결정 뒤에 숨겨진 논리야말로 에이전트가 예상치 못한 상황을 처리할 수 있게 해주는 열쇠입니다. 이 형태는 에이전트가 사용자가 작성한 지침 파일을 무시하는 이유에서 다루고 있습니다.

Claude Code에서 Cursor로의 전환은 서류상으로는 쉬워 보이지만 실제로는 손실이 발생하기 쉬우며, 그 차이점은 사람들이 예상하는 곳에 있지 않습니다. CLAUDE.md는 이름만 바꾸면 AGENTS.md가 됩니다. paths: 범위의 규칙은 Cursor의 globs에 거의 정확히 매핑됩니다. 사용자 수준 파일은 User Rules가 되고, 관리형 정책 파일은 Team Rules가 됩니다.

이동하지 않는 것은 Claude가 스스로 작성한 모든 내용입니다. 자동 메모리는 기본적으로 활성화되어 있으며, ~/.claude/projects/<project>/memory/에 로컬 마크다운으로 저장되어 CLAUDE.md에는 없는 핵심 자료들을 담고 있지만, Cursor는 이를 전혀 볼 수 없습니다. @path 체인은 병합해야 하고, CLAUDE.local.md는 프로젝트별 범위를 잃게 되며, Claude Code가 임의로 해결하던 충돌은 이제 명시된 우선순위에 따라 해결됩니다.

그러므로 먼저 자동 메모리 폴더를 읽고, /context로 로드된 세트를 덤프한 뒤, 조건이 필요한 규칙만 변환하고, 결정 사항과 거부된 접근 방식은 두 에디터 모두 쿼리할 수 있는 레이어에 보관하세요.