쇼핑몰제작업체 비교, 일반 솔루션과 맞춤 개발을 판단하는 실무 기준

쇼핑몰제작업체에 상담을 요청하면 업체마다 서로 다른 방식을 제안하는 경우가 많습니다.

어떤 업체는 기존 쇼핑몰 솔루션을 활용하면 충분하다고 설명하고, 다른 업체는 처음부터 맞춤형 쇼핑몰을 개발해야 한다고 제안합니다. 견적도 단순한 디자인 수정 수준부터 상품·주문·재고·배송·관리자 시스템을 모두 개발하는 범위까지 크게 달라질 수 있습니다.

이때 견적 금액만 놓고 비교하면 판단하기 어렵습니다.

같은 ‘쇼핑몰 제작’이라는 표현을 사용하더라도 실제 범위는 다를 수 있기 때문입니다. 한쪽 견적에는 솔루션 설정과 화면 디자인만 포함되어 있고, 다른 견적에는 백엔드와 데이터베이스, 관리자 페이지, ERP 연동, 결제 상태 검증까지 포함되어 있을 수 있습니다.

따라서 쇼핑몰제작업체를 비교하기 전에는 먼저 다음 질문에 답해보는 것이 좋습니다.

우리 사업은 일반적인 온라인 판매 구조에 가까운가요?

아니면 회사의 가격·재고·주문·승인·배송 업무를 쇼핑몰에 맞춰 구현해야 하나요?

이 질문에 대한 답이 정리되어야 일반 쇼핑몰 솔루션, 솔루션 기반의 추가 개발, 독립적인 맞춤 개발 중 적절한 방식을 선택할 수 있습니다.

쇼핑몰제작업체를 찾기 전에 판매 방식부터 정해야 합니다

쇼핑몰 제작을 검토할 때 가장 먼저 떠올리는 것은 메인 화면, 상품 상세 페이지, 장바구니와 결제 화면입니다.

하지만 개발 범위를 크게 바꾸는 요소는 화면 디자인보다 어떻게 판매하고 어떻게 운영하는가에 있습니다.

예를 들어 다음 두 쇼핑몰은 사용자에게 비슷한 상품 목록과 구매 버튼을 보여줄 수 있습니다.

첫 번째 쇼핑몰

모든 회원에게 동일한 상품을 노출합니다.
상품마다 하나의 정상 판매가를 사용합니다.
고객이 주문과 결제를 완료하면 운영자가 출고합니다.
택배 배송을 기본으로 사용합니다.
취소와 반품은 관리자가 확인한 후 처리합니다.
상품과 주문은 쇼핑몰 관리자에서 직접 관리합니다.

두 번째 쇼핑몰

거래처마다 구매할 수 있는 상품이 다릅니다.
동일한 상품도 거래처 등급과 계약 조건에 따라 가격이 달라집니다.
주문 후 담당자 또는 관리자 승인을 받아야 합니다.
재고는 ERP에서 관리하며 쇼핑몰과 동기화해야 합니다.
상품에 따라 본사 출고, 공급사 출고, 방문 수령이 나뉩니다.
월말에 거래처별 정산 자료를 생성해야 합니다.

고객이 보는 화면 수는 비슷할 수 있지만, 두 번째 쇼핑몰에는 거래처 관리, 가격 정책, 주문 승인, ERP 연동, 배송 분리와 정산 같은 별도의 업무 로직이 필요합니다.

그러므로 쇼핑몰제작업체에 문의하기 전에는 판매 방식을 다음과 같이 정리해보는 것이 좋습니다.

| 확인 항목 | 정리할 내용 | |---|---| | 판매 대상 | 일반 소비자, 회원, 거래처, 대리점, 임직원 | | 가격 정책 | 동일 가격, 회원 등급별 가격, 거래처별 가격, 수량별 가격 | | 주문 방식 | 즉시 주문, 견적 요청, 주문 승인, 후불 주문 | | 결제 방식 | 카드, 계좌이체, 가상계좌, 무통장, 후불 정산 | | 재고 기준 | 쇼핑몰 재고, ERP 재고, 창고별 재고, 공급사 재고 | | 배송 방식 | 일반 택배, 직접 배송, 공급사 배송, 방문 수령 | | 취소·반품 | 자동 접수, 관리자 승인, 부분 취소, 교환 | | 운영 시스템 | 쇼핑몰 관리자, ERP, 회계 프로그램, 배송 시스템 |

처음부터 모든 정책을 완벽하게 확정할 필요는 없습니다.

다만 현재 운영 방식과 앞으로 필요한 구조를 구분해 전달해야 업체도 적합한 구축 방식을 제안할 수 있습니다.

일반 쇼핑몰 솔루션으로 충분한 경우

맞춤 개발이 항상 더 나은 선택은 아닙니다.

