Skip to content
←

Split View: AI는 정말 개발자를 빠르게 만드는가 — 측정된 숫자들이 말하는 것

|

AI는 정말 개발자를 빠르게 만드는가 — 측정된 숫자들이 말하는 것

들어가며 — 서로 다른 두 개의 숫자

AI 코딩 도구가 생산성을 얼마나 올리는지에 대해, 우리는 잘 설계된 무작위 대조 실험(RCT)을 두 개 가지고 있습니다. 그리고 둘은 정반대의 답을 내놓았습니다.

하나는 AI를 쓴 개발자가 55.8% 더 빨랐다고 말합니다. 다른 하나는 19% 더 느렸다고 말합니다.

그리고 여기에 반전이 하나 더 있습니다. 뒤의 숫자는 더 이상 "현재"가 아닙니다 — 그 숫자를 만든 연구팀이 직접 그렇게 말했습니다. 19% 슬로다운을 측정한 METR은 2026년 2월 후속 연구를 발표하면서, 2025년 결과 위에 경고 배너를 달았습니다. "These results are out of date"(이 결과는 유효 기간이 지났다)는 것, 그리고 이것이 "no longer reflect the current impact of AI models"(현재 AI 모델의 영향을 더 이상 반영하지 않는다)는 것입니다.

그러니 이 글이 서 있는 자리부터 정리하겠습니다. 19%는 틀린 숫자가 아니라 과거의 숫자입니다. 2025년 상반기에 실제로 측정된 값이고, 그 시점의 기록으로는 여전히 유효합니다. 다만 그것을 "지금 AI를 쓰면 19% 느려진다"로 읽는 것은 오독입니다. METR 본인들이 그렇게 읽지 말라고 배너까지 달아 두었습니다.

흔한 반응은 둘 중 하나를 고르는 것입니다. 낙관론자는 앞의 숫자를 인용하고, 회의론자는 뒤의 숫자를 인용합니다. 하지만 둘 다 진짜 실험이고, 둘 다 진짜 결과입니다. 흥미로운 질문은 "누가 맞는가"가 아니라 "무엇이 둘을 갈랐는가", 그리고 이제 하나가 더 붙습니다 — "왜 이걸 제대로 재는 게 이토록 어려운가."

미리 말해두면, 이 글에서 가장 중요한 발견은 19%라는 슬로다운 자체가 아닙니다. 애초에 아니었고, METR이 그 숫자에 유효 기간을 붙인 지금은 더더욱 아닙니다. 가장 중요한 것은 자기 인식이 틀렸다는 것 입니다. 그리고 그 발견에는 배너가 붙지 않았습니다. 앞서 LLM 번아웃에 관한 글에서 생성은 싸졌지만 검증은 그대로라는 이야기를 했는데, 이번에는 그 비대칭이 실제로 측정된 데이터에서 어떻게 나타나는지 봅니다.

실험 하나 — 55.8% 빨라졌다

2023년, Peng, Kalliamvakou, Cihon, Demirer는 GitHub Copilot을 두고 통제 실험을 했습니다. 전문 개발자 95명을 모아 절반에게만 Copilot을 주고, 모두에게 같은 과제를 냈습니다. 자바스크립트로 HTTP 서버를 최대한 빨리 구현하라.

Copilot을 받은 그룹은 대조군보다 55.8% 빨리 끝냈습니다. 그리고 이득은 고르게 퍼지지 않았습니다. 경력이 짧은 개발자, 나이가 많은 개발자, 업무 부담이 큰 개발자에게서 효과가 더 크게 나타났습니다. 논문 저자들은 이것을 AI가 소프트웨어 개발로 진입하는 사람들을 도울 수 있다는 신호로 읽었습니다.

이 숫자는 지금도 자주 인용됩니다. 그런데 인용될 때 거의 언제나 빠지는 게 있습니다. 이 실험의 과제가 어떤 종류였는지 말입니다.

  • 그린필드입니다. 기존 코드베이스가 없습니다. 얽힐 레거시도, 깨질 호출자도 없습니다.
  • 자기완결적입니다. 과제 하나가 통째로 머릿속에 들어옵니다.
  • 명세가 명확합니다. "HTTP 서버"는 무엇이 정답인지 다툴 여지가 거의 없습니다.
  • 검증이 싸구려입니다. 서버가 뜨고 응답하면 끝입니다. 몇 초면 확인됩니다.
  • 측정한 것은 속도이지 품질이 아닙니다. 6개월 뒤 그 코드를 누가 유지보수하는지는 실험 범위 밖입니다.

즉 이 55.8%는 거짓말이 아니라, 매우 특정한 조건에서 참인 숫자입니다. 문제는 대부분의 실무 개발자가 하루의 대부분을 그 조건 바깥에서 보낸다는 데 있습니다.

실험 둘 — 2025년 초, 19% 느려졌다

2025년, METR(Becker, Rush, Barnes, Rein)은 정확히 그 바깥쪽을 측정했습니다. 논문 제목은 "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"입니다. 제목에 Early-2025가 박혀 있다는 점을 기억해 두세요. 나중에 중요해집니다.

설계는 이렇습니다. 숙련된 오픈소스 개발자 16명이, 자기가 관리하는 저장소에서 나온 진짜 이슈 246개를 가져옵니다. 각 이슈는 무작위로 "AI 사용 허용" 또는 "AI 사용 금지"에 배정됩니다. 개발자들은 Cursor Pro와 Claude 3.5/3.7 Sonnet을 주로 썼고, 실험은 2025년 2월부터 6월까지 진행됐습니다.

