Pilot to Production: 공장 AI 시범이 운영 직전에 멈추는 이유와 데이터 준비 3문항

공장 AI 시범이 운영 문턱에서 멈추는 까닭은 기술보다 데이터 준비, 소유권, 운영 비용 쪽에 있습니다. 시범을 고르기 전에 데이터 3문항으로 대상을 거릅니다. 지표마다 책임질 사업 오너 한 명과 운영 견적까지 정해 두어야 시범이 운영으로 넘어갑니다.

요약

IIoT World의 Paul Viorel은 2026년 11월 2일 Industrial AI Summit 2026의 패널 토론을 정리했습니다. 패널은 Strategy of Things의 Benson Chan, Siemens의 Flemming Kongsberg, NeoAI의 Maddie Zeng, Cumulocity의 Jonathan Weiss이고 사회는 Strategy of Things의 Yash Titus가 맡았습니다. Chan은 시범(pilot)을 빙산의 보이는 끝에 빗댔습니다. 약 2만 달러짜리 시범은 누군가 건넨 스프레드시트와 API 한두 개로 좁은 범위에서 돌아갑니다. 수면 아래에는 사이버보안, 버전이 제각각인 노후 설비, MES·ERP 통합, 교육, 현장의 저항이 기다립니다. 기사는 나머지 구조적 문제를 Kongsberg, Zeng, Weiss의 지적으로 묶었고, 어느 발언이 누구의 것인지는 나누지 않았습니다.

패널의 처방은 데이터에서 출발합니다. 착수할 업무를 고를 때 데이터가 있는지, 믿을 수 있는지, 이미 누가 쓰고 있는지 세 가지를 묻습니다. 셋 다 그렇다면 AI의 바탕이 있는 것이고, 데이터가 맞는지 아직 논쟁 중이라면 AI보다 데이터 정비가 먼저입니다. 시범이 데모에서 멈추는 구조적 원인으로는 소유권이 불분명한 것, 자사 데이터 없이 범용 모델에 기대는 것, 빠르게 만든 시제품을 운영 시스템으로 착각하는 것 세 가지를 꼽았습니다. 노후 공장(brownfield)은 안 되고 신규 공장(greenfield)은 준비됐다는 생각도 둘 다 틀렸다고 봅니다. 아래에서는 이 내용을 여섯 가지 메커니즘으로 나눕니다. 이어서 실제로 착수 판정을 내릴 때 필요한 기술·현업 디테일을 덧붙입니다.

핵심 메커니즘

Pilot Iceberg: 시범 아래 숨은 운영 요구

시범은 검증만 하도록 예산이 잡혀 있어서 데이터는 정제된 파일로 받고, 통합은 최소로 하며, 지름길을 허용합니다. 운영으로 넘어가면 이 생략이 그대로 청구서가 됩니다. 무엇이 무엇에 연결될 수 있는지 정하는 보안 정책, 같은 공장 바닥에서도 소프트웨어 버전이 다른 설비, 지속적인 엔지니어링이 드는 MES·ERP·스케줄링 통합이 붙습니다. 작업자 결근과 계획에 없던 정비가 같은 교대에 겹치는 일도 운영에서는 일상입니다. 거버넌스, 리스크 관리, 교육 요구는 차례로 쌓입니다. 패널은 운영 비용이 시범 투자의 몇 배가 되고 기간도 훨씬 길다고 봅니다. 확장 질문을 시범 뒤로 미룬 회사는 그제야 인프라 현대화, 재교육, 업무 재설계가 먼저라는 것을 알게 됩니다. 가상 예시를 들면, 설비 진동 데이터를 CSV로 받아 고장을 예측한 시범이 있습니다. 정확도가 좋아도 운영에서는 OT 보안 승인, 실시간 연결, 정비 시스템 연동을 새로 해야 합니다.

Data Readiness 3 Questions: 착수 대상을 거르는 세 질문

