식품공장 AI 도입의 올바른 순서 — 알고리즘보다 데이터 구조가 먼저다

식품공장에서 AI 도입이 실패하는 가장 흔한 이유는 알고리즘 성능이 부족해서가 아니다.

제품코드가 부서마다 다르고, BOM이 실제 배합과 맞지 않으며, 원료 Lot가 생산 Batch와 연결되지 않고, 설비 정지시간은 작업자가 퇴근 전에 기억으로 적는다. 이 상태에서 AI 비전검사, 수요예측, 예지보전 모델을 추가하면 결과는 정교해지지 않는다. 오히려 잘못된 데이터를 더 빠르게 계산한다.

제조 AI의 핵심 문제는 모델보다 공장이 실제로 무슨 일이 있었는지를 데이터로 설명할 수 있는가다.

AI를 먼저 넣으면 GIGO가 더 빠르게 발생한다

GIGO, Garbage In Garbage Out은 단순한 IT 문구가 아니다. 식품공장에서 매우 직접적인 문제다.

ERP BOM에는 원료 A가 30kg 투입된다고 되어 있지만 현장에서는 수분함량 때문에 33kg을 넣었다고 하자. MES에는 이 실제 투입량이 기록되지 않는다. AI는 30kg을 기준으로 수율과 원가를 학습한다. 그러면 실제 생산조건과 모델이 알고 있는 생산조건이 달라진다. 모델의 예측오차가 커지는 것이 당연하다.

이 상태에서 모델 정확도를 높이겠다며 더 복잡한 알고리즘을 적용해도 근본적인 문제는 해결되지 않는다.

제조 AI에는 먼저 ‘정답이 무엇인지’ 정의돼 있어야 한다

AI 학습에는 입력값뿐 아니라 무엇이 좋은 결과이고 무엇이 나쁜 결과인지에 대한 Label이 필요하다. 불량품을 예측하려면 어떤 제품이 불량이었는지 알아야 하고, 수율을 예측하려면 Batch별 실제 투입량과 양품산출량이 있어야 하며, 설비고장을 예측하려면 고장시점과 정비이력이 정확하게 기록돼 있어야 한다.

데이터가 없으면 AI는 학습할 수 없다. 데이터가 있지만 정의가 매번 다르면 더 위험하다. 예를 들어 LOSS라는 코드 안에 다음이 섞여 있다면 AI는 서로 다른 원인을 하나의 현상으로 학습한다.

폐기 / 샘플링
수분증발 / 설비잔량
작업실수

그래서 AI 프로젝트 앞단에는 Data Definition이 필요하다.

첫 번째 축은 Master Data다

AI가 공장을 이해하려면 무엇을 생산하는지부터 알아야 한다. 다음 정보가 Master Data다.

품목코드 / BOM / Recipe
공정순서 / Work Center / 설비코드
원재료 규격 / 단위 / 품질기준

Master Data가 흔들리면 모든 AI 결과도 흔들린다. 같은 찹쌀가루를 ERP에서는 RM001, MES에서는 GLUTINOUS_RICE, 현장 엑셀에서는 찹쌀A라고 관리하면 세 데이터가 같은 원료라는 사실부터 정리해야 한다. AI 모델링보다 먼저 필요한 작업이 코드 통일인 이유다.

BOM이 정확하지 않으면 배합 최적화 AI도 의미가 없다

AI가 원료조합을 최적화하려면 현재 기준 Recipe와 실제 투입값을 알아야 한다. Standard BOM이 틀린 상태에서는 기준 자체가 없다. Actual BOM이 기록되지 않으면 실제로 무엇을 넣었는지도 모른다.

따라서 BOM Precision이 AI 앞단에 위치해야 한다. Standard BOM과 Actual Consumption의 차이가 데이터로 남을 때 AI가 원료 Lot별 특성과 수율 차이를 분석할 수 있다. AI가 BOM을 대신 만드는 것이 아니다. 정확한 BOM과 생산실적 위에서 AI가 Pattern을 찾는 것이다.

두 번째 축은 Lot Context다

식품 제조에서는 같은 품목이라고 항상 같은 결과가 나오지 않는다. 원료 Lot별 수분함량·당도·입도·지방함량이 다를 수 있고 작업자와 설비조건도 다르다.

