28일 뒤 사라지는 기억, Copilot 메모리 통제의 새 단위

GitHub Copilot Memory 업데이트는 코딩 에이전트의 장기 기억을 저장소, 사용자, CLI, 삭제 정책으로 나누기 시작했습니다.

AI 요약

무슨 일: GitHub이 Copilot Memory에 삭제 안내, 저장소 off switch, CLI 제어, 저장 범위 표시를 추가했습니다.
- 공식 발표일은 2026년 5월 26일이고, 기능은 공개 프리뷰 상태입니다.
의미: 코딩 에이전트의 장기 문맥이 편의 기능을 넘어 관리자 정책의 대상이 됐습니다.
실무 영향: 팀은 저장소 facts, 개인 preferences, CLI 상태, 28일 만료를 나눠 운영해야 합니다.
- 기존 저장소 facts는 off switch만으로 자동 삭제되지 않는다는 점이 특히 중요합니다.

GitHub Copilot이 이제 "무엇을 기억할 수 있는가"를 더 명시적으로 묻기 시작했습니다. GitHub은 2026년 5월 26일 Changelog에서 Copilot Memory 공개 프리뷰에 네 가지 제어 장치를 추가했다고 발표했습니다. 사용자가 무언가를 잊으라고 요청했을 때 올바른 삭제 위치를 안내하고, 저장소 관리자가 저장소 단위로 Memory를 끌 수 있으며, Copilot CLI에서 /memory 명령으로 상태를 제어하고, 저장 시점의 permission prompt가 user-level preference인지 repository-level fact인지 보여주는 변화입니다.

겉보기에는 작은 품질 개선처럼 보입니다. 하지만 코딩 에이전트의 흐름에서는 작지 않습니다. 에이전트가 저장소를 읽고, 리뷰 코멘트를 남기고, CLI에서 명령을 제안하고, cloud agent로 PR을 만드는 순간 장기 문맥은 생산성 기능이자 위험 표면이 됩니다. 잘 저장된 memory는 반복 설명을 줄입니다. 잘못 저장된 memory는 오래된 규칙을 되살리거나, 팀의 의도와 다른 가정을 강화하거나, 저장소 밖으로 퍼지면 안 되는 맥락을 사용 범위 밖으로 밀어낼 수 있습니다.

최근 devlery가 다룬 GitHub Copilot targeted model rules는 어떤 조직이 어떤 모델을 쓸 수 있는가의 문제였습니다. 이번 Copilot Memory 업데이트는 다른 축입니다. 모델 선택이 비용과 성능의 정책표라면, memory scope는 에이전트가 무엇을 장기 문맥으로 삼을 수 있는가의 정책표입니다. 코딩 에이전트가 개인 도구에서 조직 인프라로 이동할수록 이 두 축은 함께 중요해집니다.

Copilot Memory가 기억하는 두 종류

GitHub Docs는 Copilot Memory를 Copilot cloud agent, Copilot code review, Copilot CLI가 더 효과적으로 일하도록 코드베이스와 개인 선호를 학습하는 기능으로 설명합니다. 여기서 핵심은 memory가 하나의 덩어리가 아니라는 점입니다. GitHub은 이번 문서에서 저장소 수준 facts와 사용자 수준 preferences를 구분합니다.

저장소 수준 fact는 특정 repository에 붙는 기억입니다. 예를 들어 프로젝트가 어떤 테스트 명령을 쓰는지, 어떤 디렉터리에 생성 코드를 두지 않는지, 어떤 내부 convention을 따르는지 같은 내용이 될 수 있습니다. 이 memory는 저장소에 기여하는 여러 사람에게 영향을 줄 수 있습니다. 그래서 repository owner가 review, delete, off switch를 가져야 합니다.

