멀티 스토어·입점형 커머스, 처음부터 나눠야 하는 경계
“우리 브랜드몰 하나”로 시작한 서비스가 어느 순간 여러 매장, 입점 판매자, 지역 대리점을 품어야 하는 경우가 있습니다.
이때 단일몰 구조에 “매장 번호만 급하게 붙이면” 권한·정산·도메인·재고가 한꺼번에 새어 나갑니다.
멀티 스토어·입점형 커머스는 테마를 여러 개 만드는 일이 아닙니다. 데이터와 권한이 어디까지 공유되고 어디서 끊기는지를 정하는 일입니다. 이 경계를 오픈 이후에 바꾸면 주문·정산 이력이 섞여 이관 비용이 커집니다.
왜 이런 일이 생기나요?
먼저 사업 모델을 한 문장으로 고정해야 합니다.
| 모델 | 한 줄 정의 | 경계의 핵심 |
|---|---|---|
| 단일 브랜드 다점포 | 한 회사가 여러 매장·창고 | 재고 위치·출고 주체 |
| 입점형 마켓 | 여러 판매자가 한 플랫폼에 입점 | 판매자 정산·상품 검수·분쟁 |
| 화이트라벨(여러 독립 몰에 가깝게) | 입점 주체마다 거의 독립 쇼핑몰 | 데이터·도메인·결제 상점 분리 수준 |
이름이 “플랫폼”이어도 위 세 가지가 섞여 있으면 요구사항이 충돌합니다. 견적 전에 어느 모델에 가까운지 정하세요.
처음부터 나눠야 하는 경계는 대략 여섯 가지입니다.
1) 어느 매장·입점 주체 소속인지
상품, 주문, 쿠폰, 정산에 “누구 것인지”가 빠지면 안 됩니다. 목록 화면에는 필터로 가릴 수 있어도, 엑셀 다운로드·정기 작업·푸시에서 다른 가게 데이터가 섞입니다. 서버가 지금 로그인한 관리자의 범위를 강제해야 합니다. 화면에서 넘긴 매장 번호만 믿으면 권한 우회가 열립니다.
2) 회원은 공유할 것인가
플랫폼 전역 회원 + 매장별 프로필인지, 매장(입점)마다 완전 분리 회원인지에 따라 로그인·포인트·마케팅 동의·탈퇴 파기 범위가 달라집니다. 개인정보 열람·파기 청구 단위도 달라지므로 초기에 결정해야 합니다.
3) 상품 소유권
입점형은 판매자가 올리고 플랫폼이 검수하는 흐름이 일반적입니다. 단일 브랜드 다점포는 본사 마스터 상품에 매장별 판매 여부·가격만 다르게 두기도 합니다. 가격·재고·진열을 누가 수정할 수 있는지를 역할 표로 적지 않으면 관리자 화면이 사고 현장이 됩니다.
4) 주문·정산·수수료
입점형에서 고객은 한 번에 여러 판매자 상품을 담을 수 있습니다. 주문을 어떻게 쪼갤지(한 장바구니 vs 판매자별 하위 주문)가 배송·취소·정산의 뼈대입니다.
| 항목 | 단일몰 | 입점형에서 추가되는 것 |
|---|---|---|
| 결제 | 보통 1결제 | 판매자별 정산 배분, 부분취소 복잡도 |
| 배송 | 자사 물류 | 판매자별 송장·출고 지연 책임 |
| 수수료 | 내부 회계 | 플랫폼 수수료·프로모션 분담 |
| 고객센터 | 한 창구 | 판매자 이관·분쟁 중재 규칙 |
결제 정산 계좌를 플랫폼 단일로 둘지, 판매자 개별 상점으로 둘지에 따라 개발 범위가 크게 갈립니다. 계약·세무 조건과 개발 설계를 같은 자리에서 맞춰야 합니다.
5) 도메인·앱·푸시
도메인으로 입점을 가르는지, 앱은 하나인데 매장만 전환하는지, 앱을 입점별로 올리는지에 따라 심사·푸시·결제 설정 부담이 달라집니다.
6) 데이터 격리 수준
같은 DB에서 컬럼으로 구분하는 방식과, DB·스키마를 나누는 방식은 비용과 안전성이 다릅니다. 논리 격리로 시작해도 목록·엑셀·정기 작업에 매장 조건 누락이 치명적입니다.
이렇게 보면 쉬워요
단일몰을 억지로 확장할 때 생기는 일입니다.
- 관리자 메뉴는 늘었는데 권한 그룹이 “전체 관리자” 하나
- 정산 엑셀에 다른 매장 주문이 섞임
- 판매자 A가 판매자 B 주문을 조회
- 쿠폰을 전 스토어에 잘못 배포
- 탈퇴 회원 파기 시 어느 스토어 데이터까지인지 불명
이런 사고는 “기능 추가”가 아니라 경계 미설계의 결과입니다.
모든 경계를 1차 오픈에 넣을 필요는 없습니다. 다만 나중에 넣기 어려운 것과 나중에 넣기 쉬운 것을 구분하세요.
| 나중에 넣기 어려움(초기에 뼈대) | 비교적 나중에 가능 |
|---|---|
| 매장·입점 키·권한 강제 | 스토어 테마 스킨 |
| 주문 분할·정산 단위 | 고급 대시보드 차트 |
| 회원 공유/분리 결정 | 마케팅 자동화 문구 |
| 결제 상점·정산 구조 | 셀러 커뮤니티 게시판 |
“입점은 2단계”라고 말해도, 1단계 데이터 모델이 단일몰 전용이면 2단계에서 재개발에 가깝습니다.
이렇게 준비하면 좋아요
- □ 사업 모델이 다점포/입점/화이트라벨 중 어디에 가까운지 문장으로 고정했다
- □ 모든 핵심 기능이 서버에서 매장·입점 범위를 강제한다
- □ 회원·포인트·동의의 공유 범위가 결정되었다
- □ 상품 수정 권한(본사/매장/셀러/검수자)이 역할 표로 있다
- □ 다판매자 장바구니 시 주문 분할 규칙이 있다
- □ 정산 단위·수수료·프로모션 분담이 개발 전에 합의되었다
- □ 관리자 목록/엑셀/정기 작업에 매장 필터 누락 점검이 있다
- □ 도메인·앱·푸시가 단일인지 다중인지 결정했다
- □ 셀러(매장) 관리자와 슈퍼 관리자 계정이 분리된다
- □ 탈퇴·파기·열람 청구 단위가 정책과 맞다
자주 하는 실수
입점·다점포를 가정하지 않은 채 빠른 오픈만 선택하면, 확장 시점에 다음이 반복됩니다.
- 주문·정산 구조 재설계와 데이터 이관
- 셀러 도구를 임시 엑셀로 운영하며 생기는 휴먼 에러
- 권한 사고로 인한 개인정보·매출 정보 유출 리스크
- 앱·도메인·푸시를 입점별로 급하게 복제하며 운영 파편화
플랫폼형 커머스의 견적이 단일몰보다 큰 이유는 화면 수 때문이 아니라 경계와 예외 상태 때문입니다.
LB Contents는 단일 쇼핑몰뿐 아니라 다점포·입점형·운영 권한 구조가 필요한 커머스도 경계 설계부터 함께 잡습니다. 확장 계획이 있는 1차 오픈 범위 정리 상담이 가능합니다.