Skip to content
←

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

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

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

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에게 없는 이점이 하나 있습니다. 당신이 다뤄야 할 표본은 하나뿐이고, 그 표본은 참여를 거부하지 않습니다. 그 데이터가 어느 벤치마크보다, 어느 벤더 자료보다, 그리고 무엇보다 당신 자신의 느낌보다 정확할 것입니다.

참고 자료

현재 단락 (1/91)

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

작성 글자: 0자원문 글자: 9,942자작성 단락: 0/91