9월 1일부터 Copilot 코드 리뷰의 승인이 저장소 필수 승인 수에 산입될 수 있다. 기본값은 꺼짐이지만, 켜면 '승인 1명' 규칙을 사람 없이 채우는 PR이 생긴다. 켜기 전에 필수 승인 1인 저장소 목록과 경로 글롭 15줄을 먼저 정한다.
브랜치 보호 규칙에 "필수 승인 1명"을 적어 둔 저장소가 많다. 그 1명이 누구인지는 묻지 않았다. 답이 늘 사람이었기 때문이다. 리뷰가 밀리면 옆자리 동료가 훑어보고 누르는 승인도 사람의 승인이었고, 사고가 나면 그 이름이 남았다.
지난달 GitHub가 Code Quality의 자동 리뷰어 배정을 되돌렸을 때 논점은 리뷰의 양이었다. 리뷰를 자동으로 붙여주던 스위치가 도로 꺼졌다에서 다룬 대로, 병목에 물량을 붓는 기본값이 취소된 사건이었다. 이번 주의 변경은 방향이 다르다. 양이 아니라 자격이 바뀌었다.
GitHub 9월 1일 공지는 Copilot 코드 리뷰가 PR을 승인할 수 있고, 관리자가 허용하면 그 승인이 저장소의 필수 승인 수에 산입된다고 밝혔다. 리뷰 도구가 하나 늘어난 것이 아니다. "승인 1명"이라는 숫자의 뜻이 바뀔 수 있게 된 것이다.
바뀐 것은 리뷰의 양이 아니라 승인의 자격이다
공지의 메커니즘은 두 단계다. 첫째, 모든 Copilot 리뷰의 개요 코멘트에 이 PR을 승인해도 되는지 판정한 승인 평가가 붙는다. 이 평가만으로는 병합 조건에 산입되지 않는다. 둘째, 관리자가 켜면 Copilot이 실제 승인을 제출하고, 그 승인은 사람 리뷰어의 승인과 같은 자격으로 필수 승인 수를 채운다. 새 커밋이 올라오면 사람 리뷰어의 승인과 같은 규칙으로 해제되고, 다시 요청하면 새 승인을 받는다. 대상 플랜은 Pro, Pro+, Max, Business, Enterprise이고 퍼블릭 프리뷰다.
승인 기능은 기본값이 꺼짐이며 세 층에서 통제된다. GitHub 문서의 설정명을 그대로 옮기면 다음과 같다.
| 층 | 설정명 | 선택지 |
|---|---|---|
| 엔터프라이즈 | Allow Copilot to approve pull requests | 조직 결정 허용 / 전체 비활성(기본) |
| 조직 | Count Copilot approvals toward merge requirements | 전체 활성 / 저장소 결정 / 선택 저장소 / 전체 비활성 |
| 저장소 | Allow Copilot approvals to count toward merge requirements, File paths | 토글, 글롭 최대 15줄 |
엔터프라이즈가 조직 결정을 허용하고 조직이 "저장소 결정"을 고르면, 저장소 관리자 한 사람의 토글로 그 저장소의 병합 규칙이 바뀐다. 필수 승인 수가 1인 저장소에서 이 토글이 켜지면, Copilot이 승인한 PR은 사람이 한 명도 보지 않은 채 병합 조건을 충족한다.
규칙의 숫자는 그대로인데, 숫자가 세는 대상이 바뀐다.
결정은 프롬프트가 아니라 경로 글롭 15줄에 적힌다
어떤 변경은 사람 없이 들어가도 되는가. 조직마다 답이 다르다. GitHub는 이 답을 적을 자리로 저장소 설정의 File paths를 뒀다. 글롭 한 줄에 경로 하나, 최대 15줄이다. 여기 적힌 경로에 해당하는 PR만 Copilot 승인이 병합 조건에 산입된다. 리뷰 프롬프트나 AGENTS.md에 "중요 파일은 승인하지 마라"고 적는 것과는 층이 다르다. 프롬프트는 모델이 따를 수도 있는 지시이고, 글롭은 플랫폼이 강제하는 규칙이다.
봇이 승인을 남기는 일 자체는 새롭지 않다. GitHub Actions에서 토큰으로 승인 리뷰를 남겨 Dependabot PR을 자동 병합하는 워크플로는 전부터 있었다. 그 승인은 "패치 버전 상승이면 승인"처럼 조건이 코드로 적힌 규칙이었다. Copilot의 승인은 규칙이 아니라 판단이다. 판단의 근거는 모델이고, 모델은 고정되지 않는다. 같은 주 GitHub 9월 3일 공지는 Claude Opus 4.7, Gemini 3.5·3.6 Flash, Kimi K2.7 Code를 10월 2일에 Copilot에서 종료한다고 밝혔다. 코드 리뷰가 어느 모델을 쓰는지는 공지가 밝히지 않지만, 승인자의 판단 기준이 한 달 단위로 바뀔 수 있는 구조라는 점은 분명하다.
이 판단에 어디까지 맡길지는 팀 구조의 문제이기도 하다. InfoQ 9월 3일 기사가 전한 Artie Shevchenko의 Craft 컨퍼런스 발표는 코드 소유자가 자기 PR을 동료 리뷰 없이 AI 승인만으로 병합하는 정책을 소개하면서, 이 방식이 작동하는 조건을 팀이 작고 구성원 대부분이 코드 소유자일 때로 못 박았다. GitHub의 스위치는 팀 크기나 소유권 구조를 알지 못한다. 그 조건을 대신 담을 수 있는 자리가 경로 글롭이다.
스위치를 켜기 전에 시험 PR로 실제 동작을 확인한다
관리자 정책과 에이전트의 실제 동작이 늘 일치하지는 않는다. GitHub 9월 2일 공지는 Copilot 앱과 CLI가 이제 콘텐츠 제외 정책을 따른다고 밝혔다. 뒤집어 읽으면 그 전까지 CLI는 관리자가 제외한 파일을 컨텍스트로 읽고 있었다는 뜻이다. 정책 화면의 설정값과 도구의 동작 사이에 간격이 있었고, 공지 한 줄로 드러났다.
승인 기능도 문서가 비워 둔 자리가 있다. CODEOWNERS의 코드 소유자 리뷰 필수 규칙과 어떻게 맞물리는지, Copilot 코딩 에이전트가 만든 PR을 Copilot이 승인할 수 있는지, 허용 경로와 비허용 경로를 함께 건드린 PR의 승인이 산입되는지는 문서에 없다. 퍼블릭 프리뷰라 변경될 수 있다는 단서도 붙어 있다. 켜기 전에 시험 저장소에서 PR 세 개를 만들어 결과를 보는 편이 문서를 다시 읽는 것보다 빠르다.
가져갈 것
| 확인 항목 | 어디서 확인하나 | 기한 |
|---|---|---|
| 엔터프라이즈 정책 "Allow Copilot to approve pull requests"가 기본값(전체 비활성)인지 | 엔터프라이즈 Copilot 정책 | 이번 주 |
| 조직 설정 "Count Copilot approvals toward merge requirements"가 "저장소 결정"으로 열려 있지 않은지 | 조직 Copilot 설정 | 이번 주 |
| 필수 승인 수가 1인 저장소 목록 (Copilot 승인이 산입되면 사람 0명이 되는 곳) | 저장소 룰셋·브랜치 보호 규칙 | 켜기 전 |
| 켤 저장소의 File paths 글롭(최대 15줄)에 문서·테스트·생성 파일만 있고 인증·결제·인프라 경로가 없는지 | 저장소 Copilot 코드 리뷰 설정 | 켜기 전 |
| 시험 PR 3개(허용 경로만 / 허용·비허용 혼합 / 코딩 에이전트 작성)에서 승인이 산입되는지 | 시험 저장소 | 켜기 전 |
| 10월 2일 종료 모델(Claude Opus 4.7 등 4종)의 대체 모델이 Copilot 정책에서 활성인지 | 조직 Copilot 모델 정책 | 10월 2일 전 |
안 되는 경우
- Pro, Pro+, Max, Business, Enterprise 플랜 밖의 사용자와 GitHub 밖에서 코드를 호스팅하는 조직에는 해당하지 않는다.
- 필수 승인 수가 2 이상인 저장소에서는 Copilot 승인 하나로 사람 0명이 되지 않는다. 단, CODEOWNERS 기반 코드 소유자 리뷰 강제와의 상호작용은 문서가 밝히지 않았다.
- 코드 리뷰에 어떤 모델이 쓰이는지, 모델 교체가 승인 판단을 어떻게 바꾸는지는 공지가 밝히지 않았다. 10월 2일 모델 종료와 승인 기능을 잇는 것은 이 글의 추론이다.
- 퍼블릭 프리뷰다. 설정명과 동작은 정식 출시 전에 바뀔 수 있다.
이번 주에 바꿀 것은 하나다. 저장소 룰셋의 "필수 승인 1명" 옆에, 그 1명이 반드시 사람이어야 하는 경로를 적는 일이다. 스위치를 켜든 끄든 그 답이 없으면 규칙은 숫자만 남는다. 조녁컴퍼니의 관점에서 리뷰 자동화 논의는 "몇 명"보다 "어느 경로에서 누가"를 먼저 물어야 하는 자리라고 본다. 사업영역 →