판매 구조가 비교적 표준적이라면 검증된 쇼핑몰 솔루션을 활용하는 편이 구축과 운영 측면에서 더 현실적일 수 있습니다.

다음과 같은 경우에는 일반 쇼핑몰 솔루션을 먼저 검토해볼 수 있습니다.

일반 소비자를 대상으로 상품을 판매하는 경우
대부분의 고객에게 동일한 상품과 가격을 제공하는 경우
상품 옵션이 색상, 사이즈처럼 일반적인 구조인 경우
주문 후 결제, 상품 준비, 배송으로 이어지는 표준 흐름을 사용하는 경우
기본적인 쿠폰, 적립금, 회원 등급 기능이면 충분한 경우
운영자가 솔루션 관리자에서 상품과 주문을 관리할 수 있는 경우
기존 앱이나 플러그인으로 필요한 부가 기능을 해결할 수 있는 경우
빠른 출시가 우선이고 고유한 업무 기능은 많지 않은 경우

쇼핑몰 솔루션을 사용한다고 해서 외부 시스템 연동이나 추가 개발이 모두 불가능한 것은 아닙니다.

예를 들어 카페24는 상품·주문·고객 등의 쇼핑몰 데이터를 다루는 API를 제공하며 상품 조회 시 품목과 재고 데이터를 함께 조회하는 방식도 공식 문서에서 안내하고 있습니다. 따라서 기존 솔루션을 기반으로 하면서 필요한 일부 업무만 별도의 프로그램으로 연결하는 방식도 검토할 수 있습니다. 다만 실제로 필요한 데이터의 조회·등록·수정이 제공되는지, 호출 제한과 권한 조건은 무엇인지 사전에 확인해야 합니다. (developers.cafe24.com)

이러한 방식은 흔히 다음과 같은 구조로 진행됩니다.

기본 상품 전시와 주문·결제는 쇼핑몰 솔루션을 사용합니다.
디자인과 사용자 화면은 브랜드에 맞게 수정합니다.
솔루션에서 부족한 기능만 별도로 개발합니다.
ERP나 내부 시스템은 제공되는 API 범위에서 연동합니다.
운영자가 추가 기능을 사용할 수 있도록 별도 관리자 화면을 만듭니다.

표준 기능은 솔루션을 활용하고 회사 고유의 기능만 추가하는 혼합형 구축입니다.

이 방식은 전체 기능을 처음부터 개발하는 것보다 범위를 줄일 수 있지만, 솔루션의 데이터 구조와 정책 안에서 개발해야 한다는 조건이 있습니다.

일반 쇼핑몰 솔루션을 선택할 때 확인해야 할 한계

솔루션에 원하는 기능이 있다는 설명만 듣고 바로 구축 방식을 결정하는 것은 주의해야 합니다.

기능의 이름이 같아도 실제 적용 조건이 다를 수 있기 때문입니다.

예를 들어 ‘회원별 가격’이라는 기능도 다음처럼 여러 의미를 가질 수 있습니다.

회원 등급별 할인율 적용
특정 회원에게만 별도 가격 적용
거래처별 계약 단가 적용
주문 수량에 따라 구간별 단가 적용
특정 기간에만 프로모션 가격 적용
상품 옵션별로 별도 계약 가격 적용

솔루션에서 회원 등급별 할인을 지원한다고 해서 거래처마다 개별 계약 단가를 관리할 수 있다는 뜻은 아닙니다.

B2B 기능도 서비스와 요금제에 따라 제공 범위가 달라질 수 있습니다. 예를 들어 Shopify의 공식 B2B 기능은 회사나 사업장에 카탈로그를 배정해 상품과 가격을 다르게 제공하고 수량 규칙과 볼륨 가격을 설정할 수 있지만, 해당 기능은 Shopify Plus 요금제에서 제공됩니다. 따라서 기능의 존재만 확인하지 말고 사용하려는 플랜, 국가, 결제 방식과 운영 조건에서 실제 사용할 수 있는지 확인해야 합니다. (help.shopify.com)

솔루션을 검토할 때는 다음 질문을 함께 확인해야 합니다.

해당 기능이 기본 제공인지 별도 앱인지
현재 선택한 요금제에서 사용할 수 있는지
국내 결제와 배송 환경에서 사용할 수 있는지
관리자에서 직접 설정할 수 있는지
API를 통해 데이터를 조회하고 변경할 수 있는지
솔루션 정책이 바뀌었을 때 영향을 받는지
기능을 해지하거나 다른 시스템으로 이전할 수 있는지
추가 앱이나 서비스의 월 이용료가 발생하는지

특히 외부 연동이 필요한 경우에는 API가 있다는 사실만으로 충분하지 않습니다.

