Copilot이 PR을 승인한다면 사람이 확인할 것은 무엇일까

내용을 살피는 일과 승인 표시를 남기는 일을 표현한 AI 생성 개념 이미지입니다.

PR에 Copilot의 긍정적인 평가가 달리면 “AI 리뷰도 승인했으니 머지해도 되겠다”고 읽기 쉽습니다. 그런데 평가 댓글, 실제 Approve 리뷰, 머지에 필요한 승인 수에 반영되는 상태는 구분해야 합니다. 같은 PR 화면에서 함께 보이더라도 역할이 다릅니다.

Copilot의 승인 의견과 머지 조건에 반영되는 실제 승인을 구분한 뒤 허용 경로를 정하세요.

GitHub의 2026년 9월 1일 발표는 Copilot의 승인 기능을 public preview로 소개합니다. 발표에 적힌 대상은 Pro·Pro+·Max·Business·Enterprise 플랜입니다. 실제 사용 전에는 현재 플랜과 관리자 정책, 설정 문서를 함께 확인해야 합니다. 아래 내용은 직접 승인 정확도를 측정한 결과가 아니라 공개 기능과 설정의 의미를 정리한 것입니다.

평가 댓글만으로 승인 수가 채워지지는 않습니다

Copilot의 review overview에 나오는 approval assessment는 PR을 승인할 준비가 됐다고 판단하는지 알려주는 의견입니다. 공지는 이 평가만으로 머지 요구사항이 충족되지는 않는다고 명시합니다.

실제 Approve 리뷰를 남기는 기능은 기본적으로 꺼져 있으며, 관리자가 허용해야 합니다. 또한 현재 설정 문서는 승인 제출 허용과 머지 요구사항에 승인 반영을 나누어 설명합니다. “Copilot 승인을 켰다”는 말만으로 어느 설정을 바꿨는지 알 수 없습니다.

팀에서 상태를 읽을 때는 다음 질문을 순서대로 확인하는 편이 좋습니다. 긍정적인 평가만 있는지, 실제 Approve 리뷰가 제출됐는지, 해당 PR에서 그 승인이 필수 승인 조건에 반영되는지입니다. 마지막으로 나머지 필수 검사와 리뷰 조건이 충족됐는지도 봐야 합니다.

승인 수에 포함될 수 있다는 것은 테스트나 보안 검사가 생략된다는 뜻이 아닙니다. 이 기능이 담당하는 조건과 PR 전체의 머지 가능 상태를 분리하면 화면의 한 표시를 과하게 해석하는 일을 줄일 수 있습니다.

조직의 허용과 저장소의 설정을 함께 봅니다

기능의 제어는 엔터프라이즈·조직·저장소 수준에 걸쳐 있습니다. 엔터프라이즈 관리자가 조직에 결정을 맡길 수 있고, 조직은 전체 저장소에 적용하거나 일부에만 허용하거나 저장소 관리자에게 맡길 수 있습니다. 저장소의 화면 하나만 보고 상위 정책이 어떤지 추정하면 안 됩니다.

설정 문서에서 저장소의 상세 경로는 Settings → Copilot → Code review입니다. Auto-approval 영역에서 PR 승인 제출과 머지 요구사항 반영을 구분해 설정합니다. 실제 계정에서 사용할 수 있는 권한과 화면은 현재 정책에 따라 확인해야 하며, 이 글에서 설정을 바꾸거나 승인을 제출한 것은 아닙니다.

처음 도입할 때는 “자동 리뷰를 요청한다”와 “자동 승인에 권한을 준다”도 나눠 두세요. 리뷰를 자주 받도록 설정하는 결정과 그 결과를 머지 조건에 포함하는 결정은 다릅니다. 자동 리뷰만 켜고 실제 승인 권한은 주지 않는 사용도 하나의 선택입니다.

팀의 설정 기록에는 세 가지가 남아야 합니다. 누가 허용 범위를 정했는지, 어느 저장소에서 사용하도록 했는지, 승인이 머지 조건에 반영되는지를 어떻게 설정했는지입니다. 그래야 다른 저장소의 동작을 보고 현재 PR도 같을 것이라고 착각하지 않습니다.

파일 경로 필터는 모든 변경 파일을 기준으로 읽습니다

현재 설정 문서는 File paths에 glob을 지정해 승인 반영 대상을 좁힐 수 있다고 설명합니다. PR의 변경 파일이 모두 지정한 패턴 중 하나와 맞아야 해당 승인이 머지 요구사항에 반영되는 조건입니다. 일부 파일만 맞으면 된다는 의미로 읽지 않습니다.

가상의 저장소에서 다음 경로만 허용한다고 해보겠습니다.

docs/**

PR이 docs/install.md만 수정했다면 경로 조건에 맞는지를 검토할 수 있습니다. 그런데 같은 PR에 src/auth.py 변경이 함께 들어 있다면 “문서 파일도 있으니 허용된다”는 판단은 잘못입니다. 모든 변경 파일이 필터의 조건을 만족하는지를 보아야 합니다.

또한 문서는 이 입력을 비워 두면 모든 파일에 대해 승인이 반영될 수 있다고 안내합니다. 따라서 빈칸을 “아무 경로도 허용하지 않음”으로 해석하면 범위가 정반대로 넓어질 수 있습니다. 실제로 좁힐 목적이라면 패턴과 대상 파일 목록을 함께 확인해야 합니다.

경로 필터가 파일 내용을 안전하게 만든다는 뜻도 아닙니다. 문서에는 실행 명령이나 외부 링크, 운영 절차가 들어갈 수 있습니다. 허용한 디렉터리라는 이유만으로 내용의 영향이 작다고 단정하지 말고, 팀에서 감당할 수 있는 변경 종류인지 따로 판단해야 합니다.

문서 PR 하나를 끝까지 따라가 봅니다

설치 문서의 설명을 고치는 PR을 예로 들어보겠습니다. 먼저 변경 파일이 문서 경로에만 있는지 확인하고, Copilot이 어떤 내용을 문제로 지적했는지 읽습니다. 단순히 평가가 긍정적인지보다 제안이 실제 변경과 맞는지 보는 단계입니다.

정책과 경로 조건이 맞고 실제 승인이 제출됐다면 PR의 머지 요구사항에서 어떻게 반영됐는지 확인합니다. 승인 평가 댓글을 실제 승인으로 세거나, 실제 승인 표시를 모든 조건의 완료로 세지 않습니다. 필수 테스트나 다른 사람의 검토가 남아 있다면 별도로 완료해야 합니다.

그 뒤 작성자가 설치 절차를 수정하면서 실행 설정 파일도 함께 바꿨다고 해보겠습니다. 이제 PR의 변경 범위와 마지막 커밋이 달라졌습니다. 처음 문서만 있던 시점의 판단을 그대로 사용할 수 없습니다. 변경 파일 목록을 다시 확인하고 새 범위에 필요한 검토를 요청해야 합니다.

이 가상 사례에서 사람의 일은 AI에게 같은 질문을 반복하는 것만이 아닙니다. 무엇을 바꾸려 했는지, 실제로 바뀐 파일이 그 범위에 맞는지, 실행 절차가 결과와 일치하는지를 연결하는 일입니다. 승인 표시가 있는지와 함께 변경의 의도를 읽어야 합니다.

새 커밋 뒤에는 재검토 방식도 확인합니다

Copilot code review 개요는 Copilot 승인 뒤 새 커밋이 올라오면 승인이 해제되고 다시 리뷰를 요청할 수 있다고 설명합니다. 이전 승인이 있었다는 이력과 현재 커밋의 유효한 승인을 구분해야 합니다.

자동 재검토가 필요한 경우에는 별도의 설정도 봅니다. 설정 문서는 ruleset의 자동 리뷰 구성에서 새 push를 검토하는 옵션을 안내합니다. 그 옵션을 선택하지 않으면 PR을 한 번만 검토하는 동작과 구분해야 합니다. 새 커밋이 올라올 때마다 자동으로 다시 승인될 것이라고 가정하면 안 됩니다.

확인 순서는 현재 커밋, 승인 상태, 새 리뷰 요청 여부, 리뷰 완료 여부입니다. 재검토를 요청했다는 사실만으로 새 승인을 얻었다고 보고하지 않습니다. 다시 나온 의견이 변경된 파일과 맞는지도 읽어야 합니다.

이전 코멘트에서 지적한 문제가 해결됐더라도 새로운 변경이 다른 문제를 만들 수 있습니다. 그래서 수정된 부분만 보는 검토와 PR 전체의 최종 상태를 보는 검토를 구분해 두는 편이 좋습니다. 어떤 범위를 확인했는지가 검토 결과와 함께 남아야 합니다.

사람이 확인해야 하는 것은 여전히 남습니다

GitHub의 책임 있는 사용 안내는 code review가 문제를 놓치거나 실제로 없는 문제를 지적할 수 있다고 설명합니다. 제안한 수정도 그대로 적용하기 전에 검토와 테스트가 필요합니다.

따라서 Copilot이 지적한 문장을 문제의 증거로 곧바로 사용하지 않습니다. 해당 코드와 조건에서 실제로 문제가 생기는지 확인하고, 수정이 다른 동작을 바꾸지 않는지도 봅니다. 반대로 코멘트가 없다는 것을 오류가 없다는 증거로 사용하지 않습니다.

또한 리뷰가 참조하거나 검토하는 범위에 제한이 있을 수 있습니다. 현재 문서의 제외 대상과 저장소의 콘텐츠 제외 정책을 읽어야 하며, PR에 포함된 모든 종류의 자료가 동일한 방식으로 검토됐다고 단정하지 않습니다. 승인 기능이 생겼다는 사실과 리뷰 범위가 무제한이라는 주장은 다릅니다.

업무 규칙이나 배포 조건처럼 저장소만 읽어서는 알기 어려운 내용은 사람이 명확히 해야 합니다. 검토에 필요한 공개 가능한 설명을 준비하고, 실제 기능 테스트와 운영 판단을 연결해야 승인 결과를 올바르게 사용할 수 있습니다.

도입 결과는 승인 개수보다 적용 범위로 설명합니다

처음 적용할 때는 작은 범위를 정하고, 허용한 문서 PR과 허용하지 않은 혼합 변경을 어떻게 처리하는지 확인하는 편이 좋습니다. 정상적인 경로뿐 아니라 새 커밋 이후의 승인 해제와 재검토도 함께 점검해야 합니다. 실제 설정 변경과 시험은 해당 저장소의 권한과 팀 절차에 따라 진행합니다.

이 글에는 Copilot의 정확도나 절감 시간을 측정한 수치가 없습니다. 기능을 도입했다고 사람이 읽어야 할 코드가 일정 비율만큼 줄었다고 주장할 근거도 없습니다. 먼저 어떤 평가와 승인을 참고할지, 어떤 경로에서 머지 조건에 반영할지를 분명히 정하는 것이 필요합니다.

현재 PR의 변경 파일과 커밋, 관리자 정책, 실제 승인 반영, 남은 테스트를 함께 대조하세요. 이 관계를 설명할 수 있다면 Copilot의 승인을 유용한 검토 자료로 활용하면서도, 최종 변경에 필요한 판단을 빠뜨리지 않을 수 있습니다.