이번 발표는 리뷰의 호출 지점을 바꿨다
GitHub가 10월 2일 발표한 변경은 Copilot 코드 리뷰를 REST와 GraphQL API에서 요청할 수 있다는 것이다. 요청할 때 review effort, 즉 분석 수준도 지정할 수 있다. 브라우저의 PR 화면에서 사람이 리뷰어를 선택하는 흐름에 더해, 내부 도구나 스크립트가 리뷰를 시작하는 방법이 열린 셈이다.
예를 들어 팀이 자체 릴리스 화면을 운영한다면 그 화면에서 검토 요청을 보낼 수 있다. 변경 파일의 종류를 보고 추가 점검이 필요할 때만 요청하거나, 사내 검사 결과와 함께 리뷰 상태를 표시하는 구성도 생각할 수 있다. 이것은 API를 활용하는 설계 예시이지, 발표와 함께 그런 정책이 자동으로 적용된다는 의미는 아니다.
지원 플랜과 기능 상태도 나눠 봐야 한다. 발표는 Pro, Pro+, Max, Business, Enterprise에서 API 지원이 일반 제공된다고 명시한다. 무료 플랜에도 같은 조건으로 열렸다고 확대해 읽으면 안 된다. 또 API로 리뷰를 부르는 기능과 Copilot이 병합 요건을 충족하는 승인까지 남기는 기능은 서로 다른 설정이다.
Balanced 기본값은 이미 9월 28일에 적용됐다
같은 공지에는 분석 수준 기본값 변경도 함께 실려 있다. 하지만 날짜를 자세히 보면 적용일은 10월 2일이 아니라 9월 28일이다. 기본 옵션인 Default를 사용하던 새 저장소와 기존 저장소·조직의 동작이 Balanced로 바뀌었고, Lite를 명시적으로 고른 설정은 그대로 존중됐다.
따라서 ‘공지 이후 갑자기 모든 리뷰가 Balanced가 됐다’고 설명하면 두 가지를 놓친다. 첫째, 변경은 API 발표보다 먼저 일어났다. 둘째, 직접 지정한 선택과 제품 기본값은 다르다. 아래 원문 화면의 Default와 명시적으로 고르는 Lite를 구분해서 봐야 하는 이유다.
운영 중인 팀이라면 문서의 기본값 설명만 읽고 끝내지 말고, 실제 PR에 남은 리뷰 개요에서 사용한 수준을 확인하는 편이 낫다. 공지는 여러 관리 범위에서 기본값을 설정할 수 있다고 안내하지만, 개별 요청과 해당 PR에 이미 사용된 값까지 포함하면 적용 우선순위가 더 세밀해진다.
조직 기본값보다 요청별 선택이 먼저다
공식 개념 문서는 적용 순서를 개별 요청의 선택, 해당 PR에서 앞서 사용한 값, 요청자의 설정, 저장소 설정, 조직 또는 소유자의 설정, GitHub 기본값 순으로 설명한다. ‘조직에서 Balanced로 정했으니 모든 요청이 같은 값일 것’이라고 단정할 수 없는 구조다.
새 API를 붙일 때는 이 우선순위가 재현성에 영향을 준다. 같은 저장소의 비슷한 PR을 비교하더라도 이전 실행에서 다른 수준을 골랐다면 결과와 사용량이 달라질 수 있다. 요청을 보내는 시스템에서는 선택한 수준과 PR의 커밋을 함께 기록하고, 결과를 가져올 때도 어떤 실행에 대한 피드백인지 연결하는 방식이 유용하다.
이 기록은 복잡한 분석 시스템이 아니어도 된다. PR 번호, 검사 대상 커밋, 요청한 분석 수준, 요청 시각, 완료 상태 정도부터 남길 수 있다. 이후 문제를 추적할 때는 ‘Copilot이 다르게 답했다’는 인상 대신, 입력 코드나 설정 중 무엇이 달랐는지를 확인할 단서가 된다.
| 순서 | 먼저 적용되는 선택 |
|---|---|
| 1 | 이번 리뷰 요청에 명시한 분석 수준 |
| 2 | 이 PR에 앞서 사용한 분석 수준 |
| 3 | 요청자의 설정 |
| 4 | 저장소 설정 |
| 5 | 조직 또는 개인 저장소 소유자의 설정 |
| 6 | GitHub의 내장 기본값 |
GitHub 공식 개념 문서의 우선순위. 단순히 가장 상위 조직의 설정을 고정 적용하는 구조가 아니다.
근거 [2]
Lite와 Balanced를 비용까지 놓고 비교하면
Lite는 일반적인 문제를 빠르게 짚는 검토에, Balanced는 복잡한 로직이나 보안에 민감한 코드, 여러 서비스에 걸친 변경을 더 깊이 분석하는 데 초점이 있다. GitHub는 Balanced가 더 많은 AI credits를 사용하며 실행 시간 사용량도 조금 늘 수 있다고 설명한다. 분석 수준은 이름만 다른 화면 옵션이 아니라 사용 자원이 달라지는 선택이다.
공식 문서의 예상 사용량은 Lite 리뷰당 0.05~1달러, Balanced는 0.25~5달러 상당의 AI credits다. 고정 판매가가 아니라 PR 크기와 사용자 지침 등에 따라 달라지는 추정 범위이고, GitHub Actions 실행 시간은 포함하지 않는다. 이 숫자를 그대로 월 예상 청구액이라고 쓰거나, 모든 리뷰가 범위 안에서 끝난다고 보장해서는 안 된다.
처음 연결하는 팀이라면 일상적인 작은 변경과 여러 서비스에 걸친 변경을 나눠 사용량을 보는 편이 이해하기 쉽다. 실행 횟수만 세지 말고, 사람이 채택한 지적과 무시한 지적, 다시 실행한 횟수도 같이 남기면 비용이 실제 검토 작업을 얼마나 덜어 줬는지 판단할 수 있다. 여기서 제시하는 방식은 도입 평가를 위한 제안이며, 특정 수준의 품질 우위를 측정한 결과는 아니다.
자동 리뷰를 켜는 것과 paid usage 또는 실행 환경을 바꾸는 일도 분리해야 한다. 이 글을 읽거나 예시를 검토하는 것만으로 설정이 바뀌지는 않는다. 실제 적용 시에는 조직의 예산과 현재 정책을 확인한 뒤 필요한 범위만 활성화하는 것이 순서다.
새 커밋을 push했다고 항상 다시 읽는 것은 아니다
Copilot이 한 번 검토한 PR에 새 커밋을 올렸을 때 자동 재리뷰가 일어나는지는 별도 설정에 달려 있다. 사용 문서는 자동 리뷰와 함께 Review new pushes를 구성하지 않았다면 변경을 자동으로 다시 검토하지 않는다고 설명한다. 처음 한 번 API 요청에 성공한 것만으로 이후 수정까지 계속 점검된다고 볼 수 없다.
반대로 저장소의 자동 정책과 내부 API 호출을 함께 운영하면 중복 요청을 관리해야 한다. 자체 자동화에서는 같은 PR의 같은 커밋에 이미 요청 중인 검토가 있는지 확인하고, 작업이 끝나기 전에 같은 요청을 반복하지 않도록 구성하는 편이 좋다. 네트워크 오류가 났을 때 무조건 다시 보내는 대신, 앞선 요청의 상태부터 확인하도록 설계할 이유도 여기 있다.
재리뷰가 언제나 새로운 피드백만 남기는 것도 아니다. 공식 안내에는 사용자가 해결 표시를 했거나 부정적인 반응을 남긴 의견이 다시 나올 수 있다고 적혀 있다. 자동화의 목표를 ‘댓글 수를 늘리는 것’으로 잡기보다, 최신 커밋에서 아직 유효한 문제를 사람이 쉽게 구분하게 하는 쪽으로 두는 편이 낫다.
리뷰 결과와 병합 승인은 같은 의미가 아니다
Copilot 리뷰의 개요에는 PR이 승인 가능한 상태인지에 대한 평가가 포함될 수 있다. 하지만 평가 문장이 있다는 사실만으로 저장소의 필수 승인 수가 채워지는 것은 아니다. 공식 문서는 Copilot approvals를 별도의 공개 프리뷰로 설명하고, 기본적으로 비활성화돼 있다고 안내한다.
승인을 허용하고 병합 요구사항에 포함하도록 구성하면 실제 승인 리뷰가 요건에 영향을 줄 수 있다. 저장소에서는 파일 경로로 승인 효력이 적용되는 범위를 제한하는 설정도 제공한다. 따라서 API 호출을 붙이는 작업을 하면서 편의상 승인 옵션까지 같이 켜는 것은 기능 추가 이상의 변경이다. 누가 어떤 코드 변경을 승인할 수 있는지에 대한 팀의 규칙을 함께 바꾸기 때문이다.
초기 도입에서는 검토를 요청하고 결과를 사람에게 전달하는 단계와 병합을 허용하는 단계를 분리하면 변경 효과를 관찰하기 쉽다. 충분히 검토한 뒤 문서 수정처럼 제한된 범위에 다른 정책을 적용할 수는 있지만, 모델의 평가 문장을 곧바로 배포 허가로 해석하는 흐름부터 만들 필요는 없다.
팀에 붙일 때는 한 PR의 전체 경로부터 확인한다
첫 연결에서 확인할 것은 호출 성공 응답 하나가 아니다. 요청 권한이 있는 계정인지, 검토가 어떤 커밋을 대상으로 시작됐는지, 선택한 수준이 결과에 남았는지, 새 커밋 이후의 상태를 어떻게 다루는지까지 한 PR의 흐름을 따라가야 한다. 외부 API가 열린다는 소식만 보고 고정된 엔드포인트나 파라미터 이름을 추측해 넣지는 말아야 한다.
여기서는 확인되지 않은 요청 본문을 복사 가능한 코드로 제시하지 않았다. API 지원 사실과 설정·비용은 공식 자료로 확인했지만, 실제 권한과 현재 스키마는 연결하는 계정과 문서를 기준으로 다시 맞춰야 한다. 오른쪽 자료에는 출시 공지, 사용법, 설정 화면, 개념 문서를 각각 연결해 두었다. 필요한 정보를 찾아 같은 키워드로 다시 검색하지 않아도 되도록 구분한 것이다.
결국 이번 변화로 팀이 결정할 수 있는 것은 리뷰를 시작할 시점과 적용할 분석 수준이다. 좋은 시작점은 이미 반복하는 검토 절차에서 한 단계를 골라 붙이고, 요청부터 결과 확인까지의 시간을 살피는 것이다. 그다음 사용량과 실제로 채택된 피드백을 기준으로 범위를 넓히면, 자동화 때문에 오히려 알림과 비용만 늘어나는 상황을 피하기 쉽다.