AccsMarket에서 옮길 때: 실제로 달라지는 세 가지

AccsMarket을 사용해 본 적이 있다면 이미 그 구조를 알고 있을 것이다. 판매자가 많고, 재고가 비슷하며, 주문이 정산되는 동안 자금이 보류된다. 거기서 이곳으로 넘어온 사람이라면 마켓플레이스가 무엇인지 묻는 게 아니다. 그들은 옮기면 한 주에 무엇이 흔들리는지를 묻는 것이다.

이 페이지의 이전 버전은 AccsMarket이 제대로 하지 못한다고 알려진 다섯 가지를 나열하고 두 사이트를 표로 평가하며 답했다. 우리는 그들의 코드에 접근할 수 없고, 그 어떤 것도 검증할 방법이 없으며, 당신도 마찬가지다. 그래서 그 내용은 다듬어 다시 쓰는 대신 전부 삭제했다. 아래는 2026년 8월 31일, 실시간 데이터베이스를 기준으로 이쪽에서 측정할 수 있는 것만 담았다. 다른 곳에서 판매할 때도 같은 세 가지 질문을 던져 보라. 그럼 비교할 만한 결과가 나올 것이다.

첫째: 양방향으로 흐르는 돈의 시계

구매자의 결제는 판매자에게 전달되지 않고 주문에 대해 보류된다. 수령 확인을 하면 해제된다. 구매자가 클릭하지 않으면, 주문이 생성된 시점부터 계산된 대기 시간이 지난 후 시간 단위 작업이 자동으로 해제한다. 판매자 등급에 따라 1~3일이다. 그 사이에 누구도 검토하지 않는다. 이건 대기열이 아니라 타이머다.

실제로는 타이머가 대부분의 작업을 처리한다. 확인 상태에 도달한 완료 주문 86,072건 중 73,511건은 자동으로 확인되었고 12,561건은 구매자가 확인했다. 타이머를 멈추는 것은 두 가지다: 진행 중인 분쟁과 주문에 걸린 열린 지원 티켓이다.

반대 방향으로, 출금 요청 1,994건 중 1,892건이 지급되었으며, 요청부터 처리까지 중앙값은 4시간 15분이다. 그중 1,880건은 하루 안에 정산되었고, 사이트 역사상 정확히 2건만 48시간을 넘겼다. 판매자별로 나누면, 거래량 상위 10개 판매자 모두 8시간 미만이다. 즉, 특정 계정 하나가 평균을 부풀린 게 아니다.

비용 측면에서: 주문에서 공제되는 것은 없다. 플랫폼 수수료는 지급 시점에 출금 금액의 일정 비율로 한 번만 적용되며, 각 방법마다 자체 최소 금액이 있다. 비교할 숫자가 하나가 아니라 둘이다. 수익 출금에서 수치와 지원되는 방법을 확인할 수 있다.

둘째: 두 가지가 아닌 세 가지 상품 모델

여기 카탈로그는 모두 같은 방식이 아니다. 리스팅이 어떤 모델을 쓰는지에 따라 주문이 들어왔을 때 누가 깨어 있어야 하는지가 달라진다.

• 자동은 시스템이 당신의 개입 없이 끌어다 쓰는 풀에서 채워진다. 보이는 리스팅 16,894개 중 12,129개, 현재까지 58,020건의 주문.
• 재고는 사전에 업로드한 재고로, 주문이 도착하면 행 단위로 할당된다. 3,051개 리스팅, 31,027건의 주문.
• 주문 제작은 당신이 수동 또는 API를 통해 직접 채우며, 작업하면서 주문 상태가 바뀐다. 1,714개 리스팅, 7,228건의 주문.

분포가 유용한 부분이다. 활성 리스팅의 약 10개 중 7개는 사람이 필요 없지만, 주문 제작도 무시할 수준이 아니다. 그리고 이 모델 덕분에 텍스트 파일 속 자격 증명이 아닌 것들도 카탈로그에 담을 수 있다. 주문 전달 방식은 특정 주문이 실제로 어떤 경로를 타는지 설명하며, 이는 리스팅 단위가 아니라 주문 단위로 결정된다.

