Shovelware는 어디에? AI 코딩 생산성 주장이 맞지 않는 이유
Where's the shovelware? Why AI coding claims don't add up
TL;DR Highlight
25년차 개발자는 소프트웨어 출시 통계로 AI 코딩 도구의 10배 생산성 향상 주장을 반박하며, AI가 정말 생산성을 획기적으로 높였다면 왜 새 소프트웨어 출시가 증가하지 않았는지 묻는다.
Who Should Read
AI 코딩 도구(Cursor, Copilot, Claude Code 등)를 쓰면서 '정말 빨라진 건가?' 의문을 가진 실무 개발자, 또는 AI-first 전환을 고민하는 엔지니어링 매니저.
Core Mechanics
- METR 연구에서 개발자들이 AI로 20% 빨라졌다고 느꼈지만 실제로는 19% 느려진 것으로 나타남. 개발자 본인이 자기 생산성의 신뢰할 수 없는 관찰자라는 뜻이다.
- 저자가 6주간 동전 던져서 AI vs 수작업으로 작업하고 시간을 측정했더니, AI가 중앙값 기준 21% 느리게 나왔고, 통계적 유의성을 확보하려면 4개월은 더 필요했다. 즉 2x 같은 극적 차이는 없다는 건 확실하다.
- Cursor는 '비범한 생산성', GitHub Copilot은 '보스처럼 위임하라', Google은 25% 빠르다고 주장하고, 개발자 14%는 10x 향상을 체감한다고 답했다. 이런 주장이 경영진의 FOMO를 자극하고 있다.
- 저자의 핵심 논증: AI가 정말 생산성을 폭발적으로 높인다면 Steam 게임, 인디 앱, SaaS 같은 새 소프트웨어 출시가 급증해야 하는데, 실제 출시 통계를 보면 그런 shovelware 홍수는 전혀 보이지 않는다.
- 이런 과장된 주장이 실질적 피해를 만들고 있다. 기업들이 AI-first를 내세워 개발자 채용을 줄이고, 연봉을 깎고, 기존 프로젝트 일정을 원래의 20%로 압축하는 근거로 쓰고 있다.
- 글 작성 시점(2025년 9월) 기준으로 세계적 소프트웨어 출시량 그래프에서 AI 도입 이후 유의미한 증가가 보이지 않는다는 것이 저자가 제시하는 실증 근거다.
- 저자는 AI 코딩의 꿈 자체를 부정하는 게 아니라, 현재 주장되는 수준의 생산성 향상은 데이터로 뒷받침되지 않으며, 이를 근거로 한 경영 의사결정이 위험하다고 경고한다.
Evidence
- 한 개발자는 매니저가 '우리는 AI-first 회사'라며 프로젝트 일정을 원래의 20%로 줄였다고 공유. SVP와 PM들의 AI 광기가 이전에 본 적 없는 수준이라고 함. 현실과 경영진 기대의 괴리가 심각하다는 사례.
- 여러 댓글에서 'AI는 특정 작업에만 극적으로 유용하다'는 중간 입장이 많았음. 새 API 학습, 스캐폴딩 생성, mock 작성, 코드베이스 탐색 같은 작업에서는 확실히 빠르지만, 대규모 기존 코드베이스 수정은 생산성 차이가 없거나 오히려 손해라는 의견.
- 전직 CTO가 '나에겐 무한대 배 생산성 향상'이라고 반론. 현업 코딩을 안 하던 사람이 Claude Code 덕에 다시 큰 시스템을 만들 수 있게 됐다며, 기존 전문 개발자와 비개발자의 체감이 완전히 다르다고 지적.
- 에이전트 코딩이 2025년 4~5월부터 본격적으로 쓸만해졌기 때문에 글의 데이터(3~4월까지)가 너무 이르다는 반론도 있었음. 한 개발자는 에이전트 덕에 몇 주 걸릴 CLI 도구를 하루만에 만들었다고 구체적 사례 제시.
- Paul Krugman의 인터넷 생산성 연구를 인용하며, 인터넷도 등장 후 25년간 생산성 통계에 유의미한 변화를 만들지 못했듯이 AI의 경제적 효과도 2030년대에나 나타날 수 있다는 역사적 관점 제시.
How to Apply
- AI 코딩 도구 도입 효과를 팀에서 측정하고 싶다면, METR 연구 방법론처럼 동전 던지기로 AI/비AI 그룹을 나눠 실제 소요 시간을 기록하라. 체감이 아닌 데이터로 판단해야 자기기만을 피할 수 있다.
- AI 도구를 모든 작업에 일률적으로 쓰지 말고, 효과가 검증된 작업(스캐폴딩, mock 작성, 새 API 탐색, 보일러플레이트 생성)에 집중 투입하고, 복잡한 기존 코드 수정에는 수작업을 병행하라.
- 경영진이 AI 생산성을 근거로 일정을 압축하려 할 때, METR 연구 결과(체감 +20% vs 실제 -19%)와 실제 소프트웨어 출시 통계를 근거로 현실적인 일정 협상에 활용할 수 있다.
- 주니어 개발자가 AI 생성 코드를 무비판적으로 수용하는 문제가 여러 댓글에서 지적됨. 코드 리뷰 시 AI 생성 코드에 대해 스타일 가이드 준수, 기존 라이브러리 활용 여부, PR 크기를 특히 체크하라.
Terminology
관련 논문
LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크
LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.
Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법
Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.
ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?
LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.
MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정
티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.
LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다
13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.
LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개
스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.