코드 리뷰는 버그 탐지기가 아니다: 에이전트가 대체할 수 없는 7가지 역할
한 줄 요약
"코딩 에이전트가 코드 리뷰의 모든 기능을 수행할 수 있으니 인간 리뷰어는 불필요하다"는 주장이 나왔습니다. 하지만 개별 기능을 수행할 수 있다는 것과 사람을 대체할 수 있다는 것은 전혀 다른 이야기입니다. 코드 리뷰는 결함 탐지 작업이 아니라, 조율(coordination)·의미 형성(sensemaking)·거버넌스(governance) 과정이기 때문입니다.
논쟁의 출발점: "코드 리뷰의 종말"
최근 The End of Code Review: Coding Agents Supersede Human Inspection이라는 논문이 도발적인 입장을 내놓았습니다. 요지는 이렇습니다.
- 1976년 Fagan이 코드 검사(code inspection)를 정형화한 이후 약 50년간, 병합 전 동료 검토는 소프트웨어 품질의 핵심 관문이었음
- 코딩 에이전트를 "소프트웨어를 읽고, 작성하고, 테스트하고, 수정할 수 있는 LLM 기반 자율 시스템"으로 정의
- 코드 리뷰를 결함 탐지 / 스타일 준수 / 지식 전달 / 상황 인지 네 기능으로 분해
- 에이전트가 이 네 기능을 각각 더 낮은 비용과 높은 처리량으로 달성할 수 있으므로, 인간 리뷰어는 대체 가능
- 에이전트가 코드를 쓰고 사람이 필수 리뷰어로 남는 구조는 유의미한 보증도 못 주고, AI 지원 개발의 처리량에도 맞춰 확장되지 못함
논리는 깔끔합니다. 문제는 그 전제입니다.
"대체의 신화"가 작동하는 방식
이런 논증은 대체의 신화(substitution myth) 라는 익숙한 3단 구조를 따릅니다.
- 사람의 기여를 측정 가능한 기능 목록으로 분해한다
- 기계가 그 기능들을 재현할 수 있음을 보인다
- 따라서 사람이 불필요해졌다고 선언한다
이 분해에서 빠지는 것은 기능 사이의 통합입니다. 사람은 예상하지 못한 상황과 맥락에 적응하고, 기대되는 사회적 책임을 수행합니다. 이 적응 능력은 애초의 기능 분해에 담기지 않았기에, 그 분해를 전제로 한 결론에도 등장할 수 없습니다.
코드 리뷰를 "결함·스타일 위반·보안 문제의 탐지"로 좁히면, 자연히 더 빠르고 저렴한 탐지가 언제나 더 낫다는 결론에 도달합니다. 하지만 리뷰가 하는 일은 탐지만이 아닙니다.
기능 목록으로 환원되지 않는 리뷰의 역할 7가지
1. 리뷰어의 혼란 자체가 발견 사항이다
숙련된 엔지니어의 "이거 이해가 안 되는데요"는 실패가 아니라 신호입니다. 코드가 너무 복잡하거나, 추상화가 잘못됐거나, 의도가 불분명하다는 뜻이죠.
LLM은 코드를 처리한다는 의미에서 언제나 '이해'할 수 있습니다. 그래서 사람이 실제로 이해하지 못한다는 신호를 줄 수 없습니다. 이해 가능성은 스타일 문제가 아니라, 코드를 이해하려는 사람과 코드 사이의 상호작용에서 생겨나는 속성입니다.
2. 변경이 필요한지부터 의심한다
정확성 검증보다 앞서는 판단이 있습니다.
- "이건 PR 두 개로 나눠야 하지 않을까요?"
- "이 변경은 문제가 아니라 증상만 해결하는데요"
이 질문들은 의도, 범위, 적절성을 겨냥합니다. 비판 대상 논문은 "검토 중인 변경은 필요하며 리뷰의 주목적은 검증"이라고 전제합니다. 하지만 실제 운영에서 코드 리뷰는 "이 변경이 정말 필요한가"에 누군가 이의를 제기할 것으로 기대할 수 있는 마지막, 때로는 유일한 기회입니다.
3. 있어야 하는데 빠진 것을 찾는다
API 계약이 바뀌었는데 오류 처리는 그대로인 경우를 생각해 보세요. 에이전트는 존재하는 코드를 검토하지만, 전문성을 가진 엔지니어는 누락을 알아차립니다.
이는 LLM이 특히 취약한 실패 유형인 부재 맹목(absence blindness) 이며, 해당 논문은 이를 고려하지 않습니다.
4. 누가 작성했는지에 따라 초점이 달라진다
리뷰어는 동료와의 과거 경험을 바탕으로 주의를 배분합니다. 경험이 적은 엔지니어의 결제 모듈 첫 커밋과 베테랑의 일상적인 리팩터링은 같은 방식으로 검토되지 않습니다.
사람은 누가, 무엇을, 언제, 어디서 바꾸는지를 자신의 위험 경험과 연결합니다. 반면 논문은 모든 변경분을 동등한 입력으로 취급하는 듯합니다.
5. 리뷰는 양방향 공동 인지 활동이다
좋은 리뷰에서는 리뷰어가 작성자의 접근법을 배우고, 작성자는 리뷰어의 질문을 통해 배우며, 둘 다 대화 이전에는 없었던 공유된 이해를 얻습니다.
이건 정보 전달이 아니라 함께 수행하는 작업(coactive work)입니다. 에이전트가 생성한 설명이나 요약은 두 참여자의 정신 모형을 동시에 바꾸는 대화를 대체하지 못합니다.
6. 운영 맥락은 저장소 밖에 있다
검토에 영향을 주는 정보는 종종 코드베이스에 없습니다.
- 최근 이 서비스에서 발생한 장애
- 하위 소비 시스템 담당 팀의 인터페이스 폐기 계획
- 특정 필드를 더 이상 로그에 남기지 말라는 법무팀 요청
사람은 테스트·문서·버전 관리에 담기지 않은 조직의 현재 상태, 최근 사건, 비공식 합의를 알고 있고, 그것과 코드의 연결을 알아차립니다. "코드베이스가 완전한 맥락"이라는 전제는 성립하지 않습니다.
7. 승인에 따르는 책임은 형식 절차가 아니다
변경 승인에 개인적으로 책임을 진다는 인식은 검토하는 방식 자체를 바꿉니다. PR을 승인하는 에이전트는 결과를 감당하지 않으며, 진지한 평가를 뒷받침하는 유인 구조도 없습니다.
논문은 인간의 책임을 "법률·규정 준수를 위해 이름을 올릴 사람을 두는 문제"로 취급합니다. 윤리 문제를 논의하기는 하지만, 이를 요구사항 공학과 배포 후 모니터링으로 넘기는 것은 책임 문제를 해결하는 게 아니라 뒤로 미루는 것에 그칩니다.
그래서 어떻게 볼 것인가
이 논의는 "AI 리뷰 도구를 쓰지 말자"는 이야기가 아닙니다. 결함 탐지, 스타일 검사, 보안 패턴 스캔처럼 자동화가 명확히 잘하는 영역은 분명히 있습니다.
핵심은 그 지점에서 멈추고 "나머지도 다 되겠지"로 넘어가지 않는 것입니다. 리뷰의 가치가 탐지에만 있다고 측정하기 시작하면, 측정되지 않는 역할들 — 혼란이라는 신호, 범위에 대한 이의, 누락 감지, 조직 맥락, 책임 — 이 조용히 사라집니다. 그리고 그 손실은 사라진 다음에야 보입니다.
자동화할 수 있는 것을 자동화하되, 리뷰를 탐지 파이프라인으로 재정의하지는 말아야 합니다.