Decision Ready: 공장 AI가 운영자를 움직이려면 먼저 증명할 조건과 신뢰 지표

공장 AI의 성패는 모델 정확도보다 운영자가 그 추천을 실제로 따르느냐로 갈립니다. 그러려면 AI를 넣기 전에 설명 시간, 오판 비용, 채택률의 기준선을 재고 관찰에서 자율 실행까지 단계마다 증명할 것을 정해 두어야 합니다.

요약

IIoT World의 Paul Viorel은 2026년 10월 30일 Industrial AI Summit 2026 패널 토론을 정리했습니다. 진행은 IIoT World의 Jeff Winter가 맡았고 Arch Systems의 Tim Burke, Velotic의 Abby Eon, LG CNS의 Bryce Barnes, AOI의 Sahil Yadav가 나왔습니다. 출발점은 숫자입니다. Parsec 조사에서 제조사 72%가 어떤 형태로든 AI를 들였지만 규모 있게 배포한 곳은 10%였습니다. Grant Thornton 조사에서는 AI 사고 대응 계획을 실제로 시험해 본 곳이 7%였습니다. 패널은 이 차이를 신뢰 문제로 보고 운영자가 AI의 답을 믿고 행동하기 전에 무엇이 증명돼야 하는지를 다뤘습니다.

기사가 인용한 두 조사의 수치

패널의 답은 AI ready(모델이 답을 낼 수 있는 상태)와 decision ready(누군가 그 답으로 생산 일정을 바꾸거나 정비 인력을 보내거나 품질 공정을 고치는 상태)를 나누는 데서 시작합니다. 기술적으로 맞는 답도 아무도 믿지 않으면 쓰이지 않습니다. 이 간극을 메우려고 패널은 AI가 운영에 영향을 주기 전 갖출 다섯 조건, 정확도 대신 운영 성과로 신뢰를 재는 세 지표, 관찰에서 자가 복구까지 네 단계의 자율 사다리를 내놓았습니다. 투자는 전사 아키텍처에 묶어 작게 시작하라고 권합니다. 아래에서는 이 다섯 장치를 차례로 풀고 실제로 돌릴 때 필요한 기술·현업 디테일을 덧붙입니다.

답을 내는 것과 그 답으로 사람이 움직이는 것 사이

핵심 메커니즘

Five Conditions: 운영에 영향을 주기 전 갖출 다섯 조건

기사는 AI가 운영 판단에 끼어들기 전에 다섯 가지를 갖춰야 한다고 정리합니다. 실제 데이터에 근거할 것(grounded), 그 현장의 운전 맥락에 맞을 것(contextual), 만들지 않은 사람에게도 설명될 것(explainable), 소유자와 정책이 분명할 것(governed), 행동 범위가 미리 정해져 있을 것(bounded)입니다. 다섯 조건은 체크리스트처럼 쓰입니다. 하나라도 비면 답이 맞아도 운영자가 움직일 근거가 없습니다. 기사는 AI가 어울리는 곳도 좁혀 둡니다. 데이터가 잘 정리돼 있고 고장 유형이 알려진 문제에는 맞습니다. 반대로 어떤 데이터에도 담기지 않는 판단이 필요한 문제는 다른 분석 방법이나 사람의 결정이 더 싸고 낫습니다. 도입 실적을 채우려고 AI를 끼워 넣으면 비용만 늘어납니다. 가상 예시를 들면, 설비 진동 이상 탐지는 다섯 조건을 맞추기 쉽지만 신제품 첫 양산의 공정 조건 결정은 숙련자 판단에 맡기는 편이 낫습니다.

다섯 조건. 패널은 여기에 불확실성 신호를 가장 중요하게 꼽음

Uncertainty Signal: 모를 때 모른다고 말하는 모델

Velotic의 Abby Eon은 다섯 조건 가운데 불확실성을 알리는 능력을 가장 중요하게 꼽았습니다. 센서가 0을 읽은 것과 센서가 고장 난 것은 다른 일인데, 이 둘을 가르지 못하는 모델은 틀린 지시를 확신에 차서 내립니다. Eon의 말로는 “Operators do not trust systems that are always sure.”입니다. 작동 방식은 단순합니다. 입력 데이터의 상태를 먼저 판정하고 상태가 의심스러우면 추천 대신 판단 보류와 그 이유를 내보냅니다. 기사는 2절에서도 같은 원칙을 되풀이합니다. 자기 불확실성을 드러내는 모델이 늘 확신에 차 있다가 가끔 조용히 틀리는 모델보다 더 신뢰를 얻는다고 봅니다. 센서가 많고 통신이 끊기기 쉬운 현장일수록 이 장치가 먼저입니다.

