AI 품질관리·이상탐지 기초 — 불량이 터지기 전에 잡는 법

품질관리 화면에 빨간색 경고가 떴다고 하자 — “공정 이상 가능성 87%.” 이 숫자를 본 관리자는 무엇을 해야 할까. 제품을 부적합으로 판정해야 할까, 생산을 중단해야 할까, 해당 Batch를 출하보류해야 할까, 설비부터 점검해야 할까. 정답은 경고가 무엇을 의미하는지에 따라 달라진다.

제조업에서 AI 이상탐지를 이야기할 때 가장 먼저 구분해야 할 것은 이상(Anomaly)과 부적합(Nonconformance)은 같은 말이 아니라는 것이다. 평소와 다른 데이터가 나타났다고 제품이 부적합이라는 뜻은 아니다. 반대로 데이터가 평소와 비슷하다고 제품의 안전이나 품질이 자동으로 보증되는 것도 아니다. AI 품질관리의 역할을 제대로 정하려면 이 경계를 먼저 명확히 해야 한다.

제조현장의 ’이상’은 하나가 아니다

공장에서 이상이라는 말을 쓸 때는 서로 다른 상황이 섞여 있다.

• 기준이탈 — 회사 또는 HACCP 계획에서 정한 관리기준·한계기준을 벗어난 경우.
• 추세이상 — 아직 기준을 벗어나지 않았지만 평소와 다른 방향으로 값이 움직이는 경우.
• 조합이상 — 온도 하나, 압력 하나를 따로 보면 정상범위지만 여러 변수를 함께 보면 평소와 다른 조합이 나타나는 경우.
• 결과이상 — 불량률·수율·검사결과 등 최종 생산성과가 평소와 크게 달라지는 경우.

이 넷을 모두 AI가 판단해야 하는 건 아니다. 오히려 명확한 기준이 존재하는 첫 번째 영역은 일반적인 Rule Engine이 더 적합하다.

명확한 기준은 AI에게 판단시키지 않아도 된다

가상의 예를 들자. 어떤 공정의 내부 관리기준이 75℃ 이상이라고 하자(실제 CCP 한계기준은 제품·HACCP 계획에 따라 다르므로 여기 숫자는 설명용 가상 수치다). 측정값이 74.5℃라면 측정값 < 75℃라는 조건만으로 기준이탈을 확인할 수 있다. 복잡한 AI가 필요하지 않다. 오히려 이렇게 명확히 정의된 조건은 Rule로 판정하는 편이 설명하기 쉽고 재현성도 높다. 특히 HACCP CCP 모니터링에서는 AI가 법적·관리상 한계기준을 대신 정하거나 임의로 변경하는 구조로 설계해서는 안 된다. AI가 활용될 수 있는 곳은 그 전후의 다른 문제다.

75℃를 넘었는데도 ‘평소와 다를’ 수 있다

같은 가상 공정을 보자. 최근 Batch 측정값이 —

76.1 → 76.0 → 75.9 → 75.7 → 75.5 → 75.3 ℃

모든 값이 75℃ 이상이라 단순 Rule에서는 전부 정상범위다. 하지만 데이터에는 하락하는 방향이 보인다. 이게 곧 다음 Batch에서 기준을 이탈한다는 뜻은 아니다 — 센서 오차일 수도, 원재료 상태가 달라졌을 수도, 생산조건 변화 때문일 수도, 아무 문제 아닐 수도 있다. 다만 관리자가 한 번 확인해볼 만한 신호는 된다. 이런 영역에서 이상탐지가 의미를 가진다. Rule이 “기준을 벗어났는가”를 판단한다면, 이상탐지는 “평소와 달라졌는가”를 찾는 데 쓸 수 있다.

관리기준과 AI 경고선을 섞으면 안 된다

