Copilot Memory 끄기 버튼, 저장된 기억의 삭제 숙제

AI 요약

• 무슨 일: GitHub이 5월 26일 Copilot Memory에 삭제 안내, 저장 범위 표시, repository off switch, CLI 명령을 추가했습니다.
  • /memory on, /memory off, /memory show 선택은 Copilot CLI 세션 사이에 유지됩니다.
• 운영 포인트: repository-level off switch는 새 저장과 읽기를 멈추지만, 기존 저장 facts는 삭제하지 않습니다.
• 개발자 영향: 에이전트 기억은 편의 기능이 아니라 저장소 규칙, 사용자 취향, 삭제 정책이 만나는 거버넌스 표면입니다.
  • GitHub 문서 기준 사용되지 않은 기억은 28일 뒤 자동 삭제되지만, 검증되어 사용되면 timer가 reset될 수 있습니다.

GitHub은 2026년 5월 26일 Changelog에 Copilot Memory 제어 강화를 올렸습니다. 새 모델 출시나 IDE 화면 개편은 아닙니다. 변경점은 더 작고 실무적입니다. Copilot Memory가 무엇을 저장하는지 더 분명히 보여주고, repository 관리자가 저장소 단위로 끌 수 있게 만들고, Copilot CLI 안에서 memory 상태를 켜고 끄고 확인하는 명령을 붙였습니다.

이 뉴스가 AI 개발팀에 닿는 이유는 memory가 이제 "편하게 기억해 주는 기능"이 아니라 관리해야 할 상태가 됐기 때문입니다. GitHub 문서에서 Copilot Memory는 Copilot cloud agent, Copilot code review, Copilot CLI가 repository-level facts와 user-level preferences를 저장하고 다시 쓰는 기능입니다. 저장소의 build command, architectural decision, coding convention 같은 facts는 팀 전체 작업 품질에 영향을 줍니다. 특정 사용자의 선호나 말투는 그 사용자 경험에만 남아야 합니다. GitHub의 이번 변경은 이 두 범위를 UI와 CLI에서 더 노출하려는 조정입니다.

GitHub 발표에서 가장 눈에 띄는 문장은 repository-level off switch입니다. Repository admin은 기존 Copilot feature controls에서 Copilot Memory를 저장소 단위로 비활성화할 수 있습니다. 비활성화하면 repository-level facts는 더 이상 저장되거나 읽히지 않습니다. 그러나 GitHub은 같은 문장에서 preexisting facts are not deleted라고 못박았습니다. 즉 off switch는 수도꼭지를 잠그는 기능이지, 이미 저장된 물을 비우는 기능이 아닙니다.

이 차이는 작지 않습니다. 조직이 "이 저장소에서는 AI memory를 쓰지 않겠다"고 결정했을 때, 관리자는 새 저장 중단과 기존 기억 삭제를 별도 작업으로 봐야 합니다. GitHub Docs는 repository owner가 저장된 repository-level facts를 검토하고 삭제할 수 있다고 설명합니다. 삭제 화면에서 trashcan icon 또는 checkbox를 사용할 수 있고, 기억이 부정확하거나 부적절하거나 오해를 부를 때 지울 수 있습니다. 기능을 끄는 정책과 이미 저장된 상태를 청소하는 절차가 분리된 셈입니다.

저장 시점의 scope prompt도 같은 문제를 겨냥합니다. GitHub은 store_memory permission prompt가 새 memory entry가 user-level preference인지 repository-level fact인지 명시한다고 설명했습니다. 사용자에게 "이 내용을 기억해도 됩니까"라고 묻는 것만으로는 부족합니다. 개인 취향으로 저장되는지, 저장소 구성원 전체가 볼 수 있는 fact로 저장되는지, 다음 code review에서 적용될 수 있는지까지 드러나야 승인 판단이 가능합니다.

Copilot Memory의 구조를 보면 GitHub가 왜 범위를 분리하는지 알 수 있습니다. GitHub Docs는 repository-level facts를 citations와 함께 저장한다고 설명합니다. Copilot은 관련 fact를 찾으면 현재 branch에서 citation을 검증하고, 여전히 정확하다고 판단될 때만 사용합니다. 닫힌 pull request에서 나온 fact도 저장될 수 있지만, 현재 코드베이스가 그 정보를 뒷받침하지 않으면 Copilot 행동에는 반영되지 않는다는 설명도 붙어 있습니다.

이 설계는 에이전트 memory의 낙관과 위험을 동시에 보여줍니다. 낙관은 분명합니다. 저장소에 오래 머문 개발자가 README보다 더 많은 암묵지를 갖듯이, Copilot도 반복 작업에서 프로젝트 규칙을 배울 수 있습니다. 예를 들어 cloud agent가 데이터베이스 연결 규칙을 발견하면, code review가 나중에 다른 pull request에서 같은 규칙 위반을 찾을 수 있습니다. GitHub 문서는 이런 교차 적용을 Copilot Memory의 이점으로 제시합니다.

위험도 같은 위치에서 생깁니다. 저장소 지식이 틀리거나 오래되면, 에이전트는 틀린 규칙을 자연스럽게 적용할 수 있습니다. GitHub은 이를 줄이기 위해 citation validation과 28일 자동 삭제를 설명합니다. 사용되지 않은 repository-level facts와 user-level preferences는 stale information이 의사결정에 영향을 주지 않도록 28일 뒤 자동 삭제됩니다. 다만 timer는 Copilot이 entry를 성공적으로 검증하고 사용할 때 reset될 수 있습니다. 오래 쓰이는 기억은 오래 남을 수 있다는 뜻입니다.

