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

.clinerules/가 이전되며, 여기에는 두 가지 문서화된 메커니즘이 있습니다.

첫 번째는 /init입니다. Claude Code 문서에 따르면, 이는 ".cursor/rules/ 또는 .cursorrules에 있는 Cursor 규칙과 .github/copilot-instructions.md에 있는 Copilot 규칙을 읽어 생성된 CLAUDE.md에 관련 부분을 통합합니다. CLAUDE_CODE_NEW_INIT=1이 설정된 경우, /init은 AGENTS.md, .devin/rules/, .windsurf/rules/ 또는 .windsurfrules, 그리고 .clinerules도 읽습니다."

조건에 유의하세요: 해당 환경 변수가 설정되어 있을 때만 .clinerules를 읽습니다. 환경 변수 없이 /init을 실행하면 Cline 규칙은 아무런 알림 없이 건너뛰어집니다.

두 번째는 더 많은 작업을 수행하는 /import입니다. 이는 "지원되는 코딩 에이전트의 구성을 Claude Code로 가져와 AGENTS.md와 같은 명령 파일의 일회성 복사본을 일치하는 CLAUDE.md에 추가하고 MCP 서버, 명령, 하위 에이전트 및 기술을 이관합니다. Claude Code v2.1.213 이상이 필요합니다." 여기서 기억해야 할 두 가지는 이것이 동기화가 아닌 일회성 복사라는 점과 버전 제한이 있다는 점입니다.

항상 활성화되는 규칙은 깔끔하게 매핑됩니다. Cline은 ".clinerules/ 내부의 모든 .md 및 .txt 파일을 처리하여 통합된 규칙 세트로 결합"하며, "프론트매터(frontmatter)가 없는 규칙은 항상 활성화됩니다." Claude Code의 CLAUDE.md도 동일한 논리로 항상 켜져 있으므로, 이러한 규칙은 예상한 위치에 안착합니다.

조건부 규칙은 매핑되지 않습니다. Cline의 프론트매터 제한 규칙은 열려 있는 파일, 표시된 탭, 언급된 경로, 편집 중인 파일 등 현재 작업 컨텍스트를 기반으로 활성화됩니다. Claude Code의 CLAUDE.md에는 프론트매터 조건문이 없습니다. 대신 디렉토리 트리 동작을 가집니다. 즉, "현재 작업 디렉토리에서 디렉토리 트리를 거슬러 올라가며 CLAUDE.md 파일을 읽고", 이와 별개로 하위 디렉토리의 파일은 시작 시 로드되는 것이 아니라 "Claude가 해당 하위 디렉토리의 파일을 읽을 때 포함"됩니다. 이는 패턴 기반이 아니라 경로 기반입니다. 취지는 비슷하지만 메커니즘이 다릅니다. 즉, glob 범위의 Cline 규칙은 해당 규칙이 적용되는 디렉토리의 CLAUDE.md가 됩니다.

규칙 우선순위가 중요한 방식으로 뒤바뀝니다. Cline: "워크스페이스 규칙과 글로벌 규칙이 모두 존재할 때, Cline은 이를 결합합니다. 충돌이 발생하면 워크스페이스 규칙이 글로벌 규칙보다 우선합니다." Claude Code: "발견된 모든 파일은 서로를 덮어쓰는 대신 컨텍스트에 연결(concatenate)되며", "파일 시스템 루트에서 작업 디렉토리 방향"으로 정렬되고, 각 디렉토리에서 CLAUDE.md 뒤에 CLAUDE.local.md가 추가됩니다. 따라서 Claude Code에는 명시적인 충돌 해결책이 없습니다. 나중에 나오는 텍스트가 단순히 뒤에 나타날 뿐입니다. Cline이 우선순위로 해결했던 모순들이 Claude Code에서는 두 부분을 모두 읽는 모순이 됩니다. 이전하는 동안 이를 정리하세요.

