컨텍스트 손실 없이 GitHub Copilot에서 Devin Desktop으로 마이그레이션하는 방법 (2026)

Copilot의 커스텀 영역은 세 가지 레이어로 구성되어 있으며, GitHub은 이에 대해 개인 지침, 리포지토리 지침, 조직 지침 순으로 명확한 우선순위를 명시하고 있습니다. 이때 "관련된 모든 지침 세트가 Copilot에 제공됩니다."

리포지토리 레이어 내부에는 다음과 같이 순위가 매겨진 세 가지 하위 유형이 있습니다:

1. .github/instructions/**/*.instructions.md에 있는 경로별 지침
2. .github/copilot-instructions.md에 있는 리포지토리 전체 지침
3. AGENTS.md, CLAUDE.md 또는 GEMINI.md 파일에 지정된 에이전트 지침

이와 별개로, Copilot에는 메모리 시스템이 있습니다. Copilot Memory는 "현재 퍼블릭 프리뷰 단계이며 변경될 수 있음" 상태로, 두 가지 종류의 정보를 저장합니다. 하나는 "코딩 컨벤션, 아키텍처 결정, 빌드 명령 및 프로젝트별 규칙"과 같은 "리포지토리 수준의 사실(Repository-level facts)"이고, 다른 하나는 "사용자가 Copilot과 상호작용하고자 하는 방식에 대한 암묵적 또는 명시적 개인 선호도"로 설명되는 "사용자 수준의 선호도(User-level preferences)"입니다.

이제 인벤토리를 살펴보겠습니다.

그대로 이전됨. AGENTS.md. 두 도구 모두 이 파일을 읽으므로 변환이 필요 없습니다. 이것은 마이그레이션 과정에서 얻을 수 있는 유일하고도 실질적인 공짜 이득입니다.

재작성 후 이전됨. .github/copilot-instructions.md 및 경로별 .instructions.md 파일들. 콘텐츠는 이식 가능한 마크다운 형식이지만, 활성화 메커니즘이 변경되며 이는 아래에서 다룹니다.

이전되지 않음. 다음 세 가지는 각각 다른 이유로 이전되지 않습니다.

개인 지침(Personal instructions)은 범위 문제 때문입니다. "개인 맞춤형 지침은 GitHub의 GitHub Copilot Chat에서만 지원됩니다." 애초에 에디터까지 도달하지 않던 정보이므로 이동할 필요가 없습니다. 다만, 기록해 둘 만한 선호도가 포함되어 있을 수는 있습니다.

조직 맞춤형 지침(Organization custom instructions)은 조직 수준의 GitHub 설정이기 때문입니다. 이 지침은 "현재 GitHub.com의 Copilot Chat, GitHub.com의 Copilot 코드 리뷰, GitHub.com의 Copilot 클라우드 에이전트에서만 지원됩니다." 조직에서 이 지침에 의존하고 있다면, 한 팀에서 Copilot을 사용 중단하더라도 다른 사람들에게는 여전히 유지된다는 점을 참고하세요.

Copilot Memory는 저장 위치와 강력한 결합성 때문입니다. 리포지토리 수준의 사실은 "해당 리포지토리에서 Copilot Memory에 액세스할 수 있는 모든 사용자가 사용할 수 있지만, 동일한 리포지토리에서의 작업에만 사용할 수 있습니다." 사용자 수준의 선호도는 "동일한 사용자의 향후 상호작용에서만 사용할 수 있습니다." 다른 벤더의 도구로 내보내는 공식적인 방법은 문서화되어 있지 않습니다. 내용을 조회할 수 있고, 리포지토리 소유자가 리포지토리 수준의 사실을 검토하고 삭제할 수는 있지만, 결국 직접 수동으로 읽어내는 것이 유일한 마이그레이션 방법입니다.

생각보다 덜 고통스러운 세부 사항이 하나 있습니다. Copilot Memory의 적용 범위는 대부분의 사람들이 생각하는 것보다 좁습니다. GitHub에 따르면, "Copilot Memory는 현재 Copilot 클라우드 에이전트, Copilot 코드 리뷰 및 Copilot CLI에서 사용됩니다." 팀에서 Copilot을 주로 에디터 내 자동 완성 및 채팅용으로만 사용했다면, 우려했던 것보다 메모리에 저장된 내용이 훨씬 적을 수 있습니다. 시간을 할당하기 전에 먼저 확인해 보세요. 사람들이 왜 Copilot forgets codebase context 현상을 겪는지 의아해하는 것과 동일한 영역의 혼선이 여기에도 적용됩니다.

