feat: (#169) 상점 API 통합

[electrohyun]

📝 작업 내용 (Description)

• 상점 관련 API(인벤토리, 코스메틱, 소모품 조회 및 구매) 연동을 완료했습니다.
• 소모품(기술 아이템)의 다중 구매 로직 및 수량 관리 기능을 구현했습니다.
• 상점 도메인의 흩어져 있던 기능(장바구니, 구매)을 features/shop으로 통합 관리하도록 리팩토링했습니다.

✨ 변경 사항 (Changes)

• ProductCard, ShopProfilePanel, ShopPurchaseModal 등 API 데이터 기반으로 전환
• 소모품 항목은 보유 여부와 상관없이 중복 담기 가능 및 quantity 기반 페이로드 전송 로직 적용
• features/cart, features/shop-purchase 기능을 features/shop으로 병합하여 응집도 향상
• 데이터 페칭, 필터링, 구매 로직을 오케스트레이션하는 전용 훅 추가(useShop.ts)

📸 스크린샷 (Screenshots)

✅ 리뷰어 체크리스트 (Reviewer Checklist)

• 코드가 문제없이 빌드되고 실행되는가?
• 코드 스타일 컨벤션을 준수하는가?
• 불필요한 로그나 주석이 없는가?
• 관련 문서(README 등)가 업데이트되었는가?

📢 참고 사항 (Notes)

• 생략하겠습니다.

🧐 이슈 (Related Issues)

• Closes 상점 페이지: API 연결 #169

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
10term-pollycasso-front	Ready	Preview, Comment	Feb 11, 2026 11:09am

[ssi02014]

@electrohyun 이런 각각의 단일 api 로직들을 각각의 파일로 관리하는게 이유가 있을까요? 🤔 단일 api 로직들을 모두 개별 파일로 관리하면 파일 수가 과도하게 많아지지 않을까요? 어떤 의도가 있는지 궁금합니다 ㅎㅎ

[electrohyun]

리뷰 감사합니다! 프로젝트 초기에 고민했던 부분입니다.

유틸 함수쪽에서는(사진은 Drawing입니다.) 제가 느끼기에 같은 목적을 위해 작성된 코드는 같은 파일에 작성해두려 했던것 같습니다.

각각 '색상 관련' / 'DOM 관련' / '페인트통 도구 관련'으로 생각할 수 있었던 반면,

API는 'Consumable 불러오기' / 'Cosmetic 불러오기' / 'Inventory 불러오기' / '구매하기' 이렇게 다른 목적을 위해 작성되었기 때문에 다른 파일 로 나누자라고 생각해왔습니다.

물론 그렇다고 해서, 파일을 이렇게 계속 분리한다면, 서비스 규모가 더 커질 때 파일이 정말정말 많아질 것 같고, 결과적으로 안좋겠다. 하는 생각도 들기 때문에 제 말이 맞다고는 절대 할 수 없다고 생각합니다.😅

이런 응집도와 분리의 적정선을 결정할 때 @ssi02014 님은 주로 어떤 기준(팀 컨벤션, 기준 등등)을 참고하시는지 여쭤봐도 괜찮을까요? 혹은 제가 이런 설계 감각을 익히기 위해 참고할 만한 좋은 공부 주제가 있다면 추천 부탁드리고 싶습니다! 😭