Shopify와 Amazon을 동시에 운영하시나요? 아무도 경고하지 않는 재고 아키텍처(Inventory Architecture) 문제

처음으로 멀티채널 이커머스(Multichannel Ecommerce) 통합을 구축하는 대부분의 개발자들은 동일한 벽에 부딪힙니다.
스테이징(Staging) 환경에서는 모든 것이 잘 작동합니다. 프로덕션(Production)에서도 몇 달 동안은 문제없이 돌아갑니다. 그러다 고객이 플래시 세일(Flash Sale)을 진행하면 고객 지원 티켓(Support Tickets)이 쏟아지기 시작합니다.
문제는 코드가 아닙니다. 그 밑바탕에 깔린 아키텍처(Architecture) 가정입니다.

모든 것을 망가뜨리는 가정
판매자가 Shopify와 Amazon을 함께 운영할 때, 대부분의 구현 방식은 한 플랫폼을 신뢰할 수 있는 단일 원천(Source of Truth)으로 취급하고 정해진 일정에 따라 다른 플랫폼으로 동기화(Sync)합니다.

javascript
// 전형적인 첫 번째 구현 방식
setInterval(async () => {
const shopifyStock = await shopify.getInventory(sku);
await amazon.updateInventory(sku, shopifyStock);
}, 15 * 60 * 1000); // 15분마다

이 방식은 작동합니다. 작동하지 않게 될 때까지는 말이죠.
실패 모드는 구체적이고 예측 가능합니다:

javascript
// 멀티채널 초과 판매(Oversell) 타임라인
// T+0:00 — 동기화 실행. 두 채널 모두 10개로 표시됨.
// T+0:03 — Amazon에서 8개 판매됨. Amazon은 2개로 표시됨.
// T+0:03 — Shopify는 여전히 10개로 표시됨. 아직 동기화가 실행되지 않음.
// T+0:07 — 고객이 Shopify에서 5개 구매. Shopify는 5개로 표시됨.
// T+0:07 — Amazon은 여전히 2개로 표시됨. 실제 재고: -3개.
// T+0:15 — 동기화 실행. 피해 상황을 발견함.

// 결과: 3개 초과 판매, 2건의 주문 취소,
// 1건의 마켓플레이스 퍼포먼스 경고,
// 다시 돌아오지 않는 고객들

동기화는 올바르게 실행되었습니다. 단지 아키텍처가 채널 간 동시 판매(Concurrent Cross-channel Sales)를 고려하여 설계되지 않았을 뿐입니다.

이것이 버그가 아닌 아키텍처 문제인 이유
폴링(Polling) 모델은 동기화 실행 사이에 각 플랫폼이 독립적으로 작동하는 시간적 간극(Window)을 만듭니다. 판매 속도가 낮은 일반적인 거래 상황에서는 이 간극이 보이지 않습니다. 두 채널에서 동시에 마지막 남은 재고가 판매될 확률이 낮기 때문입니다.
하지만 플래시 세일(Flash Sale)과 같은 빠른 속도에서는 이것이 거의 확실한 일이 됩니다:

javascript
function oversellProbability(params) {
const {
stockLevel,
ordersPerMinute,
syncIntervalMinutes,
channelCount
} = params;

const ordersPerWindow = ordersPerMinute * syncIntervalMinutes;
const windowUtilisation = ordersPerWindow / stockLevel;

// 속도(velocity)와 채널 수(channel count)가 증가할수록 확률이 높아집니다.
return 1 - Math.pow(1 - windowUtilisation, channelCount);
}

console.log(oversellProbability({
stockLevel: 10,
ordersPerMinute: 2, // 플래시 세일 속도 (flash sale velocity)
syncIntervalMinutes: 15,
channelCount: 2
}));
// 출력: ~0.998 — 품절 초과(oversell)가 거의 확실함
15분의 동기화 간격(sync interval)과 2개의 채널을 가진 플래시 세일 속도에서는 품절 초과가 거의 확실합니다. 수학적으로 계산하면 결과는 발생하기 전에 예측 가능합니다.

아키텍처 측면의 해결책
폴링(polling) 방식을 이벤트 기반 전파(event-driven propagation)로 교체하십시오. 모든 재고 변동(stock mutation)은 즉시 이벤트를 발생시킵니다. 연결된 모든 채널은 밀리초(milliseconds) 내에 이를 수신합니다.

javascript
// 이벤트 기반 멀티채널 동기화 (Event-driven multichannel sync)
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) {
await pauseListingsAcrossChannels(sku);
throw new InsufficientStockError(sku);
}

// 즉각적인 채널 간 전파 (Immediate cross-channel propagation)
await Promise.all([
// 이 주문의 소스가 아닌 모든 채널을 업데이트
...connectedChannels
.filter(ch => ch.id !== channel)
.map(ch => ch.updateInventory(sku, result.newQty)
.catch(err => deadLetterQueue.push({ sku, channel: ch.id, err }))
),
// 감사 추적 (Audit trail)
auditLog.record({ sku, qty, channel, orderId, result, timestamp: Date.now() })
]);

await idempotencyStore.mark(orderId);
});

품절 초과(Oversell) 확률 계산이 완전히 달라집니다:

javascript
// 이벤트 기반 동기화 (Event-driven sync) 사용 시
// 유효 동기화 간격: ~밀리초 (네트워크 지연 시간)
console.log(oversellProbability({
stockLevel: 10,
ordersPerMinute: 2,
syncIntervalMinutes: 0.1, // ~6초의 유효 지연 시간
channelCount: 2
}));
// 출력값: ~0.04 — 품절 초과 확률이 거의 0에 수렴

