생산에 지장 없이 빨리 투자를 회수하려면 공장은 AI를 어디서부터 시작해야 할까

핵심 요약

"AI를 어디에 쓸까"라는 질문으로 시작하지 마십시오. "이번 달 우리는 무엇 때문에 돈을 가장 많이 잃었나"에서 시작하십시오.
안전한 출발점은 생산 라인을 멈추지 않고 시험할 수 있고, 몇 주 안에 효과를 분명히 잴 수 있는 곳입니다.
시범 운영 팀에는 반드시 현장 사람이 들어가야 합니다. 무엇이 실제로 통하고 무엇이 서류상으로만 그럴듯한지 아는 사람들이기 때문입니다.

기술 로드맵보다 손실 지도(Loss Map)부터

먼저 이렇게 물어야 합니다. "지난달 우리 공장은 무엇 때문에 돈을 가장 많이 잃었나?" 설비 정지였는지, 불량이었는지, 재작업이었는지, 품종 교체를 기다린 시간이었는지 따져 보십시오. "카메라를 어디에 달까"는 그다음 문제입니다. 이 숫자를 알고 나면 어디서 시작할지가 대개 저절로 보입니다.

개발팀 참고 · 기술 세부 사항

Downtime, Scrap, Rework, Changeover, Energy, WIP, Customer Claim을 라인, 제품, 교대조(Shift), 설비별로 모은 다음, 재무팀(Finance)이 인정하는 공식으로 손실 금액을 계산하십시오. 자주 일어나고 비용이 큰 문제가 출발점입니다. 카메라를 달기 쉬운 곳이나 공급업체(Vendor)의 데모가 그럴듯해 보이는 곳을 기준으로 고르면 안 됩니다.

활용 사례(Use Case)마다 가치, 발생 빈도, 데이터 준비 상태, 생산을 멈추지 않고 시험할 수 있는지, 안전 위험을 기준으로 점수를 매기십시오. 좋은 후보에는 분명한 최종 사용자가 있습니다. 무엇을 점검할지 결정해야 하는 정비 기술자나, 어떤 제품을 빼낼지 골라야 하는 QC 검사원 같은 사람입니다. "스마트 팩토리 구축"처럼 범위가 넓은 프로젝트는 후보가 될 수 없습니다.

시범 운영 대상을 고르는 규칙: 손실(Loss) 하나 + 라인 하나 + 의사결정 하나 + 책임자(Owner) 한 명 + 기준선(Baseline) 하나

위험이 낮은 것부터 높은 순으로 고르기

좋은 출발점은 시험이 실패해도 아무도 곤란해지지 않는 곳입니다. 라인을 멈출 필요가 없고, 납품에 영향이 없고, 몇 주 안에 결과를 알 수 있어야 합니다. 공급업체가 데모가 가장 잘 나온다고 말하는 곳은 좋은 선택이 아닌 경우가 많습니다.

손실 지도는 돈이 가장 많이 새는 곳부터 순위를 매깁니다. 그곳이 출발점입니다.

순서	활용 사례	이유
1	매뉴얼 검색과 교대조 업무 요약	설비를 제어하지 않고 사람을 도움
2	비전 시스템이 의심 지점 표시	판정은 계속 QC가 하고 피드백 수집
3	이상 징후 감지/설비 보전	고장(Breakdown) 전에 계획할 시간 확보
4	생산 계획과 에너지 계획	실제 제약 조건 안에서 시나리오 작성
5	Closed-loop Control	가장 강력한 근거와 최고 수준의 안전성 필요

개발팀 참고 · 기술 세부 사항

섀도 모드(Shadow Mode)로 시작하십시오. 실제 공정에는 반영하지 않고 AI가 기존 방식과 나란히 추천만 하게 합니다. 결과가 생산에 영향을 주도록 허용하기 전에 여러 교대조, 여러 로트(Lot), Changeover 구간을 거치며 False Alarm과 Missed Event를 기록하십시오. 데이터가 끊기거나 시스템이 멈출 때를 대비해 Manual Override, Interlock, Standard Work가 있어야 합니다.

완벽한 데이터를 기다리지 마십시오: 타임스탬프, 단위, 맥락, 결과 이벤트가 서로 연결되면 시작할 수 있습니다. 다만 한계는 기록해 두어야 합니다. 확인된 고장 이력이 아직 없다면 이상 징후(Anomaly)를 "고장 예측"이라고 부르지 마십시오.

시범 운영 팀에 결과를 실제로 쓸 사람 넣기

개발팀 참고 · 기술 세부 사항

