Notes · 2026-08-27

[자율제조 시리즈 ⑩] 제조 AI 모델은 왜 구축보다 운영이 더 어려운가?

정확한 모델을 만드는 것에서 신뢰할 수 있는 모델을 계속 유지하는 것으로

제조 AI 프로젝트를 시작하면 대부분 모델의 정확도에 관심을 둔다.

과거의 생산데이터를 수집하고 정제해 학습데이터와 검증데이터로 나눈다. 여러 알고리즘을 비교하고 가장 높은 성능을 보인 모델을 선택한다.

비전검사 모델의 정확도가 98%에 도달하거나 설비고장을 일정 시간 전에 예측할 수 있다는 결과가 나오면 프로젝트가 성공한 것처럼 보인다.

그러나 실제 제조현장에 모델을 배포하면 새로운 문제가 시작된다.

제품이 변경되고 원재료 공급업체가 바뀐다. 설비부품이 교체되고 공정조건이 조정된다. 카메라와 조명도 노후화되며 작업자의 작업방식도 달라진다.

모델을 학습할 때는 없었던 불량유형과 고장모드가 나타날 수도 있다.

어제까지 정확했던 모델이 오늘도 정확하다고 보장할 수 없다.

모델은 정상적으로 작동하지만 입력데이터를 수집하는 센서가 고장 날 수 있다. 전처리 프로그램과 모델버전이 일치하지 않거나 새 모델이 일부 Edge 장치에만 배포되는 문제도 발생한다.

예측결과는 정상적으로 생성되지만 작업자가 더 이상 결과를 신뢰하지 않아 사용하지 않을 수도 있다.

따라서 다음과 같은 질문이 필요하다.

“AI 모델을 얼마나 정확하게 만들었는가?”

뿐만 아니라,

“그 모델이 현재 제조환경에서도 정확하게 작동하는지 누가 확인하고 있는가?”

제조 AI의 운영은 서버에 모델을 설치하고 장애 여부를 감시하는 것만을 의미하지 않는다.

데이터와 모델의 성능, 제조성과와 실행위험을 지속해서 확인해야 한다. 새로운 모델을 검증하고 안전하게 배포하며, 문제가 생기면 이전 버전으로 복원해야 한다.

더 이상 사용할 수 없는 모델은 자동실행에서 제외하고 폐기해야 한다.

자율제조에서 모델 운영은 기술지원 업무가 아니다.

AI가 현재 제조상황에서도 신뢰할 수 있는 판단을 내리고 있는지 지속해서 증명하는 제조 운영활동이다.

이번 글에서는 제조 AI 모델의 구축보다 운영이 왜 더 어려우며, 모델의 개발과 배포, 감시와 재학습, 중단과 폐기의 전체 생애주기를 어떻게 관리해야 하는지 살펴보고자 한다.

실험실의 AI와 제조현장의 AI는 무엇이 다른가
정확했던 모델의 성능은 왜 떨어지는가
제조 AI의 성능은 무엇으로 측정해야 하는가
제조 AI 모델의 생애주기는 어떻게 구성되는가
운영 중 무엇을 지속해서 감시해야 하는가
언제 모델을 다시 학습하고 교체해야 하는가
새로운 모델은 어떻게 안전하게 배포해야 하는가
Edge에 흩어진 모델은 어떻게 관리해야 하는가
제조 AI 운영조직은 어떤 역할과 책임을 가져야 하는가
경영진은 모델 정확도보다 무엇을 확인해야 하는가

1. 실험실의 AI와 제조현장의 AI는 무엇이 다른가

AI 모델은 일반적으로 과거 데이터를 이용해 개발한다.

수집된 데이터를 학습용과 검증용, 시험용으로 나누고 모델의 성능을 평가한다.

이 과정에서는 데이터의 범위가 고정되어 있다.

제품과 설비, 원재료와 작업조건도 이미 기록된 과거의 조건이다. 모델 개발자는 데이터의 누락과 오류를 정리하고 필요한 변수를 선택할 수 있다.

그러나 실제 제조현장은 고정되어 있지 않다.

매일 새로운 데이터가 들어오고 생산계획과 작업조건이 달라진다.

다음과 같은 변화가 지속해서 발생한다.

새로운 제품과 제품사양
원재료와 공급업체 변경
설비부품과 금형 교체
센서와 검사장비의 교정상태 변화
작업자와 교대조 변경
공정속도와 생산량 변화
계절과 온습도 변화
작업표준과 품질기준 개정
새로운 불량과 고장유형

실험실에서는 모델에 입력할 데이터가 준비되어 있다.

현장에서는 센서통신이 끊기거나 작업자가 정보를 입력하지 않을 수 있다. 시간정보가 맞지 않고 제품코드와 설비코드가 변경될 수도 있다.

