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

Devin이 리포지토리에서 학습한 내용은 마이그레이션할 필요가 없습니다. 이 점을 먼저 명확히 해야 작업량이 크게 줄어듭니다. Devin의 문서에 따르면, 기존 README와 연결된 리포지토리의 파일 구조 및 콘텐츠에서 Knowledge를 자동으로 생성하며, CLAUDE.md 및 AGENTS.md를 포함한 에이전트 지침 파일에서 Knowledge를 가져오고 업데이트합니다. Knowledge 노트가 단순히 README의 내용을 재진술한 것이라면, 해당 내용은 이미 Claude Code가 읽을 리포지토리에 존재합니다.

Devin에 직접 입력한 내용이 대체 불가능한 부분입니다. 배포 순서, 독점 도구의 특이사항, 특정 디렉터리에 접근하면 안 되는 이유 등 다른 어디에도 존재하지 않는 노트들은 Cognition의 웹 앱에 저장되어 있습니다. Devin의 문서에서는 Knowledge를 "Devin이 모든 세션에서 참조할 수 있는 지침 및 조언의 모음"으로 설명하며, 이를 생성, 트리거 및 고정(pin)하는 방법을 설명합니다. 하지만 내보내기 기능에 대한 설명은 없으며, 우회할 방법도 없습니다. 직접 읽고 복사하는 것이 유일한 방법입니다.

텍스트만큼이나 트리거도 중요합니다. 이 부분은 많은 사람들이 놓치는 부분입니다. Devin의 검색은 조건부입니다. "Knowledge는 설정한 트리거를 기반으로 검색됩니다. 트리거가 구체적일수록(예: Knowledge가 적용되는 파일, 리포지토리 또는 작업 유형) 검색 결과가 더 좋아집니다." 노트와 트리거가 결합되면 범위가 지정된 규칙이 됩니다. 트리거가 없는 노트는 모든 세션에 로드해야 하거나 완전히 잊어버리게 될 문장에 불과합니다. 수집할 때는 두 열을 모두 수집하세요.

고정(Pinning) 역시 범위 정보입니다. Knowledge 노트를 모든 리포지토리에 고정하거나 특정 리포지토리에 고정할 수 있습니다. 이는 Claude Code의 메모리 계층 구조에 직접 매핑되므로, 작업하면서 기록해 두세요. 모든 곳에 고정된 노트는 개인 또는 조직 수준의 지침이 되고, 단일 리포지토리에 고정된 노트는 해당 리포지토리에 커밋된 지침이 됩니다.

반대편에서 Claude Code가 제공하는 것. 모든 세션이 시작될 때 로드되는 CLAUDE.md 파일은 광범위한 범위에서 구체적인 범위 순으로 해석됩니다. 먼저 조직에서 관리하는 파일, 개인 설정을 위한 ~/.claude/CLAUDE.md, 팀을 위해 커밋된 프로젝트의 ./CLAUDE.md 또는 ./.claude/CLAUDE.md, 그리고 비공개 프로젝트별 노트를 위한 ./CLAUDE.local.md 순입니다. 작업 디렉터리 상위의 파일은 시작 시 전체가 로드되고, 하위 디렉터리의 파일은 Claude가 해당 디렉터리의 파일을 읽을 때 로드됩니다. 조건부 로드를 위해 .claude/rules/가 있으며, 규칙 파일에 paths: 프런트매터(frontmatter)를 추가하여 Claude가 일치하는 파일에 접근할 때만 컨텍스트에 포함되도록 할 수 있습니다. 이는 Claude Code에 존재하는 Devin 트리거와 가장 유사한 구조적 대안입니다.

시작하기 전 두 가지 솔직한 당부 말씀. Devin의 Knowledge는 실제로 유용하게 작동하는 기능이며, 이번 마이그레이션이 번거로운 이유는 고장 난 도구에서 탈출하는 것이 아니라 잘 작동하는 도구를 떠나기 때문입니다. 또한 Claude Code 역시 완벽한 메모리 시스템은 아닙니다. 공식 문서에 명시되어 있듯이 지침 파일은 "강제된 구성이 아니라 컨텍스트"일 뿐이며, 엄격한 준수를 보장하지 않습니다. 규칙이 매번 반드시 준수되어야 한다면, 문장을 더 잘 쓰는 것보다 훅(hooks)을 사용하는 것을 권장합니다.

1단계: 액세스 권한을 잃기 전에 Knowledge를 수집하고 출처별로 분류하기

