Copilot을 켰는데 PR은 왜 늦을까? 3구간 병목 진단 카드

읽는 시간 8분 · 팀 단위 PR 흐름을 점검하는 운영 카드

핵심 요약

• GitHub는 저장소 단위 Copilot 사용 지표에 ready→첫 검토, 첫→최종 검토, 최종 검토→병합의 median·p90 시간을 추가했습니다.
• median은 평소 흐름을, p90은 일부 PR이 만드는 긴 꼬리를 보여줍니다. 둘 중 하나만 보면 병목을 잘못 고르기 쉽습니다.
• 첫 구간이 길면 검토자 대기열, 가운데가 길면 요구사항·테스트 왕복, 마지막이 길면 승인·릴리스 절차를 먼저 살펴보는 편이 합리적입니다.
• 이 수치는 사람 작성자와 사람 검토자가 있는 조건부 PR을 대상으로 합니다. 개인 평가 도구가 아니라 팀 흐름을 개선하기 위한 집계 신호로 다뤄야 합니다.

평균 하나가 놓치는 세 구간

PR이 느리다는 말은 서로 다른 문제를 한데 묶습니다. 누군가 첫 검토를 시작하지 못한 것, 검토 의견을 주고받는 일이 길어진 것, 승인은 끝났지만 병합이 멈춘 것은 같은 해결책으로 고칠 수 없습니다.

GitHub의 변경 안내에 따르면, enterprise와 organization의 저장소 단위 보고서는 사람 작성자와 다른 사람의 검토가 있는 조건부 PR에 대해 다음 시간을 분리합니다.

1. ready for review → first review: 검토자가 처음 반응할 때까지의 대기
2. first review → final review: 첫 검토부터 마지막 검토까지의 왕복
3. final review → merge: 마지막 검토 뒤 병합까지의 승인·릴리스 대기

median과 p90을 함께 읽어야 하는 이유

median은 PR의 가운데 흐름이 얼마나 오래 걸렸는지 보여줍니다. p90은 느린 쪽 10%가 얼마나 길게 늘어지는지를 보여줍니다. median이 안정적인데 p90만 악화됐다면, 전체 규칙을 바꾸기보다 대형 PR·특정 소유자·긴급 변경처럼 긴 꼬리를 만든 표본을 먼저 분리해 보는 편이 좋습니다.

반대로 median과 p90이 함께 늘었다면, 특정 예외보다 기본 흐름에 공통된 마찰이 있을 수 있습니다. 다만 지표가 바뀌었다고 곧바로 도구 설정이나 인력 변화가 원인이라고 단정하지는 마세요. 변경 전후 기간과 다른 운영 이벤트를 같이 기록해야 합니다.

FLOWIT 3구간 병목 진단 카드

아래 카드는 숫자를 모으는 표가 아니라 다음 실험을 하나로 좁히는 기록입니다. 저장소별로 날짜, 조건부 PR 표본 수, 세 구간의 median·p90, 그리고 같은 기간의 변경 이벤트를 한 줄에 남겨보세요.

예를 들어 첫 구간의 p90만 길어졌다면, 모든 리뷰 규칙을 바꾸기보다 최근 긴 PR 몇 건을 확인해 보세요. 특정 시간대의 요청, 휴가 중인 코드 소유자, 하나의 큰 변경이 원인일 수 있습니다. 이때 비용·수용 결과와 시간 흐름은 서로 다른 질문입니다. 비용·수용 결과를 묶는 3원장은 별도의 판단 재료로 두는 편이 좋습니다.

병목별로 하나만 바꾸는 2주 실험

한 번에 검토자 규칙, Copilot 설정, 배포 절차를 모두 바꾸면 무엇이 영향을 줬는지 알기 어렵습니다. 이번 기간에는 병목 하나와 변경 하나만 선택하세요. 팀의 권한과 신뢰성도 함께 확인해야 합니다.

