AI 허영 지표의 부상: 코드 라인 수가 생산성 대리 지표로 돌아오는 이유

소프트웨어 엔지니어링 산업은 현재 볼륨 기반 지표, 특히 코드 라인 수(LoC)의 부활을 겪고 있으며, 이는 AI 코딩 어시스턴트의 도입 및 영향을 정당화하기 위한 것이다. 업계는 수십 년 동안 개발자 생산성의 측정 기준으로서 LoC를 멀리했지만, 현재 AI 공급업체와 기술 경영진의 주장은 거의 전적으로 생성된 코드 양에 초점을 맞추고 있다.

볼륨 주장 vs. 결과 주장

현대 AI 생산성 주장은 결과(무엇을 달성했는가)에서 볼륨(얼마나 많이 생산했는가)으로 이동했다. GitHub Copilot과 같은 도구에 대한 초기 주장은 작업 완료 속도에 초점을 맞추었으며, 예를 들어 개발자들이 작업을 55% 더 빠르게 완료했다는 주장이 있었다. 반면 2026년 산업 주장은 AI가 작성한 코드 비율에 초점을 맞추고 있다:

  • Google: 새로운 코드의 75%가 AI 생성이라고 보고한다.
  • Anthropic: 통합된 프로덕션 코드의 약 80%가 Claude에 의해 작성되었으며, 엔지니어들은 분기당 "8배 더 많은 코드"를 배포한다.
  • OpenAI: 마찬가지로 약 80%의 코드가 AI 생성이라고 주장한다.
  • Cursor: 하루에 1억 라인 이상의 엔터프라이즈 코드를 작성한다고 보고한다.

이러한 볼륨 지표는 소프트웨어의 품질, 신뢰성 또는 비즈니스 가치가 향상되는지와 무관하게 증가할 수 있기 때문에 사실상 "허영 지표"이다. AI가 작성한 코드 비율이 높다고 해서 배포 속도가 빨라지거나 사고가 감소하거나 매출이 증가한다는 보장은 없다.

AI 생산성 증거의 복잡성

AI가 생산성에 미치는 실제 영향을 측정하는 것은 복잡하며, 연구 결과는 종종 모순된다. 이러한 일관성 부족이 많은 조직이 단순한 볼륨 카운트로 되돌아가는 이유다.

상충되는 연구 결과

  • Positive Gains: Cui 등(2023)과 같은 일부 연구는 작업 완료율이 26% 증가했으며, 특히 주니어 개발자에게 큰 이득이 있었다고 보고한다.
  • Quality Concerns: GitClear 연구에 따르면 Copilot 도입이 깊어질수록 코드 churn은 증가하고 리팩토링은 급감한다.
  • Performance Paradoxes: METR 연구는 처음에 경험 많은 오픈소스 개발자들이 자신의 코드베이스에서 AI를 사용할 때 19% 느려졌지만, 스스로는 20% 빨라졌다고 믿었다고 밝혔다. 이후 METR은 결과를 수정해 속도 향상이 있다고 제시했지만, 개발자들이 이제 AI 없이는 작업을 거부한다는 점을 들어 정확한 측정이 거의 불가능하다고 지적했다.
  • Organizational Impact: NBER가 약 6,000명의 경영진을 대상으로 한 설문조사에서 69%의 기업이 AI를 사용하고 있음에도 불구하고, 약 90%가 측정 가능한 생산성 영향을 보고하지 않았으며, 조직 차원의 이득은 대략 10% 수준이라는 일반적인 합의가 도출되었다.

이해 격차

볼륨이 증가하더라도 이해도가 감소할 수 있다. Anthropic이 수행한 RCT에서 AI 지원 개발자들은 방금 배포한 코드에 대한 이해도가 17% 낮게 나타났으며, 통계적으로 유의미한 생산성 향상은 없었다.

AI를 인력 감축의 정당화 수단으로 사용

볼륨 기반 지표는 대규모 인원 감축을 정당화하는 데 활용되고 있다. 예를 들어, Jack Dorsey는 2026년 2월 Block의 인력을 40% 이상(4,000명 이상) 감축하면서 AI를 핵심 논제로 제시했으며, AI 도구를 활용하는 소규모 팀이 더 많은 일을 더 잘 할 수 있다고 주장했다. 마찬가지로 Atlassian은 직원의 약 10%를 감축했으며, AI가 요구되는 기술 조합과 역할 수를 변화시킨다고 인정했다.

비평가들은 AI가 실제로 막대한 생산성 향상을 제공한다면 기업은 그 "여유 인력"을 로드맵 가속화와 고객에게 더 큰 가치를 제공하는 데(예: MAU 또는 매출 증가) 활용할 것이며, 단순히 인력을 줄이는 것이 아니라는 점을 지적한다. AI를 해고의 정당화 수단으로 사용하는 것은 생산성 주장이 다른 요인(예: 팬데믹 기간의 과잉 채용이나 투자자 압력)으로 인한 결정의 PR 역할을 하고 있음을 시사한다.

커뮤니티 관점의 종합

코드 라인 수 지표의 복귀에 대한 기술적 논의는 여러 시스템적 위험을 강조한다:

코드의 부채

많은 엔지니어는 코드 라인 수를 자산이 아니라 부채로 보아야 한다고 주장한다. 한 커뮤니티 멤버가 언급했듯이, 목표는 장기 유지 보수 부담을 줄이기 위해 최소한의 코드로 기능을 구현하는 것이다.

“디젤 키보드” 오류

일부는 LLM이 "디젤 동력 키보드"처럼 타이핑 속도는 높이지만 문제 해결 속도는 높이지 못한다고 주장한다. 실제 프로그래밍에서 타이핑 비중이 작기 때문에, 소프트웨어 개발 생명주기(SDLC)에 대한 전체적인 영향은 관료적 레이어와 인간 검토 필요성에 의해 제한된다.

리뷰 병목 현상

AI가 더 많은 코드를 생성함에 따라 인간 검토 과정이 주요 병목이 된다. 위험은 "품질을 양으로 교환"하는 방향으로 전환되는 것으로, 코드 양은 늘어나지만 인간이 실제로 이해하거나 검토하는 코드 비율은 감소한다.

결론: 중요한 것을 측정하기

AI 도구 도입은 현대 개발자에게 실용적인 필수 사항이지만, 도입은 시작점일 뿐 점수판이 아니다. 허영 지표의 함정을 피하려면 조직은 검증된 엔지니어링 지표로 돌아가야 한다:

  • DORA 지표 (배포 빈도, 변경 리드 타임, 변경 실패율, 서비스 복구 시간).
  • 프로덕션 환경의 신뢰성 및 안정성.
  • 의미 있는 변화 비율 (비즈니스 가치를 창출하는 기능).
  • 수익 및 고객 가치 (성공의 궁극적인 측정 기준).

AI 생산성 주장을 평가할 때 핵심 질문은 제공된 지표가 결과(가치의 측정 가능한 개선)인지, 볼륨(생산된 양의 측정)인지이다.

Sources