Copilot 코드 리뷰 API 도입 전 확인할 5가지

Copilot 코드 리뷰를 API로 연결하려면 먼저 실제 적용 effort, 중복 요청, 비용 확인 방법을 정해야 합니다. 작은 저장소에서 요청 접수부터 리뷰 완료까지 확인한 뒤 자동화 범위를 넓히는 순서를 권합니다. 이미 자동 리뷰를 쓰고 있다면 새 API보다 바뀐 기본값부터 점검하는 편이 빠릅니다.

작성: David Cho · 자료 확인: 2026년 10월 4일(KST)

GitHub는 2026년 10월 2일 변경 기록에서 REST·GraphQL을 통한 Copilot 코드 리뷰 요청과 요청별 effort 선택을 발표했습니다. 대상은 Copilot Pro, Pro+, Max, Business, Enterprise이며 일반 제공(GA)입니다. 함께 공지한 Default의 Balanced 전환은 9월 28일부터 적용됐습니다. 명시적으로 Lite를 선택한 설정은 유지됩니다.

아래 내용은 공식 문서를 바탕으로 만든 도입 체크리스트입니다. 운영 절차와 실패 상황은 검토용 제안이며, 실제 계정에서 API를 실행하거나 성능을 측정한 결과는 아닙니다.

1. API 접근 권한과 Copilot 사용 조건을 따로 확인하기

Copilot 사용 문서는 REST의 리뷰어 목록에 copilot-pull-request-reviewer[bot]을 넣는 방법을 안내합니다. 리뷰 요청 REST 문서에 따르면 해당 엔드포인트를 사용하는 세분화 토큰에는 저장소의 Pull requests 쓰기 권한이 필요합니다.

확인된 최소 요청 구조는 다음과 같습니다. 인증 헤더와 API 버전 헤더를 생략한 설명용 예시이며 실행 테스트는 하지 않았습니다. OWNER, REPO, PR_NUMBER는 실제 대상 값으로 바꿔야 합니다.

POST /repos/OWNER/REPO/pulls/PR_NUMBER/requested_reviewers

{
  "reviewers": ["copilot-pull-request-reviewer[bot]"]
}

요청별 effort 필드명은 이 예시에 넣지 않았습니다. 릴리스 공지는 그 기능을 명시하지만, 확인 시점의 REST 매개변수 표와 GraphQL 입력 객체에서는 해당 필드를 확인하지 못했습니다. 위 요청은 effort를 지정하지 않습니다. 연동할 때 최신 스키마에서 필드명과 허용값을 확인해야 합니다.

처음부터 토큰 권한을 넓히기보다, 대상 저장소와 PR 번호가 맞는지, 실행 주체가 필요한 접근권을 갖는지, 그 저장소에서 Copilot 리뷰를 사용할 수 있는지를 각각 점검하십시오. 이 세 항목을 한 번에 바꾸면 무엇 때문에 동작했는지 기록하기 어렵습니다. 인증 정보는 코드나 PR 댓글에 넣지 말고 기존 비밀 관리 경로를 사용합니다.

2. 조직 기본값만 보고 실제 effort를 판단하지 않기

리뷰의 분석 수준을 뜻하는 effort는 설정 화면 한 곳만 보고 확정할 수 없습니다. 공식 우선순위 안내는 요청할 때 선택한 값, 해당 PR에서 전에 사용한 값, 요청자 설정, 저장소 설정, 조직 설정 또는 개인 저장소 소유자 설정, GitHub 기본값 순으로 적용 가능한 값을 찾습니다. 실행된 값은 PR의 리뷰 요약 댓글에서 확인할 수 있습니다.

기업 계정을 쓴다면 기업 수준 기본값도 확인 대상입니다. 이 값은 조직 소유 저장소에 상속되며 조직과 저장소가 별도 값을 지정할 수 있습니다. 설정 경로는 구성 문서에서 확인할 수 있습니다.

예를 들어 조직 설정을 Balanced로 바꿔도 기존 PR의 Lite가 우선할 수 있습니다. 신규 PR과 이미 리뷰받은 PR을 같은 요청자로 나눠 확인하고, 결과에 표시된 effort를 기록하십시오. 문서 우선순위에서 도출한 점검 사례이며 실측 결과는 아닙니다.

팀의 의도가 “항상 Lite”라면 Default라는 이름을 그 뜻으로 사용하지 마십시오. Default는 제공자가 정한 기본값을 따라가는 선택입니다. 반대로 변경 위험에 따라 effort를 달리하려면 선택한 이유와 실제 실행값을 함께 남겨야 나중에 결과를 비교할 수 있습니다.

3. 요청 접수와 리뷰 완료를 다른 상태로 관리하기

REST 문서는 리뷰 요청 성공 응답을 201로 안내합니다. 요청한 리뷰어 목록 조회에서는 리뷰를 제출한 사람이 목록에서 빠지며, 완료된 리뷰는 별도 리뷰 목록에서 확인하도록 설명합니다. 따라서 API 성공 응답만으로 “검토 완료” 상태를 만들면 안 됩니다.