동일한 타임 세일 속도. 동일한 재고 수준. 동일한 채널 수. 하지만 아키텍처가 다릅니다. 품절 초과 확률이 거의 확실한 상태에서 거의 0에 가까운 상태로 떨어집니다.

이 시스템을 프로덕션 환경에 적합하게 만드는 세 가지 요소

멱등성 (Idempotency) — 대량의 재시도(Retries)는 피할 수 없습니다. 멱등성 키(Idempotency keys)가 없다면, 재시도는 재고 수량을 조용히 망가뜨리는 중복 차감을 생성합니다.

낙관적 잠금 (Optimistic locking) — 서로 다른 채널에서 동시에 마지막 남은 SKU에 대해 두 개의 주문이 들어올 경우, 동일한 재고 수량을 기준으로 해결되어야 합니다. 잠금 장치가 없다면 두 주문 모두 성공하게 되고, 아키텍처가 방지하려고 했던 품절 초과 상황이 발생합니다.

데드 레터 큐 (Dead letter queue, DLQ) — 채널 API는 실패할 수 있습니다. 속도 제한(Rate limits)에 걸리기도 합니다. DLQ가 없다면, 실패한 전파(Propagations)는 어떤 경고도 발생시키지 않은 채 눈에 보이지 않는 재고 불일치를 누적시킵니다.

Shopify 특화 구현 참고 사항

javascript
// Shopify 웹훅 핸들러 — 모든 주문 발생 시 실행됨
app.post('/webhooks/orders/create', shopifyHmacVerify, async (req, res) => {
res.status(200).send('OK'); // 즉시 승인

const order = req.body;

await Promise.all(
order.line_items.map(item =>
orderEventBus.emit('order.confirmed', {
sku: item.sku,
qty: item.quantity,
channel: 'shopify',
orderId: shopify_${order.id}_${item.id}
})
)
);
});

// Amazon MWS/SP-API 알림 핸들러
app.post('/webhooks/amazon/orders', amazonSignatureVerify, async (req, res) => {
res.status(200).send('OK');

const notification = req.body;

if (notification.NotificationType === 'ORDER_CHANGE') {
await orderEventBus.emit('order.confirmed', {
sku: notification.OrderItem.SellerSKU,
qty: notification.OrderItem.QuantityOrdered,
channel: 'amazon',
orderId: amazon_${notification.OrderId}_${notification.OrderItemId}
});
}
});

주의해야 할 두 가지 사항:

1. 웹훅(Webhook)에 즉시 응답할 것 — Shopify와 Amazon 모두 수 초 이내에 200 응답을 받기를 기대합니다. 응답을 보낸 후 이벤트를 비동기(Asynchronously)로 처리하세요. 처리가 늦어지면 웹훅 재시도가 발생하며, 이는 멱등성(Idempotency) 시나리오를 유발합니다.
2. 채널별 주문 ID 사용 — 서로 다른 플랫폼에서 동일한 숫자 ID가 나타날 때 멱등성 키(Idempotency key) 충돌을 방지하기 위해 주문 ID에 채널 접두사를 붙이세요.

모니터링
javascript
// Shopify + Amazon 동기화에서 중요한 지표들
const syncHealthMetrics = {
// 주문 확정부터 Amazon 재고 업데이트까지 걸리는 시간
shopifyToAmazonLagMs: () => metrics.getPercentile('sync_lag_ms', 99, { channel: 'amazon' }),

// 주문 확정부터 Shopify 재고 업데이트까지 걸리는 시간
amazonToShopifyLagMs: () => metrics.getPercentile('sync_lag_ms', 99, { channel: 'shopify' }),

// DLQ(Dead Letter Queue)에서 대기 중인 전파 실패 건수
dlqDepth: () => deadLetterQueue.getDepth(),

// 지난 24시간 동안 발생한 초과 판매(Oversell) 건수
oversellCount: () => metrics.getCount('oversell_detected', '24h')
};

// 경고 임계값(Alert thresholds)
// sync lag p99 > 5000ms → 조사 필요
// dlq depth > 50 → 전파 실패(Propagation failures) 누적 중
// oversell count > 0 → 즉시 조사 필요

실제 운영 환경에서의 모습
이것이 Nventory가 구축된 아키텍처입니다. Shopify, Amazon 및 40개 이상의 기타 채널 간의 이벤트 기반 동기화(Event-driven sync)를 제공하며, 멱등성(Idempotency), 낙관적 잠금(Optimistic locking), DLQ, 그리고 전체 감사 추적(Full audit trail) 기능이 내장되어 있습니다.
이러한 해결책이 필요한 판매자를 위해 서비스를 구축하고 있다면 Shopify App Store에서 만나보실 수 있습니다: apps.shopify.com/nventory
전체 플랫폼: nventory.io

핵심 요약 (The takeaway)
Shopify와 Amazon의 재고 동기화 (Inventory sync) 문제는 데이터 신선도 (Data freshness) 문제처럼 보입니다. 하지만 실제로는 아키텍처적 해결책이 필요한 동시성 (Concurrency) 문제입니다.

폴링 (Polling)은 시간적 간극 (Windows)을 만듭니다. 이 간극은 경합 조건 (Race conditions)을 유발하며, 경합 조건은 초과 판매 (Oversells)를 발생시킵니다.

이벤트 기반 동기화 (Event-driven sync)는 그 간극을 메웁니다. 멱등성 (Idempotency)은 재시도 (Retries)를 처리합니다. 낙관적 잠금 (Optimistic locking)은 동시성 (Concurrency)을 제어합니다. DLQ (Dead Letter Queue)는 실패를 처리합니다.

네 가지 아키텍처 결정. 초과 판매 제로.

고객의 첫 번째 플래시 세일 (Flash sale)이 시작된 후가 아니라, 그전에 이 결정들을 내리십시오.