사내 MCP 이름이 보여도 도구 성공 횟수는 아닙니다: Copilot 사용 지표의 새 범위

사내 검색 MCP를 배포한 뒤 Copilot 사용 보고서에서 서버 이름을 발견했다고 해봅시다. 반가운 변화지만, 그 옆의 interaction_count를 곧바로 “검색 도구가 성공한 횟수”라고 보고하면 의미가 달라집니다. 연결 실패도 집계될 수 있고, 이미 연결한 서버에서 도구를 여러 번 호출해도 그만큼 이 수치가 늘어나지는 않기 때문입니다.

GitHub의 2026년 10월 22일 발표가 바꾼 핵심은 사내 커스터마이징을 이름으로 구분하는 범위와 목록의 길이입니다. 집계 단위 자체를 성공한 도구 호출로 바꾼 발표는 아닙니다. 이름이 보이면 식별 가능성이 늘어난 것이지, 도구 실행의 성공이 입증된 것은 아닙니다.

무엇이 새로 보이고, 무엇이 그대로인가

10월 공식 발표의 ‘What’s new’에 따르면, 조직이 정의한 스킬·커스텀 에이전트·MCP 서버·슬래시 명령·플러그인은 해당 목록에서 other 또는 custom 대신 설정된 이름으로 나타납니다. 이전에는 묶인 항목 때문에 어떤 내부 도구가 쓰이는지 구분하기 어려웠다면, 이제 지원되는 경로와 보고서에서는 이름을 단서로 도입 추이를 읽을 수 있습니다.

해당 배열은 totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd, totals_by_plugin입니다. 적용 범위는 엔터프라이즈·조직 보고서의 사용자별 1일·28일 보고서, 집계 1일 보고서, 집계 28일 보고서의 day_totals입니다. 모든 보고서의 모든 필드가 같은 방식으로 새 이름을 준다고 넓혀 읽어서는 안 됩니다.

각 레코드의 totals_by_* 목록은 최대 5개에서 최대 25개 항목으로 늘어납니다. 남은 활동은 끝의 other 항목으로 합쳐집니다. 따라서 “이제 사내 도구가 무제한으로 전부 펼쳐진다”는 해석도 맞지 않습니다. 이 숫자는 레코드별 목록 범위이지 직원 수나 도구 호출 성공률의 분모가 아닙니다.

10월 변화는 이름과 목록의 식별력 확대입니다. 남은 활동은 other로 묶이며 집계 계산은 유지됩니다. 실제 제품 화면이 아닌 원본 설명 도식입니다. 출처: github.blog/changelog/2026-10-22-custom-skills-agents-and-mcp-servers-in-usage-metrics-api.

스킬과 MCP 등의 에이전트형 커스터마이징 지표 자체는 9월 17일 발표에 이미 등장했습니다. 10월 발표는 이 기반 위에서 이름 노출과 목록 범위를 확장하며, interaction_count와 distinct_*_use_count의 계산 방식은 그대로라고 명시합니다. 새 기능을 소개할 때도 “지표 신설”과 “기존 지표의 식별력 확대”를 구분해야 도입 전후 비교가 흐려지지 않습니다.

MCP 수치의 반례: 실패한 연결도 활동이다

계산 의미는 변경되지 않았으므로 9월 발표의 ‘Important notes’를 함께 읽어야 합니다. MCP의 interaction_count는 Copilot CLI가 서버에 연결하거나 다시 연결하려는 시도에서 증가합니다. 성공한 시도와 실패한 시도가 모두 포함됩니다. 같은 연결을 유지한 상태에서 도구를 반복 호출하는 일은 이 횟수를 늘리지 않습니다.

아래는 실제 조직 데이터가 아닌 정의 설명용 가상 상황입니다. 연결에 실패한 흔적이 있어도 활동 수치는 생길 수 있습니다. 반대로 연결을 유지하면서 도구를 반복 실행하는 동안에는 도구 호출이 더 있었더라도 MCP 연결 시도 수치가 그대로일 수 있습니다. 두 경우를 나란히 보면 이 필드만으로 업무 결과나 자동화의 성공 여부를 판단할 수 없다는 점이 드러납니다.

정의 설명용 가상 상황입니다. MCP interaction_count는 연결·재연결 시도를 세며 도구의 성공 처리량이 아닙니다. 실제 조직 측정값이 아닙니다. 출처: github.blog/changelog/2026-09-17-agentic-cli-customizations-now-in-the-usage-metrics-api.

