프로그래밍 허브

7년차 현장 엔지니어로서, 디지털트윈 프로젝트에서 가장 자주 듣는 질문은 "만드는 데 얼마예요?"입니다. 그런데 정작 예산이 무너지는 지점은 구축이 아니라 그다음입니다. 만든 뒤 매달, 매년 조용히 빠져나가는 운영비 말입니다.

구축비는 한 번, 운영비는 매달 나간다

디지털트윈을 만들 때는 3D 모델링, 센서 연동, 플랫폼 구축 같은 항목이 견적서에 또렷하게 찍힙니다. 문제는 이 비용이 끝이 아니라는 점입니다. 센서는 교정이 필요하고, 통신망은 장애가 나고, 모델은 현장 설비가 바뀌는 속도를 따라가야 합니다. 설비 한 대가 교체되면 그 설비와 연결된 모델, 데이터 매핑, 알람 규칙까지 함께 손대야 합니다. 현장에서는 이런 유지보수 작업이 "보이지 않는 일"로 취급되기 쉽습니다. 그래서 운영 예산이 처음부터 작게 잡히거나, 아예 잡히지 않는 경우도 봤습니다. 그 결과 트윈은 점점 현장과 어긋나고, 어긋난 트윈은 아무도 안 보게 되고, 안 보는 트윈은 결국 방치됩니다. 얼마 전 다룬 "디지털트윈도 늙는다"는 글의 원인 중 하나가 바로 이 운영비의 부재입니다.

운영비는 크게 네 갈래로 나간다

첫째, 데이터 수집·전송 비용입니다. 센서 수가 늘면 통신료와 저장 비용이 따라 늘어납니다. 전부 실시간으로 모으다 보면 저장소가 금세 불어납니다. 둘째, 모델 업데이트 비용입니다. 설비 교체, 공정 변경, 레이아웃 이동이 있을 때마다 모델을 고쳐야 합니다. 자동화가 안 돼 있으면 사람 손이 계속 들어갑니다. 셋째, 플랫폼·라이선스 비용입니다. 대시보드, 시뮬레이션 엔진, 클라우드 요금은 월 단위로 청구됩니다. 사용자가 줄어도 요금이 줄지 않는 구조도 있습니다. 넷째, 사람 비용입니다. 트윈을 돌보는 담당자가 필요합니다. 겸직으로 돌리면 우선순위에서 밀리고, 전담을 두면 인건비가 듭니다. 이 네 갈래를 모르면 "왜 이렇게 돈이 많이 드냐"는 질문에 답할 수가 없습니다.

줄이는 3가지 방법 — 덜 모으고, 덜 고치고, 덜 맡기기

첫째, 다 모으지 말고 필요한 것만 모읍니다. 모든 센서를 1초 주기로 모을 필요는 없습니다. 설비별로 "이 데이터가 어떤 판단을 바꾸는가"를 따져보고, 판단에 쓰이지 않는 데이터는 주기를 낮추거나 샘플링으로 바꿉니다. 저장 비용이 눈에 띄게 줄고, 나중에 데이터를 볼 때도 노이즈가 적습니다. 둘째, 모델 업데이트를 반자동화합니다. 설비 교체 시 모델을 처음부터 다시 만드는 게 아니라, 설비 단위 템플릿을 만들어 교체·복제만 하도록 구조를 짜는 겁니다. 초기 설계에 시간이 조금 더 들지만, 두 번째 교체부터는 작업량이 확 줄어듭니다. 셋째, 운영을 현장 안에 남겨둡니다. 외주에만 맡기면 작은 수정에도 견적과 일정이 붙습니다. 현장 담당자가 기본적인 모델 수정과 데이터 매핑을 직접 할 수 있게 교육하고 권한을 주면, 잔잔한 유지보수는 내부에서 소화됩니다.

그래서 뭘 하면 되나

디지털트윈을 새로 시작한다면, 구축 견적 옆에 "1년 운영비" 칸을 하나 더 만드세요. 데이터 수집·모델 업데이트·플랫폼·사람, 네 갈래로 나눠서 적어보는 것만으로도 예산 회의의 분위기가 달라집니다. 이미 트윈을 운영 중이라면, 이번 달에 가장 많이 든 운영비 항목 하나를 골라 "이걸 줄일 수 있는가"부터 따져보세요. 트윈의 수명은 구축 기술이 아니라 운영 설계가 정합니다.

관련 글: 디지털트윈의 진짜 엔진은 데이터 수집이다 https://developer-archive.tistory.com/124 / 디지털트윈이 '실시간'이 되는 조건 https://developer-archive.tistory.com/132 / 디지털트윈-MES 경계 설계 https://developer-archive.tistory.com/139 / 디지털트윈도 늙는다 https://developer-archive.tistory.com/169

