AI 도구를 팀에 배포한 뒤 가장 먼저 받는 질문은 대개 ‘얼마나 쓰고 있나’다. 라이선스를 몇 개 배정했는지, 활성 사용자가 몇 명인지, 대화나 제안을 몇 번 썼는지부터 확인하게 된다. 하지만 그 숫자만으로는 업무 방식이 달라졌는지 알기 어렵다. 코드 완성은 자주 쓰지만 코드 리뷰나 에이전트 편집은 거의 쓰지 않는 팀과, 반대의 팀은 같은 ‘활성 사용자 수’를 보여도 필요한 지원이 다르기 때문이다.
GitHub는 2026년 9월 17일 Copilot Impact Dashboard와 기업·조직용 28일 집계 보고서에 기능별 참여 지표를 추가했다. 포함된 각 기능을 28일 동안 적어도 이틀 사용한 활성 사용자의 수를 보여 준다. 코드 완성, 에이전트 편집, 수동 및 자동 Copilot 코드 리뷰, 클라우드 에이전트, CLI, Copilot 앱이 기능별로 나뉜다. AI를 도입했다는 사실보다 어떤 사용 방식이 반복되는지를 볼 수 있게 된 변화다.
‘활성’과 ‘정착’은 같은 말이 아니다
이번 지표는 특정 기능을 한 번 열어 본 사람을 세는 방식이 아니다. 28일 안에 이틀 이상 해당 기능에 참여한 활성 사용자 수를 집계한다. 짧은 체험과 반복 사용을 어느 정도 구분하려는 기준이다. 다만 이 수치가 생산성이나 코드 품질을 직접 증명하지는 않는다. 이틀 사용은 습관의 강한 증거가 아니며, 기능마다 사용 빈도가 자연스럽게 다르다.
또한 한 사용자는 여러 기능에 중복으로 포함될 수 있다. 기능별 숫자를 더해 전체 사용자 수로 읽으면 안 된다. 자동으로 PR 검토에 배정된 경우는 수동으로 검토를 요청하거나 제안을 적용한 경우와도 구분된다. 자동 검토가 많다는 사실만으로 개발자가 검토 결과를 신뢰하거나 반영했다고 판단하기는 어렵다.
이 제한을 인정하면 지표의 쓰임이 더 선명해진다. 기능별 참여도는 성과표가 아니라 다음 질문을 고르는 진단 신호에 가깝다. 예를 들어 코드 완성은 널리 쓰이는데 에이전트 편집이 낮다면, 모델 성능 문제가 아니라 저장소 지침, 실행 권한, 작업 범위가 불명확한 탓일 수 있다. 반대로 코드 리뷰 기능의 참여가 낮다면 PR 흐름에 어떻게 끼워 넣을지, 사람이 최종 검토할 시간을 어떻게 확보할지부터 확인해야 한다.
28일 창을 업무 흐름과 함께 읽기
GitHub는 기존 AI 도입 단계 보고도 보완했다. 새 users_in_phase_28d 필드는 각 보고일 기준으로 28일 동안의 전체 단계별 인구를 보여 준다. 기존 total_engaged_users는 그날 실제로 활동한 사용자만 뜻한다. 두 값은 질문이 다르다. 전자는 최근 한 달에 어느 단계의 사용자가 얼마나 있었는지, 후자는 특정 날짜에 그 단계에서 얼마나 활동했는지를 읽는 데 맞다.
이 차이를 놓치면 휴가, 배포 일정, 조직 행사처럼 일별 사용량을 흔드는 요인을 AI 도입 실패로 오해할 수 있다. 월말마다 기능별 28일 지표를 같은 기준으로 비교하고, 바로 옆에 팀의 작업 맥락을 짧게 남기는 편이 낫다. 예를 들어 ‘이번 달에는 신규 서비스의 코드 리뷰 규칙을 바꿨다’거나 ‘에이전트 편집은 읽기 전용 저장소에서만 시험했다’는 기록이 있어야 숫자의 이동을 해석할 수 있다.
9월 11일 GitHub가 별도로 추가한 VS Code Agents 창 지표도 같은 맥락에서 볼 만하다. 집계 보고서에는 해당 창의 일별 고유 활성 사용자, 세션 수, 사용자 메시지 수가 들어간다. 다만 이 값은 VS Code의 전용 Agents 창만 다루며, 편집기 창의 Agent Mode나 일반 사용량과는 합쳐지지 않는다. 측정 대상이 무엇인지 명시하지 않은 비교는 피하는 편이 안전하다.
작은 AX 실험을 숫자에 묶는 방법
이런 기능별 지표는 대규모 생산성 평가보다 작은 변화의 확인에 잘 맞는다. 먼저 한 팀과 한 흐름을 고른다. 예를 들어 ‘신규 API의 테스트 코드 초안’처럼 리뷰 가능한 작업을 정하고, 4주 동안 사용하는 기능과 사람의 검토 단계를 고정한다. 그 기간에는 도구를 여러 개 바꾸지 않는 편이 해석하기 쉽다.
- 기준을 하나 정한다. 기능별 28일 참여도 외에 PR 리드타임, 리뷰에서 되돌린 변경 수, 테스트 실패처럼 업무 결과를 하나만 함께 둔다. 생성된 코드 줄 수를 품질 지표로 삼지는 않는다.
- 낮은 참여도에 바로 교육을 처방하지 않는다. 참여가 낮은 기능의 사용자를 두세 명만 골라, 권한·저장소 지침·비용·작업 적합성 중 어디에서 멈췄는지 확인한다. 기능을 몰라서인지, 써 봤지만 가치가 없었는지 구분해야 한다.
- 다음 실험의 범위를 줄인다. 한 기능의 참여가 늘어도 결과 지표가 나빠졌다면 사용을 확대하지 말고 작업 유형을 더 좁힌다. 반대로 참여와 결과가 함께 개선되면 그때 다른 팀으로 옮긴다.
대시보드가 대신 답해 주지 않는 것
GitHub의 기능별 참여 지표는 기업 및 조직의 28일 집계 보고서에만 제공되고 사용자별 보고서에는 추가되지 않는다. 권한도 제한된다. 엔터프라이즈 소유자와 청구 관리자, 조직 소유자, 또는 Copilot Metrics 보기 권한을 받은 역할이 대상이며 사용량 지표 정책이 켜져 있어야 한다. 계산할 수 없는 경우 copilot_feature_engagement 객체가 없거나 null일 수 있다. 0과 누락을 같은 의미로 처리하지 않아야 한다.
무엇보다 대시보드는 왜 어떤 기능이 쓰였는지 설명하지 않는다. 개발자가 코드 완성을 자주 사용했다는 사실과 더 빠르게 배포했다는 주장은 별개다. 에이전트가 만든 변경이 리뷰 부담을 줄였는지, 보안 검토나 테스트 비용을 늘렸는지는 저장소와 팀의 흐름에서 따로 확인해야 한다. 지표를 개인 감시나 성과 순위에 쓰면 실험의 신뢰도도 떨어질 수 있다.
이번 업데이트에서 눈여겨볼 부분은 AI 활용을 하나의 사용률로 묶지 않았다는 점이다. AX는 도구를 배포하는 순간이 아니라 특정 기능이 어떤 작업에서 반복되고, 그 반복이 사람의 검토와 결과에 어떤 영향을 주는지 확인하는 과정에서 쌓인다. 28일 기능별 참여도는 그 과정을 시작할 수 있는 관측값이다. 답으로 받아들이기보다, 다음 실험을 더 작고 분명하게 만드는 질문으로 쓰는 편이 좋다.