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

프로젝트 규칙(Project Rules)은 거의 그대로 이전됩니다. Warp의 프로젝트 규칙은 리포지토리 루트 또는 하위 디렉토리의 "AGENTS.md 파일(또는 하위 호환성을 위한 WARP.md)"에 위치합니다. Claude Code는 동일한 형태로 CLAUDE.md를 읽습니다. 내용은 그대로 이동하며, 파일 이름과 확인 순서만 변경됩니다.

한 가지 파일 이름 세부 사항에서 실수가 자주 발생합니다. Warp 문서에는 다음과 같은 명시적인 경고가 있습니다. "Warp가 인식하려면 파일 이름이 반드시 대문자여야 합니다(예: agents.md나 Agents.md가 아닌 AGENTS.md)." Claude Code는 CLAUDE.md를 찾습니다. 파일을 복사하고 이름을 바꾸는 것을 잊어버리면, Warp는 읽기를 중단하고 Claude Code는 시작조차 하지 못합니다.

글로벌 규칙(Global Rules)은 몇 가지 주의 사항과 함께 사용자 지침이 됩니다. Warp의 글로벌 규칙은 "모든 프로젝트와 컨텍스트에 적용"되며 Warp Drive Rules 창에서 관리됩니다. 각 규칙에는 선택적 이름과 "규칙의 역할 및 적용 시기"에 대한 설명이 포함됩니다. Claude Code에서 이와 가장 유사한 것은 "모든 프로젝트에 대한 개인 기본 설정"으로 설명되는 ~/.claude/CLAUDE.md입니다. 내용은 매핑되지만 메타데이터는 매핑되지 않습니다. 보존할 규칙별 설명 필드가 없기 때문에, 적용 시기를 알리기 위해 설명에 의존했던 Warp 글로벌 규칙은 무조건적인 지침이 됩니다.

규칙 우선순위의 형태가 바뀝니다. Warp는 명시된 순서대로 충돌을 해결합니다. "1. 현재 하위 디렉토리의 프로젝트 규칙 파일에 있는 규칙 2. 루트 디렉토리의 프로젝트 규칙 파일에 있는 규칙 3. 글로벌 규칙." Claude Code는 네 가지 스코프를 "가장 넓은 범위에서 가장 구체적인 범위 순으로 로드하므로, 프로젝트 지침은 사용자 지침 다음에 컨텍스트에 나타납니다." 즉, 관리형 정책(managed policy), 사용자, 프로젝트, 그리고 CLAUDE.local.md 순입니다. 의도는 같지만 메커니즘이 다르며, Claude Code 문서에서는 다음과 같은 실패 모드를 솔직하게 밝히고 있습니다. "두 규칙이 서로 모순되는 경우, Claude는 임의로 하나를 선택할 수 있습니다."

하위 디렉토리 로딩은 유사하지만 동일하지는 않습니다. Warp는 "루트 및 현재 디렉토리의 AGENTS.md(또는 WARP.md)를 자동으로 적용"하고, 다른 하위 디렉토리에 대해서는 "해당 하위 디렉토리의 규칙 파일도 포함하도록 최선의 노력을 다합니다." Claude Code는 실행 시 "작업 디렉토리 위의 디렉토리 계층 구조에 있는" 파일을 로드하는 반면, "하위 디렉토리의 파일은 Claude가 해당 디렉토리의 파일을 읽을 때 온디맨드로 로드"합니다. 둘 다 하위 트리에 대해 지연 로딩(lazy loading)을 수행하지만, 트리거가 다릅니다.

코드베이스 컨텍스트(Codebase Context)는 이전되지 않습니다. Warp는 "에이전트가 코드를 이해할 수 있도록 Git으로 추적되는 코드베이스를 인덱싱"하며, 특히 "Warp 서버에는 코드가 저장되지 않습니다." ignore 파일로 이를 조정하고 Synced, Discovering files, Failed 또는 Codebase too large 상태에서 상태를 확인할 수 있습니다. 이것은 문서가 아니라 인덱스이므로 내보낼 수 있는 것이 없습니다. 대신 Claude Code는 온디맨드로 파일을 읽습니다. 인덱스가 제공하던 검색 품질은 잃게 되지만, 동기화를 기다릴 필요가 없다는 장점을 얻게 됩니다.

