Cursor와 Claude Code 간에 하나의 메모리를 공유하는 방법 (단계별 가이드, 2026)

메커니즘은 대칭적이지만 호환되지 않습니다

Cursor의 문서는 네 가지 종류의 규칙을 설명합니다. .cursor/rules에 .mdc 파일로 저장되는 프로젝트 규칙, Cursor 환경에 글로벌하게 적용되는 사용자 규칙, Team 및 Enterprise 플랜의 대시보드에서 관리되는 팀 규칙, 그리고 프로젝트 루트의 마크다운 대안인 AGENTS.md입니다. Claude Code의 문서는 네 가지 범위의 CLAUDE.md를 설명합니다. 관리형 정책(managed policy), 사용자(~/.claude/CLAUDE.md), 프로젝트(./CLAUDE.md 또는 ./.claude/CLAUDE.md), 로컬(CLAUDE.local.md) 범위가 있으며, 여기에 경로 범위 지침을 위한 .claude/rules/가 추가됩니다.

이 둘을 나란히 놓으면 서로 다른 파일 이름, 서로 다른 프론트매터 필드, 서로 다른 로딩 규칙을 사용하는 거의 평행한 두 개의 시스템이 됩니다. 어느 쪽도 상대방의 기본 포맷을 읽지 않습니다. Claude Code 문서에서도 "Claude Code는 AGENTS.md가 아니라 CLAUDE.md를 읽습니다"라고 직접적으로 명시하고 있습니다.

두 도구가 모두 읽는 하나의 파일과 이를 연결하는 문서화된 방법

이 부분이 대부분의 사람들이 놓치는 부분입니다. Cursor는 프로젝트 루트의 AGENTS.md를 지원되는 지침 파일로 나열하며, 더 구체적인 파일이 우선순위를 갖는 하위 디렉터리의 중첩된 AGENTS.md 파일도 지원합니다. 그리고 Claude Code의 문서에는 동일한 파일을 자체적으로 작동하게 만드는 정확한 방법이 나와 있습니다. "저장소에서 이미 다른 코딩 에이전트를 위해 AGENTS.md를 사용하고 있다면, 이를 가져오는 CLAUDE.md를 생성하여 두 도구가 지침을 중복하지 않고 동일하게 읽도록 하십시오."

이는 @AGENTS.md가 포함된 한 줄짜리 CLAUDE.md이거나, Claude 전용 추가 사항이 필요하지 않은 경우 심볼릭 링크(symlink)를 사용하는 방식입니다. 이렇게 하면 두 도구 모두 하나의 파일을 읽게 됩니다. 이는 꼼수가 아니라 양쪽 모두에서 문서화된 공식 패턴입니다.

파일 트릭으로 해결할 수 없는 부분

파일을 어떻게 배치하든 두 가지는 분리된 상태로 유지됩니다.

Claude Code의 자동 메모리(auto memory). 기본적으로 활성화되어 있으며, ~/.claude/projects/<project>/memory/ 아래에 노트를 저장하고, 매 세션마다 MEMORY.md 파일의 처음 200줄 또는 25KB를 로드합니다. 이는 명시적으로 머신 로컬(machine-local)입니다. 문서에 따르면 이 파일들은 "머신이나 클라우드 환경 간에 공유되지 않습니다." 또한 사용자가 아닌 Claude가 직접 작성합니다. Cursor에는 이를 읽을 수 있는 상응하는 기능이 없으며, 커밋할 수 있는 어떤 파일로도 이를 보이게 만들 수 없습니다.

조건부 로딩(Conditional loading). Cursor의 네 가지 애플리케이션 모드는 규칙이 컨텍스트에 들어가는 시점을 결정합니다. alwaysApply: true, 지능형 적용을 위한 description, 특정 파일을 위한 globs, 또는 @-멘션이 필요한 수동 규칙 등이 있습니다. Claude Code의 .claude/rules/는 동일한 목적으로 paths: 프론트매터 필드를 사용합니다. 둘 다 합리적인 방식이지만, "콘텐츠를 공유한다"고 해서 "동일한 순간에 로드된다"는 것을 의미하지는 않습니다.

MCP는 두 도구가 이미 지원하는 유일한 채널입니다

