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

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

컨텍스트: 스토어가 마켓플레이스로 바뀔 때 달라지는 것

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

각 항목마다 데이터, 규칙, 장애 모드가 추가됩니다. 아키텍처는 단일 판매자 스토어를 무리하게 확장하는 대신, 이를 명확하게 구현해야 합니다.

레퍼런스 아키텍처

이 아키텍처를 통한 주문 처리 흐름:

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

판매자 온보딩 및 계정

온보딩 속도가 카탈로그 성장 속도를 결정하므로, 관리자 양식이 아닌 프로덕트 플로우로 접근해야 합니다. 시작에 필요한 정보만 수집하고, 검증이 진행되는 동안 판매자가 상품을 등록할 수 있도록 하며, 검증이 완료될 때까지 상품목록이 아닌 정산을 차단하세요.

처음부터 직접 개발하지 않아야 할 두 가지 영역이 있습니다:

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

판매자 계정에는 고유한 역할이 필요합니다: 소유자, 상품목록을 관리하는 직원, 주문 및 정산을 보는 직원 등이며, 모든 쿼리는 해당 판매자의 레코드로 범위가 제한됩니다. 온보딩 플로우에 대해서는 카탈로그 수집 방법 및 검토 큐 설계를 다루는 AI 판매자 온보딩 가이드를 참고하세요.

카탈로그: 판매자 상품목록 또는 공유 상품 카탈로그

패션·라이프스타일 마켓플레이스 대부분은 판매자 소유 또는 큐레이션 상품목록 방식을 선호하고, 동일 상품 마켓플레이스는 오퍼가 있는 공유 카탈로그를 선호합니다. 어떤 모델을 선택하든 상품목록을 파이프라인으로 처리하세요: 가져오기, 필수 속성 및 이미지 검증, 모더레이션, 검색 게시 순으로 진행합니다. 카탈로그 모델이 결정되면, AI 쇼핑 에이전트가 읽을 수 있도록 만드는 것은 별도의 스키마, 피드, 툴 인터페이스 결정사항입니다. 에이전트 준비 마켓플레이스 카탈로그 가이드를 참고하세요.

결제 및 정산

머니 레이어는 마켓플레이스에서 가장 위험 부담이 큰 영역입니다. 세 가지 결정이 이를 형성합니다.

직접 계좌로 돈을 모아 판매자에게 수동으로 지급하는 대신, 플랫폼을 위해 설계된 결제 서비스를 사용하세요. Stripe Connect가 하나의 예입니다. 이는 마켓플레이스가 고객으로부터 결제를 수집하고 판매자에게 일부를 지급할 수 있게 하며, 연결 계정 잔액과 정산을 제공업체가 관리합니다. 수수료, 비용, 환불 및 조정 사항을 제공업체 레코드와 대조해야 하므로 자체 원장도 반드시 유지하세요. 정산 가이드에서 자세히 다룹니다.

카드 데이터는 자체 시스템에 저장하지 않아야 합니다. PCI DSS(Payment Card Industry Data Security Standard)는 카드 소지자 데이터를 저장, 처리 또는 전송하는 모든 주체에 대한 기본 기술 및 운영 요구사항을 규정합니다. 제공업체의 호스티드 결제 필드 또는 체크아웃을 사용하면 대부분의 카드 처리가 제공업체 측에서 이루어지고 자체 컴플라이언스 범위가 줄어듭니다.

주문, 풀필먼트 및 반품

• 조기 분리. 나중이 아닌 체크아웃 시점에 판매자 주문을 생성하여 각 판매자가 즉시 작업을 확인할 수 있도록 합니다.
• 판매자별 배송. 각 판매자는 다른 장소에서 다른 요금과 시간으로 배송할 수 있으므로, 쇼퍼에게는 이를 통합한 하나의 배송 요약을 보여줍니다.
• 상태 집계. 쇼퍼는 판매자별 라인이 있는 하나의 주문을 보고, 지원 직원은 전체 흐름을 봅니다.
• 판매자 라인별 반품 및 환불. 한 판매자의 상품 반품이 다른 판매자의 잔액에 영향을 주지 않아야 합니다.

플랫폼 확장

플랫폼 베이스 선택

Netbase는 WooCommerce, Magento 2, Laravel, 헤드리스 커머스 기반의 커머스 플랫폼을 구축한 경험이 있으며, 더 넓은 스택에는 PrestaShop, OpenCart, Shopware, CS-Cart, Shopify, Salesforce, Akeneo, Odoo, Symfony가 포함됩니다. 마켓플레이스의 경우 선택지는 보통 세 가지로 압축됩니다:

어떤 베이스를 선택하든, 판매자 앱, 파트너 피드 및 AI 서비스가 스토어프런트와 동일한 인터페이스를 사용할 수 있도록 API 우선으로 설계하세요.

보안 및 신뢰

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

테스트 근거: 런칭 전 테스트 항목

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

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

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

Netbase는 직접 판매에서 마켓플레이스 모델로 전환하는 EU 패션 테크 애그리게이터를 위한 멀티 벤더 마켓플레이스를 구축했으며, 클라이언트는 익명을 유지합니다. 게시된 사례는 런칭 후 6개월 이내에 GMV(총 상품 거래액) 47% 상승과 판매자 온보딩 시간 60% 단축을 보고합니다. 이는 이 문서의 두 가지 핵심을 뒷받침합니다: 온보딩이 성장 레버이며, 마켓플레이스 결제 제공업체(이 경우 Stripe Connect)를 사용하면 엔지니어링 역량을 온보딩 및 카탈로그 플로우에 집중할 수 있습니다. 마켓플레이스 사례 읽기.

두 가지 추가 사례: RB Marketplace는 서아프리카 및 디아스포라를 위한 것으로, 판매자 승인, 수수료 및 정산과 마켓플레이스 API 기반의 고객 앱을 결합합니다. 온라인 분류 광고 플랫폼은 익명의 창업자를 위한 것으로, 불쾌한 광고를 관리자 모더레이션을 위해 플래그하는 AI 필터링을 추가했습니다. 두 사례 모두 결과를 게시하지 않았습니다.

이 문서의 한계

• 레퍼런스 아키텍처와 일반적인 관행을 설명합니다. 각 마켓플레이스는 판매자, 상품 및 지역에 맞게 조정합니다.
• 결제, 세금 및 소비자 규정은 국가마다 다릅니다. DAC7과 PCI DSS는 설계 시 고려해야 할 의무의 예시로 언급된 것이며 완전한 목록이 아닙니다. 법적 및 세무 조언을 구하세요.
• Stripe Connect는 플랫폼 결제 서비스의 한 예로 언급된 것이며 다른 제공업체보다 권장하는 것이 아닙니다.
• EU 마켓플레이스 수치는 런칭 후 6개월에 대한 해당 클라이언트의 보고 결과이며, 절대값은 게시되지 않았습니다.

다음 단계

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

관련 서비스 및 솔루션