👗 패션을 쉽게 MollyMol

온라인 패션 커머스 플랫폼

---

📅 프로젝트 정보

• 기간: 2025년 2월 ~ 2025년 3월 (8주간)
• 팀 구성: (예: Backend 2명 / Frontend 2명)
• 나의 담당 영역: (예: 상품/주문/결제 도메인 설계 및 구현)

---

📽️ 시연 영상

https://drive.google.com/file/d/13Jez_t-zlCY9VO-dskcfzjaCsl4pcMxr/view

---

📌 프로젝트 개요

MollyMol은 사용자가 상품을 탐색하고, 장바구니에 담아 결제하고, 리뷰를 작성할 수 있는 커머스 플랫폼입니다.

상품 대량 등록, 검색 필터링, 인기 리뷰 집계 기능 등을 통해
실제 운영을 고려한 구조를 목표로 개발하였습니다.

---

🚀 주요 기능

1️⃣ 회원가입 / 로그인

• 이메일 기반 회원가입 및 로그인
• 마이페이지에서 회원 정보 관리

2️⃣ 상품 관리

• 상품 검색 및 필터링
• 상품 상세 조회 (이미지, 설명, 리뷰, 재고, 배송 정보)
• 상품 단건/대량 등록
• 상품 수정 및 삭제

3️⃣ 장바구니

• 상품 담기
• 옵션 및 수량 변경
• 전체 선택 / 전체 삭제

4️⃣ 결제

• Toss API 기반 결제
• 포인트 사용 결제 지원

5️⃣ 주문 및 배송 관리

• 기본 배송지 설정 및 관리
• 주문 내역 조회

6️⃣ 리뷰

• 배송 완료 상품에 한해 리뷰 작성
• 리뷰 수정/삭제
• 리뷰 좋아요
• 최근 7일 인기 리뷰 Top 12 조회

---

🙋 나의 역할

🔹 상품 도메인 설계 및 구현

• 상품(Product)과 옵션(ProductItem)을 분리하여 설계하고, 재고를 옵션 단위로 관리하도록 구조화

• 카테고리, 가격, 정렬 조건을 포함한 동적 검색 쿼리 설계 및 페이징 처리 구현

• 판매량 및 조회수 집계를 고려하여 집계 컬럼 관리 전략 적용

---

🧠 기술 과제 및 문제 해결 – 상품 목록 조회 성능 개선

1. 문제 배경

상품 목록 조회 API의 응답 속도가 기대 수준에 미치지 못하는 문제가 발생하였습니다.

🎯 목표

• 다수 사용자 환경에서 95% 응답 시간 1초 이내
• 최악의 경우(최대 응답 시간) 2초 이내

---

2. 1차 분석 – 쿼리 구조 최적화

📌 테스트 환경

• 로컬 환경
• 데이터 1,000만 건

📌 분석 방법

• 각 케이스별 쿼리 응답 시간 직접 측정
• JOIN 구조 개선
• ORDER BY / DISTINCT 최적화
• 인덱스, 복합 인덱스, 커버링 인덱스 적용
• GROUP BY 및 파티셔닝 검토

📊 1차 결과

JOIN 최적화

• 평균: 15.5초 → 7.2초
• 최대: 85초 → 21초

ORDER BY / DISTINCT 최적화

• 다양한 인덱스 전략 적용
• 기대 수준의 성능 개선은 달성하지 못함

🔎 문제 원인

1. 상품 목록 조회에 필요한 컬럼이 상품 테이블과 아이템 테이블에 분리되어 있음
2. LIMIT을 활용한 ORDER BY 최적화를 JOIN 구조상 적용할 수 없음

---

3. 구조 개선 – 비정규화 적용

💡 해결 전략

비정규화를 통해 JOIN 내부에서 ORDER BY + LIMIT을 활용할 수 있도록 구조를 변경

📊 성능 개선 결과 (로컬, 1,000만 건)

• 평균: 7.2초 → 42ms
• 최대: 21초 → 80ms

📊 배포 환경 (데이터 30만 건)

• 평균: 102ms
• 최대: 150ms

쿼리 구조 단순화만으로 대폭적인 성능 개선 달성

---

4. 2차 분석 – 부하 테스트

📌 테스트 조건

• 가상 유저: 100명
• Ramp-Up: 10초
• Duration: 180초
• 요청 당 1초 딜레이

📌 유저 시나리오

• 20개 검색 조건 사용
• 검색 + 스크롤 10회 반복

---

📊 1차 부하 테스트 결과

• 평균: 5.8초
• 최소: 0.61초
• 최대: 7.3초
• 95%: 6.8초
• 99%: 7초

최소값이 600ms 이상으로 비정상적으로 높게 측정됨

---

5. 병목 원인 분석 – 카테고리 조회

📌 문제 상황

• 상품 목록 응답 시 각 상품의 카테고리 ID를 카테고리 경로로 변환하여 반환
• 상품 수만큼 카테고리 조회 쿼리 발생
• 카테고리 테이블이 재귀 구조로 구성되어 깊이에 따라 추가 쿼리 발생

📌 지연 계산

• 상품 40개
• 최소 카테고리 조회 1회
• 네트워크 평균 지연 15ms

40 × 15ms = 600ms

→ 최소 응답 시간이 600ms 이상이 된 원인

---

6. 해결 – 캐시 적용

📌 적용 전략

Spring SimpleCacheManager 적용

📌 선택 이유

• 카테고리 정보 변경 가능성이 낮음
• 캐싱 데이터 크기가 매우 작음
• 인메모리 캐시로 충분히 처리 가능

---

7. 캐시 적용 후 성능 비교

구분	평균	최소	최대	95%	99%
Before	5.8초	0.61초	7.3초	6.8초	7초
After	2.3초	0.025초	5.6초	3.5초	3.9초

---

✅ 최종 결과

• 최소 응답 시간: 0.61초 → 25ms
• 평균 응답 시간: 5.8초 → 2.3초
• 95% 응답 시간: 6.8초 → 3.5초

---

🎯 문제 해결 과정 요약

1. JOIN 및 정렬 구조 최적화
2. 비정규화를 통한 쿼리 단순화
3. 부하 테스트 기반 병목 분석
4. 카테고리 조회 캐싱 적용

---

💡 이 경험을 통해 얻은 역량

• 대용량 데이터 기반 성능 개선 경험
• 쿼리 실행 구조 및 인덱스 전략 이해
• 비정규화에 대한 실용적 판단
• N+1 문제 분석 및 해결
• 부하 테스트 기반 병목 지점 도출
• 캐시 전략 설계 및 적용 경험

---

📚 기술 스택

---

🌏 서버 아키텍처

---

🗺️ ERD

---

🧑‍🤝‍🧑 팀 역할