이 구분은 화면에서도 중요하다. CCP 한계기준 이탈과 AI 이상경고가 모두 같은 빨간색 경고창으로 표시되면 작업자는 둘을 같은 수준의 문제로 받아들인다. 하지만 의미가 다르다 — 한계기준 이탈은 정해진 HACCP 절차에 따라 처리해야 하는 사건이고, AI 이상경고는 추가확인이 필요한 참고신호일 수 있다. 그래서 시스템에서는 최소한 기준이탈 · 관리주의 · AI 이상신호 같은 의미를 구분해 표시하는 편이 좋다. AI가 생성한 확률값이나 이상점수를 HACCP 판정값처럼 보여주는 것도 조심해야 한다.

단일 센서보다 여러 변수의 관계에서 이상이 보인다

AI 이상탐지의 장점이 나타나는 영역이다. 가열공정에 온도·가열시간·설비속도·투입량·제품 중심온도 데이터가 있다고 하자. 각 항목만 보면 모두 평소 범위 안일 수 있다. 그런데 투입량이 평소보다 많은데 설비속도는 그대로이고 가열시간은 짧아졌다면 전체 조합이 과거 정상 Batch와 다를 수 있다. 사람이 변수 다섯 개를 매 Batch마다 비교하기는 번거롭고, 변수가 수십 개면 더 어렵다. 이때 다변량 분석이나 머신러닝 기반 이상탐지로 “개별 값은 범위 안이지만 전체 패턴은 평소와 다르다”는 후보를 찾을 수 있다. AI 이상탐지의 실질적 장점은 여기서 나타난다.

하지만 ’평소와 다르다’가 곧 ’나쁘다’는 아니다

신제품을 처음 생산하면 기존 제품과 Recipe·공정조건이 다르다. AI가 과거 제품의 정상패턴만 학습했다면 신제품 Batch를 대량으로 이상이라고 판단할 수 있다. 설비를 교체한 뒤에도, 공정개선으로 생산속도가 빨라졌는데 과거 데이터를 기준으로 봐도 오히려 이상으로 보일 수 있다. 즉 이상탐지는 과거와 다른 것을 찾는 기술이지 좋은 것과 나쁜 것을 자동으로 구분하는 기술이라고 단정할 수 없다. 그래서 모델이 학습한 ’정상’의 범위가 현재 공정을 여전히 대표하는지 계속 확인해야 한다.

정상 데이터의 정의가 모델보다 먼저다

AI 이상탐지를 시작한다고 모든 과거 생산데이터를 학습시키면 되는 게 아니다. 과거 데이터 안에 이미 문제가 있었을 수 있다. 최근 2년치 공정데이터를 전부 정상 데이터로 썼는데 그 기간 중 설비상태가 나빴던 기간, Recipe가 변경된 기간, 센서가 교정 안 된 기간, 부적합 Batch가 발생한 기간까지 섞여 있다면 모델이 잘못된 상태까지 ’평소’라고 학습한다. 그래서 학습데이터를 만들 때는 최소한 제품 · Recipe Version · 설비 · 공정조건 · 품질결과 맥락을 확인해야 한다. AI 모델을 만드는 것보다 무엇을 정상 생산으로 볼 것인지 정의하는 작업이 더 어려울 수도 있다.

Batch가 다르면 정상범위도 달라진다

같은 설비를 쓰는 제품 A(점도 높음)와 B(낮음)는 같은 펌프압력이라도 정상범위가 다를 수 있다. 생산량 100kg Batch와 500kg Batch에서도 공정패턴이 달라지고, Recipe Version이 변경되면 정상조건이 달라진다. 그래서 공장 전체에 하나의 ’정상 모델’을 적용하기보다 제품 · 제품군 · 공정 · 설비 · Batch 규모에 따라 기준을 나눠야 하는 경우가 있다. 이 때문에 제조 AI에서는 공정데이터만큼 Master Data가 중요하다.

센서 값만 모으면 원인을 찾기 어렵다

