개인 및 조직 라이선스 간 GitHub Copilot Memory 관리 방법 (2026년 가이드)

Copilot Memory는 두 가지 종류의 정보를 저장합니다. 저장소 수준의 사실(Repository-level facts)은 "코딩 컨벤션, 아키텍처 결정, 빌드 명령 및 프로젝트별 규칙"을 다룹니다. 사용자 수준의 선호도(User-level preferences)는 "사용자가 Copilot과 상호작용하고자 하는 방식에 대한 암묵적 또는 명시적인 개인적 선호도"를 의미합니다.

이 두 가지는 범위(scope)가 다릅니다.

저장소 사실은 저장소에 귀속됩니다. GitHub은 "해당 사실은 동일한 저장소에서의 작업에만 사용할 수 있으며", "Copilot Memory가 활성화된 저장소에 대한 쓰기 권한이 있는 사용자의 작업에 반응하여서만 생성된다"고 설명합니다. 해당 저장소에서 Copilot Memory에 액세스할 수 있는 사람은 누구나 이 혜택을 누릴 수 있습니다. 또한 사용 전에 검증을 거칩니다. "저장소 수준의 사실은 이를 뒷받침하는 코드를 가리키는 인용구와 함께 저장되며", 관련성이 있어 보일 때 Copilot은 현재 브랜치와 비교하여 해당 인용구를 확인합니다. "검증된 사실만 사용됩니다."

사용자 선호도는 사용자를 따라다니지만, 소유자가 지정되어 있습니다. 핵심 문구는 다음과 같습니다. "선호도는 라이선스를 부여한 조직 또는 엔터프라이즈인 청구 주체(billing entity)에 귀속됩니다." 선호도가 생성되면 "사용자의 현재 사용에 대한 활성 청구 주체에 저장됩니다." 그리고 Copilot이 세션의 컨텍스트를 빌드할 때 "사용자의 현재 활성 청구 주체를 다시 확인하고 해당 청구 주체가 소유한 메모리만 검색합니다."

따라서 고용주로부터 라이선스를 부여받은 동안 Copilot이 학습한 선호도는 고용주의 조직 또는 엔터프라이즈에 귀속됩니다. 다른 라이선스로 작업할 때는 Copilot이 해당 라이선스에 귀속된 선호도를 대신 검색합니다.

둘 이상의 액세스 소스가 있는 경우 추가 요구 사항이 있습니다. "여러 엔터프라이즈 또는 조직을 통해 Copilot 액세스 권한을 받는 경우, Copilot Memory로 사용자 수준의 선호도를 생성하려면 반드시 기본 청구 주체를 선택해야 합니다." 이 기본 설정에 따라 귀하를 위해 생성된 선호도를 관리하고 삭제할 수 있는 계정이 결정됩니다.

소유권은 관리자에게도 실질적인 영향을 미칩니다. Business 및 Enterprise 요금제에서 사용자 수준의 선호도는 "조직 또는 엔터프라이즈 관리자가 조회하고 삭제할 수 있습니다." GitHub의 관리자 가이드에 따르면 관리자는 "조직을 활성 청구 주체로 하여 생성된 모든 사용자 수준의 선호도를 JSONL 형식으로 내보내거나 삭제할 수 있습니다." 이러한 작업은 기록됩니다. "관리자가 메모리를 내보내거나 삭제할 때, 그리고 사용자가 Copilot Memory를 옵트아웃할 때 조직 또는 엔터프라이즈의 감사 로그에 이벤트가 표시됩니다."

유지되는 정보를 결정하는 두 가지 규칙이 더 있습니다. 가용성은 요금제에 따라 다릅니다. 개인 요금제의 경우 Copilot Memory가 기본적으로 켜져 있는 반면, "엔터프라이즈 및 조직에서 관리하는 Copilot 구독의 경우 Copilot Memory는 기본적으로 꺼져 있으며 엔터프라이즈 또는 조직 설정에서 활성화해야 합니다." 또한 메모리는 만료됩니다. "사용되지 않는 저장된 사실이나 선호도는 28일 후에 자동으로 삭제됩니다." Copilot Memory는 현재 공개 프리뷰 상태이므로 세부 사항은 변경될 수 있습니다.

