VS Code에서 Copilot Memory 설정하는 방법 (2026년 가이드)

두 가지 시스템이 존재하며, 서로 대체할 수 없습니다

메모리 도구(The memory tool)는 로컬에 존재하며 VS Code에 내장되어 있습니다. 문서에서는 이를 "에이전트가 작업하면서 노트를 저장하고 불러올 수 있는 내장 에이전트 도구입니다. 에이전트에게 특정 내용을 기억하도록 명시적으로 요청할 수도 있습니다"라고 설명합니다. 현재 프리뷰 상태이며, chat.tools.memory.enabled 설정으로 제어되고, 세 가지 범위(scope)를 가집니다:

• User (/memories/): 세션 및 워크스페이스 전반에 걸쳐 유지됩니다. "선호도, 패턴, 자주 사용하는 명령"을 위한 것입니다.
• Repository (/memories/repo/): 세션 간에 유지되며, 워크스페이스 범위로 제한됩니다. "코드베이스 컨벤션, 프로젝트 구조, 빌드 명령"을 위한 것입니다.
• Session (/memories/session/): 유지되지 않음(채팅이 종료되면 삭제됨). "작업별 컨텍스트, 진행 중인 계획"을 위한 것입니다.

Copilot Memory는 또 다른 시스템입니다: "Copilot이 작업하면서 리포지토리별 인사이트를 학습하고 유지할 수 있도록 하는 GitHub 호스팅 메모리 시스템"으로, "Copilot 클라우드 에이전트, Copilot 코드 리뷰, Copilot CLI를 포함한 여러 GitHub Copilot 환경"에서 공유됩니다. 리포지토리 범위로만 제한되며, 에이전트에 의해 자동으로 작성되고, 기본적으로 꺼져 있습니다.

이 두 가지를 혼동하는 것이 메모리가 작동하지 않는다고 생각하는 가장 흔한 이유입니다. 로컬 도구는 기본적으로 켜져 있지만, 호스팅되는 도구는 그렇지 않습니다.

여러 환경에 걸쳐 작동하는 시스템은 두 번 동의(opt-in)해야 합니다

Copilot Memory는 "기본적으로 꺼져 있으며 GitHub 설정에서 활성화해야 합니다." 이는 Copilot Pro 또는 Pro+ 사용자의 개인 Copilot 설정에서 활성화하거나, 팀의 경우 조직(organisation) 또는 엔터프라이즈 정책 설정을 통해 활성화해야 합니다.

만약 리포지토리 메모리가 이 시스템의 지원을 받도록 하려면 VS Code 측에 두 번째 관문이 있습니다. 기본적으로 비활성화되어 있는 실험적 설정과 함께 "GitHub 설정에서 해당 리포지토리에 대해 Copilot Memory가 활성화되어 있어야 한다"는 요구사항입니다. 그리고 실패 시 아무런 경고도 발생하지 않습니다: "두 조건 중 하나라도 충족되지 않으면 리포지토리 메모리는 로컬 파일 저장소로 대체됩니다." 에러는 발생하지 않으며, 리포지토리 메모리는 단순히 노트북에만 남아 있게 되고, 활성화했다고 생각했던 멀티 플랫폼 공유 동작은 전혀 일어나지 않습니다.

리포지토리 메모리는 28일 후에 만료됩니다

이것이 바로 설계를 고려할 때 염두에 두어야 할 사실입니다. Copilot Memory는 28일 후에 메모리를 삭제하며, 그 이유로 제시된 "오래된 정보를 방지하기 위해"라는 설명은 타당합니다. 이와 함께 칭찬할 만한 정말 독특한 안전장치가 결합되어 있습니다. 메모리는 "사용 전에 검증"됩니다. 즉, "에이전트가 메모리를 적용하기 전에 현재 코드베이스와 대조하여 검증함으로써, 오래되거나 잘못된 정보가 결과에 영향을 미치는 것을 방지"합니다. 작동하기 전에 스스로 실제 코드와 대조하여 확인하는 메모리 시스템은 극히 드뭅니다.

