CLAUDE.md나 copilot-instructions.md는 AI 에이전트에게 "이 프로젝트의 규칙을 처음부터 가르치기" 위한 파일입니다.

한 번 작성하면 끝이라고 생각하는 사람이 많겠지만, 사실 이것은 매 턴(Turn)·매 요청(Request)마다 은근슬쩍 컨텍스트(Context)에 계속 포함된다는 성질을 가지고 있습니다.

이 부분을 올바르게 정비하면, "설계서 → 코드", "코드 → 설계서"와 같은 무거운 태스크에서도 비용을 줄일 수 있는 가능성이 있습니다.

※ AI 에이전트는 나날이 진화하고 있으므로 정보가 오래되었을 가능성이 있습니다. 이번에 소개하는 내용은 2026년 6월 7일 시점의 정보입니다.

CLAUDE.md와 copilot-instructions.md는 매 요청·매 턴 자동으로 컨텍스트에 포함되기 때문에, 작성법을 잘못 선택하면 토큰을 낭비하는 설정 파일이 됩니다.

• "코드에서 알 수 있는 것은 쓰지 않는다", "수백 토큰 이내로 제한한다"와 같은 규칙으로 설계하면, 성공률을 떨어뜨리지 않으면서 비용을 억제할 수 있습니다.
• "설계서 → 코드"에서는 프롬프트 캐싱(Prompt Caching)을, "코드 → 설계서"에서는 서브 에이전트(Sub-agent) 분리를 조합하면 무거운 태스크라도 현실적인 비용 범위 내로 들어올 수 있습니다(가능성이 있습니다).

토큰이 의도치 않게 소모되는 메커니즘을 이해하지 못하면 대책이 빗나갈 수 있습니다.

Anthropic 공식 문서에 다음과 같이 명시되어 있습니다.

(출처: Anthropic 공식 — Messages API 사용)

"Messages API는 스테이트리스(Stateless)입니다. 즉, 항상 API에 완전한 대화 이력을 전송합니다."

대화의 "상태(State)"를 서버는 기억하지 않습니다. 당신이 10번째 턴에서 메시지를 보냈을 때, 서버에 전달되는 것은 이것입니다.

10번째 턴의 API 요청 (실제로 서버로 전송되는 것):
시스템 프롬프트 (Claude Code의 내부 지시)
+ CLAUDE.md의 내용 ← 매번 포함됨
...

"지금의 메시지만 보내는 것"이 아닙니다. 대화 전체가 매번 API로 재전송됩니다.

5,000 토큰 분량의 CLAUDE.md가 있다고 가정해 봅시다. 캐시를 고려하지 않은 단순 계산으로는, 20 턴의 세션에서 CLAUDE.md에 해당하는 내용이 5,000 × 20 = 100,000 토큰 분량의 입력이 됩니다. 한 마디도 입력하기 전에 발생하는 고정 비용입니다.

GitHub Copilot이 대화 이력을 어디까지 재전송하는지에 대한 내부 사양은 공개된 정보만으로는 단정할 수 없습니다. 다만, 일반적인 LLM 에이전트와 마찬가지로 매번 컨텍스트를 구성하는 설계일 가능성이 높습니다.

즉, copilot-instructions.md에 한 줄을 추가할 때마다, 팀원 전체의 모든 요청에 대한 토큰 소비가 늘어날 위험이 있습니다.

6월 1일부터 GitHub Copilot은 토큰 종량제(Pay-as-you-go)로 전환되었습니다.

입력도 출력도 캐시도 모두 토큰 단위로 과금됩니다. 설정 파일은 매 요청마다 포함되므로 무시할 수 없는 비용이 됩니다.

"CLAUDE.md나 AGENTS.md를 잘 작성하면 에이전트가 정확하게 동작한다"는 것은 2025년부터 Anthropic이나 GitHub이 권장해 온 내용입니다.

하지만 이를 과학적으로 검증한 논문이 2026년 2월에 발표되었고, 복잡한 결론이 도출되었습니다.

ETH Zurich / LogicStar.ai 팀이 138개 태스크·12개 리포지토리·4개 에이전트로 비교한 결과는 다음과 같습니다.

(출처: arXiv:2602.11988)