필요한 필드가 제공되는지, 데이터를 어느 방향으로 보낼 수 있는지, 한 번에 처리할 수 있는 수량과 호출 제한은 무엇인지까지 확인해야 합니다. 솔루션의 데이터 구조와 내부 시스템의 구조가 다르면 중간에서 데이터를 변환하고 상태를 맞추는 별도의 연동 프로그램이 필요할 수 있습니다.

맞춤형 쇼핑몰 개발이 필요한 대표적인 상황

맞춤 개발은 단순히 디자인을 자유롭게 만들기 위한 선택이 아닙니다.

기존 쇼핑몰 솔루션의 표준 흐름으로는 처리하기 어려운 판매 정책이나 운영 업무가 있을 때 검토하는 방식입니다.

1. 거래처마다 상품과 가격이 다른 경우

B2B 쇼핑몰에서는 로그인한 거래처에 따라 구매할 수 있는 상품이 달라질 수 있습니다.

같은 상품이라도 거래처별 계약 단가, 최소 주문 수량, 할인율과 결제 조건이 다를 수 있습니다. 이 경우 상품 하나에 판매가 하나만 저장하는 구조로는 부족합니다.

다음과 같은 데이터 관계를 함께 설계해야 합니다.

거래처와 사용자 계정의 관계
거래처별 접근 가능한 상품
거래처별 계약 단가와 적용 기간
최소·최대 주문 수량
수량 구간별 가격
부가세 포함·별도 기준
담당 영업자와 승인 권한
거래처의 결제·정산 조건

2. 주문 제작 상품을 판매하는 경우

인쇄물, 가구, 산업 부품, 식품 세트처럼 고객의 선택에 따라 사양과 가격이 달라지는 상품은 일반 옵션만으로 표현하기 어려울 수 있습니다.

고객이 입력한 규격, 소재, 수량과 첨부 파일을 바탕으로 가격을 계산하거나 운영자가 견적을 확정해야 할 수도 있습니다.

이때는 다음 흐름이 필요할 수 있습니다.

상품 선택 → 사양 입력 → 파일 첨부 → 예상 금액 확인 → 견적 검토 → 주문 승인 → 결제 → 제작 → 배송

일반적인 상품 선택 → 장바구니 → 결제와는 주문 구조가 다르므로 견적, 승인과 제작 상태를 별도로 설계해야 합니다.

3. 재고를 여러 시스템에서 관리하는 경우

온라인 쇼핑몰 외에 오프라인 매장, 창고, ERP와 다른 판매 채널을 함께 운영한다면 재고 기준을 먼저 정해야 합니다.

쇼핑몰의 수량이 실제 재고인지, ERP에서 받은 수량인지, 판매 가능한 수량인지 구분해야 합니다.

예를 들어 ERP에 재고가 100개 있다고 해서 쇼핑몰에서 100개를 모두 판매할 수 있는 것은 아닐 수 있습니다.

이미 출고 요청된 수량
다른 판매 채널에 배정된 수량
불량 또는 검수 중인 수량
안전재고로 확보할 수량
입고 예정이지만 아직 판매할 수 없는 수량

이러한 값을 반영하면 실제 판매 가능 재고는 별도의 계산 결과가 됩니다.

4. 주문 승인과 내부 결재가 필요한 경우

일반 쇼핑몰은 고객이 주문과 결제를 완료하면 바로 출고 준비로 넘어가는 경우가 많습니다.

하지만 기업 거래에서는 주문자의 요청만으로 주문이 확정되지 않을 수 있습니다.

거래처 내부 구매 담당자의 승인
본사 관리자의 주문 승인
신용 한도 확인
재고와 납기 확인
영업 담당자의 가격 승인
후불 거래 가능 여부 확인

이러한 절차가 있다면 ‘주문 완료’ 하나가 아니라 요청, 검토, 승인, 반려, 결제 대기, 출고 준비 같은 상태를 구분해야 합니다.

5. 독자적인 정산 구조가 필요한 경우

입점사나 공급사가 있는 쇼핑몰은 고객의 결제 금액 전체가 운영사의 매출로 끝나지 않을 수 있습니다.

상품별 공급가, 판매 수수료, 할인 부담 주체, 배송비와 환불 금액을 기준으로 정산해야 할 수 있습니다.

부분 취소와 부분 반품이 발생하면 정산 금액도 다시 계산해야 합니다.

이러한 사업은 쇼핑몰 화면만 개발해서는 운영할 수 없습니다. 입점사, 상품 공급 조건, 주문 품목, 결제, 환불과 정산 데이터를 연결하는 관리자 시스템이 필요합니다.

상품·옵션·가격·재고 관리 방법을 먼저 확인해야 합니다

쇼핑몰 견적에서 ‘상품 관리’라는 항목은 매우 넓은 범위를 포함할 수 있습니다.

상품명과 가격을 등록하는 기본 기능만 포함할 수도 있고, 여러 옵션과 가격 정책, 대량 등록, 재고 동기화까지 포함할 수도 있습니다.