이 가이드는 Copilot 자체 레이어의 작동 방식을 다시 설명하지 않습니다. 먼저 해당 내용이 필요하다면 setting up Copilot memory in VS Code에서 소스 측 설정을 자세히 다루고 있으니 참고하시기 바랍니다. 이하 내용은 마이그레이션을 결정하고 매핑 방법을 찾고 계신다는 전제하에 진행됩니다.

1단계: 각 규칙이 실제로 어떤 Copilot 레이어에서 제공되었는지 파악하고 인벤토리 작성하기

Devin 쪽에 무언가를 작성하기 전에 이 작업을 먼저 수행해야 합니다. 우선순위에 따라 실제로 적용되던 동작이 무엇이었는지 파악할 수 있기 때문입니다.

Copilot의 전체 우선순위(높은 순서대로)는 개인 지침, 경로별 지침, 리포지토리 전체 지침, AGENTS.md와 같은 에이전트 지침, 그리고 조직 맞춤형 지침 순입니다. 만약 특정 컨벤션이 copilot-instructions.md와 AGENTS.md 모두에 존재했다면, 전자가 우선 적용되었습니다. 두 가지를 모두 Devin의 상시 활성화(always-on) 레이어로 마이그레이션하면, 이전에는 무시되었던 규칙이 다시 살아나게 됩니다.

다음 네 가지를 수집하세요:

• .github/copilot-instructions.md 전체 내용.
• 모든 .github/instructions/**/*.instructions.md 파일과 해당 경로 패턴. 패턴 부분이 가장 가치 있는 정보입니다.
• AGENTS.md, CLAUDE.md 또는 GEMINI.md 파일(존재하는 경우).
• 직접 수동으로 읽어낸 Copilot Memory 내용. 리포지토리 수준의 사실(Repository-level facts)은 수집할 가치가 충분하지만, 사용자 수준의 선호도는 개인별로 적용되므로 단순히 다시 설정하는 편이 더 쉽습니다. GitHub은 "사용자는 Copilot 요금제와 관계없이 자신의 사용자 수준 선호도를 조회하고 삭제할 수 있다"고 명시하고 있으므로, 각자 개별적으로 진행할 수 있습니다.

리포지토리 수준의 사실을 읽는 동안, 정보의 정확성이 어떻게 유지되었는지에 대한 유용한 팁을 참고하세요. 이 사실들은 "이를 뒷받침하는 코드를 가리키는 인용구(citation)와 함께 저장"되며, Copilot이 이를 사용할 때 "현재 브랜치와 해당 인용구를 대조하여 정보가 여전히 정확한지 확인합니다. 검증된 사실만 사용됩니다." Devin에는 이를 대신해 주는 기능이 없습니다. 마이그레이션하는 사실에 대한 관리 책임은 이제 온전히 여러분에게 있습니다.

2단계: 모든 규칙에 대한 활성화 모드 선택하기 (Devin의 필수 요구 사항)

이 부분이 가장 핵심적인 작업이며, 대충 마이그레이션했다가는 컨텍스트 창이 불필요하게 비대해지는 원인이 됩니다.

Devin Desktop의 규칙은 .devin/rules에 저장되며(권장 사항이며 .windsurf/보다 우선순위가 높음), "현재 워크스페이스 디렉터리", "워크스페이스의 모든 하위 디렉터리" 및 "git 루트까지의 상위 디렉터리"에서 검색됩니다. 각 워크스페이스 규칙은 프런트매터(frontmatter)의 trigger field를 통해 활성화 모드를 선언합니다:

Copilot에서의 매핑은 거의 기계적으로 이루어집니다. 경로별 .instructions.md 파일은 glob 규칙이 되며, 패턴을 그대로 가져오면 됩니다. 리포지토리 전체 copilot-instructions.md 콘텐츠는 분할됩니다. 항상 적용되어야 하는 부분은 always_on이 되고, 상황에 따라 적용되는 부분은 model_decision이 됩니다. 개인 선호도는 글로벌 규칙 파일로 이동합니다.