실험실에서는 모델의 예측결과를 확인한다.

현장에서는 그 결과가 작업자의 점검과 생산계획 변경, 설비 설정값 조정으로 이어진다.

모델의 작은 오류가 실제 손실로 연결될 수 있다.

예를 들어 비전검사 모델의 정확도가 98%라고 가정해보자.

전체 정확도만 보면 성능이 높아 보인다.

그러나 하루에 10만 개의 제품을 검사한다면 2%의 오류는 최대 2천 건의 잘못된 판정과 관련될 수 있다.

물론 실제 오류 건수는 데이터 구성과 오류유형에 따라 달라지므로 단순히 정확도만으로 계산해서는 안 된다.

특히 정상제품을 불량으로 판단하는 오검출과 불량제품을 정상으로 판단하는 미검출은 영향이 다르다.

오검출이 증가하면 재검사와 폐기비용이 늘어난다.

미검출이 증가하면 불량품이 고객에게 출하될 수 있다.

예지보전도 마찬가지다.

고장을 많이 예측하는 모델이 반드시 좋은 모델은 아니다.

오경보가 반복되면 불필요한 점검과 부품교체가 늘어나고, 작업자는 결국 AI 경보를 무시하게 된다.

실험실의 AI는 정해진 데이터에서 좋은 성능을 내는지가 중요하다.

제조현장의 AI는 다음을 함께 만족해야 한다.

현재 제품과 설비에도 유효한가
필요한 시간 안에 결과를 제공하는가
데이터가 누락될 때 안전하게 대응하는가
오탐과 미탐의 비용을 감당할 수 있는가
작업자가 결과를 이해하고 활용하는가
제조성과를 실제로 개선하는가
오류가 발생하면 중단하고 복구할 수 있는가

모델 개발의 목표는 높은 정확도의 실험결과를 만드는 것이 아니다.

변화하는 제조환경에서도 필요한 성능과 안전성을 계속 유지하는 시스템을 만드는 것이다.

2. 정확했던 모델의 성능은 왜 떨어지는가

운영 중 모델의 성능이 떨어지는 현상을 흔히 Drift라는 개념으로 설명한다.

그러나 모든 성능저하가 같은 원인으로 발생하는 것은 아니다.

어떤 변화가 발생했는지 구분해야 올바른 대응을 할 수 있다.

① Data Drift

모델에 입력되는 데이터의 분포가 학습 당시와 달라지는 현상이다.

예를 들면 다음과 같다.

새로운 원재료 공급업체가 추가됐다.
제품구성이 대형 제품 중심으로 바뀌었다.
생산속도가 높아졌다.
계절변화로 공장 온습도가 달라졌다.
카메라 조명이 어두워졌다.
설비가 노후화되면서 진동의 기본수준이 높아졌다.

입력데이터가 바뀌었다고 모델이 반드시 틀리는 것은 아니다.

그러나 학습하지 않은 범위가 증가하면 성능저하 가능성이 커진다.

② Concept Drift

입력과 결과의 관계가 달라지는 현상이다.

사출압력과 제품중량의 관계가 설비마모 또는 새로운 원재료로 인해 달라질 수 있다.

과거에는 특정 진동패턴이 베어링 고장을 의미했지만 부품구조가 변경된 뒤에는 같은 패턴이 다른 원인을 의미할 수도 있다.

③ Label Drift 또는 기준변화

품질판정과 정답의 기준이 달라진다.

고객의 품질규격 변경
검사기준 강화
불량유형 분류체계 변경
작업자의 판정방식 변경
고장코드와 정비코드 개정

모델은 과거 기준으로 정확하게 작동하지만 현재의 품질기준과 맞지 않을 수 있다.

④ Sensor Drift

센서와 측정장비의 값이 실제 상태와 점차 달라지는 현상이다.

온도센서의 편차
진동센서의 부착상태 변화
카메라 위치와 초점 변화
조명 밝기 감소
저울과 측정기의 교정오차

이 경우 모델보다 측정체계가 문제다.

모델을 다시 학습하기 전에 센서와 검사장비를 점검해야 한다.

⑤ Operational Drift

모델은 정확하지만 실제 업무에서 사용하는 방식이 달라진다.

작업자가 경보를 확인하지 않는다.
생산속도가 빨라져 판정결과가 늦게 도착한다.
모델의 추천을 승인하는 담당자가 변경됐다.
MES 인터페이스가 바뀌어 작업지시와 연결되지 않는다.
AI 결과를 기록하는 절차가 생략된다.

⑥ Software와 Infrastructure Drift

모델을 둘러싼 실행환경이 달라진다.

라이브러리 버전 변경
전처리 프로그램 수정
Edge 장치 교체
운영체제와 드라이버 업데이트
데이터 스키마 변경
API 입력형식 변경

