Copilot이 PR을 승인한다…기본값은 꺼짐, 경로별 허용도 가능하다

GitHub가 2026년 9월 1일 Copilot 코드 리뷰가 풀 리퀘스트(PR)에 승인 리뷰를 제출할 수 있는 기능을 공개 미리보기로 추가했다. 9월 1일 공식 변경 공지 에 따르면 실제 승인 기능은 기본적으로 꺼져 있고, 엔터프라이즈·조직·저장소 관리자가 사용 범위를 통제한다.

같은 발표를 다룬 NEXSIGHT의 9월 2일 보도 도 공개 미리보기라는 출시 상태와 기본 비활성화, 세 단계의 관리 범위, 새 커밋 뒤 승인 취소를 확인했다. 관리자가 확인할 핵심은 Copilot의 판단 표시, 실제 승인 제출, 그 승인을 필수 승인 수에 포함하는 설정이 서로 같은 기능이 아니라는 점이다.

승인 평가와 실제 승인은 세 단계로 구분된다

모든 Copilot 코드 리뷰의 개요 댓글에는 이제 승인 평가가 포함된다. Copilot이 해당 PR을 승인할 준비가 된 것으로 판단하는지를 보여주는 신호지만, 평가 자체는 저장소의 병합 요건에 포함되지 않는다.

따라서 개요 댓글에 긍정적인 평가가 표시돼도 필수 승인 수가 올라가거나 보호된 브랜치의 병합 잠금이 풀리는 것은 아니다. 관리자가 승인 기능을 켜지 않은 저장소에서도 평가를 볼 수 있으므로, 화면의 긍정적 문구를 정식 승인으로 해석해서는 안 된다.

두 번째 단계는 Copilot이 단순한 Comment가 아니라 정식 승인 리뷰를 제출하도록 허용하는 것이다. 이 권한도 관리자가 명시적으로 켜야 하며, 기본 상태에서는 Copilot이 PR을 승인하지 않는다.

세 번째 단계는 제출된 Copilot 승인을 저장소의 required-approvals 규칙에 포함하는 것이다. 승인 리뷰를 제출할 수 있게 하는 설정과 병합 요건에 반영하는 설정이 분리돼 있으므로, 첫 번째 설정만 켠 상태에서는 Copilot의 승인이 존재하더라도 필수 승인 수를 채운다고 전제할 수 없다.

기존 사용 안내에서 Copilot 리뷰를 Comment로 설명했던 동작은 이 공개 미리보기와 무조건 충돌하는 것이 아니다. 승인을 허용하지 않은 기본 상태에는 기존 설명이 적용되고, 관리자가 새로운 권한과 병합 요건 반영을 허용한 범위에서만 더 강한 동작이 추가된다.

상위 정책부터 저장소 설정까지 차례로 확인해야 한다

승인 권한은 저장소 토글 하나만으로 결정되지 않는다. 엔터프라이즈 정책이 조직의 선택을 허용하고, 조직 정책이 해당 저장소에 승인을 허용해야 저장소 관리자가 세부 범위를 정할 수 있다.

엔터프라이즈 관리자는 AI controls에서 Copilot code review 정책을 열어 조직이 결정하도록 맡기거나, 선택한 조직에만 승인을 허용하거나, 모든 조직에서 비활성화할 수 있다. 엔터프라이즈 수준의 기본 정책은 Disabled everywhere이므로 상위 관리자가 변경하지 않으면 조직과 저장소에서 독자적으로 승인 권한을 열 수 없다.

조직 관리자는 모든 저장소에서 Copilot 승인을 병합 요건에 반영하거나, 저장소 관리자가 결정하게 하거나, 선택한 저장소에만 허용하거나, 조직 전체에서 반영하지 않도록 설정할 수 있다. 여러 저장소가 같은 조직에 속해 있어도 저장소별 위험도와 보호 규칙에 따라 적용 범위를 나눌 수 있는 구조다.

저장소에서는 Settings의 Copilot, Code review로 이동해 Auto-approval 항목을 확인한다. GitHub의 코드 리뷰 설정 문서 는 승인 리뷰 제출과 병합 요건 반영을 각각 별도 토글로 제공하며, 모든 변경 파일이 허용 glob 중 하나와 일치할 때만 승인을 반영하도록 최대 15개의 파일 glob을 지정할 수 있다고 설명한다.

1. 엔터프라이즈의 Allow Copilot to approve pull requests 정책이 대상 조직을 허용하는지 확인한다.
2. 조직의 Count Copilot approvals toward merge requirements 정책에서 전체·선택 저장소·저장소별 결정·전체 비활성화 가운데 범위를 정한다.
3. 저장소의 Auto-approval에서 승인 리뷰 제출 권한을 켤지 결정한다.
4. Copilot 승인을 필수 승인 수에 포함할지 별도 토글로 결정하고, 필요하면 파일 glob을 지정한다.
5. 브랜치 ruleset이 요구하는 승인 수와 새 push 검토 설정을 함께 확인한다.

