결론부터 먼저 말하겠다. WMS 연동 모니터링에는 단 하나의 기준이 있다. 연동이 고장 났을 때 모니터링은 비즈니스보다 먼저 알아야 한다. 고객 서비스가 고객에게서 먼저 듣거나, 창고가 신규 주문이 도착하지 않아서 알아차린다면, 대시보드가 아무리 초록색으로 보여도 모니터링 설정은 실패한 것이다. 나는 아름다운 인터페이스 문서와 서버가 살아 있다는 것만을 의미하는 초록불 하나를 달고 출시된 현장을 너무 많이 봐 왔다. 그것으로는 주문이 실제로 흘렀는지 알 수 없다.
2024년 11월, 중국 동부의 한 의류 고객사가 마켓플레이스와 택배사에 연결된 새 WMS를 출시했다. 셋째 날 아침, 창고 관리자가 내게 전화했다. 왜 아침 내내 신규 주문이 하나도 도착하지 않았느냐고. 마켓플레이스 주문 인터페이스는 오전 2시에 죽어 있었다. 미들웨어는 계속 재시도했고, 재시도 큐는 계속 불어났으며, 오전 8시까지 600건이 넘는 주문이 밀려 있었다. 알림은 하나도 울리지 않았다. 상태 점검이 프로브한 것은 게이트웨이였는데, 게이트웨이는 살아 있었고, 주문 인터페이스 자체는 죽어 있었기 때문이다. 그 고객사의 말이 잊히지 않는다. 창고가 주문을 세어야 고장을 발견하는 시스템에 돈을 냈다는 것이다.
연동이 죽는 네 가지 방식이 있기에 알림 유형도 네 가지다
연동은 네 가지 방식으로 죽고, 각 방식마다 전용 알림 유형이 필요하다. 한 유형이라도 빠지면 사각지대가 하나 남는다.
첫 번째 유형은 활성 상태(liveness)로, 인터페이스가 응답하는지를 본다. 그러나 활성 상태 점검은 게이트웨이 홈페이지가 아니라 실제 비즈니스 인터페이스를 프로브해야 한다. 그 의류 고객사의 교훈은 잘못된 엔드포인트를 프로브했다는 것이다. 각 핵심 인터페이스를 개별적으로, 1분에서 3분마다 프로브하고, 세 번이 아니라 두 번 연속 실패하면 알림을 보내라. 프로브는 가볍게 유지하라. 상태만 반환하고, 상태 점검 안에서 무거운 쿼리를 절대 실행하지 마라.
두 번째 유형은 큐 적체로, 데이터가 막혀 있는지를 본다. 주문 접수, 재고 동기화, 출하 확정은 각각 자체 큐 임계값을 가진다. 임계값은 직감이 아니라 부하 테스트 데이터에서 정하라. 그 의류 창고의 수치로는 정상 물량이 시간당 약 400건이었으므로, 200건을 넘는 적체가 15분 지속된다는 것은 소비자가 이미 뒤처졌다는 뜻이었다. 임계값은 출시 이후 직감으로 조정하는 것이 아니라, 출시 전 출시 체크리스트에 들어가야 한다.
세 번째 유형은 재시도 실패로, 데이터가 유실되는지를 본다. 세 번의 재시도에 실패한 메시지는 반드시 데드레터 큐에 들어가고 즉시 사람에게 알려야 한다. 가장 위험한 설계는 조용한 재시도에 조용한 삭제가 더해진 것이다. 메시지가 로그 속을 몇 번 돌다가 아무도 책임지지 않는다. 데드레터 큐에는 이름이 정해진 담당자와 매일 비우는 시간이 필요하며, 체크리스트에 적어야지, 당연한 것으로 가정해서는 안 된다.
네 번째 유형은 대사(reconciliation)로, 양쪽이 일치하는지를 본다. 고정된 매일 일정으로 실행하라. 마켓플레이스 출하에 대한 WMS 출하, 마켓플레이스 재고에 대한 WMS 재고를 비교한다. 차이가 합의된 값을 넘으면 알림을 보내라. 대사는 마지막 그물이다. 처음 세 유형이 모두 고장을 놓쳐도 대사는 그날 안에 잡아낸다. 대사가 없는 연동은 맨몸으로 달리는 것과 같다.
| 알림 유형 | 감시 대상 | 트리거 예시 |
|---|---|---|
| 활성 상태 | 인터페이스가 응답하는가 | 핵심 인터페이스에서 두 번 연속 프로브 실패 |
| 큐 적체 | 데이터가 막혀 있는가 | 200건을 넘는 적체가 15분 지속 |
| 재시도 실패 | 데이터가 유실되는가 | 세 번 재시도 실패, 메시지가 데드레터 큐에 있음 |
| 대사 | 양쪽이 일치하는가 | 일일 대사 차이가 합의된 값을 초과 |
내가 본 세 건의 장애, 각각 다른 사각지대에서
나는 이 함정을 세 번 봤고, 각 장애는 다르게 죽었다. 첫 번째는 위의 의류 고객사였다. 활성 상태 점검이 잘못된 곳을 프로브했고, 주문 인터페이스는 창고가 알아차리기까지 6시간 동안 죽어 있었다. 프로브를 주문 인터페이스로 옮기는 것 외의 수정은 비즈니스 물량 알림이었다. 시간당 신규 주문이 정상 평균의 30% 아래로 떨어지면 즉시 알림이 울린다. 건강한 기계라도 비즈니스 물량이 무너지고 있으면 그 자체가 장애 신호다.
두 번째는 2025년 3월의 중국 남부 3PL 고객사로, 세 곳의 택배사에 연결되어 있었다. 한 택배사의 배송 추적 콜백이 간헐적으로 실패했고, 운송장 번호가 돌아오지 않았으며, 고객 불만이 일주일 만에 세 배로 늘었다. 실패한 콜백은 담당자 없이 로그에 앉아 있었다. 데드레터 큐가 없었기 때문이다. 복구는 데드레터 큐와 일일 대사를 구축한 뒤, 누락된 콜백을 운송장 번호별로 재실행하는 것이었다. 그 프로젝트 이후 나는 엄격한 규칙을 만들었다. 데드레터 큐 없이는 어떤 인터페이스도 출시하지 않는다는 것이다.
세 번째 장애는 가장 조용했다. 재고 동기화 지연이었다. WMS 재고는 바뀌었는데 마켓플레이스 재고는 2시간 뒤에 업데이트됐고, 그 사이에 40건이 넘는 주문이 초과 판매됐다. 인터페이스는 살아 있었고, 큐는 비어 있었고, 재시도는 모두 성공했으며, 처음 세 가지 알림 유형은 초록색을 유지했다. 잡을 수 있는 것은 대사뿐이었다. 핵심 SKU 동기화 지연에는 자체 임계값이 필요하다. 다음날 일일 대사가 아니라, 지연이 30분을 넘으면 알림을 보내라. 취소된 초과 판매 주문, 사과, 나쁜 리뷰는 알림 한 건의 방해보다 훨씬 비싸다.
여기 반직관적인 지점이 있다. 알림이 많다고 좋은 것이 아니다. 알림에 파묻힌 팀은 결국 모든 알림을 노이즈로 취급하게 되고, 그러면 진짜 알림도 읽지 않는다. 알림을 심각도별로 나눠라. 활성 상태 실패, 데드레터 도착, 대사 위반은 밤에 사람을 깨운다. 큐 적체와 동기화 지연은 낮 시간 처리를 위해 업무 채널로 간다. 심각도 등급이 없는 모니터링은 모니터링이 없는 것과 같다.
알림 자체만큼 중요한 것은 누가 알림을 받는가이다
사슬의 마지막 고리가 가장 자주 무시된다. 알림은 나갔는데, 수신자가 행동할 수 있는가? 나는 스무 명짜리 프로젝트 그룹에 알림이 도착해 고객이 전화할 때까지 아무도 움직이지 않은 현장을 본 적이 있다. 모든 알림에는 이름이 정해진 주 담당자와 이름이 정해진 백업이 필요하다. 주 담당자가 30분 안에 응답하지 않으면 알림은 자동으로 백업에게, 그다음 프로젝트 관리자에게 상향된다. 상향은 채팅 그룹에서 외치는 것이 아니라 시스템에 설정해야 한다.
알림 문구는 상태 코드가 아니라 지시문처럼 읽혀야 한다. 어느 인터페이스인지, 언제인지, 영향을 받은 주문이 몇 건인지, 무엇을 먼저 확인해야 하는지가 모두 알림 본문에 들어가야 한다. «인터페이스 오류»라고만 적힌 알림은 새벽 3시에 당직 엔지니어를, 어느 인터페이스가 고장 났는지도 모른 채 로그 뒤지게 만든다. 좋은 알림은 이렇게 읽힌다. 주문 인터페이스 활성 상태 실패, 2분 안에 두 번의 프로브 무응답, 약 180건의 적체, 먼저 미들웨어 로그를 확인하고 그다음 마켓플레이스 상태 페이지를 확인할 것. 그 문구와 함께 5분이면 문제가 우리 쪽인지 상대 쪽인지 알 수 있다.
한 가지 함정이 더 있다. 알림 채널 자체가 모니터링 대상 시스템에 의존해서는 안 된다. SMS와 별도의 챗봇처럼 최소 두 개의 독립적인 채널을 유지해, 한 채널의 장애가 알림을 침묵시키지 않게 하라. 채널을 매월 테스트하라. 실제 사고를 기다려 만료된 봇 토큰을 발견하는 것이 아니라, 채널 자체를 테스트하는 것이다.
출시 전날 밤 체크리스트
출시 전날 밤 체크리스트는 내가 모든 프로젝트에서 실행하는 의식이다. 모든 항목에 서명이 들어간다. 구두의 «대충 준비됐다»는 인정되지 않는다.
- 모든 핵심 인터페이스에 활성 상태 프로브 설정, 게이트웨이 홈페이지가 아니라 실제 비즈니스 엔드포인트를 향하게 할 것
- 주문, 재고, 확정 큐의 임계값을 부하 테스트 데이터에서 정하고 체크리스트에 적을 것
- 데드레터 큐 구축, 세 번의 재시도 실패 시 자동으로 그곳으로 라우팅되고 도착 시 담당자에게 알림
- 일일 대사 일정 수립, 차이 임계값과 알림 수신자 확인
- 비즈니스 물량 기준선 설정: 시간당 주문이 정상 평균의 30% 아래로 떨어지면 즉시 알림
- 백업을 포함한 알림 수신자 확인: 주 담당자가 부재하거나 연락이 닿지 않으면 백업이 알림을 받음
- 훈련 완료: 인터페이스 하나를 의도적으로 고장 내고 5분 안에 알림이 사람에게 도달하는지 확인
- 롤백 계획 문서화: 인터페이스가 계속 다운된 경우 누가 수동 주문 가져오기를 실행하고 어떻게 하는지
훈련은 가장 자주 빠지는 항목이자 가장 중요한 항목이다. 한 번도 연습된 적 없는 알림 사슬은 첫 실제 호출에서 잘못된 사람, 잘못된 그룹, 또는 아무 데도 가지 않을 것이다. 30분의 훈련으로 출시 밤 6시간의 화재 진압을 아낄 수 있다. 기준은 단순하게 유지된다. 다음에 연동이 고장 났을 때 가장 먼저 알아야 할 사람은 창고 관리자도 고객도 아니라 당직 엔지니어여야 한다.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