여기서 결정적인 것은 개발자와 코드베이스의 관계입니다.

  • 저장소는 평균 10년 이상 된 성숙한 프로젝트로, 100만 줄이 넘고 별이 2만 개를 넘습니다.
  • 개발자들은 그 저장소에서 평균 5년을 일했고, 커밋이 평균 1,500개 쌓여 있습니다.
  • 즉 이들은 그 코드에 대해 문서화되지 않은 암묵지를 잔뜩 들고 있는 사람들입니다.

결과는 AI를 허용했을 때 완료 시간이 19% 늘어났다는 것이었습니다. 느려진 겁니다. 저자들의 표현을 빌리면 "allowing AI actually increases completion time by 19%" — AI 도구가 개발자를 느리게 만들었습니다. 신뢰구간은 **+2%에서 +39%**로, 0을 포함하지 않았습니다. 통계적으로도 방향이 분명한 결과였다는 뜻입니다.

이 문단의 동사가 전부 과거형인 데는 이유가 있습니다. 이것은 2025년 2월부터 6월까지의 세계에 대한 측정입니다. 그리고 그 세계는 그 뒤로 바뀌었습니다.

그 뒤에 벌어진 일 — METR의 2026년 후속 연구

2026년 2월 24일, METR은 같은 실험을 이어 돌린 결과를 발표했습니다. 제목은 "We are Changing our Developer Productivity Experiment Design"입니다. 그리고 같은 시점에, 2025년 논문 위에 경고 배너가 올라갔습니다. 연구팀이 자기 대표 논문의 헤드라인 숫자를 스스로 내리는 일은 흔치 않습니다. 그러니 새 숫자를 그대로 보겠습니다.

  • 기존 참가자(returning developers) — 스피드업 -18%, 신뢰구간 -38% ~ +9%
  • 새로 모집한 참가자(newly-recruited developers) — 스피드업 -4%, 신뢰구간 -15% ~ +9%

여기서 두 가지를 동시에 읽어야 합니다.

첫째, 점추정값은 여전히 마이너스입니다. 2026년 초의 도구로도, 이 세팅에서 측정된 평균은 여전히 "빨라졌다"가 아닙니다. 그러니 이 갱신은 "알고 보니 AI가 개발자를 빠르게 해준다"는 이야기가 아닙니다. 그렇게 읽는 것은 원래의 오독을 반대 방향으로 되풀이하는 것입니다.

둘째, 그런데 두 신뢰구간이 모두 0을 가로지릅니다. 2025년의 +2% ~ +39%와 달리, 2026년 수치는 슬로다운과 스피드업을 양쪽 다 품고 있습니다. 통계적으로 부호를 확정할 수 없다는 뜻입니다. 2025년에는 "느려졌다"고 단언할 수 있었지만, 2026년 데이터로는 그렇게 말할 수 없습니다.

그런데 숫자보다 더 중요한 것이 있습니다. METR이 함께 보고한 자기선택 편향입니다.

이런 실험을 하려면 개발자에게 "이 작업은 AI 없이 하세요"라고 시켜야 합니다. 그런데 2026년이 되자, 그걸 거부하는 사람이 늘었습니다. METR의 표현으로는, 연구 참여를 포기하는 개발자가 유의미하게 늘었고 그 이유가 "because they do not wish to work without AI"(AI 없이 일하고 싶지 않아서)였습니다. 참가한 사람들 안에서도 마찬가지였습니다. 개발자의 30~50% 가 일부 작업을 아예 제출하지 않았다고 METR에 말했는데, 이유는 "they did not want to do them without AI"(그 작업을 AI 없이 하고 싶지 않았기 때문에)였습니다.

왜 치명적인지 보이시나요. AI 없이 하기 싫은 작업이란, 곧 AI가 가장 크게 도움이 될 것 같은 작업입니다. 바로 그런 작업들이 표본에서 조직적으로 빠져나갑니다. METR 스스로 이 편향의 방향을 명시합니다 — 이것이 AI 스피드업 추정치를 아래쪽으로 끌어내린다는 것입니다("likely biases downwards our estimate of AI-assisted speedup").

그러니 2026년의 -18%와 -4%는 그 자체로 "AI가 사람을 느리게 만든다"의 증거가 아닙니다. 그것은 AI 없이 일하기를 거부하지 않은 사람들이, AI 없이 해도 괜찮다고 스스로 판단한 작업들에서 나온 값입니다.

그래서 METR은 무엇이라고 결론지었을까요. 그들은 2025년 초의 추정치와 비교해 지금 개발자들이 AI로 더 빨라졌을 가능성이 높다고 봅니다("developers are more sped up from AI tools now"). 그러나 곧바로 단서를 답니다 — 실험의 선택 효과 때문에 "our data is only very weak evidence for the size of this increase"(우리 데이터는 그 증가폭에 대해 매우 약한 증거일 뿐이다).

이것이 현재 우리가 가진 최선의 답입니다. 아마 나아졌을 것이다. 얼마나인지는 우리도 모른다. 이 문제를 세상에서 가장 진지하게 측정하고 있는 팀이, 두 번째 시도를 마치고 내놓은 결론이 이것입니다. 기억해 두세요. 이 글의 마지막에서 다시 쓰게 됩니다.

