AI 코딩 기여도 측정 — 한 줄만 섞여도 그 PR은 AI 작성으로 집계됩니다

회사가 AI 코딩 도구를 도입하면 관리자 화면에 AI 코딩 기여도가 뜹니다. AI가 몇 줄을 썼고, PR 중 몇 퍼센트에 AI가 들어갔고, 누가 제일 많이 썼는지 순위까지요. 이 블로그는 전에 회사가 무엇까지 볼 수 있는지를 다뤘는데, 이번엔 그 숫자가 어떻게 만들어지는지를 공식 문서에서 확인했습니다. 개발자 입장에서 알아둘 게 몇 개 있었습니다.

📌 30초 요약

• ★한 줄이면 됩니다 — "AI 세션 중에 작성된 코드가 한 줄이라도 들어 있으면" 그 PR은 AI 작성으로 태그됩니다.
• ★머지되면 깃허브에 라벨이 붙습니다 — claude-code-assisted가 자동으로 달립니다.
• 21일 전부터 2일 후까지의 세션이 매칭 대상입니다. 3주 전에 만졌던 게 오늘 PR에 붙을 수 있습니다.
• 반대로 안 붙는 경우도 있습니다 — 20% 넘게 고쳐 쓰면 AI 기여로 안 칩니다.
• 순위가 매겨집니다 — 상위 10명 리더보드에 전체 사용자 CSV 내보내기까지 됩니다.
• 문서가 스스로 "과소추정"이라고 밝힙니다 — 확신이 높은 것만 세기 때문입니다.

한 줄이면 그 PR은 AI 작성입니다

"PRs are tagged as 'with Claude Code' if they contain at least one line of code written during a Claude Code session."

AI 세션 중에 작성된 코드가 최소 한 줄이라도 들어 있으면 그 PR은 "AI 사용"으로 태그된다 — 공식 분석 문서

그러니까 "AI가 쓴 PR 비율 70%"라는 숫자는 "PR의 70%에 AI 코드가 한 줄 이상 들어 있다"는 뜻이지, 코드의 70%를 AI가 썼다는 뜻이 아닙니다. 이 둘은 완전히 다른 얘기인데 보고서에서는 나란히 놓이기 쉽습니다.

줄 수를 세는 방식도 정해져 있습니다. "유효 줄"만 셉니다 — 정규화 후 3글자를 넘는 줄만이고, 빈 줄과 괄호만 있는 줄, 사소한 문장부호만 있는 줄은 제외됩니다. 닫는 괄호가 수백 줄이어도 실적으로 안 잡힌다는 뜻입니다.

머지하면 깃허브에 라벨이 붙습니다

이게 개발자 입장에서 제일 체감되는 부분입니다. 집계가 대시보드 안에서만 도는 게 아니라 깃허브의 PR에 라벨이 실제로 달립니다.

# 머지된 PR에 자동으로 달리는 라벨
claude-code-assisted

# 그래서 깃허브 검색으로도 집계가 된다
#   label:claude-code-assisted is:merged

# 즉 대시보드 권한이 없어도
#   저장소를 볼 수 있는 사람이면 누구나 셀 수 있다

문서가 대시보드 대신 깃허브에서 조회하려면 이 라벨로 검색하라고 직접 안내합니다. 즉 관리자 화면 권한이 없는 사람도 저장소만 볼 수 있으면 누가 AI를 얼마나 썼는지 셀 수 있습니다. 이건 문서에 적힌 사실이고, 좋고 나쁨은 조직마다 다를 겁니다.

어떻게 매칭하나 — 21일 창과 20% 규칙

규칙	내용	개발자에게 뜻하는 것
시간 창	머지일 기준 21일 전 ~ 2일 후 세션	3주 전 세션이 오늘 PR에 귀속될 수 있음
20% 규칙	20%를 넘게 고쳐 쓰면 AI 기여로 안 침	많이 손보면 내 것으로 남음
정규화	공백 정리, 따옴표 표준화, 소문자 변환 후 비교	흔한 짧은 줄은 우연히 겹칠 수 있음
제외 파일	잠금 파일, 생성 코드, 빌드 폴더, 테스트 픽스처, 1,000자 넘는 줄	자동 생성물로 숫자를 못 부풀림
브랜치	출발·도착 브랜치를 고려하지 않음	체리픽·리베이스가 섞이면 어긋날 수 있음

20% 규칙은 개발자에게 유리한 쪽입니다. AI가 초안을 주고 내가 크게 고쳐 썼다면 그건 AI 기여로 안 잡힙니다. 문서 표현으로 "개발자가 상당히 다시 쓴 코드는 귀속되지 않는다"입니다. 대충 받아 쓴 것과 제대로 다듬은 것을 구분하려는 설계로 보입니다 — 다만 이 해석은 제 것이고 문서가 의도를 밝힌 건 아닙니다.