Agent Memory가 가장 큰 부분이며, 그 경계는 명확합니다. Warp의 Agent Memory는 "Warp 에이전트, Claude Code, Codex를 포함하여 지원되는 하네스 전반에서 에이전트에게 지속적인 메모리를 제공"합니다. 이는 실제적이고 성숙하며 대부분의 시스템보다 더 많은 기능을 수행합니다. 개인, 에이전트 및 팀 저장소, 새 에이전트에 대해 기본적으로 켜져 있는 "자동 메모리(Auto-memory)", 대화가 끝난 후 자동 추출("새로운 지식은 기존 메모리와 병합되거나 충돌 시 대체됨"), 저장소별 지침이 포함된 저장소별 읽기 전용 또는 읽기-쓰기 권한, 그리고 추적성("각 메모리는 출처를 기록함") 및 감사 가능성("메모리에 대한 모든 변경 사항이 기록됨")을 제공합니다.

이 중 일부라도 유지될지 여부는 두 가지 사실에 의해 결정됩니다. 첫째, 이는 "연구 프리뷰(research preview) 단계에 있으며 디자인 파트너를 위해 팀별로 활성화"되고 대기자 명단이 있으므로, 대부분의 독자는 애초에 이 기능을 가지고 있지 않습니다. 둘째, 디자인 파트너들이 놀라는 부분인데, 서드파티 하네스 지원은 "클라우드 에이전트로 실행될 때" 적용되며, 문서에는 "연구 프리뷰 기간 동안 서드파티 하네스를 로컬에서 실행하는 것은 지원되지 않는다"고 명시되어 있습니다.

따라서 Agent Memory를 사용하고 있었고 자체 터미널에서 로컬로 실행되는 Claude Code로 이동하는 경우, 지원되는 경로를 벗어나게 됩니다. 메모리 자체는 원래 위치에 유지되며("메모리는 어떤 하네스가 읽고 쓰는지와 관계없이 소유자(사용자, 에이전트 또는 팀)에게 바인딩된 상태로 유지됨"), Warp가 이를 보유하는 시스템으로 남습니다.

1단계: 규칙 이동 및 스코프 설정

실제로 복사되는 부분인 파일부터 시작합니다.

리포지토리의 각 AGENTS.md(또는 WARP.md)를 가져와 동일한 경로에 일치하는 CLAUDE.md를 생성합니다. 루트 파일은 루트 CLAUDE.md로, ui/AGENTS.md는 ui/CLAUDE.md로 이동합니다. 내용은 변경하지 않습니다.

그런 다음 모든 것을 하나의 파일에 쏟아붓기보다 스코프별로 분할합니다. Claude Code 문서에서는 "CLAUDE.md 파일당 200행 미만"을 목표로 할 것을 권장합니다. "파일이 길어지면 더 많은 컨텍스트를 소비하고 준수율이 떨어지기 때문"입니다. Warp 루트 파일이 그 이상으로 커졌다면 지금이 분할할 때입니다. Claude Code의 .claude/rules/ 디렉토리는 주제별 파일을 허용하며, "모든 .md 파일은 재귀적으로 탐색"되고, 규칙은 paths 프론트매터(frontmatter)로 범위를 지정하여 "Claude가 지정된 패턴과 일치하는 파일로 작업할 때만 적용"되도록 할 수 있습니다.

이 매핑은 신중하게 진행할 가치가 있습니다. Warp 하위 디렉토리 규칙 파일이 존재하는 이유 중 하나는 Warp에 지침의 범위를 제한할 다른 방법이 없었기 때문입니다. Claude Code에서는 이를 중첩된 CLAUDE.md로 유지하거나 경로 범위 규칙으로 변환할 수 있으며, 후자가 보통 "모든 API 핸들러는 입력을 검증해야 한다"와 같은 규칙에 더 잘 맞습니다.

글로벌 규칙을 ~/.claude/CLAUDE.md로 이동합니다. 특정 프로젝트에만 해당하는 개인적인 설정의 경우, 프로젝트 루트의 CLAUDE.local.md가 그 역할을 하며 이는 .gitignore에 추가해야 합니다.

마지막으로, 짐작하지 말고 확인하세요. 세션에서 /context를 실행하고 Memory files 아래의 목록을 확인하십시오. 이는 실제로 무엇이 로드되었는지 확인하는 Claude Code의 공식적인 방법입니다. 위의 모든 마이그레이션 단계는 겉으로는 작동하는 것처럼 보이지만 실제로는 절반만 작동할 수 있는 성격의 것들이며, 이는 일반적으로 why Claude Code forgets project context의 원인이 되는 패턴이기도 합니다.

2단계: 파일이 없는 지식을 어떻게 처리할지 결정하기

이제 복사되지 않는 부분입니다.

