AI 버블론의 착각: 생산성은 평균이 아니라 격차로 온다

이 글은 아래 한경 글로벌 마켓 영상을 보고 AI 버블론에 대해 반박하기 위해 작성하였습니다.

영상 출처

AI 버블론에서 가장 설득력 있는 문장은 아래와 같다.

돈은 썼다. 그런데 생산성은 어디 있나.

GPU를 샀다. HBM도 샀다. 데이터센터는 짓고 있다. 전기도 끌어온다. 토큰 비용은 매달 청구된다. 비용은 회계에 찍힌다. 반면 생산성이 안보인다. 거시 통계는 조용하고, 기업들은 AI를 많이 쓴다고 말하지만 그것이 매출과 고객가치로 얼마나 이어지는지는 아직 선명하지 않다.

그래서 회의론자는 말한다.

비용은 확실한데 산출은 안 보인다. 그러니 AI 수요는 FOMO다.

필자는 이 주장에 절반은 동의한다. AI에는 과잉이 있다. 토큰 낭비도 있고, 데이터센터 선점 경쟁도 있다. 모든 요청이 최고급 칩을 필요로 하는 것도 아니다. 일부 데이터센터는 낮은 수익률을 낼 수 있고, 일부 모델 회사는 가격 경쟁에 눌릴 것이다.

하지만 “생산성이 안 보인다”에서 “생산성이 없다”로 바로 뛰어가는 것은 성급하다. 특히 AI가 들어가는 곳이 공장이 아니라 지식노동, 소프트웨어, 서비스 운영이라면 더 그렇다.

AI 생산성은 흙더미처럼 쌓이지 않는다. 대부분 회사 내부의 시간 절감, 외주비 감소, 버그 대응 속도, 실험 횟수, 의사결정 리드타임, 직군 간 핸드오프 감소로 먼저 나타난다. 보이지 않는다고 없는 것은 아니다. 다만 보이지 않는다는 이유만으로 무조건 정당화할 수도 없다.

이 글의 결론은 단순하다.

“생산성이 없다”는 결론은 틀렸다.
AI는 평균을 조금 올리는 도구가 아니라 격차를 벌리는 도구다.

1. 비용은 보이고 산출은 숨어 있다: Dark Output

포크레인의 생산성은 보인다. 흙을 더 많이 판다. 흙은 잴 수 있다. 톤수와 시간이 있다.

AI는 다르다. AI는 리서치, 문서 초안, 코드 리뷰, 회의 준비, 고객응대, 버그 추적, 의사결정 보조로 들어간다. 이것들은 흙처럼 쌓이지 않는다. 가격표가 없으면 통계에도 잘 안 잡힌다.

예전에는 외주 리서치에 200만 원을 냈다. 그 거래는 매출이고 GDP다. 이제 직원이 AI로 30분 만에 초안을 만든다. 회사는 빨라졌고 비용은 줄었다. 그런데 통계에는 외주 매출 200만 원이 사라지고 토큰 비용 몇 천 원만 남는다.

산출이 사라진 것이 아니다. 거래가 사라진 것이다.

이것이 SemiAnalysis가 말한 Dark Output이다. 비용은 GPU, 데이터센터, 전력, 토큰 비용으로 선명하게 보인다. 반면 산출은 회사 내부의 시간 절감, 문서 초안, 코드 리뷰, 회의 준비, 외주 업무의 내부화처럼 가격표 없이 발생한다. 그래서 실제 생산성이 생겼더라도 GDP나 기업 매출 통계에는 늦게 잡히거나 아예 안 잡힐 수 있다.

이 프레임은 변명으로 쓰면 안 된다. “어딘가에 보이지 않는 생산성이 있다”는 말만으로 토큰 비용을 정당화할 수는 없다. 하지만 “통계에 당장 안 보이니 생산성이 없다”는 말도 너무 얕다.

봐야 할 것은 Dark Output을 Visible KPI로 바꾸는 능력이다. 내부 산출이 리드타임, 품질, 비용절감, 고객경험, 매출, 마진으로 연결되는지 봐야 한다.

2. AI 생산성의 본질은 평균이 아니라 격차다

AI 생산성 자료에서 가장 먼저 봐야 할 것은 “모두가 조금씩 빨라진다”가 아니다. 더 중요한 변화는 격차다.

