Copilot 에이전트 사용량이 통계에서 빠진다면?

세 줄 요약

에이전트 활동의 감소가 실제 사용 감소인지 판단하기 전에 IDE의 집계 오류를 확인해야 한다.
파일에 직접 반영한 코드는 자동완성 제안량이 아니라 agent_edit의 추가·삭제량으로 본다.
수정 후에도 보고서 반영 시간과 텔레메트리 전송 조건을 확인해야 한다.

에이전트를 덜 쓴 것이 아니라 출처 정보가 빠졌을 수 있다

개발자는 계속 Copilot 에이전트로 작업하는데 관리 대시보드의 활동이나 코드량이 줄었다면, 사용 습관보다 IDE 버전을 먼저 살펴볼 이유가 생겼다. GitHub가 10월 6일 공개한 문제는 일부 IDE가 에이전트 세션을 Copilot SDK로 옮기면서 어느 IDE에서 발생한 활동인지 식별 정보를 보내지 않은 것이다.

그 결과 활동 상당수가 보고서에서 빠지고 일부는 Copilot CLI 사용으로 분류됐다. 이 오류는 과금에 영향을 주지 않았다. 해당하는 VS Code 사용자는 1.139.0 이상에서 수정된 집계를 이용할 수 있다. 누락된 기록과 잘못 분류된 과거 CLI 기록은 소급 보정되지 않는다.

일반 지원 버전과 이번 오류의 수정 버전을 구분한다

관리자는 사용자별 보고서의 IDE 정보부터 볼 수 있다. totals_by_ide 안의 last_known_ide_version과 last_known_plugin_version은 사용자의 최근 IDE·플러그인 버전을 식별하는 데 쓰인다. 모두에게 같은 업데이트 요청을 보내기 전에 어느 환경이 남아 있는지 확인할 수 있는 단서다.

지원 IDE 표는 메트릭을 수집하기 위한 일반 최소 버전을 설명한다. 특정 SDK 이관 오류를 고친 버전과 같은 표가 아니다. VS Code 이외의 IDE는 해당 제품의 수정 릴리스가 적용됐는지 확인해야 한다. 10월 6일 공지의 다른 IDE 일정은 당시의 출시 예상이므로, 그 날짜만으로 패치 적용을 판단할 수 없다.

에이전트 편집량은 자동완성 제안량에서 찾지 않는다

버전 문제를 고쳐도 엉뚱한 칸을 읽으면 수치는 계속 0처럼 보일 수 있다. GitHub의 코드량 정의에서 에이전트는 제안을 보여주고 사용자가 하나씩 수락하는 자동완성과 다르게 취급된다. 파일을 직접 고친 양은 agent_edit 아래에서 집계한다.

알고 싶은 내용	읽을 항목	해석
IDE 에이전트를 썼는가	`used_agent`	사용 여부이며 편집량은 아니다.
파일에 얼마나 추가·삭제했는가	`agent_edit`의 `loc_added_sum`·`loc_deleted_sum`	에이전트가 파일을 바꾼 양이다.
화면에 어떤 코드 제안을 보여줬는가	`loc_suggested_to_add_sum`	직접 수행한 에이전트 편집량은 제외된다.

한 번의 지시로 여러 파일을 고치면 각 파일의 변경이 추가·삭제량에 들어간다. 그러므로 프롬프트 수와 코드 변경량이 같은 비율로 늘어야 한다고 볼 수 없다. 활동 여부, 제안, 파일 편집을 각각 읽어야 한다.

오늘 업데이트한 결과를 오늘 보고서에서 찾으면 이르다

공식 안내에 따르면 해당 날짜가 UTC 기준으로 끝난 뒤 보고서가 나오기까지 최대 2일이 걸린다. 업데이트 직후 화면에 변화가 없다는 사실만으로 수정 실패를 판단할 수 없다.

활성 사용자 수는 서버 측 정보로 잡히는데 기능별 사용량과 코드량은 비어 있는 경우도 있다. 상세 정보는 IDE의 텔레메트리에 더 많이 의존하기 때문이다. 조직의 수집 정책에 맞는 IDE 설정과 프록시·방화벽의 전송 허용 상태를 함께 살펴야 한다.

팀 보고서를 작성할 때는 IDE를 업데이트한 시점을 표시해 두는 편이 좋다. 이후 수치가 늘더라도 실제 활용 증가와 집계 회복이 함께 반영될 수 있기 때문이다. 과거의 빈칸을 0회 사용으로 처리하거나, 코드량의 반등만으로 도입 효과가 커졌다고 결론 내리기 전에 수집 조건부터 맞춰야 한다.