반면 소문자로 바꿔서 비교한다는 대목은 반대 방향입니다. return null; 같은 흔하고 짧은 줄은 우연히 일치할 수 있습니다. 물론 3글자 초과 조건과 확신 기준이 걸려 있으니 과대집계보다는 과소집계 쪽이라는 게 문서의 입장입니다.

문서가 스스로 "적게 잡힌다"고 말합니다

"These metrics are deliberately conservative and represent an underestimate of Claude Code's actual impact. Only lines and PRs where there is high confidence in Claude Code's involvement are counted."

이 지표들은 의도적으로 보수적이며 실제 영향의 과소추정이다. 관여가 확실한 줄과 PR만 센다 — 공식 분석 문서

이 문장은 양쪽으로 읽어야 합니다. 도입을 정당화하는 쪽에서는 "실제로는 더 크다"는 근거가 되고, 개발자 쪽에서는 "이 숫자가 내 기여를 정확히 반영하지 않는다"는 근거가 됩니다. 같은 문장이 두 방향으로 다 쓰입니다.

⚖️ 개인 평가에 쓰는 문제 — 여기부터는 제 의견입니다

문서가 권하는 용도는 도입 추이 파악·ROI 산정·잘 쓰는 사람 찾기입니다. 인사 평가에 쓰라는 말은 없습니다. 그런데 상위 10명 리더보드와 전체 사용자 CSV 내보내기가 있으니, 조직에 따라 그 방향으로 쓰일 수 있습니다. 스스로 과소추정이라고 밝힌 지표를 개인 평가에 쓰는 건 위험하다는 게 제 생각인데, 이건 문서의 서술이 아니라 제 판단입니다. 도입 검토 중이라면 측정 목적을 미리 합의하고 문서로 남기는 편이 낫습니다.

어디까지 보이나 — 플랜과 조건

항목	Team · Enterprise	API 고객
사용량 지표 · 접속자 수	O	O
기여 지표 · 라벨 · 리더보드	O (공개 베타)	X
1인당 지출	별도 보고서	O (추정치)
데이터 미보관을 켠 조직	기여 지표 불가	해당 없음

맨 아랫줄이 데이터 전송을 끄는 이야기와 이어집니다 — 데이터를 안 남기기로 하면 기여 지표를 못 봅니다. 사용량 지표만 남습니다. 보안과 측정 사이의 맞바꿈이고, 이 블로그에서 확인한 두 번째 사례입니다. 그리고 기여 지표는 Team·Enterprise 전용이라 플랜과 구매 경로에 따라 갈립니다.

켜는 것도 자동이 아닙니다. 깃허브 관리자가 앱을 설치하고 소유자 권한으로 두 개의 토글을 켠 뒤 인증까지 마쳐야 합니다. 데이터는 보통 24시간 안에 나타나고 하루 단위로 갱신됩니다. 즉 라벨이 붙기 시작했다면 조직이 그 설정을 켰다는 뜻입니다.

⚠️ 이 글의 한계 — 제가 먼저 밝힙니다

• 대시보드를 직접 못 봤습니다. 관리자 권한이 있는 조직 계정이 없어서 화면을 확인하지 않고 문서만 읽었습니다.
• 매칭 정확도를 검증하지 않았습니다. 소문자 비교로 오탐이 얼마나 나는지, 20% 기준이 실제로 어떻게 계산되는지 재보지 않았습니다.
• 공개 베타입니다. 기여 지표는 베타 단계라 동작과 기준이 바뀔 수 있습니다.
• "평가에 쓰면 안 된다"는 제 의견입니다. 문서는 권장 용도만 적었고 금지한다고 쓰지 않았습니다.
• 라벨이 조직 밖으로 보이는지는 확인 못 했습니다. 저장소가 공개면 라벨도 보일 가능성이 있지만 문서에서 그 문장을 찾지 못했습니다.

🗺️ AI 지출 전체 지도

측정은 회사로 넘어가는 단계의 일입니다. 무료로 시작해서 결제하고 상한을 걸기까지, 순서대로 묶어 둔 지도가 있습니다.

AI 지출 완전 정복 — 7단계 지도 보기 →

자주 묻는 것

Q. 내 PR에 라벨이 붙는 걸 막을 수 있나요?

문서에 개인이 끄는 방법은 없습니다. 조직 설정이라 소유자가 기능을 꺼야 합니다. 다만 20%를 넘게 고쳐 쓰면 귀속되지 않는다고 적혀 있으니, 초안을 받아 충분히 다시 쓰는 경우는 자연히 빠집니다. 라벨을 피하려고 코드를 바꾸라는 얘기는 아닙니다 — 그건 본말이 뒤집힌 겁니다.

Q. "AI가 쓴 코드 70%"라는 발표를 어떻게 읽어야 하나요?

