“PR 올리기”가 개발의 절반을 잡아먹는다면: /pr + /apply-review로 커밋→PR→리뷰 반영 자동화하기

Others

목록 보기

9/9

시리즈 안내

순서	제목	내용
1편	Claude Code Commands로 개발 워크플로우 자동화하기	전체 개요
2편	/spec - 명세서 기반 코드 구현 자동화	가장 핵심인 구현 자동화
3편	/create-jest - 테스트 코드 자동 생성	테스트 작성 자동화
4편	/w-context - AI를 위한 문서 작성	CONTEXT.md 개념과 활용
5편	/pr + /apply-review - PR 워크플로우 자동화	PR 생성부터 리뷰 반영까지 (현재 글)

들어가며

코드 다 짰어요. 이제 PR 올리면 끝…일 줄 알았죠.
근데 PR 단계에서 갑자기 일이 늘어납니다.

“커밋 메시지 뭐라고 쓰지?”
“PR 설명에 뭘 써야 하지?”
“리뷰 달렸네… 또 수정해야 하나…”
“코멘트 5개 달렸는데 하나씩 보기 귀찮아…”

가끔은 이런 생각도 들어요.

내가 개발을 하고 있는 건지, PR 매니저를 하고 있는 건지…

그래서 만든 게 /pr과 /apply-review입니다.

코드 작성 → PR 생성 → 리뷰 반영
이 전체 흐름을 명령어 두 개로 끝내버리는 자동화.

`/pr`이 하는 일: “PR 올리는 과정”을 통째로 줄이기

실행은 한 줄입니다.

/pr

하지만 내부적으로는 아래를 순서대로 처리합니다.

변경 사항 분석 — git diff로 뭐가 바뀌었는지 파악
커밋 메시지 생성 — 변경 내용을 요약한 메시지 작성
커밋 실행 — 스테이징 → 커밋
브랜치 푸시 — 원격 저장소로 push
PR 생성 — GitHub에 Pull Request 생성 (gh CLI 활용)

즉, 개발자는 “코드만 수정”하고
나머지 PR 관련 반복 작업은 /pr이 처리합니다.

커밋 메시지: 자동이지만 ‘의미 있게’ 만들기

자동 커밋 메시지라고 하면 걱정부터 들죠.

“Update file”
“Fix bug”
이런 거 나오면 오히려 히스토리가 망한다…

그래서 저는 커밋 메시지를 규칙으로 강제했습니다.

1) Conventional Commits 형식 고정

<type>(<scope>): <description>

<body>

예시:

feat(auth): 카카오 로그인 기능 추가

- 카카오 OAuth 연동
- 토큰 저장 및 갱신 로직 구현
- 로그인 화면 UI 추가

이 형식의 장점은 딱 하나입니다.
커밋을 읽는 순간 변경의 성격이 보인다는 것.

2) 타입 자동 분류 (feat/fix/refactor…)

Claude가 변경 내용을 보고 타입을 고릅니다.

타입	의미
feat	새로운 기능
fix	버그 수정
refactor	리팩토링(기능 변경 없음)
style	포맷/스타일 변경
docs	문서 변경
test	테스트 추가/수정
chore	빌드/설정 등 기타

타입이 일관되면 릴리즈 노트 생성이나 변경 추적도 훨씬 편해져요.

3) 설명은 한글로 (팀 컨벤션 반영)

저희 팀은 한글이 더 빨리 읽혀서, 한글로 고정했습니다.

feat(api): 재시도 로직 추가

- 네트워크 에러 시 최대 3회 재시도
- 지수 백오프 적용 (1초, 2초, 4초)
- 타임아웃 설정 추가

이 부분은 팀 성향에 따라 영어로 바꿔도 되고, scope 규칙을 더 엄격히 해도 됩니다.

PR 설명: “리뷰어가 코드부터 열지 않게” 만드는 자동 생성

PR 본문은 팀 생산성에서 생각보다 큰 비중을 차지합니다.
본문이 빈약하면 리뷰어가 코드부터 열어서 맥락을 추측해야 하거든요.

/pr은 PR 본문도 템플릿 기반으로 생성합니다.

기본 템플릿 구조

## Summary
- 변경 사항 요약 (1-3 bullet points)

## Test plan
- [ ] 테스트 항목 1
- [ ] 테스트 항목 2

실제 생성 예시

## Summary
- 카카오 로그인 기능 추가
- 기존 Apple/Google 로그인과 동일한 인터페이스로 통합
- 로그인 화면에 카카오 버튼 추가

## Test plan
- [ ] 카카오 계정으로 로그인 성공 확인
- [ ] 토큰 만료 시 자동 갱신 확인
- [ ] 로그아웃 후 재로그인 정상 동작 확인
- [ ] 기존 Apple/Google 로그인 영향 없음 확인

