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

규칙은 텍스트로만 전송되며 동작으로 전송되지 않습니다. Cline의 문서에 따르면 워크스페이스 규칙은 프로젝트 루트의 .clinerules/에 저장되며, Cline은 ".clinerules/ 내부의 모든 .md 및 .txt 파일을 처리하여 하나의 통합된 규칙 세트로 결합"합니다. 글로벌 규칙은 macOS 및 Linux의 ~/Documents/Cline/Rules 아래에 위치하며, 충돌이 발생할 경우 워크스페이스 규칙이 우선 적용됩니다.

Cursor의 모델은 본질적으로 다릅니다. 프로젝트 규칙은 버전 관리 하에 있는 .cursor/rules 폴더의 .mdc 파일이며, 세 가지 프론트매터 필드(alwaysApply, description, globs)가 각 규칙이 컨텍스트에 포함되는 시점을 결정합니다. Cursor 문서에는 해당 폴더의 일반 .md 파일은 이러한 필드가 없기 때문에 규칙 시스템에서 무시되며, 일반 마크다운은 대신 AGENTS.md에 작성해야 한다고 명시되어 있습니다.

특히 .txt 파일의 경우를 주의하세요. Cline은 .txt 규칙을 읽지만, Cursor의 규칙 시스템에는 이를 위한 자리가 전혀 없습니다. 경고 없이 사라지게 됩니다.

활성화 의미론(semantics)은 거의 일치하지만, 형태는 일치하지 않습니다. Cline의 조건부 규칙은 "현재 파일이 정의된 범위와 일치할 때만 활성화"되며, 변환에서 가장 중요한 문장은 "프론트매터가 없는 규칙은 항상 활성화된다"는 점입니다.

따라서 일반적인 .clinerules/ 폴더는 항상 활성화되는 파일들이 결합된 덩어리입니다. 이는 사실상 하나의 거대한 상시 활성화 지시문 블롭(blob)과 같습니다. 이를 규칙을 500행 미만으로 유지하라는 자체 가이드라인을 가진 도구(Cursor)에서 alwaysApply: true를 사용해 .mdc 파일로 1대1 변환하는 것은, 원본을 충실하게 재현한 것이지만 잘못된 방식입니다.

Memory Bank는 파일로 전송되지만 그 메커니즘은 유실됩니다. 이 부분이 중요합니다. Cline의 Memory Bank는 "Cline이 세션 간에 컨텍스트를 유지하도록 돕는 구조화된 문서 시스템"으로 설명되어 있으며, 이를 통해 Cline을 "상태가 없는(stateless) 어시스턴트에서 지속적인 개발 파트너"로 전환합니다. 여기에는 projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md라는 6가지 핵심 파일이 규정되어 있습니다.

Cline의 자체 문서에 1인칭으로 작성된 전제 조건을 읽어보세요. "내 메모리는 세션 간에 완전히 리셋됩니다. 이는 한계가 아니라 내가 완벽한 문서를 유지하도록 이끄는 원동력입니다." 그리고 운영 규칙은 다음과 같습니다. "각 리셋 후, 나는 프로젝트를 이해하고 작업을 효과적으로 계속하기 위해 전적으로(ENTIRELY) 나의 Memory Bank에 의존합니다."

이것이 작동하는 이유는 Cline이 각 작업의 시작 부분에서 이 모든 것을 읽도록 지시받기 때문입니다. Cursor에는 이와 동등한 규칙이 없습니다. 폴더를 복사하면 문서는 최신 상태로 존재하지만, 아무도 읽지 않는 상태가 됩니다.

Cursor가 대신 제공하는 것. 문서에 따르면 네 가지 규칙 유형이 있습니다. 코드베이스로 범위가 지정되고 버전 관리되는 .cursor/rules의 프로젝트 규칙, 전체 Cursor 환경에 적용되는 사용자 규칙, Team 및 Enterprise 플랜의 대시보드에서 관리되는 팀 규칙, 그리고 .cursor/rules 대신 사용할 수 있는 일반 마크다운 형식의 AGENTS.md입니다. 규칙은 모델의 컨텍스트 앞에 추가됩니다. 그리고 Cursor는 Cline만큼이나 명확하게 근본적인 현실을 밝히고 있습니다. "대규모 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다."

두 도구 모두 메모리가 존재하지 않는다는 점에 동의합니다. 차이점은 이에 대해 어떻게 대처해야 하는가입니다. Cline은 문서를 종교적일 정도로 철저히 유지하라고 말하고, Cursor는 규칙을 정밀하게 구성하라고 말합니다. 이번 마이그레이션은 두 파일 형식 간의 이동이 아니라, 이 두 가지 철학 간의 이동입니다.

