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

AGENTS.md — 양쪽 모두에서 읽는 실제 가교. Cursor는 프로젝트 루트 및 하위 디렉터리에서 AGENTS.md를 지원하며, 중첩된 파일을 부모 파일과 결합하여 "더 구체적인 지침이 우선순위를 갖도록" 합니다. Cline의 지원 규칙 표에는 AGENTS.md 및 ~/.agents/AGENTS.md가 "도구 간 호환성을 위한 표준 형식"으로 나열되어 있습니다. 규칙이 이미 AGENTS.md에 있다면 거의 다 끝난 것이며, 결정을 내리는 동안 동일한 파일에 대해 두 도구를 모두 실행할 수 있습니다.

Skills — 정확히 하나의 공유 디렉터리를 통해. Cursor는 .agents/skills/, .cursor/skills/, ~/.agents/skills/, ~/.cursor/skills/에서 skills를 로드하며, 호환성 목록도 제공합니다: "호환성을 위해 Cursor는 Claude 및 Codex 디렉터리인 .claude/skills/, .codex/skills/, ~/.claude/skills/, ~/.codex/skills/에서도 skills를 로드합니다." Cline은 프로젝트 skills를 .cline/skills/, .clinerules/skills/, .claude/skills/에서 읽습니다. 두 목록을 비교해 보면 양쪽 모두에 존재하는 디렉터리가 딱 하나 있습니다: 바로 .claude/skills/이며, 이는 두 도구 중 어느 쪽에도 속하지 않는 디렉터리입니다. 여기에 skills를 두면 양쪽 도구 모두에서 읽을 수 있습니다. SKILL.md 형태는 양쪽 모두 동일하므로, 이는 재작성이 아닌 단순 이동 작업입니다.

모델 — 만약 그것이 목적이라면 OpenAI 모델 포함. Cline은 두 가지 OpenAI 경로를 문서화하고 있습니다: 설정에 입력하는 API 키와, "OpenAI로 로그인하고 브라우저 OAuth를 완료"하여 "API 키 입력이 필요 없고" "사용 가능한 모델은 OpenAI 요금제에 따라 달라지는" "OpenAI Codex (Subscription OAuth)"입니다. 이는 OpenAI를 "표준적인 비추론형 채팅 모델"로 제한하고 "사용자 지정 API 키는 채팅 모델에서만 작동한다"고 명시한 Cursor의 자체 키 제공(bring-your-own-key) 페이지와 비교해 볼 만합니다.

이전되지 않는 것: 범위 지정 언어로서의 .mdc frontmatter. 이것이 진짜 작업입니다. Cursor의 4가지 규칙 유형은 3개의 frontmatter 필드를 기반으로 구축되며, 해당 문서에서는 그 상호작용을 다음과 같이 설명합니다: alwaysApply: true는 "항상 포함됨. Glob 및 설명은 무시됨"을 의미하고, globs가 있는 false는 "일치하는 파일이 컨텍스트에 있을 때 자동 첨부됨"을 의미하며, description이 있는 false는 "에이전트가 설명을 읽고 관련이 있을 때 규칙을 가져옴"을 의미하고, 둘 다 없는 false는 "채팅에서 규칙을 @로 언급할 때만 포함됨"을 의미합니다. Cline에는 이에 상응하는 메타데이터가 없습니다. Cline은 ".clinerules/ 내부의 모든 .md 및 .txt 파일을 처리하여 하나의 통합된 규칙 세트로 결합"합니다. 모든 것은 파일당 수동 토글을 통해 포함되거나 제외될 뿐입니다.

사라지는 기능: 강제 적용으로서의 Team Rules. Cursor의 Team Rules는 대시보드에서 생성되며, "Team Rules → Project Rules → User Rules"라는 문서화된 우선순위를 따르고, 규칙이 "모든 팀원에게 필수적이며 Customize에서 비활성화할 수 없음"으로 표시될 수 있습니다. 반면 Cline의 모델은 설계상 그 반대입니다: "감지된 모든 규칙 유형은 Rules 패널에 표시되며, 여기서 개별적으로 토글할 수 있습니다." 모든 규칙은 사용하는 사람이 직접 켜고 끌 수 있습니다. 이는 강제 적용에 의존하던 팀에게는 진정한 손실이며, 어떤 파일로도 이를 이전할 수 없습니다.