이렇게 되면 리뷰어가 PR을 열자마자 “이 PR이 뭘 하는지”가 보이고,
테스트 플랜까지 있으니 질문이 줄어듭니다.

`/apply-review`: 리뷰 대응을 “작업”이 아니라 “반영”으로 만들기

PR 올리면 끝이 아니라, 이제 리뷰가 오죠.

- "이 함수 이름 좀 더 명확하게 바꿔주세요"
- "에러 핸들링이 빠진 것 같아요"
- "타입을 더 구체적으로 해주세요"
- "테스트 케이스 추가해주세요"

이걸 하나씩 열고, 파일 찾고, 수정하고, 커밋하고, 푸시하고…
리뷰 반영 자체가 일입니다.

그래서 /apply-review는 한 줄로 시작합니다.

/apply-review

`/apply-review`가 하는 일

리뷰 코멘트 수집 — 현재 브랜치의 PR에서 모든 코멘트를 가져옴
코멘트 분석 — 각 코멘트가 요구하는 변경을 분류
코드 수정 — 요청 내용대로 반영
반영 커밋 생성 — 리뷰 반영 커밋 작성 (요청자 정보 포함)
푸시 — 원격 브랜치에 재푸시

즉, 리뷰어의 말이 “할 일 목록”으로 남는 게 아니라
코드 변경으로 바로 이어지게 하는 게 목표예요.

리뷰 반영 예시: 코멘트가 코드로 변환되는 순간

Before: 리뷰 코멘트

@reviewer: 이 함수 에러 핸들링이 없네요. try-catch로 감싸주세요.

After: 코드 수정

// Before
async function fetchUser(id: string) {
  const response = await fetch(`/users/${id}`);
  return response.json();
}

// After
async function fetchUser(id: string) {
  try {
    const response = await fetch(`/users/${id}`);
    if (!response.ok) {
      throw new ApiError(response.status, "Failed to fetch user");
    }
    return response.json();
  } catch (error) {
    if (error instanceof ApiError) throw error;
    throw new ApiError(500, "Network error");
  }
}

자동 생성된 커밋

fix(api): 에러 핸들링 추가

- fetchUser 함수에 try-catch 추가
- 응답 상태 코드 검증 추가
- 네트워크 에러 처리 추가

Requested by @reviewer

여기서 제가 좋았던 포인트는 이거예요.

“무슨 변경을 했는지”가 커밋 메시지에 남고
“누가 요청했는지”까지 기록되니
나중에 히스토리 추적이 쉬워집니다.

리뷰 타입별로 ‘다르게’ 처리합니다

리뷰는 전부 “고쳐주세요”가 아니죠.
그래서 /apply-review는 코멘트를 분류해서 행동을 달리합니다.

1) 코드 수정 요청

"변수명 더 명확하게 바꿔주세요"
→ 코드 변경 + 커밋

2) 질문

"이 로직이 왜 필요한가요?"
→ 코드 주석 추가 또는 PR 코멘트로 설명

3) 제안

"이렇게 분리하면 어떨까요?"
→ 적용 여부 판단 후 반영하거나, 거절 사유를 남김

4) 승인(LGTM)

"LGTM!"
→ 액션 없음

결과적으로 “리뷰를 처리하는 방식” 자체가 표준화돼서
리뷰 대응이 훨씬 덜 피곤해집니다.

워크플로우 전체 그림: 5개 명령어의 완성형

이 시리즈에서 소개한 명령어들을 한 번에 연결하면 이렇게 됩니다.

/spec user-notification     # 1) 명세 기반 구현
/create-jest                # 2) 테스트 자동 생성
/w-context                  # 3) 맥락 문서화

/pr                         # 4) 커밋 + PR 생성
/apply-review               # 5) 리뷰 반영 + 재푸시

코드 작성부터 리뷰 반영까지, 명령어 5개로 한 사이클이 완성됩니다.

왜 이 방식이 효과적이었나

1) PR 올리는 심리적 허들이 줄어듭니다

커밋 메시지/PR 본문 고민이 사라지면, PR을 더 자주 올리게 돼요.
PR이 작아지면 리뷰도 쉬워지고, 충돌도 줄어듭니다.

2) 커밋 히스토리 품질이 올라갑니다

수동으로 쓰면 귀찮아서 “fix”만 남발하게 되는데,
자동이더라도 규칙이 있으니 품질이 균일해집니다.

3) 리뷰 반영 속도가 빨라집니다

리뷰가 달리면 미루게 되잖아요.
근데 /apply-review는 “미루기 어려울 정도로 가볍게” 처리됩니다.

4) 리뷰어-작성자 사이의 마찰이 줄어듭니다

