AI 코딩 생산성, 19% 느려진다는 수치가 진짜일까요?

AI 툴을 쓰면 당연히 빨라진다고 생각했는데, 숙련 개발자 대상 무작위 대조 실험 결과는 반대였습니다. AI를 허용했을 때 작업 완료 시간이 오히려 19% 늘어났습니다. 그리고 개발자들은 자신이 20% 빨라졌다고 느꼈습니다. 이 수치 사이의 39포인트 격차가 이 글의 핵심입니다.

실험은 어떻게 설계됐나요?

METR(Model Evaluation & Threat Research)은 2025년 초, 숙련 오픈소스 개발자 16명을 대상으로 무작위 대조 실험(RCT)을 진행했습니다. 참가자들은 평균 스타 수 2만 2천 개 이상, 코드 100만 줄 이상인 대형 오픈소스 프로젝트를 수년간 기여해온 사람들이었습니다. (출처: METR 공식 블로그, 2025.07.10)

실험 방식은 단순합니다. 개발자들이 직접 작업 목록 246개를 제출하면, 각 태스크가 무작위로 “AI 허용” 또는 “AI 금지” 조건에 배정됩니다. AI 허용 조건에서는 Cursor Pro와 Claude 3.5/3.7 Sonnet(당시 프런티어 모델)을 자유롭게 사용했습니다. 시간당 보수는 150달러였고, 화면 녹화로 실제 작업 흐름을 기록했습니다.

이 설계의 핵심은 “자기가 잘 아는 코드베이스”에서 “실제 업무 태스크”를 다뤘다는 점입니다. 평균 작업 시간은 2시간, 버그 수정·기능 추가·리팩토링이 골고루 포함됐습니다. 벤치마크처럼 만들어진 문제가 아니라, 실제 병합 요청(PR)으로 이어지는 진짜 작업이었습니다.

▲ 목차로 돌아가기

수치가 전혀 다른 GitHub Copilot 연구와 무엇이 달랐나

GitHub과 Microsoft가 2023년 발표한 연구에서는 개발자들이 JavaScript HTTP 서버 구현 태스크를 GitHub Copilot 사용 시 55.8% 빠르게 완료했습니다. (출처: Microsoft Research, “The Impact of AI on Developer Productivity”, 2023.02.13) 이 수치가 이후 수많은 블로그·영업 자료에서 “AI 코딩은 55% 빠르다”는 근거로 굳어졌습니다.

결론부터 말하면, 두 연구 모두 틀리지 않았습니다. 새로운 코드를 처음 짤 때는 AI가 강력하고, 이미 잘 아는 복잡한 코드베이스를 유지보수할 때는 AI가 오히려 흐름을 끊는다는 의미입니다. 실제 업무의 대부분이 어느 쪽에 가까운지 생각해보면, 두 수치 중 어느 것이 내 상황에 더 가까운지가 명확해집니다.

▲ 목차로 돌아가기

왜 느려지는데도 빨라졌다고 느낄까요?

실험에서 가장 주목할 만한 부분은 바로 이겁니다. 개발자들은 AI를 사용하기 전 “24% 빨라질 것”이라고 예측했고, 실험을 마친 후에는 “20% 빨라졌다”고 자가 보고했습니다. 실제 측정치는 19% 더 느렸습니다. 예상과 인식 모두 현실과 정반대였습니다.

METR이 제시한 원인 중 가장 설득력 있는 가설은 이렇습니다. AI가 코드를 생성하는 동안 개발자는 기다립니다. 이 “기다리는 시간”은 생산적으로 느껴집니다. 실제로는 AI가 제안한 코드를 검토하고, 맥락에 맞지 않는 부분을 수정하고, 숨어 있는 버그를 잡는 데 추가 시간이 소요됩니다. 그러나 이 시간은 “AI의 잘못”이 아니라 “내 검토”처럼 느껴지기 때문에 생산성 인식에 마이너스로 반영되지 않습니다. (출처: METR RCT 논문 Appendix C.2.7, arxiv.org/abs/2507.09089)

Hacker News 커뮤니티(2026년 3월 기준 활성 스레드)에서 FAANG 현직 개발자들도 비슷한 패턴을 보고했습니다. 대형 코드베이스에서는 AI가 사내 프레임워크나 패턴을 모르기 때문에 제안 코드가 기존 패턴과 어긋나는 경우가 많았고, 수정 비용이 생성 비용보다 크게 나타났습니다.

이 부분이 중요합니다. AI 코딩 툴을 도입했을 때 팀 전체가 “빨라진 것 같다”는 공감대가 형성되는 시점에도, 실제 배포 주기나 PR 병합 시간이 단축됐는지는 별도로 확인해야 한다는 뜻입니다.

