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

변경 사항이 전혀 없는 Skills. Cline의 프로젝트 skill 위치는 .cline/skills/(권장), .clinerules/skills/, .claude/skills/입니다. 세 번째 항목 덕분에 Claude Code에서 이미 사용 중이던 리포지토리는 Cline에서도 그대로 작동합니다. 글로벌 skill은 ~/.cline/skills/에 저장됩니다. 기존에 익숙했던 방식과 반대되는 우선순위 주의 사항이 있습니다. "글로벌 skill과 프로젝트 skill의 이름이 같을 경우, 글로벌 skill이 우선합니다." 또한 Cline은 SKILL.md를 5k 토큰 미만으로 유지하고, 넘치는 내용은 docs/ 디렉터리로 분할할 것을 권장하며, "필요할 때만 참조된 파일을 로드한다"고 설명합니다.

Cline이 읽는 파일에 저장된 지침(instruction) 내용. 두 가지 깔끔한 형태가 있습니다. 프로젝트 루트에서 이름을 AGENTS.md로 변경하면, Cline은 이를 "도구 간 호환성을 위한 표준 형식"으로 취급합니다. 또는 .clinerules/로 분할할 수도 있습니다. Cline은 ".clinerules/ 내부의 모든 .md 및 .txt 파일을 처리하여 통합된 규칙 세트로 결합"하며, 순서 지정을 위해 01-coding.md와 같은 숫자 접두사를 옵션으로 사용할 수 있습니다.

개인화 레이어의 새로운 저장소. Claude Code의 사용자 지침은 "모든 프로젝트에 대한 개인 기본 설정"으로 설명되는 ~/.claude/CLAUDE.md에 위치합니다. Cline의 글로벌 규칙 디렉터리는 macOS 및 Linux/WSL의 경우 ~/Documents/Cline/Rules이고, Windows의 경우 Documents\Cline\Rules입니다. 또한 ~/.agents/AGENTS.md에서 도구 간 글로벌 지침을 읽습니다. 위치가 닷파일(dotfile)이 아닌 Documents 폴더라는 점을 기억하세요. ~/.cline/에서 찾기 전에 알아두면 유용합니다.

그 외에는 깔끔하게 전송되는 것이 없으며, 세 가지 사항이 다르게 작동합니다.

자동 메모리(auto memory)가 갈 곳이 없습니다. 이것이 가장 큰 공백입니다. Claude Code는 ~/.claude/projects/<project>/memory/에 자체적으로 노트를 작성하며(프런트매터에 user, feedback, project, reference로 태그 지정된 네 가지 종류), 이 기능은 기본적으로 켜져 있습니다. Cline에는 이에 상응하는 자동 저장소가 없습니다. 폴더를 그냥 복사하려는 사람들에게 더 나쁜 소식은, Claude Code 문서에 "자동 메모리는 로컬 머신 전용"이며 "머신이나 클라우드 환경 간에 파일이 공유되지 않는다"고 명시되어 있다는 점입니다. 또한 이 파일들은 지침 파일에 명시되지 않은 내용들의 잔재입니다. Claude는 "코드베이스에서 유추할 수 있는 모든 것을 건너뛰고", "CLAUDE.md 파일에 이미 명시된 모든 것을 건너뛰기" 때문입니다. 즉, 메모리 디렉터리에는 이름을 바꾸려는 파일에 포함되지 않은 정확한 내용들만 보관되어 있습니다.

우선순위 및 병합 방식이 다릅니다. Claude Code는 관리형 정책, 사용자 지침, 프로젝트 지침 순으로 연결하며, "두 규칙이 서로 충돌하는 경우 Claude가 임의로 하나를 선택할 수 있다"고 명시합니다. Cline 역시 결합하지만 충돌을 해결합니다. "작업 공간 규칙과 글로벌 규칙이 모두 존재할 때, Cline은 이를 결합합니다. 충돌이 발생하면 작업 공간 규칙이 글로벌 규칙보다 우선합니다." 따라서 Claude Code에서 프로젝트 파일과 은밀하게 충돌하던 개인 설정이 이제는 확실하게 무시됩니다.

경로 범위 규칙(Path-scoped rules)이 토글 방식으로 바뀝니다. Claude Code에는 일치하는 파일에만 로드되도록 glob의 paths: 프런트매터 필드가 있는 .claude/rules/ 파일이 있습니다. Cline의 이에 상응하는 제어 방식은 자동이 아닌 수동입니다. "모든 규칙에는 활성화 또는 비활성화할 수 있는 토글이 있습니다." Cline의 예시로는 "프로토타이핑할 때 비활성화하려는 엄격한 테스트 규칙이나, 해당 클라이언트의 기능을 작업할 때만 필요한 클라이언트별 규칙" 등이 있습니다. 목표는 같지만 트리거가 다릅니다. glob 패턴이 처리하는 대신 사용자가 직접 토글을 전환합니다.

