feat/ #35 옷테이블 컬러테이블 분리

[warcat12]

📌 관련 이슈

관련된 이슈 번호를 작성해 주세요.

Closes #35

---

🛠️ 작업 내용

구현한 내용을 간략히 설명해 주세요.
옷테이블과 컬러테이블 분리
옷 테이블 동시 입력 막기 위해 version 추가

✅ 변경 사항

• 옷 테이블 변경
• 컬러 테이블 변경

🔍 테스트 내용

테스트한 방법과 결과를 작성해 주세요.

• 단위 테스트 작성 / 확인
• 기능 동작 확인

📷 스크린샷 (선택사항)

UI 변경이 있는 경우 첨부해 주세요.

💬 리뷰어에게

리뷰 시 특별히 봐줬으면 하는 부분이 있다면 작성해 주세요.

---

📋 PR 체크리스트

• develop 브랜치를 base로 설정했나요?
• 코드 컨벤션을 준수했나요?
• 불필요한 주석 / 디버그 코드를 제거했나요?
• 관련 이슈 번호를 연결했나요?

[github-actions]

ℹ️ Claude 코드 리뷰 생략: 변경된 파일이 18개로 너무 많습니다. 10개 이하로 분리하는 것을 권장합니다.

[github-actions]

Test Results

1 tests  ±0   1 ✅ ±0   0s ⏱️ ±0s
1 suites ±0   0 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit 5cfa8a1. ± Comparison against base commit 5aab159.

♻️ This comment has been updated with latest results.

[github-actions]

✅ 테스트 결과: 모든 테스트 통과

항목	수
전체	1
통과	1
실패	0
건너뜀	0

[jychoi0831]

P0: 기존 DB에서 신규 등록이 실패할 가능성이 큽니다.
현재 설정이 ddl-auto: update인데 application.yml (line 10), 기존 clothes 테이블에는 wardrobe_id, color, is_favorite 같은 NOT NULL 컬럼이 이미 만들어져 있었을 가능성이 높습니다. #35의 새 Clothes.java (line 40)는 이 컬럼들을 제거했고, ClothesService.java (line 108)는 clothes 저장 시 해당 값들을 넣지 않습니다. Hibernate update는 기존 컬럼을 안전하게 drop/backfill하지 않으므로, 기존 DB에서는 insert가 color/wardrobe_id 누락으로 실패할 수 있습니다.
해결: clothing_colors, wardrobe_clothes 생성 및 기존 clothes.color, clothes.wardrobe_id, clothes.is_favorite 백필 SQL이 필요합니다.

P1: 목록/상세 조회 쿼리가 런타임에 MultipleBagFetchException을 낼 수 있습니다.
WardrobeClothesRepository.java (line 17)에서 c.colorTags와 c.styleTags를 동시에 join fetch합니다. 둘 다 Clothes.java (line 78)의 List 컬렉션이라 Hibernate bag fetch 제한에 걸릴 수 있습니다.
해결: fetch를 분리하거나, 한쪽을 Set/@OrderColumn 기반으로 바꾸거나, batch fetch/entity graph로 나누는 방식이 필요합니다.

P1: 기존 데이터가 새 테이블로 백필되지 않으면 목록 API가 빈 배열을 반환합니다.
#35 이후 보유/위시리스트 목록은 WardrobeClothesRepository.java (line 15)의 wardrobe_clothes 기준으로 조회합니다. 기존 clothes row만 있고 wardrobe_clothes row가 없으면 사용자의 기존 옷이 모두 사라진 것처럼 보입니다. 색상도 clothing_colors가 없으면 ClothesResponse.java (line 46)에서 primaryColor가 null로 내려갑니다.

P2: sourceType과 ownershipStatus가 중복 상태가 됩니다.
새 WardrobeClothes.java (line 42)에 ownershipStatus가 생겼는데, 조회 필터는 여전히 WardrobeClothesRepository.java (line 23)에서 c.sourceType을 봅니다. ERD상 보유/위시리스트 상태가 옷장-옷 관계의 속성이라면 wc.ownershipStatus 기준으로 조회하는 편이 일관됩니다.

본 리뷰는 Codex를 사용해 작성했습니다.

[github-actions]

ℹ️ Claude 코드 리뷰 생략: 변경된 파일이 19개로 너무 많습니다. 10개 이하로 분리하는 것을 권장합니다.

[github-actions]

✅ 테스트 결과: 모든 테스트 통과

항목	수
전체	1
통과	1
실패	0
건너뜀	0

[jychoi0831]

반영된 부분은 좋습니다. 기존 colorTags/styleTags 동시 join fetch는 제거됐고, 목록 조회도 sourceType 대신 ownershipStatus 기준으로 바뀌었습니다. 최신 원격 기준 compileJava --offline도 성공했습니다.

1. migration.sql (line 12)의 핵심 백필 SQL이 전부 주석 처리되어 있고, 프로젝트에 Flyway/Liquibase 설정도 없어 자동 실행되지 않습니다. 또 예시 SQL이 SELECT id를 쓰는데 실제 컬럼명은 clothes_id라서 그대로 풀어도 실패합니다.

2. ClothesStyleTag.java (line 47)에 style_role, sort_order가 NOT NULL로 추가됐지만 기존 clothing_styles 데이터 백필이 migration에 없습니다. 기존 스타일 태그 row가 있으면 schema update/조회 시 문제가 날 수 있습니다.

3. ./gradlew test --offline는 여전히 실패합니다. 원인은 feat/ 옷에서 컬러 분리 #35 로직보다는 테스트 DB 설정 문제로, ${DB_USERNAME} 값이 치환되지 않은 채 MySQL 접속을 시도하면서 contextLoads가 실패합니다.

요약하면, 런타임 fetch 문제는 개선됐고 방향은 좋아졌습니다. 남은 핵심은 “실제 DB 마이그레이션 스크립트를 실행 가능한 형태로 완성하는 것”입니다.

본 리뷰는 Codex를 사용해 작성했습니다.

[github-actions]

ℹ️ Claude 코드 리뷰 생략: 변경된 파일이 19개로 너무 많습니다. 10개 이하로 분리하는 것을 권장합니다.

[github-actions]

✅ 테스트 결과: 모든 테스트 통과

항목	수
전체	1
통과	1
실패	0
건너뜀	0