손실의 책임자(Loss Owner), Operator, Maintenance/QC, Process Engineer, IT/OT, Safety, Finance가 함께 기준을 정해야 합니다. 공급업체나 데이터팀이 현장 대신 성공을 정의해서는 안 됩니다. 정상 사례, 경계 사례, 이상 사례가 들어간 테스트 세트를 만들고, 어떤 추천이 Inspection, Recheck, Stop으로 이어지는지 정하십시오.

범위를 통제한 시범 운영의 예

"공장 설비 정지 줄이기" 대신 "A 그룹 모터의 베어링 이상을 점검 일정을 잡을 수 있을 만큼 미리 알리기"를 고르십시오. "모든 불량 검사하기" 대신 "조립 공정 다음에서 SKU Y의 X 유형 흠집 검사하기"를 고르십시오. 범위가 좁으면 데이터를 찾고, 효과를 재고, 한계를 파악하는 속도가 빨라집니다.

운영 시작(Go-live) 전 통과 기준

안전 검토와 사이버 보안 검토 통과
작업자가 경고의 의미와 수동 전환(Override) 방법을 이해함
오경보와 시스템이 놓친 건을 모두 집계
장애와 모델 변경의 담당자가 정해져 있음
AI가 멈춰도 수동 방식으로 일할 수 있음

"파일럿 무덤" 없이 투자 회수하고 확대하기

개발팀 참고 · 기술 세부 사항

Sensor, Edge, Network, Integration, Labeling, Cloud, Support 비용에 현장 인력의 시간과 모델 유지 보수 비용까지 모두 넣으십시오. Accuracy만 보지 말고 Cost per Outcome을 비교하십시오. 효과는 실제로 줄어든 손실(Loss)에 AI가 기여한 비율을 곱한 값입니다. Downtime 전체의 금액을 효과로 내세워서는 안 됩니다.

개발팀 참고 · 기술 세부 사항

시범 운영을 통과하면 다음 라인으로 넓히기 전에 Data Tag, Interface, Alert, Training, Change Control, Support의 표준을 만드십시오. 조명, 오래된 설비 모델, 원자재, 야간 교대조의 숙련도 같은 Site Difference도 확인하십시오. 거의 전부를 다시 손봐야 한다면 새 프로젝트로 보아야 하며, 확대(Scale)라고 불러서는 안 됩니다.

포트폴리오는 분기마다 Scale, Improve, Hold, Stop 중 하나로 결정을 받아야 합니다. 수익이 나지 않는 프로젝트는 중단하고 교훈을 남기십시오. 시범 사업이 몇 개인지와 상관없이, 앞서가는 공장은 측정할 수 있는 손실을 안전하게 새 작업 표준으로 바꾸는 공장입니다.

SHOP-FLOOR TIP · 장난감 대신 손실에서 시작하기

펜으로 20분 만에 채우는 시범 운영 캔버스(Pilot Canvas)

여섯 칸을 그리십시오. 줄일 손실, 더 나아져야 할 의사결정, 결과를 쓸 사람, 지금 있는 데이터, 위험 없이 시험하는 방법, 가치 계산 공식입니다. 한 칸이라도 비어 있다면 아직 공급업체를 부르지 마십시오. 기술이 팀 대신 문제를 정의하게 됩니다.

위험이 낮은 프로젝트부터 높은 순으로 배열하고, 실패해도 생산에 지장이 없는 곳에서 시작합니다

가상 사례: 한 포장 라인에서 짧은 정지가 자주 일어났습니다. 팀은 처음에 새 비전 시스템을 달고 싶어 했지만, 현장 점검(Gemba Walk)에서 정지의 절반이 필름 롤을 교체한 직후에 생긴다는 사실을 발견했습니다. 그래서 교체 작업(Changeover) 기록과 비정상 파라미터 알림부터 시작했습니다. 결과는 더 빨리 나왔고, 그 데이터는 다음 단계의 비전 시스템에 쓰였습니다.

1-1-1-1 규칙

초기에는 라인 하나, 교대조 하나, 손실 하나, 책임자 한 명으로 갑니다. 생산 시즌을 한 번 겪거나 중요한 제품 구성(Product Mix) 변화를 거친 뒤에 넓히십시오. 설비 정지, 유지 보수, 시스템을 돌보는 사람의 시간을 빼지 않고 1주일 결과를 1년치로 곱해서는 안 됩니다.

팁: 시스템을 쓰기 가장 어려운 교대조의 작업자를 첫날부터 시범 운영 팀에 부르십시오. 엔지니어가 옆에 서 있을 때만 돌아가는 시스템이라면 아직 운영 시스템이라고 부를 수 없습니다.

