GitHub Copilot Memory 업데이트: 삭제·저장 범위·CLI 명령어, 어디까지 통제할 수 있나

 

GitHub Copilot Memory 업데이트: AI가 기억하는 정보, 어디까지 통제할 수 있나

삭제 안내, 저장소 단위 끄기, Copilot CLI /memory 명령어를 팀 운영 기준으로 읽어봅니다.

 

GitHub Copilot Memory 업데이트: 삭제, 저장 범위, CLI 제어가 바뀐 이유

 

2026년 5월 26일 GitHub는 Copilot Memory에 삭제 안내, 저장소 단위 off switch, Copilot CLI /memory 명령, 캡처 시점의 사용자/저장소 범위 표시를 추가했습니다. AI 코딩 도구가 무엇을 기억하는지 개인과 팀이 더 명확히 확인하고 제어하도록 만든 변화입니다.

GitHub Copilot을 업무에 붙여 쓰다 보면 가장 애매한 질문이 하나 남습니다. AI가 내 취향이나 저장소 규칙을 기억한다면, 그 정보는 어디에 저장되고 누가 다시 쓰게 되는가입니다.

이번 GitHub Copilot Memory 삭제 저장 범위 CLI 명령어 업데이트는 그 질문에 정면으로 붙어 있습니다. GitHub는 2026년 5월 26일 changelog에서 Copilot Memory의 삭제 안내, 저장소 단위 비활성화, Copilot CLI의 `/memory on`, `/memory off`, `/memory show`, 그리고 memory 캡처 시점의 범위 표시를 공개했습니다.

다만 이 업데이트를 개인정보 보호가 완전히 해결됐다는 뜻으로 읽으면 위험합니다. 제가 보기에는 이 변화의 실무적 의미는 더 좁고 분명합니다. Copilot Memory를 켤지 말지 결정하기 전에, 개인 선호와 저장소 단위 facts를 구분할 수 있는 운영 장치가 늘었다는 쪽에 가깝습니다.

한국 개발자와 팀 리드라면 지금 볼 부분은 세 가지입니다. Copilot Memory가 무엇을 저장하는지, 저장소별로 끄면 기존 정보도 사라지는지, CLI에서는 어떤 순서로 확인해야 하는지입니다.

 

 

Copilot Memory 타임라인: 3월 기본 활성화부터 5월 제어 강화까지

 

Copilot Memory는 2026년 3월 Pro와 Pro+ 개인 사용자 공개 프리뷰 기본 활성화 이후, 5월 26일 삭제와 범위 제어가 강화됐습니다. 같은 흐름에서 Copilot CLI changelog에는 memory permission prompt의 범위 표시 개선도 기록됐습니다.

날짜로 놓고 보면 이번 업데이트의 성격이 조금 더 선명합니다.

날짜	변화	독자가 봐야 할 의미
2026-03-04	개인 GitHub Copilot Pro, Pro+ 사용자 대상으로 Copilot Memory 공개 프리뷰 기본 활성화 공지	개인 계정에서는 Memory가 실험 기능이 아니라 실제 사용 흐름에 들어오기 시작함
2026-05-24	Copilot CLI changelog에 memory permission prompt의 범위 표시 개선 기록	CLI에서 저장되는 정보가 사용자 범위인지 저장소 범위인지 더 잘 드러나야 하는 요구가 반영됨
2026-05-26	삭제 안내, repository off switch, `/memory` 명령, 캡처 범위 표시 발표	기업 개발팀이 민감하게 보는 제어와 운영 문제가 업데이트의 중심이 됨

한국 사용자 입장에서는 3월의 기본 활성화보다 5월 26일 업데이트가 더 현실적인 체크포인트입니다. AI가 반복 맥락을 기억해 생산성을 올리는 기능은 매력적이지만, 회사 저장소에서는 잘못 저장된 규칙이나 민감한 프로젝트 맥락이 팀 전체에 영향을 줄 수 있기 때문입니다.

그래서 기준을 기능 소개에 두지 않으려고 합니다. GitHub Copilot Memory 삭제 저장 범위 CLI 명령어를 각각 따로 떼어 보고, 어떤 설정은 개인이 바꿀 수 있고 어떤 설정은 저장소 소유자나 조직 관리자가 봐야 하는지 구분합니다.

 