사용자 수준 preference는 개인에게 붙는 기억입니다. 예를 들어 어떤 개발자가 답변 형식, 설명 깊이, 선호하는 workflow를 지정하는 식입니다. GitHub Docs는 개인 Copilot Pro 또는 Pro+ 사용자의 Copilot Memory가 기본 활성화라고 설명합니다. 반면 enterprise와 organization-managed Copilot 구독에서는 기본 비활성화이고, enterprise 또는 organization 설정에서 켜야 합니다. 사용자가 여러 조직에서 Copilot 구독을 받는 경우에는 가장 제한적인 설정이 적용됩니다.

이 구분이 중요한 이유는 memory의 가치와 위험이 범위에 따라 달라지기 때문입니다. 개인 preference는 한 사용자의 생산성을 높일 수 있지만, 저장소 fact는 팀 전체의 에이전트 행동을 바꿉니다. 한 개발자가 임시로 남긴 추정이 repository-level fact로 저장되면, 다른 기여자에게도 영향을 줄 수 있습니다. 반대로 중요한 저장소 규칙이 개인 preference에만 남으면 팀 차원의 일관성을 만들기 어렵습니다. 이번 업데이트의 store_memory prompt가 저장 범위를 더 명확히 표시하는 것은 그래서 단순 UI 개선이 아닙니다.

GitHub Docs의 Copilot repository memory list 예시

잊어달라는 말과 실제 삭제는 다릅니다

AI 제품에서 "forget this"는 직관적인 명령입니다. 하지만 운영 관점에서는 모호합니다. 어떤 memory를 지우라는 것인지, user-level preference인지 repository-level fact인지, 현재 채팅의 임시 문맥인지, 장기 저장소에 들어간 항목인지가 다릅니다. GitHub의 이번 변경은 이 차이를 인정합니다. Copilot에게 무언가를 잊으라고 요청하면 이제 올바른 삭제 위치를 안내하고, voting이 가능한 곳에서는 해당 memory를 down-vote합니다.

이 대목은 에이전트 제품이 UX 문구만으로 governance를 해결할 수 없다는 사실을 보여줍니다. 사용자는 자연어로 "기억하지 마"라고 말할 수 있습니다. 그러나 장기 memory 시스템은 저장 위치, 소유자, 삭제 권한, 만료 정책을 따로 갖습니다. 말 한마디로 모든 계층이 즉시 삭제된다고 가정하면 감사와 복구가 어려워집니다. 반대로 사용자가 자연어로 삭제 의도를 밝혔는데도 실제 삭제 경로를 찾지 못하면 신뢰가 깨집니다.

GitHub Docs는 저장소 facts와 사용자 preferences를 직접 삭제할 수 있다고 설명합니다. 저장소 owner는 repository settings에서 Copilot Memory 목록을 보고 부적절하거나 잘못된 항목을 삭제할 수 있습니다. 개인 사용자는 personal Copilot settings에서 user-level preferences를 볼 수 있습니다. 또 두 종류의 memory는 28일 뒤 자동 삭제됩니다. 이 28일 만료는 오래된 정보가 에이전트 판단에 계속 영향을 주는 문제를 줄이기 위한 장치입니다.

다만 28일 만료가 모든 문제의 답은 아닙니다. 28일은 충분히 긴 기간입니다. 에이전트가 잘못된 fact를 저장하고 그 fact가 반복 작업에 영향을 준다면, 한 달 가까운 기간 동안 품질 문제를 만들 수 있습니다. 특히 저장소 구조가 빠르게 바뀌는 팀에서는 stale memory가 실제 코드보다 뒤처질 수 있습니다. GitHub은 memory를 사용하기 전에 검증한다고 설명하지만, 모든 조직은 자기 프로젝트의 변화 속도와 위험 수준에 맞춰 삭제와 review 루틴을 가져야 합니다.

저장소 off switch가 의미하는 것

이번 업데이트에서 가장 운영적인 기능은 repository-level off switch입니다. GitHub Changelog에 따르면 repository admin은 repository settings의 기존 Copilot feature controls에서 Copilot Memory를 끌 수 있습니다. 이 경우 repository-level facts는 더 이상 저장되거나 읽히지 않습니다. 하지만 이미 저장된 facts는 삭제되지 않습니다. user-level preferences도 영향을 받지 않습니다.

