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

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

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

단일 판매자 스토어에는 카탈로그 소유자, 판매자, 이행 운영 주체가 각각 하나입니다. 마켓플레이스에는 각각 여럿이 존재하고, 플랫폼이 이들 사이에 위치합니다.

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

참조 아키텍처

이 아키텍처에서 주문이 이동하는 경로:

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

벤더 온보딩 및 계정

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

두 부분은 처음부터 직접 구축하지 않는 것이 좋습니다:

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

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

카탈로그: 벤더 상품 목록 또는 공유 제품 카탈로그

패션 및 라이프스타일 마켓플레이스 대부분은 벤더 소유 또는 큐레이션 상품 목록을 선호하고, 동일 상품 마켓플레이스는 공유 카탈로그 + 오퍼 방식을 선호합니다. 어느 모델을 선택하든 상품 목록을 파이프라인으로 처리하십시오: 가져오기, 필수 속성 및 이미지 유효성 검사, 검수, 검색 게시 순서로 진행합니다. 큐를 사용하면 대량 가져오기가 구매자에게 영향을 주지 않습니다.

결제 및 정산

머니 레이어는 마켓플레이스에서 리스크가 가장 큰 부분입니다. 세 가지 결정이 이를 구성합니다.

자체 계좌에 금액을 수집하여 벤더에게 수동으로 지급하는 방식보다 플랫폼용 결제 서비스를 사용하십시오. 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가 포함됩니다. 마켓플레이스의 경우 선택은 보통 세 가지 옵션으로 좁혀집니다:

어느 기반을 선택하든 API 우선으로 설계하여 벤더 앱, 파트너 피드, AI 서비스가 스토어프런트와 동일한 인터페이스를 사용하도록 하십시오.

보안 및 신뢰

마켓플레이스는 접근 권한을 가진 사람 수를 크게 늘립니다. 벤더별·플랫폼 역할별 역할 기반 접근 제어, 관리자 및 벤더 대시보드에 대한 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 인사이트 탐색도 가능합니다.

관련 서비스 및 솔루션