무엇이 바뀌었나: 삭제 안내, 저장소 off switch, /memory 명령어

 

2026년 5월 26일 변경점은 기억 삭제 요청 시 올바른 삭제 위치 안내, repository admin용 저장소 단위 비활성화, Copilot CLI의 /memory on/off/show, memory 캡처 시 범위 표시입니다. 특히 저장소 단위 off는 기존 facts 자동 삭제가 아니라 이후 저장과 읽기를 막는 제어로 봐야 합니다.

가장 먼저 나눠야 할 것은 삭제와 끄기입니다. 사용자가 Copilot에게 어떤 내용을 잊으라고 요청하면, GitHub는 해당 memory를 제거할 수 있는 위치로 안내하도록 바뀌었다고 설명합니다. 투표 기능이 있는 표면에서는 해당 memory에 down-vote도 적용됩니다.

반면 저장소 단위 off switch는 다른 성격입니다. repository admin은 Repository Settings > Copilot > Memory 또는 기존 Copilot feature controls에서 특정 저장소의 Memory를 끌 수 있습니다. 이 설정을 끄면 저장소 수준 facts를 더 이상 저장하거나 읽지 않는 방향으로 동작하지만, GitHub는 기존 repository facts가 자동 삭제되는 것은 아니라고 밝힙니다.

Copilot CLI 쪽 변화도 실무에 직접 닿습니다. `/memory show`는 현재 상태 확인에, `/memory off`는 CLI에서 Memory 사용을 끄는 데, `/memory on`은 허용된 정책 안에서 다시 켜는 데 쓰입니다. 선택은 CLI 세션을 넘어 유지된다고 공지됐습니다.

> 실무에서 제일 중요한 문장은 “끄면 끝”이 아니라 “끄기, 삭제, 자동 만료는 서로 다르다”입니다.

따라서 GitHub Copilot Memory 삭제 저장 범위 CLI 명령어를 검색한 독자라면, 먼저 자신이 해결하려는 문제가 무엇인지 구분해야 합니다. 잘못된 memory를 지우려는 것인지, 특정 저장소에서 앞으로 저장을 막으려는 것인지, 터미널에서 현재 CLI 상태를 확인하려는 것인지가 각각 다릅니다.

 

 

왜 중요한가: 개인 선호와 팀 지식은 저장 범위가 다르다

 

사용자 단위 preference는 개인의 선호로 취급되지만, 저장소 단위 fact는 repository contributors가 함께 쓰는 팀 맥락이 될 수 있습니다. 그래서 Copilot Memory는 편의 기능이면서 동시에 권한, 공유 범위, 오래된 맥락 관리 문제와 연결됩니다.

GitHub Docs는 Copilot Memory가 크게 두 종류의 정보를 다룬다고 설명합니다. 하나는 저장소 단위 facts입니다. 예를 들면 코딩 컨벤션, 아키텍처 결정, 빌드 명령, 프로젝트별 규칙 같은 정보입니다. 다른 하나는 사용자 단위 preferences입니다. 개인이 선호하는 응답 스타일이나 반복적으로 쓰는 작업 방식에 가까운 정보입니다.

이 차이는 사소하지 않습니다. 사용자 단위 preference는 개인의 Copilot 경험에 붙는 반면, 저장소 단위 fact는 같은 repository의 contributor들이 함께 영향을 받을 수 있는 팀 맥락입니다. 잘 관리되면 반복 설명을 줄이지만, 오래된 빌드 명령이나 임시 실험 규칙이 저장되면 오히려 혼란을 만듭니다.

Docs는 repository-level facts가 supporting code citation과 함께 저장되고, Copilot이 관련 fact를 쓰기 전에 현재 branch와 citation을 확인한다고 설명합니다. 또 사용되지 않은 facts나 preferences는 28일 뒤 자동 삭제될 수 있고, 검증과 사용 과정에서 타이머가 다시 시작될 수 있다고 안내합니다.

실제로 확인할 부분은 여기입니다. 자동 삭제가 있다고 해서 모든 위험이 사라지는 것은 아닙니다. 저장소별 off switch가 기존 facts를 지우는 것도 아닙니다. 팀에서는 “무엇이 저장됐는지 보는 사람”, “틀린 facts를 삭제하는 사람”, “정책상 켜도 되는 저장소를 정하는 사람”을 구분해야 합니다.

 

