AI를 도입했는데, 왜 더 빨라지지 않을까요?

들어가며 — “다 깔았는데, 왜 안 빨라지죠?”

교육 현장에서 요즘 부쩍 자주 듣는 질문이 있습니다. “AI 도구는 다 도입했고 직원들도 곧잘 쓰는데, 정작 팀 전체가 빨라진 것 같지가 않아요. 뭘 잘못하고 있는 걸까요?”

잘못한 게 아닙니다. 그리고 그 느낌은 착각도 아닙니다. 실제로 한 연구에서 숙련된 개발자들에게 AI 도구를 쥐여 주고 작업 속도를 측정했더니 — 그들은 오히려 19% 느려졌습니다. 더 흥미로운 건, 정작 본인들은 20% 빨라졌다고 느꼈다는 점입니다. 체감과 실측이 정반대로 갈렸어요.

왜 이런 일이 벌어질까요. AI가 무능해서가 아닙니다. 빨라진 자리와, 일의 시간을 쥔 자리가 서로 다르기 때문입니다. 이 글은 그 어긋남을 짚으려고 씁니다.

1. AI가 빠르게 만든 건 ‘실행’이다

먼저 분명히 해둘 게 있습니다. AI는 분명히 무언가를 빠르게 만들었습니다. 코드를 짜고, 초안을 쓰고, 표를 만들고, 자료를 정리하는 일 — 손을 움직여 결과물을 찍어내는 일이 극적으로 빨라졌죠. 어제 세 시간 걸리던 보고서 초안이 십 분 만에 나옵니다. 이건 진짜입니다.

문제는 우리가 그 ‘실행’을 곧 ‘일 전체’라고 착각한다는 데 있습니다. 보고서 한 건을 끝내는 일은 타이핑만이 아닙니다. 그 앞에 무엇을 쓸지 정하는 일(정의)이 있고, 그 뒤에 나온 게 맞는지 보고 다듬고 합의하는 일(검증·정리)이 있습니다. 손으로 찍어내는 건 그 사이의 한 토막일 뿐이에요.

AI는 바로 그 가운데 토막 하나를 빠르게 했습니다. 그게 가장 눈에 띄는 토막이라 “빨라졌다”는 느낌이 강하게 들 뿐입니다.

2. 그런데 실행은 원래 병목이 아니었다

여기서 핵심 질문 하나. 일을 느리게 만든 게 정말 실행이었나요?

대개는 아닙니다. 한 개발자가 이런 말을 했습니다 — “타이핑 속도가 병목이었다면, 우리는 진작 다 같이 타자 학원에 다녔을 것이다.” 정곡입니다. 일이 오래 걸린 건 손이 느려서가 아니라, 무엇을 만들지가 불분명하고, 만든 게 맞는지 확인하는 데 시간이 들기 때문이었습니다. 요구사항을 이해하고, 빠진 걸 되묻고, 결과를 검토하고, 관련된 사람들과 합의하는 일 — 일의 시간은 거의 다 거기서 녹습니다.

AI는 실행 한 칸을 줄였을 뿐입니다. 정의와 검증이 그대로면 전체 시간은 거의 줄지 않아요 — '빨라졌다'는 실행 칸만 본 착시입니다.

그래서 실행이라는 한 칸을 아무리 짧게 줄여도, 정의와 검증이 그대로면 전체 시간은 별로 줄지 않습니다. 도식의 두 막대가 그것입니다 — 실행 칸만 보면 71% 빨라졌지만, 막대 전체 길이는 거의 그대로예요. “우리 팀이 안 빨라진 것 같다”는 느낌은 정확합니다. 빨라진 건 실행 칸이고, 그 칸은 애초에 일의 시간을 별로 쥐고 있지 않았으니까요.

3. 실행이 싸지면, 병목은 오히려 더 두꺼워진다

더 까다로운 일도 벌어집니다. 실행이 거의 공짜가 되면, 사람은 더 많이 만듭니다. 초안을 하나 뽑던 자리에서 다섯 개를 뽑고, 코드를 한 번 짜던 자리에서 열 번 시도합니다. 만드는 건 싸졌으니까요.