리스팅 수수료는 없다. 계정이 동시에 보유할 수 있는 활성 리스팅 수에는 상한이 있으며, 판매자 등급이 올라가면 늘어난다. 그게 계획할 때 염두에 둬야 할 제약이다. 리스팅 한도에서 계산 방식을 다룬다.

셋째: API, 이것이 진짜 마이그레이션 비용이다

위의 모든 것은 정책이다. 이 부분은 작업이며, 보통 이주가 멈추는 이유다.

문서화된 인터페이스가 두 개 있고, 둘 다 아무것도 확정하기 전에 열어볼 수 있는 라이브 페이지다. 공급자 API는 인터랙티브 패널이다: 엔드포인트를 나열하고, 키를 생성하며, 키 헤더와 타임스탬프로 요청에 서명하고, 브라우저에서 각 호출을 실행해 응답을 읽을 수 있게 해준다. 또한 주문 지불 웹훅도 포함되어 있으며, 상점 설정에서 구성할 수 있다. 이 웹훅 덕분에 주문 제작 워크플로에서 폴링이 필요 없어진다. 고객 API는 구매 측면이다: 주문하기, 확정 전 재고 확인, 카테고리 트리 읽기, 별도의 SMS 인증 흐름.

수동 주문 API 가이드는 주문 제작 루프를 처음부터 끝까지 안내한다. 사람이 개입하는 루프이므로 가장 먼저 테스트해 볼 가치가 있다.

카탈로그를 옮기기 전에 상품 하나와 웹훅 하나로 테스트하라. 패널이 있으니 그 비용은 일주일이 아니라 오후 하나면 충분하다.

이 페이지가 알려주지 않는 것

이 페이지에서 빠진 네 가지 주장이 있으며, 그 부재가 바로 핵심이다.

• 리뷰가 무언가를 증명한다는 것. 리뷰는 유료 주문이 확인된 후, 주문한 구매자가 작성해야 한다. 하지만 구매자가 확인 후 아무 말도 하지 않으면 시스템이 조용히 별 다섯 개 항목을 등록하며, 거의 대부분이 정확히 그런 경우다. 사이트는 누군가 실제로 작성한 리뷰 수를 별도로 표시한다. 그 숫자에 정보가 담겨 있다. 공급자 평가하기에서 둘 다 다룬다.
• 구매가 익명이라는 것. 그렇지 않다. 계정 없이 결제할 수는 있지만, 결제가 완료되는 즉시 사용한 이메일로 계정이 생성된다. 게스트 결제는 실제로 가능하지만, 익명성은 제공되지 않으며 우리가 그렇게 암시해서는 안 됐다.
• 경쟁사가 내부적으로 어떻게 작동하는지에 대한 어떤 것. 위를 참고하라.
• 암호화나 네트워크 보안에 대한 어떤 것. 측정된 주장이 없으므로 해당 섹션도 없다.

실제로 옮긴다면

1. 무엇보다 먼저 공급자 API 패널을 열고 테스트 상품으로 엔드포인트 하나를 실행하라. 통합이 아프게 할 거라면 거기서 아프다.
2. 먼저 상품 라인 하나만 옮기고 전체 사이클을 지켜보라: 주문, 전달, 확인, 지급. 몇 주가 아니라 며칠이면 되고, 위의 타이밍이 바로 당신이 봐야 할 수치다.
3. 보증 시간을 의도적으로 설정하라. 리스팅별로 적용되며, 결제가 아닌 전달 시점부터 시작되고, 구매자들이 읽는다.
4. 지급 사이클이 한 번 완료될 때까지 두 카탈로그를 모두 활성 상태로 유지하라. 마이그레이션과 첫 출금을 같은 실험으로 만들 이유가 없다.

판매자가 아니라 구매자로 오는 중이라면, 여기서 주문을 실제로 보호하는 것이 더 유용한 페이지다.