URL: https://evnm.substack.com/p/code-review-is-dead-long-live-code

코드 리뷰는 죽었다, 코드 리뷰 만세

학부를 마치고 첫 직장에 다니던 시절, 존경하는 동료에게서 거의 15년 동안 잊지 못한 교훈을 배웠다.

대기 중인 코드 리뷰는 실행이 막힌 스레드나 다름없다. [그러므로] 코드 리뷰를 (장애 대응과 고객 지원을 제외하고) 다른 업무보다 우선순위에 둬야 한다.

바꿔 말하면, 열려 있는 PR(풀 리퀘스트)은 동료가 누군가가 그 작업을 리뷰해 주기 전까지는 자신의 일을 더 진행할 수 없다는 뜻이다. 코드 리뷰를 우선하면 사람들이 ‘막혀 있는’ 상태로 보내는 시간을 줄여 팀의 처리량(throughput)을 최적화할 수 있다.

나도 여전히 이 현명한 조언에 따라 살고 싶다. 하지만 에이전트가 코드를 생성하는 시대가 되면서 점점 더 어려워지고 있다. 생성되는 코드의 양이 늘어날수록, 전통적인 방식으로 이를 리뷰하는 것은 버티기 힘든 일이 된다.

이 변화하는 환경에 적응하기 위한 몇 가지 관점(학파)이 나타나고 있다.

한 관점은 코드 리뷰라는 관행 자체를 아예 버리라고 한다. 그냥 분위기에 맡기자는 것이다. 품질 관리관료주의 때문에 기능 개발 속도가 발목 잡히게 둘 수는 없다. 그리고 이제 코드는 너무나도 쉽게 만들어낼 수 있으니, 버그가 나면 나중에 빠르게 고치면 된다는 주장이다.

내가 구식이라고 불러도 좋지만, 이건 장애와 유지보수 불가능한 코드베이스로 가는 레시피처럼 느껴진다.

또 다른 관점—내가 더 설득된 쪽—은 Every의 사람들이 주장한 방식이다.

이것이 ‘컴파운드 엔지니어링’ 방식으로 수행하는 코드 리뷰다. 에이전트들이 병렬로 리뷰하고, 발견 사항은 의사결정으로 이어지며, 각 수정은 다음번에 무엇을 잡아내야 하는지 시스템이 학습하게 만든다.

[…]

보안 전문가는 인증의 빈틈을 찾아내지만 데이터베이스 문제는 놓친다. 성능 전문가는 느린 쿼리는 잡아내지만 스타일이 흐트러지는 건 무시한다. 나는 각자 잘하는 것에 집중하는 전문가들이 병렬로 일하길 원했다. 그렇게 함께하면, 수동 리뷰로는 내가 놓칠 수 있는 것까지 잡아낸다.

요지는 이렇다. 코드 리뷰어가 쓸 법한 ‘모자’(관점)—예를 들면 관심사 분리? 데이터 모델의 견고함? API 설계? 성능? 보안?—마다, 그 측면의 리뷰 모범 사례를 마크다운 파일에 정리해 둔다. 그런 다음 각 파일을 에이전트에게 컨텍스트로 제공하고, 이렇게 모인 에이전트들을 띄워 각 PR에 투입한다.

그러면 하나의 PR이 열두 개 이상의 에이전트에게 평가를 받고, 그 에이전트들이 함께 제안 목록을 만들어 내며, 당신은 그 제안들을 하나씩 처리해 나가게 된다.

이 방식은 YOLO 접근보다 확실히 낫다. 하지만 여전히 판단의 부담은 PR 작성자에게 있다. 에이전트의 각 제안을 따를지 무시할지를 작성자가 결정해야 하기 때문이다.

경험을 통해 무엇을 조심해야 하는지 이미 체득한 시니어 엔지니어에게는 잘 작동할 수 있다고 상상한다. 하지만 아직 그 정도 판단력을 쌓지 못한 주니어 엔지니어에게는 그렇지 않을 수 있다.

또는 숙련된 엔지니어라도, 자신이 익숙하지 않은 회사 코드베이스의 특정 영역을 변경하는 경우에는 마찬가지다. AI 코딩 시대정신의 많은 부분이 그러하듯, 이런 것들은 그린필드 작업에 최적화된 느낌이고, 많은 사람과 다양한 구성 요소가 맞물린 대규모 코드베이스에는 덜 고민된 느낌이 든다.

어쩌면 하이브리드 접근이 등장할지도 모른다. PR을 먼저 관심사별 에이전트 무리가 샅샅이 훑고, 그다음 동료가 작성자가 에이전트의 제안을 어떻게 처리했는지에 대해 승인하도록 요구하는 방식 말이다.