Copilot 사용량 지표 읽기: 도구·스킬 사용 증가와 측정 확대를 구분하는 법

IDE 밖의 사용이 보고서 안으로 들어온다

한 팀이 VS Code, Copilot CLI, OpenCode를 함께 쓴다고 하자. 관리자는 IDE 보고서에서 보이는 활동만으로 교육 대상을 고르고 있었다. 터미널에서 꾸준히 일하던 사람은 덜 사용하는 사람처럼 보일 수 있다. 모델을 제공한 서버는 요청을 받았지만, 편집기에서 어떤 행동을 했는지 알려 주는 기록은 없기 때문이다.

GitHub는 2026년 10월 23일 Copilot usage metrics API에 totals_by_client를 추가했다. Copilot을 모델 제공자로 쓰는 도구의 성공한 모델 요청, 세션, 토큰과 모델별 내역을 서버 측에서 집계한다. OpenCode 같은 IDE 밖 도구도 대상이다. 이 수치는 각 도구가 다른 제공자에 보낸 요청까지 모은 전체 사용량이 아니다. 10월 23일 공식 변경

하루 전에는 사내에서 만든 스킬·커스텀 에이전트·MCP 서버 등의 이름을 보고서에 표시하는 변경도 발표됐다. 익명 묶음 안에 있던 활동을 구체적인 구성 항목과 연결할 수 있게 된 것이다. 10월 22일 이름 표시 변경

필자의 해석으로, 두 변화는 팀의 질문을 “AI를 몇 명이나 쓰나”에서 “어떤 경로와 어떤 업무 지침을 지원해야 하나”로 넓힌다. 다만 새 차원이 생긴 순간에는 과거와 현재의 숫자를 같은 눈금으로 읽기 어렵다. 이 글은 10월 27일 확인한 공식 문서와 직접 만든 가상 사례로 그 비교 방법을 설명한다. 실제 조직 보고서, API 호출, Copilot 실행과 생산성 실험은 수행하지 않았다.

한 번의 작업이 여러 종류의 숫자를 만든다

개발자가 “오류를 고쳐 줘”라고 한 번 요청해도 에이전트는 코드를 읽고 수정하고 테스트 결과를 해석하며 모델을 여러 번 부를 수 있다. totals_by_client.request_count는 이 모델 호출을 세므로 프롬프트 횟수와 일대일로 대응하지 않는다. 클라이언트 이름도 요청의 integration ID에 따른 최선의 분류이지 검증된 도구 신원은 아니다. 클라이언트 집계의 범위와 주의사항

아래는 구분을 위한 표다. 이벤트 정의는 공식 필드 문서에서, 마지막 열의 판단은 이 글의 분석에서 가져왔다.

보고서에서 본 값	무엇을 세나	곧바로 말할 수 없는 것
클라이언트 request_count	성공한 모델 요청	사람의 질문 수, 완료 업무 수
스킬 interaction_count	스킬 호출	그 스킬을 쓴 사람 수, 결과의 정확도
MCP interaction_count	성공·실패한 서버 연결 및 재연결 시도	연결 뒤 도구를 호출한 횟수
플러그인 interaction_count	플러그인에 속한 스킬 호출	스킬 합계에 더할 별도의 활동

커스터마이징 이벤트 정의

예를 들어 가상 팀의 MCP 연결 시도가 20회에서 100회로 늘었다. 그 차이는 새 사용자의 유입일 수도 있지만 연결이 끊겨 재시도한 결과일 수도 있다. 이 지표만으로 “도구를 다섯 배 활용했다”고 보고하면 다음 조치가 틀어진다. 교육을 확대하기 전에 연결 실패가 늘었는지 확인해야 한다. 반대로 연결을 유지한 채 도구를 많이 호출해도 이 연결 횟수는 거의 늘지 않을 수 있다.

합산에도 함정이 있다. 같은 범위·기간에서 스킬 호출이 80회이고 그중 플러그인에 속한 호출이 30회라면, 80과 30을 더한 110회는 중복 계산이다. 이 가정의 스킬 전체는 80회이며 나머지 50회가 플러그인 밖 호출이다. 공식 정의상 플러그인 이벤트는 스킬 이벤트에 이미 포함된다. 배열마다 숫자가 있다는 이유로 모두 더하면 안 된다.

사용은 그대로인데 보고서가 50% 커지는 경우

다음은 수집률 변화만 떼어 설명하기 위한 가상 사례다. GitHub의 실제 누락률이나 이번 변경의 효과 추정치가 아니다. 두 기간의 실제 활동은 각각 1,000건으로 고정하고, 동일한 이벤트 중 보고서에 잡히는 비율만 다르게 놓는다.

가정	변경 전	변경 후
실제 활동	1,000건	1,000건
수집되는 비율	60%	90%
보고서에 잡힌 활동	600건	900건

관측 증가율은 (900 − 600) ÷ 600 = 50%지만 실제 활동 증가는 0이다. 수집 비율을 모르는 실제 보고서에서는 이 계산을 거꾸로 사용해 진짜 사용량을 복원할 수 없다. 관측값이 변했다는 사실과 행동이 변했다는 설명을 구분하는 반례다.