이 문장은 짧지만 중요합니다. off switch는 사용 중단 장치이지 데이터 삭제 장치가 아닙니다. 저장소 단위로 Memory를 끄면 앞으로 해당 저장소 facts를 저장하거나 읽지 않게 되지만, 과거에 저장된 facts를 지우려면 별도 삭제가 필요합니다. 보안팀이나 플랫폼팀이 기능을 끌 때 "꺼졌으니 끝"이라고 생각하면 안 됩니다. 끄기, 조회, 삭제, 재활성화 시 영향 확인이 서로 다른 작업입니다.

이 구조는 다른 개발 인프라와 비슷합니다. CI secret을 비활성화하는 것과 secret 값을 삭제하는 것은 다릅니다. feature flag를 끄는 것과 데이터베이스에 남은 상태를 지우는 것도 다릅니다. Copilot Memory 역시 운영 인프라가 되면 같은 구분이 필요합니다. 특히 AI memory는 사람이 직접 읽지 않은 텍스트 조각이 에이전트의 다음 행동에 영향을 줄 수 있다는 점에서 더 신중해야 합니다.

저장소 off switch는 조직별 정책과도 연결됩니다. 어떤 저장소는 에이전트 memory가 큰 도움이 됩니다. 오래된 monorepo, 복잡한 테스트 명령, 특이한 배포 convention이 있는 프로젝트에서는 반복 설명을 줄일 수 있습니다. 반대로 고객별 민감 코드, 규제 대상 코드, 보안 연구 코드, 임시 migration 저장소에서는 memory를 최소화하고 싶을 수 있습니다. enterprise 또는 organization 차원의 전체 정책만으로는 이런 차이를 다루기 어렵습니다. 저장소 단위 switch는 실제 위험 단위에 더 가깝습니다.

범위	누가 관리하나	이번 업데이트의 의미
User preference	개인 사용자	개인 설정에서 조회와 삭제, 조직 정책의 제한 적용
Repository fact	저장소 owner/admin	저장소 설정에서 조회, 삭제, off switch 가능
CLI state	CLI 사용자와 조직 정책	`/memory on`, `/memory off`, `/memory show`가 세션을 넘어 유지
Retention	GitHub Memory 정책	repository facts와 user preferences가 28일 뒤 자동 삭제

CLI까지 내려온 memory 제어

Copilot Memory가 CLI까지 내려온 점도 눈여겨볼 부분입니다. GitHub Changelog는 Copilot CLI에서 /memory on, /memory off, /memory show를 사용할 수 있고 선택이 세션을 넘어 유지된다고 설명합니다. CLI는 IDE와 다르게 더 직접적인 실행 표면입니다. 파일을 읽고, 명령을 제안하고, 로컬 개발 환경에서 작업을 이어가는 접점입니다. 이 표면에서 memory가 켜져 있는지 확인하고 끄는 명령이 필요해지는 것은 자연스러운 변화입니다.

CLI의 memory 제어는 개발자 경험과 운영 정책 사이에 놓입니다. 개발자는 현재 세션에서 memory가 사용되는지 빠르게 확인하고 싶습니다. 조직은 enterprise AI controls에서 허용 여부를 통제하고 싶습니다. 이 둘이 어긋나면 혼란이 생깁니다. Reddit r/GithubCopilot에는 이번 업데이트 링크 아래에서 CLI가 enterprise AI controls에서 비활성화된 조직 설정과 다르게 enabled로 표시된다는 초기 피드백이 올라왔습니다. 표본이 작고 공식 확인된 버그는 아니므로 과장할 수는 없지만, 이런 종류의 피드백은 memory 기능의 핵심 위험을 잘 보여줍니다. 사용자가 보는 상태와 관리자가 의도한 상태가 같아야 합니다.