Velotic의 Abby Eon이 든 센서 예시

Three Trust Metrics: 정확도 대신 운영 성과로 재는 신뢰

AOI의 Sahil Yadav는 운영 책임자에게 모델 정확도는 알고리즘에 관한 숫자일 뿐이라고 보고 운영 성과를 재는 세 지표를 제안했습니다. Mean time to explanation(설명까지 걸리는 평균 시간)은 사람이 추천의 이유를 이해하고 재구성하는 데 드는 시간입니다. 이 시간이 결정 시한보다 길면 그 추천은 운영에서 쓸모가 없습니다. Trust-adjusted risk(신뢰 보정 위험)는 AI가 틀렸을 때의 결과를 평판, 공급망 차질, 규제, 법적 책임까지 포함해 금액으로 매긴 값입니다. AI를 따를 때와 무시할 때의 위험을 숫자로 비교하게 만듭니다. Adoption rate(채택률)는 운영자가 실제로 따른 추천의 비율입니다. 정확도는 높은데 채택률이 낮으면 기술 개선으로는 닫히지 않는 신뢰 간극이 있다는 신호입니다. 기사는 세 지표의 기준선을 AI 도입 전에 재고 시험 사례는 운영 책임자가 고르라고 권합니다.

AOI의 Sahil Yadav가 제안한 세 지표

Autonomy Ladder: 관찰에서 자가 복구까지 네 단계

기사는 AI의 권한을 네 단계로 나누고 단계마다 증명할 것을 붙였습니다. 1단계 Observe에서 AI는 감시하고 보여 주기만 하며 데이터가 운영 현실을 정확히 비추는지를 증명합니다. 2단계 Recommend에서는 행동을 제안하고 사람이 라벨을 붙인 실제 과거 사고로 따졌을 때 얼마나 정확한지를 보여야 합니다. 3단계 Act with supervision은 사람 승인 뒤 실행하는 단계로, circuit breaker(이상 시 자동으로 멈추는 차단 장치), 빠짐없는 감사 기록, 설명 가능성, 잘못돼도 피해가 퍼지는 범위(blast radius)를 좁혀 두는 장치가 필요합니다. 4단계 Self-heal은 자율 실행으로, 오래 쌓인 실적, 모든 행동의 되돌림 가능성, 승인된 한도 안의 trust-adjusted risk가 조건입니다. 사다리는 한 칸씩 오르는 구조라서 앞 단계의 증명 없이 다음 단계로 건너뛰지 않습니다.

기사의 자율 사다리를 다시 그린 것

Architecture-first Investment: 아키텍처에 묶어 사례 하나부터

Arch Systems의 Tim Burke는 AI 투자를 기술 과제 단독으로 두지 말고 전사 아키텍처 계획에 묶을 때 정당화하기 쉽다고 봅니다. 순서는 합의된 아키텍처에 맞추고 이미 깔린 시스템 한두 개를 통합하고 그 기반 위에서 사용 사례 하나를 냅니다. 기사는 반대 사례로 IT 부서만 3년 동안 데이터 통합을 붙잡고 끝에 모든 문제를 풀겠다고 약속하며 중간에 아무것도 내놓지 못하는 방식을 듭니다. 3년 전망도 같은 결입니다. 생성형 AI는 운영 판단을 고르고 보여 주는 방식을 바꾸겠지만 결정은 사람이 계속 쥡니다. 언어 모델은 다음 토큰을 예측하고 제조 제어는 결정론적 결과가 필요하므로 둘이 맞물리는 데 시간이 걸립니다. 로트가 작아지고 공정 변경이 잦아지면 AI는 어떤 결정론적 워크플로를 돌릴지 골라 운영자에게 제시하는 역할을 맡게 됩니다.

Arch Systems의 Tim Burke가 말한 투자 순서

통념과 다른 주장

흔히 이렇게 봅니다모델 정확도가 충분히 높으면 현장은 AI를 믿고 씁니다.

패널은 이렇게 봅니다운영 책임자에게 필요한 것은 운영 성과입니다. 신뢰는 설명 시간, 오판 비용, 실제로 따른 비율로 잽니다.

