eBay는 재고 동기화(Inventory Sync) 실수가 가장 치명적인 마켓플레이스입니다 - 이를 해결하는 아키텍처를 소개합니다

멀티채널 통합(Multichannel Integrations)을 구축하는 대부분의 개발자들은 eBay를 쉬운 채널로 취급합니다.
API를 연결하고, 리스팅(Listings)을 동기화하면 끝이라고 생각하죠.
그러다 고객이 단 하나뿐인 상품을 초과 판매(Oversells)하게 되면, eBay가 다른 모든 마켓플레이스에 비해 얼마나 가차 없는지(Unforgiving)를 뼈저리게 깨닫게 됩니다.

왜 eBay는 Amazon보다 초과 판매에 대해 더 가혹하게 처벌하는가
Amazon에서는 초과 판매가 발생하면 주문 취소와 퍼포먼스 지표(Performance Metric) 경고가 발생합니다. 몇 주 동안 깨끗하게 판매를 이어가면 회복할 수 있습니다.
반면 eBay에서는 그 결과가 더 빠르게 연쇄 반응을 일으킵니다:

• 리스팅 삭제 - eBay는 특정 리스팅을 즉시 삭제할 수 있습니다.
• 결함률(Defect rate) 급증 — 취소된 트랜잭션은 판매자 계정에 대한 결함(Defects)으로 집계됩니다.
• 판매자 등급 강등 — 충분한 결함이 쌓이면 계정 전체의 노출도(Visibility)가 떨어집니다.
• 최종 판매 수수료(Final value fee) 크레딧 요구 - eBay는 취소된 트랜잭션에 대해 수수료 크레딧을 요구하며, 이는 회복 과정에 마찰을 더합니다.

복합적인 효과: eBay에서의 단 한 번의 초과 판매는 단순히 해당 리스팅 하나에만 영향을 미치지 않습니다. 판매자 등급에 미치는 영향을 통해 계정 내의 모든 리스팅에 영향을 줍니다.
빈티지, 핸드메이드, 세상에 하나뿐인 제품과 같이 독특하거나 수량이 제한된 품목을 판매하는 고객의 경우, 단 한 번의 초과 판매로 다시는 재현할 수 없는 리스팅을 영구적으로 잃을 수 있습니다.

근본 원인 — 언제나 동일합니다
멀티채널 설정에서의 모든 eBay 초과 판매는 결국 한 가지, 즉 채널 간의 동기화 지연(Sync lag)으로 귀결됩니다.

javascript
// 전형적인 멀티채널 시나리오
// T+0:00 — 동기화 실행. eBay는 1개 재고 표시. Amazon은 1개 재고 표시.
// T+0:04 — Amazon에서 제품 판매됨. Amazon은 0개 표시.
// T+0:04 — eBay는 여전히 1개 표시. 동기화가 아직 실행되지 않음.
// T+0:11 — 고객이 eBay에서 구매. eBay가 주문을 처리함.
// T+0:11 — 실제 재고: -1개. eBay 결함 발생 예정.
// T+0:15 — 동기화 실행. 피해를 발견함. 이미 너무 늦었음.

const syncInterval = 15 * 60 * 1000; // 15분
const timeOfAmazonSale = 4 * 60 * 1000; // T+4분
const timeOfEbaySale = 11 * 60 * 1000; // T+11분

const ebayStillShowsAvailable = timeOfEbaySale < syncInterval; // true
// Amazon에서 상품이 판매된 후 11분 동안 eBay에는 재고가 있는 것으로 표시되었습니다.
// 결과: 초과 판매 (oversell), 결함 (defect), 리스팅 삭제 가능성
폴링 (polling) 아키텍처가 11분의 공백을 만들었습니다. 초과 판매는 그 공백 안에서 발생했습니다. 동기화는 올바르게 실행되었지만, 단지 너무 늦었을 뿐입니다.

eBay 특유의 동기화 과제
eBay에는 다른 채널보다 동기화를 더 복잡하게 만드는 몇 가지 플랫폼 특유의 동작 방식이 있습니다:

변형 리스팅 (Variation listings)
eBay의 변형 리스팅(Variation listings)—하나의 리스팅에 여러 사이즈/색상 조합이 포함된 형태—은 단순히 부모 리스팅 (parent listing) 수준이 아니라, 각 변형 수준에서 수량 업데이트를 수행해야 합니다.

javascript
// eBay 변형 재고 업데이트 (eBay variation inventory update)
async function updateEbayVariationInventory(itemId, variationSpecifics, qty) {
const request = {
ReviseInventoryStatus: {
InventoryStatus: [{
ItemID: itemId,
SKU: variationSpecifics.sku,
Quantity: qty
// 변형 SKU를 반드시 지정해야 합니다 — 부모 수량만으로는 불충분합니다
}]
}
};

return ebayApi.post('ReviseInventoryStatus', request);
}

