Copilot Memory 끄기 버튼, 에이전트 기억의 권한 문제

AI 요약

• 무슨 일: GitHub가 2026년 5월 26일 Copilot Memory에 삭제 안내와 저장소 단위 off switch를 추가했습니다.
  • Copilot CLI에는 /memory on, /memory off, /memory show가 들어갔고 선택은 세션을 넘어 유지됩니다.
• 범위: 저장 시점 prompt가 user-level preference와 repository-level fact를 구분해 보여줍니다.
• 주의점: 저장소에서 Memory를 꺼도 기존 facts는 자동 삭제되지 않고, 개인 preferences는 영향을 받지 않습니다.

GitHub가 2026년 5월 26일 Changelog에서 Copilot Memory 제어 업데이트를 공개했습니다. 발표 문장은 짧습니다. 삭제 안내가 개선됐고, repository-level off switch가 생겼고, Copilot CLI에 /memory 명령이 들어갔습니다. 개발자가 봐야 할 부분은 기능 이름보다 경계입니다. 코딩 에이전트가 저장소의 관례와 개인 취향을 오래 기억한다면, 그 기억을 누가 보고, 끄고, 삭제하고, 어떤 세션에 다시 주입할지 정하는 제어판이 제품의 본체가 됩니다.

이번 업데이트는 새 모델 출시나 benchmark 발표가 아닙니다. GitHub가 이미 public preview로 운영 중인 Copilot Memory의 운영 surface를 고친 사건입니다. Changelog 기준 Copilot Memory는 모든 유료 Copilot plan에서 public preview로 제공됩니다. GitHub Docs는 이 기능이 repository-level facts와 user-level preferences를 저장하고, Copilot cloud agent, Copilot code review, Copilot CLI가 더 효과적으로 동작하도록 돕는다고 설명합니다. 사람이 README, coding conventions, architecture docs를 읽고 저장소에 적응하듯, Copilot도 작업 중 발견한 사실을 다음 작업에 가져오려는 설계입니다.

GitHub의 memory 실험은 2026년 1월 15일 public preview에서 시작됐습니다. 당시 발표는 Copilot coding agent, Copilot CLI, Copilot code review가 repository-specific memory를 공유한다고 설명했습니다. 한 feature가 배운 convention이 다른 feature의 review에도 영향을 줄 수 있다는 뜻입니다. 2026년 3월 4일에는 Copilot Pro와 Pro+ 사용자를 대상으로 Memory가 기본 활성화됐고, 5월 15일에는 Pro와 Pro+ 사용자에게 user-level preferences early access가 추가됐습니다. 5월 26일 업데이트는 이 세 단계 뒤에 나온 제어 보강입니다.

GitHub가 새로 넣은 첫 번째 장치는 삭제 안내입니다. 사용자가 Copilot에게 어떤 내용을 잊으라고 요청하면, Copilot은 이제 해당 memory를 제거할 수 있는 올바른 위치를 안내하고 voting이 가능한 surface에서는 그 memory를 down-vote한다고 밝혔습니다. 이 설명은 자동 삭제를 약속하지 않습니다. 사용자가 말로 “잊어”라고 입력했을 때 실제 삭제가 어느 설정 화면에서 일어나는지 연결하는 제품 동작에 가깝습니다. 팀이 민감한 convention, 내부 path, 고객명, 임시 migration 규칙을 잘못 저장했을 때 중요한 차이입니다.

두 번째 장치는 repository-level off switch입니다. repository admin은 기존 repository settings의 Copilot feature controls에서 Copilot Memory를 끌 수 있습니다. GitHub 설명에 따르면 이 경우 repository-level facts는 더 이상 저장되거나 읽히지 않습니다. 그러나 preexisting facts는 삭제되지 않습니다. user-level preferences도 영향을 받지 않습니다. 따라서 “저장소에서 껐다”는 말은 앞으로의 repository facts read/write를 막는다는 뜻이지, 이미 저장된 모든 기억과 개인 취향까지 한 번에 지운다는 뜻이 아닙니다.