온도패턴이 이상하다는 경고가 발생했을 때 센서 데이터만 있으면 “14시 32분부터 온도가 평소와 다릅니다” 정도까지는 안다. 하지만 품질관리자는 묻는다 — 그때 어떤 제품을 만들고 있었나, 어느 Batch인가, 어떤 원재료 LOT를 썼나, Recipe Version은, 어느 설비인가, 작업자는, 최종 검사결과는. 이 정보가 연결돼야 이상신호를 실제 조사로 이어갈 수 있다. 그래서 제조 AI의 데이터 구조는 Timestamp → Sensor Value에서 끝나면 부족하고, 최소한 Timestamp → Equipment → Production Order → Batch → Product → Recipe Version 같은 생산맥락과 연결돼야 한다.

이상탐지에서 LOT 연결이 중요한 이유

이상신호가 발생한 Batch가 확인되면 다음 질문은 영향범위다 — 같은 원재료 LOT를 쓴 다른 Batch가 있는가, 같은 설비에서 같은 시간대에 생산한 다른 제품이 있는가, 해당 완제품 LOT가 이미 출고됐는가, 어느 거래처로 나갔는가. 이건 AI 문제가 아니라 Traceability 문제다. AI가 아무리 빨리 이상을 찾아도 영향범위를 확인할 수 없다면 실제 대응은 다시 수작업이 된다. 그래서 품질 AI는 독립된 분석도구보다 LOT·Batch 추적구조와 연결될 때 실무가치가 커진다.

이상점수 87점은 품질점수가 아니다

AI 시스템에서 흔히 Anomaly Score를 0~100으로 보여준다. 87점이 나왔다고 “불량확률 87%“라고 해석하면 안 되는 모델도 많다. 이상점수는 모델에 따라 정상패턴에서 얼마나 멀리 떨어져 있는지를 나타내는 내부 지표일 수 있다. 확률처럼 보이는 숫자라고 실제 불량확률을 의미하는 건 아니다. 그래서 화면에서는 Anomaly Score · 불량확률 · 품질판정을 명확히 구분해야 하고, 관리자에게 숫자를 보여줄 때 그 값의 의미를 설명할 수 있어야 한다.

오탐과 미탐은 단순히 민감도 슬라이더 문제가 아니다

이상탐지에서는 두 오류가 발생한다 — 정상인데 이상이라고 경고하는 False Positive, 실제 이상인데 정상으로 지나가는 False Negative. 민감도를 높이면 더 많은 후보를 잡지만 경고도 는다. 그렇다고 “처음엔 둔감하게 시작하고 놓친 사례가 생기면 조금씩 올린다”가 항상 적절한 건 아니다. 어떤 이상을 놓쳤을 때의 위험이 큰지, 경고 하나를 조사하는 비용은 얼마인지, 기존 품질통제가 별도로 존재하는지에 따라 허용 가능한 오탐·미탐 수준이 달라진다. 식품안전과 직접 관련된 영역이라면 특히 단순한 편의성 기준으로 민감도를 결정해선 안 된다.

경고가 너무 많으면 좋은 모델도 현장에서 버려진다

하루 200개 Batch를 생산하는 공장에서 AI가 80건의 이상경고를 만든다면, 품질담당자가 80건을 다 조사할 수 없어 시스템은 실제로 작동하기 어렵다. 처음엔 확인하지만 시간이 지나면 알림 자체를 무시하게 된다. 그래서 이상탐지의 목표는 가능한 많은 경고를 만드는 게 아니라 사람이 실제로 확인할 수 있는 수준으로 우선순위를 좁히는 것이다. 단순 이상점수 외에 제품 위험도 · 이상 지속시간 · 변수 개수 · 과거 부적합과의 연관성 · 출하상태를 이용해 조사 우선순위를 정할 수 있다.

반대로 경고가 없다고 ’품질보증’이라고 표시해서도 안 된다

AI가 이상을 감지하지 않았다고 해당 Batch가 안전하고 적합하다는 의미는 아니다. 모델이 보지 않는 변수가 있을 수 있고, 학습하지 못한 새로운 유형의 문제가 발생할 수도 있고, 미생물 오염처럼 현재 수집하는 센서데이터만으로 직접 판단하기 어려운 문제도 있다. 따라서 AI 이상탐지는 기존 검사·모니터링·검증절차를 대체하는 품질보증 장치가 아니다. AI 경고 없음 = 제품 적합이라는 논리를 시스템에 넣으면 안 된다.

