Copilot Memory와 사용자 지정 지침의 차이: 메모리 저장 위치와 삭제 방법
GitHub Copilot Memory는 공개 프리뷰 중인, 저장소 단위로 GitHub가 호스팅하는 메모리이며 디스크에서 찾은 그 폴더가 아닙니다. 이 워크스루에서는 종류별 메모리가 어디에 저장되는지, 어떻게 확인하고 삭제하는지, 개인과 조직 각각에서 클라우드 버전을 켜고 끄는 방법, 그리고 메모리로는 대체할 수 없는 규칙을 적는 복사·붙여넣기용 사용자 지정 지침 템플릿을 12단계로 설명합니다. docs.github.com과 VS Code 메모리 문서와 대조해 확인했습니다.
핵심 요약
- 메모리는 저장소 안의 폴더가 아닙니다. GitHub Copilot Memory는 GitHub가 저장하며 하나의 저장소에만 적용됩니다. 확인과 삭제는 Repository → Settings → Code & automation → Copilot → Memory에서 합니다. 디스크에서 찾을 수 있는 메모리 폴더는 VS Code의 별도 로컬 메모리 도구에 속합니다.
- 로컬에 세 가지, 클라우드에 한 가지 범위가 있습니다. VS Code 메모리 도구는 User, Session, Repository 메모를 /memories/, /memories/session/, /memories/repo/에 두고 내 컴퓨터에 저장합니다. GitHub Copilot Memory는 저장소 범위를 coding agent, code review, Copilot CLI가 모두 읽는 호스팅 범위로 대체합니다.
- 기본값은 플랜이 정합니다. Copilot Pro와 Pro+는 Copilot Memory가 기본으로 켜져 있고, Copilot Business와 Enterprise는 엔터프라이즈 또는 조직 소유자가 켜기 전까지 꺼져 있습니다. 두 조직에서 라이선스를 받았다면 더 제한적인 설정이 적용됩니다.
- 메모리는 만료되지만 지침은 그렇지 않습니다. 메모리는 Copilot이 작성하고, 생성에 사용된 코드와 대조해 검증되며, 계속 재사용되지 않으면 28일 뒤 삭제됩니다. 잃으면 안 되는 규칙, 예를 들어 테스트 명령과 보안 요구사항은 .github/copilot-instructions.md에 적으세요. 이 페이지가 템플릿으로 끝나는 이유입니다.
I tried out all the memory features in GitHub Copilot (User / Session / Repository / Copilot Memory)
데모 영상:Yuzubon — ゆずぼん15:00
Instruction Files & /chronicle — Teaching Copilot Your Codebase
데모 영상:Casey Irvine17:37
The latest in managing and auditing GitHub Copilot agents
데모 영상:GitHub4:12
Managing and curating Copilot Memory (official docs, public preview)
공식 문서:docs.github.com
Copilot Memory는 공개 프리뷰 중이고 설정 경로도 계속 바뀌고 있습니다. 이 페이지의 활성화 경로, 28일 만료 규칙, 저장소 메모리 페이지는 docs.github.com의 “Managing and curating Copilot Memory” 사용법과 VS Code의 “Use memory with agents” 레퍼런스에서 가져왔습니다. 로컬 메모리 폴더 경로는 녹화 영상 자체에서 확인한 Windows 기준이므로, macOS와 Linux에서는 같은 VS Code global storage 디렉터리 아래의 해당 경로로 바꿔 읽으세요.
스크린샷은 출처 녹화를 명시했고 각 단계는 해당 초로 연결됩니다. 본문 단계, 비교표, 템플릿은 이 페이지의 오리지널이며 자막을 옮기지 않았습니다.
12단계 전체: 디스크의 폴더에서 커밋하는 지침 템플릿까지
Copilot이 기억하는 것과 저장 위치
- 1
설정을 건드리기 전에 메모리 폴더부터 확인하기
VS Code 메모리 도구는 내 컴퓨터에 일반 Markdown 파일을 쓸 뿐, GitHub로 보내지 않습니다. Windows에서는 %APPDATA%\Code\User\globalStorage\github.copilot-chat\memory-tool\memories\ 아래에 있고, 스크린샷의 coding-style.md도 바로 이 디렉터리에 있습니다. macOS는 ~/Library/Application Support/Code/User/globalStorage/, Linux는 ~/.config/Code/User/globalStorage/이며 그 아래 github.copilot-chat/memory-tool/memories 경로는 같습니다. 여기 있는 파일은 커밋되지 않아 동료가 읽을 수 없고, 파일을 지우면 메모리도 사라집니다.
memory-tool 폴더를 연 파일 탐색기: VS Code 로컬 메모리 도구를 이루는 Markdown 파일들입니다.영상 3:26 보기 - 2
사용자 메모리는 가장 먼저 로드되는 파일
채팅에서 취향을 말해 보세요. “I prefer early returns and longer, descriptive variable names”라고 하면 메모리 도구가 사용자 메모리 파일을 만들고 응답에서도 그 사실을 알려 줍니다. 스크린샷에서는 coding-style.md가 globalStorage › github.copilot-chat › memory-tool › memories에서 열려 있고, 채팅 패널이 “Reviewed memory file coding-style.md”를 표시하며 파일이 생성되었음을 확인해 줍니다. 사용자 메모리는 모든 대화에 자동으로 주입되는 유일한 범위이며, VS Code 문서는 상한을 처음 200줄로 안내합니다. 200줄이 아니라 쓸모 있는 10줄을 쓰세요.
의도적으로 짧게 유지한 사용자 메모리. 채팅이 기록한 파일을 확인해 줍니다.영상 3:56 보기 - 3
세션 메모리는 다시 설명하지 않아도 되는 계획서
세션 메모리는 플랜 모드에서 진가를 발휘합니다. Plan을 선택한 상태로 변경을 요청하면 에이전트가 구현 계획을 /memories/session/plan.md에 저장하고, 그 대화에서만 참조할 수 있게 합니다. VS Code 문서는 Session을 “현재 대화 전용”이라고 설명합니다. Agent 모드로 돌아온 뒤에는 다시 입력하지 말고 이 계획을 가리키면 됩니다. 세션 메모리는 수명이 가장 짧은 범위이기도 해서 마지막 접근 후 14일이 지나면 버려집니다. 다음 달에도 필요한 결정은 여기에 두지 마세요.
Plan 모드로 바꾼 Copilot Chat에 TODO 앱의 update 함수 추가를 요청하는 장면. 에이전트가 세션 메모리에 계획을 쓰게 되는 순간입니다.영상 7:06 보기
저장소 메모리와 GitHub 클라우드 계층
- 4
저장소 메모리는 직접 켜기 전까지 로컬에 남습니다
“in this repository, remember that every new function needs a test”라고 말하면 에이전트가 이를 /memories/repo/에 기록합니다. 여전히 내 디스크에 있고, 팀에는 보이지 않으며, 설정 하나를 바꾸기 전까지 GitHub 서버에도 올라가지 않습니다. 스크린샷은 그 요청을 입력하는 장면입니다. 사람들이 흔히 “Copilot memory folder”라고 부르는 범위가 이것입니다. 폴더는 실제로 존재하지만 저장소 안이 아니라 VS Code global storage 안에 있으므로 프로젝트에서 검색해도 찾을 수 없습니다.
저장소 규칙을 Copilot에게 기억시키는 요청. 이 쓰기는 로컬 저장소 범위에 들어갑니다.영상 10:00 보기 - 5
클라우드 스위치를 켜면 새 메모리만 옮겨 갑니다
Copilot Memory는 이 구조에서 GitHub가 호스팅하는 쪽이며, VS Code에서는 별도로 켜야 합니다. github.copilot.chat.copilotMemory.enabled를 .vscode/settings.json에 추가하세요. VS Code 문서는 copilotMemory를 옵트인 항목으로 다루고 로컬 메모리 도구와 분리해 설명합니다. 이 값이 true가 되면 기존에 /memories/repo/로 들어가던 쓰기가 GitHub로 전송됩니다. 바뀌지 않는 점이 두 가지 있습니다. 기존 로컬 저장소 메모리는 이전되지 않고, 도구는 생성만 합니다. 호스팅 메모리를 확인하거나 삭제하려면 GitHub로 가야 합니다.
저장소 메모리의 저장 위치를 로컬 폴더에서 GitHub로 돌리는 .vscode/settings.json 편집입니다.영상 13:10 보기 - 6
메모리 확인과 삭제는 설정이 아니라 저장소에서
공식 문서가 안내하는 페이지입니다. Repository → Settings → Code & automation → Copilot → Memory이며 Preview로 표시됩니다. 메모리는 최신순으로 본문과 태그가 함께 나열되고, 휴지통 아이콘은 한 건을, 체크박스는 여러 건을 삭제합니다. 삭제가 중요한 이유는 잘못된 메모리가 메모리 없음보다 나쁘기 때문입니다. Copilot은 각 메모리를 생성에 사용된 인용과 대조해 검증하고 그 코드가 바뀌면 무시하지만, 잘못 읽고 만든 메모리는 이 검사를 계속 통과합니다. 메모리는 28일 뒤 스스로 만료되기도 합니다.
저장소 설정 안의 GitHub Copilot memory 페이지. 저장된 메모리 한 건과 그 옆의 삭제 버튼.영상 12:09 보기
팀에 켜 준 뒤 지침 작성하기
- 7
엔터프라이즈와 조직 소유자가 먼저 켜야 합니다
누가 무엇을 하는지는 플랜이 정합니다. 개인 Copilot Pro와 Pro+는 Copilot Memory가 기본으로 켜져 있고 Settings → Copilot → Features에서 끌 수 있습니다. Copilot Business와 Enterprise는 반대로 소유자가 켜기 전까지 꺼져 있습니다. 엔터프라이즈 소유자는 AI Controls → Copilot → Features에서 Let organizations decide, Enabled everywhere, Disabled everywhere 중에 고르고, 조직 소유자는 Organization settings → Code, planning and automation → Copilot → Policies → Features → Copilot Memory → Enabled에서 켭니다. 두 조직이 라이선스를 할당했다면 더 제한적인 설정이 적용됩니다.
엔터프라이즈 AI Controls. Copilot Memory 활성화 정책이 이 페이지 묶음에 있습니다.영상 1:06 보기 - 8
사용자 지정 지침은 .github 폴더에서 시작합니다
메모리는 Copilot이 쓰고, 지침은 여러분이 써서 커밋합니다. 일을 하는 파일은 두 개입니다. 저장소 전체에 적용되는 규칙은 .github/copilot-instructions.md, 일부 경로에만 적용되는 규칙은 .github/instructions/NAME.instructions.md이며 후자는 Copilot이 만지는 파일과 대조됩니다. 스크린샷은 Microsoft 자체 VS Code 저장소로, .github 안에 copilot-instructions.md가 instructions/, agents/, skills/, prompts/, hooks/와 나란히 있습니다. 몇 달째 공개로 운영해 온 저장소의 형태를 그대로 따라 하세요.
microsoft/vscode의 .github 폴더. copilot-instructions.md가 instructions 디렉터리 옆에 있습니다.영상 1:40 보기 - 9
경로별 규칙은 applyTo로 정합니다
.instructions.md 파일은 YAML 프론트매터로 언제 로드될지 정합니다. name은 UI에 표시되는 라벨, description은 이 파일이 어떤 작업을 위한 것인지 에이전트에게 알려 주는 문장, applyTo는 저장소 루트 기준의 상대 glob입니다. 스크린샷에는 실제 VS Code 지시 파일의 applyTo: src/vs/workbench/contrib/chat/browser/aiCustomization/**가 보입니다. applyTo가 에이전트가 만들거나 수정하는 파일과 일치하면 VS Code가 자동으로 붙이고, description이 작업에 맞으면 필요할 때 불러오기도 합니다. 두 필드를 모두 생략하면 직접 붙일 때만 로드됩니다.
applyTo glob으로 폴더 하나에만 묶여 있는 실제 지시 파일.영상 5:20 보기
사용자 지정 지침 템플릿
- 10
개인 지침도 파일입니다
저장소 템플릿을 쓰기 전에 내 기본값이 어디에 속하는지 알아 두세요. 우선순위가 더 높기 때문입니다. Copilot CLI와 에이전트 호스트는 ~/.copilot/copilot-instructions.md를 읽고, 스크린샷에는 ## Output, ## Working style, ## AI disclosure 섹션을 갖춘 실제 예시가 보입니다. 얼마나 짧은지 눈여겨보세요. github.com에서는 Copilot Chat → 프로필 사진 → Personal instructions가 같은 역할을 하며, GitHub는 [format] 같은 자리표시자가 들어간 템플릿도 제공합니다. 우선순위는 개인, 저장소, 조직 순이고 일치하는 내용은 모두 전송되므로 두 가지가 서로 모순되지 않게 하세요.
.copilot 홈 폴더의 개인 copilot-instructions.md. output, working style, disclosure 섹션을 갖췄습니다.영상 4:10 보기 - 11
먼저 /init으로 초안을 만들고, 그다음 교체하세요
빈 파일에서 시작할 필요는 없습니다. 저장소에 지시 파일이 없으면 Copilot CLI가 “No copilot instructions found. Run /init to generate a copilot-instructions.md file for this project”를 출력합니다. 스크린샷이 바로 그 메시지입니다. /init을 실행한 뒤 결과를 아래 템플릿과 대조해 다듬으세요. 명령 목록은 정확하게 유지하고, 코드를 읽으면 알 수 있는 내용은 덜어내고, 시크릿·토큰·고객 데이터는 절대 붙여 넣지 마세요. 이 파일은 커밋되어 모든 동료와 모든 에이전트가 읽습니다.
저장소에 아직 지시 파일이 없다고 알려 주며 /init을 안내하는 Copilot CLI.영상 10:00 보기 - 12
세션이 실제로 로드한 파일 확인하기
감사할 수 없는 템플릿은 추측일 뿐입니다. Copilot CLI에서 /instructions는 세션이 불러온 지시 파일을 모두 나열합니다. 스크린샷에는 명령 위에 “Loading environment: 18 custom instructions, 3 extensions, 26 hooks, 27 skills, 4 MCP servers” 줄이 있습니다. 각 파일은 삭제하지 않고 현재 세션에서만 끌 수 있습니다. VS Code에서는 Chat: Open Customizations 뒤의 Agent Customizations 편집기가 같은 역할을 하고, 저장소 지침은 채팅 응답 상단의 참조 목록을 펼쳐 .github/copilot-instructions.md가 사용되었는지 확인할 수 있습니다.
Copilot CLI의 /instructions 명령. 세션이 어떤 컨텍스트를 불러왔는지 확인하는 가장 빠른 방법입니다.영상 7:10 보기
Copilot Memory vs 사용자 지정 지침 vs 저장소 지침
“Copilot memory”라고 불리는 서로 다른 세 가지가 있습니다. 에이전트가 쓰는 것은 첫 번째뿐이고, 나머지 둘은 여러분이 커밋해 유지하는 파일입니다. 이 비교는 우열을 가리는 표가 아니라 두 기능이 나란히 존재하는 이유를 보여 줍니다. 아무도 적어 두지 않은 관례에는 메모리를, 근거를 댈 수 있는 규칙에는 지침을 쓰세요.
| 항목 | Copilot Memory(호스팅) | 사용자 지정 지침(.github/copilot-instructions.md) | 경로 지침(.github/instructions/*.instructions.md) |
|---|---|---|---|
| 무엇인가 | Copilot이 저장소에서 작업하며 추론한 사실. 주제와 이를 뒷받침하는 인용의 조합으로 저장됩니다. | 한 번 작성하면 저장소의 모든 요청에 적용되는 규칙. | 저장소 안 특정 경로, 언어, 폴더에만 적용되도록 작성하는 규칙. |
| 작성자 | Copilot이 자동으로. 기능을 켠 사용자의 작업을 계기로 기록합니다. | 여러분이 직접. Markdown으로 작성합니다. | 여러분이 직접. YAML 프론트매터가 있는 Markdown으로 작성합니다. |
| 저장 위치 | GitHub에 있으며 하나의 저장소에만 적용됩니다. 확인과 삭제는 Repository → Settings → Copilot → Memory에서 합니다. 작업 트리에는 파일이 없습니다. | 저장소 안, 프로젝트 루트의 .github/copilot-instructions.md. | 저장소 안 .github/instructions/ 아래에 범위마다 파일 하나. |
| 로드 시점 | 자동. 다만 인용이 현재 브랜치와 대조해 검증을 통과한 뒤에만. | 해당 저장소의 모든 요청에. 채팅, 에이전트, code review 모두. | applyTo glob이 관련 파일과 일치할 때, 또는 에이전트가 description을 관련 있다고 판단할 때만. |
| 유지 기간 | 28일. 검증되어 다시 쓰인 메모리는 재작성되어 수명이 늘어납니다. | 누군가 파일을 바꾸거나 지울 때까지. 코드와 함께 버전 관리됩니다. | 누군가 파일을 바꾸거나 지울 때까지. |
| 볼 수 있는 사람 | 해당 저장소에서 Copilot Memory를 켠 모든 사람. 메모리는 저장소를 벗어나지 않습니다. | 저장소에 접근할 수 있는 모든 사람, 그리고 이를 읽는 모든 에이전트와 리뷰어. | 저장소에 접근할 수 있는 모든 사람. |
| 수정 방법 | 저장소 설정에서 삭제합니다. 메모리 도구는 생성만 하고 확인이나 삭제는 할 수 없습니다. | 다른 파일처럼 Pull Request를 올립니다. | 다른 파일처럼 Pull Request를 올립니다. |
| 잘 맞는 용도 | 아무도 문서화하지 않은 관례, 리뷰어가 반복해서 지적하는 수정 방식, 이 코드베이스의 안전한 패턴. | 스택과 버전, 정확한 빌드·테스트 명령, 폴더 구조, 보안과 리뷰 규칙. | 모노레포의 프레임워크 규칙, 테스트 파일 관례, 특정 폴더의 스타일, 특정 언어의 관용구. |
Copilot이 실제로 필요로 하는 여섯 가지를 담은 사용자 지정 지침 템플릿
GitHub 자체 지침은 파일을 짧고 구체적으로 유지하라는 것입니다. 스택이 무엇인지, 어떻게 실행하는지, 코드가 어디 있는지, 어떤 규칙이 필수인지, 무엇을 피해야 하는지. 아래 블록은 복사한 뒤 덜어내도록 작성했습니다. 에이전트가 저장소를 읽으면 알 수 있는 줄은 삭제하세요. 비대해진 지침 파일은 정작 중요한 규칙을 희석합니다. 저장소 루트에 .github/copilot-instructions.md로 저장하세요.
# .github/copilot-instructions.md
## Project and stack
- Next.js 15 app router, TypeScript strict, Node 22.
- Package manager: pnpm. Never run npm or yarn install.
## Commands
- Build: pnpm build
- Lint: pnpm lint
- Test everything: pnpm test
- Test one file: pnpm test -- path/to/file.test.ts
## Layout
- Routes: src/app/**
- UI components: src/components/**
- Data access: src/lib/db.ts and src/lib/repositories/**
- Tests live next to the file they cover: *.test.ts
## Conventions
- Named exports only; no default exports from src/lib.
- Handle errors at the boundary and return early instead of nesting.
- Import order: node builtins, external packages, then @/ aliases.
## Testing and review
- Every behaviour change ships with a test in the same pull request.
- Run the single-file test before requesting review.
- Commit messages follow Conventional Commits.
## Do not
- Do not edit files under src/generated/**.
- Do not add a dependency without calling it out in the pull request.
- Do not log secrets, tokens or full request bodies.- 1프로젝트와 스택: 프레임워크, 언어 모드, 패키지 관리자를 한 줄로 명시하세요. 에이전트가 npm, pnpm, yarn 사이에서 추측해 요청하지도 않은 lockfile을 만드는 것을 막는 블록입니다.
- 2명령: 빌드, lint, 테스트, 단일 파일 테스트의 정확한 명령을 기억이 아니라 CI 설정에서 복사하세요. 테스트 명령을 잘못 적는 것이 가장 비싼 한 줄입니다.
- 3구조: 라우트, 컴포넌트, 데이터 접근, 테스트가 어디 있는지. 아키텍처를 문장으로 설명하지 말고 디렉터리를 가리키세요. 경로는 검증할 수 있지만 문단은 그렇지 않습니다.
- 4규칙: 이름 짓기, 오류 처리, import 순서, 팀이 실제로 지키는 포맷 규칙. 각 규칙은 이분법으로 판정할 수 있어야 합니다. 코드가 지키거나, 지키지 않거나 둘 중 하나입니다.
- 5테스트와 리뷰: 어떤 변경에 테스트가 필수인지, 리뷰가 무엇을 확인해야 하는지, 커밋과 브랜치 규칙. 메모리에 의존할 수밖에 없던 것을 보장으로 바꿔 주는 블록입니다.
- 6하지 말 것: 안티패턴. 생성된 파일, 말없이 추가하는 의존성, 무관한 리팩터링, 로그에 남는 시크릿. 나쁜 Pull Request 한 부류를 통째로 막는 가장 저렴한 방법은 금지 규칙입니다.
두 번째 파일로 범위 좁히기
폴더별 규칙을 .github/instructions/ 아래 별도 파일로 옮기면 저장소 파일을 짧게 유지할 수 있습니다. 핵심은 프론트매터입니다. applyTo가 일치하는 경로에 파일을 자동으로 붙이고, description이 에이전트로 하여금 맞는 작업에서 불러오게 합니다. VS Code는 지원 필드로 name, description, applyTo를 문서화합니다.
---
name: 'React components'
description: 'Use when creating or updating components under src/components.'
applyTo: 'src/components/**/*.tsx'
---
# React components
- One component per file, named after the file.
- Props are typed with an explicit interface; no React.FC.
- Colocate styles with the component; no global class names.내 취향은 저장소 파일에 넣지 마세요
프로젝트가 아니라 나에 관한 것, 예를 들어 답변 길이, 말투, diff 설명 방식은 개인 지침에 두세요. Copilot CLI와 에이전트 호스트는 ~/.copilot/copilot-instructions.md를 읽고, github.com에서는 Copilot Chat을 열어 프로필 사진을 클릭하고 Personal instructions를 선택합니다. GitHub는 [format] 같은 자리표시자가 있는 템플릿도 제공합니다. 개인 지침은 저장소와 조직 지침보다 우선하므로, 거기서 설정한 취향을 저장소마다 반복할 필요가 없습니다.
모든 블록에 적용되는 마지막 두 가지 규칙입니다. 커밋되는 지침 파일에 시크릿, 토큰, 고객 데이터를 넣지 마세요. 그리고 저장소 지침과 메모리가 서로 다른 말을 하게 두지 마세요. 충돌하면 Copilot은 두 컨텍스트를 가능한 범위에서 따르려 하므로 결과를 예측할 수 없습니다. 메모리가 작성한 규칙과 계속 모순된다면 규칙을 약화하지 말고 메모리를 삭제하세요.