실습 노트
GitHub Copilot 코드 리뷰 승인 기능: 평가·승인·머지를 분리하는 방법
GitHub Copilot 코드 리뷰의 승인 평가와 실제 PR 승인을 구분하고, 기업·조직·저장소 정책에서 권한을 나누는 기준을 정리합니다.
코드 리뷰 봇이 “승인할 만하다”고 판단하는 것과 실제로 GitHub의 승인 기록을 남기는 것은 다른 권한입니다. GitHub는 2026년 9월 1일 Copilot 코드 리뷰에 승인 평가를 표시하고, 관리자가 허용하면 Copilot이 pull request를 승인할 수 있는 Preview 기능을 공개했습니다. 이 기능은 자동 머지 버튼이라기보다 리뷰 판단과 승인 권한을 분리해 설정하는 기능으로 읽어야 합니다.
평가와 승인의 차이
공식 Changelog에 따르면 모든 Copilot 코드 리뷰의 개요 댓글에 승인 평가가 표시됩니다. 이 평가는 Copilot이 PR을 승인할 준비가 됐다고 보는지 보여 주지만, 평가만으로 저장소의 병합 요건을 충족하지는 않습니다. 사람이 결과를 읽고 다음 조치를 결정하는 정보 단계입니다.
관리자가 승인을 켜면 Copilot이 실제 approval을 제출할 수 있고, 이 승인은 저장소의 required approvals 규칙에 반영될 수 있습니다. 즉 운영 상태는 최소 세 단계로 나뉩니다.
- 리뷰 실행: 변경을 읽고 댓글과 분석을 남김
- 승인 평가: 승인할 만한 상태인지 신호를 표시함
- 실제 승인: 권한이 켜진 경우 GitHub 승인 기록을 남김
이 중 마지막 단계가 켜졌다고 해서 PR이 자동으로 머지되는 것은 아닙니다. 브랜치 보호 규칙, 상태 검사, 배포 승인 같은 별도 조건은 그대로 남습니다.
기본값과 관리자 계층
승인 기능은 기본적으로 꺼져 있으며, Enterprise·Organization·Repository 세 수준에서 제어할 수 있다고 GitHub는 설명합니다.
- Enterprise: 기업 전체에서 승인 기능을 끄거나 조직에 결정을 위임
- Organization: 조직 전체 적용, 저장소 관리자 위임, 특정 저장소 허용, 조직 전체 차단
- Repository: 저장소에서 켜거나 끄고 Copilot이 승인할 수 있는 파일 경로 선택
이 계층은 단순한 설정 편의가 아니라 권한 분리 장치입니다. 예를 들어 일반 애플리케이션 코드와 배포·인증·권한 정책 파일을 같은 자동 승인 범위로 두지 않을 수 있습니다. 파일 경로 제한이 있다고 해서 코드의 위험을 자동으로 판단해 주는 것은 아니므로, 민감한 경로는 저장소 규칙과 사람 승인을 함께 두는 편이 적절합니다.
새 커밋이 오면 승인은 사라진다
GitHub 공지의 중요한 조건은 Copilot이 승인한 뒤 새 커밋이 추가되면 사람 리뷰어의 승인과 마찬가지로 승인 상태가 해제된다는 점입니다. 이후에는 Copilot에 새 리뷰를 요청해 현재 커밋 집합을 다시 평가해야 합니다.
이 동작은 자동화 설계에서 “승인 이벤트”를 영구적인 신뢰 신호로 저장하면 안 된다는 뜻입니다. 승인 기록을 사용할 때는 다음을 함께 확인해야 합니다.
- 승인이 어느 커밋 SHA를 대상으로 했는가
- 승인 뒤 변경된 파일과 상태 검사가 있는가
- 새 커밋이 들어오면 리뷰가 다시 요청되는가
- 사람이 승인한 것과 Copilot이 승인한 것을 감사 기록에서 구분하는가
실무 적용 순서
처음부터 모든 PR에 자동 승인을 켜기보다, 승인 권한이 필요한 범위를 작게 고정하는 편이 좋습니다.
- 먼저 승인 평가만 켜고 실제 승인 없이 false positive와 놓친 문제를 분류합니다.
- 테스트가 충분하고 변경 위험이 낮은 저장소 또는 경로에서만 실제 승인을 허용합니다.
- 인증·권한·배포 설정과 같은 경로는 Copilot 승인 범위에서 제외하거나 사람 승인을 추가합니다.
- 새 커밋이 들어오면 기존 승인을 무효화하고 재리뷰하는 규칙을 확인합니다.
- 병합 후에도 승인 주체, 대상 커밋, 검사 결과를 감사 로그에서 확인합니다.
이 흐름은 Copilot을 믿지 말자는 주장이 아니라, 한 번의 모델 판단에 리뷰·승인·머지 권한을 모두 묶지 말자는 설계 원칙입니다. 자동화의 범위를 늘리려면 먼저 어떤 실패가 사람에게 되돌아오는지 관측할 수 있어야 합니다.
공급자 발표와 독립 검증의 경계
이 기능은 GitHub의 공식 Changelog에 공개된 Public Preview입니다. 공식 공지는 설정 계층과 커밋 변경 시 승인 해제 동작을 설명하지만, 조직별로 승인 품질이 어느 정도인지에 대한 독립 벤치마크는 제시하지 않습니다. 이 저장소에서 실제 Copilot 리뷰를 실행한 결과도 아니므로, 기능 소개를 특정 팀의 품질 향상 결과처럼 읽어서는 안 됩니다.
따라서 도입 판단의 질문은 “Copilot이 사람처럼 승인하는가”가 아니라 “어떤 경로와 커밋 상태에서 자동 승인을 허용하고, 어떤 조건에서 사람에게 되돌릴 것인가”여야 합니다. 승인 평가를 정보로 쓰는 단계와 GitHub 승인 기록을 정책에 반영하는 단계 사이에 명확한 경계를 두면 기능 Preview가 바뀌어도 운영 원칙을 유지하기 쉽습니다.