마켓플레이스 플랫폼 아키텍처: 벤더, 카탈로그, 결제, AI, 확장성

이 기술 문서는 멀티벤더 마켓플레이스를 계획하거나 기존 스토어를 마켓플레이스로 전환하려는 CTO, 아키텍트, 프로덕트 오너를 위한 것입니다. 아키텍처, 주요 트레이드오프, 테스트 방법을 설명합니다. 정보 제공 목적의 문서입니다. 구축 범위를 정할 준비가 되셨다면 이커머스 마켓플레이스 솔루션을 참고하십시오. 커스텀 플랫폼이 과연 정당화되는지에 대한 더 넓은 질문은 커스텀 이커머스 플랫폼 가이드를 참고하십시오. 에이전틱 커머스 준비도 및 멀티테넌트 SaaS 아키텍처도 참고하십시오. 마켓플레이스 플랫폼 옵션도 참고하십시오.

맥락: 스토어가 마켓플레이스가 될 때 달라지는 것

단일 판매자 스토어에는 카탈로그 소유자, 판매자, 이행 운영이 각각 하나씩 있습니다. 마켓플레이스에는 각각 여럿이 있으며, 플랫폼이 그 사이에 위치합니다.

각 행마다 데이터, 규칙, 장애 모드가 추가됩니다. 아키텍처는 단일 판매자 스토어를 억지로 늘리는 대신, 이를 명시적으로 다루어야 합니다.

레퍼런스 아키텍처

이 아키텍처를 통한 주문의 경로:

1. 쇼핑객이 3개 벤더의 상품이 담긴 장바구니를 체크아웃합니다.
2. 결제 제공업체가 쇼핑객에게 한 번 청구합니다.
3. 원장이 각 벤더의 몫, 플랫폼 수수료, 기타 수수료를 기록합니다.
4. 주문 라우팅이 3개의 벤더 주문을 생성하고 각 벤더에 알립니다.
5. 각 벤더가 배송하고 자체 주문을 업데이트하면, 쇼핑객은 통합 상태를 확인합니다.
6. 보류 기간 이후, 정산이 각 벤더의 잔액을 은행 계좌로 이체합니다.
7. 한 벤더 주문에 대한 환불 또는 분쟁은 해당 벤더의 잔액만 조정합니다.

벤더 온보딩 및 계정

온보딩 속도는 카탈로그가 얼마나 빨리 성장할 수 있는지를 결정하므로, 관리 양식이 아닌 프로덕트 플로우로 취급하십시오. 좋은 플로우는 시작에 필요한 최소 정보만 수집하고, 검증이 진행되는 동안 벤더가 상품을 등록할 수 있게 하며, 검증이 완료될 때까지 상품 목록이 아닌 정산을 차단합니다.

처음부터 직접 구축하지 말아야 할 두 가지 영역이 있습니다:

• 신원 및 정산 검증. 마켓플레이스 결제 서비스가 이를 처리합니다. 예를 들어 Stripe Connect는 연결된 계정의 온보딩 옵션을 제공하고, 각 계정에 필요한 검증 정보를 수집하며, 정산을 관리합니다.
• 판매자 신고 의무. EU에서는 이사회 지침(EU) 2021/514인 DAC7이 2023년 1월 1일부터 적용되어, 디지털 플랫폼 운영자가 판매자 정보를 수집·검증하고 세무 당국에 연간 보고하도록 요구합니다. 이 필드를 나중에 추가하지 않도록 온보딩 시 벤더 데이터 모델을 설계하십시오.

벤더 계정에는 자체 역할이 필요합니다: 소유자, 상품 목록을 관리하는 직원, 주문 및 정산을 확인하는 직원. 모든 벤더 쿼리는 해당 벤더의 레코드로 범위가 제한되어야 합니다.

카탈로그: 벤더 소유 상품 목록 vs. 공유 상품 카탈로그

