Code Review Strategy - 2026-05-24
TL;DR
현재 규모에서는 “모든 PR에 여러 AI 리뷰를 병렬로 돌리고 모두 통과할 때까지 반복”하는 방식은 비용과 소음이 크다. 기본 경로는 하나로 두고, 실패·소진·고위험 PR에서만 fallback을 쓰는 편이 낫다.
Compared Options
| Option | Strength | Concern | Fit |
|---|---|---|---|
Claude Code plugin code-review:code-review |
로컬 컨텍스트와 기존 Codex/Claude workflow에 잘 붙음 | self-hosted runner/토큰/동시성 제어 필요 | 유력 기본 경로 |
| Claude Code Action | PR 생성/푸시 트리거에 자연스럽게 붙음 | GitHub Actions 비용·권한·설정 관리 필요 | 자동화 후보 |
| Gemini code review | 무료/저비용 fallback 가능성 | 무료 quota가 PR 단위 재리뷰에서 빨리 소진될 수 있음 | fallback 후보 |
| CodeRabbit | PR UX와 리뷰 제품 완성도 높음 | 소규모 개인 시스템에 월 비용 부담, 재리뷰 카운트 우려 | 보류 |
| Pantheon ad-hoc review | 지금 당장 유연하고 빠름 | 표준화·재현성·비용 통제 부족 | 임시 유지 |
| Multi-review every PR | blind spot 감소 | 비용, latency, review fatigue | 기본값으로 부적합 |
Operating Principle
- PR 생성 또는 브랜치 push 시 기본 리뷰 1개만 실행한다.
- 기본 리뷰 실패, quota 소진, 또는 high-risk label일 때만 fallback 리뷰를 실행한다.
- 같은 PR 안에서 반복 리뷰가 필요한 auto-ship 구조는 리뷰 횟수 예산을 먹는 것으로 간주한다.
- 리뷰 자동화는 “생산성 상한”이 아니라 “품질 하한”이어야 한다. 하루 33회 제한 같은 외부 quota가 전체 개발 throughput을 막으면 안 된다.
- 비용을 조금 쓰더라도 안정적인 한 경로를 확보하고, 자체 리소스를 쓸 경우 동시성/큐/취소 장치를 둔다.
Near-term Recommendation
면접 전에는 PR #136처럼 수동 Codex review + 기존 plugin 지식으로 운영하고, 안정화 후 다음 설계를 진행한다.
- Primary: self-hosted 또는 Pantheon worker에서 Claude Code plugin
code-review:code-review. - Fallback: Gemini 또는 manual Codex review.
- Guard: PR당 active review 1개, push debounce, stale review 취소, high-risk label만 extra review.
- Data: review provider, trigger, elapsed time, finding count, false-positive 여부를 JSONL로 남긴다.
Teach-back Prompt
코드 리뷰 자동화 설계 전 사용자에게 확인할 질문:
왜 “좋은 리뷰 도구 여러 개를 항상 다 돌리기”보다 “기본 리뷰 하나 + 조건부 fallback”이 지금 우리에게 더 맞나요? 비용, 속도, 생산성 상한 측면에서 설명해주세요.
See also: source: Claude Code tools research · extends: Autonomous Agent Loop · related: Wansu Slack Persona Playbook