Agent Memory를 사용하고 있었다면 Warp 사용을 중단하기 전에 해당 저장소에 무엇이 있는지 인벤토리를 작성하십시오. 각 메모리가 출처를 기록하므로 추적성이 도움이 됩니다. 배포 런북, 리뷰 컨벤션, 온콜 절차 등 가치 있는 자료는 대개 팀 저장소에 있습니다. 이를 읽고 여전히 중요한 내용을 기록해 두십시오. Warp 저장소를 Claude Code 메모리 디렉토리로 변환하는 내보내기 경로는 없으므로, 이는 직접 읽고 다시 작성하는 수동 작업이 됩니다.

Claude Code에는 이 중 일부를 수용할 수 있는 자체 자동 레이어가 있습니다. 자동 메모리는 기본적으로 켜져 있으며, Claude는 type 필드로 태그가 지정된 네 가지 종류의 노트를 작성합니다. user는 "귀하의 역할, 전문성 및 작업 선호도", feedback은 "귀하가 Claude에게 제공하는 수정 사항 및 확인한 접근 방식", project는 "코드나 git 기록에서 Claude가 도출할 수 없는 진행 중인 작업, 마감일 및 결정 사항", reference는 "프로젝트 외부에서 정보를 찾을 수 있는 위치"를 나타냅니다.

의존하기 전에 그 형태를 파악해 두십시오. 이는 ~/.claude/projects/<project>/memory/ 아래에 MEMORY.md 인덱스와 함께 일반 파일로 저장되며, 로드되는 슬라이스는 제한되어 있습니다("매 세션마다 첫 200행 또는 25KB"). 범위는 git 리포지토리에서 파생된 "리포지토리별, 작업 트리 간 공유"입니다. 그리고 Claude는 의도적으로 중복을 피합니다. "Claude는 코드베이스에서 도출할 수 있는 모든 것을 건너뛰며", "또한 CLAUDE.md 파일에 이미 명시된 내용도 건너뜁니다."

두 시스템 간의 격차는 품질이 아니라 토폴로지(구조)입니다. Warp의 저장소는 호스팅되고 여러 에이전트에 연결할 수 있으며, 팀 전체가 사용하는 에이전트에 저장소를 연결하여 팀과 공유할 수 있습니다. Claude Code의 자동 메모리는 로컬이며 리포지토리별로 존재하고 개인의 것입니다. 첫 번째에서 두 번째로 이동한다는 것은 팀의 공유 지식이 여러 사람의 개인 파일이 된다는 것을 의미하며, 이는 keeping team AI context when someone leaves에서 설명하는 실패 모드입니다.

위의 모든 과정은 일회성 변환으로, 결국 로컬 파일만 남고 더 이상 팀 공유 레이어는 갖지 못하게 됩니다. 변환 과정을 줄이고 결과를 더 지속 가능하게 만드는 세 번째 옵션이 있습니다. 바로 두 도구 중 어느 쪽에도 속하지 않는 저장소에 지속적인 지식을 보관하는 것입니다.

이렇게 하면 마이그레이션의 프레임이 바뀝니다. Warp의 메모리를 Claude Code의 메모리로 번역하는 대신, 두 도구 모두 동일한 레이어를 가리키게 하고 도구별 파일은 작고 도구에 특화된 상태로 유지합니다. 또한 이는 다음 마이그레이션(반드시 발생할 것입니다)이 고고학 프로젝트가 아니라 단순한 규칙 파일 이름 변경이 됨을 의미합니다. MemoryLake는 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인하고 대시보드에서 API 키를 생성합니다. 이 자격 증명은 하네스가 아닌 귀하에게 귀속되며, 이것이 여기서 중요한 속성입니다. Warp의 Agent Memory는 Warp 클라우드 에이전트로 실행될 때만 서드파티 하네스를 지원하지만, 이 방식은 로컬을 포함하여 어디서 실행하든 Claude Code를 지원합니다.

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

수동 마이그레이션의 2단계에서 수집한 자료가 여기에 들어갑니다. 배포 런북, 리뷰 컨벤션, 아키텍처 결정 및 그 이유, 새로운 팀원에게 필요한 도메인 어휘 등 Warp 팀 저장소에서 읽어온 잃고 싶지 않은 모든 내용이 해당됩니다.

도구별 연결 설정은 제자리에 두십시오. 빌드 명령어와 파일 레이아웃은 CLAUDE.md에 유지하고, 사실 정보는 여기로 이동합니다.

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

