03-실전

03. 실전 — 4가지 흐름

흐름 A: “지금 변경한 것 PR로 만들기” (가장 일반적)

1. 작업 완료, git status로 깨끗한지 확인.
2. /pr 호출 → PR 본문 생성.
3. 사람이 본문을 다듬는다 (이건 항상 가치 있는 단계).
4. gh pr create --title "..." --body-file pr.md.
5. CI 결과 + 사람 리뷰 → 머지.

흐름 B: “이슈 → PR” (에이전트가 처음부터)

1. gh issue view <N> 로 이슈 컨텍스트.
2. 새 브랜치: git checkout -b fix/issue-<N>.
3. Claude에게 “이 이슈를 plan mode로 진단 → 수정 → 테스트” 의뢰.
4. /pr 으로 본문 생성, 이슈 번호 링크.
5. 사람 리뷰.

흐름 C: 대규모 마이그레이션 (에어비앤비식 파이프라인)

sources/23-case-studies-raw/success/airbnb-enzyme-to-rtl-test-migration.md의 핵심 교훈:

“Brute-force retry loops: up to 10+ attempts per file with dynamic prompts containing the latest error output.”
의역: “파일당 최대 10회 이상의 brute-force 재시도 루프, 매번 최신 에러 출력을 담은 동적 프롬프트.”

“The biggest lever was context selection (which nearby files, which examples, which dependencies to include) — not prompt wording.”
의역: “가장 큰 레버는 컨텍스트 선택이었다 — 어떤 인접 파일, 어떤 예시, 어떤 의존성을 포함할지.”

흐름:

1. 마이그레이션 단위(파일 1개)를 정의.
2. 헤드리스 Claude로 단위 단위 실행. 각 단위는 격리된 세션 / worktree.
3. 검증(lint, typecheck, test) → 실패 시 동일 세션에서 재시도, 에러를 컨텍스트로.
4. 단위가 통과하면 자동 커밋·PR.
5. 사람은 단위 PR을 묶어 리뷰.

이게 /batch 번들 스킬의 정신 모델이다 — 5~30개 단위, 단위마다 worktree, 각 단위가 하나의 PR.

흐름 D: 원격 트리거 (PR from anywhere)

1. Slack 메시지/Cloudwatch 알람을 GitHub Actions가 받음.
2. Action이 헤드리스 Claude를 컨테이너에서 실행.
3. Claude가 브랜치를 만들고 변경 후 PR 생성.
4. PR 링크를 다시 Slack으로 응답.
5. 사람이 PR 리뷰·머지.

이 흐름은 사람 옆에 없을 때도 반응성을 만든다. 단, 권한과 컨테이너 격리가 단단해야 한다 — 헤드리스에서는 사람이 막을 수 없다.