AI는 정말 우리를 빠르게 만들었나 — 숙련 개발자가 19% 느려진 이유

TL;DR

2025년 개발자의 84%가 AI 코딩 도구를 쓰지만, AI 정확도에 대한 신뢰는 40% → 29%로 떨어졌습니다 (Stack Overflow 2025, 49,009명).
METR의 무작위 대조 실험(RCT)에서 숙련 오픈소스 개발자는 AI를 쓸 때 오히려 19% 느려졌는데, 본인들은 20% 빨라졌다고 느꼈습니다.
핵심 병목은 모델 성능이 아니라 "거의 맞는데 미묘하게 틀린 코드"(개발자 45%가 최대 불만)를 고치는 시간입니다.
결론은 "AI를 쓰지 말자"가 아니라, 체감 생산성과 실측 생산성의 격차를 인지하고, 검증 비용까지 포함해 도구를 쓰자는 것입니다.

우리는 정말 빨라지고 있을까

AI 코딩 도구를 한동안 쓰다 보면 익숙한 장면이 있습니다. 프롬프트 한 번에 함수가 통째로 나오고, "오, 이거 30분 걸릴 일을 5분 만에 끝냈네" 하는 순간입니다. 그런데 그날 하루를 돌이켜보면 묘하게 일이 덜 끝나 있습니다. 분명 빨랐는데, 결과적으로는 느렸던 것 같은 이 감각. 2025년의 데이터는 이 위화감이 착각이 아니라고 말합니다.

이 글은 개인 무용담이 아니라, 2025~2026년에 공개된 대규모 조사와 통제 실험이 가리키는 한 가지 역설을 정리한 글입니다. 한 줄로 요약하면 이렇습니다. AI 코딩은 빠르게 보급됐지만, 그 효과에 대한 우리의 체감은 데이터와 어긋나 있다.

역설 1 — 쓰는 사람은 늘고, 믿는 사람은 줄었다

Stack Overflow의 2025년 개발자 설문(2025년 5~6월, 166개국 49,009명 응답)은 두 곡선이 정확히 반대로 움직인 해를 보여줍니다.

AI 도구를 쓰거나 쓸 계획인 개발자: 76% → 84%
AI 출력의 정확도를 신뢰하는 비율: 40% → 29%
호감도(favorability): 72% → 60%

특히 인상적인 건 신뢰의 분포입니다. AI 정확도를 적극적으로 불신하는 개발자(46%)가 신뢰하는 개발자(33%)보다 많고, "매우 신뢰한다"는 단 3%였습니다. 즉 도입은 가속하는데 신뢰는 식는, Stack Overflow의 표현 그대로 "쓰긴 쓰지만 마지못해(willing but reluctant)" 쓰는 상태입니다.

왜 신뢰가 떨어졌을까요. 응답자가 꼽은 1위 불만(45%)이 답을 줍니다. "거의 맞는데, 미묘하게 틀린(almost right, but not quite)" 코드입니다. 그리고 66%가 이런 "거의 맞는" 코드를 고치는 데 시간을 더 쓴다고 답했습니다.

이 지점이 핵심입니다. 완전히 틀린 코드는 차라리 쉽습니다. 컴파일이 안 되거나 테스트가 빨갛게 뜨니까요. 무서운 건 그럴듯하게 맞는 코드입니다. 리뷰를 통과할 만큼 자연스럽지만 엣지 케이스 하나가 틀어져 있고, 그걸 찾으려면 결국 코드를 처음부터 끝까지 다시 읽어야 합니다. 생성은 5분, 검증은 40분. 생성 시간만 체감하고 검증 시간은 잊는 것, 이것이 다음 역설로 이어집니다.

역설 2 — 19% 느려졌는데, 20% 빨라졌다고 느낀다

이 역설을 가장 정밀하게 포착한 건 METR의 무작위 대조 실험입니다 (2025-07, arXiv:2507.09089).

설계는 이렇습니다. 평균 5년 이상 자기 프로젝트를 다뤄온 숙련 오픈소스 개발자 16명에게, 익숙한 대형 저장소의 실제 이슈 246개를 풀게 합니다. 각 이슈는 무작위로 AI 사용 허용 / 금지로 나뉩니다 (도구는 주로 Cursor Pro + Claude 3.5/3.7 Sonnet). 그리고 걸린 시간을 잽니다.

결과는 연구진조차 놀랐다고 밝힌 수준이었습니다.

구분	수치
실험 전 개발자 예상	AI로 24% 빨라질 것
실험 후 개발자 체감	20% 빨라졌다
실제 측정	19% 느려짐

