GitHub의 에이전트 스킬(agent skills) 및 MCP 서버를 위한 Copilot 코드 리뷰 지원이 2026년 7월 29일에 정식 출시(general availability)되었습니다. 유용한 점은 "AI가 더 많은 코드를 리뷰한다"는 것이 아닙니다. 바로 경계(boundary)입니다. 저장소 지침(repository instructions)과 외부 컨텍스트(external context)가 리뷰를 형성할 수 있는 반면, Copilot 코드 리뷰에 의해 수행되는 MCP 호출은 읽기 전용(read-only)으로 유지됩니다. 또한 GitHub는 스킬이나 MCP 컨텍스트를 사용한 댓글에 대해 출처(attribution)를 명시합니다.

이는 실질적인 제어 평면(control-plane) 문제입니다. 즉, 코드 리뷰를 은밀하게 수정 권한(mutation privileges)을 가진 에이전트로 변질시키지 않으면서 어떻게 프로젝트 컨텍스트를 추가할 것인가의 문제입니다.

워크플로 (The workflow)

안전한 시작을 위한 설계는 네 가지 계층을 가집니다:

1. 저장소 내의 버전 관리된 리뷰 정책 (Versioned review policy).
2. 티켓, 아키텍처 노트 또는 서비스 카탈로그를 위한 읽기 전용 외부 컨텍스트 (Read-only external context).
3. 리뷰어가 어떤 댓글이 해당 컨텍스트에 의존했는지 확인할 수 있도록 하는 출처 표기 (Attribution).
4. 코드, 레이블, 이슈 또는 배포를 변경하기 전의 사람의 승인 (Human approval).

모델은 잘못된 댓글을 생성할 수 있습니다. 읽기 전용 액세스라고 해서 댓글이 반드시 정확해지는 것은 아닙니다. 다만 잘못된 도구 호출(tool call)의 폭발 반경(blast radius)을 줄여줄 뿐입니다.

리뷰 정책을 코드 옆에 두기

GitHub의 형식은 .github/skills 아래에 있는 스킬별 디렉토리이며, SKILL.md 파일을 포함합니다. 거대한 엔지니어링 핸드북보다는 좁고 테스트 가능한 지침부터 시작하세요. 예를 들어:

.github/skills/api-review/SKILL.md

---
name: api-review
description: "공개 HTTP API의 변경 사항을 리뷰합니다"
...

중요한 단어는 **증거 (evidence)**입니다. 스킬은 리뷰어에게 결론을 강요하는 것이 아니라, 어디를 살펴보고 무엇을 검증해야 하는지를 알려주어야 합니다. 파일을 프로덕션 설정(production configuration)처럼 리뷰할 수 있을 정도로 작게 유지하세요.

권한이 아닌 컨텍스트를 추가하기

MCP는 리뷰를 이슈 트래커(issue tracker), 문서 플랫폼 또는 서비스 카탈로그와 같은 시스템에 연결할 수 있습니다. 이러한 연결을 사용하여 다음과 같은 질문에 답하세요:

• 연결된 이슈가 실제로 요구하는 동작은 무엇인가?
• 이 엔드포인트(endpoint)가 여전히 지원되는가?
• 변경된 스키마(schema)의 소유 서비스는 무엇인가?
• 승인된 폐기(deprecation) 날짜가 있는가?

검색된 컨텍스트(context)를 권한 부여 결정(authorization decision)으로 취급하지 마세요. 티켓은 오래되었을 수 있고, 문서는 저장소(repository)와 모순될 수 있으며, 서비스 카탈로그(service catalog)는 현실을 따라가지 못할 수 있습니다. 리뷰는 출처와 불확실성을 드러내야 합니다.

유용한 리뷰 코멘트는 다음과 같은 형태를 가집니다:

이 PR은 currency를 필수 항목으로 만들어 POST /v2/orders를 변경합니다. 연결된 마이그레이션 이슈(migration issue)에는 기존 클라이언트가 9월까지 지원된다고 명시되어 있습니다. currency가 없는 요청에 대한 호환성 테스트를 찾을 수 없었습니다. 테스트를 추가하거나, 해당 이슈가 더 이상 적용되지 않는 이유를 설명해 주세요.

이는 다음과 같은 방식보다 훨씬 안전합니다: “이것은 중대한 변경(breaking change)이므로 되돌리세요(revert).”

속성(attribution)을 감사 신호(audit signal)로 취급하기

GitHub는 에이전트 기술(agent skills) 또는 MCP 컨텍스트(context)로 생성된 코멘트에 속성(attribution)이 부여된다고 밝히고 있습니다. 리뷰 분류(triage) 과정에서 이 신호를 활용하세요:

속성(attribution)은 정확도 점수가 아닙니다. 그것은 코멘트가 권위 있어 보일 때 무엇을 검사해야 하는지를 알려주는 지표입니다.

소규모 출시 체크리스트

모든 저장소에 이를 활성화하기 전에, 위험도가 낮은 프로젝트 하나를 테스트하세요:

• API 호환성과 같은 하나의 리뷰 카테고리에 대해 하나의 기술(skill)을 추가합니다.
• 하나의 읽기 전용(read-only) MCP 서버를 연결합니다.
• 자격 증명(credentials)을 SKILL.md나 워크플로(workflow)가 아닌, 저장소의 에이전트 비밀값(Agents secrets)에 저장합니다.
• 이미 검증된 변경(known good), 알려진 잘못된 변경(known bad), 그리고 모호한 변경(ambiguous changes)을 포함하는 풀 리퀘스트(pull requests)를 엽니다.
• 리뷰어가 예상된 문제를 발견했는지, 올바른 출처를 인용했는지, 그리고 불확실성을 명시했는지 기록합니다.
• 연결된 어떤 도구도 생성, 편집, 병합(merge), 라벨링(label), 또는 배포(deploy)를 할 수 없는지 확인합니다.
• 컨텍스트에 의존하는 모든 코멘트의 속성(attribution)을 검토합니다.

간단한 테스트 매트릭스(test matrix) 예시:

이것이 해결하지 못하는 것

이것이 해결하지 못하는 것

읽기 전용 (Read-only) MCP는 환각 (hallucinations)이 아닌 변이 (mutations)를 제한합니다. 저장소 기술 (Repository skills)은 오래되거나 모순될 수 있습니다. 외부 컨텍스트는 지연 시간 (latency)과 또 다른 권한 부여 표면 (authorization surface)을 추가합니다. 댓글이 실제 티켓을 인용하더라도 여전히 구현 내용을 오해할 수 있습니다.

따라서 단순히 댓글의 양이 아니라 워크플로를 측정하세요: 유지 관리자에 의해 확인된 유용한 발견 사항, 오탐률 (false-positive rate), 소스 최신성 실패, 발견 사항 해결까지 걸리는 시간, 그리고 리뷰어가 에이전트의 해석을 수정해야 했던 빈도 등을 측정해야 합니다. GitHub의 발표는 가용성과 동작 방식을 확립하는 것이지, 리뷰 정확도에 대한 독립적인 평가를 제공하는 것은 아닙니다.

실질적인 규칙은 간단합니다: 리뷰 에이전트에게 더 많은 증거를 제공하되, 권한은 저장소의 테스트와 인간의 승인 경로에 유지하십시오.

코드 리뷰 워크플로에서 무엇을 가장 먼저 연결하시겠습니까: 이슈 컨텍스트 (issue context), 아키텍처 문서 (architecture documentation), 아니면 서비스 카탈로그 (service catalog)입니까?

출처:

• GitHub: Copilot code review support for agent skills and MCP servers
• GitHub Docs: Configure MCP servers for Copilot
• GitHub Docs: About agent skills