Knowledge 목록을 열고 모든 노트를 임시 파일에 복사하세요. 이때 노트별로 텍스트, 트리거, 고정 대상의 세 가지 정보를 함께 기록해야 합니다. 반드시 구독이 유지되는 동안 이 작업을 수행하세요. 이 마이그레이션의 다른 모든 단계는 반복할 수 있지만, 이 단계는 단 한 번만 가능합니다.

그런 다음 각 노트를 출처에 따라 다음 세 가지 범주로 분류하세요:

리포지토리에서 파생된 내용. README의 재진술, 디렉터리 레이아웃, package.json에 작성된 테스트 명령 등입니다. 이 내용들은 삭제하세요. Claude Code가 리포지토리를 읽을 것이며, /init 명령어가 발견된 내용을 바탕으로 초기 CLAUDE.md를 생성합니다. 이를 그대로 복사해 두면 파일만 길어져 오히려 지침 준수율이 떨어집니다.

직접 작성했으며 여전히 유효한 내용. 배포 순서, 특정 플래그가 필요한 도구, 이번 분기에 아무도 리팩터링해서는 안 되는 모듈과 그 이유 등입니다. 이것들이 바로 마이그레이션 대상입니다.

직접 작성했으나 더 이상 유효하지 않은 내용. 모든 Knowledge 모음에는 비활성화된 서비스에 대한 노트나 이미 해결된 버그의 우회 방법 같은 것들이 포함되어 있습니다. 지침 파일에 오래된 규칙을 남겨두는 것은 잃어버리는 것보다 나쁩니다. Claude가 그 잘못된 규칙을 따를 것이기 때문입니다. 기억이 생생할 때 지금 의도적으로 삭제하세요.

작업 시 유용한 팁: Devin 세션에는 어떤 Knowledge에 액세스했는지 표시됩니다. 따라서 최근 세션을 보면 실제로 어떤 노트가 자주 활성화되는지 알 수 있습니다. 한 달 동안 한 번도 검색되지 않은 노트는 트리거가 잘못 설정되었거나 더 이상 유효하지 않은 것이므로, 세 번째 범주(삭제 대상)로 분류하는 것이 좋습니다.

2단계: CLAUDE.md 및 경로 범위 규칙으로 노트 재구성하기

이제 살아남은 노트를 한 파일에 모두 넣지 말고, 기록해 둔 범위에 따라 배치하세요:

• 모든 리포지토리에 고정됨, 개인용 → ~/.claude/CLAUDE.md. 여러분의 습관이나 선호하는 워크플로우입니다. 컴퓨터의 모든 프로젝트에 로드되므로 짧게 유지하세요.
• 모든 리포지토리에 고정됨, 팀 표준 → 각 리포지토리의 프로젝트 CLAUDE.md 또는 팀에서 중앙 집중식으로 배포하는 조직 관리 정책 파일.
• 단일 리포지토리에 고정됨 → 해당 리포지토리의 루트 ./CLAUDE.md에 커밋하여 팀원들이 이를 다시 찾을 필요 없이 그대로 물려받을 수 있도록 합니다.
• 특정 파일 또는 특정 유형의 작업에서 트리거됨 → 해당 파일과 일치하는 paths: 프런트매터가 있는 .claude/rules/ 내의 파일. 이는 Devin 트리거가 하던 역할과 가장 유사합니다. 예를 들어 paths: ["src/api/**/*.ts"]는 Claude가 API 레이어에서 작업할 때만 해당 규칙을 로드하고, 그렇지 않을 때는 컨텍스트에서 제외합니다.
• 비공개 및 프로젝트 전용 → gitignore에 등록된 ./CLAUDE.local.md.

여기서 두 가지 기술적 디테일이 번거로움을 줄여줍니다. Claude Code 문서에서는 CLAUDE.md 파일당 200행 미만을 유지할 것을 권장합니다. 파일이 길어질수록 더 많은 컨텍스트를 소비하고 지침 준수율이 떨어지기 때문입니다. 따라서 1단계에서의 분류 작업은 단순히 정리 정돈이 아니라 결과물을 제대로 작동하게 만드는 핵심 과정입니다. 또한 리포지토리에 이미 Devin이 읽던 AGENTS.md가 있다면 중복해서 작성하지 마세요. @AGENTS.md로 이를 가져오는 CLAUDE.md를 생성하고 그 아래에 Claude 전용 지침을 추가하면, 두 도구 모두 하나의 소스를 읽을 수 있습니다.

