AI 코딩은 어디에나, 그러나 확신은 아직
AI 코딩은 더 이상 실험이 아니다. MIT Technology Review가 2025년 12월 15일 공개한 기획에 따르면, 개발자의 65%가 매주 AI 코딩 도구를 쓰고(Stack Overflow 2025), 상위 모델은 표준 벤치마크에서 버그의 70% 이상을 푼다 — 1년 전 33%에서 급등했다. 그런데 같은 글이 던지는 질문은 정반대다. 이 폭발적 채택이 정말 ‘생산성 향상’으로 이어졌는가. 경영진의 장담과 현장의 증거 사이에 큰 틈이 있다는 것이다.
"You remember the jackpots. You don't remember sitting there plugging tokens into the slot machine for two hours."Mike Judge, MIT Technology Review
무슨 일인가
Microsoft·Google 임원은 자사 코드의 25%가 AI로 작성된다고 말하고, 초기 벤더 연구는 20~55% 속도 향상을 제시한다. 그러나 METR 연구에서 숙련 개발자는 AI 도구로 오히려 19% 느려졌고, GitClear 데이터상 ‘오래 가는(durable) 코드’는 2022년 이후 10%가량만 늘었다. 기사는 AI가 보일러플레이트·테스트·버그 수정 같은 좁은 작업엔 강하지만, 숙련자 업무의 대부분인 복잡한 통합 문제에선 제한적 문맥창과 일관성 부족으로 흔들린다고 짚는다. 게다가 AI 결함의 90% 이상은 명백한 버그가 아니라 미묘한 ‘코드 냄새(code smell)’라, 리뷰에서 걸러내기 어렵다.
여러 시각
같은 흐름을 더 멀리서 보면 ‘도구’가 아니라 ‘조직’의 문제가 보인다.
- MIT Technology Review(에이전트 리포트) — 변곡점의 관점. 에이전틱 AI를 오픈소스·DevOps에 이은 세 번째 전환으로 보고, 평균 37%의 속도 향상을 기대한다. 다만 “완전한 효과를 얻으려면 때로 고통스러운 조직·프로세스 변화가 필요하다”고 못 박는다 — 기술만으론 부족하다는 것.
- 현장 데이터(METR·GitClear) — 회의의 관점. 잭팟의 기억은 또렷하지만 토큰을 허비한 두 시간은 잊힌다. 개인의 ‘체감 향상’과 측정된 ‘실제 향상’ 사이의 인지 편향을 경고한다.
왜 중요한가
두 자료를 겹치면 결론은 분명하다 — AI 코딩의 성패는 모델 성능보다 ‘조직의 엔지니어링 규율’에 달렸다. AI는 좋은 관행도 나쁜 관행도 똑같이 증폭한다. 주니어가 쏟아내는 코드량이 시니어 리뷰 용량을 포화시키면 병목은 오히려 심해지고, 기술부채는 더 빨리 쌓인다. ‘얼마나 빨리 짜는가’가 아니라 ‘얼마나 빨리 검증·통합·유지하는가’가 진짜 지표가 됐다는 뜻이다.
실무 적용
- AI 생산성은 라인 수·속도가 아니라 ‘리뷰 통과율·재작업률·결함 밀도’로 측정해, 잭팟 편향에 속지 않는다.
- AI가 낸 코드는 프로젝트 컨벤션 준수와 통합 영향을 우선 검토한다 — 미묘한 코드 냄새는 자동 린트·테스트로 1차 거른다.
- 주니어 산출량이 시니어 리뷰를 포화시키지 않도록, 생성-검증 비율과 리뷰 SLA를 팀 단위로 명시한다.
Kenny의 관점
프런트엔드와 PM·QA를 오가며 AI를 매일 쓰는 입장에서 이 기사는 과장이 아니라 균형추다. 나는 AI를 ‘초안 생성기’로 쓰되, 검증 책임은 끝까지 사람이 진다는 선을 분명히 한다. 특히 미묘한 코드 냄새는 속도의 대가로 슬그머니 쌓이므로, 테스트·타입·린트라는 ‘자동 안전망’을 먼저 깔아 두는 것이 AI 활용의 전제 조건이다. 잭팟의 기억보다 두 시간의 토큰을 기록하는 것 — 결국 측정만이 체감의 환상을 이긴다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — MIT Technology Review ↗