시작 절차와 규칙은 CONTRIBUTING.md를, 개발 순서는 개발 워크플로우를 따릅니다. 이 문서는 PR을 올리고, 리뷰하고, 병합하는 기준입니다.
리뷰는 사람을 검사하는 절차가 아니라, 변경이 정확하고·규약을 지키고·유지보수 가능한지 함께 확인하는 과정입니다. 형식적 승인이 아니라 근거 있는 확인을 남깁니다.
리뷰를 요청하기 전에 스스로 먼저 검토합니다. 아래를 만족하지 않으면 리뷰를 요청하지 않습니다.
-
./gradlew clean check --no-daemon통과 (Docker 실행 상태, 테스트 규약) - 변경 의도를 증명하는 테스트가 있다(실패 → 통과 확인)
- 변경 유형별 추가 테스트를 만족한다(CONTRIBUTING.md의 검증 표)
- 규약을 지켰다 — 패키지 구조, API, 에러 처리, 로깅, 설정, DB
- 비밀값·개인정보를 코드/로그/PR 본문에 남기지 않았다
- PR 본문에 Jira 키와 RED/GREEN/Regression 증거, 범위 밖 항목, 리뷰 포인트를 적었다
PR은 작게 유지합니다. 리뷰 가능한 크기를 넘어서면 나눕니다. 무엇을·왜 바꿨는지, 어디를 집중해서 봐야 하는지 PR 본문에서 안내합니다.
우선순위 순으로 봅니다.
- 정확성 — 요구사항을 실제로 충족하는가. 경계·실패·동시성 경로를 놓치지 않았는가.
- 테스트 — 변경 의도를 테스트가 증명하는가. DB 테스트가 Testcontainers를 쓰는가(H2 금지). 오류 경로 테스트가 있는가.
- 계약·규약 준수 — API 오류 계약(
code/message/traceId), Entity 직접 노출 금지, Flyway 소유 구간, 패키지 위치, 설정/비밀값 규칙. - 보안 — 비밀값 노출, 인증·인가 경로(해당 시 인증 PR 계약), 로그에 민감정보.
- 유지보수성 — 이름·구조가 주변 코드와 일관적인가. 불필요한 추측성 계층·빈 패키지를 만들지 않았는가.
- 범위 — PR이 선언한 범위를 벗어나지 않았는가.
- 무엇이 문제인지와 왜를 함께 적습니다. 가능하면 대안을 제시합니다.
- 필수 변경과 선택 제안(nit)을 구분합니다. 선택 제안은
nit:등으로 표시합니다. - 취향 다툼이 아니라 규약·정확성에 근거합니다. 근거가 규약이면 해당 문서를 링크합니다.
- 좋은 점도 짧게 남깁니다.
- 받는 사람은 맹목적으로 반영하지 않습니다. 제안이 불명확하거나 기술적으로 의심되면 검증하고, 근거로 논의합니다. 형식적 동의가 아니라 확인이 목적입니다.
- 반영했으면 무엇을 어떻게 바꿨는지 답글로 남깁니다.
- 반영하지 않기로 했으면 이유를 남깁니다.
- 논의로 규약이 바뀌어야 한다면, 코드가 아니라 해당 규약 문서를 함께 고칩니다.
dev는 보호되어 있어 다음을 모두 만족해야 병합됩니다(관리자 포함).
backend-ci / check성공(최신dev기준)- 미해결 리뷰 대화 전부 해결
승인 리뷰는 병합 게이트가 아닙니다(0건). 조직 표준이 단일 운영자 구조에서 형식적 self-approval을 요구하지 않기 때문입니다(infra git-governance). 위의 리뷰 절차는 그대로 유효합니다 — 강제 수단이 대화 해결과 CI일 뿐입니다.
리뷰 대화는 제기한 사람 또는 합의로 해결합니다. 미해결 대화가 남으면 병합할 수 없습니다.
체크와 대화 해결을 통과하면 squash로 병합하고 기능 브랜치는 자동 삭제됩니다(개발 워크플로우). 병합 후 티켓 상태를 갱신합니다.
작성자
- self-review 완료,
clean check통과, 테스트·규약·PR 본문 준비 - PR이 리뷰 가능한 크기다
리뷰어
- 정확성·테스트·규약·보안·유지보수·범위를 확인했다
- 필수/선택 코멘트를 구분하고 근거를 남겼다
- 남은 대화가 모두 해결됐는지 확인했다