B2B·B2C 쇼핑몰 개발
파는 방식이 다르면
필요한 시스템도 다릅니다
핵심 답변
미션비는 일반 소비자용 B2C 자사몰, 거래처 전용 B2B 발주몰, 그리고 위탁판매와 사입을 함께 쓰는 쇼핑몰을 요구사항에 맞춰 개발합니다. 화면을 먼저 그리지 않고 회원등급별 가격 정책, 옵션과 분리한 SKU, 정산 기준을 먼저 정의한 뒤 주문·결제·배송·정산과 관리자 화면을 함께 만듭니다. 결제·택배·오픈마켓·ERP 연동은 대상 서비스가 제공하는 방식에 따라 가능 범위가 달라지므로 상담 단계에서 함께 확인합니다.
같은 '쇼핑몰'이라도 일반 소비자에게 파는 것과 거래처에 발주를 받는 것, 재고를 사서 파는 것과 공급사 물건을 대신 파는 것은 전혀 다른 시스템입니다. 미션비는 자사 쇼핑몰을 직접 운영하면서 이 차이를 겪어 왔고, 화면보다 먼저 가격 정책·재고 단위·정산 기준을 정리하는 방식으로 개발합니다.
B2C 쇼핑몰
모든 고객에게 같은 가격. 상품 노출, 프로모션, 결제 경험이 핵심입니다.
B2B 발주몰
거래처마다 단가와 볼 수 있는 상품이 다릅니다. 권한과 가격 정책이 핵심입니다.
위탁판매
재고는 공급사에. 주문 전달과 배송 결과 수집, 정산이 중심입니다.
사입 판매
재고는 우리 창고에. 입고·재고·피킹·출고가 함께 필요합니다.
각 기능이 해결하는 업무 문제
기능 목록이 아니라, 그 기능이 없을 때 운영에서 무슨 일이 생기는지를 기준으로 정리했습니다.
| 기능 | 없을 때 생기는 문제 | 시스템에서 다루는 방식 |
|---|---|---|
| 공급사 관리 | 주문을 엑셀·메신저로 전달하다 누락되고, 배송 결과가 늦게 들어와 문의가 폭증합니다. | 공급사 전용 화면에서 자기 주문만 확인·발송 처리. 품절 시 사유 입력과 고객 안내 연결. |
| 회원등급 | 거래처별 단가를 담당자가 매번 수기로 조정하게 됩니다. | 등급·계약 단가·수량 구간 단가를 규칙으로 두고, 주문 시 자동 적용. |
| 상품 · 옵션 · SKU | 옵션별 재고를 셀 수 없어 품절 옵션이 팔립니다. 외부 연동 시 맞출 기준이 없습니다. | 옵션 조합 하나를 SKU 하나로 만들고, 주문 항목이 SKU를 참조하게 합니다. |
| 주문 상태 관리 | "지금 어느 단계인가"를 담당자 기억에 의존하게 됩니다. | 단계별 상태와 되돌릴 수 있는 조건을 정의하고, 모든 변경에 이력을 남깁니다. |
| 결제 | 부분 취소·부분 환불·추가 결제를 표현하지 못해 금액이 맞지 않습니다. | 결제 여부가 아니라 금액 이력으로 관리하고, 주문 금액은 이력의 합계로 계산합니다. |
| 정산 | 공급사·거래처와 매달 대사가 맞지 않아 확인에 시간이 듭니다. | 정산 기준일(판매/배송완료/구매확정)을 설정으로 두고, 공제 항목을 명시적으로 기록합니다. |
| 택배 · 송장 | 운송장을 수기로 입력하다 오타가 나고, 분할 배송을 표현하지 못합니다. | 배송 건을 주문과 분리해 1:N으로 두고, 택배사 코드를 내부 기준으로 통일합니다. |
| 오픈마켓 연동 | 채널별 관리자에 각각 들어가 주문을 옮겨 적게 됩니다. | 채널 상품 매핑 테이블과 상태값 변환 계층을 두고 증분 동기화합니다. |
| ERP · API | 같은 데이터를 두 시스템에 각각 입력하고, 값이 서로 달라집니다. | 어느 쪽이 원본인지 정하고 한 방향으로만 흐르게 합니다. 실패 건은 재처리 대상으로 남깁니다. |
| 관리자 · 통계 | 사소한 변경마다 개발자를 불러야 하고, 숫자를 엑셀로 다시 만듭니다. | 자주 바뀌는 값은 관리자에서 수정. 통계는 집계본 조회 + 당일 실시간 방식으로 제공합니다. |
| 유지보수 | 오픈 후 문제 생겼을 때 대응할 곳이 없어 서비스가 멈춥니다. | 기능 개선·장애 대응·서버/DB 운영을 유지보수 계약으로 이어서 담당합니다. |
주문이 실제로 처리되는 흐름
쇼핑몰 구축에서 정의하게 되는 단계입니다. 판매 방식에 따라 쓰지 않는 단계가 있어, 요구사항에 맞춰 덜어내거나 더합니다.
-
상품 · 옵션 · SKU 등록
고객에게 보여 줄 옵션과 창고에서 셀 단위(SKU)를 나눠 등록합니다. 옵션 조합 하나가 SKU 하나가 되고, 이후 재고·주문 항목·외부 채널 매핑이 모두 이 SKU를 기준으로 연결됩니다.
-
주문 접수 · 단가 적용
B2C는 모든 고객에게 같은 가격이 적용되지만, B2B는 회원등급·계약 단가·수량 구간 단가가 주문 시점에 자동으로 적용되어야 합니다. 담당자가 매번 수기로 금액을 고치지 않도록 규칙으로 정의합니다.
-
결제 · 금액 이력
결제 여부 한 칸이 아니라 금액 이력으로 관리합니다. 부분 취소·부분 환불·추가 결제가 생겨도 주문 금액을 이력의 합계로 계산하면 장부와 실제 입금이 어긋나지 않습니다.
-
주문 분배 (위탁 · 사입)
상품에 지정된 판매 방식에 따라 주문이 다른 흐름을 탑니다. 위탁 건은 공급사 화면으로 전달되어 공급사가 직접 발송하고, 사입 건은 우리 창고의 피킹·패킹 작업으로 넘어갑니다. 한 주문에 두 방식이 섞이는 경우를 전제로 설계합니다.
-
출고 · 운송장
배송 건을 주문과 분리해 1:N으로 두면 분할 배송과 합포장을 모두 표현할 수 있습니다. 택배사 코드는 내부 기준으로 통일해 두고, 운송장은 수기 입력 대신 일괄 등록으로 처리합니다.
-
배송조회 · 고객 안내
배송 상태는 택배사 연동이나 조회 대행 서비스로 받아 주문에 반영합니다. 송장이 아직 발급되지 않은 상태와 조회 서비스 장애는 고객에게 다르게 안내해야 하고, 외부 조회가 늦어도 화면이 멈추지 않도록 타임아웃을 둡니다.
-
취소 · 반품 · 교환
어느 단계까지 되돌릴 수 있는지를 상태별로 정의하고, 모든 변경에 이력을 남깁니다. 사입 건은 반품 입고와 재고 복구까지, 위탁 건은 공급사 회수와 정산 취소까지 이어집니다.
-
정산
정산 기준일(판매 / 배송완료 / 구매확정)을 설정으로 두고, 수수료·배송비·공제 항목을 명시적으로 기록합니다. 위탁은 판매 후 공급사 정산이, 사입은 매입 원가 기준의 마진 계산이 필요합니다.
이런 상황에서 맞춤 개발이 필요합니다
반대로 판매 방식이 단순하고 거래 조건이 하나라면 기성 솔루션으로 충분한 경우도 많습니다. 아래에 해당하지 않는다면 그 점도 상담에서 그대로 말씀드립니다.
거래처마다 조건이 다를 때
등급·계약별 단가, 여신과 후불 정산, 대량 발주, 세금계산서 발행이 필요한 경우. 기성 B2C 솔루션은 데이터 모델에 이 개념이 없어 화면만 고쳐서는 해결되지 않습니다.
옵션별 재고가 맞지 않을 때
품절된 옵션이 계속 팔리거나, 실사할 때마다 원인 모를 차이가 생기는 경우. 옵션과 SKU가 분리돼 있지 않은 것이 원인인 경우가 많습니다.
판매 채널이 늘어났을 때
자사몰과 오픈마켓 관리자에 각각 들어가 주문을 옮겨 적고 있는 경우. 채널 상품 매핑과 상태값 변환 계층을 두면 한 화면에서 처리할 수 있습니다.
위탁과 사입을 함께 쓸 때
상품마다 재고 주체가 달라 주문 처리와 정산 방식이 갈리는 경우. 상품별 판매 방식을 지정하고 주문이 자동으로 다른 흐름을 타도록 만듭니다.
운영 화면이 부족할 때
사소한 값 하나 바꾸는 데도 개발자를 불러야 하거나, 필요한 숫자를 매번 엑셀로 다시 만드는 경우. 자주 바뀌는 값은 관리자에서 직접 수정하게 만듭니다.
오픈 이후를 맡길 곳이 필요할 때
구축은 끝났는데 장애 대응과 서버·DB 운영을 맡을 곳이 없는 경우. 미션비는 자사 쇼핑몰을 직접 운영하며 같은 방식으로 유지보수를 이어서 담당합니다.
쇼핑몰 구축 자주 묻는 질문
실제 상담에서 가장 자주 나오는 질문과, 저희가 드리는 답변입니다.
B2B 쇼핑몰과 일반 B2C 쇼핑몰은 무엇이 다른가요?
가격과 주문 방식이 다릅니다. B2C는 모든 고객에게 같은 가격을 보여 주지만, B2B는 거래처 등급이나 계약에 따라 단가가 달라지고 여신·후불 정산, 대량 발주, 세금계산서 발행 같은 흐름이 필요합니다. 그래서 B2B 발주몰은 화면보다 누가 무엇을 얼마에 살 수 있는지를 정하는 권한·가격 정책 설계가 핵심입니다.
B2C 솔루션을 그대로 쓰다가 막히는 지점도 대부분 여기입니다. 등급별 단가와 결제 조건이 데이터 모델에 없으면 화면만 고쳐서는 해결되지 않습니다.
상품 옵션과 SKU를 꼭 분리해야 하나요?
재고를 관리한다면 분리해야 합니다. 옵션은 고객에게 보여 주는 선택지이고, SKU는 창고에서 세는 실제 단위입니다. 이 둘을 한 덩어리로 두면 옵션 조합별 재고를 따로 셀 수 없고, 나중에 WMS나 오픈마켓과 연동할 때 매칭할 기준 값이 없어집니다.
옵션 조합마다 SKU 코드를 부여해 두면 바코드 발행, 재고 실사, 판매 채널별 재고 배분이 모두 같은 키로 처리됩니다.
위탁판매와 사입은 시스템에서 어떻게 다르게 처리하나요?
위탁은 공급사가 재고를 갖고 직접 배송하므로 시스템은 주문 전달과 배송 결과 수집, 정산에 집중합니다. 사입은 우리가 재고를 갖고 출고하므로 입고·재고·피킹·출고 처리가 필요합니다. 한 쇼핑몰에서 두 방식을 함께 쓰는 경우가 많아, 상품마다 판매 방식을 지정하고 주문이 자동으로 다른 흐름을 타도록 만듭니다.
정산 방식도 달라집니다. 위탁은 판매 후 공급사 정산이, 사입은 매입 원가 기준의 마진 계산이 필요합니다.
오픈마켓·ERP와 연동할 수 있나요?
가능합니다. 상품·주문·배송 데이터를 표준화해 외부 시스템과 주고받는 방식으로 개발합니다. 다만 채널마다 옵션 구조와 주문 상태값이 달라서, 내부 SKU와 채널 상품을 잇는 매핑 테이블을 두고 상태값을 우리 기준으로 변환하는 계층을 반드시 만듭니다.
연동 가능 범위와 일정은 대상 채널의 API 정책에 따라 달라지므로 상담 단계에서 함께 확인합니다.
관리자 페이지도 같이 개발하나요?
네, 쇼핑몰 화면과 관리자(백오피스)를 함께 개발합니다. 쇼핑몰은 고객이 보는 화면보다 운영자가 매일 쓰는 주문·상품·회원·정산 관리 화면에 업무 시간이 더 많이 들기 때문입니다. 권한별 메뉴, 주문 일괄 처리, 송장 일괄 등록, 작업 이력 같은 기능을 운영 방식에 맞춰 설계합니다.
미션비가 직접 운영하는 쇼핑몰 툴ON도 고객 화면과 별도로 관리자 애플리케이션을 두고, 매입 원장 대사나 가격 비교 피드 관리 같은 운영 기능을 계속 추가해 왔습니다.
