숫자가 불편한 이유
METR의 무작위 대조 실험 결과는 꽤 도발적이다. 자신의 코드베이스를 누구보다 잘 아는 숙련된 오픈소스 기여자들이 AI 코딩 어시스턴트를 쓴 뒤 스스로는 약 20% 빨라졌다고 느꼈지만, 실제 측정값은 19% 느렸다. 체감과 실측 사이의 간극이 무려 39%p다. 이건 반올림 오차가 아니다. 감각 자체가 방향을 잘못 가리키고 있다는 신호다.
이 연구가 불편한 건 방법론 때문이다. 설문도 아니고, 벤더가 후원한 벤치마크도 아니다. 개발자들이 자기 레포에서, 자기 코드로 작업한 실험이다. '익숙하지 않아서 느렸다'는 변명이 통하지 않는다. 그럼에도 체감은 완전히 반대 방향을 가리켰다.
왜 '빠른 느낌'이 생기는가
자동완성이 작동하고, 코드가 화면에 나타나고, 무언가 계속 움직인다. 이 시각적·물리적 피드백이 '진전'처럼 느껴진다. 하지만 실제로는 AI가 생성한 코드를 리뷰하는 시간, 틀린 결과를 다시 프롬프트하는 시간, 내가 쓰지 않은 코드의 버그를 디버깅하는 시간, 제안을 평가하면서 발생하는 컨텍스트 스위칭 비용—이 모든 것이 스톱워치에는 찍히지만 개발자의 감각에는 잡히지 않는다. '움직임'과 '진전'은 다른 개념이다.
더 구조적인 문제는 업계 전체가 자기보고 데이터 위에서 의사결정을 내리고 있다는 점이다. 수십억 달러의 AI 툴링 투자가 개발자 감정 설문을 근거로 정당화된다. 채용 계획을 세우고, 스프린트 커밋을 잡고, 헤드카운트를 조정한다. METR 연구는 이 가정에 정면으로 반박하는 몇 안 되는 실증 데이터인데, 아무도 이 대화를 하고 싶어하지 않는다.
도구마다 실제로 다르다—3종 비교의 교훈
물론 'AI 코딩 도구 = 느림'으로 단순화하면 안 된다. dev.to에 올라온 Claude Code·Cursor·Windsurf 2주 실사용 비교는 도구 간 편차가 꽤 크다는 걸 보여준다. 같은 React 리팩토링 작업에서 Claude Code는 단순히 파일을 쪼개는 대신 코드베이스 전체의 패턴을 읽고 컴포넌트 계층을 제안했다. Cursor는 인라인 편집 경험이 빠르고 테스트 작성에서 가장 강했지만, 큰 그림의 설계 질문에서는 generic한 답을 냈다. Windsurf의 Cascade 모드는 자율적으로 실행해주지만, 그 자율성이 오히려 개발자를 의사결정 루프 밖으로 밀어낼 수 있다.
여기서 눈여겨볼 것은 '컨텍스트 핸들링'의 차이다. 파일 하나를 잘 완성하는 도구와, 코드베이스 전체의 맥락을 읽고 패턴을 맞추는 도구는 생산성에서 본질적으로 다른 결과를 낸다. METR 연구의 참가자들이 자신의 레포에서도 느려진 이유 중 하나는, 도구가 코드베이스의 '맥락'을 제대로 읽지 못해 계속 수정과 재프롬프트가 반복됐기 때문일 가능성이 있다. 도구 선택의 기준이 '코드 생성 속도'에서 '컨텍스트 이해 깊이'로 이동해야 하는 이유다.
평가 기준의 이동—진짜 경쟁력은 어디에
AI가 코딩을 평준화하면, 평가는 더 고차원으로 이동한다. velog의 분석이 짚는 것처럼, 지금 면접과 사내 평가에서 실제로 점수가 갈리는 질문은 이미 달라졌다. "이 코드가 왜 맞는지 설명할 수 있나요?