쇼핑몰제작업체와 상담할 때는 상품 정보를 어떤 방식으로 관리할 것인지 구체적으로 확인해야 합니다.

상품 구조

단일 상품인지 옵션 상품인지
옵션 조합마다 품목 코드가 있는지
상품과 실제 재고 품목이 같은 단위인지
세트 상품과 구성 상품의 재고를 어떻게 차감할지
추가 상품이나 필수 선택 항목이 있는지
상품마다 배송 방식이 다른지

예를 들어 티셔츠 한 장을 판매하더라도 색상 5개와 사이즈 4개를 조합하면 20개의 품목이 생길 수 있습니다.

재고가 상품 단위가 아니라 색상·사이즈 조합별로 관리된다면 각 품목을 식별할 수 있는 코드가 필요합니다.

가격 구조

정상 판매가
할인 판매가
회원 등급별 가격
거래처별 계약 가격
수량별 가격
옵션 추가 금액
프로모션 적용 우선순위
쿠폰과 적립금 중복 적용 여부

여러 할인 정책이 동시에 적용될 수 있다면 어떤 정책을 먼저 계산할지도 정해야 합니다.

‘가장 큰 할인 하나만 적용’하는 방식과 ‘등급 할인 후 쿠폰을 추가 적용’하는 방식은 최종 금액이 다릅니다.

재고 구조

재고를 어느 시스템에서 관리할지
주문 접수 시점과 결제 완료 시점 중 언제 차감할지
결제 중인 상품을 임시로 확보할지
취소·반품 시 재고를 언제 복구할지
품절 상품의 주문을 허용할지
창고별 재고를 구분할지
여러 채널에서 발생한 주문을 어떻게 반영할지

견적서에 ‘재고 관리’가 적혀 있다면 단순 수량 수정인지, 주문에 따른 자동 차감인지, ERP와의 동기화까지 포함하는지 확인해야 합니다.

주문·결제·배송·취소·환불 상태를 함께 설계해야 합니다

쇼핑몰에서는 주문, 결제와 배송이 서로 연결되어 있지만 완전히 같은 상태는 아닙니다.

고객이 주문서를 작성했지만 아직 입금하지 않았을 수 있고, 결제는 승인됐지만 주문 정보 저장이나 재고 반영이 지연될 수도 있습니다. 한 주문 안에서 일부 상품만 배송하거나 일부 품목만 취소하는 상황도 발생할 수 있습니다.

따라서 다음 상태를 하나로 합치기보다 역할에 맞게 구분하는 것이 좋습니다.

| 구분 | 상태 예시 | |---|---| | 주문 | 주문 접수, 확인 중, 승인, 취소, 완료 | | 결제 | 결제 대기, 승인, 실패, 부분 취소, 전체 취소 | | 배송 | 출고 대기, 상품 준비, 배송 중, 배송 완료 | | 교환·반품 | 접수, 승인, 수거 중, 검수, 처리 완료 | | 환불 | 환불 예정, 요청, 완료, 실패 |

실제 솔루션의 공식 API 문서에서도 주문, 환불과 배송은 별도의 리소스와 상태로 관리되며, 한 주문에 여러 배송 정보가 연결되는 부분배송 구조도 확인할 수 있습니다. 이는 쇼핑몰 운영에서 주문 한 건이 항상 한 번의 배송과 한 번의 환불로 끝나지 않는다는 점을 보여줍니다. (developers.cafe24.com)

결제 연동 역시 결제창에서 성공 화면을 보여주는 것만으로 완료되지 않습니다.

브라우저에서 받은 결과는 서버에서 실제 결제 상태와 금액을 다시 확인하는 과정이 필요합니다. 결제사나 결제 연동 서비스의 웹훅을 사용하더라도 지연이나 중복 전송 가능성을 고려해 주문 상태를 안전하게 갱신해야 합니다. 포트원 공식 문서도 결제 조회 API를 통한 서버 검증과 웹훅을 이용한 결제 정보 동기화를 안내하고 있습니다. (developers.portone.io)

쇼핑몰제작업체에 다음 상황의 처리 방법을 물어보면 주문 구조를 어느 정도까지 검토했는지 확인할 수 있습니다.

결제는 승인됐지만 주문 반영에 실패하면 어떻게 처리하나요?
같은 결제 결과가 두 번 전달되면 중복 주문이 생기지 않나요?
주문 상품 중 일부만 취소할 수 있나요?
부분 취소 후 쿠폰과 배송비는 어떻게 다시 계산하나요?
배송이 시작된 상품과 아직 출고되지 않은 상품을 구분할 수 있나요?
반품이 접수되면 재고는 언제 복구하나요?
환불 실패 건을 관리자가 확인하고 다시 처리할 수 있나요?

