제조 AI 프로젝트가 PoC에서 멈추는 세 가지 이유

제조 AI 프로젝트에서 가장 자주 보는 결말은 실패가 아닙니다. 성공한 PoC가 리포트 한 편으로 남고 끝나는 것입니다.

정확도는 목표를 넘겼고, 데모는 잘 돌아갔고, 보고도 잘 끝났습니다. 그런데 반년이 지나도 그 모델은 라인에 없습니다. 담당자에게 물어보면 대답이 비슷합니다. "그건 잘 됐는데, 그다음이 좀…"

이 "그다음"이 무엇인지, 현장에서 반복해서 본 세 가지를 정리했습니다. 세 가지 모두 모델의 문제가 아니었습니다.

#1. 데이터를 모으던 사람이 PoC에만 있었다

데이터가 없어서 막히는 경우는 드뭅니다. PLC, 진동 센서, 비전 카메라, MES. 공장에는 이미 데이터가 넘칩니다. 문제는 그것들이 서로 다른 시스템에, 서로 다른 형식으로, 서로 다른 주기로 있다는 것입니다.

PoC 단계에서는 이 문제가 잘 드러나지 않습니다. 누군가 몇 주 동안 시간을 내서 CSV를 내려받고, 시각을 맞추고, 엑셀에서 열을 정리해 학습 데이터를 만들기 때문입니다. 대개 그 사람은 프로젝트를 위해 잠깐 투입된 엔지니어입니다.

운영 단계가 되면 그 일을 매일 해야 합니다. 그런데 그 사람은 이미 다른 프로젝트로 옮겨 갔습니다. 남은 현장 담당자에게 그 작업은 원래 자기 일이 아니고, 배운 적도 없습니다. 모델은 틀려서 멈추는 것이 아니라, 먹을 것이 끊겨서 멈춥니다.

이 일이 미뤄지는 이유는 분명합니다. 데이터 연결을 자동화하는 일은 PoC의 성공 기준에 들어가지 않습니다. 정확도는 평가받지만 파이프라인은 평가받지 않으니, 예산과 일정에서 가장 먼저 밀립니다.

#2. PoC 데이터는 좋은 날, 좋은 조건에서 모인다

PoC 데이터는 대체로 깨끗합니다. 깨끗하게 모으려고 애썼기 때문입니다. 설비가 잘 돌아가는 날, 조명이 안정적인 시간대에, 사람이 옆에서 지켜보며 촬영합니다. 이상한 데이터가 섞이면 빼고 다시 찍습니다. 그렇게 만든 데이터셋은 좋은 학습 재료지만, 실제 라인의 하루와는 다릅니다.

실제 라인에서는 계절이 바뀌면 창으로 들어오는 빛이 달라집니다. 같은 모델의 설비라도 개체마다 편차가 있고, 소모품을 교체한 직후와 교체 직전이 다릅니다. 야간 조에서는 조명이 다르고, 주말에는 공조가 꺼집니다.

학습 때 96%였던 정확도가 현장에서 80%로 떨어지는 일은 흔합니다. 여기서 중요한 것은, 이것이 모델이 잘못 만들어졌다는 뜻이 아니라는 점입니다. 모델은 배운 대로 정확히 동작하고 있습니다. 배운 적 없는 조건이 들어왔을 뿐입니다.

그래서 PoC에서 확인해야 할 것은 최고 정확도가 아니라 가장 나쁜 조건에서의 정확도입니다. 야간 조 데이터를 일부러 섞고, 설비를 두 대 이상 쓰고, 몇 주에 걸쳐 데이터를 모으면 숫자는 낮아집니다. 대신 그 숫자는 라인에서 재현됩니다.

#3. 틀리기 시작해도 아무도 모른다

세 번째가 가장 조용하고, 그래서 가장 위험합니다.

모델은 배포하는 순간부터 서서히 어긋납니다. 부품 공급처가 바뀌고, 설비가 노후하고, 공정 파라미터가 조정됩니다. 학습 당시의 데이터 분포와 지금의 분포가 벌어지는 드리프트는 예외가 아니라 기본값입니다.

문제는 모델이 틀릴 때 소리를 내지 않는다는 것입니다. 에러를 뱉지도 않고, 화면이 멈추지도 않습니다. 그냥 조금씩 더 자주 틀린 답을 냅니다. 그동안 현장은 이미 그 판정을 믿기 시작한 뒤입니다. 사람이 이중으로 확인하던 습관은 도입 두어 달이면 사라집니다.

그래서 이 질문에 답이 없으면 아직 운영 준비가 되지 않은 것입니다. 이 모델이 틀리기 시작하면 누가, 언제, 어떻게 알게 되는가.

#세 가지의 공통점

셋을 나란히 놓으면 같은 모양이 보입니다.

PoC는 사람이 떠받쳐서 돌아갑니다. 운영은 사람이 없어도 돌아가야 합니다. 이 차이를 나중에 메우려고 하면 사실상 프로젝트를 다시 시작하는 일이 됩니다.

#그래서 모델보다 파이프라인을 먼저 그립니다

우리는 프로젝트를 시작할 때 모델 구조보다 파이프라인 정의부터 씁니다. 어떤 데이터를 어디서 가져오고, 언제 다시 학습하고, 어디에 배포하고, 무엇을 감시할지를 한 파일에 적습니다.

# 4I-MLOps 파이프라인 정의 예시
pipeline: quality-inspection-line-a
sources:
  - type: vision
    camera: line-a-cam-01
  - type: plc
    tags: [cycle_time, reject_count]
train:
  trigger: drift_detected or weekly
  validation: holdout_by_shift
deploy:
  strategy: rolling
  targets: [edge-line-a-01, edge-line-a-02]
monitor:
  drift: feature_distribution
  alert: slack://quality-team

짧은 파일이지만 앞의 세 가지에 각각 답하고 있습니다. sources 는 데이터를 모으던 사람을 대신하고, validation: holdout_by_shift 는 교대조를 나눠 검증해 좋은 조건만 보고 판단하지 않게 하며, monitor 와 alert 는 틀리기 시작할 때 누가 알게 되는지를 정합니다.

이 파일이 있으면 PoC와 양산의 경계가 흐려집니다. PoC 모델이 그대로 파이프라인에 올라가고, 현장 데이터로 계속 재학습되기 때문입니다.

#정리하면

제조 AI가 PoC에서 멈추는 이유는 대개 기술이 부족해서가 아닙니다. PoC는 사람이 손으로 떠받친 상태의 성공이고, 그 손을 뗐을 때 무엇이 무너지는지를 아무도 확인하지 않았기 때문입니다.

시스템이 되지 못한 AI는 멈춥니다. 4I-MLOps는 이 손을 대신하도록 만든 운영 체계입니다.