사라지는 기능: 원격 규칙 동기화. Cursor는 GitHub 리포지토리에서 .cursor/rules/imported/<repoName>으로 규칙을 가져와 "풀(pull) 및 동기화"할 수 있습니다. Cline의 상응하는 방식은 .clinerules/가 리포지토리에 포함되는 것이며, 이는 단일 프로젝트에 대한 동일한 요구사항은 충족하지만 여러 프로젝트에 공유되는 규칙은 지원하지 않습니다.

1단계: 파일 위치가 아닌 활성화 방식에 따라 규칙 분류하기

.cursor/rules를 열고 모든 .mdc 파일을 frontmatter 기준으로 분류하세요. 파일이 어디로 가야 할지를 결정하는 유일한 기준이기 때문입니다. 네 가지 분류로 나뉩니다.

alwaysApply: true. 항상 켜져 있는 규칙이며 직접 이동합니다. 두 도구 모두 동일한 파일을 읽게 하려면 AGENTS.md에 넣고, Cline만 사용하기로 결정했다면 .clinerules/에 넣으세요. 둘 다 작동하며, 첫 번째 방법은 선택의 여지를 남겨둡니다.

globs 설정됨. 이에 상응하는 직접적인 기능은 없습니다. Cline의 규칙은 파일 패턴에 따라 조건부로 첨부되지 않으므로, src/components/**/*.tsx에만 적용되던 규칙은 항상 켜져 있는 규칙(모든 작업에서 컨텍스트 비용 발생)이 되거나 해당 영역에서 작업할 때 켜는 토글형 규칙이 됩니다. 규칙별로 선택하되, 일괄 변환하지 마세요.

description 설정됨, alwaysApply: false. 이 규칙들은 예상보다 더 적합한 위치가 있으며, 그것은 규칙 시스템이 아닙니다. Cursor는 이 유형을 "설명을 바탕으로 에이전트가 관련이 있다고 판단할 때" 적용되는 것으로 설명합니다. Cline의 skills도 동일하게 작동합니다: "메시지를 보낼 때 Cline은 설명과 함께 사용 가능한 skills 목록을 봅니다. 요청이 skill의 설명과 일치하면 Cline은 use_skill 도구를 사용하여 이를 활성화하고, SKILL.md에서 전체 지침을 로드합니다." 동일한 메커니즘에 이름만 다를 뿐입니다. 설명으로 트리거되는 규칙은 규칙 파일보다 skill로 변환하는 것이 더 충실하게 작동합니다.

두 필드 모두 설정되지 않음. 이 규칙들은 @ 언급 전용이었습니다. Cline에서는 토글을 꺼둔 규칙 파일이 되거나 명시적으로 호출하는 skills가 됩니다. 어느 쪽이든 타당하며, 토글 방식이 원래 방식에 더 가깝습니다.

이 작업을 수행하는 동안 .mdc 파일을 삭제하지 마세요. 어떤 규칙이 어디에 적용되었는지 보여주는 유일한 기록입니다.

2단계: 파일 배치, 모델 연결 및 컨텍스트 비용 모니터링

프로젝트 루트에 .clinerules/를 생성하고 파일당 하나의 관심사만 유지하세요. 이는 Cline의 자체 권장 사항이기도 하며, 토글이 유일한 범위 지정 도구인 여기서는 더욱 중요합니다: "주제별로 규칙을 분할하세요... 이렇게 하면 특정 규칙을 쉽게 켜고 끌 수 있습니다."

올바르게 처리해야 할 세 가지 사항이 있습니다.

토큰 비용에 유의하세요. Cline은 이를 경고로 명시하고 있습니다: "규칙은 컨텍스트 토큰을 소비합니다. 장황한 설명이나 전체 스타일 가이드를 붙여넣는 것은 피하세요. 규칙을 간결하게 유지하고 자세한 참조가 필요한 경우 외부 문서를 링크하세요." Cursor에서는 glob 규칙이 일치하는 파일이 컨텍스트에 들어오기 전까지는 비용이 들지 않았습니다. 이를 항상 켜짐으로 여러 개 변환하면 모든 작업에 해당 비용이 조용히 추가됩니다.

글로벌 규칙의 위치와 우선순위를 파악하세요. Cline의 글로벌 규칙 디렉터리는 macOS 및 Linux의 경우 ~/Documents/Cline/Rules, Windows의 경우 Documents\Cline\Rules이며, ~/.agents/AGENTS.md도 읽습니다. 둘 다 존재할 때 "글로벌 규칙과 충돌하는 경우 워크스페이스 규칙이 우선합니다." 이는 Cursor의 프로젝트 우선 순서와 동일하므로 기존 직관을 그대로 적용할 수 있습니다.