진짜 발견 — 인식과 실제의 간극

19%는 이제 과거형입니다. 그런데 2025년 연구에는 배너가 붙지 않은 발견이 하나 더 있습니다. 그리고 이 글의 조언이 실제로 딛고 서 있는 것은 그쪽입니다.

  • 실험 전에 개발자들은 AI가 자신을 24% 빠르게 해줄 거라고 예측했습니다.
  • 실험을 다 마치고 나서, 그러니까 실제로 19% 느려지는 경험을 온몸으로 겪은 뒤에, 그들은 자신이 20% 빨라졌다고 추정했습니다.
  • 참고로 경제학 전문가들은 39% 단축을, 머신러닝 전문가들은 38% 단축을 예측했습니다. 모두 방향부터 틀렸습니다.

이건 예측이 틀렸다는 이야기가 아닙니다. 사후 회고조차 틀렸다는 이야기입니다. 자기가 방금 한 일에 대해, 스톱워치와 정반대 방향으로 기억한 것입니다. 약 40퍼센트포인트짜리 간극이 인식과 측정 사이에 벌어져 있었습니다.

왜 이런 일이 생길까요. 그럴듯한 설명은 이렇습니다. 생성은 눈에 보이고 검증은 눈에 보이지 않기 때문입니다.

모델이 3초 만에 40줄을 뱉어내는 순간은 강렬하고 기억에 남습니다. 그 40줄을 읽고, 전제를 의심하고, 이 저장소의 규칙에 맞는지 대조하고, 절반을 버리는 20분은 기억에 남지 않습니다. 그건 그냥 "일하는 중"처럼 느껴집니다. 우리는 도파민이 튀는 순간을 기준으로 하루를 채점하고, 조용히 갈려 나간 시간은 장부에 적지 않습니다.

METR 데이터는 이 해석을 뒷받침합니다. 개발자들은 AI가 생성한 코드의 44% 미만만 받아들였습니다. 나머지는 읽고, 판단하고, 버리는 데 시간을 쓴 것입니다 — 아무 산출물도 남기지 않은 채로요. 그리고 참가자 중 실제로 AI로 빨라진 사람은 약 4분의 1뿐이었습니다.

여기서 한 번 더 강조해 둡니다. 이 발견에는 유효 기간 배너가 붙지 않았습니다. METR이 지났다고 말한 것은 스피드업의 크기이지, 사람이 자기 스피드업을 얼마나 못 읽는지가 아닙니다. 도구는 한 세대가 지났지만, 그 도구를 쓰는 사람의 자기 계측 능력이 그 사이에 좋아졌다는 증거는 어디에도 없습니다.

무엇이 두 실험을 갈랐는가

두 실험의 차이를 한 문장으로 줄이면 이렇습니다. AI는 당신이 갖지 못한 맥락을 대신 채울 때 이기고, 당신이 이미 가진 맥락을 따라잡아야 할 때 집니다.

Copilot 실험의 참가자는 빈 화면 앞에 있었습니다. 모델이 채워 넣는 모든 것이 순이득입니다. METR 실험의 참가자는 5년치 암묵지를 이미 머릿속에 들고 있었습니다. 모델은 그 맥락을 모르고, 알려주려면 프롬프트를 써야 하고, 그렇게 받은 결과를 다시 그 암묵지에 비추어 검사해야 합니다. 맥락이 풍부한 사람일수록 모델을 따라잡게 만드는 비용이 커집니다.

METR 저자들이 짚은 가장 날카로운 대목이 이것입니다. 2025년 실험에서 개발자들은 자신이 더 익숙한 이슈에서 더 많이 느려졌습니다. 익숙함이 방패가 아니라 오히려 세금이 된 것입니다.

2026년 데이터도 이 방향과 어긋나지는 않습니다. 자기 저장소를 오래 지켜 온 기존 참가자는 -18%였고, 새로 합류한 참가자는 -4%였습니다. 익숙한 쪽이 더 크게 느려진 셈입니다. 다만 두 신뢰구간이 크게 겹치므로 이것을 증거라고 부르면 과합니다. 가설과 어긋나지 않는다, 딱 그 정도로만 적어 둡니다.

그래서 실무에서 쓸 수 있는 축은 두 개입니다. 익숙함과 검증 비용.

  • 낯선 영역 + 검증이 쌈 — AI가 가장 확실하게 이기는 칸입니다. 처음 쓰는 언어, 낯선 API, 일회성 스크립트, 스캐폴딩. 틀리면 바로 티가 나고, 당신이 몰랐던 것을 모델이 채워 줍니다. 마음껏 쓰세요.
  • 익숙한 영역 + 검증이 쌈 — 보일러플레이트, 반복 패턴. 이득이 작지만 손해도 작습니다. 무난합니다.
  • 익숙한 영역 + 검증이 비쌈 — METR의 칸입니다. 미묘한 로직, 오래된 코드의 불변식, 당신만 아는 함정. 그냥 직접 쓰는 게 빠를 수 있습니다.
  • 낯선 영역 + 검증이 비쌈 — 가장 위험한 칸입니다. 이해하지 못하는 것은 리뷰할 수 없습니다. 여기서 AI 출력은 조용히 기술 부채가 되고, 대개 몇 달 뒤에 청구서가 옵니다. 이 칸에 있다면 도구를 바꿀 게 아니라 먼저 그 영역을 배워야 합니다.

