fix: ReviewDetailV1 NPE 위험 수정

.claude/commands/backend-review.md

@@ -0,0 +1,214 @@
+# 📄 Backend PR Review Guide (for claude)
+
+## 📌 목적
+
+이 문서는 백엔드 Pull Request를 리뷰할 때,  
+LLM이 일관되고 실무적인 기준으로 코드 리뷰를 수행하도록 돕기 위한 가이드입니다.
+
+리뷰는 단순 코드 스타일이 아니라,  
+**설계 / 안정성 / 성능 / 보안 / 유지보수성 중심**으로 수행해야 합니다.
+
+---
+
+## 리뷰 기본 원칙
+
+- 단순 "좋다/나쁘다"가 아니라 **이유 + 개선 방향** 제시
+- 가능하면 **대안 코드** 또는 **구체적 수정 방향** 제시
+- 불필요한 nitpick 지양
+- **문제 → 이유 → 개선안** 구조로 설명
+
+---
+
+## 1. 아키텍처 / 설계
+
+- 책임 분리가 잘 되어 있는가?
+    - Controller / Service / Repository 역할이 명확한가?
+- 비즈니스 로직이 Service에 위치하는가?
+- Entity에 로직이 적절히 포함되어 있는가?
+- 도메인 중심 설계가 되어 있는가?
+
+### 체크 포인트
+
+- Service가 너무 비대하지 않은가?
+- Controller에서 비즈니스 로직 처리하지 않는가?
+- Repository가 불필요한 로직을 가지지 않는가?
+
+---
+
+## 2. 도메인 모델 (Entity)
+
+- 엔티티가 비즈니스 규칙을 잘 표현하는가?
+- setter 남용 없이 메서드 기반 변경인가?
+- 상태 변경 메서드가 명확한가?
+
+### 체크 포인트
+
+- `user.restore()` 같은 명확한 행위 메서드 존재 여부
+- 무분별한 public setter 사용 여부
+- soft delete 정책 일관성
+
+---
+
+## 3. 인증 / 보안
+
+- 인증 로직이 안전한가?
+- 외부 API 토큰을 그대로 신뢰하지 않는가?
+- JWT 사용 방식이 올바른가?
+
+### 체크 포인트
+
+- 우리 서비스 JWT 따로 발급하는가
+- refresh token 저장 위치가 안전한가 (DB/Redis)
+- 민감 정보 로그 출력 여부
+
+---
+
+## 4. 예외 처리
+
+- 예외가 일관되게 처리되는가?
+- 비즈니스 예외 vs 시스템 예외 구분되어 있는가?
+
+### 체크 포인트
+
+- ErrorCode enum 사용 여부
+- try-catch 남용 여부
+- 의미 없는 RuntimeException throw 여부
+
+---
+
+## 5. 트랜잭션
+
+- 필요한 곳에 `@Transactional`이 있는가?
+- readOnly 설정이 적절한가?
+
+### 체크 포인트
+
+- 조회 후 엔티티 수정 시 트랜잭션 존재 여부
+- 트랜잭션 범위가 과도하지 않은가
+
+---
+
+## 6. 성능 / 쿼리
+
+- 불필요한 쿼리가 발생하지 않는가?
+- N+1 문제 가능성 있는가?
+
+### 체크 포인트
+
+- find 후 다시 조회하는 구조
+- lazy loading 문제
+- 인덱스 고려 여부
+
+---
+
+## 7. 동시성 / 데이터 정합성
+
+- race condition 가능성 있는가?
+- 중복 데이터 생성 가능성 있는가?
+
+### 체크 포인트
+
+- 소셜 로그인 중복 가입 가능성
+- DB unique constraint 존재 여부
+- save 전에 검증만 하는 구조
+
+---
+
+## 8. 테스트 가능성
+
+- 테스트 가능한 구조인가?
+- 의존성 분리가 잘 되어 있는가?
+
+### 체크 포인트
+
+- Service 단위 테스트 가능 여부
+- 외부 API mock 가능 여부
+
+---
+
+## 9. 코드 가독성 / 유지보수성
+
+- 변수명 / 메서드명이 명확한가?
+- 코드 흐름이 직관적인가?
+
+### 체크 포인트
+
+- map/orElseGet 남용 여부
+- if-else가 더 나은 경우인지
+- 메서드 분리 적절한가
+
+---
+
+## 10. API 설계
+
+- RESTful하게 설계되어 있는가?
+- 요청/응답이 명확한가?
+
+### 체크 포인트
+
+- DTO 사용 여부
+- Entity 직접 반환 여부
+- 응답 포맷 일관성
+
+---
+
+## 11. 데이터베이스
+
+- 스키마 설계가 적절한가?
+- 인덱스가 필요한 곳에 있는가?
+
+### 체크 포인트
+
+- `(oauth_provider, oauth_id)` unique 여부
+- nullable 정책 적절한가
+- enum 사용 시 확장성 고려했는가
+
+---
+
+## 12. 위험 신호 (중요)
+
+아래가 보이면 반드시 지적하세요.
+
+- ❌ 인증 로직이 Controller에 있음
+- ❌ Entity setter 남용
+- ❌ 트랜잭션 없이 엔티티 변경
+- ❌ unique 제약 없이 중복 생성 가능
+- ❌ 외부 API 응답을 그대로 신뢰
+- ❌ 비즈니스 로직이 여러 계층에 흩어짐
+
+---
+
+## 🧾 리뷰 출력 형식
+
+```text
+### 문제점
+- 설명
+
+### 왜 문제인가
+- 설명
+
+### 개선 방법
+- 설명
+
+### 개선 예시 코드 (선택)
+- 코드
+```
+
+---
+
+## 리뷰 우선순위
+
+1. 버그 가능성
+2. 데이터 정합성
+3. 보안
+4. 성능
+5. 설계
+6. 가독성
+
+---
+
+## 추가 지침
+
+- 작은 스타일 지적보다 **치명적인 설계 문제를 우선**
+- "이건 취향" 수준은 과하게 지적하지 않기
+- 반드시 **실무 기준으로 판단**