Claude Code가 이 저장소를 가리키도록 설정하고, 두 도구를 모두 실행 중이라면 Warp도 가리키도록 설정합니다. 마이그레이션 중인 팀은 대개 한동안 두 도구를 병행하여 사용하며, 이 시기가 바로 공유 레이어가 제 역할을 톡톡히 하는 때입니다. 이는 일반적으로 cross-agent memory의 배경이 되는 논리와 동일합니다.

첫 번째 변화는 마이그레이션 시 정보 손실이 없어진다는 점입니다. 파일은 어떻게든 복사되지만, 파일로 만들 수 없는 지식이 누락되기 마련인데, 공유 저장소가 바로 그 부분을 보존해 줍니다.

두 번째는 팀 지식이 계속 팀 지식으로 유지된다는 점입니다. Warp는 팀 전체가 사용하는 에이전트에 저장소를 연결하여 공유를 쉽게 만들었습니다. Claude Code의 자동 메모리는 설계상 리포지토리별로 존재하며 로컬에 저장됩니다. 공유 레이어를 사용하면 두 번째 도구를 도입하면서도 첫 번째 속성을 그대로 유지할 수 있습니다.

세 번째는 두 도구를 모두 실행하는 데 드는 유지 관리 비용이 사라진다는 점입니다. Warp의 /init은 기존의 외부 규칙 파일을 연결할 수도 있습니다. 지원되는 목록에는 CLAUDE.md, .cursorrules, AGENT.md, GEMINI.md, .clinerules, .windsurfrules, .github/copilot-instructions.md가 포함되어 있어 지침 레이어를 진정으로 하나의 파일로 구성할 수 있습니다. 지식 레이어도 동일한 처리가 필요하며, 이것이 바로 Warp's project rules setup이 자체적으로 할 수 있는 일과 할 수 없는 일의 차이입니다.

• 단순히 복사만 하지 말고 이름을 바꾸십시오. Warp가 인식하려면 AGENTS.md가 모두 대문자여야 하며, Claude Code는 CLAUDE.md를 원합니다. 복사만 하고 이름을 바꾸지 않은 파일은 양쪽 도구 모두 읽지 않습니다.
• 마이그레이션하기 전에 분할하십시오. CLAUDE.md당 200행 미만을 목표로 하고, 범위가 지정된 Warp 하위 디렉토리 규칙을 .claude/rules/ 아래의 paths 범위 항목으로 변환하십시오.
• /context로 확인하십시오. 파일이 로드되었다고 가정하지 말고 Memory files 목록을 확인하십시오.
• Warp를 떠나기 전에 저장소를 읽어두십시오. 추적성을 통해 각 메모리의 출처를 알 수 있으며, 이를 자동으로 내보내 주는 도구는 없습니다.
• 자동 메모리가 선택적으로 작동함을 인지하십시오. CLAUDE.md에 이미 명시된 내용과 코드에서 도출할 수 있는 내용은 건너뛰며, 첫 200행 또는 25KB만 로드합니다.
• 모순되는 내용을 배제하십시오. Claude Code는 충돌하는 규칙 중에서 임의로 선택할 수 있으므로, 중첩된 파일과 규칙을 정기적으로 검토하십시오.
• 반드시 준수해야 하는 사항에는 훅(hook)을 사용하십시오. 지침은 컨텍스트일 뿐 강제력이 없습니다. 작업을 완전히 차단하는 공식적인 방법은 PreToolUse 훅을 사용하는 것입니다.
• Agent Memory가 그대로 유지될 것이라 가정하지 마십시오. 이는 디자인 파트너를 위해 팀별로 활성화되는 연구 프리뷰 단계이며, 프리뷰 기간 동안 로컬 서드파티 하네스는 지원되는 경로가 아닙니다.

이 마이그레이션에서 파일과 관련된 절반은 이름 변경과 범위 결정에 불과하며, Claude Code의 규칙 디렉토리는 수많은 하위 디렉토리 파일보다 조건부 안내를 제공하는 데 진정으로 더 뛰어납니다.

어려운 부분은 아무도 내보내 주지 않는 나머지 절반입니다. Warp는 호스팅되고 팀이 공유하며 감사가 가능한 메모리 시스템을 보유하고 있는 반면, Claude Code는 리포지토리별 로컬 마크다운을 보유합니다. 떠나기 전에 저장소를 읽고, 지속되어야 할 사실 정보를 두 도구 모두에 속하지 않는 곳에 두십시오. 그러면 마이그레이션 비용은 한 분기 동안의 재학습 대신 단 하루 오후의 시간으로 충분할 것입니다.