이 네 칸은 여전히 쓸 만한 지도입니다. 다만 이제는 이렇게 덧붙여야 합니다. 이건 가설이지 측정된 법칙이 아닙니다. 그러니 당신의 칸이 어디인지는 당신이 직접 재서 확인해야 합니다.

조직 단위로 보면 — DORA와 스택오버플로

개인 수준의 착시가 조직 수준에서는 어떻게 나타날까요. 2025년 DORA 보고서(State of AI-assisted Software Development)가 기술 전문가 약 5,000명을 조사했습니다.

채택률은 사실상 끝났습니다. 개발자의 약 90% 가 AI를 쓰고, 80% 이상 이 생산성이 올랐다고 답합니다. 그리고 DORA는 AI가 처리량(throughput)을 실제로 늘린다고 봤습니다 — 여기까지는 낙관적입니다.

문제는 같은 보고서가 AI가 불안정성(instability)도 함께 늘린다고 말한다는 점입니다. 코드가 더 많이, 더 빨리 만들어지면, 그 하류의 약한 고리가 그대로 드러납니다. 자동화된 테스트, 성숙한 버전 관리, 빠른 피드백 루프 같은 통제 장치가 없으면 변경량 증가는 곧장 불안정으로 이어집니다.

DORA의 결론은 그래서 "AI는 증폭기" 입니다. AI는 조직의 기존 강점과 약점을 함께 키웁니다. 좋은 엔지니어링 시스템 위에 얹으면 성과가 커지고, 망가진 시스템 위에 얹으면 낮은 품질의 결과물을 더 빨리 찍어낼 뿐입니다. 속도만 있고 안정성이 없으면 그건 그냥 가속된 혼돈입니다.

스택오버플로 2025년 개발자 설문(응답자 약 4만 9천 명)은 여기에 마지막 조각을 얹습니다. 사용률과 신뢰도가 반대 방향으로 움직이고 있습니다.

  • AI 도구를 쓰거나 쓸 계획인 응답자는 84% — 전년 76%에서 늘었습니다.
  • 그런데 AI 출력의 정확성을 불신한다는 응답이 46% 로, 신뢰한다는 응답 33% 보다 많습니다.
  • "매우 신뢰한다"는 응답은 3.1% 에 불과합니다.
  • 가장 큰 불만은 66% 가 꼽은 "거의 맞지만 완전히 맞지는 않은 답" 입니다. 두 번째는 45% 가 꼽은 "AI가 만든 코드를 디버깅하는 게 더 오래 걸린다" 입니다.

"거의 맞지만 완전히 맞지는 않은" — 이게 이 글 전체를 관통하는 표현입니다. 명백히 틀린 코드는 싸게 걸러집니다. 비싼 것은 믿고 싶어질 만큼 그럴듯하고, 대가를 치를 만큼 틀린 코드입니다. 그리고 그것을 걸러내는 노동은 아무 대시보드에도 잡히지 않습니다.

그래서 무엇을 할 것인가

이 데이터가 "AI를 쓰지 마라"는 뜻은 아닙니다. 실제로 할 수 있는 일은 따로 있습니다.

1. 느낌을 믿지 말고 자기 일을 직접 재세요. 이 연구의 교훈은 회고가 틀린다는 것이므로, 회고 말고 기록이 필요합니다. 그리고 METR의 2026년 후속 연구는 이 조언을 약화시키기는커녕 강화합니다 — 전담 연구팀이 무작위 대조 실험을 두 번 돌리고도 부호를 확정하지 못했다면, 하루를 마친 당신의 인상은 더더욱 확정할 수 없습니다. 도구는 거창할 필요 없습니다. 작업을 시작하기 전에 예상 소요 시간을 한 줄 적고, 끝난 뒤에 실제 시간과 AI 사용 여부를 적으세요. 2주만 모아도 어떤 설문보다 당신에게 정확합니다. 측정되지 않은 생산성 향상은 그냥 기분입니다.

2. 익숙함과 검증 비용으로 작업을 골라 쓰세요. 위의 네 칸을 기준으로 삼으면 됩니다. 낯설고 검증이 싼 일에는 아낌없이, 익숙하고 검증이 비싼 일에는 인색하게. 그리고 낯설면서 검증이 비싼 일에는 도구보다 학습을 먼저 넣으세요.

3. 리뷰를 일급 업무로 예산에 넣으세요. 생성이 공짜에 가까워질수록 병목은 전부 검증으로 옮겨 갑니다. 리뷰를 "진짜 일이 끝난 뒤의 잡무"로 취급하는 한, 늘어난 비용은 계속 장부 밖에 남습니다. 이 부분은 LLM 번아웃 글에서 더 자세히 다뤘습니다.

4. 벤더가 주는 숫자를 벤치마크처럼 대하세요. 즉, 회의적으로요. 55.8%가 어떤 과제에서 나온 숫자였는지 기억한다면, 다음번 마케팅 자료의 숫자에도 같은 질문을 던지게 됩니다 — 어떤 과제였고, 누가 측정했고, 무엇이 빠졌는가. 그리고 이제 질문이 하나 늘었습니다. 언제 측정한 숫자인가. 평가 숫자가 어떻게 흔들리는지는 코딩 평가의 신호와 잡음에서 다뤘습니다.