따라서 AI가 품질과 수율을 학습하려면 단순한 품목코드보다 Context가 필요하다. 다음이 하나의 생산이력으로 묶여야 한다.

Raw Material Lot / Supplier
Batch / Operator / Machine
Temperature / Humidity
Recipe Version / CCP Result

이것이 Lot Traceability가 AI에서도 중요한 이유다.

Lot 번호가 없으면 품질 원인을 평균값으로만 보게 된다

제품 A의 불량률이 3%라고 하자. Lot Context가 없다면 AI는 제품 A라는 SKU 전체의 평균값만 볼 가능성이 크다. 하지만 실제로는 다음처럼 특정 조건에서만 문제가 집중될 수 있다.

특정 공급사 원료 Lot를 사용한 Batch에서만 불량률이 9%
특정 작업조에서만 발생
특정 설비의 온도편차와 연결

Batch와 Lot가 연결돼 있으면 AI가 이 차이를 학습할 수 있다. 연결돼 있지 않으면 품목 평균에 묻힌다.

세 번째 축은 Time-Series Data다

설비 AI에는 시간축이 중요하다. 다음 같은 데이터가 초·분 단위로 쌓여야 한다.

진동 / 온도 / 압력 / 전류 / RPM
Cycle Time / Alarm / Stop Event

정비이력도 같은 시간축에 올라가야 한다. 베어링을 교체한 날짜를 모르는 상태에서 진동 패턴만 학습시키면 예지보전 모델의 Ground Truth가 약해진다. 그래서 PLC와 IoT 센서 데이터는 MES의 설비 Master와 연결돼야 한다. 센서값을 저장하는 것만으로는 부족하다. “이 값이 어느 설비의 어떤 상태에서 발생했는가”가 필요하다.

AI 비전검사도 카메라 하나로 끝나지 않는다

비전 AI 도입은 가장 빠르게 체감되는 제조 AI 중 하나다. 포장불량, 형상불량, 이물, 인쇄오류를 이미지로 판정할 수 있다. 하지만 단순히 PASS/FAIL만 저장하면 품질검사는 자동화돼도 공정개선에는 한계가 있다.

불량 이미지에 다음을 연결해야 한다.

Batch / Lot / Machine
Operator / Timestamp / Recipe Revision

그러면 단순 불량탐지에서 한 단계 더 나아가 특정 설비, 작업조, 원료 Lot와 불량률의 상관관계를 분석할 수 있다. AI 검사기는 눈이고 MES는 기억에 가깝다. 둘이 연결돼야 원인을 찾을 수 있다.

수요예측 AI도 매출 데이터만 넣으면 부족하다

수요예측 AI를 도입하면서 과거 매출 3년치를 넣으면 된다고 생각하는 경우가 있다. 기본 모델은 만들 수 있다. 하지만 식품은 프로모션, 계절, 채널, 소비기한의 영향을 크게 받는다.

같은 매출 1,000개라도 정상판매인지 할인행사인지 의미가 다르다. 품절 때문에 1,000개밖에 못 판 것인지 실제 수요가 1,000개였는지도 구분해야 한다. 따라서 ERP에서 최소한 다음 데이터가 연결돼야 예측오차의 이유를 설명하기 쉬워진다.

판매채널 / 가격 / 프로모션
출하량 / 재고 / 품절
반품 / 소비기한

여기에서 수요예측 오차(MAPE·Bias)와 연결된다.

수요예측 AI에 수수료 데이터를 넣는 목적도 구분해야 한다

판매수수료가 수요 자체를 직접 결정하는 핵심 입력변수는 아닐 수 있다. 다만 채널별 수익성을 고려한 생산계획에는 중요하다. 즉 수요예측 모델과 최적 생산배분 모델은 분리할 수 있다.

첫 모델은 “얼마나 팔릴 것인가”를 예측한다. 다음 최적화 단계에서는 공헌이익, 수수료, 재고회전율, 생산 CAPA, 소비기한을 함께 보고 무엇을 얼마나 생산할지 결정한다. 예측과 의사결정을 하나의 AI라고 뭉뚱그리면 시스템 설계가 흐려진다.

배합 최적화 AI는 ’자동 레시피 변경’보다 제안형으로 시작하는 편이 안전하다