고려해야 할 두 가지 제한 사항이 있습니다. "워크스페이스 규칙 파일은 각각 최대 12,000자까지 제한됩니다. 글로벌 규칙 파일은 최대 6,000자까지 제한됩니다." 그리고 이 글로벌 파일이 저장되는 위치를 확인해 두세요. 바로 memories 디렉터리 내부의 ~/.codeium/windsurf/memories/global_rules.md입니다. 이 때문에 많은 사람들이 자신에게 글로벌 규칙이 전혀 없다고 생각하곤 합니다.

글로벌 규칙 파일(global_rules.md)과 루트 수준의 AGENTS.md 파일은 프런트매터를 사용하지 않으며, 항상 활성화(always on) 상태입니다. 이것이 바로 서론에서 언급한 함정입니다. 여러분의 AGENTS.md는 Copilot에서 가장 우선순위가 낮은 리포지토리 지침이었지만, Devin에서는 무조건적으로 적용됩니다.

마지막으로, 마이그레이션 시도 자체를 재고하게 만드는 경고가 하나 있습니다. Devin Desktop의 memories 문서 첫머리에는 다음과 같이 적혀 있습니다. "Memories는 레거시 Cascade 에이전트에만 적용됩니다." 그리고 "새 탭의 기본 에이전트인 Devin Local 에이전트는 memories를 유지하지 않습니다." Copilot Memory를 Devin memories로 옮길 계획이었다면, 기본 에이전트에서는 해당 메모리가 유지되지 않습니다. 벤더 자체의 권장 사항은 다른 방향을 제시합니다. "Cascade가 안정적으로 재사용하기를 원하는 지식의 경우, 자동 생성된 Memories에 의존하기보다는 규칙(Rule)으로 작성하거나 리포지토리의 AGENTS.md에 추가하세요. 규칙은 버전 관리 및 팀원 간 공유가 가능하며, 활성화에 대한 명시적인 제어권을 제공합니다."

이 조언을 따르십시오. 마이그레이션된 Copilot Memory 사실들의 최종 목적지는 memory가 아니라 Rule이어야 합니다.

1단계와 2단계를 거치면 올바른 Devin 설정이 완료됩니다. 하지만 이 과정에서 6,000자의 글로벌 제한, 파일당 12,000자의 워크스페이스 제한이 주어지며, 프로젝트에 대해 알고 있는 모든 단일 정보에 대해 활성화 모드를 결정해야 하는 번거로움이 따릅니다.

활성화 모드는 규칙(규칙이란 어떻게 행동해야 하는가에 대한 지침)을 설계하는 데는 훌륭한 방식입니다. 하지만 사실(facts)을 다루기에는 적합하지 않습니다. "우리는 npm이 아니라 bun을 사용한다"는 트리거가 필요합니다. 반면 "결제 서비스는 티켓 4471에 문서화된 업스트림의 특이 사항 때문에 세 번 재시도한다"는 트리거가 필요하지 않습니다. 이 정보는 모든 메시지의 시스템 프롬프트를 낭비하지 않으면서, 관련이 있을 때 언제든 찾아낼 수 있어야 합니다.

이것이 바로 메모리 레이어가 채워주는 공백이며, 다음 마이그레이션 비용을 낮춰주는 요인입니다. MemoryLake은 세 단계로 설정할 수 있습니다.

1단계: API 키 생성하기

대시보드에 로그인하여 API 키를 생성합니다. 이 인증 정보는 Copilot이나 Devin이 아닌 팀에 귀속되므로, 자체적으로 메모리를 유지하지 않는 Devin Local 에이전트를 포함하여 어떤 에이전트에서도 저장소에 접근하여 읽을 수 있습니다.

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

이곳에 추출한 Copilot Memory 내용을 업로드합니다. 아키텍처 결정, 빌드 명령, 프로젝트별 규칙 및 그 이면의 이유와 같은 리포지토리 수준의 사실들을 입력합니다. 그다음 각 개인이 복구한 사용자 수준의 선호도와 기존에 GitHub.com의 Copilot Chat에만 도달했던 개인 지침들을 추가합니다.

실제 행동 규칙은 적절한 트리거와 함께 .devin/rules/에 두고, 항상 참인 규칙은 AGENTS.md에 유지하세요. 이러한 분리가 핵심입니다. 규칙은 글자 수 제한 내에 머물 수 있을 만큼 작게 유지되고, 사실 정보들은 더 이상 그 제한된 용량을 두고 경쟁하지 않게 됩니다.

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

