WES 보충 트리거: forward pick 존이 고갈되기 전에 보충을 시작하는 방법

결론부터 말하겠다. forward pick 존의 보충 트리거는, 하나의 트리거에 의존하지 마라. 30회 이상의 WES 도입을 해오면서 프로젝트가 죽는 가장 흔한 패턴이다. 레벨 트리거만 설정해 두고, 첫날 피커가 빈 슬롯 앞에 서 있고, 보충 태스크는 큐에 잠들어 있다. 실제로 돌아가는 설정은 세 가지 트리거 타입을 겹친다. 재고 레벨이 바닥을 받치고, 웨이브 수요 예측이 리드타임을 사고, 시간 윈도우가 안전망이 된다. 이 글에서는 각 트리거의 설정과 실패 사례, 그리고 보충과 피킹이 인력과 장비를 다툴 때의 우선순위 정하기를 다룬다.

왜 하나의 트리거 타입으로는 절대 부족한가

forward pick 존에는 내장된 모순이 있다. 슬롯은 작고 회전이 빠르다. 피커 이동을 줄이려고 패스트무버를 손이 닿는 높이에 두고 싶지만, 인체공학 슬롯은 재고를 많이 못 담고, 한 번의 큰 웨이브에 고갈된다. WES가 여기서 하는 건 시간의 수학이다. 슬롯 재고가 얼마나 버티는지, 보충에 얼마나 걸리는지, 그 두 숫자 사이의 간격이 피커를 기다리게 만드는지다.

각 트리거 타입은 그 중 하나의 질문에만 답한다. 레벨 트리거는 "지금 얼마나 남았는가"에 답한다. 웨이브 예측 트리거는 "얼마나 소비되려 하는가"에 답한다. 시간 윈도우 트리거는 "뭔가 빠져나갔는가"에 답한다. 하나만 설정하는 건 한쪽 눈으로 운전하는 것과 같다.

트리거 타입 1: 재고 레벨(Min/Max)——바닥을 받친다

가장 단순한 로직. 픽페이스 재고가 min 아래로 떨어지면 보충 태스크를 생성한다. max에서 멈춘다. 설정 체크리스트.

min은 (보충 리드타임 중 최대 소비량) + 안전 버퍼로 설정한다——최댓값으로, 평균이 아니다. 평균으로 설정하면 프로모션 데이 파탄이 보장된다.
max는 물리 슬롯 용량에서 10~15% 작업 공간을 뺀 값으로 한다. 슬롯에 욱여넣으면, 보충자가 재작업 없이 상품을 넣을 수 없게 된다.
min/max를 ABC 속도로 단계화한다. A무버는 min을 올리고, C무버는 낮게 유지해 슬로우 SKU에 보충 노동력을 태우지 않는다.
이동 중 보충 수량을 제외한다. 이미 생성되고 미실행인 태스크를 트리거 계산에서 빼라. 안 그러면 슬롯에 중복 발주가 걸린다.

이 실패를 세 번 봤다. 최악은 중국 동부의 이커머스 DC로, 하루 약 20,000 오더, min이 평균 일간 소비량으로 설정돼 있었다. 프로모션 데이 오전 10시, 핫 SKU의 픽페이스가 40분 만에 고갈됐는데 보충 리드타임은 25분——min은 태스크를 발화시킬 만큼 오래 버티지 못했다. 더 나쁜 건, 시스템이 같은 슬롯에 3건의 중복 발주를 냈다——아무도 이동 중 수량을 제외하지 않았다. 수정. 핫 SKU의 min을 시간대별 피크로 재설정하고, 중복 제거 로직을 하룻밤에 추가했다. 그 이후로 "이동 중 제외"는 내 본가동 전날 체크리스트의 필수 행이다.

트리거 타입 2: 웨이브 수요 예측——리드타임을 산다

로직. WES가 웨이브 계획을 받으면, 각 SKU의 웨이브 수요에서 역산한다——픽페이스가 웨이브를 버티지 못하면, 보충 태스크를 일찍 생성한다. 설정 체크리스트.

"웨이브 수요 + 진행 중 오더"로 예측하고, 과거 일간 평균에만 의존하지 마라. 과거는 오늘 뭘 출고하는지 모른다.
트리거 임계값을 역산으로 구한다. 먼저 "웨이브 시작 X분 전에 보충을 완료시킨다"를 정하고, 거기서 태스크 릴리스 시각을 역산한다.
데이터 품질 게이트를 추가한다. 웨이브 계획의 SKU 커버리지가 95% 아래로 떨어지면, 자동으로 레벨 트리거로 폴백한다. 불완전한 데이터로 예측하지 마라.
핫 SKU와 프로모 SKU에는 독자 규칙을 준다. 일반 SKU와 임계값을 공유하지 마라.

실패 사례. 어떤 3PL은 멋진 예측 트리거를 가졌지만, 웨이브 계획은 수동 임포트 스프레드시트로, 일상적으로 2시간 늦었다. 모든 예측은 낡은 데이터로 돌았다——태스크는 한 시간은 일찍 발화하고, 다음 한 시간은 늦었다. 교훈은 직설적이다. 예측 트리거는 상류 데이터의 품질까지만 좋다. WES에는 신선도 체크가 필요하다——웨이브 계획이 설정 윈도우 안에 갱신되지 않았으면, 레벨 트리거로 폴백하고 알림을 올려라.

