pgms

[5주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 24

Ejah 2026. 2. 6. 15:48

유사 도서 커머스(YES24·알라딘 등) 비교·분석

2차 프로젝트 설계서는 도서 커머스의 핵심 흐름(도서 탐색→상세 확인→좋아요/장바구니→주문→주문 조회)을 중심으로 구성되어 있다.

다만 실제 도서 쇼핑몰(YES24, 알라딘 등)은 탐색 편의성, 구매 전환(결제·혜택), 신뢰(리뷰/평점), **재방문(개인화)**을 강화하는 기능을 폭넓게 제공한다. 이를 기준으로 프로젝트에 추가하면 좋은 기능을 다음과 같이 정리할 수 있다.

1) 탐색/검색 고도화 (전환율에 직결)

설계서의 검색은 “키워드·카테고리·페이지·목록 개수” 중심이다

실서비스는 검색을 더 세밀하게 분해해 사용자가 원하는 책을 빠르게 찾도록 돕는다.

  • 상세 필터: 가격 범위, 출판사, 출간일, 재고/품절, 배송 가능 여부(당일/익일), 포맷(종이책/전자책) 등
  • 정렬 옵션: 인기순(판매량), 평점순, 리뷰 많은 순, 최신순, 가격 낮은/높은 순
  • 자동완성/추천 검색어: 입력 중 연관 키워드 제안, 오타 교정, 인기 검색어 노출
  • 카테고리 탐색 강화: 대분류-중분류-소분류(다단 카테고리) 및 카테고리별 베스트(설계서에도 “이 분야 베스트”가 암시됨)

프로젝트 적용 포인트: 목록 API에 sort, minPrice, maxPrice, pub, publishedFrom~To 같은 쿼리 파라미터를 확장하고, 인덱스/동적쿼리(SQL or ORM) 설계를 함께 보여주면 점수가 큼.

2) 리뷰/평점 시스템 (신뢰 형성의 핵심)

설계서에는 “리뷰 목록 노출(작성자·날짜·내용)”이 있으나, 리뷰 작성/평점/집계는 명시가 약하다

  • 평점(별점) + 리뷰 작성/수정/삭제
  • 리뷰 정렬/필터: 최신순, 평점 높은/낮은 순, 포토리뷰만 보기
  • 리뷰 요약 통계: 평균 평점, 평점 분포(5점 00%), 키워드 태그(“배송 빨라요”, “가독성 좋아요” 등)
  • 프로젝트 적용 포인트: “구매자만 리뷰 작성 가능” 같은 정책을 넣으면 권한/검증 로직이 자연스럽게 생기고 완성도가 올라감.

3) 개인화(추천/최근 본 상품) (재방문 유도)

실서비스는 사용자를 다시 오게 만드는 장치가 많다. 설계서에는 “신간 안내”와 “메인 슬라이드”가 있으나 개인화 요소는 제한적이다

  • 최근 본 도서 목록
  • 관심사 기반 추천: 사용자의 좋아요/장바구니/주문 카테고리 기반 추천
  • 맞춤 큐레이션: “당신이 좋아할 만한 책”, “이 책을 본 사람들이 함께 본 책(연관상품)”

프로젝트 적용 포인트: 추천을 ML로 하지 않아도 됨. 단순 규칙(같은 카테고리 인기순, 함께 장바구니 담긴 조합)만으로도 “개인화” 성격을 충분히 보여줄 수 있음.

4) 장바구니/주문 경험 강화 (실무형 기능)

설계서의 장바구니는 “목록/삭제/체크한 상품 주문요청” 중심이다

실서비스는 구매 전환을 높이기 위해 세부 기능이 촘촘하다.

  • 수량 변경, 옵션(포맷) 변경
  • 쿠폰/포인트/적립금 적용
  • 배송비 정책: 무료배송 조건(금액 기준), 배송비 계산
  • 주문 상태 관리: 결제완료→상품준비→배송중→배송완료 / 취소·환불 흐름
  • 프로젝트 적용 포인트: 주문 테이블에 status, paymentMethod, deliveryFee, discount 등을 두면 도메인 설계가 확 살아남.

5) 이벤트/혜택/랭킹 (커머스의 운영 요소)

YES24·알라딘 같은 사이트는 “상품 판매”뿐 아니라 운영(프로모션) 기능이 강하다.

  • 베스트셀러/스테디셀러 랭킹
  • 카테고리별 TOP N
  • 기획전/이벤트 배너: 특정 주제 묶음(“자기계발 주간”, “토익 기획전”)
  • 알림/구독: 찜한 책 할인/재입고 알림

프로젝트 적용 포인트: 메인 슬라이드(배너)를 백엔드 API로 제공할지 논의가 필요하다고 설계서에 적혀 있으므로

배너/기획전 API”는 자율 기능으로 매우 자연스러운 확장.

6) 계정 보안/운영 품질 (백엔드 과제에서 강력한 가산점)

요구사항 문서에는 예외처리/유효성검사/dotenv/토큰(선택) 등이 포함되어 있다

이를 실서비스 수준으로 확장하면 “완성도”를 보여주기 좋다.

  • Refresh Token 도입 + 재발급 로직
  • 로그인 실패 횟수 제한 / 계정 잠금(간단 정책)
  • 비밀번호 재설정 토큰(만료시간 포함)
  • API 공통 응답 포맷 + 에러 코드 체계화