근거정확도가 높아도 채택률이 낮으면 기술 개선으로 닫히지 않는 신뢰 간극이 있다는 신호라고 Yadav는 설명합니다.

흔히 이렇게 봅니다AI를 더 많은 업무에 넣을수록 앞서 나갑니다.

패널은 이렇게 봅니다데이터가 정리돼 있고 고장 유형이 알려진 문제에만 맞습니다. 도입 실적용으로 끼워 넣으면 비용만 늘어납니다.

근거데이터에 담기지 않는 판단이 필요한 문제는 다른 분석 방법이나 사람의 결정이 더 싸고 낫다고 봅니다.

흔히 이렇게 봅니다확신 있게 답하는 모델이 믿음직합니다.

패널은 이렇게 봅니다자기 불확실성을 드러내는 모델이 더 신뢰를 얻습니다.

근거센서 값 0과 센서 고장을 가르지 못하면 틀린 지시를 확신에 차서 내린다는 Eon의 예시가 근거입니다.

왼쪽은 흔한 통념, 오른쪽은 패널의 시각

저자가 든 사례

사례 1. AOI의 베테랑 엔지니어

상황	한 일	결과	연결
AOI에서 경험이 가장 많은 엔지니어들이 가장 회의적이었음	지루하고 반복적이지만 핵심이 아닌 작업부터 AI에 맡김	반복 작업이 줄면서 신뢰가 쌓임. 어떤 작업이었는지는 원문에서 밝히지 않음	Autonomy Ladder, Three Trust Metrics

사례 1. AOI의 베테랑 엔지니어

사례 2. 확산을 막는 가장 큰 장벽, 네 가지 답

상황	한 일	결과	연결
확산을 막는 가장 큰 장벽 하나를 물음	패널 네 명이 각자 답함	조직(Burke), 맥락(Eon), 데이터(Barnes), 신뢰(Yadav). 먼저 키울 사례로는 품질 근본 원인 분석, 다운타임 원인 귀속, 업무 보조, 예지 정비가 나옴(누가 어느 것을 꼽았는지는 원문에서 밝히지 않음)	Five Conditions, Architecture-first Investment

사례 2. 확산을 막는 가장 큰 장벽, 네 가지 답

기술 디테일: 실제로 돌릴 때 필요한 것

아래 필드명, 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. 패널이 말한 조건과 지표를 실제로 돌릴 때 필요한 것을 정리했습니다.

불확실성 신호(Uncertainty Signal)를 넣으려면 모델 앞에 센서 상태 판정 단계를 따로 둡니다. 태그마다 마지막 갱신 시각, 같은 값이 얼마나 이어졌는지, 설계 범위를 벗어났는지를 규칙으로 검사해 data_quality를 ok·suspect·fail로 매깁니다. 예를 들어 값 0이 15분 넘게 그대로이고 같은 설비의 전류 태그는 움직인다면 suspect입니다. suspect 이상이 하나라도 있으면 모델은 추천을 내지 않고 abstain=true와 이유를 냅니다. LLM으로 설명 문장을 만든다면 temperature 0, JSON 스키마 강제로 돌리고 수치 판단은 LLM이 아니라 앞단의 규칙과 통계 모델이 맡습니다.

불확실성 신호를 출력에 넣는 구조 (가상 예시)

세 지표(Three Trust Metrics)를 재려면 추천 하나를 한 행으로 남기는 로그부터 만듭니다. 화면에 뜬 시각, 운영자가 근거를 열어 본 시각, 행동을 정한 시각을 남기면 설명 시간을 잴 수 있습니다. 채택률은 (accepted + modified) ÷ 노출 건수로 계산합니다. trust-adjusted risk는 결정 유형마다 오판 확률과 오판 비용(평판·공급망·규제·법률 네 항목의 금액 합)을 곱해 구합니다. 오판 확률은 사람이 라벨을 붙인 과거 사고로 백테스트해 정합니다.

{
  "rec_id": "R-20261105-0217",
  "decision_type": "line_stop",
  "decision_window_min": 15,
  "data_quality": "ok",
  "confidence": 0.82,
  "abstain": false,
  "evidence": ["진동 RMS 3일 연속 상승", "유사 사고 2025-07 베어링 손상"],
  "shown_at": "2026-11-05T09:12:04+09:00",
  "explanation_opened_at": "2026-11-05T09:12:40+09:00",
  "decided_at": "2026-11-05T09:16:10+09:00",
  "operator_action": "accepted",
  "reason_code": null,
  "expected_loss_krw": 42000000,
  "autonomy_tier": 2
}