트리거 타입 3: 시간 윈도우——안전망

로직. 고정 시각에 픽페이스를 일소하고, 라인 아래 것을 전부 보충한다. 설정 체크리스트.

윈도우는 웨이브 사이의 틈에 둔다——출고 피크 중의 소탕은 절대 안 된다. 보충 태스크의 홍수가 노이즈가 될 뿐이다.
안전망 라인은 min보다 느슨해도 된다. 그 일은 처음 둘이 놓친 걸 줍는 것이지, 중노동이 아니다.
스로틀을 건다. 윈도우당 보충 태스크 수에 상한을 두어, 한 번의 소탕으로 현장을 침수시키지 않는다.
윈도우당 태스크 수를 지표로 추적한다. 연속 0인 윈도우는 처음 두 트리거가 건강한 증거. 급격한 스파이크는 상류에서 뭔가 깨진 증거다.

실패 사례. 어떤 창고는 윈도우를 "매시 정각"으로 설정했다. 각 소탕마다 200건 이상의 보충 태스크가 생성됐고, 팀은 처리하지 못했고, 백로그는 눈덩이처럼 불었고, WES 태스크 풀은 완전히 막혔다. 수정. 4시간에 1회 윈도우에, 윈도우당 60태스크 상한이다. 기억해라. 안전망은 놓친 걸 줍기 위한 것이지, 본업을 위한 게 아니다.

셋 비교: 뭘 고르고, 어떻게 조합할 것인가

차원	레벨 트리거	웨이브 예측	시간 윈도우
해결하는 문제	고갈시키지 않는다	기다리게 하지 않는다	놓치지 않는다
발화 타이밍	재고가 min 아래로	웨이브 계획이 도착, 역산	고정 시각 소탕
강점	단순, 견고, 상류 데이터 불필요	최대 리드타임, 프로모에 강함	가장 만들기 쉽고, 전부 줍는다
약점	반응적. min을 틀리면 실패	웨이브 데이터 품질에 좌우	빈도가 너무 높으면 태스크 풀 침수
최적	모든 창고의 베이스라인	신뢰할 수 있는 웨이브 계획을 가진 창고	다른 둘의 보완
내 권장	필수, ABC 단계화	웨이브 계획이 신뢰할 만하면 설정	필수, 단 스로틀 적용

여기서부터가 반직관적인 얘기다. 빠른 트리거가 항상 좋은 건 아니다. 보충을 일찍 발화시키면 태스크 수가 폭발한다——보충자와 피커가 통로와 장비를 다투고, 픽 생산성이 떨어진다. 극단적인 예도 봤다. min이 너무 높아 슬롯이 비는 일은 없었지만, 보충이 현장 노동력의 40% 가까이를 먹고, 피커는 하루 종일 보충 카트를 피해 다녔다. 보충 로직의 목표는 "슬롯이 항상 가득"이 아니다. "피커가 상품을 기다리지 않는다"다. 이 두 목표는 정확히 1 리드타임만큼 떨어져 있다. 그 거리를 정확히 맞추는 게, 수위를 올리는 것보다 중요하다.

현장에서 견고한 핸디로 전송된 보충 태스크

보충과 피킹이 노동력을 다툴 때: 우선순위 정하는 법

이건 대부분 팀이 거꾸로 하는 규칙이다. 내 우선순위 리스트——한 줄 한 줄이 프로젝트에서 돈 내고 배운 것이다.

보통은, 피킹(출고)이 일상의 보충보다 위다. 출고는 고객과의 약속. 보충은 내부 효율이다. 고객과의 약속이 항상 먼저다.
단 긴급 보충은 보통 피킹보다 위다. 슬롯이 비어 있고 웨이브가 그것을 기다릴 때, 그 슬롯의 픽 태스크는 어차피 죽어 있다——먼저 보충하고 나서 픽이다.
장비를 분리한다. 보충자는 리치트럭이나 파렛트잭, 피커는 오더피커, 시간이나 통로로 어긋나게——같은 통로에서의 정면충돌 데드락 없다.
WES에서 우선순위를 동적으로 한다. 웨이브 시작 30분 전에 보충 태스크를 자동 승격시킨다. 웨이브가 돌기 시작하면 피킹을 승격시킨다. 하드코드 우선순위는 언젠가 한쪽을 벌한다.
교대 인계. 미완료 보충 태스크는 명시적 체크리스트로 인계한다. "다음 교대가 하겠지"는 절대 안 된다. 다음 교대는 바빠지고, 태스크는 사라진다.

이 실패를 세 번 봤다. 항상 같은 각본이다. 어떤 본가동 전날, 클라이언트는 "보충 우선"을 고집했다. "피커를 기다리게 해선 안 된다"는 이유에서다. 프로모션 데이, 보충자가 모든 주요 통로를 막고, 피커는 카트를 들이지 못했고, 출고 SLA가 터졌다. 하룻밤에 "피킹 우선, 긴급 보충은 새치기"로 뒤집었더니, 다음 날은 회복됐다. 그러니 보충 퍼스트냐 피킹 퍼스트냐로 나와 논쟁하지 마라——답은 "경우에 따라 다르다"다. WES가 자동으로 전환하도록 규칙에 적어라.