당시 Hacker News(미국판 하테나 북마크 + 기술 게시판 같은 대형 테크 사이트)에서도 큰 화제가 되었던 것으로 보입니다. 특히 주목받은 점은 "LLM이 자동 생성한 설정 파일은 성공률을 평균 3% 정도 저하시켰다"는 점, 그리고 인간이 정성스럽게 작성하더라도 개선은 +4% 정도에 그치며 비용은 증가한다는 결과입니다.

또한 다른 논문(동일한 ETH Zurich 계열)에서는 AGENTS.md를 적절히 작성한 사례에서 실행 시간 중앙값이 28.64% 감소하고, 출력 토큰 소비가 16.58% 감소했다는 결과도 나와 있습니다.

（출처: arXiv:2601.20404）

요약하자면

대충 작성하기 (/init 자동 생성) → 성공률 감소, 출력 토큰 절감 효과 없음

올바르게 작성하기 (사람이 정밀 검토) → 실행 시간 단축, 출력 토큰 절감

'그냥 쓰기만 하면 되는 것'이 아니라 '올바르게 쓰는 것'이 중요합니다.

※ 여기서 소개한 논문은 영문 PDF이므로, Chrome 확장 기능인 Immersive Translate 등을 사용하여 번역하며 확인하는 것을 추천합니다.

olivomarco.github.io — GitHub Copilot Token Optimization Guide가 4가지 메커니즘으로 정리하고 있으며, 위 arXiv 논문의 내용과 일치합니다.

① 중복 비용 (Redundancy tax)

LLM이 생성한 설정 파일에는 에이전트가 코드를 읽으면 스스로 발견할 수 있는 내용이 적혀 있습니다.

# 에이전트가 package.json을 읽으면 알 수 있는 것 (쓸 필요 없음)
이 프로젝트는 TypeScript를 사용하고 있습니다.
테스트에는 Vitest를 사용하고 있습니다.

단지 토큰만 늘릴 뿐, 새로 알 수 있는 정보는 제로입니다. 완전한 낭비입니다.

② 주의력 비용 (Attention tax)

LLM의 컨텍스트에 대한 주의력은 'U자형'입니다. 처음과 끝은 읽지만, 중간 부분은 놓치기 쉽다고 합니다.

200행의 CLAUDE.md를 작성했다고 가정할 때, 50~150행에 작성한 규칙은 무시될 수도 있습니다. 가장 지켜줬으면 하는 규칙일수록 파일의 중간 부분에 적게 되지 않나요? 그것이 무시될 (가능성이 있는) 상황은 곤란하겠지요.

③ 앵커링 함정 (Anchoring trap)

에이전트는 설정 파일의 내용에 과도하게 얽매입니다. 논문에 따르면, 설정 파일에서 특정 도구를 언급하면 (설령 그 상황에서는 다른 도구가 더 적절하더라도) 해당 도구의 사용 빈도가 대폭 증가하는 것으로 나타났습니다 (예: uv에 대한 언급이 있는 경우, 태스크당 사용 횟수가 약 160배로 증가).

④ 본질적인 정보 비율의 저하 (Signal-to-noise ratio)

모든 토큰이 모델의 주의력을 쟁탈합니다.

# 노이즈 (저가치 정보)
이 프로젝트는 ES 모듈을 사용하고 있습니다 ← tsconfig.json을 보면 알 수 있는 내용
# 시그널 (고가치 정보)
...

Google Cloud AI Director의 Addy Osmani가 제시한 심플한 기준이 있습니다.

"에이전트가 코드를 읽으면 스스로 발견할 수 있는 정보인가? 그렇다면 삭제하라."

# 남겨두어야 할 정보 (코드에서 발견할 수 없는 것)
- "uv를 사용할 것. pip는 불가"
- "src/auth/는 변경 금지 (보안 감사 중)"
...

Anthropic 공식 입장도 같은 방향입니다.

"각 행에 대해 다음과 같이 질문하십시오. '이것을 삭제하면 Claude가 실수를 저지르는가?' 그렇지 않다면 삭제하십시오. 비대해진 CLAUDE.md 파일은 Claude가 당신의 실제 지시를 무시하게 만듭니다."

(출처: Anthropic 공식 — Claude Code의 베스트 프랙티스)

Claude Code 공식 측에서도 '비대해진 CLAUDE.md는 무시되기 쉽다'고 경고하고 있으므로, (공식적으로 명확한 수치는 나오지 않았지만) 500토큰 이내를 기준으로 삼는 것이 안전하다고 저는 생각합니다.