모델 파일이 같더라도 실행결과와 처리속도가 달라질 수 있다.

⑦ Business Drift

기업이 중요하게 보는 목표가 달라진다.

처음에는 불량률 최소화가 목표였지만 이후에는 생산량과 에너지 사용량, 납기가 더 중요해질 수 있다.

기술적으로 정확한 모델이 현재의 경영목표에는 맞지 않을 수 있다.

결국 모델성능 저하는 알고리즘만의 문제가 아니다.

제품과 공정, 센서와 데이터, 품질기준과 업무방식, 실행환경과 경영목표가 변하면서 발생하는 시스템의 문제다.

3. 제조 AI의 성능은 무엇으로 측정해야 하는가

제조 AI 모델을 운영할 때 하나의 정확도 지표만 감시해서는 안 된다.

모델의 기술적 성능과 시스템 운영성능, 제조성과와 위험을 함께 측정해야 한다.

① 기술적 성능

분류모델이라면 다음을 확인할 수 있다.

Accuracy
Precision
Recall
F1 Score
오검출률
미검출률
제품별·불량유형별 성능

예측모델이라면 다음과 같은 지표를 사용할 수 있다.

MAE
RMSE
예측오차의 분포
예측구간의 적절성
설비별·제품별 오차

그러나 지표의 이름보다 어떤 오류가 제조현장에서 더 위험한지 먼저 정해야 한다.

② 데이터 품질

누락률
이상값 비율
지연수집 비율
시간동기화 오류
코드매핑 오류
단위 불일치
라벨 정확성
데이터 분포 변화

ISO/IEC 5259 시리즈는 분석과 머신러닝에 사용되는 데이터의 품질을 관리하기 위한 개념과 측정, 요구사항 및 프로세스·거버넌스 체계를 다룬다. 특히 ISO/IEC 5259-4는 ML 데이터의 라벨링과 평가, 생애주기 관리를 포함한 데이터 품질 프로세스 프레임워크를 제시한다. ISO/IEC 5259-3:2024, ISO/IEC 5259-4:2024, ISO/IEC 5259-5:2025

③ 운영성능

추론시간
시간당 처리건수
서비스 가용성
CPU·GPU와 메모리 사용량
Edge 장치의 온도와 전력
통신지연과 실패
모델 로딩과 재시작 시간
장애와 복구시간

비전검사 모델의 정확도가 높더라도 생산속도보다 판정이 늦으면 현장에 사용할 수 없다.

④ 사람과의 상호작용

작업자의 승인비율
추천 수정비율
경보 무시비율
수동전환 횟수
작업자의 판정과 AI 판정 차이
경보 확인과 대응시간
모델에 대한 이의제기와 피드백

작업자가 계속 수정하는 모델은 정확도 지표와 관계없이 현재 업무에 적합하지 않을 수 있다.

⑤ 제조성과

불량률
고객 불량유출
재검사와 재작업
비계획 정지시간
정비비용
납기준수율
생산량과 사이클타임
재고와 에너지 사용량
문제분석과 대응시간

AI 모델이 높은 성능을 보이더라도 제조 KPI가 개선되지 않으면 모델의 활용방식과 업무연계를 다시 확인해야 한다.

⑥ 위험과 부작용

불필요한 설비정지
과도한 부품교체
다른 품질특성 악화
작업자의 경보피로
데이터 유출
잘못된 자동실행
Near-miss
안전과 환경규칙 위반

제조 AI의 성능평가는 다음의 구조로 이루어져야 한다.

데이터는 정상인가

↓

모델은 정확한가

↓

시스템은 제시간에 작동하는가

↓

작업자는 결과를 활용하는가

↓

제조성과가 개선되는가

↓

허용할 수 없는 위험은 없는가

좋은 모델은 시험데이터에서 정확한 모델만을 의미하지 않는다.

현장에서 필요한 시간에 신뢰할 수 있는 판단을 제공하고, 실제 제조성과를 개선하면서 위험을 허용범위 안에 유지하는 모델이다.

4. 제조 AI 모델의 생애주기는 어떻게 구성되는가

제조 AI 모델은 개발과 배포로 끝나지 않는다.

기획부터 폐기까지 전체 생애주기를 관리해야 한다.

① 문제와 목적 정의

어떤 제조문제를 해결할 것인지 정한다.

적용제품과 설비
예측대상
목표 KPI
허용 가능한 오류
실행과 승인범위
사용해서는 안 되는 조건

② 데이터 정의와 수집

판단에 필요한 데이터를 정의한다.

데이터 출처
수집주기
단위와 시간
제품과 LOT의 연결
라벨의 정의
품질관리 기준
보존기간과 권한

③ 모델 개발

특징과 알고리즘 선택
학습과 검증
제품·설비별 성능분석
불확실성 평가
설명 가능성 검토
위험한 오류의 분석