Copilot Memory가 개인당 하나의 메모리라고 가정하는 것. 실제로는 청구 주체당 하나의 선호도 세트입니다. 개인 요금제와 회사 라이선스는 각각 자체 메모리를 가집니다.

기본 청구 주체를 선택하지 않는 것. 두 곳 이상에서 액세스 권한을 받는 경우, GitHub은 사용자 수준의 선호도를 생성하기 전에 기본 청구 주체를 설정하도록 요구합니다. Memory 페이지에 선호도가 전혀 표시되지 않는다면 이 부분을 가장 먼저 확인해야 합니다.

코드 리뷰에 선호도가 반영되기를 기대하는 것. GitHub은 "Copilot 코드 리뷰는 저장소 수준의 사실만 사용합니다. 코드 리뷰 중에는 사용자 수준의 선호도가 적용되지 않습니다"라고 명시하고 있습니다. CLI는 다릅니다. "Copilot CLI는 저장소 수준의 사실과 작업을 시작한 사용자의 사용자 수준 선호도를 모두 적용합니다."

팀에 필요한 규칙을 메모리에만 의존하는 것. 저장소 사실은 유용하지만, Copilot이 추론하는 것이며 사용되지 않으면 만료됩니다. 팀 규칙은 Copilot이 지침 파일을 확인하는 순서에서 설명하듯이 지침 파일에 명시해야 합니다.

Copilot Memory를 VS Code의 로컬 메모리 도구와 혼동하는 것. 이 둘은 저장소와 수명이 서로 다른 별개의 기능이며, VS Code에서 Copilot memory 설정하기에서 자세히 다룹니다.

1단계: 현재 내 선호도를 소유한 청구 주체 확인하기

GitHub에서 Copilot 설정을 열고 Memory로 이동합니다. GitHub은 "사용자는 개인 설정에서 저장된 모든 선호도와 해당 소유자를 볼 수 있다"고 설명합니다. 목록을 살펴보며 각 선호도의 소유자를 기록해 두세요. 또한 "사용자는 Copilot 요금제에 관계없이 자신의 사용자 수준 선호도를 조회하고 삭제할 수 있으므로", 오래된 항목은 이 기회에 정리하는 것이 좋습니다.

두 곳 이상에서 Copilot을 제공받는 경우, Copilot 기능 설정으로 이동하여 기본 청구 주체를 선택하세요. 주로 작업할 때 사용하는 계정을 선택하는 것이 좋습니다. GitHub은 액세스 권한이 여러 곳에서 제공될 때 사용자 수준의 선호도를 생성하기 위한 조건으로 이 선택을 요구합니다.

설정 페이지에 머무는 동안 Copilot Memory가 활성화되어 있는지도 확인하세요. 조직 관리 요금제에서는 관리자가 먼저 정책을 활성화해야 하며, 그 이후에 사용자가 개별적으로 옵트인되거나 옵트아웃할 수 있습니다. GitHub은 조직 또는 엔터프라이즈가 기능을 켜기 전까지는 조직 관리 구독에서 이 기능이 꺼져 있는 것으로 설명하므로, 작업 세션에 메모리가 표시되지 않는다면 관리자에게 문의하세요.

마지막으로, 나에게 중요한 선호도 목록을 작성해 보세요. 어떤 라이선스 하에서든 Copilot이 알았으면 하는 코딩 스타일 선택, 리뷰 습관, 워크플로우 세부 사항 등이 이에 해당합니다.

2단계: 팀 지식은 저장소에 두고, 개인 선호도는 나만의 언어로 기록하기

두 가지 종류의 컨텍스트를 분리하고, 각각의 소유자에 맞는 보관처를 지정하세요.

