Copilot 에이전트 성과가 갑자기 줄었다면, 먼저 IDE 업데이트부터 보세요

Copilot 에이전트 사용량이 갑자기 줄어 보였다면, 먼저 “사람들이 덜 썼다”가 아니라 IDE와 Copilot 확장 업데이트가 계측을 다시 살렸는지를 봐야 한다. 기준 시점은 2026년 10월 12일이다. GitHub는 10월 6일 공지에서 최근 일부 IDE가 Copilot agent session을 Copilot SDK로 옮기면서 세션이 어느 IDE에서 왔는지 식별하지 못했고, 그 결과 agent activity와 agent lines of code가 누락되거나 일부가 Copilot CLI 활동으로 잡혔다고 설명했다. GitHub Changelog · usage metrics

오늘의 독자 질문: 에이전트 ROI가 떨어진 건가, 계측이 빠진 건가

최근 seonoh.dev 글들은 에이전트 도구 권한, Copilot 로컬 샌드박싱, 모델 사용 정책처럼 “agent에게 어디까지 맡길 것인가”를 다뤘다. 오늘의 새 기여는 그다음 단계다. agent를 실제로 열어 둔 뒤, 대시보드 수치가 흔들릴 때 무엇을 성과 하락으로 보고 무엇을 데이터 품질 문제로 분리할지 정리한다.

GitHub 공지의 핵심은 간단하다. SDK 전환 자체가 나쁜 것이 아니라, 일부 agent session이 IDE attribution을 남기지 않아 상세 usage metrics가 비어 보였다는 점이다. GitHub는 Visual Studio Code 1.139.0 이상에서는 수정이 사용 가능하고, Visual Studio 18.12는 2026년 10월 예정, JetBrains는 10월 말, Eclipse와 Xcode는 2026년 11월 예정이라고 적었다. 같은 공지는 affected IDE version에서 빠진 activity는 나중에 backfill할 수 없고, 개발자가 업데이트할수록 점진적으로 회복된다고 설명한다. GitHub Changelog · supported versions

왜 이 문제가 실무에서 더 큰가

AI 에이전트 성과 보고는 보통 “도입률이 올랐다”, “agent가 만든 코드가 늘었다”, “PR 처리 시간이 줄었다”처럼 숫자로 시작한다. 그런데 숫자가 client telemetry에 기대고 있으면, 도구가 실제로 덜 쓰인 것과 계측 이벤트가 빠진 것을 섞어 보게 된다. GitHub의 Copilot metrics 문서는 usage metrics가 IDE, Copilot CLI, agent apps 활동을 포함하되, 가장 풍부한 세부 지표는 IDE의 client-side telemetry에서 온다고 설명한다. GitHub Docs · Copilot metrics

여기서 운영자가 조심할 점은 “서버 데이터가 있으니 다 괜찮다”도 아니라는 것이다. 같은 문서는 GitHub가 server-side telemetry로 client telemetry가 놓친 active user를 보완한다고 설명하지만, feature별 breakdown이나 lines-of-code 같은 일부 세부 지표는 richer telemetry가 오기 전까지 비어 있을 수 있다고 적는다. 즉 월간 활성 사용자 수는 정상처럼 보이는데 agent edit 줄 수만 낮게 보이는 상황이 가능하다.

그래서 오늘의 답은 “성과판을 버려라”가 아니다. 성과판을 해석하기 전에 계측판의 상태를 먼저 보고서에 붙여라다. 특히 agent activity가 줄었는데 Copilot 전체 사용량은 계속 늘었다면, 제품 사용 변화보다 먼저 SDK 전환·IDE 버전·텔레메트리 endpoint·프록시를 확인해야 한다.

첫 번째 체크: 영향을 받는 IDE와 버전을 분리한다

