요즘 제조업에서도 “AI 전환(AX)”이라는 말을 정말 많이 합니다.
그런데 현장에 들어가 보면, AI는 대개 이 흐름으로 흘러갑니다.
경영진: “우리도 빨리 AI 해야 한다. 경쟁사도 한다.”
현업: “지금도 바쁜데 데이터 정리까지요?”
IT: “기존 시스템 구축처럼 외주 주면 되지 않나?”
이 간극이 메워지지 않으면, 제조업 AI는 높은 확률로 POC(시연)까지만 하고 멈춥니다.
이 글은 “AI 기술 소개”가 아니라, 전통 제조업에서 AI가 굴러가기 위해 반드시 필요한 구조를 정리해보는 글입니다.
1) 디지털 네이티브 vs 전통 제조업: 출발점이 다르다
디지털 네이티브 기업은 본업이 온라인 서비스고, 핵심 자산은 데이터·사용자·트래픽입니다.
일하는 방식 자체가 실험과 개선에 최적화되어 있고, 실패 비용도 비교적 낮습니다.
반면 전통 제조업은 본업이 공장·설비·현장·공정처럼 물리 세계에 있습니다.
여기서 중요한 건 “빠른 실험”보다 안전·품질·수율입니다. 바꾼다는 것 자체가 리스크일 수 있어요.
그리고 더 큰 차이가 하나 있습니다. IT 인력 구조입니다.
전통 기업은 내부에서 제품 개발 조직이 강하게 성장하기보다, 그룹 SI/외주 중심으로 개발·운영을 해온 경우가 많습니다. 그래서 AI도 “요청해서 만들면 되는 시스템”으로 이해되기 쉬운데, AI는 그렇게 끝나지 않습니다.
AI는 결국 데이터가 흐르고, 운영이 반복되는 체계여야 합니다.
즉, 제조업 AX는 “의지”보다 “구조” 싸움입니다.
2) 제조업 AX가 POC에서 멈추는 3가지 이유
(1) 이해관계자들의 AI 인식이 다르다
경영진은 “우리가 가진 데이터/노하우면 AI로 크게 낼 수 있다”고 생각합니다.
현업은 “그걸 만들려면 추가 업무가 너무 많다”고 느낍니다.
IT는 “기존처럼 요건 받고 개발사 붙이면 된다”로 접근하기 쉽습니다.
이 상태에서는 목표가 “효율화/최적화”처럼 뭉개지고, 성공 기준(KPI)이 사라집니다.
성공 기준이 없으면 책임도 없습니다. 책임이 없으면 운영으로 못 갑니다.
(2) AI 과제에 ‘주인(오너십)’이 없다
제조업에서 AI는 새 영역이라 오너십이 공중에 뜨는 경우가 흔합니다.
현업: “IT가 하는 거 아닌가요?”
IT: “현업이 데이터/요건을 줘야 하죠.”
벤더: “요청 범위까지만 하겠습니다.”
그러다 보니 POC는 잘 나옵니다.
샘플 데이터로 “되는 것처럼”은 보여줄 수 있거든요.
하지만 그 다음(전사 확산/운영/모니터링/업데이트)은 누군가가 설계와 조율을 해야 하는데, 그 역할이 비어 있으면 멈춥니다.
(3) “데이터는 많은데 쓸 데이터가 없다”
전통 제조업에는 데이터가 정말 많습니다. 10년, 20년 된 데이터도 있습니다.
그런데 AI에 쓰려고 보면 “쓸 수가 없는” 경우가 많습니다.
현장에만 존재하는 암묵지(경험·감각·관행)가 데이터로 남지 않음
디지털화가 덜 된 구간의 데이터는 개인 PC 엑셀/문서로 흩어짐
시스템별 용어/단위/키가 달라서 연결이 안 됨
운영용 데이터라 분석/학습 구조로 쓰기 어렵고 전처리가 과도하게 들어감
결국 제조업 AI의 진짜 비용은 모델이 아니라 데이터 정합성과 운영 체계 구축에 들어갑니다.
3) 제조업 실전 과제 2가지: “기술”보다 “설계”가 먼저다
케이스 A) 사내 문서 기반 검색/챗봇(RAG)
현업 요청은 보통 이렇게 옵니다.
“매뉴얼/기준문서 있으니 직원들이 질문하면 바로 찾게 해주세요.”
하지만 막상 들어가면 현실은 이렇습니다.
문서 포맷 제각각(PDF/워드/PPT/스캔/스크린샷 위주)
최신본이 뭔지 모름(버전/정본 체계 부재)
도메인 용어·약어·사내 은어가 많음
문서에 없는 예외/관행은 어디에 담을지 애매함
보안 정책 때문에 외부 LLM/클라우드 사용 제약이 있을 수 있음
여기서 핵심은 “RAG 구현”이 아니라 지식관리 체계 재설계입니다.
문서를 모아 분류 체계를 만들고
문서 라이프사이클(생성/수정/만료/폐기)을 정의하고
업데이트를 누가 어떻게 할지 정하고(업로드 vs 자동 파이프라인)
성능 평가용 Q&A를 현업과 함께 만들고
사용 환경(현장 PC/모바일/권한/업무 흐름)에 맞게 UX를 설계해야 합니다.
즉, 제조업 챗봇 프로젝트는 “챗봇 개발”이라기보다
지식의 구조 + 운영 루틴을 만드는 프로젝트에 가깝습니다.
케이스 B) 수요 예측(전통 ML 과제)
수요 예측은 흔한 과제지만, 운영 단계에서 벽을 만납니다.
판매 데이터가 현실과 다르거나 사람이 손댄 흔적이 있음
신제품/단종/이벤트 같은 엣지케이스가 계속 발생
예측값을 생산/재고 의사결정에 어디까지 자동 반영할지 합의가 필요
성능이 떨어질 때(드리프트) 누가 원인을 분석하고 개선할지 체계가 필요
그래서 여기서도 핵심은 모델 그 자체보다
예측값을 의사결정 구조에 편입시키는 설계입니다.
어디까지 자동화하고 어디부터 사람 판단을 남길지
예외는 규칙으로 처리할지, 별도 모델로 갈지
운영 주기/성능 모니터링/데이터 품질 점검을 누가 할지
이게 정리되지 않으면 “좋은 모델”이 있어도 현업은 쓰지 않습니다.
4) 제조업 AX 담당자가 실제로 하는 일: 기술자가 아니라 ‘설계자’
전통 제조업에서 AX 역할은 보통 3가지로 정리됩니다.
문제를 번역한다
현업의 불편을 데이터/지표/프로세스 관점의 문제로 재정의
사람과 시스템을 조율한다
현업-IT-벤더 사이 오너십/범위/KPI/운영 책임을 설계
데이터와 AI 활용 흐름을 설계한다
수집→정제→저장→서빙→평가→운영(업데이트)까지 end-to-end로 연결
코딩과 모델링이 중요하지 않다는 뜻이 아닙니다.
다만 제조업에서 성과를 만드는 건 “기능을 만드는 것”보다 굴러가게 만드는 구조입니다.
5) 제조업 AX로 생존하기: 개인이 준비할 3가지 (취업/이직에도 그대로 먹힘)
(1) 문제 구조화 능력
“불편했다”에서 끝내지 말고,
원인-영향-목표-제약을 구조화하는 연습을 해두면 강합니다.
이력서/포트폴리오도 똑같습니다.
“XGBoost 썼다, LLM 썼다”보다 먼저
어떤 문제를 왜 풀었고, 성공 기준을 어떻게 잡았고, 무엇이 바뀌었는지를 앞에 쓰는 게 훨씬 설득력 있습니다.
(2) 기술을 넓게 보는 시야
요즘 AI는 모델만 아는 사람보다,
RAG/평가/데이터 파이프라인/모니터링/권한·보안까지 연결할 줄 아는 사람이 귀합니다.
사이드 프로젝트도 “모델 만들기”에서 멈추지 말고
수집→정제→서빙→운영을 한 번이라도 끝까지 가보면 포트폴리오가 달라집니다.
(3) 커뮤니케이션(설명) 능력
제조업 AX는 결국 사람을 움직이는 일입니다.
프로젝트 끝나면 최소한 아래 6줄은 글로 남겨보세요.
문제는 무엇이었나
왜 발생했나
어떤 데이터를 썼나
어떤 접근을 했나
결과는 어떻게 측정했나
다음 단계는 무엇인가
이게 쌓이면 면접에서도 강해지고, 현업 설득도 쉬워집니다.
"AI와 개발에 관련된 모든 사항은 윈디벨로 문의해 주세요”