어느 지표인지부터 물어보세요. "AI가 들어간 PR 비율"과 "AI가 쓴 줄 비율"은 완전히 다른 숫자인데 둘 다 70%로 적힐 수 있습니다. 대시보드에도 두 값이 따로 있습니다. PR 비율은 한 줄만 있어도 카운트된다는 걸 기억하세요.

Q. 개인 요금제로 쓰면 회사가 볼 수 있나요?

기여 지표는 조직 계정 안의 사용자만 대상이라고 문서에 적혀 있습니다. 다만 회사 저장소에 PR을 올리는 순간 이야기가 달라질 수 있고, 개인 계정으로 회사 코드를 다루는 건 데이터 정책 쪽에서도 별개 문제입니다.

Q. 관리자인데 무엇부터 보면 되나요?

문서는 도입 추이·1인당 PR 변화·다른 엔지니어링 지표와 함께 보기를 권합니다. 지출 쪽은 별도 보고서나 원격 측정 내보내기를 봐야 하고, 화면의 지출은 추정치라 실제 청구와 다릅니다 — 비용 문서를 읽은 글에서 같은 경고를 봤습니다.

🔁 제로 데이터 보존이 기능을 막는 세 번째 사례 (8월 16일 추가)

이 글에서 제로 데이터 보존을 켠 조직은 기여도 지표를 못 쓴다고 적었습니다. 그게 이 도구의 일반 규칙에 가깝다는 걸 확인했습니다. 오늘 자체 호스팅 환경 문서를 열어보니 같은 조건에서 그 기능도 아예 사용 불가였습니다. 데이터 전송을 최소로 조인 조직이 다른 기능도 함께 잃는 사례까지 합치면 세 번째입니다. → 보존을 0으로 만들수록 쓸 수 있는 기능이 줄어듭니다. 회사 도입을 검토한다면 ZDR을 켤지 말지가 프라이버시 문제로만 끝나지 않고 기능 목록을 결정한다고 봐야 합니다. 세 번째 사례의 전말은 자체 호스팅을 뜯어본 기록에 있습니다.

🤖 자동으로 도는 PR은 전부 이 조건에 걸립니다 (8월 16일 추가)

이 글의 규칙은 세션 중에 쓰인 코드가 한 줄만 있어도 그 PR 전체가 AI 작성으로 태깅된다였습니다. 여기에 예약 실행되는 루틴을 곱하면 이야기가 달라집니다. 루틴은 클라우드에서 자동으로 도는 정식 세션이고, 만들어낸 커밋과 PR은 내 깃허브 계정으로 올라갑니다. 즉 루틴이 연 PR은 정의상 전부 "AI 작성"으로 집계되고, 작성자는 나로 찍힙니다. 밤마다 도는 루틴을 몇 개 걸어두면 내 이름 옆의 AI 비중이 그만큼 올라간다는 뜻입니다 — 이 글이 짚은 대로 그 숫자를 평가에 쓰면 안 되는 이유가 하나 더 생긴 셈입니다. 다만 이 연결은 두 문서를 겹쳐 읽은 제 추론이고 어느 쪽도 그렇게 명시하진 않았습니다. 루틴 쪽 정리는 승인 창 없이 도는 자동 실행에 있습니다.

✨ 정리하면

한 줄이면 그 PR은 AI 작성으로 집계되고, 머지되면 깃허브에 라벨이 붙습니다. 매칭은 21일 전부터 2일 후까지를 보고, 20% 넘게 고쳐 쓰면 빠집니다.

숫자를 볼 때는 "PR 비율"인지 "줄 비율"인지부터 가르세요. 그리고 문서가 스스로 과소추정이라고 밝힌 지표라는 것도요. 도입 추이를 보는 데는 쓸 만하고, 사람을 줄 세우는 데 쓰기엔 근거가 약합니다 — 뒤엣것은 제 의견입니다.

📎 출처와 주의

• 1차 확인 — 한 줄 기준 태그, 라벨 이름, 21일 시간 창, 20% 규칙, 정규화 방식, 제외 파일, 유효 줄 정의, 과소추정 서술, 플랜별 가용성, ZDR 제약은 공식 팀 사용량 분석 문서(`code.claude.com/docs/en/analytics`)에서 2026년 8월 15일에 직접 확인했습니다. 인용한 영문 문장은 원문 그대로입니다.
• 검증하지 않은 것 — 대시보드 실제 화면, 매칭 정확도, 오탐률. 문서만 읽었습니다.
• 못 찾은 것 — 라벨이 조직 밖 열람자에게 어떻게 보이는지. "안 보인다"가 아니라 이 문서에서 못 찾았다는 뜻입니다.
• 제 의견임을 밝히는 부분 — 20% 규칙의 설계 의도 해석, 개인 평가에 쓰는 것에 대한 판단.
• 기여 지표는 공개 베타입니다. 기준과 동작이 바뀔 수 있으니 도입 결정 전에 원문을 다시 확인하세요.