이커머스
온라인 스토어, 결제 화면, 온라인 판매.
이커머스
이 카테고리에 속하는 도구
실물이나 디지털 상품을 온라인으로 판매하는 소프트웨어입니다. 스토어프런트, 카탈로그, 결제 화면, 주문 처리, 그리고 그 뒤의 백오피스가 대상입니다. 완결된 플랫폼도 있고, 이미 운영하는 사이트에 장바구니를 더하는 제품도 있으며, 디지털 전송이나 구독에 특화된 제품도 있습니다.
일반적인 결제 수납은 결제에 속합니다. 창고와 채널을 가로지르는 재고는 재고 관리에 있고, 운송사 요금을 반영한 라벨 출력은 배송·물류입니다.
첫 결정은 어디서 운영하느냐입니다
호스팅형 플랫폼은 서버, 업데이트, 백업, 보안을 처리해 주는 대신 결제 화면을 얼마나 바꿀 수 있는지를 제한합니다. 자체 호스팅 소프트웨어는 소스와 그에 딸린 모든 운영 의무를 줍니다.
정직한 시험 기준은 비용이 아닙니다. 12월의 어느 화요일에 보안 업데이트를 적용할 사람이 조직에 있느냐입니다. 답이 아니라면, 라이선스가 공짜처럼 보여도 호스팅형이 맞습니다.
그 사이에 세 번째 경로가 있습니다. 직접 만든 프런트엔드에 콘텐츠를 공급하는 헤드리스 백엔드입니다. 개발자가 있고 판매 접점이 여럿인 팀에 맞고, 두 명짜리 가게에는 잘 맞지 않습니다.
결제 화면은 돈이 새는 곳입니다
입력란이 하나 늘 때마다 주문이 줄어듭니다. 이 카테고리에서 가장 믿을 수 있는 발견이며, 테마 디자인보다 결제 화면의 유연성에 먼저 신경 써야 하는 이유입니다.
개발자 없이 바꿀 수 있는 것을 확인하세요. 입력란 순서, 비회원 결제, 판매하는 나라의 주소 처리, 오류 표시 방식입니다. 그다음 시장별 결제 수단 지원을 확인하세요. 평소 쓰는 수단이 없는 구매자는 카드를 찾아 나서는 일이 드뭅니다.
실패한 뒤에 무슨 일이 일어나는지도 보세요. 장바구니 이탈 복구, 저장된 장바구니, 거절된 카드의 재시도 경로는 평범한 매출입니다. 플랫폼마다 이 중 무엇이 포함되고 무엇이 앱으로 팔리는지 다릅니다.
카탈로그, 옵션, 규모가 커지면 깨지는 부분
- 옵션 조합은 여러 선택지를 가지며, 각각 고유의 재고, 가격, 이미지, 식별자가 있습니다.
- 일괄 편집과 가져오기가 필요합니다. 가격 사백 개를 손으로 바꾸는 것은 계획이 아닙니다.
- 필터링과 검색은 스토어프런트에서 큰 카탈로그가 팔리는지를 결정합니다.
- 디지털 전송은 파일을 판다면 라이선스, 다운로드, 접근 제어를 뜻합니다.
- 구독은 반복 상품을 판다면 일시 정지, 업그레이드, 결제 재시도를 뜻합니다.
샘플 상품이 아니라 가장 까다로운 상품으로 시험하세요. 옵션이 여섯 개이고, 배송 제한이 있고, 묶음 할인이 붙고, 나라별 가격이 다른 상품이 플랫폼의 한계를 드러냅니다.
세금, 배송, 국경을 넘는 판매
해외 판매는 스토어를 컴플라이언스 업무로 바꿉니다.
플랫폼이 도착지별로 세금을 어떻게 계산하는지, 시장별로 세금 포함 가격과 별도 가격을 처리하는지, 등록 기준액에는 어떻게 대응하는지 물어보세요. 그다음 결제 시점의 관세를 물어보세요. 예상치 못한 통관 청구서를 받은 고객은 환불과 나쁜 리뷰를 한꺼번에 가져옵니다.
배송 요금은 현실을 반영해야 합니다. 정액 요금은 단순하지만 돈을 잃거나 고객을 잃으니, 실시간 운송사 요금이 더 높은 요금제가 아니라 내 요금제에서 되는지 확인하세요.
스토어에 실제로 드는 비용
세 층이 쌓입니다. 구독, 거래 수수료, 그리고 빈틈을 메우려고 추가하는 애플리케이션입니다.
결제 처리는 대략 2~3%에 주문당 고정 금액입니다. 여러 플랫폼이 자체 결제 대행사를 쓰지 않으면 추가 요금을 붙이며, 이것이 낮은 월 요금을 통째로 상쇄할 수 있습니다. 앱은 세 번째 층이자 가장 예측하기 어려운 층입니다. 스토어는 흔히 리뷰, 구독, 업셀, 보고서 빌더 비용까지 내게 됩니다.
월 요금이 아니라 예상 주문량과 평균 장바구니 금액으로 총비용을 모델링하세요. 관련된 요금 관행은 요금 페이지가 감추는 것에 설명되어 있습니다.
결정하기 전에 전체 경로로 테스트 주문을 넣어 보세요. 구매, 확인 메일, 환불, 그리고 월말에 회계사가 요구할 보고서입니다.
플랫폼을 바꾸기 전에 고칠 것
이전은 비싸고 불필요한 경우가 많으므로, 플랫폼 문제와 가게 문제를 구분해 볼 가치가 있습니다.
느린 페이지, 긴 결제 과정, 부실한 상품 사진, 빈약한 설명은 가게 문제입니다. 이는 함께 따라오며, 이런 문제가 남은 채 플랫폼을 옮기면 새 청구서 위에 같은 전환율이 남을 뿐입니다.
플랫폼 문제는 다르게 보입니다. 바꿀 수 없는 결제 화면. 내 상품을 표현할 수 없는 카탈로그 구조. 시장이 기대하는데 플랫폼이 지원하지 않는 결제 수단. 실제로 받는 주문량에 비해 나쁘게 늘어나는 비용.
목록이 대부분 앞의 종류라면 먼저 그것을 고치고 나중에 다시 생각하세요. 뒤의 종류라면 이전을 제대로 계획하세요. 주소는 보존하거나 리디렉션하고, 주문 이력은 내보내고, 성수기 직전이 아니라 의도적으로 고른 한가한 시기를 잡으세요.
자주 묻는 질문
호스팅형 플랫폼과 자체 구축 스토어 중 무엇이 나을까요?
호스팅형은 유지보수를 없애는 대신 커스터마이징을 제약합니다. 자체 호스팅은 완전한 통제권을 주는 대신 업데이트, 보안, 호스팅을 떠안깁니다. 결정 요인은 겉보기에 무엇이 싼지가 아니라 개발 역량이 있느냐입니다.
거래 수수료는 실제로 얼마나 되나요?
결제 처리 수수료는 대략 2~3%에 주문당 고정 금액이 붙습니다. 자체 결제 대행사를 쓰지 않으면 플랫폼 수수료를 추가로 받는 곳도 있으며, 가장 먼저 확인할 항목이 그 추가 요금입니다.
이런 플랫폼은 상품을 몇 개까지 감당하나요?
대부분 수천 개는 처리합니다. 부담은 개수보다 옵션 조합, 필터링, 일괄 편집에서 드러나므로, 가장 복잡한 상품을 포함한 현실적인 카탈로그로 시험해 보세요.
별도의 재고 시스템이 필요한가요?
재고가 채널이나 창고 한 곳을 넘어 움직이면 필요합니다. 플랫폼의 재고 추적은 스토어 하나에는 충분하지만, 마켓플레이스를 추가하는 순간부터 초과 판매가 생깁니다.
나중에 스토어를 다른 플랫폼으로 옮길 수 있나요?
상품과 고객은 꽤 잘 내보내집니다. 주문 이력, 구독, 리뷰, URL이 어려운 부분이며, 리디렉션 없이 URL을 잃는 것이 이전을 트래픽 손실로 바꿉니다.