1단계: 변환하기 전에 통합된 블롭 분할하기

파일 대 파일로 그대로 변환하지 마세요. Cline이 처리했던 방식대로 .clinerules/ 전체 내용을 하나의 문서로 읽고, 각 부분이 언제 적용되어야 하는지에 따라 다시 분류하세요.

• 항상, 모든 완료 시: 답변을 잘못되게 만들 수 있는 두세 가지 제약 조건. 저작권 헤더, "생성된 파일을 절대 수정하지 말 것", 엄격한 아키텍처 규칙 등.
• 특정 파일을 다룰 때만: 디렉터리, 언어 또는 레이어를 언급하는 모든 것. 보통 규칙의 대부분이 여기에 해당합니다.
• 모델이 관련이 있다고 판단할 때만: 경로에 매핑되지 않는 도메인 규칙.
• 요청할 때만: 긴 체크리스트, 릴리스 절차, 리뷰 프로토콜.

그런 다음 .cursor/rules에 그룹당 하나의 .mdc 파일을 작성하고, 이에 맞게 프론트매터를 설정합니다.

• 항상 → alwaysApply: true (globs 및 description은 무시됨)
• 파일 범위 지정 → alwaysApply: false와 함께 globs: src/api/**/*.ts 설정
• 모델 선택형 → 적절한 description: 작성 및 globs 없음
• 수동 → 둘 다 설정하지 않고, 채팅에서 @rule-name으로 호출

이 작업을 수행할 때 주의해야 할 두 가지 함정이 있습니다. 확장자는 반드시 .mdc여야 합니다. .cursor/rules 폴더 내의 .md 파일은 오류 표시 없이 완전히 무시됩니다. 그리고 Cline 글로벌 규칙(~/Documents/Cline/Rules)은 프로젝트가 아닌 개인 설정이므로, 리포지토리가 아니라 Cursor의 Customize 메뉴 아래에 있는 User Rules에 들어가야 합니다. 팀이 표준을 공유하는 경우, Team 및 Enterprise 플랜의 대시보드 관리형 팀 규칙이 그 상위 레이어가 됩니다.

이 기회에 불필요한 규칙도 삭제하세요. 마이그레이션은 누군가가 새로운 시각으로 모든 규칙을 읽는 유일한 순간입니다. 그렇지 않으면 이미 중단된 서비스를 위해 작성된 규칙이 계속해서 적용될 것입니다.

2단계: Memory Bank의 운명 결정하기

세 가지 옵션이 있으며, 어떤 것을 선택하느냐보다 의도적으로 선택하는 것 자체가 중요합니다.

옵션 A: 그대로 유지하고 Cursor가 이를 가리키도록 설정. alwaysApply: true인 하나의 .mdc 규칙을 작성하여, 에이전트가 작업을 시작하기 전에 memory-bank/activeContext.md 및 memory-bank/progress.md를 읽고 작업이 끝나면 이를 업데이트하도록 지시합니다. 이는 Cline의 동작을 가장 유사하게 재현하는 방법입니다. 하지만 매 세션마다 항상 켜져 있는 지시문과 이로 인해 발생하는 파일 읽기 비용이 추가된다는 실질적인 대가가 따릅니다.

옵션 B: 영구적인 부분은 규칙으로 통합하고 나머지는 문서로 유지. systemPatterns.md 및 techContext.md는 대부분 안정적인 아키텍처 및 기술 스택 정보이므로, 프로젝트 규칙이나 AGENTS.md로 변환합니다. projectbrief.md 및 productContext.md는 사람이 한 번 읽는 오리엔테이션 문서이므로 리포지토리 문서로 남겨둡니다. activeContext.md 및 progress.md는 세션 상태를 나타내며, 이 부분에서는 솔직해져야 합니다. Cursor에서는 이를 자동으로 유지 관리해 주지 않으므로, 직접 수동으로 업데이트하지 않으면 프로젝트 상태에 대해 잘못된 정보를 제공하는 쓸모없는 문서로 방치될 것입니다.

옵션 C: 포맷은 폐기하고 콘텐츠만 유지. 6개 파일 구조가 존재하는 이유는 Cline이 매 리셋 후 찾아볼 고정된 장소가 필요했기 때문입니다. 더 이상 Cline을 실행하지 않는다면 이 구조는 뼈대에 불과합니다. 중요한 것은 그 안의 결정 사항, 아키텍처, 제약 조건이 검색 가능한 어딘가에 유지되는 것입니다.

어떤 것을 선택하든, 아무것도 하지 않은 채 방치하지 마세요. 리포지토리에 방치된 오래된 activeContext.md는 Memory Bank가 아예 없는 것보다 나쁩니다. 다음 작업자나 이를 발견한 다음 에이전트가 그 내용을 그대로 믿어버릴 것이기 때문입니다.

