코드 리뷰, 한 명이 다 읽지 마라: 읽는 층위마다 리뷰어를 나눠라
One reviewer per layer: splitting code review by the way code is read
Claude Code 팀의 모노레포는 하루 병합 변경이 5월 2,500건에서 9월 3만 건을 넘었다. 이들은 리뷰를 포기하는 대신 여섯 단계의 검증 파이프라인을 쌓았다. 저자는 여기서 한 걸음 더 나아가, 코드를 읽는 층위(의도·형태·국소 의미·연결·런타임·사용)마다 별도의 리뷰어 에이전트를 두는 트리 구조를 제안한다. 각 리뷰어는 좁은 문맥만 갖고, 정보는 계약 형태로 위로 흐른다. Parnas의 정보 은닉 원칙을 리뷰어 설계에 적용한 셈이다.
우리는 코드에서는 이 규칙을 따르고, 프롬프트에서는 깨뜨린다. diff와 주변 파일, 모든 추상화 수준을 하나의 문맥 창에 밀어 넣고 모델이 알아서 정리해 주기를 바란다.
- visarga
올해에는 좋은 접근 방식이라고 생각하지만, 중요한 뭔가를 놓치고 있다. 주 단위, 월 단위로 여러 세션에 걸쳐 방향을 잡아가다 보면, 코드가 여전히 당신의 의도를 반영하고 있는지 어떻게 알 수 있겠는가? 세션 안에서 메시지가 흘러가고 시야 밖으로 사라지며, 컴팩션과 새 세션을 거치면서 잊힌다. 이 문제를 해결하기 위해 나는 모든 사용자 메시지를 채팅 로그에 기록하고, 때때로 검토하면서 최신 형태의 사용자 의도를 추출한다.
여기나 Anthropic의 글에서 언급되지 않은 또 다른 종류의 리뷰는 계획 리뷰다. 나는 일정 기간의 작업에 대한 계획을 생성한 다음, 그 계획(파일로 저장된)을 하나 이상의 에이전트가 리뷰하게 한다. 이렇게 하면 실행 전에 프로젝트 제약 조건에 비추어 계획을 검증한다.
테스트 문제를 해결할 수 있다면 코딩은 거의 완전히 자동화된다. 남은 유일한 문제는 항상 신뢰였다. 왜 그 코드를 신뢰해야 하는가? 직접 읽으면 오토바이를 타는 것과 같다. 읽지 않으면 리스크를 줄일 방법이 필요하다. 이에 대한 많은 아이디어가 떠돌고 있으며, OP와 Anthropic이 각자의 견해를 보여주었다. 하지만 접근 방식은 프로젝트마다 다르며, 일반적인 방법은 없다고 생각한다.
- jwpapi
지금 내 문제는 모든 종류의 리뷰 프로세스가 불필요한 복잡성을 더해 나중에 민첩성을 떨어뜨리고 비용을 증가시키며 성능을 저하시킨다는 점이다.
기능이 있고 6명의 서로 다른 리뷰어가 이를 검토하면 논리가 쉽게 비대해진다. 다른 사람들은 이걸 어떻게 처리하는지 궁금하다. 나는 완전히 찬성이고 이게 잘 되길 바라지만, 이게 현재의 제약이다.
리뷰 모니터에서 잘못된 제안을 받는 경우가 많다. 때로는 좋은 제안, 아주 좋은 제안도 받지만 일부는 나쁘다. 그래서 버그에 대한 리뷰는 항상 기꺼이 보지만, 리뷰어 6명을 거치면 그냥 텍스트 덩어리가 되어 혼란스러워지고, 실제 중요한 것들을 내가 직접 살펴보는 것보다 최종 결과가 더 나빠질까 봐 두렵다. 내 컨텍스트도 제한적이고 완전한 hands-off는 충분히 신뢰할 수 없다...
여러분은 어떻게 하는가?
- zomtorg
더 많은 엔지니어링 팀이 git에서 Sapling으로 전환하는 것을 보게 될지 궁금하다. 코드를 리뷰하고 배포하는 방식을 새로 고칠 필요가 있다.
GH가 최근 stacked PRs를 출시한 것은 알고 있지만, Meta와 아마도 Anthropic이 내부적으로 가진 것과 비교하면 사용성과 신뢰성 측면에서 여전히 갈 길이 멀어 보인다.