7년차 현장 엔지니어로서 한 줄로 정리하면, 로봇 스펙표보다 비싼 건 '그 로봇이 어제 무엇을, 왜 실패했는지'에 대한 기록이다. 그래서 뭘 하면 되나. 로봇 도입 전에 계약서에 데이터 소유와 학습 범위를 먼저 적고, 성공뿐 아니라 실패 기록까지 남기는 데이터 파이프라인부터 만들자. 피지컬 AI 시대에 공장의 진짜 자산은 로봇이 아니라, 그 로봇이 매일 쌓는 현장 데이터다.

> 이 글은 새로 시작하는 '현장 AI 운영 노트' 시리즈의 첫 번째 글입니다. 데이터를 모으고 흘려보내는 이야기는 '현장 데이터 파이프라인' 시리즈(EP.3 https://developer-archive.tistory.com/158, EP.4 https://developer-archive.tistory.com/165)에서 다뤘고, 이제는 도입된 AI를 매일 어떻게 돌보는지를 다룹니다.

AI를 공장에 붙이는 날보다 더 중요한 날이 있습니다. 붙인 다음 날 아침입니다. 도입 당일에는 모두가 화면을 들여다보지만, 한 달이 지나면 아무도 AI의 건강을 묻지 않습니다. 그러다 어느 날 AI가 조용히 틀리기 시작하고, 현장은 그걸 한참 뒤에야 알아챕니다. 7년차 현장 엔지니어로서 제가 배운 건, AI 운영의 핵심은 대단한 재학습 기술이 아니라 "매일 아침 5분, 같은 지표를 보는 습관"이라는 것입니다.

운영 지표는 정확도가 아니라 '이상 신호'부터 본다

도입 이후에 정확도를 매일 재는 현장은 거의 없습니다. 정답 라벨이 그날 바로 나오지 않기 때문입니다. 대신 볼 수 있는 건 이상 신호입니다. 첫째, 입력이 달라졌는가 — 센서 결측률이 평소보다 올랐는지, 이미지 밝기나 각도가 바뀌었는지. 둘째, 예측 분포가 달라졌는가 — 평소에는 불량 판정이 2%였는데 오늘은 8%라면, 제품이 나빠졌을 수도 있지만 AI가 보는 세상이 바뀌었을 가능성도 큽니다. 셋째, 작업자가 판정을 얼마나 뒤집는가 — 뒤집는 비율이 오르면 AI와 현장의 눈이 어긋나고 있다는 뜻입니다.

이 세 가지는 정답 없이도 매일 볼 수 있습니다. 저는 이걸 "AI의 활력징후"라고 부릅니다. 사람이 매일 체온을 재듯, AI도 매일 이 세 숫자를 보면 됩니다.

알람은 적게, 그러나 반드시 사람이 보게

운영에서 가장 흔한 실패는 알람을 너무 많이 만드는 것입니다. 입력이 조금만 흔들려도 알람이 울리면, 현장에서는 일주일 만에 알람을 무시하기 시작합니다. 그래서 알람은 두 단계로 나눠야 합니다. '주의'는 대시보드에만 남기고, '조치'는 사람이 반드시 확인해야 하는 경우에만 울립니다. 조치 알람의 기준은 간단합니다. "지금 이걸 안 보면 오늘 안에 라인이 멈추거나 불량이 흘러갈 수 있는가"입니다. 아니라면 주의로 두세요.

또 하나, 알람에는 반드시 '그다음 행동'이 붙어야 합니다. "예측 분포 이상"이라는 알람만으로는 아무도 움직이지 않습니다. "최근 1시간 이미지 20장을 확인하고, 조명이 바뀌었는지 보세요"까지 써 있어야 알람이 일이 됩니다.

그래서 뭘 하면 되나 — 아침 5분 운영 점검표

내일 아침부터 이렇게 해보세요. ① 어제 입력 결측률이 평소와 달랐는지 ② 불량 판정 비율이 평소 범위를 벗어났는지 ③ 작업자가 뒤집은 판정이 몇 건인지 ④ 조치 알람이 있었다면, 그 원인이 확인됐는지. 네 가지 중 하나라도 평소와 다르면, 그날은 재학습을 논하기 전에 "무엇이 달라졌나"부터 찾습니다. 데이터 드리프트(https://developer-archive.tistory.com/133)나 모델 평가(https://developer-archive.tistory.com/164)에서 다룬 것처럼, 원인을 모른 채 모델만 고치면 같은 문제가 반복됩니다.

AI 도입은 설치가 아니라 운영의 시작입니다. 매일 아침 5분, 같은 지표를 보는 팀은 AI가 틀리기 전에 알아챕니다. 다음 편에서는 이 점검표를 실제로 대시보드 하나로 만드는 법 — 어떤 차트부터 그릴지, 어떤 숫자는 빼야 할지를 다룹니다.

불량 검사 AI를 현장에 붙여본 사람이라면 한 번쯤 이런 장면을 봤을 겁니다. AI는 "불량"이라고 찍어내는데, 작업자는 고개를 갸웃합니다. 어디가, 왜 불량인지 모르겠으니 라인을 세울 수도, 그냥 흘려보낼 수도 없는 겁니다. 정확도가 99%여도, 이유를 말하지 못하는 AI는 현장에서 오래 살아남지 못합니다.

AI의 판정이 아니라, 현장의 판단이 멈춘다

공장에서 판정은 끝이 아니라 시작입니다. 불량 판정이 나오면 다음 질문이 바로 이어집니다. 어느 공정에서 생긴 결함인지, 같은 원인이 다른 제품에도 있는지, 지금 라인을 세워야 하는지 말아야 하는지. AI가 답을 주지 못하면 이 질문들은 전부 사람의 어깨로 돌아갑니다.

그래서 현장에서 AI의 가치는 정확도 하나로 재단되지 않습니다. "왜 그렇게 판단했는지"를 함께 내놓는지가 도입 성패를 가릅니다. 설명이 없는 판정은 결국 확인 작업만 늘립니다. 작업자는 AI를 믿지 못하고, 전수 검사를 다시 하거나, 아예 AI 판정을 무시하기 시작합니다.

설명 가능하다는 건, 현장 언어로 말한다는 뜻이다

현장 기준은 훨씬 실용적입니다.

첫째, 근거를 현장 언어로 보여줄 것. "확률 0.87"이 아니라 "용접부 우측 상단 3mm 지점의 밝기 편차"처럼, 작업자가 눈으로 확인할 수 있는 단서여야 합니다. 이미지 검사라면 결함 위치를 표시하고, 센서 기반이라면 어느 센서 값이 기준을 넘었는지 짚어줘야 합니다.

둘째, 설명이 조치로 이어질 것. "불량"에서 멈추지 않고 "재작업"인지 "폐기"인지, "앞 공정 점검"이 필요한지까지 연결돼야 설명이 일을 줄입니다. 설명이 조치와 끊기면 그건 보고서용 장식에 불과합니다.

셋째, 틀렸을 때 되돌릴 수 있을 것. AI가 틀린 판정을 내렸을 때, 그 근거와 원본 데이터를 함께 남겨두면 원인을 추적할 수 있습니다. 근거 없는 오판은 개선도 안 됩니다. 무엇을 고쳐야 할지 모르니까요.

도입 전에 확인할 실전 체크리스트

7년차 현장 엔지니어로서, 설명 가능한 제조 AI를 도입하기 전에 이렇게 확인하길 권합니다.

- 판정 화면에 "어디가, 왜"가 함께 보이는가? 확률 숫자만 있다면 아직 반쪽짜리입니다.

- 설명이 작업자의 다음 행동과 연결되는가? 확인 → 조치 → 기록의 흐름이 끊기지 않는지 보세요.

- 오판 사례를 모아 근거와 함께 복기할 수 있는가? 틀린 판정에서 배우지 못하는 시스템은 같은 실수를 반복합니다.

- 설명을 만드는 비용이 현장에 전가되지 않는가? 설명을 위해 검사 속도가 느려지거나 작업이 늘어난다면, 그건 설계가 잘못된 겁니다.

그래서 뭘 하면 되나 — 지금 쓰고 있는 검사 AI가 있다면, 판정 결과 옆에 근거 한 줄을 붙이는 것부터 시작하세요. "어느 부위, 어떤 신호, 기준 대비 얼마나" 이 세 가지만 붙여도 현장의 반응은 달라집니다. AI가 똑똑해지는 것도 중요하지만, 현장에서 믿고 쓸 수 있게 만드는 것이 먼저입니다. 이유를 말하는 AI가 결국 라인을 세우지 않고도 품질을 지키는 AI가 됩니다.

관련 글: #164 정확도 99%가 현장에서 쓸모없을 수 있다, #152 포스코 InnoPIMS

스마트팩토리 얘기를 하다 보면 ERP, MES, SCADA, PLC가 한꺼번에 등장합니다. 이름은 비슷한데 하는 일은 완전히 다릅니다. 오늘은 그 가운데서도 현장과 가장 가까운 시스템, MES(Manufacturing Execution System, 제조실행시스템)를 정리합니다. 한 줄로 말하면, MES는 "오늘 무엇을, 어느 설비에서, 어떤 순서로 만들지"를 지시하고, 그 결과를 실시간으로 기록하는 공장 생산의 사령탑입니다.

ERP와 MES, 그리고 SCADA는 뭐가 다를까

계층으로 보면 역할이 깔끔하게 나뉩니다. ERP는 수주·자재·재고·출하 같은 경영 계획을 세우는 곳, MES는 그 계획을 받아서 오늘의 생산 지시로 바꾸는 곳, SCADA와 PLC는 설비를 직접 움직이고 값을 읽는 곳입니다. 흔한 오해가 "ERP만 있으면 생산 관리가 된다"는 건데, ERP는 월·주 단위의 계획에는 강하지만 지금 이 라인에서 무슨 일이 벌어지는지는 모릅니다. 반대로 MES 없이 SCADA만 있으면 설비 데이터는 쌓이지만, 그 데이터가 어떤 작업지시·어떤 제품과 연결되는지 알 수 없습니다. MES가 비어 있는 자리가 바로 이 사이입니다.

| 계층 | 담당 | 시간 단위 |

| ERP | 수주·자재·재고·출하 계획 | 일·주·월 |

| MES | 작업지시·실적·품질·설비 상태 관리 | 분·시간 (실시간) |

| SCADA / PLC | 설비 제어·데이터 수집 | 초 단위 |

MES가 실제로 하는 일 4가지

첫째, 작업지시와 배분입니다. ERP의 생산계획을 받아서 라인·설비·작업자별로 "지금 이걸 만드세요"라는 지시를 내립니다. 둘째, 실적 수집입니다. 생산 수량, 가동·정지 시간, 불량 수량을 자동으로 모아, 종이 작업일보를 대체합니다. 셋째, 품질과 추적성입니다. 어떤 자재 로트가 어떤 제품에 들어갔는지, 어떤 공정에서 어떤 검사를 통과했는지를 남깁니다. 불량이 터졌을 때 "어디까지 회수해야 하나"를 이 기록으로 가릅니다. 넷째, 설비 상태와 알람 관리입니다. 가동률·정지 원인을 코드로 정리해 두면, 나중에 "왜 자꾸 이 설비만 멈추나"를 데이터로 따질 수 있습니다.

현장에서 MES를 처음 도입할 때 가장 많이 틀리는 지점은, 이 4가지를 한 번에 다 하려는 것입니다. 제 경험으로는 실적 수집부터 제대로 붙는 게 순서입니다. 실적이 안 쌓이는 MES는 대시보드만 화려한 빈 껍데기입니다.

MES가 "실시간"이 되려면 무엇이 필요한가

MES가 실시간이 되려면 세 가지가 맞아야 합니다. 설비에서 데이터가 자동으로 올라와야 하고(수작업 입력만으로는 실시간이 안 됩니다), 작업지시·자재 로트·설비 상태가 같은 기준으로 묶여야 하며, 현장 작업자가 "입력하기 귀찮은 시스템"이 아니어야 합니다. 특히 마지막이 중요합니다. 현장에서 입력이 밀리면 MES의 데이터는 그날 저녁에나 채워지고, 그러면 MES는 실시간 시스템이 아니라 "늦은 보고서"가 됩니다. 그래서 도입할 때는 화면을 예쁘게 만드는 것보다, 작업자가 한 번의 스캔이나 버튼으로 실적을 남길 수 있게 만드는 게 먼저입니다.

그래서 뭘 하면 되나 — MES를 볼 때 체크리스트

MES를 새로 보거나 도입을 검토한다면, 이 다섯 가지만 먼저 확인해 보세요. ① 작업지시가 ERP 계획과 자동으로 연결되는가 ② 실적·불량·정지 원인이 자동으로 수집되는가 ③ 자재 로트부터 완제품까지 추적이 되는가 ④ 현장 입력이 1~2번의 동작으로 끝나는가 ⑤ 나중에 AI나 디지털트윈이 쓸 수 있는 형태로 데이터가 남는가. 이 중 ①~④가 안 된 MES에 AI를 얹는 건, 기초가 안 된 집에 지붕부터 올리는 일과 같습니다.

MES는 화려한 기술이 아닙니다. 하지만 MES가 없으면 스마트팩토리의 나머지 이야기는 대부분 공중에 뜹니다. 내일 현장에서 "오늘 생산 실적이 어떻게 되나요"라는 질문에, 누군가 엑셀을 뒤지지 않고 화면 하나로 답할 수 있다면, 그 공장은 이미 MES의 절반은 갖고 있는 셈입니다.

관련 글: 디지털트윈과 MES의 경계 설계(https://developer-archive.tistory.com/139), 예지정비 심화(https://developer-archive.tistory.com/126)

공장용 AI 챗봇을 처음 현장에 내놨을 때, 가장 많이 틀린 답은 어려운 기술 질문이 아니었다. "라인이 섰다"는 말을 AI는 "생산라인이 완전히 멈췄다"고만 이해했고, 현장은 그 말을 "한 공정이 잠시 대기 중"이라는 뜻으로 쓰고 있었다. 모델은 멀쩡했고 프롬프트도 길었다. 틀린 건 단 하나, 단어의 뜻이었다.

7년차 현장 엔지니어로서, 나는 이제 AI 도입 프로젝트에서 가장 먼저 묻는다. "이 현장에서 이 단어는 정확히 무슨 뜻인가요?" 그 답이 정리되지 않은 곳에서는, 아무리 좋은 모델도 현장의 언어를 못 알아듣는다.

같은 말, 다른 뜻이 현장을 지배한다

현장의 말은 사전의 말과 다르다. "불량" 하나만 봐도, 검사 기준을 넘은 제품인지, 재작업이 가능한 상태인지, 라인에서 이미 분리된 것인지에 따라 대응이 완전히 달라진다. "점검"도 마찬가지다. 어떤 팀은 육안 확인을, 다른 팀은 센서 값 기록까지 포함한 절차를 점검이라 부른다.

AI는 이런 차이를 스스로 알아채지 못한다. 학습 데이터에 있는 일반적인 뜻을 가져오고, 확신에 찬 말투로 틀린 답을 낸다. 현장 사람들은 그 답을 보고 "AI는 현장을 모른다"고 결론내린다. 사실 AI가 몰랐던 건 기술이 아니라, 이 현장만의 말이었다.

용어집은 문서가 아니라 계약이다

그래서 나는 용어집을 "참고 자료"가 아니라 "계약"으로 만든다. 용어 하나마다 세 가지를 적는다. 첫째, 현장에서의 정확한 정의. 둘째, 그 단어가 쓰이는 상황과 쓰이지 않는 상황. 셋째, 그 단어와 연결된 후속 행동. 예를 들어 "라인 정지"라면, 어떤 조건일 때 정지로 부르고, 정지가 선언되면 누가, 무엇을, 어떤 순서로 하는지까지 연결한다.

이렇게 만든 용어집은 AI의 답변 기준이 된다. 모델이 용어를 쓸 때는 용어집의 정의를 따르고, 정의에 없는 말은 함부로 쓰지 않게 한다. 프롬프트에 넣는 문장 한 줄보다, 용어집 한 페이지가 현장의 오해를 훨씬 많이 줄인다.

용어집 만드는 3단계

첫째, 현장에서 실제로 많이 쓰이는 말 30개를 뽑는다. 회의록, 작업지시서, 알람 문구에서 자주 나오는 말이 기준이다. 둘째, 각 단어마다 현장 담당자 한 명씩 "뜻의 주인"을 정한다. 주인이 없는 정의는 회의 때마다 바뀐다. 셋째, AI 답변에 용어집 정의를 그대로 인용하게 하고, 답이 틀렸을 때는 모델이 아니라 용어집부터 고친다.

이 순서가 중요한 이유는 간단하다. 모델은 계속 바뀌고, 프롬프트도 계속 바뀐다. 하지만 현장의 말이 바뀌는 속도는 훨씬 느리다. 오래 남는 것부터 정리해야 도입이 흔들리지 않는다.

그래서 뭘 하면 되나: 이번 주에 현장 용어 10개만 뽑아, 정의와 주인 한 명씩을 적어보자. 그 10개가 정리되는 순간, AI의 답은 눈에 띄게 현장다워진다.

이전 글: 공장용 AI 챗봇 권한 문제(https://developer-archive.tistory.com/145), AI 에이전트의 행동 권한 설계법(https://developer-archive.tistory.com/167)

출처: PR Newswire, 2026년 10월 27일 — ROKAE Robotics "ROKAE delivers its 10,000th humanoid force-controlled arm"

1만 대라는 숫자가 말하는 것

중국 로봇 기업 ROKAE Robotics가 휴머노이드용 힘제어 암(force-controlled arm) 누적 출하 1만 대를 달성했습니다. 2026년 9월 산둥성 생산기지에서 1만 번째 제품이 라인에서 내려왔고, 이 수치는 산업용·협동로봇을 제외한 휴머노이드 힘제어 암 제품군만의 집계입니다.

숫자 자체보다 주목할 점은 쓰임새입니다. ROKAE의 로봇은 중국 타이창의 셰플러(Schaeffler) 라이트하우스 팩토리에서 실제 생산 라인에 투입돼 있습니다. 바퀴형 휴머노이드 5대가 AR 시리즈 힘제어 암을 장착하고 부품 핸들링·조립·검사를 맡고 있고, 80곳이 넘는 산업 파트너가 이 암을 생산 공정에 통합했다고 회사는 밝혔습니다.

왜 '힘제어'가 중요한가

휴머노이드 로봇의 손과 팔은 "어디까지 움직이는가"보다 "얼마나 세게 닿는가"가 먼저입니다. 위치만 제어하면 부품을 쥐었다 놓는 동작은 되지만, 끼워 맞추고, 눌러 고정하고, 깨지기 쉬운 부품을 다루는 일은 힘의 피드백 없이는 불안정합니다.

ROKAE 창업자 투오 화(Tuo Hua) CEO의 말도 같은 방향입니다. "힘제어에는 지름길이 없다. 1만 대를 달성했다는 것은 하드웨어와 제어 알고리즘, 제조 공정이 규모 있게 일관된 성능을 냈다는 의미다." 데모 영상 한 편이 아니라, 같은 성능을 수천 번 반복해서 찍어내는 능력이 곧 양산의 문턱이라는 뜻입니다.

한국 제조 현장에 주는 시사점

휴머노이드가 공장에 들어온다는 뉴스는 이제 낯설지 않습니다. 테슬라 옵티머스, LG 클로이드에 이어 이번 ROKAE 소식까지, 경쟁의 축은 "만들 수 있는가"에서 "공장에서 매일 돌릴 수 있는가"로 옮겨가고 있습니다.

7년차 현장 엔지니어로서 한 줄로 정리하면, 휴머노이드의 진짜 시험대는 쇼룸이 아니라 불량률·가동률·교체 주기가 숫자로 찍히는 공장 바닥입니다.

그래서 뭘 하면 되나 — 당장 휴머노이드를 들여올 필요는 없습니다. 대신 우리 공정의 "힘"이 필요한 작업을 먼저 골라보세요. 끼움·압입·연마처럼 사람이 손끝 감각으로 하던 작업 3가지를 리스트업하고, 각 작업의 허용 힘 범위와 불량 기준을 수치로 적어두는 것만으로도, 나중에 어떤 로봇 팔을 들여와도 평가 기준이 생깁니다.

마무리: 부품에서 시스템으로

ROKAE의 1만 대는 휴머노이드 부품 시장이 "시제품" 단계를 벗어나고 있다는 신호입니다. 팔 하나가 아니라 팔+제어+검증이 묶인 시스템으로 팔리기 시작했다는 점이 핵심입니다. 한국 제조 현장도 로봇을 "도입"이 아니라 "운영"의 관점으로 보기 시작할 때, 이런 뉴스가 남의 이야기가 아니라 우리 공정의 선택지가 됩니다.

> **[현장 데이터 파이프라인 EP.5 최종회 — 시리즈 이어서 읽기]** 1편에서는 데이터가 '나오는 것'과 '쓸 수 있는 것' 사이의 4가지 막힘을, 2편에서는 전송이 끊기는 것을 전제로 한 엣지 버퍼링과 재전송 설계를, 3편에서는 저장 구간의 스키마 계약을, 4편에서는 저장된 데이터를 꺼내 쓰는 활용 구간의 운영 설계를 다뤘습니다. 오늘이 최종회입니다. 1편(https://developer-archive.tistory.com/148) · 2편(https://developer-archive.tistory.com/153) · 3편(https://developer-archive.tistory.com/158) · 4편(https://developer-archive.tistory.com/165)

파이프라인은 만드는 것보다 운영하는 것이 오래갑니다. 처음에는 잘 돌아가던 파이프라인도, 설비가 늘고, 담당자가 바뀌고, 분석 요구가 쌓이면서 조금씩 어긋나기 시작합니다. 그 어긋남은 어느 날 갑자기 터지지 않습니다. 조용히 쌓이다가, 어느 날 "이 숫자 믿을 수 있어요?"라는 질문 하나로 드러납니다. 그래서 최종회에서는 거창한 시스템이 아니라, 한 장의 점검표를 제안합니다. 파이프라인 전체를 정기적으로 훑어보는 습관 말입니다.

1) 수집 구간 — 데이터가 '나오고' 있는가

첫 번째 점검은 수집 구간입니다. 센서가 보내는 값이 실제로 들어오고 있는지, 값이 비어 있거나 멈춘 구간은 없는지, 단위와 범위가 바뀐 설비는 없는지 확인합니다. 현장에서 흔한 실패는 수집이 멈춘 줄도 모르고 분석을 계속하는 경우입니다. "값이 안 들어오면 바로 알아차리는가"가 첫 번째 문항입니다. 수집이 멈췄을 때 알람이 울리는지, 누가 확인하는지까지 함께 점검해야 합니다.

2) 전송·저장 구간 — 끊겨도, 쌓여도 괜찮은가

두 번째는 전송과 저장 구간입니다. 네트워크가 끊겼을 때 엣지에서 버퍼링이 되는지, 복구 후 재전송이 빠짐없이 되는지, 저장된 데이터의 스키마가 약속대로 유지되는지 봅니다. 2편과 3편에서 다룬 내용이 실제로 지켜지고 있는지를 확인하는 단계입니다. 특히 스키마가 조용히 바뀌는 경우가 위험합니다. 필드 하나가 추가되거나 단위가 바뀌었는데, 받는 쪽이 모르고 있으면 분석 결과가 조용히 틀어집니다. "스키마가 바뀌면 누가 누구에게 알리는가"를 점검표에 넣어두는 것이 좋습니다.

3) 활용 구간 — 숫자가 결정으로 이어지는가

세 번째는 활용 구간입니다. 대시보드를 누가, 어느 주기로 보는지, 알람이 울리면 누가 받는지, 보고서의 숫자가 실제 결정에 쓰이는지를 확인합니다. 4편의 운영 설계가 현장에서 살아 있는지를 보는 단계입니다. 대시보드는 있는데 아무도 안 보거나, 알람은 울리는데 받는 사람이 없으면, 그 구간은 이미 멈춘 것과 같습니다. 점검표의 마지막 문항은 그래서 이렇게 묻습니다. "지난 한 달, 이 데이터로 내린 결정이 무엇인가." 대답이 없으면, 파이프라인이 아니라 활용부터 다시 손봐야 합니다.

최종회 결론 — 점검표는 문서가 아니라 약속이다

정리하면 이렇습니다. 수집은 '들어오고 있는가', 전송·저장은 '끊겨도·쌓여도 괜찮은가', 활용은 '결정으로 이어지는가'. 이 세 문항만으로도 파이프라인 전체의 건강 상태를 대략 가늠할 수 있습니다. 점검 주기는 월 1회면 충분합니다. 길게 잡을 필요도 없습니다. 30분, 세 구간을 한 번씩 훑는 것만으로 "믿을 수 있는 숫자"와 "그냥 쌓인 숫자"를 구분할 수 있습니다.

그래서 뭘 하면 되나 — 오늘 이 글의 세 문항을 복사해서 팀 점검표 첫 페이지로 만들어 보세요. 그리고 다음 달 같은 날, 다시 한 번 답해 보세요. 파이프라인의 완성은 구축이 아니라, 이렇게 정기적으로 점검하는 습관에서 옵니다. 현장 데이터 파이프라인 시리즈는 여기서 마칩니다. 다음 시리즈에서 또 이어집니다.

왜 어긋나나 — 현장과 모델이 벌어지는 세 가지 이유

첫째, 설비가 바뀐다. 센서 하나를 교체했는데 측정 범위가 달라지고, 지그를 바꾸면서 작업 순서가 미세하게 달라진다. 둘째, 공정이 바뀐다. 생산 품목이 바뀌면 사이클 타임도, 부하 패턴도 달라진다. 셋째, 센서 자체가 늙는다. 드리프트는 갑자기 오는 게 아니라 조금씩 쌓인다. 이 세 가지가 조용히 쌓이면, 어느 날 트윈이 보여주는 숫자와 현장 작업자의 감이 정반대가 된다.

어긋남을 알아채는 신호 세 가지

신호는 대개 숫자가 아니라 사람의 반응에서 먼저 보인다. 작업자가 "트윈은 참고만 해요"라고 말하기 시작하면 이미 신뢰가 깨진 상태다. 두 번째 신호는 알람의 무감각이다. 알람이 너무 자주 울리면 사람은 알람을 끄고, 너무 안 울리면 고장을 놓친다. 세 번째는 예측과 실적의 간격이 한 방향으로만 벌어지는 것이다. 가끔 틀리는 건 정상이지만, 한쪽으로만 계속 벌어지면 모델이 아니라 기준이 낡았다는 뜻이다.

재캘리브레이션 루틴 — 트윈을 현장에 붙들어두는 방법

그래서 뭘 하면 되나 — 트윈에도 점검 주기를 두는 것이다. 첫째, 기준을 정한다. 어떤 설비, 어떤 지표, 어느 정도 오차까지 허용할지를 문서로 남긴다. 둘째, 변경을 트윈에 반영하는 절차를 만든다. 설비 교체나 공정 변경이 있을 때 트윈 업데이트를 같은 작업지시서에 넣는 것이다. 셋째, 책임자를 정한다. "다 같이 본다"는 말은 결국 아무도 안 본다는 뜻이 되기 쉽다. 주기는 현장마다 다르지만, 최소한 분기 한 번은 예측과 실적을 나란히 놓고 보는 시간을 갖는 것이 좋다.

마무리

디지털트윈은 한 번 만드는 프로젝트가 아니라, 현장과 함께 늙어가는 운영의 대상이다. 모델이 현장과 어긋나는 건 실패가 아니라 관리가 필요하다는 신호다. 오늘 할 일은 하나다. 내 담당 트윈의 예측과 실적을 한 장으로 나란히 놓고, 벌어진 방향이 있는지 확인해보는 것이다.

관련 글: 디지털트윈이 '실시간'이 되는 조건(https://developer-archive.tistory.com/132), 디지털트윈의 '해상도'(https://developer-archive.tistory.com/147), 디지털트윈의 진짜 엔진은 데이터 수집(https://developer-archive.tistory.com/124)

PoC는 Proof of Concept, 우리말로 '개념 검증'이다. 제조 현장에서 PoC는 "이 AI, 우리 라인에서 정말 돌아가나?"를 전면 도입 전에 작게 확인하는 과정이다. 멋진 데모 영상이 아니라, 현장 조건에서 돌아가는지를 확인하는 시험이다.

PoC는 '데모'가 아니다

데모는 잘되는 장면만 보여줘도 된다. PoC는 그 반대다. 안 되는 조건을 일부러 찾아내야 한다. 조명이 바뀔 때, 속도가 올라갈 때, 먼지가 쌓일 때 — 그때도 결과가 유지되는지가 PoC의 본질이다. 그래서 현장 7년차의 기준은 단순하다. "예쁘게 돌아가나요?"가 아니라 "망가지는 조건을 알고 있나요?"다.

현장 PoC는 이렇게 작게 시작한다

PoC 범위를 처음부터 크게 잡으면 검증이 아니라 구축이 된다. 한 설비, 한 공정, 한 불량 유형부터 시작하는 것이 좋다.

1단계는 대상 고정이다. 한 공정·한 불량 유형으로 범위를 고정하고, 측정 지표 1~2개를 확정하는 것이 종료 기준이다. 2단계는 데이터 확인이다. 실제 현장 데이터로 테스트하며, 데모용 데이터 사용은 금지다. 3단계는 현장 조건 테스트다. 조명·속도·오염 변수를 포함하고, 실패 조건을 문서화한다. 4단계는 판정이다. 도입·보완·중단 중 하나를 선택하며, "좀 더 해보자"는 판정이 아니다.

종료 기준이 없는 PoC는 끝나지 않는다. "정확도 몇 % 이상이면 다음 단계로" 같은 숫자를 시작 전에 정해두는 것이 PoC를 살리는 가장 쉬운 방법이다.

PoC를 통과했다고 끝이 아니다

PoC 통과는 시작일 뿐이다. 다음은 파일럿이다. 한 라인에서 일정 기간 운영하면서 유지보수 비용, 오작동 시 대응 절차, 작업자 교육까지 확인한다. 파일럿을 거치지 않고 전 공장으로 확산하면, 작은 오류가 전사 오류가 된다.

예지정비나 엣지 컴퓨팅 같은 기술도 마찬가지다. 기술이 새롭다고 도입이 빨라지는 것이 아니라, 검증 단계가 촘촘할수록 확산이 빨라진다.

마무리: PoC 전에 이 세 가지만 확인하자

1. 무엇을 검증하는지 한 문장으로 말할 수 있는가?

2. 성공·실패 기준을 숫자로 정했는가?

3. 실패했을 때 중단할 수 있는가?

세 가지에 답할 수 있다면, 그 PoC는 이미 절반은 성공이다. 도입 전에 작게 검증하는 습관이 현장 AI의 실패 비용을 가장 크게 줄인다.

관련 글: 예지정비 심화(https://developer-archive.tistory.com/126), MQTT 심화(https://developer-archive.tistory.com/151), 엣지 컴퓨팅 심화(https://developer-archive.tistory.com/157)