한쪽에서는 AI 도입 이후 코드 중복이 81% 늘고 리팩터링이 70% 줄었다고 말합니다. 반면 같은 주제를 다른 방법으로 분석한 연구는 “전반적인 증가는 없었다”고 말합니다. 전자는 코드 분석 업체의 데이터이고, 후자는 동료 심사를 거친 논문입니다. 어느 쪽을 믿을지가 아니라, 왜 엇갈리는지가 요점입니다.
“AI가 코드 품질을 망친다”는 주장은 지금 한 업체의 데이터에 거의 전적으로 기대고 있습니다. 그 데이터는 규모가 크고 지표도 구체적이지만, 만든 곳은 코드 분석 도구를 파는 회사입니다. 같은 질문을 다룬 동료 심사 논문은 반대 방향의 결과를 냈습니다.
GitClear는 커밋 단위로 코드 변경의 성격을 분류하는 분석 도구를 만드는 회사입니다. 2026년 발표한 보고서에서 2023년부터 2026년까지의 실제 코드 변경 6억 2,300만 건을 분석했다고 밝혔습니다. AI 보조 커밋이 전체의 약 4분의 1을 차지했다고 합니다.
| 지표 | 변화 | 보도가 밝힌 비교 기준 |
|---|---|---|
| 코드 블록 중복 | +81% | “AI 도입 이전 수준” |
| 커밋 내 복사·붙여넣기 | +41% | “AI 도입 이전 수준” |
| 2주 내 재수정 | +15% | “AI 도입 이전 수준” |
| 리팩터링 라인 이동 | −70% | “AI 도입 이전 수준” |
| 오래된 코드 유지보수 | −74% | 2023년 이후 |
| 파일 간 함수 호출 코드 재사용의 대리 지표 | −35% | 보도에 밝혀지지 않음 |
가장 상징적인 수치는 이것입니다 — 2024년은 커밋 안에서 “복사·붙여넣기”가 “이동”을 넘어선 최초의 해였습니다. 코드를 옮겨서 정리하는 것보다 베껴 쓰는 것이 많아졌다는 뜻입니다. 리팩터링이 전체 변경 줄에서 차지하는 비중은 2021년 25%에서 2024년 10% 미만으로 떨어졌습니다.
다만 이 두 수치는 2026년 보고서의 새 결과가 아니라 같은 회사의 이전 조사에서 나온 것을 다시 인용한 것일 가능성이 있습니다. 원문을 열지 못해 어느 쪽인지 구분하지 못했습니다.
같은 회사가 앞서 낸 보고서에 이 글에서 가장 유용한 대목이 있습니다. “AI 사용자가 몇 배 더 생산적이다”라는 흔한 주장이 어떻게 만들어지는지를 자기 데이터로 보여줍니다.
여기서 쓰는 Diff Delta는 GitClear가 자체적으로 만든 지표로, 전체 줄 수가 아니라 의미 있게 변경된 코드의 줄 수를 세어 산출량을 나타냅니다.
매일 AI를 쓰는 개발자의 의미 있는 코드 변경량은 AI를 쓰지 않는 개발자보다 약 4배 많았고, 사용량이 특히 많은 개발자는 4~10배 많았습니다.
일반 AI 사용자 +12%, 사용량이 특히 많은 개발자 +81%. 비사용자는 −2%였고 이는 통계적으로 유의하지 않았습니다.
이 구분은 실무에서 바로 쓸모가 있습니다. 도구 도입 효과를 평가할 때 사용자와 비사용자를 비교하면 안 됩니다. 같은 사람의 도입 전후를 비교해야 합니다. 전자는 4배, 후자는 12%가 나옵니다.
같은 시기에 같은 주제를 다른 방법으로 분석한 연구도 있습니다. Self-Admitted GenAI Usage in Open-Source Software는 IEEE Transactions on Software Engineering에 실린 동료 심사 논문입니다. 저자는 Tao Xiao 외 6인이고, arXiv 최신 개정본은 2026년 4월 5일입니다. (저널 게재일은 arXiv 기록에 나오지 않아 확인하지 못했습니다.)
접근 방식이 다릅니다. 이들은 개발자가 커밋 메시지·주석·문서에 “AI를 썼다”고 스스로 밝힌 경우를 찾았습니다.
결론은 이렇습니다.
같은 단기 재수정률 지표를 두고 벤더는 15% 증가를, 이 논문은 전반적 증가 없음을 보고했습니다.
둘 중 하나가 거짓말을 하고 있다고 볼 필요는 없습니다. 재는 대상이 다릅니다.
| 벤더 조사 | 동료 심사 논문 | |
|---|---|---|
| 표본 | 코드 변경 6억 2,300만 건. 전체 코드베이스의 흐름 | 자가 신고가 있는 저장소 151개. 20만 개 중 극소수 |
| 분석 단위 | 산업 전체의 연도별 추세 집계 | 저장소별로 첫 자가 신고 시점을 도입 시점으로 삼은 전후 비교 |
| 이해관계 | 코드 품질 도구 판매사 | 학술 기관. 심사를 거침 |
| 공개 수준 | 보고서 형태. 원자료·방법론 비공개 | 논문 전문 공개 |
여기서 분석 단위의 차이가 특히 큽니다. 한쪽은 산업 전체의 시간 추세를 보고, 다른 쪽은 저장소마다 도입 시점을 잡아 그 전후를 비교합니다. 같은 지표를 써도 다른 질문에 답하고 있는 셈입니다. 표본의 성격 차이도 결정적입니다. 커밋에 AI 사용 사실을 적는 개발자는 개발 절차와 기록 원칙을 비교적 엄격하게 지키는 쪽일 가능성이 큽니다. 20만 저장소 중 156개만 그렇게 했습니다. 반대로 벤더 데이터는 그런 자가 신고와 무관하게 전체 흐름을 보지만, 무엇을 AI 보조로 분류했는지가 공개되지 않았습니다.
여기부터는 연구 결과가 아니라 제 실무 판단입니다. 두 조사가 엇갈릴 때 남는 선택은 자기 데이터를 보는 것입니다.
git log -L은 지정한 줄 범위 하나를 추적할 뿐 저장소 전체 비율을 계산하지 않고, --find-renames는 파일 이름 변경을 찾는 옵션이지 옮겨진 코드 줄을 세지 않습니다.
그래서 비용 대비 값이 나오는 순서로 적습니다.
| 난이도 | 무엇을 | 어떻게 |
|---|---|---|
| 쉬움 오늘 가능 |
중복 추세 | jscpd나 pmd cpd 같은 복붙 탐지기를 CI에 걸고 값을 기록합니다. 절대값은 설정에 좌우되므로 같은 설정에서의 방향만 봅니다 |
| 쉬움 | 도구 도입 효과 | 같은 사람의 도입 전후를 비교합니다. 사용자와 비사용자를 비교하면, 원래 성과가 높은 사람이 AI를 먼저 쓰기 시작해서 생긴 차이까지 도구의 효과로 잘못 재게 됩니다. 이를 선택 효과라고 합니다. 지표는 무엇이든 좋으니 바꾸지 말고 계속 같은 것을 씁니다 |
| 중간 스크립트 필요 |
단기 재수정 | git log -p 출력을 파싱해, 어떤 줄이 처음 들어온 커밋과 다시 바뀐 커밋의 간격을 세는 스크립트를 씁니다. 정의(며칠 이내, 어떤 줄을 셀지)를 한 번 정하고 고정해야 비교가 됩니다 |
| 어려움 | 리팩터링 비중 | 변경을 “새로 추가·수정·이동·삭제”로 분류해야 합니다. 직접 만들 값은 아니고, 필요하면 상용 도구를 쓰거나 이 지표는 포기하는 편이 낫습니다 |
git log -L과 --find-renames로 잴 수 있다고 썼는데, 그 명령들은 실제로 그 계산을 하지 않아 바로잡았습니다.| 자료 | 내용 | 링크 |
|---|---|---|
| Self-Admitted GenAI Usage in Open-Source Software Tao Xiao 외 6인. IEEE TSE 동료 심사. arXiv v4 2026-04-05 |
저장소 20만+, 자가 신고 1,292건. 151개 저장소 code churn 종단 분석 결과 전반적 증가 없음 | arxiv.org/abs/2507.10422 |
| GitClear — The Maintainability Gap (2026) 벤더 보고서. 원문 직접 확인 못 함 |
코드 변경 6억 2,300만 건. 중복·복붙·churn·리팩터링 지표 | gitclear.com |
| LeadDev — Code maintainability plummets in the AI coding era Bill Doerrfeld, 2026-07-07. 2차 보도 |
위 보고서의 지표를 정리한 기사. 이 글의 벤더 수치는 여기서 확인했습니다 | leaddev.com |
| LeadDev — AI doesn’t create great developers, it amplifies them Bill Doerrfeld, 2026-01-20. 2차 보도 |
Diff Delta 전년 대비 +12% / +81% / −2%, 단면 비교 4~10배, 선택 효과 | leaddev.com |
이 문서는 2026-09-07 기준 공개 자료를 정리한 기술 요약입니다. 벤더 수치는 2차 보도를 거쳐 옮긴 것이므로, 인용하실 일이 있으면 원 보고서를 직접 확인하세요.