코드 라인은 더 나은 홍보 담당자를 얻었다

2 hours ago 1

개발자 생산성 평가는 코드 양보다 고객 가치, 매출, 신뢰성 같은 결과 지표로 판단해야 함
Google, Anthropic, OpenAI, Cursor의 최근 AI 코딩 홍보 수치는 모두 코드 생성 비율이나 코드 라인 수 같은 양적 주장에 집중함
GitHub Copilot의 과거 55% 작업 속도 향상 주장은 검증 가능한 결과였지만, “AI가 작성한 코드 비율”은 개선 여부와 무관하게 커질 수 있음
연구 결과는 단순하지 않으며, Cui et al.은 완료 작업 26% 증가를 보였고 METR은 후속 추정에서 2026년 AI가 개발자를 빠르게 만들 가능성이 있지만 정확한 측정은 어렵다고 봄
AI 도입은 필요하지만 성과 측정은 DORA 지표, 신뢰성, 의미 있는 변경 속도, 매출, 고객 가치처럼 검증된 기준에 기반해야 함

문제의 출발점

한 SaaS 회사의 선임 개발자 두 명 중 한 명이 다른 한 명보다 코드 라인을 40% 더 많이 작성했더라도, 그 개발자가 더 뛰어나거나 비즈니스에 더 큰 영향을 준다고 판단할 수 없음
실제로 중요한 기준은 무엇이 배포됐는지, 고객·매출·신뢰성에 어떤 영향을 줬는지임
코드 라인 수와 PR 수는 개발자 평가에 부적절한 방식으로 오랫동안 학습돼 왔고, 오늘날 이를 평가 기준으로 제안하는 일은 웃음거리가 될 정도임
올해 업계의 대표 홍보 문구는 다시 코드 양 중심으로 돌아왔으며, AI가 작성한 코드 비율이 더 세련된 홍보 문구를 얻은 코드 라인 수에 가까움

올해 전면에 나온 양적 주장

Google은 신규 코드의 75%가 AI 생성이라고 했음
Anthropic은 병합된 프로덕션 코드의 약 80%가 Claude가 작성했고, 엔지니어들이 분기당 “8배 더 많은 코드”를 배포한다고 했음
OpenAI도 약 80% 수준을 언급했음
Cursor는 “하루 1억 줄 이상의 엔터프라이즈 코드 작성”을 내세웠음
이 수치들은 모두 채택과 코드 생성 규모를 강조하며, 모두 어떤 형태로든 AI 벤더와 연결돼 있어 채택 확대가 중요함

예전에는 결과를 주장했음

GitHub의 대표 수치는 Copilot을 사용한 개발자가 작업을 55% 더 빠르게 완료했다는 주장이었음
이 주장은 연구에 대한 비판과 별개로, 가치에 관한 검증 가능한 결과 주장이었음
2026년의 “코드 75%가 AI 작성” 같은 주장은 실제로 참일 수 있고 계속 증가할 수 있지만, 더 빠른 배포, 사고 감소, 고객 만족 증가와 무관하게 성립함
양적 수치는 채택이 멈출 때만 실망을 만들고, 채택 자체는 많은 사람이 실제로 일어나고 있다고 동의하는 영역임
결과적으로 홍보 수치는 더 커졌지만 말하는 내용은 줄어들었음

광고판에 잘 올라가지 않는 부분