하지만 AGENTS.md 외에도 두 도구가 공통으로 가지고 있는 두 번째 요소가 있으며, 이것이 더 흥미로운 부분입니다. 바로 둘 다 MCP를 지원한다는 점입니다. Claude Code는 하위 에이전트별 인라인 mcpServers 정의를 포함하여 MCP 서버 구성을 주요 기능으로 문서화하고 있으며, Cursor는 자체 설정에서 MCP 구성을 노출합니다.

이것이 중요한 이유는 "메모리 공유"의 의미를 바꾸기 때문입니다. 공유 파일은 정적입니다. 동일한 텍스트가 양쪽에 로드되고 수동으로 업데이트됩니다. 반면 공유 서버는 동적입니다. 두 도구 모두 무언가가 필요한 순간에 동일한 저장소를 쿼리하며, 한쪽에서 기록한 내용은 다음 읽기 시점에 다른 쪽에서도 즉시 볼 수 있습니다. 작업하면서 계속 변하는 지식(실제로 중요한 대부분의 지식)의 경우, 이 두 번째 형태가 실제로 유효한 방식입니다.

또한 두 도구의 기본 메모리 시스템 중 하나를 선택할 필요가 없음을 의미합니다. Claude Code는 로컬 리콜을 위해 자동 메모리를 유지하고, Cursor는 조건부 로딩을 위해 규칙을 유지하며, 지속적인 프로젝트 지식은 두 도구 중 어느 쪽도 상대방의 포맷을 이해할 필요 없이 양쪽 모두 접근할 수 있는 한 곳에 저장됩니다.

그리고 무언가를 복사하기 전에 알아두어야 할 한 가지 함정이 있습니다. Cursor 문서에 따르면 ".cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 프론트매터가 없기 때문에 규칙 시스템에서 무시됩니다." 콘텐츠를 이동하다가 해당 디렉터리에 일반 마크다운 파일을 넣으면 아무런 경고 없이 작동하지 않습니다. 이 구체적인 실패 사례는 why Cursor forgets project rules에서 다루고 있습니다.

동일한 내용의 파일 두 개를 유지 관리하기. 가장 기본적이고 직관적인 방법이지만 약 2주 동안만 유효합니다. 그 후 누군가 한쪽 파일을 업데이트하면, 두 파일 모두 정상적으로 관리되는 것처럼 보이기 때문에 오류나 차이점(diff)을 인지하지 못한 채 두 도구의 동작이 어긋나기 시작합니다.

두 파일 모두 거대하게 만들기. 파일이 유일한 채널이라면 모든 내용이 파일에 들어가게 됩니다. 하지만 두 개발사 모두 이를 권장하지 않습니다. Cursor는 규칙을 500줄 미만으로 유지하고 큰 규칙은 조합 가능한 조각으로 나눌 것을 권장하며, Claude Code는 파일당 200줄 미만을 목표로 할 것을 권장하면서 파일이 길어질수록 "더 많은 컨텍스트를 소비하고 규칙 준수율을 떨어뜨린다"고 지적합니다.

여러 머신 간에 `~/.claude` 동기화하기. 자동 메모리가 머신 로컬이라는 점을 우회하기 위해 전체 설정 디렉터리를 동기화하는 사람들도 있습니다. 이는 실무자들의 임시방편일 뿐 문서화된 기능이 아니며, 쓰기 충돌의 실제 위험이 따릅니다. 정식 설정이 아닌 실험적인 방법으로만 취급하십시오.

`/init`을 실행하고 끝내기. 유용하지만 잘 사용되지 않는 방법입니다. Claude Code의 /init은 .cursor/rules/ 또는 .cursorrules에서 Cursor 규칙을 읽어 생성된 CLAUDE.md에 관련 부분을 통합하며, CLAUDE_CODE_NEW_INIT=1을 설정하면 AGENTS.md, .devin/rules/, .windsurf/rules/, .clinerules도 읽습니다. 하지만 이는 일회성 복사일 뿐 링크가 아닙니다. 한 번 실행되고 나면 두 파일은 다시 어긋나기 시작합니다. 지원되는 에이전트의 구성을 가져오고 MCP 서버, 명령, 하위 에이전트, 스킬을 이전하는 /import도 마찬가지로 동기화가 아닌 마이그레이션입니다. 이 일방향 이동을 제대로 수행하고 싶다면, migrating Cursor rules to Claude Code에서 다루고 있습니다.