AI coding CLI는 점점 더 많은 작업을 맡습니다. 단순 질문 답변이 아니라 repository 탐색, 계획 작성, 코드 수정, 테스트 실행, PR 준비까지 연결됩니다. 이때 memory 상태는 디버깅 정보입니다. 에이전트가 왜 특정 규칙을 따랐는지, 왜 특정 명령을 기본값으로 썼는지, 왜 특정 디렉터리를 피했는지 설명하려면 memory가 개입했는지 알아야 합니다. /memory show 같은 명령은 편의 기능이 아니라 agent observability의 작은 단위로 봐야 합니다.

GitHub Docs의 Copilot user memory list 예시

장기기억은 생산성 기능이면서 보안 표면입니다

Copilot Memory의 장점은 분명합니다. 에이전트에게 매번 같은 배경을 설명하지 않아도 됩니다. 테스트 명령, 코드 스타일, 금지된 패턴, preferred library, 내부 naming convention을 기억하면 agent task의 성공률이 올라갈 수 있습니다. 특히 cloud agent와 code review에서는 반복되는 저장소 맥락을 기억하는 것이 비용과 시간을 줄일 수 있습니다. 모든 작업마다 저장소를 처음부터 다시 학습하는 것은 비효율적입니다.

하지만 장기기억은 공격 표면이기도 합니다. prompt injection 논의에서 자주 등장하는 문제는 외부 문서나 이슈, README, 웹 페이지가 에이전트에게 잘못된 지시를 주는 상황입니다. memory가 여기에 더해지면 문제는 길어집니다. 한 번 저장된 잘못된 fact가 여러 세션에 영향을 줄 수 있기 때문입니다. 저장소에 일시적으로 존재했던 문구, 실험 중인 branch의 임시 규칙, 악의적인 PR 설명이 memory 후보가 되지 않도록 검증과 승인 UX가 필요합니다.

GitHub은 store_memory permission prompt가 저장 범위를 명확히 표시한다고 밝혔습니다. 이 변화는 매우 실용적입니다. 사용자가 승인하는 순간 그 memory가 개인에게만 영향을 주는지, 저장소 기여자 전체에게 영향을 줄 수 있는지 알아야 합니다. 같은 문장이라도 scope가 다르면 의미가 달라집니다. "테스트는 항상 pnpm으로 실행한다"는 개인 preference일 수도 있고, 저장소 fact일 수도 있습니다. 후자라면 repository owner의 통제가 필요합니다.

또 하나의 위험은 오래된 memory입니다. GitHub Docs는 28일 자동 삭제를 둡니다. 이는 stale context를 줄이는 장치입니다. 그러나 실무에서는 28일보다 짧은 수명도 필요할 수 있습니다. 대규모 migration, dependency 전환, build system 변경, secret rotation처럼 단기간에 규칙이 바뀌는 작업에서는 memory review가 더 촘촘해야 합니다. 반대로 아주 안정적인 저장소 convention은 28일마다 사라지는 것이 불편할 수 있습니다. 이 tension은 앞으로 memory 제품이 더 세밀한 retention과 pinning을 요구받을 가능성을 보여줍니다.

GitHub이 유리한 이유는 저장소 권한을 이미 갖고 있기 때문입니다

Copilot Memory는 순수한 모델 기능이 아닙니다. 모델이 좋아진다고 자동으로 해결되는 문제도 아닙니다. 저장소 권한, 조직 정책, 사용자 설정, CLI 상태, code review workflow가 엮여야 합니다. GitHub이 이 분야에서 유리한 이유는 이미 repository와 organization의 권한 모델을 갖고 있기 때문입니다.

코딩 에이전트의 memory는 코드와 가까워야 합니다. 저장소 owner가 볼 수 있어야 하고, repository settings에 붙어야 하며, 조직 정책의 제한을 받아야 합니다. GitHub은 이 인프라를 새로 만들 필요가 없습니다. 이미 branch protection, Actions secrets, code owners, Copilot policies, enterprise AI controls가 있는 위치에 memory controls를 붙이면 됩니다. 이것은 독립 AI coding tool이 흉내 내기 어려운 장점입니다.