자동화에는 최소한 요청 전, 요청 접수, 결과 확인의 세 상태를 두는 편이 좋습니다. 예를 들어 요청은 접수됐지만 네트워크 문제로 응답을 받지 못했다면, 곧바로 재전송하기 전에 PR의 현재 리뷰 상태를 조회합니다. 외부 호출의 재시도와 실제 리뷰의 재실행을 같은 버튼으로 처리하지 않는 것이 핵심입니다.

  • 식별: 저장소, PR 번호, 검토 대상 커밋 SHA를 기록합니다.
  • 대기: 같은 대상의 요청이 진행 중이면 새 요청을 보류합니다.
  • 완료: 리뷰 링크와 확인 시각을 저장하고, 도중에 새 커밋이 들어왔는지 확인합니다.
  • 재시도: 권한 오류, 일시 오류, 이미 접수된 요청을 구분한 뒤 다음 행동을 정합니다.

개인 설정과 저장소 규칙에 의한 자동 리뷰도 먼저 살펴보십시오. 구성 문서는 여러 자동 리뷰 조건이 겹쳐도 하나의 리뷰를 남긴다고 설명합니다. 다만 이것을 별도로 만든 API 호출의 중복 방지 보장으로 확대 해석해서는 안 됩니다. 기존 자동 트리거에 새 워크플로를 덧붙이기 전에, 어느 경로가 요청을 책임질지 정하십시오.

4. 비용은 실행 횟수와 함께 기록하기

공식 사용량 안내는 리뷰의 AI 크레딧과 에이전트 기능의 GitHub Actions 사용량을 구분합니다. Balanced는 Lite보다 AI 크레딧을 더 사용하며 Actions 사용량도 다소 늘 수 있습니다. 조직의 봇으로 리뷰를 요청하는 자동화라면 조직에 청구되는 사용량도 확인해야 합니다.

따라서 자동화 전환의 비용 검토에는 “어떤 수준으로 실행했나”와 “몇 번 요청했나”가 함께 있어야 합니다. 사람이 한 번 누르던 요청을 모든 push마다 실행하도록 바꾸면 비교 조건도 달라집니다. 단순히 이전 주와 이번 주 청구 총액만 비교하면 코드 변경량과 실행 빈도 차이를 놓치기 쉽습니다.

시범 적용 기록에는 PR별 요청 횟수, 실제 effort, 변경 규모, AI 사용량, Actions 사용량을 남기십시오. 품질 쪽에는 사람이 받아들인 지적과 불필요하다고 판단한 지적을 짧게 적습니다. 이 자료가 있어야 더 깊은 분석의 추가 비용이 팀에 도움이 되는지 판단할 수 있습니다. 특정 절감률이나 처리 시간은 직접 측정하기 전에는 목표와 결과를 구분해 써야 합니다.

5. 리뷰 자동화와 병합 승인 정책을 따로 결정하기

Copilot 승인 문서에 따르면 기본 리뷰는 필수 승인 수에 포함되지 않습니다. Copilot의 승인 기능은 별도 설정이 필요한 공개 프리뷰입니다. 이번 API의 일반 제공과 승인 기능의 출시 상태를 혼동하지 않아야 합니다.

초기 도입에서는 기존 사람 리뷰와 테스트 통과 조건을 유지하는 방법을 권합니다. AI가 문제를 지적하지 않았다는 이유만으로 검증 항목을 건너뛰지 마십시오. 예를 들어 데이터 삭제 경로를 바꾼 PR이라면 담당자가 삭제 조건과 복구 절차를 직접 확인해야 합니다. 이는 Copilot의 특정 결함을 주장하는 것이 아니라 팀의 최종 책임 범위를 정하는 운영 원칙입니다.

실패 때의 처리도 정해 두면 좋습니다. 리뷰가 완료되지 않거나 기대한 effort로 실행되지 않았을 때 누가 확인할지, 자동 요청을 어디서 멈출지, 기존 수동 리뷰로 어떻게 돌아갈지 적어 두십시오. 자동화가 멈췄다는 사실을 사람이 볼 수 있어야 조용히 검토가 누락되는 일을 줄일 수 있습니다.

작은 저장소 하나에서 시작할 도입 순서

  1. 현재 개인·저장소·조직 설정과 자동 요청 경로를 기록합니다.
  2. 검토 대상과 책임자가 분명한 PR 하나를 골라 최소 요청부터 확인합니다.
  3. 접수 상태, 완료된 리뷰, 실제 effort, 사용량을 대조합니다.
  4. 새 커밋과 응답 지연 상황에서 중복 요청을 막는지 확인합니다.
  5. 중단 방법과 사람 리뷰 경로까지 확인한 뒤 적용 저장소를 늘립니다.

도입 판단은 API 호출 한 번의 성공보다, 어떤 코드에 어떤 리뷰가 실행됐는지 설명할 수 있는가에 두는 편이 좋습니다. 이미 쓰던 자동 리뷰의 목적이 충족된다면 API 연결을 서두를 필요는 없습니다. 외부 작업 흐름에서 요청 시점을 제어해야 할 때 이 다섯 항목을 기준으로 범위를 정하십시오.

공식 변경 기록과 문서를 바탕으로 AI의 도움을 받아 작성했습니다. 예시는 도입 설계용이며 실측 성능·비용 비교는 포함하지 않습니다.

댓글

댓글 쓰기