Memory Bank는 갈 곳이 없습니다. 6개의 파일(projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md)은 일반 마크다운이므로 파일 자체는 유지됩니다. 유지되지 않는 것은 시스템입니다. Cline의 목소리로 작성된 방법론 자체의 지침은 "나는 모든 작업의 시작 시점에 반드시 모든 Memory Bank 파일을 읽어야 합니다 - 이는 선택 사항이 아닙니다"이며, "initialize memory bank", "update memory bank", "follow your custom instructions"와 같은 명령에 의해 구동됩니다.

이는 프롬프트로 강제된 의식이며, 이것이 작동하게 만든 핵심이었습니다. Claude Code에는 이에 상응하는 명령이 없으며, 6개의 문서를 CLAUDE.md에 붙여넣는 것은 대안이 될 수 없습니다. 매 요청마다 6개의 문서를 함께 전송하는 꼴이 되기 때문입니다.

1단계: 규칙 가져오기 및 조정

먼저 버전을 확인하세요. /import를 사용하려면 Claude Code v2.1.213 이상이 필요합니다. 그런 다음:

CLAUDE_CODE_NEW_INIT=1 claude

…그리고 /init을 실행하여 .clinerules를 생성된 CLAUDE.md에 병합하거나, MCP 서버, 명령, 하위 에이전트 및 기술도 함께 가져오려면 /import를 실행하세요. /import는 일회성 복사본을 추가할 뿐이며, 이후 Cline 측에서의 편집은 추적하지 않는다는 점을 기억하세요.

그런 다음 결과를 그대로 믿지 말고 직접 읽어보세요. 수동으로 수정해야 할 세 가지 사항은 다음과 같습니다.

무조건부로 바뀐 조건부 규칙. .clinerules에서 glob 범위로 지정되었던 모든 규칙이 이제 항상 켜져 있습니다. 각 규칙을 실제로 제어하는 디렉토리의 CLAUDE.md로 이동하거나, 한 영역에만 관련이 있었던 규칙이라면 삭제하세요.

이전에 해결되었던 모순. 워크스페이스 우선 적용 원칙이 더 이상 적용되지 않습니다. 두 규칙이 충돌하여 Cline이 하나를 선택했다면, Claude Code는 두 규칙을 모두 읽게 됩니다.

길이. Claude Code의 가이드에 따르면 파일이 길어질수록 더 많은 컨텍스트를 소비하고 규칙 준수율이 떨어집니다. 지침을 정리할 수 있는 구조화된 대안인 .claude/rules/가 있습니다. 누적하지 말고 분할하세요.

/context로 확인하고 CLAUDE.md가 Memory files 아래에 나타나는지 확인하세요.

만약 CLAUDE.md가 프로젝트 외부에서 무언가를 가져오게 되는 경우 한 가지 경고가 있습니다: "Claude Code가 프로젝트에서 외부 임포트를 처음 발견하면 파일 목록이 포함된 승인 대화 상자를 표시합니다. 거절하면 임포트가 비활성화된 상태로 유지되며 대화 상자가 다시 나타나지 않습니다." ~/.claude/CLAUDE.md와 같은 사용자 범위 파일의 임포트는 대화 상자 없이 로드됩니다. 마이그레이션 후 지침이 누락된 것처럼 보인다면 대화 상자를 거절했기 때문일 수 있습니다.

2단계: Memory Bank 처리 방식 결정

6개의 파일을 읽고 그 내용을 세 가지 분류로 분류하세요. 이것이 마이그레이션의 진짜 작업이며 약 20분이 소요됩니다.

규칙 및 제약 조건 → CLAUDE.md. systemPatterns.md 및 techContext.md 내용의 대부분은 아키텍처 패턴, 컴포넌트 관계, 기술 스택, 설정, 의존성 등입니다. 이는 안정적이며, 규칙으로 압축하면 짧아지고, 명령 파일에 속합니다.

요구사항 및 제품 컨텍스트 → 레포지토리(붙여넣지 말고 참조). projectbrief.md 및 productContext.md는 에이전트뿐만 아니라 사람을 위한 문서이기도 합니다. 문서로 유지하고 이를 가리키도록 하되, 인라인으로 넣지 마세요.