AI 도입에 유리한 강한 결과로는 Cui et al.의 연구가 있으며, 거의 5,000명의 개발자에게서 완료 작업 26% 증가와 주니어 개발자에게서 더 큰 효과를 보였음
GitClear는 Copilot 채택이 깊어질수록 코드 변경 churn이 증가하고 리팩터링이 줄어드는 현상을 보였음
METR 연구는 숙련된 오픈소스 개발자가 자기 코드베이스에서 AI 사용 시 19% 느려졌고, 본인은 20% 빨라졌다고 믿는 결과를 냈음
2026년 2월 METR 후속 추정은 속도 향상 쪽으로 뒤집혔지만, 오차 범위가 넓었고 기존 연구 설계를 포기했음
METR의 최신 입장은 2026년 AI가 개발자를 빠르게 만들 가능성이 있으나, 얼마나 빠르게 만드는지는 더 이상 깔끔하게 측정하기 어렵다는 쪽임
기업 수준에서는 NBER의 약 6,000명 임원 설문에서 기업 69%가 AI를 적극 사용했고, 약 10곳 중 9곳은 측정 가능한 생산성 영향이 없었음
여러 연구를 가로지르는 합의는 조직 단위 이득이 약 10% 수준이라는 쪽이며, 이는 유용하지만 개발자가 더 이상 필요 없다는 수준은 아님
여전히 “19% 느림”만 인용하는 회의론도 체리피킹에 해당하며, 연구는 계속 갱신되고 업계는 측정 대상을 바꿨음

AI 맛을 입은 허영 지표

Carnegie Mellon SEI와 Accenture는 AI Adoption Maturity Model을 공개했고, 5개 수준과 8개 차원으로 구성했음
이 모델은 조직의 95%가 수익을 보지 못한다는 통계를 내세워 홍보됐음
Steve Yegge의 “AI 지원 개발 8단계”는 어떤 도구를 쓰고 얼마나 감독하는지로 개발 방식을 구분함
도구 벤더들의 성숙도 사다리는 대체로 채택 강도를 측정하면서 이를 성숙도라고 부르는 구조임
Augment가 219명의 엔지니어링 리더에게 “AI-native engineering” 정의를 물었을 때 219개의 서로 다른 답이 나왔음
Anthropic은 “8배 더 많은 코드 배포” 주장을 내놓았고, 동시에 AI 지원 개발자가 방금 배포한 코드 이해도에서 17% 낮은 점수를 받은 무작위 대조 연구도 냈음
해당 Anthropic 연구에서는 통계적으로 유의미한 생산성 향상이 없었음
Claude 제품은 훌륭하지만, Anthropic의 마케팅은 양을 세고 연구 조직은 더 엄격한 결과를 갱신하는 상황이 동시에 존재함

왜 중요한가

이런 수치는 장식이 아니라 예산, 성과 기대치, 인력 계획을 움직임
2026년 2월 Jack Dorsey는 AI를 핵심 근거로 Block 인력 40% 이상, 4,000명 이상을 감축했음
Block의 발표에는 “우리가 만드는 도구를 사용하는 훨씬 작은 팀이 더 많이, 더 잘할 수 있다”는 문장이 있었음
몇 주 뒤 Atlassian은 10%, 약 1,600명을 감축했고, AI가 필요한 기술 조합이나 역할 수를 바꾸지 않는 척하는 것은 부정직하다고 인정했음
Dorsey는 같은 발표에서 사업이 강하고 총이익이 증가하고 있다고도 말했음
“AI가 모두를 더 생산적으로 만들었으므로 인력이 더 적게 필요하다”는 주장에는 증거가 필요하지만, 현재 그런 증거는 존재한다고 믿기 어려움
실제로 적은 인력으로 같은 일을 할 수 있어 유휴 또는 과소 활용 인력이 생겼다는 증거가 필요함
제품·SaaS 회사에는 끝없는 로드맵이 있으므로, 하룻밤 사이 사실상 인력 증가를 얻었다면 더 빠르게 고객 가치를 전달하는 선택지도 가능함
감원 선택은 MAU, 전환율, 매출로 드러나는 생산성 향상 대신 이미 정해진 결정을 포장하는 PR 역할을 할 수 있음
효율을 위한 감축이 정당하게 일어날 수는 있지만, 그 경우에도 토큰 수나 AI 작성 코드 비율, 성숙도 단계가 아니라 기존 개인 성과 시스템을 활용해야 함
선택 근거가 허영 지표라면 인력 선택은 겉만 그럴듯한 추첨에 가까움