Devin Desktop이 해당 저장소를 가리키도록 설정합니다. 저장소가 외부에 있기 때문에 현재 탭에서 Cascade를 실행 중이든 Devin Local 에이전트를 실행 중이든 상관없습니다. 이는 Devin의 memories 페이지 상단에 있는 경고에 대한 실질적인 해결책이 됩니다.

첫 번째 변화는 글자 수 제한이 더 이상 지식 설계의 제약 조건이 되지 않는다는 점입니다. 6,000자는 에이전트가 어떻게 행동해야 하는지 정의하기에는 합리적인 용량이지만, 에이전트가 무엇을 알아야 하는지 담기에는 턱없이 부족한 용량입니다.

두 번째는 사실 정보에 대해 활성화 모드 비용을 지불하지 않아도 된다는 점입니다. model_decision은 모든 메시지의 시스템 프롬프트에 설명을 포함하고 관련이 있어 보일 때 본문을 가져옵니다. 이는 규칙에는 합리적이지만, 개별적으로 설명해야 하는 수백 개의 도메인 사실 정보에는 매우 낭비적입니다.

세 번째는 Cascade와 Devin Local 간의 분리 문제가 더 이상 여러분의 고민거리가 되지 않는다는 점입니다. 벤더가 에이전트를 개편하더라도, 여러분이 커밋한 파일과 소유한 저장소는 모두 그대로 유지됩니다. 이미 이 방식을 도입한 팀들은 지식 베이스를 전혀 건드리지 않고도 Windsurf to Devin Desktop 리브랜딩 과정을 무사히 넘겼습니다.

• 무언가를 복사하기 전에 우선순위를 먼저 확인하세요. 특정 컨벤션이 두 개의 Copilot 레이어에 모두 존재했다면, 더 높은 순위의 레이어만 적용되고 있었습니다.
• Copilot Memory에 실제로 무엇이 들어있는지 먼저 확인하세요. 이는 Copilot 클라우드 에이전트, Copilot 코드 리뷰, Copilot CLI에만 적용되며 모든 영역에 적용되는 것은 아닙니다. 생각보다 옮길 내용이 적을 수 있습니다.
• 경로 패턴을 그대로 가져오세요. Copilot의 경로별 지침은 Devin의 glob 트리거에 깔끔하게 매핑됩니다.
• 활성화 모드를 신중하게 할당하세요. 모든 항목을 기본값인 always_on으로 설정하면 첫 번째 프롬프트를 입력하기도 전에 컨텍스트 창이 가득 차게 됩니다.
• memories 디렉터리 내부에서 global_rules.md를 찾으세요. 이 파일은 ~/.codeium/windsurf/memories/global_rules.md에 위치하며, 프런트매터 없이 항상 활성화됩니다.
• .windsurf/rules보다 .devin/rules를 우선적으로 사용하세요. 이것이 권장되는 위치이며 우선순위를 가집니다. 워크스페이스 루트에 있는 레거시 단일 파일 .windsurfrules도 여전히 읽히므로, 오래된 파일이라면 삭제하세요.
• 사실 정보를 자동 생성된 memories로 마이그레이션하지 마세요. Devin 자체 문서에서도 안정적으로 재사용하려는 모든 정보에 대해 규칙(Rules)이나 AGENTS.md를 사용할 것을 권장하며, 기본 에이전트는 메모리를 전혀 유지하지 않습니다.
• 일주일 후에 무엇이 유지되었는지 감사(Audit)해 보세요. 아무도 검증하지 않은 마이그레이션된 규칙 세트는 조용히 절반쯤 무시되기 마련입니다. 깨끗한 설정을 유지하기 위해 Auditing what your AI remembers를 실천하는 좋은 습관을 들이세요.

AGENTS.md 덕분에 이 마이그레이션이 아주 간단해 보이며, 실제로도 이 마이그레이션에서 가장 유용한 부분입니다. 나머지는 두 가지 서로 다른 철학 사이의 번역 작업입니다. Copilot은 지침 소스의 순위를 매겨 모델에 모두 전달하는 반면, Devin은 모든 규칙이 언제 로드될지 스스로 선언하도록 만듭니다.

우선순위를 눈앞에 두고 이 번역 작업을 신중하게 한 번 진행해 보세요. 그리고 결정 사항, 도메인 지식, 이유와 같은 사실 정보들은 각 항목마다 트리거를 일일이 선택할 필요가 없는 곳에 보관하세요.