GitHub가 2026년 5월 15일 Copilot Memory의 새 기능을 공지했습니다.

이제 Copilot Memory는 저장소 수준의 사실뿐 아니라, 사용자의 개인 선호도 저장할 수 있습니다.
대상은 early access 기준 GitHub Copilot Pro와 Copilot Pro+ 사용자입니다.

쉽게 말하면 Copilot이 “이 저장소는 이렇게 빌드한다”뿐 아니라 “이 사용자는 PR 설명을 이런 형식으로 쓰는 걸 좋아한다”까지 기억할 수 있게 되는 방향입니다.

무엇이 달라졌나

기존 Copilot Memory의 중심은 repository-level memory였습니다.

예를 들면 이런 정보입니다.

  • 이 저장소의 빌드 명령
  • 테스트 실행 방식
  • 자주 쓰는 아키텍처 패턴
  • 특정 파일을 같이 수정해야 하는 규칙
  • 프로젝트별 coding convention

이번에 추가된 것은 user-level preferences입니다.

GitHub 설명 기준으로 Copilot은 사용자가 명시했거나 대화에서 추론된 개인 선호를 저장하고, 이후 Copilot 경험 전반에서 참고할 수 있습니다.

예시는 이렇습니다.

  • 선호하는 commit style
  • pull request 설명 구조
  • 커뮤니케이션 톤
  • 답변 방식이나 작업 스타일

저장소가 아니라 사용자에게 붙는 기억이므로, 한 저장소에서만 끝나지 않고 여러 저장소와 Copilot agent 경험으로 이어질 수 있습니다.

바로 보기

저장소 기억과 개인 기억은 다르다

이 기능은 편하지만, 팀에서는 경계를 이해해야 합니다.

저장소 기억은 프로젝트 공동 작업에 가깝습니다.
여러 사람이 같은 repository에서 Copilot을 쓸 때, 그 repository의 규칙과 사실을 Copilot이 활용할 수 있습니다.

반면 개인 선호는 특정 사용자에게만 적용됩니다.
GitHub 문서 기준으로 user-level preferences는 해당 사용자에게만 제공되고, 모든 repository의 Copilot interaction에서 활용될 수 있습니다.

따라서 개인 선호에 팀 규칙을 너무 많이 맡기면 안 됩니다.

예를 들어 “우리 팀 PR 템플릿은 이렇게 써야 한다”는 내용은 repository instruction, PR template, CONTRIBUTING 문서에 있어야 합니다.
”나는 요약을 먼저 보고 싶다” 같은 개인 취향은 Copilot Memory에 맡겨도 됩니다.

어디에서 쓰이나

GitHub 문서 기준으로 Copilot Memory는 현재 Copilot cloud agent, Copilot code review, Copilot CLI에서 쓰입니다.

다만 기능별 차이가 있습니다.

  • Copilot CLI는 작업을 시작한 사용자의 저장된 사실과 선호를 적용합니다.
  • Copilot code review는 repository-level facts만 사용하며, user-level preferences는 적용하지 않습니다.
  • 저장된 기억은 관련 작업에서 재사용될 수 있습니다.

이 차이가 중요합니다.

예를 들어 개인이 “짧은 커밋 메시지를 선호한다”는 기억을 갖고 있어도, Copilot code review가 그 개인 취향대로 리뷰 기준을 바꾸는 것은 아닙니다. 코드 리뷰 쪽은 저장소 수준 사실 중심으로 봅니다.

관리와 삭제가 가능해야 한다

개인화 기능에서 가장 중요한 운영 포인트는 “기억한다”가 아니라 “지울 수 있다”입니다.

GitHub는 사용자가 개인 Copilot Memory settings에서 user-level preferences를 검토하고 삭제할 수 있다고 설명합니다.

또 GitHub Docs는 저장된 fact나 preference가 28일 동안 쓰이지 않으면 자동 삭제된다고 설명합니다. 사용될 때 timer가 다시 갱신될 수 있고, repository-level facts는 현재 코드와 citation을 검증한 뒤 사용됩니다.

사용자는 아래를 주기적으로 보는 편이 좋습니다.

  1. Copilot이 내 선호를 잘못 추론하지 않았는가
  2. 오래된 업무 스타일이 남아 있지 않은가
  3. 특정 회사나 프로젝트에서만 맞는 선호가 개인 전체 선호처럼 저장되지 않았는가
  4. 민감한 내부 표현이나 사람 이름이 preference에 남지 않았는가

AI 기억 기능은 틀린 기억이 쌓일 때 오히려 품질을 떨어뜨립니다.

개인 사용자는 어떻게 써볼까

개인 개발자라면 구체적인 선호를 한 번 알려주는 것부터 시작할 수 있습니다.

예시는 이렇습니다.

앞으로 PR 설명은 변경 요약, 검증 방법, 위험 요소 순서로 짧게 작성해줘.
커밋 메시지는 영어 imperative mood로 쓰고, 한 줄 제목 뒤에 필요할 때만 본문을 붙여줘.
코드 리뷰 결과는 버그 가능성, 테스트 누락, 유지보수 리스크 순서로 정리해줘.

이런 선호는 매번 프롬프트에 반복해서 쓰기 번거로운 부분입니다.

다만 “우리 회사 보안 정책은 이렇다” 같은 정보는 개인 선호보다 repository 또는 조직 문서에 두는 편이 맞습니다.

팀 관리자는 무엇을 봐야 하나

조직이 Copilot Business나 Enterprise를 쓴다면, Copilot Memory는 개인 기능처럼 보여도 정책 이슈가 됩니다.

GitHub 문서 기준으로 enterprise·organization-managed subscription에서는 Copilot Memory가 기본 꺼짐 상태이고, 관리자 설정을 통해 켜야 합니다. 여러 조직에서 Copilot subscription을 받는 사용자는 더 제한적인 설정이 적용됩니다.

관리자는 아래를 확인해야 합니다.

  • 조직에서 Copilot Memory를 켤 것인가
  • repository-level facts를 누가 검토하고 삭제할 수 있는가
  • 개인 선호와 팀 규칙을 어떻게 구분할 것인가
  • custom instructions, repository instructions, PR templates와 역할이 겹치지 않는가
  • Copilot Memory가 비용과 에이전트 사용량 흐름에 어떤 영향을 주는가

특히 2026년 6월 Copilot AI Credits 전환을 앞둔 팀이라면, Copilot Memory 자체보다 에이전트 작업이 길어질 때 비용과 품질이 어떻게 변하는지도 같이 봐야 합니다.

한 줄 결론

Copilot Memory의 user-level preferences는 AI 코딩 도구가 프로젝트 문맥뿐 아니라 사용자 작업 습관까지 따라오게 만드는 변화입니다.
반복 프롬프트는 줄일 수 있지만, 팀 규칙은 문서에 두고 개인 기억은 주기적으로 검토·삭제하는 운영 습관이 필요합니다.

같이 보면 좋은 글

출처