팀 보고서의 안전한 문장은 “지원되는 클라이언트 텔레메트리에서 이 서버에 대한 연결 시도 활동이 관측됐다”입니다. “이 서버의 도구가 성공적으로 처리한 작업량”이라고 쓰려면 별도의 성공·실패 결과 관측이 필요합니다. 여기서 별도 관측이 필요하다는 것은 이 글의 운영상 해석입니다. GitHub 사용 지표 API가 그 결과 증거까지 제공한다고 주장하는 것은 아닙니다.

또한 항목 종류별로 interaction_count의 사건이 다릅니다. 9월 발표는 스킬·슬래시 명령·플러그인 스킬은 호출, 커스텀 에이전트는 시작, MCP는 연결 시도를 설명합니다. 이름이 붙은 배열이라는 이유만으로 서로 다른 사건을 합산해 하나의 “자동화 성공” 점수로 만들면 비교 대상이 섞입니다.

보고서 해석 결정표: 보이는 값 다음에 무엇을 판단할까

다음 표는 공식 정의를 바탕으로 작성한 실무 해석표입니다. 실제 응답을 캡처하거나 조직별 수치를 측정한 표가 아닙니다. “이름이 없다”거나 “수가 늘었다”는 관찰에서 멈추지 않고, 어떤 결론은 가능하고 어떤 결론은 보류해야 하는지 구분하는 데 목적이 있습니다.

보고서에서 본 것	가능한 해석	아직 말할 수 없는 것	다음 판단에 필요한 근거
사내 MCP 이름과 활동 수치	해당 이름으로 식별된 연결 시도 활동	도구 호출의 성공 횟수·처리량	실제 결과를 구분하는 별도 로그
이름 대신 other 또는 custom	묶인 활동이 존재함	그 도구가 미도입·미사용이라는 단정	보고 경로, 버전, 이름 형태, 처리된 보고일
빈 배열 또는 0	일치하는 활동이 없음	조직 전체에 도구가 없다는 주장	해당 필드의 적용 범위와 관측 조건
null 또는 필드 부재	커스터마이징 데이터를 사용할 수 없음	활동이 없다는 결론	수집 가능 여부와 보고서 범위
집계 distinct_*_use_count 증가	사용된 서로 다른 항목의 종류가 늘어남	고유 사용자 수 증가	사람 수를 별도로 판단할 근거
스킬 합계와 플러그인 합계	플러그인 스킬 활동은 스킬에도 포함됨	두 합계를 더한 중복 없는 총량	포함 관계를 유지한 별도 표시

9월 정의에서 집계 보고서의 고유 항목 수는 조직이나 엔터프라이즈 안에서 누군가 사용한 항목을 항목별로 한 번 셉니다. 사용자마다 같은 항목을 한 번씩 더하는 방식이 아닙니다. 따라서 distinct_mcp_use_count를 고유 MCP 사용자 수로 바꾸어 부를 근거가 없습니다. 목록에서 보이는 상위 항목 수와 고유 항목 수 역시 같은 질문에 답하는 값이 아닙니다.

플러그인의 경우에도 중복을 주의해야 합니다. 플러그인 지표는 플러그인에 연결된 스킬 호출만 세며, 그 호출은 스킬 합계에도 들어갑니다. 플러그인에서 오지 않은 스킬 호출은 스킬에만 들어갑니다. 플러그인 활동은 스킬 활동의 부분집합이므로 두 합계를 더하지 않아야 합니다.

플러그인 스킬은 스킬 활동의 부분집합이므로 합산하면 중복됩니다. 면적 비례 그래프가 아닌 포함 관계 도식이며, 고유 항목 수는 사람 수가 아닙니다. 출처: github.blog/changelog/2026-09-17-agentic-cli-customizations-now-in-the-usage-metrics-api.

이름이 안 보일 때는 도입 실패보다 관측 범위를 먼저

10월 발표의 ‘Coverage’는 이름을 보고하는 경로로 Copilot CLI의 대화형 세션과 프롬프트 모드, GitHub Copilot 앱, JetBrains 같은 ACP 연동, Copilot SDK를 열거합니다. 그중 프롬프트 모드·앱·ACP 연동에는 Copilot CLI 1.0.97 이상이 필요합니다. 이 조건을 모든 경로에 무차별 적용하거나, 반대로 경로 조건을 지운 채 “CLI는 다 된다”고 단순화하면 안 됩니다.

Copilot SDK에는 1.0.21 이상 조건이 있습니다. IDE의 에이전트 경험이 이 SDK 버전 이상에서 돌아갈 때는 이름을 보고하지만, IDE의 내장 채팅 텔레메트리는 이름을 보고하지 않습니다. 같은 IDE 안의 기능이라도 데이터 경로가 다를 수 있다는 뜻입니다. 팀원이 “IDE에서 썼다”고 말한 사실만으로 이름 필드의 존재를 예상하지 않는 편이 안전합니다.

