우리 팀은 코드 퀄리티를 유지하고 사이드 이펙트를 최소화하기 위해, 꼼꼼한 코드 리뷰와 자동화된 CI(Continuous Integration) 파이프라인을 거쳐야만 코드를 병합(Merge)할 수 있습니다.
1. PR 생성 및 Merge 기본 조건
작업 브랜치에서 dev (또는 main) 브랜치로 병합하기 위해서는 다음 조건들을 모두 만족해야 합니다.
- 지정된 PR 템플릿 사용: 변경 내역과 목적을 다른 팀원이 한눈에 파악할 수 있도록 템플릿에 맞춰 작성합니다.
- 최소 2명 이상의 승인 (2 Approvals): 작업자 본인을 제외한 최소 2명의 파트원(FE/BE)에게
Approve를 받아야 Merge 버튼이 활성화됩니다. - CI 파이프라인 통과 (All checks have passed): 하단에 설명된 제미나이 코드 리뷰와 JaCoCo 테스트 커버리지 검사를 무사히 통과해야 합니다.
2. PR 템플릿 양식
PR 생성 시 기본적으로 노출되는 템플릿입니다. 빈칸을 지우고 상세히 채워주세요. (특히 쿼리나 DB 마이그레이션이 포함된 경우 상세히 적어주어야 리뷰가 수월합니다.)
Markdown
### 📝 작업 내용
- (ex: V29 DB 마이그레이션 스크립트(Flyway) 추가)
- (ex: CDC(실시간 감지) 알림 트리거 구현: support_case 테이블 INSERT/UPDATE 시 pg_notify 브로드캐스트)
- (ex: 비즈니스 키워드 이탈 가중치(negative_weight) 세팅)
### 👀 변경 사항
- (기존 로직과 비교해서 어떻게 바뀌었는지, 새롭게 도입한 라이브러리나 기술이 있다면 작성)
- (ex: 기획 룰에 맞춰 이탈 위험도별 마스터 데이터 일괄 업데이트 로직 반영 - High 20점, Medium 10점 등)
### 🎫 Jira Ticket
- Jira Ticket: HSC-000
### #️⃣ 관련 이슈
- closes #이슈번호 (PR 머지 시 관련 이슈 자동 닫힘)
3. 자동화 리뷰 파이프라인 (CI / CD Checks)
우리 팀의 PR에는 사람이 직접 코드를 보기 전에, 자동화된 봇(Bot)들이 1차 검문을 수행합니다.
- 🤖 제미나이 AI 코드 리뷰 (Gemini Code Review)
- PR이 생성되면 제미나이 봇이 변경된 코드를 스캔하여 잠재적인 버그, 보안 취약점, 비효율적인 로직, 팀 컨벤션 위반 사항을 코멘트로 남겨줍니다.
- 작업자의 액션: 동료들에게 리뷰 핑을 보내기 전에, 봇이 남긴 피드백을 먼저 확인하고 수정 사항을 반영해 주세요.
- 📊 JaCoCo 테스트 커버리지 (Test Coverage)
- PR을 올리면 빌드 시스템이 자동으로 유닛/통합 테스트를 돌리고, JaCoCo 리포트를 코멘트로 달아줍니다.
- 작업자의 액션: 새로 추가된 비즈니스 로직(특히 과금, 구독, 이탈 위험도 계산 등 핵심 로직)에 대한 테스트 코드가 누락되어 전체 커버리지가 기준치(ex. 70%) 밑으로 떨어지면 CI가 실패(X) 처리되어 Merge가 차단됩니다. 반드시 테스트 코드를 동반해 주세요.
4. 코드 리뷰어(Reviewer) 그라운드 룰
리뷰는 코드를 지적하는 자리가 아니라, 시스템의 안정성을 함께 고민하는 자리입니다.
- 24시간 룰: 리뷰 요청(Review Request)을 받으면 가급적 24시간 이내에 리뷰를 완료하여 팀원의 작업이 병목(Block)되지 않도록 합니다.
- 단어 선택: 지시형이나 비난형 어투 대신, 제안형과 질문형 어투를 사용합니다.
- ❌ “이 쿼리 이렇게 짜면 풀스캔 돌아서 느려요. 인덱스 타게 고치세요.”
- ✅ “이 부분 조인 조건에 인덱스가 없어서 데이터가 많아지면 타임아웃이 날 수도 있을 것 같아요!
subscription테이블에 복합 인덱스를 추가해 보는 건 어떨까요?”
- 사소한 의견 (Nitpick): 변수명 오타나 단순 포맷팅 등 로직에 큰 영향을 주지 않는 사소한 제안은 코멘트 앞에
(nit)를 붙여, 작성자가 부담 없이 수용할 수 있게 배려합니다.ex) (nit) 메서드명이 너무 긴 것 같은데, calcWeight() 정도로 줄이는 건 어떨까요?