예상도 빗나가고, 무엇보다 직접 겪은 뒤의 체감마저 실제와 정반대였습니다. 한 일에 시간이 더 걸렸는데도 본인은 더 빨랐다고 기억합니다. 이게 위험한 이유는, 우리가 도구의 가치를 대부분 체감으로 판단하기 때문입니다. 체감이 실제와 39%포인트나 어긋나 있다면, "AI 도입하니 빨라졌다"는 현장의 증언 상당수는 측정이 아니라 인상일 수 있습니다.

물론 이 연구는 한계가 분명합니다. 표본이 16명이고, _익숙한 대형 저장소_라는 특수 조건입니다. 이미 5년간 손에 익은 코드베이스라면, 머릿속 맥락이 AI보다 빠른 게 어찌 보면 당연합니다. 신규 프로젝트나 낯선 언어였다면 결과는 달랐을 가능성이 높습니다. 그래서 이 데이터는 "AI는 개발자를 느리게 한다"는 일반 명제가 아니라, "숙련자가 익숙한 영역에서는 AI 이득이 우리 생각보다 작거나 마이너스일 수 있다"는 경계 조건으로 읽는 게 정확합니다. (METR도 2026-02 후속 글에서 실험 설계를 보완 중이라고 밝혔지, 결과를 철회하진 않았습니다.)

두 데이터를 겹쳐 보면

Stack Overflow가 "왜 신뢰가 떨어졌나(거의 맞는 코드의 검증 비용)"를 말한다면, METR은 "그 비용이 실제 시간으로 얼마였나(19% 손해)"를 말합니다. 두 조각을 겹치면 그림이 완성됩니다.

AI는 생성(generation)을 극적으로 싸게 만들었지만, 그만큼 검증(verification) 부담을 늘렸다. 그런데 우리 뇌는 생성 시간만 또렷이 기억하고 검증 시간은 흐릿하게 처리한다. 그래서 체감은 부풀고, 실측은 따라오지 않는다.

이건 도구를 버릴 이유가 아니라, 도구를 다르게 쓸 이유입니다.

그래서, 어떻게 쓸 것인가

데이터가 주는 실용적 교훈을 정리하면 이렇습니다.

생성보다 검증을 설계하라. AI가 코드를 5분에 뱉는다면, 병목은 항상 그다음입니다. 테스트가 없는 코드에 AI를 들이미는 건 검증 비용을 미래의 나에게 외상으로 다는 일입니다. AI 활용도가 높을수록 테스트·타입·리뷰 게이트의 가치가 올라갑니다.
"거의 맞는 코드"를 가장 경계하라. 완전히 틀린 출력보다, 그럴듯하게 맞는 출력이 더 비쌉니다. 익숙한 영역일수록 AI 제안을 한 번 더 의심하는 게 합리적입니다 (METR이 가리키는 구간이 정확히 여기입니다).
체감 말고 측정으로 판단하라. "AI 쓰니 빨라진 것 같다"는 가장 신뢰하기 어려운 신호입니다. 팀이라면 도입 전후의 리드타임·재작업률 같은 실제 지표로 검증하길 권합니다. 체감과 실측이 39%포인트까지 벌어질 수 있다는 걸 우리는 이제 압니다.
영역을 구분하라. 낯선 보일러플레이트·일회성 스크립트·탐색에는 AI가 강하고, 5년 묵은 핵심 도메인 로직에서는 이득이 줄거나 역전될 수 있습니다. 한 도구를 모든 작업에 균일하게 쓰는 게 오히려 손해일 수 있습니다.

마치며 · 한계

AI 코딩을 부정하려는 글이 아닙니다. 오히려 84%가 이미 쓰는 흐름은 되돌릴 수 없습니다. 다만 *"빨라진 것 같다"*는 만족감과 _실제로 빨라졌다_는 사실 사이에는 측정 가능한 간극이 있고, 2025년의 데이터는 그 간극이 생각보다 크다고 말합니다. 좋은 도구를 쓰는 것과, 그 도구가 나를 어떻게 바꾸는지 정직하게 보는 것은 별개입니다.

인용 시 주의(한계). METR 연구는 16명·숙련자·익숙한 저장소라는 좁은 조건이라 모든 개발 상황으로 일반화하면 안 됩니다. Stack Overflow 수치는 자기보고 설문입니다. 두 데이터 모두 "신규 개발이나 비숙련자에게도 AI가 느리게 만든다"는 주장의 근거가 아닙니다. 이 글은 그 경계 안에서만 읽혀야 합니다.

참고 자료

Stack Overflow, 2025 Developer Survey — "Developers remain willing but reluctant to use AI" (https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/)
METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), arXiv:2507.09089