결론부터 말하자. WCS 이중화와 장애 조치 계획은 본 가동 전에 확정되어야 하고, 최소 한 번은 실제처럼 처음부터 끝까지 훈련해야 한다. 훈련한 적 없는 계획은 계획이 없는 것과 같다. 나는 이 실패를 세 번 봤다. 그리고 매번 수업료는 다운타임으로 치렀다.
WCS가 왜 이리도 용서가 없을까? 자동화 창고의 두뇌이기 때문이다. 컨베이어, 분류기, 리프트, AMR 배차—모든 것이 WCS의 지시를 받는다. WCS가 죽으면 시스템은 "느려지지" 않는다. 현장의 모든 장비가 동시에 멈추고, 상품은 사람의 손이 닿지 않는 장비 위에 멈춰 선다. WMS 서버가 죽으면 종이 피킹 리스트로 출고할 수 있다. WCS가 죽으면 그냥 서서 지켜볼 뿐이다. 이는 전혀 다른 규모의 장애이며, 본 가동 밤 체크리스트에서 WCS 이중화는 깎아서는 안 될 항목이다.
이 실패를 세 번 봤다: 4시간 vs 10분
2024년 후반, 중국 남부의 전자상거래 물류센터가 화재 진압을 요청해 왔다. 그 센터는 하루 약 80,000건의 주문을 처리했고, 자동화 고층 창고와 크로스벨트 분류기를 갖췄으며, 모든 것이 단 하나의 물리적 WCS 서버에서 돌아갔다. 예비기 없음. 어느 날 아침 디스크가 고장 나 WCS가 올라오지 않았다. 현장의 풍경: 컨베이어 위에 상품이 멈추고, 분류 슈트의 절반이 가득 찼으며, 야간 근무자 60명 이상이 할 일 없이 서 있었다. 장애 감지, 부품 대기, OS 재설치, 설정 재로드, 완전 복구까지—4시간. 그 센터의 일일 물량을 감안하면 4시간은 약 13,000건의 주문 적체에 해당한다. 성수기 직전 주에 고객 서비스 전화는 불이 났다. 사후 검토에서 IT 매니저의 말이 아직도 아프다. "서버는 튼튼하다고 늘 생각했지. 그냥 죽을 수도 있다는 건 생각도 못 했어."
이제 긍정적인 사례. 2025년 상반기, 중국 동부의 3PL 자동화 창고는 교과서 같은 액티브-스탠바이 구성을 운용했다. 대기기는 프라이머리 데이터베이스를 실시간으로 복제했고, 하트비트 모니터링이 갖춰졌으며, 장애 조치 SOP는 인쇄되어 관제실 벽에 붙어 있었다. 핵심은 이거다. 본 가동 전에 완전한 실전 장애 조치 훈련을 두 번 했다—슬라이드 훈련이 아니라, 프라이머리의 네트워크 케이블을 실제로 뽑는 훈련 말이다. 가동 시작 3개월 후 프라이머리 서버의 전원 모듈이 고장 났고, 당직 운전자는 SOP를 따라 스탠바이가 10분 안에 인수했다. 훈련 두 번, 각각 두 시간 정도. 그 대가로 산 것은 실제 장애에서의 10분이었다. 쉬운 계산이다.
본 가동 전 체크리스트: 장애 조치 설계를 완성하는 5단계
1단계: 아키텍처를 선택하고, 과도하게 구축하지 마라. 하루 약 100,000건 이하의 사이트에는 데이터베이스 프라이머리-레플리카 복제의 액티브-스탠바이면 충분하다. 듀얼-액티브는 복잡도가 두 배가 된다—메가 허브에 맡겨라. 그리고 대기기의 사양은 프라이머리보다 낮으면 안 된다. 대기기 장비를 아끼지 마라. 현장 전체를 감당할 수 없는 기계로 장애 조치하는 것은 대기기가 없는 것보다 나쁘다.
2단계: 데이터 동기화 목표를 돌에 새겨라. RPO(허용할 수 있는 데이터 손실량)는 5분을 넘으면 안 된다. 복제 지연이 1분을 넘으면 담당자에게 알려라. WCS 작업 상태와 장비 상태는 복제 범위에 포함되어야 한다. 업무 데이터베이스만 복제하고 상태 데이터베이스를 빼면 어차피 혼돈 속으로 장애 조치하는 셈이다—이것이 가장 자주 놓치는 세부 사항이다.
3단계: 장애 조치 SOP는 반쯤 잠든 상태에서도 실행할 수 있도록 작성하라. 반드시 포함할 것: 장애 조치를 명령할 권한이 있는 사람(교대조 리더 이상), 순서(먼저 작업 배차 일시 중지, 다음 스탠바이 인수, 다음 장비 재연결, 마지막으로 현장 검증), 각 단계의 승인 기준(예: "3개의 컨베이어 간선 모두 상품을 움직이는 것"). 복사본 2부를 인쇄—1부는 관제실에, 1부는 IT 당직실에. 누군가의 노트북에만 존재하게 두지 마라.
4단계: 본 가동 전 최소 한 번의 완전한 실전 훈련. 세 가지 엄격한 조건: 실제 링크를 끊을 것(케이블을 뽑고, 전원을 끄고—"시뮬레이션" 버튼 금지), 모든 것을 계시할 것(장애 감지부터 생산 재개까지, 분 단위로), 사후 검토를 할 것(시간을 초과한 단계는 SOP 수정 또는 아키텍처 수정). 본 가동 후에는 분기별로 훈련하고, 핵심 인력이 바뀔 때마다 추가로 훈련하라.
5단계: 모니터링과 정기 점검, 예외 없음. 대기기는 가구가 아니다. 스탠바이 하트비트와 복제 지연을 매일 자동으로 확인하고, 주 1회 스탠바이 읽기 전용 검증(데이터가 최신 상태인지 확인)을 하고, 월 1회 장애 조치 흐름의 탁상 연습을 하라. 3개월간 아무도 로그인하지 않은 대기기는 비밀번호가 만료되었을 수 있다—내가 본 세 가지 실패 중 하나가 바로 그것이었다. 만료된 스탠바이 인증 정보 때문에 모두가 우왕좌왕하는 동안 현장은 추가로 40분 더 멈춰 있었다.
흔히 실패하는 방식: 종이 위의 계획은 계획 없음과 같다
- 스탠바이 데이터가 3개월 전 것이다: 복제는 오래전에 깨졌고 아무도 알림을 보지 않았다.
- 장애 조치 스위치를 누를 줄 아는 사람이 한 명뿐이다: 그 사람이 휴가 중이라 현장 전체가 함께 기다린다.
- 훈련은 파워포인트에서만 했다: 처음으로 실제 케이블을 뽑는 순간 장비 절반이 스탠바이에 재연결되지 않는다는 것이 드러난다.
- 스탠바이 사양 부족: 프라이머리는 수십 개의 코어, 스탠바이는 그 일부. 인수하는 순간 부하에 무너진다.
직관에 반하는 결론: 고가용성은 비싸지 않다—훈련하지 않은 계획이 비싸다
마지막으로 직관에 반하는 판단 하나. WCS 고가용성 자체는 비싸지 않다. 스탠바이 서버와 복제 소프트웨어는 보통 다운타임 1시간의 몇 분의 1 정도의 비용이다—위 계산대로, 4시간의 정지로 13,000건의 주문이 적체되었고, 고객 서비스와 SLA 파장만으로도 서버 한 대 가격은 묻혀 버린다. 진짜 비싼 것은 문서 속에만 존재하고 훈련된 적 없는 계획이다. 그것은 탈출구의 환상을 주지만, 불이 나고 나서야 출구가 벽에 그려진 그림이었다는 것을 알게 된다.
그러니 오늘 밤 당장 할 수 있는 세 가지: IT팀에 WCS에 대기기가 있는지 물어봐라. 스탠바이 데이터가 최신 상태인지, 3개월 전 것인지 물어봐라. 마지막 장애 조치 훈련이 언제였는지 물어봐라. 이 질문 중 하나라도 답이 나오지 않으면, 이는 지금 당장 안건에 올라야 한다—새벽 3시 장애 대응 전화의 시간이 아니라, 본 가동 전에.
Lin Xiao, WMS 구축 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