도입 시뮬레이션: 설치, 첫 테스트, 운영 모델

 

첫 테스트는 Copilot CLI 설치 후 저장소 안에서 copilot을 실행하고 /memory show로 상태를 확인하는 흐름이 적절합니다. 팀 도입은 repository owner의 웹 설정 검토, 조직 정책 확인, .github/copilot-instructions.md 같은 명시적 지침과의 역할 분리까지 포함해야 합니다.

실무에서는 이 업데이트를 작은 도입 시뮬레이션으로 보는 편이 더 유용합니다. 터미널에서 Copilot CLI를 쓰는 개발자라면 GitHub Copilot Memory 삭제 저장 범위 CLI 명령어를 바로 확인할 수 있습니다.

개인 실험은 작게 시작하면 됩니다.

1. Node.js 22 이상 환경이라면 `npm install -g @github/copilot`로 Copilot CLI를 설치합니다. macOS나 Linux에서는 `brew install copilot-cli`, Windows에서는 `winget install GitHub.Copilot` 경로도 공식 문서에 있습니다.
2. 확인할 권한이 있는 GitHub 저장소에서 `copilot`을 실행합니다. 인증이 필요하면 `/login`으로 로그인합니다.
3. interactive session에서 `/memory show`로 현재 Memory 상태를 먼저 봅니다.
4. 터미널 작업에서 Memory를 끄고 싶다면 `/memory off`, 다시 켜려면 `/memory on`을 사용합니다. 단, 조직이나 엔터프라이즈 정책이 막고 있으면 CLI 명령만으로 우회할 수 있다고 보면 안 됩니다.

팀 테스트는 순서가 조금 다릅니다. repository owner가 Repository Settings > Copilot > Memory에서 저장된 repository-level facts를 확인하고, 틀렸거나 오래된 facts를 삭제할 수 있는지 봐야 합니다. 개인 사용자는 자신의 Copilot Memory settings에서 user-level preferences를 확인하고 삭제하는 경로를 따로 봐야 합니다.

제가 보기에는 `.github/copilot-instructions.md`와 Memory를 섞어 쓰는 기준도 필요합니다. version control에 남겨야 하는 빌드 정책, 보안 규칙, 리뷰 기준은 명시적 instruction 파일이나 문서에 두는 편이 낫습니다. Copilot Memory는 반복적으로 드러나는 저장소 facts를 줄이는 보조 장치로 보고, 영구 정책 저장소처럼 쓰지 않는 쪽이 안전합니다.

 

 

 

Copilot CLI, code review, cloud agent에서 Memory는 같지 않다

 

Copilot Memory는 Copilot cloud agent, Copilot code review, Copilot CLI에서 쓰일 수 있지만 표면별 제한이 다릅니다. 특히 code review는 repository-level facts만 사용하고, CLI는 시작한 사용자 기준의 facts와 preferences 적용으로 봐야 합니다.

여기서 자주 생기는 오해가 있습니다. “Copilot Memory가 켜져 있다”는 말만으로 모든 Copilot 기능이 같은 방식으로 같은 정보를 쓴다고 보면 안 됩니다.

GitHub Docs는 Copilot Memory가 cloud agent, code review, Copilot CLI에서 쓰인다고 설명하지만, 기능별 한계도 함께 제시합니다. code review는 repository-level facts를 사용하는 쪽으로 제한됩니다. CLI는 명령을 시작한 사용자 기준으로 저장된 facts와 preferences가 적용되는 맥락으로 이해하는 편이 안전합니다.

간단히 나누면 다음과 같습니다.

사용 표면	확인할 점	실무 의미
Copilot CLI	`/memory show/off/on`, 로컬 설정과 로그, 사용자 기준 상태	개인 터미널 작업에서 먼저 실험하기 좋음
Copilot code review	repository-level facts 중심	반복 리뷰 규칙에는 유용하지만 user preference까지 기대하면 안 됨
Copilot cloud agent	저장소 맥락 재사용 가능성	agent 작업 전에 저장된 facts가 오래됐는지 확인 필요