이상이 발생했을 때 가장 먼저 필요한 건 ’원인 자동확정’이 아니다

AI가 온도 이상을 감지하고 시스템이 곧바로 “히터 노후가 원인입니다”라고 표시하면 편리해 보인다. 하지만 실제 원인은 센서 이상일 수도, 투입량 변화일 수도, 설비속도 변경일 수도 있다. 충분한 근거 없이 원인을 확정하면 오히려 조사방향을 잘못 유도한다. 초기 품질 AI에서는 어떤 변수가 평소와 달랐는지 · 언제부터 달라졌는지 · 어떤 Batch에 해당하는지 · 비슷한 과거사례가 있었는지를 보여주는 것만으로도 상당한 가치가 있다. 원인분석은 그다음 문제다.

담당자가 경고를 처리한 결과가 다시 중요한 데이터가 된다

AI가 30개의 이상신호를 만들었고 담당자가 확인한 결과 10건 실제 공정문제 / 5건 센서문제 / 12건 정상변동 / 3건 원인미확인이었다고 하자. 이 결과를 시스템에 남기지 않으면 다음 달에도 같은 종류의 경고가 반복된다. 그래서 이상경고 자체뿐 아니라 처리결과 — 확인자 · 확인시각 · 판정 · 원인분류 · 조치내용 · 관련 부적합 기록 — 도 데이터로 관리할 가치가 있다. 이 데이터는 모델 개선뿐 아니라 공정개선에도 쓰인다.

AI가 자동으로 계속 학습하게 만드는 게 항상 좋은 건 아니다

담당자가 정상이라고 처리한 데이터를 AI가 즉시 정상패턴으로 다시 학습한다면 편리해 보이지만 위험할 수 있다. 담당자가 잘못 판단했거나 일시적인 공정이상을 정상으로 승인했을 수 있고, 그 데이터가 계속 모델에 들어가면 정상범위가 서서히 잘못된 방향으로 이동한다. 그래서 운영환경에서는 경고 발생 → 사람의 검토 → 결과 축적 → 모델 성능평가 → 필요 시 재학습 → 검증 후 배포 같은 관리절차를 두는 편이 안전하다. AI가 스스로 공장의 ’정상’을 계속 바꾸게 두는 것과, 데이터가 축적되면서 관리자가 모델을 개선하는 것은 다른 이야기다.

Recipe나 설비가 바뀌면 모델도 다시 봐야 한다

공정개선으로 Recipe가 변경되거나, 새 설비를 설치하거나, 센서 위치를 바꾸거나, 생산속도를 높이면 기존 모델이 학습한 정상패턴과 현재 공정이 달라진다. 이것을 Model Drift 또는 Data Drift 관점에서 검토할 수 있다. 모델 성능이 떨어졌다고 반드시 AI 자체가 나빠진 건 아니다 — 공장이 바뀌었는데 모델은 과거 공장을 보고 있는 것일 수도 있다. 그래서 제조 AI에서는 모델 Version과 함께 적용기간·대상제품·공정조건을 관리해야 한다.

처음부터 모든 공정에 AI를 붙일 필요는 없다

품질 이상탐지를 도입한다면 한 공정에서 시작하는 편이 현실적이다 — 데이터가 이미 자동수집되고, 품질과 관련성이 높으며, 과거 데이터가 충분하고, 이상 발생 시 사람이 확인할 수 있는 공정을 고른다. 그리고 먼저 Rule 기반 관리가 충분한지 확인하고, 그다음 추세나 다변량 관계에서 추가 신호가 필요한지 보고, AI가 실제로 기존 관리보다 빨리 의미 있는 이상후보를 찾는지 검증한다. 효과가 확인된 뒤 다른 공정으로 확장한다. AI를 설치한 공정의 개수보다 중요한 건 AI 경고가 실제 품질관리 Workflow 안에서 사용되고 있는가다.