하지만 이 두 가지를 함께 생각해보십시오. 코드에 대해 검증하는 동시에 4주의 주기로 만료되는 시스템은 최근의 운영 인사이트(빌드 특이사항, 불안정한 테스트, 지난주 리뷰 중에 발견된 패턴 등)에 최적화되어 있습니다. 지난 3월에 내린 아키텍처 결정을 보관하도록 설계된 것이 아닙니다. 6개월 후에도 필요한 정보는 다른 곳에 보관해야 하며, 문서 자체의 비교 표에서도 Copilot Memory의 "자동(28일)" 만료와 로컬 도구의 "수동 관리"를 대조하여 이를 명시하고 있습니다.

지침(Instructions)과 메모리(Memory)는 서로 다른 질문에 답합니다

지침은 사용자가 요구하는 사항이고, 메모리는 에이전트가 학습한 내용입니다. Copilot은 첫 번째 종류인 지침을 다양하게 지원합니다: 단일 .github/copilot-instructions.md 파일, 하나 이상의 AGENTS.md 파일, GitHub 조직 수준에서 정의된 조직 수준 지침, 그리고 특히 Claude Code 및 기타 Claude 기반 도구와의 호환성을 위해 워크스페이스 루트, .claude 폴더 또는 사용자 홈 디렉토리에서 읽어오는 CLAUDE.md 파일이 있습니다. 파일 기반의 *.instructions.md 파일은 applyTo 헤더를 통해 glob 스코핑을 추가하며, 문서화된 위치에는 .github/instructions 및 .claude/rules가 포함됩니다.

이 시스템의 한 가지 특징이 다른 어떤 것보다 중요합니다: "프로젝트에 여러 지침 파일이 있는 경우, VS Code는 이를 결합하여 채팅 컨텍스트에 추가하며, 특정 순서는 보장되지 않습니다." 우선순위에 따라 해결되는 것이 아니라 결합됩니다. 두 파일이 충돌하는 경우 대신 결정해 주는 장치가 없으므로, 요구사항을 최소화하고 명확하게 유지해야 하며, 지침 파일을 알고 있는 모든 정보를 담아두는 서류 캐비닛처럼 사용해서는 안 됩니다.

메모리 도구를 켜고 그것이 Copilot Memory라고 가정하는 것. 로컬 도구는 기본적으로 활성화되어 사용자의 컴퓨터에 기록합니다. 여러 환경에 걸쳐 작동하는 시스템은 GitHub에서 별도로 동의(opt-in)해야 합니다.

모든 것을 .github/copilot-instructions.md에 넣는 것. 내용이 길어지기 전까지는 잘 작동하지만, 길어지면 두 번째 AGENTS.md, 상속된 CLAUDE.md, 그리고 일치하는 다른 .instructions.md 파일들과 컨텍스트 경쟁을 벌이게 되며, 이들 간의 순서는 보장되지 않습니다.

메모리가 규칙을 강제하기를 기대하는 것. 메모리는 규칙을 강제하지 않습니다. 지침은 사용자가 요구하는 사항이고, 메모리는 감지된 내용입니다. 매번 반드시 지켜져야 하는 사항은 빌드를 실패하게 만드는 검사 단계에 포함되어야 합니다.

문제가 발생한 후에야 28일 만료 제한을 발견하는 것. 흔히 발생하는 시나리오: 1주 차에 기록된 결정 사항이 6주 차에 사라지고, 7주 차에 다시 논쟁을 벌이게 됩니다.

Copilot에는 메모리가 전혀 없다고 결론 내리는 것. 몇 달 전이라면 이해할 수 있었겠지만 지금은 틀린 생각이며, 이미 문서화된 두 시스템이 수행하고 있는 작업을 사람들이 수동으로 다시 구축하게 만듭니다.

설정 자체는 간단합니다. 다음 순서대로 진행하세요.

메모리 도구가 꺼져 있다면 활성화하세요. 기본적으로 켜져 있지만, chat.tools.memory.enabled 설정을 확인하고 의도적으로 사용하세요. 여러 프로젝트에 걸친 선호도에는 user 메모리를, 코드베이스 관련 사실에는 repository 메모리를, 현재 진행 중인 계획에는 session 메모리를 사용하세요. 기억해 둘 만한 한 가지 디테일은 user 메모리의 경우 "매 세션이 시작될 때 처음 200줄이 에이전트의 컨텍스트에 자동으로 로드된다"는 점입니다. 해당 파일의 상단 부분을 가치 있는 내용으로 채우세요.

