1. 상품 정보와 관리 정보는 분리
상품에는 상품명, 상품코드, 카테고리와 같이 서비스 운영에 필요한 핵심 정보가 존재한다.
반면 관리자 메모, 운영 정책, 내부 관리용 데이터와 같은 정보는 상품 자체와는 성격이 다르다.
이러한 데이터를 모두 상품 테이블에 저장하게 되면 운영 요구사항이 추가될 때마다 상품 구조가 복잡해질 수 있다.
따라서 상품의 핵심 정보와 관리 목적의 정보는 별도의 매핑 테이블로 분리하는 것이 좋다.
2. 가격은 반드시 이력을 남길 수 있어야 한다.
가격은 상품 정보 중 가장 자주 변경되는 데이터다.
이벤트 할인, 원가 변동, 프로모션 등 다양한 이유로 가격이 변경될 수 있기 때문에 현재 가격만 저장하는 방식은 한계가 있다.
따라서 현재 가격과 가격 변경 이력을 분리하여 관리하는 것이 좋다.
특히 운영 중에는 이런 요구사항이 자주 발생한다.
아래 상황을 고려하면 가격 이력 테이블은 사실상 필수에 가깝다.
- 지난달 가격이 얼마였는지 확인하고 싶다.
- 특정 기간 동안의 가격 변동 내역을 보고 싶다.
- 할인 적용 전 가격을 조회하고 싶다.
3. 상품 노출 정책은 별도로 관리하자
상품이 생성되었다고 바로 사용자에게 노출되는 것은 아니다.
실제 서비스에서는 관리자(Admin)에서 상품을 생성한 후 Mall에 노출되기까지 여러 정책이 존재한다.
가장 기본적으로는 상품 노출 여부와 상품 상태를 분리하는 것을 추천한다.
상품 노출 여부
- 전시
- 비전시
상품 상태
- 판매중
- 판매중지
- 숨김
- 품절
*아래는 예시이고 운영정책에 따라 정해서 진행하면 좋음
| 리스트 노출여부 | URL 접근가능여부 | 구매가능 여부 | 장바구니 담기 | 장바구니 구매 | |
| 판매중 | 노출 | 접근가능 | 구매가능 | 담기가능 | 구매가능 |
| 판매중지 | 비노출 | 접근불가 | 구매불가 | 담기불가 | 구매불가 |
| 숨김 | 비노출 | 접근가능 | 구매가능 | 담기가능 | 구매가능 |
| 품절 | 비노출 | 접근가능 | 구매불가 품절표시 | 담기불가 | 구매불가 품절표시 |
리스트에는 노출하지 않지만 URL을 알고 있는 사용자만 접근할 수 있기 때문에 다음과 같은 상황에 활용할 수 있다.
- 이벤트 상품
- 사전 공개 상품
- 테스트 상품
4. 정렬 정책은 초기에 고민하는 것이 좋다.
상품 서비스에서는 정렬 기능 요청이 생각보다 많다.
대표적으로 다음과 같은 정렬이 존재한다.
- 최신순 가격
- 오름차순 가격
- 내림차순
- 추천순
- 커스텀 정렬
특히 운영자는 특정 상품을 상단에 노출하고 싶어하는 경우가 많다.
이를 위해 별도의 정렬값(sort order)을 두는 것이 좋다.
5. 검색 편의성을 위한 검색 키워드 컬럼을 고려한다.
개발 초기에는 검색엔진(엘라스틱서치, 오픈서치) 도입이 당장 필요하지는않다.
필요에따라 도입을 고려할수있는데 그전에는 like 검색을 통해서 상품 검색을 구성한다.
내부 검색 로직을 커스텀해서 어느정도 고도화를 할수있지만
상품명 및 일부 컬럼만을 가지고는 검색정확도를 올리기가 어렵다.
사용자는 항상 정확한 상품명을 알고 검색하지 않는다.
예를 들어 상품명이 아래와 같다고 가정해보자.
"나이키 에어포스 1 로우 화이트" 하지만 실제 검색은 다음과 같이 이루어질 수 있다.
에어포스 AF1 흰운동화 나이키 신발 이처럼 상품명만으로는 검색 정확도를 높이는 데 한계가 있다.
따라서 검색 보조 키워드를 등록할 수 있는 기능을 제공하는 것이 좋다.
6. 상품은 최대한 독립적인 단위로 설계하자
초기 설계 단계에서는 특정 비즈니스 요구사항에 맞춰 상품 구조를 복잡하게 만드는 경우가 있다.
예를 들어 키트 상품이나 세트 상품을 상품 구조 자체에 녹여 설계하는 경우가 있다.
하지만 이런 방식은 시간이 지나면서 확장에 제약이 될 수 있다.
설계가 아니여도 운영단계에서도 세트상품을 상품에 녹여 상품을 구성할수 있는데 이부분도 주의하면 좋다.
상품은 최대한 독립적으로 관리하고, 여러 상품을 묶어 판매해야 한다면 별도의 묶음 상품 기능으로 해결하는 것이 좋다.
7. 상품 ID와 상품 코드는 구분하자
상품 설계 시 자주 놓치는 부분 중 하나가 상품 ID와 상품 코드의 역할 구분이다.
상품 ID는 시스템 내부 식별자다.
상품 코드는 운영자와 외부 시스템이 사용하는 비즈니스 식별자다.
이 둘의 역할을 분리해두면 상품 개편 시 유연하게 대응할 수 있다.
예를 들어 기존 상품을 수정하는 대신 새로운 상품을 생성하고 상품 코드만 변경하는 방식도 가능해진다.
8. 상품(Product)과 옵션(Option)은 분리해서 관리하자
상품을 설계하다 보면 상품 자체와 실제 판매 단위를 구분해야 하는 경우가 많다.
예를 들어 아래와 같은 상품이 있다고 가정해보자.
사용자가 실제 구매하는 것은 상품 자체가 아니라 옵션이 포함된 특정 상품이다.
상품명 : 반팔 티셔츠
색상 : 블랙
사이즈 : M
색상 : 블랙
사이즈 : L
색상 : 화이트
사이즈 : M만약 옵션 정보를 상품에 직접 저장하게 되면 상품 구조가 복잡해지고 확장에 제약이 발생한다.
따라서 상품(Product)과 옵션(Option)은 분리하여 관리하는 것이 좋다.
'정리 > 설계' 카테고리의 다른 글
| 상품 설계 전에 체크해봐야하는 비즈니스 모델 B2B B2C B2B2C B2B2B (0) | 2026.06.12 |
|---|