Copilot 메모리가 도입된 배경

개발자라면 이 상황이 익숙할 겁니다. 오늘 Copilot에 프로젝트 아키텍처와 네이밍 컨벤션을 열심히 설명했더니 훌륭한 코드가 나왔습니다. 다음 날 새 파일을 열면 Copilot은 어제 설명한 걸 하나도 기억하지 못합니다. 처음부터 다시 설명해야 하죠.

이게 Copilot만의 문제가 아닙니다. 세션이 끝나면 컨텍스트가 사라지는 건 LLM 기반 AI 시스템의 구조적 한계입니다. Microsoft는 이 문제의 해결책으로 Copilot 메모리(Copilot Memories)를 내놨습니다. Visual Studio 2026 18.3.0 업데이트(출시일: 2026년 2월 10일)에서 정식 도입됐고, 에이전틱 메모리(Agentic Memory)로도 불리는 기능입니다.

단순한 ‘기억 기능’처럼 보이지만, 실제로는 저장 구조, 만료 규칙, 적용 범위가 세밀하게 정의되어 있어서 무작정 켜두기만 하면 기대와 다른 결과가 나올 수 있습니다.

▲ 목차로 돌아가기

기능이 실제로 작동하는 방식 (JIT 인증 구조)

기능이 어떻게 돌아가는지를 알아야 왜 안 될 때가 있는지도 이해됩니다. Copilot 에이전트가 저장소에서 작업하는 동안 작게 범위를 잡은 사실들, 즉 ‘메모리’를 추출하고 저장합니다. 이 메모리는 세션이 끝나도 남아 있고, 같은 저장소에서 작업하는 다른 Copilot 에이전트(코딩 에이전트, 코드 리뷰, CLI)와도 공유됩니다.

‘오프라인 큐레이션 방식’을 쓰지 않은 이유가 있습니다. 별도의 ‘진실 데이터베이스’를 빠르게 변하는 코드베이스와 동기화하는 건 대규모에서 유지 보수 악몽이 됩니다. JIT 방식은 그 문제를 없앱니다. 검증은 인라인으로 일어나고, 소수의 읽기 작업만 추가되며 세션 지연이 거의 없습니다. 덕분에 메모리 저장소가 노이즈 없이 유효한 신호만 남게 되죠.

(출처: GitHub Docs, Managing and curating Copilot Memory; VS 2026 공식 릴리스 노트 18.3.0)

▲ 목차로 돌아가기

저장 위치와 관리 방법

어디에 저장되나요?

Copilot이 감지해서 저장한 메모리는 두 곳으로 분기됩니다. 개인 선호는 %USERPROFILE%/copilot-instructions.md(개인 파일)에, 팀 전체가 공유해야 할 규칙은 /.github/copilot-instructions.md(저장소 레벨)에 자동으로 병합됩니다. (출처: Visual Studio Blog, Copilot Memories, 2026.01.15)

메모리가 저장될 때 무작정 덮어쓰지 않습니다. 확인 알림(Confirmation nudge)이 뜨고, 검토 후 수락하거나 수정할 수 있습니다. 저장소 전체 메모리 목록은 GitHub 저장소 설정 → Copilot → Memory에서 볼 수 있고, 개별 삭제도 가능합니다.

활성화 방법 (플랜별)

기본값이 OFF이기 때문에 직접 켜야 합니다. 플랜에 따라 경로가 다릅니다.

• 개인(Pro/Pro+): GitHub 프로필 → Copilot settings → Features → Copilot Memory → Enabled
• 조직(Business): 조직 Settings → Copilot → Policies → Copilot Memory → Enabled
• 엔터프라이즈: 엔터프라이즈 → AI controls → Copilot → Copilot Memory 정책 설정

▲ 목차로 돌아가기

켜도 효과가 없는 조건들

메모리 기능을 활성화해도 바로 체감되는 게 없어서 의아한 경우가 많습니다. 공식 문서가 밝히는 이유가 있습니다.

공식 문서에서 직접 확인한 한계 조건

▲ 목차로 돌아가기

VS 코드와의 실질적인 기능 차이

Visual Studio 2026에서 Copilot을 쓰고 있다면 한 가지를 알아두는 게 좋습니다. 같은 Copilot이지만 Visual Studio 2026(IDE)과 VS Code의 Copilot 품질이 현재 다릅니다.

(출처: VS 2026 공식 릴리스 노트, GitHub Blog Changelog 2026-03-04 기준)

.NET/C# 위주로 Visual Studio 2026을 주력으로 쓴다면, 현재 메모리 기능은 잘 쌓이지만 복잡한 멀티파일 작업의 플래닝 품질에서는 VS Code 쪽이 더 낫습니다. 불편하더라도 탭 전환을 하는 실사용자가 많은 이유입니다.

▲ 목차로 돌아가기

기존 instruction 파일과 함께 쓰는 방법

많이 오해하는 부분입니다. Copilot 메모리가 생기면서 기존 /.github/copilot-instructions.md 파일이 필요 없어지는 게 아닙니다. 두 가지는 역할이 다릅니다.

실용적인 접근은 이렇습니다. instruction 파일에는 처음부터 지켜야 하는 규칙들(publisher prefix, 금지 패턴, 아키텍처 원칙)을 적어두고, 메모리에는 개발 과정에서 자연스럽게 드러나는 암묵적 패턴이 쌓이도록 둡니다. 메모리가 처음에는 없으니 instruction 파일이 기반을 잡아주고, 메모리가 충분히 쌓인 후에는 두 레이어가 서로 보완합니다.

저장소를 처음 시작한 팀이라면 instruction 파일 없이 메모리만 믿고 들어가면 초반에 비어있어서 일관성이 안 나옵니다. 반대로 instruction 파일만 있고 메모리를 끈 채로 쓰면, 코드베이스가 발전하면서 생기는 암묵적 패턴을 Copilot이 계속 모르는 상태로 남게 됩니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

Copilot 메모리는 ‘그냥 켜두면 점점 좋아지는 기능’으로 소개되지만, 실제로는 구체적인 작동 조건이 있습니다. 28일 자동 만료, 저활동 저장소의 학습 한계, Plan 모드와의 기능 갭, 저장소 간 격리 구조는 공식 문서에 분명히 나와 있는데 한국어 콘텐츠에서는 이 부분이 잘 다뤄지지 않습니다.

솔직히 말하면, 혼자 작업하는 작은 저장소에서 활성화했다가 “뭐가 달라졌는지 모르겠다”고 느끼는 경우가 나올 수 있습니다. 기능이 나쁜 게 아니라, 팀 단위로 PR 활동이 활발한 저장소에서 훨씬 더 잘 작동하게 설계된 기능이기 때문입니다.

instruction 파일과 함께 쓰면서 2~4주 기다리는 게 번거롭게 느껴질 수 있지만, 그 누적이 생기면 팀이 반복적으로 같은 설명을 Copilot에 해주는 작업이 줄어듭니다. 조건을 이해하고 쓰는 것과 무작정 쓰는 것의 결과가 다릅니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Visual Studio Blog — Copilot Memories (2026.01.15)
2. GitHub Blog Changelog — Copilot in Visual Studio February Update (2026.03.04)
3. Microsoft Learn — Visual Studio 2026 릴리스 노트 (2026.03.31 기준)
4. GitHub Docs — Managing and curating Copilot Memory
5. Neowin — VS 2026 18.3.0 brings GitHub Copilot memories (2026.02.11)