skills 레이어에서의 한 가지 반대 동작에 주의하세요. Cline은 "글로벌 skill과 프로젝트 skill의 이름이 같을 때 글로벌 skill이 우선합니다"라고 명시합니다. 이는 규칙이 해결되는 방식과 반대이며, 대부분의 도구와도 반대입니다. 이름이 같은 개인용 skill과 프로젝트용 skill을 유지하는 경우 개인용이 우선합니다.

그런 다음 Cline 설정의 OpenAI 아래에서 API 키 또는 Codex OAuth를 통해 제공업체를 구성하고, 에디터에서 자동으로 넘어오지 않는 MCP 서버를 다시 추가하세요.

이것으로 문서화된 부분은 끝났습니다. 남은 것은 그 뒤에 숨겨진 추론이며, 두 도구 모두 이를 담을 공간은 없습니다.

지속성에 대한 Cline의 해답은 Memory Bank이며, 이것이 무엇인지 솔직하게 보여주기 때문에 정확히 이해할 가치가 있습니다. 리포지토리에 있는 6개의 마크다운 파일(projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md)과 Cline에게 이를 읽으라고 지시하는 규칙 파일 하나로 구성됩니다. 함께 제공되는 지침은 다음과 같은 인용할 만한 문장으로 시작합니다: "나는 전문 소프트웨어 엔지니어인 Cline입니다. 나에게는 독특한 특징이 있습니다. 세션 사이에 내 기억이 완전히 초기화된다는 점입니다. 이는 한계가 아니라 내가 완벽한 문서를 유지하도록 이끄는 원동력입니다."

이것은 훌륭한 문서화 방법론입니다. 또한 하나의 코드베이스로 범위가 지정됩니다. 하나의 프로젝트 상태를 설명하는 6개의 파일이며, Cline에게 "update memory bank"를 요청하여 업데이트됩니다. 여기에 맞지 않는 것은 코드와 전혀 관련이 없는 것들입니다. 예를 들어 표준이 존재하는 이유, 팀이 시도했다가 거부한 것, 누구에게 물어봐야 하는지, 어떤 마감일이 변경되었는지 등입니다.

MemoryLake는 단일 도구의 외부에 존재하는 메모리 레이어로, 이 마이그레이션과 다음 마이그레이션에서도 해당 자료들이 살아남을 수 있도록 합니다. 설정은 3단계로 진행됩니다.

1단계: API 키 생성

로그인하고 API 키를 생성하세요. 연결하는 도구 전반에 걸쳐 하나의 자격 증명만 사용됩니다.

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

각각 하나의 주장만 담긴 짧은 항목들입니다. 소스 자료는 frontmatter에 담을 수 없었던 내용들입니다:

각 항상 켜짐 규칙이 항상 켜져 있는 이유. 방금 변환한 모든 glob 규칙에 대해 판단을 내렸을 것입니다. 그 판단과 이유를 기록해 두지 않으면 3개월 후에 다시 다르게 판단하게 될 것입니다.

강제 적용된 Team Rules가 보호하려던 것. 강제 적용 기능은 이전 시 유지되지 않습니다. 그것이 존재했던 이유는 유지되어야 합니다.

유지된 수정 사항들. 팀이 시도했다가 포기한 접근 방식입니다. 양쪽의 규칙 형식 모두 이를 위한 필드를 가지고 있지 않습니다.

코드가 아닌 작업 컨텍스트. 소유권, 동결된 영역, 현재 우선순위, 런북 등입니다. Memory Bank의 activeContext.md는 하나의 리포지토리에 대해 이 중 일부를 다루지만, 이는 모든 리포지토리에 걸쳐 이를 다룹니다.

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

사용 중인 도구를 연결하세요. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으며, Cline은 MCP 서버를 지원하므로 동일한 메모리를 Cline에서 즉시 사용할 수 있습니다. Cursor, Claude Code, Codex, OpenClaw도 동일한 방식으로 연결되므로, 알고 있는 지식의 복사본을 두 개 유지하지 않고도 전환 기간 동안 두 에디터를 모두 열어둘 수 있습니다.

세 가지 솔직한 한계가 있습니다. 이것은 .mdc 파일을 변환하지 않습니다 — 1단계의 frontmatter 매핑은 수동이며, 선택이 수반되므로 수동이어야 합니다. 강제 적용을 복구하지 않습니다 — 메모리 레이어는 Cline의 Rules 패널에서 규칙을 비활성화할 수 없도록 만들 수 없습니다. 그리고 메모리는 컨텍스트이지 강제 적용이 아닙니다 — Cursor의 문서에서도 자체 강제 규칙에 대해 동일한 점을 지적합니다: "AI 가이드가 유일한 보안 제어 수단이 되어서는 안 됩니다."