패션 및 라이프스타일 마켓플레이스 대부분은 벤더 소유 또는 큐레이션 상품 목록 방식을 선호하고, 동일 상품 마켓플레이스는 오퍼가 포함된 공유 카탈로그 방식을 선호합니다. 어떤 모델을 선택하든 상품 목록을 파이프라인으로 처리하십시오: 임포트, 필수 속성 및 이미지 유효성 검사, 모더레이션, 그 다음 검색에 게시. 큐를 사용하면 대용량 임포트가 쇼핑객에게 영향을 미치지 않습니다.

결제 및 정산

머니 레이어는 마켓플레이스에서 리스크가 가장 집중되는 영역입니다. 세 가지 결정이 이를 결정합니다.

자체 계좌로 수금 후 벤더에게 수동 지급하는 대신, 플랫폼용으로 설계된 결제 서비스를 사용하십시오. Stripe Connect가 한 예입니다: 마켓플레이스가 고객으로부터 결제를 수집하고 판매자에게 일부를 지급할 수 있게 하며, 연결된 계정 잔액과 정산을 제공업체가 관리합니다. 그래도 자체 원장은 유지하십시오. 수수료, 요금, 환불, 조정이 제공업체 기록과 대조되어야 하기 때문입니다. 정산 가이드에서 이를 다룹니다.

카드 데이터는 자체 시스템에서 벗어나 있어야 합니다. PCI DSS(Payment Card Industry Data Security Standard)는 카드 소유자 데이터를 저장, 처리 또는 전송하는 모든 주체에 대한 기술적·운영적 기준선 요건을 설정합니다. 제공업체의 호스팅 결제 필드나 체크아웃을 사용하면 대부분의 카드 처리가 제공업체 측에서 이루어져 자체 컴플라이언스 범위가 줄어듭니다.

주문, 이행, 반품

• 조기 분할. 나중이 아닌 체크아웃 시점에 벤더 주문을 생성하여 각 벤더가 즉시 작업을 확인할 수 있게 하십시오.
• 벤더별 배송. 각 벤더는 다른 장소에서 다른 요금과 기간으로 배송할 수 있습니다. 쇼핑객에게는 이를 합산한 배송 요약을 보여주십시오.
• 통합 상태. 쇼핑객은 벤더별 라인이 있는 주문 하나를 봅니다. 지원 직원은 전체 이력을 확인합니다.
• 벤더 라인별 반품 및 환불. 한 벤더 상품 반품이 다른 벤더의 잔액에 영향을 주어서는 안 됩니다.

플랫폼 확장

플랫폼 베이스 선택

Netbase JSC는 WooCommerce, Magento 2, Laravel, 헤드리스 커머스 기반의 커머스 플랫폼을 납품했으며, 더 넓은 스택에는 PrestaShop, OpenCart, Shopware, CS-Cart, Shopify, Salesforce, Akeneo, Odoo, Symfony가 포함됩니다. 마켓플레이스의 경우 선택은 보통 세 가지 옵션으로 좁혀집니다:

어떤 베이스를 선택하든 API 퍼스트로 설계하여 벤더 앱, 파트너 피드, AI 서비스가 스토어프론트와 동일한 인터페이스를 사용하도록 하십시오.

보안 및 신뢰

마켓플레이스는 접근 권한을 가진 사람의 수를 늘립니다. 벤더별·플랫폼 역할별 역할 기반 접근 제어, 관리자 및 벤더 대시보드 MFA, 전송 중 TLS 및 저장 시 암호화, 정기적인 취약점 스캐닝을 적용하십시오. Netbase JSC 납품은 보안 코드 리뷰, 침투 테스트, 재해 복구 계획과 함께 이러한 관행을 따릅니다. 마켓플레이스 전용 통제도 추가하십시오: 신규 벤더 및 비정상적인 정산 변경에 대한 사기 점검, 상품 목록 및 리뷰 모더레이션, 은행 정보 모든 변경에 대한 감사 추적. AI 위험 점수가 검토 큐의 우선순위를 정할 수 있지만, 정지 및 정산 보류 결정은 사람이 합니다.

