Copilot API가 사용자 단계를 매긴다, AI 도입률의 새 지표

GitHub가 2026년 5월 29일 Changelog에서 Copilot usage metrics API에 AI adoption phase를 추가했습니다. 이제 API는 engaged user를 단순히 활성 사용자로 세지 않고, 최근 28일 동안 어떤 Copilot surface를 썼는지에 따라 code first, agent first, multi-agent 같은 단계로 분류합니다. Copilot을 IDE 자동완성 도구로만 보는 조직과 cloud agent, code review, CLI까지 쓰는 조직을 같은 숫자로 묶지 않겠다는 업데이트입니다.

새 필드는 두 갈래입니다. user-level report에는 ai_adoption_phase가 추가됩니다. enterprise와 organization level report에는 totals_by_ai_adoption_phase 배열이 들어갑니다. GitHub는 이 배열이 phase별 engagement와 activity metrics를 보여준다고 설명했습니다. 포함 항목은 engaged user 수, user-initiated interaction average, code generation과 acceptance activity averages입니다. lines added/deleted averages, pull request created/merged/reviewed averages, median time-to-merge average도 phase별로 묶입니다.

분류 기준은 rolling 28-day window입니다. GitHub Changelog는 각 engaged user가 최근 28일 동안 해당 Copilot surface를 최소 2일 이상 사용했는지를 본다고 적었습니다. 하루 실험으로 agent mode를 눌러본 사용자를 곧바로 agent-first로 세지 않기 위한 기준입니다. 반대로 28일 안에서 두 번 이상 같은 surface를 사용했다면, 교육 프로그램이나 도입률 보고서에서는 실험이 아니라 반복 사용으로 집계될 수 있습니다.

GitHub가 phase 이름에 code first와 agent first를 쓴 점은 제품 방향을 드러냅니다. 기존 Copilot adoption 보고서에서 관리자가 가장 먼저 보던 숫자는 활성 사용자 수, completion acceptance, IDE별 사용량이었습니다. 이번 필드는 "몇 명이 쓰는가"보다 "어디까지 쓰는가"를 묻습니다. code completion에서 시작한 사용자가 code review, cloud agent, CLI, Copilot app까지 이동했는지 보는 지표입니다. AI 코딩 도구의 사용면이 IDE 한 칸에서 GitHub workflow 전체로 넓어진 결과입니다.

GitHub Docs의 Copilot usage metrics REST API 문서는 이 API를 켜려면 enterprise의 Copilot usage metrics policy가 Enabled everywhere로 설정돼야 한다고 설명합니다. endpoint는 1일 report와 28일 report를 나눠 제공하고, enterprise owner, billing manager, fine-grained 권한을 가진 사용자에게 접근을 허용합니다. 보고서는 직접 payload를 돌려주는 대신 제한 시간 signed URL을 제공하는 구조입니다. 숫자는 제품 UI 대시보드보다 API와 데이터 파이프라인으로 흘러갈 가능성이 큽니다.

이번 업데이트가 관리자에게 유용한 이유는 교육 예산을 더 구체적으로 배분할 수 있기 때문입니다. 예를 들어 전체 활성 사용자는 높지만 Phase 2와 Phase 3이 낮다면, 조직은 cloud agent나 Copilot code review 교육을 별도로 설계할 수 있습니다. 특정 팀이 Phase 3으로 빠르게 이동했지만 pull request median time-to-merge가 좋아지지 않는다면, agent 사용량 자체보다 review 정책과 테스트 병목을 점검해야 합니다. adoption phase는 "AI를 많이 쓴다"는 홍보 문구보다 rollout 운영표에 가깝습니다.

다만 이 숫자는 쉽게 압박 도구가 될 수 있습니다. 개인별 ai_adoption_phase가 user-level report에 들어간다는 사실은 개발자에게 민감합니다. 관리자가 phase를 목표값으로 삼으면, 실제 문제 해결보다 agent surface를 눌러 phase를 올리는 행동이 생길 수 있습니다. Copilot CLI를 한 번 더 쓰거나 code review agent를 형식적으로 호출하는 행동이 도입률로 보이면, 숫자는 제품 활용이 아니라 평가 대응으로 바뀝니다. 지표 설계에서 가장 피해야 할 부분입니다.