GitHub는 agent activity가 다시 잡히는 기준을 IDE별로 나눠 제시했다. Visual Studio Code는 1.139.0 이상, Visual Studio는 18.12 예정, JetBrains는 다음 plugin release 예정, Eclipse와 Xcode도 다음 release 예정이다. 이 날짜와 버전은 “성과가 회복되는 시작점”이지 과거 결측을 복원하는 버튼이 아니다. GitHub Changelog · rollout table

작은 팀이라면 per-user report에서 outdated client를 먼저 찾는 편이 좋다. GitHub 공지는 per-user reports의 totals_by_ide에 last_known_ide_version과 last_known_plugin_version이 포함된다고 설명한다. 이 필드로 “업데이트된 그룹”과 “아직 영향권에 남은 그룹”을 분리하면, 대시보드 전체 평균보다 훨씬 덜 흔들리는 비교가 된다. GitHub Changelog · outdated clients

반대로 업데이트가 끝나지 않은 팀 전체를 한 덩어리로 보고 “agent 활용률이 떨어졌다”고 결론내리면 위험하다. 실제로는 사용량이 유지되거나 늘었는데, affected IDE version이 보내야 할 상세 이벤트를 못 보냈을 수 있다.

두 번째 체크: Copilot CLI 수치를 그대로 성과로 보지 않는다

GitHub는 일부 activity가 Copilot CLI activity로 집계됐을 수 있고, 과거 CLI metrics는 실제 CLI 사용과 분리할 수 없어 고칠 수 없다고 설명했다. 이 문장은 작지만 중요하다. agent 기능을 여러 IDE와 CLI에서 같이 쓰는 팀은 “CLI 사용이 늘었다”는 수치가 실제 습관 변화인지, attribution 누락의 부산물인지 분리해야 한다. GitHub Changelog · CLI attribution

실무 보고서에는 이렇게 적는 편이 안전하다. “10월 6일 GitHub 공지 기준, affected IDE의 agent activity와 agent lines of code는 업데이트 전까지 과소 집계될 수 있고, 일부 CLI attribution은 과거 값을 정정할 수 없다.” 이 한 줄을 붙이면 의사결정자가 숫자를 과잉 해석할 가능성이 줄어든다.

세 번째 체크: 텔레메트리 차단과 오래된 확장을 같이 본다

이번 문제의 직접 원인은 SDK 전환과 IDE attribution이지만, GitHub 문서는 client-side metrics가 흔들리는 일반 원인도 함께 든다. IDE telemetry가 꺼져 있거나, network proxy 또는 firewall이 Copilot telemetry endpoint를 막거나, IDE와 Copilot extension이 오래됐거나, client가 telemetry 전송 방식을 바꾸면 보고서와 다른 Copilot 데이터가 어긋날 수 있다. GitHub Docs · client-side gaps

이 항목은 보안팀과 개발팀이 같이 봐야 한다. 보안팀은 프록시와 방화벽을 강화하고, 개발팀은 agent 성과를 보고 싶어 한다. 둘 다 맞다. 다만 endpoint 차단 때문에 세부 지표가 비어 있다면, 대시보드 앞에서 “도입 효과가 없다”고 말하기 전에 차단 정책의 의도와 예외 범위를 먼저 합의해야 한다.

네 번째 체크: JetBrains 팀은 MCP 자동 시작 설정도 같이 본다

GitHub는 10월 10일 Copilot for JetBrains 업데이트에서 enterprise-managed default model, diagnostics에서 Fix action, 그리고 Copilot과 Claude의 MCP server automatic startup을 끄는 설정을 추가했다고 공지했다. 이 글의 주제인 usage metrics 누락과 같은 원인은 아니지만, 같은 시기의 운영 신호로 보면 중요하다. agent가 어떤 모델로 시작하고, 어떤 MCP 서버가 자동으로 켜지는지를 중앙에서 관리하는 쪽으로 IDE 설정이 움직이고 있기 때문이다. GitHub Changelog · JetBrains controls

