--- title: "AI가 쓴 코드 비율? 그냥 줄 수 세기의 새 포장지라는 비판" published: 2026-06-11T12:26:42.000Z canonical: https://jeff.news/article/4044 --- # AI가 쓴 코드 비율? 그냥 줄 수 세기의 새 포장지라는 비판 글쓴이는 ‘신규 코드의 75~80%가 AI가 쓴 코드’ 같은 숫자가 개발 생산성을 보여주는 지표가 아니라고 비판한다. 예전에는 작업 완료 속도나 고객 가치 같은 결과를 말했지만, 지금은 코드량·도구 사용률·성숙도 단계 같은 볼륨 지표가 AI 생산성 논쟁을 덮고 있다는 주장이다. - 글쓴이의 핵심 주장은 간단함. ‘AI가 쓴 코드 비율’은 생산성 지표가 아니라 예전의 줄 수 세기임 - 15년 전에도 코드 줄 수나 PR 개수로 개발자 성과를 재면 웃음거리가 됐음 - 그런데 2026년 AI 업계는 다시 같은 걸 포장만 바꿔서 내세우는 중이라는 비판임 - 실제로 올해 나온 AI 코딩 홍보 숫자는 거의 다 볼륨 지표임 - 구글은 신규 코드의 75%가 AI 생성이라고 말함 - 앤트로픽은 병합된 production code의 약 80%를 Claude가 쓴다고 하고, 엔지니어가 분기당 8배 더 많은 코드를 ship한다고 주장함 - 오픈AI도 약 80%를 언급했고, Cursor는 하루 1억 줄 이상의 엔터프라이즈 코드가 작성된다고 홍보함 - 문제는 이 숫자가 ‘더 좋은 제품이 더 빨리 나왔는가’에는 답하지 않는다는 점임 > [!IMPORTANT] > ‘AI가 코드의 80%를 썼다’는 말은 사실이어도 생산성 향상을 증명하지 못함. 더 빠른 출시, 장애 감소, 고객 만족, 매출 증가 같은 결과로 이어졌는지가 빠져 있기 때문임. - 예전 Copilot 홍보는 그래도 결과 지표에 가까웠음 - GitHub는 개발자가 Copilot으로 작업을 55% 더 빨리 완료했다는 주장을 내세웠음 - 이 연구도 논쟁은 많았지만, 최소한 ‘작업 완료 속도’라는 검증 가능한 결과를 말했음 - 반면 ‘코드의 75%가 AI 작성’은 도입률이 오르기만 하면 계속 좋아 보이는 숫자라 실패하기 어려움 - 연구 결과는 생각보다 훨씬 복잡해졌음 - Cui et al. 연구는 약 5,000명의 개발자를 대상으로 AI 사용 시 완료 작업이 26% 늘었다고 봤고, 특히 주니어 개발자에게 효과가 컸음 - GitClear는 Copilot 도입이 깊어질수록 code churn은 늘고 refactoring은 줄었다고 분석함 - METR의 유명한 연구는 숙련된 오픈소스 개발자가 자기 코드베이스에서 AI를 쓰면 19% 느려졌고, 본인은 20% 빨라졌다고 믿었다고 보고함 - 다만 2026년 2월 METR은 후속 추정에서 속도 향상 쪽으로 뒤집혔고, 개발자들이 AI 없이 일하기를 거부하면서 기존 실험 설계 자체를 접었다고 설명함 - 그래서 ‘AI는 느리다’고 19% 연구만 들고 오는 것도 체리피킹임 - 글쓴이는 AI 반대가 아니라, 최신 연구가 계속 바뀌는데 업계가 측정 대상을 바꿔버렸다고 봄 - NBER의 약 6,000명 임원 설문에서는 기업의 69%가 AI를 적극 사용하지만, 약 10곳 중 9곳은 측정 가능한 생산성 영향이 없다고 답함 - 여러 연구를 뭉뚱그리면 조직 차원의 생산성 향상은 대략 10% 언저리라는 분위기임 - 문제는 이런 숫자가 예산, 성과 기대치, 인력 감축에 실제로 쓰인다는 점임 - Jack Dorsey는 Block 인력의 40% 이상, 4,000명 넘는 직원을 줄이며 AI를 핵심 논리로 들었음 - Atlassian도 약 10%, 1,600명을 줄이면서 AI가 필요한 스킬과 역할 수를 바꾼다고 인정함 - 글쓴이는 회사가 ‘AI 덕분에 더 적은 인원으로 가능하다’고 말하려면, 정말 그만큼 일이 줄었는지 증거를 보여야 한다고 요구함 - 특히 제품 회사라면 ‘남는 생산성’을 해고가 아니라 더 많은 고객 가치로 연결할 수도 있음 - 로드맵이 끝없이 쌓인 SaaS 회사에서 갑자기 공짜 headcount가 생겼다면, 보통은 더 많은 기능과 개선을 ship하는 게 자연스러움 - 그런데 해고를 선택한다면 생산성 주장이 이미 정해진 결정의 PR 문구로 쓰이는 것 아니냐는 의심이 생김 - 과잉 채용, 투자자 압박, 비용 절감 같은 이유가 있었을 수 있는데, 그걸 AI 생산성으로 포장하는 건 별개의 문제임 - 글쓴이의 결론은 ‘AI를 쓰지 말자’가 아님. 오히려 매일 쓰라고 함 - AI-first든 AI-proficient든 이름은 상관없고, 새 도구와 모델을 계속 테스트해야 한다는 입장임 - 클라우드 도입은 몇 년 미뤄도 버틸 수 있었지만, AI는 몇 달만 미뤄도 작업 방식에서 뒤처질 수 있다고 봄 - 다만 도입은 출발선이지 점수판이 아니라는 게 핵심임 - 그래서 다음 vendor pitch나 경영진 리뷰에서 물어볼 질문은 하나임 - ‘이 숫자는 outcome인가, volume인가?’ - 코드 줄, 토큰 수, AI 작성 비율, 성숙도 레벨이 아니라 DORA 지표, 신뢰성, 의미 있는 변경 속도, 고객 가치, 매출로 봐야 한다는 주장임 - AI-first로 일하되, 측정은 검증된 방식으로 하자는 게 글의 마지막 메시지임 --- ## 기술 맥락 - 이 글에서 중요한 건 AI 코딩 도구의 성능 자체보다 측정 단위예요. 코드 생성량은 모델이 일을 많이 한 것처럼 보이게 만들지만, 실제 팀 성과는 장애가 줄었는지, 배포가 빨라졌는지, 고객 문제가 해결됐는지에서 나오거든요. - DORA Metrics가 언급되는 이유도 여기에 있어요. 배포 빈도나 복구 시간은 코드가 사람 손에서 나왔는지 AI에서 나왔는지보다, 시스템이 얼마나 안정적으로 바뀌는지를 보여줘요. AI 도입 효과를 보려면 이런 지표가 같이 움직여야 설득력이 생겨요. - METR 연구가 흔들린 대목도 현실적이에요. 에이전트형 AI 작업은 사람이 직접 타이머를 켜고 끄며 측정하기 어렵고, 개발자도 AI 없이 일하는 조건을 잘 받아들이지 않아요. 도구가 일상화될수록 깔끔한 대조 실험이 어려워지는 거예요. - 그래서 조직에서 필요한 건 ‘AI 사용률 목표’가 아니라 결과 지표와 연결된 실험이에요. 예를 들어 코드 작성 비율이 아니라 특정 팀의 리드타임, 변경 실패율, 온콜 부담, 고객 이슈 해결 시간이 어떻게 바뀌는지를 봐야 해요. ## 핵심 포인트 - 구글, 앤트로픽, 오픈AI, 커서의 AI 코드 비율 주장은 대부분 볼륨 지표임 - Copilot의 55% 빠른 작업 완료처럼 검증 가능한 결과 지표와 성격이 다름 - 연구 결과는 복잡해졌고, 2026년 현재 AI가 개발자를 얼마나 빠르게 만드는지 깔끔하게 측정하기 어려워짐 - AI 도입 자체는 필요하지만 평가는 DORA, 신뢰성, 고객 가치, 매출 같은 결과 지표로 해야 한다는 주장 ## 인사이트 AI 코딩 도구를 쓰느냐 마느냐는 이미 전선이 아니다. 진짜 쟁점은 ‘토큰과 코드 줄 수를 생산성으로 착각한 채 조직 설계와 해고까지 정당화할 것인가’다.