기존 설정을 종료하기 전에 확인해야 할 항목이 하나 더 있습니다. 바로 Cline이 학습했지만 Memory Bank에 기록하지 않은 내용입니다. 세션 중에 Cline에게 프로젝트의 특이사항에 대해 무엇을 알고 있는지, 새로운 개발자에게 무엇을 경고하고 싶은지 물어보세요. 그리고 그 답변을 어딘가에 붙여넣어 두세요. 이것이 이번 마이그레이션에서 기한이 있는 유일한 작업입니다.

Cline의 Memory Bank가 올바르게 짚어낸 점에 주목해 보세요. 사람들이 이를 좋아하는 이유는 지식을 단순히 채팅의 부수 효과가 아니라 일급 아티팩트(first-class artifact)로 취급하기 때문입니다. 단점은 이 아티팩트가 저장되는 위치와 관리 주체입니다. 하나의 리포지토리에 있는 6개의 파일은 단 하나의 도구 규칙에 의해 업데이트되며, 여러분이 사용하는 다른 모든 어시스턴트에게는 보이지 않습니다.

따라서 그 본질은 유지하되 저장 위치를 바꾸세요. 규칙은 Cursor 형식에 맞춰 작게 리포지토리에 유지합니다. 그 뒤에 있는 지식(결정 사항, 아키텍처, 장애 이력, 계약 등)은 모든 도구가 읽고 쓸 수 있는 저장소에 보관합니다.

MemoryLake는 이를 위한 메모리 레이어입니다. 문서, 결정 사항, 프로젝트 지식이 보관되는 단일 저장소로, Claude 및 Codex와 같은 MCP 지원 도구에서 직접 읽을 수 있으며 API를 통해 ChatGPT에서도 읽을 수 있습니다. 특정 에이전트의 규칙에 의존하지 않고도 Memory Bank의 아이디어를 실현할 수 있습니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 채팅창에 직접 붙여넣는 대신 환경 변수나 보안 관리자(secret manager)에 보관하세요.

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

기존 Memory Bank가 담당하던 문서, 이미지, 파일들을 업로드하세요. systemPatterns.md 및 techContext.md를 있는 그대로 업로드하고, 아키텍처 결정 사항과 그 이유, 장애 보고서, API 계약서, 그동안 축적된 제약 조건들을 추가합니다. 요약본보다는 원본 소스를 업로드하는 것이 좋습니다. 요약하는 과정에서 규칙 뒤에 숨겨진 맥락과 이유가 유실되기 때문입니다.

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

MCP 또는 API를 통해 Claude, Codex, OpenClaw 및 기타 AI 에이전트에게 메모리 액세스 권한을 부여하세요. MCP를 지원하는 도구는 동일한 저장소를 직접 읽으므로, 작년에 채택한 특정 폴더 규칙 대신 이번 달에 사용 중인 에이전트가 누구든 상관없이 지식에 접근할 수 있습니다.

첫 번째 차이점은 항상 켜져 있는 규칙을 단 세 개로 줄일 수 있다는 것입니다. 모든 것을 항상 적용하도록 설정해야 했던 압박은 컨텍스트를 둘 다른 곳이 없었기 때문입니다. 검색(retrieval)이 가능해지면, alwaysApply: true는 답변을 완전히 잘못되게 만들 수 있는 핵심 규칙에만 예약해 둘 수 있습니다.

두 번째는 activeContext.md가 언젠가 거짓말이 될 위험에서 벗어난다는 점입니다. 아무도 관리하지 않는 상태 정보는 부패하기 마련입니다. 하지만 에이전트가 작업하면서 다시 기록하는 저장소의 상태는 최신으로 유지되며, 결정 사항이나 아키텍처처럼 진정으로 안정적인 부분은 유지 관리할 필요가 전혀 없습니다.

세 번째는 지식이 특정 도구의 형태에 종속되지 않는다는 점입니다. Memory Bank는 Cline의 규칙이고, .cursor/rules는 Cursor의 규칙이며, CLAUDE.md는 Claude Code의 규칙입니다. 세 가지 모두에 들어가는 내용은 동일합니다. 지식이 도구 외부에 존재하지 않는 한, 에디터를 바꿀 때마다 주말을 통째로 반납해야 하는 일이 반복되는 이유가 바로 이 때문입니다.

