AI로 PR 생성 속도가 급증한 상황에서, PR 크기 라벨 자동 부여·AI 리뷰 승인·조건부 자동 머지를 조합해 사람 리뷰의 병목을 완화하는 방법을 소개한다.
URL: https://zenn.dev/pepabo/articles/ai-pr-review-bottleneck
PR 리뷰가 따라가지 못하는 일이 있다. 정신 차리고 보면 리뷰에 하루 대부분의 시간을 쓰고 있기도 했다.
내 팀에서는 엔지니어가 Claude Code 같은 에이전트를 병렬로 띄워서, 혼자서 예전의 몇 명 분량의 PR을 내는 방식이 되었다. 더 나아가 엔지니어뿐 아니라 CS나 디렉터 같은 비엔지니어 멤버도 Claude Code Actions(GitHub Actions 위에서 Claude Code를 돌리는 구조)를 통해 PR을 내고 있다. (이 시도는 이전 글 「Claude Code Action으로 여러 리포지토리를 가로질러 정보를 참조해 조사·구현을 진행하게 해보자」에서 소개했다.)
PR 생성 속도는 극적으로 올라갔지만, 사람이 하는 리뷰의 처리량이 병목이 되기 시작했다.
이 글에서는 PR 크기 라벨 자동 부여, AI 리뷰에 의한 Approve, 조건부 auto merge라는 3가지 장치를 조합해 이 병목을 조금씩 해결해 가는 시도를 소개한다.
기존의 개발 플로우에서는 한 명의 엔지니어가 하루에 내는 PR이 많아야 몇 개 정도였다. 리뷰어의 처리 속도와 PR 생성 속도는 대체로 균형을 이루고 있었던 것 같다.
하지만 2025년 후반 이후, 상황이 크게 바뀌었다.
그 결과, 하루에 생성되는 PR 양이 가속적으로 늘고 있다.
PR이 늘어도 리뷰어는 여전히 사람이므로, 리뷰 대기 큐가 길어진다. 특히 아래와 같은 PR이 큐에 막히면, 원래 우선해야 할 중요한 변경의 리뷰가 늦어진다.
OpenClaw라는 OSS 커뮤니티 운영을 보고 있었는데, 각 PR에 크기(size) 라벨이 자동으로 붙어 있었다. 이 접근에서 힌트를 얻어, 아래 3단계 구조를 만들었다.
PR이 생성/갱신될 때마다 AI가 변경 내용을 분석해 크기 라벨을 붙인다.
여기서 중요한 점은, 단순한 diff 행 수가 아니라 “영향 범위”로 판단하도록 했다는 것이다. 예를 들어 1줄 변경이라도 결제 로직 변경이라면 size/L이 될 수 있고, 100줄의 테스트 추가라도 size/S가 될 수 있다. 행 수만으로 판단하면 1줄짜리 결제 로직 변경이 XS로 분류될 위험이 있다.
| 라벨 | 기준 | 예 |
|---|---|---|
size/XS | 영향이 국소적이고, 리스크가 거의 없음 | 오타 수정, 주석 추가, 설정 값 미세 조정 |
size/S | 영향 범위가 좁고, 리스크가 낮음 | 단일 기능 내의 작은 수정, 테스트 추가 |
size/M | 여러 곳에 영향하지만 범위가 명확함 | 단일 기능 추가·개수정, 리팩터링 |
size/L | 영향 범위가 넓거나 중요한 도메인에 관련됨 | 여러 기능에 걸친 변경, DB 스키마 변경 |
size/XL | 시스템 전체로 파급될 수 있음 | 아키텍처 변경, 결제·인증의 근간 변경 |
분류 관점으로는 아래를 종합적으로 판단하도록 하고 있다.
같은 workflow 안에서 AI가 코드 리뷰도 수행한다. 리뷰 관점은 사람 리뷰어와 동일하다.
그리고 위 관점에서 중대한 문제가 없다면 AI가 Approve를 제출(submit)한다.
마지막 조각으로, 아래 조건을 모두 만족하는 PR에 auto merge를 활성화하도록 했다.
size/XS 라벨이 붙어 있음(AI가 “영향이 국소적이고 리스크가 거의 없다”고 판단)이를 통해 오타 수정이나 Dependabot의 패치 버전 업처럼, 사람이 리뷰할 필요성이 낮은 PR은 자동으로 머지된다.
GitHub Actions workflow로 구현했다.
yamlname: Claude PR Review on: pull_request: types: [opened, synchronize] jobs: claude-pr-review: runs-on: ubuntu-latest if: github.event.pull_request.draft == false steps: - uses: actions/checkout@v4 # Claude Code Action으로 라벨 부여 + 리뷰 실행 - uses: anthropics/claude-code-action@v1 with: direct_prompt: | 以下の2つのタスクを順に実行してください。 ## タスク1: PRサイズラベルの付与 PRの変更内容を分析し、影響範囲に基づいて size/XS〜size/XLのラベルを付与してください。 ## タスク2: コードレビュー PRをレビューし、問題がなければApproveしてください。 # XS + Approve済み → auto merge - name: Enable auto-merge for XS PRs env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | PR_NUMBER=${{ github.event.pull_request.number }} has_xs_label=$(gh pr view "$PR_NUMBER" \ --json labels \ --jq '[.labels[].name] | any(. == "size/XS")') is_approved=$(gh pr view "$PR_NUMBER" \ --json reviews \ --jq '[.reviews[] | select(.state == "APPROVED")] | length > 0') if [ "$has_xs_label" = "true" ] && [ "$is_approved" = "true" ]; then echo "size/XS かつ Approve 済み: auto-merge を有効化" gh pr merge "$PR_NUMBER" --auto --squash fi
참고로 리뷰 기준과 라벨 분류 기준은 리포지토리 내 .claude/skills/ 아래에 Markdown 파일로 두고 있다. 이렇게 하면 기준 변경을 PR로 관리할 수 있어 팀에서 논의하기 쉽다.
사실 workflow를 만들기 전에 브랜치 보호 규칙 변경이 필요했다. 이게 없으면 AI가 아무리 Approve해도 머지할 수 없다.
기존 브랜치 보호 규칙은 “코드 오너(CODEOWNERS)의 리뷰 필수”였다. 이 설정에서는 CODEOWNERS 파일에 적힌 멤버(= 사람 엔지니어)가 Approve하지 않으면 머지할 수 없다.
그래서 머지 조건을 **“코드 오너 리뷰 필수” → “Approve 1개 이상”**으로 변경했다.
diff# Branch protection rules - ✅ Require review from Code Owners + ✅ Required approving reviews: 1
이 변경으로 AI의 Approve도 머지 조건을 만족하게 된다.
도입 후 아래와 같은 PR이 사람 리뷰 없이 자동으로 머지됐다.
팀 멤버 반응도 호의적이었다.
“어느새 릴리스돼 있었네”
“XS 사이즈가 나오면, 계속 릴리스되네 🚀”
작은 PR이 큐에 쌓이지 않게 되면서, 사람 리뷰어는 M/L/XL의 중요한 변경에 집중할 수 있게 됐다. 아직 시작한 지 얼마 안 됐지만, 손맛(?)을 느끼고 있다.
처음부터 “AI가 전부 리뷰하고 머지”로 하지는 않았다. 가장 리스크가 낮은 XS 사이즈만부터 시작했다. 운영 실적을 쌓아 가며 단계적으로 S 사이즈까지 확대하는 것도 검토할 수 있는 구조로 했다.
앞서 말했듯 PR 크기 판단을 diff 행 수가 아니라 AI의 영향 범위 분석으로 했다. 행 수 기반이면 1줄짜리 결제 로직 변경이 XS로 분류될 위험이 있다. AI가 코드 문맥을 이해하도록 함으로써 더 적절한 분류가 가능해졌다.
리뷰 기준과 라벨 분류 기준을 리포지토리 내부의 Markdown 파일로 관리한다. “왜 이 PR이 XS로 판정됐는지”, “왜 Approve됐는지”를 팀 전원이 볼 수 있는 상태다. 기준을 바꾸고 싶다면 PR을 내면 된다.
AI가 PR을 대량 생산하는 시대에, 사람이 하는 리뷰가 따라가지 못하는 것은 자연스러운 흐름이라고 생각한다. 이 문제에 대해 “PR 크기 라벨 자동 부여 → AI 리뷰 & Approve → 조건부 auto merge”라는 3단계 파이프라인을 구축함으로써 사람의 리뷰 부담을 조금씩 줄일 수 있었다.
중요한 것은 사람 리뷰를 없애고 싶은 게 아니라는 점이다. 리스크가 낮은 변경을 자동화해서, 사람이 더 중요한 변경 리뷰에 집중할 수 있는 환경을 만들고 싶다.
AI로 코드 작성 방식이 바뀐 것처럼, 리뷰 방식도 업데이트할 필요가 있다고 생각한다. 이번에는 XS 사이즈의 auto merge라는 작은 한 걸음이지만, 개발 프로세스 전체를 AI 전제로 재검토하는 노력의 일환으로 앞으로도 계속해 나갈 것이다.
비슷한 고민이 있는 분들께 참고가 되면 좋겠다.
표현 활동을 지원하고 “인류의 아웃풋을 늘린다”는 미션에 임하는 GMO페파보 엔지니어들의 글이 모이는 Publication이다.