GitHub Blog 글은 Copilot이 코드베이스를 더 잘 이해하도록 만드는 방법을 네 가지로 정리한다. 핵심은 “질문을 잘 쓰는 법”보다 “반복해서 설명하던 프로젝트 규칙을 저장소 안에 남기는 법”에 가깝다. 개인 프로젝트든 연구 코드든 팀 저장소든, Copilot이 매번 같은 컨벤션과 실행 절차를 추측하게 두면 결과 품질이 흔들릴 수 있다.
저장소 안에 남기는 Copilot용 맥락
첫 번째 방법은 custom instructions다. 저장소 전체에 적용할 규칙은 .github/copilot-instructions.md에 둘 수 있고, 특정 경로나 파일 유형에만 적용할 규칙은 .github/instructions 아래에 둘 수 있다. GitHub Blog는 이 파일들이 아키텍처 선호, 이름 규칙, 테스트 기대치 같은 기준을 Copilot에게 전달하는 용도라고 설명한다.
개발자가 먼저 볼 지점은 “내가 Copilot에게 반복해서 설명하는 문장이 있는가”다. 예를 들어 컴포넌트 구조, 테스트 파일 위치, API 응답 처리 방식, 문서 작성 규칙을 매번 프롬프트에 넣고 있다면 저장소 지침으로 분리할 가치가 있다. 반대로 한 번만 쓰는 임시 요구사항까지 넣으면 Copilot의 기본 판단이 과하게 좁아질 수 있다.
반복 절차는 agent skill로 분리
두 번째는 agent skills다. custom instructions가 넓은 기준을 전달한다면, agent skill은 특정 절차를 묶는 방식이다. GitHub Blog는 품질 점검, 릴리스 준비, 실패한 워크플로 디버깅처럼 반복되는 작업을 예로 든다. 프로젝트 수준의 skill은 .github/skills 아래에 둘 수 있고, 각 skill 폴더에는 SKILL.md가 들어간다.
개인 사용자나 학생에게는 이 부분이 특히 실용적이다. 과제, 논문 실험 코드, 사이드 프로젝트에서 테스트 명령어가 매번 다르고 lint나 빌드 순서가 헷갈린다면, Copilot이 임의로 명령어를 고르게 두기보다 저장소에 절차를 적어두는 편이 낫다. 다만 실제 명령어, 실패 시 확인할 로그, 통과 기준을 사람이 먼저 정리해야 한다. Copilot이 프로젝트 정책을 대신 만들어주는 것이 아니라, 사람이 정한 절차를 더 일관되게 따르게 만드는 쪽에 가깝다.
넓은 역할이 필요하면 custom agent를 검토
세 번째는 custom agents다. GitHub Blog는 접근성 검토처럼 여러 파일과 관점을 함께 봐야 하는 작업을 예로 설명한다. 저장소 수준의 agent profile은 .github/agents에 둘 수 있으며, 목적, 지침, 도구, 관련 프로젝트 맥락을 정의할 수 있다.
이 기능은 “한 가지 명령을 실행하는 절차”보다 “반복되는 전문 역할”이 있을 때 의미가 커진다. 예를 들어 접근성 점검, 보안 리뷰 보조, 문서 품질 점검, 프론트엔드 상태 관리 규칙 검토처럼 매번 비슷한 관점으로 넓게 살펴야 하는 일이 있다면 custom agent 후보가 된다. 단순히 코드 한 줄을 고치는 작업이라면 custom instructions나 skill만으로도 충분할 수 있다.
브라우저와 외부 도구까지 연결하는 MCP
네 번째는 MCP 서버다. instructions, skills, agents가 저장소 내부의 작업 방식을 알려준다면, MCP 서버는 Copilot이 외부 도구나 데이터 소스에 접근하도록 확장한다. GitHub Blog는 문서 서버와 Playwright MCP 서버를 예로 든다. Playwright가 구성되어 있으면 Copilot이 애플리케이션을 브라우저에서 열고 사용자가 하듯 상호작용하며 기능을 확인할 수 있다고 설명한다.
여기서는 권한과 데이터 이동 조건을 반드시 봐야 한다. 브라우저 자동화, 외부 문서, 사내 도구, 연구 데이터 저장소와 연결할수록 Copilot이 볼 수 있는 범위가 넓어진다. 업무 코드, 비공개 연구 자료, 학생 개인정보, 내부 API가 들어가는 환경에서는 연결 자체보다 접근 범위와 로그, 보존 정책, 계정 권한을 먼저 확인해야 한다.
네 가지 기능을 나누어 판단하는 기준
| 구분 | 잘 맞는 상황 | 적용 전 확인할 점 |
|---|---|---|
| Custom instructions | 저장소 전반의 코딩 규칙, 테스트 기대치, 이름 규칙을 반복해서 설명할 때 | 규칙이 너무 넓거나 오래된 내용이 아닌지 확인 |
| Agent skills | 테스트, lint, 릴리스, 디버깅처럼 절차가 정해진 작업이 반복될 때 | 실제 명령어와 실패 대응 기준이 문서화되어 있는지 확인 |
| Custom agents | 접근성, 보안, 문서 품질처럼 넓은 관점의 반복 리뷰가 필요할 때 | 역할, 사용 도구, 판단 기준이 과도하게 모호하지 않은지 확인 |
| MCP servers | 브라우저, 문서, 외부 서비스 등 저장소 밖의 도구가 필요할 때 | 권한, 데이터 접근 범위, 계정 정책, 보안 조건을 확인 |
개인 프로젝트와 연구 코드에서 먼저 볼 지점
개인 개발자는 비용과 시간 절감 효과를 함께 봐야 한다. GitHub Blog 글은 사용법 중심으로 설명하며 가격 조건을 상세히 다루지는 않는다. 따라서 실제 적용 전에는 현재 쓰는 GitHub Copilot 계정 유형, 조직 정책, 기능 제공 범위, 추가 비용 여부를 공식 문서에서 확인해야 한다.
학생과 연구자는 재현성을 중심에 두는 편이 좋다. 실험 실행 순서, 데이터 전처리 방식, 평가 스크립트, 결과 저장 위치를 skill이나 instructions로 정리하면 Copilot이 프로젝트 구조를 더 잘 따라갈 수 있다. 다만 연구 데이터나 비공개 자료가 포함되는 경우에는 MCP 서버 연결이나 외부 도구 접근을 켜기 전에 데이터 반출 가능성과 권한 범위를 확인해야 한다.
팀 개발자는 “모든 저장소에 바로 적용”하기보다 변경 폭이 작은 저장소에서 시작하는 편이 안전하다. 예를 들어 문서 사이트, 내부 도구, 테스트가 잘 갖춰진 작은 서비스에서 custom instructions 하나를 추가한 뒤 Copilot의 제안이 기존 규칙을 더 잘 따르는지 확인할 수 있다. 효과가 확인되면 품질 점검 skill, 특정 리뷰용 custom agent, 브라우저 검증용 MCP 순서로 넓혀가는 방식이 현실적이다.
도입보다 먼저 정리할 질문
- 반복 설명: Copilot에게 매번 다시 말하는 프로젝트 규칙이 무엇인가?
- 반복 절차: 테스트, 빌드, 릴리스, 디버깅 중 문서화하면 좋은 절차가 무엇인가?
- 전문 역할: 접근성, 보안, 문서, 성능처럼 별도 관점이 필요한 반복 작업이 있는가?
- 외부 연결: Copilot이 브라우저, 문서, 외부 서비스에 접근해야 실제 검증이 가능한가?
- 권한 범위: 저장소, 계정, 조직, 외부 도구에서 Copilot이 어디까지 접근할 수 있는가?
처음 적용할 때의 안전한 순서
- 가장 자주 반복하는 규칙 하나를 고른다.
- .github/copilot-instructions.md에 짧고 검증 가능한 문장으로 적는다.
- 작은 변경 작업 하나를 Copilot에 맡겨 결과가 기존 패턴을 따르는지 본다.
- 테스트나 lint처럼 명령어가 정해진 작업은 skill로 분리할지 판단한다.
- 외부 도구 연결이 필요하면 MCP 서버의 권한과 데이터 접근 범위를 먼저 확인한다.
중요한 것은 Copilot을 더 강하게 만드는 것이 아니라, Copilot이 따라야 할 프로젝트의 기준을 더 명확하게 만드는 것이다. 기준이 불명확한 저장소에서는 custom instructions를 넣어도 효과가 제한적일 수 있다. 반대로 코드 스타일, 테스트 절차, 리뷰 관점이 이미 어느 정도 정리된 저장소라면 이 네 가지 방식이 반복 설명을 줄이고 결과의 일관성을 높이는 데 도움이 될 수 있다.
출처와 검증
이 글은 GitHub Blog가 2026년 10월 12일 공개한 글을 바탕으로 정리했다. 실제 사용 가능 범위, 가격, 조직 정책, 계정별 제공 여부, MCP 서버별 권한 조건은 변경될 수 있으므로 적용 전 GitHub의 최신 공식 안내와 현재 계정 설정을 확인해야 한다.
원문: GitHub Copilot app for Beginners: How to teach Copilot about your codebase