Copilot의 사내 MCP 사용량, 연결 횟수와 호출 수가 다른 이유

MCP 통계는 도구 호출 대신 연결 시도를 센다

사내 MCP 서버의 interaction_count가 커졌다면 연결 시도가 많이 기록됐다는 뜻이다. 이미 연결된 서버에서 도구를 호출해도 이 수치는 늘지 않는다. 실패와 재연결도 포함하므로 같은 숫자가 업무 활용 증가와 연결 불안정 중 무엇을 뜻하는지는 따로 살펴야 한다.

GitHub의 10월 22일 변경은 그 활동을 조직이 설정한 이름으로 식별하게 해 준다. 이전에 other나 custom으로 묶이던 사내 도구를 구별할 수 있지만, 이벤트를 세는 방식 자체가 바뀐 것은 아니다.

공식 필드 정의에 따르면 플러그인 활동은 이미 스킬 합계에 들어 있다. 두 합계를 더하면 중복된다. 서로 다른 범주의 숫자를 하나의 ‘많이 쓰는 도구’ 순위로 묶기 전에 단위를 맞춰야 한다.

이름이 안 보이면 보고일과 실행 경로를 살핀다

새 이름은 지원 기능이 배포된 뒤 처리된 보고일에 등장한다. 이전 날짜의 other나 custom을 새 이름으로 소급 복원하지 않는다. 경로처럼 보이는 이름이나 이름을 얻지 못한 항목도 묶여 남는다.

이름을 보내는 경로는 Copilot CLI, Copilot 앱, ACP 연동, Copilot SDK다. 프롬프트 모드·앱·ACP에는 CLI 1.0.97 이상, SDK에는 1.0.21 이상이 필요하다. SDK가 내장 CLI를 별도 버전으로 바꿨다면 그 CLI도 1.0.97 이상이어야 한다. IDE의 기본 Copilot 채팅은 이름을 보고하지 않으며 SDK를 이용한 에이전트 실행과 구별해야 한다.

사용자별 1일 보고서와 집계 1일 보고서, 집계 28일 보고서의 각 day_totals에는 범주별로 이름이 있는 상위 25개 항목을 유지한다. 그 밖의 활동은 추가 other 항목으로 묶인다. 이름이 빠졌다는 사실만으로 사용하지 않았다고 결론 낼 수 없는 이유다.

누가 쓰는지는 사용자별 API 보고서에서 읽는다

이 사용자 지정 기능 통계는 대시보드가 아닌 API로 제공된다. 관리자는 먼저 Copilot usage metrics 정책을 켜고, REST API의 사용자별 보고서를 가져올 수 있다. 조직 소유자나 해당 범위의 메트릭 조회 권한이 있는 역할 등 접근 자격이 필요하다.

GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD

두 경로는 조직과 엔터프라이즈 범위 중 필요한 것을 선택한다. 응답의 download_links에서 NDJSON 보고서를 내려받고 report_day를 확인한다. 다운로드 주소는 유효기간이 있는 서명 URL이며, 당일 실시간 스트림이 아니라 처리가 끝난 날짜의 일일 보고서다.

조직의 실제 보고서를 읽을 때는 사용자 레코드의 totals_by_skill이나 totals_by_mcp에서 해당 이름을 찾는다. 집계의 distinct_mcp_use_count는 서로 다른 서버 식별자 수이므로 사용자 수를 대신하지 않는다.

수치가 높을 때와 이름이 없을 때 확인할 것이 다르다

GitHub의 해석 지침은 여러 사용자의 보고서에 같은 이름이 등장하는지를 채택 신호로 보도록 안내한다. 반면 MCP 연결이 예상보다 많으면 설정과 반복 연결을 먼저 살피고, 실제 도구 활용은 개발자 피드백이나 다른 내부 데이터로 확인하도록 한다.

클라이언트가 오래됐거나 원격 측정이 차단되면 활동이 적게 잡힐 수 있다. 이 보고서는 도입 추세와 사용이 기록된 대상을 찾는 데 유용하지만 승인된 도구만 사용됐다는 완전한 감사 기록은 아니다.

사내 도구의 효과를 판단하려면 이름별 활동을 찾은 다음 실제로 어떤 업무에 쓰였는지를 이어서 확인해야 한다. 연결 횟수, 스킬 실행 횟수, 사용자 수를 각각 읽어야 배포가 확산된 것인지 연결만 반복된 것인지 구분할 수 있다.