PR 리뷰 지연을 세 구간으로 읽는 Copilot 사용량 지표: 사람 리뷰만 집계하는 분모

PR이 늦게 병합된다는 사실만으로는 팀이 어디서 기다렸는지 알기 어렵습니다. 처음 보는 사람이 늦었는지, 첫 리뷰 뒤에 논의가 길었는지, 최종 리뷰가 끝난 뒤 병합이 늦었는지는 다른 운영 문제입니다. GitHub가 2026년 9월 25일 발표한 저장소 단위 Copilot 사용량 보고서의 pull_request_review_times는 이 시간을 세 구간의 중앙값과 90백분위 값으로 나눕니다. 그러나 표를 읽기 전에 어떤 PR을 세고 어느 날짜에 넣었는지부터 확인해야 합니다.

이 글은 공식 발표와 REST API 설명을 기반으로 보고서를 읽는 진단 절차를 만듭니다. 실제 조직 데이터나 고객별 시간 수치를 조회한 실측 보고가 아닙니다. Copilot 사용량 보고서 안에 들어간 지표라는 사실도 Copilot이 리뷰 지연을 줄였다는 인과 증거가 아닙니다.

세 구간은 서로 다른 대기 질문이다

엔터프라이즈와 조직의 저장소별 repos-1-day 보고서 각 행에 새 배열이 제공됩니다. authored_by와 reviewed_by는 이번 릴리스에서 각각 사람 작성자와 사람 리뷰어를 나타냅니다. 각 항목의 total_merged는 해당 저장소에서 그날 병합된 조건에 맞는 PR 수입니다. 시간 단위는 분이고, 날짜는 리뷰를 시작한 날이 아니라 병합일에 귀속됩니다.

  1. ready_to_first_review: 리뷰 준비 상태에서 첫 사람 리뷰까지. 길다면 첫 응답을 기다리는 구간인지 조사합니다.
  2. first_to_final_review: 첫 사람 리뷰에서 최종 사람 리뷰까지. 길다면 반복 검토와 수정의 흐름을 살펴봅니다.
  3. final_review_to_merge: 최종 사람 리뷰에서 병합까지. 길다면 승인 이후의 대기 원인을 별도로 살펴봅니다.

각 구간에는 median_minutes_…와 p90_minutes_…가 있습니다. 중앙값만 보면 소수의 긴 대기가 가려질 수 있으므로 90백분위도 같이 읽습니다. 다만 각 구간의 집계 통계를 더해 ‘전형적인 PR 한 건의 총 병합 시간’이라고 부르면 안 됩니다. 서로 다른 PR의 순위와 구간별 분포를 하나의 실제 PR 타임라인으로 복원할 수 없기 때문입니다. 발표는 이 지표의 고객별 실측 수치나 개선 퍼센트를 제공하지 않습니다.

사람 리뷰 지연을 준비부터 첫 리뷰, 첫 리뷰부터 최종 리뷰, 최종 리뷰부터 병합의 세 구간으로 나눈 도식

세 구간 각각 중앙값과 90백분위 분 단위 통계를 제공한다. 실제 고객 시간 값은 그리지 않았다. 출처: github.blog/changelog/2026-09-25-usage-metrics-api-adds-pull-request-review-stages.

가장 중요한 함정: 두 total_merged의 분모가 다르다

신규 배열은 사람이 열고 작성자 이외의 사람이 적어도 한 번 리뷰한 PR을 대상으로 합니다. Copilot code review, 다른 봇, PR 작성자의 리뷰는 시간 측정에서 제외됩니다. 사람과 Copilot이 모두 리뷰했다면 사람 리뷰가 있는 PR은 조건을 충족할 수 있지만, Copilot 리뷰 자체를 첫·최종 사람 리뷰 시각으로 사용하지는 않습니다. 기존 pull_requests.total_merged는 리뷰 없이 병합한 PR도 셉니다. 따라서 새 배열의 total_merged가 기존 값보다 보통 작다는 설명은 누락이나 오류의 증거가 아닙니다.

예를 들어 어떤 날 기존 병합 총수가 더 크더라도, 차이를 곧장 ‘리뷰 프로세스 위반 건수’로 이름 붙일 수 없습니다. 사람 리뷰 유무와 이번 출시 이전의 준비일 제외 조건, 병합일 귀속을 먼저 분리해야 합니다. 발표는 작성자·리뷰어 조합별 배열 구조를 설명하지만, 이 차이에 대한 고객별 원인 분해나 특정 팀의 실제 수치를 제시하지 않습니다. 서로 다른 분모를 그대로 나눠 리뷰율 또는 Copilot 효과로 보고하지 마세요.

사람이 열고 타인이 리뷰한 적격 PR과 리뷰 없는 PR도 포함하는 기존 병합 총수의 서로 다른 분모 비교

신규 배열과 기존 병합 총수의 분모를 구별한다. 봇·Copilot·작성자 리뷰는 신규 시간 측정에서 제외된다. 출처: github.blog/changelog/2026-09-25-usage-metrics-api-adds-pull-request-review-stages.

0과 빈 배열, 과거 누락은 각각 다른 의미다

