GitHub Copilot 코드 리뷰 API·Balanced 기본값 정리

GitHub Copilot 코드 리뷰를 이제 API로도 요청할 수 있다. GitHub은 10월 2일 체인지로그에서 REST·GraphQL API로 Copilot에게 PR 리뷰를 맡길 수 있고, 요청할 때마다 리뷰 강도(effort level)를 따로 고를 수 있다고 발표했다. 같은 글에서 기본 리뷰 강도가 Lite에서 Balanced로 바뀌었다는 사실도 확정했다. 전환은 9월 28일부터 적용됐고, 대상 플랜은 Copilot Pro, Pro+, Max, Business, Enterprise다.

두 소식은 따로 떨어진 얘기가 아니다. 스크립트나 사내 도구에서 리뷰를 대량으로 걸기 시작하면, 리뷰 한 건의 강도가 곧 비용이 된다. 이 글은 API로 리뷰를 거는 실제 방법, 강도가 정해지는 순서, 그리고 그게 청구서에 어떻게 찍히는지를 공식 문서 기준으로 정리했다. 9월에 다룬 개요 댓글·해결 이력·커밋 메시지 자동 생성 얘기는 지난 글에 있으니 여기선 반복하지 않는다.

리뷰 강도(effort level)는 무엇이고, 기본값은 어떻게 바뀌었나

리뷰 강도는 Copilot이 PR을 얼마나 깊게 볼지 정하는 설정이다. 8월 7일 정식 출시 때 공개 프리뷰 시절 이름(Low, Medium)이 Lite와 Balanced로 바뀌었고, 기존 설정은 새 이름으로 그대로 옮겨졌다. GitHub 문서의 설명을 옮기면 이렇다.

강도	하는 일	리뷰 1건당 예상 AI 크레딧
Lite	버그·보안 취약점·스타일 불일치 같은 흔한 문제를 빠르게 짚는 표준 리뷰	약 0.05~1달러
Balanced	더 높은 추론 모델로 보내 복잡한 로직, 보안 민감 코드, 여러 서비스에 걸친 변경을 길게 분석	약 0.25~5달러

금액 범위는 문서가 밝힌 추정치다. PR이 크거나 저장소 지침이 길수록 늘고, 모델이 바뀌면 범위도 달라질 수 있다고 적혀 있다. GitHub Actions 사용 시간은 이 숫자에 들어 있지 않다. 단순히 계산하면 Balanced의 하한이 Lite의 다섯 배다.

기본값 변경은 8월 28일 예고된 내용이다. 저장소·조직 설정에서 강도를 'Default'로 둔 곳은 9월 28일부터 Balanced로 돈다. 그 전에 명시적으로 Lite를 골라 둔 곳은 그대로 Lite다. 즉 아무것도 안 건드린 팀일수록 리뷰가 깊어졌고, 그만큼 크레딧도 더 쓰게 됐다.

실제로 어떻게 돌고 있는지 공개 저장소에서 확인해 봤다. 10월 3~4일에 생성되고 Copilot 리뷰가 달린 공개 PR 60건의 리뷰 본문을 gh api로 읽어, 개요 댓글의 **Review effort:** 줄을 셌다(10월 5일, macOS·gh 2.101.0, 읽기 전용 호출만). 강도가 찍힌 27건 중 Balanced가 21건, Lite가 6건이었다. 표본이 작고 공개 저장소만 본 결과라 일반화할 순 없지만, 기본값 전환 뒤 Balanced가 대세가 된 흐름은 보인다.

그렇다면 한 리뷰의 강도는 정확히 어떻게 정해질까. 문서는 아래 순서로 확인해 처음 해당하는 값을 쓴다고 설명한다.

리뷰를 요청할 때 고른 강도
이 PR에서 이전에 쓴 강도
요청자 개인 설정의 강도(새 PR이면 작성자, 초안을 리뷰 준비 상태로 바꾸면 그 사람)
저장소에 설정된 강도
조직에 설정된 강도(개인 저장소면 소유자의 설정)
GitHub 기본값, 지금은 Balanced

2번이 놓치기 쉽다. 한 번 Balanced로 리뷰한 PR은, 다음 요청에서 강도를 따로 지정하지 않으면 계속 Balanced로 다시 리뷰된다. 저장소 기본값을 Lite로 바꿔도 이미 열려 있는 PR에는 바로 적용되지 않을 수 있다는 뜻이다.

API로 Copilot 리뷰를 요청하는 방법

새 전용 엔드포인트가 생긴 건 아니다. 사람에게 리뷰를 요청할 때 쓰던 기존 API에 Copilot의 봇 계정을 리뷰어로 넣는 방식이다. REST에서는 PR 리뷰어 요청 엔드포인트에 copilot-pull-request-reviewer[bot]을 넘긴다.

curl -L -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/pulls/PR_NUMBER/requested_reviewers \
  -d '{"reviewers":["copilot-pull-request-reviewer[bot]"]}'

