먼저 결론부터: WMS나 자동화 go-live를 앞두고 있다면 네 단계의 알림 등급을 설정하세요 — Tier 1(SMS + 전화), Tier 2(WeCom 온콜 그룹 @멘션), Tier 3(일반 WeCom 메시지), Tier 4(이메일 다이제스트) — 응답 SLA는 각각 5분, 30분, 4시간, 다음 날입니다. "전부 SMS로 보내자"는 접근 방식을 세 번 봤습니다. 세 번 모두 알림 피로로 망했습니다. 온콜 담당자는 47번째 메시지에서 읽기를 그만뒀고, 48번째가 진짜 불이었습니다.
알림 등급화는 운영 문제가 아니라 구현 문제입니다
대부분의 프로젝트는 알림을 "go-live 이후에 운영이 알아서 하는 것"으로 취급하고, 구현 컨설턴트는 떠나갑니다. 30회가 넘는 go-live를 거친 뒤 단언합니다. 알림 규칙은 UAT 기간에 확정해야 합니다. 등급화는 인시던트 대응 프로세스를 정의하고, 인시던트 대응은 서명되는 WMS 블루프린트의 일부이기 때문입니다.
November 2023, 중국 선전의 크로스보더 이커머스 고객, go-live 후 두 번째 달. 새벽 2:14, 통합 큐가 막히기 시작하면서 재고 동결 알림이 발송됐습니다 — 그런데 이메일로만 나갔습니다. 당직 슈퍼바이저는 방해금지 모드를 켜 놓은 상태였고, 이메일은 읽히지 않은 채 인박스에 남았습니다. 오전 8시까지 재고가 동결된 상태라 2,000건이 넘는 주문을 출고할 수 없었습니다. 고객 서비스는 마비됐습니다. 직접 손실: 그날 하루 약 18,000건의 주문이 미출고됐고, 평균 주문 금액이 $22 — 마켓플레이스 지연 출고 패널티를 제외하고도 하루 매출 약 $400,000가 날아갔습니다. 이 실패를 정확히 세 번 봤습니다. 매번 "알림은 발송됐는데, 아무도 보지 않았다"였습니다.
여기 직관에 반하는 대목이 있습니다. 놓친 알림의 90%는 채널 문제가 아니라 등급화 문제입니다. 반대 극단도 봤습니다. 미국 동부의 한 3PL은 콜드체인 온도 프로브가 측정값이 흔들릴 때마다 SMS를 보내 하루 밤에 60통이 넘었습니다. 사흘째 되던 날 온콜 매니저는 알림 번호를 차단했습니다. 알림이 너무 많으면 없는 것과 같습니다. 등급화는 온콜 담당자의 주의력을 지키기 위해 존재하며, 정말로 생사를 가르는 사건만 그들을 깨우는 겁니다.
에스컬레이션 체인을 구축하는 네 단계
1단계: 먼저 등급을 정의하세요 — Tier 1 카테고리는 다섯 개를 넘지 않습니다.
두 가지 차원으로만 분류합니다: 영향 반경 × 돌이킬 수 없는 손상까지의 시간. Tier 1은 "지금 아무도 움직이지 않으면 한 시간 이내에 생산 인시던트가 발생한다"는 뜻입니다. 제 표준 고객 템플릿은 다음과 같습니다.
| Tier | 정의 | 채널 | 응답 SLA | 예시 |
|---|---|---|---|---|
| Tier 1 | 무시하면 1시간 이내 생산 인시던트 | SMS + 전화 | 5분 | WMS 다운, 콜드체인 전력 손실, 화재 경보 연동 |
| Tier 2 | 부분적 영향, 몇 시간 대기 가능 | WeCom 온콜 그룹 @on-call | 30분 | 인터페이스 적체가 임계값 초과, AGV 대규모 오프라인 |
| Tier 3 | 조치 필요, 긴급하지 않음 | 일반 WeCom 메시지 | 4시간 | 라벨 프린터 용지 부족, PDA 단독 고장 |
| Tier 4 | 통계와 추세 | 이메일 다이제스트 | 다음 날 | 어제 인시던트 요약, 디스크 70% |
Tier 1 목록은 짧게 유지하세요. 제 철칙: 카테고리 다섯 개를 넘지 않는다. 다섯 개를 넘겼다는 것은 우선순위를 가려내지 못했다는 뜻이고, 그건 등급화를 안 한 것이나 마찬가지입니다.
2단계: 온콜 로테이션을 만드세요 — 연속 두 주를 초과해 당직을 서지 않습니다.
프라이머리 + 백업 쌍으로 운영하세요. 프라이머리가 응답하고, 프라이머리가 10분 안에 수신 확인을 하지 않을 때만 백업에게 전화가 갑니다. 주 단위 로테이션, 최대 두 주. 한 번은 한 고객이 한 사람을 한 달 내내 온콜에 세운 걸 봤습니다. 세 주 차에는 응답 시간이 눈에 띄게 떨어졌습니다. 이유를 물어보니, 모든 알림이 오탐이라고 가정하는 버릇이 생겼다고 했습니다.