품질 AI의 성과를 ‘불량률 감소’ 하나로만 평가하기도 어렵다

AI 도입 전 불량률이 2%였는데 도입 후 1.5%가 됐다면 좋은 결과처럼 보이지만, 같은 기간에 원재료가 바뀌었거나 설비개선이 있었을 수도 있다. 반대로 불량률이 그대로여도 AI가 문제 Batch를 더 빨리 찾아 격리범위를 줄였다면 운영효과가 있다. 그래서 품질 AI는 상황에 따라 의미 있는 경고의 비율 · 조기탐지 시간 · 조사에 걸리는 시간 · 반복이상 감소 · 영향 Batch 특정시간 · 담당자의 경고처리량 같은 지표를 함께 본다. AI가 품질을 직접 만들어내는 게 아니라 품질관리의 판단속도와 조사범위를 개선하는 도구이기 때문이다.

가장 좋은 경고는 ’빨간불’이 아니라 다음 행동을 알려주는 경고다

“이상 발생”만 뜨면 담당자는 다시 여러 화면을 찾아야 한다. 조금 더 실무적인 경고라면 이렇게 보여줄 수 있다.

제품 A / Batch 20260831-03 / 설비 2호기
14:32부터 온도와 설비속도 조합이 최근 정상 Batch 범위에서 벗어남
현재 회사 관리기준 이탈 없음 / 관련 완제품 출하 전 / 확인 필요

이 정도만 있어도 담당자가 무엇을 확인해야 할지 훨씬 명확하다. 여기에 생산 Batch를 클릭해 실제투입 LOT·공정기록·검사결과까지 내려갈 수 있다면 별도의 AI 화면을 만들 필요도 줄어든다. 통합 제조시스템에서 AI 기능을 생산·품질·LOT 데이터와 연결해야 하는 이유도 여기 있다 — AI 자체보다 경고 이후의 Workflow가 중요하기 때문이다.

AI가 찾은 이상은 품질관리의 시작점이지 판정의 끝이 아니다

다시 처음 화면으로 돌아가면 — “공정 이상 가능성 87%” 이 숫자 하나로는 아무것도 확정할 수 없다. 먼저 87이 무엇을 의미하는지 알아야 하고, 어떤 제품·공정의 데이터인지 확인하고, 회사 기준이나 CCP 한계기준을 실제로 벗어났는지 별도로 보고, 어떤 변수가 평소와 달랐는지 확인하고, 관련 Batch와 LOT를 찾고, 필요하면 담당자가 조사한다. 그 결과 실제 문제가 확인되면 회사의 부적합관리 절차에 따라 조치하고, 문제가 아니라면 정상변동이나 오탐으로 기록한다.

이 과정을 거치고 나면 AI의 역할이 분명해진다. AI는 제품의 안전을 선언하는 시스템이 아니고, HACCP 한계기준을 대신 만드는 시스템도 아니며, 품질담당자의 책임을 대신 지는 시스템도 아니다. 수많은 정상 데이터 사이에서 평소와 다른 몇 개를 먼저 찾아 품질담당자가 확인해야 할 범위를 좁혀주는 시스템이다.

그래서 제조업 품질 AI를 시작한다면 첫 질문을 “불량을 AI로 예측할 수 있는가?“보다 조금 다르게 잡는 편이 좋다. “우리 품질담당자가 매일 확인하는 수많은 데이터 가운데, 정말 먼저 봐야 할 몇 개를 시스템이 골라줄 수 있는가?” 그 질문부터 해결하면 이상탐지는 과장된 ’AI 품질판정’이 아니라 실제 현장에서 쓸 수 있는 품질관리 도구가 된다.

참고 — CCP 한계기준·품질판정은 AI가 대신 정하거나 확정할 수 없으며 HACCP 계획·관련 법령을 따른다. 실제 적용은 식품안전나라와 관할 기준으로 확인한다.