④ 운영환경 검증

실제 설비와 Edge 또는 Cloud 환경에서 확인한다.

추론시간
처리량
인터페이스
데이터 누락 시 동작
장애와 복구
보안
기존 제어시스템과의 경계

⑤ 모델 등록과 승인

모델의 정보를 중앙에 등록한다.

모델명과 버전
개발자와 소유부서
학습데이터 범위
성능지표
적용범위
제한조건
승인자
유효기간

⑥ 시험배포

Shadow Mode와 Pilot 운영을 통해 실제 데이터에서 성능을 확인한다.

새 모델의 결과가 현실의 실행에 영향을 주지 않는 상태에서 기존 모델 및 작업자의 판단과 비교한다.

⑦ 운영배포

승인된 제품과 설비에 모델을 배포한다.

배포파일과 전처리 로직, 설정값과 실행환경의 버전을 함께 관리한다.

⑧ 지속적 모니터링

데이터와 모델, 시스템과 제조성과를 감시한다.

⑨ 재학습과 변경관리

새로운 데이터와 오류사례를 이용해 모델을 개선한다.

변경된 모델은 기존 모델과 별개의 새 버전으로 보고 다시 검증한다.

⑩ 중단과 롤백

성능이 기준 이하로 떨어지거나 예상하지 못한 위험이 발생하면 자동실행을 중단한다.

이전에 검증된 모델이나 수동업무로 전환한다.

⑪ 폐기

더 이상 필요하지 않거나 대체된 모델을 운영환경에서 제거한다.

모델 실행중지
접근권한 회수
배포파일 제거
관련 데이터 보존 또는 삭제
폐기사유와 영향 기록
작업절차 전환

ISO/IEC 5338:2023은 머신러닝과 휴리스틱 기반 AI 시스템의 정의와 통제, 관리, 실행 및 개선을 지원하는 생애주기 프로세스를 다룬다. 제조 AI도 개별 모델 파일이 아니라 데이터와 소프트웨어, 운영환경과 사람을 포함한 AI 시스템의 생애주기로 관리해야 한다. ISO/IEC 5338:2023

전체 흐름을 정리하면 다음과 같다.

문제 정의

↓

데이터 준비

↓

모델 개발

↓

운영환경 검증

↓

등록과 승인

↓

Shadow Mode와 시험배포

↓

운영배포

↓

지속적 모니터링

↓

재학습 또는 롤백

↓

모델 폐기

모델 운영의 핵심은 자동배포 기술이 아니다.

각 생애주기 단계에서 누가 무엇을 검증하고 승인하는지를 명확히 하는 것이다.

5. 운영 중 무엇을 지속해서 감시해야 하는가

운영 중 모델을 감시한다고 서버가 실행 중인지 확인하는 것만으로는 부족하다.

AI 시스템은 정상적으로 응답하면서도 잘못된 판단을 할 수 있기 때문이다.

다음의 여러 계층을 함께 감시해야 한다.

① 입력데이터

필수 데이터가 들어오는가
값이 정상범위에 있는가
시간과 순서가 맞는가
단위와 데이터 형식이 변경되지 않았는가
제품과 작업지시가 정확히 연결됐는가
학습 당시 분포와 얼마나 달라졌는가

② 모델출력

예측값의 분포가 갑자기 변하지 않았는가
특정 등급의 판정만 지나치게 증가하지 않았는가
모델의 신뢰도가 낮아지지 않았는가
불확실한 결과가 증가하지 않았는가
설비와 제품별 편차는 없는가

③ 정답과 결과

예측 당시에는 정답을 바로 알 수 없는 경우가 많다.

품질검사 결과가 몇 시간 뒤에 나오거나 설비고장이 몇 주 후에 발생할 수 있다.

따라서 예측과 실제결과를 나중에 연결하는 구조가 필요하다.

AI 판정과 최종 품질검사
고장예측과 실제 고장
정비추천과 실제 부품상태
생산계획 예측과 실제 완료시간
에너지 예측과 실제 사용량

④ 시스템 상태

서비스 가용성
처리시간
자원사용량
네트워크 상태
데이터 적체
API 오류
Edge 장치의 상태
모델과 전처리 버전

⑤ 실행과 승인

AI가 어떤 행동을 추천했는가
작업자가 승인 또는 거부했는가
무엇을 수정했는가
실제로 어떤 명령이 실행됐는가
실행이 정상적으로 완료됐는가
이전 상태로 복구됐는가

⑥ 제조 KPI

모델 적용 전후의 불량률
생산중단과 정비시간
작업자의 대응시간
납기와 생산량
에너지와 재고
비용절감과 추가비용

⑦ 위험지표

중요 불량의 미검출
위험한 오경보
자동실행 실패
승인되지 않은 변경
안전조건 접근
Near-miss
반복되는 작업자 거부

