Vibe Coding의 함정 — METR 연구를 컴포넌트팀 자체 데이터로 검증한 결과

도입 배경

직전 글에서 컴포넌트팀이 5개 클라이언트 프로젝트를 Claude Code로 병렬 운영하면서 처리량이 2.3배 늘었다고 적었습니다. 그런데 솔직히 말하면 글을 발행하기 전 한 가지가 마음에 걸렸습니다.

2025년 METR이 발표한 연구에서 경험 많은 개발자가 AI 도구를 사용했을 때 실제로는 19% 더 오래 걸렸지만, 본인들은 20% 더 빨랐다고 믿었다는 결과가 있었습니다. AI가 전 세계 코드의 41%를 생성하고 Cursor가 12개월 만에 ARR $1M에서 $500M로 성장한 시기에, "AI 도구는 모두를 더 빠르게 만든다"는 명제는 누구도 의심하지 않는 분위기였습니다. METR 결과가 그 분위기에 정면으로 반하는 데이터였던 거죠.

그래서 자체 검증을 진행했습니다. 컴포넌트팀에서도 같은 현상이 일어나고 있는가, 아니면 우리는 다른가를 확인하기 위해서였습니다.

이를 위해 다음 4가지 측정 항목을 정의했습니다.

• 동일 난이도 이슈를 AI 사용 그룹과 미사용 그룹이 처리한 시간 비교
• 개발자 본인의 체감 속도 vs 실제 측정 속도의 차이
• AI 사용 시 PR 리뷰 시간·롤백률·버그 발생률 변화
• 경력 구간(주니어/미들/시니어)별 효과 차이

검증은 2026년 1~3월, 3개월간 진행했습니다.

검증 방법

5개 프로젝트에서 처리된 132개 이슈를 다음 기준으로 분류했습니다.

• 난이도 — XS(1시간 이하) / S(반나절) / M(1~2일) / L(3일 이상)
• AI 사용 여부 — 코드 작성의 50% 이상을 AI가 담당한 경우 "AI 사용"으로 분류
• 개발자 경력 — 주니어(1~2년) / 미들(3~5년) / 시니어(6년 이상)
• 이슈 유형 — 버그 수정 / 기능 추가 / 리팩터링 / 문서화

각 이슈는 작업 시작·종료 시각, 본인이 추정한 소요 시간, 실제 소요 시간, 머지 후 7일 이내 롤백 여부를 모두 기록했습니다.

핵심은 이슈를 처음 받았을 때 본인이 추정한 시간과 실제 시간을 모두 기록한 부분이었습니다. METR 연구의 가장 충격적인 발견은 "더 빠르다고 느끼지만 실제로는 느리다"였기 때문에, 이 자기 인식 격차를 측정하는 게 핵심이었습니다.

검증 결과

3개월간 132개 이슈의 데이터에서 다음 패턴이 나왔습니다.

1. 전체 평균: AI 사용 그룹이 27% 빨랐음

전체로만 보면 METR 결과와 정반대로 보였습니다. AI 사용 그룹이 평균적으로 더 빠르게 작업을 마쳤습니다. 그러나 이슈 유형·경력·난이도별로 쪼개보자 그림이 완전히 달라졌습니다.

2. 경력별 차이가 극적

• 주니어(1~2년차): AI 사용 시 42% 빠름
• 미들(3~5년차): AI 사용 시 18% 빠름
• 시니어(6년차 이상): AI 사용 시 9% 느림

시니어 구간에서 METR 연구와 일치하는 패턴이 재현됐습니다. 시니어들이 자기 머릿속에 이미 가진 코드베이스 모델을 AI에 다시 설명하는 비용이 컸고, AI가 생성한 코드를 검토·수정하는 시간이 직접 작성하는 시간을 초과한 케이스가 많았습니다.

3. 이슈 유형별 차이도 극적

• 신규 기능 추가: AI 사용 시 38% 빠름
• 버그 수정: AI 사용 시 5% 빠름 (거의 차이 없음)
• 미묘한 리팩터링: AI 사용 시 22% 느림
• 문서화: AI 사용 시 51% 빠름

가장 인상적이었던 건 리팩터링이었습니다. AI가 코드 구조를 "개선"하면서 도메인 의미를 잃어버리는 경우가 빈번해, 시니어가 직접 했다면 30분 걸렸을 작업이 AI 검토·수정에 1시간 이상 들어갔습니다.

4. 자기 인식 격차

전체 응답자에게 작업 직후 "AI 덕분에 얼마나 빨라졌다고 느끼는가"를 물었을 때, 평균 응답은 47% 빨라졌다였습니다. 실제 측정치는 27%였고, 시니어 구간에서는 본인은 31% 빨라졌다고 느꼈지만 실제로는 9% 느려졌습니다. METR 연구의 자기 인식 격차 패턴이 거의 그대로 재현됐습니다.

5. 롤백률