새 이름 표시에도 비슷한 단절이 생긴다. 공식 발표는 이름 지원 배포 후 처리되는 보고일부터 설정 이름이 보이고, 이전 날짜는 other 또는 custom으로 남는다고 설명한다. 과거 other의 감소와 새 스킬 이름의 증가가 곧 사용자의 이동은 아니다. 클라이언트 기록이 막히거나 구버전이면 덜 잡힐 수도 있다. 이름 표시의 이력·수집 조건

이때 필요한 기록은 “업데이트했다” 한 줄보다 구체적이다. 어떤 날짜에 어느 클라이언트를 바꿨는지, 같은 보고 범위를 유지했는지, 이름이 처음 나타난 날이 언제인지 적는다. 이 경계가 포함된 전후 차이는 일단 측정 방식이 바뀐 비교로 분류한다. 안정된 조건의 다음 기간을 확보한 뒤 행동 변화를 평가하는 편이 낫다.

사내 스킬을 개선하려면 이름과 분모를 함께 본다

새 이름은 실무적인 이점이 있다. 예컨대 release-note가 많이 보이면 해당 지침의 관리자를 정하고 실패 사례를 모을 근거가 생긴다. db-migration이 적게 보여도 곧바로 폐기할 이유는 없다. 원래 분기마다 쓰는 작업일 수 있고, 필요한 사람에게 배포되지 않았을 수도 있다. 호출 수는 지원 우선순위를 조사할 출발점이다.

이름 수집 조건은 별도로 맞춰야 한다. 공식 안내에서 prompt mode·앱·ACP 경로는 Copilot CLI 1.0.97 이상, SDK 경로는 SDK 1.0.21 이상을 요구한다. SDK에 포함된 CLI를 교체했다면 그 CLI 조건도 확인한다. IDE의 내장 채팅 텔레메트리는 이름을 보고하지 않는다. 이는 해당 이름 수집의 조건이며 모든 Copilot 지표에 공통인 최소 버전은 아니다. 커스터마이징 수집 조건

현재 상위 목록 밖 활동은 other에 모일 수 있다. 따라서 특정 이름이 없다는 사실을 사용 0으로 바꾸지 않는다. distinct_*_use_count도 서로 다른 항목 식별자의 수이며 사용자 수가 아니다. “스킬 12종이 기록됐다”와 “12명이 사용했다”는 다른 주장이다. 이름에는 내부 업무 명칭이 들어갈 수 있으므로 외부에 공유할 보고서는 표시명을 먼저 검토한다.

팀의 채택률을 계산하려면 분모를 직접 정해야 한다. 예를 들어 “이번 달 릴리스 노트 작성 담당 10명 중 해당 스킬을 실제 사용했다고 확인한 사람”을 평가 대상으로 삼을 수 있다. 이때도 상위 목록의 이벤트 수를 10명으로 나누어 채택률이라고 부를 수는 없다. 사용자별 근거와 수집 공백이 필요하다. 과도한 개인별 순위표보다, 업무군에 필요한 도구가 도달했는지 확인하는 용도가 이 질문에 더 적합하다.

보고서를 가져와도 먼저 기간과 범위를 맞춘다

권한 있는 담당자는 usage metrics 정책과 조회 권한을 확인한 뒤 API를 사용할 수 있다. API는 보고서 다운로드 링크와 보고 날짜 또는 기간을 반환한다. 28일 집계 보고서는 처리된 최신 날짜까지의 기간을 다루며, 링크에는 유효기간이 있다. 아래는 인증 호출 예제가 아니라 보고서를 인수할 때 함께 기록할 항목이다. REST API 보고서 계약

조사 질문: 어떤 도구의 지원 또는 교육을 먼저 개선할 것인가?
범위: enterprise / organization, 포함할 업무군
보고 시작일·종료일 / 내려받은 시각:
지표 단위: 모델 요청 / 스킬 호출 / 연결 시도 / 고유 사용자
수집 조건: 클라이언트·버전 / 정책 / 누락 또는 변경 날짜
비교 불가 구간: 새 필드·이름 표시 전환 / 처리 중인 최근 날짜
다음 행동: 담당자·확인할 실제 사례·다음 평가일

회사 전체 수치를 만들려고 조직 보고서를 모두 더하는 것도 주의해야 한다. 공식 개념 문서는 조직별 사용량이 소속 관계에 따라 귀속되므로 같은 사람이 여러 조직에 나타날 수 있고, enterprise 수준에서는 한 번 집계된다고 설명한다. 조직 합계와 enterprise 합계의 차이를 바로 누락 오류라고 판단하지 않는다. 조직 귀속 규칙

