METR의 AI 코딩 속도 연구 결과: 너무 많은 개발자가 AI 없이는 일할 수 없다

• 책: AI Agents Pocket Guide
• 저자 소개: Thinking in Go (2권 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구와 함께 배포하는 개발자를 위한 IDE
• 저자: xgabriel.com | GitHub

2025년 초, METR는 숙련된 오픈소스 개발자 16명에게 시간당 $150를 지급하고 그들이 수년간 작업해 온 대규모 오픈소스 저장소의 실제 이슈 246개를 처리하도록 했습니다. 각 이슈에는 AI 사용 여부가 무작위로 허용되거나 금지되었습니다. AI가 허용된 경우, 작업 시간이 19% 더 오래 걸렸습니다. 개발자들은 시작하기 전에 24%의 속도 향상을 예측했습니다. 작업을 마친 후에도 그들은 AI가 자신들을 20% 빠르게 만들었다고 여겼습니다. (METR, July 2025).

이후 METR은 더 새롭고 많은 사람들을 동원하여 연구를 다시 시도했습니다. 하지만 명확한 답을 얻지 못했습니다. 너무 많은 개발자가 AI 없이는 일하기로 동의하지 않았습니다.

두 번째 결과가 첫 번째 결과보다 더 중요합니다.

후속 조치에서 밝혀진 문제점

새로운 실험은 2025년 8월에 시작되었으며, 개발자 57명, 저장소 143개, 작업 800개 이상을 포함했습니다. METR은 2026년 2월에 그 결과를 발표했습니다. (METR, February 2026). 자체 데이터에 대한 결론은

주요 원인은 인력 확보 문제였습니다. METR는 'AI 없이 일하고 싶지 않아 연구에 참여하지 않기로 선택한 개발자들'의 급증을 확인했습니다. 실제로 참여한 사람들조차도 자신의 작업을 걸러냈습니다. 즉, 개발자의 30%에서 50%가 AI 없이는 수행하기 싫은 과제들이라며 제출하지 않겠다고 말했습니다. METR는 이 두 가지 효과 모두가 AI가 개발자들의 속도를 얼마나 높여주는지 실제 수치보다 낮게 측정하게 만든다고 생각합니다.

여기에 또 다른 문제가 겹쳤습니다. 시간당 임금이 $150에서 $50으로 떨어졌는데, METR는 이것이 자체적인 선택 효과를 추가했다고 보고 있습니다. 또한 '여러 AI 에이전트를 동시에 사용하는 개발자 비율'에 대해서도 METR는 작업별 소요 시간에 대한 측정이 신뢰할 수 없다고 말합니다. 만약 에이전트 하나를 실행시키고 다른 곳으로 전환하는 동안 그 과제가 얼마나 걸렸을까요?

METR가 제시한 수치는 다음과 같습니다. 재참여 개발자의 경우, '신뢰 구간이 -38%에서 +9% 사이인 -18%의 속도 향상'입니다. 새로 모집된 개발자의 경우, '추정 속도 향상은 -4%이며, 신뢰 구간은 -15%에서 +9%'입니다. 같은 게시물에서는 2025년 결과를 +2%에서 +39% 사이인 19% 더 길다고 제시했는데, 이 척도에서 마이너스 부호는 AI를 사용했을 때 과제가 더 적게 걸렸다는 의미입니다. 두 추정치 모두 AI가 개발자를 더 빠르게 만든다는 쪽으로 기울어져 있으며, 이는 2025년의 결과와 반대됩니다. 신뢰 구간이 0을 가로지르기 때문에 어느 쪽도 확실하게 결론을 내리지는 못합니다. METR 자체 분석에 따르면, 개발자들은 아마도 2025년 초보다 지금 더 빨라졌으며, 이 데이터는 그 정도에 대한 매우 약한 증거라고 합니다.

소위 무작위 대조 시험(randomized trial)을 통해 AI 코딩 속도를 측정하려 했으나, 통제 조건(control condition)이 사라졌습니다. AI 없이 일하는 것은 많은 개발자들이 거부하게 되었고, 시급 150달러 대신 50달러에 불과한 금액으로는 기꺼이 시도하려는 사람이 적었습니다.

당신의 속도 감각은 이미 40포인트나 벗어났다

METR는 또한 사람들에게 질문했습니다. 무작위 대조 시험은 비용이 많이 들고 설문조사는 저렴하기 때문에, 2026년 2월부터 4월까지 진행된 연구를 실시했으며, 기술직 근로자 349명(소프트웨어 엔지니어 87명 포함)을 대상으로 했습니다. 중앙값으로 보고된 속도 변화는 3배였고, 자신의 업무 가치에 대한 중앙값으로 보고된 변화는 1.4배에서 2배 사이였습니다(METR, May 2026). 응답자들은 또한 AI 도구를 유지하기 위해 급여의 29%를 포기할 것이라고 말했는데, METR는 이를 약한 증거로 간주합니다.

METR는 이 수치 바로 옆에 자체 경고문을 게재했습니다.

METR의 스톱워치를 망가뜨린 것이 무엇인지 보세요: 여러 에이전트를 동시에 실행하고 그 에이전트들이 돌아가는 동안 다른 작업을 수행하는 개발자들입니다. 이것이 사람들이 속도 증거로 자주 언급하는 작업 흐름입니다. 더 많은 에이전트를 시작하는 것은 세기 쉽고 기분 좋게 느끼기 쉽습니다. 하지만 그것은 당신의 메인 브랜치에 무엇이 도달했는지에 대해서는 아무것도 말해주지 않습니다.

40분 동안 실행되지만 버려지는 diff를 건네주는 에이전트도 검토 시간을 소모시켰습니다. 변경 사항이 도착했다가 이틀 후에 되돌아가는(reverted) 에이전트는 더 많은 비용을 발생시킵니다. 어느 쪽도 '실행된 에이전트 수'에는 나타나지 않습니다.

스톱워치나 직감 없이 세어볼 수 있는 세 가지 것이 있습니다:

• Landed (도착): 변경 사항이 배포하는 브랜치에 병합(merged)된 작업입니다.
• Dropped (폐기): 병합되지 않고 닫힌 풀 리퀘스트(pull requests, PR).
• Reverted (되돌림): 도착했다가 다시 빠져나온 변경 사항입니다.

이 측정 항목들 중 어느 것도 속도를 나타내지 않습니다. 이것들은 검토를 통과한 결과물(output)을 세는 것이며, 이는 팀이 비용을 지불하는 것과 더 가깝습니다. 거칠고 시차를 두고 나타나지만, 한 주가 어떻게 느껴졌는지에 의존하지는 않습니다.

오늘 바로 실행할 수 있는 주간 카운트

만약 에이전트 작업의 결과가 풀 리퀘스트로 이어진다면, GitHub CLI와 git을 사용하여 세 가지 숫자를 얻을 수 있습니다. 이 스크립트는 현재 저장소의 지난 7일간을 계산합니다:

#!/usr/bin/env bash
# weekly-landed.sh: last 7 days에 도착한 것들
since=$(date -d '7 days ago' +%F 2>/dev/null \
...

date 라인은 GNU(-d)와 macOS(-v) 모두를 처리합니다. 되돌림(revert) 카운트는 git의 기본 `Revert

저는 Hermes IDE를 만들었으니 이 부분을 염두에 두고 읽어주세요.

작업이 완료된 것을 계산하기 위해서는 모든 에이전트 작업에 명확한 시작점과 끝점이 있어야 합니다. Hermes에서는 ⌘N (Windows 및 Linux의 경우 Ctrl+Shift+N)을 누르면 각 작업을 새로운 hermes/<name> 브랜치와 워크트리에서 시작하며, 해당 작업이 에이전트의 첫 번째 프롬프트가 됩니다. 모든 세션은 '작업 중(working)', '승인 필요(needs approval)', '질문함(asked you)', '완료됨(done)', '오류(error)' 또는 '유휴(idle)'라는 하나의 상태를 보여주며, Hermes는 해당 상태가 추측일 때도 알려줍니다.

작업은 그것에 무슨 일이 생길지 결정할 때까지 작업으로 남아 있습니다. Hermes는 모든 에이전트 턴을 저장하므로, 어떤 단일 턴이라도 비교(diff)하거나 복원할 수 있습니다. 검토 데스크(Review Desk)(⌘G, Windows 및 Linux의 경우 Ctrl+Shift+G)는 위험 플래그와 함께 턴별 또는 파일별로 변경 사항을 보여주며, 라인 주석은 해당 라인을 작성한 에이전트에게 되돌아갑니다.

그리고 Land가 있습니다. 이는 작업을 시작한 브랜치로 한 단계에서 커밋하고, 풀 리퀘스트(pull request)를 열거나 로컬 병합(merge)할 수 있으며, 취소도 가능합니다. 사용자가 직접 설정한 검사(checks)는 작업이 완료된 시점을 결정할 수 있습니다. Land가 풀 리퀘스트를 열고 그것이 병합되면, 위의 스크립트가 이를 계산합니다. 로컬 병합은 PR 번호에 표시되지 않으므로, 만약 그렇게 작업을 완료했다면 git log에서 그 횟수를 세어야 합니다.

Hermes는 생산성 대시보드가 없고 사용자의 속도를 측정하지 않습니다. 카운트는 여전히 git과 GitHub에서 가져옵니다. 각 에이전트는 실제 터미널에 자체 인터페이스를 실행하며, 여기에 사용자 로그인 정보가 포함됩니다. 따라서 Hermes는 단순히 브랜치, 상태, 리뷰, 그리고 Land 단계를 주변에 추가할 뿐입니다. 만약 한 공급업체를 사용한다면, 그 자체의 도구만으로 충분할 수 있습니다: Claude Code는 기본적으로 백그라운드 세션을 .claude/worktrees/ 아래의 worktree로 이동시키며, Codex 앱은 $CODEX_HOME/worktrees 아래에서 병렬 채팅을 worktree로 실행합니다.

Hermes는 무료이며 BSL 1.1에 따라 소스 코드가 공개되어 있고, macOS, Windows 및 Linux에서 실행됩니다. 이는 Nous Research, Anthropic, OpenAI 또는 어떤 에이전트 공급업체와도 제휴하지 않습니다.

그래서, 더 빨라졌나요?

대부분의 우리에게는: 모르겠습니다. METR는 무작위화, 스톱워치, 그리고 예산으로 인해 올해 신뢰할 수 있는 숫자를 얻지 못했습니다. 화요일이 어땠는지에 대한 느낌으로는 알 수 없습니다.

이번 주 금요일에 스크립트를 실행하고, 또 다른 에이전트를 추가하기 전에 다음 주 금요일에도 실행해 보세요.

만약 METR의 AI가 없는 과제를 시간당 150달러를 받고 맡았을 때도 그렇게 했을까요? 그리고 만약 팀에서 에이전트 출력을 추적한다면, 무엇을 계산하시나요? 댓글로 알려주세요.

이것이 유용했다면

Hermes로 카운트를 시도해 보고 싶다면, 다운로드하여 두 에이전트에게 하나의 과제를 주고 어떤 것이 성공하는지 확인해 보세요. 도움이 되었다면, GitHub에서 별표 표시해주세요.

에이전트가 작업을 완료하고 멈추도록 설계된 경우에만 '성공한 것'을 세는 것이 작동합니다. AI Agents Pocket Guide에서는 단일 에이전트부터 여러 에이전트가 병렬로 작업하는 과정 뒤의 루프, 도구(tool), 가드레일 패턴을 다룹니다.