AI 사용 그룹의 7일 이내 롤백률이 6.1%, 미사용 그룹은 2.4%였습니다. AI가 만든 코드는 빠르게 작성되지만 더 자주 되돌아왔습니다.

정책 변경 사항

이 데이터를 본 직후 컴포넌트팀은 AI 도구 사용 정책을 다음과 같이 조정했습니다.

시니어의 미묘한 리팩터링 작업은 AI 위임을 기본 비활성화

시니어 본인이 명시적으로 "AI에 맡기겠다"고 판단한 경우에만 사용. 기본값은 직접 작성.

신규 기능·문서화·반복 작업은 AI 사용을 적극 권장

가장 효과가 명확한 영역에 집중. 주니어가 신규 기능을 작업할 때는 AI 사용을 사실상 의무화했습니다.

PR 머지 전 체감 시간·실제 시간을 기록하는 셀프 측정 의무화

자기 인식 격차를 매번 인식하게 만드는 메커니즘. 이게 가장 효과적인 가드레일이었습니다. "내가 AI 덕분에 빨라졌다고 느꼈는데 실제로는 비슷했다"는 경험이 누적되면서 과신이 줄어들었습니다.

롤백 발생 시 AI 사용 여부를 사후 분석에 필수 기록

AI가 만든 코드의 어떤 패턴이 자주 롤백되는지 추적해 다음 분기 정책에 반영하기 위해서였습니다.

트러블슈팅: 검증 과정에서 만난 4가지 함정

1. "AI 사용" 정의의 모호함

처음에는 "AI 사용 여부"를 단순 yes/no로 기록했는데, 데이터가 쓸모없는 수준으로 노이즈가 많았습니다.

원인: Cursor의 Tab 자동완성으로 30%만 AI가 작성한 케이스와, Claude Code에 작업 전체를 위임한 케이스가 같은 카테고리로 묶였습니다. 두 작업의 성격이 완전히 다른데 한 데이터로 합쳐진 셈이었습니다.

해결: "AI 작성 비중"을 0%/30%/50%/80%/100% 5단계로 분류하고, 본 분석에서는 50% 이상을 "AI 사용"으로 정의했습니다. 이 분류 기준을 바꾼 뒤에야 의미 있는 패턴이 보였습니다.

2. 자기 보고 데이터의 신뢰성 문제

개발자들이 "AI를 거의 안 썼다"고 보고한 작업의 깃 로그를 추적하니 Cursor Composer 호출 기록이 다수 발견됐습니다. 본인이 의식하지 못하는 사용까지는 자기 보고로 잡히지 않았습니다.

원인: Tab 자동완성이 너무 자연스럽게 흐름에 녹아 있어서, 사용자 본인이 "이걸 AI가 쓴 건가" 자체를 인식하지 못했습니다. Cursor의 Tab 자동완성이 다음 몇 글자가 아니라 전체 논리 블록을 예측하는 수준으로 발전한 시점에서, 사용 인식 자체가 흐릿해진 결과입니다.

해결: Cursor·Claude Code 사용 로그를 셸 히스토리·에디터 텔레메트리에서 자동 수집해 자기 보고와 교차 검증했습니다. 이 후속 데이터에서 자기 인식 격차가 더 크게 나타났습니다.

3. 표본 편향 문제

초기 분석에서 시니어 구간이 "AI 사용 시 30% 느림"으로 나왔는데, 실제로는 시니어들이 어려운 이슈만 골라서 AI에 맡긴 영향이 컸습니다.

원인: 작업 난이도와 AI 사용 여부가 독립 변수가 아니었습니다. 시니어는 자기가 직접 하기 귀찮은 어려운 이슈를 AI에 맡기는 경향이 있어, 데이터상으로는 "AI가 시니어를 느리게 만든 것"처럼 보였습니다.

해결: 난이도 카테고리(XS/S/M/L)를 통제 변수로 두고 같은 난이도 안에서만 비교하도록 분석을 다시 했습니다. 통제 후에도 시니어의 9% 둔화는 유지됐지만 30%보다는 훨씬 작은 수치였습니다.

4. 데이터 발표 시의 정치적 압박

검증 결과를 사내 발표할 때 "AI 회의론자"로 분류되는 시니어 그룹과 "AI 옹호자"로 분류되는 주니어 그룹의 반응이 양극화됐습니다. 데이터를 객관적으로 제시했음에도 각자 자기 진영의 결론을 강화하는 방식으로 해석했습니다.

원인: 결과를 한 줄 요약("AI 도구가 시니어를 느리게 만든다" vs "AI 도구가 주니어를 빠르게 만든다")으로 받아들이면서 미묘한 조건들(이슈 유형, 작업 종류)이 사라졌습니다.

해결: 발표 자료에서 한 줄 요약을 의도적으로 제거하고, "어떤 조건에서 누가 빨라지는가"의 매트릭스만 제시했습니다. 정책 변경도 한 번의 결정이 아니라 분기별 재측정·재조정을 전제로 한 살아있는 정책으로 운영하기로 했습니다.