Copilot CLI의 MCP 서버 연결 횟수가 리포트에 나옵니다. GitHub 이 2026년 9월 17일 올린 에이전틱 CLI 커스터마이징 지표 공지에 따르면 스킬, 커스텀 에이전트, MCP 서버, 슬래시 명령어, 플러그인 다섯 갈래의 활동 필드가 Copilot 사용량 지표 리포트에 들어갔습니다. 다만 이 리포트는 엔터프라이즈와 조직 단위로만 나옵니다. 개인 계정용 엔드포인트는 Copilot 사용량 지표 REST API 문서의 목록에 아예 없습니다. 조회 조건으로는 Copilot usage metrics 정책이 켜져 있어야 하고, 리포트를 받아 보는 쪽은 엔터프라이즈 소유자와 결제 관리자, 조직 소유자, 그리고 View Copilot Metrics 권한을 주는 커스텀 조직·엔터프라이즈 역할을 받은 사람입니다.

「REST API endpoints for Copilot usage metrics (GitHub Docs)」 문서 화면

출처: 「REST API endpoints for Copilot usage metrics (GitHub Docs)」, docs.github.com. 2026-09-18 캡처.

「Agentic CLI customizations now in the usage metrics API (GitHub Changelog)」 문서 화면

출처: 「Agentic CLI customizations now in the usage metrics API (GitHub Changelog)」, github.blog. 2026-09-18 캡처.

아래 내용은 2026년 9월 18일 기준입니다. 공지가 올라온 지 하루 된 변경이라, 리포트 스키마를 파서에 박아 두기 전에 실제 응답과 맞춰 보는 쪽이 확실합니다.

Copilot 사용량 지표 API에 새로 생긴 필드 10개

새로 붙은 필드는 두 묶음입니다. 한 묶음은 totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd, totals_by_plugin 다섯 개고, 각각 활동이 가장 많이 기록된 항목을 최대 다섯 개까지 배열로 담습니다. 배열의 각 항목에는 interaction_count 가 함께 들어갑니다.

숫자의 의미는 갈래마다 다릅니다. 스킬과 슬래시 명령어, 플러그인 스킬은 호출 횟수를 세고, 커스텀 에이전트는 에이전트가 시작된 횟수를 세며, MCP 서버는 연결을 시도한 횟수를 셉니다. 이름은 같은 interaction_count 인데 세는 사건이 서로 다르니, 다섯 배열의 값을 나란히 놓고 크기를 비교하는 것은 의미가 없습니다.

다른 묶음은 distinct_skill_use_count, distinct_custom_agent_use_count, distinct_mcp_use_count, distinct_slash_cmd_use_count, distinct_plugin_use_count 다섯 개입니다. 이쪽은 횟수가 아니라 서로 다른 항목이 몇 종류 쓰였는지를 셉니다. 상위 다섯 개 배열에 못 들어간 항목도 여기에는 포함되기 때문에, 배열 길이만 보다가 “우리 조직은 스킬을 다섯 개 쓰는군요” 하고 넘어가면 실제 숫자를 놓치게 됩니다.

집계 리포트에서 distinct_* 값은 조직이나 엔터프라이즈 전체에서 한 항목을 한 번만 셉니다. 같은 MCP 서버를 서른 명이 썼어도 1 입니다. 사용자별 리포트에서는 그 사용자가 쓴 항목을 한 번씩 세니까, 조직 전체 값은 사용자별 값을 그냥 더한 수보다 작거나 같게 나오는 것이 정상입니다.

필드가 들어가는 리포트도 종류가 정해져 있습니다. 엔터프라이즈와 조직의 사용자별·집계 1일 리포트, 사용자별 28일 리포트, 그리고 집계 28일 리포트의 day_totals 항목입니다. 값이 빈 배열이거나 0 이면 해당 활동이 없었다는 뜻이고, null 이거나 필드 자체가 빠져 있으면 커스터마이징 데이터를 받지 못한 상태입니다. 이 둘을 같은 것으로 처리하면 집계 대시보드에서 “사용량 0” 과 “데이터 없음” 이 한 칸에 섞입니다.

