Copilot Memory가 사용자를 기억하기 시작했다

AI 요약

• 무슨 일: GitHub이 Copilot Memory에 user-level preferences를 추가했습니다.
  • Copilot Pro와 Pro+ 사용자는 커밋 스타일, PR 구조, 말투 같은 개인 선호를 Copilot 경험 전반에서 유지할 수 있습니다.
• 의미: 코딩 에이전트의 경쟁축이 답변 품질에서 지속 컨텍스트, 작업 습관, 에이전트 신뢰 관리로 이동하고 있습니다.
• 실무 영향: 개인 선호는 반복 프롬프트를 줄이지만, 조직에서는 저장 범위·삭제 권한·검증 가능한 memory 정책을 함께 봐야 합니다.
• 주의점: 공식 문서 기준 기능은 public preview이며, user-level preferences는 현재 Pro/Pro+에만 제한됩니다.

GitHub이 2026년 5월 15일 Copilot Memory에 user-level preferences를 추가했습니다. 표면적으로는 작은 changelog입니다. Copilot이 사용자의 커밋 스타일, pull request 구조, 커뮤니케이션 톤 같은 개인 선호를 저장하고, 이후 다른 Copilot 경험에서도 그 선호를 참고할 수 있게 됐다는 내용입니다. 하지만 코딩 에이전트 흐름에서 보면 이 변화는 작지 않습니다. 에이전트가 프로젝트를 기억하는 단계를 넘어, 개발자 한 사람의 작업 스타일을 따라다니는 단계로 이동하고 있기 때문입니다.

기존 Copilot Memory는 repository-level facts에 더 가까웠습니다. 특정 저장소의 빌드 명령, 테스트 방식, 아키텍처 결정, 코딩 규칙 같은 정보를 기억해 두고, Copilot cloud agent나 code review, CLI가 다음 작업에서 참고하는 구조입니다. 저장소가 바뀌면 memory도 바뀝니다. 팀이 공유하는 코드베이스의 사실을 저장하는 것이므로, 범위가 비교적 명확합니다. 이번에 추가된 user-level preferences는 다릅니다. 사용자가 어느 저장소에서 일하든, 같은 사용자에게 적용되는 개인 작업 취향을 저장합니다.

GitHub Changelog는 예시를 세 가지로 들었습니다. 선호하는 commit style, pull request structure, communication and tone preferences입니다. 여기서 중요한 단어는 "stated or inferred"입니다. Copilot은 사용자가 명시적으로 말한 선호뿐 아니라, 상호작용에서 추론한 개인 선호도 저장할 수 있습니다. 개발자가 매번 "커밋 메시지는 Conventional Commits로 써줘", "PR 설명은 위험과 테스트를 먼저 적어줘", "답변은 짧고 직접적으로 해줘"라고 반복하지 않아도 되는 것이 장점입니다. 동시에 추론된 선호가 틀릴 수 있다는 점이 신뢰 문제의 시작입니다.

왜 지금 memory일까요. 2026년의 GitHub Copilot은 단일 IDE 자동완성 도구가 아닙니다. Copilot cloud agent는 GitHub 안에서 이슈나 작업을 받아 백그라운드로 코드를 고치고 PR을 만들 수 있습니다. Copilot code review는 PR에서 변경을 읽고 리뷰 코멘트를 남깁니다. Copilot CLI는 터미널에서 명령과 작업 흐름을 돕습니다. 여기에 JetBrains IDE의 unified sessions, Copilot app technical preview, REST API로 시작하는 cloud agent task까지 붙으면, 사용자는 여러 표면에서 같은 조수를 만납니다. 문제는 각 표면이 매번 새로 시작하면 일관성이 떨어진다는 것입니다.

memory는 이 일관성 문제의 답입니다. 모델을 아무리 개선해도, 사용자와 저장소의 맥락을 매번 잃어버리면 코딩 에이전트는 늘 새 동료처럼 행동합니다. 새 동료는 설명이 필요합니다. 프로젝트의 금기, 테스트 명령, 배포 흐름, 선호하는 리뷰 문체, "우리는 이 패턴을 쓰지 않는다" 같은 지식을 다시 알려줘야 합니다. AGENTS.md, README, .github/copilot-instructions.md, Cursor rules, Claude Code memory, Codex의 instructions가 모두 이 문제를 다른 방식으로 다룹니다. GitHub의 선택은 일부 맥락을 Copilot 자체의 관리형 memory로 끌어들이는 것입니다.

