플랫폼 특징 정하기
커머스 플랫폼을 개발하기로 결정한 후, 한국에서 성공적으로 운영 중인 커머스 플랫폼들을 살펴보니 크게 두 갈래로 나눌 수 있었습니다.
- 범용 커머스 플랫폼: 쿠팡, 네이버 쇼핑, 11번가
- 특화 커머스 플랫폼: 무신사(의류), 당근마켓(중고), 오늘의 집(셀프 인테리어), 아이디어스(핸드메이드)
평소 잘 아는 분야가 있었다면 그쪽 분야 특화 커머스 플랫폼(자전거 용품, 전자제품 등)으로 정했겠지만, 개발 외에는 딱히 익숙한 분야가 없었습니다. 마침 사는 곳 근처에 코스트코가 있어서, 초기 판매자 확보 전 직접 테스트 판매자로서 활동해 보기에 좋겠다는 생각이 들었고 추후 좋은 아이디어가 생기면 해당 제품군 특화 서비스로 개편할 수도 있다는 점에서 일단은 범용 커머스 플랫폼으로 방향을 정하게 되었습니다.
범용 커머스 플랫폼 중에서 제가 실제 자주 사용하는 쿠팡과 네이버 쇼핑, 두 사이트를 참고하기로 했습니다.
커머스 플랫폼의 기능 구성
두 사이트를 참고해보니, 대략적인 기능 구성은 다음과 같았습니다.
- 인증: 로그인, 회원가입 등
- 사용자: 프로필, 배송 주소, 결제수단 관리 등
- 상품: 상품 목록, 상품 상세, 리뷰, 문의 등
- 주문: 장바구니, 주문, 결제, 환불 등
- 판매자 센터: 상품, 배송, 리뷰, 문의, 매출 관리 등
- 어드민: 쇼핑몰 관리자가 구매자, 판매자, 상품정보 등을 관리하는 페이지
프론트 및 백엔드를 모두 혼자 개발하는 입장에서, 위 기능을 처음부터(그것도 실 사용자에게 제공 가능한 퀄리티로) 모두 구현하는 것은 무리라는 판단이 들었습니다.
큰 개발 범위에 압도당하지 않고 방향과 동기를 잃지 않으려면, 우선 MVP(최소 기능 구현) 범위를 설정하여 구현한 뒤, 점진적으로 업데이트해 나가는 방식이 적절해 보였습니다. 그리고 MVP를 구현할 때는 최소 기능들을 구현하면서도, 추후 커머스 플랫폼 사이즈로 확장하기 쉬운 구조로 구현하는 것이 중요하다는 생각이 들었습니다.
MVP 범위 정하기
MVP의 범위는 "물건을 사고판다"는 서비스의 최소한의 정체성을 만족하는 것 외에는 모두 제외하는 방향으로 설정했습니다.
상품 판매는 사이트 운영자만 가능한 자사몰 형태의 서비스로 시작한다면, 판매자 센터 기능을 구현하지 않아도 되며, 어드민 기능에서도 판매자 관련 기능들을 제외할 수 있어 구현 범위가 크게 줄어듭니다.
이를 바탕으로 정한 MVP의 범위는 아래와 같습니다.
- 인증: 로그인, 회원가입 등
- 사용자: 프로필, 배송 주소, 결제수단 관리 등
- 상품: 상품 목록, 상품 상세, 리뷰, 문의 등
- 주문: 장바구니, 주문, 결제, 환불 등
- 어드민: 쇼핑몰 관리자가 구매자, 상품정보 등을 관리하는 페이지
확장 가능한 MVP를 위한 설계 원칙
MVP를 확장 가능한 구조로 구현하지 않으면, 이후 판매자 기능을 추가할 때 단순 기능 추가가 아니라 구조 재설계를 해야하는 상황이 생길 수 있습니다. 그런 상황을 피하기 위해 다음과 같은 3가지 원칙을 적용하기로 했습니다.
1. 운영자도 하나의 Seller로 설정한다
- Seller 테이블을 만들고, 사이트 운영자를 하나의 Seller로 설정합니다.
- 상품(Product), 배송(Shipment)처럼 추후 seller_id가 필요해질 모든 테이블에 seller_id 컬럼을 추가하고, 관련 데이터 처리 로직작성 시 seller_id를 활용하여 작성합니다.
- 판매자 정보가 필요한 API 요청과 응답에 Seller 정보를 포함시킵니다.
이렇게 하면, 추후 판매자 기능 추가 시 Repository 계층 코드, API 인터페이스, 그리고 이를 사용하는 프론트엔드 코드까지 수정해야 수고를 줄일 수 있습니다.
2. 역할 기반 접근 제어(RBAC)를 도입한다.
- USER, ADMIN, SELLER등의 역할을 정의하고, 각 역할별 권한을 설정합니다.
- API 구현 시 역할 기반 접근 제어를 적용합니다.
- 사이트 운영자에게는 ADMIN, SELLER 권한을 모두 부여합니다.
- 추후 판매자의 영역이 될 기능들을 구현할 때 SELLER 권한 기준으로 구현합니다.
이렇게 하면, 판매자 기능 도입 시 권한 검사 구조를 재구성하거나 권한 검사가 적용된 코드들을 수정해야 하는 수고를 줄일 수 있습니다.
3. 핵심 작업은 이벤트 발행 패턴으로 구현한다.
- 주문, 결제 등 부수 작업(재고 차감, 알림 발송, 정산 데이터 생성 등)이 많이 따라붙는 핵심 작업은 이벤트 발행 패턴으로 구현합니다.
이렇게 하면, 판매자 기능 도입 후 늘어나는 부수작업들을 위해 작업 처리 구조를 이벤트 발행 패턴으로 변경하는 수고를 줄일 수 있습니다.
이번 글에서는 커머스 플랫폼 구현을 위한 MVP 기획을 해보았습니다. 다음 글에서는 서비스 개발에 사용할 기술 스택을 선정해 보겠습니다.
