우리는 Amazon 판매자 계정을 스캔하여 비용 손실이 발생하기 전에 문제를 식별하는 도구인 SellerQI를 구축했습니다. Buy Box 상실, 과다 청구된 수수료, 상위 키워드를 조용히 잃어버린 리스팅 등이 그 대상입니다. 이러한 데이터의 대부분은 이미 Amazon 내부에 존재합니다. 어려운 점은 "데이터를 가져올 수 있는가"가 아니라, "충분히 빠르게, 충분히 자주 읽어 들여서 판매자가 1분 이내에 조치를 취할 수 있는 정보로 바꿀 수 있는가"였습니다.

실제로 어떤 과정이었는지, 그리고 그 과정에서 우리가 실수했던 몇 가지 사항들을 공유합니다.

의도적인 읽기 전용 (Read-only) 설계
우리가 내린 첫 번째 결정은 판매자의 계정에 어떠한 데이터도 다시 쓰지(write) 않는 것이었습니다. SellerQI는 Amazon의 Selling Partner API를 통해 읽기 전용 (read-only) 모드로 연결됩니다. 우리는 리스팅, 캠페인 또는 설정을 건드리지 않습니다.

이는 단순히 신뢰를 위한 결정일 뿐만 아니라, 신뢰 구축에도 도움이 됩니다. 또한 아키텍처를 크게 단순화해주었습니다. 누군가를 대신해 취할 수 있는 조치에 대한 롤백 로직 (rollback logic), 충돌 해결 (conflict resolution), 또는 승인 워크플로우 (approval workflows)를 구축할 필요가 없었습니다. 우리는 단지 우리가 발견한 내용이 정확해야 하고, 다음에 무엇을 해야 할지 명확하게 제시하기만 하면 되었습니다. 판매자가 모든 변경 사항에 대한 통제권을 유지하므로, 자동으로 무언가를 수정하는 도구보다 우리의 오류 발생 범위 (error surface)가 훨씬 작다는 것을 의미하기도 합니다.

데이터가 민감하고 실제 돈이 걸려 있는 마켓플레이스 API를 기반으로 서비스를 구축하고 있다면, 기능이 유용해 보이더라도 앱에 쓰기 권한 (write access)을 부여하기 전에 신중하게 생각하시길 권합니다. 보통 데이터를 잘 읽고 명확하게 설명하는 것만으로도 가치의 80%를 얻을 수 있습니다.

속도 제한 (Rate limits)이 전체 파이프라인을 결정한다
SP-API의 속도 제한 (rate limits)은 엔드포인트와 판매자 계정 규모에 따라 다르며, 전체 계정 스캔을 시도할 경우 결코 관대하지 않습니다. 초기에는 계정당 한 번의 패스 (pass)로 모든 데이터를 가져오려고 시도했습니다. 하지만 수천 개의 ASIN을 보유한 계정이 몇 개 생기자마자 그 방식은 무너졌습니다.

더 효과적이었던 방법은 다음과 같습니다:

• 데이터 유형별(리스팅 (listings), PPC, 수수료 (fees), 반품 (returns), 재고 (inventory))로 스캔을 독립적인 작업 (jobs)으로 분리하여, 하나의 작업이 느려지더라도 다른 작업이 차단되지 않도록 함
• 429 오류 발생 시 즉시 재시도하는 대신, 백오프 (backoff)를 적용한 큐잉 (queuing) 방식 사용
• 변경되었을 가능성이 가장 높은 항목을 우선순위화하여, 설정 하나가 바뀐 것을 확인하기 위해 계정이 전체 재스캔 (re-scan)이 끝날 때까지 기다리지 않도록 함
• 과거 거래 기록과 같이 매시간 변하지 않는 데이터에 대해 공격적인 캐싱 (caching) 적용

이 중 어느 것도 생소한 기술은 아닙니다. 단지 첫 실제 고객이 12,000개의 SKU를 보유하고 있고, 당신의 단순한 스캐너 (scanner)가 작동하는 데 6시간이 걸리기 전까지는 생각조차 하지 못하는 것들일 뿐입니다.

금액적 영향도 (dollar impact)에 따른 순위 매기기가 실제 제품의 핵심이 되었습니다.
우리는 순위 알고리즘 (ranking algorithm)을 만들기 위해 시작한 것이 아닙니다. 우리는 스캐너를 만들기 위해 시작했습니다. 하지만 계정당 하루에 수십 개의 이슈를 찾아내기 시작하면, 단순히 "문제 목록입니다"라고 말하는 것만으로는 충분하지 않습니다. 판매자들은 이미 자신들에게 문제가 있다는 것을 알고 있습니다. 그들이 모르는 것은 이번 주에 어떤 문제가 가장 많은 비용을 발생시키고 있는가 하는 점입니다.

