METR이 개발자 생산성 연구를 뜯어고쳐야 했습니다. 연구 참여 요청을 받은 개발자 중 30~50%가 거절했거든요. AI 없이는 코딩을 안 하겠다는 거였어요.
생산성 향상의 증거처럼 들릴 수 있어요. 근데 같은 METR이 실제로 측정한 생산성 수치는 정반대였어요.
다들 이렇게 믿죠 — "AI가 나를 2배 더 가치 있게 만든다"
개발자들의 AI 체감은 확실해요. METR 연구에 참여한 개발자들은 평균적으로 AI가 자신을 조직에서 2배 더 가치 있게 만든다고 느꼈고, 생산성이 약 20% 향상됐다고 자체 보고했어요. 막혔던 문제가 풀리고, 코드가 빠르게 나오는 느낌 — 이건 진짜 체감이에요.
이 체감이 완전히 틀린 건 아니에요. AI 없이 30분 걸리던 함수를 5분 만에 완성하는 건 분명히 빠른 거잖아요. 측정의 함정은 다른 곳에 있어요 — 그 5분짜리 코드가 이후 몇 주 동안 유지보수에 얼마나 비용을 쓰게 만드는지는 체감이 안 되거든요.
METR 연구 참여자가 남긴 말
"AI 없이 이 작업을 하려고 하면 머리가 폭발할 것 같아요. Uber를 타다가 갑자기 걸어서 도시를 가로질러야 하는 느낌이에요."
근데 숫자는 정반대예요
METR이 2025년 초 진행한 무작위 대조 실험에서 경험 있는 개발자들을 AI 사용 그룹과 미사용 그룹으로 나눠서 작업 완료 시간을 쟀어요. 결과는 이랬어요 — AI를 쓴 개발자들이 안 쓴 개발자들보다 작업 완료에 평균 19% 더 오래 걸렸어요. 자체 보고 +20%와 실측 -19%. 이 간극이 바로 AI 생산성 착각의 핵심이에요.
코드 품질 측면은 더 심각해요. CodeRabbit이 오픈소스 GitHub PR 470개를 분석한 결과, AI가 포함된 PR은 인간이 작성한 PR보다 문제가 1.7배 더 많았어요. PR당 평균 이슈가 10.83개 대 6.45개예요. 보안 취약점(XSS)은 2.74배, 로직 오류는 75%, 성능 회귀는 무려 8배 더 많이 발생했어요.
| 코드 이슈 유형 | AI 생성 코드 | 인간 작성 코드 |
|---|---|---|
| PR당 평균 이슈 | 10.83개 | 6.45개 |
| XSS 보안 취약점 | +174% 더 많음 | 기준 |
| 로직·정확성 문제 | +75% 더 많음 | 기준 |
| 가독성 문제 | +200% 더 많음 | 기준 |
| 성능 회귀 | +700% 더 많음 | 기준 |
그 비용은 즉각 나타나요. AI 코딩 분석 기업 Entelligence에 따르면, 기업들이 쓰는 AI 토큰의 44%가 AI가 처음부터 만들어낸 버그를 수정하는 데 사용된다고 해요. 생산성을 높이겠다고 쓴 AI가 생산한 버그를 또 AI로 고치는 구조예요.
기업 단위로 보면 더 명확해요. Uber는 직원들의 AI 도구 사용을 독려하기 위해 리더보드를 도입했다가 2026년 4개월 만에 연간 AI 예산을 다 써버렸어요. COO Andrew Macdonald의 결론은 이거였어요 — "AI 사용량 지표와 실제로 유용한 기능 출시 사이에 선을 긋기가 매우 어렵다."
Amazon도 비슷한 실수를 했어요. 내부 AI 사용량 리더보드인 Kirorank를 만들었다가, 직원들이 쓸모없는 가짜 작업을 AI에게 계속 돌려서 순위를 올리는 "토큰맥싱"을 발견하고 2026년 5월에 전면 폐지했어요. Amazon이 직원들에게 보낸 메시지 — "AI를 쓰기 위해서 AI를 쓰지 마세요."
더 무서운 건 그다음이에요 — 조용한 기술 퇴화
단기 수치보다 더 긴 문제가 있어요. AI 없이 일하기를 거부한다는 건, 단순한 선호가 아니라 AI 없이는 코드를 판단하는 능력 자체가 줄고 있다는 신호일 수 있어요.
프로그래밍 실력은 "절차 기억"이에요 — 직접 코드를 짜고, 실패하고, 고치는 반복 과정에서만 만들어지는 근육 같은 거예요. AI가 이 과정을 건너뛰게 해주면, 어떤 코드가 좋고 나쁜지 판단하는 능력 자체가 약해져요. 신경과학적으로도 확인된 현상이에요 — 직접 생성하는 과정에서만 뇌의 여러 영역이 동시에 활성화되며 장기 기억이 형성되거든요.
결정적인 역설은 여기예요 — AI를 가장 잘 활용하는 개발자는, AI 없이도 코드를 판단할 수 있는 사람이에요. AI가 생성한 코드를 검토하고, 아키텍처를 설계하고, 보안 결함을 잡는 능력은 AI가 줄 수 없어요. 지금 많은 개발자가 그 판단력을 키울 기회를 AI에게 넘기고 있는 거예요.
"개발자들은 임시적인 속도 향상을 위해 영구적인 노예 계약을 맺고 있다 — 더 빠른 코드 생산이 유지보수 비용의 절반을 줄이지 않는 한."
— James Shore, 소프트웨어 엔지니어링 저자
그럼 어떻게 써야 하는 건데요
AI 코딩 도구를 안 쓰는 게 답은 아니에요. 싱가포르 경영대학원 연구팀이 제안한 방향과 업계가 공통으로 찾은 결론은 이거예요 — AI를 시니어 개발자가 주니어를 다루듯이 쓰세요. 결과물을 받아서 그대로 올리는 게 아니라, 검토하고, 이해하고, 책임지는 구조요.
- AI 코드 리뷰를 기본 루틴으로
AI가 생성한 PR은 반드시 라인 단위로 리뷰하는 걸 팀 규칙으로 만드세요. "AI가 짰으니까"는 리뷰 생략의 이유가 되지 않아요. - AI 없이 하는 시간을 의도적으로 만들기
일주일에 한 번, AI 없이 작은 기능이나 버그를 직접 풀어보세요. 불편하게 느껴질수록 그 감각이 필요하다는 신호예요. - 토큰 사용량이 아니라 배포 품질로 측정하기
Amazon·Uber의 실수처럼, AI 사용량을 생산성 지표로 쓰지 마세요. 버그율, 배포 후 인시던트, PR 사이클 타임이 진짜 지표예요. - AI 생성 코드를 주니어 코드처럼 다루기
"이 코드가 왜 이렇게 작동하는지 나는 설명할 수 있나?"라는 질문을 매번 던지세요. 설명 못 하면 올릴 수 없어요. - 아키텍처와 보안은 사람이 설계하기
AI가 잘 못하는 영역이 있어요 — 코드베이스 전체 맥락을 이해한 아키텍처 결정, 조직 고유의 보안 정책 반영이에요. 이 부분은 사람이 직접 설계하세요.
Devin 개발사 CEO도 인정했어요
AI 코딩 에이전트 Devin을 만든 Cognition의 Scott Wu는 현재 AI 코딩 에이전트가 "주니어~미드레벨 프로그래머 수준"에서 작동한다고 했어요. 시니어 레벨 판단이 필요한 결정을 AI에게 위임하면 안 되는 이유예요.