NIST AI RMF는 AI 위험관리를 Govern, Map, Measure, Manage의 네 기능으로 구성하고, AI 시스템의 성능과 신뢰성이 운영 중 변할 수 있으므로 지속적인 측정과 관리가 필요하다고 설명한다. NIST AI Risk Management Framework 1.0

모니터링 화면에 많은 그래프를 표시한다고 운영이 되는 것은 아니다.

각 지표에 다음이 정의되어야 한다.

정상범위
경고기준
자동실행 중단기준
담당자
대응시간
원인분석 절차
복구와 재검증 조건

모니터링의 목표는 문제가 발생한 뒤 보고서를 만드는 것이 아니다.

모델이 신뢰할 수 있는 범위를 벗어나는 순간을 조기에 발견해 잘못된 판단이 제조실행으로 이어지는 것을 막는 것이다.

6. 언제 모델을 다시 학습하고 교체해야 하는가

데이터가 변했다고 항상 모델을 다시 학습해야 하는 것은 아니다.

재학습은 비용과 시간이 필요하고 잘못 수행하면 기존보다 성능이 낮아질 수도 있다.

반대로 일정한 주기만 기다리면 성능이 떨어진 모델을 계속 사용하게 될 수 있다.

따라서 재학습 조건을 명확하게 정의해야 한다.

① 성능기준 이하

중요 불량의 미검출률이 허용기준을 초과했다.
설비별 예측오차가 증가했다.
고장 사전감지 시간이 짧아졌다.
오경보가 증가해 작업자의 거부율이 높아졌다.

② 데이터 분포 변화

신제품이 일정 비율 이상 투입됐다.
원재료 공급업체가 변경됐다.
새로운 설비와 센서가 추가됐다.
온습도와 생산속도의 범위가 학습조건을 벗어났다.

③ 제조공정 변경

설비가 개조됐다.
금형과 공구가 변경됐다.
공정조건과 작업표준이 개정됐다.
검사장비와 판정기준이 달라졌다.

④ 새로운 불량과 고장유형

기존 모델이 알지 못하는 새로운 문제유형이 나타나면 기존 분류체계와 학습데이터를 수정해야 한다.

⑤ 데이터 충분성 확보

과거에는 고장데이터가 부족했지만 운영 중 충분한 사례가 축적됐을 수 있다.

이 경우 새로운 데이터를 이용해 성능을 개선할 수 있다.

⑥ 정기 재검토

명확한 성능저하가 없어도 일정 주기마다 다음을 검토한다.

모델의 목적이 여전히 유효한가
현재 생산제품과 설비에 적합한가
다른 모델로 대체할 필요가 있는가
운영비용 대비 효과가 있는가
자동실행 권한을 유지해도 되는가

재학습 과정에서는 다음을 주의해야 한다.

최근 데이터만 사용하지 않는다

최근 조건에는 적합하지만 과거에 드물게 발생했던 중요한 불량과 고장유형을 잊을 수 있다.

작업자의 수정값을 무조건 정답으로 사용하지 않는다

작업자의 판단에도 오류와 개인차가 있을 수 있다.

수정이 발생한 이유와 승인여부를 확인해야 한다.

성능지표 하나만 비교하지 않는다

평균 정확도가 높아졌지만 중요한 불량의 미검출이 증가할 수 있다.

기존 모델과 동일한 조건에서 비교한다

데이터와 평가기준이 다르면 모델의 개선 여부를 정확하게 판단하기 어렵다.

재학습과 재배포를 구분한다

모델을 다시 학습했다고 자동으로 운영환경에 배포해서는 안 된다.

검증과 승인, Shadow Mode를 다시 거쳐야 한다.

모델의 재학습은 단순한 기술적 업데이트가 아니다.

변경된 제조조건에서도 새로운 모델에 판단과 실행권한을 다시 부여할 수 있는지 검증하는 변경관리 절차다.

7. 새로운 모델은 어떻게 안전하게 배포해야 하는가

새로운 모델이 시험데이터에서 기존 모델보다 높은 성능을 보였다고 곧바로 모든 설비에 배포해서는 안 된다.

운영환경에서는 데이터와 하드웨어, 인터페이스와 작업절차가 다를 수 있다.

새 모델의 배포는 단계적으로 이루어져야 한다.

① Offline Evaluation

과거 운영데이터와 별도의 시험데이터를 이용해 기존 모델과 비교한다.

전체 성능
제품별·설비별 성능
중요 오류
처리시간
불확실성
알려지지 않은 조건에서의 동작

② Integration Test

모델을 둘러싼 전체 파이프라인을 시험한다.

센서와 카메라 입력
데이터 전처리
모델 추론
MES와 QMS 연결
알람과 작업지시
로그와 모니터링
장애와 복구