상태 → 갈 곳 없음, 그리고 이것이 문제입니다. activeContext.md("현재 포커스, 최근 변경 사항, 다음 단계"이며 문서에서는 "가장 자주 업데이트됨"이라고 명시함) 및 progress.md("작동하는 것, 남은 것, 알려진 이슈")는 실행 상태(running state)입니다. 이것들은 규칙도 아니고 문서도 아닙니다. 이를 CLAUDE.md에 넣으면 매 요청마다 지난주 화요일의 상태를 전송하게 되고, 파일로 남겨두면 아무도 읽지 않습니다.

이 세 번째 분류가 바로 Memory Bank가 존재했던 이유이며, Claude Code에는 이를 담을 컨테이너가 없습니다. 메커니즘이 없더라도 이 습관은 유지할 가치가 있습니다. 일반적인 사례는 why Cline forgets task history에서 확인할 수 있습니다.

Memory Bank가 정확히 짚어낸 한 가지가 있습니다. 일부 프로젝트 지식은 규칙이 아니라 상태이며, 기록되고 다시 읽혀야 한다는 점입니다. 한계에 부딪힌 지점은 저장소가 프롬프트에 의해 유지되는 6개의 마크다운 파일이었다는 점입니다. 즉, 에이전트가 의식을 따르는 것에 의존했고, 하나의 도구를 위해 하나의 레포지토리에 상주했습니다.

이것이 바로 MemoryLake가 존재하는 이유입니다. 에이전트가 읽는 상태와 추론을 전체 문서로 전송하는 대신 검색 가능한 개별 항목으로 제공합니다. 설정은 3단계로 진행됩니다.

1단계: API 키 생성

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

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

누군가 이미 추출 작업을 해두었기 때문에 여러분의 Memory Bank는 매우 훌륭한 시작점입니다. 파일을 그대로 붙여넣지 말고, 하나의 주장당 하나의 짧은 항목으로 분할하세요:

progress.md에서: 작동하는 것, 남은 것, 알려진 이슈. 각 알려진 이슈는 증상과 원인을 포함한 하나의 항목이 됩니다. 이는 전체 Memory Bank에서 가장 가치 있는 콘텐츠이며, 문서 형태보다 개별 항목으로 검색할 때 훨씬 더 잘 작동합니다.

activeContext.md에서: 현재 포커스 뒤에 숨겨진 결정 사항. "결제 리팩터링 작업 중"과 같은 내용은 만료됩니다. 하지만 "제공업체가 멱등성 키 없이 재시도하므로 결제 리팩터링은 아웃박스 패턴을 사용함"과 같은 내용은 만료되지 않습니다.

systemPatterns.md에서: 각 패턴 뒤에 있는 이유. 패턴은 CLAUDE.md에 들어가고, 그에 대한 논거는 여기에 들어갑니다. 그래야 에이전트가 예상치 못한 상황을 처리할 수 있습니다.

두 번 이상 수정해야 했던 모든 것. 거절 사유가 기록되어 있지 않으면 Cline과 Claude Code 모두 거절된 방식을 다시 제안할 것입니다.

항목을 짧게 유지하고 폐기한 시스템을 설명하는 내용은 모두 삭제하세요. 6개 파일로 구성된 Memory Bank는 보통 20개에서 40개 사이의 항목을 생성합니다. 200개나 만들고 있다면 단순히 필사하고 있는 것입니다.

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

사용하는 도구를 연결하세요. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽습니다. 즉, 전환을 완료하기 전에 이 작업을 수행할 수 있으며, 평가하는 동안 두 도구 모두 동일한 상태를 읽을 수 있습니다.

세 가지 솔직한 한계가 있습니다. MemoryLake는 CLAUDE.md 또는 .clinerules를 대체하지 않습니다. 이것들은 각 도구를 조종하는 방법이며, 위의 가져오기는 그 자체로 수행할 가치가 있습니다. 또한 사용자가 직접 또는 에이전트가 기록한 내용만 보관하므로 2단계는 수동 작업입니다. 그리고 강제 메커니즘이 아닙니다. 검색 가능한 컨텍스트가 있다고 해서 모델이 반드시 그에 따라 행동한다는 보장은 없습니다.