세 질문 가운데 패널이 가장 무겁게 보는 것은 마지막 질문, 누가 이미 그 데이터를 쓰고 있느냐입니다. 한 팀이 ERP, 이메일, 현장 메모, 문서에서 정보를 손으로 모으고 있다면 데이터는 쓸 수 있는 형태로 이미 존재합니다. 남은 일은 원천을 연결하고 형식을 맞추는 것이고, 패널은 이것이 지금의 AI 도구가 잘하는 일이라고 봅니다. 데이터가 아예 없다면 현대화가 먼저입니다. 다만 모든 것을 현대화한 뒤에 시작하겠다고 기다리면 과제가 끝나지 않을 수 있습니다. 그래서 패널은 데이터가 이미 흐르는 업무를 골라 거기서부터 쌓으라고 권합니다. 가상 예시로, 품질팀이 매주 불량 기록과 설비 메모를 엑셀로 모아 보고한다면 그 업무가 첫 후보입니다.

Single Owner: 부서 경계에서 멈추지 않게 하는 한 사람

패널의 표현으로는 “Unclear ownership kills more AI projects than technical failure”입니다. AI가 개선하려는 지표를 책임지는 사업 오너가 한 명도 없으면 운영 전환을 자기 일로 여기는 사람이 없습니다. 설계, 제조, 운영에 걸친 과제는 세 기능을 건드리고 기능마다 리더가 따로 있습니다. 부서마다 자기 지표만 최적화하면 통합, 거버넌스, 변화 관리를 밀어붙일 사람이 없어 과제가 부서 경계에서 멈춥니다. 패널이 내놓은 답은 세 기능 전체의 결과를 책임지는 한 사람입니다. 가상 예시로, 신제품 수율 개선 과제라면 설계팀장, 생산팀장, 설비팀장 가운데 한 명을 수율 지표의 오너로 정하고 나머지 둘은 협조 의무를 집니다.

Generic Model Trap: 범용 모델만으로는 차별화가 안 되는 이유

대형 AI 연구소의 범용 모델을 그대로 제조 공정에 쓰면 같은 모델을 쓰는 경쟁사와 같은 능력을 얻습니다. 패널은 마케팅 문구나 사내 소통에는 범용 모델로 충분하지만 차별화된 제조 성과에는 모자란다고 봅니다. 차이를 만드는 것은 자사 운영 데이터, 도메인 지식, 공정별 학습을 모델에 더하는 일입니다. 데이터 3문항과 이어지는 지점이기도 합니다. 자사 데이터가 준비돼 있어야 범용 모델 위에 차별화를 쌓을 수 있습니다.

Prototype ≠ Production: 데모와 운영 시스템의 거리

코드 어시스턴트나 챗봇 세션에서 만든 데모도 그럴듯하게 돌아갑니다. 패널은 돌아가는 데모가 엔터프라이즈급 소프트웨어는 아니라고 선을 긋습니다. 규정을 지키고, 거버넌스 아래 놓이고, 기존 시스템과 통합된 형태로 키우려면 상당한 엔지니어링이 필요합니다. 실제로 돌릴 때는 시범 결과 보고에 운영 전환 견적을 함께 붙입니다. 그러면 경영진이 데모를 보는 자리에서 운영 일정과 비용도 함께 판단합니다.

Brownfield vs Greenfield: 오래된 공장과 새 공장의 다른 오해

기존 공장에서는 센서가 범용품이 됐고, PLC가 없는 설비도 저렴하게 후장착할 수 있습니다. 직렬 포트, USB 같은 옛 인터페이스용 어댑터가 있어 40~50년 된 설비에서도 데이터를 뽑을 수 있고, 연결 비용은 10년 전보다 낮습니다. 데이터는 여러 형식과 시스템에 흩어져 있어도 그것을 쓰는 팀이 있는 경우가 많습니다. 신규 공장은 반대입니다. 최신 Siemens나 Allen-Bradley PLC가 MQTT로 데이터를 내보내도, 한 공장 안에 PLC 제조사와 MES 소프트웨어가 섞여 있습니다. 표준화는 기대만큼 되지 않고, 서류상 간단해 보이는 통합에도 엔지니어링이 많이 듭니다. 패널의 결론은 어느 쪽도 시작을 미룰 이유가 없다는 것이고, 판단 기준은 공장 연식이 아니라 데이터가 있고 누가 쓰고 있느냐입니다.

