CUBE.ai

바이브코딩

20% 빨라진 느낌, 19% 느려진 실제 — 바이브코딩의 체감 함정

2026.08.30

목차

  1. 이 실험은 대체 무엇이었나?
  2. 사라진 19%는 어디로 갔을까?
  3. 그런데 왜 빨라진 것처럼 느껴질까?
  4. 내 체감은 믿을 만한가?
  5. 이 글이 하려는 말이 아닌 것은?

전체 지도

예측 24% → 체감 20% → 실제 −19% 막대그래프

오늘은 지도랄 것도 없습니다. 막대 세 개가 전부니까요.

  • 실험 예측: +24% 빨라질 것이다
  • 실험 체감: +20% 빨라졌다
  • 실제 측정: −19% 느려졌다

본인들조차 끝나고도 몰랐습니다.


1. 이 실험은 대체 무엇이었나?

지도의 맨 왼쪽 막대, 그러니까 "예측 24%"가 찍힌 그 시점부터 보겠습니다.

METR이 2025년 2~6월에 진행한 무작위 대조 실험입니다. 참가자는 숙련 개발자 16명. 남의 코드가 아니라 자기가 수년간 유지보수해온 대형 오픈소스 레포에서 — 평균 스타 2만 개 이상, 코드 100만 줄 이상입니다 — 실제 이슈 246건을 처리했습니다.

주사위 무작위 배정 → A/B 두 레인 → 16명·246이슈

핵심은 여기입니다. 이슈마다 AI 사용 허용/금지를 무작위로 배정했어요. "AI 써보니 어떠셨어요?"라고 나중에 물어본 설문이 아니라, 같은 사람이 같은 레포에서 두 조건을 번갈아 겪게 만든 실험입니다. 도구는 당시 최전선이던 Cursor Pro + Claude 3.5/3.7 Sonnet이었고요.

그리고 여기서 정직하게 하나 짚고 가겠습니다. 16명, 자기가 훤히 아는 성숙한 코드베이스, 2025년 상반기 모델. 연구진 스스로 "우리 개발자와 레포가 소프트웨어 개발의 다수를 대표한다고 주장하지 않는다"고 못 박았습니다. 이 조건을 지우고 인용하는 순간, 이 연구는 분석이 아니라 낚시가 됩니다.

참고: METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

2. 사라진 19%는 어디로 갔을까?

타이핑이 줄었으면 시간도 줄어야 정상입니다. 그런데 시간의 주인만 바뀌어 있었습니다.

화면 녹화를 뜯어보니, AI를 쓸 때 개발자는 직접 코드를 치고 정보를 찾는 시간이 줄어든 대신 이런 일을 하고 있었습니다. 프롬프트를 쓰고, 응답을 기다리고(작업 시간의 약 4%), 돌아온 코드를 읽고 정리하고(약 9%), 그리고 그냥 멍하니 있었습니다. 심지어 Cursor 제안의 수용률은 44%에 못 미쳤고, 참가자 전원이 AI 코드를 손봐야 했다고 답했습니다. 절반 이상은 "대폭 수정"이었고요.

사라진 19%: 타이핑이 줄고 대기·검증이 늘었다

요리로 치면 재료를 대신 썰어주는 보조가 생긴 겁니다. 손은 편해졌죠. 그런데 썰어온 걸 매번 확인하고 절반은 다시 썰어야 한다면, 저녁 식사는 늦어집니다.

타이핑은 줄었는데, 그 빈자리를 대기와 검증이 채웠습니다.

참고: METR 논문 원문(PDF) · The Register — AI coding tools make developers slower but they think they're faster

3. 그런데 왜 빨라진 것처럼 느껴질까?

여기가 진짜 이상한 대목입니다. 느려졌다는 것보다, 끝나고 나서도 몰랐다는 게 훨씬 무섭거든요. 가설 세 개.

왜 빨라진 것처럼 느낄까: 15분의 인지적 무게 차이

첫째, 우리는 힘든 것과 오래 걸리는 것을 혼동합니다. 빈 화면을 노려보는 15분은 영원처럼 길고, AI 응답을 기다리는 15분은 그냥 15분입니다. 시계로는 같은 시간인데 체감 무게가 다릅니다.

둘째, 첫 결과물이 빨리 나옵니다. 5분 만에 화면에 뭔가 뜨면 뇌는 "거의 다 됐다"로 저장해버립니다. 그 뒤에 붙는 40분의 수정은 기억에서 흐려지고요. 영화로 치면 오프닝은 선명한데 중반부는 통째로 기억이 안 나는 상태입니다.

셋째, 시작이 쉬워져서 부담이 줄었습니다. 그런데 우리는 줄어든 부담을 줄어든 시간이라고 착각합니다.

한 문장으로 정리하겠습니다. 우리는 소요 시간이 아니라 인지적 피로를 측정하고 있었습니다.

4. 내 체감은 믿을 만한가?

이 대목에서 "어… 나도 그런데?" 싶으셨다면, 훈계 대신 실험을 하나 권해드립니다. 도구는 필요 없습니다.

자기 실험 가이드: 체중계처럼 재는 생산성

  1. 다음 작업 5개만 시작·종료 시각을 적어두세요. 메모장이면 충분합니다.
  2. 그중 절반은 AI 없이 해보세요.
  3. 일주일 뒤 비교하세요. 느낌이 아니라 숫자로.

체중계 없이 다이어트하는 사람은 없습니다. 유독 생산성만 감으로 관리하고 있었을 뿐입니다.

5. 이 글이 하려는 말이 아닌 것은?

"AI 쓰지 마라"가 아닙니다. 실험 조건은 특수했고, 모델은 그 뒤로 달라졌습니다.

이 글이 하려는 말이 아닌 것: 측정 ≠ 금지

실제로 METR은 2026년 2월에 후속 실험 설계를 바꾸겠다고 발표했습니다. 이유가 흥미로운데요, 개발자들이 AI 없이 하는 조건 자체를 거부해서 실험이 성립하지 않았다는 겁니다. 참가자의 30~50%가 "AI 없이는 하기 싫은 작업"을 아예 제출하지 않았고, 그래서 새 데이터는 선택 편향에 오염됐습니다.

이 글이 하려는 말은 하나입니다. 자기 생산성에 대한 감각은 신뢰할 수 없다. 그래서 측정이 필요하다.

체감이 못 미덥다면 남는 건 절차뿐입니다. 그 절차 이야기는 규칙 파일(3편), 리뷰 체크리스트(1편), 디버깅 3단계(6편)로 이어집니다.

참고: METR — We are Changing our Developer Productivity Experiment Design · ZDNet Korea — "개발자들, AI 쓰면 더 빨라진다?"…실제로는 19% 더 느렸다


댓글

불러오는 중입니다…