GitHub Copilot PR 코드 리뷰 자동화 만들기

 

AI 업무 자동화

GitHub Copilot PR 자동 코드 리뷰: 새 푸시마다 재검토하고 사람 승인 1명 남기기

개발자가 매번 리뷰어를 부르기 전에 1차 지적을 받되, AI 코멘트가 승인이나 병합 권한으로 바뀌지 않도록 선을 긋는 설정입니다.

작은 개발팀에서는 PR을 올린 뒤 첫 리뷰가 시작되기까지의 공백이 길다. 작성자는 단순한 누락을 뒤늦게 발견하고, 리뷰어는 변수명보다 권한 검사와 테스트 실패를 먼저 보고 싶어도 변경 파일을 처음부터 훑어야 한다. GitHub Copilot 코드 리뷰를 붙이면 이 첫 번째 훑기를 PR 생성 시점에 자동으로 시작할 수 있다. 새 커밋이 올라올 때 다시 보게 하는 옵션도 있다.

다만 여기서 자동화할 일은 코멘트 작성까지다. GitHub 공식 문서상 Copilot은 리뷰를 항상 Comment로 남기며, Approve나 Request changes를 제출하지 않는다. 필수 승인 수에도 들어가지 않고 병합을 막지도 않는다. 그래서 이번 구성은 AI 리뷰 규칙과 사람 병합 규칙을 따로 만든다. Copilot 쪽에 문제가 생기면 자동 리뷰만 끄고, 사람 승인 1명은 그대로 남길 수 있다.

문서 기준으로 구성한 실습

이 글은 2026년 7월 16일 GitHub 공식 문서를 기준으로 메뉴와 동작을 확인해 재현 절차를 구성했다. 실제 유료 Copilot 좌석과 조직 저장소를 연결해 리뷰를 실행한 사용기는 아니다. 아래 검증표의 숫자는 독자가 자신의 시험 PR에서 기록해야 한다.

완료 조건은 코멘트 개수가 아니다

Copilot이 무언가를 적었다는 이유만으로 도입이 끝나지는 않는다. 한 저장소에서 아래 다섯 가지가 함께 확인돼야 운영 후보가 된다.

• 기본 브랜치를 향한 PR을 열면 Copilot 리뷰가 자동 요청된다.
• 수정 커밋을 푸시하면 두 번째 리뷰가 실행된다.
• Copilot 리뷰가 끝나도 병합 상자에는 사람 승인 1명이 계속 필요하다.
• MCP·브라우저 도구와 별도 클라우드 에이전트 없이 리뷰 코멘트만 생성된다.
• 10개 시험 PR에서 채택할 만한 지적, 오탐, 중복 지적을 사람이 구분해 기록한다.

구분	자동화 전	이번 구성
입력	리뷰어가 열어 보기 전까지 대기하는 PR	기본 브랜치를 향한 ready-for-review PR과 이후 새 푸시
처리	사람이 변경 파일 전체를 처음부터 읽음	Copilot 1차 리뷰 → 작성자 수정 → 사람 최종 리뷰
출력	사람 리뷰 코멘트와 승인	Copilot Comment와 별도의 사람 Approve
자동화 제외	명시된 경계 없음	병합, 승인, 코드 자동 수정, 외부 MCP 호출

Copilot 요금제와 저장소 권한을 따로 본다

코드 리뷰 자체는 GitHub가 안내하는 모든 유료 Copilot 요금제에서 제공된다. 개인 계정 설정에서 자신의 PR 자동 리뷰를 켜는 기능은 Copilot Pro, Pro+ 또는 Max가 필요하다. 조직에서 받은 좌석이라면 조직 관리자가 Copilot code review 정책을 허용해야 한다. 저장소 전체에 규칙을 만들려면 저장소 관리자 또는 edit repository rules 권한이 있는 사용자여야 한다.

Rulesets의 저장소 요금 조건도 별개다. 공개 저장소는 GitHub Free에서도 ruleset을 쓸 수 있지만, 비공개 저장소는 GitHub Pro·Team·Enterprise Cloud가 필요하다. Copilot 유료 좌석이 있다고 해서 비공개 저장소의 모든 규칙 기능이 자동으로 열리는 것은 아니다.

