02-02 PR과 코드 리뷰

Pull Request를 품질 게이트로 활용하는 법 — 좋은 PR 작성, 효과적인 리뷰, 브랜치 보호.

Pull Request를 품질 게이트로 활용하는 법 — 좋은 PR 작성, 효과적인 리뷰, 브랜치 보호.

목표: PR로 코드 품질을 지키고 협업 마찰을 줄이기

🔄 PR 흐름

graph LR
    BRANCH["feature 브랜치"] --> PR["PR 생성"]
    PR --> CI["🤖 CI 자동 검사"]
    CI --> REVIEW["👀 동료 리뷰"]
    REVIEW --> FIX["수정"]
    FIX --> REVIEW
    REVIEW --> MERGE["✅ 머지"]

PR은 단순 머지 수단이 아니라 자동화된 품질 검문소다: Lint → Test → Security Scan → 사람 리뷰.

✍️ 좋은 PR 작성법

작게 쪼개라: 리뷰 가능한 크기(보통 400줄 이하). 큰 PR은 리뷰 품질이 급락
하나의 목적: 한 PR = 하나의 논리적 변경
설명 충실히: 무엇을·왜·어떻게 테스트했는지
스스로 먼저 리뷰: 올리기 전 diff를 직접 읽기

PR 템플릿 예시:

## 변경 사항
- 로그인 OAuth 연동 추가

## 이유
- 소셜 로그인 요구사항(#123)

## 테스트
- [ ] 단위 테스트 통과
- [ ] 로컬에서 구글 로그인 확인

## 스크린샷
(UI 변경 시)

👀 효과적인 코드 리뷰

리뷰어 자세

코드를 비판하되 사람을 비판하지 않는다
칭찬도 남긴다(좋은 패턴 강화)
“이렇게 해야 한다”보다 “왜 이렇게 했나요?” 질문형
막는(blocking) 의견과 단순 제안(nit)을 구분 표시: nit:

우선순위

우선	항목
높음	버그·보안·데이터 손실 가능성
중간	설계·가독성·테스트 누락
낮음	스타일·네이밍(`nit:`) — 가능하면 자동화로

[!tip] 스타일은 자동화로 포맷·린트는 리뷰에서 다투지 말고 Prettier/ESLint/pre-commit으로 자동화하라. 리뷰는 로직과 설계에 집중. → 03-04-Git-훅과-자동화

🔀 머지 방식 선택

방식	결과	적합
Merge commit	모든 커밋 + 병합 커밋 보존	히스토리 완전 보존
Squash and merge	모든 커밋을 1개로 압축	깔끔한 main(권장)
Rebase and merge	커밋 보존 + 선형	병합 커밋 없는 선형

대부분의 팀은 Squash로 main을 깔끔하게 유지한다.

🛡️ 브랜치 보호 규칙 (Branch Protection)

GitHub/GitLab에서 main을 보호:

✅ main 직접 push 금지(PR 필수)
✅ 머지 전 상태 체크(CI) 통과 필수
✅ 최소 N명 승인 필요
✅ 최신 base와 동기화 후 머지
✅ CODEOWNERS: 영역별 필수 리뷰어 자동 지정

# .github/CODEOWNERS
/src/auth/    @security-team
*.tf          @infra-team

📋 체크리스트

🔗 관련 노트

02-01-브랜치-전략 — 이전
02-03-커밋-컨벤션과-시맨틱-버저닝 — 다음
02-02-GitHub-Actions — PR CI 구현
01-04-원격-저장소와-협업 — push/PR 기초

마지막 업데이트: 2026-06-02