최종 검토 이후 병합이 길다고 해서 검토 자체가 끝난 것은 아닐 수 있습니다. AI 코멘트의 처리와 병합 안전성은 별도 기록으로 확인하는 편이 낫습니다. 병합 전 4상태 결정 기록을 함께 보면 이 구간의 인수 조건을 더 분명히 정할 수 있습니다.

이 카드가 틀린 결론으로 가는 네 가지 경우

• 빈 배열을 0분으로 읽는 경우: 조건을 만족해 병합된 PR이 없는 날의 빈 결과는 빠른 병합이 아닙니다.
• 초기 데이터를 과신하는 경우: 새 지표는 릴리스 전부터 과거 데이터를 채워 넣지 않습니다. 초반 기간은 표본이 얇을 수 있습니다.
• 단일 검토를 왕복 없음으로 과장하는 경우: 첫 검토에서 최종 검토가 된 PR은 가운데 시간이 0일 수 있습니다. 품질이 좋아졌다는 뜻으로 해석할 수는 없습니다.
• 관찰값을 인과로 바꾸는 경우: Copilot 설정, 리뷰 정책, 담당 인력이 동시에 바뀌었다면 하나의 변화가 시간을 줄였다고 단정하지 마세요.

저장소 전체의 AI 도입 흐름을 함께 보고 싶다면 코드 생성량만으로 판단하지 않는 저장소 지표도 참고할 수 있습니다. 다만 이 글의 카드는 PR 대기 시간의 위치를 찾는 용도로 좁혀 두는 것이 좋습니다.

시작 전 7문항 체크리스트

1. 사용 지표 정책과 필요한 organization 또는 enterprise 권한이 준비되어 있나요?
2. 대상 저장소와 관찰 기간을 한 문장으로 정했나요?
3. 조건부 PR 표본 수와 빈 결과 여부를 같이 남기나요?
4. 세 구간의 median과 p90을 같은 날짜 단위로 기록하나요?
5. 동시에 일어난 인력·릴리스·정책 변경을 기록하나요?
6. 개인 평가가 아닌 팀 운영 개선 목적과 접근 범위를 합의했나요?
7. 다음 2주에 바꿀 규칙 한 가지와 책임자, 중단 조건이 있나요?

자주 묻는 질문

Copilot code review가 있는 PR도 이 지표에 포함되나요?

사람이 작성하고 적어도 다른 사람이 검토한 조건부 PR이 대상입니다. GitHub의 안내에 따르면 Copilot code review와 다른 봇, 작성자 본인의 검토 시간은 측정에서 제외됩니다. 사람 검토가 함께 있으면 해당 PR은 포함될 수 있습니다.

첫 검토에서 최종 검토까지 0분이면 좋은 신호인가요?

단일 검토로 끝난 PR에서는 가운데 구간이 0일 수 있습니다. 그 값만으로 더 좋은 검토나 더 높은 품질을 뜻한다고 볼 수는 없습니다.

빈 결과는 병합이 빨랐다는 뜻인가요?

아닙니다. 그날 조건을 만족하는 병합 PR이 없었을 수 있습니다. 표본 수와 결과 배열을 함께 확인해야 합니다.

지표가 늘면 Copilot을 끄는 것이 먼저인가요?

아닙니다. 먼저 어느 구간이 늘었는지와 동시에 바뀐 운영 조건을 확인하세요. 한 저장소에서 하나의 규칙만 짧게 실험한 뒤 판단하는 편이 안전합니다.

누가 이 데이터를 볼 수 있어야 하나요?

GitHub가 요구하는 정책과 역할을 충족하는 범위에서, 팀 흐름을 개선할 책임이 있는 사람에게만 집계 결과를 제공하는 편이 좋습니다. 개인 평가 용도로 확대하지 않도록 목적과 보존 범위를 분명히 하세요.

참고 자료

• GitHub Changelog — Usage metrics API adds pull request review stages: 세 구간, human-only 조건, 빈 배열·no backfill 같은 해석 주의사항의 근거입니다.
• GitHub Docs — REST API endpoints for Copilot usage metrics: 정책 활성화, organization·enterprise 보고서와 접근 권한을 확인할 수 있습니다.