마지막으로, 방금 우회한 비대칭성에 주목하세요. Devin은 처음부터 리포지토리의 에이전트 파일을 읽고 있었습니다. Claude Code는 새로운 대화형 흐름이 활성화된 상태에서 /init을 실행할 때 Devin Desktop 설정의 .devin/rules/ 파일을 읽을 수 있으며, /import를 통해 지원되는 에이전트의 구성을 가져올 수 있습니다. 하지만 어떤 도구도 웹 앱에만 존재했던 Knowledge는 읽을 수 없습니다. 여기서 얻을 수 있는 교훈은 Devin에 대한 것이 아닙니다. 벤더의 UI에 저장된 지식은 언젠가 직접 손으로 복사해야 하는 지식이 된다는 점입니다.

여러분은 방금 벤더의 지식 저장소를 파일로 변환하는 데 한 시간을 보냈습니다. 이 파일들은 버전 관리가 가능하고, 검토할 수 있으며, 검색 및 이식이 가능하다는 점에서 확실한 개선책입니다. 하지만 다음 분기에 Codex를 추가하거나, 팀원이 릴리스 노트를 작성하면서 ChatGPT에서 동일한 컨텍스트를 사용하고 싶어 한다면 어떻게 해야 할지 생각해 보세요. 오직 하나의 도구만 읽을 수 있는 곳에서 또다시 복사 작업을 반복해야 할 것입니다.

해결책은 영구적인 자료를 모든 어시스턴트가 읽을 수 있는 단일 저장소에 보관하고, 지침 파일은 본연의 역할, 즉 코딩 에이전트가 항상 눈앞에 두어야 하는 짧고 강력한 규칙을 담는 용도로만 사용하는 것입니다.

MemoryLake는 이를 위한 메모리 레이어입니다. 규칙 뒤에 숨겨진 결정 사항, 장애 이력, 소스 문서 등을 한곳에 모아 Claude 및 Codex와 같은 MCP 지원 도구에서 직접 읽을 수 있고, API를 통해 ChatGPT에서도 읽을 수 있습니다. 규칙은 리포지토리에 남고, 그 규칙이 만들어진 이유는 특정 제품의 데이터베이스에 갇히지 않게 됩니다.

1단계: API 키 생성하기

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

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

방금 마이그레이션한 노트의 배경이 되는 문서, 이미지, 파일을 업로드하세요. 배포 순서가 명시된 런북, 특정 디렉터리 접근을 제한하게 만든 장애 보고서, 아키텍처 결정 사항, 이전에 기록해 둔 벤더의 API 특이사항 등이 해당됩니다. 한 줄짜리 요약본보다는 원본 소스를 업로드하세요. 요약본은 방금 여러분이 한 시간 동안 재구성하느라 애썼던 바로 그 형태입니다.

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

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 설정하세요. Claude Code는 CLAUDE.md 파일과 함께 MCP를 통해 저장소를 직접 읽습니다. ChatGPT의 경우, API를 통해 필요한 내용을 검색하여 프롬프트나 모델을 호출하는 워크플로우에 주입할 수 있습니다.

첫 번째 차이점은 규칙과 함께 그 이유가 함께 전달된다는 것입니다. "스테이징 배포 전에 마이그레이션을 실행하라"는 규칙은 누군가 불필요해 보인다고 판단하기 전까지만 준수됩니다. 반면 "스테이징 배포 전에 마이그레이션을 실행하라 — 지난 3월에 순서가 잘못된 배포로 인해 스테이징 서버가 두 번 다운되었습니다. 보고서 참조"라는 규칙은 새로 온 엔지니어의 자의적 판단 속에서도 살아남습니다.

두 번째는 CLAUDE.md 파일을 짧게 유지할 수 있다는 점입니다. 지침 파일의 가장 큰 딜레마는 유용한 모든 내용을 항상 로드되는 파일에 넣고 싶어 하지만, 그 파일이 커질수록 성능이 저하된다는 것입니다. 세부 사항을 검색할 수 있게 되면, 지침 파일에는 핵심적인 제약 조건만 남겨둘 수 있습니다. 이는 이미 알고 있는 내용에서 시작하는 대신 매 세션마다 코드베이스를 다시 읽는 에이전트 문제를 해결하는 방법이기도 합니다.

세 번째는 다음 마이그레이션 비용이 매우 저렴해진다는 것입니다. 이번 마이그레이션에는 UI에서 복사하는 데 한 시간이 걸렸지만, 다음번에는 설정 변경 한 번으로 끝납니다. 지식이 떠나려는 도구 내부에 갇혀 있지 않기 때문입니다.

