📌 핵심 요약
- 여러 제조 고객이 공통으로 말한 것은 하나였습니다. 채팅창은 있으면 괜찮은 정도였고, 요청은 다른 두 곳에 모여 있었습니다.
- 제조 AI 에이전트는 AI가 판단을 대신하는 기술이 아니라, 쌓인 데이터를 읽어 사람이 판단하러 들어오는 시점을 앞당기는 단계입니다.
- 그래서 앞의 두 단계가 먼저입니다. ① 다시 확인하지 않아도 되는 검사 판정, ② 흩어진 기록을 하나로 묶는 모니터링.
- 요청이 모인 두 곳은 먼저 오는 알림과 정기 보고서 자동화였고, 여기에 근거를 되짚을 수 있어야 한다는 조건이 붙었습니다.

제조 AI 에이전트가 갑자기 많이 들리는 이유
올해 들어 제조 쪽 미팅에서 제조 AI 에이전트라는 말이 부쩍 자주 나옵니다. 그런데 이야기를 조금만 더 들어가면 서로 다른 것을 상상하고 있는 경우가 많습니다. 어떤 분은 공정을 스스로 조정하는 무인 공장을 떠올리고, 어떤 분은 사내 문서를 찾아주는 챗봇을 떠올립니다. 같은 단어를 쓰는데 기대치가 다르니, 논의가 길어져도 결론이 잘 나지 않습니다.
이 글은 그 간극을 정리하기 위해 썼습니다. 출발점은 여러 제조 고객과 이 주제를 논의하면서 반복해서 확인한 한 가지입니다. 현장이 먼저 원한 것은 채팅창이 아니었습니다. 요청은 다른 두 곳에 모여 있었고, 그 두 가지를 하려면 에이전트 앞에 반드시 있어야 하는 층이 있습니다. 그 층이 무엇인지, 왜 대부분 거기서 막히는지를 순서대로 다룹니다.
제조 AI 에이전트란 무엇인가
💡 제조 AI 에이전트란?
사람이 지시한 명령을 그대로 수행하는 자동화와 달리, 목표를 주면 필요한 데이터를 스스로 찾아 읽고, 상황을 해석해 다음 행동을 제안하거나 실행하는 소프트웨어를 말합니다. 제조 현장에서는 주로 품질·설비·생산 데이터를 읽어 이상을 알리고, 원인 후보를 좁히고, 보고서를 만드는 역할로 논의됩니다.
여기서 한 가지 구분이 필요합니다.
제조에서 에이전트라고 부르는 것에는 성격이 꽤 다른 두 가지가 섞여 있습니다.