1단계: 지침 파일을 수정하기 전에 자동 메모리를 먼저 읽으세요

이 작업을 가장 먼저 수행해야 합니다. 리포지토리에서 나중에 복구할 수 없는 유일한 마이그레이션 부분이기 때문입니다.

Claude Code에서 /memory를 실행하여 메모리 디렉터리를 찾아보거나, ~/.claude/projects/<project>/memory/를 직접 여세요. 여기에는 MEMORY.md 인덱스와 주제별 파일이 하나씩 포함되어 있습니다. 읽는 동안 알아두어야 할 두 가지 사항은, 세션 시작 시 "MEMORY.md 파일의 처음 200줄 또는 처음 25KB 중 먼저 도달하는 것"만 로드되었다는 점과, 주제 파일은 로드되는 것이 아니라 "필요에 따라 읽기(read on demand)" 방식으로 작동하므로 Claude가 평소에 사용하던 것보다 더 많은 내용이 들어 있을 수 있다는 점입니다.

그런 다음 /context를 실행하고 Memory files 아래의 목록을 확인하세요. 이것이 실제로 로드되고 있던 항목의 신뢰할 수 있는 기록이며, 이름을 바꾸려는 CLAUDE.md가 유일한 파일이었는지 알려줍니다. 하위 디렉터리의 파일은 필요에 따라 로드되고, 임포트는 "최대 4단계 깊이"로 확인되므로, 모노레포(monorepo)의 경우 루트 파일이 보여주는 것보다 더 많은 파일이 작동하고 있을 수 있습니다.

보관하고 싶은 내용을 복사해 두세요. 이것은 파일을 이동하는 작업이 아니라 읽고 기록하는 과정입니다. feedback과 project 항목이 대개 가장 가치 있는 정보입니다. 설계상 사용자가 제공한 피드백과 코드에서 유추할 수 없는 결정 사항들이 포함되어 있기 때문입니다.

2단계: 지침을 적용한 후 Memory Bank 사용 여부 결정하기

지침을 먼저 적용하고, 한 가지 형태를 선택하세요. 이제 리포지토리에서 Cline만 유일한 에이전트로 사용한다면 CLAUDE.md 이름을 AGENTS.md로 변경하세요. 팀원들이 여전히 Claude Code를 사용 중이라면 CLAUDE.md를 유지하고 AGENTS.md를 추가하되, 하나를 신뢰할 수 있는 단일 소스(authoritative source)로 지정하고 다른 하나는 가볍게 유지하세요. 두 개의 전체 복사본이 있으면 내용이 서로 달라지기 쉽습니다. 내용이 길다면 .clinerules/로 분할하는 것이 더 좋습니다. 토글 기능이 있는 개별 파일들이 아무도 편집하고 싶어 하지 않는 하나의 거대한 파일보다 낫기 때문입니다. 이 결정의 파일 형식 측면은 how to migrate your CLAUDE.md to AGENTS.md에서 별도로 다룹니다.

이 작업을 하는 김에 Claude Code 가이드에서 이미 삭제하라고 권장했던 섹션들을 정리하세요. 가이드에서는 "200줄 미만을 목표로 하라"고 조언합니다. "파일이 길어질수록 더 많은 컨텍스트를 소비하고 지침 준수율이 떨어지기 때문"이며, 이는 Cline이 로드하는 모든 파일에도 동일하게 적용됩니다.

그다음은 사람들이 흔히 건너뛰는 Memory Bank입니다. 세션 간 컨텍스트 유지에 대한 Cline의 해법은 활성화하는 기능이 아니라 사용자가 직접 설치하는 방법론입니다. 설정은 세 단계로 진행됩니다. Cline의 커스텀 지침을 복사하고, "이를 .clinerules/memory-bank.md와 같은 Cline Rules 파일에 추가"한 다음, Cline에게 "initialize memory bank"를 요청합니다.

그러면 리포지토리에 projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md 등 6개의 마크다운 파일이 생성되며, 이 중 activeContext.md가 "가장 자주 업데이트"됩니다. 이를 작동시키는 세 가지 문구는 "initialize memory bank", "update memory bank", 그리고 다시 시작하기 위한 "follow your custom instructions"입니다.

Cline이 왜 이 방식을 사용하는지 직접 설명한 내용을 읽어보세요. 트레이드오프에 대해 매우 직설적으로 설명하고 있습니다. "저는 전문 소프트웨어 엔지니어인 Cline입니다. 저에게는 독특한 특징이 있습니다. 세션 간에 제 메모리가 완전히 초기화된다는 점입니다. 이는 한계가 아니라, 제가 완벽한 문서를 유지하도록 이끄는 원동력입니다."