"설계서 → 코드" 이야기로 들어가기 전에, 프롬프트 캐싱 (Prompt Caching)의 실제 메커니즘을 정리하겠습니다. 이 부분을 오해하면 대책이 빗나갈 수 있습니다.

Anthropic 공식 문서에는 캐시 대상이 다음과 같이 적혀 있습니다 (출처: Anthropic 공식 — 프롬프트 캐싱).

"프롬프트 캐싱은 cache_control로 지정된 블록까지, 해당 순서대로 tools, system, 그리고 messages를 포함하는 완전한 프롬프트를 참조합니다."

"정적 콘텐츠(도구 정의, 시스템 지시, 컨텍스트, 예시)를 프롬프트의 처음에 배치하십시오. cache_control 파라미터를 사용하여 캐싱을 위한 재사용 가능한 콘텐츠의 끝을 표시하십시오."

즉 **"앞부분의 정적인 부분"**에 캐시가 적용됩니다.

한 번의 요청 안에는 "캐시가 적용되는 정적인 부분"과 "매번 풀 코스트(Full cost)로 전송되는 동적인 부분"이 혼재되어 있습니다. 경계는 "내용이 변하는가"입니다.

1회의 API 요청의 내부 구조:
[캐시가 적용되는 부분]─────────────────────
시스템 프롬프트 (Claude Code의 내부 지시)
...

왜 "CLAUDE.md는 캐시가 적용되고, 대화 이력은 적용되지 않는가"에 대한 이유는 간단합니다. "이전 요청과 완전히 일치하는 부분만 캐시가 재사용되기" 때문입니다.

• CLAUDE.md는 세션 중에 다시 쓰지 않음 → 매번 동일한 내용 → 캐시가 재사용됨
• 대화 이력은 턴이 진행될 때마다 내용이 늘어남 → 매번 다름 → 캐시가 재사용되지 않음

설계서를 어디에 두느냐에 따라 비용이 달라진다는 것은 바로 이 메커니즘 때문입니다.

설계서를 "세션 초반(첫 번째 메시지)"에 두었을 때와 "중간부터 붙여넣었을" 때 무엇이 일어나는지 비교해 보겠습니다.

【중간부터 붙여넣었을 경우】
턴 1: 안녕하세요, 인증 기능을 만들고 싶습니다
턴 2: 오늘의 작업 내용을 확인했습니다
...

【초반에 두었을 경우】
턴 1: 다음 설계서에 따라 구현해 주세요.
---설계서---
(10,000 토큰)
...

공식 요금 체계에서는 캐시 쓰기가 일반 입력보다 높고, 이후의 캐시 읽기는 상당히 저렴하기 때문에, 재사용 횟수가 적은 단계에서도 효과가 나타나기 쉬운 설계입니다.

캐시의 TTL(Time To Live)을 1시간으로 설정하는 옵션도 있는 것으로 보이며, 이 경우 캐시 쓰기 시의 비용이 일반 입력의 200%가 됩니다.

출처: Anthropic 공식 — 프롬프트 캐싱, Anthropic 공식 — 요금

"이전 요청과 완전히 일치하는 부분만 캐시가 적용된다"는 메커니즘이므로, 정적이어야 할 부분이 바뀌면 캐시가 깨집니다.

캐시가 깨지는 작업

• 세션 도중에 모델을 전환함
• CLAUDE.md에 타임스탬프나 날짜를 작성함 (매번 바뀌므로 당연함)
• 도구 정의 (Tool Definition)의 순서를 바꿈
• CLAUDE.md를 메모 대용으로 세션 중에 다시 작성함

"태스크 시작 전에 설정을 확정한다. 세션 중에는 바꾸지 않는다"가 철칙입니다.

각 도구에서 읽히는 파일을 정리합니다.

GitHub Copilot의 프롬프트 엔지니어링 (Prompt Engineering) 공식 문서:

• 프롬프트 엔지니어링: docs.github.com/en/copilot/concepts/prompting/prompt-engineering
• 베스트 프랙티스: docs.github.com/en/copilot/get-started/best-practices

솔직히 말해서, GitHub의 공식 문서는 토큰 비용 절감 관점이 부족한 것이 현상태입니다. 더 실전적인 것은 커뮤니티의 github/awesome-copilot 이나 olivomarco.github.io/github-copilot-token-optimization 입니다.