DNA MAKER · SOLUTION BLUEPRINT

지식에서 실제로 문제를 해결하는 시스템으로

문제의 핵심

공장은 손실을 줄이는 능력을 사야 하고, "AI"라는 이름표는 중요하지 않습니다. 좋은 시범 운영은 현장이 더 잘 내릴 수 있게 될 의사결정 하나에 묶여 있어야 합니다.

단계별 해결 방법

손실 지도를 만들고 가치, 실현 가능성, 위험을 기준으로 활용 사례 순위 매기기
데이터와 OT 시스템을 조사하고, 안전에 영향을 주지 않는 섀도 모드 설계
라인 하나에서 효과를 입증한 뒤, 확대 전에 표준 만들기

현장 지식과 공장 데이터를 잇는 소프트웨어 계층 만들기

DNA Maker는 공장의 공정 엔지니어, 작업자, 품질팀, 안전 담당자를 대신하려는 것이 아닙니다. 손실이 어디서 생기는지, 어떤 신호가 중요한지, 어떤 결정이 안전한지는 이들이 가장 잘 압니다. 저희 역할은 질문을 세우고, Loss-to-Decision Map을 만들고, 현장 지식이 실제 이벤트와 연결되도록 데이터 수집 방법을 설계하는 것입니다. 어떤 문제는 양식과 워크플로로 시작하고, 어떤 문제는 시스템 연동이 필요하며, 어떤 문제는 나중에 AI를 쓰는 편이 좋은지 함께 가려냅니다. 그래야 사용자가 결과로 무엇을 할지 알기도 전에 기술에 투자하는 일을 막을 수 있습니다.

문제가 소프트웨어로 풀기에 맞으면 DNA Maker는 현장 기록용 웹·모바일 애플리케이션, 대시보드, 알림 워크플로, 지식 어시스턴트(Knowledge Assistant), 데이터를 모으고 기존 시스템과 연계하는 AI 에이전트를 만들 수 있습니다. 고객사 기술팀과 합의한 아키텍처에 따라 IoT, MES, CMMS도 연결합니다. 섀도 방식의 시범 운영, 생산 교대조에 맞춘 UX 설계, 시스템 개발과 모니터링을 돕되, 공장의 안전 규칙을 요구 사항으로 삼습니다. 줄이고 싶은 손실이 있는데 센서, 프로세스, 소프트웨어 중 어디서 시작해야 할지 확신이 없다면, 그 질문에 근거로 답하는 시범 운영을 함께 설계해 보겠습니다.

SOFTWARE ENGINEERING GLOSSARY

소프트웨어 엔지니어링 용어집

경영진, 업무 책임자, 개발팀이 같은 용어를 서로 다르게 이해하지 않도록 정리한 표입니다. 외울 필요는 없고, 의미와 예시, 오른쪽 열의 질문까지 함께 읽으면 됩니다. 이 질문을 던지면 개발을 시작하기 전에 숨어 있던 범위와 위험, 비용이 드러나는 경우가 많습니다.

용어	의미	쉬운 예시	개발팀에 물어봐야 할 질문
Edge Computing	모든 데이터를 클라우드로 보내지 않고 설비 가까이에서 처리하는 방식	지연을 줄이려고 라인 바로 옆에서 이미지를 분석	즉시 응답해야 하는 작업은 무엇이고, 왜 현장에서 처리해야 합니까?
IoT	네트워크로 데이터를 보내는 장치나 센서	설비 온도를 1분마다 읽음	각 센서의 담당자는 누구이고, 점검과 교정은 어떻게 합니까?
Data Pipeline	데이터를 출처에서 쓰이는 곳까지 옮기는 경로	센서 → 데이터베이스 → 대시보드	데이터가 빠지거나 늦게 오면 시스템은 어떻게 대응합니까?
Shadow Mode	시스템이 추천만 하고 실제 작업은 아직 제어하지 않는 운영 방식	알림을 정비 기술자의 판단과 비교	실제로 쓰기 전에 얼마나 오래, 어떤 조건을 거쳐 시험해야 합니까?
Integration	새 시스템을 공장의 기존 시스템과 연결하는 일	이벤트를 CMMS나 MES로 전송	시스템 간 데이터 계약은 무엇이고, 각 쪽은 누가 관리합니까?

내일 해 볼 일: 지난 12개월의 손실을 파레토(Pareto)로 정리하고, 자주 일어나면서 섀도 방식으로 시험할 수 있는 문제 하나를 고른 뒤, 모델 이야기를 하기 전에 비즈니스 KPI부터 정하십시오.