MCP 서버 활동은 어떻게 집계되나요?

MCP 쪽 숫자는 오해하기 딱 좋게 생겼습니다. totals_by_mcp 의 interaction_count 는 Copilot CLI 가 서버에 연결하거나 재연결을 시도할 때만 올라갑니다. 성공한 시도와 실패한 시도가 모두 한 번으로 잡힙니다.

연결된 서버에서 도구를 여러 번 호출하는 것은 이 숫자를 전혀 올리지 않습니다.

이게 왜 중요한지는 MCP 의 연결 구조를 보면 분명해집니다. MCP 명세의 Lifecycle 문서는 클라이언트가 initialize 요청으로 프로토콜 버전과 기능을 협상하고, 서버 응답 뒤에 notifications/initialized 를 보내면서 연결이 열린다고 적고 있습니다. 그 뒤로는 같은 연결 위에서 도구 호출이 계속 오갑니다. 세션 하나를 켜 두고 하루 종일 도구를 이백 번 부른 사람과, 터미널을 자주 껐다 켜서 연결만 스무 번 맺은 사람을 비교하면 후자의 숫자가 열 배로 보입니다.

그래서 이 필드는 “MCP 서버를 얼마나 썼나” 가 아니라 “MCP 서버에 얼마나 자주 붙었나” 로 읽어야 맞습니다. 도입 효과를 보고하는 자리에서 이 값을 사용량처럼 인용하면 숫자가 부풀려집니다. 연결 실패까지 같은 칸에 더해지니, 설정이 깨져서 계속 재연결을 시도하는 서버가 가장 인기 있는 서버로 올라오는 일도 구조적으로 가능합니다. 지표로서는 거칠고, 실패와 성공을 나눠 주지 않는 점은 분명한 약점입니다.

플러그인과 스킬 수치를 더하면 안 되는 이유

플러그인 지표는 플러그인에 딸린 스킬 호출만 셉니다. 플러그인 상호작용은 하나도 빠짐없이 스킬 합계에도 같이 들어가고, 플러그인에서 오지 않은 스킬 호출은 스킬 합계에만 남습니다. 플러그인 값이 스킬 값의 부분집합이라는 뜻이라, 두 값을 더하면 같은 사건을 두 번 세게 됩니다. 공지에도 두 숫자를 합산하지 말라고 못을 박아 두었습니다.

이름 표시 규칙에도 걸리는 구석이 있습니다. GitHub 이 제공하는 항목은 이름이 그대로 보이지만, 고객이 직접 정의한 항목의 이름은 나오지 않습니다. 스킬·커스텀 에이전트·MCP 서버·플러그인은 other 로 묶이고, 슬래시 명령어는 Copilot CLI 텔레메트리가 이미 쓰던 표기를 따라 custom 으로 묶입니다.

사내에서 만든 스킬 열 개가 전부 other 한 줄로 합쳐진다는 이야기예요.

개인정보 보호 목적은 납득이 가지만, 관리자가 정작 알고 싶은 것은 “우리가 만든 배포 스킬이 쓰이고 있나” 쪽입니다. 그 질문에는 이 리포트가 답을 주지 못하고, distinct_* 값으로 “종류가 늘었다” 정도만 짐작하는 데서 멈춥니다. 자체 자동화의 개별 성과를 따지려면 결국 CLI 쪽에 별도 로깅을 붙여야 합니다.

리포트 엔드포인트 주소와 데이터 보관 기간

엔드포인트는 리포트 종류마다 하나씩 나뉘어 있습니다. 엔터프라이즈 쪽 주소는 아래와 같습니다.

GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest
GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/users-28-day/latest
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/user-teams-1-day?day=YYYY-MM-DD