정상적인 구매 흐름만 설명하는 업체보다 예외 상황과 운영자의 대응 방법까지 질문하는 업체가 실제 구축 범위를 더 구체적으로 파악하고 있다고 볼 수 있습니다.

B2B 쇼핑몰은 일반 쇼핑몰보다 확인할 범위가 많습니다

B2B 쇼핑몰은 로그인 후 상품을 주문한다는 점에서는 일반 회원제 쇼핑몰과 비슷해 보입니다.

하지만 실제로는 개인 회원이 아니라 회사와 거래 조건을 기준으로 움직이는 경우가 많습니다.

회사와 사용자 계정을 구분해야 합니다

하나의 거래처에 여러 사용자가 소속될 수 있습니다.

주문을 작성하는 실무자
주문을 승인하는 책임자
세금계산서와 정산 자료를 확인하는 회계 담당자
전체 주문을 관리하는 거래처 관리자

따라서 사용자마다 조회·작성·승인 권한을 다르게 설정해야 할 수 있습니다.

거래처별 판매 조건이 다를 수 있습니다

구매 가능한 상품
계약 단가
최소 주문 수량
월 주문 한도
결제 수단
외상 거래 한도
배송지와 배송비
담당 영업자

이러한 조건을 상품이나 회원 정보에 임시로 입력하면 운영이 복잡해질 수 있습니다. 거래처, 사용자, 상품, 가격 정책과 계약 기간을 분리해 관리하는 구조가 필요합니다.

견적과 주문을 구분해야 할 수 있습니다

B2B 거래에서는 구매자가 바로 주문하기보다 견적을 먼저 요청할 수 있습니다.

견적 금액이 확정된 후 주문으로 전환하거나, 발주서를 첨부한 뒤 관리자가 승인하는 방식도 있습니다.

이 경우 견적서의 유효기간과 버전, 승인 상태를 관리해야 합니다. 수정된 견적이 여러 개라면 어떤 견적을 기준으로 주문했는지도 추적할 수 있어야 합니다.

후불 정산을 지원해야 할 수 있습니다

모든 주문을 온라인 카드 결제로 처리하지 않고 월 단위로 합산해 정산할 수 있습니다.

그러면 쇼핑몰의 역할이 결제 중심에서 주문·출고·채권 관리 중심으로 달라집니다.

거래처별 미수금
정산 기간
입금 예정일
세금계산서 발행 기준
부분 입금
주문별 수금 배분

이 기능을 1차 구축에 모두 포함할 필요는 없지만, 향후 ERP나 회계 시스템과 연결할 계획이 있다면 데이터 구조에는 반영해두는 것이 좋습니다.

ERP·배송·결제·외부 API 연동 견적에서 확인할 항목

쇼핑몰에 외부 연동이 포함되면 견적서에는 단순히 ‘ERP 연동’ 또는 ‘배송 API 연동’이라고 적는 것보다 구체적인 범위가 필요합니다.

1. 어떤 데이터를 연결하는가

ERP 연동이라도 상품만 가져오는 프로젝트와 상품·가격·재고·주문·취소·배송을 모두 양방향으로 동기화하는 프로젝트는 범위가 다릅니다.

데이터별로 구분해 확인해야 합니다.

| 데이터 | 확인할 내용 | |---|---| | 상품 | ERP 상품을 쇼핑몰에 등록할지 | | 옵션·품목 | 품목 코드와 옵션 조합을 어떻게 연결할지 | | 가격 | 정상가, 계약가, 프로모션 가격 중 무엇을 받을지 | | 재고 | 전체 재고인지 판매 가능 재고인지 | | 주문 | 쇼핑몰 주문을 ERP로 언제 전달할지 | | 배송 | 송장과 배송 상태를 어느 시스템에서 입력할지 | | 취소·반품 | 어느 시스템에서 접수하고 승인할지 | | 회원·거래처 | 신규 거래처와 변경 정보를 어디에서 관리할지 |

2. 어느 시스템이 기준인가

상품명은 ERP에서 관리하고 상세 설명은 쇼핑몰에서 관리할 수도 있습니다.

상품 기본 정보는 ERP가 기준이고, 노출 여부와 전시 카테고리는 쇼핑몰이 기준일 수 있습니다.

모든 데이터를 한 시스템에서 관리한다고 가정하기보다 항목별 기준 시스템을 정해야 합니다.

3. 언제 동기화하는가

운영자가 버튼을 눌렀을 때
일정한 주기로 일괄 처리
주문이 발생한 즉시
외부 시스템에서 웹훅을 받았을 때
하루 업무 종료 후 한 번에 처리

실시간 연동이 항상 필요한 것은 아닙니다.

상품 설명은 하루 한 번 반영해도 되지만, 품절 위험이 있는 재고는 더 자주 반영해야 할 수 있습니다. 데이터의 성격에 따라 동기화 시점을 다르게 정하는 것이 좋습니다.