공식 문서 기준 Copilot Memory는 두 층으로 나뉩니다. repository-level facts는 저장소에 묶입니다. 예를 들어 "이 저장소는 pnpm을 사용한다", "데이터베이스 연결 설정은 특정 파일 두 곳이 함께 바뀌어야 한다", "테스트는 이 명령으로 돈다" 같은 정보입니다. GitHub 문서는 repository-level facts가 citation과 함께 저장되고, Copilot이 fact를 사용할 때 현재 branch에서 그 citation을 검증한다고 설명합니다. 현재 코드가 더 이상 그 사실을 뒷받침하지 않으면, 오래된 memory가 그대로 적용되지 않도록 설계한 셈입니다.

user-level preferences는 사용자에게 묶입니다. 문서는 이 선호가 direct user quotes를 포함할 수 있는 citation과 함께 저장될 수 있다고 설명합니다. 예컨대 사용자가 "나는 PR 본문에 테스트 결과를 먼저 보고 싶다"고 말했다면, 그 문장이 개인 선호의 근거가 될 수 있습니다. GitHub은 이 선호가 같은 사용자의 later interactions에서만 제공된다고 말합니다. 같은 저장소에서 일하는 다른 사용자에게 영향을 주지 않는다는 점이 repository facts와 다릅니다. 팀 규칙과 개인 습관을 분리하려는 설계입니다.

이 분리는 실무적으로 중요합니다. 저장소 규칙은 팀의 공유 계약입니다. formatter, lint, 테스트 명령, 아키텍처 경계, 보안 규칙처럼 모든 기여자가 따라야 합니다. 반면 개인 선호는 사용자 경험에 가깝습니다. 어떤 사람은 짧은 답변을 원하고, 어떤 사람은 tradeoff를 자세히 보고 싶어합니다. 어떤 팀 리드는 PR 설명에서 위험을 먼저 보고 싶고, 어떤 개인 개발자는 commit message 초안을 Conventional Commits로 받고 싶어합니다. 둘을 같은 memory에 섞으면 팀 규칙이 개인 취향으로 오염되거나, 개인 취향이 팀 규칙처럼 강제될 수 있습니다.

GitHub 문서에서 눈에 띄는 제한도 있습니다. Copilot Memory는 현재 Copilot cloud agent, Copilot code review, Copilot CLI에서 쓰입니다. 하지만 code review는 repository-level facts만 사용하고 user-level preferences는 적용하지 않는다고 설명합니다. 이 결정은 타당합니다. 코드 리뷰는 개인 취향보다 팀 기준과 저장소 사실에 맞춰야 합니다. 사용자가 "부드러운 톤으로 리뷰해줘" 같은 선호를 가질 수는 있지만, 보안 취약점이나 테스트 누락을 판단하는 근거가 개인 선호에 흔들리면 곤란합니다. GitHub이 user preference를 모든 표면에 무차별 적용하지 않는다는 점은 신뢰 측면에서 중요합니다.

보존 정책도 봐야 합니다. 문서에 따르면 사용되지 않은 fact나 preference는 28일 뒤 자동 삭제될 수 있습니다. 성공적으로 검증되고 사용되면 이 타이머가 reset될 수 있습니다. 이는 memory가 무한히 쌓이는 지식 저장소가 아니라, 최근에 유용했던 working context에 가깝다는 뜻입니다. 오래된 프로젝트 규칙과 개인 취향이 계속 남아 에이전트 행동을 왜곡하는 문제를 줄이려는 설계입니다. 다만 사용자는 어떤 memory가 언제 생성됐고, 어떤 근거로 쓰였는지 확인할 수 있어야 합니다. GitHub은 repository owners와 individual users가 각각 memory를 review/delete할 수 있다고 설명합니다.