통념과 다른 주장

저자가 든 사례

사례 1. 연결된 설비가 하나도 없는 공장

상황	한 일	결과	연결
설비 16~20대가 어떤 시스템에도 연결되지 않음. 25년 경력 작업자가 기록 없이 운영. 스크랩은 교대 끝에 폐기통을 눈으로 보고 판단	패널이 데이터가 없는 경우의 예로 듦	AI보다 현대화가 먼저인 경우. 이후 진행은 원문에서 밝히지 않음	Data Readiness 3 Questions

사례 2. 약 2만 달러 시범이 운영에서 맞는 비용

상황	한 일	결과	연결
시범 예산은 보통 1만~3만 달러. 기사의 예는 약 2만 달러	스프레드시트와 API 1~2개, 좁은 범위로 검증	운영에는 보안, 통합, 거버넌스, 교육, 레거시 호환이 붙어 시범의 몇 배 비용과 훨씬 긴 기간. 구체 금액은 원문에서 밝히지 않음	Pilot Iceberg

사례 3. 40~50년 된 설비에 데이터 연결 붙이기

상황	한 일	결과	연결
디지털 제어 이전 세대의 노후 설비	저렴해진 센서와 직렬 포트·USB 어댑터로 후장착	누가 이미 운영 데이터를 모아 쓰고 있다면 예지 정비·품질 모니터링 가능	Brownfield vs Greenfield

기술 디테일: 착수 판정을 데이터로 내리려면

아래 필드명, 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. 패널의 기준을 실제로 돌릴 때 필요한 것을 정리했습니다.

데이터 3문항을 점검표로 돌리려면 후보 업무마다 원천 목록과 최근 30일치 샘플을 받습니다. 첫째 질문(있나)은 원천별 결측률과 수집 주기로 봅니다. 둘째 질문(믿을 수 있나)은 값 범위와 단위 검사를 자동으로 돌린 뒤, 현장 기록 10건을 골라 사람이 실제 값과 대조합니다. 셋째 질문(누가 쓰나)은 자동으로 알 수 없으므로 인터뷰로 채우고 사용자 이름과 업무를 남깁니다. LLM은 인터뷰 메모를 아래 JSON으로 정리하는 데만 쓰고 temperature 0으로 스키마를 강제합니다. 판정(verdict)은 LLM이 아니라 규칙이 냅니다. 세 값이 모두 yes면 go, available이 no면 no-go, 그 밖에는 fix입니다.

{
  "use_case_id": "UC-07",
  "use_case": "프레스 라인 금형 마모 예측",
  "sources": [
    {"name": "PLC 사이클 카운트", "missing_rate": 0.03, "interval_s": 1},
    {"name": "정비 이력(ERP)", "missing_rate": 0.18, "interval_s": null}
  ],
  "available": "yes",
  "trusted": "yes",
  "trusted_check": {"field_samples": 10, "matched": 9},
  "already_used_by": "설비보전팀 주간 금형 교체 계획",
  "owner": "생산2팀장",
  "verdict": "go"
}

범용 모델에 자사 데이터를 더하려면 먼저 모델을 다시 학습시키기보다 검색 근거로 붙이는 쪽이 빠릅니다. 정비 이력, 작업표준, 불량 기록을 설비 ID와 공정 ID로 색인하고, 질문이 들어오면 같은 설비의 기록만 걸러 근거로 넣습니다. 출력은 답변, 근거 문서 ID, 확신 수준을 담은 JSON으로 받습니다. 차별화가 생겼는지는 현장 질문 50개와 숙련 작업자가 쓴 정답으로 만든 평가 세트로 잽니다. 근거 없이 범용 모델만 쓴 결과와 같은 세트로 비교하면 자사 데이터가 얼마나 보탰는지 숫자로 보입니다. 같은 질문을 3회 돌려 답이 갈리는 질문은 근거 문서가 부족한 곳이므로 데이터 정비 목록에 넣습니다.

