창고 운영자가 새 AI 워크플로를 보여줄 때마다 내가 먼저 꺼내는 불편한 진실이 있다. 데이터가 거대 모델에 한 번 들어가면 바닥에 쏟아진 물과 같다. 다시 돌려받을 수 없다.
지난 2년간 AI를 현장에 도입하는 창고를 많이 지켜봤다. WMS 출고 데이터를 모델에 던져 넣어 이상 징후를 찾고, 고객 주문 내역을 AI 어시스턴트에 먹여 일일 보고서를 만들고, 피커 실적 시트를 집어넣어 스케줄을 짰다. 성과는 정말 인상적이다. 2시간 걸리던 분석이 몇 분 만에 돌아온다. 하지만 이런 얘기를 들을 때마다 나의 첫 질문은 "얼마나 빨라요?"가 아니라 "그 데이터, 먼저 정리하셨나요?"다.
대부분의 경우 답은 아니오다. 창고 데이터가 해로워 보이지 않기 때문이다. SKU와 상자 수량, 로케이션 번호뿐 아닌가? 틀렸다. 실제 출고 주문 한 건에는 고객사 이름과 배송지 주소, 운송사와 협상한 실제 운송 요금, 피커의 이름과 근무 시간이 숨어 있다. 그것이 어느 공개 모델의 학습 데이터에 들어가는 순간, 당신의 가격 전략은 낯선 사람들 앞에 펼쳐진다. 그리고 2020년부터 시행된 캘리포니아 CCPA도, EU의 GDPR도 "실수였다"는 변명은 들어주지 않는다. 데이터 유출의 청구서는 언제나 데이터를 쥐고 있던 자에게 온다.
그래서 내 결론은 이렇다. AI는 마음껏 쓰되, 창고 데이터가 어떤 AI 도구에 닿기 전에 반드시 세 관문을 통과해야 한다. 비식별화, 접근 통제, 감사다. 하나라도 빼면 도박이다.
첫 번째 관문: 비식별화 — AI가 고객이 누군지 알지 못하게
비식별화란 이름을 별표로 바꾸는 것이라고 생각하는 사람이 많다. 그것만으로는 턱없이 부족하다. 창고 데이터에는 정말로 위험한 필드가 세 종류 있다.
첫째는 고객 식별 정보다. 수하인 회사명, 주소, 전화번호, 이메일이다. 이상 징후 분석이나 일일 보고서에 AI는 화물이 누구에게 가는지 알 필요가 없다. 필요한 건 그 화물뿐이다. 실무적인 해법은 데이터가 외부로 나가기 전에 매핑 테이블을 만들어 실제 고객 ID와 익명 토큰을 연결해 두는 것이다. 매핑을 보관하는 건 내부 시스템뿐이다. AI는 토큰만 본다.
둘째는 영업 비밀이 있다. 운송 요금, 고객 견적가, 운송사 정산가다. 이는 창고 사업의 보물 그 자체다. 한때 캘리포니아의 한 3PL이 1년 치 출고 데이터 — 실제 운송 요금 포함 — 를 AI 도구에 붙여넣고 원가 분석을 한 것을 본 적이 있다. 분석은 훌륭하게 나왔다. 그리고 그 요금은 지금 남의 서버에 살고 있다. 요금 관련 필드는 데이터 흐름에서 완전히 제거하거나 구간으로 묶어야 한다("평균 이상 / 평균 이하"). 있는 그대로 보내는 일은 절대 없다.
셋째는 직원 개인정보다. 이름, 근무 시간, 생산성 점수, 출근 기록이다. 시프트 최적화와 생산성 분석에는 확실히 사람의 데이터를 쓰지만, AI가 봐야 할 건 "스테이션 A의 피킹율"이지 "어제 John이 몇 개 피킹했는지"가 아니다. 직원 ID는 해시한다. 이름은 사외로 나가지 않는다.
여기 솔직히 짚고 넘어갈 트레이드오프가 있다. 비식별화를 강하게 할수록 AI의 분석력은 약해진다. 고객명을 모두 익명화하면 모델은 고객 세분화를 할 수 없다. 나의 경험칙은 데이터의 행선지에 따라 비식별화 강도를 달리하는 것이다. 온프레미스 AI 도구(데이터가 자사 서버를 나가지 않음)라면 가벼운 비식별화로 충분하다. 외부 벤더나 퍼블릭 클라우드 AI 서비스로 가는 건은 강한 비식별화를 적용한다. 안전과 유용성의 균형에 만능 해법은 없다. 핵심은 "데이터가 자사의 경계를 넘느냐"다.
두 번째 관문: 접근 통제 — 이 수도꼭지는 아무나 열 수 없다
비식별화가 정하는 건 AI가 무엇을 볼 수 있느냐다. 접근 통제가 정하는 건 애초에 누가 데이터를 AI에 넘길 수 있느냐다.
내가 본 가장 무서운 구성은 이렇다. WMS 홈 화면에 AI 어시스턴트가 고정돼 있고 누구나 쓸 수 있다. 피커가 주문 스크린샷 — 고객 주소 포함 — 을 붙여넣고 "이건 어떻게 처리하죠?"라고 묻는다. 데이터는 그 순간 사외로 나갔다. AI 도구에 대한 접근은 WMS의 데이터 권한과 일치해야 한다. 시스템에서 요금 필드를 볼 수 없는 사람은 요금 필드를 AI에 넘겨서도 안 된다.
구현은 세 층으로 나눈다. 첫째, 역할 계층이다. 정말 필요한 역할 — 데이터 분석가, 운영 매니저 — 만 AI 도구에서 전체 데이터에 접근할 수 있다. 현장 운영자가 AI 어시스턴트를 쓴다면 데이터 소스가 이미 정제된 미리 만들어진 Q&A 시나리오만 쓴다. 둘째, 데이터 화이트리스트다. 어떤 종류의 데이터를 어떤 목적으로 AI에 넘길 수 있는지 명시한 목록이다. 예를 들어 "허용: 수요 예측을 위한 익명화된 입출고량. 불허: 고객 정보가 포함된 생주문 내역". 셋째, 기술적 체크포인트다. 데이터 출구에 게이트웨이를 둔다. 외부 AI 서비스로 향하는 요청은 모두 스캔해서 고객명, 주소, 요금, 직원명 같은 민감 필드가 있으면 차단하고 플래그를 세운다. 이 게이트웨이가 가장 중요하다. 누구의 선의에도 의존하지 않기 때문이다.
놓치기 쉬운 접근 통제 함정이 하나 더 있다. 벤더 계정이다. 많은 AI 도구가 SaaS이며, 트러블슈팅을 위해 벤더 지원 엔지니어가 일시적인 데이터 접근을 요청할 수 있다. 계약에 명문화해 둬야 한다. 벤더의 접근은 승인을 거쳐, 기한이 정해지고, 감사 가능해야 한다. 사고가 난 뒤에야 "3개월 전에 풀 액세스를 준 채로 아무도 회수하지 않았다"는 걸 알게 되지 않도록.
세 번째 관문: 감사 — 문제가 생기면 설명할 수 있는 이야기가 필요하다
앞의 두 관문은 예방이다. 세 번째 관문은 안전망이다. 만일 문제가 생겼을 때, 누가, 언제, 무슨 데이터를, 어느 AI에, 무슨 목적으로 보냈는지 말할 수 있는가.
기록은 세 종류를 남긴다. 첫째, 데이터 흐름 로그다. 외부 AI 서비스로 향하는 요청은 모두 기록한다. 타임스탬프, 작업자, 데이터 유형, 데이터량, 목적지 서비스. 이 로그는 자사 인프라에 둔다. 벤더의 대시보드에 두지 않는다. 대시보드는 벤더의 것이다. 분쟁이 생겼을 때 "우리 로그는 유효기간이 지났습니다"라는 말 한마디에 아무것도 남지 않는다.
둘째, 데이터에 닿는 모든 AI 벤더와의 데이터 처리 계약이다. DPA에서는 네 가지를 못 박아야 한다. 당신의 데이터는 모델 학습에 사용하지 않는다. 데이터 보유 기간. 삭제 절차. 침해 발생 시 통지 기한. 이 계약에 사인하지 않는 벤더에게는 데이터를 흘려보내선 안 된다. 기능과 가격만 보고 AI 도구를 골라 계약서 페이지를 건너뛰는 팀이 너무 많다. 내가 본 가장 비싼 "절약"이다.
셋째, 분기별 접근 검토다. 분기에 한 번 확인한다. AI 도구 계정이 지금도 재직자의 손에 있는가. 퇴사자의 접근은 회수됐는가. 화이트리스트는 지금도 맞는가. 권한은 재고와 같아서 썩는다. 순환 실사를 빼먹으면 어긋나기 시작한다. 이 검토를 분기 운영 회의 안건에 올려 재고 차이, 안전 점검과 같은 체크리스트에 넣어 두길 권한다. 아무도 잊지 않게 된다.
먼저 관문을 통과하고, 효율은 그다음에 쫓아라
세 관문을 읽고 나면 일이 많아 보일 수 있다. 계산해 보면 다르게 보인다. 고객 데이터 유출 한 건이면 CCPA 벌금과 고객 손해배상을 합쳐 중견 3PL의 연간 이익 전체가 날아갈 수 있다. 비식별화, 접근 통제, 감사 구축은 IT 담당자 한 명과 운영 책임자 한 명이 몇 주면 된다. 어려운 계산이 아니다.
내가 권장하는 순서는 이렇다. 먼저 인벤토리(데이터 안의 민감 필드를 모두 세어내기). 다음 비식별화(매핑 테이블과 필드 규칙 만들기). 다음 접근 잠그기(게이트웨이 + 화이트리스트). 마지막으로 감사로 고리를 닫기(로그, DPA, 분기 검토). 이 네 단계가 끝나면 그다음엔 마음 편히 AI를 써라.
집에 가져갈 질문 하나. 지금 창고에서 쓰는 AI 도구 중에 "데이터가 어디에 저장되는지", "그 데이터가 모델 학습에 쓰이는지"를 솔직히 말할 수 없는 게 있는가. 있다면 조사는 거기서 시작하라.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