그날 조건에 맞는 병합 PR이 없으면 pull_request_review_times는 []입니다. 이는 시간이 0분이라는 측정값이 아니라 집계할 적격 항목이 없다는 상태입니다. 반대로 사람 리뷰가 한 번뿐인 PR에서는 첫 리뷰와 최종 리뷰가 같아 first_to_final_review 구간이 0입니다. 이 0을 ‘상호작용이 빨랐다’는 성과로 읽기보다, 리뷰 횟수 조건과 함께 표시해야 합니다.

또한 2026년 9월 21일 이전에 리뷰 준비 상태가 된 PR은 새 섹션에서 빠집니다. 같은 PR이 기존 pull_requests.total_merged에는 들어갈 수 있습니다. 과거 데이터를 소급 채우지 않으므로 출시 직후의 빈약한 시계열을 이전 기간과 연결해 개선 추세처럼 그리지 마세요. 보고서의 날짜가 병합일이라는 규칙도 잊지 말아야 합니다. 오래전에 준비된 PR이 오늘 병합됐다고 해서 새 지표에 반드시 포함되는 것은 아닙니다.

적격 병합이 없는 날의 빈 배열과 사람 리뷰 한 번일 때 첫 리뷰부터 최종 리뷰 구간이 0인 상태의 차이

빈 배열은 적격 병합 없음, 단일 사람 리뷰의 첫→최종 구간 0은 측정 정의다. 초기 기록의 소급 채우기는 없다. 출처: github.blog/changelog/2026-09-25-usage-metrics-api-adds-pull-request-review-stages.

진단표: 숫자보다 먼저 확인할 질문

아래 진단표는 GitHub 발표의 집계 정의를 운영 질문으로 옮긴 것입니다. 해당 API가 조직의 리뷰 운영에 자동으로 처방을 내리거나 이 표를 공식 평가 기준으로 보증한다는 뜻은 아닙니다.

보고서에서 본 신호 먼저 확인할 것 다음 조사 피해야 할 결론
준비→첫 리뷰 구간의 p90이 중앙값보다 큼 해당일 적격 병합과 사람 리뷰가 있는지 늦은 첫 응답 사례의 배정·대기 경로 전체 PR의 90%가 같은 시간에 리뷰됐다는 단정
첫→최종 리뷰 구간이 0 사람 리뷰가 한 번인 사례인지 반복 리뷰가 없었던 이유와 수정 기록 모든 검토가 즉시 끝났다는 성과 주장
최종 리뷰→병합 구간이 길어 보임 병합일과 사람 최종 리뷰의 정의 승인 뒤 검사·병합 정책 등 별도 기록 Copilot이 병합을 늦췄다는 인과 주장
배열이 비었거나 기존 병합 수보다 작음 적격 병합, 사람 리뷰, 준비일 경계 동일 저장소·동일 날짜의 분모를 나란히 기록 []를 0분으로, 두 분모의 차이를 오류로 처리

이 표를 실제 팀에 적용하려면 먼저 같은 보고서 날짜와 저장소를 고르고, 새 배열의 적격 건수와 기존 병합 건수를 별도 열로 둡니다. 그런 다음 각 구간의 중앙값·p90을 분 단위로 기록하고, 빈 배열과 단일 리뷰에 따른 0을 숫자 성과와 구별해 주석을 붙입니다. 병목 가설을 세운 뒤에는 개별 PR의 실제 이벤트 기록으로 확인해야 합니다. 구간 통계는 조사 순서를 좁히는 지표이지 원인을 자동 판정하는 로그가 아닙니다.

아래 진단표는 GitHub가 발표한 집계 정의를 운영 질문으로 재구성한 편집상 도구입니다. 실제 조직의 PR이나 시간 분포를 조회하거나 Copilot 도입 효과를 측정한 결과는 아닙니다.

분모 확인, 세 구간 중앙값과 p90 비교, 빈 배열과 단일 리뷰 0 분리, 원본 PR 기록 검증의 네 단계

공식 집계 정의를 운영 질문으로 바꾼 자체 진단 순서다. 개별 PR 원인이나 Copilot 인과 효과를 증명하지 않는다. 출처: github.blog/changelog/2026-09-25-usage-metrics-api-adds-pull-request-review-stages.

어디서 받으며 무엇을 아직 모르는가

REST 문서는 엔터프라이즈와 조직의 일자별 저장소 보고서 endpoint가 다운로드 링크를 반환한다고 설명합니다. 즉 API 응답의 링크 자체가 위 배열의 최종 행은 아닙니다. 사용 권한은 발표가 열거한 기업 소유자·청구 관리자, 조직 소유자 또는 해당 사용자 지정 역할의 View Copilot Metrics 권한과 Copilot 사용량 지표 정책 활성화에 달려 있습니다. 실제 호출에서는 해당 REST endpoint의 권한·토큰 요구사항도 확인해야 합니다. 이 글은 접근 가능한 기업 계정에서 다운로드나 권한 검증을 실행하지 않았습니다.

운영 대시보드라면 [], 단일 리뷰의 0, 적격 병합 건수, 전체 병합 건수, 준비일 제외 기준을 각각 명시하는 것이 출발점입니다. 그다음 세 구간 중 조사할 곳을 선택하고 원본 PR 활동으로 가설을 확인하세요. 이번 발표는 분해 방법을 제공하지만 특정 조직의 개선 효과나 Copilot의 인과 영향을 제공하지 않습니다.

출처

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기