세 번째 장치는 Copilot CLI의 /memory 명령입니다. GitHub는 /memory on, /memory off, /memory show를 제시했습니다. 사용자는 CLI 안에서 Memory 사용 여부를 켜고 끄고 확인할 수 있으며, 선택은 session을 넘어 유지됩니다. 터미널 기반 코딩 에이전트에서 이 제어는 생각보다 큽니다. IDE 설정 화면을 열지 않고도 현재 agent session이 저장소 지식을 장기 기억으로 읽고 쓰는지 확인할 수 있기 때문입니다.

네 번째 장치는 저장 시점 scope 표시입니다. store_memory permission prompt는 이제 항목이 user-level preference인지 repository-level fact인지 명시합니다. user-level preference는 개인에게만 보이고 여러 repository session에서 쓰이는 취향입니다. repository-level fact는 repository contributor에게 보이는 저장소 사실입니다. 한 문장으로 보이면 단순한 UI 개선 같지만, agent memory에서는 이 구분이 권한 모델입니다. “저는 테스트를 먼저 보고 싶습니다”와 “이 repository는 결제 코드를 packages/billing에 둡니다”는 저장 위치와 노출 대상이 달라야 합니다.

Docs의 retention 설명도 같이 봐야 합니다. GitHub는 저장된 fact나 preference가 사용되지 않으면 28일 뒤 자동 삭제된다고 설명합니다. 이 숫자는 memory가 영구 지식베이스가 아니라는 신호입니다. 그러나 28일 expiration은 모든 governance 질문을 닫지 않습니다. 잘못 저장된 기억이 다음 PR review나 CLI session에 바로 영향을 줄 수 있고, 사용된 memory는 stale 여부 검증이 필요합니다. GitHub는 repository facts가 current codebase에 대해 검증된다고 설명하지만, 어떤 검증 실패가 사용자에게 어떻게 노출되는지는 제품 surface마다 확인해야 합니다.

이번 사건의 실무 가치는 “기억이 생겼다”가 아니라 “기억의 scope가 화면에 드러났다”에 있습니다. 코딩 에이전트가 한 번의 session에서 끝날 때는 prompt, diff, 로그만 보면 됩니다. 여러 session을 건너뛰며 기억을 재사용하면 검토 대상이 늘어납니다. 저장된 fact의 출처, 생성 권한, 읽기 권한, 삭제 권한, 만료 조건, 사용자별 취향과 팀 지식의 충돌이 review checklist에 들어옵니다. GitHub가 store_memory prompt에서 user preference와 repository fact를 나누는 이유도 여기 있습니다.

기업 팀에서는 repository-level off switch의 범위가 구매 검토 항목이 됩니다. 보안팀은 “Memory를 끌 수 있는가”보다 “끈 뒤 기존 facts가 어떻게 남는가”를 물어야 합니다. Changelog는 repository-level off switch가 preexisting facts를 삭제하지 않는다고 적었습니다. 따라서 민감한 저장소에서 Memory를 끄는 절차는 두 단계여야 합니다. 먼저 feature를 끄고, Repository Settings의 Copilot Memory 영역에서 이미 저장된 facts를 검토하거나 삭제해야 합니다. 개인 preferences가 별도 범위라는 점도 계정 관리 문서에 들어가야 합니다.

개발자 개인에게는 Copilot CLI의 /memory show가 작은 안전장치입니다. terminal agent가 갑자기 repository convention을 너무 잘 안다면, 그것이 현재 파일 탐색에서 온 것인지, 저장된 memory에서 온 것인지 확인할 필요가 있습니다. /memory off는 민감한 작업, customer-specific branch, 보안 패치, 라이선스 검토 같은 session에서 쓰일 수 있습니다. 다만 CLI 토글이 모든 Copilot surface의 조직 정책을 대체한다고 해석하면 안 됩니다. GitHub 설명은 Copilot CLI 안에서의 memory controls와 repository settings의 관리 surface를 나눠 제시합니다.

