이슈 없이 PR 하나로: 요구사항부터 배포 확인까지
4월에 GitHub Issues → PR 워크플로우 를 작성하고 난 후에 오늘 워크플로우를 조금 바꿔봤다. 이슈에서 요구사항을 정리하면 -> PR 을 생성해서, 코드리뷰를 완료하면 -> 배포되는 순서였다. 한참 뒤에 다시 워크플로우를 봤는데 뭔가 자연스럽지 않고 몸에 쏙 녹아드는 느낌이 아니었다. 이슈 단계에서는 코드를 확인하지 않기 때문에 논의가 두 군데로 나눠지는 문제도 있을 것 같았다. 에이전트와 의견을 주고 받기가 애매했다. PR 은 변경된 파일 라인에 직접 표시해 가며 코멘트를 남길 수 있지만 이슈는 그게 어렵다.
이런 이유로, PR 을 주로 사용하는 워크플로우를 계획해달라고 했고, 그래서 이번엔 (이슈 -->) plan file --> PR, PR 리뷰 --> 머지,테스트,롤백지원 으로 변경했다.
요약하자면
- 오가는 곳이 이슈·PR·사이트 세 곳에서 PR 한 곳 으로 줄었다.
- 요구사항을 plans 파일 로 커밋해 줄 단위로 리뷰한다.
- 머지는 기계적으로 판정 가능한 LGTM 으로만 한다. 사람이 본 코드만 나간다.
- 배포 확인 항목 을 머지 전에 정하고, 머지 후 운영에서 대조한다.
- 실패하면 rerun → revert → 기록, 한 번만.
이 글은 클로드가 작성한 문서의 일부만 남기고 일부를 작성함.
변경 한눈에 보기
| 항목 | 이전 | 현재 |
|---|---|---|
| 할 일을 정하는 곳 | 이슈 | PR 의 plans/ 파일 |
| 이슈의 역할 | 작업 단위 | 당장 안 할 아이디어 메모(백로그) |
| 상태 관리 | draft / wip 라벨 |
Draft PR + 코멘트 마커로 차례 판별 |
| 브랜치명 | issue/<번호>-<slug> |
<종류>/<slug> (feat, fix, docs, chore, post, revert) |
| 요구사항 리뷰 | 이슈 코멘트 | plans 파일 줄 단위 인라인 코멘트 |
| PR 전 확인 | just check |
just check + just preview + 배포 확인 항목 대조 |
| 머지 | 사람이 직접 | 사람이 LGTM 코멘트 → Claude 가 머지 |
| 배포 후 | 자동 배포로 끝 | Claude 가 운영 사이트에 접속해 확인하고 PR 에 보고 |
| 실패 대응 | 정해진 절차 없음 | 직전 배포 재실행 → revert PR → 기록 이슈 |
| 글 PR | 사람이 머지 | 코드와 같은 LGTM 흐름 (LGTM = 발행) |
아직 남은 것
- 호출은 수동이다. "PR 확인해줘" 라고 말해야 Claude 가 움직인다. PR 이벤트로 자동으로 깨우는 건 다음 과제다.
- CI 가 없다. 지금 머지 조건은 로컬
just check와 LGTM 뿐이다. PR Checks 가 들어오면 조건에 추가한다.