화요일 밤 9시 40분, 운영 매니저에게서 전화가 왔다. 계산은 이미 끝났고 답이 마음에 들지 않을 때 사람들이 짓는, 그 평온하고 무표정한 목소리였다. "오늘 밤 이 SKU를 300개 팔았어요." 그가 말했다. "WMS는 재고가 0이라고 나옵니다. OMS는 아직 40개 남았다고 하고요."
어느 시스템도 고장 나지 않았다. 주문 관리 시스템과 창고 관리 시스템 사이의 연동은 설계된 대로 정확히 돌아가고 있었다. 문제는 설계 자체였다. 상류로 흘러올라가는 재고 수치에게 '돌아간다'가 실제로 무엇을 의미하는지 아무도 묻지 않았던 것이다. 그 40개의 격차가 동기화 지연이었고, 누군가 알아차렸을 때는 과다 판매 주문이 이미 시스템에 들어와 있었다.
나는 이 영화를 너무 많이 봐서 대본을 외우고 있다. OMS에서 WMS로 향하는 방향 — 주문이 내려가는 방향 — 은 구축 시 모든 관심을 받는다. 돌아오는 길, 재고가 올라가는 길은 대충 후순위로 만들어진다. 그리고 바로 그곳에서 돈이 새어나간다.
OMS 화면의 숫자는 이력이지 실시간 피드가 아니다
실제 데이터 흐름을 따라가 보자. 주문은 모든 판매 채널에서 들어와 라우팅과 할당을 위해 OMS에 도착하고, 피킹·포장·출고를 위해 WMS로 내려간다. 반대 방향에서는 WMS가 입고, 풋어웨이(입고 정리), 피킹, 실사 조정을 OMS에 보고해야 하고, OMS는 그 정보를 각 채널에 판매 가능 수량으로 밀어 넣는다. 이 복귀 구간이 바로 지연이 사는 곳이며, 원인은 3가지다.
첫째는 동기화 빈도다. 여전히 많은 연동이 스케줄 방식이다 — 15분마다, 30분마다, 때로는 1시간마다. 즉 WMS에서 8시 05분에 피킹된 200개는 다음 스케줄 실행까지 OMS에 반영되지 않는다. 야간 피크 시간대에는 그 시간 창이 바로 과다 판매가 일어나는 때다. 이벤트 기반 푸시(입고가 등록되면, 실사 조정이 승인되면 즉시 업데이트를 쏜다)로 바꾸면 격차가 메워지지만, API 호출이 배로 늘고, 속도 제한과 인프라 비용에 정면으로 부딪힌다. 기술 퍼즐이 아니라 비즈니스 트레이드오프다.
둘째는 아무도 모르는 동기화 실패다. 배치 작업이 에러를 내고, 3번 재시도하다가, 조용히 죽는다. 너무 많은 현장에 실패 알림이 없다 — 운영팀은 다음 날 아침에야 재고 업데이트가 6시간 전에 멈췄다는 걸 안다. WMS에서는 실사 조정이 정상 등록됐는데 상류 동기화 작업이 막혀서, 채널이 이틀 묵은 숫자로 48시간 동안 팔았던 창고를 본 적이 있다.
셋째는 사람의 지연이다. 화물은 도크에 있는데, 입고 담당이 시스템에 아직 확정하지 않았다. 실사 차이는 슈퍼바이저의 승인 대기 큐에 앉아 있다. 시스템 지연은 분 단위로 측정되지만, 사람의 지연은 시간이나 일 단위로 측정된다. 내가 조사한 '동기화 정확도' 민원 절반은 시스템 옷을 입은 프로세스 문제였다.
과다 판매 주문은 취소보다 더 큰 비용을 초래한다
그래서 나는 지연을 IT 티켓이 아니라 돈 문제로 다룬다. 과다 판매는 연쇄를 일으키고, 고리마다 비용이 든다.
먼저 취소가 온다. 판매자발 취소는 마켓플레이스에 보낼 수 있는 최악의 신호 중 하나다. 아마존 정책은 판매자발 출고 전 취소를 7일 기간 내 2.5% 미만으로, 주문 불량률을 60일 기간 내 1% 미만으로 유지하라고 요구한다 — 이 선을 넘으면 판매 권한 제한이 기다린다. 피크 야간의 수십 건의 과다 판매만으로 취소율이 날아갈 수 있고, 계정 건강도는 하룻밤에 회복되지 않는다.
다음은 고객 서비스 부담이다. 환불, 사과, 부정적 리뷰. 과다 판매 주문 한 건을 처리하는 인건비는 그 주문이 남겼을 마진보다 큰 경우가 많다. 그리고 가장 조용한 비용은 땜질 처방이다 — 일부 판매자는 다른 데서 상품을 긁어모아 두 배 운임으로 늦게 발송한다. 나쁜 리뷰를 받기 위해 돈을 쓰는 셈이다.
지연을 없앨 수는 없다. 줄이고 대비할 수는 있다
결론부터 말하자. OMS와 WMS 사이의 동기화 지연은 절대 0이 될 수 없다. 2개의 시스템, 네트워크 홉, API 속도 제한 — 항상 수 초에서 수 분의 지연이 남는다. 목표는 지연을 비즈니스가 감당할 수 있는 크기로 줄이고, 나머지는 가드레일을 세우는 것이다.
줄이기는 3가지 설정 결정으로 귀결된다. 첫째, 핵심 이벤트를 실시간으로 만드는 것. 풋어웨이 완료와 실사 조정 승인은 즉시 OMS로 푸시되어야 한다. 내려가는 주문은 배치로 둬도 된다. 올라가는 재고는 예산이 허락하는 범위에서 이벤트 기반으로 해야 한다. 둘째, 올바른 필드를 동기화하는 것. WMS가 보내야 하는 것은 판매 가능 수량 — 실재고에서 할당분과 품질 보류를 뺀 것 — 이지 총 재고가 아니다. 총 재고를 그대로 넘겨 OMS가 판매 가능하다고 취급하게 한 연동을 나는 감사한 적이 있다. 그건 내장된 부풀리기다. 셋째, 다중 창고 매핑을 깔끔하게 유지하는 것. 한 SKU가 3개 건물에 있을 때 OMS 합산에서 운송 중과 동결 재고를 빼지 않으면, '가용' 숫자는 허구다.
보험은 2가지다. 첫째, 인기 SKU에는 안전 버퍼를 잡아두는 것. 실제 가용 수량이 500이면 OMS에는 460을 올리고, 지연 시간 창에 대비해 40을 남긴다. 조금의 판매율을 포기하고 보호를 사는 것 — 버퍼 크기는 해당 SKU의 과거 최악 시간당 판매율에 동기화 간격을 곱한 정도로 잡아, 최소 한 번의 지연 사이클은 커버하게 한다. 둘째, 차이 알림이 있는 일일 대사를 돌리는 것. 하루에 1번, 야간의 한적한 시간대에 두 시스템의 전체 재고 스냅샷을 비교하고, 차이가 임계값을 넘으면 알린다. 대사는 회계 쇼가 아니다 — 화난 고객에게서 정오에 듣는 대신 새벽 6시에 죽은 동기화 작업을 발견하는 방법이다.
자정에 터졌을 때, 이 3가지를 확인하라
과다 판매 주문이 큐에 쌓였나? 책임 공방은 시작하지 마라. 이 순서로 진행하면 대개 30분 안에 근본 원인에 도달한다.
먼저 WMS 트랜잭션 로그를 확인하라. 사고 시간대 전후로 해당 SKU의 대규모 피킹, 실사 조정, 입고 등록을 찾아라. '미스터리 과다 판매'의 놀라울 만큼 많은 경우, 정체는 반대 방향으로 등록된 실사 조정이나 두 번 입고된 반품이다.
다음으로 동기화 작업 로그를 확인하라. OMS가 가진 해당 SKU 재고 스냅샷의 마지막 타임스탬프를 보라. 스냅샷이 3시간 전 것인데 주문은 1시간 전까지 계속 흘렀다면, 범인은 지연이다. 실패한 재시도에 특히 주목하라 — 타임아웃인가, 속도 제한인가, 데이터 형식 불일치인가?
마지막으로 OMS 할당 로직을 확인하라. 할당 시점에 사용된 가용 수량에 안전 버퍼가 포함되어 있었는지, 이미 할당됐지만 아직 릴리스되지 않은 주문이 이중 계산되지 않았는지 확인하라. 할당 버그와 동기화 지연은 함께 나타나기를 좋아하고, 한쪽만 보면 조합을 잡을 수 없다.
찾았으면, 그 사건을 대사 규칙에 기록하라 — 다음에는 고객 서비스가 움직이기 전에 알림이 울려야 한다.
내일의 첫 업무: 우리 OMS의 재고 동기화가 스케줄 방식인지 실시간 푸시인지 알아내고, 간격을 적어 두는 것. 그 숫자가 과다 판매 반응 시간이다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