비용은 월 좌석료로 끝나지 않는다. 현재 코드 리뷰는 토큰 사용분을 GitHub AI Credits로 계산하고, 에이전틱 분석에는 GitHub Actions minutes도 쓴다. 1 AI Credit은 0.01달러지만, 코드 리뷰 모델은 GitHub가 자동 선택하며 공개하지 않아 리뷰 한 건의 토큰 단가를 미리 고정하기 어렵다. 자동 규칙으로 실행된 리뷰의 AI Credits는 원칙적으로 PR 작성자에게, Actions minutes는 저장소 쪽에 귀속된다. 파일이 큰 PR과 매 푸시 재검토를 무턱대고 전 저장소에 켜기보다 시험 저장소 한 곳에서 소비량을 먼저 보라는 이유다.

먼저 기본 브랜치에 리뷰 기준을 넣는다

저장소 루트에 .github/copilot-instructions.md를 만든다. 길게 코딩 규칙을 복사하기보다 이 팀이 PR에서 놓치면 곤란한 세 가지를 적는 편이 낫다. 다음은 시작용 예시다.

코드 리뷰에서는 인증·인가 경계, 사용자 입력 검증, 기존 테스트와의 충돌을 먼저 확인한다.
확신할 수 없는 항목은 오류로 단정하지 말고 재현 조건이나 확인할 테스트를 제안한다.
스타일 차이보다 런타임 오류, 데이터 손실, 보안 영향을 우선한다.