팀 지식은 저장소에 귀속됩니다. 컨벤션, 아키텍처 결정, 빌드 명령 및 프로젝트 규칙은 .github/copilot-instructions.md, 경로별 지침 파일 또는 AGENTS.md에 위치해야 합니다. Copilot Memory의 저장소 사실이 이를 보완할 수는 있지만, 서면 지침은 28일 동안 사용하지 않아도 만료되지 않으며 Copilot이 올바르게 추론하는지에 의존하지도 않습니다. Copilot이 저장한 저장소 사실이 유용하다면, 이를 참고하여 규칙을 직접 문서화하세요. Copilot이 코드베이스의 구조를 계속 놓치는 경우, GitHub Copilot이 코드베이스 컨텍스트를 잊어버리는 이유에서 더 광범위한 해결책을 다룹니다.

개인 선호도는 직접 다시 작성하면 됩니다. 코드 구조화 방식, 명명 규칙, 테스트 선호도, 설명 방식 등 나만의 언어로 짧은 목록을 작성해 보세요. 이는 고용주의 청구 주체 아래에 저장된 내용을 복사하는 것이 아니라, 나 자신에 대한 설명입니다. 어떤 라이선스 하에서든 Copilot에게 이러한 사항을 알려주면 다시 학습할 수 있습니다.

두 영역 사이의 경계에 주의하세요. 고용주의 라이선스 하에서 생성된 선호도는 고용주에게 소유권이 있으며, 관리자가 이를 내보내거나 삭제할 수 있습니다. 이를 회사 데이터로 취급해야 합니다. 필요한 내용이 있다면 관리자에게 요청하고, 직접 복사하려고 시도하지 마세요.

3단계: 라이선스 변경이 발생하기 전에 미리 준비하기

이직, 팀의 엔터프라이즈 계정 이전, 개인 요금제 추가 또는 취소 등 라이선스 변경은 예측 가능합니다. 이에 대비해 계획을 세우세요.

조직을 떠나기 전에, 내가 기여한 팀 컨텍스트가 메모리에만 남아 있지 않고 저장소 지침 파일에 반영되어 있는지 확인하세요. 저장소 사실은 저장소에 남지만 만료될 수 있으며, 서면 지침은 다음 사람도 지식을 계속 활용할 수 있도록 보장합니다. 이러한 인수인계의 더 넓은 범위는 팀원이 떠날 때 AI 컨텍스트를 유지하는 방법에서 다룹니다.

새로운 라이선스로 시작할 때는 초기 세션에서 Copilot에게 개인 선호도 목록을 미리 알려주세요. Copilot이 스스로 추론할 때까지 기다리기보다 직접 알려주고, 일주일 후에 Memory 설정 페이지를 확인하여 무엇이 저장되었고 소유자가 누구인지 확인하세요.

개인 요금제와 회사 라이선스를 병행하여 사용하는 경우, 어떤 작업을 할 때 어떤 라이선스를 사용할지 의식적으로 구분하세요. GitHub은 각 선호도가 생성될 당시 활성화되어 있던 청구 주체에 이를 저장하므로, Copilot이 중요한 내용을 학습할 때 어떤 라이선스를 사용 중인지 유의해야 합니다.

이 해결책은 팀 규칙을 저장소에 보관하고 개인 선호도를 나만의 언어로 기록하는 방식입니다. 하지만 여러 프로젝트에 걸쳐 내린 결정, 컨벤션의 배경이 되는 이유, 다루는 모든 코드베이스에 적용되는 교훈 등 두 영역 사이에 존재하면서 라이선스보다 오래 지속되는 컨텍스트도 있습니다. MemoryLake는 Copilot 비용을 누가 지불하든 상관없이 이 레이어를 독립적으로 유지할 수 있는 공간입니다.

항목은 나만의 언어로 직접 작성합니다. Copilot Memory, 저장소 또는 타사 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않습니다. 고용주의 코드나 결정에 관한 내용을 추가하기 전에 조직의 정책을 확인하세요.

1단계: API 키 생성하기

