AI가 나를 19% 느리게 만들었는데, 나는 20% 빨라졌다고 믿었다 — METR RCT가 흔든 생산성 통념

2025년, 한 실험이 개발 생산성 담론의 바닥을 흔들었다. 참가자들은 실험 전에 "AI를 쓰면 24% 빨라질 것"이라고 예측했다. 실험이 끝난 뒤에는 "실제로 20%쯤 빨라진 것 같다"고 답했다. 그런데 초시계가 기록한 진실은 반대였다. AI를 허용한 조건에서 그들은 작업을 끝내는 데 19% 더 오래 걸렸다.

예측도 틀렸고, 사후 체감도 틀렸다. 두 번 틀렸는데 방향이 같았다. 이 대칭이 이 글의 진짜 주제다. "AI가 개발자를 빠르게 한다"는 명제는 대부분 체감에 기대어 산다. 자동완성이 코드를 대신 타이핑해 주고, 막힌 함수가 한 번에 채워질 때의 그 즉각적 쾌감이 그것이다. 문제는 이 쾌감이 실제 완료 속도와 반드시 같은 방향은 아니라는 점이다. 가장 엄밀한 실측이 그 어긋남을 드러냈고, 더 무서운 건 개발자 자신이 어긋남을 인지조차 못 한다는 사실이다.

데이터 — 서베이가 아니라 RCT다

METR의 2025년 연구는 자기보고 설문이 아니라 무작위 대조 실험(RCT, Randomized Controlled Trial — 조건을 무작위 배정해 인과를 재는 실험 설계)이다. 이 방법론적 무게가 핵심이다. 평균 22,000개의 star, 100만 줄 이상 규모의 대형 오픈소스 저장소를 관리하는 숙련 개발자 16명이, 자신의 실제 이슈 246건을 AI 허용/금지로 무작위 배정받아 처리했다. 도구는 당시 프런티어였던 Cursor Pro와 Claude 3.5/3.7 Sonnet. 결과는 AI 허용 시 완료 시간 +19%였다.

이것만으로도 통념과 충돌하지만, 진짜 균열은 인지 지표에서 벌어졌다. 사전 예측 −24%(단축), 실측 +19%(지연), 사후 인식 −20%(단축). 세 숫자가 그리는 궤적이 이 연구를 특별하게 만든다.

여기서 흔한 반박 하나를 미리 막아두자. "16명은 표본이 작다"는 지적이다. 맞다. 하지만 이 연구가 잰 것은 여론이 아니라 각 개발자가 자기 저장소에서 처리한 246건의 실제 소요 시간이다. 개인이 자기 자신과 겨루는 피험자 내(within-subject) 설계라 개인차 노이즈가 상당 부분 상쇄되고, 무엇보다 자기보고가 아니라 초시계다. 표본 수의 약점은 있어도, "체감과 실측의 방향이 반대였다"는 관찰 자체는 표본 크기로 쉽게 뒤집히지 않는다.

왜 이런 괴리가 생기나

다이어그램 설명. 세 시점의 숫자를 나란히 놓으면 왜곡의 구조가 보인다. "실험 전 예측"과 "실험 후 체감"은 서로 손을 잡고 있고, 오직 초시계가 잰 "실측 결과"만 반대편에 서 있다. 개발자의 머릿속에서 "AI를 켜면 빨라진다"는 믿음은 실험 전후로 일관되게 유지됐다. 코드가 즉시 채워지는 순간의 만족감은 강렬하고 셀 수 있게 느껴지는 반면, AI가 뱉은 코드를 읽고 의심하고 고치는 데 흘러간 시간은 흐릿하게 배경으로 가라앉는다. 그래서 체감은 생성의 쾌감만 계상하고, 검증의 비용은 장부에서 누락한다.

