AI 코딩 속도전보다 느린 리뷰 루프가 남긴 것

Nolan Lawson의 글은 AI 코딩을 속도 경쟁으로만 보는 흐름에 브레이크를 건다. 요지는 단순하다. LLM이 빠르게 코드를 뽑아내는 도구라면, 같은 모델을 더 느리고 까다로운 검토자로도 쓸 수 있다. 작성보다 검토에 모델을 배치하면 생산성의 기준이 “몇 줄을 만들었나”에서 “어떤 결함을 미리 발견했나”로 이동한다.

글에서 제안하는 방식은 여러 모델과 도구를 같은 PR에 던져 버그 후보를 모으고, 사람이 그 결과를 다시 걸러 최종 보고서로 정리하는 구조다. Claude sub-agent, Codex, Cursor Bugbot처럼 성격이 다른 도구를 병렬로 쓰면 한 모델의 착각이나 과잉 지적을 줄일 수 있다는 설명이다. 중요한 부분은 자동 수정이 아니라 우선순위와 검증이다. 모델이 찾은 결함을 그대로 믿는 대신, 사람은 재현 가능성, 코드베이스의 설계 의도, 테스트 가치까지 함께 본다.

HN 댓글도 비슷한 지점을 파고들었다. 일부 개발자는 AI와 긴 설계 대화를 거친 뒤 명세를 만들고, 구현 이후 다시 다른 모델로 corner case와 보안, 동시성 문제를 점검한다고 설명했다. 반대로 “에이전트가 목표까지 너무 빨리 달려가면서 중간의 미세한 설계 판단이 사라진다”는 우려도 나왔다. 이 논점은 AI 코딩 도구가 부족해서라기보다, 사람이 어떤 작업을 넘기고 어떤 판단을 붙잡을지 정해야 한다는 쪽에 가깝다.

실무적으로 읽을 대목은 AI를 “코드 작성자” 하나로 고정하지 않는 것이다. 빠른 초안 작성, 독립 리뷰, 테스트 아이디어 발굴, 접근성 점검, 회귀 위험 탐색은 서로 다른 작업이다. 같은 LLM이라도 역할을 나누면 결과의 성격이 달라진다. 특히 리뷰 루프는 느리지만, 대형 PR을 그대로 합치는 것보다 더 작은 비용으로 결함을 앞당겨 찾을 수 있다.

원문은 Nolan Lawson의 블로그에 실렸고, HN 논의는 해당 스레드에서 이어졌다.