조직 쪽은 앞부분이 /orgs/{org} 로 바뀌고 첫 줄이 organization-1-day, 둘째 줄이 organization-28-day/latest 가 됩니다. 나머지 네 개는 이름이 같습니다.

주소 목록에서 바로 읽히는 제약이 두 가지입니다. 28일 리포트에는 latest 만 있고 날짜 파라미터가 없어서 지난달 특정 시점의 28일 집계를 다시 뽑는 경로가 없습니다. 저장소 리포트와 사용자·팀 리포트는 1일짜리만 있고 28일짜리가 없습니다. 분기 보고용으로 과거 구간을 되짚어야 한다면 매일 1일 리포트를 받아 쌓아 두는 수밖에 없습니다.

호출은 Accept: application/vnd.github+json 과 X-GitHub-Api-Version: 2026-03-10 헤더를 붙여서 보냅니다. 응답에 담기는 것은 지표 본문이 아니라 download_links 배열이고, 실제 데이터는 그 링크가 가리키는 NDJSON 파일 안에 있습니다. 문서에는 이 링크가 만료 시간이 있는 서명 URL 이라고 적혀 있으니, 링크를 그대로 저장해 두고 나중에 쓰는 구조로 짜면 안 됩니다.

날짜 필드는 리포트 주기에 따라 갈라집니다. 1일짜리 리포트의 예시 응답에는 report_day 하나가 들어 있고, enterprise-28-day·users-28-day·organization-28-day 같은 28일짜리는 report_start_day 와 report_end_day 두 개로 구간의 양끝을 알려 줍니다. 두 주기를 한 파서로 받으면서 report_day 만 읽게 짜 두면 28일 쪽에서 날짜가 통째로 비어 버리죠.

상태 코드는 어느 엔드포인트든 200, 403, 404, 500 이 공통입니다. 내용 없이 헤더만 돌아오는 204 는 일부에만 붙어 있는데, 문서에 204 가 적힌 곳은 엔터프라이즈의 repos-1-day, 그리고 조직 쪽 organization-1-day·repos-1-day·user-teams-1-day·users-1-day 입니다. 28일 리포트 세 갈래에는 204 가 없고, 엔터프라이즈의 enterprise-1-day·users-1-day·user-teams-1-day 에도 적혀 있지 않습니다. 엔터프라이즈냐 조직이냐로 줄이 갈린다고 외워 두면 엔터프라이즈 저장소 리포트에서 바로 어긋납니다.

데이터가 언제부터 있는지도 엔드포인트마다 안내가 다릅니다. 2025년 10월 10일부터 리포트가 제공되고 과거 데이터는 현재 시점 기준 1년까지 열린다는 문장은, 열두 개 엔드포인트 가운데 enterprise-1-day 와 엔터프라이즈 users-1-day 두 곳의 설명에만 나옵니다. 조직 쪽 여섯 개를 포함한 나머지 설명에는 같은 기간 안내가 없습니다.

두 곳에만 붙은 문장이라 조직 리포트의 과거 조회 한계는 문서만 읽어서는 확정되지 않습니다.

usage metrics 리포트 조회 권한과 필요한 스코프

권한은 엔터프라이즈와 조직이 서로 다릅니다. 엔터프라이즈 리포트는 엔터프라이즈 소유자, 결제 관리자, 그리고 세분화된 View Enterprise Copilot Metrics 권한을 받은 사용자가 받습니다. OAuth 앱 토큰과 classic 개인 액세스 토큰은 manage_billing:copilot 이나 read:enterprise 스코프가 있어야 하고, 세분화된 토큰은 Enterprise Copilot metrics 엔터프라이즈 권한을 읽기로 갖고 있어야 합니다.

여기서 한 번 걸리는 지점이 있습니다. 엔터프라이즈 엔드포인트가 받아 주는 세분화된 토큰은 GitHub App 사용자 액세스 토큰과 GitHub App 설치 액세스 토큰 두 가지뿐입니다. 조직 엔드포인트 쪽에는 세분화된 개인 액세스 토큰이 목록에 함께 적혀 있어서, 조직에서 잘 돌던 스크립트를 엔터프라이즈 주소로 바꿔 부르면 토큰 종류 때문에 막힙니다.