비용을 감수하기. 가장 흔한 결과로, 사람들은 그냥 다시 설명합니다. 이는 메시지마다 토큰 비용을 발생시킬 뿐만 아니라, 실제로 중요한 부분인 '첫 번째 도구가 학습한 내용을 두 번째 도구가 모른 채 결정을 내린다'는 문제를 야기합니다.

문제를 둘로 나누면 양쪽 모두 쉬워집니다.

매번 컨텍스트에 포함되어야 하는 규칙은 커밋된 하나의 파일에 속해야 합니다. AGENTS.md를 실제 콘텐츠로 사용하고, 이를 가져오는 한 줄짜리 CLAUDE.md를 사용하십시오. 지식 베이스가 아니라 코드 리뷰에서 방어할 만한 규칙들만 짧게 유지하십시오.

계속 늘어나는 지식은 두 도구 모두 쿼리하는 메모리 레이어에 속해야 합니다. 그것이 바로 MemoryLake입니다. 두 에이전트 모두 접근할 수 있는 하나의 저장소로, 그렇지 않았다면 한 도구의 비공개 메모리 디렉터리에 머물렀을 결정 사항과 제약 조건을 보관합니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 두 도구 모두에 하나의 자격 증명을 사용하는 것이 핵심입니다. 자격 증명은 현재 사용 중인 에디터에 종속되지 않습니다.

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

계속해서 다시 설명해야 했던 내용부터 시작하십시오. 아키텍처 결정과 그 배경이 되는 이유, 컨텍스트 없이는 임의적으로 보이는 제약 조건, 사람들의 머릿속에만 존재하는 컨벤션, 시도했다가 거부된 접근 방식 등입니다. Claude Code가 자동 메모리를 축적해 왔다면 해당 디렉터리를 열어 읽어보십시오. 그 안의 지속적인 사실들은 바로 Cursor가 한 번도 접근하지 못했던 자료들입니다. 검색 시 유용한 결과를 얻을 수 있도록 항목은 짧고 단일 주제로 유지하십시오.

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

두 도구를 모두 연결합니다. MemoryLake는 MCP 및 API를 통해 접근할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트들은 MCP 서버를 가리켜 연결하고, Cursor는 자체 MCP 구성을 통해 연결합니다. 이 시점부터 두 도구는 동일한 지식을 읽게 되며, 한쪽에서 작업하는 동안 기록된 결정 사항을 다른 쪽에서도 사용할 수 있게 됩니다. MCP 측면의 일반적인 가이드는 setting up cross-AI memory with MCP를 참조하십시오.

두 가지 명확한 한계가 있습니다. 첫째, 이것이 두 도구 자체의 메모리 시스템을 병합하지는 않습니다. Claude Code는 계속해서 머신 로컬 자동 메모리를 작성할 것이며, 이는 최근 로컬 작업을 회상하는 데 유용하므로 괜찮습니다. 둘째, 이것은 강제 레이어가 아닙니다. 두 개발사 모두 지침을 강제 설정이 아닌 컨텍스트로 설명하므로, 모델의 결정과 관계없이 반드시 유지되어야 하는 사항은 훅(hook)이나 CI 검사에 두어야 합니다.

한 번의 수정으로 두 도구 모두 적용. 가장 구체적인 이점입니다. 현재는 Cursor에 "우리는 더 이상 그 ORM을 사용하지 않습니다"라고 말하면 정확히 하나의 도구만 학습합니다. 하지만 이 수정 사항이 공유 레이어에 반영되면, 다른 도구도 해당 제안을 중단합니다.

인수인계 시 컨텍스트 손실 방지. 일반적인 워크플로우는 한 도구에서 탐색하고 다른 도구에서 실행하는 것입니다. 그 인수인계 과정에서 다시 설명하는 일이 발생하는데, 공유 레이어는 이 단계를 제거해 줍니다. 이는 하나의 도구 내에서 작동하는 sharing context between Claude Code sessions의 개념을 두 도구 간으로 확장한 것과 유사합니다.