이 누락된 항목에 DORA(Google의 소프트웨어 딜리버리 연구 조직)는 이름을 붙였다. 2025년 보고서는 AI를 "증폭기"라 부른다. 팀을 고쳐주는 게 아니라 이미 있는 것을 증폭할 뿐이라는 것이다. 개발자가 코드 작성에서 아낀 시간은 사라지지 않고 검증과 감독으로 재배분된다. Stack Overflow 2025 설문이 이 재배분의 실체를 보여준다. AI 도입률은 84%에 달하지만 정확도를 불신하는 비율(46%)이 신뢰하는 비율(33%)을 앞선다. 가장 큰 불만은 66%가 꼽은 "거의 맞지만 완전히 틀린" 답이고, 45%는 AI가 만든 코드를 디버깅하는 데 오히려 시간이 더 든다고 답했다. "거의 맞음"은 무해하지 않다. 완전히 틀린 답은 즉시 버려지지만, 미묘하게 틀린 답은 검증의 함정으로 끌고 들어간다. 그럴듯한 코드일수록 의심의 문턱을 넘기 어렵고, 결함이 리뷰를 통과해 나중에 더 비싼 값으로 되돌아온다. 절약처럼 보였던 처음의 몇 분이 실은 뒤로 미뤄둔 청구서였던 셈이다.

반론 — 그렇다면 왜 다른 연구는 +26%인가

정직하려면 반대 데이터를 세워야 한다. GitHub Copilot의 대규모 현장 연구(약 5,000명)는 주간 완료 태스크가 +26% 늘었다고 보고한다. 같은 도구 범주가 한쪽에선 −19%, 다른 쪽에선 +26%를 냈다면, 둘 중 하나가 틀린 게 아니라 측정한 세계가 다른 것이다.

다이어그램 설명. 같은 도구가 두 갈래로 갈라지는 지점은 대상과 태스크의 성격이다. "숙련 소수" 갈래는 자신이 100만 줄을 훤히 꿰고 있는 개발자의 세계다. 여기서 병목은 타이핑이 아니라 판단이다. 코드베이스에는 문서화되지 않은 관례와 암묵적 제약이 촘촘하게 깔려 있고, AI가 내놓는 그럴듯한 제안은 이 맥락을 자주 위반한다. 그래서 제안을 맥락에 맞게 되돌리는 비용이 절약분을 삼킨다. "신참 다수" 갈래는 익숙지 않은 작업을 다루는 세계다. 여기서 병목은 정말로 타이핑과 탐색이었고, AI는 그 병목을 정확히 겨눈다. "AI가 생산성을 올린다"는 명제는 참도 거짓도 아니라, 어느 갈래에 서 있느냐에 따라 부호가 바뀌는 조건문이다.

정리 — 성숙한 질문은 "어떤 조건에서"다

METR조차 자기 연구를 절대화하지 말라고 말한다. 2026년 2월 기준 실험 설계를 수정 중이며, 결론은 "숙련자가 성숙 코드베이스에서" 겪은 현상이라는 조건을 달고 읽어야 한다. 그러니 단일 숫자를 새 통념으로 삼는 건 옛 통념을 반복하는 짓이다.

남길 것은 숫자가 아니라 습관이다. 첫째, 생산성 체감을 데이터로 착각하지 않는다. 빨라진 느낌과 빨라진 사실은 별개이며, RCT는 그 둘이 정반대일 수 있음을 보였다. 둘째, 아낀 시간을 검증 비용으로 되갚고 있는지 자문한다. 코드 작성이 줄어든 만큼 검증에 시간이 새고 있다면 순이득은 환상이다. 셋째, "우리 맥락은 어느 갈래인가"를 먼저 묻는다. 성숙하고 관례가 촘촘한 코드베이스인지, 정형화된 새 작업인지에 따라 답이 갈린다. AI 생산성 논쟁의 성숙한 질문은 "AI가 빠르게 하는가"가 아니라 "어떤 조건에서 빠르게 하는가"이다.

---

참고한 공개 자료:

• Measuring the impact of early-2025 AI on experienced open-source developer productivity — METR (https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
• METR RCT 논문 원문 — arXiv (https://arxiv.org/abs/2507.09089)
• AI 보조가 생산성을 낮추는 조건의 후속 분석 — arXiv (https://arxiv.org/pdf/2510.10165)
• Balancing AI tensions — DORA (https://dora.dev/insights/balancing-ai-tensions/)
• Stack Overflow Developer Survey 2025: AI (https://survey.stackoverflow.co/2025/ai/)
• On METR's AI coding RCT — Zvi Mowshowitz (https://thezvi.substack.com/p/on-metrs-ai-coding-rct)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.