③ Shadow Mode

새 모델이 실제 데이터를 처리하지만 결과를 생산에 적용하지 않는다.

기존 모델과 작업자의 판정을 비교한다.

④ Champion–Challenger

현재 운영 중인 모델을 Champion, 후보모델을 Challenger로 두고 동일한 조건에서 비교한다.

후보가 실제 운영데이터에서 우수하고 위험기준도 만족하는지 확인한다.

⑤ Canary Deployment

일부 제품과 설비, 일부 시간대에만 새 모델을 적용한다.

문제가 없을 때 적용범위를 단계적으로 확대한다.

⑥ 승인형 운영

초기에는 새 모델의 판단을 작업자가 확인하고 승인한 뒤 실행한다.

충분한 사례와 성과가 확인된 뒤 제한적인 자동실행을 허용한다.

⑦ 롤백 준비

배포 전에 다음을 준비한다.

이전 모델
이전 전처리 로직
설정값
실행환경
복원절차
롤백 책임자
롤백 판단기준

⑧ 배포 후 집중관찰

새 모델 배포 직후에는 평상시보다 더 자주 성능과 오류를 확인한다.

새로운 제품과 야간조, 고부하 운전과 같은 다양한 조건에서 검증해야 한다.

배포방식을 비교하면 다음과 같다.

단계	현실에 미치는 영향	주요 목적
Offline 평가	없음	과거 데이터에서 성능비교
통합시험	시험환경	전체 파이프라인 확인
Shadow Mode	실행 없음	실제 데이터에서 비교
Canary	일부 적용	제한된 범위에서 위험확인
승인형 운영	사람 승인 후 실행	현장 신뢰성 검증
자동실행	현실에 직접 반영	검증된 범위의 자율운영

새 모델의 배포는 소프트웨어 파일을 복사하는 일이 아니다.

새로운 판단주체가 제조운영에 참여하도록 권한을 부여하는 절차다.

8. Edge에 흩어진 모델은 어떻게 관리해야 하는가

9회차에서 살펴본 것처럼 제조 AI 모델은 Cloud뿐 아니라 카메라와 센서, Machine Edge와 Factory Edge에 배포될 수 있다.

하나의 공장에 수십 또는 수백 개의 AI 모델이 운영될 수도 있다.

중앙관리가 없으면 다음과 같은 문제가 발생한다.

같은 설비에 서로 다른 모델버전이 설치된다.
승인되지 않은 시험모델이 운영환경에 남는다.
어느 제품에 어떤 모델을 사용했는지 알 수 없다.
일부 Edge만 업데이트되어 결과가 달라진다.
취약한 라이브러리와 오래된 운영체제가 방치된다.
문제가 생겨도 이전 모델로 복구할 수 없다.

따라서 Edge 모델의 자산관리와 배포관리가 필요하다.

① AI 자산목록

다음을 등록한다.

AI 시스템과 모델
배포된 Edge 장치
대상공장과 설비
적용제품
모델버전
소프트웨어와 라이브러리
모델 소유자
승인상태
운영기간

② 모델과 데이터의 연결

어떤 데이터로 학습하고 검증했는지 추적한다.

운영 중 발생한 판정결과도 사용한 모델버전과 연결해야 한다.

③ 장치의 상태관리

하드웨어 사양
운영체제
GPU와 가속기
저장공간
네트워크
온도와 전력
보안패치
인증서와 자격증명

④ 서명된 배포물

모델과 실행프로그램, 설정파일의 출처와 무결성을 확인한다.

승인되지 않았거나 변조된 모델은 실행하지 않아야 한다.

⑤ 배포그룹

제품과 설비, 하드웨어 조건이 같은 Edge를 그룹으로 관리한다.

한 번에 전체 장치에 배포하지 않고 시험그룹과 운영그룹을 구분한다.

⑥ 통신단절 대응

Edge가 중앙과 연결되지 않아도 마지막으로 검증된 모델을 사용할 수 있어야 한다.

다만 유효기간을 초과하면 자동실행을 제한하거나 수동운영으로 전환해야 한다.

⑦ 원격 롤백과 현장복구

중앙에서 롤백할 수 있어야 하지만 네트워크 장애를 고려해 현장에서도 이전 버전으로 복구할 수 있어야 한다.

⑧ 사용종료 처리

폐기된 모델과 불필요한 계정, 인증서와 데이터를 Edge에서 제거한다.

중앙의 모델 저장소만 정리하고 현장장치에 파일을 남겨두어서는 안 된다.

Edge 모델관리의 핵심은 모든 장치를 항상 최신버전으로 만드는 것이 아니다.

설비와 제품별로 검증된 버전이 다를 수 있기 때문이다.