지금까지 입력 토큰에 대해 이야기해 왔지만, Anthropic 공식 가격표를 보면 출력 토큰은 입력의 5배가 비싸다는 구조가 있습니다 (출처: Anthropic 공식 — 요금).

Claude Sonnet 4.6의 경우:
입력 토큰: $3 / MTok
출력 토큰: $15 / MTok (5배)

AI는 설명을 좋아합니다.

채팅 상대방으로서의 AI (Chappie 같은 용도)라면 괜찮지만, 코드 생성에서는 곤란합니다.

50줄의 코드를 반환하면서 200 토큰의 설명문을 덧붙인다면, 그것이 매번 쌓이게 됩니다.

해결책은 간단합니다. copilot-instructions.md 또는 CLAUDE.md에 다음 내용을 추가하는 것뿐입니다.

# copilot-instructions.md / CLAUDE.md 에 추가 (모든 요청에 적용)
Be concise. No explanations unless asked.
Code only for code generation tasks.
...

# 한국어로 하면
간결하게. 요청받지 않는 한 설명은 불필요.
코드 생성 태스크에 대해서는 코드만 작성할 것.
...

(출처: olivomarco.github.io — Output Control)

코드 생성 태스크의 출력 토큰이 40~70% 절감됩니다 (출처: 위와 동일). 한 번만 작성하면 모든 요청에 적용되므로 가성비가 매우 높은 대책입니다.

최근에는 케이브맨 (Caveman) 프롬프트도 토큰 절감에 유효하다고 알려져 있지만, 출력된 설계서까지 원시인 언어처럼 변해버릴 수 있으므로 주의가 필요합니다.

설계서는 세션 중에 변하지 않는 "정적 텍스트 (Static Text)"입니다. 하지만 사용법을 잘못 알고 있으면 매 턴 전체 내용이 재전송됩니다.

10,000 토큰의 설계서를 사용하여 40 턴의 세션을 진행하면, 설계서만으로 400,000 토큰의 입력 비용이 발생합니다. GitHub Copilot의 종량제 요금 (Claude Sonnet 4.6 기준, 입력 $3/MTok)으로 환산하면 $1.20입니다. 팀원 5명이 매일 사용한다면 월 $900의 고정 비용이 됩니다.

하지만 프롬프트 캐싱 (Prompt Caching)을 적용하고 그것이 제대로 작동한다면 최대 1/10까지 줄어들 수도 있습니다.

앞서 설명한 캐시 메커니즘에서 언급했듯이, 설계서를 세션의 첫 번째 메시지에 배치함으로써 캐시가 작동하도록 만들 수 있습니다.

중간에 붙여넣었을 때와의 차이를 실제 프롬프트로 비교해 보겠습니다.

(앞서 설명한 프롬프트 캐싱에 대한 설명과 일부 중복되지만, 중요한 내용이므로 다시 설명합니다)

비용이 높은 패턴 (중간에 붙여넣기)

턴 1

안녕하세요, 인증 기능을 만들고 싶습니다.

턴 2

오늘의 작업 내용을 확인했습니다.

턴 3 (여기서 설계서를 붙여넣음)

이것이 설계서입니다.
기술 스택
- JWT: 액세스 토큰 15분, 리프레시 토큰 7일
...

설계서가 턴 3의 대화 이력에 포함되어 버립니다. 턴 4 이후부터 설계서는 "매번 풀 코스트(Full Cost)로 전송되는 부분"에 계속 머물게 됩니다.

비용이 낮은 패턴 (맨 앞에 배치)

턴 1 (첫 번째 메시지에 설계서 포함)

다음 설계서에 따라 인증 기능을 구현해 주세요.
---설계서---
## 기술 스택
...

첫 번째 메시지에 설계서가 포함되면 캐시 히트 (Cache Hit)가 일어나기 쉬운 구조가 됩니다. 턴 2 이후부터는 설계서 부분이 캐시에서 읽히므로 비용이 대폭 감소합니다.

이 프롬프트는 GitHub Copilot (Agent mode)에서도 거의 그대로 사용할 수 있습니다.

사람을 위한 설계서를 그대로 전달하는 것은 비효율적입니다. 경위, 배경, 향후 계획은 불필요한 토큰입니다.

비용이 높은 패턴 (사람용 설계서를 그대로 전달)

