GitHub이 9월 25일 Copilot 지표 API에 PR 리뷰 단계별 시간을 붙였다. 사람이 열고 다른 사람이 리뷰한 PR만 세며 Copilot 리뷰는 첫 리뷰가 아니다. 중앙값을 읽기 전에 이 배열이 빠뜨린 병합 PR 수부터 저장소별로 센다.
Copilot 코드 리뷰를 켠 조직은 분기 말에 같은 질문을 받는다. 리뷰가 빨라졌느냐. GitHub 9월 23일 changelog 이후 이 질문을 받을 조직이 늘었다. Pro·Pro+·Max 플랜에만 있던 자동 리뷰 설정이 Business·Enterprise 사용자에게도 열려, 켜 두면 PR을 만들거나 draft에서 빼는 순간 Copilot 리뷰가 붙는다.
이틀 뒤 GitHub 9월 25일 changelog가 Copilot 사용 지표 API에 PR 리뷰 단계별 시간을 추가했다. 두 공지를 붙이면 "Copilot이 첫 리뷰를 맡아 대기가 줄었다"는 슬라이드가 금방 나온다.
새 배열로는 그 슬라이드를 만들 수 없다. 이유는 필드 정의에 있다.
첫 리뷰 시각은 다른 사람이 처음 리뷰를 제출한 시각이다
새 필드는 저장소별 일일 보고서(repos-1-day)의 각 행에 붙는 pull_request_review_times 배열이다. 단계는 셋이다. 리뷰 준비 완료에서 첫 리뷰까지, 첫 리뷰에서 마지막 리뷰까지, 마지막 리뷰에서 병합까지. 단계마다 중앙값과 90번째 백분위(p90)를 분 단위로 주고, 값은 병합일에 귀속된다.
GitHub Docs 사용 지표 참조 문서는 제외 조건을 한 문장으로 적었다. Copilot 코드 리뷰, 다른 봇, PR 작성자 본인의 리뷰는 무시한다. 봇이 연 PR은 통째로 빠지고, 배열의 authored_by·reviewed_by에는 현재 사람 값만 있다. median_minutes_ready_to_first_review는 Copilot이 몇 분 만에 코멘트를 달았는지와 상관없이, 동료가 처음 리뷰를 낼 때까지 PR이 기다린 시간이다.
Copilot 쪽 숫자는 따로 있다. 보고서의 median_minutes_to_merge_copilot_reviewed와 median_minutes_to_merge_copilot_authored는 PR 생성부터 병합까지를 한 덩어리로 잰다. Copilot 리뷰가 세 단계 중 어디서 시간을 줄였는지는 이 필드로 가를 수 없다.
이름이 비슷한 7월 필드와도 섞지 않는다. GitHub 7월 7일 changelog가 도입 단계별 집계에 넣은 avg_pull_requests_minutes_to_review는 이름과 달리 중앙값이고, 시작점이 리뷰 준비 완료가 아니라 PR 생성이다. draft로 오래 두는 팀일수록 두 값이 벌어진다.
| 필드 | 시작 | 끝 | 대상 |
|---|---|---|---|
avg_pull_requests_minutes_to_review (7월) | PR 생성 | 첫 리뷰 | 병합된 PR |
median_minutes_ready_to_first_review (9월) | 리뷰 준비 완료 | 다른 사람의 첫 리뷰 | 사람이 열고 다른 사람이 리뷰한 병합 PR |
median_minutes_to_merge_copilot_reviewed | PR 생성 | 병합 | Copilot 코드 리뷰를 받은 병합 PR |
배열 밖 병합이 늘면 중앙값은 더 좁은 PR 묶음을 말한다
문서는 9월 21일 전에 리뷰 준비가 끝난 PR을 배열에서 빼면서도 pull_requests.total_merged에는 넣는다고 밝혔다. 배열의 total_merged와 이 값의 차이가 배열이 보지 못한 병합이다. 여기에는 세 부류가 섞인다. Copilot 클라우드 에이전트나 다른 봇이 연 PR, 9월 21일 전에 준비된 PR, 다른 사람의 리뷰 없이 병합된 PR이다.
세 번째는 설정 하나로 커진다. GitHub 9월 1일 changelog에 따르면 관리자가 켜면 Copilot의 승인이 필수 승인 수에 산입되고, 저장소 관리자는 Copilot이 승인할 파일 경로를 제한할 수 있다. 기본값은 꺼짐이다. 병합 규칙 쪽 변화는 Copilot의 PR 승인이 병합 조건에 산입되면, 필수 승인 1명 규칙은 사람 0명 규칙이 된다에서 다뤘다. 지표 쪽에서는 Copilot 승인만으로 병합된 PR이 사람 리뷰가 없어 배열에서 빠진다.
문서·테스트 경로에만 Copilot 승인을 허용했다면 배열에 남는 PR은 그 밖의 경로를 건드린 PR로 기운다. 중앙값이 늘었다면 리뷰어가 느려져서가 아니라 표본이 바뀌어서일 수 있다.
병합일 귀속도 같은 방향으로 작동한다. 가장 오래 기다리는 PR은 병합되는 날까지 p90에도 나타나지 않는다. 첫 몇 주는 9월 21일 전에 준비된 PR이 병합되면서 차이가 저절로 줄어드니, 추세 비교는 그 뒤부터 한다.
가져갈 것
- 저장소별로
pull_request_review_times[].total_merged÷pull_requests.total_merged비율을 주 단위로 뽑고 있는가? - 9월 1일 공개된 Copilot 승인 산입을 켠 저장소와 허용 경로 목록을 지표 보고서 각주에 적었는가?
- 리뷰 속도 비교표에서 7월 필드
avg_pull_requests_minutes_to_review와 9월 필드median_minutes_ready_to_first_review를 한 열에 섞지 않았는가? - 9월 21일 이전 분기와 단계별 시간을 나란히 놓은 슬라이드를 지웠는가?
- Copilot 코드 리뷰 효과는
median_minutes_to_merge_copilot_reviewed로 말하고, 생성부터 병합까지 한 덩어리라고 각주에 적었는가?
안 되는 경우
- 이 배열은 조직·엔터프라이즈 범위 저장소 보고서에만 붙고, 소유자·결제 관리자나 "View Copilot Metrics" 권한자만 본다. 개인 플랜 팀은 해당하지 않는다.
- 한두 명이 서로 리뷰 없이 병합하는 저장소는 배열이 거의 비어 중앙값이 PR 몇 건에 좌우된다.
- 소스는
authored_by·reviewed_by에 Copilot 값을 언제 넣을지, 넣은 뒤 지난 날짜의 행을 다시 계산할지 밝히지 않았다. - 7월 changelog는
avg_pull_requests_minutes_to_review가 Copilot 리뷰를 첫 리뷰로 세는지 적지 않았다. 두 필드의 차이를 전부 시작점 탓으로 돌릴 수는 없다.
이번 주에 바꿀 것은 리뷰 속도 보고서의 첫 칸 하나다. 중앙값 앞에 "이 숫자가 센 병합 / 전체 병합"을 둔다. AX 성과 지표를 새로 짜는 중이라면 조녁컴퍼니와 이 제외 조건부터 따져 볼 수 있다. 사업영역 →