4. 실패했을 때 어떻게 처리하는가

연동은 외부 시스템의 장애나 호출 제한, 데이터 형식 오류로 실패할 수 있습니다.

따라서 다음 기능이 견적에 포함되는지 확인해야 합니다.

요청과 응답 로그
실패 사유 표시
자동 재시도
운영자의 수동 재처리
중복 처리 방지
부분 성공 건의 구분
관리자 알림
수정 후 다시 전송하는 기능

연결에 성공하는 정상 상황만 개발하면 운영 중 문제가 발생했을 때 개발자가 직접 데이터베이스를 확인해야 할 수 있습니다.

운영자가 실패 건을 조회하고 필요한 범위에서 다시 처리할 수 있어야 유지보수 부담을 줄일 수 있습니다.

관리자 페이지를 비교할 때는 메뉴 수보다 업무 기능을 확인해야 합니다

쇼핑몰 관리자 페이지는 상품과 주문 목록을 보여주는 화면만을 의미하지 않습니다.

운영자가 반복 업무를 얼마나 직접 처리할 수 있는지가 중요합니다.

검색과 필터

주문이 적을 때는 전체 목록을 살펴볼 수 있지만 주문량이 늘어나면 조건 검색이 필요합니다.

주문일
결제일
주문 상태
배송 상태
상품 또는 품목 코드
구매자
거래처
결제 수단
담당자
취소·반품 여부

자주 사용하는 검색 조건을 조합할 수 있어야 운영자가 별도의 엑셀 파일을 만들지 않아도 됩니다.

일괄 처리

운영자가 주문 100건의 상태를 하나씩 수정해야 한다면 관리자 페이지가 있어도 업무 효율은 높아지지 않습니다.

다음과 같은 일괄 기능이 필요한지 확인해야 합니다.

상품 일괄 등록·수정
주문 상태 일괄 변경
송장번호 일괄 업로드
거래처별 가격 일괄 적용
선택 주문 엑셀 다운로드
세금계산서 발행용 데이터 생성
특정 회원에게 쿠폰이나 적립금 지급

권한 관리

관리자 계정을 하나만 만들어 공동으로 사용하면 누가 어떤 데이터를 변경했는지 확인하기 어렵습니다.

역할별로 권한을 나눌 필요가 있습니다.

상품 담당자
주문·배송 담당자
고객 상담 담당자
정산 담당자
거래처 관리 담당자
최고 관리자

메뉴 접근뿐 아니라 조회, 수정, 승인, 다운로드와 삭제 권한을 구분해야 할 수도 있습니다.

변경 이력

가격, 주문 상태와 환불 금액처럼 운영에 영향을 주는 데이터는 변경 이력을 남기는 것이 좋습니다.

누가 변경했는지
언제 변경했는지
변경 전 값과 변경 후 값
변경 사유
관련 주문 또는 거래처

오류가 발생했을 때 현재 값만 확인해서는 원인을 찾기 어려울 수 있습니다.

운영자 예외 처리

자동화가 잘 되어 있어도 모든 상황을 자동으로 처리할 수는 없습니다.

주소 오류, 재고 부족, 잘못된 주문, 부분 출고, 결제와 주문 상태 불일치처럼 운영자의 판단이 필요한 상황이 생길 수 있습니다.

따라서 관리자 페이지는 자동 처리 기능뿐 아니라 예외 상황을 확인하고 수정할 수 있는 기능도 제공해야 합니다.

쇼핑몰제작업체의 견적과 역량을 비교하는 방법

업체를 비교할 때는 금액과 포트폴리오만 보지 말고 같은 요구사항을 어떻게 해석하는지 살펴보는 것이 좋습니다.

요구사항을 화면이 아니라 업무 흐름으로 질문하는가

“상품 페이지가 몇 개인가요?”라는 질문만 하는 것보다 다음과 같은 질문을 하는 업체가 운영 구조를 구체적으로 파악하는 데 도움이 됩니다.

상품과 실제 재고 품목은 같은 단위인가요?
가격은 모든 회원에게 동일한가요?
주문이 들어오면 누가 무엇을 확인하나요?
결제 전후에 재고는 언제 확보하나요?
부분 취소와 부분 배송이 필요한가요?
상품과 재고는 어느 시스템이 기준인가요?
연동 실패 건은 누가 어떻게 처리하나요?

솔루션과 맞춤 개발을 함께 비교하는가

모든 프로젝트에 맞춤 개발을 제안하거나 반대로 모든 요구사항을 솔루션 설정으로 해결할 수 있다고 단정하는 방식은 주의해서 볼 필요가 있습니다.

적합한 업체라면 표준 기능과 고유 업무를 나누고 다음 선택지를 비교할 수 있어야 합니다.