따라서 모든 이슈는 고정된 임계값 (thresholds) 대신 현재 전환율 (CVR), 지출액, 과거 기준치 (baselines)와 같은 계정별 데이터를 사용하여 예상 월간 비용 또는 회수 가능한 금액으로 점수가 매겨집니다. CVR이 20%에서 18%로 떨어지는 것은 트래픽이 낮은 리스팅 (listing)에서는 아무것도 아닐 수 있지만, 트래픽이 높은 리스팅에서는 한 달에 수천 달러의 손실이 될 수 있습니다. 순위 매기기는 일반적인 규칙이 아니라 해당 특정 계정에 상대적이어야 합니다.

결국 우리의 엔지니어링 시간 대부분은 스캐닝 자체보다 이 작업에 투입되었습니다.

알림 (alerts)은 누군가를 방해할 가치가 있는 아주 짧은 목록이어야 합니다.
우리는 Buy Box 상실, 부정적인 리뷰, 재고 문제와 같은 사항에 대해 알림 이메일을 보냅니다. 초기 버전은 거의 모든 특이 사항에 대해 알림을 보냈고, 이는 사용자들이 일주일 만에 이메일을 무시하도록 길들였습니다.

우리는 목록을 대폭 축소하여 단 하루의 지연만으로도 실제 비용이 발생하는 항목들로만 유지했습니다. 그 외의 모든 사항은 누군가 실제로 깊이 파고들고 싶을 때 확인할 수 있도록 대시보드 (dashboard)에 남겨둡니다.

만약 여러분이 어떤 종류의 모니터링 제품을 만들고 있다면, 알림 목록 (alert list)을 계속해서 늘려가는 것이 아니라 지속적으로 가지치기 (prune)해야 하는 대상으로 취급해야 합니다. 무시되는 알림은 아예 알림이 없는 것보다 더 나쁩니다. 왜냐하면 사람들이 다음 알림도 무시하도록 학습시키기 때문입니다.

계정 특정 데이터에 기반한 AI 어시스턴트 (AI assistant) 구축
우리는 또한 일반적인 Amazon의 조언 대신 판매자의 실제 계정 데이터를 사용하여 질문에 답하는 어시스턴트 (QMate라고 부릅니다)를 구축했습니다. 기술적으로 흥미로웠던 부분은 모델 (model) 자체가 아니라, 답변이 실제 수치로 추적 가능하도록 (traceable) 보장하는 것이었습니다. 만약 판매자가 매출이 왜 감소했는지 묻는다면, 답변은 실제 전환율 (CVR)의 변화, 실제 이미지 수정 날짜, 또는 리스팅 (listing)에서 사라진 실제 키워드를 지목해야 합니다. 일반적인 조언은 생성하기 쉽지만 대부분 쓸모가 없습니다. 근거가 있는 답변 (Grounded answers)을 만들기 위해서는 훨씬 더 많은 배관 작업 (plumbing)이 필요합니다. 즉, 계정 이력의 적절한 조각을 가져오고, 데이터 소스 간의 타임스탬프 (timestamps)를 일치시키며, 데이터가 하락 원인을 명확히 설명하지 못할 때는 솔직하게 답변해야 합니다.

마켓플레이스 API (marketplace API)를 기반으로 구축할 때 얻은 몇 가지 교훈

• 읽기 전용 액세스 (Read-only access)는 대부분의 사람들이 생각하는 것보다 더 작고 합리적인 시작점입니다.
• 속도 제한 (Rate limits)이 기능 목록보다 여러분의 아키텍처 (architecture)를 더 많이 정의할 것입니다.
• 순위 지정 (Ranking) 및 우선순위 설정 (prioritization)이 원시 데이터 수집 (raw data collection)보다 더 가치 있는 일이 될 수 있습니다.
• 포괄적인 알림보다는 적지만 날카로운 알림이 더 낫습니다.
• 계정 데이터 위에 AI를 계층화한다면, 유창함 (fluency)보다 근거 (grounding)가 더 중요합니다.

이 중 어떤 내용이든, 특히 작업 큐 (job queue)가 어떻게 구조화되어 있는지에 대해 더 듣고 싶으신 분이 있다면 SP-API 속도 제한 (rate limiting) 부분에 대해 더 자세히 설명해 드릴 수 있습니다.