안녕하세요. 정리하는 개발자 워니즈입니다.
AI 도구를 도입하고 나면 누군가는 반드시 묻습니다. “그래서 얼마나 빨라졌어요?”
저도 답하기 어려웠습니다. 분명 코드는 빨리 나오는데 일이 끝나는 속도는 크게 달라지지 않았거든요. 그동안은 감각의 문제라고 생각했습니다.
그런데 최근에 숫자 하나를 보고 이유를 알았습니다.
개발자가 코드 작성에 쓰는 시간은 전체의 14%다.
— 2025년 Microsoft 엔지니어 450명 이상 조사
AI 코딩 생산성을 코딩 속도로 재고 있었으니 답이 안 나온 겁니다. 전체의 14%를 재고 있었으니까요.
그러면 본격적으로 정리해보도록 하겠습니다.
1. 왜 답이 안 나오는가 — 산술이 안 맞습니다
코드 작성이 전체의 14%라면, 나머지 86%는 원래부터 코딩이 아니었습니다.
설계를 고민하고, 남의 코드를 읽고, 왜 안 되는지 찾고, 리뷰를 기다리고, 회의하고, 배포를 지켜보는 시간입니다.
여기서 계산이 나옵니다.
| 코드 작성 시간 | 14% |
| AI로 그 부분을 2배 빠르게 하면 | 14% → 7% |
| 전체 절감 | 7% |
코딩 속도를 두 배로 올려도 전체는 7% 줄어듭니다.
7%는 하루 8시간 중 30분입니다. 회의 하나 길어지면 사라지는 양이죠. 측정에 안 잡히는 게 당연합니다.
같은 자료에 좋은 근무일의 코딩 시간이 18%, 나쁜 근무일이 11%라는 수치도 있습니다. 하루가 잘 풀리든 안 풀리든 코드를 치는 시간은 원래 그 정도입니다.
2. 그럼 무엇을 재야 하는가
리뷰 대기 시간입니다.
AI 채택도가 높은 팀을 조사한 결과가 이 방향을 가리킵니다.
| 지표 | 변화 |
|---|---|
| 처리한 작업·병합 PR 수 | 증가 ✅ |
| PR 리뷰 시간 | 91% 증가 |
| PR 크기 | 154% 증가 |
| 버그 수 | 9% 증가 |
그리고 이 숫자가 핵심입니다. AI가 작성한 PR은 리뷰어가 집어들기까지 사람이 쓴 것보다 평균 4.6배 오래 기다립니다.
만드는 14%가 빨라지면 그 뒤에 줄이 생깁니다. 속도가 사라진 게 아니라 다음 단계로 옮겨간 것이고, 코딩 시간만 재면 이 이동이 보이지 않습니다.
생각해보면 당연합니다. PR이 2.5배 커졌는데 리뷰할 사람 수는 그대로입니다. 만드는 쪽만 빨라지면 그다음 단계에 줄이 생깁니다.
AI 도입 효과를 코딩 시간으로 재면 이 이동이 통계에 잡히지 않습니다. 코딩 시간은 줄었고 리뷰 대기는 늘었는데, 둘을 따로 보면 “빨라졌다”만 남습니다.
이 얘기는 AI 코딩 도구, 빨라진 건 맞는데 어디가 느려졌을까에서 더 다뤘습니다.
3. 제 경우에도 그랬습니다
에이전트를 여러 개 굴리면서 산출물은 확실히 늘었습니다. 문서 초안, 스크립트, 조사 자료가 동시에 만들어집니다.
그런데 늘어난 만큼 읽어야 했습니다. 혼자 짰다면 짜는 동안 검증이 끝나 있는데, 받은 것은 읽고 판단해야 합니다. 그 부담이 전부 한 사람에게 몰렸습니다. (AI 에이전트로 혼자 일하기)
하네스를 절반 걷어낸 것도 같은 이유였습니다. 코딩을 더 돕는 도구를 추가하는 것보다, 판단과 검증 쪽 부담을 줄이는 게 실제로 남았습니다.
세 경우 모두 14%가 아니라 86% 쪽에서 일이 벌어지고 있었습니다.
공통점이 하나 있습니다. 문제가 생긴 곳은 전부 “만든 뒤”였습니다. 만드는 과정은 순조로웠고, 그 결과물을 읽고 판단하고 책임지는 단계에서 시간이 갔습니다.
4. AI 도입 효과, 이렇게 재기로 했습니다
AI 도입 효과를 물을 때 저는 이제 코딩 시간을 묻지 않습니다. 대신 이 셋을 봅니다.
| 측정할 것 | 왜 |
|---|---|
| PR이 올라간 뒤 리뷰까지 걸린 시간 | 병목이 여기로 이동했다 |
| PR 하나의 평균 크기 | 커질수록 리뷰가 밀린다 |
| 되돌린 횟수(롤백·재작업) | 빨리 만들고 다시 만드는 건 절감이 아니다 |
세 지표 모두 코딩 속도와 무관하게 움직입니다. 그리고 도구를 바꿨을 때 실제로 값이 변합니다.
반대로 “AI가 코드를 몇 줄 썼는가”는 재봐야 소용없습니다. 줄 수가 늘어난 만큼 읽을 것도 늘어나니까요.
한 가지 덧붙이면, 이 지표들은 도입 전에 먼저 재둬야 의미가 있습니다. 도입 후에 재면 비교 대상이 없어 “느낌”으로 판단하게 됩니다. AI 도입 효과를 두고 논쟁이 갈리는 이유가 대개 여기 있습니다 — 양쪽 다 기준선이 없습니다.
5. AI 코딩 생산성 — 정리
- 코드 작성은 개발 시간의 14%다. 좋은 날 18%, 나쁜 날 11%
- 그 14%를 2배 빠르게 해도 전체는 7%만 줄어든다. 하루 30분이라 측정에 안 잡힌다
- 속도는 사라진 게 아니라 리뷰로 이동했다. 리뷰 시간 91%↑, PR 크기 154%↑
- 그래서 재야 할 것은 코딩 시간이 아니라 리뷰 대기 시간·PR 크기·재작업 횟수다
- “AI가 개인을 10배 개발자로 만든다”는 기대는 애초에 산술이 안 맞는다
당장 해보실 수 있는 것 하나를 남기겠습니다. 최근 PR 다섯 개를 열어 이것만 확인해보세요.
올린 시각과 첫 리뷰가 달린 시각의 차이
여기가 코딩 시간보다 길다면, AI 도구를 더 붙여도 체감은 달라지지 않습니다. 줄여야 할 곳은 그쪽입니다.
읽어주셔서 감사합니다. 팀에서 어떤 지표를 보고 계신지 궁금합니다.
참고
- 소프트웨어 엔지니어링과 생성형 AI에 관한 8가지 오해 (GeekNews)
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv)