AI 코드 리뷰, 결함 탐지와 변경 승인을 나눠야 하는 이유
AI 리뷰의 탐지 능력과 팀에 남는 이해는 별도로 평가해야 한다. 코드 리뷰 대체 논문과 반론을 비교하고, 자동화할 검사·사람이 결정할 경계·도입 효과를 확인할 기준을 정리한다.
테스트가 통과하고 AI 리뷰도 문제를 찾지 못한 변경이 있다고 하자. 그런데 다음 배포를 맡은 동료는 왜 이 로직이 필요한지, 되돌리면 무엇이 달라지는지 설명하지 못한다. 이 변경은 충분히 검토된 것일까. AI 코드 리뷰를 도입할 때는 결함을 찾는 능력과 팀이 변경을 이해하는 능력을 따로 살펴야 한다.
이 질문을 다시 꺼낸 계기는 John Allspaw의 코드 리뷰 자동화에 대한 글이다. 원문은 2026년 8월 24일에 작성됐고, GeekNews에는 9월 28일 14시 40분, 한국 시각으로 등록됐다. 새 도구의 출시보다 리뷰의 목적을 다시 정하는 논의로 읽을 만하다.
대체 가능성은 아직 주장과 근거를 나눠 읽어야 한다
논쟁의 출발점은 Martin Monperrus가 6월 11일 공개한 논문이다. 저자는 에이전트가 리뷰의 목표를 더 적은 비용과 높은 처리량으로 달성할 수 있고, 코드 생성 속도만 높인 채 사람의 필수 검토를 유지하면 병목이 된다고 주장한다. 다만 서론에서 새로운 실증 연구를 제시하는 것이 아니라 기존 연구와 능력 평가를 종합한 논증이라고 밝힌다.
논문의 결론도 모든 판단을 무인화하자는 말로 요약하면 부정확하다. 장기적인 설계 결정, 민감한 보안 경로, 에이전트가 전달받지 못한 요구사항에 의존하는 변경에는 사람의 감독을 남긴다. 누락과 불확실성에 대응하기 위해 여러 에이전트의 검토와 판단 유보도 제안한다. 논의와 결론
내가 주목한 부분은 처리량에 관한 문제 제기다. 생성된 변경이 늘어도 읽을 시간은 그대로라면, 승인 버튼만 누르는 절차가 될 수 있다. 그러나 그 진단에서 곧바로 우리 팀의 필수 리뷰를 없애도 된다는 결론이 나오지는 않는다. 어떤 결함을 얼마나 놓치는지, 검토를 없앤 뒤 누가 시스템을 이해하는지는 별도로 확인해야 한다.
요약문이 남는 것과 이해가 남는 것은 다르다
Allspaw는 숙련된 리뷰어가 코드를 이해하지 못하는 상황 자체가 복잡성이나 불분명한 의도를 드러낼 수 있다고 본다. 또 작성자와 리뷰어가 질문을 주고받으며 함께 이해를 바꾸는 일을, 에이전트의 설명 생성과 구분한다. 이는 리뷰를 조율과 공동 이해의 과정으로 보는 원문 작성자의 관점이다.
나는 이 논점을 사람이 언제나 더 정확하다는 주장으로 받아들이지 않는다. 모델도 불필요한 추상화나 누락된 조건을 지적할 수 있다. 다만 그 지적이 정확하더라도, 다음 변경을 맡을 사람이 내용을 이해했는지는 여전히 미확인 상태다. 설명을 생산한 사실과 그 설명을 사용할 수 있는 상태는 다르다.
가령 할인 정책을 바꾸는 PR을 가정해 보자. PR은 코드 변경을 병합하기 위한 검토 요청이다. 새 계산식과 테스트가 일치해도, 이전 정책으로 생성된 주문에 어느 규칙을 적용할지는 다른 질문이다. 담당자가 그 경계를 설명하고 반례를 하나 제시할 수 있다면, 요약문을 읽었다는 확인보다 구체적인 근거가 된다. 실제 장애 사례가 아니라 이해 여부를 확인하기 위한 예다.
Google의 공식 리뷰 지침도 전체 설계, 불필요한 복잡성, 테스트 자체의 타당성을 검토 대상으로 둔다. 특히 코드가 깨졌을 때 테스트가 실제로 실패하는지 묻는다. 통과 표시를 확인하는 일에 더해, 그 표시가 어떤 동작을 보장하는지 읽어야 한다는 기준이다.
도구의 승인 권한보다 팀의 확인 항목을 먼저 정한다
AI 리뷰를 붙이기 전에는 지금 사람이 하던 일을 나눠 보겠다. 포맷과 명확한 규칙 위반은 린터나 타입 검사로 확인하고, AI에는 변경 설명의 빈틈이나 의심되는 실패 경로를 제안하게 할 수 있다. 사람에게는 사용자가 원하는 변화인지, 기존 운영 조건과 충돌하지 않는지 판단할 근거를 남긴다. 아래는 내가 적용해 볼 역할 분담이다.
- 작성자는 바뀌는 동작, 유지할 동작, 아직 확인하지 못한 가정을 PR에 적는다.
- AI의 지적에는 해당 코드 위치와 실패 조건을 요구한다. 수정했다면 어떤 검증으로 확인했는지 연결한다.
- 담당 리뷰어는 중요한 선택의 이유와 배포 후 확인할 신호를 설명한다. 자신이 확인한 범위도 기록한다.
이 절차의 비용은 문맥을 준비하고 유지하는 시간이다. 저장소에 없는 합의나 운영 제약을 사람이 계속 전달해야 한다면, 모델 호출 가격만으로 도입 비용을 계산할 수 없다. 반대로 같은 규칙을 반복 설명하고 있다면 이를 테스트나 명시적인 문서로 옮겨 검토 부담을 줄일 여지가 있다.
모든 설계 논의를 PR 끝에 몰아넣을 필요도 없다. 논문은 아키텍처의 일관성을 설계 문서와 별도 검토에서 다룰 것을 제안한다. 해당 논의 이런 경로가 이미 작동하는 팀이라면 PR에서 반복할 질문을 줄일 수 있다. 내 판단 기준은 사람의 승인이 반드시 어디에 있어야 하는가보다, 필요한 결정이 실제로 어디에서 내려지고 기록되는가다.
도입 효과는 지적 개수 밖에서도 측정한다
처음에는 범위가 제한된 저장소나 변경 유형 하나에서 기존 검토와 AI 리뷰를 병행해 보겠다. 이 글에서 특정 제품을 실행하거나 효과를 측정한 것은 아니다. 다음은 도입 여부를 판단하기 위한 제안이다.
먼저 AI가 남긴 댓글 가운데 실제 수정으로 이어진 것, 잘못된 경고, 사람이 추가로 발견한 누락을 구분한다. 여기에 검토 대기 시간과 사람이 확인에 쓴 시간을 더한다. 댓글이 늘면서 확인 시간이 더 길어졌다면 탐지량만으로 성공이라고 부르기 어렵다.
이해의 유지도 작은 방식으로 살필 수 있다. 일정 시간이 지난 뒤 다른 담당자가 변경의 이유와 되돌릴 조건을 기록만 보고 설명할 수 있는지 확인한다. 이 결과를 생산성 점수로 단순화할 필요는 없다. 어느 부분의 설명이나 협업이 사라졌는지 찾는 단서로 쓰면 된다.
자동 승인 범위를 넓히려면 실패를 발견할 관측 수단과 복구 절차가 먼저 있어야 한다고 본다. 영향 범위가 작고 쉽게 되돌릴 수 있는 변경과, 데이터 해석이나 권한 경계를 바꾸는 변경을 같은 조건으로 승인할 이유는 없다. 도구를 평가할 때도 저장소 접근 범위, 제공할 문맥, 호출 비용을 기록하고 모델이나 설정이 바뀌면 결과를 다시 비교해야 한다.
AI 리뷰가 줄여야 할 것은 팀이 반복해서 쓰는 확인 비용이다. 그 과정에서 중요한 결정을 설명할 사람이 사라진다면 다른 비용이 생긴다. 내가 도입 여부를 판단할 마지막 질문은 하나다. 검토가 빨라진 뒤에도, 이 시스템을 다음에 바꿀 사람이 무엇을 지켜야 하는지 알고 있는가.
참고 자료
이 이야기가 도움이 되었나요?