채팅을 썼는데 비활동 사용자일까, 깃허브 사용 지표의 빈칸

Copilot으로 채팅을 했는데 보고서에는 Passive users로 묶여 있다면, 먼저 무엇을 세는 화면인지 궁금해질 것이다. 검토 댓글에 답한 사람의 수와 코드를 고친 사람의 수도 다를 수 있다. 이름이 비슷한 숫자라도 그 뒤에 있는 행동은 제각각이다.

깃허브는 11월 5~6일 Copilot의 기능 참여, 코드 검토 댓글에 대한 반응, 편집기 이벤트의 누락을 나눠 보여주는 변경을 발표했다. 채팅을 쓰는 사람이 더 잘 보이게 됐고, 댓글에 반응한 시점과 세부 기록이 빠진 조건도 드러났다. 필드마다 어떤 사람과 행동이 담겼는지 하나씩 따라가 보자.

비활동이라는 이름 뒤에 있던 채팅 사용자

Copilot impact dashboard의 Agent adoption 차트는 Copilot Chat과 VS Code Agents 창을 포함해 아홉 가지 경험의 참여를 보여주게 됐다. 28일 보고서에도 chat과 vscode_agent 항목이 추가된다. 기능 참여는 해당 기간 중 적어도 이틀에 그 기능을 사용했는지를 기준으로 하며, 한 사용자가 여러 기능에 함께 집계될 수 있다.

이름이 Passive users였던 집단은 Chat-first users로 바뀌었다. 깃허브는 이들이 실제로 Copilot을 쓰지만 도입 단계에 필요한 기능 사용 기준을 충족하지 않은 집단이라고 설명한다. 여기서 이름과 가시성이 바뀐 것과 도입 단계의 기준이 바뀐 것은 다르다. 채팅과 Agents 창의 참여는 표시되지만 도입 단계 판정에는 들어가지 않고, API의 해당 집단 값도 No Cohort로 남는다.

보고서의 이름이 달라졌다고 도입 성과까지 달라진 것은 아니다. 변경 전 기간의 보고서는 원래 일곱 기능만 포함한다. 전후 숫자를 나란히 놓을 때에는 새로 포함된 기능부터 확인해야 한다. 행동이 늘어난 것과 행동을 보여주는 칸이 늘어난 것을 혼동하지 않기 위해서다.

댓글에 답한 것과 결함을 고친 것은 다르다

저장소별 하루 보고서의 copilot_code_review 객체에는 평가한 댓글 수와 그중 사용자가 반응한 댓글 수가 들어간다. 두 수를 나누면 addressed rate를 구할 수 있다. 이때 반응은 준비된 제안을 적용하는 행동에 한정되지 않는다. Copilot에 수정을 요청하거나 직접 코드를 고치는 경우, 나중 PR에서 고치겠다고 답하는 경우도 포함한다.

댓글은 해당 PR이 병합될 때 평가돼 병합일에 집계된다. 댓글이 달린 날짜와 보고서에 나타나는 날짜가 다를 수 있다는 뜻이다. 봇이 연 PR의 댓글은 보통 이 평가에서 제외되는 반면, Copilot 검토 뒤 사람이 변경 요청을 하지 않은 병합 PR 수는 봇 PR도 포함한다. 서로 가까이 놓인 필드라도 분모가 같다고 가정할 수 없다.

아래 코드는 두 댓글 집계 필드의 비율만 계산하는 독립 예제다. 빠진 값이나 평가 댓글이 없는 경우를 0%로 바꾸지 않는다. 함수가 돌려주는 비율이 뜻하는 것은 공식 정의에 따른 반응의 비중이며, 실제 결함을 고친 비율이나 코드의 정확도는 아니다.

// ARCH.B 독립 설명 예제. 실제 조직 데이터·GitHub 응답이 아닙니다.
// 외부 호출 없이 두 집계 필드의 비율만 계산합니다.
function addressedRate(report) {
  const n = report.total_comments_evaluated;
  const a = report.total_comments_addressed;
  if (!Number.isInteger(n) || !Number.isInteger(a) ||
      n <= 0 || a < 0 || a > n) return null;
  return a / n;
}
// null은 계산할 근거가 없음을 뜻하며, 0%로 바꾸지 않습니다.
// 이 비율은 결함 수정률·코드 품질 점수가 아닙니다.

활동은 했지만 기록이 도착하지 않았다면

client_telemetry_present가 false라는 것은 그날 사용자의 활동은 확인했으나 편집기의 사용 이벤트를 받지 못했다는 뜻이다. 이 사용자는 활동 사용자로 남지만 코드 줄 수나 기능·모델별 세부 정보가 부족할 수 있다. 버전이 오래됐거나 편집기 텔레메트리가 꺼져 있거나 프록시가 이벤트를 막는 상황 등이 원인으로 제시된다.

버전 충족 여부는 usage_metrics_requirements에서 met·unmet·unknown으로 따로 표시한다. 모든 최소 버전을 충족해도 이벤트가 오지 않을 수 있으므로 두 신호는 독립적이다. 이벤트 누락 사용자 수와 최소 버전 미달 사용자 수에는 같은 사람이 들어갈 수 있어 합계로 고유 사용자 수를 만들면 안 된다. 날짜별 수도 여러 날 더하면 같은 사람을 다시 셀 수 있다.

null이거나 필드가 없는 경우는 false나 0과 다르다. 변경 전 날짜에는 해당 값이 없으므로, 새 열을 옛 보고서에 붙이면서 빈칸을 비활동으로 바꿔서는 안 된다. 이 지표는 기업·조직 보고서의 권한과 사용 지표 정책이 켜진 범위에서 제공되며 모든 개인 계정의 활동을 그대로 보여주는 자료도 아니다.

채팅을 쓴 날, 검토 제안에 답한 순간, 편집기 이벤트가 도착했는지는 각각 다른 기록이다. 참여·반응·누락이라는 세 이름을 실제 행동으로 풀어 놓으면, 숫자를 비교하기 전에 맞춰야 할 분모와 날짜가 보인다.

ARCH.B 의견

이 변경에서 흥미로운 부분은 채팅을 쓰던 사람에게 맞는 이름을 돌려준 점이다. Passive users보다 Chat-first users라는 이름은 무엇을 했는지 더 구체적으로 말해준다. 사용 현황 화면에서 항목을 이름 짓는 일도 숫자를 해석하는 방식에 영향을 준다.

빈칸을 빈칸으로 남기는 선택도 중요하다. 기록을 받지 못했다는 이유로 활동을 0으로 바꾸면, 화면은 모르는 것을 안다고 말하게 된다. 반응 비율을 계산하는 코드는 짧지만 그 비율 옆에 무엇을 설명할지는 길게 고민할 만하다. 답글, 수정, 미관측의 차이가 사용자의 눈에도 남아 있어야 하기 때문이다.