활성화 정책은 개인과 조직에서 다릅니다. 개인 Copilot Pro와 Pro+ 사용자는 Copilot Memory가 기본 활성화이며, personal Copilot settings에서 끌 수 있습니다. enterprise와 organization-managed subscription은 기본 비활성화이고, 관리자가 켜야 합니다. 여러 조직에서 Copilot subscription을 받는 사용자는 가장 제한적인 설정이 적용됩니다. 조직 입장에서는 이 기본값 차이가 중요합니다. 개인 사용자는 편의성이 우선이고, 조직 사용자는 데이터 거버넌스와 정책 검토가 먼저라는 GitHub의 판단이 들어 있습니다.

개발자 경험만 놓고 보면 장점은 분명합니다. 반복 프롬프트가 줄어듭니다. "이 저장소에서는 테스트 명령이 특이합니다", "나는 PR 설명에 요약보다 변경 위험을 먼저 씁니다", "커밋은 squash merge를 전제로 한 단일 메시지로 정리해주세요" 같은 정보를 매번 알려주지 않아도 됩니다. 에이전트가 여러 표면으로 확장될수록 이 효과는 커집니다. GitHub 웹에서 cloud agent가 시작한 작업을 CLI에서 확인하고, 나중에 다른 저장소에서 비슷한 commit style을 기대한다면 user-level memory가 체감됩니다.

하지만 memory는 늘 양날입니다. 첫째, 암묵적 저장은 편하지만 예측 가능성이 떨어집니다. 사용자가 명시하지 않은 선호를 Copilot이 추론한다면, 잘못된 추론이 다음 작업에 섞일 수 있습니다. 둘째, 개인 선호와 팀 규칙의 경계가 흐려질 수 있습니다. "나는 이렇게 합니다"와 "우리 저장소는 이렇게 해야 합니다"는 다릅니다. 셋째, 여러 Copilot 표면에서 memory 적용 범위가 다르면 사용자는 왜 어떤 곳에서는 선호가 반영되고 어떤 곳에서는 반영되지 않는지 헷갈릴 수 있습니다. 넷째, memory가 편해질수록 명시적 문서가 부실해질 위험도 있습니다.

그래서 이 기능은 AGENTS.md나 repository instructions를 대체한다기보다, 다른 층을 추가한다고 보는 편이 정확합니다. AGENTS.md와 .github/copilot-instructions.md 같은 파일은 version-controlled policy입니다. 코드 리뷰에서 변경 이력을 볼 수 있고, 팀 전체가 같은 내용을 공유합니다. Copilot Memory는 사용 중 발견되는 사실과 선호를 관리형으로 저장합니다. 빠르게 적응하지만, 파일처럼 코드베이스의 명시적 계약으로 남지는 않습니다. 좋은 팀이라면 둘을 경쟁시키지 않고 역할을 나눌 가능성이 큽니다. 팀 규칙은 파일로, 반복적으로 발견되는 저장소 사실은 memory로, 개인 작업 스타일은 user preference로 두는 식입니다.

커뮤니티 반응은 아직 큰 토론으로 번지지 않았습니다. 하지만 Copilot 관련 커뮤니티에서는 이미 수개월 전부터 memory의 범위와 위치에 대한 질문이 반복됐습니다. 어떤 memory가 로컬 VS Code 기능이고, 어떤 memory가 GitHub의 Copilot Memory인지 헷갈리는 개발자가 있습니다. 또 어떤 개발자는 암묵적 memory보다 문서 파일을 선호합니다. 이유는 간단합니다. 파일은 보이고, diff가 남고, 팀이 합의할 수 있습니다. memory는 편하지만, UI와 정책이 충분하지 않으면 "에이전트가 왜 이렇게 행동하지?"라는 불신으로 바뀝니다.