최근 날짜에는 처리 지연도 있다. 확인한 개념 문서는 두 번의 온전한 UTC 일자 이내 제공, 보고서 대조 문서는 보통 세 번의 온전한 UTC 일자 안에 확정된다고 서로 다르게 설명한다. 이 글은 이를 하나의 확정 SLA로 합치지 않는다. 분석 실무에서는 보고 종료일과 추출 시각을 저장하고, 최근 구간은 잠정으로 두며 세 번째 UTC 일자가 지난 뒤 다시 조회하는 보수적인 기준을 제안한다. 재조회 후에도 차이가 남으면 수집 조건을 조사한다. Data freshness, Delayed telemetry

사용자 수는 날짜를 더하는 방식으로도 부풀 수 있다. 같은 사람이 매일 사용했다면 일별 활성 사용자 수의 합은 기간의 고유 사용자 수와 다르다. 대시보드의 28일 코호트와 API의 일별 코호트는 모집단도 다르므로 기간 이름을 맞추는 것만으로 일치하지 않는다. 코호트와 시간창 차이

평균 토큰 수는 요청 수로 가중한다

모델 트래픽을 비교할 때는 평균의 평균도 조심해야 한다. 아래는 같은 기간·같은 토큰 집계 정의를 사용하며 중복 없는 두 묶음이라고 가정한 계산이다. 실제 모델 가격이나 제품 측정치가 아니다.

가상 묶음	요청 수	입력·출력 토큰 합계	요청당 평균
A	100	1,000,000	10,000
B	900	1,800,000	2,000

평균 둘을 단순히 평균 내면 6,000이다. 전체 요청당 토큰은 (1,000,000 + 1,800,000) ÷ (100 + 900) = 2,800이다. B가 훨씬 많은 요청을 처리했기 때문이다. 입력·출력 합계를 요청 수로 나누는 공식 CLI 필드의 평균 정의와 같은 산술이다. 토큰 평균 정의

그렇다고 B가 더 좋은 도구라는 결론은 나오지 않는다. 짧은 질문과 큰 저장소 수정은 필요한 문맥이 다르다. 낮은 토큰 사용이 일을 덜 했다는 뜻일 수도 있다. 작업 종류를 맞춘 뒤 문맥 크기·반복 요청을 조사할 근거로 쓰고, 청구액은 해당 과금 자료로 따로 확인해야 한다.

업계 비교보다 먼저 우리 팀의 다음 행동을 정한다

10월 22일 발표된 impact dashboard의 업계 비교는 참여한 동종·유사 규모 기업과의 위치를 제공한다. 기본 비활성인 선택 참여이며, 참여 집단이 작으면 범위가 넓어지거나 순위가 보이지 않을 수 있다. 이 비교는 usage metrics API나 NDJSON에 포함되지 않는다. 업계 비교 발표

여기서 leverage는 에이전트 사용 집단과 그렇지 않은 집단의 사용자당 월 PR 병합률을 비교한다. 이는 관측 집단 간 비교다. 원래 작은 PR을 많이 만드는 팀이 에이전트를 먼저 채택했다면 도구 효과와 업무 차이가 섞인다. “동료 기업보다 높다”는 순위 역시 우리 팀의 결함률이나 절약한 시간을 대신하지 않는다. GitHub도 잠재 ROI 수치를 정확한 재무 결과가 아닌 방향을 보는 추정으로 다루도록 안내한다. impact 지표와 추정의 의미

새 지표로 당장 바꿀 수 있는 판단은 다음처럼 좁히는 편이 실용적이다. 이 표는 실행 결과가 아니라 팀 운영을 위한 제안이다.

관측한 신호	먼저 할 일	효과를 확인할 별도 근거
IDE 밖 요청이 꾸준히 보임	해당 도구의 지원 담당·설정 안내 정비	같은 작업군의 문의 해결 시간과 실패 유형
특정 사내 스킬 호출이 많음	지침 관리자와 대표 입력·출력 사례 확보	수정·반려 원인, 작업 완료 후 재작업
MCP 연결만 급증함	연결 실패·재연결 조건 조사	정상 연결 유지와 실제 필요한 도구 결과
새 이름이 거의 안 보임	배포·버전·기록 범위부터 확인	의도한 사용자에게 도달했는지, 대체 업무 경로

먼저 한 업무군과 한 변경을 고른다. 예컨대 릴리스 노트 스킬의 입력 지침만 고치고, 동일한 종류의 릴리스에서 누락 항목과 사람의 수정 시간을 비교할 수 있다. 요청이 줄어도 결과 품질이 같거나 나아졌다면 개선일 수 있다. 요청이 늘어도 더 어려운 일을 끝냈다면 낭비로 단정할 수 없다. 이 연결을 확인해야 사용량이 지원 예산과 업무 개선의 근거가 된다.

모델·도구·사람 시간을 함께 평가하려면 에이전트의 완료 비용 비교, 연결과 실제 도구 실행의 역할을 구분하려면 MCP와 API의 차이를 이어 읽을 수 있다. 보고서 접수 항목을 다시 쓰려면 글 위 저장 기능을 이용하고, 소프트웨어 주제 모음과 RSS에서 후속 분석을 확인할 수 있다.