2025년 7월, AI 업계를 발칵 뒤집어 놓은 연구가 나왔어요.
METR(Model Evaluation & Threat Research)이라는 AI 안전 연구 기관이 실험을 했어요.
실험 설계:
- 참가자: 숙련된 오픈소스 개발자 16명
- 작업: 본인이 수년간 기여해온 레포지토리의 실제 이슈 246개
- 코드베이스: 평균 100만 줄 이상, GitHub 스타 22,000개 이상
- 방법: 무작위로 AI 허용/금지 조건 배정
결과:
AI 도구 사용 시 → 19% 더 느림
진짜 충격적인 건 인식 차이
실험 전 개발자 예상:
"AI 쓰면 24% 빨라질 것 같아요"
실험 후 개발자 인식:
"AI 쓰니까 20% 빨라진 것 같아요"
실제 측정값:
19% 더 느림
인식과 현실의 갭: 39%p
AI 때문에 느려졌는데, 개발자 본인은 빨라졌다고 느꼈어요.
이게 제일 무서운 부분이에요.
왜 시니어가 오히려 더 느려지나
이유 1 — 익숙한 코드베이스일수록 AI가 방해가 됨
주니어 개발자:
코드베이스 잘 모름 → AI 제안 = 도움
AI가 방향 잡아줌 → 시간 절약
시니어 개발자:
코드베이스 완벽히 앎 → AI 제안 = 검증 대상
AI 제안 읽고 → 맞는지 판단하고 → 틀리면 수정
→ 그냥 직접 짜는 게 더 빠름
연구 참가자가 말했어요.
"AI는 어디를 수정해야 하는지 제대로 못 잡아요. 하위 호환성 같은 특수한 케이스를 몰라요."
이유 2 — 코딩 모드 ↔ 프롬프트 모드 전환 비용
기존 개발 흐름:
문제 파악 → 코드 작성 → 테스트
(단일 사고 모드)
AI 도입 후:
문제 파악 → 프롬프트 작성 → AI 출력 대기
→ 출력 검토 → 틀린 부분 찾기 → 수정 요청
→ 다시 검토 → ...
(사고 모드 계속 전환)
연구에서 화면 녹화를 분석해보니, 개발자들이 전체 작업 시간의 9%를 AI 출력 검토 및 수정에만 사용했어요.
이유 3 — AI 코드는 "70% 정확"
AI 첫 번째 시도 정확도: ~70%
그린필드 프로젝트(새 코드):
→ 70% 맞는 코드 제공 = 엄청난 도움
→ 30% 수정만 하면 됨
기존 복잡한 코드베이스:
→ 70% 맞아 보이지만 실제론 틀린 코드
→ 어디가 틀렸는지 찾는 게 더 오래 걸림
→ 그냥 처음부터 짜는 게 빠름
실제로 AI 생성 PR 수락률은 32.7%, 인간 작성 PR은 84.4%예요.
이유 4 — 디버깅이 더 어려움
내가 짠 코드 디버깅:
내 논리 → 내가 다 앎 → 빠르게 찾음
AI가 짠 코드 디버깅:
AI 논리 → 내가 모름 → 처음부터 이해해야 함
→ "왜 이렇게 했지?" 하나하나 파악
→ 훨씬 오래 걸림
Harness 2025 설문에서 67%의 개발자가 "AI 코드 디버깅이 직접 짜는 것보다 오래 걸린다"고 답했어요.
한 개발자의 직접 실험
MIT 테크 리뷰가 인터뷰한 개발자 Mike Judge(컨설팅사 Substantial)의 이야기예요.
처음엔 AI가 25% 빠르게 해준다고 생각했어요.
METR 연구를 보고 직접 실험해봤어요.
방법:
- 6주간 작업 전 시간 예측
- 동전 던져서 AI 사용/미사용 결정
- 실제 시간 측정
결과:
AI 사용 시 중앙값 기준 21% 더 느림
→ METR 연구와 일치
그다음 그는 데이터를 뒤졌어요.
"AI 도구로 생산성이 폭발했다면 앱 등록, GitHub 프로젝트, 웹사이트 등이 급증해야 하잖아요. 수백 달러를 써서 데이터를 분석했는데 전부 플랫라인이었어요. 하키스틱 어디 있어요?"
DORA 보고서도 같은 말을 한다
Google의 DORA 팀이 39,000명 이상의 개발자를 대상으로 조사했어요.
AI 채택률 25% 증가마다:
- 배포 속도: 1.5% 감소
- 시스템 안정성: 7.2% 감소
개발자의 39%: AI 코드 신뢰 못함
개발자의 75%: 더 빠르다고 느낌 (실제론 아님)
그럼 AI 코딩 툴은 쓰면 안 되나?
아니에요. 어디에 쓰냐가 중요해요.
AI 효과 좋은 상황:
✅ 새 프로젝트 (그린필드)
✅ 보일러플레이트 코드 (CRUD, 설정 파일)
✅ 테스트 코드 작성
✅ 문서화
✅ 익숙하지 않은 언어/프레임워크
✅ 에러 메시지 검색/분석
AI 효과 나쁜 상황:
❌ 수년간 기여한 익숙한 코드베이스
❌ 복잡한 비즈니스 로직
❌ 성능 최적화 (시스템 전체 맥락 필요)
❌ 보안 민감한 코드
❌ 하위 호환성이 중요한 수정
2026년 업데이트 — 결과가 바뀌었나?
METR이 2025년 8월 후속 연구를 진행했어요. 57명으로 확대했어요.
결과:
기존 참가자: 여전히 18% 느림 (비슷)
새로 모집한 참가자: 4% 느림 (덜 부정적)
문제: 선택 편향
→ AI 없으면 참가 안 하겠다는 개발자들이 탈락
→ 결과가 왜곡됨
METR은 2026년 초에 이렇게 밝혔어요.
"측정 방법론을 다시 설계 중입니다. 다만 원래 연구의 핵심 발견은 여전히 유효합니다."
동시에 그들 자체 직원의 Claude Code 사용 로그를 분석해보니 특정 작업에서 1.5배~13배 속도 향상이 있었어요. 작업 유형에 따라 극명하게 갈린다는 거예요.
결론 — 진짜로 받아들여야 할 것
틀린 믿음: "AI 쓰면 무조건 빨라진다"
맞는 이해:
→ 신입/주니어한테는 효과적
→ 새 프로젝트엔 효과적
→ 익숙한 복잡한 코드베이스의 시니어에겐 오히려 방해
→ 내가 빠르다고 느껴도 실제론 아닐 수 있음
실용적인 결론이에요.
"AI가 빠르게 해준다는 게 아니라, 내 주의를 더 중요한 문제에 쓸 수 있게 해준다. 단, 그럴 의지가 있을 때만."
'AI Development' 카테고리의 다른 글
| AI가 짠 코드 43%가 프로덕션에서 터진다 — Lightrun 200개 기업 조사 (0) | 2026.04.15 |
|---|---|
| AI가 코드 작성 속도 올려도 배포는 안 빨라진다 (0) | 2026.04.15 |
| Vibe Coding은 끝났다 — Karpathy가 선언한 Agentic Engineering 시대 (1) | 2026.04.14 |
| Claude Code 토큰 낭비 없애는 법 — 컨텍스트 관리 완전 가이드 (0) | 2026.04.14 |
| Git Worktrees + Claude Code — 혼자서 팀처럼 병렬 개발하는 법 (0) | 2026.04.13 |