핵심 판단: AI 코딩 에이전트가 만든 PR은 “코드가 깨끗하다”는 인상만으로 승인하면 위험합니다. 리뷰어가 가장 먼저 봐야 할 것은 스타일이 아니라 CI가 약해졌는지, 기존 코드와 중복되는지, 중요한 경로가 실제로 맞는지, 보안 경계가 열렸는지입니다.
무슨 변화인가
GitHub Blog는 에이전트가 만든 pull request가 이미 리뷰 흐름을 바꾸고 있다고 설명합니다. 글에 따르면 GitHub Copilot code review는 6천만 건 이상의 리뷰를 처리했고, GitHub의 코드 리뷰 중 5건 중 1건 이상이 에이전트와 관련됩니다. 개발자가 오전에 여러 에이전트 세션을 동시에 돌릴 수 있게 되면서 코드 생산량은 빨라졌지만, 사람이 판단해야 하는 리뷰 역량은 같은 속도로 늘어나지 않았습니다.
문제는 에이전트가 만든 코드가 대체로 그럴듯해 보인다는 점입니다. 테스트가 통과하고 diff가 정돈되어 있으면 사람 리뷰어도 쉽게 안심합니다. 하지만 GitHub가 인용한 “More Code, Less Reuse” 연구는 에이전트 생성 코드가 사람 작성 코드보다 중복과 기술 부채를 더 많이 만들 수 있다고 지적합니다. 즉, 리뷰의 초점은 “잘 작성된 것처럼 보이는가”에서 “시스템 맥락 안에서 안전한가”로 옮겨가야 합니다.
왜 지금 봐야 하나
에이전트 PR은 개별 개발자의 생산성을 높이는 동시에 리뷰 큐를 빠르게 포화시킵니다. 과거에는 한 사람이 하루에 올리는 PR 수가 자연스럽게 제한됐지만, 이제는 에이전트가 작은 수정, 테스트 추가, 리팩터링, 문서 변경을 병렬로 만들어낼 수 있습니다. 리뷰어가 모든 줄을 같은 깊이로 읽는 방식은 더 이상 지속 가능하지 않습니다.
그래서 중요한 건 리뷰 시간을 줄이는 것이 아니라, 리뷰 깊이를 다르게 배분하는 기준입니다. 문서 수정이나 작은 타입 보정은 자동 리뷰와 CI에 맡기고, 권한·데이터 변환·배포 워크플로·보안 경계를 건드리는 변경은 사람이 더 깊게 추적해야 합니다.
바로 확인할 체크포인트
| 체크 항목 | 확인할 내용 | 승인 기준 |
|---|---|---|
| CI 약화 | 테스트 삭제, skip 추가, coverage 기준 완화, workflow 조건 변경 | 명확한 사유 없으면 승인 보류 |
| 중복 유틸 | 새 helper, validator, middleware가 기존 기능을 다시 만들었는지 검색 | 기존 모듈로 통합하거나 추가 이유를 PR에 남김 |
| 환각된 정답 | 컴파일은 되지만 경계값, 권한, pagination, race condition에서 틀릴 가능성 | 핵심 경로를 입력부터 출력까지 추적하고 실패 재현 테스트를 요구 |
| 큰 PR | 파일 5개 이상, 목적이 한 문장으로 설명되지 않음, 구현 계획 없음 | 작은 단위로 쪼개거나 구조 설명을 먼저 요구 |
| LLM 워크플로 | PR 본문·issue·commit message 같은 비신뢰 입력이 prompt나 shell로 이어지는지 | read-only 권한, 입력 sanitization, 실행 전 사람 승인, model output eval 금지 |
10분 리뷰 루틴
- 1~2분: 파일 목록과 diff 크기를 보고 변경을 분류합니다. 문서·작은 수정인지, 다중 파일 로직·성능·권한 변경인지 먼저 나눕니다.
- 2~3분: 애플리케이션 코드보다 CI와 테스트 설정을 먼저 봅니다. 에이전트가 테스트를 통과시키기 위해 기준을 낮춘 흔적이 있으면 바로 멈춥니다.
- 3~5분: 새 유틸과 helper를 검색합니다. 비슷한 기능이 이미 있으면 리뷰 코멘트가 아니라 통합을 요구하는 편이 낫습니다.
- 5~8분: 가장 중요한 실행 경로 하나를 끝까지 따라갑니다. 입력값, 변환, 권한 확인, 예외 처리, 출력까지 실제로 이어 봅니다.
- 8~9분: LLM이나 자동화 workflow가 있으면 비신뢰 입력과 token 권한을 확인합니다.
- 9~10분: “이 변경이 없던 상태에서는 실패하는 테스트”가 있는지 확인합니다. 없으면 증거가 부족합니다.
실사용 판단
에이전트 PR 리뷰에서 자동 리뷰 도구를 쓰는 것은 좋은 선택입니다. 다만 자동 리뷰는 사람 리뷰의 대체물이 아니라 사전 필터에 가깝습니다. 스타일, 타입, 빠진 error handling 같은 기계적 문제는 도구가 먼저 잡게 하고, 사람은 제품 맥락과 운영 리스크를 봐야 합니다.
팀 단위로는 PR 템플릿에 “에이전트 사용 여부”, “변경 범위”, “새 유틸 추가 이유”, “실패 재현 테스트”, “CI/권한 변경 여부”를 넣는 것이 효과적입니다. 특히 에이전트가 만든 큰 PR은 리뷰를 시작하기 전에 구현 계획이나 변경 단위 분리를 요구하는 것이 리뷰어 시간을 지키는 방법입니다.
ActualStack 관점
이 글의 포인트는 “AI가 코드를 많이 만들수록 리뷰가 더 중요해진다”가 아닙니다. 더 정확히는 코드 생산량이 늘어날수록 리뷰어의 판단 기준을 문서화해야 한다는 것입니다. 체크리스트가 없으면 에이전트는 기존 중복을 더 복제하고, CI를 우회하고, 테스트가 포착하지 못한 오류를 자연스럽게 통과시킬 수 있습니다.
따라서 개인 개발자라면 에이전트 PR을 받을 때마다 위 체크리스트를 복사해 쓰고, 팀이라면 repository별 Copilot/custom instruction 또는 PR template으로 고정하는 편이 좋습니다. 에이전트가 반복 작업을 맡는 만큼, 사람은 “우리 시스템에서 절대 놓치면 안 되는 것”을 더 선명하게 써둬야 합니다.