어느 현장에서 어떤 모델이 어떤 근거와 승인으로 운영되고 있는지를 정확하게 알고 통제하는 것이 중요하다.

9. 제조 AI 운영조직은 어떤 역할과 책임을 가져야 하는가

제조 AI 운영을 데이터분석팀이나 IT 부서에만 맡겨서는 안 된다.

모델성능은 데이터와 알고리즘뿐 아니라 제품과 공정, 설비와 품질기준에 의해 결정된다.

생산과 품질, 설비와 IT·OT, 보안과 경영이 함께 책임을 가져야 한다.

① AI 모델 소유자

모델의 목적과 성과, 운영여부에 책임을 진다.

적용범위
목표 KPI
운영예산
재검토와 폐기 결정

② 공정·설비 전문가

모델의 판단이 제조현상과 일치하는지 검증한다.

변수와 원인관계
적용조건
설비 허용범위
현장변경의 영향
작업자 피드백

③ 품질담당자

라벨과 판정기준
중요 오류의 정의
품질규격
변경승인
고객 불량과 모델결과 연결

④ 데이터·AI 담당자

데이터 파이프라인
모델 개발과 검증
Drift 분석
재학습
기술적 성능 모니터링

⑤ IT·OT 운영담당자

서버와 Edge 장치
네트워크와 인터페이스
배포와 롤백
가용성과 복구
기존 제조시스템 연계

⑥ 보안담당자

계정과 권한
모델과 데이터 보호
취약점과 패치
보안사건
공급망과 외부솔루션 위험

⑦ 현장 작업자

AI 결과의 실제 활용
잘못된 판단의 보고
수정과 거부이유 기록
새로운 작업조건과 예외 공유

⑧ AI 검토 또는 거버넌스 조직

위험과 영향이 큰 모델의 등록과 배포, 자동실행 권한과 폐기를 검토한다.

조직별 역할은 RACI와 같은 방식으로 명확히 할 수 있다.

주요 활동	생산·공정	품질	데이터·AI	IT·OT	보안	경영·거버넌스
문제와 KPI 정의	R	C	C	C	I	A
데이터와 라벨 검증	C	A/R	R	C	I	I
모델 개발	C	C	A/R	C	C	I
현장 검증	A/R	R	C	R	C	I
모델 배포	C	C	R	A/R	C	I
자동실행 승인	R	R	C	C	C	A
성능 모니터링	R	R	R	R	C	I
롤백·중단	R	R	C	A/R	C	I
모델 폐기	C	C	R	R	C	A

기업의 조직구조와 모델의 위험수준에 따라 책임배분은 달라질 수 있다.

중요한 것은 문제가 발생했을 때 데이터팀과 현장, 공급업체가 서로 책임을 미루지 않도록 하는 것이다.

ISO/IEC 42001:2023은 조직이 AI 시스템을 책임 있게 개발·제공·사용하기 위해 정책과 목표, 역할과 절차를 수립하고 유지하며 지속해서 개선하는 AI 경영시스템을 요구한다. 개별 모델의 기술관리뿐 아니라 조직 전체의 AI 거버넌스가 필요한 이유다. ISO/IEC 42001:2023

제조 AI의 운영주체는 모델개발자 한 사람이 아니다.

모델의 판단을 데이터와 공정, 품질과 설비, 시스템과 조직이 공동으로 유지하는 운영체계다.

10. 경영진은 모델 정확도보다 무엇을 확인해야 하는가

제조 AI 사업을 보고받을 때 경영진은 정확도와 투자비용, 도입설비 수를 확인하기 쉽다.

그러나 운영단계에서는 다른 질문이 필요하다.

첫째, 현재 운영 중인 AI 모델이 몇 개이며 어디에 배포되어 있는가.

기업의 AI 자산목록이 있어야 한다.

둘째, 각 모델의 목적과 적용범위, 사용금지 조건이 정의되어 있는가.

어떤 제품과 설비, 공정조건에서 사용할 수 있는지 명확해야 한다.

셋째, 모델의 성능을 현장에서 지속해서 측정하고 있는가.

개발 당시의 시험성능이 아니라 현재 운영성능을 확인해야 한다.

넷째, AI 판정과 실제 품질·고장결과를 연결할 수 있는가.

정답이 나중에 발생하는 경우에도 예측과 결과를 연결해야 한다.

다섯째, 데이터와 제조환경의 변화를 감지할 수 있는가.

제품과 설비, 원재료와 검사기준의 변경이 모델에 미치는 영향을 확인해야 한다.

여섯째, 성능이 어느 수준까지 떨어지면 자동실행을 중단하는가.

허용기준과 중단조건이 사전에 정의되어야 한다.

일곱째, 새 모델은 어떤 검증과 승인을 거쳐 배포되는가.

시험성능만으로 전체 현장에 배포해서는 안 된다.