// 단순 리스팅 업데이트와 비교
async function updateEbaySimpleListingInventory(itemId, qty) {
const request = {
ReviseInventoryStatus: {
InventoryStatus: [{
ItemID: itemId,
Quantity: qty
}]
}
};

return ebayApi.post('ReviseInventoryStatus', request);
}

이 과정을 잘못 처리하여 변형 수량을 업데이트하지 않고 부모 수량만 업데이트하면, 부모 수량이 정확하더라도 eBay의 변형 수준에서는 잘못된 가용성이 표시됩니다.

취소 시까지 유효 (Good Till Cancelled) 리스팅
대부분의 eBay 리스팅은 취소 시까지 유효 (Good Till Cancelled, GTC) 방식을 사용하며, 이는 리스팅이 무기한으로 활성 상태를 유지함을 의미합니다. 재고가 0이 되어도 리스팅이 자동으로 종료되지 않으며, 명시적으로 처리하지 않으면 수량이 0인 상태로 활성 상태를 유지합니다.

javascript
// eBay GTC 리스팅의 재고 0 처리 (Handle zero stock on eBay GTC listings)
async function handleZeroStock(sku) {
const ebayListings = await getEbayListingsForSku(sku);

await Promise.all(
ebayListings.map(async listing => {
if (listing.listingType === 'GTC') {
// 옵션 1: 수량을 0으로 업데이트 (리스팅은 유지되지만 품절로 표시됨)
await updateEbayVariationInventory(listing.itemId, listing.variation, 0);

    // 옵션 2: 리스팅을 완전히 종료 (검색 결과에서 제거됨)
    // await endEbayListing(listing.itemId, 'NotAvailable');

...

);
}
API 속도 제한 (Rate limits)
eBay의 Trading API는 계정 수준에 따라 일일 호출 제한이 다릅니다. 대규모 카탈로그를 보유한 대량 판매자는 대규모 동기화 작업 중에 속도 제한에 걸릴 수 있습니다.
javascript// 속도 제한을 고려한 eBay 동기화
class EbayRateLimitManager {
constructor(dailyLimit = 5000) {
this.dailyLimit = dailyLimit;
this.callsToday = 0;
this.resetAt = this.getNextMidnight();
}

async executeWithRateLimit(apiCall) {
if (Date.now() > this.resetAt) {
this.callsToday = 0;
this.resetAt = this.getNextMidnight();
}

if (this.callsToday >= this.dailyLimit * 0.9) {
  // 제한에 도달 중 — 긴급하지 않은 호출은 큐에 추가
  await this.queue.push(apiCall);
...

}

getNextMidnight() {
const tomorrow = new Date();
tomorrow.setDate(tomorrow.getDate() + 1);
tomorrow.setHours(0, 0, 0, 0);
return tomorrow.getTime();
}
}

eBay를 위한 이벤트 기반 (Event-driven) 해결책
올바른 아키텍처는 모든 재고 변동(Stock mutation)을 다음 예정된 작업(Scheduled job)이 아닌, 즉시 eBay로 전파되는 이벤트로 취급합니다.
javascript// 이벤트 기반 eBay 동기화
orderEventBus.on('order.confirmed', async ({ sku, qty, channel, orderId }) => {
// 멱등성 (Idempotency) — 안전한 재시도
if (await idempotencyStore.exists(orderId)) return;

// 낙관적 잠금 (Optimistic locking) — 동시 주문이 안전하게 해결됨
const result = await inventory.decrementWithLock(sku, qty);

if (!result.success) {
// 즉시 eBay 리스팅 중단 — 다음 동기화를 기다리지 않음
await ebay.endOrZeroListing(sku);
throw new InsufficientStockError(sku);
}

// eBay에 즉시 전파 (Propagate)
const ebayPropagation = ebay.updateInventory(sku, result.newQty, {
updateVariations: true, // Variation 목록 처리
handleGTC: true, // Good Till Cancelled 동작 처리
rateLimitAware: true // API 호출 제한 준수
});

// 다른 모든 채널에 동시에 전파 (Propagate)
const otherChannelPropagations = connectedChannels
.filter(ch => ch.id !== channel && ch.id !== 'ebay')
.map(ch => ch.updateInventory(sku, result.newQty));

// 모든 채널을 동시에 업데이트 — 순차적(sequentially)이 아님
await Promise.allSettled([
ebayPropagation,
...otherChannelPropagations
].map(p => p.catch(err => deadLetterQueue.push({ sku, err }))));

await idempotencyStore.mark(orderId);
});
세 가지 주목할 점:
병렬 전파 (Parallel propagation) — eBay와 다른 모든 채널이 Promise.allSettled을 통해 동시에 업데이트됩니다. 순차적 업데이트는 일부 채널이 완료되기를 기다리는 동안 다른 채널들이 진행되어 마지막 채널에 불필요한 지연(lag)을 만듭니다.

eBay 전용 매개변수: Variation 처리와 GTC 동작은 eBay 전파 호출에서 명시적으로 다루어져야 합니다. eBay의 목록 구조를 고려하지 않은 일반적인 재고 업데이트는 Variation 목록에서 잘못된 결과를 초래할 것입니다.

eBay 실패에 대한 DLQ (Dead Letter Queue): eBay의 API는 부하(load)가 걸릴 때 Shopify나 Amazon보다 신뢰성이 떨어집니다. 실패한 전파는 조용히 무시되는 대신 데드 레터 큐(dead letter queue)로 보내져야 합니다. 누락된 실패한 eBay 업데이트는 다음 수동 동기화까지 eBay에 오래된 재고를 표시하게 만듭니다.

eBay 동기화 상태 모니터링:
javascriptconst ebayHealthMetrics = {
// eBay 전용 동기화 지연 (sync lag)
ebaySyncLagP99: async () => {
const p99 = await metrics.getPercentile('sync_lag_ms', 99, {
channel: 'ebay'
});
return { pass: p99 < 5000, value: ${p99}ms, threshold: '5000ms' };
},

// 결함률 (Defect rate) — eBay는 이를 매우 엄격하게 처벌합니다
bayDefectRate: async () => {
const rate = await ebayApi.getSellerDashboard();
return {
pass: rate.defectRate < 0.005, // 0.5% 임계값 (threshold)
value: rate.defectRate,
threshold: '0.5%'
};
},

// 옵션 동기화 정확도 (Variation sync accuracy)
variationSyncAccuracy: async () => {
const discrepancies = await auditLog.getVariationDiscrepancies('ebay', '24h');
return { pass: discrepancies === 0, value: discrepancies };
},

// 종료되어야 하지만 재고가 0으로 표시되는 GTC 리스팅 (GTC listings showing zero stock that should be ended)
staleZeroStockListings: async () => {
const stale = await ebayApi.getActiveListingsWithZeroStock();
return { pass: stale.length === 0, value: stale.length };
}
};

// 매시간 실행 — 모든 실패에 대해 알림 전송
setInterval(async () => {
const results = await Promise.all(
Object.entries(ebayHealthMetrics).map(async ([name, check]) => ({
name,
result: await check()
}))
);

results
.filter(r => !r.result.pass)
.forEach(r => alerting.warn(eBay 상태 점검 실패: ${r.name}, r.result));

}, 60 * 60 * 1000);

결함률 (Defect rate) 점검은 eBay 특화 지표 중 가장 중요합니다. 결함이 나타날 때쯤이면 이미 초과 판매 (Oversell)가 발생한 상태입니다. 하지만 결함률 추이를 모니터링하면 계정 수준의 영향이 발생하기 전에 조기 경보를 받을 수 있습니다.

실제 운영 환경에서의 모습
이것이 Nventory가 eBay를 처리하는 방식입니다. 이벤트 기반 동기화 (Event-driven sync)를 통한 네이티브 통합, 옵션 (Variation)을 고려한 수량 업데이트, GTC 리스팅 관리, 그리고 eBay 특화 상태 모니터링이 내장되어 있습니다.

eBay 멀티채널 판매에 대한 전체 가이드: nventory.io/blog/tips-on-how-to-sell-on-ebay-multi-channel
eBay를 사용하는 멀티채널 판매자를 위한 솔루션을 구축 중이라면 탐색해 볼 가치가 있습니다: nventory.io

개발자를 위한 시사점 (The developer takeaway)
eBay는 Amazon이나 Shopify보다 통합(Integration)하기 더 어려운 플랫폼이 아닙니다. 잘못되었을 때의 결과가 더 빠르게 나타나고 더 공격적으로 누적되기 때문에, 제대로 구현하기가 더 어려울 뿐입니다.
변형 사항을 인식하는 업데이트 (Variation-aware updates). GTC 리스팅 관리 (GTC listing management). 속도 제한 인식 (Rate limit awareness). 결함률 모니터링 (Defect rate monitoring).
표준적인 이벤트 기반 동기화 아키텍처 (Event-driven sync architecture) 위에 추가되는 네 가지 eBay 특화 요구사항입니다.
고객이 단 하나뿐인 상품을 처음으로 초과 판매 (Oversell)하기 전에 이 사항들을 제대로 구현하십시오.
그 이후에는 — 해당 리스팅을 살리기에는 너무 늦습니다.