따라서 기업 개발팀은 “우리 팀 Copilot Memory를 켜자”가 아니라 “어느 표면에서, 어떤 범위의 memory를, 누가 검토할 것인가”로 질문을 바꿔야 합니다. 이 질문이 정리되지 않으면 GitHub Copilot Memory 삭제 저장 범위 CLI 명령어를 알아도 운영상 혼선이 남습니다.

 

주의할 점: 끄기, 삭제, 자동 만료를 섞어 말하면 안 된다

 

저장소 단위 Memory를 끄는 것, 저장된 fact를 삭제하는 것, 사용되지 않은 항목이 28일 뒤 자동 삭제되는 것은 서로 다른 동작입니다. 민감한 저장소, client-confidential context, 임시 실험 규칙이 많은 저장소는 프리뷰 단계에서 보류하거나 엄격히 관리하는 편이 낫습니다.

다만 여기서 조심할 점은 분명합니다. Memory 제어가 늘었다고 해서 민감 정보 관리가 자동으로 해결되는 것은 아닙니다. GitHub가 제공한 것은 더 나은 삭제 안내, 범위 표시, 저장소 단위 off, CLI 제어이지, 모든 조직 리스크를 없애는 보증이 아닙니다.

특히 다음 조건에서는 도입을 늦추는 쪽이 합리적입니다.

• 고객사 기밀, 법무 검토 대상, 짧은 기간만 유효한 실험 규칙이 저장소에 자주 등장하는 경우
• repository contributors 사이의 접근 경계가 아직 정리되지 않은 경우
• Copilot Business 또는 Enterprise 정책을 누가 관리하는지 불명확한 경우
• code review에서만 쓰려는데 user-level preferences까지 반영될 것이라고 기대하는 경우
• Memory를 `.github/copilot-instructions.md`나 팀 표준 문서의 대체재로 쓰려는 경우

반대로 안정적인 build command, 반복되는 code review rule, 오래 유지되는 architecture decision이 있는 저장소라면 테스트할 만합니다. 단, repository owner가 저장된 facts를 주기적으로 확인하고 오래된 항목을 삭제하는 운영 루틴이 있어야 합니다.

이 업데이트의 좋은 점은 AI가 기억하는 내용을 완전히 믿으라는 메시지가 아니라, 기억의 범위를 더 잘 보라고 요구한다는 데 있습니다. 개인 블로그 독자에게는 그 차이가 더 중요합니다. 편의성보다 먼저 봐야 할 것은 “이 memory가 나만의 취향인지, 저장소 contributor에게 공유될 팀 지식인지”입니다.

 

 

 

한국 개발팀을 위한 한 줄 판단

 

GitHub Copilot Memory는 반복되는 저장소 맥락을 줄이는 데 유용하지만, 도입 판단은 기능 편의보다 삭제 경로, 저장 범위, CLI 상태 확인, 조직 정책이 정리됐는지로 해야 합니다.

개인 개발자라면 Copilot CLI에서 `/memory show`를 먼저 실행해 현재 상태를 확인하는 것으로 충분히 시작할 수 있습니다. 유료 Copilot 플랜을 쓰고 있고 정책상 허용된다면 `/memory off`와 `/memory on`으로 터미널 작업에서의 사용감을 비교해보면 됩니다.

팀이라면 질문이 조금 더 무겁습니다. repository owner가 Memory 설정과 저장된 facts를 볼 수 있는지, 조직 또는 엔터프라이즈 정책에서 허용되어 있는지, code review와 cloud agent에서 어떤 memory가 실제로 쓰이는지 확인해야 합니다.

GitHub Copilot Memory 삭제 저장 범위 CLI 명령어 업데이트는 Copilot이 더 많은 것을 기억하게 만드는 뉴스라기보다, 기억을 관리하는 표면을 넓힌 업데이트에 가깝습니다. 그래서 제가 내리는 결론은 간단합니다. 안정적인 저장소 규칙이 있고 리뷰할 사람이 있는 팀은 작게 실험해볼 만하지만, 민감한 맥락이 많은 저장소는 아직 보수적으로 접근하는 편이 낫습니다.

 

자주 묻는 질문

 

Q. GitHub Copilot Memory는 어떤 정보를 저장하나요?
A. GitHub Docs 기준으로 Copilot Memory는 저장소 단위 facts와 사용자 단위 preferences를 다룹니다. 저장소 단위 facts에는 코딩 컨벤션, 아키텍처 결정, 빌드 명령, 프로젝트별 규칙 같은 팀 맥락이 포함될 수 있습니다.