AI는 생산성을 올린다. 다만 똑같이 올리지 않는다. 남이 시켜서 억지로 쓰는 사람, 기존 업무방식을 그대로 둔 채 챗봇만 하나 더 켜는 사람, 회사가 라이선스를 줬으니 가끔 문장 다듬기에 쓰는 사람에게 효과는 작다. 반대로 자기 일을 쪼개고, 자동화하고, 도구를 연결하고, 검증 루프를 만드는 사람에게는 폭발력이 생긴다.

이 차이는 새롭지 않다. 엑셀에서도 그랬다.

사무실에 들어가서 내가 먼저 한 일은 엑셀 매크로와 단축키 세팅이었다. 반복 입력을 줄이고, 보고서 양식을 자동화하고, 자주 쓰는 작업을 한 번에 돌리게 만들었다. 아웃룩도 외부 플러그인과 연동했다. 일정, 메일, 엑셀 파일을 묶어서 관리했다.

옆에 있던 부장이 말했다.

넌 뭐 그렇게 쓸데없는 걸 하냐.

실무자는 안다. 한 번 세팅하면 시간이 계속 줄어든다. 찾는 시간이 줄고, 실수가 줄고, 반복이 사라진다. 그런데 그 부장은 내가 퇴사할 때까지 엑셀을 제대로 할 줄 몰랐다. ERP 시스템도, 메일 연동도, 기본적인 업무 자동화도 제대로 못 쓰는 사람에게는 도구의 가치가 보이지 않는다.

AI도 똑같다. 누군가는 AI로 메일 문장만 고친다. 누군가는 갑자기 자기 직무 밖으로 넘어간다. 프로그래머가 되고, 디자이너가 되고, 리서처가 되고, 데이터 분석가가 된다. 원래 하루에 한두 개 보던 자료를 수십 개, 수백 개까지 훑는다. 같은 AI 계정을 받아도 한쪽은 토큰을 소비하고, 다른 한쪽은 토큰을 자본화한다.

그래서 AI 생산성 논쟁에서 평균만 보면 놓친다. 진짜 변화는 평균의 완만한 상승보다 상위 사용자와 하위 사용자의 벌어지는 간격이다.

NBER 고객지원 연구는 반복 업무에서 생산성 향상을 보여준다. HBS/BCG 연구는 AI가 잘하는 영역에서는 속도와 품질이 같이 오른다는 것을 보여준다. 하지만 더 중요한 것은 AI가 모든 사람에게 같은 효과를 주지 않는다는 점이다. AI가 맞는 업무와 맞지 않는 업무가 있고, AI를 다루는 사람의 역량 차이도 크다.

DORA의 2025 State of AI-assisted Software Development도 이 해석에 가깝다. 전 세계 약 5,000명의 기술 인력 설문과 100시간 이상의 정성 데이터를 바탕으로 AI 도입과 성과 지표의 관계를 분석했다. 응답자의 90%가 업무에 AI를 쓰고, 80% 이상은 생산성이 올랐다고 답했다. 동시에 30%는 AI 생성 코드에 대한 신뢰가 낮다고 답했다.

결과 지표는 더 흥미롭다. DORA는 AI adoption이 individual effectiveness, organizational performance, valuable work, code quality, product performance, software delivery throughput과 양의 관계를 보인다고 제시했다. 하지만 software delivery instability도 같이 올라간다.

이 그래프의 결론은 “AI를 쓰면 무조건 좋아진다”가 아니다. 더 정확히는 이렇다.

AI는 개인과 팀의 속도를 올린다.
그러나 조직이 리뷰, 테스트, 배포, 책임 체계를 따라가지 못하면 그 속도는 불안정성으로 새어 나간다.

즉 생산성은 올라가고 있다. 문제는 그 생산성을 조직이 흡수하느냐다. AI에 맞게 업무를 재설계한 조직은 속도와 품질을 얻고, 그렇지 못한 조직은 더 빠른 혼란을 얻는다.

Claude Code 시대에 더 가까운 자료는 METR의 2026년 transcript analysis다. METR은 2026년 1월 7명의 technical staff가 만든 5,305개의 Claude Code transcript를 분석했다. AI 없이 숙련 엔지니어가 같은 작업을 했다면 얼마나 걸렸을지를 LLM judge로 추정하고, 실제 Claude Code 사용 시간과 비교했다. 결과는 Claude Code-assisted task에서 약 1.5x~13x의 time savings factor였다.