.claude/commands/branch.md

@@ -0,0 +1,74 @@
+---
+description: Create or suggest a git branch name using this repository's branch convention.
+argument-hint: "<type> #<issue-number> <brief Korean or English summary>"
+allowed-tools: Bash(git status --short), Bash(git branch --show-current), Bash(git switch -c *)
+---
+
+You are creating or suggesting a git branch for this repository.
+
+Use Korean.
+
+Branch naming convention:
+
+```text
+<git-commit-type>/#<issue-number>-<brief-english-description>
+```
+
+Examples:
+
+```text
+feat/#123-add-review-api
+fix/#346-handle-apple-email-missing
+refactor/#354-clean-partnership-period
+docs/#12-update-deploy-guide
+```
+
+Input from the user:
+
+```text
+$ARGUMENTS
+```
+
+Process:
+
+1. Identify the git commit type.
+2. Identify the issue number.
+3. Convert the feature/fix summary into short English kebab-case.
+4. Check current branch and working tree before creating.
+5. If the user only asks for a branch name, suggest the branch name only.
+6. If the user explicitly asks to create the branch, run `git switch -c <branch-name>`.
+
+Allowed commit types:
+
+```text
+feat, fix, refactor, style, docs, test, chore
+```
+
+Rules:
+
+- Always include `#` before the issue number.
+- Use lowercase English in the description.
+- Use kebab-case, not spaces, underscores, or Korean.
+- Keep the description short, usually 2-6 words.
+- If the issue number is missing, ask for it before creating a branch.
+- If the type is unclear, choose the most conservative type and explain briefly.
+- Before creating a branch, run `git status --short` and `git branch --show-current`.
+- If there are uncommitted changes, mention that they will remain in the working tree after switching.
+
+Output when suggesting:
+
+```text
+추천 브랜치명: feat/#123-add-review-api
+```
+
+Output when creating:
+
+```text
+생성할 브랜치명: feat/#123-add-review-api
+```
+
+Then run:
+
+```bash
+git switch -c feat/#123-add-review-api
+```

.claude/commands/commit.md

@@ -0,0 +1,60 @@
+---
+description: Create a git commit message using this repository's commit convention.
+argument-hint: "<brief context or leave empty to auto-detect from staged changes>"
+allowed-tools: Bash(git status --short), Bash(git diff --staged)
+---
+
+You are creating a git commit message for this repository.
+
+Use Korean.
+
+Commit message convention:
+
+```text
+<type>: <한글로 간단하게>
+```
+
+Examples:
+
+```text
+feat: 리뷰 생성 API 추가
+fix: 애플 로그인 이메일 누락 오류 수정
+refactor: Partnership 기간 타입 정리
+style: 코드 포맷 정리
+docs: 배포 가이드 업데이트
+test: 리뷰 서비스 단위 테스트 추가
+chore: 의존성 버전 업데이트
+```
+
+Input from the user:
+
+```text
+$ARGUMENTS
+```
+
+Process:
+
+1. Run `git status --short` to check staged files.
+2. Run `git diff --staged` to inspect actual changes.
+3. Identify the appropriate commit type from the changes.
+4. Write a short Korean description summarizing what changed and why.
+
+Allowed commit types:
+
+```text
+feat, fix, refactor, style, docs, test, chore
+```
+
+Rules:
+
+- Description is written in Korean.
+- Keep it short and clear — one line only.
+- Focus on "무엇을 왜" not "어떻게".
+- Do not end with a period.
+- If nothing is staged, mention it and do not suggest a commit message.
+
+Output format:
+
+```text
+커밋 메시지: feat: 리뷰 생성 API 추가
+```