두 지침 파일 모두 짧아집니다. 참조 지식을 검색할 수 있게 되면 AGENTS.md는 원래 의도했던 짧은 목록으로 유지될 수 있으며, 이는 규칙이 얼마나 안정적으로 준수되는지 눈에 띄게 향상시킵니다.

머신 간의 경계가 더 이상 중요하지 않게 됩니다. 자동 메모리가 머신 로컬이라는 것은 누적된 지식의 절반이 단 하나의 컴퓨터에만 존재한다는 것을 의미합니다. 공유 레이어가 이 메커니즘 자체를 바꾸지는 않지만, 중요한 부분이 그곳에만 머물지 않도록 해줍니다. 이는 stopping Cursor from forgetting across machines에서 설명한 문제를 해결합니다.

세 번째 도구를 추가하는 것은 단지 연결하는 일입니다. 다음에 어떤 도구를 도입하든 빈 도화지에서 시작하여 일주일 동안 다시 설명하는 대신, 동일한 메모리를 읽게 됩니다.

하나의 실제 파일, 하나의 포인터. AGENTS.md가 콘텐츠를 보유하고, CLAUDE.md에는 @AGENTS.md와 선택적으로 그 아래에 짧은 Claude 전용 섹션을 포함합니다. 절대 두 개의 전체 복사본을 만들지 마십시오.

glob 설정을 일치시키십시오. Cursor 규칙의 globs와 Claude Code 규칙의 paths:가 동일한 파일 세트를 설명할 때, 이 둘을 쌍으로 검토할 수 있습니다. 이들이 어긋나면 특정 영역 규칙이 한 도구에는 적용되고 다른 도구에는 적용되지 않는 현상이 발생합니다.

절대 `.cursor/rules`에 일반 `.md` 파일을 두지 마십시오. 아무런 경고 없이 무시됩니다. 프론트매터가 없는 콘텐츠는 AGENTS.md에 속해야 합니다.

신중하게 `/init`을 한 번만 실행하십시오. 이는 CLAUDE.md를 시작하기에 좋은 출발점이며 기존 Cursor 및 Copilot 규칙을 읽어옵니다. 다만 이를 지속적인 동기화로 오해해서는 안 됩니다.

구조를 변경한 후에는 무엇이 로드되었는지 확인하십시오. Claude Code는 세션 내에서 /context를 통해 로드된 메모리 파일을 나열합니다. 모델이 사용자를 무시하고 있다고 결론 내리기 전에 먼저 확인하십시오. 이 차이는 why Claude Code forgets project context에서 다룬 것처럼, 5분 만에 해결할 수 있는 문제와 일주일 동안 프롬프트 튜닝을 해야 하는 문제의 차이입니다.

결정 사항뿐만 아니라 거부된 사항도 기록하십시오. 단일 항목 중 가장 가치가 높은 카테고리입니다. 이미 배제한 사항을 읽을 수 있는 곳에 기록해 두지 않으면, 두 도구 모두 해당 사항을 다시 제안할 것입니다.

두 도구를 사용하면서 발생하는 비용은 두 가지 요소로 구성되며, 각각 다른 해결책이 필요합니다. 항상 켜져 있는 규칙은 실제로 하나의 파일이 될 수 있습니다. Cursor는 AGENTS.md를 읽고, Claude Code의 자체 문서에서는 한 줄짜리 CLAUDE.md에서 이를 가져오라고 안내합니다. 오늘 오후에 바로 적용해 보십시오. 가장 자주 중요하게 작용하는 레이어에서 발생하는 어긋남 문제를 해결할 수 있습니다.

파일이 할 수 없는 것은 누적되는 지식을 공유하는 것입니다. Claude Code 측에서 이 레이어는 머신 로컬이자 자체 작성되는 반면, Cursor 측에서는 프론트매터 조건에 의해 제어되기 때문입니다. 이 절반의 영역을 두 도구 모두 쿼리하는 메모리 레이어에 두면, 편집 작업과 에이전트 작업 간의 인수인계 과정에서 컨텍스트가 유실되는 현상을 막을 수 있습니다.