gh CLI를 쓰면 더 짧다. 두 줄 다 같은 일을 한다.

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

gh pr edit PR_NUMBER --add-reviewer @copilot

GraphQL에서는 requestReviewsByLogin 뮤테이션의 botLogins 필드를 쓴다. 공개 GraphQL 스키마의 필드 설명에 예시 값으로 이 봇 이름이 그대로 적혀 있다. 기존 리뷰어를 지우지 않으려면 union: true를 함께 준다.

mutation {
  requestReviewsByLogin(input: {
    pullRequestId: "PR_NODE_ID",
    botLogins: ["copilot-pull-request-reviewer[bot]"],
    union: true
  }) { pullRequest { number } }
}

예시는 문서와 스키마에 있는 형식을 옮긴 것이다. 우리 쪽에서 실제 PR에 리뷰를 걸어 보진 않았다 — 비용이 나가는 쓰기 호출이라서다.

여기서 정직하게 짚어야 할 공백이 하나 있다. 체인지로그는 "요청할 때 강도를 지정할 수 있다"고 했지만, 그 파라미터 이름이 아직 어디에도 공개되지 않았다. 10월 5일 기준으로 REST 레퍼런스의 리뷰어 요청 본문 파라미터는 reviewers, team_reviewers 두 개뿐이었다. GitHub이 공개하는 OpenAPI 명세(rest-api-description 저장소)와 GraphQL 공개 스키마에서도 effort 관련 필드를 찾지 못했다. gh 2.101.0의 gh pr edit --help에도 강도 옵션은 없다. 당장은 강도를 API로 고르기보다, 저장소·조직·개인 설정으로 미리 정해 두고 API는 "리뷰를 건다"는 용도로만 쓰는 게 현실적이다.

결과를 읽어 오는 쪽은 바로 해 볼 수 있다. 공개 PR 하나를 골라 같은 리뷰를 세 가지 API로 조회했더니 Copilot의 이름이 매번 달랐다.

REST 리뷰 목록(pulls/N/reviews)의 작성자: copilot-pull-request-reviewer[bot]
GraphQL latestReviews의 작성자: copilot-pull-request-reviewer([bot] 없음, 타입은 Bot)
타임라인 이벤트(issues/N/events)의 review_requested 대상: Copilot

스크립트에서 Copilot 리뷰만 골라내려면 이름을 정확히 비교하기보다 copilot이 들어가는지로 거르는 편이 덜 깨진다. 리뷰에 쓰인 강도는 리뷰 본문에서 뽑으면 된다.

gh api repos/OWNER/REPO/pulls/PR_NUMBER/reviews \
  --jq '.[] | select(.user.login | test("copilot")) | .body | capture("\\*\\*Review effort:\\*\\* (?<effort>[A-Za-z]+)")'
# {"effort":"Lite"}

비용은 premium request가 아니라 AI 크레딧으로 나간다

"리뷰 한 번에 premium request 몇 개"로 기억하고 있다면 이제 맞지 않는다. GitHub은 6월 1일 사용량 기반 과금으로 넘어갔다. 지금 코드 리뷰는 두 갈래로 청구된다. 리뷰 자체(모델 토큰)는 AI 크레딧으로, 맥락 수집과 도구 실행을 맡는 에이전트 인프라는 GitHub Actions 사용 시간으로. 코드 리뷰는 어떤 모델을 쓰는지 공개하지 않는 예외라서, 토큰 단가표로 미리 계산할 수도 없다.

예외는 있다. 6월 1일 이후에도 옛 premium request 방식에 남은 연간 결제 Copilot Pro·Pro+ 사용자다. 이 경우 문서상 코드 리뷰의 배수는 13이다. 리뷰 한 번에 월 premium request 할당량이 13개씩 줄어든다는 뜻이다.

API 자동화에서 가장 중요한 건 누구에게 청구되느냐다. 문서 기준 규칙은 이렇다.

사람이 직접 요청하면 AI 크레딧은 요청한 사람에게 붙는다. 자동 리뷰 정책으로 걸리면 PR 작성자에게 붙는다.
요청자에게 Copilot 좌석이 없으면 엔터프라이즈나 비용 센터로 청구된다.
봇이 리뷰를 요청하면 조직에 직접 청구된다. 다른 봇이 만든 PR도 마찬가지다.
Actions 사용 시간은 저장소 기준으로 잡힌다. 사용량은 Actions 지표에서 copilot-pull-request-reviewer 워크플로로, 결제 사용량 보고서에서는 workflow_path 값 dynamic/agents/copilot-pull-request-reviewer로 걸러 볼 수 있다.

