병목이 이동했다
"코드 작성은 이제 저렴하다." Simon Willison이 에이전틱 엔지니어링 패턴 가이드에서 꺼낸 이 한 문장이 Hacker News를 흔들었다. Claude Code, OpenAI Codex 같은 코딩 에이전트가 본격적으로 팀에 스며들면서, 개발 워크플로우의 병목이 조용히 자리를 바꿨다. 예전엔 '어떻게 빠르게 코드를 만드느냐'가 문제였다. 지금은 '쏟아지는 코드를 누가, 어떻게 검토하느냐'가 진짜 문제다.
dev.to에 실린 The AI Code Review Bottleneck 분석은 이 현상을 정확히 짚는다. AI 도구를 쓰는 개발자는 이제 5분 만에 이벤트 드리븐 아키텍처 스캐폴딩을 뽑아낼 수 있다. 하지만 그걸 디버깅하고 검토하는 데 걸리는 시간은 예전과 똑같다. 생성은 빨라졌는데 판단은 그대로다. 결과적으로 리뷰어—특히 시니어 개발자나 테크 리드—가 팀 전체의 발목을 잡는 병목이 된다.
Hacker News 스레드에서 한 개발자의 고백이 이 상황을 압축한다. "팀원들이 구조를 이해하지 못한 채 '작동하니까 됐잖아' 식으로 접근한다. PR은 점점 커지고, 나는 병목이 된다." 이 말은 단순한 푸념이 아니다. AI가 코드 생성 비용을 낮추면서 PR당 변경 규모가 커지고, 리뷰 비용은 오히려 급등하는 역설이 이미 현장에서 벌어지고 있다는 신호다.
'작동하면 됐잖아'가 왜 위험한가
이 문제를 조직 문화 이슈로만 보면 절반만 맞다. 기술적으로도 구조적 위험이 크다. LLM이 만드는 코드에는 고유한 취약점이 있다. 에이전틱 엔지니어링 패턴 스레드에서 여러 개발자가 지적한 '자기충족적 테스트' 문제가 대표적이다. AI가 생성한 테스트가 실제로는 아무것도 검증하지 않거나, 하드코딩된 값으로 통과하는 경우가 생긴다. 겉으로는 그린 빌드인데 실질적인 보호망이 없는 상태다.
"나쁜 테스트는 없는 것보다 더 위험하다. 한 번 신뢰가 깨지면 전체 테스트 스위트에 대한 믿음이 무너진다." 이 말이 그냥 지나칠 수 없는 이유는, AI 코딩이 가속될수록 이 위험도 같이 가속되기 때문이다. Mutation testing을 활용해 테스트가 실제로 코드 변경을 잡아내는지 검증하는 접근이 거론되는 건 이 때문이다. AI에게 코드 일부를 의도적으로 바꾸게 해서 테스트가 실패하는지 확인하는 방식—이제 이게 품질 관리의 기본 위생이 돼야 한다.
보안 관점은 더 냉정하다. 같은 스레드에서 나온 의견: "코드가 싸다면 리뷰 기준을 낮출 수도 있겠지만, 보안 검토는 절대 생략할 수 없다." AI가 생성한 코드는 학습 데이터에 포함된 취약한 패턴을 그대로 재현할 수 있다. 생성 속도가 빨라질수록 보안 취약점이 코드베이스에 스며드는 속도도 빨라진다. 리뷰 품질을 낮추는 방향은 선택지가 아니다.
언어 선택도 리뷰 비용에 영향을 미친다
흥미롭게도 Claude Code로 13개 언어를 비교한 실험 결과(dev.to)가 리뷰 병목 논의에 실용적인 인사이트를 하나 더 얹는다. Ruby, Python, JavaScript가 가장 빠르고 저렴하며 안정적이었다. 정적 타입 언어는 1.4~2.6배 느리고 비쌌다. 특히 Ruby/Steep는 plain Ruby보다 3.2배 느렸다.
이 데이터를 리뷰 관점에서 다시 읽으면 흥미롭다. "정적 타입이 AI 할루시네이션을 막는다" vs "동적 타입이 토큰을 아낀다"는 논쟁에서, 실험 결과는 프로토타이핑 규모에서는 동적 언어의 손을 들어준다. 단 이 결론은 맥락이 중요하다. 강한 타입과 테스트가 갖춰진 코드베이스에서는 Claude Code 성능이 극적으로 향상된다는 현장 증언도 있다. 프로젝트 성숙도와 리스크 허용도에 따라 언어 선택 전략이 달라져야 한다.
리뷰 병목, 어떻게 풀 것인가
그렇다면 팀은 지금 무엇을 해야 하나. 세 갈래로 정리된다.
첫째, 리뷰 인프라에 먼저 투자하라. dev.to 분석의 핵심 권고도 같다. "생성 툴링이 아니라 리뷰 인프라에 투자하라. 코드 리뷰 속도가 지금의 바인딩 컨스트레인트다." 커스텀 린트 규칙, 강한 타입 검사, mutation testing 같은 정적·동적 분석 자동화가 리뷰 전에 조기 피드백을 줄 수 있다. 리뷰어가 구조적 문제가 아니라 의미적 판단에만 집중하게 만드는 것이 목표다.
둘째, 에이전틱 루프 안에 인간 검증 포인트를 설계하라. Hacker News 스레드의 가장 실용적인 제안은 이것이었다. 완전 자율형 에이전트는 테스트를 통과하면서도 암묵적 불변조건을 깨는 경우가 많다. 되돌릴 수 없는 결정 직전에 인간이 개입하도록 루프를 설계하는 것—계획 → 실행 → 테스트/수정 → 리뷰/리팩터 → QA 가이드 생성의 흐름에서 리뷰 단계를 자동화로 대체하는 게 아니라 보강하는 관점이다.
셋째, AI 리뷰어를 부분적으로 활용하되 맥락 세팅에 공을 들여라. AI 코드 리뷰는 리뷰어를 대체하는 것이 아니라 초안 필터로 쓰는 게 현실적이다. 에이전트 기반 리뷰를 도입할 때 가장 중요한 건 맥락 세팅이다. CLAUDE.md 같은 문서로 코드베이스의 암묵적 규칙을 전달하고, rejections.md처럼 '왜 이 접근을 버렸는가'를 기록해 AI가 같은 실수를 반복하지 않도록 하는 방식이 현장에서 효과를 보고 있다.
음성 명령이 병목을 더 키울 수도 있다
Anthropic이 Claude Code에 음성 모드를 추가한 건 생성 속도를 한 단계 더 높이는 신호다. 터미널에서 /voice를 입력한 뒤 "인증 미들웨어 리팩토링해줘"라고 말하면 바로 실행된다. 키보드 입력 마찰이 사라지면 코드 생성 속도는 더 빨라진다. ARR 25억 달러, 주간 활성 사용자 1월 대비 2배—Claude Code의 성장 지표가 보여주는 건, AI 코딩 도구가 이미 팀 워크플로우의 중심에 들어와 있다는 사실이다.
이게 왜 리뷰 병목 맥락에서 중요한가. 생성 인터페이스가 쉬워질수록, 검토 없이 코드베이스에 들어오는 변경의 양도 늘어난다. 음성으로 빠르게 뽑아낸 코드가 동일한 리뷰 파이프라인을 통과해야 한다면, 병목은 더 심해진다. 생성 편의성이 올라갈수록 리뷰 거버넌스를 함께 강화하지 않으면 품질 부채가 쌓이는 속도도 함께 올라간다.
전망: 리뷰는 자동화되는 게 아니라 재설계되어야 한다
"이번엔 AI 붐 주기가 반복될 것 같다. AI가 너무 많은 코드를 생성해서 인간도, AI도 감당 못 하는 상황이 생길 것이다." Hacker News의 이 예측은 냉소가 아니라 경고로 받아들여야 한다. 코드 리뷰가 병목이 된 현재, 이걸 단순히 'AI 리뷰어 붙이기'로 해결하려는 접근은 문제를 한 레이어 뒤로 미루는 것에 불과하다.
더 근본적인 재설계가 필요하다. 리뷰가 무엇을 검증해야 하는지를 다시 정의하고, 자동화가 맡을 영역과 인간 판단이 반드시 남아야 할 영역을 명확히 나누는 것. "인간에게 좋은 개발 습관이 AI에게도 좋다"는 교훈처럼, AI 시대의 코드 리뷰도 결국 좋은 소프트웨어 엔지니어링의 원칙에서 출발한다. 다만 그 원칙을 팀 전체가 더 빠른 속도로, 더 큰 규모로 지켜낼 수 있는 시스템을 지금 설계해야 한다.