또한 이는 Cursor가 기본적으로 제공하는 기능과도 조화를 이룹니다. 규칙은 문서에 명시된 대로 프롬프트 수준의 컨텍스트를 계속 제공하고, 팀 규칙은 표준을 계속 배포하며, 어느 쪽도 프로젝트의 히스토리를 억지로 담고 있을 필요가 없습니다. 프로젝트 히스토리를 억지로 담으려고 하면 Cursor의 규칙이 계속 잊어버리는 것처럼 느껴지게 되는데, 실제로는 단지 설계상 짧게 유지되도록 만들어졌기 때문입니다.

활성화 조건에 따라 규칙을 다시 분류하고, 절대 파일 대 파일로 복사하지 마세요

Cline은 모든 것을 결합했지만, Cursor는 각 파일을 개별적으로 평가합니다. 1대1 복사는 조건부 활성화를 잃게 만들거나 모든 것을 항상 켜진 상태로 만듭니다. 한 시간 정도 투자하여 규칙을 다시 분류하세요. 이는 관련이 있을 때만 실행되는 규칙과 모든 프롬프트를 희석시키는 거대한 덩어리 간의 차이를 만듭니다.

디버깅하기 전에 확장자를 먼저 확인하세요

확장자는 반드시 .mdc여야 합니다. .cursor/rules 폴더 내의 .md 파일은 규칙 시스템에서 무시되며, .txt 파일은 들어갈 자리조차 없습니다. 마이그레이션 직후 Cursor가 "규칙을 따르지 않는 것" 같다면 이 부분부터 확인하세요.

개인 규칙은 User Rules에, 팀 표준은 팀 규칙에 넣으세요

Cline의 글로벌 규칙 폴더는 개인 레이어이지만, 리포지토리는 그렇지 않습니다. Cursor의 User Rules는 여러 프로젝트에 걸친 개인의 습관을 다루며, 대시보드에서 관리되는 팀 규칙은 Team 및 Enterprise 플랜에서 조직의 표준을 다룹니다. 이 세 가지를 프로젝트 규칙에 섞어버리면 모든 팀원이 누군가의 개인적인 취향을 강제로 물려받게 됩니다.

첫날에 Memory Bank의 운명을 결정하세요

상시 활성화 규칙으로 유지하거나, 규칙 및 문서로 통합하거나, 포맷을 폐기하고 콘텐츠를 이동하세요. 세 가지 모두 타당한 방법입니다. 하지만 관리되지 않는 6개의 파일을 리포지토리에 방치하는 것은 올바르지 않습니다. 그 파일들의 가치는 오직 최신 상태를 유지하는 데서 나오기 때문입니다.

사용을 중단하기 전에 기존 에이전트에게 무엇을 알고 있는지 물어보세요

Memory Bank에 기록되지 않은 모든 내용은 곧 버려질 세션 안에만 존재합니다. Cline에게 새로운 개발자에게 무엇을 경고하고 싶은지 물어보는 10분의 시간은 이 마이그레이션 과정 전체에서 가장 저렴하고 확실한 보험입니다.

규칙이 강제 도구가 될 것이라 기대하지 마세요

Cursor는 명확하게 밝히고 있습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다. 컨텍스트는 영향력일 뿐입니다. 포맷팅, 보호된 파일, 금지된 임포트, 커밋 정책 등은 포매터, 린터, CI의 영역이어야 하며, 규칙 파일은 그것들이 왜 존재하는지 설명하는 역할을 해야 합니다.

Cline에서 Cursor로의 전환은 하나의 옷을 입은 두 개의 마이그레이션과 같습니다. 규칙 부분은 복사하는 대신 다시 분류해야 합니다. Cline은 .clinerules/ 안의 모든 .md 및 .txt 파일을 하나의 통합된 세트로 결합하는 반면, Cursor는 프론트매터에 따라 각 .mdc 파일의 적용 여부를 결정하기 때문입니다. 또한 .cursor/rules 안의 일반 .md 파일은 오류 없이 무시됩니다. Memory Bank 부분은 조용히 망가지는 부분입니다. 6개의 마크다운 파일은 그대로 전송되지만, 매 리셋 후 Cline이 이를 읽도록 만들었던 규칙이 사라지기 때문입니다.

두 도구 모두 근본적인 문제에 대해 진실을 말하고 있습니다. Cline은 세션 간에 메모리가 완전히 리셋되므로 문서를 강조합니다. Cursor는 완료 간에 모델이 메모리를 유지하지 못하므로 규칙을 강조합니다. Memory Bank의 본질을 진지하게 받아들이고, 규칙은 작고 명확한 범위로 유지하며, 지식 자체는 두 도구 모두에 종속되지 않는 저장소에 보관하세요. 그렇게 하면 다음 마이그레이션은 대대적인 발굴 작업이 아니라 단순한 설정 변경이 될 것입니다.