그런데 그 늘어난 결과물을 읽고, 이해하고, 검증하는 일은 싸지지 않았습니다. 오히려 양이 늘어난 만큼 더 무거워졌어요. 누군가는 이걸 ‘이해 부채’라고 부릅니다 — AI가 사람이 이해하는 속도보다 훨씬 빠르게 만들어내니, 결과물은 쌓이는데 그게 무슨 일을 하는지 아는 사람은 따라가지 못하는 상태입니다.

그래서 역설이 생깁니다. 실행을 싸게 만들수록, 검증이라는 병목은 더 두꺼워질 수 있습니다. 손은 빨라졌는데 머리가 처리할 양은 늘어난 거죠. 체감은 “빠르다”인데 전체는 그대로거나 오히려 막히는 이유가 여기 있습니다.

4. 빨라지려면, 더 빨리 돌리는 게 아니다

그러니 처방은 “AI를 더 많이, 더 빨리 돌리자”가 아닙니다. 그건 이미 빠른 칸을 더 빠르게 하려는 것이고, 일의 시간을 쥔 칸은 손도 안 댄 겁니다. 진짜 빨라지려면 병목인 두 칸 — 정의와 검증 — 을 잡아야 합니다.

정의를 또렷이 하면, AI가 헛것을 만드는 횟수가 줄어듭니다. 무엇을 원하는지 흐릿한 채로 던지면 AI는 다섯 번 헤매고, 그 다섯 개를 다시 골라내는 건 사람 몫입니다. 무엇을 만들지 먼저 정하는 일이 곧 실행의 헛걸음을 줄이는 일이에요.
검증을 눈에 맞추면, 확인이 빨라집니다. 긴 답을 끝까지 읽는 대신 결과를 표·그림으로 바꿔 한눈에 검토하면, 빈칸과 튀는 값이 눈에 먼저 걸립니다. 검증이 빨라지는 만큼 전체가 빨라집니다.

요컨대 빨라지는 길은 실행을 더 빠르게가 아니라, 정의와 검증이라는 병목을 좁히는 것입니다. 그리고 그 둘은 도구가 대신해 주지 않습니다. 사람이 하는 일이에요.

5. 빨라진 자리를 착각하지 않기

“AI를 도입하면 빨라진다”는 말이 틀린 건 아닙니다. 다만 어디가 빨라지는지를 착각하면, 도입하고도 “왜 그대로지?” 하며 헤매게 됩니다. AI가 빠르게 한 건 손(실행)입니다. 일을 가르는 머리(무엇을 할지 정하고, 맞는지 판단하는 일)는 여전히 사람 몫이고요.

그래서 AI를 깔고 나서 던질 질문은 “어떻게 하면 더 빨리 돌릴까”가 아니라, “우리 일에서 시간을 진짜로 먹는 칸이 어디인가, 그 칸을 우리는 손대고 있나”입니다. 대개 그 칸은 실행이 아니라, 일을 또렷이 정의하고 결과를 제대로 검증하는 자리에 있습니다.

저는 그래서 도구 사용법을 더 가르치는 대신, 늘 그 두 칸을 봅니다. 빨라지는 건 거기서 시작하니까요. 도구는 손을 거들 뿐, 일을 바꾸는 건 결국 일하는 방식입니다.

출처

METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (숙련 개발자가 AI로 실측 19% 느려졌으나 체감은 20% 빨라졌다고 응답한 무작위 대조 연구)
Frederick Van Brabant — I don’t think AI will make your processes go faster (병목은 코드 작성 속도가 아니라 요구사항 이해라는 현장 논점, Hacker News 상위 토론)
O’Reilly Radar — Comprehension Debt: The Hidden Cost of AI-Generated Code (‘이해 부채’ — 생성 속도가 사람의 이해·검증 용량을 앞지르는 병목)

수치와 사례는 위 출처에 근거하며, 해석과 현장 관점은 박상훈의 견해입니다.