| 구분 | 제어형 에이전트 | 운영형 에이전트 |
|---|---|---|
| 하는 일 | 설비·공정 조건을 직접 조정 | 데이터를 읽고 알리고 정리 |
| 판단 주체 | AI가 실행까지 | 사람이 최종 결정 |
| 실패 시 영향 | 생산·안전에 직접 영향 | 판단 참고자료가 틀림 |
| 현재 현장 수용도 | 검증 부담이 큼 | 상대적으로 진입 쉬움 |
| 선행 조건 | 정밀 제어 인프라 | 신뢰할 수 있는 데이터 |
지금 국내 제조 현장에서 현실적으로 논의되는 쪽은 대부분 오른쪽입니다. 이 글에서 다루는 에이전트도 오른쪽을 가리킵니다.
수요는 원래 있었습니다 — 제조 AI 에이전트를 가능하게 한 두 가지 변화
“라인 상태를 한눈에 보고 싶다”, “이상이 생기면 먼저 알려줬으면 좋겠다”는 요구는 새로운 것이 아닙니다. 십수 년 전부터 있었습니다. 달라진 것은 두 가지 조건입니다.
첫째, 묻는 방식이 바뀌었습니다. 예전에는 원하는 지표를 미리 정의해 대시보드를 만들어야 했습니다. 정의하지 않은 질문은 할 수 없었습니다. 지금은 “지난주 대비 3라인 불량이 왜 늘었는지” 같은 질문을 그대로 던질 수 있습니다.
둘째, 어디서 돌릴 수 있는지가 바뀌었습니다. 제조 데이터는 사내망 밖으로 내보내기 어렵습니다. 외부 API를 호출해야만 쓸 수 있던 시기에는 검토 자체가 막혔습니다. 사내 서버에서 직접 모델을 띄울 수 있게 되면서, 비로소 논의 테이블에 올라왔습니다.
📊 정책도 같은 방향을 가리킵니다
중소벤처기업부·중소기업기술정보진흥원이 2026년 6월 공고한 「중소제조 특화 멀티 AI 에이전트 개발(R&D)」 과제에는 172개 과제가 접수돼 14.3 대 1의 경쟁률을 기록했고, 12개 과제가 선정됐습니다(과제당 최대 3억 원, 6개월).
출처: 중소벤처기업부·중소기업기술정보진흥원, 2026년 6월 공고
과제 설명에 적힌 역할 정의가 특히 눈여겨볼 만합니다.
“공정 상태 분석과 품질 위험 예측, 생산조건 조정 권고, 현장 보고 등 기능별 AI를 제조 업무 흐름에 맞춰 연계해 운영”
— 중소벤처기업부·중소기업기술정보진흥원, 2026년 6월 공고문
한 개의 만능 AI가 아니라 기능별 AI를 업무 흐름에 맞춰 잇는다는 표현입니다.
정부 과제조차 에이전트를 “연결의 문제”로 보고 있다는 뜻이고, 이 글의 나머지는 사실상 그 연결 이야기입니다.
흐름 자체는 그 전부터 이어져 왔습니다. 산업통상자원부는 2025년 5월 기준으로 AI 팩토리 보급을 26개에서 100개 수준으로, 관련 지원 과제를 213개에서 519개로 확대하는 계획을 밝힌 바 있습니다.
다만 이 수치는 발표 시점 기준이므로 현재 집행 현황은 별도 확인이 필요합니다. 중요한 건 규모보다 방향입니다. 정책이 개별 설비의 자동화가 아니라 공장 단위의 데이터 활용으로 무게중심을 옮기고 있다는 점입니다.
제조 AI 에이전트가 성립하려면 필요한 3단계
정리하면 순서는 이렇습니다.
| 단계 | 하는 일 | 없으면 생기는 일 |
|---|---|---|
| 1단계 · 검사 | 제품 판정을 정확하게 내리고 그 기록을 남김 | 에이전트가 틀린 기록을 근거로 요약함 |
| 2단계 · 모니터링 | 라인에서 일어난 일을 시간 순으로 묶어 남김 | 질문에 답할 맥락 자체가 없음 |
| 3단계 · 에이전트 | 쌓인 기록을 읽어 알리고 정리하고 답함 | — |
많은 현장이 3단계부터 검토를 시작합니다. 데모 화면이 가장 인상적인 곳이 거기라서 그렇습니다. 하지만 실제로 막히는 곳은 거의 예외 없이 1단계와 2단계입니다. 참고로 MIT 미디어랩이 2025년 8월 발표한 「The GenAI Divide」 보고서는 기업 생성형 AI 파일럿의 약 95%가 측정 가능한 성과로 이어지지 못했다고 보고했습니다.
제조업만을 대상으로 한 조사는 아니지만, 실패 지점이 모델이 아니라 업무 데이터와의 연결에 있다는 지적은 제조 현장의 경험과 겹칩니다.
제조 AI 에이전트가 현장에서 하는 일 — 요청이 모인 세 가지 형태
3단계가 실제로 어떤 모습인지 그려보면 이해가 빠릅니다. 현재 제조 현장에서 논의가 모이는 형태는 대체로 셋입니다.
| 형태 | 하는 일 | 필요한 선행 데이터 |
|---|---|---|
| 이상 알림 | 평소와 다른 패턴이 잡히면 담당자에게 먼저 통보 | 시간 순으로 정리된 검사·설비 기록 |
| 원인 후보 좁히기 | 불량이 늘었을 때 관련 있을 만한 변수를 추려 제시 | 판정·설비 상태·투입 로트의 연결 |
| 정기 보고서 생성 | 주간 품질 리포트, 라인별 추이 차트를 자동 작성 | 일정 기간 누적된 판정 이력 |
오른쪽 열을 보면 공통점이 보입니다. 셋 모두 모델 성능이 아니라 데이터 상태를 전제로 합니다. 이상 알림은 “평소”가 무엇인지 알아야 가능하고, 원인 후보를 좁히려면 서로 다른 시스템의 기록이 같은 시간축 위에 있어야 하며, 보고서 자동화는 일정 기간 신뢰할 수 있는 판정이 쌓여 있어야 성립합니다. 에이전트를 먼저 올려도 읽을 것이 없으면 아무 일도 일어나지 않는 이유입니다.
1단계에서 막히는 곳 — AI 검사가 데이터를 만들지 못할 때
에이전트를 이야기하다가 검사 정확도로 돌아오는 게 이상하게 들릴 수 있습니다. 하지만 순서를 뒤집어 보면 자연스럽습니다. 에이전트가 읽을 데이터는 검사기가 내린 판정입니다. 그 판정이 틀려 있으면 에이전트는 틀린 기록을 근거로 요약하고 권고합니다. 잘못된 판정 위에 쌓은 자동화는 잘못된 결론을 더 빠르게 내놓을 뿐입니다.
현장에서 검사 성능의 기준은 보통 둘로 나뉩니다.
| 지표 | 무엇인가 | 놓쳤을 때 | 에이전트에 미치는 영향 |
|---|---|---|---|
| 미검 | 실제 불량을 양품으로 통과시킴 | 고객사로 흘러감 | 불량 이력 자체가 누락됨 |
| 과검 | 양품을 불량으로 올림 | 사람이 다시 확인 | 실제보다 불량률이 부풀려 기록됨 |
두 지표는 방향이 반대라 한쪽을 조이면 다른 쪽이 늘어납니다. 그래서 “정확도 몇 퍼센트”라는 단일 숫자만으로는 판단할 수 없고, 두 지표를 함께 봐야 합니다. 판정을 사람이 다시 확인해야 하는 비율이 높다면, 그 데이터는 아직 에이전트가 읽을 준비가 되지 않은 것입니다. 부풀려진 불량률 위에서 만들어진 주간 보고서는, 사람이 손으로 쓴 것보다 오히려 판단을 흐립니다.
모델이 라인 변화를 따라가야 합니다 — MLOps 운영 구조
성능만큼 자주 걸리는 게 운영입니다. 소재 로트가 바뀌고, 조명이 미세하게 틀어지고, 신규 모델이 들어옵니다. 그때마다 모델을 처음부터 다시 학습시켜야 한다면 데이터가 쌓이기 전에 운영이 먼저 지칩니다.
🏭 현장에서 확인된 운영 방식
판정이 애매했던 경계 데이터를 골라 다시 학습에 넣는 MLOps 구조를 적용한 사례에서, 전체 데이터를 재학습할 때 대비 약 10%의 경계성 데이터만으로 99% 수준의 성능에 도달한 결과가 공유된 바 있습니다.
출처: 홍영석 세이지 대표, 「2025 스마트 제조 대전망」 온라인 컨퍼런스 발표
중요한 건 숫자보다 구조입니다. 모델을 고쳐 쓰는 일이 특별한 프로젝트가 아니라 일상 운영 안에 들어와야, 1단계가 “한 번 구축하고 끝나는 시스템”이 아니라 계속 데이터를 만들어내는 층이 됩니다.
2단계에서 막히는 곳 — 제조 데이터가 부서마다 흩어져 있습니다
검사가 제 몫을 하기 시작하면 다음 벽이 나옵니다. 데이터가 한곳에 모이지 않는다는 점입니다.
검사 결과는 검사 장비 안에, 설비 알람은 제어 시스템에, 생산 실적은 MES에, 품질 이력은 또 다른 문서함에 있습니다. 사람은 이 사이를 오가며 맞춰 볼 수 있지만 에이전트는 그렇게 하지 못합니다. “어제 3라인 불량이 왜 늘었나”에 답하려면 검사 판정과 설비 상태와 투입 로트를 같은 시간축 위에 올려야 하는데, 그 시간축이 없는 공장이 대부분입니다.
세이지가 여러 제조 현장에서 에이전트 적용을 검토하며 반복해서 확인한 것도 이 지점이었습니다. 기술적으로 어려운 쪽은 모델이 아니라 연결이었습니다. MES를 비롯한 기간 시스템과 실제로 연결되느냐가 관문이고, 여기서 막히면 그다음은 전부 데모로 끝납니다.
그래서 2단계의 실질은 “AI를 붙이는 일”이 아니라 흩어진 기록을 하나의 맥락으로 묶는 일에 가깝습니다. 라인에서 일어난 일을 시간 순으로 남겨두는 층이 있어야, 그 위에서 무언가를 읽어낼 수 있습니다.
여기서 자주 나오는 오해가 하나 있습니다. “데이터 레이크를 먼저 구축해야 하느냐”는 질문입니다. 전사 통합을 먼저 끝내야 한다고 보면 프로젝트가 몇 년짜리가 됩니다. 실무적으로는 반대 순서가 현실적입니다. 질문 하나를 정하고, 그 질문에 답하는 데 필요한 시스템부터 연결하는 방식입니다. “이 라인의 불량이 늘었을 때 무엇을 먼저 보고 싶은가”를 정하면 연결해야 할 대상이 서너 개로 줄어듭니다.
🔗 함께 읽으면 좋은 글
제조 AI를 도입할 때 플랫폼 관점에서 무엇을 봐야 하는지
→ 제조 AI 플랫폼, 무엇을 기준으로 골라야 할까
현장이 AI 에이전트에 실제로 원한 것 — 챗봇은 거들 뿐입니다
제조 AI 에이전트를 소개하면 대체로 채팅창부터 보여주게 됩니다. 자연어로 물어보면 답이 나오는 화면입니다. 그런데 여러 제조 고객과 이 주제를 논의하면서 반복해서 들은 반응은 예상과 조금 달랐습니다.
“묻고 답하는 기능은, 있으면 괜찮은 정도입니다.”
필요 없다는 뜻은 아닙니다. 다만 그것만으로는 도입을 결정할 이유가 되지 못한다는 쪽에 가까웠습니다.

