핵심부터 말하자면, WMS 권한 설정 오류로 데이터가 손상될 때 원인은 거의 절대 단일 체크박스가 아니다. 세 가지 누수가 함께 작용한다――역할에 너무 넓게 부여된 권한, 고객을 무시하는 로케이션 범위, 그리고 아무도 잠그지 않는 문서 상태이다. 이 중 하나라도 놓치면 재고 실사나 고객 불만이 얽힌 문제를 풀어내라고 강제할 때까지 단 하나의 오류 메시지 없이 잘못된 데이터가 시스템을 통과한다.
나는 이 똑같은 실패를 세 번, 세 개의 서로 다른 창고에서, 세 가지 서로 다른 증상과 함께 보았다. 근본 원인은 매번 같았다. 고라이브 과정에서 누군가 시간을 아끼려고 한 역할에서 다른 역할로 권한 템플릿을 복사했고, 아무도 돌아가서 다듬지 않았다.
누수 1: 너무 넓게 부여된 역할
2024년 9월, 중국 동부의 제3자 물류 창고가 새로운 WMS를 고라이브했다. 마감 압박 속에서 구현 팀은 재고 관리자의 권한 템플릿을 복사해 피커 역할을 만들고 이름을 바꿨다. 복사 과정에서 하나의 설정이 살아남았다. 피커가 재고 수량을 수동으로 조정할 수 있다는 설정이었다.
고라이브 3주 후, 순환 실사 차이가 오르기 시작했다. 조사 결과 할당된 로케이션에서 재고를 찾지 못한 피커들이 눈앞에 보이는 것과 맞추려고 시스템 수량을 조용히 수정하고 있음이 밝혀졌다. 재고는 대개 바로 옆 베이에 있었지만, 시스템은 이제 수량이 정확하다고 말했다. 한 달 안에 120개가 넘는 SKU가 장부 재고와 실물 재고 사이에서 어긋났고, 두 건의 주문이 잘못 출고되었으며, 창고는 전체 실물 실사를 위해 주말 하나를 통째로 잃었다.
해결책은 기능이 아니라 규율이다. 권한은 직함이 아니라 액션 단위로 부여하라. 피커에게 필요한 것은 피킹 확정, 예외 보고, 스캔 검증이다. 피커에게 재고 조정, 문서 무효화, 마스터 데이터 편집은 필요 없다. 재고 관리자는 조정을 요청할 수 있지만, 그 요청은 승인을 거쳐야 한다. 슈퍼바이저는 승인할 수 있지만, 같은 거래를 입력하고 승인해서는 안 된다. 액션 목록을 적어두고 한 줄씩 확인하면 역할 이름이 숨기는 것을 잡아낼 수 있다.
| 역할 | 할 수 있는 일 | 절대 해서는 안 되는 일 |
|---|---|---|
| 피커 | 피킹 확정, 예외 보고, 스캔 검증 | 재고 조정, 문서 무효화, 로케이션 마스터 데이터 편집 |
| 입고 작업자 | 입고 확정, 로케이션 스캔, 차이 보고 | 고객 간 작업, 제품 마스터 데이터 편집 |
| 재고 관리자 | 조정 요청, 실사 수행 | 자신의 조정 승인 |
| 슈퍼바이저 | 조정 승인, 창고 전체 보고서 조회 | 같은 문서 입력과 승인 |
누수 2: 고객을 무시하는 로케이션 범위
두 번째 누수는 더 미묘하고, 다고객 창고에서 가장 아프게 물린다. 2025년 3월, 중국 남부의 한 창고가 두 화장품 브랜드에 서비스를 제공했다. 로케이션 권한은 고객별이 아니라 존별로만 설정되어 있었다. 브랜드 A의 작업자는 브랜드 B의 로케이션을 볼 수 있었고, 목록에서 잘못된 로케이션을 골라도 시스템이 막지 않았다.
브랜드 A 페이스 크림 한 배치가 브랜드 B의 피킹 페이스에 올라가게 되었다. 장부 재고는 브랜드 A라고 했고, 실물 재고는 브랜드 B의 선반에 있었다. 양쪽 브랜드의 실사가 모두 실패했고, 실제로 일어나지 않은 재고 이동을 두고 서로 상대 탓을 했다. 상자를 찾는 데 선반을 하나씩 뒤지며 나흘을 썼고, 지연된 주문을 메우기 위한 긴급 항공 배송도 필요했다.
다고객 운영에서는 로케이션 권한이 두 가지를 동시에 잠가야 한다. 사용자가 볼 수 있는 것과 사용자가 만질 수 있는 것이다. 가시성만 잠그는 것으로는 부족하다. 작업자는 로케이션 코드를 기억으로 입력할 수 있기 때문이다. 액션만 잠그는 것으로도 부족하다. 다른 고객의 데이터를 흘리는 보고서와 조회가 어차피 의사결정을 오도할 것이기 때문이다. 올바른 설정은 각 역할을 고객 범위에 묶은 뒤, 그 범위를 통해 로케이션 선택기, 작업 풀, 모든 보고서를 필터링한다. 고객 간 작업은 나타났다가 오류를 던져서는 안 된다. 아예 나타나서는 안 된다.
누수 3: 아무도 잠그지 않는 문서 상태
세 번째 누수는 문서 안에 있다. 2025년 6월, 중국 북부의 자동차 부품 창고에는 오래된 결함이 있었다. 승인된 출고 주문을 편집을 위해 되돌리고,명세를 바꾸고, 새로운 승인 없이 피킹용으로 릴리스할 수 있었던 것이다. 승인이 커버한 것은 버전 1이었다. 실제로 출고된 것을 아무도 승인하지 않았다.
피해는 구체적이었다. 승인 후 86라인짜리 출고 주문이 편집되었다. 세 라인의 수량이 늘어났고, 창고는 편집된 수량을 피킹했으며, 고객은 주문보다 많이 받았다. 원래 주문과의 대사는 실패했고, 감사 로그에는 편집자, 피커, 승인자가 모두 구별 없는 "창고 작업자" 그룹 하나로 묶여 있었다. 책임 소재를 재구성하는 것은 불가능했다.
문서 권한은 신뢰가 아니라 상태 머신으로 강제해야 한다. 문서 유형마다 상태――초안, 승인됨, 릴리스됨, 출고됨――를 매핑하고, 각 상태에서 정확히 어떤 필드를 바꿀 수 있는지 정의하라. 상태가 바뀌면 편집 가능 필드는 즉시 좁아진다. 핵심 필드가 바뀌면 문서는 승인 대기로 되돌아간다. 그 규칙은 운영 매뉴얼이 아니라 시스템 설정에 속한다. 사람은 매뉴얼을 잊는다. 시스템은 잊지 않는다.
WMS 권한 설정 오류를 위한 고라이브 당일 밤 체크리스트
이것은 내가 고라이브 당일 밤에 매번 실행하는 체크리스트이며, 모두 녹색이 될 때까지 사인하지 않는다.
- 모든 역할의 전체 권한 목록을 내보낸다. 각 역할을 할 수 있는 일 / 절대 해서는 안 되는 일 목록과 대조하고, 재고 조정, 문서 무효화, 마스터 데이터 편집에 특히 주의한다.
- 테스트 피커로 로그인한다. 재고 수량 하나를 조정하고, 문서 하나를 무효화하고, 다른 고객의 로케이션을 열어 본다. 세 가지 시도 모두 차단되어야 한다. 단 한 번의 성공도 누수이다.
- 고객 간 오류를 시뮬레이션한다. 브랜드 A 테스트 계정이 브랜드 B 로케이션 코드를 스캔하게 한다. 시스템은 이를 거부하거나 그 로케이션을 아예 표시하지 않아야 한다.
- 편집된 승인을 시뮬레이션한다. 승인된 문서의 핵심 필드 하나를 바꾸고 상태가 승인 대기로 되돌아가는지, 그리고 편집자와 승인자가 같은 계정이 될 수 없는지 확인한다.
- 승인 체인을 확인한다. 모든 조정 및 무효화 유형에 대해 승인자 목록은 해당 거래를 입력한 사람을 제외해야 한다. 긴급 우회도 감사 추적을 남겨야 한다.
- 보고서 권한을 확인한다. 한 고객으로 제한된 역할은 보고서를 통해 다른 고객의 데이터를 내보낼 수 없어야 한다.
직관에 반하는 부분은 이렇다. 과도한 권한 부여는 과소 권한 부여보다 위험하다. 과소 권한 부여는 시끄럽게 실패한다――작업자가 첫날 오류에 부딪히고 격차가 수정된다. 과도한 권한 부여는 조용히 실패한다. 작업자는 매끄럽게 일하고, 오류는 조용히 쌓이며, 재고 실사나 고객 불만이 문제를 드러낼 때쯤에는 설정 하나가 아니라 수개월치 손상된 데이터를 수리하고 있게 된다.
고라이브 팀을 위한 한 가지 경고가 더 있다. 권한 설정은 일회성 작업이 아니다. 새로운 고객, 새로운 존, 새로운 직무 역할이 생길 때마다 같은 체크리스트가 돌아가야 한다. 대부분의 창고는 권한을 한 번의 큰 실수로 망가뜨리지 않는다. 아무도 취소하지 않는 작은 "일시적으로 이것만 추가해 달라"는 호의들의 연속으로 망가뜨린다. 석 달 뒤에는 왜 그 접근 권한이 존재하는지 아무도 기억하지 못한다.
바로 그 조용한 실패 패턴 때문에 WMS 권한 설정 오류는 일회성 검토가 아니라 체크리스트를 필요로 한다. 시스템은 절대 불평하지 않으므로, 체크리스트가 대신 불평해야 한다.
권한을 제대로 설정하면 시스템이 진실을 말한다. 잘못 설정하면 매일 완전한 자신감을 갖고 오류를 기록할 것이다.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
