-
AI의 ROI 역설 — 더 빨리 만드는 게 매출의 병목은 아니었다IT 2026. 7. 22. 22:00
개인적으로 AI를 일에 들이면서 가장 먼저 체감한 건 "코드가 빨리 나온다"였다. 기능 하나 붙이는 데 걸리던 시간이 눈에 띄게 줄었다. 그런데 한참 뒤에야 이상한 지점을 깨달았다. 빨리 만든다고 해서 그만큼 성과가 늘지는 않았다는 점이다.
이건 나 혼자만의 착시가 아니었다. 미국 애틀랜타 연방준비은행 조사에 따르면 기업의 구성원 1인당 AI 지출은 1년 새 약 50% 늘어, 2025년 연 1,358달러에서 2026년 2,068달러로 뛰었다. 가장 공격적인 상위 10% 기업은 구성원 한 명에게 매달 600달러 넘게 쓴다. 그런데 정작 매출은 그만큼 따라오지 않았다. MIT의 한 연구 조직이 펴낸 2025년 기업 AI 현황 보고서는, 기업이 돌린 생성형 AI 파일럿의 약 95%가 손익에 잡히는 ROI를 내지 못했다고 짚었다. 여기서 ROI(Return on Investment)는 쓴 돈이 얼마나 성과로 돌아왔는가를 뜻한다. 생성형 AI(글·코드·이미지를 스스로 만들어 내는 AI)에 들어간 돈은 전 세계 기준 수백억 달러인데, 장부상 이익으로 잡힌 건 극소수였다.
생산성은 늘었는데 매출은 왜 제자리인가
같은 보고서가 던지는 핵심은, 개인 단위 생산성 향상은 진짜라는 것이다. 글 쓰는 사람, 디자이너, 개발자 모두 도구를 쥐면 분명히 더 빨리 일한다. 문제는 그 개인의 이득이 조직의 이익으로 잘 이어지지 않는다는 데 있다. 도구가 맥락을 기억하지 못하고 업무 흐름에 녹아들지 못해서, AI가 "일하는 방식을 바꾸는 도구"가 아니라 "개인 작업을 거드는 도구"에 머문다는 진단이다.
개발자는 더 빨리 만들었지만, 더 빨리 만드는 것이 애초에 성과를 가로막던 지점이 아니었다. 그러니 그 지점을 아무리 빠르게 해도 전체 결과는 거의 움직이지 않았다.
병목은 '기능 속도'가 아니었다
생산관리에는 병목(bottleneck)이라는 개념이 있다. 전체 처리량은 라인에서 가장 느린 한 곳이 결정한다는 발상이다. 제약 이론(Theory of Constraints)이라고도 부른다 — 가장 느린 한 곳이 전체를 묶고 있으니, 거기가 아닌 곳을 아무리 빠르게 해도 전체 산출은 늘지 않는다는 이야기다. AI를 개발에 쏟아부은 많은 경우가 바로 이 함정에 빠졌다.
다이어그램 설명. "매출 성장"이라는 목표는 두 갈래에 동시에 기댄다. 한쪽은 "개발 — 기능 추가 속도"이고, 다른 한쪽은 "방향·마케팅·영업 — 시장 니즈 해결"이다. 대부분의 AI 투자는 "개발" 갈래로 몰려 그쪽을 더 빠르게 만들었다. 그런데 "방향·마케팅·영업" 갈래는 "낡은 워크플로우 그대로" 남았다. 두 갈래가 합쳐져 매출이 되는데, 묶여 있던 쪽이 그대로이니 "전체 매출은 정체"로 모인다. 핵심은 빠르지 않던 쪽이 진짜 제약이었다는 것이다 — 이미 빠른 쪽을 더 빠르게 해도 전체는 늘지 않는다. 이 그림만 보고 "그럼 양쪽 다 AI를 넣으면 되지 않나"로 넘어가기 쉬운데, 묶여 있던 갈래는 도구 속도가 아니라 일하는 방식 자체가 문제라 단순히 도구를 얹는 것으로는 풀리지 않는다.
막힌 곳은 따로 있었다 — 방향·마케팅·영업
같은 보고서에서 또 하나 눈에 띈 대목이 있다. 생성형 AI 예산의 절반 이상이 영업·마케팅 쪽 도구에 쓰였는데, 정작 가장 큰 ROI는 백오피스 자동화에서 나왔다는 것이다. 외주 업무 대행(BPO, 업무를 외부 업체에 맡겨 처리하는 방식)을 줄이고 대행사 비용을 깎는 데서 효과가 컸다. 돈은 보이는 앞단에 몰렸는데 성과는 보이지 않는 뒷단에서 났다는 뜻이다.
매출을 진짜로 묶고 있던 건 "기능을 얼마나 빨리 추가하느냐"가 아니라, 방향을 제대로 잡고 마케팅과 영업이 시장의 니즈를 실제로 푸는 일이었다. 그런데 이 영역은 여전히 낡은 워크플로우에 갇혀 있다. 개발은 도구를 바꾸면 곧장 빨라지는 게 눈에 보이니 손대기 쉽지만, 방향과 시장 접근은 무엇을 어떻게 바꿔야 할지부터 막막해 개혁이 엄두가 안 난다. 그래서 가장 쉽고 측정 가능한 개발 쪽에만 AI가 쌓인다.
못 더하면 빼는 쪽으로 — 냉정한 현실
여기서 흐름이 차갑게 꺾인다. AI로 이익을 더하지 못하면, 조직은 비용을 빼서 이익을 만들려 한다. "적어도 같은 일을 더 적은 사람이 할 수 있다"가 확인되는 순간 감원으로 흐른다. 더하기가 막히니 빼기로 손익을 맞추는 셈이다.
그런데 데이터는 이 선택마저 미덥지 않다고 말한다. 컨설팅 기업 가트너가 2026년 5월 내놓은 조사를 보면, 연매출 10억 달러가 넘는 기업의 임원 350명 가운데 80%가 AI 도입과 연결된 인력 감축을 단행했고, 일부는 인원의 20%까지 줄였다. 하지만 가장 많이 자른 기업과 가장 적게 자른 기업의 재무 수익률은 거의 같았고, 덜 자른 쪽이 오히려 더 나은 경우도 있었다. 조사를 이끈 분석가는 "감원만으로 가치를 쫓으면 대개 제한적인 수익에 그친다"고 정리했다. 감원은 손익을 한 번 맞춰 줄 수는 있어도, 묶여 있던 진짜 제약을 풀어 주지는 않는다는 이야기다.
AX의 목적을 다시 잡는다
그래서 나는 개인 AX(AI Transformation, 일하는 방식을 AI 중심으로 다시 짜는 전환)의 목적을 바꿔 잡기로 했다. 처음 AI를 들일 때 내 목표는 "개발 생산성"이었다. 더 빨리, 더 많이 만드는 것이었다. 하지만 빨리 만드는 건 이미 내 병목이 아니었다.
목적을 "방향성과 워크플로우 재편"으로 옮기면 질문이 달라진다. 무엇을 빨리 만들까가 아니라, 애초에 무엇을 만들어야 시장의 니즈가 풀리는가를 먼저 묻게 된다. 그리고 그동안 손대기 막막해서 미뤄 둔 영역 — 방향을 잡고, 시장에 닿고, 낡은 절차를 다시 설계하는 그 영역에 AI를 들이는 게 진짜 과제가 된다. 거기가 묶여 있던 곳이기 때문이다.
AI로 더 빨리 만드는 일은 즐겁고 눈에도 잘 띈다. 하지만 즐겁고 잘 보이는 곳이 꼭 막힌 곳은 아니다. 도구를 어디에 얹을지 정하기 전에, 무엇이 나를 묶고 있는지부터 정직하게 보는 것 — 그게 ROI 역설에서 내가 건진 한 줄이다.
참고한 공개 자료:
- MIT report: 95% of generative AI pilots at companies are failing — Fortune: https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
- State of AI in Business 2025 (MIT NANDA) 요약: https://www.aigl.blog/state-of-ai-in-business-2025/
- The GenAI Divide: Why 95% of investors see no ROI — Ignitec: https://www.ignitec.com/insights/the-genai-divide-why-95-of-investors-see-no-roi/
- AI automation layoffs failing to generate returns, Gartner study — Fortune: https://fortune.com/2026/05/11/ai-automation-layoffs-gartner-study-roi/
- AI workforce cuts fail to boost returns, Gartner study finds — NJBIZ: https://njbiz.com/ai-workforce-cuts-gartner-returns-study/
- AI Spending Per Employee benchmark (Atlanta Fed) — Rize: https://rize.io/blog/ai-spending-per-employee-benchmark
- The most AI-obsessed companies spend $7,500 per employee per month — The Next Web: https://thenextweb.com/news/ai-pilled-firms-7500-per-employee-spending
- Rethinking Dev Productivity in 2026: Beyond Velocity: https://www.ai-infra-link.com/why-developer-productivity-beats-velocity-as-the-key-performance-metric/
이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.
'IT' 카테고리의 다른 글
봇은 대화를 어떻게 기억하나 — OpenClaw는 격리로, Hermes는 통합검색으로 (0) 2026.07.24 봇을 안 죽게 만드는 두 갈래 — OpenClaw는 프로세스 하나로, Hermes는 감독관을 세워 (0) 2026.07.24 '관리만 하던 시니어'의 종말 — 다시 실무로 내려온 그의 팀원은 에이전트다 (0) 2026.07.23 사용자가 AI라면, 가위 손잡이부터 다시 깎는다 (0) 2026.07.23 AI를 깔아도 AI-native가 아닌 이유 — 회사를 'AI가 읽고 쓸 수 있는' 형태로 다시 세우기 (1) 2026.07.22 전기 모터가 공장에 들어왔을 때 — AI는 도구가 아니라 일하는 방식을 바꿀 때 효과가 난다 (0) 2026.07.22 검증은 작업한 본인이 아니라 맥락을 모르는 새 비판자에게 맡겨라 (0) 2026.07.21 AI가 다 만들면 나는 뭘 하나 — 좋은 검증 레이어를 만드는 사람 (0) 2026.07.21 'A급 코드'를 원했던 진짜 이유 — 우리는 코드가 아니라 머릿속 공간을 지키고 있었다 (0) 2026.07.21 AI 결과물을 믿게 만드는 검증 3종 — 이진·정량·정성, 그리고 운영 중 검증 (0) 2026.07.20