대신 요청이 구체적으로 모인 곳은 두 군데였습니다.
이 두 가지의 공통점은 “판단을 맡긴다”가 아니라 “사람이 판단하러 들어오는 시점을 앞당긴다”는 데 있습니다.
그리고 한 가지 조건이 따라붙습니다. 답이나 알림에는 근거가 같이 나와야 한다는 것입니다. 어느 라인, 어느 시각, 어떤 기록을 근거로 이런 결론이 나왔는지 되짚을 수 없으면 현장은 그 결과를 쓰지 않습니다. 품질 판정은 책임이 따르는 일이기 때문입니다. 제조에서 에이전트의 성패가 모델 성능보다 “어디서 나온 이야기인지 되짚을 수 있는가”에 달려 있다고 보는 이유입니다.
제조 AI 에이전트 도입 전 확인할 세 가지
| # | 확인 항목 | 무엇을 볼 것인가 |
|---|---|---|
| 01 | 검사 판정의 신뢰도 | 사람이 다시 확인해야 하는 판정이 얼마나 되나 |
| 02 | 기간 시스템 연동 | MES 등과 어떤 방식으로, 어느 범위까지 연결되나 |
| 03 | 근거 추적 | 알림·보고서가 어떤 기록에서 나왔는지 화면에서 확인되나 |
세 가지 모두 계약 전에 확인할 수 있는 항목입니다. 특히 두 번째는 견적서보다 연동 범위와 기간이 적힌 문서로 받아두는 편이 좋습니다. PoC에서 잘 돌아가던 것이 실제 라인에서 멈추는 지점이 대부분 여기입니다.
세이지가 지금 서 있는 자리 — 검사·모니터링 그리고 에이전트
세이지는 AI 비전 검사(SAIGE VISION)와 영상 기반 공정·안전 모니터링(SAIGE VIMS)을 제조 현장에 공급해 왔습니다. 앞에서 말한 1단계와 2단계에 해당하는 영역입니다. 검사 쪽에서는 MLOps 기반의 모델 운영 구조를, 모니터링 쪽에서는 라인에서 일어난 일을 시간 순으로 남기는 구조를 운영 중입니다.
3단계인 에이전트는 이 두 층 위에서 고도화하고 있는 단계입니다. 사내망 밖으로 데이터를 내보내기 어려운 제조 환경을 전제로 온프레미스에서 모델을 직접 서빙하는 구성을 검증하고 있고, 현장에서 요청이 모였던 이상 알림과 정기 보고서 자동화를 우선순위에 두고 있습니다. 완성해 놓고 파는 단계가 아니라는 점은 분명히 해둡니다. 다만 그 앞의 두 단계는 이미 돌아가고 있고, 그게 이 글에서 하고 싶은 이야기입니다.
📢 다음 달 컨퍼런스 발표 안내
2026년 10월 16일(금) 10:00~10:40 · 코엑스 컨퍼런스룸 317호에서 세이지 홍영석 대표가 「AI 품질 검사의 확장 방향 — Edge AI부터 품질 자율 운영 Agent까지」를 주제로 발표합니다. 이 글에서 다룬 3단계 구조와 현장 적용 사례를 더 자세히 다룰 예정입니다.