성과 측정과 권한 통제는 따로 놀지 않는다. “agent가 얼마나 일했는가”를 보려면 먼저 “agent가 어디서 어떤 도구와 모델로 실행됐는가”를 안정적으로 남겨야 한다. JetBrains 조직이라면 이번 업데이트를 단순 UI 개선이 아니라, 모델 기본값·MCP 시작·worktree 안정성까지 묶은 운영 점검 신호로 보는 편이 낫다.

작은 팀용 보고서 문장

아래 문장을 그대로 내부 보고서에 붙여도 된다.

• 이번 기간의 Copilot agent activity와 agent lines of code는 일부 IDE의 SDK 전환 영향으로 과소 집계됐을 수 있다.
• Visual Studio Code 1.139.0 이상 사용자와 그 이전 사용자를 분리해 본다.
• Visual Studio, JetBrains, Eclipse, Xcode 팀은 GitHub가 공지한 rollout 완료 전후를 같은 기준으로 비교하지 않는다.
• Copilot CLI 증가분은 실제 CLI 사용 증가와 attribution 오차가 섞였을 수 있어, 과거 값은 보정하지 않고 주석 처리한다.
• telemetry off, proxy/firewall, outdated extension, unsupported editor를 별도 결측 원인으로 기록한다.

결론: AI 에이전트 성과 논쟁의 첫 질문은 “숫자가 맞나”다

Copilot agent를 도입한 팀이 이번 공지에서 얻을 교훈은 단순하다. agent 성과는 모델 성능만의 문제가 아니라, IDE 버전·확장 버전·텔레메트리·프록시·attribution까지 포함한 관측 시스템의 문제다.

업데이트 후 수치가 회복되면 “agent가 갑자기 더 똑똑해졌다”가 아니라 “이제 보고서가 다시 보기 시작했다”에 가깝다. 반대로 업데이트 후에도 agent activity가 낮다면 그때부터 워크플로우, 권한, 리뷰 병목, 사용자 교육을 봐도 늦지 않다. 숫자 싸움을 시작하기 전, 계측이 정상인지 확인하는 것이 오늘의 실무 이득이다.

자주 묻는 질문

GitHub가 빠진 데이터를 나중에 채워 주나요?

GitHub는 affected IDE version의 activity가 IDE를 식별하지 못했기 때문에 나중에 attribution할 수 없고, 개발자가 수정된 버전으로 이동하면서 점진적으로 회복된다고 설명했다. 그래서 과거 결측은 보정하려고 꾸미기보다 보고서에 주석으로 남기는 편이 안전하다.

billing도 잘못됐다는 뜻인가요?

GitHub 공지는 billing은 affected되지 않았고, 바뀐 것은 usage metrics의 attribution이라고 설명한다. 비용 청구 문제로 확대하기보다, 성과 보고와 도입률 해석의 데이터 품질 문제로 다루는 것이 맞다.

우리 팀은 VS Code만 쓰는데 무엇부터 하면 되나요?

먼저 Visual Studio Code가 1.139.0 이상인지 확인하고, Copilot 확장 버전과 telemetry 설정을 같이 본다. 그다음 업데이트 전후의 agent activity와 28일 보고서를 분리해서 해석한다.

서버 측 활성 사용자 수가 있으면 lines of code 지표도 믿어도 되나요?

그렇지 않다. GitHub 문서는 server-side telemetry가 active user를 보완하지만, feature별 breakdown이나 lines-of-code 같은 일부 상세 지표는 richer client telemetry가 필요하다고 설명한다. 활성 사용자 수와 agent edit 세부 지표를 같은 신뢰도로 보면 안 된다.

참고한 1차 자료

• GitHub Changelog, “Update your IDE to restore agent activity in Copilot usage metrics”, 2026-10-06. 확인일: 2026-10-12.
• GitHub Docs, “GitHub Copilot usage metrics”. 확인일: 2026-10-12.
• GitHub Changelog, “New controls and chat improvements in Copilot for JetBrains”, 2026-10-10. 확인일: 2026-10-12.