한 개발자가 자기 IDE 대시보드를 열었더니 "PCW 98%"이라고 떠 있었어요. AI가 짠 코드 비율이 98%라는 거예요. 이상하잖아요? 그래서 직접 실험을 했습니다. 결과는 충격적이었어요. 내가 49글자를 손으로 쳐도, 측정 시스템은 그중 46자만 사람 기여로 인정하고, 복사-붙여넣기 한 줄은 통째로 AI 점수로 넘어갔어요.
이게 뭔 일인데?
2026년 4월, William O'Connell이 자기 블로그에 올린 글이에요. 회사에서 쓰는 Windsurf(VS Code 기반 AI IDE)의 분석 대시보드를 봤더니 "% new code written by Windsurf" 지표가 98%로 찍혀 있었어요. 본인 체감으로는 10~20% 정도였는데 말이죠. "내가 손으로 쓴 코드보다 AI가 짠 게 49배 많다고? 그럼 진작에 토큰 예산 다 털리고 해고됐어야 하는 거 아냐?" 의심이 들어서 직접 실험을 시작했어요.
Windsurf 본인들도 "고객사 PCW 값은 보통 85% 이상, 종종 95% 이상으로 나옵니다"라고 공식 블로그에 적어놨어요. "환각이 아니라 정확한 수치"라고 강조하면서요. 하지만 측정 방식을 뜯어보면 이게 "정확하다"고 주장하는 게 무리예요.
O'Connell은 mitmproxy로 네트워크 트래픽을 가로채려다가 protobuf 인코딩 때문에 막혔는데, 다행히 대시보드 API 응답에 user_bytes, codeium_bytes, total_bytes, percent_code_written 필드가 노출돼 있었어요. 이걸로 그가 발견한 편향이 다섯 가지예요.
Windsurf PCW가 사람 기여를 깎아먹는 5가지 메커니즘
1. 자동 닫힘 괄호/따옴표는 사람 입력으로 안 침. 49자 입력해도 46자만 user_bytes 증가.
2. 붙여넣기는 user_bytes에 들어가지 않음. 내가 쓴 코드를 다른 파일로 옮겨도 0점.
3. 리팩토링이 통째로 AI 점수. 내가 쓴 함수를 AI에게 옮기게 시키면 100% AI 기여.
4. 세션 경계가 없음. 재시작하면 이전 세션 라인은 어디서 왔는지 잊음.
5. "커밋 시 측정"이라더니 git 연동 미작동. 실제로는 타이핑할 때마다 카운터가 움직임.
O'Connell이 결정적 실험을 했어요. human_file.js에 한 줄 직접 타이핑(49자), AI에게 똑같은 길이 한 줄을 ai_file.js에 쓰게 했어요. 그다음 자기가 쓴 함수를 AI 파일에 복붙하고, 자기 함수를 AI에게 다른 파일로 옮기라고 지시했어요. 결과: AI가 사람보다 두 배 넘는 양을 썼다고 보고됐어요(67.9%). 사실 두 파일은 길이도 거의 같았는데도요.
Cursor의 "AI Share of Committed Code"는 좀 더 정직한 git 기반 측정이었어요. 하지만 O'Connell이 100줄짜리 JS 파일을 붙여넣고 AI에게 따옴표만 바꾸라고 시켰더니, 100줄 전체가 "AI 작성"으로 카운트됐어요. AI가 실제로 건드린 건 49줄뿐이었는데도요. 결국 두 도구 모두 편향이 있는데 그 방향이 항상 "AI 비중 과대평가"예요.
왜 이게 더 심각한 문제인 건데?
Anthropic의 Claude Code 책임자 Boris Cherny가 2026년 1월에 "내 코드의 100%는 Claude가 쓴다. 회사 전체도 거의 100%다"라고 X에 올려서 화제가 됐어요. 비슷하게 Microsoft CEO Satya Nadella는 30%, Google은 75%를 자랑했고요. 임원이 발표하기 좋은 숫자예요. AI 회사 입장에선 자기 도구의 가치를 증명하는 숫자고요.
그런데 METR 연구는 정반대 결과를 냅니다. 16명 시니어 오픈소스 개발자를 대상으로 한 RCT(무작위 통제 시험)에서, AI 도구를 쓴 그룹이 19% 더 느렸어요. 더 무서운 건 "AI 덕분에 빨라졌다"고 본인들이 믿고 있었다는 거예요. 본인 체감으로는 20% 빨라졌다는데, 실제로는 19% 느려진 거였죠.
GitClear가 2억 1천 1백만 줄의 코드 변경을 5년치 분석한 결과도 충격적이에요. 리팩토링 비율은 2021년 25%에서 2024년 10% 이하로 떨어졌고, 복붙 코드는 8.3%에서 12.3%로 4배 늘었어요(처음으로 "복붙"이 "이동"을 추월). AI가 코드 양은 늘렸지만 코드베이스의 건강성은 측정 가능하게 나빠졌다는 얘기예요.
| 도구 벤더의 메트릭 | 현장에서 진짜 봐야 할 신호 | |
|---|---|---|
| 측정 단위 | 바이트 / 줄 수 (양) | PR 머지 사이클, 사후 수정률 (질) |
| 편향 방향 | AI 비중 과대평가 | 중립 — 머지 후 이슈/롤백으로 검증 |
| 측정 시점 | 타이핑 즉시 또는 커밋 시 | 머지 후 7~30일간 추적 |
| 의사결정 효용 | "AI가 일 다 하니 사람 줄이자" | "어디서 검증 부채가 쌓이는가" |
| 법적 리스크 | "코드 대부분이 저작권 보호 안 됨" | 사람 기여 비율을 보수적으로 산정 |
이게 단순한 메트릭 정확도 문제가 아니에요. "우리 회사 코드의 90%가 AI"라는 한 문장이 만들어지면, 경영진은 "그럼 사람이 왜 이렇게 많이 필요해?"를 묻기 시작해요. 게다가 미국에서는 AI 생성 저작물이 저작권 보호 대상이 아니라는 판결이 나와있어서, "코드의 대부분이 AI로 작성됐다"는 메트릭은 법무팀의 악몽이에요.
한국 현장에서도 같은 고민이 시작됐어요. 어느 사내 가이드라인 글에서는 "AI 코드 수용률을 KPI로 쓰면 품질 검증 없이 억셉만 하는 행동이 나온다"고 Goodhart의 법칙을 인용했고요. 다른 CTO는 "AI가 1분 만에 짜준 코드를 사람이 10분 동안 리뷰해야 하는 아이러니"를 지적했어요. 메트릭이 거짓말을 하는 동안, 진짜 비용은 코드 리뷰 시간으로 옮겨가고 있어요.
핵심만 정리: PR에서 진짜 신호 잡는 검증 체크리스트
- 대시보드 PCW/AI Share 숫자는 "방향성"으로만 본다
Windsurf 자체 가이드도 "directional proxy"라고 못 박았어요. 절대값은 의미 없음. 같은 팀, 같은 도구, 같은 분기 안에서 추세 변화로만 활용하세요. 다른 도구·다른 팀과 절대 비교하지 마세요. - PR 리뷰 시 "디프 레이아웃"부터 본다
AI가 쓴 PR은 보통 건드릴 필요 없는 곳까지 같이 수정되어 있어요(O'Connell 실험의 "100줄 전체가 AI" 같은 패턴). 디프가 비정상적으로 광범위하면 "이 변경의 진짜 의도가 뭔가"를 먼저 묻는 게 신호예요. - 테스트가 너무 깔끔하면 의심한다
METR 연구에 따르면 AI는 "하드코딩된 값으로 통과하는 자기충족적 테스트"를 자주 만들어요. 어서션이 입력값을 그대로 비교하거나, edge case 없이 happy path만 있으면 빨간불이에요. 실패 케이스 한 줄을 추가해서 테스트가 무너지는지 확인하세요. - 중복 코드와 죽은 코드를 자동 감지한다
GitClear 연구가 보여준 4배 증가한 복붙 패턴이 PR에 들어오면 막아야 해요. jscpd, sonarqube duplications, 또는 단순히grep으로 같은 함수 시그니처가 두 곳에 있는지만 확인해도 효과가 큽니다. AI는 기존 코드를 재사용하는 대신 비슷한 걸 새로 쓰는 경향이 강해요. - "AI에게 자기 코드를 디펜드하게 시킨다"
Adam Ferrari가 제안한 검증 패턴이에요. 동일 또는 다른 모델에게 PR 디프를 주고 "이 변경이 왜 필요했나, 어떤 리스크가 있나"를 설명하게 시키세요. 자기 코드도 설명을 못 하면 사람 리뷰어 시간을 아낀 게 아니라 그냥 부채를 미룬 거예요.
매니저용 한 줄 체크
"우리 팀 AI 코드 비율이 X%다"라고 보고가 올라오면 두 질문만 던지세요. ① 이 숫자가 어떻게 계산됐는가(Windsurf PCW인지 Cursor Share인지 자체 정의인지). ② 같은 분기 안에서 PR 사후 수정률·롤백률은 어떻게 변했는가. 두 질문에 답이 안 나오면 그 숫자는 의사결정 근거로 쓰지 마세요.