테스트 증거: 출시 전 테스트 항목

이것들은 일반적인 엔지니어링 관행이며, 특정 프로젝트의 결과가 아닙니다:

• 원장 대조 테스트. 여러 벤더에 걸쳐 생성된 장바구니, 수수료, 요금에 대해 몫, 환불, 정산이 제공업체 기록과 균형이 맞는지 확인합니다.
• 주문 분할 테스트. 하나, 여러 개, 많은 벤더가 포함된 장바구니를 테스트하며, 한 라인의 부분 환불 및 취소 포함.
• 접근 테스트. 한 벤더가 다른 벤더의 상품 목록, 주문, 정산을 읽거나 변경하려는 자동화된 시도는 실패해야 합니다.
• 임포트 부하 테스트. 쇼핑객 트래픽 시뮬레이션 중 최대 예상 벤더 피드를 실행하고 페이지 응답 시간이 유지되는지 확인합니다.
• 정산 실패 테스트. 거부된 은행 정보, 정산 보류, 분쟁으로 인해 잔액이 정확하고 가시적인 상태를 유지해야 합니다.
• 랭킹 및 위험 점검. AI 검색 및 사기 점수는 쇼핑객에게 영향을 미치거나 벤더를 보류하기 전에 레이블이 지정된 쿼리 및 과거 사례 샘플과 비교됩니다.

사례: EU 패션테크 마켓플레이스

Netbase JSC는 직접 판매에서 마켓플레이스 모델로 전환하는 EU 패션테크 애그리게이터를 위한 멀티벤더 마켓플레이스를 구축했으며, 고객사는 익명으로 유지됩니다. 공개된 사례는 출시 후 6개월 이내에 GMV(총 거래액) 47% 증가, 벤더 온보딩 시간 60% 단축을 보고합니다. 이는 본 문서의 두 가지 요점을 뒷받침합니다: 온보딩이 성장 레버이며, 마켓플레이스 결제 제공업체(이 경우 Stripe Connect)를 통해 엔지니어링 노력을 온보딩 및 카탈로그 플로우에 집중할 수 있다는 것입니다. 마켓플레이스 사례 읽기.

두 개의 추가 기록이 다른 시장에서 동일한 구성요소를 보여줍니다. RB Marketplace는 서아프리카 및 디아스포라를 위해 벤더 승인, 수수료, 정산과 마켓플레이스 API 기반 고객 앱을 결합합니다. 이름을 밝히지 않은 창업자를 위한 온라인 분류 광고 플랫폼은 공격적인 광고를 관리자 모더레이션을 위해 표시하는 AI 필터링을 추가합니다. 두 기록 모두 결과를 공개하지 않습니다.

이 문서의 한계

• 레퍼런스 아키텍처와 일반적인 관행을 설명합니다. 모든 마켓플레이스는 벤더, 상품, 지역에 맞게 조정합니다.
• 결제, 세금, 소비자 규정은 국가마다 다릅니다. DAC7 및 PCI DSS는 설계 시 고려해야 할 의무의 예시로 인용된 것이며 완전한 목록이 아닙니다. 법률 및 세무 자문을 구하십시오.
• Stripe Connect는 플랫폼 결제 서비스의 한 예시로 언급되었으며, 다른 제공업체보다 추천하는 것이 아닙니다.
• EU 마켓플레이스 수치는 출시 후 6개월 동안 해당 고객사가 보고한 결과이며, 절대값은 공개되지 않습니다.

다음 단계

벤더 모델, 카탈로그 규모, 결제 지역을 공유해주시면 솔루션 검토를 예약하여 아키텍처와 첫 번째 릴리스를 설계해 드리겠습니다. 관련 서비스 보기, 리테일 및 이커머스에서 Netbase JSC의 작업 방식 확인, 또는 더 많은 Netbase JSC 인사이트 살펴보기도 가능합니다.

관련 서비스 및 솔루션