5. 사람이 읽을 수 있게 쓰세요. 검증이 병목이라면, 읽기 쉬운 코드는 이제 취향이 아니라 처리량 문제입니다. AI가 유지보수해도 사람을 위해 쓴다에서 이야기한 그대로입니다.

숫자를 읽을 때의 정직한 주의사항

이 글의 논지가 "연구가 AI는 쓸모없다고 증명했다"로 읽히면 안 되므로, 양쪽의 한계를 분명히 적어 둡니다.

METR 2025년 연구의 한계. 참가자는 16명입니다. 작습니다. 특정 세팅(대규모 성숙 오픈소스 저장소, 고숙련 유지보수자) 하나를 측정했을 뿐입니다. 참가자의 56%는 Cursor를 써 본 적이 없었고, 모델은 2025년 상반기 것입니다 — 지금 기준으로는 한 세대 이상 지난 도구입니다. 저자들 스스로 이 결과가 다음을 보여주지 않는다고 명시했습니다. AI가 대부분의 개발자를 못 빠르게 한다는 것, 다른 도메인에서도 그렇다는 것, 가까운 미래의 AI도 같은 세팅에서 실패하리라는 것, 그리고 기존 AI를 더 잘 쓰는 방법이 없다는 것. 이 네 가지는 이 연구의 주장이 아닙니다. 그리고 이제는 저자들이 여기에 유효 기간 경고까지 붙였습니다.

METR 2026년 후속 연구의 한계. 어떤 의미로는 더 심각합니다. 자기선택 편향이 실험의 뼈대를 갉아먹고 있습니다. AI 없이 일하기를 거부하는 개발자가 늘수록, 남아서 측정되는 것은 점점 더 "AI 없이 해도 괜찮은 작업"으로 편향됩니다. METR이 이 편향의 방향(추정치를 아래로 끌어내림)을 명시한 것은 정직하지만, 방향을 안다고 크기를 아는 것은 아닙니다. 그래서 2026년 수치는 더 넓은 신뢰구간과 더 약한 결론을 달고 나옵니다. 그리고 이 문제는 시간이 갈수록 나아지는 게 아니라 나빠집니다. AI가 유용해질수록, AI 없는 대조군을 구하기가 어려워지기 때문입니다. METR이 후속 글의 제목을 아예 "실험 설계를 바꾸겠다"로 잡은 이유가 여기에 있습니다.

Copilot 연구의 한계. 과제가 하나이고, 그린필드이며, 자기완결적입니다. 측정한 것은 완료 시간이지 코드 품질도 유지보수성도 아닙니다. 연구에 GitHub 소속 저자가 참여했다는 점도 기록해 둘 만합니다.

DORA와 스택오버플로의 한계. 둘 다 자기보고 설문입니다. 그리고 METR이 알려준 바로 그 이유 때문에, 자기보고는 정확히 이 주제에서 가장 믿기 어려운 도구입니다.

그러니 정직한 결론은 "AI는 당신을 느리게 만든다"가 아닙니다. 정직한 결론은 세 문장입니다. 효과는 맥락에 따라 부호까지 바뀐다. 그 부호는 잘 설계된 무작위 실험으로도 깨끗하게 읽히지 않는다. 그리고 당신의 감각으로는 더더욱 읽히지 않는다.

마치며

우리는 보통 도구에 대해 "좋은가 나쁜가"를 묻습니다. 이 데이터가 말하는 건, 그게 잘못된 질문이라는 것입니다. 같은 도구가 한 실험에서는 55.8% 이득을, 다른 실험에서는 19% 손해를 냈습니다. 도구는 그대로였고, 바뀐 것은 일의 종류와 그 일을 하는 사람의 맥락이었습니다.

그리고 그 위에 한 겹이 더 있습니다. 19%라는 숫자마저 이제 "지금"이 아니라 "그때"의 값이 되었습니다. 그 숫자를 만든 사람들이 직접 그렇게 표시했습니다. 후속 실험은 부호를 확정하지 못했고, 그 이유는 데이터가 모자라서가 아니라 AI 없이 일하기를 거부하는 사람들 때문에 깨끗한 대조군 자체가 사라지고 있기 때문입니다.

여기서 겸손해질 수도 있고, 반대로 결론을 더 세게 쥘 수도 있습니다. 저는 후자라고 생각합니다. 생각해 보세요. 전담 연구팀이, 무작위 대조 실험을 설계하고, 실제 저장소에서 수백 개의 진짜 이슈를 모으고, 두 번을 시도했습니다. 그러고도 내놓은 결론이 "아마 나아졌을 것이다, 다만 그 크기에 대해서는 매우 약한 증거밖에 없다"입니다.

그들이 스톱워치를 들고도 부호를 확정하지 못했다면, 당신은 느낌만으로 그것을 알 수 없습니다. 이것이 이 글의 진짜 결론이고, 2026년의 갱신은 이 결론을 흔든 게 아니라 못을 더 깊이 박았습니다.

그리고 19% 느려진 사람들이 자신은 20% 빨라졌다고 믿었던 그 간극은, 여전히 그 자리에 있습니다. 우리 대부분은 지금도 그 사람들과 같은 위치에 있습니다 — 자기 생산성에 대해 확신을 갖고 있지만, 그 확신을 재 본 적은 한 번도 없는 위치 말입니다.

