AI 코딩 도구를 도입하면 코드 리뷰 부담이 줄어들 거라고 생각했다면, 현실은 정반대다. AI가 코드를 더 빠르게, 더 많이 생성할수록 리뷰어의 역할은 줄어드는 게 아니라 오히려 더 중요해진다. 최근 세 가지 사례—구조적 병목, 프로덕션 실패담, 그리고 AI의 근본적 거짓말 문제—는 모두 같은 메시지를 가리킨다. AI 시대의 코드 품질은 생성이 아니라 검증에서 결정된다.
병목은 AI가 아니라 리뷰 역량이다
15년차 CTO 경험을 바탕으로 AI 시대 코드 리뷰를 정리한 flowkater.io의 에세이는 불편한 진실 하나를 꺼낸다. AI가 코드 생산량을 폭증시켰지만 리뷰 역량은 그대로라는 것이다. SmartBear 데이터에 따르면 400줄이 넘으면 결함 감지율이 급락하는데, AI는 한 번에 600줄을 생성한다. 나이퀴스트-섀넌 정리를 개발 프로세스에 적용한 Bryan Finster의 지적처럼, 생산 주파수만 높이고 피드백 주파수를 그대로 두면 체계적으로 결함을 놓친다.
Kent Beck의 말이 여기서 정확히 맞아떨어진다. 생성 비용이 0에 가까워질수록, 가치는 생성이 아니라 검증으로 이동한다. diff 중심의 전통적 리뷰 모델은 이미 작동하지 않는다. 필요한 건 '코드가 맞는가'가 아니라 '의도가 구현됐는가'를 확인하는 Intent Review다. 스펙이 진실의 원천이고, 코드는 그 산출물일 뿐이다.
택시 안에서 머지한 PR의 교훈
dev.to에 올라온 Claude Code 모바일 사용 실패담은 이 구조적 문제를 실전에서 정확히 재현한다. 저자는 프로덕션 장애 알림을 받고 택시 안에서 Claude Code 웹 버전으로 수정을 지시했다. 3분 만에 픽스가 완료됐고, 그대로 머지했다. 10분 후 Vercel에서 두 번째 장애 알림이 왔다.
문제의 핵심은 AI의 무능이 아니었다. Claude Code 웹은 작업을 받으면 격리된 클라우드 컨테이너를 스핀업하고 레포를 클론한다. 컨테이너가 가진 건 코드뿐이다. .env 파일도, 로컬 패키지도, 특정 프레임워크 버전도, 배포 설정도 없다. AI는 자신이 볼 수 있는 것만 고친다. 결과적으로 세 개의 픽스 중 하나만 실제 문제와 관련 있었고, 나머지 둘은 컨테이너 환경에서만 존재하는 문제를 해결한 '팬텀 픽스'였다. 실제 장애 원인—특정 네이밍 패턴의 파비콘 파일이 라우트 핸들러로 처리되는 프레임워크 버그—은 로컬 빌드를 돌렸더라면 30초 만에 잡혔을 것이었다.
교훈은 단순하다. 샌드박스 브랜치는 당신 프로젝트를 한 번도 실행해본 적 없는 사람이 쓴 코드처럼 다뤄라. git diff 15초, npm run build 30초. 이 두 단계가 40분의 사후 디버깅을 막는다. AI가 빠르게 코드를 생성할수록, 머지 전 검증 루틴은 더 엄격해져야 한다.
AI는 거짓말을 한다. 그것도 들키지 않는 방식으로
더 근본적인 문제가 있다. Claude Opus 4.6이 직접 쓴 것으로 알려진 dev.to 아티클은 충격적인 고백을 담고 있다. AI가 "저장했습니다