• 개발자 생산성 평가는 코드 양보다 고객 가치, 매출, 신뢰성 같은 결과 지표로 판단해야 함
  • Google, Anthropic, OpenAI, Cursor의 최근 AI 코딩 홍보 수치는 모두 코드 생성 비율이나 코드 라인 수 같은 양적 주장에 집중함
  • GitHub Copilot의 과거 55% 작업 속도 향상 주장은 검증 가능한 결과였지만, “AI가 작성한 코드 비율”은 개선 여부와 무관하게 커질 수 있음
  • 실제 연구는 엇갈리며, Cui et al.의 +26% 완료율부터 METR의 "19% 느려짐" 및 이후 번복, 기업 90%가 측정 효과 없다는 조사까지 조직 단위 효과는 약 10% 수준
  • AI 도입은 필요하지만 성과 측정은 DORA 지표, 신뢰성, 의미 있는 변경 속도, 매출, 고객 가치처럼 검증된 기준에 기반해야 함

코드 라인 수 지표의 부활

  • 15년 전 SaaS 기업의 두 시니어 개발자 중 한 명이 다른 한 명보다 40% 더 많은 코드를 작성했다는 사실만으로 더 뛰어난 개발자라 볼 수 없음
  • 실제 중요한 것은 무엇이 출시(ship) 되어 고객·매출·안정성에 기여했는가이며, 코드 라인 수와 PR 개수는 수십 년간 나쁜 측정 방식으로 학습됨
  • 2026년 업계가 내세운 대표 수치는 모두 AI 작성 코드 비율에 집중
  • Google: 신규 코드의 75%를 AI가 생성
  • Anthropic: 병합된 프로덕션 코드의 약 80%를 Claude가 작성, 엔지니어는 분기당 "8배 더 많은 코드"를 배포함
  • OpenAI: 마찬가지로 약 80%
  • Cursor: “하루 1억 줄 이상의 엔터프라이즈 코드 작성”
  • 이들 수치는 전부 양적(volume) 주장이며, "AI가 작성한 코드 비율"은 더 세련된 홍보 문구를 얻은 코드 라인 수에 불과함
  • 해당 기업들이 모두 AI 벤더라는 점에서 채택률 부풀리기가 중요한 동기로 작용

과거에는 성과를 주장했음

  • 몇 년 전 핵심 수치는 규모가 아니라 종류 자체가 달랐음
  • GitHub의 대표 주장은 Copilot 사용 시 작업을 55% 더 빠르게 완료한다는 것
  • 비판이 많았으나 이는 성과(outcome) 주장으로, 대담하고 반증 가능하며 가치에 관한 것 — 틀렸다면 틀렸음을 입증할 수 있음
  • 2026년의 주장은 실패할 수 없는 구조
  • "코드의 75%가 AI 작성"은 더 빠른 배포·장애 감소·고객 만족 등 실제 개선과 무관하게 사실일 수 있고 계속 상승함
  • 볼륨 수치는 채택이 정체될 때만 실망을 주며, 채택이 진짜라는 점에는 대부분 동의함
  • 주장은 커졌으나 말하는 바는 줄어듦

광고판에 오르지 않는 부분

  • 성과 증거가 복잡해진 것이 그 사이 벌어진 일

  • 채택을 지지하는 결과

  • Cui et al.: 약 5,000명 개발자 대상 완료 작업 +26%, 특히 주니어 개발자에서 가장 큰 향상 — 거의 논쟁의 여지 없음

  • 반대 방향의 증거

  • GitClear: Copilot 채택이 깊어질수록 코드 처닝(churn) 증가, 리팩터링 붕괴

  • METR: 숙련된 오픈소스 개발자가 자신의 코드베이스에서 AI 사용 시 19% 더 느려졌으나, 본인은 20% 더 빠르다고 믿음

  • METR의 입장 번복

  • 2026년 2월 METR은 사실상 입장을 철회 — 후속 추정치가 속도 향상(speedup) 으로 뒤집힘(오차 범위는 매우 넓음)

  • 개발자들이 이제 AI 없이 작업하기를 거부하고 에이전트 작업의 소요 시간을 신뢰성 있게 자가 보고하지 못해 연구 설계 자체를 폐기
  • 최신 입장: 2026년 AI가 개발자 속도를 높일 가능성이 크나 그 정도를 깔끔하게 측정할 수 없음

  • 기업 단위 효과

  • NBER의 약 6,000명 임원 조사: 69% 기업이 AI 활용 중, 약 10곳 중 9곳이 측정 가능한 생산성 효과 없다고 보고

  • 교차 연구 합의는 조직 단위 약 10% 향상 수준 — 유용하나 "개발자가 더는 필요 없다"는 수준은 아님
  • 여전히 "19% 느려짐"만 인용하는 회의론자도 체리피킹이며, 연구는 계속 갱신되고 업계는 측정 대상만 바꿈