로테이션은 반드시 시스템 안에 있어야 합니다. 알림 플랫폼(WeCom 봇, SMS 게이트웨이)이 날짜에 따라 당직자에게 자동으로 라우팅합니다. 수동 전달은 없습니다. 수동 전달은 가장 큰 단일 장애점입니다. March 2024, 중국 동부의 한 3PL에서 온콜 슈퍼바이저가 휴가 중이었습니다. SMS는 그의 휴대전화로 갔지만, 그는 신호가 안 잡히는 고속철도 안에 있었고, 백업은 자신이 백업인지조차 몰랐습니다. 이건 Tier 1이었습니다. AS/RS 스태커 크레인 고장으로 라인이 3시간 멈췄고, 9,000케이스가 미출고됐습니다.
3단계: 에스컬레이션 체인을 구축하세요 — 타임아웃 시 자동 에스컬레이션.
이 부분은 가장 많이 빠뜨리면서도 여러분을 구해줄 가능성이 가장 큽니다. 규칙은 간단합니다.
- Tier 1 발송. 프라이머리가 5분 안에 시스템에서 "수신 확인"을 누르지 않으면 자동으로 백업에게 전화.
- 10분이 더 지나도 확인이 없으면 자동으로 운영 매니저에게 전화.
- 15분이 더 지나면 총괄 매니저에게 직접 전화하고 WeCom 관리 그룹에서 @전체를 멘션.
모든 에스컬레이션을 기록하세요. 누가 몇 시에 확인했고, 어떤 조치를 취했는지. 기록은 누굴 탓하려고 하는 게 아니라 사후 분석용입니다. 기록 없는 알림 프로세스는 다음에도 같은 방식으로 실패합니다.
4단계: go-live 전날 체크리스트 — 알림을 기능처럼 테스트하세요.
이게 제 신조이자, 매 go-live 전날 밤에 하는 일입니다.
- Tier 1 카테고리마다 수동으로 발생시켜 SMS + 전화가 1분 안에 당직 휴대전화에 도달하는지 확인
- 프라이머리가 받지 않는 상황을 시뮬레이션하고 5분에 백업으로 자동 에스컬레이션되는지 확인
- WeCom 봇 토큰이 운영용인지 확인(테스트 봇은 테스트 그룹에 게시합니다 — go-live 때 전환)
- SMS 게이트웨이에 잔액이 있는지 확인(웃으셔도 됩니다 — 잔액이 바닥나서 사흘째 메시지가 멈춘 고객을 본 적이 있습니다)
- 로테이션이 향후 4주를 커버하고 시스템에서 올바르게 라우팅되는지 확인
- Tier 4 다이제스트 수신자 목록에 고객 IT 책임자가 포함됐는지 확인
세 번 넘게 본 세 가지 실패 패턴
실패 패턴 1: 테스트 알림과 운영 알림이 섞임. 테스터가 자정에 부하 테스트를 하면 SMS 알림이 홍수처럼 나갑니다. 온콜 담당자는 세 번 깨고 나서 모든 알림을 노이즈로 취급하기 시작합니다. 대책: 테스트 환경 알림은 WeCom 테스트 그룹에만 보냅니다. SMS 채널은 절대 건드리지 않습니다.
실패 패턴 2: Tier 1 목록이 계속 늘어남. go-live 여섯 달 후, 각 부서가 로비를 시작합니다. "저희도 중요하니 Tier 1으로 올려주세요." 반년 뒤에는 Tier 1 카테고리가 20개가 넘고 SMS 채널은 다시 막힙니다. 대책: 등급 목록 변경은 리뷰를 거칩니다. 프로젝트를 떠나기 전 리뷰 프로세스를 운영 매뉴얼에 적어 둡니다. Tier 1 알림을 추가하려면 운영 매니저와 IT 책임자의 이중 승인이 필요합니다.
실패 패턴 3: 쏘고 잊어버림. 알림은 시스템상 "발송됨"으로 표시되는데, SMS 게이트웨이가 30%를 조용히 떨어뜨렸습니다. 대책: 매월 알림 상태 점검을 하세요 — 발송 수 vs 도달 수. 도달률이 95% 미만이면? 게이트웨이를 바꾸세요. 이 점검을 월간 운영 회의 안건에 넣으세요. 의지력에 기대지 마세요.
계산을 해 보세요. 이 구성 전체 비용은 소규모 창고 기준으로 연간 약 RMB 5,000–8,000의 SMS와 플랫폼 요금, 대규모 창고는 RMB 20,000–30,000입니다. 새벽 2시의 Tier 1 알림 하나를 놓치면 위 두 사례가 보여준 대가가 돌아옵니다. 하루 매출 $400,000가 날아가거나, 3시간 라인 정지로 9,000케이스 미출고. 이 산수는 직접 해 보세요.
실천할 만한 한 가지: 지금 WMS 선정이나 구현 중이라면 "알림 등급화 계획"을 계약 부속서에 넣고 블루프린트와 함께 서명하세요. 새벽 3시 전화에 아무도 이걸 정하지 않았다는 걸 깨닫지 마세요.
Lin Xiao, WMS 구축 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.




