코드 리뷰 에이전트를 개발자 PC 대신 CI에서 실행해야 한다

코딩 에이전트가 더 많은 풀 리퀘스트(PR)를 만들면서 사람이 모든 변경 사항을 검토하는 일이 병목이 될 수 있다. 이 글은 GitHub Actions에서 팀 공통의 규칙·도구·지식을 사용하는 코드 리뷰 에이전트를 실행하는 방법과, 작은 실험에서 접근 가능한 정보에 따라 리뷰 결과가 달라진 사례를 소개한다.

GitHub 검색으로 집계한 공개 저장소의 월간 PR 수는 2024년 1월 약 330만 건에서 2026년 9월 약 2,000만 건으로 늘었다. 집계는 2026년 10월에 했으며 Dependabot과 Renovate가 만든 PR은 제외했다. 글은 에이전트가 코드를 작성하더라도 사람이 계속 모든 PR을 직접 검토하면 리뷰가 병목이 된다며, 리뷰를 개인 컴퓨터에서 실행하는 작업이 아니라 CI의 일부로 다뤄야 한다고 제안한다.

개인 컴퓨터에서 에이전트가 쌓은 기억과 기술은 과거의 잘못된 피드백이나 특정 담당자의 경험을 반영할 수 있다. 따라서 같은 PR과 지시문을 주더라도 사람마다 리뷰 결과가 달라질 수 있다. 도구와 서비스 접근 권한도 다르다. 예를 들어 데이터베이스를 읽을 수 있으면 마이그레이션을 검토하는 데 도움이 되고, Grafana 접근은 운영 장애 수정 검토에 유용할 수 있지만 모든 엔지니어에게 광범위한 권한을 줄 수는 없다.

제안된 구성에서는 GitHub Actions가 PR이 열리거나 갱신될 때 epho에 요청을 보낸다. epho는 격리된 샌드박스를 시작하고 저장소를 복제한 뒤, 팀의 프롬프트·기술 파일·허용된 도구를 갖춘 코딩 에이전트를 실행한다. 에이전트는 PR에 리뷰를 게시한다. PR마다 리뷰 대화가 유지되므로 새 커밋이 올라오면 앞선 피드백을 참고해 변경된 부분을 검토하고, 이미 남긴 댓글을 반복하지 않는다. 지적한 문제가 수정되면 해당 스레드에 수정 커밋을 표시하고 해결 처리한다.

팀은 리뷰에 필요한 저장소와 도구, 기술 자료를 요청에 포함하고 비밀 정보는 GitHub Actions 시크릿에 둔다. 프롬프트와 기술 자료는 저장소에서 버전 관리한다. 이 방식은 모든 PR의 리뷰를 PR 화면에 남기고, 리뷰어의 권한과 지식을 팀이 관리하게 한다. 다만 글은 구성을 보여주는 동시에 소규모 실험 결과를 제시하는 것이며, 대규모 환경에서의 효과를 입증했다고 말하지는 않는다.

실험에서 확인한 차이

실험용 송장 앱은 API, 별도 프런트엔드, 2년치의 다소 정돈되지 않은 데이터가 담긴 PostgreSQL 데이터베이스로 구성했다. 연구자는 코드 변경만으로는 알아채기 어려운 문제가 있는 API PR 몇 개를 만들고, 같은 모델·프롬프트·샌드박스를 사용해 세 가지 리뷰어 구성을 각 PR마다 세 번씩 실행했다. 차이는 리뷰어가 다른 저장소와 도구, 팀 기술 자료에 접근할 수 있는지였다.

첫 번째 PR은 API의 기존 amount 필드를 제거했다. 프런트엔드는 여전히 이 필드를 사용해 가격을 표시하므로 값이 $NaN으로 나타날 수 있었다. API 저장소만 본 리뷰어는 세 번 모두 문제를 놓쳤고, 프런트엔드 저장소에도 접근한 두 리뷰어는 세 번 모두 문제를 찾아냈다. 또 팀 기술 자료에는 금액을 달러에서 센트로 바꾸는 네 단계의 이전 계획이 기록돼 있었다. 기존 필드를 프런트엔드가 새 필드로 전환하기 전에 제거한 점은 해당 자료를 받은 세 번째 리뷰어만 세 번 모두 지적했다.

두 번째 PR은 고객 이메일의 대소문자를 구분하지 않는 고유 인덱스를 추가했다. 기존 데이터에 서로 대소문자만 다른 이메일이 있어 마이그레이션이 실패할 수 있었다. 데이터베이스를 볼 수 없던 첫 번째 리뷰어는 그런 데이터가 있으면 실패한다고 가능성만 지적했다. 읽기 전용 데이터베이스에 접근한 두 리뷰어는 고객 74명에 걸친 중복 그룹 37개를 확인했다. 세 번째 리뷰어는 팀의 마이그레이션 기술 자료에 따라 운영 데이터에서 실패하는 마이그레이션을 병합 차단 사안인 P0로 표시했고, 두 번째 리뷰어는 P1로 분류했다.

문제가 없는 PR을 대조군으로 넣었을 때는 세 리뷰어 모두 테스트 누락에 관한 같은 의견 하나만 남겼다. 이 제한된 실험에서는 저장소·도구·팀 지식을 더 제공한 리뷰어가 문제를 더 잘 찾았지만, 깨끗한 PR에 댓글을 더 많이 달지는 않았다. 실험에 사용한 워크플로와 프롬프트, 기술 자료, PR은 invoices-api 저장소에 있으며, 검토 대상 프런트엔드는 invoices-web이다. 실험의 전체 내용도 확인할 수 있다.

원문은 CI에서 리뷰어가 실행되는 방식, 필요한 파일, 워크플로, 에이전트에 전달하는 정보, 프롬프트, 팀 기술 자료와 실험 결과를 더 자세히 설명한다.

부록: 원문 예시

follow-up.md, sent when new commits are pushed
```