# 인증 기능 설계서
## 배경 및 경위
2024년 Q3에 기존 인증 시스템이 확장성(Scalability) 문제를 안고 있음이 판명됨.
...

비용이 낮은 패턴 (AI용으로 다시 작성)

# 인증 기능 구현 사양 (AI 전달용)
## 스택 및 설정
- JWT: 액세스 토큰 15분 / 리프레시 토큰 7일
...

삭제한 것: 경위, 배경, 향후 계획, README와 중복되는 정보. 남긴 것: 현재 세션에서 구현하는 데 필요한 정보만. 이 방식 역시 Claude Code와 GitHub Copilot 모두에서 사용할 수 있습니다.

거대한 설계서를 그대로 던져서 일괄 구현하게 하는 것은 컨텍스트 (Context)를 가장 많이 소비하는 패턴입니다.

프롬프트 예시 (기능별 세션)

【세션 1: 로그인 처리만 구현】

다음 사양"만"을 참조하여 구현해 주세요.
리프레시 및 로그아웃은 이번 스코프(Scope) 외입니다.
---스코프---
...

"설계서의 다른 섹션은 이번에 참조하지 마세요"라는 문구가 중요합니다. 이것이 없으면 Copilot이 관련 파일을 광범위하게 읽으려고 시도합니다. 이 프롬프트는 Claude Code와 GitHub Copilot 모두에서 사용할 수 있습니다.

이것은 반대의 문제입니다. 코드는 캐싱(Caching)도 압축(Compression)도 거의 효과가 없습니다. 이전에 다른 기사에서 소개했던 Headroom가 코드를 의도적으로 압축하지 않도록 설계된 이유도 정확도가 떨어지기 때문입니다.

"이 리포지토리에서 설계서를 만들어줘"라는 지시를 내리면, 에이전트(Agent)는 차례차례 파일을 읽어 들여 컨텍스트(Context)가 폭발합니다.

서브 에이전트(Sub-agent)는 메인 세션(Main session)과는 독립된 컨텍스트 윈도우(Context window)에서 동작합니다. 50개의 파일을 읽어 중간 과정을 쌓더라도, 메인 세션에는 최종 결과만 반환됩니다.

메인 세션 (깨끗한 상태 유지):
당신의 지시
↓ 서브 에이전트 기동
...

VS Code 공식 문서에는 서브 에이전트의 동작이 다음과 같이 기술되어 있습니다 (출처: VS Code Docs — Agents).

"Context isolation: each subagent runs in its own context window. It doesn't inherit the main agent's conversation history or instructions. It receives only the task prompt."

"Focused results: only the final result is returned to the main agent, keeping the main context focused and reducing token usage."

(각 서브 에이전트는 독자적인 컨텍스트 윈도우에서 실행된다. 메인 에이전트의 대화 기록이나 지시 사항을 상속받지 않으며, 태스크 프롬프트(Task prompt)만을 받는다. 최종 결과만이 메인 에이전트에게 반환되어, 메인 컨텍스트를 집중시키고 토큰 사용량을 줄인다.)

비용이 높은 패턴 (컨텍스트가 폭발하는 경우)

src/ 하위 디렉토리를 전부 읽어서 인증 플로우(Authentication flow) 설계서를 만들어 주세요

비용이 낮은 패턴 (서브 에이전트를 의식한 지시)

src/auth/ 하위의 인증 플로우를 조사해서,
다음 정보"만" 반환해 주세요.
1. 등장하는 클래스와 역할 (클래스당 1행, 최대 10행)
...

"코드 자체는 반환하지 않는다"와 "위의 3개 항목에 포함되지 않는 정보는 생략한다"가 중요합니다. 탐색 범위는 넓더라도, 메인으로 돌아오는 정보량을 컨트롤 합니다.

나아가 Claude Code에서의 고도화된 활용법으로, 탐색 전용 서브 에이전트를 Markdown으로 정의해 둘 수도 있습니다.

# .claude/agents/code-analyzer.md
---
name: code-analyzer
...

분석용 서브 에이전트에 Haiku 모델을 할당하고, 메인에만 Opus를 사용하는 조합이 효과적입니다.

GitHub Copilot은 VS Code의 서브 에이전트와 같은 명시적인 "별도 컨텍스트"를 아직 가지고 있지 않지만, "세션을 기능별로 나누고 요약본만을 메모로 남기는" 방식을 통해 실질적으로 동일한 효과를 얻을 수 있습니다.