정확도와 채택률을 함께 보는 진단표 (가상 예시)

자율 단계(Autonomy Ladder)를 시스템으로 묶으려면 단계를 코드 설정으로 둡니다. 결정 유형마다 autonomy_tier를 정하고 3단계 실행 도구는 승인 ID가 없으면 거절합니다. circuit breaker는 설정값 변경 폭(예: 한 번에 ±5% 이내), 시간당 실행 횟수, 연속 실패 2회 같은 조건으로 걸어 둡니다. 4단계로 올릴 결정 유형은 모든 행동에 되돌림 절차(rollback_action)가 등록돼 있어야 합니다. 감사 기록은 위 로그에 model_version, rule_version, approved_by를 더하면 됩니다.

실패하는 경우	대응 (가상 예시)
센서 통신 끊김을 정상 0으로 읽음	갱신 시각과 연관 태그 교차 검사, `suspect`면 판단 보류
정확도는 높은데 운영자가 추천을 무시	거절 사유 코드 집계, 설명 카드의 근거를 3개 이내로 줄임
설명을 읽는 데 결정 시한보다 오래 걸림	유사 과거 사고 1건을 맨 위에 보여 주는 형식으로 바꿈
3단계 실행이 연쇄 오류를 냄	circuit breaker로 자동 정지, 2단계로 강등 후 원인 분석

현업 실행 디테일: 누가, 언제, 무엇을

결정 유형 하나를 골라 decision ready까지 끌어올리는 시범을 기준으로 정리했습니다. 역할, 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
운영 책임자(공장장·생산 담당 임원)	시험 사례 선정, 단계 승격 승인, trust-adjusted risk 한도 결정
교대 반장·운영자	추천을 따르거나 거절하고 사유 코드 입력, 주 1회 피드백
보전·품질 엔지니어	과거 사고 라벨링, 다섯 조건 중 contextual 검토
데이터·AI 엔지니어	센서 상태 판정, 추천 로그, circuit breaker 구현
아키텍트	전사 아키텍처와의 정합, 통합할 기존 시스템 1~2개 지정
리스크·법무	오판 비용 네 항목의 금액 기준 확정

시작 전 준비물은 네 가지입니다. 최근 12개월 사고·고장 기록(사람이 원인을 붙인 것), 결정 유형별 결정 시한 목록, 이미 쓰는 시스템 목록(MES·CMMS·히스토리안 등), AI 없이 지금 판단할 때의 설명 시간과 판단 결과 기준선입니다.

기간	할 일	산출물
1~2주	결정 유형 하나 선정, AI 없이 세 지표 기준선 측정, 운영 책임자가 시험 사례 20건 선정	기준선 보고서, 시험 사례 세트
3~4주	Observe 단계 운영, 데이터 그림과 현장 실제를 매일 대조	불일치 목록, 센서 상태 규칙
5~6주	Recommend 단계 그림자 운영, 추천 로그로 세 지표 측정	세 지표 주간표, 거절 사유 집계
7~8주	판정 회의, 3단계 승격·2단계 유지·중단 결정	판정 보고서, 다음 결정 유형 후보

8주 시범 일정 (가상 예시)

확인 질문은 이렇게 준비합니다. 이 결정은 몇 분 안에 내려야 합니까? 지금은 누가 무엇을 보고 결정합니까? AI가 틀리면 돈, 고객, 규제 측면에서 무엇이 걸립니까? 센서가 고장 났을 때 지금은 어떻게 알아챕니까? 추천을 거절한다면 주로 어떤 이유 때문입니까? 어떤 행동은 되돌릴 수 없습니까?

진행 판정 기준은 결정 유형마다 다시 정하되, 출발점은 아래 표와 같습니다. 하나라도 미달이면 단계를 올리지 않고 2주를 더 봅니다.

다음 단계로 올리는 판정 기준 (가상 예시)