식품 생산에서는 원료 특성에 따라 배합을 미세하게 조정할 필요가 있을 수 있다. AI는 과거 데이터를 바탕으로 수분함량·점도·온도·Yield·완제품 품질 사이의 관계를 분석해 보정값을 제안할 수 있다.

그러나 AI가 바로 ERP BOM이나 MES Recipe를 자동 변경하게 하는 구조는 위험하다. 품질과 표시, 품목제조보고에 영향을 줄 수 있기 때문이다. 초기 구조는 AI Recommendation → QA/Production Review → Approved Recipe Revision → MES Deployment가 적절하다. AI는 추천하고 승인된 변경만 현장에 적용하는 구조다.

예지보전도 고장 데이터가 없으면 예지라고 부르기 어렵다

예지보전은 설비센서 데이터를 분석해 고장 가능성을 미리 감지하는 방식이다. 하지만 식품 중소공장에서 실제 고장 Label이 충분하지 않은 경우가 많다. 정비기록이 “수리함” 한 줄로 남아 있거나, 베어링 교체와 모터 교체가 구분되지 않는 경우도 있다.

이 상태에서 복잡한 Deep Learning 모델부터 적용하면 모델의 근거를 검증하기 어렵다. 초기에는 다음 데이터를 이용한 Condition Monitoring부터 시작하는 것이 현실적일 수 있다.

Alarm Frequency / Temperature Trend
Current Draw / Vibration / Downtime Pattern

데이터가 쌓이면 Predictive Maintenance로 발전시킬 수 있다.

AI 앞단에서 데이터 품질을 측정해야 한다

“우리 데이터가 많다”와 “AI에 사용할 수 있다”는 같은 의미가 아니다. Data Quality는 최소한 다음 관점으로 확인할 필요가 있다.

누락이 얼마나 있는가 / 코드가 일관적인가
시간이 맞는가 / 중복이 있는가
단위가 같은가 / 실제 현장과 일치하는가

예를 들어 kg와 g가 섞여 있으면 값은 모두 숫자지만 학습데이터로는 위험하다. 작업종료시간이 일괄적으로 18:00으로 입력돼 있다면 데이터량은 많아도 Cycle Time 분석에는 쓸 수 없다. AI의 선행과제는 데이터 수집량이 아니라 데이터 신뢰도다.

단독 AI와 데이터 파이프라인 기반 AI의 차이는 원인을 설명할 수 있는가다

구분	파편화된 AI 솔루션	ERP/MES 기반 AI
품목정보	개별 시스템	Master Data 공유
BOM	별도 등록	ERP/MES Revision 연결
Lot	미연결 가능	Batch/Lot Context
작업자	미연결	Operator ID
설비정보	센서 ID 중심	Equipment Master
시간데이터	단독 저장	MES Time-Series
품질결과	PASS/FAIL	QMS 결과 연결
원가	별도 분석	ERP Cost 연동
원인분석	제한적	Context 기반 분석
모델개선	수동	Feedback Loop 가능

ERP와 MES가 있다고 데이터가 자동으로 좋아지는 것은 아니다

ERP를 도입했다고 Master Data가 정확해지는 것은 아니다. MES가 있다고 작업자가 실제 투입량을 정확히 입력한다는 보장도 없다. AI 준비는 시스템 구매가 아니라 데이터 거버넌스 문제다.

누가 품목코드를 생성하는가
BOM 변경은 누가 승인하는가
설비코드는 어떻게 관리하는가
Lot 누락 시 생산을 차단하는가

이런 규칙이 필요하다. ERP/MES는 이 규칙을 실행할 수 있는 기반이다.

모든 제조 AI가 ERP/MES 전체 구축 후에만 가능한 것도 아니다

단순 비전검사처럼 독립적으로 시작할 수 있는 AI도 있다. 특정 설비의 센서 분석 PoC도 ERP 전체 구축 없이 가능하다. 따라서 “ERP와 MES가 없으면 AI를 절대 할 수 없다”고 말하는 것도 지나치다.

문제는 확장성이다. 독립형 PoC는 가능하지만 결과를 생산계획, Lot, 원가, 품질과 연결하려면 결국 구조화된 데이터가 필요하다. 따라서 질문은 “AI부터 할 수 있는가”가 아니라 이 AI 결과를 공장 전체 의사결정에 연결할 수 있는가가 되어야 한다.