그러니 이 글에서 하나만 가져간다면 이것이었으면 합니다. AI를 더 쓰든 덜 쓰든 상관없습니다. 다만 다음 2주 동안 당신의 작업 시간을 실제로 기록해 보세요. 당신에게는 METR에게 없는 이점이 하나 있습니다. 당신이 다뤄야 할 표본은 하나뿐이고, 그 표본은 참여를 거부하지 않습니다. 그 데이터가 어느 벤치마크보다, 어느 벤더 자료보다, 그리고 무엇보다 당신 자신의 느낌보다 정확할 것입니다.

참고 자료

Does AI Actually Make Developers Faster? What the Measured Numbers Say

Introduction — two numbers that disagree

On the question of how much AI coding tools improve productivity, we have two well-designed randomized controlled trials. They reached opposite conclusions.

One says developers with AI were 55.8% faster. The other says they were 19% slower.

And there is a twist. The second number is no longer "current" — the researchers who produced it say so themselves. METR, who measured the 19% slowdown, published a follow-up in February 2026 and mounted a warning banner on their 2025 result: "These results are out of date," and they "no longer reflect the current impact of AI models."

So let me be clear about where this post stands. The 19% is not a wrong number; it is a past number. It was really measured in the first half of 2025, and as a record of that moment it still holds. What is now a misreading is treating it as "using AI today makes you 19% slower." METR hung a banner on their own page specifically to stop you from reading it that way.

The usual move is to pick one of the two. Boosters cite the first number, skeptics cite the second. But both are real experiments producing real results. The interesting question is not "which one is right" — it is "what separated them" and, now, one more: "why is this so hard to measure properly?"

Let me flag the punchline early: the most important finding here is not the 19% slowdown. It never was, and it certainly is not now that METR has put an expiry date on it. The most important finding is that self-perception was wrong — and that finding carries no banner. In an earlier piece on LLM burnout I argued that generation got cheap while verification did not. This post is about what that asymmetry looks like once someone puts a stopwatch on it.

Experiment one — 55.8% faster

In 2023, Peng, Kalliamvakou, Cihon, and Demirer ran a controlled experiment on GitHub Copilot. They recruited 95 professional developers, gave Copilot to half of them, and handed everyone the same task: implement an HTTP server in JavaScript, as fast as you can.

The group with Copilot finished 55.8% faster than the control group. The gains were not evenly distributed either — less experienced developers, older developers, and developers with heavy workloads benefited most. The authors read this as a signal that AI pair programmers could help people transition into software careers.

The number still gets cited constantly. What almost always gets dropped in the citation is what kind of task it was.

  • It is greenfield. There is no existing codebase. No legacy to entangle with, no callers to break.
  • It is self-contained. The whole problem fits in your head at once.
  • The spec is unambiguous. Nobody argues about what an HTTP server is supposed to do.
  • Verification is cheap. Does the server start and respond? You know in seconds.
  • It measured speed, not quality. Who maintains that code in six months is outside the experiment.

So 55.8% is not a lie. It is a number that is true under very specific conditions. The trouble is that most working developers spend most of the day outside those conditions.

Experiment two — 19% slower, in early 2025

In 2025, METR (Becker, Rush, Barnes, Rein) measured exactly that outside. The paper is "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." Note the Early-2025 sitting right there in the title. It matters later.

The design: 16 experienced open-source developers brought 246 real issues from repositories they themselves maintain. Each issue was randomly assigned to "AI allowed" or "AI not allowed." Participants mostly used Cursor Pro with Claude 3.5/3.7 Sonnet. The trial ran from February to June 2025.

The decisive variable here is the relationship between the developer and the codebase.

  • The repos are mature — averaging over a decade old, more than a million lines of code, over 22,000 stars.
  • The developers averaged five years working in those repos, with roughly 1,500 commits each.
  • In other words, these people carry an enormous amount of undocumented tacit knowledge about that code.

The result: allowing AI increased completion time by 19%. They got slower. In the authors' words, "allowing AI actually increases completion time by 19% — AI tooling slowed developers down." The confidence interval ran from +2% to +39% and did not include zero, so the direction was statistically clear too.

Every verb in that paragraph is past tense for a reason. This is a measurement of the world as it stood between February and June 2025. And that world has since changed.

What happened next — METR's 2026 follow-up

On 24 February 2026, METR published the results of continuing the same experiment. The post is titled "We are Changing our Developer Productivity Experiment Design." At the same time, the warning banner went up on the 2025 paper. It is not common for a research team to pull down the headline number of its own most-cited work. So let us look at the new numbers straight.

  • Returning developers — speedup of -18%, confidence interval -38% to +9%
  • Newly-recruited developers — speedup of -4%, confidence interval -15% to +9%

Two things have to be read at once here.

First, the point estimates are still negative. Even with early-2026 tooling, the average measured in this setting is still not "faster." So this update is not the story that "it turns out AI does speed developers up after all." Reading it that way just repeats the original misreading in the opposite direction.

Second, and yet, both confidence intervals cross zero. Unlike 2025's +2% to +39%, the 2026 figures contain both slowdown and speedup. Statistically, the sign cannot be pinned down. In 2025 you could assert "they got slower." On the 2026 data you cannot.

But there is something more important than the numbers: the self-selection bias METR reported alongside them.

