지난 가을, 나는 인랜드 엠파이어의 한 3PL 창고(약 120,000평방피트)를 컨설팅하고 있었다. 거기서는 AI 보충 예측 모델을 막 도입한 참이었다. 인수 확인서에는 서명했고, 벤더 팀은 3주 차에 떠났다. 그리고 96일째, 창고 매니저에게서 전화가 왔다. "라오 미, 시스템이 고장 난 것 같습니다. 보충 제안이 매주 점점 더 엉뚱해지고 있어요."
나는 세 가지 질문을 했다. 지난주 모델 예측 정확도는 얼마였는가? 그는 몰랐다. 알림 이메일은 어디로 가는가? 확인하러 갔다――그리고 벤더 프로젝트 팀이 만들어 둔 메일함으로 아직도 가고 있다는 것을 알게 됐다. 그 팀은 두 달 전에 해산됐다. 알림은 아무도 열지 않는 받은편지함에 쌓이고 있었다. 세 번째 질문: 드리프트 임계값은 누가 정했는가? 전화기 너머는 침묵이었다.
이건 특별한 이야기가 아니다. 지난 몇 년 동안 같은 방식으로 죽어가는 AI 프로젝트를 여러 개 봤다. 선정 단계에서도, 개발 단계에서도 아니라 Go-Live 후 3개월 동안 죽는다. 장비를 인수할 때 지게차가 스스로 차선을 바꾸지는 않는다. AI는 다르다. 매일 새로운 데이터를 먹고, 데이터가 바뀌면 모델도 함께 바뀐다. 아무도 지켜보지 않으면, 3개월 후 당신이 '소유'하고 있는 'AI 시스템'은 더 이상 당신이 서명한 그것이 아니다.
Go-Live 당일은 프로젝트에서 가장 위험한 날이다
직관에 반하는 시각을 하나 제시하자. AI 프로젝트에서 인수 서명은 끝이 아니라 시작이다.
인수 테스트는 정적인 조건에서 이뤄진다. 데이터는 벤더가 미리 깨끗이 손질했고, 테스트 세트는 엄선됐고, 시즌 믹스는 손으로 골랐다. 인수 지표를 좋게 보이고 싶은 건 당연하다――최종 대금이 걸려 있으니까. 부정직한 게 아니라, 인간의 본성이다.
하지만 실제 데이터가 흐르기 시작하면 모든 것이 바뀐다. 신규 고객이 새로운 주문 패턴을 들고 온다. SKU 믹스가 바뀐다. 포장 사양이 바뀐다. 성수기와 비수기가 뒤집힌다. 이게 바로 학습 때 모델이 한 번도 본 적 없는 '지저분한 데이터'다. 어느 창고는 인수 때 예측 정확도 92%에서 두 달 후 78%로 떨어지는 걸 나는 지켜봤다. 근본 원인은 거의 웃길 지경이었다. 학습 데이터에 Q4 성수기 SKU 조합이 없어서, 성수기가 시작되자 모델이 마구잡이 추측을 시작한 것이었다.
그래서 내 결론은 직설적이다. 인수 기준에는 90일 재테스트 조항을 넣어야 한다. 서명은 두 번――Go-Live 때 시스템이 돌아가고 있음을 확인하는 서명과, 90일째에 실제 데이터를 상대로도 모델이 버티고 있음을 확인하는 서명. 두 번째 테스트에 떨어지면 최종 대금은 테이블 위에 그대로 두고, 벤더가 돌아와서 튜닝한다. 계약서의 한 조항이 인수 당일의 열 가지 추가 지표보다 낫다.
이걸 요구하기를 두려워하는 바이어가 많다. 벤더가 불신으로 받아들일까 걱정한다. 나는 반대로 본다. 그 조항에 서명할 수 있는 벤더는 자사 모델을 진짜로 믿는 벤더다.
모델은 갑자기 죽지 않는다. 천천히 바보가 된다.
이게 AI 운영과 전통적인 IT 운영의 가장 큰 차이다. 서버 다운은 갑작스럽다――알람이 울리고 모두가 안다. 모델 드리프트는 만성 질환이다. 오늘 조금 나빠지고, 내일 조금 나빠지고, 3개월 후에는 조용히 쓸모없어졌다는 걸 깨닫는다.
드리프트는 쉽게 말해 두 종류다. 첫째, 데이터가 바뀌었다. 예전에는 하루 8,000건을 출고했는데, 지금은 12,000건이다. 고객 A가 예전에는 물량의 60%를 차지했는데, 이제는 고객 B가 지배적이다. 모델은 옛 데이터의 패턴을 학습했는데, 새 데이터는 그 패턴을 따르지 않는다. 둘째, 관계가 바뀌었다. '주말은 바쁘다'가 예전에는 맞았는데, 고객의 주문 습관이 바뀌고 주말은 조용해졌다. 데이터 자체는 똑같아 보이는데, 데이터의 '의미'가 이동한 것이다.
무서운 건 드리프트 자체가 아니라――아무도 지켜보지 않는다는 점이다. 인랜드 엠파이어 창고에서는 시스템이 몇 주째 알림을 보내고 있었다. 드리프트 지표는 이미 임계값을 넘었다. 하지만 알림은 아무도 읽지 않는 받은편지함으로 가고 있었다. 알림이 없는 것과 마찬가지다. 이것이 내가 말하는 운영 공백이다. 시스템은 말하고 있는데, 아무도 듣지 않는다.
어떻게 메울 것인가. 책임 분담표는 인수 전에 정해야 하고, 실명으로 적어야 한다――'고객의 책임'은 통하지 않는다. 나는 3개 층을 권장한다.
창고 오퍼레이션은 매일 업무 지표를 본다. 예측 품질을 누구보다 빨리 몸으로 느끼는 건 오퍼레이션이다――보충 제안이 말이 안 되면 피커가 가장 먼저 불평한다. 간단한 규칙 하나를 줘라. 제안 수량이 현실과 3일 연속 일정 비율 이상 벗어나면 에스컬레이션한다. 알고리즘 지식은 필요 없다. 숫자만 읽으면 된다.
IT――또는 벤더――는 매주 모델 지표를 본다. 드리프트 스코어, 피처 분포, 예측 신뢰도. 무엇을 보고 있는지 아는 사람이 필요하다. 사내에 그런 사람이 없으면 계약에 벤더의 원격 모델 지원을 넣어라. 분기 청구는 괜찮다. 여기서 아끼지 마라. 생략하면 이미 쓴 수십만 달러가 물거품이 될 수 있다.
경영진은 매달 추세를 리뷰한다. 정확도 곡선은 올라가는가 내려가는가? 재학습에 얼마가 들었고, 본전은 뽑았는가? 30분이면 충분하지만, 회의는 열어야 한다. 안 그러면 분기 리뷰에서 모델이 3개월째 고장 나 있었다는 걸 알게 된다. 너무 늦다.
드리프트 임계값은 누가 정하는가? 내 답은 이렇다. 벤더가 제안하고, 바이어가 결정한다. 벤더는 모델을 알고, 정상 변동이 무엇인지 안다. 바이어는 비즈니스를 알고, 어느 정도의 오류가 용납 안 되는지 안다. 함께 정하고, SOP에 쓰고, 벽에 붙여라.
계약에 없는 인계는, 없었던 일이다
이건 내가 빠진 가장 깊은 함정이다. 어느 창고의 AI 외관 검사 프로젝트에서는 계약서에 '벤더는 교육을 제공한다'고 적혀 있었다. 인수 전에 벤더는 실제로 교육을 제공했다――2시간짜리 슬라이드였다. 3개월 후 모델이 문제를 일으켰는데, 운영 엔지니어는 피처 파이프라인이 어디에 있는지도 몰랐다. 데이터가 어떤 테이블에서 오는지, 모델 파일이 어느 서버에 있는지――세 가지 질문에 답은 제로였다. 벤더에 전화했다. 프로젝트 팀은 사라졌다. 지원 담당자는 '유료 지원 티켓을 열 수 있다'고 했다.
그래서 나는 이제 바이어에게 인수 서명 전에 인계 체크리스트를 항목별로 확인하게 한다. 네 가지다. 하나라도 빠지면 서명하지 마라.
첫째, 모델 문서. 피처 목록, 학습 데이터의 버전, 모델링의 가정――'SKU 수는 일정하다고 가정'이나 '주문 구조는 안정적이라고 가정' 같은 것들이다. 이 가정들이 미래의 드리프트 경고선이다. 가정이 무너지는 순간 모델은 재학습이 필요하다. 문서는 멋질 필요 없다. 읽을 수 있으면 된다.
둘째, 알림 설정. 알림을 누가 받고, 누가 CC에 들어가고, 어느 주기로 리뷰하고, 누가 에스컬레이션하는지. 이메일 주소를 하나하나 적고, 인수 당일에 테스트 알림을 보내서 도착하는지 확인한다. 웃지 마라――알림 주소의 철자가 틀려서 Go-Live 후에야 발견된 프로젝트를 본 적이 있다.
셋째, 재학습 프로세스. 누가 재학습을 발동하고, 발동 조건이 무엇이며, 누가 실행하고, 누가 돈을 내는지. 재학습은 공짜가 아니다――데이터 준비, 연산, 검증, 전부 돈이 든다. 미리 정하지 않으면 고장 났을 때 양쪽이 책임 떠넘기기를 시작한다. 4개월이나 다툼이 이어진 경우를 봤다. 모델은 4개월 동안 그냥 썩어갔다.
넷째, 롤백 계획. 모델이 말썽을 부릴 때 한 번의 전환으로 구형 규칙 엔진으로 되돌리려면 어떻게 하는가. 스위치는 어디에 있고, 누가 스위치를 돌릴 권한이 있으며, 전환 후 비즈니스는 어떻게 돌아가는가. 이게 가장 자주 빠지지만, 문제가 생기면 목숨을 구해주는 건 바로 이거다.
계약에는 두 조항이 더 필요하다. 팀 철수 후 6개월에서 12개월의 벤더 원격 지원, 응답 시간을 명시한 것. 그리고 데이터 소유권――학습 데이터, 모델 파일, 피처 파이프라인――바이어는 이 모든 것의 완전한 복사본을 받는다. 벤더는 떠나도 된다. 자산은 남는다.
결론을 말하자. AI 프로젝트가 장비 구매와 다른 점은 근본적으로 하나다. 장비는 한 번의 납품이지만, AI는 계속 진화하는 것이다. 당신이 인수하는 건 기계가 아니다. 계속 먹이를 줘야 하는 살아 있는 것이다. 계약에 '누가 먹이를 주는지' 쓰여 있지 않으면, 굶어 죽는 건 시간문제다.
마지막으로 질문 하나를 남기자. 당신의 AI 프로젝트가 내일 Go-Live한다면, 90일째 알림 이메일이 누구의 받은편지함으로 가는지――그리고 그것을 열 책임이 누구에게 있는지 이름을 댈 수 있는가? 대지 못하면 인수 확인서에 아직 서명하지 마라.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