제조 AI 에이전트 자주 묻는 질문
반드시 검사일 필요는 없지만, 에이전트가 읽을 수 있는 데이터를 꾸준히 만들어내는 층은 필요합니다. 제조에서는 그 층이 검사와 모니터링인 경우가 가장 많습니다. 데이터가 쌓이지 않는 상태에서 에이전트만 먼저 올리면 요약할 대상이 없습니다.
장비 교체가 전제는 아닙니다. 다만 현재 판정을 사람이 다시 확인해야 하는 비율이 높다면, 그 데이터를 근거로 삼는 자동화는 같은 오차를 물려받습니다. 검사 성능 점검이 먼저입니다.
가능합니다. 폐쇄망 환경을 전제로 온프레미스에서 모델을 직접 서빙하는 구성이 있습니다. 다만 요구 사양과 운영 범위는 현장 조건에 따라 달라지므로 개별 검토가 필요합니다.
전사 통합을 선행 조건으로 두면 프로젝트가 길어집니다. 답해야 할 질문을 먼저 정하고, 그 질문에 필요한 시스템부터 연결하는 순서가 현실적입니다. 범위가 좁을수록 검증도 빨라집니다.
에이전트 자체의 정확도보다, 앞단 지표의 변화로 보는 편이 실무에 맞습니다. 재확인이 필요한 판정 건수, 이상 인지까지 걸린 시간, 정기 보고서 작성에 들어가던 공수 같은 항목입니다. 도입 전 값을 먼저 기록해 두는 것이 중요합니다.
요약
- 제조 AI 에이전트는 판단을 대신하는 기술이 아니라, 쌓인 데이터를 읽어 사람의 판단 시점을 앞당기는 단계입니다.
- 그래서 앞의 두 단계 — 정확한 검사와 흩어진 기록을 묶는 모니터링 — 이 없으면 에이전트도 없습니다.
- 현장이 실제로 원한 것은 채팅창이 아니라 먼저 오는 알림, 자동으로 만들어지는 보고서, 근거를 되짚을 수 있는 결과였습니다.
에이전트 이전에, 매일 신뢰할 수 있는 판정 데이터를 만드는 층부터 점검해 보시길 권합니다.
참고 출처
- 중소벤처기업부·중소기업기술정보진흥원, 「중소제조 특화 멀티 AI 에이전트 개발(R&D)」 과제 선정 결과, 2026년 6월
- 산업통상자원부, AI 팩토리 보급 확대 계획, 2025년 5월 발표 기준
- MIT Media Lab, 「The GenAI Divide: State of AI in Business 2025」, 2025년 8월
- 홍영석 세이지 대표, 「2025 스마트 제조 대전망」 온라인 컨퍼런스 발표
© SAIGE All Rights Reserved.