Copilot agent metrics 활용법: Claude·Codex 에이전트 사용량을 분리해 보는 기준

검색 의도: Copilot usage metrics API agent app activity, AI 에이전트 사용량 측정, GitHub Copilot metrics 핵심 요약: GitHub Copilot usage metrics API가 third-party agent app activity를 개별 에이전트 단위로 제공하기 시작했다. Claude, Codex 같은 에이전트를 GitHub workflow 안에서 함께 쓰는 조직은 이제 채택률과 세션 수를 분리해서 볼 수 있다.

“AI를 많이 쓴다”는 지표는 너무 넓다

팀에서 AI 코딩 도구를 도입하면 처음에는 사용량만 본다. 전체 interaction 수, 활성 사용자 수, seat 사용률 같은 지표다. 하지만 에이전트가 늘어나면 이 지표는 금방 흐려진다. Copilot coding agent, Claude, Codex, 기타 파트너 agent app이 모두 같은 바구니에 들어가면 무엇이 실제로 쓰이는지 알기 어렵다.

GitHub는 2026년 8월 7일 Copilot usage metrics API에 agent app activity 구분을 추가했다고 밝혔다. enterprise, organization, enterprise-user, organization-user의 1-day 및 28-day reports에서 recognized agent app별 활동을 볼 수 있다.

새 optional 필드는 totals_by_3rd_party_agent다. 각 항목에는 agent_name, agent_id, user_initiated_interaction_count, session_count가 들어간다. 단, session_count는 enterprise와 organization aggregate report에만 포함되고 per-user entry에는 없다.

agent_id를 기준으로 봐야 하는 이유

GitHub는 display name이 바뀔 수 있으므로 agent_name이 아니라 agent_id로 group하라고 안내한다. 이건 데이터 파이프라인에서 중요한 포인트다. 이름을 기준으로 월별 대시보드를 만들면 어느 날 “Claude”가 “Claude Agent”로 바뀌었을 때 다른 제품처럼 보일 수 있다.

따라서 저장 테이블은 다음 구조가 낫다.

• report_date
• scope_type: enterprise 또는 organization
• scope_id
• agent_id
• agent_name_snapshot
• user_initiated_interaction_count
• session_count

agent_name_snapshot은 화면 표시용으로 저장하되, join key는 agent_id로 잡는다. 이 작은 결정 하나가 분기별 도입 리포트의 신뢰도를 만든다.

interaction count와 session count를 섞지 말 것

GitHub는 nested user_initiated_interaction_count가 agent app job start 수를 의미한다고 설명한다. top-level field의 같은 이름은 다른 telemetry의 explicit prompt count라서 서로 더하면 안 된다.

이 경고는 실무에서 자주 터지는 실수다. 필드명이 같으면 분석가가 전체 interaction을 계산한다고 두 값을 합쳐버린다. 그러면 보고서에는 “사용량 증가”가 보이지만 실제로는 서로 다른 이벤트 타입을 더한 값이 된다.

권장 방식은 지표 이름을 내부에서 바꿔 저장하는 것이다. 예를 들어 agent app의 값은 agent_job_start_count, top-level prompt 값은 prompt_interaction_count로 rename한다. 원본 필드명은 metadata에 남기고, 대시보드에는 의미가 분명한 이름을 쓴다.

무엇을 측정해야 도입 판단에 쓸 수 있나

에이전트별 사용량이 보이면 이제 “누가 쓰나”보다 “어떤 작업에 맞나”를 봐야 한다. 단순 활성 수만으로는 충분하지 않다.

첫 번째 지표는 도입 깊이다. 한 번 실행한 사용자와 매주 반복 사용하는 사용자는 다르다. 28일 기준으로 user count, session count, job start count를 함께 보면 체험과 습관을 구분할 수 있다.

두 번째 지표는 대체 관계다. 새 에이전트를 도입했을 때 기존 Copilot coding agent 사용량이 줄었는지, 아니면 전체 에이전트 작업량이 늘었는지 봐야 한다. 전자는 도구 교체이고, 후자는 업무 범위 확장이다.

세 번째 지표는 팀별 적합도다. 프론트엔드 팀, 플랫폼 팀, 데이터 팀이 같은 에이전트를 같은 방식으로 쓰지는 않는다. 조직 리포트만 보면 평균에 묻힌다. 가능하면 organization-user report를 이용해 팀 매핑과 연결하되, 개인 감시처럼 보이지 않게 aggregate해서 봐야 한다.

라이선스와 rollout 의사결정에 연결하기

이 데이터의 진짜 가치는 비용 결정에 있다. 에이전트 앱을 전사 배포할지, 특정 팀에만 유지할지, 교육을 더 할지 판단할 수 있다.

예를 들어 Claude agent app을 50명에게 열었는데 28일 동안 8명만 반복 사용한다면 세 가지 가능성이 있다. 도구가 팀 업무와 맞지 않거나, 사용법 교육이 부족하거나, GitHub workflow 안에서 호출 지점이 자연스럽지 않은 것이다. 반대로 session count는 낮지만 job start당 PR 처리 시간이 크게 줄었다면 고가치 특수 도구일 수 있다.

따라서 metrics API만 보지 말고 PR lead time, review cycle, merge frequency와 연결해야 한다. 사용량은 입력 지표다. 개발 생산성이나 품질에 가까운 출력 지표와 같이 봐야 rollout 결정을 할 수 있다.

대시보드 구성 예시

처음에는 복잡한 BI보다 4개 카드면 충분하다.

1. Agent별 28일 active users
2. Agent별 session count와 job start count
3. 팀별 agent adoption rate
4. 신규 agent 도입 전후 PR lead time 변화

여기에 주의 문구를 달아야 한다. GitHub 설명처럼 recognized agent app activity만 포함되며, 식별되지 않은 agent activity는 생략된다. 즉 “0”은 항상 미사용을 뜻하지 않을 수 있다. 데이터 수집 범위와 누락 조건을 보고서에 적어야 한다.

실행 체크리스트

• Copilot usage metrics policy가 enabled인지 확인한다.
• API 접근 권한이 enterprise owner, billing manager, organization owner 또는 View Copilot Metrics 권한에 있는지 확인한다.
• totals_by_3rd_party_agent를 수집하되 agent_id를 기준 key로 저장한다.
• agent_name은 화면 표시용 snapshot으로만 사용한다.
• nested interaction count를 top-level interaction count와 합산하지 않는다.
• 1-day report는 이상 징후 탐지, 28-day report는 도입 판단에 쓴다.
• 팀별 adoption은 개인 평가가 아니라 rollout 개선 목적으로 aggregate한다.
• PR lead time, 리뷰 cycle, incident 같은 출력 지표와 함께 본다.

출처: GitHub Changelog, “Copilot usage metrics API adds agent app activity”, 2026-08-07.