AI 에이전트가 코드 리뷰를 죽이고 있다 — 프린시펄-에이전트 문제 설명

업계 표준 코드 리뷰 프로세스(리뷰 후 커밋, GitHub PR로 대중화됨)는 낮은 신뢰의 협업을 위해 설계되었습니다. 한 사람이 변경을 하고, 다른 사람이 이를 리뷰하며, 반복을 거쳐 변경 사항이 적용됩니다. 이 방식은 리뷰어가 코드를 읽음으로써 노력과 이해도를 쉽게 추론할 수 있었기 때문에 작동했습니다. AI 에이전트는 이를 완전히 깨뜨립니다.

중간에 끼인 에이전트의 재앙

AI 에이전트의 최상의 시나리오: 사람이 기계에 코드 작성을 지시하고, 사람이 이를 리뷰한 후, 두 번째 사람에게 전통적인 리뷰를 위해 보냅니다. 이는 리뷰 부담을 두 배로 늘립니다. 더 나쁜 점은 에이전트가 전체 변경량을 증가시킨다는 것입니다. 결과적으로, AI 생산성 향상의 일부라도 실현되기 전에 리뷰 대역폭이 소진됩니다.

하지만 현실은 더 심각합니다. 실제 패턴은 다음과 같습니다: 사람이 짧은 프롬프트를 입력하고, 출력물을 가볍게 QA한 후, PR로 패키징하고, 리뷰어의 피드백을 에이전트에 다시 전달하여 수정합니다. 이는 전형적인 주인-대리인 문제입니다: 리뷰어(주인)는 더 이상 코드에서 노력이나 이해도를 추론할 수 없습니다. 코드가 기계에 의해 생성되었기 때문입니다. 에이전트를 사용하는 사람은 코드를 실제로 읽거나 리뷰어 피드백에 대해 비판적으로 생각할 인센티브가 없습니다. 그들은 5분을 투자하고 다른 엔지니어에게 심각한 리뷰 부담을 초래합니다.

이것이 오픈 소스를 망가뜨리고 있는 원인입니다 — 프로젝트, 제약 조건, 도구에 대한 이해가 없는 사람들이 만드는 '슬롭 PR' 말입니다.

소규모 팀을 위한 해결 방안

소규모의 높은 신뢰 팀을 위해 더 간단한 프로세스가 있습니다: 사람이 에이전트에 지시 → 사람이 코드 리뷰 → 사람이 직접 배포 (두 번째 리뷰어 없음). 기계를 사용하는 사람이 배포를 직접 책임짐으로써 모든 책임을 집니다. 주인-대리인 문제는 사람이 운전자이자 배포자가 되면서 사라집니다.

exe.dev에서는 9명의 팀이 이 접근 방식을 성공적으로 사용하고 있습니다. 핵심 관행: 통합 및 E2E 테스트를 훨씬 더 많이 작성하고, 에이전트 기반 워크플로우를 구축하여 커밋의 안전성/성능/사용성 버그를 분석하며, 최종 배포에 항상 사람이 책임을 지도록 합니다.

전통적인 코드 리뷰 모델은 에이전트와 함께 사용할 수 없습니다. 소규모 팀은 적응할 수 있지만, 대규모 조직과 오픈 소스 프로젝트는 더 어려운 구조적 문제에 직면합니다.