코드 작성 속도가 문제라고 생각했다면 더 큰 문제가 있는 것이다
목차
개요
Andrew Murphy가 AI 코딩 도구가 개발 생산성을 40% 높인다는 주장에 의문을 제기하는 글을 발표했다. 저자는 실제 병목이 코드 작성 속도가 아니라 조직의 비효율적인 프로세스에 있다고 주장한다. Goldratt의 제약 이론을 소프트웨어 개발에 적용하여, 병목이 아닌 단계를 최적화하면 시스템 전체가 오히려 더 느려진다는 점을 설명한다.
배경
AI 코딩 도구의 등장과 함께 “개발자 생산성 40% 향상”이라는 수치가 자주 인용되고 있다. 많은 조직이 이를 근거로 AI 코딩 어시스턴트를 도입하여 코드 출력 속도를 높이려 한다. 하지만 이 최적화 전략이 근본적으로 잘못되었으며 오히려 더 심각한 문제를 만든다는 것이 저자의 핵심 주장이다.
핵심 내용
제약 이론의 적용
Eli Goldratt의 1984년 저서 The Goal에서 소개된 제약 이론(Theory of Constraints)이 핵심 이론적 기반이다. “모든 시스템에는 정확히 하나의 제약, 하나의 병목이 있다. 전체 시스템의 처리량은 그 병목의 처리량에 의해 결정된다.”
핵심 통찰은 이것이다. 병목이 아닌 단계를 최적화하면 더 빠른 시스템이 아니라 더 망가진 시스템을 얻게 된다. A 스테이션이 더 빨리 생산하지만 병목인 B 스테이션이 같은 속도를 유지하면, 스테이션 사이에 재고가 쌓이고 리드 타임과 혼란이 증가한다.
AI로 코드를 더 빨리 쓸 때 발생하는 문제들
개발자가 PR을 더 빨리 생산하지만 이후 단계에서 다음과 같은 연쇄 문제가 발생한다.
리뷰 병목이 나타난다. 리뷰어 수는 3배가 되지 않았는데 PR이 며칠에서 몇 주씩 대기한다. 컨텍스트 손실이 일어난다. 리뷰 시점에 개발자가 자신의 코드를 잊어버린다. 품질이 저하된다. 볼륨 때문에 리뷰가 형식적으로 처리된다. WIP가 폭발한다. 진행 중인 작업은 늘어나지만 완료되는 것은 없다.
결과적으로 “더 많은 코드를 생산하지만 더 적은 소프트웨어를 출시하게 된다.”
코드 이해도 붕괴도 심각한 위험이다. AI가 작성한 코드를 아무도 완전히 이해하지 못한다. “작성”한 사람은 실제로 프롬프트를 입력하고 훑어보고 한 번 실행했을 뿐이다. 새벽 2시에 프로덕션이 멈추면 온콜 엔지니어도 프롬프터도 코드를 설명할 수 없어 장애 대응 범위가 확대된다.
실제 5가지 병목
첫째, 불명확한 요구사항이다. 팀이 추측에 기반하여 잘못된 기능을 만든다. 한 팀이 Slack 메시지를 의역하여 6주간 기능을 개발했는데, 해당 잠재 고객은 구매하지 않았고 11명만 사용했으며 그 중 9명은 내부 QA였다. 코드를 더 빨리 쓰면 “실패 지점에 더 빨리 도착”할 뿐이다.
둘째, 코드가 “완료”된 이후의 모든 것이다. 코드 작성은 전체 전달 여정의 약 20%에 불과하다. 나머지 80%는 PR 리뷰, CI/CD 파이프라인, 스테이징 환경, QA, 보안 리뷰, 프로덕트 승인, 배포 윈도우, 카나리 롤아웃 등에서의 대기다. 코딩이 한 오후 만에 끝난 기능이 프로덕션까지 두 달이 걸린 사례가 있었다.
셋째, 공포 기반 배포 문화다. 배포가 무서워서 변경사항을 더 큰 릴리스로 묶게 되고, 이것이 리스크를 증가시켜 공포를 강화하는 악순환이 발생한다. 더 빠른 코드 출력은 팀이 출시할 가능성을 오히려 낮춘다.
넷째, 출시 후 피드백 부재다. 출시 후 기능이 의도한 문제를 해결했는지 측정하지 않는다. 이것이 다음 기능에 대한 추측을 영속시킨다.
다섯째, 조직 캘린더 병목이다. 회의, 승인, 의사결정자의 휴가 등 조정 문제가 발생한다. “휴가 중인 누군가와의 회의를 기다리고 있다”는 상황이 반복된다.
제안된 해결책
저자는 다섯 가지 해결책을 제안한다.
| 해결책 | 설명 |
|---|---|
| 밸류 스트림 매핑 | 아이디어에서 프로덕션까지의 흐름을 추적하고 단계 간 대기 시간을 기록 |
| 사이클 타임 측정 | PR 수나 스토리 포인트가 아닌, 커밋에서 사용자 전달까지의 시간을 측정 |
| 대기 상태 제거 | 리뷰 프로세스 개선, 승인 자동화, 필수 회의 축소 |
| WIP 제한 | 새 작업 시작 전에 기존 작업 완료, 컨텍스트 스위칭 최소화 |
| 실무자 의견 듣기 | 개발자들이 이미 병목을 알고 있으며 일상적으로 논의하고 있음 |
의미와 시사점
이 글은 AI 코딩 도구 도입의 맹점을 정확히 짚고 있다. 코드 생산 속도를 높이는 것이 전체 소프트웨어 전달 속도를 높이는 것과 동일하지 않다는 점은 많은 조직이 간과하는 사실이다. 특히 제약 이론을 소프트웨어 개발에 적용한 분석은 AI 도구 도입 전략을 재고하게 만든다.
AI 코딩 도구의 가치를 부정하는 것이 아니라, 도구 도입 전에 조직의 실제 병목을 먼저 파악해야 한다는 것이 핵심 메시지다.
결론
코드 작성 속도는 결코 진짜 문제가 아니었다. 경쟁 우위는 코드를 가장 빨리 쓰는 팀이 아니라, 무엇을 만들지 파악하고 정확하게 만들어 사용자에게 전달하는 팀에게 돌아간다. “병목을 고쳐라. 그것은 키보드가 아니다.”