이것이 이 마이그레이션의 실제 모습입니다. Claude Code의 메모리는 자동이었고 로컬 머신 전용이었습니다. 반면 Cline의 메모리는 수동이며 리포지토리에 저장됩니다. 이를 통해 ~/.claude/projects/에서는 결코 얻을 수 없었던 이점, 즉 팀원이 이를 읽고 검토할 수 있으며 새 노트북으로 교체해도 유지된다는 장점을 얻게 됩니다. 대신 사용자의 개입 없이 자동으로 처리되던 부분은 포기해야 합니다.

워크플로 팁 한 가지: /newtask는 인수인계 프리미티브에 가장 가까운 기능으로, "개발자 인수인계처럼 작동합니다. 중요한 내용(전체 계획, 완료된 작업, 관련 파일, 다음 단계)을 깨끗한 컨텍스트 창을 가진 새로운 작업으로 패키징합니다." 반면 /smol(/compact로도 호출 가능)은 그 자리에서 압축을 수행합니다. 상태를 단순히 요약하는 대신 명확히 기록해 두고 싶다면 두 명령어를 실행하기 전에 update memory bank를 사용하세요.

마이그레이션이 실제로 어떻게 진행되었는지 살펴보세요. 파일 이름이 변경되었고, 폴더는 이미 올바른 위치에 있었습니다. 그리고 유일하게 되돌릴 수 없는 단계는 한 도구가 특정 머신에서 해당 도구만 사용하는 형식으로 작성한 노트 디렉터리를 읽는 것이었습니다.

이것은 Claude Code나 Cline의 잘못이 아닙니다. 지속되어야 할 지식이 그것을 생성한 에이전트 내부에 머물 때 발생하는 현상입니다. Claude Code의 자동 메모리는 명시적으로 로컬 머신 전용입니다. Cline의 Memory Bank는 명시적으로 사용자가 수동으로 유지 관리하는 문서화 방식입니다. 둘 다 합리적인 설계이지만, 특정 결정이 내려진 이유에 대한 유일한 사본을 보관하기에 적합한 장소는 아닙니다.

바로 이 문제를 해결하기 위해 MemoryLake가 존재합니다. 도구들이 쿼리할 수 있는 레이어에 프로젝트의 지속 가능한 지식을 보관하므로, 에디터를 전환하는 것은 마이그레이션 작업이 아니라 단순한 취향의 선택이 됩니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

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

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

각각 하나의 사실만 담은 짧은 항목들을 작성하세요. 1단계에서 /memory를 통해 읽은 내용이 아직 생생할 때 작성하는 것이 좋습니다.

feedback 카테고리의 모든 내용. 사용자가 제공한 수정 사항과 확인된 접근 방식입니다. 이 카테고리는 새로운 도구에서 다시 논쟁거리가 될 가능성이 가장 높습니다. 코드베이스 자체에는 이러한 내용이 전혀 암시되어 있지 않기 때문입니다.

이유가 첨부된 결정 사항. "부하가 걸리면 읽기 복제본이 지연되므로 마이그레이션은 추가만 가능합니다." 지침은 규칙을 명시할 뿐이며, 대안이 다시 제안되는 것을 막을 수 있는 것은 오직 이러한 결정 배경뿐입니다.

이미 시도했다가 거부된 접근 방식. 지침 파일이나 커밋 메시지에는 없지만 매 세션마다 다시 제안되는 내용들입니다.

아무도 알려주지 않는 환경적 사실. CI에서만 실패하는 테스트, 문서화되지 않은 속도 제한(rate limit), 두 작업 간의 순서 의존성 등입니다.

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

사용 중인 도구를 연결하세요. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Cline, Codex, OpenClaw 등 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽을 수 있습니다. 즉, 전환 기간 동안 동일한 추론 과정의 복사본 두 개를 유지 관리할 필요 없이 동일한 리포지토리에서 Cline과 Claude Code를 동시에 실행할 수 있습니다.

세 가지 분명한 한계가 있습니다. MemoryLake는 AGENTS.md, .clinerules/ 또는 Memory Bank 파일을 작성하지 않습니다. 이러한 파일들은 각 도구를 제어하는 방법이며, 위에서 설명한 감지 동작은 각 도구의 몫입니다. MemoryLake는 사용자나 에이전트가 입력한 내용만 보관하므로 2단계는 수동으로 진행됩니다. 또한 지침은 강제되는 설정이 아니라 컨텍스트로 작용합니다. 매번 반드시 준수해야 하는 사항이 있다면 메모리 레이어 대신 각 도구의 자체 강제 메커니즘을 사용하세요.

Skills가 더 이상 마이그레이션 대상이 아닙니다. .claude/skills/는 Cline이 직접 읽는 디렉터리이므로 이동할 필요가 없습니다.

"어떤 파일이 활성화되어 있는가?"에 대한 답이 명확해집니다. .clinerules/, .cursorrules, .windsurfrules, AGENTS.md가 활성화되며, CLAUDE.md는 제외됩니다.

동전 던지기식 결정 대신 충돌이 해결됩니다. Cline에서는 작업 공간 규칙이 글로벌 규칙보다 우선합니다. 반면 Claude Code는 "임의로 하나를 선택할 수 있습니다."

긴 지침 파일이 토글 가능한 여러 개의 짧은 파일로 바뀝니다. 이를 통해 백엔드 작업 중에 프론트엔드 섹션이 로드되는 것을 방지할 수 있습니다.

컨텍스트를 검토할 수 있게 됩니다. Memory Bank 파일은 리포지토리에 저장되어 풀 리퀘스트(pull request)를 거칠 수 있습니다. ~/.claude/projects/<project>/memory/는 결코 그럴 수 없었습니다.

새 노트북으로 바꿔도 초기화되지 않습니다. 자동 메모리는 로컬 머신 전용이었지만, 커밋된 파일은 그렇지 않습니다.

파일 이름을 바꾸기 전에 /memory를 먼저 읽으세요. 여기에는 CLAUDE.md가 의도적으로 생략한 내용들이 담겨 있으며, 자동으로 이전되지 않습니다.

/context를 실행하여 실제로 무엇이 로드되고 있었는지 확인하세요. 하위 디렉터리 파일과 4단계 깊이의 임포트 구조 때문에 루트 파일 하나만으로는 전체 상황을 파악하기 어렵습니다.

AGENTS.md 또는 .clinerules/ 중 하나를 선택하고, 단 하나의 신뢰할 수 있는 소스만 유지하세요. 두 개의 전체 복사본이 있으면 한 스프린트 내에 내용이 서로 달라집니다.

마이그레이션한 후가 아니라, 하기 전에 분할하세요. 토글 기능이 있는 개별 .clinerules/ 파일로 분할해야만 토글 기능의 가치를 제대로 누릴 수 있습니다.

Memory Bank를 실제로 설치하세요. 규칙 파일 하나와 명령어 한 번이면 충분합니다. 이를 건너뛰면 Cline이 자꾸 잊어버린다는 결론에 도달하게 됩니다. 이 증상에 대해서는 why Cline forgets project context에서 다룹니다.

/newtask 또는 /smol을 실행하기 전에 memory bank를 업데이트하세요. 압축하는 것은 실제로 기록해 두는 것과 다릅니다.

.cline/과 Memory Bank를 커밋하세요. Cline의 자체 가이드에서도 프로젝트 설정은 "리포지토리와 함께 이동해야 하는 팀 공유 동작"을 위해 사용할 것을 권장합니다.

항상 로드되는 파일에는 추론 과정을 포함하지 마세요. 두 도구 모두 전달할 수 있는 용량에 제한이 있으며, 추론 과정이 가장 먼저 누락됩니다. 이 일반적인 문제는 why agents ignore the instruction files you wrote에서 다룹니다.

Claude Code에서 Cline으로의 전환은 단순한 이름 변경처럼 보이며, 기계적인 부분은 실제로 그렇습니다. .claude/skills/는 이미 작동하고 있으며, CLAUDE.md는 AGENTS.md 또는 일련의 .clinerules/ 파일이 됩니다. 함정은 Cline의 규칙 표가 .cursorrules와 .windsurfrules는 자동으로 감지하면서 CLAUDE.md는 전혀 언급하지 않는다는 점입니다. 즉, 여러분이 의존하고 있던 바로 그 파일이 반대편에서는 읽을 수 없는 유일한 파일명이 됩니다.

진정으로 전송되지 않는 부분은 자동 메모리입니다. Claude Code는 ~/.claude/projects/<project>/memory/에 자체적으로 네 가지 카테고리로 메모리를 작성하며, 여기에는 설계상 지침 파일에 명시되지 않은 내용들이 포함되어 있고 로컬 머신 전용입니다. Cline의 대체재는 Memory Bank입니다. 리포지토리에 있는 6개의 마크다운 파일로, 규칙 파일과 명령어로 초기화되고 사용자가 직접 유지 관리합니다. 이러한 트레이드오프는 명확히 인지하고 선택할 가치가 있습니다. 자동화는 잃게 되지만 검토 가능성을 얻기 때문입니다.

먼저 메모리 디렉터리를 읽고, /context로 무엇이 로드되고 있었는지 확인한 다음, 지침을 신뢰할 수 있는 단일 파일에 적용하고, Memory Bank를 올바르게 설치하세요. 그리고 결정 사항과 거부된 접근 방식을 두 도구 모두 쿼리할 수 있는 곳에 보관하세요. 그러면 오늘 아침에 어떤 에디터를 열었는지가 에이전트의 이해도를 결정하는 요인이 되지 않게 될 것입니다.