먼저 결론부터: 자연어 재고 조회는 오늘날 작동합니다 — 하지만 좁은 차선 안에서만요: 통제된 어휘에 확인 단계를 더한 형태입니다. 그때그때 생각나는 대로 말해도 시스템이 매번 이해해 주기를 기대하시나요? 먼저 여러분 창고에서 직접 테스트해 보세요. 제가 본 운영 현장 대부분은 아직 그 단계가 아닙니다.
똑같은 실패를 세 번 봤습니다. 첫 번째는 2025년 가을, 중국 동부의 3PL이었습니다. 현장 슈퍼바이저들이 재고 숫자를 "그냥 물어보기"만 하면 되길 원했습니다. 슈퍼바이저가 태블릿에 "A존에 3C 제품 가용 재고가 얼마나 있어?"라고 말하면 시스템이 즉시 답해 주는 방식이었습니다. 매끄럽기 그지없었죠. 3주차에 터졌습니다. 시스템이 준 숫자를 기준으로 판촉 출하를 준비했는데 팔레트 두 개가 모자랐고, 긴급 운송을 붙여야 했습니다. 한 번의 긴급 육상 운송으로 석 달 치 인건비 절감이 날아갔습니다. 사후 분석에서 치명적인 문제 두 가지가 발견됐습니다. 첫째, 그들의 WMS에는 "3C 제품"이라는 카테고리가 애초에 없었습니다 — 모델이 그걸 "소비자 가전"으로 환각해 폰 케이스와 케이블을 쓸어 담으면서, 실제 3C 액세서리의 절반은 빼먹었습니다. 둘째, "모델 A"는 두 개의 SKU(빨강·파랑 변형)로 존재했는데 시스템은 하나만 조회했습니다. "모델 A"가 그 창고의 은어로 둘 한 쌍의 패밀리라는 걸 시스템은 몰랐던 겁니다.
두 번째는 전자상거래 창고로, 제대로 해냈습니다. 이유는 세 문장으로 설명됩니다. 어휘는 모델이 추측한 게 아니라 사람이 정의했고, 모든 답변은 먼저 "이렇게 이해했습니다"라고 밝힌 뒤 탭 한 번으로 확인을 기다렸고, 모든 숫자에는 출처가 붙어 있었습니다. 질문 가능한 차원을 화이트리스트로 묶었습니다 — 창고, 존, 카테고리, SKU, 로트, 재고 상태 — 여섯 가지 차원, 각각에 사람이 관리하는 유의어 맵을 붙였습니다. "3C 제품"이 목록에 없으면? 시스템이 되물었습니다. "3C 제품은 검색 가능한 카테고리가 아닙니다. 디지털 액세서리나 소비자 가전을 말씀하신 건가요?" 작업자는 한 번 탭했습니다. 10초. 그 확인 단계는 어설퍼 보입니다. 하지만 정확도를 지키는 퓨즈입니다.
세 번째는 더 까다로웠습니다. 작년의 한 화장품 창고에서 모든 SKU 이름이 색상이었습니다 — "체리 핑크", "피치 핑크", "팥 핑크". 모델은 셋이 비슷해 보인다고 판단해 유의어로 병합해 버렸고, "핑크가 얼마나 남았어?"라고 물으면 세 SKU의 재고를 합친 숫자 하나가 돌아왔습니다. 실사 재고와 맞지 않았고, 창고 팀은 전자상거래 운영팀과 고성으로 싸우게 됐습니다. 교훈: 색상, 스펙, 버전 — 유의어처럼 보이지만 절대 병합해서는 안 되는 것들 — 은 매핑 테이블에 명시적인 "병합 금지" 플래그가 필요합니다. 유의어 테이블은 "크면 클수록 좋다"의 세계가 아닙니다. 잘못 들어간 한 건이, 빠져 있는 한 건보다 더 아픕니다.
첫 번째 3PL은 어떻게 회복했을까요? 세 단계입니다. 첫째, 자유 형식 질문을 없애고 "차원을 고른 뒤 물어보기"로 바꿔, 질문 가능한 모든 것을 우리 안에 가뒀습니다. 둘째, 베테랑 슈퍼바이저 두 명을 두 주간 앉혀 유의어 맵을 200건 이상으로 만들었습니다. 슈퍼바이저들은 처음엔 투덜거렸지만, 장부를 뒤적이는 것보다 세 배 빠르다는 걸 알게 되자 자발적으로 쓰기 시작했습니다. 셋째, 모든 답변에 출처와 타임스탬프를 의무화했습니다. 두 달 뒤 틀린 답변은 사실상 사라졌습니다 — 참고로, 모델이 똑똑해진 게 아닙니다. 우리가 좁아진 겁니다.
제가 병목이 모델이 아니라고 말하는 이유는 이렇습니다. 파이프라인은 네 단계, 저는 그 모든 단계에서 넘어졌습니다.
자연어 재고 조회가 실제로 작동하는 방식: 네 단계, 네 가지 함정
- 의도 인식: "얼마나 남았어"를 "가용 재고 조회"로 번역합니다. 모델이 가장 잘하는 부분입니다. 제일 걱정 안 해도 되는 부분이죠.
- 개체 매핑: "A존"과 "3C 제품"을 실제 WMS 마스터 데이터에 연결합니다. 여기가 재앙 구간입니다. 한 제품에 이름이 세 개, 카테고리 필드 절반이 비어 있고, 신구 존 코드가 뒤섞여 있는 — 매핑 테이블은 여기서 죽습니다. 규칙은 하나: 모델은 존재하고 유일한 것만 매핑할 수 있습니다. 마스터 데이터에 없는 건 추측합니다. 추측은 틀립니다.
- WMS API 호출: 매핑을 실제 API 조회로 바꿉니다. 깨끗한 읽기 전용 조회 API가 필요합니다. 레거시 WMS 조회 엔드포인트는 사람이 읽는 리포트용으로 만들어진 경우가 많아, 필드 정의가 재고 원장과 맞지 않습니다. 그래서 두 숫자가 엇갈리고 작업자가 하나를 골라야 합니다.
- 결과 검증: 보여주기 전에 답을 검사합니다. 제대로 해낸 전자상거래 창고는 여기에 엄격한 규칙을 추가했습니다. 모든 답변에 출처를 반드시 붙이는 겁니다 — "출처: A존 가용 재고 원장. 필터: zone = A AND category = 디지털 액세서리. 10분 전 업데이트." 출처가 없으면 표시하지 않습니다.
자연어 재고 조회 파일럿 전 체크리스트
- 마스터 데이터가 먼저, 세 개의 관문: SKU 중복 제거, 카테고리 필드 채우기, 존 코드 통일. 이걸 건너뛰면 이후의 모든 것은 연극입니다.
- 질문 가능한 차원을 화이트리스트로: 처음엔 세 개에서 다섯 개. 첫날부터 전부 열지 마세요.
- 유의어 맵은 손으로 만드세요: 현장 슈퍼바이저와 앉아서 슬랭 하나하나를 시스템 코드에 매핑하세요. 하루 작업. 충분히 가치 있습니다.
- 확인은 필수: 시스템이 "이렇게 이해했습니다"라고 밝히고, 숫자가 나오기 전에 사용자가 확인합니다. 그게 마찰이 너무 크다고 느껴지면, 그 기능은 출시하지 마세요.
- 먼저 읽기 전용: 파일럿은 조회만 합니다. 절대 쓰지 않습니다. 모델이 잔액을 조정하거나 재고 상태를 바꾸게 한다고요? 그 실패를 세 번 봤습니다. 네 번째는 보고 싶지 않습니다.
- 모든 것을 계측하세요: 각 질문, 시스템의 해석, 사용자가 수정했는지, 수정 내용이 무엇인지 로그에 남기세요. 석 달 뒤, 그 로그는 매핑 테이블 개선의 금광이 됩니다.
- "오답" 폴백을 정의하세요: 조회가 틀렸을 때 시정 프로세스는 무엇이고 책임자는 누구인지. 운영 시작 후가 아니라 전에, 껄끄러운 건 미리 합의해 두세요.
직관에 반하는 부분입니다. 사람들이 묻습니다, "99% 정확도에 도달할 수 있나요?" 제 답: 질문이 틀렸습니다. 정확도의 천장은 모델이 정하지 않습니다. 마스터 데이터가 얼마나 깨끗한지가 정합니다. 마스터 데이터가 엉망이면 모델은 자신만만한 답을 지어내는 인턴이고, 마스터 데이터가 깨끗하면 빠르게 세는 베테랑입니다. 먼저 마스터 데이터를 정리하고, 그 다음에 자연어 이야기를 하세요. 그건 기술의 문제가 아니라 순서의 문제입니다.
원래 질문으로 돌아가죠. 자연어 재고 조회의 정확도는 이제 충분한가요? 모델에 달린 게 아닙니다. 세 가지에 달렸습니다. 어휘가 정의되어 있는지, 확인 절차가 자리 잡았는지, 마스터 데이터가 깨끗한지. 셋 다 갖춰지면 — 진행하세요. 하나라도 빠지면 — 먼저 숙제를 하세요.
Lin Xiao, WMS 구축 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