▲ 목차로 돌아가기

METR이 2026년 2월에 실험을 바꾼 이유

METR은 2026년 2월 24일, 공식 블로그에서 후속 실험의 설계를 변경한다고 발표했습니다. 이유는 명확합니다. 2025년 8월부터 시작한 2차 실험(개발자 57명, 800개 이상 태스크)에서 심각한 선택 편향이 발생했기 때문입니다. (출처: METR 공식 블로그, metr.org/blog/2026-02-24-uplift-update)

개발자의 30~50%가 “이 태스크는 AI 없이 하기 싫다”는 이유로 아예 제출하지 않았습니다. “AI가 2시간에 끝낼 일인데, AI 금지 조건이면 내가 20시간을 써야 한다”는 인식이 생겨난 것입니다. 한 참여 개발자는 이런 말을 남겼습니다. “걷던 도시를 이제 우버로 다니는데, 다시 걸으라는 게 말이 되냐”(출처: METR 2026.02.24 후속 보고서 개발자 인터뷰 인용)

이 변화가 의미하는 바는 이렇습니다. 2025년 초에는 “AI 없이도 할 수 있지만 AI를 써보는” 개발자들이 실험 대상이었다면, 2025년 말에는 “AI 없이는 아예 시작하지 않는” 개발자들이 주류가 됐다는 뜻입니다. AI 코딩 툴이 생산성을 바꾼 것이 아니라, 개발자가 일하는 방식 자체를 바꿔놓은 것입니다. 이 맥락에서 “느려진다” vs “빨라진다”는 이분법 자체가 이미 낡은 프레임일 수 있습니다.

▲ 목차로 돌아가기

그러면 AI 코딩 툴은 언제 진짜 빠른가요?

솔직히 말하면, METR 연구가 말하는 것과 Hacker News 개발자 커뮤니티가 말하는 것 사이의 간극은 태스크 유형에서 갈립니다. METR 논문 Appendix B는 “우리 연구 결과로 AI가 소프트웨어 개발에서 쓸모없다고 일반화해서는 안 된다”고 명시적으로 경고합니다. (출처: arxiv.org/abs/2507.09089, Appendix B)

막상 써보면 이 두 구간이 한 사람의 하루 안에 모두 존재합니다. 오전엔 디버깅에서 AI로 30분을 아끼고, 오후엔 레거시 모듈 수정에서 AI 제안을 검토하느라 40분을 더 씁니다. 결국 중요한 것은 “AI 생산성”이라는 단일 수치가 아니라, 어떤 종류의 작업에 AI를 붙이고, 어디서는 끊을지를 판단하는 기준입니다.

▲ 목차로 돌아가기

자주 나오는 질문

▲ 목차로 돌아가기

마치며

AI 코딩 생산성 논쟁은 “AI가 좋냐 나쁘냐”가 아니라 “어떤 조건에서 측정했냐”의 싸움입니다. 55% 향상도 사실이고, 19% 저하도 사실입니다. 이 두 수치가 서로 다른 조건을 측정한 것임을 이해하면, 둘 다 내 상황에서 맞게 활용할 수 있습니다.

솔직히 말하면, 개인적으로 가장 흥미로운 부분은 METR의 2차 실험 실패 이유입니다. 개발자들이 AI 없이 태스크를 제출하기를 거부하기 시작했다는 건, AI 코딩 툴이 “선택적 도구”에서 “기본 인프라”로 바뀌었다는 신호입니다. 이 부분이 아직 한국어 콘텐츠에서 거의 다뤄지지 않은 맥락이라고 생각합니다.

METR은 여전히 후속 실험 설계를 개선 중이고, 2026년 이후 데이터를 계속 공개할 예정입니다. 최신 모델(GPT-5.4 Thinking, Claude Opus 4.6, Gemini 3.1 Pro 기준)에서 다시 측정된 수치가 나오면, 이 글의 내용도 달라질 수 있습니다. 지금으로선 “AI가 빠르다”는 주장도, “AI가 느리게 한다”는 주장도 조건 없이는 반쪽짜리입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. METR 공식 블로그 — RCT 결과 원문 (metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
2. METR 공식 블로그 — 2026년 2월 후속 연구 설계 변경 (metr.org/blog/2026-02-24-uplift-update/)
3. arXiv 논문 — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developers (arxiv.org/abs/2507.09089)
4. Microsoft Research — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (microsoft.com/en-us/research/…)
5. DevX Platform — The 55% Productivity Myth (devxplatform.com/blog/the-55-percent-productivity-myth/)