To run an experiment like this, you have to tell a developer "do this task without AI." By 2026, more of them were refusing. In METR's account, there was a significant increase in developers declining to participate at all, "because they do not wish to work without AI." The same thing happened inside the group that did participate: 30% to 50% of developers told METR they were not submitting some tasks at all, because "they did not want to do them without AI."

Do you see why this is fatal? A task you do not want to do without AI is, almost by definition, a task where AI seems most likely to help. Exactly those tasks get systematically drained out of the sample. METR names the direction of the bias themselves — it "likely biases downwards our estimate of AI-assisted speedup."

So the 2026 figures of -18% and -4% are not, on their own, evidence that "AI slows people down." They are numbers produced by the people who did not refuse to work without AI, on the tasks they themselves judged they could handle without it.

What, then, did METR conclude? They say it is likely that "developers are more sped up from AI tools now" than their early-2025 estimates suggested. And they immediately qualify it — because of the selection effects, "our data is only very weak evidence for the size of this increase."

That is the best answer currently available. It probably got better. We do not know by how much. That is what the team measuring this question more seriously than anyone else in the world concluded after their second attempt. Hold on to that. We come back to it at the end.

The real finding — the perception gap

The 19% is past tense now. But the 2025 study contains another finding that carries no banner — and it is the one this post's advice actually rests on.

  • Before the trial, developers forecast that AI would make them 24% faster.
  • After finishing — after actually living through a 19% slowdown — they estimated they had been 20% faster.
  • For reference, economics experts predicted a 39% speedup and ML experts predicted 38%. Everyone got the sign wrong, not just the magnitude.

This is not a story about bad forecasting. It is a story about bad hindsight. These developers misremembered work they had just personally done, in the opposite direction from the stopwatch. That leaves roughly a 40-percentage-point gap between what was perceived and what was measured.

Why would that happen? The most plausible explanation is simple. Generation is visible; verification is not.

The moment the model emits forty lines in three seconds is vivid and memorable. The twenty minutes you then spend reading those lines, questioning their assumptions, checking them against this repo's conventions, and throwing half of them away is not memorable. It just feels like "working." We grade our day on the dopamine spikes and never write the quiet grind into the ledger.

The METR data supports this reading. Developers accepted fewer than 44% of the code the AI generated. The rest was time spent reading, judging, and discarding — producing nothing. And only about one quarter of participants actually got faster with AI at all.

Let me underline this once more. No expiry banner was hung on this finding. What METR declared out of date was the size of the speedup, not how badly people read their own speedup. The tooling moved on by a generation. There is no evidence anywhere that human self-measurement improved in the meantime.

What separated the two experiments

Compress the difference into one sentence and it reads: AI wins when it supplies context you lack, and loses when it has to catch up to context you already have.

The Copilot participants faced a blank screen. Everything the model filled in was pure gain. The METR participants already carried five years of tacit knowledge in their heads. The model does not have that context, getting it there costs prompting, and whatever comes back must then be checked against that same tacit knowledge. The richer your context, the more expensive it is to bring the model up to speed with you.

The sharpest observation in the METR paper is exactly this: in the 2025 trial, developers slowed down more on the issues they were more familiar with. Familiarity was not a shield. It was a tax.

The 2026 data does not contradict this. Returning developers — the ones who have kept their own repos for years — came in at -18%, while newly-recruited developers came in at -4%. The more familiar group slowed down more. But the two confidence intervals overlap heavily, so calling this evidence would be overreach. Consistent with the hypothesis is as far as it goes, and that is exactly how I will file it.

So the two axes that actually matter in practice are familiarity and cost of verification.

  • Unfamiliar, cheap to verify — the quadrant where AI reliably wins. A language you have never used, an unfamiliar API, one-off scripts, scaffolding. If it is wrong you find out immediately, and the model supplies what you did not know. Use it freely.
  • Familiar, cheap to verify — boilerplate, repetitive patterns. Small gains, small losses. Fine either way.
  • Familiar, expensive to verify — METR's quadrant. Subtle logic, invariants in old code, traps only you know about. Writing it yourself may well be faster.
  • Unfamiliar, expensive to verify — the dangerous quadrant. You cannot review what you do not understand. This is where AI output silently becomes technical debt and the invoice arrives months later. If you are here, the fix is not a better tool. It is learning the domain first.

These four quadrants are still a useful map. But one caveat now has to be stapled to it: this is a hypothesis, not a measured law. Which quadrant you are in is something you have to check for yourself, by measuring.

Zooming out — DORA and Stack Overflow

What does the individual-level illusion look like at organizational scale? The 2025 DORA report (State of AI-assisted Software Development) surveyed roughly 5,000 technology professionals.

Adoption is effectively settled. About 90% of developers use AI, and more than 80% say it has increased their productivity. And DORA found that AI genuinely does increase throughput — so far, so optimistic.

The problem is that the same report finds AI also increases instability. When code gets produced faster and in greater volume, every weak link downstream is exposed. Without control systems — automated testing, mature version control, fast feedback loops — a rise in change volume converts directly into instability.

Hence DORA's central thesis: AI is an amplifier. It magnifies an organization's existing strengths and weaknesses together. Drop it onto a healthy engineering system and performance compounds. Drop it onto a broken one and you ship low-quality work faster. Speed without stability is just accelerated chaos.