시제품을 운영으로 올리려면 데모를 버리지 말고 네 군데를 바꿉니다. 개인 계정 대신 SSO와 역할별 권한을 붙입니다. 파일 업로드 대신 OT 네트워크에서 읽기 전용 게이트웨이로 데이터를 받습니다. 입력, 출력, 모델 버전, 프롬프트 버전을 요청마다 로그로 남깁니다. 설비 설정을 바꾸거나 작업 지시를 내는 출력은 사람 승인 없이 실행하지 않게 하고, 직전 버전으로 되돌리는 경로를 둡니다. 이 네 항목의 공수를 시범 끝에 견적으로 내면 패널이 말한 운영 비용의 몇 배가 실제 숫자로 바뀝니다.

실패하는 경우	대응 (가상 예시)
샘플은 깨끗한데 실시간 데이터는 결측이 많음	점검을 30일 샘플과 실시간 1주 두 번 하고, 결측률 차이가 5%p를 넘으면 fix
현장 대조에서 숫자가 실제와 다름	trusted=no로 두고 AI 착수 대신 계측·기록 방식부터 고침
인터뷰에서 데이터를 쓰는 사람이 안 나옴	셋째 질문 no. 더 쉬운 후보로 바꾸거나 수작업 사용부터 시작
범용 모델과 자사 데이터 버전의 점수 차이가 없음	근거 문서 색인 범위·설비 ID 매핑을 점검하고 평가 세트 질문을 현장 언어로 다시 씀
데모 시연 뒤 운영 견적 없이 확대 요구	네 가지 운영 항목 견적이 승인되기 전에는 대상 설비를 늘리지 않음

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

패널 기준으로 시범 착수를 판정한다면 시범 전에 6주를 씁니다. 아래 역할과 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
사업 오너(생산·품질 팀장 중 1명)	개선할 지표 1개를 책임, 착수·확대 판정
현장 데이터 사용자	지금 데이터를 손으로 모으는 사람. 데이터 정확성 확인, 인터뷰 응답
OT·IT 엔지니어	설비 연결 방법, 보안 정책 확인, MES·ERP 통합 견적
데이터·AI 엔지니어	3문항 점검 자동화, 평가 세트 작성, 시제품 강화 견적
교대 반장	작업자 교육 계획, 현장 반응 수집

시작 전 준비물은 후보 업무 3개와 업무별 원천 목록, 최근 30일치 샘플, 현재 손으로 만드는 보고서 사본, 개선하려는 지표의 현재 값입니다.

기간	할 일	산출물
1~2주	후보 3개에 데이터 3문항 점검, 데이터 사용자 인터뷰, 현장 대조 10건	후보별 readiness JSON
3~4주	go 후보의 운영 견적. 보안 승인, 설비 연결, MES·ERP 통합, 교육 공수	시범 예산과 운영 예산을 나란히 둔 견적서
5~6주	사업 오너 지정, 지표 목표 합의, 착수 판정 회의	착수·보류 결정, 시범 범위 문서

확인 질문은 이렇게 준비합니다. 이 데이터를 지금 누가, 어떤 보고서나 결정에 쓰고 있습니까? 지난달 숫자 중 현장 실제와 맞지 않았던 건이 있습니까? 이 업무가 설계, 제조, 운영 중 몇 부서를 건드리고, 결과 지표의 주인은 누구입니까? 이 시스템이 공장 네트워크의 어디에 연결돼야 하고, 보안 승인은 누가 합니까? 시범이 성공하면 운영 예산은 어느 계정에서 나옵니까?