커뮤니티 반응은 기능 자체보다 저장 위치와 교정 가능성에 집중돼 왔습니다. Reddit의 GitHub Copilot 관련 토론에서는 “memory가 어디 저장되는가”, “잘못 추론한 repository 지식을 어떻게 고치는가”, “AGENTS.md나 .github/copilot-instructions.md처럼 파일로 명시한 context와 제품 내 memory를 어떻게 나눌 것인가”라는 질문이 반복됩니다. 긍정적 기대는 반복 설명을 줄이고 code review와 CLI가 같은 repository 지식을 공유한다는 데 있습니다. 우려는 portability, auditability, hidden prompt처럼 보이는 UI 혼란, organization 밖 저장소 지원 범위에 모입니다.

GitHub의 답은 파일 기반 memory와 다릅니다. AGENTS.md, README, docs, .github/copilot-instructions.md는 repository에 남고 Git review를 받습니다. Copilot Memory는 제품 설정과 permission prompt를 통해 만들어지는 동적 상태입니다. 파일은 명시적이고 이식성이 좋지만 stale 문서가 되기 쉽습니다. 제품 memory는 agent가 작업 중 발견한 사실을 빠르게 재사용할 수 있지만, 저장과 삭제의 책임이 설정 화면과 계정 권한으로 이동합니다. 5월 26일 업데이트는 이 둘 중 하나를 폐기하는 발표가 아니라, 제품 memory 쪽에 필요한 제어를 보강한 발표입니다.

도입 checklist는 간단하게 시작할 수 있습니다. 첫째, repository owner가 현재 저장된 facts를 볼 수 있는지 확인합니다. 둘째, 민감 저장소에서 Memory를 기본으로 켤지 opt-in으로 둘지 정합니다. 셋째, 개인 preferences가 팀 convention과 충돌할 때 review 기준을 어디에 둘지 문서화합니다. 넷째, 보안 패치나 고객 데이터가 들어간 branch에서는 CLI에서 /memory show를 먼저 확인하는 습관을 넣습니다. 이 네 가지는 모델 성능 평가와 별개로, agent가 다음 작업에 가져갈 상태를 관리하는 최소 절차입니다.

경쟁 축도 모델 이름에서 멀어집니다. Copilot, Codex, Claude Code, Cursor, Gemini 계열 도구가 모두 “프로젝트를 기억하는 방법”을 갖추려 합니다. 어떤 도구는 instruction file을 읽고, 어떤 도구는 session history를 저장하고, 어떤 도구는 repository fact를 별도 memory로 유지합니다. 팀이 비교해야 할 항목은 답변 품질만이 아닙니다. 기억이 user-scoped인지 repository-scoped인지, citation이 남는지, admin이 끌 수 있는지, CLI에서 확인 가능한지, retention이 명시됐는지가 도입 기준이 됩니다.

GitHub의 Copilot Memory는 아직 public preview입니다. GitHub Docs도 preview 기능이며 변경될 수 있다고 명시합니다. user-level preferences는 현재 Copilot Pro와 Pro+ 사용자 대상으로만 설명됩니다. enterprise와 organization 환경에서는 policy, repository settings, paid plan, Copilot feature availability가 섞입니다. 따라서 팀 단위로 적용할 때는 “우리 organization 전체에서 켜져 있는가”, “repository owner가 facts를 볼 수 있는가”, “개별 개발자가 /memory off를 썼을 때 어떤 surface에만 적용되는가”를 실제 계정으로 확인해야 합니다.

이번 Changelog를 작게 보면 Copilot 설정 메뉴가 하나 늘어난 일입니다. 그러나 코딩 에이전트를 장기 작업자로 쓰는 팀에는 더 직접적인 질문입니다. 에이전트가 PR 하나를 넘어서 다음 달의 review와 CLI session까지 저장소 지식을 가져간다면, memory는 productivity feature와 governance feature를 동시에 갖습니다. GitHub가 deletion guidance, repository off switch, CLI commands, scope prompt를 같은 발표에 묶은 이유도 이 지점에 있습니다. 에이전트가 기억하는 시대의 기본 UI는 “더 똑똑해졌다”가 아니라 “무엇을 기억했고 누가 지울 수 있는가”여야 합니다.