사람의 코드 리뷰는 당분간 사라지지 않습니다

AI 요약

AI 에이전트가 코드를 빠르게 작성하면서 Pull Request(PR) 검토가 병목이 됐다는 지적이 나옵니다. 글은 리뷰를 없애기보다 역할을 바꿔야 한다고 주장합니다. 에이전트는 격리된 환경에서 구현과 테스트를 반복하고, CI(Continuous Integration)는 검토에 필요한 증거를 정리합니다. 사람은 모든 생성 과정을 따라가는 대신 변경의 의도와 위험을 확인한 뒤 병합을 승인합니다.

에이전트 작업은 격리된 내부 루프에서

에이전트의 설계, 구현, 테스트가 한 세션에서 이어지면서 개발 단계가 압축됐습니다. 하지만 요구사항이 맞는지, 아키텍처가 다음 팀에도 견딜지, 변경을 다른 사람이 이해할 수 있는지 확인하는 일은 남습니다. 코드 작성 속도가 빨라졌다고 위험 관리와 책임까지 사라지는 것은 아닙니다.

사람이 에이전트의 매 작업을 지켜보며 의견을 보태면 사람이 병목이 됩니다. 공유 브랜치나 PR을 디버깅 작업장처럼 쓰는 것도 비효율적입니다. 글은 개발자 컴퓨터의 worktree와 sandbox에서 먼저 작업하고, 외부 실행이 필요하면 임시 runner나 브랜치와 함께 사라지는 preview 환경을 쓰라고 제안합니다. 사람은 도구 호출 하나하나가 아니라 결과를 검토합니다.

에이전트가 작성한 테스트만 통과했다고 독립 검증이 끝난 것은 아닙니다. 구현과 테스트를 같은 세션에서 만들면 에이전트가 자기 답안을 채점하는 꼴이 될 수 있습니다. CI는 에이전트가 통제하지 않는 별도 환경에서 테스트를 다시 실행해야 합니다. 고정된 이미지와 환경을 사용하고, 테스트가 통과하도록 assertion을 임의로 바꾸지 않는 과정도 필요합니다.

PR은 없애지 말고 검토 브리핑으로 바꿉니다

글은 LinearB의 2026년 벤치마크를 인용합니다. 810만 건의 PR을 분석한 결과, AI가 작성한 변경은 첫 검토까지 약 4.6배 더 오래 기다렸고 병합률은 32.7%였습니다. 비보조 변경의 병합률은 84.4%였습니다. GitLab의 AI 책임성 조사에서는 응답자의 85%가 병목이 코드 작성에서 검토와 검증으로 옮겨갔다고 답했으며, 78%는 커밋 속도가 빨라졌다고 답했습니다. 글은 생성 속도가 빨라져도 배포 성과가 자동으로 따라오지는 않는다고 설명합니다.

사람에게 근거 없는 500줄짜리 diff를 건네면 검토는 다시 병목이 됩니다. 그렇다고 생성량에 맞춰 검토를 생략해서는 안 됩니다. 팀이 검증할 수 있는 양보다 더 많은 변경을 만든다면 작업 단위를 줄이고, 내부 루프를 마친 뒤 작은 PR을 적게 열어야 합니다. DORA가 오랫동안 강조해 온 작은 배치와 빠른 피드백, 품질을 통한 속도도 같은 원칙입니다.

CI는 단순히 테스트 통과 여부만 표시하지 않고 검토자가 판단할 자료를 PR에 제공해야 합니다. 변경 의도, 영향 범위와 되돌리는 방법, 에이전트와 분리된 환경에서 다시 실행한 테스트 결과, 변경분의 테스트 커버리지, 보안 검사와 인증·데이터·결제 관련 사항이 포함됩니다. 동작을 확인할 preview URL이나 스크린샷도 유용합니다. 사람이 실제로 살펴야 할 세 곳을 짚어 주면 검토 시간도 줄어듭니다.

검토 에이전트는 기계적 수정을 맡고, 사람은 서명합니다

구현 에이전트가 코드 탐색과 수정, 검사 오류 해결을 한꺼번에 맡으면 같은 맥락에 코딩 규칙까지 몰아 넣기 어렵습니다. 글은 diff만 읽는 별도 검토 에이전트가 규칙을 확인하도록 제안합니다. 이 에이전트는 누락된 테스트나 이름, 반복되는 실수를 지적하는 데 그치지 않고, 가능한 기계적 수정은 브랜치에 직접 커밋합니다. 댓글을 쌓아 두는 것보다 정돈된 diff를 사람에게 보여주는 방식입니다.

사람은 변경 자체가 필요한지, 아키텍처에 맞는지, 계약의 의미가 유지되는지, 에이전트에게 작업을 맡긴 사람이 diff를 이해하고 책임질 수 있는지 판단합니다. 에이전트는 main 브랜치에 직접 커밋하지 않습니다. 브랜치에 커밋할 수는 있어도 병합은 이름이 확인된 사람이 승인합니다. 사람의 검토에서 반복해서 나오는 지적은 lint, 타입 검사, 테스트 같은 결정적 검사나 검토 에이전트의 규칙으로 옮깁니다. 다음 리뷰에서 같은 지적을 되풀이하지 않도록 하는 방식입니다.

운영 환경은 에이전트의 학습장이 아닙니다

빠른 rollback도 이미 발생한 사용자 피해를 지우지는 못합니다. 잘못된 가격, 노출된 데이터, 결제 오류가 운영 환경에 나타난 뒤에야 배우는 방식은 위험합니다. 특히 업무 규칙 오류나 조용한 데이터 변동처럼 모니터링이 잡아내지 못하는 문제도 있습니다. 관측성(Observability)은 사전 검증을 대신하지 않으며, 문제가 빠져나간 뒤 알아차리는 수단입니다.

사람 한 명과 에이전트 하나가 만드는 실험용 프로젝트에서는 내부 루프만으로 충분해 보일 수 있습니다. 여러 개발자가 함께 작업하고 기본 브랜치에서 배포하는 제품이라면 PR은 변경을 공유하고 충돌을 줄이며 이유를 전달하는 공간입니다. 글은 PR 대기열을 없애려면 리뷰를 지우는 대신 작은 diff와 당일 검토, 근거를 갖춘 브리핑을 마련해야 한다고 정리합니다. 생성자는 승인자가 아니며, 병합에는 운영 책임을 맡을 수 있는 사람이 남아야 합니다.

dev.to 반응

• @nullandvoid_ — 사람의 리뷰를 간결하고 근거가 뒷받침된 브리핑으로 바꾸자는 생각이 특히 눈에 띕니다. AI는 코딩 루프를 압축할 수 있지만 병합 시점의 책임은 여전히 사람이 져야 합니다. “두 번 쓰게 될 댓글은 빠진 검사입니다”라는 문장이 특히 유용한 요점입니다.

원문: dev.to / 번역·요약: Trawling