많은 대표님들이 프로젝트를 시작할 때 같은 문제에서 막힙니다. 쇼핑몰을 웹사이트로 만들어야 할까, 아니면 미니프로그램으로 만들어야 할까?
여러 서비스 업체에 물어봐도 말이 다릅니다. 어떤 곳은 미니프로그램이 대세라며 웹사이트는 필요 없다고 하고, 어떤 곳은 웹사이트가 근간이라며 미니프로그램은 보조일 뿐이라고 합니다. 다 맞는 말 같지만 예산은 하나뿐입니다.
사실 이 질문 자체가 방향을 잘못 잡은 것입니다. 쇼핑몰 웹사이트 개발과 미니프로그램 쇼핑몰은 대체 관계가 아니라 역할 분담 관계입니다. 핵심은 각자가 무엇을 담당할지 먼저 명확히 하고, 그다음에 어떻게 협업할지를 논하는 것입니다.
먼저 역할 분담: 누가 결제를 담당하고, 누가 신뢰를 담당하는가
흔히 볼 수 있는 합리적인 분담은 다음과 같습니다.
미니프로그램 쇼핑몰은 고빈도 재구매와 프라이빗 도메인 전환을 담당합니다. 사용자가 공식 계정, 커뮤니티, 오프라인 QR코드를 통해 유입되며 경로가 짧고 결제가 매끄러워 회원, 쿠폰, 공동구매 같은 액션에 적합합니다.
기업 웹사이트는 브랜드 신뢰 구축과 검색 유입 대응을 담당합니다. 사용자가 브랜드명이나 카테고리 키워드로 검색해 유입되면 회사가 어떤 곳인지, 자격은 어떤지, AS는 어떻게 보장되는지를 확인해야 합니다. 이 단계에서 결제가 이뤄지지 않는 것은 당연하며, 신뢰를 쌓는 것이 이 채널의 임무입니다.
구체적인 시나리오를 들어보겠습니다. 생활용품 회사가 홈페이지를 개편하면서 상품 상세, 회사 소개, AS 정책을 웹사이트에 두고, 동시에 각 상품 페이지에 미니프로그램 QR코드를 배치했습니다. 사용자가 바이두를 통해 유입되어 먼저 웹사이트를 보고, 믿을 만하다고 판단되면 QR코드를 스캔해 미니프로그램에서 주문합니다. 이 경로는 단순 광고 집행보다 전환율이 안정적입니다.
주의할 점: 양쪽 모두를 "크고 완전한" 형태로 만들지 마세요. 웹사이트에 장바구니를 쌓고 미니프로그램에 기업 소개를 쌓으면 결국 양쪽 모두 미완성 상태가 되어 유지보수 비용이 두 배로 늘어납니다.
데이터는 반드시 연동되어야 하며, 그렇지 않으면 두 개의 가게일 뿐입니다
가장 문제가 발생하기 쉬운 지점입니다.
많은 팀이 하는 방식은 이렇습니다. 웹사이트에 하나의 백엔드, 미니프로그램에 또 하나의 백엔드를 두고 상품을 각각 업로드하고 주문을 각각 확인합니다. 오픈한 지 석 달 후 재고가 맞지 않고, 회원 포인트가 호환되지 않으며, 고객센터가 두 개의 창을 열어야 한다는 것을 발견합니다.
올바른 방법은 상품과 주문을 위한 공통 미들 플랫폼을 공유하는 것입니다. 웹사이트 개발과 미니프로그램 개발이 인터페이스 레벨에서 동일한 데이터 세트에 연결되어 상품, 재고, 가격, 회원, 주문의 출처가 하나만 존재해야 합니다. 프런트엔드는 두 개일 수 있지만 백엔드는 반드시 하나여야 합니다.
구현 방식은 보통 세 가지입니다.
- 자체 API 게이트웨이를 구축해 양쪽이 동일한 인터페이스 그룹을 호출하는 방식으로 유연성이 가장 높지만 작업량도 가장 큽니다
- 성숙한 미들 플랫폼 제품을 기반으로 하고 양쪽에 어댑터 레이어를 두는 방식으로 출시는 빠르지만 제품에 제약을 받습니다
- 한쪽을 먼저 만들고 다른 쪽은 오픈 API로 연동하는 방식으로 예산을 단계적으로 투입하기에 적합합니다
어떤 방식을 선택할지는 상품 복잡도와 팀의 유지보수 역량에 달려 있습니다. SKU가 적고 기능이 단순하다면 두 번째 방식으로 충분하고, 분산 판매, 다중 창고, 복잡한 프로모션이 필요하다면 첫 번째 방식이 더 안정적입니다.
주의할 점: 인터페이스 설계 시 필드와 오류 코드를 미리 약속하세요. 양쪽 개발이 끝난 뒤에야 연동 테스트를 하지 마세요. 연동 단계에서 필드가 맞지 않는 것을 발견하면 사전에 이틀을 더 투자해 설계하는 것보다 재작업 비용이 훨씬 큽니다.
계정과 회원 체계는 한 번에 제대로 설계해야 합니다
사용자가 미니프로그램에서 가입했는데 웹사이트에서 또 다시 가입해야 한다면 이런 경험은 사용자를 즉시 이탈시킵니다.
회원 체계는 휴대폰 번호를 기본 키로 통일하고, 웹사이트와 미니프로그램 모두 동일한 로그인 인증 체계를 사용할 것을 권장합니다. 포인트, 등급, 쿠폰은 양쪽에서 동기화되어 표시되고 사용되어야 합니다.
여기서 자주 간과되는 세부 사항이 있습니다. 미니프로그램의 인증 로그인과 웹사이트의 아이디·비밀번호 로그인은 뒤에서 동일한 사용자 ID로 매핑되어야 합니다. 처음에 제대로 설계하지 않으면 나중에 데이터를 통합할 때 매우 고통스러워지며, 특히 이미 수만 명의 회원이 있는 경우에는 더욱 그렇습니다.
또한 App 개발도 계획에 있다면 회원 체계는 더더욱 사전에 통일해야 합니다. 세 채널에 각각 계정 체계를 구축하면 나중에 연동하는 것은 거의 재작업에 가깝습니다.
예산이 제한적일 때 우선순위를 정하는 방법
모든 회사가 동시에 두 채널을 오픈해야 하는 것은 아닙니다. 다음 순서로 판단할 수 있습니다.
먼저 트래픽이 어디서 오는지 보세요. 주로 검색과 콘텐츠로 고객을 확보한다면 기업 웹사이트를 먼저 탄탄히 구축하고, 주로 커뮤니티와 오프라인 매장에 의존한다면 미니프로그램을 우선하세요.
다음으로 재구매 빈도를 보세요. 고빈도 소비재는 미니프로그램으로 리텐션을 관리하기에 적합하고, 저빈도 고가 상품은 웹사이트에서 심층적인 소개를 하는 것이 더 적합합니다.
마지막으로 팀 역량을 보세요. 미니프로그램의 활동과 푸시를 지속적으로 운영할 사람이 있나요? 없다면 만들어도 껍데기에 불과합니다.
단계적으로 진행하는 것은 부끄러운 일이 아닙니다. 두려운 것은 양쪽을 모두 오픈했지만 양쪽 모두 운영이 안 되는 상황입니다.
어떤 경우에 MIC Studio를 찾는 것이 적합한가
다음 조건에 해당한다면 저희와 상담해 보시기 바랍니다.
- 이미 웹사이트나 미니프로그램 중 한쪽이 있고, 다른 쪽을 보완하면서 데이터를 연동하고 싶다
- 상품과 주문 로직이 복잡해 표준 템플릿으로는 감당이 안 된다
- 웹사이트 개발, 미니프로그램 개발, 향후 App 개발을 동시에 계획하고 있어 아키텍처를 한 번에 설계하고 싶다
- 오픈 전에 웹사이트 보안 테스트를 진행해 결제와 회원 데이터 문제를 예방하고 싶다
저희는 "순위 보장" 같은 약속은 하지 않으며, 주된 업무는 기술 방안과 실행 일정을 명확히 정리하고 단계별로 납품하는 것입니다.
실행 가능한 세 가지 제안
첫째, 프로젝트 착수 시 데이터 흐름도를 먼저 그리세요. 상품이 어디서 오고, 주문이 어디로 가며, 회원을 어떻게 식별하는지 명확히 그린 후 프런트엔드를 논하세요. 이 도표 하나로 이후 논쟁의 절반을 줄일 수 있습니다.
둘째, 양쪽 인터페이스는 계약을 먼저 정하고 개발하세요. 필드, 오류 코드, 인증 방식을 문서에 작성하고 양측이 문서에 따라 개발하면 연동 테스트 시간을 크게 단축할 수 있습니다.
셋째, 기능을 한 번에 모두 채우지 마세요. 먼저 상품, 주문, 결제라는 핵심 경로를 오픈하고 안정화된 후 회원, 쿠폰, 분산 판매를 추가하세요. 핵심 경로가 불안정하면 기능이 많을수록 문제도 많아집니다.
쇼핑몰 웹사이트 개발과 미니프로그램 쇼핑몰의 협업은 결국 아키텍처 문제이지 선택 문제가 아닙니다. 역할 분담과 데이터를 명확히 생각하면 나머지는 일정에 따라 실행하는 것뿐입니다.