AI는 리뷰를 끝냈다. 사람의 시계는 아직 돌고 있다

AI는 리뷰를 끝냈는데, 보고서에는 첫 리뷰까지 30분을 기다렸다고 나온다. 둘 다 맞을 수 있다. GitHub가 새로 만든 리뷰 시간 지표는 사람을 기다리는 시계이기 때문이다.

리뷰를 부르는 쪽은 한결 편해졌다. GitHub는 10월 2일 REST·GraphQL API로 Copilot 리뷰를 요청하고, 요청마다 검토 강도를 고를 수 있다고 발표했다. 이제 스크립트가 리뷰어를 부른다. 그렇다고 성과표의 숫자까지 저절로 설명되는 것은 아니다.

가상 PR의 두 시간

가상의 PR 하나를 따라가 보자. 아래 시간은 설명용 합성 예제에서 가져왔다. 실제 팀의 실험도, Copilot 실행 기록도 아니다. 사람이 작성한 변경 사항이 오전 10시에 검토 준비 상태가 된다. 10시 5분에 Copilot이 리뷰를 올리고, 10시 10분에는 작성자가 자기 리뷰를 남긴다. 동료의 리뷰는 10시 30분에 딱 한 번 올라온다. 11시 50분에 다른 봇이 리뷰를 추가하고, 정오에 변경 사항을 병합한다.

GitHub의 정의를 적용하면 세 구간은 30분, 0분, 90분이다. 검토 준비부터 첫 사람 리뷰까지 30분. 첫 사람 리뷰부터 마지막 사람 리뷰까지 0분. 마지막 사람 리뷰부터 병합까지 90분. 동료의 리뷰가 한 번뿐이어서 처음과 마지막이 같은 시각이다. 가운데 0분은 동료가 코드를 순식간에 읽었다는 뜻이 아니다.

Copilot이 먼저 말했다고 첫 구간이 5분이 되지는 않는다. 봇과 작성자의 자기 리뷰는 이 시계의 경계를 정하지 않는다. 마지막 봇 리뷰가 11시 50분에 올라와도 병합 전 구간은 10분으로 줄지 않는다. 보고서가 나눈 것은 사람의 리뷰를 거쳐 병합까지 흐른 두 시간이다. 누군가 두 시간 내내 코드를 읽었다는 기록은 아니다.

사람 집계에 AI가 들어가는 이유

더 중요한 반전은 따로 있다. 이 PR은 AI와 사람이 함께 봤지만 여전히 사람 리뷰 집계에 들어간다. ‘사람’은 시간을 재는 리뷰의 주체를 가리킨다. AI를 쓰지 않은 작업이라는 인증표가 아니다. 이 집단을 그대로 ‘AI 미사용 대조군’으로 부르면 계산을 시작하기도 전에 비교가 틀어진다.

가상 예제에서 봇 리뷰 두 개를 지워 보자. 사람의 시각을 그대로 두면 30·0·90이라는 숫자도 그대로다. 여기서 ‘AI는 아무 도움도 안 됐다’는 결론은 나오지 않는다. 동료가 오기 전에 유용한 지적 덕분에 버그를 고쳤을 수도, 쓸모없는 지적을 읽느라 시간을 버렸을 수도 있다. 시각만으로는 두 이야기를 가를 수 없다. 어떤 지적이 어떤 수정으로 이어졌고, 그 수정이 실제로 도움이 됐는지를 봐야 한다.

빈칸을 0으로 만들면

빈칸은 또 다른 이야기다. 그날 병합된 PR 중 집계 조건을 만족하는 것이 없으면 리뷰 시간 배열은 []로 비어 있다. 봇만 리뷰한 PR에는 잴 만한 사람 리뷰 구간이 없다. 여기에 0을 채우면 ‘측정할 대상이 없음’이 ‘즉시 완료’로 둔갑한다. 그래프는 매끈해지고 설명은 틀린다.

실제 지표는 저장소별 API 보고서에서 중앙값과 90백분위값으로 제공되며, 병합한 날에 귀속된다. 위 예제는 PR 하나의 구간 계산이지 API 응답이나 백분위 계산의 재현이 아니다. 9월 25일 출시된 지표는 과거 데이터를 소급 채우지 않고, 9월 21일 전에 검토 준비 상태가 된 PR도 제외한다. 초기 보고서의 기억은 저장소의 역사보다 짧다.

비용표의 날짜 하나

비용에는 날짜 하나를 더 붙여야 한다. 기본 검토 강도가 Balanced로 바뀐 날은 10월 2일 공지보다 앞선 9월 28일이다. Lite를 직접 선택한 설정은 유지됐다. GitHub에 따르면 Balanced는 AI 크레딧을 더 쓰며 Actions 사용 시간도 조금 늘 수 있다. 이 날짜를 걸친 지출 증가는 요청 횟수뿐 아니라 리뷰 강도가 달라진 결과일 수도 있다.

정오에 물을 질문은 ‘AI가 몇 분 만에 끝냈나’에서 한 걸음 더 나아간다. ‘첫 쓸모 있는 지적부터 병합 결정까지 무엇이 달라졌나.’ API는 리뷰의 시작을 쉽게 만든다. 일이 끝났다고 말하려면, 무엇을 알아냈고 어떤 결정을 내렸는지도 문장에 들어가야 한다.

확인 범위: 2026년 10월 3일 GitHub 공식 정의를 다시 확인했다. 예제 시간은 모두 합성이며 실제 저장소의 비용·결함 발견률을 실측하지 않았다.