여기서 자동 코드 리뷰와 자동 승인은 같은 설정이 아니다. ruleset으로 Copilot 리뷰를 자동 요청하더라도 승인 제출과 병합 요건 반영이 허용되지 않았다면 리뷰는 병합 게이트를 충족시키는 승인으로 작동하지 않는다.

경로별 허용은 PR 전체의 자격 조건이다

파일 경로 제한은 PR 안의 일부 파일만 따로 승인하는 기능이 아니다. 경로 조건을 설정하면 변경된 모든 파일이 허용된 glob 가운데 하나에 맞는 PR에서만 Copilot 승인을 병합 요건에 반영할 수 있다.

가령 허용 패턴을 문서 디렉터리로 한정한 저장소에서 문서와 애플리케이션 소스가 하나의 PR에 함께 변경됐다고 가정하자. 소스 파일이 허용된 다른 glob에 맞지 않는다면 Copilot이 긍정적인 리뷰를 남겨도 그 승인은 필수 승인 수에 포함될 수 없다.

반대로 파일 경로 입력을 비워 두면 모든 파일이 대상이 된다. 따라서 경로 제한을 운영 통제로 사용하려면 문서, 테스트, 애플리케이션 코드처럼 허용할 영역만 볼 것이 아니라 빌드 설정, 배포 워크플로, 권한 정책, 의존성 관련 파일처럼 함께 변경될 수 있는 경로도 고려해야 한다.

경로가 일치한다는 사실은 변경의 안전성이나 리뷰 품질을 보증하지 않는다. glob은 Copilot 승인을 병합 요건에 반영할 수 있는 PR을 가르는 조건일 뿐이며, 해당 변경에 결함이 없다는 판정 기준이나 모든 파일이 충분히 검토됐다는 증명은 아니다.

새 커밋이 추가되면 이전 승인은 취소된다

Copilot이 PR을 승인한 뒤 새 커밋이 푸시되면 기존 Copilot 승인은 사람 리뷰어의 승인과 마찬가지로 취소된다. 승인 뒤 변경된 코드는 이전 판단의 대상이 아니므로 기존 승인을 최신 상태의 병합 근거로 남겨 두지 않는 동작이다.

다시 유효한 승인을 받으려면 최신 커밋을 대상으로 Copilot의 재검토가 필요하다. 자동 리뷰 ruleset에서 Review new pushes를 선택하면 새 push마다 자동 검토하도록 구성할 수 있지만, 이 설정을 사용하지 않으면 Copilot이 변경 사항을 자동으로 다시 검토하지 않는다.

승인 취소와 재검토 요청도 구분해야 한다. 새 커밋으로 이전 승인이 사라졌다고 해서 새로운 리뷰와 승인이 자동으로 완료됐다는 뜻은 아니며, 자동 재검토를 설정하지 않았다면 Reviewers 영역에서 Copilot 리뷰를 다시 요청해야 한다.

병합 직전에는 최신 커밋을 대상으로 리뷰가 끝났는지, Copilot이 새 승인 리뷰를 제출했는지, 그 승인이 저장소 정책상 필수 승인 수에 포함되는지를 각각 확인해야 한다. 개요 댓글의 승인 평가가 긍정적이라는 사실만으로 이 세 조건을 대신할 수는 없다.

Copilot 승인 하나가 required-approvals 규칙을 충족할 수 있어도 테스트, 대화 해결, CODEOWNERS 승인이나 다른 ruleset 조건까지 없애는 기능은 아니다. 이번 변경의 범위는 Copilot의 승인 리뷰를 필수 승인 수에 포함할 수 있도록 한 것이며, 나머지 병합 보호 조건은 독립적으로 적용된다.

공개 미리보기는 Copilot Pro, Pro+, Max, Business, Enterprise 요금제를 대상으로 제공되며 사양이 바뀔 수 있다. 확정된 현재 상태는 승인 평가가 모든 Copilot 리뷰에 표시되고, 실제 승인은 기본적으로 꺼져 있으며, 상위 정책과 저장소 설정이 허용한 경우에만 병합 요건에 반영될 수 있다는 것이다.

사람의 확인 범위는 저장소 정책으로 남는다. 권한 변경, 보안 경계, 데이터 처리, 배포 구성처럼 코드 밖의 맥락과 책임 판단이 필요한 변경에서는 Copilot 승인과 별도로 사람 또는 코드 소유자의 승인을 유지할지 정해야 한다.