GitHub Copilot 코드 리뷰를 API로 요청하기: gh·REST로 자동 요청하고 리뷰 강도 고르기

Copilot 코드 리뷰를 PR 화면에서 손으로 요청하는 대신, 배포 스크립트나 사내 봇, 특정 라벨이 붙은 PR에서만 자동으로 요청하고 싶은 팀을 위한 글이다. 2026년 10월 2일 GitHub는 REST·GraphQL API로 Copilot 리뷰를 요청할 수 있게 했고, 기본 리뷰 강도를 Balanced로 바꿨다(GitHub Changelog). 이 글을 따라가면 gh와 REST로 리뷰를 요청하는 명령, 룰셋 자동 요청과의 역할 분담, 리뷰 강도 설정 위치를 정리해 팀 규칙으로 고정할 수 있다.

Copilot 코드 리뷰는 Pro, Pro+, Max, Business, Enterprise 플랜에서 쓸 수 있다. 리뷰 요청 방법이 늘어나도 Copilot은 기본적으로 Comment 리뷰를 남기며, 필수 승인 수에는 포함되지 않는다(사용 가이드). 사람 리뷰를 대체하는 장치가 아니라 사람 리뷰 전에 1차 지적을 받는 장치로 설계하는 것이 문서의 동작과 맞다.

요청 경로 네 가지와 고르는 기준

모든 PR에 리뷰를 받는다면 룰셋 하나로 충분하다. API가 필요한 경우는 조건이 붙을 때다. 예를 들어 needs-ai-review 라벨이 붙은 PR만, 특정 디렉터리를 건드린 PR만, 또는 사내 배포 승인 시스템에서 요청 버튼을 눌렀을 때만 리뷰를 받는 식이다.

gh CLI로 요청하기

CLI 지원 발표에 따르면 GitHub CLI 2.88.0 이상에서 @copilot을 리뷰어로 지정할 수 있다. gh pr create와 gh pr edit의 대화형 리뷰어 선택에도 Copilot이 나온다.

gh --version                       # 2.88.0 이상인지 확인
gh pr create --fill
gh pr edit --add-reviewer @copilot  # 현재 브랜치의 PR에 요청
gh pr edit 482 --add-reviewer @copilot

PR을 만들 때마다 따로 입력하기 번거롭다면 셸 별칭으로 묶어 둔다.

gh alias set prc 'pr create --fill && gh pr edit --add-reviewer @copilot' --shell
gh prc

REST API로 요청하기

API로는 기존 리뷰어 요청 엔드포인트에 Copilot 봇 계정을 넣는다. 사용 가이드는 copilot-pull-request-reviewer[bot]을 리뷰어로 요청하는 방식을 안내한다.

gh api \
  -X POST \
  repos/OWNER/REPO/pulls/482/requested_reviewers \
  -f 'reviewers[]=copilot-pull-request-reviewer[bot]'

curl로 직접 부르는 경우 본문은 {"reviewers":["copilot-pull-request-reviewer[bot]"]} 형태다. Changelog는 API 요청마다 리뷰 강도를 지정할 수 있다고 밝히고 있지만, 2026-10-12 기준 REST 레퍼런스의 이 엔드포인트 문서에는 강도 관련 파라미터가 표시돼 있지 않았다. 요청별 강도를 쓰려면 레퍼런스에 파라미터 이름이 올라왔는지 먼저 확인하고, 그 전까지는 아래에서 다룰 설정 계층으로 강도를 정한다. 이 엔드포인트는 알림을 발생시키고 짧은 시간에 많이 호출하면 보조 속도 제한(secondary rate limit)에 걸릴 수 있다는 점도 레퍼런스에 적혀 있다.

라벨이 붙은 PR만 리뷰 요청하는 워크플로

조건부 요청을 GitHub Actions로 만들면 다음과 같다. 라벨 이벤트에서만 실행되고, 라벨 이름이 맞을 때만 요청한다.

# .github/workflows/copilot-review-on-label.yml
name: copilot-review-on-label
on:
  pull_request:
    types: [labeled]

permissions:
  pull-requests: write

jobs:
  request:
    if: github.event.label.name == 'needs-ai-review'
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.REVIEW_REQUEST_TOKEN }}
        run: |
          gh api -X POST \
            repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/requested_reviewers \
            -f 'reviewers[]=copilot-pull-request-reviewer[bot]'