여러 환경에 걸친 학습을 원하는 경우에만 Copilot Memory를 활성화하세요. 개인 사용자를 위한 개인 Copilot 설정, 조직을 위한 정책 설정과 더불어, 리포지토리 메모리가 이를 지원하도록 하려면 리포지토리 수준의 활성화 및 VS Code 실험적 설정이 필요합니다. 로컬 저장소로의 대체는 아무런 경고 없이 자동으로 이루어지므로, 그냥 가정하지 말고 직접 검증하세요.

리포지토리 소유자에게 검토하는 습관을 들이도록 하세요. 저장된 메모리는 Repository Settings > Copilot > Memory에서 검토 및 삭제할 수 있으며, 메모리는 "쓰기 권한이 있는 기여자만 생성할 수 있습니다." 한 달에 한 번 목록을 확인해 보세요. 에이전트가 여러분의 코드베이스를 어떻게 이해하고 있는지 파악하는 가장 빠른 방법입니다.

필수 지침은 메모리가 아닌 지침 파일에 보관하세요. 항상 켜져 있는 파일 하나와 나머지를 위한 범위 지정 .instructions.md 파일들을 사용하고, 이들 중 어느 것에도 무시되었을 때 곤란해질 내용은 넣지 마세요. 파일 간의 순서가 보장되지 않기 때문입니다.

그다음, 4주의 시간 제한이 있는 부분을 처리합니다. MemoryLake는 특정 도구의 외부에 존재하는 메모리 레이어이므로, 28일 이상 유지되어야 하는 지식을 안전하게 보존할 수 있습니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

로그인하고 API 키를 생성합니다. 연결하는 여러 도구에서 하나의 자격 증명으로 사용할 수 있습니다.

2단계: 첫 번째 메모리 업로드

각각 하나의 사실만 담은 짧은 항목을 작성합니다. Copilot Memory가 보관하도록 설계되지 않은 내용을 여기에 작성하세요:

결정 사항과 그 이유. "두 모바일 클라이언트가 이전 빌드를 고정하여 사용하고 있으므로 API 경로에 버전을 명시합니다." 리포지토리 메모리는 만료되지만, 그 이유는 만료되어서는 안 됩니다.

시도했으나 거부된 사항. 올바른 접근법처럼 보였으나 실패한 방식과 그 실패 원인입니다. 두 Copilot 시스템 모두 부정적인 결과(실패 사례)를 기록하기 위한 필드를 제공하지 않습니다.

소유권 및 경계. 어떤 서비스를 누가 소유하는지, 어떤 디렉토리가 고정(frozen)되어 있는지, 어느 팀에 문의해야 하는지 등입니다. 이는 코드가 아닌 사람에 관한 사실이므로, 코드베이스와 아무리 대조하여 검증하더라도 복구할 수 없습니다.

외부 포인터. 대시보드, 장애 로그, 디자인 문서 등 에이전트가 리포지토리를 읽는 것만으로는 찾을 수 없는 컨텍스트입니다.

3단계: AI 및 에이전트 연결

사용 중인 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으며, VS Code는 MCP 서버를 지원하므로 Copilot과 함께 동일한 메모리를 사용할 수 있습니다. Claude Code, Codex, Cursor, Cline도 동일한 메모리를 읽을 수 있습니다. Copilot의 지침 로더가 이미 CLAUDE.md 및 .claude/rules를 읽고 있으므로, 여러 도구를 혼용하는 팀 환경이 예외가 아닌 일반적인 상황이라는 점에서 이는 매우 중요합니다.

세 가지 명확한 한계가 있습니다. MemoryLake는 /memories/나 Copilot Memory를 읽거나 쓰지 않습니다. 두 저장소 모두 API를 제공하지 않으므로 위의 검토 습관이 수동으로 이루어져야 하는 이유입니다. 지침의 순서를 변경하지 않습니다. "특정 순서가 보장되지 않는" 동작은 VS Code 자체의 특성입니다. 마지막으로, 메모리는 컨텍스트일 뿐 강제 수단이 아닙니다. 매 실행마다 반드시 참이어야 하는 사항은 CI 단계에 포함되어야 합니다.

두 시스템이 더 이상 하나의 모호한 기능으로 묶이지 않습니다. 어떤 것이 로컬이고 어떤 것이 호스팅되는지, 그리고 실제로 어떤 것을 활성화했는지 명확히 알게 됩니다.