반대로 이 장점은 책임도 만듭니다. GitHub의 memory가 저장소 fact로 자리 잡으면, 개발자는 그것을 "GitHub이 관리하는 사실"처럼 받아들일 수 있습니다. UI가 보여주는 scope, 삭제 가능성, 만료 정책, 관리자 override가 명확해야 합니다. 잘못된 memory 때문에 agent가 반복적으로 나쁜 제안을 한다면, 사용자는 모델만 탓하지 않을 것입니다. memory 관리 경험 전체를 문제로 볼 것입니다.

팀이 지금 점검할 것

이번 업데이트를 보는 팀은 먼저 Copilot Memory가 어디에서 켜져 있는지 확인해야 합니다. 개인 Pro/Pro+ 사용자는 기본 활성화일 수 있고, enterprise/organization-managed 구독은 기본 비활성화일 수 있습니다. 여러 조직에서 라이선스를 받는 사용자는 가장 제한적인 설정을 따른다는 점도 확인해야 합니다. 정책 문서와 실제 CLI 표시가 일치하는지도 봐야 합니다.

두 번째는 저장소 단위 기준입니다. 모든 repository에 Memory를 같은 방식으로 허용할 필요는 없습니다. 내부 도구 저장소, 고객별 저장소, 보안 민감 저장소, 오픈소스 저장소, 빠르게 변하는 migration 저장소는 서로 다른 기준을 가질 수 있습니다. 저장소 off switch는 이런 차이를 표현하는 첫 단계입니다. 다만 off switch가 기존 facts를 삭제하지 않는다는 점을 운영 절차에 넣어야 합니다.

세 번째는 memory review 루틴입니다. 저장소 owner가 memory 목록을 정기적으로 보며 부정확하거나 오래된 facts를 지우는 절차가 필요합니다. 특히 agent가 실패한 작업을 분석할 때 memory가 영향을 줬는지 확인해야 합니다. 실패 원인을 모델 성능, tool permission, 테스트 환경, memory contamination으로 나눠 볼 수 있어야 합니다. 그래야 에이전트 품질 개선이 감으로 흐르지 않습니다.

네 번째는 개발자 교육입니다. 개발자는 store_memory permission prompt에서 scope를 읽어야 합니다. 개인 preference로 남겨야 할 내용을 repository fact로 승인하지 않아야 하고, 팀 규칙으로 공유해야 할 내용이 개인 설정에만 갇히지 않도록 해야 합니다. CLI 사용자는 /memory show로 현재 상태를 확인하는 습관을 들이는 것이 좋습니다.

결론

Copilot Memory 업데이트는 화려한 제품 발표가 아닙니다. 새 모델도 아니고, 새 agent demo도 아닙니다. 그러나 코딩 에이전트가 실제 개발 조직에 들어갈 때 이런 변화가 더 오래 남습니다. 에이전트가 잘 일하려면 기억해야 합니다. 동시에 조직은 무엇을 기억하게 할지, 누가 지울 수 있는지, 어떤 범위로 적용할지, 언제 만료되는지 알아야 합니다.

GitHub이 이번에 추가한 삭제 안내, 저장소 off switch, CLI /memory 명령, scope 표시, 28일 만료 문서는 모두 같은 방향을 가리킵니다. 장기기억은 더 이상 채팅 UX의 부속 기능이 아닙니다. 코딩 에이전트 운영에서 memory는 모델, 권한, 비용, 감사와 나란히 놓이는 제어 단위가 되고 있습니다.

지난 몇 달 동안 AI coding news는 더 강한 모델, 더 빠른 agent, 더 큰 context window에 집중했습니다. 이제 다음 질문이 등장합니다. 에이전트가 오래 일할수록 무엇을 오래 기억하게 둘 것인가. GitHub Copilot Memory의 이번 업데이트는 그 질문에 대한 초기 답입니다. 답은 완전 자동화가 아니라 scope, 삭제, off switch, CLI 상태, 만료 시간을 사용자가 볼 수 있게 만드는 쪽으로 가고 있습니다.