The 2025 Stack Overflow Developer Survey (roughly 49,000 respondents) supplies the last piece: usage and trust are moving in opposite directions.

  • 84% are using or planning to use AI tools, up from 76% the previous year.
  • Yet 46% actively distrust the accuracy of AI output — more than the 33% who trust it.
  • Only 3.1% say they "highly trust" it.
  • The top frustration, cited by 66%, is "AI solutions that are almost right, but not quite." Second, at 45%: "debugging AI-generated code is more time-consuming."

"Almost right, but not quite" is the phrase that runs through this entire post. Obviously wrong code is cheap to filter out. The expensive kind is code that is plausible enough to tempt you and wrong enough to cost you — and the labor of filtering it shows up on no dashboard anywhere.

So what should you actually do

None of this means "stop using AI." It means there is real work to do, and it is not the work most people think.

1. Stop trusting the feeling; measure your own work. The lesson of this research is that hindsight lies, so you need records rather than recollection. And METR's 2026 follow-up does not weaken this advice — it strengthens it. If a dedicated research team ran a randomized controlled trial twice and still could not pin down the sign, then your end-of-day impression certainly cannot. The instrument does not need to be fancy. Before you start a task, write down your estimate. When you finish, write down the actual time and whether you used AI. Two weeks of that will tell you more about you than any survey will. An unmeasured productivity gain is just a mood.

2. Choose tasks by familiarity and verification cost. Use the four quadrants above. Be generous with AI where the domain is unfamiliar and checking is cheap; be stingy where the domain is familiar and checking is expensive. And where it is both unfamiliar and expensive to verify, spend on learning before you spend on tooling.

3. Budget review as first-class work. As generation approaches free, the bottleneck migrates entirely to verification. As long as review is treated as chores after the "real work," the added cost stays off the books. I went deeper into this in the LLM burnout piece.

4. Treat vendor numbers the way you treat benchmarks. That is, skeptically. Once you remember which task produced the 55.8%, you will ask the same questions of the next number in a marketing deck: which task, measured by whom, and what got left out. And now there is one more question to ask: when was it measured? On how evaluation numbers get shaky, see separating signal from noise in coding evals.

5. Write for humans. If verification is the bottleneck, then readable code is no longer a matter of taste — it is a throughput problem. Which is exactly the argument in when an AI maintains your code, write for humans anyway.

Honest caveats about these numbers

Since I do not want this read as "the research proves AI is useless," the limitations on both sides deserve to be stated plainly.

Limits of the METR 2025 study. Sixteen participants. That is small. It measured one specific setting — large, mature open-source repositories worked by highly skilled maintainers. 56% of participants had never used Cursor before, and the models are from the first half of 2025, which is more than a generation old by now. The authors themselves explicitly said their result does not show: that AI fails to speed up most developers; that AI fails in domains other than software; that near-future AI will fail in this same setting; or that there is no better way to use today's AI to get a speedup. None of those four are claims of this paper. And the authors have now added an expiry warning on top.

Limits of the METR 2026 follow-up. In one sense these are worse. Self-selection bias is eating the skeleton of the experiment. The more developers refuse to work without AI, the more what remains to be measured skews toward "tasks that are fine to do without AI." It is honest of METR to name the direction of that bias — it pushes the estimate down — but knowing the direction is not knowing the size. Hence the wider confidence intervals and the weaker conclusion. And this problem gets worse over time, not better: the more useful AI becomes, the harder it is to obtain a no-AI control group at all. That is precisely why METR titled the follow-up around changing the experiment design.

Limits of the Copilot study. One task, greenfield, self-contained. It measured completion time — not code quality, not maintainability. It is also worth noting that the author list includes GitHub-affiliated researchers.

Limits of DORA and Stack Overflow. Both are self-report surveys. And for precisely the reason METR uncovered, self-report is the least trustworthy instrument available on exactly this topic.

So the honest conclusion is not "AI slows you down." The honest conclusion is three sentences. The effect is context-dependent enough that even its sign flips. That sign does not come out cleanly even from a well-designed randomized trial. And it certainly does not come out of your intuition.

Closing

We tend to ask whether a tool is good or bad. What this data says is that this is the wrong question. The same tool produced a 55.8% gain in one experiment and a 19% loss in another. The tool did not change. What changed was the kind of work and the context of the person doing it.

And there is another layer on top of that. Even the 19% is now a "then" number rather than a "now" number — flagged as such by the very people who produced it. The follow-up could not pin down the sign, and the reason was not insufficient data. It was that the clean control group is disappearing, because people refuse to work without AI.

You can take that as a reason to be humble, or as a reason to hold the conclusion harder. I think it is the latter. Consider what happened here. A dedicated research team designed a randomized controlled trial, collected hundreds of genuine issues from real repositories, and ran it twice. And what they came away with was: it probably improved, but we have only very weak evidence about the size.

If they could not pin down the sign with a stopwatch in hand, you are not going to get it from a feeling. That is the real conclusion of this post, and the 2026 update did not shake it. It drove the nail deeper.

And the gap — the one where people who were 19% slower believed they were 20% faster — is still sitting exactly where it was. Most of us are still standing exactly where they stood: confident about our own productivity, having never once measured it.

So if you take one thing from this post, let it be this. Use AI more or use it less; it does not much matter. But log your actual working hours for the next two weeks. You have one advantage METR does not: you only have one subject to study, and that subject cannot refuse to participate. That data will be more accurate than any benchmark, any vendor deck, and above all more accurate than how you feel.

References