여기서 볼 것은 평균보다 분산이다. 왜 어떤 사람은 1.5배에 가깝고, 어떤 사람은 10배 이상에 가까운 시간 절감을 보이는가. 단순히 Claude Code를 켰느냐의 문제가 아니다. 작업을 잘게 쪼개는 능력, repo 구조를 이해시키는 능력, 테스트와 검증을 설계하는 능력, agent를 병렬로 굴리는 능력, 결과물을 사람이 빠르게 판정하는 능력이 갈라진다.

METR도 이것을 최종 생산성 배수라고 말하지 않는다. productivity multiplier가 아니라 soft upper bound라고 못박았다. 모든 사람이 모든 업무에서 10배 생산성을 낸다는 뜻은 아니다. 하지만 투자 관점에서는 상위 꼬리가 중요하다. AI에 적응한 인재와 팀은 특정 작업에서 10배에 가까운 시간 압축을 반복적으로 만들 수 있다. 시간이 지나면 시장은 그런 사람과 조직을 더 많이 남기고, 그렇지 못한 방식은 줄인다.

결국 비용 효율은 처음부터 회계에 바로 찍히지 않을 수 있다. 먼저 나타나는 것은 사람 간 격차다. 그다음에는 조직 간 격차다. 마지막에는 인력 구성, 외주비, 개발 리드타임, 제품 출시 속도, 마진으로 돌아온다.

AI 생산성 논쟁을 평균 직원의 오늘 생산성만으로 보면 놓친다. 봐야 할 것은 AI-native 인재와 프로세스가 얼마나 빠르게 표준이 되는가다.

3. 사용량 자료는 생산성의 증거가 아니다. 그러나 수요 부재론은 반박한다

사용량 증가만으로 생산성을 증명할 수는 없다. commit 수가 많다고 좋은 코드가 되는 것은 아니다. 토큰을 많이 썼다고 일을 잘한 것도 아니다.

다만 사용량 자료는 다른 주장에는 유용하다. “AI 수요가 없다”, “개발 현장은 별로 쓰지 않는다”는 말과는 맞지 않는다.

SemiAnalysis는 2026년 2월 기준 Claude Code가 public GitHub commit의 약 4%, 하루 약 13.5만 개 commit을 작성한다고 분석했고, 현재 추세라면 2026년 말 daily commit 비중이 20%를 넘을 수 있다고 봤다. 별도 arXiv 연구 Agentic Much도 128,018개 GitHub 프로젝트를 분석해 coding agent adoption을 약 22.20~28.66%로 추정했다.

이 숫자는 “생산성”이 아니라 “침투율”이다. 그래도 의미는 있다. agent가 개발 현장의 commit과 PR 단위로 흔적을 남길 만큼 들어왔다는 뜻이다.

OpenRouter 데이터도 수요의 폭을 보여준다. 아래는 OpenRouter AI Model Rankings 화면이다. 벤치마크가 아니라 OpenRouter를 통해 실제 호출된 모델들의 주간 사용량이다.

중요한 것은 개별 모델 순위가 아니라 전체 모양이다. 2025년 중반부터 2026년 5월까지 weekly usage가 계단식으로 커진다. 색이 여러 개로 쪼개진 것도 중요하다. 수요가 한 모델에만 몰리는 것이 아니라 여러 모델로 분산된다.

정리하면 이렇다. 사용량 자료는 “성과”의 증거가 아니다. 그러나 “수요가 없다”는 말도 설명하지 못한다. 실제 그림은 수요 부재가 아니라 수요의 계층화에 가깝다. 비싼 frontier model, 저가 open model, reasoning model, tool-calling model이 용도별로 갈라지고 있다.

4. AI가 버블이라는 쪽의 사례: 못 쓴 AI는 정말 비용만 남긴다

먼저 회의론자들이 드는 사례부터 봐야 한다.

Microsoft는 Claude Code를 줄였다.
Uber는 AI 비용을 정당화하기 어렵다고 했다.
Amazon은 토큰 사용량 리더보드를 중단했다.
그러니 AI 생산성은 과장된 것 아닌가.

이 반례는 중요하다. AI를 잘못 쓰면 정말 버블이 된다. 계정만 뿌리고, 사용량을 KPI로 삼고, 고객가치와 연결하지 못하면 비용만 남는다. 다만 이 사례들이 말하는 것은 “AI가 무용하다”가 아니라 “AI를 못 쓰면 무용해진다”에 가깝다.

