One reviewer per layer: splitting code review by the way code is read

Djordje Puzic 블로그 글의 앞부분(문제 제기와 첫 번째 층 설명)을 읽고 옮겼어요. 뒤쪽의 층별 리뷰어 설계 세부는 다 읽지 못했어요.

출발점: Claude Code 팀의 리뷰 방식

글쓴이는 Addy Osmani가 공유한, Claude가 대부분의 코드를 쓰는 Claude Code 팀의 리뷰 방식 글에서 출발해요. 그 글에 따르면 모노레포의 머지 건수는 5월 하루 약 2,500건에서 9월 하루 3만 건 이상으로 늘었어요. 아무도 한 줄씩 읽을 수 없는 양이에요. Claude Code 저장소에서는 6월에서 9월 사이 머지된 PR이 두 배 넘게 늘었고, 되돌려야 했던 비율은 40% 넘게 줄었대요.

팀은 리뷰를 멈춘 게 아니라 계층화했어요. 변경은 여섯 층의 검사를 거치고, 마지막 뒤에는 롤백 장치가 있어요. 각 층은 일부 버그를 잡고 일부를 놓치지만, 여섯 층을 다 통과하는 버그는 드물어요.

그 층들은 '단계'예요

여섯 층은 시간 순서예요. PR 전 검증 → PR의 AI 리뷰 → 차단형 보안 리뷰 → CI → 위험도에 따른 사람 승인 → 머지·단계적 배포·되돌리기. 도로의 관문처럼 차례로 지나가요.

그런데 AI 리뷰 관문 안에서는 리뷰어 하나에게 변경이 이슈를 해결하는지, 큰 시스템에 맞는지, 다른 부분을 깨지 않는지를 다 보라고 해요. 여러 에이전트가 병렬로 찾고 투표하지만, 각자 줄 단위 문자부터 주변 시스템까지 전부 읽어야 해요.

글쓴이는 그게 한 독자에게 너무 많은 요구라고 봐요. 사람 엔지니어는 제품 의도, 서비스 경계, null 체크 엣지 케이스, 문법 규칙을 동시에 머릿속에 두지 않고 확대·축소하며 읽어요. 한 맥락에 모든 걸 넣은 에이전트는 확대·축소를 못 하고, 모든 추상화 수준이 같은 주의력을 두고 다퉈요.

코드에는 의미의 층이 있어요

첫 번째 층은 정확한 형태예요. 세미콜론 하나만 바뀌어도 프로그램이 깨지죠. 하지만 이 층도 둘로 나뉘어요. 파싱이나 컴파일이 안 되는 변경은 컴파일러가 밀리초 만에, 매번, 공짜로 찾아요. 그런 일에 에이전트를 쓸 이유가 없다는 게 글쓴이의 출발점이에요.