갑자기 "이 리포지토리에서 설계서를 만들어줘"라고 부탁하는 대신, 우선 디렉토리나 책임(Responsibility) 단위로 나누어 대화합니다.

src/auth/만 대상으로 "인증 관련 흐름"을 정리한다

src/payment/만 대상으로 "결제 관련 흐름"을 정리한다

src/notify/만 대상으로 "알림 관련 흐름"을 정리한다

이 시점에서는, 각 세션에서 "전체 설계서"를 쓰게 하지 않는 것이 포인트입니다. 어디까지나 "해당 모듈의 구조와 동작의 요약"만을 출력하도록 합니다.

각 세션에서는 Copilot에 대해 처음부터 출력 포맷을 상당히 좁혀둡니다.

src/auth/ 하위만을 대상으로, 인증 플로우의 개요를 알려주세요.
【출력 조건】
1. 주요 클래스 / 함수와 역할 (1행 1요소, 최대 10행)
...

이렇게 얻은 요약은 리포지토리의 notes/ 하위나 docs/_generated/ 등에 짧은 Markdown으로 저장해 둡니다. Copilot은 파일 내용을 컨텍스트로 읽을 수 있으므로, 다음 세션부터는 "원본 코드"가 아니라 "요약 메모"를 읽게 하면 된다는 상태를 만들 수 있습니다.

모듈별 요약 메모가 모두 갖춰지면, 별도의 세션에서 그것들만을 컨텍스트로 읽어 들여 전체 설계서를 작성하게 합니다.

다음 3개의 요약 Markdown 파일만을 참조하여, 이 시스템 전체의 인증·결제·알림 플로우(flow) 설계서를 작성해 주세요.
- notes/auth-summary.md
- notes/payment-summary.md
...

이렇게 하면, 「코드 → 요약」 단계에서는 컨텍스트(context)가 팽창하더라도 그 이력은 다음 세션으로 넘어가지 않습니다. 반면, 「요약 → 설계서」 단계에서는 컴팩트한 요약 파일만을 사용하여 설계서를 구성할 수 있습니다.

CLAUDE.md나 copilot-instructions.md는 "쓰면 끝"이 되기 쉽지만, 매 턴·매 요청마다 계속해서 실리는 비용을 가진 파일입니다.

대충 작성하면 오히려 역효과가 납니다. Anthropic의 공식적인 표현을 빌리자면 "CLAUDE.md는 코드와 마찬가지로 정기적으로 리뷰하고 가지치기(pruning)해야 한다"가 올바른 접근 방식입니다.

6월의 Copilot 요금 개정으로 토큰(token) 절약 이야기가 어디에서나 나오고 있지만, **가장 효율적인 것은 "처음부터 불필요한 토큰을 싣지 않는 것"**입니다. 화려한 도구를 사용하지 않더라도, 설정 파일의 정리만으로 체감할 수 있는 변화가 있습니다.

지금은 바로 생성형 AI의 과도기이므로, 몇 년 뒤에 "그 시절에는 토큰 절약 같은 걸 하고 있었지... 원시인 말이었어 ㅋㅋㅋ"라며 웃으며 이야기할 날이 올지도 모릅니다.

그렇게 바라면서도 지금은 토큰 절감에 전력을 다합시다!

※ 이번 방법과 병행하여 효과를 기대할 수 있는 토큰 절감 기법에 대해서는 아래 ↓ 기사도 참고해 주세요.

공식 문서

• Anthropic 공식 — Messages API 사용
• Anthropic 공식 — 프롬프트 캐싱 (Prompt Caching)
• Anthropic 공식 — 요금 (Pricing)
• Anthropic 공식 — Claude Code 베스트 프랙티스 (Best Practices)
• GitHub Blog — GitHub Copilot is moving to usage-based billing
• GitHub Docs — Models and pricing for GitHub Copilot
• GitHub Docs — Usage-based billing for individuals
• GitHub Docs — Prompt engineering for GitHub Copilot
• GitHub Docs — Best practices for using GitHub Copilot
• VS Code 공식 — Agents
• GitHub Blog — Agent mode vs Coding agent

학술 논문

• arXiv:2601.20404 — On the Impact of AGENTS.md Files (ETH Zurich)
• arXiv:2602.11988 — Evaluating AGENTS.md (ETH Zurich / LogicStar.ai)

실전 가이드