이 파일은 시험 PR 안에서 새로 추가하면 늦다. Copilot은 PR의 대상이 되는 base branch에 있는 지침을 읽는다. 먼저 이 파일만 별도 PR로 검토해 기본 브랜치에 병합한 뒤 시험 PR을 만든다. 하위 경로마다 규칙이 다르면 .github/instructions/*.instructions.md를 추가할 수 있지만, 첫 주에는 저장소 공통 파일 하나로 충분하다.

자동 리뷰와 사람 병합 규칙을 두 개로 나눈다

1. Settings → Copilot → Code review에서 Allow Copilot to use MCP tools when reviewing pull requests를 끈다. 이 설정은 현재 기본 활성화이며, 그대로 두면 GitHub·Playwright MCP를 리뷰가 사용할 수 있다. 이번 흐름에는 브라우저나 외부 도구가 필요 없다.
2. Settings → Rules → Rulesets → New branch ruleset으로 가서 copilot-review-pilot을 만든다. Enforcement status는 Active, 대상 브랜치는 기본 브랜치로 제한한다.
3. Automatically request Copilot code review를 켜고 Review new pushes도 켠다. Review draft pull requests는 첫 주에는 끈다. 작성 중 커밋마다 리뷰가 생기는 소음과 비용을 피하기 위해서다.
4. 두 번째 ruleset human-merge-gate를 만든다. 같은 기본 브랜치를 대상으로 Require a pull request before merging, required approvals 1, 모든 대화 해결 요구를 켠다. 새 커밋 뒤 기존 승인을 무효화할지 여부는 팀 정책에 맞추되, 보안 민감 저장소라면 stale approval 해제를 우선 검토한다.
5. Fix with Copilot, Copilot cloud agent, 저장소 Skills, 별도 MCP 서버는 이 실습에서 켜지 않는다. 리뷰 코멘트가 맞는지 확인하기 전에 코드 쓰기 권한과 외부 연결을 늘릴 이유가 없다.

두 ruleset을 나누는 이유

자동 리뷰가 반복 오류를 내거나 예산을 초과하면 copilot-review-pilot만 Disabled로 바꾼다. 사람 승인 규칙을 같은 묶음에 넣었다면 긴급 중단 때 병합 보호까지 함께 꺼질 수 있다.

시험 PR 두 번으로 자동화 경계를 확인한다

실제 고객 코드 대신 작은 샌드박스 저장소에서 시작한다. 첫 PR에는 정상 코드와 의도적으로 빠뜨린 경계 조건을 함께 넣되, 비밀번호·토큰·실사용 개인정보는 넣지 않는다. Copilot이 특정 오류를 반드시 잡는지를 성공 조건으로 삼으면 안 된다. 모델 출력은 달라질 수 있다. 확인할 것은 리뷰 요청과 재검토, 사람 승인 경계다.

1. 기본 브랜치를 대상으로 draft가 아닌 PR을 연다. 타임라인에 Copilot 리뷰 요청이 생겼는지, Reviewers 영역에 Copilot이 표시되는지 확인한다.
2. Copilot이 남긴 리뷰 종류가 Comment인지 본다. 코멘트가 없어도 리뷰 완료 자체는 기록한다. 병합 상자에 사람 승인 1명 요구가 남아 있어야 한다.
3. 코드 한 줄과 관련 테스트를 수정해 새 커밋을 푸시한다. 두 번째 Copilot 리뷰가 타임라인에 생기는지 확인한다.
4. 코멘트마다 채택, 오탐, 중복, 판단 보류 중 하나를 표시한다. Copilot 코멘트에 답글을 달아도 Copilot은 그 답글을 읽거나 응답하지 않는다는 점도 기억한다.
5. 사람 리뷰어가 테스트 결과와 실제 코드 문맥을 확인해 Approve한다. 그 뒤에만 병합한다.

시험 PR 기록	적을 값	통과 기준
최초 리뷰	요청 시각, 완료 시각, Comment 여부	자동 요청과 완료 흔적이 남음
새 푸시	커밋 SHA, 재검토 시각	두 번째 리뷰가 새 커밋 뒤에 생성
사람 승인	Copilot 완료 전후의 merge box 상태	사람 Approve 전에는 병합 불가
품질	채택·오탐·중복·보류 건수	10개 PR을 본 뒤 팀이 계속 쓸지 판단

비용은 GitHub Actions metrics에서 copilot-pull-request-reviewer로 필터링한다. Billing usage report에서는 workflow path dynamic/agents/copilot-pull-request-reviewer를 찾는다. PR 수만 세면 새 푸시 재검토가 만든 사용량을 놓친다.

빠뜨리는 파일과 반복 코멘트는 별도 실패로 남긴다

Copilot 코드 리뷰는 모든 파일을 보지 않는다. lock 파일, 로그, SVG, dist, vendor, 생성물 디렉터리 등은 공식 제외 목록에 들어간다. requirements.txt와 여러 설정 파일도 예시에 포함된다. 의존성 변경과 빌드 설정은 기존 CI, Dependabot, 사람 리뷰로 계속 확인해야 한다.

새 푸시 재검토에서는 이미 Resolve했거나 싫어요 표시한 코멘트가 다시 나올 수 있다고 GitHub 문서가 밝힌다. 반복 코멘트를 ‘아직 해결하지 않은 결함’과 같은 것으로 세면 품질 지표가 왜곡된다. 커뮤니티에도 새 푸시 재검토가 일관적으로 보이지 않는다는 사용자 보고가 있다. 이런 경우 먼저 ruleset 대상 브랜치와 Review new pushes 설정, 조직 정책, Actions runner 사용 가능 여부를 확인하고, 필요하면 Reviewers 메뉴에서 수동 재검토를 요청한다.

문제	먼저 확인	복구
PR에 자동 리뷰가 없음	Copilot 정책, 유료 좌석, ruleset 대상, draft 여부	설정 수정 뒤 새 시험 PR 1개로 재확인
새 푸시를 다시 안 봄	Review new pushes 활성화 여부	수동 재요청 후 규칙을 고침
반복·오탐이 많음	instruction 문구와 PR 크기	자동 리뷰 ruleset만 끄고 사람 gate 유지
비용이 예상보다 큼	푸시 횟수, PR 크기, Actions minutes, AI Credits	새 푸시 재검토 또는 대상 저장소 범위를 줄임

코드는 GitHub 밖으로 나갈 수 있다는 전제로 권한을 줄인다

Copilot 코드 리뷰의 에이전틱 기능은 GitHub Actions runner에서 전체 프로젝트 문맥을 모을 수 있다. 자체 호스팅 runner가 꼭 필요하다면 GitHub가 공식 지원하는 방식은 ARC 관리 scale set뿐이며, runner의 네트워크가 내부망이나 공개 인터넷에 활짝 열리지 않도록 방화벽을 구성하라고 문서가 경고한다. 첫 시험은 별도 네트워크 권한이나 비밀정보가 없는 GitHub-hosted runner로 제한하는 편이 단순하다.

• 파일 쓰기: 자동 리뷰는 코멘트까지만 허용한다. 제안 적용과 Fix with Copilot은 사용하지 않는다.
• 셸·runner: 별도 setup steps, 자체 호스팅 runner, 내부 패키지 저장소 접속을 붙이지 않는다.
• 브라우저·MCP: PR 리뷰의 MCP 도구 사용 토글을 끈다. 외부 MCP 서버는 구성하지 않는다.
• API 키·비밀정보: 이 구성에는 별도 API 키가 필요 없다. 저장소·PR·instruction 파일에 비밀 값을 적지 않는다.
• 외부 전송: 리뷰 대상 코드와 관련 문맥이 GitHub Copilot 처리 경로로 전달될 수 있음을 보안팀과 저장소 소유자가 승인해야 한다.
• 장기 메모리: Copilot Memory는 현재 공개 미리보기이고 코드 리뷰가 저장소 수준 사실을 사용할 수 있다. 개인 요금제에서는 기본 활성화다. 시험 단계에서는 저장된 사실을 검토·삭제할 담당자가 없으면 끈다. 사용하지 않은 메모리는 28일 뒤 자동 삭제되지만, 다시 검증돼 쓰이면 기간이 갱신될 수 있다.
• 민감 경로: Copilot Business·Enterprise 조직은 content exclusion으로 특정 파일을 리뷰에서 제외할 수 있다. 다만 심볼릭 링크 등 제한이 있으므로 비밀정보를 소스에 저장하는 대안으로 보지 않는다.

로컬 도구를 쓴다는 말과 코드가 기기 안에만 남는다는 말은 다르다. 계산과 데이터가 실제로 어디로 가는지 먼저 확인하는 방법은 이전 글 Bonsai 27B 3.9GB를 읽는 법: Ollama·Claude Code의 로컬 경계에서도 같은 기준으로 다뤘다. 비공개 저장소에 Copilot 리뷰를 켜는 결정 역시 제품 이름보다 데이터 경로를 먼저 보는 편이 맞다.

첫 주에는 자동 리뷰가 몇 건을 잡았는지보다 사람 리뷰가 덜 산만해졌는지를 본다. 오탐이 많으면 instruction을 한 줄씩 고치고, PR을 작게 나눈다. 그래도 도움이 없다면 자동 리뷰 규칙만 끈다. 사람 승인과 CI를 남긴 채 쉽게 되돌릴 수 있어야 이 자동화는 안전하다.

출처와 확인 문서

• GitHub Docs — About GitHub Copilot code review
• GitHub Docs — Configuring automatic code review
• GitHub Docs — Using GitHub Copilot code review
• GitHub Docs — Adding repository custom instructions
• GitHub Docs — Files excluded from Copilot code review
• GitHub Docs — Configuring runners for code review
• GitHub Docs — Configure MCP servers for a repository
• GitHub Docs — Content exclusion for GitHub Copilot
• GitHub Docs — About GitHub Copilot Memory
• GitHub Docs — Models and pricing for GitHub Copilot
• GitHub Docs — Available rules for rulesets
• GitHub Community — automatic review 재실행 관련 사용자 보고

요금제, AI Credits, 공개 미리보기 기능, 메뉴 이름은 바뀔 수 있습니다. 실제 적용 전 각 링크와 조직의 Copilot 정책을 다시 확인하세요.