조직 리포트는 조직 소유자와 View Organization Copilot Metrics 권한을 받은 사용자가 조회합니다. classic 토큰은 read:org 스코프면 되고, 세분화된 토큰은 Organization Copilot metrics 조직 권한을 읽기로 가지면 됩니다.

토큰을 아무리 잘 만들어도 정책이 꺼져 있으면 아무것도 안 나옵니다. API 문서는 엔터프라이즈에서 Copilot usage metrics 정책이 모든 곳에 사용 설정된 상태여야 이 엔드포인트가 열린다고 적고 있습니다. 조직 관리자가 자기 조직 설정만 뒤지다가 시간을 쓰는 자리가 여기인데, 정책 스위치는 조직이 아니라 엔터프라이즈 쪽에 있습니다.

Copilot impact dashboard 에 추가된 28일 피처 참여 데이터

같은 날 올라온 임팩트 대시보드 변경 공지는 화면과 리포트를 함께 건드렸습니다. 대시보드에는 28일 구간 동안 각 기능을 최소 이틀 이상 쓴 활성 사용자 수가 표시되고, 같은 값이 copilot_feature_engagement 객체로 엔터프라이즈·조직 28일 집계 리포트에 들어갑니다.

「Copilot impact dashboard now shows feature engagement (GitHub Changelog)」 문서 화면

출처: 「Copilot impact dashboard now shows feature engagement (GitHub Changelog)」, github.blog. 2026-09-18 캡처.

그 안의 totals_by_feature 는 코드 완성, 에이전트 편집, 자동 배정된 Copilot 코드 리뷰, 사용자가 직접 요청한 Copilot 코드 리뷰, Copilot 클라우드 에이전트, Copilot CLI, Copilot 앱 일곱 갈래로 숫자를 나눕니다. 코드 리뷰를 둘로 쪼갠 기준이 분명한데, 사용자가 리뷰를 직접 요청했거나 리뷰 제안을 반영했으면 능동 쪽으로, Copilot 이 알아서 리뷰어로 배정되기만 했으면 수동 쪽으로 잡힙니다.

기능별 숫자를 다 더해도 사람 수가 되지 않는 구조네요.

한 사람이 여러 기능에 중복해서 잡히기 때문입니다. 사용자 단위 리포트에는 이 값이 들어가지 않고, 계산이 불가능한 구간에서는 copilot_feature_engagement 자체가 없거나 null 로 옵니다.

AI 도입 단계 지표도 같이 손봤습니다. 기존 total_engaged_users 는 그날 활동한 사용자만 세는데, 새로 붙은 users_in_phase_28d 는 그 날짜 기준 28일 롤링 인구 전체를 단계별로 분류해 담습니다. 값이 빠져 있으면 그 단계 인구를 측정하지 못한 것이고, 0 이면 측정은 했는데 해당 인원이 없었던 것입니다. 두 필드는 집계 값이라 개별 사용자를 식별하지는 않습니다.

숫자를 언제 믿을 수 있느냐도 문서에 적혀 있습니다. Copilot 지표 데이터 속성 문서에 따르면 활동 리포트는 30분마다 자동 갱신되고, last_activity_at 값에 새 텔레메트리가 반영되기까지는 최대 24시간이 걸립니다. 그마저도 IDE 에서 텔레메트리를 켜 둔 사용자에 한해 도는 시계예요. last_activity_at 데이터의 보관 기간은 90일로 못이 박혀 있어 바꿀 수 없고, 90일 동안 새 활동이 없으면 그 사용자 값이 nil 로 내려앉습니다. 오늘 아침 회의 직전에 어제 자 숫자를 뽑아 보는 용도로는 맞지 않는 주기죠.