만료 제한이 더 이상 갑작스러운 놀라움으로 다가오지 않습니다. 4주 동안 유지되는 운영 인사이트는 Copilot Memory에, 만료 타이머가 없는 영구적인 추론 정보는 다른 안전한 곳에 보관됩니다.

지침 파일이 더 짧아집니다. 지식을 보관할 전용 공간이 생기면, 요구사항에 불필요한 배경 설명을 덧붙일 필요가 없어집니다.

활성화했을 때 여러 환경 간의 공유가 실제로 작동합니다. 로컬 저장소로 소리 없이 대체되는 설정을 맹신하지 않고 직접 검증했기 때문입니다.

어떤 시스템을 활성화했는지 확인하세요. 로컬 메모리 도구는 기본적으로 켜져 있으며, Copilot Memory는 기본적으로 꺼져 있어 GitHub 측에서 활성화해야 합니다.

28일 만료 제한을 설계 제약 조건으로 취급하세요. 다음 분기에도 필요한 정보는 이 시스템의 외부에 두십시오.

리포지토리 메모리 목록을 매달 확인하세요. Repository Settings > Copilot > Memory에서 확인할 수 있으며, 이는 에이전트가 이해하고 있는 내용을 보여주는 거울입니다.

user 메모리의 처음 200줄을 가치 있게 유지하세요. 이 부분이 매 세션마다 로드되는 영역입니다.

계획에는 session 범위를 사용하세요. /memories/session/은 채팅이 끝나면 지워지므로, 진행 중인 작업에 적합합니다.

우선순위가 해결해 줄 것이라 기대하며 지침 파일을 쌓아두지 마세요. 순서가 보장되지 않으므로, 모순되는 내용이 동시에 전달될 뿐입니다.

지침은 인라인 제안에 도달하지 않는다는 점을 기억하세요. 문서에 따르면 지침은 "에디터에서 입력할 때 제공되는 인라인 제안에는 고려되지 않습니다."

Agent Host에서 사용자 수준 지침을 어디서 읽어오는지 확인하세요. 문서에 따르면 "VS Code 프로필 사용자 데이터가 아니라 ~/.copilot/instructions 및 ~/.claude/rules와 같이 하네스에 구애받지 않는 폴더"에서 읽어옵니다. 일반적인 함정은 why agents ignore your instruction files에서 설명하고 있습니다.

VS Code에서 Copilot의 메모리 기능은 일상적인 대화에서 하나의 이름으로 불리지만 실제로는 두 가지 기능입니다. 로컬 메모리 도구는 프리뷰 상태이며 기본적으로 켜져 있고, user, repository, session 범위로 나뉘며, user 메모리의 처음 200줄은 매 세션마다 로드됩니다. Copilot Memory는 프리뷰 상태이며 기본적으로 꺼져 있고, GitHub에서 호스팅되며, 리포지토리 범위로 제한되고, 쓰기 권한이 있는 에이전트에 의해 자동으로 작성되며, 클라우드 에이전트, 코드 리뷰, CLI 전반에서 공유됩니다. 이 시스템의 안전장치는 실질적입니다. 메모리는 사용 전에 현재 코드베이스와 대조하여 검증되는데, 이는 대부분의 시스템이 제공하는 것 이상의 기능입니다.

그리고 이 메모리들은 28일 후에 삭제됩니다. 이 한 줄은 이 시스템이 무엇을 위한 것인지 명확히 말해줍니다. 바로 제도적 지식(institutional knowledge)이 아니라, 최근의 검증 가능한 운영 인사이트를 위한 것입니다. 두 시스템을 의도에 맞게 설정하고, 멀티 플랫폼 공유 경로를 당연하게 여기지 말고 직접 검증하며, 지침 파일 간의 순서가 보장되지 않는다는 점을 인지한 상태에서 요구사항을 지침 파일에 보관하고, 결정 사항, 거부된 접근법, 소유권 관련 사실은 만료 타이머가 없는 레이어에 보관하세요.

그렇게 하면 Copilot이 매달 코드베이스를 다시 학습하는 일을 멈출 것입니다. 또한 각 레이어가 어떤 정보를 보유하고 있는지 직접 확인할 수 있습니다. 이에 대한 실습은 how to audit what your AI assistants actually remember에서 확인하실 수 있습니다.