진행 판정 기준은 세 가지에서 출발합니다. 데이터 3문항이 모두 예일 것, 지표 하나에 이름 하나가 붙은 사업 오너가 있을 것, 시범 예산과 운영 견적이 함께 승인될 것입니다. 하나라도 빠지면 시범을 시작하지 않고, 빠진 항목을 채우는 데이터 정비나 오너 지정부터 합니다.

AX 적용 제언. 국내 제조사의 AI 과제 목록을 이 기준으로 다시 걸러 보면 시범을 몇 개 했는지보다 몇 개가 운영 견적과 오너를 갖췄는지가 더 중요한 지표가 됩니다. 첫 대상은 품질이나 설비보전팀이 이미 엑셀로 모으는 보고 업무처럼 데이터가 흐르고 사용자가 분명한 곳이 좋습니다. 노후 공장이라고 후보에서 빼지 말고, 신규 공장이라고 점검을 건너뛰지 않습니다. 시범 품의서에는 운영 견적과 사업 오너 칸을 필수로 넣고, 범용 모델을 쓰는 과제는 자사 데이터를 무엇으로 더할지 한 줄을 반드시 적게 합니다. 이렇게 하면 데모가 빨리 나와도 확대 결정이 견적과 책임자 없이 내려지지 않습니다.

원문 사례

항목	내용
원문	IIoT World, Paul Viorel, 2026.11.2
출처 행사	Industrial AI Summit 2026 패널
패널	Benson Chan(Strategy of Things), Flemming Kongsberg(Siemens), Maddie Zeng(NeoAI), Jonathan Weiss(Cumulocity). 사회 Yash Titus(Strategy of Things)
빙산 비유	Benson Chan. 시범은 보이는 끝, 운영 요구는 수면 아래
시범 비용	기사 예시 약 2만 달러, 보통 1만~3만 달러
운영 비용	시범 투자의 몇 배, 기간도 훨씬 김
데이터 3문항	있나, 믿을 수 있나, 이미 누가 쓰나. 셋 다 예면 바탕이 있음
구조적 실패 원인	불분명한 소유권, 자사 데이터 없는 범용 모델, 시제품을 운영으로 착각
데이터 없는 공장 예	설비 16~20대 미연결, 작업자 25년 경력, 폐기통 육안으로 스크랩 판단
노후 설비	40~50년 된 설비도 어댑터로 데이터 추출, 예지 정비·품질 모니터링 가능
신규 공장	최신 PLC와 MQTT가 있어도 PLC 제조사·MES가 섞임

핵심 개념

pilot

좁은 범위와 작은 예산으로 AI가 효과를 내는지 검증하는 시범 단계입니다.

brownfield

이미 가동 중인 기존 공장. 설비 연식과 시스템이 섞여 있습니다.

greenfield

새로 짓는 공장. 최신 설비로 시작하지만 시스템이 하나로 통일돼 있다는 보장은 없습니다.

PLC

설비를 제어하는 산업용 컨트롤러입니다. 설비 데이터의 1차 원천입니다.

MES

제조 실행 시스템. 작업 지시, 실적, 품질 기록을 공장 단위로 관리합니다.

MQTT

설비와 센서가 데이터를 가볍게 주고받는 메시지 프로토콜입니다.

retrofit

기존 설비에 센서나 통신 어댑터를 덧붙여 데이터를 뽑는 일입니다.

내 메모

TODO: 내 생각 추가

원문은 IIoT World의 「Why AI Pilots Stall Before Production」(Paul Viorel, 2026.11.2 게재)이며, Industrial AI Summit 2026 패널 토론을 정리한 기사입니다. 기사는 빙산 비유만 Benson Chan의 발언으로 밝히고 나머지는 패널 전체의 의견으로 묶었으므로, 이 노트도 발언자를 따로 나누지 않았습니다. 요약, 핵심 메커니즘의 기사 내용, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.