일반 솔루션 설정
솔루션 디자인과 기능 확장
솔루션과 별도 관리자 시스템의 결합
일부 업무만 맞춤 개발
전체 맞춤형 쇼핑몰 구축

포함 범위와 제외 범위가 명확한가

견적서에서는 다음 항목을 구분해 확인하는 것이 좋습니다.

요구사항 정리와 화면 기획
UX/UI 디자인
사용자용 쇼핑몰 화면
백엔드와 데이터베이스
관리자 페이지
결제 연동
배송 연동
ERP·회계 시스템 연동
기존 상품·회원·주문 데이터 이전
테스트 데이터와 검수 지원
서버와 도메인 설정
배포와 공개
운영 매뉴얼
하자 수정과 유지보수
소스코드와 서버 계정 인수인계

견적이 낮더라도 관리자 기능, 데이터 이전과 외부 연동이 제외되어 있다면 이후 추가 비용이 발생할 수 있습니다.

예외 상황을 견적에 포함하는가

정상 흐름만 구현하는 것과 실패·취소·중복·부분 처리까지 구현하는 것은 개발 범위가 다릅니다.

기능 목록에 ‘결제 연동’ 한 줄만 적혀 있다면 결제 검증, 취소, 부분 취소, 웹훅, 중복 방지와 실패 로그가 포함되는지 별도로 확인하는 것이 좋습니다.

출시 이후 운영 조건을 설명하는가

쇼핑몰은 공개한 이후에도 상품 정책과 운영 방식이 바뀔 수 있습니다.

다음 항목도 계약 전에 확인해두는 것이 좋습니다.

오류 수정 범위와 기간
운영 문의 방식
추가 개발 산정 기준
서버와 외부 서비스 비용
API 변경 대응 범위
백업과 장애 대응 방식
소스코드와 데이터의 소유·접근 권한
다른 개발사로 이전할 때 제공되는 자료

견적 문의 전에 준비하면 좋은 자료

완성된 기획서가 없어도 다음 자료가 있으면 상담과 견적 비교가 수월해집니다.

1. 판매할 상품의 예시

실제 상품 3~5개 정도를 기준으로 옵션, 가격과 재고 구조를 보여주면 좋습니다.

상품 전체 목록보다 복잡한 대표 상품을 먼저 준비하는 편이 범위를 파악하는 데 도움이 됩니다.

2. 현재 주문 처리 과정

고객이 주문한 후 배송이 완료될 때까지 담당자의 업무를 순서대로 적어봅니다.

예를 들면 다음과 같습니다.

주문 접수 → 입금 확인 → 재고 확인 → ERP 등록 → 출고 요청 → 송장 입력 → 고객 안내 → 정산

엑셀과 메신저를 사용하고 있다면 해당 파일의 항목과 실제 사용 방식도 참고 자료가 될 수 있습니다.

3. 사용자와 관리자 유형

비회원
일반 회원
거래처 사용자
거래처 승인자
상품 담당자
주문 담당자
정산 담당자
최고 관리자

각 사용자가 무엇을 조회하고 처리해야 하는지 간단히 정리합니다.

4. 외부 시스템 자료

ERP, 배송사, 결제, 회계 프로그램이나 다른 판매 채널과 연동해야 한다면 다음 자료를 확인합니다.

서비스 이름
사용 중인 버전과 계약 상품
API 문서 제공 여부
담당 업체의 기술 지원 여부
테스트 계정 제공 가능 여부
필요한 데이터 목록
기존 데이터의 형식

API 문서가 없거나 접근 권한이 없다면 상담 단계에서 확인이 필요하다고 전달하면 됩니다.

5. 1차 출시 기능과 이후 기능

처음부터 모든 자동화와 통계를 구축하면 일정과 비용이 커질 수 있습니다.

1차 출시에서는 실제 판매와 운영에 필요한 흐름을 먼저 구성하고, 데이터가 쌓인 후 확장해도 되는 기능은 분리할 수 있습니다.

#### 1차에 검토할 기능

상품 조회
옵션 선택
장바구니와 주문
결제
기본 배송 관리
취소·환불 접수
상품·주문 관리자 기능
운영에 반드시 필요한 연동

#### 이후 확장을 검토할 기능

고급 통계와 대시보드
추천과 개인화
마케팅 자동화
복잡한 정산 자동화
다국어·다국가 판매
추가 판매 채널 연동
반복 업무의 고도화

다만 B2B 가격, 승인이나 ERP 재고처럼 핵심 판매 방식과 직접 연결되는 기능은 단순한 부가 기능으로 미루기 어렵습니다. 해당 기능이 없으면 실제 주문을 처리할 수 있는지를 기준으로 판단해야 합니다.

원소프트가 쇼핑몰 개발 상담에서 함께 검토하는 범위