추가 구현하면 좋은 기능

현재 프로젝트는 도서 조회 → 상세 → 좋아요 → 장바구니 → 주문 → 회원 인증이라는
기본적인 서비스 흐름을 충실히 다루고 있다.
이 흐름을 확장하거나, 실제 서비스에 가까운 요소를 보완하는 방향이 적절하다.

아래는 기존 기능과 자연스럽게 연결되면서도, 구현 난이도와 학습 효과가 높은 추가 기능들이다.

1. 사용자 활동 이력 관리 기능 (마이페이지 확장)

추가 이유

현재는 로그인/주문 기능이 존재하지만, 사용자의 “이력”을 보여주는 화면은 없다.
실제 서비스에서는 사용자 중심 기능이 핵심이므로, 마이페이지 개념을 도입하면 완성도가 크게 올라간다.

 

추가 기능 예시

  • 내가 좋아요 누른 도서 목록 조회
  • 최근 주문 내역 요약
  • 최근 본 도서 목록 (조회 이력)

백엔드 구현 포인트

  • user_activity, view_history 테이블 추가
  • JWT 토큰 기반 사용자 식별
  • /users/me/likes, /users/me/orders 같은 REST API 설계
  • 인증 + 데이터 관계 설계를 동시에 연습할 수 있는 좋은 확장 포인트

2. 리뷰 작성 및 평점 기능

추가 이유
화면 설계서에는 “리뷰 목록 조회”만 존재하고, 리뷰 작성 기능은 명시되지 않았다.
자율 주제로 CRUD 기능을 완성하기에 가장 적합한 요소다.

 

추가 기능 예시

  • 리뷰 작성 / 수정 / 삭제
  • 별점(1~5점) 등록
  • 도서 평균 평점 계산

백엔드 구현 포인트

  • reviews 테이블 설계 (user_id, book_id, rating, content)
  • 하나의 유저는 한 도서에 하나의 리뷰만 작성 가능하도록 제약
  • 평균 평점 계산을 위한 서브쿼리 또는 JOIN
  • DB 설계, 유효성 검사, 권한 체크를 모두 다룰 수 있음

3. 주문 상태 관리 및 상태 변경 이력

추가 이유
현재 주문은 “생성”까지만 정의되어 있으며, 이후 흐름은 단순 조회 수준이다.
주문 상태 개념을 추가하면 실제 커머스 서비스 구조에 가까워진다.

 

추가 기능 예시

  • 주문 상태: 결제완료 / 배송중 / 배송완료 / 취소
  • 주문 상태 변경 이력 조회
  • 취소 가능 조건 처리 (배송 전까지만 가능)

백엔드 구현 포인트

  • orders.status 컬럼 추가
  • 상태 변경 시 이력 테이블(order_logs)에 기록
  • 상태에 따른 API 접근 제어
  • 비즈니스 로직(Service Layer)의 필요성을 자연스럽게 보여줄 수 있음

4. 관리자(Admin) 기능 분리

추가 이유
일반 사용자 기능만 있는 서비스는 한계가 있다.
관리자 기능을 분리하면 권한(Role) 개념을 도입할 수 있다.

 

추가 기능 예시

  • 도서 등록 / 수정 / 삭제
  • 카테고리 관리
  • 전체 주문 목록 조회

백엔드 구현 포인트

  • JWT payload에 role(USER, ADMIN) 포함
  • 관리자 전용 미들웨어 구현
  • /admin/books, /admin/orders API 분리
  • 실무에서 매우 중요한 “권한 기반 접근 제어” 경험 가능

5. 검색 및 필터 고도화

추가 이유
기존 검색은 키워드 중심이다. 이를 확장하면 SQL 활용도가 높아진다.

 

추가 기능 예시

  • 가격 범위 필터
  • 좋아요 수 기준 정렬
  • 평점 높은 순 정렬
  • 출간일 기준 정렬

백엔드 구현 포인트

  • 쿼리 파라미터 기반 동적 SQL
  • ORDER BY / WHERE 조건 조합
  • 인덱스 고려한 조회 쿼리
  • SQL 실력과 API 설계 역량을 동시에 어필 가능

6. 공통 응답 포맷 및 에러 코드 체계화 (완성도 강화)

추가 이유
요구사항에 이미 “response 포맷 정돈”이 있지만, 자율 주제로 더 정교하게 만들 수 있다.

 

추가 기능 예시

  • 성공/실패 공통 응답 구조 통일
  • 에러 코드 enum 관리
  • 클라이언트 친화적인 에러 메시지

백엔드 구현 포인트

  • ApiResponse 유틸 모듈
  • 글로벌 에러 핸들러
  • 커스텀 에러 클래스
  • 단순 기능 구현을 넘어서 “잘 설계된 API”라는 인상을 줌

마무리 정리

중요한 것은 새로운 기술을 무작정 추가하는 것이 아니라,
기존 서비스 흐름을 자연스럽게 확장하고 완성도를 높이는 것이다.

위에서 제안한 기능들은

  • 기존 화면/기능과 충돌하지 않고
  • 백엔드 핵심 역량(DB, 인증, 권한, 비즈니스 로직)을 잘 드러내며