코드 리뷰는 관문보다 자동화된 안전장치가 돼야 한다

안드레아(Andrea)는 코드 작성량이 늘어난 시대에 사람의 검토를 모든 변경 사항의 관문으로 삼으면 팀의 처리 능력이 한계에 부딪힌다고 주장한다. 반복되는 검토 기준은 린터와 테스트로 자동화하고, 사람은 위험한 변경과 판단이 필요한 일에 집중해야 한다는 제안이다.

코드 리뷰가 병목이 되는 이유

코드 리뷰는 코드를 쓰는 데 시간이 오래 걸리고 읽는 데는 비용이 적었던 시대에 맞춰 설계됐다. 하지만 이제 엔지니어링 팀에서 가장 부족한 자원은 사람의 주의력이고, 그중 상당 부분을 꼭 사람의 검토가 필요하지 않은 풀 리퀘스트(PR)에 쓴다는 것이 안드레아의 진단이다.

안드레아는 코드 리뷰를 고속도로 요금소에 비유한다. 예전에는 차가 지나가기 전에 요금을 내야 했지만, 기술이 발전하면서 요금소 센서를 통과하는 전자식 요금 납부 방식이 생겼다. 계정에 잔액을 넣지 않았다면 운영자가 나중에 청구서를 보낸다. 코드 리뷰도 매번 사람이 코드를 확인하고 승인하는 방식에서 벗어나, 자동 검사와 사후 대응을 함께 활용할 수 있다는 설명이다.

LLM 에이전트가 더 많은 코드를 만들면서 PR을 작은 단위로 나누는 팀도 있다. 하지만 같은 코드량을 더 작은 PR로 나누면 처리해야 할 PR 수가 크게 늘어난다. 1만 2,000줄짜리 기능을 나누는 방식에 따라 20~40개의 PR이 생길 수도 있다. PR마다 필요한 맥락을 전달하고, 앞선 변경 요청이 뒤쪽 PR에도 미치는 영향을 관리해야 하므로 검토 병목은 오히려 심해질 수 있다.

PR을 300~500줄로 제한하고 한 번에 바꾸는 파일 수를 줄이는 원칙은 여전히 유효하다고 안드레아는 본다. 다만 에이전트가 며칠 만에 만들어 낸 코드를 잘게 나누고, 여러 브랜치를 계속 최신 상태로 맞추는 일에는 큰 부담이 따른다.

반복 검사는 자동화하고 위험한 변경은 사람이 본다

안드레아는 선임 엔지니어로서 코드 리뷰를 나쁜 코드나 설계가 코드베이스에 들어오지 않게 막는 역할로 여겨 왔다고 말한다. 사람의 리뷰는 스타일 차이를 찾아내고, 버그를 발견하고, 새로운 패턴과 지식을 공유하며, 위험한 변경을 식별하는 데 쓰인다.

그중 반복되는 규칙은 리뷰 단계보다 앞서 자동화할 수 있다. 스타일 지침과 자주 반복되는 리뷰 의견을 린터 규칙으로 만들고, 동작을 평가하는 테스트를 추가하면 CI가 기준에 맞지 않는 변경을 막을 수 있다. 가능하다면 CI에 도달하기 전에 에이전트가 로컬에서 같은 검사를 실행하도록 하는 편이 낫다는 제안이다. 자동화된 안전장치를 갖추면 요금소에 차가 쌓이는 일을 줄이면서 품질 기준을 유지할 수 있다.

모든 변경에 자동 검사가 완벽하게 적용되는 것은 아니다. 안드레아는 일부 문제가 빠져나올 수 있다고 전제하고, 그런 사례를 근본 원인 분석에 활용해 새 린터 규칙이나 예방 방법을 찾자고 제안한다.

팀은 사람이 직접 살펴볼 핵심 경로도 정해야 한다. 안드레아가 예로 든 영역은 결제, 인증·권한 부여, 보안에 영향을 주거나 데이터 유출 위험이 있는 변경이다. 개인 식별 정보를 수집하거나 저장 과정에서 유출할 위험이 있다면 사람을 검토에 참여시켜야 한다는 설명이다. 필요한 핵심 경로는 앱과 업종에 따라 달라질 수 있다. 모든 교차로에 경비를 세울 필요는 없지만, 위험도가 높은 곳에는 사람의 판단을 남겨야 한다.

지식 공유와 규칙 관리도 필요하다

사람이 PR을 검토하면 새 패턴이나 시스템을 자연스럽게 접하고, 다음 작업에 활용할 수 있다. 검토를 자동화하면 이런 지식 공유가 줄어들 수 있으므로 페어 작업, 설계 문서, 비동기식 설명으로 보완해야 한다고 안드레아는 말한다. 에이전트와 함께 한 작업에서 효과가 있었던 점과 없었던 점을 화면 녹화 등으로 공유하는 방법도 제시한다.

자동화된 규칙도 계속 관리해야 한다. 어떤 린터 규칙이 여전히 유용한지, 모델이 개선돼 더는 필요하지 않은 규칙은 무엇인지 살펴야 한다. 자동 리뷰에서 반복해서 문제가 되는 규칙이 있다면, 개인의 불편에 그치는 것이 아닌지 확인한 뒤 규칙을 고칠 수 있다. 안드레아는 이 과정에서 평가 테스트가 도움이 될 수 있다고 덧붙인다.

종단 간 테스트와 아키텍처 검사는 자동 승인형 LLM 작업 흐름의 부담과 위험을 낮출 수 있는 보완책으로 꼽힌다. 잠재적인 변경 사항에 테스트를 실행하는 것뿐 아니라, 운영 환경에서도 테스트해 빠져나간 회귀 문제를 신속히 찾을 필요가 있다는 주장이다.

사람의 판단은 사람에게 남긴다

안드레아는 에이전트가 사람의 생각을 대신할 수는 없다고 강조한다. 자신의 PR이든 동료의 PR이든, 사람은 정보를 살펴보고 상황에 대해 판단해야 한다. 동시에 에이전트가 만든 긴 설명을 매일 읽는 데 시간을 쏟기보다, 동료와 공유하는 맥락을 추리고 사람이 읽기 쉽게 쓰는 일에 주의를 기울이자고 제안한다.

검토를 대부분 자동화하면 변경 속도가 빨라질 수 있고, 엔지니어가 안전장치에 더 많은 노력을 들일 여지도 생긴다. 안드레아는 이런 환경에서 디자이너가 에이전트로 UI를 개선하거나, 제품 관리자가 텍스트 입력 한도를 100자에서 5,000자로 바꾸는 일도 가능해질 수 있다고 본다. 엔지니어링팀의 우선순위가 밀릴 때까지 기다려야 했던 고객 지원 담당자가 특정 고객의 버그를 직접 고치는 사례도 들었다.

이는 모든 변경을 사람 없이 승인하자는 뜻이 아니다. 반복 확인은 기계에 맡기고, 위험한 경로와 판단이 필요한 사안에는 사람을 참여시키자는 제안이다. 안드레아는 과거의 작업 방식만이 유일한 선택지는 아니며, 에이전트와 조직이 올바른 경로를 따르도록 안내하면 코드 검토 병목의 부담을 줄일 수 있다고 주장한다.