“제가 말한 건 그게 아닌데…” 같은 오해가 줄어드는 편이었어요.
특히 변경사항이 커밋 메시지로 요약되니 커뮤니케이션이 더 명확해집니다.

실제 명령어 파일 구조 (핵심만)

`/pr` 명령어 예시

# pr.md

현재 변경사항을 커밋하고 PR을 생성합니다.

## 실행 절차
1. git diff로 변경 사항 확인
2. 변경 내용 분석하여 커밋 메시지 생성
3. 변경 파일 스테이징 및 커밋
4. 원격 브랜치에 푸시
5. gh pr create로 PR 생성

## 커밋 메시지 규칙
- Conventional Commits
- 타입: feat, fix, refactor, style, docs, test, chore
- 설명은 한글

## PR 템플릿
## Summary
- 변경 사항 요약 (1~3개)

## Test plan
- [ ] 테스트 항목들

`/apply-review` 명령어 예시

# apply-review.md

현재 브랜치의 PR 리뷰를 분석하고 반영합니다.

## 실행 절차
1. 현재 브랜치의 PR 확인
2. gh api로 리뷰 코멘트 수집
3. 코멘트 분석 및 액션 결정
4. 코드 수정
5. 반영 커밋 생성 (리뷰어 정보 포함)
6. 푸시

## 리뷰 타입별 처리
- 수정 요청: 코드 변경 + 커밋
- 질문: 주석 추가 또는 답변
- 제안: 적용 여부 판단
- 승인: 액션 없음

커스터마이징 포인트

프로젝트마다 팀 룰이 다르니까, 아래는 쉽게 바꿀 수 있게 열어두는 편이 좋아요.

1) 커밋 메시지 언어/톤

- 영어로 작성
- 동사 원형으로 시작 (Add/Fix/Update/Remove)

2) PR 템플릿 확장

## Changes
- 상세 변경 내용

## Screenshots
<!-- UI 변경 시 -->

## Checklist
- [ ] 테스트 통과
- [ ] 문서 업데이트(해당 시)

3) 브랜치 네이밍 자동화

- feat/: 새 기능
- fix/: 버그 수정
- refactor/: 리팩토링
예: feat/kakao-login

4) 리뷰 반영 후 자동 코멘트

"리뷰 내용을 반영했습니다. 확인 부탁드립니다!"

주의사항

1) 민감한 변경은 자동화만 믿지 않기

보안/결제/개인정보 같은 영역은 자동 커밋 전에 꼭 사람이 확인하는 게 안전합니다.

2) 리뷰가 너무 함축적이면 오해 가능

"이거 좀…"
"여기 그렇게 하면 안 되는데"

이런 코멘트는 AI도 사람도 해석이 어렵습니다.
리뷰어가 “요청 형태”로 써주면 자동화가 훨씬 잘 굴러가요.

3) 충돌은 수동 해결이 필요할 수 있음

머지 충돌은 자동 처리의 한계가 있는 영역이라, 충돌 해결 후 다시 실행하는 흐름이 필요합니다.

4) CI 실패는 별도 대응

PR 생성 후 CI가 깨지는 건 /apply-review로 자동 해결되지 않을 수 있어요.
CI 로그 기반 수정은 별도의 작업으로 보는 게 좋습니다.

마치며

/pr과 /apply-review의 핵심은 한 문장입니다.

리뷰 “과정”이 아니라, 리뷰의 결과(품질 개선)에 집중하게 만드는 것.

커밋 메시지/PR 본문 작성 같은 반복 작업은 자동화하고
리뷰 코멘트는 코드로 빠르게 반영해서 사이클을 줄이고
개발자는 더 중요한 판단(설계/품질)에 에너지를 쓰게 됩니다

이 시리즈에서 소개한 명령어를 다시 정리하면:

명령어	역할
`/spec`	명세서 기반 코드 구현
`/create-jest`	테스트 코드 자동 생성
`/w-context`	AI를 위한 맥락 문서화
`/pr`	커밋 + PR 생성 자동화
`/apply-review`	리뷰 반영 자동화

물론 완벽한 자동화는 없어요.
아키텍처 결정이나 논쟁이 필요한 리뷰는 여전히 사람이 해야 합니다.

하지만 기계적인 반복 작업을 AI에게 맡기고,
우리는 더 가치 있는 판단에 집중할 수 있게 됐습니다.

이게 제가 생각하는 “AI와 같이 일하는 개발 워크플로우”의 형태였습니다.

참고: Link Dropper 프로젝트

이 글에서 소개한 명령어들은 제가 만들고 있는 Link Dropper 프로젝트에서 실제로 사용하고 있습니다.

LinkDropper

“기록하는 습관을 도구로 만들다 — 두 개발자의 링크 드라퍼 구축기”

이전 포스트