1. 리뷰 대상과 원칙

• 모든 PR은 머지 전에 필수로 코드리뷰를 거친다.
• 한 PR에서는 가능한 한 하나의 기능/목적만 다룬다.
• 리뷰어는 동작, 설계, 스타일을 모두 고려하되, 우선순위는 동작/설계 > 스타일로 둔다.

2. 리뷰 인원 & 승인 기준

• 기본 규칙
  • 최소 2명 이상 Approve 후 머지 가능.
  • 승인 2명 이상일 때, 작성자가 직접 머지(self-merge) 가능.
• 예외(긴급 hotfix)
  • 팀 합의 시 1명 승인 + self-merge 허용 가능.
  • 이 경우 머지 후 슬랙/노션에 “긴급 머지 사유 및 변경 내용” 필수 공유.

3. 리뷰 범위 (무엇을 볼 것인가)

리뷰어는 다음 항목을 우선 순위로 확인한다.

1. 기능/로직
   • 요구사항대로 동작하는지
   • 예외/에러 케이스가 적절히 처리되는지
   • 비즈니스 규칙 위반은 없는지
2. 설계/구조
   • 레이어 구조(Controller/Service/Repository)가 잘 분리되어 있는지
   • 메서드/클래스 책임이 과도하지 않은지 (SRP 위반 여부)
   • 의존성 방향이 올바른지 (순환 참조 등)
3. 테스트
   • 중요한 로직에 대한 테스트가 존재하는지
   • 테스트가 “행동”을 검증하는지, 단순 구현 디테일에만 묶여 있지 않은지
4. 코드 스타일 & 네이밍
   • 팀 코드 스타일/포매터가 적용되어 있는지
   • 변수/메서드/클래스 이름이 역할을 잘 드러내는지
   • 불필요한 주석, 죽은 코드(deprecated/unused)는 없는지

4. 리뷰 코멘트 규칙

• 코멘트 종류 구분
  • Blocking(필수 수정): 머지 전에 반드시 수정/논의가 필요한 사항
  • Non-blocking(선택/제안): 있으면 좋은 개선사항, 스타일 등
• 표현 방식
  • 공격적 표현, 인신 공격 금지 (항상 코드/설계에만 피드백)
  • “이렇게 바꾸면 어떨까요?” 식으로 대안을 제시할 수 있으면 같이 제시
• 합의
  • Blocking 코멘트는 수정 또는 충분한 논의 후 resolve
  • 의견이 갈리면 팀 컨벤션/리더 결정에 맞춘다

5. 리뷰어/작성자 역할

• 작성자
  • PR 템플릿을 충실히 작성해 리뷰어의 맥락 파악을 돕는다.
  • 리뷰 코멘트에 가능한 한 빠르게 응답하고, 수정 후 다시 알려준다.
• 리뷰어
  • 알림 기준 24시간 내에 최소 1차 리뷰를 남기는 것을 목표로 한다.
  • 리뷰가 늦어질 경우, 슬랙 등으로 간단히 공유한다.