Microsoft: Claude Code가 무용해서가 아니라, 너무 많이 쓰였기 때문

Microsoft가 Claude Code 직접 라이선스를 줄이고 GitHub Copilot CLI 중심으로 표준화하려 했다는 보도는 사실에 가깝다. 하지만 이것을 “Claude Code가 생산성이 없어서 퇴출됐다”고 읽으면 맥락이 빠진다.

보도상 Claude Code는 Microsoft 내부에서 인기가 있었다. 문제는 외부 도구가 너무 많이 쓰이면서 비용, 보안, 제품 전략, 자체 Copilot CLI와의 충돌이 생긴 것이다. Claude 모델 자체를 버린 것도 아니다. Copilot CLI, Microsoft Foundry, Microsoft 365 Copilot 같은 자사 워크플로우 안에서 모델 접근은 계속 가능하다는 맥락이 있다.

이 사례는 AI 수요 부재가 아니다. 외부 AI 도구가 너무 빠르게 확산되자 Microsoft가 그것을 자사 플랫폼 안으로 흡수하고 표준화하려는 사례에 가깝다.

Uber: 손은 빨라졌는데 고객가치 연결이 약하다

Uber 사례도 마찬가지다. Uber에서 Claude Code, Cursor 같은 AI 코딩 도구 사용량과 예산 소진이 빠르게 늘었다. 일부 보도는 내부 생산성이 크게 개선됐다는 취지의 내용도 다뤘다.

문제 제기는 “AI가 아무 효과가 없다”가 아니다. 쟁점은 AI 사용량과 token 소비 증가가 라이더와 드라이버에게 더 유용한 기능 증가로 얼마나 직접 연결되는지 아직 명확하지 않다는 것이다.

개발자의 손이 빨라지는 것과 고객가치가 늘어나는 것은 같은 말이 아니다. 코드를 더 많이 썼는가보다 중요한 질문은 따로 있다.

• 라이더 대기시간이 줄었는가?

• 매칭률이 개선됐는가?

• 취소율이 줄었는가?

• 드라이버 수익성이 개선됐는가?

• 안전 이슈 탐지가 빨라졌는가?

• 고객지원 비용이 줄었는가?

• 기능 출시 리드타임이 줄었는가?

Uber 사례는 AI 생산성 부재가 아니라 개발 생산성과 고객가치 사이의 연결 장치가 필요하다는 사례다.

Amazon: 토큰 사용량은 KPI가 아니다

Amazon의 KiroRank/tokenmaxxing 사례는 더 명확하다. 내부에 token 사용량 리더보드가 있었고, 이것이 “AI를 많이 쓰는 것” 자체를 경쟁하게 만들면서 잘못된 인센티브를 만들 수 있다는 우려가 있었다.

이건 AI 수요가 허구라는 증거가 아니다. token 사용량을 생산성 지표처럼 쓰면 안 된다는 증거다.

토큰은 KPI가 아니다. 토큰은 전기요금에 가깝다.

전기를 많이 쓴 공장이 생산적인 공장인가. 아니다. 중요한 것은 생산된 제품, 불량률, 납기, 원가, 마진이다. AI도 똑같다. 토큰을 많이 썼다는 사실은 “많이 일했다”는 뜻이 아니다. 비효율적으로 루프를 돌았다는 뜻일 수도 있다.

그래서 이 세 사례의 결론은 이것이다.

Microsoft, Uber, Amazon은 AI 버블론자가 들기 좋은 사례다.
하지만 정확히 말하면 AI의 실패가 아니라 AI 운영 방식의 실패다.

기업이 봐야 할 KPI는 token 사용량, AI 라이선스 수, AI 생성 코드 라인 수, AI PR 수, 로그인율이 아니다.

개발조직이라면 이슈 생성부터 머지까지 걸리는 시간, PR 리뷰 대기시간, 배포 빈도, 장애율, 롤백률, 버그 재발률, 고객 기능 출시 속도를 봐야 한다. CS 조직이라면 첫 응답 시간, 평균 처리 시간, 1차 해결률, 재문의율, CSAT, 에스컬레이션 비율을 봐야 한다. 마케팅이라면 소재 제작 단가, 실험 수, 승자 소재 발굴 속도, CAC, 전환율, LTV/CAC를 봐야 한다.

5. 반대편 사례: 국방부가 Anthropic을 빼기 ...