세 번째 줄이 API 연동과 바로 이어진다. GitHub Actions의 GITHUB_TOKEN이나 GitHub App 설치 토큰(installation access token)으로 리뷰를 걸면 요청자는 봇이다. 개인 한도와 상관없이 조직 비용으로 쌓인다. 같은 GitHub App이라도 사용자 액세스 토큰(user access token)은 사용자를 대신해 요청하는 토큰이라 봇 요청과 같은 규칙으로 단정할 수 없다. 개인 토큰(PAT)으로 걸면 기본적으로는 그 사람의 크레딧과 예산을 쓴다. 다만 엔터프라이즈·조직 소유자가 구성원의 리뷰 비용을 조직에 청구하도록 바꿔 둘 수 있어서, 그 설정이 켜져 있다면 조직 비용이 된다. Business·Enterprise에서는 사용자 예산이나 조직 지출 한도에 닿는 순간 코드 리뷰가 다른 크레딧 기능과 함께 막힌다.

막혔을 때 리뷰가 어떻게 보이는지도 알아 두면 좋다. 위 표본 조회에서 한도에 걸린 리뷰는 오류 코드가 아니라 일반 리뷰처럼 COMMENTED 상태로 달렸고, 본문은 "Copilot was unable to review this pull request because the user who requested the review has reached their quota limit." 한 줄이었다. API 호출 자체는 성공한 것처럼 보이니, 스크립트가 "리뷰 완료"로 착각하지 않게 이 문구를 따로 걸러야 한다.

자동화에 붙이기 전에 정해 둘 것

개인적으로는 이번 API가 "리뷰를 언제 걸지"를 사람 손에서 떼어 놓는 데 의미가 있다고 본다. 라벨이 붙었을 때만, 특정 경로를 건드렸을 때만, 사람 리뷰어가 승인하기 직전에만 — 이런 조건부 리뷰를 저장소 규칙(ruleset)만으로 짜기는 번거로웠다. 대신 비용 통제는 더 신경 써야 한다. 순서대로 보면 이렇다.

기본 강도를 일부러 고른다. 'Default'로 두면 이제 Balanced다. 문서 기준 Balanced 하한이 Lite의 다섯 배이니, 일상적인 PR이 많은 저장소라면 Lite를 명시하고 보안·결제처럼 중요한 경로만 Balanced로 돌리는 구성을 생각해 볼 만하다.
어떤 토큰으로 요청할지 정한다. 봇 토큰이면 조직 비용, 개인 토큰이면 기본은 개인 예산이다(조직 청구 설정이 켜져 있으면 조직 비용). 예산 담당자와 먼저 맞춰 두지 않으면 월말에 놀라게 된다.
같은 PR의 재요청을 줄인다. 위 우선순위의 2번 때문에 한 번 Balanced로 본 PR은 계속 Balanced로 다시 본다. 푸시마다 API로 다시 거는 스크립트라면 비용이 PR 길이에 비례해 늘어난다.
한도 초과 응답을 처리한다. COMMENTED 상태와 quota 문구를 함께 확인해 실패로 분류한다.

보안 이력도 찾아봤다. Copilot 코드 리뷰 자체에 대해 공개된 취약점 보고는 찾지 못했다. 다만 같은 Copilot 계열인 클라우드 에이전트(이슈를 받아 PR을 만드는 쪽)에서는 사례가 있었다. 보안 연구자 Aonan Guan이 4월 공개한 'Comment and Control' 연구로, 이슈 본문에 사람 눈에 안 보이는 HTML 주석으로 명령을 숨겨 두면 Copilot에게 이슈를 맡기는 순간 에이전트가 그 명령을 실행해 GITHUB_TOKEN 같은 자격 증명이 노출될 수 있었다. GitHub은 이를 "이미 알려진 아키텍처상 한계"로 분류하고 3월 9일 500달러의 보상금을 지급했다고 연구자는 적었다. 코드 리뷰와는 다른 제품이지만, PR 제목·설명·댓글을 그대로 AI에게 넘기는 자동화라는 점은 같다. 외부 기여자 PR에 API로 리뷰를 자동으로 거는 구성이라면, 리뷰 요청 토큰의 권한을 pull-requests: write 정도로 좁혀 두는 게 기본이다.

리뷰 강도가 개요 댓글에 찍히기 시작한 게 8월 정식 출시 때이고, 그 강도를 요청 단위로 고르는 길이 열린 게 이번이다. 파라미터 이름이 문서에 올라오면 위 1번 구성을 API 한 줄로 끝낼 수 있게 된다.

이 글에 인용·번역한 GitHub Docs(docs.github.com) 내용은 CC BY 4.0 라이선스를 따른다.

깃허브 코파일럿(GitHub Copilot) 코드 리뷰 API 요청법 — 기본 강도 Balanced 전환과 AI 크레딧 비용

리뷰 강도(effort level)는 무엇이고, 기본값은 어떻게 바뀌었나

API로 Copilot 리뷰를 요청하는 방법

비용은 premium request가 아니라 AI 크레딧으로 나간다

자동화에 붙이기 전에 정해 둘 것

관련 글