Claude Code로 블로그 배포 파이프라인을 구축하면서 /pr-iterate 워크플로우를 만들었다. PR 리뷰 → 수정 → 재리뷰를 ❌ 항목이 사라질 때까지 반복하는 워크플로우다.
첫 실행 결과를 보고 바로 다듬어야겠다고 생각했다.
첫 실행 결과
2라운드, 약 80,000 토큰 소비. 발견된 ❌ 항목은 딱 하나였다.
gh pr comments <PR번호> → 존재하지 않는 서브커맨드
워크플로우 파일 자체의 오타였다. 80K 토큰으로 오타 하나를 잡은 셈이다.
왜 과했는가
원인은 설계에 있었다. 매 라운드마다:
gh pr diff— 전체 diff 재독SPEC.md재독- 전체 관점에서 리뷰
Round 2의 목적은 "Round 1에서 발견한 ❌가 잘 수정됐는가?"인데, 전체 PR을 처음부터 다시 읽고 있었다.
프로덕션이라면 괜찮을까?
처음엔 그럴 것 같았다. 하지만 생각해보면 아니다.
AI 반복 루프로 해결되지 않는 것들:
- 아키텍처 결정의 타당성
- 비즈니스 로직 정합성
- 보안 취약점의 맥락 판단
AI가 잘하는 것들 — lint, 타입 오류, 알려진 패턴의 버그 — 은 사실 PR 리뷰보다 커밋 시점에 hook으로 잡는 게 더 효율적이다.
프로덕션이라도 /pr-review 1회 + 사람 최종 승인이 더 나은 구조다. /pr-iterate는 사람 리뷰어가 없는 솔로 프로덕션에서만 의미가 있다.
개선: Round 2+는 범위를 제한
해결책은 명확했다.
| Round 1 | Round 2+ | |
|---|---|---|
| diff 범위 | 전체 PR diff | 수정 커밋만 |
| SPEC.md | 읽음 | 재독 금지 |
| 리뷰 관점 | 전체 | "❌가 고쳐졌는가?"만 |
| 종료 조건 | — | ❌ 없으면 종료 |
이론상 Round 2 토큰이 50~70% 줄어든다. 최대 반복도 5회에서 3회로 낮췄다.
결국 배운 것
자동화를 설계할 때 "무엇을 반복할 것인가"보다 "언제 멈출 것인가" 와 "각 라운드의 범위를 어떻게 줄일 것인가" 가 더 중요하다.
무한 루프에 가까운 설계는 토큰만 태운다. 수확체감이 가장 빠른 영역 중 하나다.
# 현재 권장 플로우 (사이드 프로젝트)
/commit → /push → /pr-create → (머지)
# 품질이 걱정될 때만
/pr-review → 눈으로 확인 → 필요하면 수정
# 큰 PR, 솔로 프로덕션에서만
/pr-iterate (최대 3라운드)
도구는 많을수록 좋은 게 아니다. 꺼내는 타이밍이 맞아야 한다.