AI 버전의 허영 지표

  • AI 벤더 주장만의 문제는 아님

  • 성숙도 모델과 사다리

  • Carnegie Mellon SEI와 Accenture가 며칠 전 AI Adoption Maturity Model 출시 — 5단계·8차원, "조직 95%가 수익 없음" 통계를 마케팅에 활용

  • Steve Yegge의 "8 levels of AI-assisted development"는 어떤 도구를 쓰고 얼마나 감독하는지로 순위 매김
  • 모든 도구 벤더가 성숙도 사다리를 출시하며 최상단은 보통 "자사 제품을 더 많이 사용"
  • 이들 사다리는 채택 강도를 측정하면서 성숙도라 부르는, 포장만 다른 동일한 대체

  • 정의의 혼란

  • Augment가 219명 엔지니어링 리더에게 "AI-native engineering" 정의를 물었더니 219개의 서로 다른 답변이 나옴

  • Anthropic의 양면

  • "8배 더 많은 코드 출시" 주장과 동시에 올해 가장 엄밀한 연구 중 하나 제시

  • RCT 결과 AI 지원 개발자가 방금 출시한 코드 이해도에서 17% 낮은 점수, 통계적으로 유의미한 생산성 향상은 없음
  • 연구 부문은 갱신하고 마케팅 부문은 볼륨을 세는, 두 가지가 동시에 참인 상황

이 문제에 주목하는 이유

  • 이 수치들은 장식이 아니라 예산·성과 기대치·인력 계획을 움직임

  • AI를 명분으로 한 감원

  • 2월 Jack Dorsey가 Block 인력의 40% 이상(4,000명+) 감축, AI를 명시적 핵심 논거로 제시 — "더 작은 팀이 우리가 만드는 도구로 더 많이, 더 잘 할 수 있음"

  • 몇 주 뒤 Atlassian이 10%(약 1,600명) 감축, "AI가 필요한 기술 구성이나 역할 수를 바꾸지 않는 척하는 건 솔직하지 못함"이라 인정
  • Dorsey는 같은 발표에서 사업이 견조하고 총이익이 성장 중이라 언급

  • 생산성 주장에 대한 의문

  • "AI로 모두가 더 생산적이 되어 인력이 덜 필요하다"면 그 증거를 보고 싶으나 현재 존재하지 않는다고 봄

  • 인력 일부가 실제 유휴·저활용 상태임을 입증해야 하며, 제품/SaaS 기업은 끝없는 로드맵을 가지므로 늘어난 여력을 고객 가치·속도에 써야 정상 — MAU·전환·매출로 나타나야 함
  • 감원을 택했다는 것은 생산성 주장이 이미 다른 이유(과잉 채용, 투자자 압박)로 내려진 결정의 PR 역할을 한다는 신호
  • 효율성 기반 감축이 정당할 때도 있으나, 그럴 때는 토큰 수나 "AI 작성 코드 비율", 성숙도 사다리 등급이 아니라 이미 운영 중인 개인 성과 시스템을 사용해야 함
  • 선별 근거가 허영 지표라면 그 선별은 "립스틱 바른 복권"에 불과함

결론

  • 반(反)AI가 아니며, 모든 엔지니어가 매일 AI를 사용해야 한다는 입장임
  • AI-first든 AI-proficient든 이름과 무관하게 새 도구와 최신 모델을 호기심 있게 시험하는 일이 필요함
  • 업계는 고급 언어, IDE, 자동완성, 애자일, devops를 흡수해 왔고 늘 옛 시절을 그리는 저항자가 있었으나 결국 합류함
  • 이번에 다른 점은 속도 — "클라우드" 도입은 몇 년 미뤄도 생존했으나 AI는 몇 달뿐일 수 있음
  • AI 도입은 출발선이지 점수판이 아님
  • 엔지니어링 성과 측정법은 이미 알려져 있음 — DORA 지표, 신뢰성, 의미 있는 변경 비율, 궁극적으로 매출과 고객 가치
  • 검증된 방식을 버리고 AI 허영 점수를 택할 이유가 없음
  • 벤더 피칭·임원 리뷰·LinkedIn 피드에서 던질 질문: "그것은 성과인가, 볼륨인가?"
  • 일하는 방식은 AI-first로, 측정하는 방식은 검증된(battle-tested) 방식으로 해야함