결론부터 말하자면, 창고 비전 AI가 배포 후 정확도를 잃을 때 모델이 진짜 문제인 경우는 거의 없다. 진짜 문제는 모델을 둘러싼 모든 것이다 — 빛, 카메라, 데이터, 그리고 새 버전을 내보내는 방식이다.
나는 이 장면을 너무 많이 봐왔다. 벤더가 노트북으로 데모를 한다. 학습 데이터 정확도 99%, 프로젝터에는 예쁜 차트가 뜨고, 방 안의 모두가 박수를 친다. 가동 두 달 후, 현장 정확도는 90% 초반으로 떨어지고, 작업자들은 모든 주문을 수동으로 재검수하고 있으며, 상사는 돈이 어디로 갔는지 알고 싶어한다. 벤더는 어깨를 으쓱한다. "현장의 조건이 바뀌었습니다."
학습 데이터 정확도는 참고서 없는 시험이다. 운영은 참고서 있는 시험인데, 누군가가 계속 조명을 껐다 켰다 한다.
근본 원인을 하나씩 살펴보자. 첫째: 빛이다. 창고의 빛은 결코 가만히 있지 않는다. 도크 문이 열리면 햇빛이 컨베이어를 비춘다. 야간 조는 주간 조와 다른 조명 아래에서 일한다. 가을이 되면 태양의 각도가 달라지고, 6월에는 잘 돌아가던 스테이션이 갑자기 글레어투성이가 된다. 나는 공개된 사례 하나를 잘 기억한다. Jetson Orin 하드웨어 기반 비전 검사 시스템이 랩에서 99.8%를 기록했는데, 배포 후 오탐이 15–20%로 치솟았다 — 원인은 창문으로 쏟아지는 햇빛으로, 금속 부품의 반사가 불량처럼 보인 것이었다. 골판지, 테이프, 스트레치 필름 — 창고의 표면은 모두 거울이다. 이건 누구도 피해갈 수 없다.
둘째: 카메라가 움직인다. 지게차가 마운팅 브래킷을 건드려 각도가 몇 도 틀어진다. 세 달 동안 렌즈에 먼지가 쌓인다. 컨베이어 진동으로 이미지가 번진다. 몇 도쯤은 사소해 보이지만, 위치 파악이나 계수를 하는 모델에게 새 각도는 사실상 새 데이터셋이다.
셋째: 상품이 바뀐다. 새 SKU가 들어오고, 브랜드가 박스 색상을 바꾸고, 로고가 리뉴얼되고, 스트레치 필름이 투명에서 검은색으로 바뀐다 — 학습 데이터에는 하나도 없다. 넷째는 더 교묘하다. 운영 환경의 전처리가 학습 때와 일치하지 않는 것이다. 모델은 정규화된 이미지로 학습했는데, 엔지니어가 몇 밀리초의 지연을 줄이려고 정규화 단계를 건너뛰었다. 이런 학습-서빙 스큐(training-serving skew)는 에러를 하나도 내지 않는다. 그저 조용히 정확도를 갉아먹을 뿐이다.
다섯째는 알고리즘 팀조차 많이 놓치는 것이다. 라벨 자체가 드리프트한다. 같은 품질 검사팀도 "이 긁힘이 불량인가"의 판단이 1월과 7월에 다르다. 모델은 움직이는 표적에서 학습하고 있다.
한 줄로 정리하자면 이렇다. 모델이 나빠진 게 아니다. 세상이 바뀌었다. 그리고 대부분의 창고 비전 배포는 바뀌는 세상에 전혀 대비가 안 돼 있다.
모델도 슬로팅처럼 버전을 관리하라
보기 흉한 습관부터 고치자. 너무 많은 프로젝트에서 모델 관리는 model_final_v2_real_final.pth가 들어 있는 폴더다. 그걸 학습시킨 데이터셋은? 하이퍼파라미터는? 전처리가 바뀌었나? 아무도 말할 수 없다. 뭔가 깨져서 롤백하고 싶은데 — 정확히 어디로 롤백한다는 말인가?
버전 관리에는 협상 불가 규칙이 하나 있다. 한 번이라도 운영에 나간 모델은 모두 완벽히 재현 가능해야 한다. 버전 번호는 세 가지를 묶어야 한다 — 데이터셋 버전, 코드 버전, 그리고 하이퍼파라미터와 랜덤 시드다. 학습 데이터는 손대지 않는 불변 아티팩트로 스냅샷을 뜬다. 어느 하나라도 빠지면, 뭔가 깨진 날 어떤 링크가 바뀌었는지 추측하는 신세가 된다.
오버엔지니어링 없이 데이터셋 스냅샷을 뜨는 법은? 간단하다. 매 학습 실행마다 학습 세트의 파일 목록과 해시값을 저장하고, 샘플링 비율과 증강 방법을 학습 로그에 기록한다. "이 버전이 정확히 무엇으로 학습됐나"라는 질문에 3분 안에 답할 수 있으면 합격이다. 답하지 못하는 팀은 미신으로 디버깅하게 된다.
두 번째 생존 조건은 롤백이다. 비전 모델 반복의 표준은 원클릭 롤백이다. 잘못된 새 버전은 몇 분 안에 마지막 안정 버전으로 교체된다 — 재학습 없이, 코드 변경 없이. 이게 안 되면 반복을 말하지 마라. 정확도가 무너진 공포의 사례들을 보라. 재앙의 정체는 "새 버전이 나빴다"가 아니라 "새 버전이 나빴는데 돌아갈 길이 없었다"인 경우가 많다. 그래서 현장은 깨진 모델로 몇 주를 돌았다.
다음은 배포 전략의 결정인데, 내 결론을 바로 말하겠다. 업계 표준 세 가지 패턴: 섀도우 모드, 카나리 배포, 블루-그린 배포. 섀도우 모드는 새 모델을 기존 모델과 나란히 실 트래픽으로 돌린다 — 새 모델의 출력은 기록되지만 실제로 사용되지는 않는다. 리스크는 제로, "이 모델이 실 트래픽에서 어떻게 동작하는가"에 답하기 위한 전용 수단이다. 카나리 배포는 새 모델이 실 트래픽의 일부 — 예컨대 1주일간 5% — 를 처리하게 하고, 문제없으면 20%, 50%, 100%처럼 단계적으로 올린다. 영향 범위를 작게 유지한다. 블루-그린 배포는 두 개의 완전한 환경을 순간적으로 전환하는 방식이며, 카메라 모델 변경이나 전처리 대수술 같은 "전환해야만 하는" 순간에 맞다.
창고 비전에 대한 내 추천은 이렇다. 표준 경로는 섀도우 2주, 그 다음 카나리 램프업이다. 섀도우를 건너뛰고 카나리로 직행하지 마라 — 카나리가 처리하는 주문은 모두 진짜 비즈니스이며, 품질 검사 오판 하나가 오배송 하나가 된다. 섀도우의 잘못된 예측은 로그의 한 줄일 뿐이다. 순서가 중요하다.
그 섀도우 2주도 노는 기간이 아니다. 세 가지 숫자를 본다. 새 모델과 기존 모델의 불일치율, 불일치가 몰리는 SKU, 그리고 고신뢰도 샘플에서 새 모델이 확실히 더 안정적인지다. 불일치율이 높게 유지되는데도 카나리로 밀고 나가면 눈을 가리고 비행하는 것이다. 카나리 중에는 기술 지표뿐 아니라 비즈니스 지표를 본다. 수동 재검수 시간이 줄었는가, 오배송률이 움직였는가. 기술 지표는 좋은데 비즈니스 지표가 평탄한 업그레이드는 업그레이드가 아니다. 그냥 변경일 뿐이다.
알람이 너무 많은 건 알람이 없는 것과 같다
가동 후에는 두 번째 전장이 온다. 모니터링이다. 많은 프로젝트가 가동일에 정점을 찍는다. 모델이 썩기 시작했다는 걸 아무도 눈치채지 못하기 때문이다. 운영팀이 이상함을 느끼고 나면, 모델은 이미 두 달째 성능이 떨어지고 있다.
먼저 올바른 지표를 봐야 한다. 오탐율과 미탐율은 따로 추적해야 한다. 태우는 돈의 종류가 다르기 때문이다. 오탐은 인건비를 태운다. 모델이 없는 문제를 지적하고, 지적된 주문은 모두 누군가 손을 멈추고 재검수한다. 오탐율을 충분히 높이면 작업자들은 시스템을 무시하기 시작한다 — AI 투자는 태어나자마자 죽는다. 미탐은 진짜 현금을 태운다. 불량품이 빠져나가 고객에게 배송되고, 반품과 차지백이 된다. "전체 정확도"만 보여주는 대시보드는 자기기만이다. 정확도 95%인 모델은 오탐 2.5% + 미탐 2.5%일 수도 있고, 4.5%와 0.5%일 수도 있다. 이건 완전히 다른 두 비즈니스다.
"고장났다"의 네 가지 종류도 구분해야 한다. 데이터 드리프트(입력이 바뀌었다 — 조명, 새 포장), 예측 드리프트(모델의 출력 분포가 바뀌었다), 개념 드리프트(입력과 답의 관계 자체가 바뀌었다 — 예컨대 품질 기준이 강화됐다), 그리고 단순한 엔지니어링 버그(피처 파이프라인이 죽었다)다. 원인이 다르면 처방도 다르다. 정확도가 떨어진 순간 "데이터를 더 넣고 재학습"으로 달려드는 것은 열 번 중 아홉은 엉뚱한 병을 치료하는 것이다. 카메라가 기울어져 있으면 백 번 재학습해도 소용없다.
마지막으로 알람 피로다. 가장 흔한 죽음 방식이라 따로 언급한다. 임계값을 너무 느슨하게 잡으면 썩어가는 모델이 아무에게도 알람을 울리지 않는다. 너무 빡빡하게 잡으면 담당자는 하루에 수십 개의 알람을 받고 읽기 전에 일괄 무시하기 시작한다. 내 경험으로는 알람은 두 단계, 그 이상은 없다. 1단계: 정확도가 기준선을 밑돌았다. 오늘 처리한다. 2단계: 추세가 악화되고 있다. 이번 주에 본다. 두 단계가 넘는 알람 설계는 사실상 알람 설계가 없는 것과 같다.
끝맺음에 거창한 이론은 없다. 내일 당장 할 수 있는 한 가지만.
오늘부터 시스템이 운영 이미지를 저장하게 하고, 매일 100장을 랜덤으로 뽑아 사람이 재검수하고, 오탐과 미탐이 몇 건이었는지 기록하자. 2주 동안 이어가면, 이 프로젝트 전체에서 가장 가치 있는 자산을 얻게 된다. 현장에서 나온 진짜 정확도 곡선이다. 버전 관리도, 카나리 배포도, 알람 임계값도, 모두 이 곡선이 있어야 돌아간다. 이게 없으면 조정하는 파라미터는 전부 추측이다.
이 업계에서 이기는 팀은 가장 정확한 모델을 가진 팀이 아니다. 자기 모델이 정확하지 않게 된 걸 가장 먼저 아는 팀이다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