여기서는 기본 GITHUB_TOKEN 대신 별도 토큰을 쓰는 예로 적었다. 설정 문서에 따르면 엔터프라이즈 룰셋에서 코드 리뷰 과금 주체를 멤버·조직 등으로 고를 수 있고, 10월 8일에는 조직 단위 과금 옵션과 제어 기능이 추가됐다. 어떤 계정의 토큰으로 요청할지는 이 과금 설정과 맞춰 관리자와 함께 정한다. 같은 이벤트 구조로 다른 AI 리뷰 도구를 붙이는 방법은 GitHub Actions와 AI 코드 리뷰 봇 연동에서 다뤘다.

리뷰 강도 Lite와 Balanced 고르기

코드 리뷰 설정 문서에 나온 강도는 다음과 같다. 2026년 9월 28일부터 기존 저장소와 새 저장소 모두 Default 선택이 Balanced로 동작하며, 이전에 Lite를 명시해 둔 설정은 그대로 유지됐다.

강도는 네 단계에서 설정하며, 아래 단계가 위 단계 설정을 덮어쓴다. 팀 단위 기본값은 조직에서 정하고, 특정 저장소만 다르게 가져가야 할 때 저장소 설정을 쓰는 구성이 관리하기 쉽다.

1. 엔터프라이즈 — AI controls → Agents → Copilot code review
2. 조직 — Settings → Copilot → Code review
3. 저장소 — Settings → Copilot → Code review
4. 개인 — 프로필 → Copilot settings → Code review

룰셋 자동 요청과 함께 쓸 때 정할 것

룰셋 자동 요청을 켜 둔 저장소에서 API 요청까지 추가하면 같은 PR에 리뷰가 중복으로 요청될 수 있다. 둘의 대상을 겹치지 않게 나눈다. 예를 들어 main 대상 PR은 룰셋으로 자동 요청하고, 장기 기능 브랜치 대상 PR은 라벨 기반 API 요청으로만 받는 식이다. 룰셋에는 "Review new pushes"(새 커밋마다 재리뷰)와 "Review draft pull requests" 옵션이 있는데, 푸시가 잦은 브랜치에서 새 푸시 재리뷰를 켜면 요청 횟수가 빠르게 늘어난다. 수동 재리뷰는 Reviewers 메뉴의 Copilot 옆 동기화 아이콘으로 할 수 있다.

리뷰 품질은 지침 파일에 좌우된다. 사용 가이드에 따르면 Copilot은 리뷰할 때 .github/copilot-instructions.md, .github/instructions/**/*.instructions.md, AGENTS.md를 읽고, 있으면 CLAUDE.md·GEMINI.md·REVIEW.md도 읽는다. 이 지침은 base 브랜치가 아니라 head 브랜치의 파일을 기준으로 읽으므로, PR 작성자가 지침 파일을 바꾸면 그 PR의 리뷰 기준도 바뀐다는 점을 알고 있어야 한다. 지침 파일 작성법은 Copilot 저장소 지침 파일 작성과 적용 범위에서, AI 리뷰와 사람 리뷰의 역할 분담은 AI가 작성한 코드의 리뷰 규칙에서 다뤘다.

# 지침 파일을 바꾼 PR을 찾아 사람 리뷰를 따로 요구하는 CODEOWNERS 예시
/.github/copilot-instructions.md   @org/platform-leads
/.github/instructions/              @org/platform-leads
/AGENTS.md                         @org/platform-leads
/REVIEW.md                         @org/platform-leads

도입 첫 주에 확인할 지표

자동 요청을 넓히기 전에 두세 개 저장소에서 다음을 기록해 둔다. 요청 건수 대비 Copilot 리뷰 코멘트 수, 그중 실제로 코드 수정으로 이어진 비율, 리뷰 대기로 병합이 늦어진 사례가 있는지다. 반영 비율이 낮은 영역은 강도를 Lite로 낮추거나 자동 요청 대상에서 빼고, 반영 비율이 높은 영역은 라벨 조건을 없애 룰셋으로 옮긴다. 이 판단은 조직 대시보드의 사용량 지표와 함께 보는 것이 정확하다. 10월 6일 Changelog에 따르면 IDE를 업데이트해야 Copilot 사용량 지표에 에이전트 활동이 다시 집계되므로, 지표를 볼 때 팀원 IDE 버전도 확인한다.