GitHub Copilot은 일반적인 지침에만 의존할 때보다 작업 대상 코드베이스의 고유한 규칙을 알고 있을 때 더 효과적으로 작동한다. GitHub는 이러한 컨텍스트의 상당 부분을 저장소 내부에 저장할 수 있으며, 이를 통해 Copilot이 구성 요소 구성 방식, 사용되는 명령, 명명 및 테스트 표준을 자동으로 파악할 수 있다고 설명한다.
일반 지침과 경로별 지침
설정은 .github/copilot-instructions.md 파일을 생성하는 것부터 시작한다. 이 파일에는 선호하는 아키텍처, 명명 규칙, 테스트 및 검증 요구 사항처럼 저장소 전체에 적용되는 규칙을 작성한다.
GitHub는 또한 .github/instructions 아래에 특정 경로와 연결된 지침 파일을 만들 수 있도록 한다. 이러한 파일은 applyTo 필드를 사용해 지침이 적용되는 파일이나 상황을 지정한다. 이를 통해 모든 파일 유형에 하나의 방식을 강요하지 않고 일반 지침과 보다 구체적인 규칙을 함께 사용할 수 있다.
반복 절차를 스킬로 전환하기
일반 지침이 모든 절차에 적합한 것은 아니다. 품질 검사 실행, 릴리스 준비, 워크플로 실패 진단과 같은 작업에는 반복 가능한 단계가 필요하다. GitHub는 이러한 목적에 에이전트 스킬 사용을 제안한다. 에이전트 스킬은 지침, 스크립트, 추가 리소스를 포함할 수 있는 폴더다.
프로젝트별 스킬은 .github/skills에 배치할 수 있으며, 각 스킬마다 별도의 폴더를 지정한다. 예를 들어 quality-checks 폴더에는 스킬을 언제 사용할지, 테스트 및 코드 스타일 검증 명령, 각 명령이 검사하는 항목, 일반적인 실패 상황에 대응하는 방법을 설명하는 SKILL.md 파일이 들어갈 수 있다.
언제 사용자 지정 에이전트가 필요한가?
일부 작업은 하나의 절차를 넘어 여러 파일과 도구에 걸쳐 수행된다. GitHub는 구성 요소, 템플릿, 스타일, 상호작용을 검사해야 할 수 있는 접근성 검토를 예로 든다. 이러한 경우 .github/agents 안에 사용자 지정 에이전트를 만들고, 해당 에이전트의 목표와 지침, 도구, 프로젝트와 관련된 컨텍스트를 지정할 수 있다.
특정 유형의 작업이 반복되고 전문화된 역할이나 특정 관점의 이점을 얻을 때 이 방법이 적합하다. 특히 여러 파일과 컨텍스트 소스를 다뤄야 하는 경우에 유용하다.
MCP 서버를 통한 Copilot의 범위 확장
지침, 스킬, 에이전트가 Copilot이 프로젝트 내부에서 작업하는 방법을 이해하도록 돕는다면, Model Context Protocol (MCP) 서버는 Copilot을 저장소 외부의 도구, 데이터 소스, 서비스와 연결한다. 문서화 서버는 프레임워크 지침을 제공할 수 있으며, Playwright 같은 서버를 사용하면 브라우저를 통해 애플리케이션을 열고 상호작용할 수 있다.
Playwright를 설정한 후에는 MCP 서버를 사용해 기능을 수동으로 테스트하도록 요청할 수 있다. 따라서 검증은 자동화된 테스트의 성공 여부에만 국한되지 않는다. Copilot은 변경 후 인터페이스의 동작을 검사하고 브라우저에서 인터페이스와 상호작용할 수도 있다.
실제로 무엇이 달라지는가?
가장 큰 이점은 반복적으로 설명하던 지식을 대화에서 저장소 내부의 검토 가능한 파일로 옮기는 데 있다. 지침은 표준을 정하고, 스킬은 절차를 문서화하며, 에이전트는 복잡한 작업에 집중하고, MCP 서버는 외부 도구를 사용할 수 있는 기능을 추가한다. GitHub는 점진적으로 시작할 것을 권장한다. 반복해서 설명하는 규칙 하나를 선택해 .github/copilot-instructions.md에 작성한 다음 Copilot이 이를 어떻게 적용하는지 관찰하라는 것이다.
또한 이 자료는 공유할 수 있도록 준비된 지침, 스킬, 에이전트를 모아 둔 Awesome Copilot 저장소를 언급한다. 그러나 이러한 리소스를 도입하기 전에 프로젝트의 도구와 표준에 맞게 조정하는 작업은 여전히 필요하다.