같은 문서는 한계도 같이 적어 두었습니다. 활동 리포트가 담는 범위부터가 IDE·GitHub·GitHub CLI·GitHub Mobile 에서 정식 출시(GA)된 기능의 사용이고, 아직 GA 가 아닌 기능은 리포트에서 빠질 수 있으며 현재 완전히 기록되지 않는 예로 Copilot Spaces 와 Copilot Spark 가 적혀 있습니다. VS Code 를 벗어난 JetBrains·Xcode 같은 서드파티 IDE 에서는 텔레메트리가 일관되게 들어오지 않을 가능성도 함께 적혀 있어요. 공개 미리보기라 바뀔 수 있다는 안내는 문서 전체가 아니라 last_activity_at 항목 머리에 달려 있습니다. JetBrains 를 주력으로 쓰는 팀이라면 이 대시보드의 채택률을 그대로 성과로 올리기 전에 IDE 구성부터 맞춰 두는 편이 안전합니다.

Claude Code 애널리틱스 API와 어떻게 다른가요?

에이전트 도구 사용량을 조직 단위로 재는 곳이 GitHub 만은 아닙니다. Claude Code 애널리틱스 문서는 조직의 사용자별 참여·사용량·비용 리포트를 API 로 내려받는 경로를 적어 두었는데, 이건 Enterprise 플랜에서만 열리는 길입니다. 키는 Primary Owner 가 read:analytics 스코프로 발급하고, Teams 플랜에는 이 API 자체가 제공되지 않는다고 못을 박아 두었어요. 별개로 콘솔 대시보드는 UsageView 권한이 있는 Developer, Billing, Admin, Owner, Primary Owner 역할에게 열립니다.

세는 대상이 다른 점이 흥미롭습니다. 콘솔 대시보드는 사용자가 수락한 코드 줄 수, Edit·Write·NotebookEdit 도구 사용이 수락된 비율, 일별 활성 사용자와 세션 수, 일별 비용을 보여 줍니다. PR 단위 기여도는 여기에 없어요. 문서가 GitHub 연동 기여도 지표는 API 고객에게 지금 제공되지 않으며 콘솔 대시보드는 사용량과 지출만 보여 준다고 따로 표시해 두었거든요. 기여도 쪽은 Claude for Teams·Enterprise 대시보드에 붙고, 그 귀속 계산에는 조건이 꽤 촘촘합니다. PR 병합일 기준 21일 전부터 2일 뒤까지의 세션만 후보로 보고, 개발자가 20% 넘게 다시 쓴 코드는 귀속에서 빼며, lock 파일과 dist/·build/ 같은 빌드 디렉터리, 1,000자를 넘는 줄은 분석에서 제외합니다. 라벨도 모든 병합 PR 에 붙지는 않고, Claude Code 가 거든 줄이 실제로 들어간 병합 PR 에만 GitHub 에서 claude-code-assisted 가 달립니다.

한쪽은 “무엇을 몇 종류나 썼는가” 를 세고, 다른 쪽은 “코드와 비용이 얼마나 남았는가” 를 셉니다. 경영진 보고에 바로 쓰기 좋은 모양은 뒤쪽이고, 그 대신 코드 줄 수라는 지표 자체가 생산성 대리 지표로는 예전부터 말이 많던 값이라는 점은 그대로 남습니다. 문서도 콘솔의 비용 수치가 분석용 추정치이며 실제 청구액은 결제 페이지를 봐야 한다고 적어 두었습니다.

GitHub 쪽 새 필드의 값어치는 다른 데 있다고 봅니다. 라인 수로는 안 보이던 것, 그러니까 팀이 자체 자동화를 실제로 손에 익혔는지를 종류 수로나마 보여 준다는 점이죠. 이름이 other 로 가려진 상태로는 절반짜리지만요.

다음에 열릴 만한 필드는 MCP 도구 호출 단위 지표와 고객 정의 항목의 선택적 이름 공개 쪽입니다. 둘 중 하나라도 붙으면 이 리포트는 그때 다시 볼 만해집니다.

참고 자료