쇼핑몰 앱 개발, 상품·장바구니·주문은 관리자와 어떻게 연결할까요?

먼저 무엇을 어떤 조건으로 주문할 수 있고, 접수된 주문을 누가 어디까지 처리할지 정해 보세요. 이 글에서는 가상의 생활용품 쇼핑몰을 예로 상품·옵션부터 장바구니, 주문 조건과 발송 업무를 나눕니다. 이어서 모프마루와 스테이마트의 서로 다른 개발 사례를 살펴보겠습니다.

예를 들어 ‘크림은 판매 중, 검정은 주문 불가’인 상품을 판매한다면 상품 전체와 옵션별 판매 가능 여부를 구분해야 합니다. 여기서 판매를 잠시 막는 기능, 남은 수량을 보여주는 기능, 주문에 따라 재고를 자동으로 줄이는 기능은 별도 범위입니다. ‘재고 관리 포함’이라고만 적기보다 필요한 업무를 골라 요청하세요.

또한 자기 상품을 직접 파는 쇼핑몰과 여러 판매자가 입점하는 서비스는 관리자 구성이 다릅니다. 첫 버전을 직접 판매로 시작한다면 판매자 가입·승인·별도 관리 계정까지 처음부터 만들 것인지 다시 판단할 수 있습니다.

가상 예시에서는 크림 색상 파우치 2개를 담습니다. 단가 18,000원, 상품 합계 36,000원, 배송비 3,000원으로 주문 합계는 39,000원입니다. 상품명과 금액은 설명을 위한 예시입니다. 고객이 수량을 바꾸거나 상품을 삭제하면 어떤 합계가 바뀌어야 하는지도 함께 정합니다.

상품 개수와 배송비만 맞춘다고 장바구니가 완성되는 것은 아닙니다. 무료 배송 기준이 있다면 전체 상품 기준인지 선택한 상품 기준인지 정해야 하고, 판매자별로 따로 배송한다면 합계를 묶는 기준도 달라집니다. 이 예시는 한 판매자의 상품을 한 번에 보내는 방식으로 한정합니다.

예를 들어 배송 불가 지역이라면 고객이 주소를 고친 뒤 다시 진행할 수 있어야 합니다. ‘주문 실패’라는 문구 하나보다 어떤 조건이 맞지 않고 무엇을 바꾸면 되는지가 구체적이어야 합니다.

결제 승인·취소·환불은 주문을 운영하는 데 필요하지만 각각의 처리 기준을 따로 정해야 합니다. 이번 글에서는 주문할 상품과 운영자에게 전달할 정보를 중심으로 살펴봅니다. 결제 상태별 설계는 아래 관련 가이드에서 이어서 확인할 수 있습니다.

한 주문을 여러 번 나눠 보내거나 여러 업체가 각각 발송한다면 상품별 처리와 배송 정보를 구분해야 할 수 있습니다. 지금 그런 주문이 있는지부터 확인하고, 필요하지 않은 복잡한 구조를 기본 기능처럼 넣지 마세요.

이 사례에서는 고객이 선택하는 거래 조건과 운영자가 확인하는 거래 정보가 각각 필요하다는 점을 참고할 수 있습니다. 일반 분양, 경매와 맞춤 요청은 서로 다른 흐름이므로 모든 쇼핑몰에 같은 거래 방식을 넣을 필요는 없습니다.

참고할 점은 고객의 주문 화면 외에 업체가 확인할 정보와 운영자가 관리할 대상을 나눴다는 것입니다. 자체 쇼핑몰도 상품을 고르는 사람과 포장·발송하는 사람의 업무를 함께 설명하면 필요한 화면을 더 구체적으로 정할 수 있습니다.

두 사례의 자세한 화면과 제작 범위는 아래 관련 포트폴리오에서 확인할 수 있습니다. 앞서 설명한 파우치 주문은 첫 개발 범위를 정하기 위한 가상 예시입니다.

이처럼 한 주문이 접수되고 실제 담당자의 처리로 이어지는 범위를 먼저 적어 보세요. 요청서에는 다음 항목이면 출발할 수 있습니다.

기존 솔루션으로 상품이나 주문을 관리하고 있다면 그 업무를 유지할지부터 알려주세요. 관리자까지 새로 만드는 의뢰와 기존 시스템에 고객 앱을 연결하는 의뢰는 필요한 범위가 다릅니다. 자동 재고 반영, 택배사 연동, 여러 판매자 입점·정산, 쿠폰·적립금도 실제 필요에 따라 따로 고릅니다.

검수할 때는 같은 주문번호를 기준으로 고객이 선택한 상품·옵션·수량과 운영자가 보는 값이 일치하는지 확인합니다. 수량 변경 뒤 합계, 주문 불가 조건의 안내, 운영자의 발송 입력 뒤 고객에게 보이는 정보도 확인 대상으로 적어 두세요. 화면의 개수보다 실제로 처리할 주문 한 건을 설명하면 개발업체와 범위를 맞추기 쉽습니다.

상담할 때는 판매할 상품 한 개의 정보와 옵션, 현재 주문을 받아 발송하는 방식을 가져오세요. 아래 개발 비용 안내와 함께 고객 화면·관리자·기존 시스템 중 첫 출시에서 만들 범위를 정리할 수 있습니다.