AX 적용 제언. 국내 제조사가 이 패널에서 가져갈 것은 지표의 순서입니다. AI를 넣기 전에 설명 시간, 오판 비용, 채택률의 기준선을 재 두면 도입 뒤 성과 논쟁이 정확도가 아니라 운영 언어로 정리됩니다. 첫 대상은 AOI 사례처럼 지루하고 반복적이며 틀려도 되돌릴 수 있는 일이 좋고 패널이 꼽은 다운타임 원인 귀속이나 품질 근본 원인 분석이 후보입니다. 과제는 전사 아키텍처 계획 안에 두고 이미 쓰는 MES나 보전 시스템 한두 개를 묶는 데서 시작합니다. 자율 단계는 결정 유형마다 따로 매기고 3단계 이상은 circuit breaker와 되돌림 절차가 준비된 유형에만 엽니다. 이렇게 하면 첫 유형에서 만든 추천 로그와 판정 기준을 다음 유형에 그대로 쓸 수 있습니다.

원문 사례

항목	내용
원문	IIoT World, Paul Viorel, 2026.10.30. Arch Systems 후원, 편집 독립 표기
행사	Industrial AI Summit 2026 패널, 진행 Jeff Winter(IIoT World)
패널	Tim Burke(Arch Systems), Abby Eon(Velotic), Bryce Barnes(LG CNS), Sahil Yadav(AOI)
조사 수치	Parsec 2026: AI 도입 72%, 규모 있는 배포 10%. Grant Thornton 2026: 운영에 AI 집중 62%, 사고 대응 계획 시험 7%, 독립 거버넌스 감사 통과 자신 12%
다섯 조건	grounded, contextual, explainable, governed, bounded. Eon은 불확실성 신호를 가장 중요하게 꼽음
세 지표	Mean time to explanation, trust-adjusted risk, adoption rate(Yadav 제안). 도입 전 기준선, 시험 사례는 운영 책임자가 선정
자율 단계	Observe, Recommend, Act with supervision, Self-heal
3년 전망	생성형 AI가 판단을 고르고 제시하는 방식을 바꾸되 결정은 사람이 유지
투자 순서	아키텍처 합의, 기존 시스템 1~2개 통합, 사용 사례 하나(Burke)
가장 큰 장벽	조직(Burke), 맥락(Eon), 데이터(Barnes), 신뢰(Yadav)
먼저 키울 사례	품질 근본 원인 분석, 다운타임 원인 귀속, 업무 보조, 예지 정비
과대평가된 것	휴머노이드 로봇, 지저분한 데이터 위의 코파일럿, 대형 언어 모델 자체, 현장 자율 에이전트

핵심 개념

decision window: 어떤 판단을 내려야 하는 시한입니다. 설명 시간이 이보다 길면 추천은 쓸모가 없어집니다.
circuit breaker: 이상 조건이 감지되면 AI의 실행을 자동으로 멈추는 장치입니다.
blast radius: AI 행동이 잘못됐을 때 피해가 미치는 범위입니다. 3단계부터 좁혀 두어야 합니다.
deterministic workflow: 같은 입력이면 늘 같은 결과를 내는 정해진 처리 절차입니다.
downtime attribution: 설비가 멈춘 시간을 원인별로 나눠 귀속시키는 분석입니다.
quality root causing: 품질 불량의 근본 원인을 데이터로 추적하는 일입니다.

내 메모

TODO: 내 생각 추가

원문은 IIoT World의 「What AI Must Prove Before Operators Act」(Paul Viorel, 2026.10.30 게재, Industrial AI Summit 2026 패널 정리)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.

Decision Ready: 공장 AI가 운영자를 움직이려면 먼저 증명할 조건과 신뢰 지표

요약

핵심 메커니즘

Five Conditions: 운영에 영향을 주기 전 갖출 다섯 조건

Uncertainty Signal: 모를 때 모른다고 말하는 모델

Three Trust Metrics: 정확도 대신 운영 성과로 재는 신뢰

Autonomy Ladder: 관찰에서 자가 복구까지 네 단계

Architecture-first Investment: 아키텍처에 묶어 사례 하나부터

통념과 다른 주장

저자가 든 사례

사례 1. AOI의 베테랑 엔지니어

사례 2. 확산을 막는 가장 큰 장벽, 네 가지 답

기술 디테일: 실제로 돌릴 때 필요한 것

현업 실행 디테일: 누가, 언제, 무엇을

원문 사례

핵심 개념

내 메모

함께 읽으면 좋은 노트

Can It Say Why: 이유를 대지 못하는 공급망 AI 점수로는 누구도 결정하지 못한다

More AI Power, More Explainability: 모델이 강해질수록 설명도 두꺼워지게 만드는 설계 원칙

The Architecture Your Auditors Will Ask About: 공급망 AI 구매 평가의 통과 조건이 된 감사 추적 설계