GitHub는 ai_adoption_phase 값에 version field를 넣고 시작값을 v1로 둔다고 밝혔습니다. 이 장치는 작지만 중요합니다. Copilot product surface가 늘어나면 phase 정의도 바뀔 수 있습니다. 예를 들어 새 Copilot app이 Phase 3 조건에 들어가듯, 앞으로 Spaces, custom agent, repository automation 같은 면이 추가되면 같은 28일 사용 기록이라도 다른 version의 분류 logic을 거칠 수 있습니다. version field는 2026년 5월의 지표와 2026년 말의 지표를 같은 그래프에 억지로 겹치지 말라는 경고입니다.

enterprise와 organization report에서 phase별 metrics가 sum이 아니라 per-user average라는 점도 읽어야 합니다. phase별 총 PR 수나 총 line changes를 비교하면 규모가 큰 cohort가 항상 커 보입니다. GitHub는 phase 안에서 사용자당 평균 interaction, code generation, acceptance, lines added/deleted, PR activity, median time-to-merge average를 제공한다고 적었습니다. 이 설계는 Phase 3 사용자군이 적어도 사용자당 작업 변화가 있는지 보려는 목적에 가깝습니다.

개발팀은 이 지표를 seat optimization과 섞어 읽을 가능성이 큽니다. Phase 0 사용자는 license 회수 후보로 보일 수 있고, Phase 1 사용자는 training 대상, Phase 2와 Phase 3 사용자는 champion 후보로 분류될 수 있습니다. 이런 운영 자체가 나쁘지는 않습니다. 문제는 phase가 개인 능력이나 생산성의 직접 지표가 아니라는 점입니다. 어떤 저장소는 agent workflow보다 짧은 completion과 review discipline이 더 중요하고, 어떤 팀은 security policy 때문에 CLI나 cloud agent 사용을 제한할 수 있습니다.

Copilot usage metrics 문서가 제공하는 다른 field와 함께 봐야 하는 이유도 여기에 있습니다. GitHub reference는 lines of code changed with AI, agent contribution, model usage by chat mode, monthly active users, Copilot code review users, CLI usage 같은 field를 설명합니다. adoption phase 하나만 보면 "agent를 많이 쓰는 팀"이 좋은 팀처럼 보일 수 있습니다. 하지만 PR merge time, review suggestion 적용률, generated code acceptance, deleted lines를 같이 보면 agent 사용이 실제 workflow에 어떤 비용과 이득을 남겼는지 더 잘 보입니다.

이 API는 GitHub가 Copilot을 단일 기능이 아니라 제품군으로 관리하려는 시도이기도 합니다. Code completion, IDE agent mode, cloud agent, code review, CLI, Copilot app은 서로 다른 작업면입니다. 예전에는 이 차이를 제품 블로그 문장으로 설명했다면, 이제 enterprise report field로 나눕니다. 관리자 대시보드가 이 구조를 따라가면, AI 도입 회의의 질문도 "Copilot seat가 몇 개인가"에서 "팀이 어떤 agent surface까지 책임 있게 쓰고 있는가"로 바뀝니다.

한국 개발 조직이 바로 확인할 항목은 네 가지입니다. 첫째, Copilot usage metrics policy가 켜져 있는지 확인합니다. 둘째, API로 받은 user-level report를 개인 평가에 쓰지 않는다는 내부 원칙을 명시합니다. 셋째, phase별 평균 PR 지표를 팀 규모와 업무 유형으로 보정합니다. 넷째, Phase 2와 Phase 3을 목표값으로 강제하기보다 agent workflow가 실제로 필요한 저장소부터 pilot을 설계합니다. 지표는 adoption을 돕는 도구이지, 모든 개발자를 multi-agent 사용자로 밀어 넣는 목적지가 아닙니다.

이번 Changelog는 작은 API field 추가지만, AI 코딩 도구가 관리자용 운영 시스템으로 들어가는 장면입니다. GitHub가 engaged user를 4단계로 나누고, 28일 반복 사용과 per-user average를 함께 제공한다는 사실은 Copilot 경쟁의 기준이 모델 성능만이 아니라는 점을 보여줍니다. 앞으로 조직이 비교할 것은 "어떤 모델이 코드를 잘 쓰는가"만이 아닙니다. 어떤 제품이 AI 사용을 설명 가능한 지표로 만들고, 그 지표가 개발자를 압박하지 않도록 제어할 수 있는지도 도입 기준이 됩니다.