이름 누락은 곧 미사용이 아닙니다. 버전 조건은 해당 경로에만 적용하며, 과거 보고일·경로형 이름·내장 채팅은 별도로 해석합니다. 문서 기반 진단 도식이지 실행 결과가 아닙니다. 출처: github.blog/changelog/2026-10-22-custom-skills-agents-and-mcp-servers-in-usage-metrics-api.

이름 자체에도 조건이 있습니다. 설정된 이름은 앞뒤 공백을 정리하고 128자로 제한해 보고하며, 파일 경로처럼 보이는 이름은 계속 other 또는 custom으로 묶습니다. 이름을 보고한다고 해서 파일 경로와 같은 내부 식별 정보까지 언제나 그대로 노출한다는 의미는 아닙니다. 반면 실제 설정 이름은 드러날 수 있으므로 외부로 보고서를 공유하기 전 내부 프로젝트명이나 서비스명이 들어 있는지 검토할 이유가 생깁니다.

이름은 이번 릴리스 후 처리된 보고일에서부터 나타나며, 이전 날짜는 여전히 묶여 있습니다. 과거 보고서를 다시 보았는데 이름이 없다는 이유로 과거 활동도 없었다고 판단해서는 안 됩니다. 도입 전후를 비교한다면 이름이 구분되기 시작한 보고일과 비교 구간을 함께 설명해야 합니다. 이것은 과거 데이터가 새 이름으로 소급 분해된다는 발표가 아닙니다.

마지막으로 이 지표는 클라이언트 텔레메트리입니다. 오래된 클라이언트나 텔레메트리 차단 등으로 활동이 실제보다 적게 집계될 수 있다고 공식 발표가 경고합니다. 추세와 도입 현황을 살피는 자료이지 정확한 회계 자료가 아닙니다. 수치의 증가를 개인 생산성 향상의 증거로 삼거나 비용 절감을 확정하는 것은 이 자료의 관측 범위를 넘어섭니다.

팀에 전달할 결론: 이름, 사건, 적용 범위를 함께 적기

보고서를 볼 수 있는 권한과 데이터가 의미하는 바도 별개입니다. 공식 안내는 엔터프라이즈 소유자·청구 관리자, 조직 소유자 또는 ‘View Copilot Metrics’ 권한을 부여한 조직·엔터프라이즈 커스텀 역할을 열거하며, Copilot 사용 지표 정책이 활성화되어 있어야 한다고 설명합니다. 이 글에서는 권한을 바꾸거나 조직 지표 API를 호출하지 않았습니다.

팀의 도입 보고에는 이름으로 구분한 대상, 그 필드가 세는 사건, 수집 경로와 버전, 비교하는 보고일을 함께 적는 방식이 유용합니다. MCP라면 연결 시도임을 명시하고 성공 처리량과 분리합니다. 누락 항목은 우선 관측 조건으로 분류하고, null과 0은 다른 상태로 남깁니다. 플러그인과 스킬은 포함 관계를 유지하고, 고유 항목은 사람 수로 바꾸지 않습니다. 이 구성은 API를 직접 실행해 입증한 절차가 아니라, 공식 정의에서 도출한 해석 기준입니다.

이 글은 공식 발표의 정의를 대조한 문서 분석이며, 실제 조직 보고서 조회나 Copilot 실행을 재현한 결과가 아닙니다. 본문 그림도 실제 제품 화면이 아니라 정의를 설명하기 위해 제작한 원본 도식입니다. 관련 없는 내부 글을 억지로 연결하는 대신, 바뀐 노출 범위와 유지된 집계 정의를 확인할 수 있는 아래 두 공식 발표를 근거로 삼았습니다.

이번 변화로 사내 도구의 이름은 더 잘 보이지만, 그 이름 옆 숫자의 의미까지 바뀐 것은 아닙니다. 도입 추이를 읽는 데는 식별력이 좋아졌고, 성공 처리량을 말하는 데는 여전히 다른 증거가 필요합니다.

출처와 확인 범위

• GitHub, Custom skills, agents, and MCP servers in usage metrics API — 2026년 10월 22일: What’s new, Coverage, Configured names, Accuracy, History, Access. 이름·목록 확장과 버전·처리일 조건의 근거입니다.
• GitHub, Agentic CLI customizations now in the usage metrics API — 2026년 9월 17일: Which items are used most?, How many different items were used?, Important notes. MCP 연결 시도, 고유 항목, 플러그인 포함 관계, 빈 값 해석의 근거입니다.

확인 기준은 2026년 10월 24일에 보존한 공식 본문입니다. 이후의 제품 동작이나 발표 변경을 별도로 검증한 글은 아닙니다.