Q. 저장소별로 Copilot Memory를 끄면 기존 메모리도 삭제되나요?
A. 아닙니다. 2026년 5월 26일 GitHub Changelog는 저장소 단위 off switch가 이후 repository-level facts를 저장하거나 읽지 않게 하지만, 기존 facts를 자동 삭제하지는 않는다고 설명합니다.

Q. Copilot CLI에서 /memory on, /memory off, /memory show는 어떻게 쓰나요?
A. Copilot CLI interactive session에서 /memory show는 현재 상태 확인, /memory off는 CLI의 Memory 사용 중지, /memory on은 허용된 정책 안에서 다시 켜는 명령으로 이해하면 됩니다. 먼저 /memory show로 확인한 뒤 off/on을 테스트하는 순서가 안전합니다.

Q. Copilot Memory는 무료 Copilot 사용자도 사용할 수 있나요?
A. 이 글의 근거가 되는 2026년 5월 26일 changelog는 Copilot Memory가 공개 프리뷰이며 유료 Copilot 플랜 사용자를 대상으로 한다고 설명합니다. 무료 사용자도 모두 가능하다고 단정하면 안 됩니다.

Q. Copilot code review, cloud agent, CLI에서 Memory가 똑같이 적용되나요?
A. 똑같다고 보면 안 됩니다. GitHub Docs는 Copilot Memory가 cloud agent, code review, Copilot CLI에서 쓰일 수 있다고 설명하지만, code review는 repository-level facts만 사용하고 CLI는 시작한 사용자 기준의 facts와 preferences 적용으로 제한됩니다.

Q. 회사에서 Copilot Memory를 켜기 전에 무엇을 확인해야 하나요?
A. 조직 또는 엔터프라이즈 Copilot 정책, repository owner의 Memory 설정 접근 권한, 저장된 repository facts의 검토와 삭제 루틴, 민감 저장소 제외 기준을 먼저 확인해야 합니다. 둘 이상의 조직에서 Copilot을 받는 사용자는 가장 제한적인 정책이 적용될 수 있습니다.

Q. Copilot Memory와 .github/copilot-instructions.md는 어떻게 함께 써야 하나요?
A. 오래 유지되어야 하는 팀 표준, 보안 규칙, 리뷰 기준은 .github/copilot-instructions.md나 문서처럼 version control에 남기는 편이 좋습니다. Copilot Memory는 반복적으로 학습되는 저장소 facts를 줄이는 보조 장치로 두는 쪽이 운영상 더 명확합니다.

함께 읽으면 좋은 글

 

• OpenAI Agents SDK 업데이트 핵심: 장기 실행 AI 에이전트는 어떻게 복구하고 확장할까 — AI UPDATES
• Claude 에이전트 보안 설계: Anthropic이 말한 샌드박스와 egress control — AI UPDATES
• Gemini Interactions API 변경: steps 스키마 전환 체크리스트 — AI UPDATES

참조 링크

 

• Copilot Memory has more controls for deletion, scope, and the Copilot CLI — 2026년 5월 26일 Copilot Memory 삭제, 저장 범위, Copilot CLI /memory 명령어 업데이트의 원문입니다.
• About GitHub Copilot Memory — Copilot Memory가 저장하는 정보 유형, 적용 표면, citation 검증, 28일 자동 삭제 조건을 확인한 공식 문서입니다.
• Managing and curating Copilot Memory — 개인, 저장소, 조직, 엔터프라이즈 수준의 Memory 관리와 삭제 경로를 확인한 공식 문서입니다.
• Installing GitHub Copilot CLI — Copilot CLI 설치 경로와 Node.js 요구사항을 확인한 공식 문서입니다.
• GitHub Copilot CLI — Copilot CLI의 공식 GitHub 저장소로, CLI 제품 맥락과 릴리스 활동을 확인하는 보조 근거입니다.
• copilot-cli changelog.md — 2026년 5월 24일 memory permission prompt의 범위 표시 개선 흐름을 확인한 changelog입니다.
• Copilot Memory now on by default for Pro and Pro+ users in public preview — Copilot Memory 공개 프리뷰와 개인 Pro, Pro+ 기본 활성화 흐름을 설명하는 이전 공식 업데이트입니다.