activeContext.md가 아무도 읽지 않는 파일로 방치되지 않습니다. 실행 상태가 검색 가능한 항목으로 제공되므로, 전체를 붙여넣거나 잊어버리는 대신 필요할 때 즉시 사용할 수 있습니다.

명령 파일이 짧게 유지됩니다. CLAUDE.md는 규칙을 담습니다. 6개의 문서를 담지 않으므로 규칙 준수율이 유지되는 길이를 유지할 수 있습니다.

"Update memory bank"라는 의식이 필요 없어집니다. 가치는 기록하는 데 있었지, 매 작업을 시작할 때마다 6개의 파일을 다시 읽는 의식에 있었던 것이 아닙니다.

가져오기 대화 상자를 거절해도 컨텍스트를 잃지 않습니다. 영구적인 지식이 외부에 있으면 명령 파일을 로드하지 못하더라도 리셋이 아닌 단순한 불편함에 그칩니다.

도구를 다시 전환하는 비용이 저렴해집니다. 상태가 Cline 형태나 Claude 형태의 컨테이너에 갇혀 있지 않기 때문입니다. 이 형태에 대해서는 what AI memory is and isn't에서 다루고 있습니다.

/init 전에 CLAUDE_CODE_NEW_INIT=1을 설정하세요. 설정하지 않으면 .clinerules를 읽지 않습니다.

/import를 사용하기 전에 v2.1.213 버전을 확인하세요. 이것이 문서화된 최소 버전이며, /import가 MCP 서버, 명령, 하위 에이전트 및 기술을 가져옵니다.

가져오기를 스냅샷으로 취급하세요. 일회성 복사본을 추가할 뿐입니다. 이후의 .clinerules 편집은 전파되지 않습니다.

모든 조건부 규칙의 범위를 재조정하세요. glob 범위의 Cline 규칙은 제어하는 디렉토리로 이동하지 않으면 항상 켜져 있는 상태가 됩니다.

모순은 직접 해결하세요. Claude Code는 덮어쓰는 대신 연결하므로, Cline이 적용했던 우선순위는 사라집니다.

projectbrief.md를 문서로 유지하세요. 인라인으로 넣지 말고 참조하도록 하세요.

절대로 activeContext.md를 CLAUDE.md에 붙여넣지 마세요. Cline 자체 문서에 따르면 가장 자주 변경되는 파일이며, 매 요청마다 전송되는 콘텐츠로는 최악입니다.

변경할 때마다 /context를 실행하세요. Memory files 아래에 CLAUDE.md가 있는지 확인하는 데는 5초밖에 걸리지 않으며, "로드되었는가"에 대한 대부분의 의문을 해결해 줍니다. 관련 내용은 why Claude Code forgets project context에서 확인할 수 있습니다.

이번 마이그레이션에서 규칙 부분은 거의 해결되었습니다. CLAUDE_CODE_NEW_INIT=1과 함께 /init을 실행하면 .clinerules를 읽고, v2.1.213 이상에서 /import를 실행하면 MCP 서버, 명령, 하위 에이전트 및 기술을 포함한 더 넓은 구성을 가져옵니다. 대신 조정을 위한 시간을 확보하세요. 알림 없이 무조건부로 바뀐 조건부 규칙과, Claude Code가 덮어쓰는 대신 연결하기 때문에 더 이상 존재하지 않는 워크스페이스 우선순위 등을 정리해야 합니다.

Memory Bank는 깊이 생각해 볼 가치가 있는 부분입니다. 일부 지식은 상태이며, 상태는 기록되고 다시 읽혀야 한다는 통찰은 옳았습니다. 하지만 그 구현은 하나의 도구를 위해 하나의 레포지토리에서 프롬프트로 묶인 6개의 문서였습니다. 규칙은 CLAUDE.md로 이동하고, 브리프는 참조 문서로 유지하며, 알려진 이슈, 결정 사항, 거절된 접근 방식은 에이전트가 쿼리하는 레이어에 넣으세요. 그래야 다음 도구 전환 시 6개월 동안 축적한 자산을 잃지 않을 수 있습니다.