로그인한 후 대시보드에서 키를 생성합니다. 이 키는 GitHub 조직이나 라이선스와는 별개로 귀하의 MemoryLake 워크스페이스에 귀속됩니다.

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

2단계에서 작성한 개인 목록과 모든 세션에서 활용하고 싶은 프로젝트 간 공통 이유부터 시작하세요. 항목당 하나의 선호도 또는 결정을 날짜와 함께 기록합니다.

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

Copilot 및 사용하는 다른 코딩 에이전트를 연결합니다. 이제 어떤 라이선스나 도구로 작업하든 귀하의 선호도를 사용할 수 있습니다.

첫 번째 변화는 사라진 선호도가 더 이상 미스터리가 아니라는 점입니다. 어떤 청구 주체가 어떤 메모리를 소유하고 있는지, 그리고 왜 특정 라이선스 하에서의 세션이 다른 라이선스에서 학습한 내용을 보여주지 않는지 명확히 이해하게 됩니다.

두 번째는 팀 지식이 인원 교체 시에도 유지된다는 점입니다. 규칙이 모든 Copilot 환경에서 읽을 수 있는 지침 파일에 저장되므로, 28일의 만료 기한은 물론 이를 처음 설명했던 사람보다 더 오래 지속됩니다. 터미널에서 이러한 파일이 로드되는 방식은 Copilot CLI 지침 연결하기를 참조하세요.

세 번째는 이직을 하더라도 처음부터 다시 시작할 필요가 없다는 점입니다. 직접 작성해 둔 선호도 덕분에 한두 세션 만에 새로운 Copilot을 원하는 대로 설정할 수 있습니다.

네 번째는 회사 컨텍스트와 개인 컨텍스트 간의 명확한 구분입니다. 회사 소유의 선호도는 관리자의 통제 하에 회사에 그대로 남고, 이동 가능한 지식은 귀하가 직접 작성한 내용으로 유지됩니다.

기본 청구 주체 설정하기. 두 곳 이상에서 액세스 권한을 받는 경우 필수 사항입니다.

Memory 설정에서 소유자 확인하기. 각 선호도마다 소유자가 표시됩니다.

팀 규칙은 지침 파일에 작성하기. 메모리는 추론에 의존하며 사용하지 않으면 만료됩니다.

개인 선호도는 나만의 언어로 다시 작성하기. 목록을 짧고 최신 상태로 유지하세요.

고용주 소유의 메모리는 회사 데이터로 취급하기. 직접 복사하기보다 관리자에게 요청하세요.

각 메모리가 적용되는 위치 기억하기. 코드 리뷰는 저장소 사실만 사용하며, CLI는 둘 다 사용합니다.

다른 컨텍스트 소스도 활용하기. 최신 상태를 유지하는 Copilot Space 구축하기에서 보여주듯이, 잘 관리된 공간은 메모리가 담지 못하는 프로젝트 지식을 전달할 수 있습니다. 도구를 이전하는 팀은 Copilot에서 Codex로 마이그레이션하기에서 접근 방식을 비교해 볼 수 있습니다.

GitHub Copilot Memory는 저장소에 남는 저장소 사실과 라이선스를 부여한 조직 또는 엔터프라이즈에 귀속되는 개인 선호도를 저장합니다. Copilot은 현재 청구 주체가 소유한 선호도만 검색하며, 관리자는 조직 소유의 선호도를 내보내거나 삭제할 수 있고, 사용되지 않는 메모리는 28일 후에 만료됩니다.

이러한 설계는 조직 관점에서는 합리적이지만, 사용자의 Copilot 메모리가 하나로 연속되지 않음을 의미합니다. 기본 청구 주체를 선택하고, 소유권을 확인하고, 팀 규칙은 지침 파일에 작성하고, 개인 선호도는 나만의 언어로 기록해 두세요.

이렇게 준비하면 라이선스가 변경되더라도 처음부터 다시 시작하는 대신 가벼운 재소개 세션 정도로 충분할 것입니다.