이번 변화가 GitHub에게 중요한 이유는 Copilot을 단순 assistant가 아니라 developer workflow platform으로 만들고 있기 때문입니다. 모델 선택은 이미 다변화됐습니다. Copilot은 OpenAI 모델만 쓰는 제품이 아니며, 여러 모델과 에이전트 표면을 라우팅합니다. 모델이 바뀌어도 사용자 경험이 유지되려면, GitHub가 소유한 컨텍스트 계층이 필요합니다. memory, custom instructions, model policy, usage metrics, cloud agent sessions, PR review 결과가 서로 연결되면 GitHub는 모델 공급자보다 위의 작업 계층을 장악할 수 있습니다.

경쟁사도 같은 문제를 봅니다. Cursor는 rules와 workspace context, background agent로 개발 환경 안의 컨텍스트를 붙잡습니다. Claude Code는 CLAUDE.md, settings, memory/instructions 흐름으로 프로젝트와 사용자 지시를 다룹니다. Codex 계열 도구는 AGENTS.md와 세션 지시, 원격 작업 제어를 통해 비슷한 문제를 풉니다. 차이는 GitHub이 코드 호스팅, PR, Actions, issue, review, billing, organization policy를 이미 갖고 있다는 점입니다. Copilot Memory가 이 표면을 모두 가로지르면, memory는 단순 편의 기능이 아니라 GitHub 에이전트 런타임의 접착제가 됩니다.

물론 기업 도입에서는 질문이 더 까다롭습니다. 어떤 정보가 memory로 저장될 수 있는가. direct user quotes가 citation에 포함될 수 있다면, 민감한 내부 표현이나 고객 이름이 들어갈 수 있는가. repository owners는 어떤 수준까지 볼 수 있고, 개인 preference는 조직 관리자가 볼 수 있는가. 조직 정책에서 off로 둔 경우 개인 Pro 계정의 memory는 업무 저장소에서 어떻게 제한되는가. GitHub 문서는 범위와 기본값을 설명하지만, 실제 보안 검토에서는 audit log, data retention, eDiscovery, incident response, cross-org policy가 함께 검토될 것입니다.

개발자 개인에게는 더 간단한 원칙이 필요합니다. 반복되는 개인 취향은 memory에 맡겨도 됩니다. 하지만 팀 규칙, 보안 요구사항, 배포 절차, 법적 주의사항은 명시적 파일과 문서에 남겨야 합니다. 에이전트가 기억해 주기를 기대하는 것과, 팀이 반드시 따라야 하는 규칙을 repository에 선언하는 것은 다릅니다. Copilot Memory가 좋아질수록 이 구분은 더 중요해집니다. memory는 편의성을 높이고, instructions는 책임과 합의를 남깁니다.

이번 GitHub Changelog는 짧습니다. 그러나 그 안에 들어 있는 방향은 길게 갑니다. 코딩 에이전트는 더 이상 한 번의 질문에 답하는 모델이 아닙니다. 사용자의 취향을 기억하고, 저장소의 사실을 검증하고, 여러 표면에서 작업을 이어가며, 때로는 cloud agent로 실제 코드를 고칩니다. 이때 memory는 UX 기능이면서 동시에 거버넌스 표면입니다. 무엇을 기억할지, 누구에게 적용할지, 어떻게 삭제할지, 언제 잊을지, 어떤 표면에서는 쓰지 않을지를 정하는 일이 에이전트 품질의 일부가 됩니다.

GitHub Copilot Memory의 user-level preferences는 작은 개인화 기능처럼 보일 수 있습니다. 하지만 코딩 에이전트 시장에서는 개인화가 곧 지속성이고, 지속성이 곧 신뢰의 문제입니다. 사용자는 매번 설명하지 않아도 되는 도구를 원합니다. 동시에 도구가 몰래 잘못 기억하지 않기를 원합니다. GitHub의 이번 업데이트는 그 긴장 위에 있습니다. 편리한 기억과 통제 가능한 기억 사이의 균형을 누가 더 잘 잡느냐가, 다음 코딩 에이전트 경쟁의 중요한 차이가 될 것입니다.

출처

• GitHub Changelog: Copilot Memory supports user preferences for Pro, Pro+ users
• GitHub Docs: About GitHub Copilot Memory
• GitHub Docs: Managing and curating Copilot Memory
• VS Code Docs: Memory in VS Code agents