여덟째, 문제가 발생하면 이전 모델이나 수동업무로 복구할 수 있는가.

롤백 절차와 복구시간을 실제로 시험해야 한다.

아홉째, 모델과 데이터, 운영결과에 대한 책임자가 지정되어 있는가.

모델 소유자와 현장·품질·IT·보안의 역할을 구분해야 한다.

열째, 모델 운영비용을 포함해 실제 사업성과가 있는가.

다음의 비용과 효과를 함께 확인해야 한다.

모델 개발과 재학습 비용
데이터 라벨링과 품질관리 비용
Cloud와 Edge 인프라 비용
모니터링과 장애대응 인력
불량과 정지시간 감소
검사와 점검시간 단축
고객 불량과 재작업 감소
AI 오류로 인한 추가비용
작업자의 신뢰와 활용률

ISO/IEC 23894:2023은 AI를 개발·제공·배포·사용하는 조직이 AI 관련 위험관리를 기존 조직활동과 기능에 통합할 수 있도록 지침을 제공한다. 모델 운영도 별도의 기술업무가 아니라 기업 위험관리의 일부로 다루어야 한다. ISO/IEC 23894:2023

경영진이 확인해야 할 것은 정확도가 높은 모델을 몇 개 만들었는가가 아니다.

현재 현장에서 어떤 AI가 판단하고 있으며, 그 판단을 조직이 계속 신뢰할 수 있는 상태로 관리하고 있는가이다.

마치며

제조 AI 프로젝트에서는 모델을 만드는 일이 가장 어려워 보인다.

데이터를 수집하고 정제하며 적절한 알고리즘을 선택해야 한다. 모델을 학습하고 성능을 높이는 데도 많은 시간과 전문성이 필요하다.

그러나 모델을 실제 제조현장에 배포하면 더 긴 운영의 시간이 시작된다.

제품과 설비, 원재료와 작업환경은 계속 변한다.

센서와 카메라는 노후화되고 품질기준과 작업표준도 개정된다. 새로운 불량과 고장유형이 나타나며 AI를 실행하는 Edge와 Cloud 환경도 변경된다.

따라서 한 번 정확했던 모델이 계속 정확할 것이라고 가정할 수 없다.

결국 제조 AI 모델은 다음의 흐름으로 관리해야 한다.

제조문제와 목적을 정의한다.

필요한 데이터와 품질기준을 정한다.

모델을 개발하고 위험한 오류를 분석한다.

실제 운영환경에서 성능과 안전성을 검증한다.

모델과 적용범위, 제한조건을 등록한다.

Shadow Mode와 단계적 배포를 거친다.

데이터와 모델, 시스템과 제조성과를 지속해서 감시한다.

성능이 떨어지면 원인을 구분한다.

필요하면 재학습하고 다시 검증한다.

위험기준을 벗어나면 자동실행을 중단한다.

문제가 발생하면 이전 모델 또는 수동업무로 복구한다.

사용가치가 없어진 모델은 안전하게 폐기한다.

이 흐름이 연결될 때 AI 모델은 일회성 프로젝트의 산출물에서 제조운영의 자산으로 발전한다.

중요한 것은 모델을 자주 업데이트하는 것이 아니다.

현재 모델이 왜 유효하며 어떤 조건에서 사용할 수 있는지를 설명할 수 있어야 한다.

새 모델이 나왔다는 이유로 자동으로 교체해서도 안 된다.

제조현장에서 충분히 검증하고 이전 모델과 비교한 뒤 필요한 승인을 받아야 한다.

MLOps 플랫폼을 도입한다고 운영문제가 자동으로 해결되는 것도 아니다.

도구는 모델과 데이터, 배포와 모니터링을 관리하는 데 도움을 준다.

그러나 어떤 성능을 허용할지, 언제 자동실행을 멈출지, 누가 재학습과 배포를 승인할지는 조직이 결정해야 한다.

제조 AI의 경쟁력은 가장 높은 정확도의 모델을 한 번 만드는 데 있지 않다.

변화하는 제조환경에서 모델의 신뢰성을 계속 측정하고, 성능이 떨어지기 전에 발견하며, 안전하게 개선하거나 중단할 수 있는가.

바로 이것이 제조 AI 모델이 구축보다 운영이 더 어려운 이유이며, 자율제조 기업이 갖추어야 할 실질적인 AI 운영역량이다.

다음 글에서는 여러 AI 모델과 Agent, Digital Twin이 실제 제조운영에 참여할 때 필요한 책임과 통제체계를 살펴보고자 한다.

AI가 생산계획과 공정조건을 바꾸고 설비의 행동에 영향을 준다면 누가 그 판단을 승인하고 결과에 책임져야 할까.

[자율제조 시리즈 ⑪] 자율제조 AI 거버넌스는 무엇을 통제해야 하는가?