규칙 범위 지정이 명시적인 결정이 됩니다. Cursor는 frontmatter에서 이를 결정했습니다. Cline은 파일당 한 번씩 공개적으로 선택하도록 합니다.

설명으로 트리거되는 규칙이 실제 작동하는 위치에 안착합니다. 항상 켜져 있는 파일에 억지로 밀어 넣는 대신 skills로 변환되어 실제로 원했던 동작을 유지합니다.

skills가 특정 에디터에 종속되지 않습니다. 두 도구 모두 읽는 하나의 디렉터리를 사용하므로 에디터를 전환하는 것이 skills 마이그레이션이 되지 않습니다.

추론이 채팅 창에만 머무르지 않습니다. 이것이 다음 도구 변경 시에도 이 모든 것이 살아남을 수 있는 유일한 이유입니다.

파일이 아닌 활성화 모드별로 변환하세요. frontmatter가 사양입니다. 파일 이름은 아무것도 알려주지 않습니다.

결정하는 동안 항상 켜져 있는 규칙에는 AGENTS.md를 사용하세요. 두 도구 모두 이를 읽으므로 마음이 바뀌어도 낙오되는 것이 없습니다.

설명으로 트리거되는 규칙은 skills로 보내세요. Cline의 skill 활성화는 어떤 규칙 파일보다 Cursor의 "Apply Intelligently" 동작에 더 가깝게 일치합니다.

두 에디터를 모두 원한다면 skills를 .claude/skills/에 넣으세요. 양쪽 지원 목록에 모두 있는 유일한 디렉터리입니다.

항상 켜짐으로 설정한 항목을 감사하세요. 변환된 모든 glob 규칙은 이제 모든 작업에서 컨텍스트 비용을 소모하며, Cline은 정확히 이에 대해 경고합니다.

강제 적용이 무엇을 위한 것이었는지 기록해 두세요. 이는 유지되지 않는 유일한 속성이며, 대개 누군가 여전히 기억할 수 있는 이유 때문에 존재했습니다.

상황이 정리될 때까지 .mdc 파일을 보관하세요. 이 파일들은 여러분이 곧 다시 구현할 범위 지정을 문서화하고 있습니다.

Memory Bank를 프로젝트 간 메모리와 혼동하지 마세요. 이는 하나의 코드베이스 상태를 설명합니다. 더 넓은 차이점은 why long context isn't memory에서 다룹니다.

Cline이 무료로 제공하는 것처럼 보이는 마이그레이션은 여러분에게 필요한 것이 아닙니다. Cline의 규칙 표는 Cursor의 현재 문서에서 더 이상 언급하지 않는 형식인 .cursorrules를 감지하는 반면, 실제로 여러분이 가지고 있는 형식인 .mdc 파일로 가득 찬 .cursor/rules는 Cline 문서 어디에도 나타나지 않습니다. 실제로 존재하는 가교는 두 도구 모두 읽는 AGENTS.md와 양쪽 지원 목록에 모두 나타나는 단일 skills 디렉터리인 .claude/skills/입니다.

시간이 걸리는 부분은 frontmatter입니다. Cursor의 3개 필드는 4가지 활성화 동작을 생성하며, Cline의 규칙은 수동 토글을 통한 전부 아니면 전무(all-or-nothing) 방식입니다. 복사하기 전에 alwaysApply, globs, description별로 분류하세요: 항상 켜져 있는 규칙은 직접 이동하고, glob 규칙은 컨텍스트 비용에 대한 규칙별 판단이 필요하며, 설명으로 트리거되는 규칙은 skills로 가장 잘 변환되고, @ 언급 규칙은 토글이 됩니다. Team Rules 강제 적용은 전혀 변환되지 않습니다.

그리고 그 모든 것 아래에 있는 레이어 — 이 규칙들이 왜 존재하는지, 무엇을 시도했다가 거부했는지, 누가 무엇을 소유하고 있는지 — 는 두 도구의 형식 어디에도 없었습니다. Cline의 Memory Bank는 세션 간에 완전히 초기화된다는 점을 솔직하게 밝히고 있으며, 이것이 바로 추론이 두 에디터 모두 소유하지 않는 곳에 속해야 하는 이유입니다. 여러분을 여기로 이끈 증상이 규칙이 조용히 적용되지 않는 것이었다면, 그 이야기의 양면은 why Cursor forgets your project rules 및 why Cline forgets your project context에서 모두 다루고 있습니다.