28일이라는 숫자는 보존 정책처럼 보이지만, 팀 운영에서는 질문을 남깁니다. 어떤 기억이 "사용됐다"는 사건이 audit log에 어떻게 보이는지 확인해야 합니다. Repository owner가 memory list를 얼마나 자주 검토할지도 정해야 합니다. Build command처럼 안정적인 fact와 임시 migration workaround를 같은 보존 규칙으로 다룰지도 결정 대상입니다. GitHub 문서는 저장된 기억을 사용자가 보고 삭제할 수 있다고 설명하지만, 실제 조직 프로세스는 각 팀이 만들어야 합니다.

Copilot code review에서 user-level preferences가 적용되지 않는다는 제한도 주목할 만합니다. GitHub Docs는 Copilot Memory가 현재 Copilot cloud agent, Copilot code review, Copilot CLI에서 쓰인다고 설명합니다. 그중 code review는 repository-level facts만 사용하고 user-level preferences는 적용하지 않습니다. 이 구분은 타당합니다. Code review는 개인 취향보다 repository 규칙을 적용해야 합니다. 반대로 CLI 작업은 사용자의 선호를 반영할 여지가 더 큽니다.

CLI에 /memory 명령이 들어간 것도 작지만 실무적인 변화입니다. 터미널에서 장시간 에이전트를 돌리는 개발자는 GitHub 설정 페이지를 열지 않고도 현재 memory 상태를 확인하고 전환할 수 있습니다. /memory show는 상태 확인이고, /memory off는 이후 세션까지 이어지는 비활성화 선택입니다. GitHub 발표는 이 선택이 세션 사이에 유지된다고 적었습니다. 에이전트 작업이 한 번의 chat turn보다 길어지는 상황에서는 "이번 명령에서만 끈 것인지, 다음 세션에도 꺼지는지"가 실제 혼란 포인트가 됩니다.

커뮤니티 반응은 아직 크지 않습니다. Hacker News와 GeekNews에서는 이번 changelog만 따로 큰 토론이 잡히지 않았습니다. Reddit r/GithubCopilot의 changelog 공유 글에는 enterprise AI controls에서 memory를 껐는데 CLI가 enabled로 보인다는 짧은 지적이 있었습니다. 표본은 작지만 제품의 어려운 부분을 보여줍니다. Memory governance는 기능 설명만 맞으면 끝나지 않습니다. GitHub 설정, enterprise policy, repository setting, CLI 상태가 사용자의 머릿속에서 하나의 정책으로 읽혀야 합니다.

이 지점에서 Copilot Memory는 지난주 devlery가 다룬 오픈소스 agentmemory와 다른 질문을 냅니다. agentmemory는 여러 코딩 에이전트가 공유하는 로컬 기억 런타임과 hook surface가 주제였습니다. GitHub Copilot Memory는 vendor-managed memory입니다. 장점은 제품 깊숙한 곳의 cloud agent, code review, CLI가 같은 기억을 쓸 수 있다는 점입니다. 부담은 GitHub 계정, 조직 정책, 저장소 권한, 개인 선호가 한 제품 안에서 섞인다는 점입니다.

개발팀이 여기서 바로 확인할 항목은 네 가지입니다. 첫째, 우리 조직에서 Copilot Memory가 기본적으로 켜지는 plan과 계정 유형이 무엇인지 봐야 합니다. GitHub Docs는 Copilot Pro, Pro+, Max 사용자의 Memory가 기본 활성화될 수 있고, enterprise와 organization-managed subscription에서는 admin이 켜야 한다고 설명합니다. 둘째, repository-level facts를 누가 검토하고 삭제할지 정해야 합니다. 저장소 owner만 기능을 알고 있으면 code review와 cloud agent 사용자에게 영향을 설명하기 어렵습니다.

셋째, project rules를 memory에 맡길지 문서에 둘지 구분해야 합니다. 반복되는 convention은 memory에 잘 맞을 수 있습니다. 반대로 보안 정책, compliance rule, 배포 금지선처럼 명시적 승인과 리뷰가 필요한 내용은 repository 문서와 policy로 남겨야 합니다. Copilot Memory는 custom instructions를 완전히 대체하는 기능이라기보다, 반복 작업에서 생기는 repository facts를 보조하는 층에 가깝습니다.

넷째, offboarding과 incident 대응 절차에 memory를 넣어야 합니다. 민감한 내부 규칙이나 잘못된 임시 결론이 repository-level fact로 저장됐을 때 누가 삭제하는지, user-level preference에 민감한 user quote가 남았을 때 사용자가 어디서 지우는지, memory를 끄는 것과 삭제하는 것의 차이를 support runbook에 적어야 합니다. GitHub이 이번에 deletion guidance를 개선했다는 사실은 사용자들이 "잊어 달라"고 말한 뒤 실제 삭제 위치를 찾는 데 어려움이 있었다는 반증이기도 합니다.

이번 업데이트를 과장해서 볼 필요는 없습니다. Copilot Memory는 아직 public preview이고, GitHub도 더 많은 feature로 확장할 계획이라고만 밝혔습니다. 하지만 방향은 선명합니다. 코딩 에이전트는 점점 stateless autocomplete가 아니라 저장소를 배우는 장기 도구가 됩니다. 그 순간 memory는 context window 절약이 아니라 팀 지식의 저장, 적용, 삭제 문제로 바뀝니다.

GitHub의 5월 26일 변경은 거대한 출시가 아니라 작은 제어면 추가입니다. 그 작은 면이 중요한 이유는 AI 코딩 도구가 팀 안에서 점점 오래 머물기 때문입니다. 좋은 memory는 같은 설명을 반복하지 않게 해 줍니다. 나쁜 memory는 오래된 결정과 잘못된 규칙을 자동화합니다. Copilot Memory의 새 off switch, scope prompt, CLI 명령은 이 차이를 사용자가 직접 다루기 시작했다는 신호입니다.