배경 및 맥락
기업의 AI 도입은 이제 '몇 명이 라이선스를 갖고 있는가'보다 '얼마나 실제 워크플로에 스며들었는가'가 더 중요해졌다. 특히 code review 영역은 자동 실행 정책만 켜도 표면상 사용량이 높아 보일 수 있어, 진짜 채택과 단순 노출을 분리하기 어려웠다.
이 때문에 많은 조직이 Copilot, agent, code review rollout의 성공을 과대평가하거나 반대로 과소평가했다. GitHub의 이번 metrics 업데이트는 이 문제를 직접 겨냥한다. AI 기능이 돌았다는 사실과 사용자가 그 결과를 적극적으로 활용했다는 사실을 다르게 측정하겠다는 선언이다.
핵심 내용
GitHub changelog에 따르면 새 user-level report에는 used_copilot_code_review_active와 used_copilot_code_review_passive가 추가된다. 전자는 사용자가 Copilot을 reviewer로 지정하거나 재리뷰를 요청하거나 제안을 적용하는 등 의도적 상호작용이 있을 때 true가 된다. 후자는 repository-level policy로 자동 실행은 되었지만 사용자가 직접 개입하지 않았을 때 true가 된다.
같은 날 두 이벤트가 모두 발생하면 active가 우선한다. 이 설계는 단순 방문 수가 아니라 실제 행동을 더 높은 신호로 간주하는 구조다.
경쟁 구도 / 비교
많은 AI 도입 대시보드는 아직도 활성 사용자 수를 단일 숫자로만 보여준다. 하지만 AI code review는 자동 실행 정책, 권한 구조, 팀 문화에 따라 숫자의 해석이 크게 달라진다. GitHub가 active/passive를 분리한 것은 AI adoption analytics가 이제 더 정교한 product analytics 단계로 들어섰다는 뜻이다.
이는 단순히 Copilot용 지표 개선이 아니라, 다른 agent 제품도 결국 '실행됨'과 '신뢰받음'을 분리 측정해야 한다는 압력을 만든다.
의미
이 업데이트의 핵심은 AI 도입 관리가 seat management에서 behavior analytics로 이동하고 있다는 점이다. 조직은 이제 자동화 기능을 켰다는 사실만으로 성공을 선언하기 어려워진다. 사용자가 실제로 리뷰를 요청하고 제안을 채택하는지까지 봐야 한다.
실무적으로는 플랫폼 팀과 엔지니어링 매니저가 rollout 판단 기준을 더 정밀하게 잡을 수 있다. passive 비중이 높다면 정책은 배포됐지만 신뢰가 형성되지 않은 것이고, active 비중이 높다면 리뷰 루프에 실질적으로 흡수되고 있다는 뜻이다. 이 차이는 라이선스 최적화, 교육, 정책 설계 모두에 바로 영향을 준다.