또한 이는 Claude Code가 이미 제공하는 기능과도 잘 결합됩니다. Claude Code의 자동 메모리(auto memory) 기능은 빌드 명령과 디버깅 인사이트를 리포지토리별로 유용하게 계속 축적합니다. 다만 한계를 알아둘 필요가 있습니다. 이 저장소는 로컬 머신에 국한되며, 문서에 따르면 파일이 머신 간 또는 클라우드 환경 간에 공유되지 않습니다. 따라서 로컬 편의성 레이어로는 훌륭하지만 공식 기록 시스템으로는 부족하며, 이는 우리가 원하는 정확한 역할 분담이기도 합니다.

액세스 권한이 있을 때 수집하기

Knowledge, 메모리, 저장된 컨텍스트는 구독이 만료되는 순간까지만 표시되며, 단 1분도 연장되지 않습니다. 먼저 복사부터 하고 정리는 나중에 하세요. 이 단계는 전체 마이그레이션 과정 중 유일하게 기한이 있는 단계입니다.

텍스트뿐만 아니라 트리거도 기록하기

검색 조건도 중요한 정보입니다. Devin이 결제 모듈을 다룰 때 활성화되었던 노트는 경로 범위 규칙이 됩니다. 하지만 이 조건을 잊어버린 채 노트만 남겨두면 모든 세션에서 노이즈가 되거나 무관하다는 이유로 삭제될 수 있습니다. 두 열을 모두 복사하세요.

마이그레이션 과정에서 과감히 삭제하기

마이그레이션은 모든 규칙을 새로운 시각으로 검토할 수 있는 유일한 기회입니다. 이 기회를 활용하세요. 오래된 지침은 없는 것보다 나쁩니다. 에이전트는 그 지침을 따를 것이고, 여러분은 한 달 동안 그 사실을 눈치채지 못할 수도 있기 때문입니다.

이유는 검색 가능한 곳에, 규칙은 로드되는 곳에 두기

두 줄짜리 규칙은 CLAUDE.md에 있어야 합니다. 반면 장애 보고서, RFC, 그리고 이를 도출해 낸 벤더 스레드는 에이전트가 설명이나 재고가 필요할 때 가져올 수 있는 저장소에 있어야 합니다. 두 가지를 모두 지침 파일에 쑤셔 넣으면 파일이 800행에 달하게 되고, 결국 에이전트가 지침을 따르지 않게 됩니다.

지침 파일이 강제력을 가질 것이라 기대하지 않기

Claude Code의 자체 문서에서도 지침 파일은 강제된 구성이 아니라 컨텍스트일 뿐이라고 명확히 밝히고 있으며, 매번 반드시 실행되어야 하는 작업에는 훅(hooks)을 사용할 것을 권장합니다. 마이그레이션하려는 규칙이 매우 중요한 것(예: main 브랜치에 직접 푸시 금지, 항상 린터 실행)이라면 훅이나 CI 체크로 구현하고, 지침 파일에는 그것이 왜 존재하는지 설명하는 역할만 부여하세요.

Devin에서 Claude Code로의 이동은 단방향 복사입니다. 그 이유는 적대적인 정책 때문이 아니라 구조적인 한계 때문입니다. Devin의 Knowledge는 CLAUDE.md 및 AGENTS.md를 포함한 리포지토리 파일에서 정보를 가져오지만, Devin 외부로 정보를 내보내는 기능은 없습니다. 리포지토리에서 파생된 모든 것은 이미 Claude Code가 참조할 위치에 있습니다. 웹 앱에 직접 입력한 내용과 범위 지정을 위한 트리거 및 고정 정보는 액세스 권한이 있을 때 직접 수집해야 합니다.

한 손에는 삭제 키를 쥐고 수집 작업을 진행한 다음, 범위별로 재구성하세요. 개인 설정은 ~/.claude/CLAUDE.md에, 팀 표준은 커밋된 CLAUDE.md에, 파일별 규칙은 paths: 프런트매터가 있는 .claude/rules/에, 비공개 노트는 CLAUDE.local.md에 배치하세요. 파일은 짧게 유지해야 합니다. 그런 다음 규칙 뒤에 숨겨진 이유들을 어시스턴트가 읽을 수 있는 단일 저장소에 보관하세요. 그렇게 하면 다음에 플랫폼을 바꿀 때는 지식을 다시 파헤칠 필요 없이 도구만 바꾸면 됩니다.