AI 도입 순서는 기술보다 데이터 성숙도에 맞춰야 한다

식품공장에서 현실적인 순서는 다음과 같다.

품목·BOM·공정·설비 Master를 정리한다.
생산일보, 자재수불, Lot, 품질결과를 디지털화한다.
PLC와 환경센서 데이터를 시간축으로 연결한다.
데이터 품질을 검증하고 분석용 Dataset을 만든다.
그 다음에 AI 모델을 적용한다.

Master Data → Transaction Data → Lot Context → Time-Series → Data Quality → AI

AI를 맨 앞에 두면 뒤에서 데이터를 맞추느라 프로젝트가 길어진다.

PoC 단계에서는 정확도보다 운영 가능성을 먼저 봐야 한다

AI 모델 정확도가 97%라고 해도 현장에서 사용할 수 없을 수 있다. 판정속도가 생산라인보다 느릴 수 있고, 오탐이 많아 작업자가 경보를 무시할 수 있으며, 모델이 왜 판정했는지 설명하기 어려울 수 있다. 따라서 PoC에서는 다음을 함께 봐야 한다.

Model Accuracy / False Positive
Inference Time / Data Availability
Operator Workflow

AI는 분석실에서 정확한 모델이 아니라 공장에서 계속 사용할 수 있는 시스템이어야 한다.

AI 모델도 Version 관리가 필요하다

Recipe와 BOM에 Revision이 있듯 AI 모델에도 Version이 필요하다. 어떤 데이터로 학습했는지, 언제 배포했는지, Threshold가 무엇인지, 이전 모델 대비 성능이 어땠는지 남겨야 한다.

품질판정 AI의 Threshold를 바꿨는데 기록이 없다면 불량률 변화의 원인이 공정인지 모델인지 구분할 수 없다. QMS Audit Trail과 AI Model Registry를 연결할 수 있는 이유다.

AI는 생산기록을 대신하는 기술이 아니다

현장에서 가장 위험한 기대는 “AI가 알아서 기록할 것”이라는 생각이다. AI는 데이터에서 패턴을 찾는다. 생산사실 자체는 MES가 기록해야 한다. ERP는 자재와 원가, 판매를 기록하고, QMS는 품질판정을 관리하며, PLC는 설비상태를 제공한다.

AI는 그 위에서 예측·분류·추천·이상탐지를 수행한다. 역할을 섞지 않는 것이 중요하다.

식품공장 AI의 경쟁력은 모델보다 Context에서 나온다

비슷한 AI 알고리즘은 다른 회사도 사용할 수 있다. 차이를 만드는 것은 회사가 가진 제조데이터다.

어떤 원료 Lot를 썼는가
어떤 설비조건이었는가
누가 작업했는가
수율이 얼마였는가
어떤 품질결과가 나왔는가

이 데이터가 몇 년 동안 일관되게 연결돼 있으면 AI가 학습할 수 있는 제조 Context가 축적된다. 그것이 제조기업의 데이터 자산이다.

스마트공장의 순서는 자동화보다 구조화다

ERP와 MES의 목적이 AI를 하기 위한 것만은 아니다. 재고와 생산, 품질과 원가를 정확하게 관리하는 것이 본래 역할이다. 하지만 이 기초가 갖춰진 공장은 AI를 붙이기 쉬워진다.

생산일보 표준화는 Time-Series와 Batch Context를 만든다.
BOM Precision은 AI가 비교할 기준값을 만든다.
OEE는 설비손실을 구조화한다.
Lot Traceability는 품질과 원재료를 연결한다.

그 위에 AI를 올리면 모델의 결과가 다시 생산과 품질, 원가에 연결된다. 이 흐름은 제조 AI 전체 그림에서 각 모델이 어디에 위치하는지와도 이어진다.

제조 AI의 시작점은 알고리즘 선정이 아니다. 공장에서 발생한 사건을 품목·Lot·Batch·설비·시간이라는 공통 언어로 설명할 수 있게 만드는 것이다.

그 언어가 정리되지 않은 공장에서는 AI가 데이터를 이해하지 못한다. 반대로 ERP와 MES를 통해 제조사실이 일관된 구조로 쌓이면, AI는 별도의 화려한 프로젝트가 아니라 그 데이터 위에서 작동하는 다음 단계의 분석도구가 된다.