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
관련 논문
2,000명이 내 AI 어시스턴트를 해킹하려 한 뒤 벌어진 일
실제로 6,000개 이상의 이메일로 AI 에이전트에 prompt injection 공격을 시도한 공개 실험 결과로, Claude Opus 4.6이 비밀 파일 유출을 한 번도 허용하지 않았지만 실험 설계의 현실성에 대한 논란이 뜨거웠다.
언제 LLM을 조합하면 효과가 있나? 67개 Frontier 모델에서 Routing, Voting, Mixture-of-Agents의 Co-Failure Ceiling 분석
여러 LLM을 조합해도 '모든 모델이 동시에 틀리는 비율(β)'이 성능 상한선이며, 업계가 쓰는 pairwise 상관계수(ρ)는 이 상한선을 예측하지 못한다.
Function Calling을 넘어서: Tool-Environment 신뢰성 문제 하에서의 Tool-Using Agent 벤치마크
실제 환경처럼 API가 망가지거나 결과가 이상할 때 LLM 에이전트가 얼마나 잘 버티는지 측정하는 벤치마크 ToolBench-X 공개.
LG 스마트 TV 앱의 절반 가까이에 Residential Proxy SDK가 심어져 있다
6,038개의 LG·Samsung 스마트 TV 앱을 스캔했더니 2,058개에서 사용자의 IP를 몰래 팔아 트래픽을 중계하는 Residential Proxy SDK가 발견됐다. TV는 컴퓨터처럼 감시받지 않아서 프록시 호스트로 거의 이상적인 환경이다.
Prompt Injection의 본질은 Role Confusion이다
LLM이 시스템 프롬프트, 사용자 입력, 툴 출력을 구분하지 못하는 구조적 결함이 prompt injection의 근본 원인이라는 ICML 2026 논문으로, 현재 LLM 보안 아키텍처의 한계를 명확히 분석한다.
GPT-5.5의 환각(Hallucination) 비율이 MIT 라이선스 GLM-5.2보다 3배 높다
모델 크기가 커질수록 성능이 좋아진다는 통념에 반해, 오픈소스 753B 모델 GLM-5.2가 추정 1~2T 규모의 GPT-5.5보다 환각 비율이 3배 낮다는 벤치마크 결과가 나왔다. 단순히 파라미터 수와 벤치마크 점수만으로 모델을 선택하면 실제 업무에서 낭패를 볼 수 있다는 경고다.