식품 MES 데이터 품질과 AI 모델 붕괴 — 좋은 알고리즘보다 좋은 원천 데이터가 먼저다
정교한 AI 모델도 MES의 작은 Transaction이 틀리면 무너진다(GIGO). 수기 입력·센서 Drift·BOM 불일치·시간축 어긋남을 Quality at Source로 막고 Lineage로 설명 가능하게 만드는 법.
식품공장에 AI를 도입한 뒤 몇 달 지나 다시 엑셀과 작업자 경험에 의존하는 경우가 있다. 알고리즘이 부족해서만은 아니다.
수율예측 모델에 들어가는 실제 투입량이 틀리고, 설비 이상탐지 모델의 센서 Timestamp가 생산 Batch와 맞지 않으며, 수요예측에 사용한 재고 데이터가 실물과 다르면 모델이 아무리 정교해도 안정적인 결과를 만들 수 없다.
이것이 Garbage In, Garbage Out, GIGO다. 제조 AI의 실패는 AI 모델에서 시작되는 것이 아니라 MES의 가장 작은 Transaction에서 시작되는 경우가 많다.
데이터가 많다는 것과 학습 가능한 데이터가 많다는 것은 다르다
MES가 하루에 수백만 건의 데이터를 만들고 있다고 해서 AI 준비가 끝난 것은 아니다. 같은 설비가 서로 다른 이름으로 등록돼 있고, Batch 번호가 없는 센서데이터가 쌓이며, 작업자가 생산이 끝난 뒤 투입량을 한꺼번에 입력했다면 데이터량은 많아도 Context가 없다.
AI가 필요한 것은 단순한 숫자의 집합이 아니다.
언제/어느 설비에서/어떤 제품을어떤 원료 Lot로/어떤 공정조건에서
생산했는지를 연결할 수 있는 데이터다. 그래서 식품 제조 AI의 출발점은 Big Data가 아니라 Master Data와 Transaction Integrity다.
첫 번째 오염원은 작업자의 수기 입력이다
생산이 바쁜 시간에는 현장에서 데이터 입력이 뒤로 밀린다. Batch가 끝난 뒤 작업자가 기억을 더듬어 생산량, 원료투입량, 비가동시간, Loss를 입력한다. 이때 가장 먼저 왜곡되는 것이 Timestamp다.
실제 원료투입은 09시 12분에 발생했지만 MES에는 11시 40분에 입력될 수 있다. 수율분석에서는 큰 문제가 없어 보일 수 있다. 하지만 온도, 압력, 설비 Current와 함께 AI 모델을 학습시키면 문제가 발생한다. 모델은 11시 40분의 설비상태가 해당 원료투입과 연관돼 있다고 학습할 수 있다. 값 자체보다 사건의 시간적 관계가 틀어진 것이 더 위험하다.
수기 데이터에는 ’0’과 ’미입력’을 구분해야 한다
공정 Loss가 0kg이라는 것과 작업자가 Loss를 입력하지 않았다는 것은 전혀 다른 의미다. 그런데 엑셀이나 단순 MES에서는 두 경우가 모두 0으로 저장되는 경우가 있다. AI에서는 이것이 정상 생산으로 학습된다. 따라서 Data Model에서 다음을 구분해야 한다.
0/NULLNot Measured/Not Applicable
Data Quality는 숫자를 채우는 문제가 아니라 값의 의미를 유지하는 문제다.
두 번째 오염원은 센서 Noise와 Drift다
식품공장은 센서에 좋은 환경이 아니다. 고온, 고습, 스팀, 세척수, 진동, 원료 부착이 반복된다. 저울은 Zero Point가 이동할 수 있고 온도센서는 Calibration Drift가 생길 수 있다. 압력센서에는 순간적인 Spike가 발생할 수 있다.
이 데이터를 그대로 AI 모델에 넣으면 센서 이상을 공정 이상으로 학습할 수 있다. 반대로 실제 이상 신호를 Noise로 간주해 제거하면 중요한 Failure Pattern을 잃는다.
Outlier는 삭제할 데이터가 아니라 먼저 분류할 데이터다
온도가 평소 80℃인데 순간적으로 110℃가 기록됐다고 하자. 센서 오류일 수 있다. 하지만 실제 Steam Valve가 비정상 동작한 것일 수도 있다. 그래서 단순한 3 Sigma 초과값 삭제 같은 방식은 위험하다. 먼저 다음을 함께 확인해야 한다.
- 센서 상태 / 인접 센서값
- 설비 Event / PLC Alarm / Calibration History
그 결과 명백한 Measurement Error라면 보정하거나 제외할 수 있다. 실제 공정 이상이라면 그 값은 오히려 가장 중요한 학습데이터다.
세 번째 오염원은 BOM과 실제 투입의 불일치다
Standard BOM에는 설탕 20kg이 등록돼 있다. 현장에서는 원료 당도가 낮아 23kg을 투입했다. MES에는 실제투입이 기록되지 않았고 ERP는 BOM 기준으로 20kg만 차감했다. 그러면 AI가 보는 세계에서는 20kg을 투입하고 정상 품질이 나온 Batch가 된다. 실제 세계에서는 23kg을 사용했다.
이런 데이터로 Recipe Optimization 모델을 학습하면 잘못된 상관관계를 만들 수 있다. BOM Precision과 Actual Consumption 데이터가 AI보다 먼저 필요한 이유다.
원료 대체는 더 큰 문제를 만든다
같은 품목코드로 관리하더라도 공급사와 Lot에 따라 수분함량, 당도, 점도, 지방함량이 달라질 수 있다. 하지만 MES에 Material Lot Context가 없다면 AI는 모든 원료를 동일한 재료로 인식한다. 실제로는 원료 특성 변화 때문에 Yield가 떨어졌는데 모델은 설비속도나 작업자를 원인으로 볼 수 있다.
따라서 Material Code만으로는 부족하다. 필요한 경우 Vendor / Lot / Specification / CoA Result까지 연결해야 한다.
네 번째 오염원은 시스템 간 시간축 불일치다
PLC는 밀리초 단위 Timestamp를 사용한다. MES는 초 또는 분 단위다. ERP는 생산완료 시점에 한 번만 데이터를 받는다. 작업자 태블릿의 시각이 3분 늦을 수도 있다.
이 상태에서 데이터를 Join하면 동일 Batch의 사건순서가 뒤섞일 수 있다. 특히 Predictive Maintenance나 품질예측 모델은 시간관계가 중요하다. 공정조건 변화 → 설비신호 변화 → 품질이상 순서가 뒤바뀌면 모델도 잘못된 인과관계를 학습한다.
Clock Synchronization은 사소한 IT 설정이 아니다
PLC, Edge Gateway, MES Server, Database, 작업자 단말 모두 동일한 시간기준을 사용하도록 관리해야 한다. 또 Source Timestamp와 Ingestion Timestamp를 분리하는 것이 좋다.
예를 들어 센서가 10시 01분에 측정했지만 네트워크 장애로 10시 06분에 서버에 도착했다면 Event Time = 10:01, Ingest Time = 10:06을 둘 다 남겨야 한다. 그래야 지연전송을 공정이벤트로 오인하지 않는다.
사후 Data Cleaning만으로는 근본 문제가 해결되지 않는다
AI 프로젝트가 시작되면 데이터팀이 과거 데이터를 정제한다. 중복값을 제거하고 누락값을 보간하며 이상치를 삭제한다. 필요한 작업이다. 그러나 현장의 데이터 생성방식이 그대로라면 다음 달부터 같은 문제가 다시 생긴다.
그래서 제조 데이터 품질은 Cleaning after Collection보다 Quality at Source로 전환해야 한다. 오류가 DB에 들어온 뒤 고치는 것이 아니라 잘못된 Transaction이 발생하기 어렵게 설계하는 것이다.
1단계는 Capture를 자동화하는 것이다
원료투입은 키보드보다 Barcode Scan이나 저울 Interface를 우선한다. 생산수량은 작업자의 기억보다 Counter나 Checkweigher 데이터를 활용한다. 설비상태는 생산일보의 수기시간보다 PLC Event를 활용한다.
사람의 입력을 완전히 없애는 것이 목적은 아니다. 기계가 생성할 수 있는 데이터까지 사람이 다시 입력하지 않도록 하는 것이 핵심이다. Production Log Standardization이 AI Infrastructure와 연결되는 지점이다.
2단계는 Edge에서 잘못된 입력을 막는 것이다
MES는 단순 기록창이 아니라 Validation Layer가 돼야 한다. 예를 들어 Batch Recipe에 등록되지 않은 원료를 Scan하면 투입을 거부한다. 소비기한이 지난 Lot도 차단한다. 저울값이 허용범위를 벗어나면 Supervisor Approval을 요구할 수 있다. 설비센서가 물리적으로 가능한 범위를 벗어난 값을 보내면 Invalid Sensor State로 Flag할 수 있다. 이것이 Edge Interlock이다.
Validation Rule과 품질규격은 구분해야 한다
온도센서가 -999℃를 보낸다면 센서 오류로 판단할 수 있다. 하지만 기준온도 85℃인 공정에서 82℃가 나온 것은 Invalid Data가 아니다. 유효한 데이터로 기록된 공정이탈이다.
따라서 Data Validity와 Process Conformance를 같은 Rule로 처리하면 안 된다. 첫 번째는 데이터 품질 문제이고 두 번째는 제조품질 문제다.
3단계는 Cleaning보다 Validation과 Flagging이다
실시간 파이프라인에서는 다음을 감지할 수 있다.
- Missing / Duplicate / Out-of-order
- Sensor Spike / Drift / Unit Mismatch
하지만 원본데이터는 가능한 한 보존하는 편이 좋다. Raw Layer에는 원본을 저장하고, Clean Layer에 검증된 데이터를 만들 수 있다. AI는 목적에 따라 Clean Dataset을 사용하되 필요하면 Raw Data까지 추적할 수 있어야 한다. 이를 통해 “모델에 들어간 숫자가 어디서 왔는가”를 설명할 수 있다.
4단계가 Lineage와 Audit Trail이다
AI가 특정 Batch를 불량위험 82%로 판단했다고 하자. 그 결과만 저장하면 나중에 원인을 검증하기 어렵다. 최소한 다음을 추적해야 한다.
- 어떤 데이터 Version / 어떤 Master Revision
- 어떤 Feature / 어떤 Model Version
이것이 Data Lineage다. Audit Trail은 데이터가 누가 언제 어떻게 수정됐는지를 설명하고, Lineage는 그 데이터가 어떤 경로를 거쳐 모델 입력과 결과가 됐는지를 설명한다. 두 기능은 비슷해 보이지만 역할이 다르다.
수기 정제와 Source Governance의 차이는 오류발견 시점이다
| 구분 | 수기·사후 Data Cleaning | MES Source Governance |
|---|---|---|
| 입력 | 작업자 재입력 | Scan/Sensor 우선 |
| Timestamp | 소급 가능 | Event Time 관리 |
| BOM 검증 | 사후 비교 | 투입 Interlock |
| Lot 연결 | 누락 가능 | Scan 강제 |
| Sensor Noise | 사후 삭제 | 상태 Flag/Validation |
| Outlier | 일괄 제거 | 원인별 분류 |
| Master Revision | 추적 어려움 | Version Binding |
| 수정이력 | 불명확 | Audit Trail |
| AI Dataset | 프로젝트별 생성 | Governed Pipeline |
| 오류 발견 | 분석 단계 | 발생 시점 |
데이터 품질은 Accuracy 하나로 평가할 수 없다
제조 데이터에서는 여러 차원을 봐야 한다.
- Accuracy — 실제값과 맞는가
- Completeness — 필요한 값이 빠지지 않았는가
- Consistency — ERP, MES, QMS의 동일 정보가 일치하는가
- Timeliness — 필요한 시점에 기록됐는가
- Uniqueness — 동일 Transaction이 중복되지 않았는가
- Traceability — 원본까지 역추적할 수 있는가
AI 학습 데이터는 이 조건들을 동시에 만족해야 한다.
모델이 갑자기 나빠졌다면 Model Drift만 의심하면 안 된다
예측오차가 최근 급증했다고 하자.
- 시장이 변해서 Concept Drift가 발생했을 수 있다.
- 센서를 교체하면서 Calibration Range가 달라졌을 수도 있다.
- BOM Revision이 바뀌었는데 AI Feature에는 반영되지 않았을 수도 있다.
- 작업자 입력화면을 개편하면서 Null 처리방식이 바뀌었을 수도 있다.
즉 모델성능 저하는 Model Problem뿐 아니라 Upstream Data Problem일 수 있다. 따라서 AI Monitoring에는 Data Drift와 Data Quality KPI가 함께 들어가야 한다.
Predictive Maintenance에서도 같은 원칙이 적용된다
진동센서 데이터가 쌓여 있다고 예지보전 AI가 바로 가능한 것은 아니다. 어느 Motor, 어느 Bearing, 어느 부하조건, 어느 제품생산 중 발생한 신호인지 알아야 한다.
설비 교체나 Overhaul 이후 Baseline이 달라지면 Model Revision도 검토해야 한다. 따라서 Predictive Maintenance 데이터 역시 Asset Master와 4M 변경이력에 연결돼야 한다.
AI용 데이터와 법정 기록을 무리하게 하나로 만들 필요도 없다
CCP 기록은 규제·품질 증빙이 목적이다. AI Feature Store는 모델학습이 목적이다. 둘은 연결돼야 하지만 저장구조와 보존정책까지 동일할 필요는 없다.
HACCP 원본기록은 변경이력과 함께 보존하고, AI에서는 필요한 Feature를 별도 생성할 수 있다. 중요한 것은 Feature가 어느 원본기록에서 만들어졌는지를 추적할 수 있는 것이다.
Data Governance는 IT팀만의 프로젝트가 아니다
BOM의 Owner는 생산·R&D일 수 있고, 품질 Spec의 Owner는 QA다. Vendor Master는 구매팀이, 설비 Master는 생산기술팀이 관리할 수 있다. IT팀은 시스템을 운영하지만 데이터의 업무적 의미까지 결정할 수는 없다. 따라서 Master마다 다음을 정해야 한다.
- Data Owner / Approver
- Change Rule / Effective Date
이것이 제조 Data Governance의 실체다.
AI 프로젝트의 첫 KPI는 정확도가 아닐 수도 있다
초기에는 Model Accuracy보다 다음을 먼저 관리하는 편이 낫다.
- Barcode Scan Compliance / Missing Rate
- Timestamp Error Rate / BOM-Actual Variance
- Lot Mapping Completion Rate / Sensor Validity Rate
이 지표가 안정되지 않은 상태에서 AI Accuracy를 높이는 작업은 불안정한 기초 위에서 모델을 계속 튜닝하는 것과 같다.
제조 AI는 네 단계의 데이터 파이프라인 위에서 작동해야 한다
현실적인 구조는 다음과 같다.
Physical Event → MES/Edge Capture → Validation & Context Binding → Governed Data Layer → AI Feature / Model
온도 82℃라는 숫자가 들어왔다는 사실만으로 끝나지 않는다. 어느 설비, 어느 Batch, 어느 제품, 어느 Recipe Revision, 어느 시각에서 발생했는지 붙여야 한다. 그래야 숫자가 제조정보가 된다.
좋은 데이터는 많이 정제한 데이터가 아니라 설명 가능한 데이터다
AI 모델이 틀렸을 때 원인을 추적할 수 있어야 한다.
- 원료 데이터가 잘못됐는지 / Sensor Drift인지
- Master Revision이 달라졌는지 / Model 자체가 Drift했는지
구분할 수 있어야 한다. 그렇지 않으면 현장은 AI 결과를 믿지 않게 된다. 한두 번 잘못된 생산지시가 내려가면 작업자는 결국 시스템 화면을 무시하고 자신의 경험으로 돌아간다.
제조 AI의 신뢰성은 모델의 복잡도보다 데이터가 만들어지는 순간의 통제수준에서 결정된다.
생산일보 표준화가 Transaction을 만들고, Smart Quality Systems가 변경이력을 남기며, Predictive Maintenance가 시계열 Context를 축적한다. 이 세 층이 연결돼야 AI가 식품공장의 실제 공정을 학습할 수 있다.
제조업 AI 자동화 — 어디서부터 시작하나
AI · 자동화3분 만에 확인
글 · Michael Han
(주)단지 대표(식품제조, 2016~) · VSL Vietnam MD · ISO 9001·14001·45001 인증심사원.저자 소개 →
최종 검증:
개정 이력
· 발행
여기 담긴 규정·수치는 최소 6개월마다 위 공식 출처와 대조해 재확인합니다. 실질적 변경(요건·기준·수치)은 조용히 덮어쓰지 않고 개정 이력에 남깁니다.
이 글은 일반적인 실무 정보이며 법률·세무·행정 자문이 아닙니다. 규정·수치는 관할과 시점에 따라 달라지므로, 실제 판단 전 위 공식 출처와 관할 기관에서 최신 기준을 확인하시기 바랍니다.