원소프트는 쇼핑몰 화면만이 아니라 상품, 주문, 결제, 재고, 배송과 관리자 운영이 연결되는 전체 흐름을 기준으로 개발 범위를 검토합니다.

일반적인 판매 구조라면 기존 쇼핑몰 솔루션을 활용할 수 있는 영역과 별도 개발이 필요한 영역을 나누어볼 수 있습니다. 거래처별 가격, 주문 승인, ERP 연동과 고유한 관리자 업무가 있다면 맞춤형 웹서비스 또는 혼합형 구축이 필요한지도 함께 검토할 수 있습니다.

프로젝트 상황에 따라 다음 영역을 통합해 구성할 수 있습니다.

사용자용 쇼핑몰 웹 화면
상품·회원·주문 백엔드
데이터베이스 설계
운영자용 관리자 페이지
결제와 소셜 로그인
배송·ERP·외부 API 연동
웹서비스 배포와 운영 구조
공개 이후 유지보수와 기능 확장

모든 쇼핑몰을 처음부터 맞춤 개발할 필요는 없습니다.

반대로 사업의 핵심 업무가 일반 솔루션의 구조와 맞지 않는데도 디자인 수정과 여러 부가 앱으로만 해결하려 하면 운영이 복잡해질 수 있습니다.

현재 판매 방식과 운영 중인 문서, 사용 중인 시스템, 필요한 연동을 기준으로 범위를 나누면 솔루션 활용 영역과 맞춤 개발 영역을 보다 현실적으로 판단할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·관리자 시스템 개발사입니다. 동탄과 화성을 비롯해 수원·용인 등 경기 남부에서 쇼핑몰이나 주문 시스템 구축을 검토하고 계신 경우에도 현재 운영 방식과 필요한 기능을 바탕으로 개발 범위를 함께 정리해드릴 수 있습니다.

쇼핑몰제작업체를 비교할 때 가장 먼저 확인해야 하는 것은 어느 업체의 디자인이 더 화려한지가 아닙니다.

우리 판매 구조를 일반 솔루션으로 처리할 수 있는지, 어떤 업무를 별도로 개발해야 하는지, 출시 후 운영자가 직접 처리할 수 있는지가 더 중요한 기준입니다.

상담 전에 상품·가격·주문·재고·배송·연동 구조를 모두 확정하기 어렵다면 현재 업무 과정부터 정리해도 괜찮습니다. 실제 업무 흐름을 기준으로 1차 구축에 필요한 기능과 이후 확장할 기능을 나누는 것부터 시작할 수 있습니다.

제목 후보

쇼핑몰제작업체 비교, 일반 솔루션과 맞춤 개발을 판단하는 실무 기준
쇼핑몰제작업체 선정 전, 상품·주문·재고·관리자 범위를 확인하세요
쇼핑몰제작업체 견적 비교, ERP 연동과 운영 기능까지 확인하는 방법
쇼핑몰제작업체 문의 전, 솔루션과 맞춤형 쇼핑몰을 구분하는 기준
쇼핑몰제작업체 선택, 디자인보다 판매·주문·재고 운영을 먼저 확인하세요

메인 키워드

쇼핑몰제작업체

서브 키워드

맞춤형쇼핑몰개발
쇼핑몰제작견적
B2B쇼핑몰개발
쇼핑몰관리자페이지
쇼핑몰ERP연동

썸네일 문구

솔루션으로 충분할까?
쇼핑몰 업체 비교 기준
견적보다 운영 범위

글 요약

쇼핑몰제작업체를 비교할 때는 디자인과 총견적보다 판매 대상, 상품·가격·재고 구조, 주문·결제·배송·환불 흐름과 관리자 운영 범위를 먼저 확인해야 합니다. 표준적인 판매는 일반 솔루션을 활용할 수 있지만, 거래처별 가격·주문 승인·ERP 연동과 고유한 정산 업무가 있다면 맞춤 개발 또는 혼합형 구축을 검토할 수 있습니다.

CTA 후보

현재 사용 중인 상품 목록이나 주문 처리 자료가 있다면 이를 기준으로 일반 쇼핑몰 솔루션으로 처리할 영역과 별도 개발이 필요한 영역을 함께 나누어볼 수 있습니다.

거래처별 가격, 재고 동기화, 주문 승인이나 ERP 연동 때문에 구축 방식을 결정하기 어렵다면 현재 업무 흐름을 바탕으로 1차 개발 범위와 이후 확장 기능을 정리해드릴 수 있습니다.

다음에 작성하면 좋은 연관 글

B2B 쇼핑몰 개발, 거래처 계정·계약 가격·주문 승인 권한을 설계하는 방법
쇼핑몰 관리자 페이지 개발, 검색·일괄 처리·권한·변경 이력 비교 기준
쇼핑몰 ERP 연동, 상품·재고·주문·배송 데이터의 기준 시스템 정하는 방법