프로그래밍 허브

피지컬 AI 얘기가 나오면 늘 같은 그림이 떠올랐다. 수천만 원, 아니 수억 원짜리 휴머노이드가 공장 바닥을 걷는 장면. 멋있지만, 그 그림 앞에서 대부분의 현장 엔지니어와 개발자는 구경꾼으로 남을 수밖에 없었다. 그런데 11월 1일, 그 구도가 깨졌다는 소식이 전해졌다. 399달러(약 53만 원)짜리 소형 이족보행 로봇 '마이크로덕(Microduck)'의 사전예약이 2만 대를 넘었다는 소식이다.

출처: 전자신문, 2026년 11월 1일, "399달러 오리 로봇만이 아니다…저가형 피지컬AI 로봇 잇단 등장"

왜 중요한가: 피지컬 AI의 진입 문턱이 '가격'에서 무너졌다

마이크로덕은 높이 25cm, 무게 800g 미만의 작은 로봇이다. 15개의 소형 서보 모터와 카메라, 소형 LiDAR, 2개의 IMU를 탑재하고 걷고, 앉고, 앞구르기를 한다. 지난 10월 독일 베를린 엔비디아 GTC 행사에서 젠슨 황 CEO가 무대 위에서 음성 명령으로 직접 시연했고, 시연 직후 하루 만에 사전예약 2만 대를 돌파했다. 초도 양산 물량은 2026년 크리스마스 이전 배송 예정, 가격은 399달러다.

핵심은 스펙이 아니라 구조다. 고가 휴머노이드가 로봇 안에 고성능 GPU·NPU를 넣는 방식과 달리, 마이크로덕 같은 저가 로봇은 무거운 연산을 외부 PC나 클라우드에서 처리한다. 개발자는 MuJoCo나 엔비디아 Isaac Lab 같은 가상 물리 엔진에서 수만 번의 넘어짐을 강화학습으로 학습시키고, 그 정책을 실제 로봇에 이식하는 '심투리얼(Sim-to-Real)' 파이프라인을 쓴다. 로봇 본체는 가볍게, 학습은 바깥에서 무겁게. 그래서 399달러가 가능해진 것이다.

같은 흐름은 로봇팔에서도 이어진다. 허깅페이스의 오픈소스 로봇 AI 플랫폼 '르로봇(LeRobot)'과 연계되는 SO-101 로봇팔은 기본 부품 기준 100달러(약 13만 원)부터 만들 수 있다. 미국의 소형 사족보행 로봇 '비틀 X'는 319달러, 중국의 소형 휴머노이드 '토니파이'는 약 600달러부터다. 고성능 휴머노이드를 대체하는 제품이 아니라, 개인 개발자와 연구기관이 AI 모델을 실제 로봇에서 검증하는 플랫폼이라는 점이 분명하다.

7년차 현장 관점: 공장에 들어가기 전에, 손으로 먼저 배워야 한다

7년차 현장 엔지니어로서 한 줄로 정리하면 이렇다. 피지컬 AI의 병목은 로봇 스펙이 아니라 '실패를 얼마나 싸게 경험하느냐'다.

현장에서는 로봇 한 대가 넘어지는 비용이 크다. 라인이 멈추고, 안전 검토가 붙고, 보고서가 따라온다. 그래서 시뮬레이션에서 배운 정책이 현장에서 살아남는지를 검증하는 단계가 늘 비싸고 느렸다. 그런데 53만 원짜리 로봇이라면 얘기가 달라진다. 책상 위에서 수백 번 넘어뜨려보고, 정책을 고치고, 다시 돌려볼 수 있다. 실패 기록이 쌓이는 속도가 곧 학습 속도가 된다. 지난달 다룬 중기부 피지컬 AI 확산 전략, 삼일PwC 보고서가 말한 '현장 배치'의 전 단계가 바로 이 '책상 위 검증'이다. 거대한 휴머노이드 도입을 논하기 전에, 팀 안에서 피지컬 AI를 만져본 사람이 몇 명인지가 먼저다.

그래서 뭘 하면 되나: 399달러짜리부터, 현장 문제 하나에 붙여보기

그래서 뭘 하면 되나, 세 가지로 정리한다. 첫째, 팀에 피지컬 AI 학습용 소형 로봇 한 대를 두고, 시뮬레이션-실기 전이(Sim-to-Real) 파이프라인을 직접 돌려본다. MuJoCo나 Isaac Lab에서 보행 정책을 학습시키고 실제 기기에 이식하는 경험 자체가 자산이다. 둘째, 현장의 작은 문제 하나를 골라 로봇팔(SO-101 같은 저가 플랫폼)로 물체 조작을 학습시켜본다. 불량품 집기, 부품 정렬 같은 좁은 과제부터다. 셋째, 실패 로그를 남긴다. 넘어진 이유, 미끄러진 바닥 조건, 조명이 바뀔 때의 인식 오차 — 이 기록이 나중에 공장용 로봇을 들여올 때의 검증 체크리스트가 된다.

비싼 로봇이 피지컬 AI의 시작이 아니었다. 만져보고, 넘어뜨리고, 다시 세우는 작은 로봇이 시작이다. 399달러 오리 한 마리가 그 문을 열었다.

이 글은 '현장 AI 운영 노트' 시리즈의 다섯 번째 글입니다. 1편에서는 매일 아침 AI의 건강을 보는 5분 점검표를, 2편에서는 그 점검표를 대시보드 하나로 만드는 법을, 3편에서는 경보가 울렸을 때 누가 어떤 순서로 움직이는지 조치 루틴을, 지난 편에서는 한 달 돌린 경보 루틴을 숫자로 리뷰하는 법을 다뤘습니다 (EP.1 https://developer-archive.tistory.com/175 · EP.2 https://developer-archive.tistory.com/180 · EP.3 https://developer-archive.tistory.com/184 · EP.4 https://developer-archive.tistory.com/190). 이번 편에서는 그 월간 리뷰를 세 번 쌓은 뒤, 분기 단위에서 재학습 여부를 판단하는 기준을 다룹니다.

한 달 리뷰를 잘했다고 재학습 결정이 쉬워지는 건 아닙니다. 월간 리뷰는 경보를 다듬는 일이고, 재학습은 모델 자체를 바꾸는 일이라 무게가 다릅니다. 그래서 현장에서 가장 많이 하는 실수가 두 가지입니다. 하나는 모델이 조금만 틀려도 바로 재학습을 돌리는 것, 다른 하나는 성능이 떨어지는 게 보이는데도 "다음 분기에"라며 미루는 것입니다. 둘 다 기준이 없어서 생기는 일입니다. 분기 리뷰의 역할은 재학습을 자주 하자는 것도, 미루자는 것도 아니라, "이 숫자면 재학습, 저 숫자면 유지"라는 선을 미리 정해두는 것입니다.

1. 재학습의 근거는 정확도가 아니라 '현장 지표의 추세'다

분기 리뷰에서 가장 먼저 볼 것은 모델 정확도 자체가 아니라, 월간 리뷰에서 쌓인 현장 지표의 추세입니다. 예를 들어 경보의 무조치 비율, 조치까지 걸린 시간, 오탐으로 라인이 선 횟수 같은 숫자들입니다. 정확도는 테스트 데이터에서 좋아 보일 수 있지만, 이 지표들은 현장에서 모델이 실제로 사람을 얼마나 돕고 있는지를 보여줍니다.

저는 세 달 치 월간 리뷰를 나란히 놓고 이렇게 묻습니다. 무조치 경보 비율이 계속 오르고 있는가, 조치 시간은 길어지고 있는가, 같은 원인으로 반복되는 실패가 늘고 있는가. 세 가지 중 두 가지 이상이 악화 추세면 재학습 후보로 올립니다. 한 달만 나빠진 건 계절성이나 일시적 로트 변화일 수 있지만, 세 달 연속이면 모델이 현장과 어긋나고 있다는 신호로 봅니다.

2. 재학습 전에 '데이터가 문제인지, 모델이 문제인지'부터 가른다

재학습 후보로 올랐다고 바로 학습을 돌리면 안 됩니다. 먼저 틀린 사례를 모아 원인을 가릅니다. 라벨 기준이 바뀌어서 틀린 건지, 새로운 불량 유형이 들어와서 틀린 건지, 센서나 조명 같은 입력 조건이 달라져서 틀린 건지. 라벨 기준이 바뀐 거라면 재학습보다 기준 정리와 재라벨링이 먼저이고, 입력 조건이 달라진 거라면 데이터 수집 조건을 고치는 게 먼저입니다.

현장에서 써먹는 구분법은 간단합니다. 틀린 사례 30건을 놓고, "이건 사람이 봐도 판정이 애매한가, 아니면 모델만 틀린 건가"를 묻는 것입니다. 사람이 봐도 애매한 게 많으면 기준과 데이터가 문제이고, 사람이 쉽게 맞추는데 모델만 틀리면 모델이 문제입니다. 전자에 재학습을 돌리면 애매한 기준을 그대로 학습시켜서, 오히려 현장 혼란만 커집니다.

3. 재학습 결정은 '비용'까지 넣어 한 장으로 정한다

마지막으로, 재학습 여부를 정할 때는 성능 숫자만 보지 않고 비용도 함께 적습니다. 재학습에 드는 데이터 수집·라벨링 시간, 검증 기간, 배포 후 모니터링 부담, 그리고 재학습을 안 했을 때 현장에서 계속 감당해야 할 오탐·미탐 비용까지 말입니다. 재학습 비용보다 방치 비용이 커질 때가 재학습 시점입니다.

분기 리뷰 한 장의 양식은 이렇습니다. 현장 지표 3가지의 3개월 추세, 틀린 사례 30건의 원인 분류, 재학습 비용과 방치 비용의 비교, 그리고 결정 한 줄. 결정은 "재학습한다 / 유지한다 / 기준·데이터부터 고친다" 중 하나로만 적습니다. "좀 더 지켜본다"는 결정이 아니라 미루는 말이라, 저는 분기 리뷰에서 그 문장을 쓰지 않습니다.

그래서 뭘 하면 되나 — 이번 분기 리뷰에서 할 3가지

이번 분기 말이 오기 전에, 지난 세 달의 월간 리뷰 표를 한 장으로 모아보세요. 현장 지표가 악화 추세인지, 틀린 사례 30건의 원인이 데이터인지 모델인지, 재학습과 방치 중 어느 쪽 비용이 큰지. 이 세 가지가 채워지면 재학습 결정은 감이 아니라 문서가 됩니다. 모델을 바꾸는 결정일수록, 근거를 한 장에 남기는 습관이 현장을 지킵니다. 다음 편에서는 재학습을 하기로 정한 뒤, 배포 전에 반드시 거치는 검증 단계를 다룹니다.

관련 글: 현장 AI 운영 노트 EP.1(https://developer-archive.tistory.com/175), EP.2(https://developer-archive.tistory.com/180), EP.3(https://developer-archive.tistory.com/184), EP.4(https://developer-archive.tistory.com/190), 데이터 드리프트(https://developer-archive.tistory.com/133), AI 모델 평가를 현장 지표로(https://developer-archive.tistory.com/164)

요즘 제조 AI 얘기를 들으면 모델이 좋아졌다는 소식부터 나옵니다. 더 큰 모델, 더 빠른 추론, 더 낮은 비용. 그런데 현장에 들어가 보면 이상합니다. 데모에서는 잘 되던 모델이 라인에서는 자꾸 어긋나고, "좋아졌다"는 말이 현장 지표로는 잘 안 보입니다. 제 경험으로는 이 간극의 상당 부분이 모델 자체가 아니라 '평가'에 있습니다. 무엇을 기준으로 좋다고 말할 것인가, 그 기준을 현장 데이터로 만들었는가가 관건입니다.

데모의 정확도와 현장의 합격률은 다른 숫자다

데모용 데이터는 대개 깨끗합니다. 조명도 일정하고, 불량 유형도 대표 사례 위주입니다. 반면 라인은 조명이 바뀌고, 먼지가 쌓이고, 작업자가 바뀌고, 제품 로트가 바뀝니다. 같은 모델이라도 평가 데이터가 데모 세트면 99%가 나오고, 한 달치 실제 라인 데이터면 90% 아래로 떨어지는 일이 흔합니다. 숫자가 틀린 게 아니라, 재는 자가 다른 겁니다. 그래서 저는 모델을 고르기 전에 먼저 묻습니다. "이 정확도는 어떤 데이터로 잰 겁니까?" 그 답이 없으면, 그 정확도는 현장에서 쓸 수 없는 숫자입니다.

현장 평가 세트는 '모으는' 게 아니라 '설계하는' 것이다

현장 평가 데이터를 만들 때 가장 흔한 실수는 있는 데이터를 그냥 쌓는 것입니다. 그러면 잘 찍힌 정상품만 많아지고, 정작 판단이 어려운 경계 사례는 빠집니다. 제가 현장에서 쓰는 기준은 세 가지입니다. 첫째, 정상·불량·경계(애매한) 사례를 일부러 골고루 넣을 것. 둘째, 시간·조명·로트·작업자 같은 현장 변수를 일부러 섞을 것. 셋째, 정답 라벨을 현장 기준, 즉 "이건 출하해도 되는가"로 정할 것. 연구실 기준이 아니라 출하 기준이어야 합니다. 이 세 가지가 빠지면 평가 세트는 커지기만 하고, 현장에서는 여전히 틀립니다.

그래서 뭘 하면 되나 — 이번 주에 할 수 있는 3가지

7년차 현장 엔지니어로서, 거창한 프로젝트부터 시작하지 말라고 권하고 싶습니다. 먼저, 최근 한 달간 모델이 틀린 사례 30건만 모아보세요. 틀린 이유가 모델인지, 데이터인지, 라벨 기준인지가 보이기 시작합니다. 다음으로, 평가 세트에 '어려운 사례'의 비중을 정해 두세요. 예를 들어 경계 사례를 최소 20%는 넣는 식입니다. 마지막으로, 평가 주기를 정하세요. 모델을 바꿀 때마다 같은 평가 세트로 다시 재는 습관이 없으면, 개선인지 우연인지 구분할 수 없습니다.

모델이 좋아지는 속도는 빠릅니다. 그런데 현장이 모델을 믿는 속도는 평가가 따라갈 때만 빨라집니다. 평가 데이터를 현장 기준으로 다시 설계하는 일, 그게 요즘 제조 AI에서 가장 실속 있는 투자라고 생각합니다. 여러분 현장의 평가 기준은 데모용인가요, 출하용인가요?

요즘 공장 뉴스를 보면 로봇이 사람을 대신하는 장면이 먼저 떠오른다. 그런데 7년차 현장 엔지니어로서 내가 먼저 보는 건 로봇의 스펙이 아니라 작업 지시서다. 로봇이 무엇을, 어떤 순서로, 어디까지 해도 되는지가 문서에 없으면, 현장에서는 결국 사람이 옆에서 계속 붙어 있어야 한다. 피지컬 AI의 진짜 변화는 기계가 움직인다는 데서 오는 게 아니라, 일의 정의가 바뀐다는 데 있다.

로봇이 보는 '작업'은 사람의 작업과 다르다

사람은 말하지 않아도 되는 맥락을 안다. "이건 대충 넘겨도 된다", "여기는 절대 건드리면 안 된다" 같은 판단을 현장 경험으로 채운다. 로봇은 그 빈칸을 채우지 못한다. 그래서 지시서는 '무엇을 하라'에서 '무엇을 보고, 무엇을 기준으로, 무엇이 되면 멈추라'로 바뀌어야 한다. 기준이 애매하면 로봇은 멈추거나, 더 위험하게는 멈추지 않는다. 현장에서 로봇 도입이 지지부진한 경우를 보면, 대개 로봇이 나빠서가 아니라 기준이 문서에 없었던 경우가 많다.

지시서를 바꾸는 세 가지 질문

첫째, 무엇을 보고 판단하나 — 지시서에 적어야 할 것은 센서 값, 이미지, 작업자 신호 중 판단 근거이다. 둘째, 어디까지가 정상인가 — 허용 오차, 허용 시간, 재시도 횟수를 적어야 한다. 셋째, 안 되면 누가, 어떻게 멈추나 — 정지 조건, 복귀 절차, 보고 경로를 적어야 한다.

이 표를 채우다 보면 의외로 많은 지시서가 "숙련자 판단에 따름"으로 끝나 있다는 걸 알게 된다. 그 문장 하나가 로봇에게는 없는 것이고, 사람에게도 새로 온 사람에게는 없는 것이다. 지시서를 로봇용으로 다시 쓰는 작업은 결국 사람이 일하는 방식을 다시 정리하는 작업과 같다. 그래서 이 과정이 귀찮아 보일수록, 도입 후 되돌릴 일도 적어진다.

그래서 뭘 하면 되나

1. 지금 쓰는 지시서 한 장을 골라 '판단 기준' 문장에 밑줄을 쳐본다.

2. 그 기준을 숫자로 바꿀 수 있는지 확인한다. 숫자로 못 바꾸면, 그 판단이 정말 필요한지 다시 묻는다.

3. 로봇을 들이기 전에, 사람이 그 기준으로 같은 작업을 반복할 수 있는지 시험한다. 사람이 재현하지 못하는 기준은 로봇도 재현하지 못한다.

로봇 도입의 성패는 도입 당일이 아니라, 도입 전에 일을 얼마나 정확히 정의했는지에서 갈린다. 지시서 한 장이 바뀌면 로봇의 행동이 바뀌고, 현장의 안전도 바뀐다. 11월, 로봇 뉴스를 볼 때 스펙표보다 그 공장의 지시서가 어떻게 바뀌었는지 먼저 물어보자.

1. "이 값은 항상 들어온다"는 가정을 찾아라

센서값이 끊기지 않고, 단위가 바뀌지 않고, 타임스탬프가 순서대로 들어온다는 가정. 개발실에서는 당연해 보이지만, 현장에서는 통신 단절·센서 교체·설비 재기동이 일상입니다. 리뷰할 때는 입력이 비거나 늦거나 튀는 경우를 코드가 어떻게 처리하는지부터 봅니다. 예외 처리가 없는 코드는 현장에서 첫 번째 장애의 원인이 됩니다.

2. "이 판단은 사람이 확인한다"는 가정을 확인하라

AI가 불량 판정을 내렸을 때, 그 결과를 누가, 언제, 어떤 권한으로 뒤집는지 코드에 명시되어 있습니까? 판단의 주인이 불분명한 코드는 현장에서 아무도 책임지지 않는 판정을 만듭니다. 이전 글에서 다룬 '행동 권한' 설계(https://developer-archive.tistory.com/167)와 연결되는 지점입니다. 리뷰 체크리스트에 "판정 → 확인자 → 되돌리기 경로"가 있는지 꼭 넣으세요.

3. "이 숫자는 현장 지표다"를 검증하라

정확도 99% 같은 개발 지표가 아니라, 오탐 1건당 작업자가 멈추는 라인 시간 같은 현장 지표로 코드가 평가되는지 봅니다. 모델 평가를 현장 지표로 바꾸는 법은 https://developer-archive.tistory.com/164 에서 자세히 다뤘습니다. 리뷰 때는 지표 정의 부분부터 읽는 습관이, 나중에 "왜 현장에서 못 쓰냐"는 질문을 줄여줍니다.

그래서 뭘 하면 되나

다음 코드 리뷰부터는 모델 구조보다 위 3가지 가정부터 확인해 보세요. 재현성 있는 개발 환경(https://developer-archive.tistory.com/125) 위에, 가정이 명시된 코드가 쌓일 때 현장 AI는 비로소 오래 갑니다.

로봇 한 대를 더 똑똑하게 만드는 시대는 지났다. 이제는 로봇 여러 대가 경험을 나누며 함께 성장하는 시대가 열리고 있다. 2026년 10월 30일 공개된 칭화대·애지봇(智元)·무문심궁(无问芯穹)의 공동 연구가 그 증거다. 로봇 96대를 묶어 서로의 실행 경험을 공유하게 했더니, 다섯 가지 실제 작업에서 성공률이 93.3%에서 99.2%까지 올라갔다.

왜 중요한지 — 실패가 '자산'이 되는 구조

이 연구의 핵심은 '집단 경험 학습(CEL)'이다. 로봇이 실패한 순간의 맥락을 단서로 삼아, 군집 전체가 쌓은 성공 경험에서 비슷한 구간을 찾아내고 그 동작을 교사 신호로 삼아 정책을 고친다. 실패를 숨기거나 버리는 게 아니라, 다음 학습의 재료로 돌리는 구조다. 이를 구현한 방법이 '실패 유도 경험 검색 미세조정(FERT)'이고, 대규모 군집을 지탱하는 시스템이 '오류 허용 비동기 학습 시스템(FATS)'이다.

숫자가 말해준다. 다단계 휴대폰 포장 작업에서 96대 학습 후 성공률은 79.2%에서 98.3%로 뛰었다. 로봇 한 대당 수집 시간을 고정하고 대수만 늘렸는데도 성능이 함께 좋아졌다. 즉, 배포 규모가 커질수록 경험 공급도 같이 커지는, 확장 가능한 학습 구조라는 뜻이다. 평가에 참여한 로봇은 훈련 데이터 수집에 참여하지 않았는데도 이 성적을 냈다는 점이 더 의미 있다.

현장에서 읽는 포인트 — '한 대의 명품'이 아니라 '군집의 운영'

7년차 현장 엔지니어로서, 이 연구에서 가장 와닿는 지점은 이것이다. 현장의 병목은 로봇 한 대의 손재주가 아니라, 수십 대가 동시에 돌아갈 때 터지는 편차와 예외 처리다. 한 대가 배운 요령이 다른 대에 전파되지 않으면, 현장은 같은 실패를 대수만큼 반복한다. 군집 학습은 바로 이 지점을 정면으로 겨냥한다.

다만 주의할 점도 있다. 이 결과는 꽃꽂이, 옷 개기, 휴대폰 충전, 의자 조립, 휴대폰 포장이라는 다섯 가지 작업에서 나온 것이다. 공장 바닥의 먼지, 진동, 작업자 동선, 설비 편차까지 그대로 옮겨갈 거라고 단정해서는 안 된다. 성공률 99%도 나머지 1%가 어떤 실패인지에 따라 현장 가치가 달라진다. 그래서 뭘 하면 되나 — 로봇을 도입할 때 '한 대의 데모 성공률'이 아니라 '실패를 어떻게 수집하고, 누구에게 전파하고, 얼마나 빨리 고치는가'를 먼저 물어야 한다.

그래서, 우리 공장은 무엇을 준비해야 하나

첫째, 실패 기록을 남기는 습관이다. 어떤 상황에서, 어떤 동작이, 왜 틀렸는지 남지 않으면 군집이 배울 재료 자체가 없다. 둘째, 로봇 간 데이터 형식과 평가 기준을 통일하는 일이다. 경험이 공유되려면 '같은 언어로 기록'돼야 한다. 셋째, 사람 감독의 역할 재정의다. 연구진도 말하듯, 군집이 커지면 사람의 감독을 같은 비율로 늘릴 수는 없다. 사람은 모든 동작을 감시하는 대신, 실패의 기준을 정하고 예외를 승인하는 자리로 이동해야 한다.

로봇 경쟁의 단위가 바뀌고 있다. 한 대의 스펙이 아니라, 몇 대를 얼마나 빨리 함께 성장시키느냐가 경쟁력이 되는 시대다. 우리 공장의 다음 질문도 그에 맞춰 바뀌어야 한다. "로봇 몇 대를 살까"가 아니라 "우리 로봇들은 서로 배우고 있는가"다.

출처: 36Kr 보도(2026년 10월 30일 연구 공개 정리, 논문 arXiv:2610.25736), 김경진 AI '중국 AI·로봇·반도체·통신 심층 브리핑 2026년 10월 31일' 정리.

이 글은 '현장 AI 운영 노트' 시리즈의 네 번째 글입니다. 1편에서는 매일 아침 AI의 건강을 보는 5분 점검표를, 2편에서는 그 점검표를 대시보드 하나로 만드는 법을, 지난 편에서는 경보가 울렸을 때 누가 어떤 순서로 움직이는지 조치 루틴을 다뤘습니다 (https://developer-archive.tistory.com/175 · EP.2 https://developer-archive.tistory.com/180 · EP.3 https://developer-archive.tistory.com/184). 이번 편에서는 루틴을 한 달 돌린 뒤, 경보를 줄이고 기준을 다듬는 '운영 리뷰'를 다룹니다.

경보 루틴을 만들었다고 운영이 끝난 게 아닙니다. 루틴은 만든 날이 아니라 한 달 돌린 뒤에 진짜 모습이 드러납니다. 어떤 경보는 한 번도 안 울리고, 어떤 경보는 매일 울리는데 아무도 신경을 안 씁니다. 이 상태를 그대로 두면, 루틴은 종이에만 있는 절차가 됩니다. 그래서 한 달에 한 번, 경보 루틴 자체를 리뷰하는 시간이 필요합니다.

1. 리뷰는 경보 개수가 아니라 '움직인 횟수'로 본다

리뷰에서 가장 먼저 볼 숫자는 경보가 몇 번 울렸는지가 아니라, 울린 경보 중 실제로 누군가 움직인 게 몇 번인지입니다. 경보 100번 중 현장 확인이 10번이면, 나머지 90번은 경보가 아니라 소음입니다. 반대로 경보 5번 중 5번 다 움직였다면, 그 경보는 개수는 적어도 운영에 꼭 필요한 경보입니다. 그래서 저는 리뷰 표의 첫 줄을 '경보별 울림 횟수 / 조치 횟수 / 조치 없이 지나간 횟수'로 적습니다. 조치 없이 지나간 비율이 높은 경보부터 의심합니다. 기준이 너무 예민하거나, 경보 자체가 현장과 무관하거나, 둘 중 하나입니다. 숫자가 말해주기 전까지는 어느 쪽인지 단정하지 않는 게 좋습니다.

2. 예민한 경보는 기준을 바꾸고, 무관한 경보는 끈다

조치 없이 지나간 경보가 많다고 해서 무조건 기준을 늦추면 안 됩니다. 먼저 왜 움직이지 않았는지부터 확인합니다. 기준이 너무 예민해서 현장에서 '또 그 경보'라며 넘긴 건지, 아니면 경보가 가리키는 게 현장에서 손댈 수 없는 건지. 전자는 기준을 다듬을 문제이고, 후자는 경보를 끄거나 받는 사람을 바꿀 문제입니다. 기준을 다듬을 때는 한 번에 크게 바꾸지 않습니다. 예를 들어 뒤집기 비율 기준을 5%에서 10%로 올린 뒤, 다음 한 달은 그 기준으로 다시 봅니다. 기준을 두 개씩 바꾸면 어느 변경이 효과가 있었는지 모릅니다. 운영 리뷰의 원칙은 실험과 같습니다. 한 번에 하나씩, 결과를 숫자로 확인합니다.

3. '멈춘다' 기준은 더 엄격하게, '지켜본다'는 더 가볍게

지난 편에서 정한 심각도 3단계도 리뷰 대상입니다. '멈춘다' 기준이 한 달에 한 번도 발동하지 않았다면, 기준이 너무 높거나 라인이 운이 좋았던 겁니다. 반대로 '멈춘다'가 매주 발동한다면, 기준이 너무 낮아 라인이 자주 서는 겁니다. 어느 쪽이든 기준을 현장 영향에 맞춰 다시 정합니다. 반대로 '지켜본다' 단계는 가볍게 두는 게 좋습니다. 지켜본다는 건 추이를 본다는 뜻이지, 무시한다는 뜻이 아닙니다. 추이를 보다 보면, 나중에 '확인한다'로 올려야 할 경보가 보입니다. 예를 들어 뒤집기 비율이 3주 연속 조금씩 오르고 있다면, 아직 경보는 아니지만 기준을 올리기 전에 원인을 먼저 살펴볼 신호입니다.

그래서 뭘 하면 되나 — 한 달 운영 리뷰 한 장

이번 달 말에 이렇게 해보세요. 경보별로 울림·조치·무조치 횟수를 적고, 무조치 비율이 높은 경보 3개만 골라 원인을 적습니다. 기준이 예민한지, 경보가 무관한지, 받는 사람이 잘못됐는지. 그리고 다음 달에 바꿀 기준은 딱 하나만 정합니다. 한 달 뒤, 그 하나가 경보 수를 어떻게 바꿨는지 숫자로 확인합니다. 운영 리뷰는 시스템을 고치는 회의가 아닙니다. 경보가 사람을 지치게 만들지 않는지, 사람이 경보를 믿고 움직이는지를 점검하는 일입니다. 경보를 줄이는 게 목표가 아니라, 울린 경보마다 누군가 움직이는 상태를 만드는 게 목표입니다. 다음 편에서는 이 리뷰를 분기 단위로 묶어, 모델 재학습 여부를 판단하는 기준을 다룹니다.

관련 글: 현장 AI 운영 노트 EP.1(https://developer-archive.tistory.com/175), EP.2(https://developer-archive.tistory.com/180), EP.3(https://developer-archive.tistory.com/184), 데이터 드리프트(https://developer-archive.tistory.com/133), AI 모델 평가를 현장 지표로(https://developer-archive.tistory.com/164)

정부가 10월 29일, 중소기업 공장에 AI와 로봇을 넣는 큰 그림을 내놨다. 중소벤처기업부가 국무총리 주재 국가정책조정회의에서 발표한 '중소제조 피지컬 AI 확산 전략'이다. 2030년까지 스마트제조혁신에 5조 원 이상을 투입하고, AI를 도입한 중소 제조기업을 지금 600곳에서 6,000곳으로 열 배 늘리겠다는 목표다. 디지털 전환율도 30%에서 50%로, AI 도입률은 1%에서 10%로 끌어올리겠다는 숫자까지 함께 나왔다. 출처: 뉴스핌(2026-10-29), 서울경제(2026-10-29).

피지컬 AI, 이번엔 '로봇 스펙'이 아니라 '생산방식'이다

피지컬 AI는 현실을 인식하고 판단해 로봇·장비로 직접 움직이는 AI다. 이번 전략이 눈에 띄는 이유는 휴머노이드 한 대를 자랑하는 데서 멈추지 않기 때문이다. 정부는 개별 설비 자동화를 넘어 데이터와 AI, 로봇을 연결해 생산방식 자체를 바꾸겠다고 했다. 공정별로는 K-푸드·K-뷰티 같은 수출 주력 업종의 수작업에 작업자 숙련·노하우를 학습한 AI를 적용하고, 주조·금형 같은 위험·유해공정에는 AI 로봇과 안전장치를 넣어 고열·분진 작업을 줄이는 실증을 추진한다. 검증된 공정 모델은 하나의 공장에 통합해 '스마트 로보팩토리'로 발전시키고, 2028년부터는 휴머노이드 보급 전용사업 신설도 검토한다.

현장에서 제일 반가운 대목은 '데이터를 현물로 쳐준다'는 부분이다

7년차 현장 엔지니어로서, 이번 전략에서 가장 현실적인 대목은 제조데이터 현물 인정이다. 정부 지원사업에 참여하는 기업이 제조데이터셋을 제공하면 가치를 평가해 현물 부담분으로 인정하고, 그만큼 현금 부담을 덜어주는 방식이다. 올해 가치평가 모델과 가이드라인을 만들고, 내년 자율형공장 구축사업 등에 시범 적용한 뒤 확대할 계획이다. 현장에서 데이터는 늘 "있긴 한데 못 쓰는" 상태였다. 장비마다 형식이 다르고, 로그는 쌓이지만 라벨도 기준도 없기 때문이다. 그래서 기존 인공지능제조플랫폼(KAMP)을 '제조AI 24'로 고도화해 데이터 형식을 표준화하고, 축적한 데이터로 모델을 개선해 다시 현장에 적용하는 체계를 만든다는 대목도 함께 읽어야 한다. 지원도 단계별로 나뉜다. 기반이 부족한 기업은 데이터 수집부터, 기반이 있는 기업은 공정 최적화와 자율제조로 나아가는 식이다. 2030년까지 1,000여 곳에 제조로봇을 보급하고, 스마트제조 전문기업은 올해 100곳 시범 지정에서 2030년 500곳까지 늘린다. 실무인력 교육도 올해 600명에서 내년 1,600명으로 확대한다.

그래서 뭘 하면 되나 — 지원받기 전에 공장부터 준비할 3가지

그래서 뭘 하면 되나. 지원 사업 공고만 기다리기 전에, 현장에서 먼저 준비할 일은 세 가지다. 첫째, 지금 설비에서 어떤 데이터가 어떤 주기로 나오는지 목록부터 만들 것. 형식이 달라도 괜찮다. 목록이 있어야 표준화도, 현물 평가도 시작된다. 둘째, 위험·수작업 공정 하나를 골라 "사람이 어떻게 판단하는지"를 문장으로 적어둘 것. 숙련 노하우가 문장이 되지 않으면 AI가 배울 재료가 없다. 셋째, 작은 공정 하나에서 로봇·AI 실증을 먼저 돌려보고, 그 결과를 다음 공정으로 옮길 기준을 정해둘 것. 6,000곳이라는 목표 숫자가 중요한 게 아니다. 우리 공장에서 데이터가 돈이 되는 첫 번째 사례 하나를 만드는 게 먼저다. 5조 원이라는 돈이 현장에 닿으려면, 결국 공장이 "데이터를 내놓을 준비가 된 곳"이어야 한다. 그 준비는 지원사업이 아니라, 오늘 현장의 기록 습관에서 시작된다.

디지털트윈  프로젝트를 시작할 때 팀이 가장 먼저 하는 일은 대개 3D 모델링입니다. 공장 레이아웃을 그리고, 설비를 배치하고, 화면을 예쁘게 만드는 일부터 시작합니다. 그런데 현장에서 7년을 일하며 본 실패 패턴은 놀랍게도 한결같습니다. 화면은 번듯한데, 정작 현장과 연결이 안 됩니다. 센서 값은 안 들어오고, 들어와도 어느 설비의 어떤 값인지 모릅니다. 문제는 3D가 아니라 순서입니다.

1. 3D부터 그리면 생기는 일

3D 모델은 보기에는 완성품 같지만, 데이터가 붙지 않으면 그냥 그림입니다. 현장에서 자주 보는 풍경이 있습니다. 모델링 업체는 설비 외형을 정교하게 만들었는데, PLC 태그 목록은 나중에 달라고 합니다. 태그 목록이 오면 이름 규칙이 제각각이라 모델의 어느 부품에 붙여야 할지 모릅니다. 결국 “일단 화면만”으로 끝나고, 트윈은 대시보드 구경용이 됩니다.

3D는 트윈의 얼굴이지, 엔진이 아닙니다. 엔진은 데이터입니다. 얼굴부터 만들고 엔진을 나중에 끼우면, 엔진 크기에 맞게 얼굴을 다시 뜯어야 합니다.

2. 데이터 흐름도부터 그리는 법

제가 현장에서 쓰는 순서는 이렇습니다. 먼저 설비별로 "무엇을, 어디서, 얼마나 자주, 어떤 이름으로" 뽑을지 적습니다. 온도·진동·압력 같은 측정 항목, PLC·센서·MES 같은 출처, 샘플링 주기, 태그 명명 규칙까지 한 장의 표로 만듭니다. 다음으로 그 데이터가 어떤 경로로 흘러가는지 그립니다. 센서에서 게이트웨이로, 게이트웨이에서 브로커로, 브로커에서 트윈 서버로. 이 그림이 데이터 흐름도입니다.

이 흐름도가 있으면 3D는 그다음에 자연스럽게 따라옵니다. 데이터가 붙을 자리가 이미 정해져 있기 때문입니다. 설비 하나를 추가해도 흐름도에 한 줄만 더하면 되고, 태그 이름이 바뀌어도 흐름도에서 한 번만 고치면 됩니다.

3. 흐름도가 현장에서 버는 돈

흐름도가 있으면 장애 대응이 달라집니다. 값이 안 들어올 때 "화면 문제인가, 통신 문제인가, 센서 문제인가"를 경로를 따라 순서대로 좁힐 수 있습니다. 예전에는 화면부터 뒤졌지만, 이제는 흐름도의 어느 구간에서 끊겼는지부터 봅니다. 원인 파악 시간이 줄고, 라인 정지 시간도 줄어듭니다.

또 하나, 흐름도는 외주·인수인계의 기준이 됩니다. 모델링 업체와 "이 태그를 이 주기로 이 이름으로 달라"고 문서로 주고받을 수 있으니, 나중에 "그런 말 없었다"는 다툼이 사라집니다. 트윈이 오래 살아남는 비결은 화려한 화면이 아니라, 데이터가 어떻게 흐르는지 누구나 볼 수 있게 남겨두는 것입니다.

마무리

디지털트윈을 시작한다면, 3D 프로그램부터 열지 마세요. 먼저 종이에라도 데이터 흐름도를 그려보세요. 설비 목록, 태그 이름, 주기, 경로. 이 네 가지만 정리돼도 트윈은 이미 절반은 만들어진 셈입니다. 화면은 나중에 예쁘게 만들면 됩니다. 현장과 연결되지 않은 예쁜 화면은, 공장 지도가 아니라 포스터일 뿐입니다.

10월 한 달, 아침 쇼츠 '제조AI 용어 사전'으로 열두 개 용어를 풀었습니다. 예지정비부터 산업용 사물인터넷까지, 하나씩은 알겠는데 막상 현장에서 "이게 다 어떻게 연결되냐"고 물으면 말이 막힐 때가 있습니다. 그래서 마지막 편은 복습입니다. 열두 개 용어를 세 층으로 묶어, 공장에서 데이터가 어떻게 흐르는지 한 장으로 정리합니다.

1층 — 연결: 기계가 말을 시작하는 층

현장의 시작은 언제나 연결입니다. 산업용 사물인터넷(IIoT)은 기계·센서가 네트워크로 데이터를 주고받는 환경 자체를 말합니다. 그 위에서 OPC UA는 기종이 달라도 통하는 통신 규약, MQTT는 센서가 가볍게 메시지를 주고받는 방식입니다. 그리고 디지털 스레드는 설계부터 생산, 유지보수까지 제품의 일생을 데이터 실로 꿰는 개념입니다.

이 층에서 자주 하는 실수가 하나 있습니다. 통신 규약부터 고르는 겁니다. 순서가 반대입니다. "무엇을, 얼마나 자주, 어디까지 보내야 하는가"가 먼저고, 규약은 그 다음에 정하는 도구입니다. 연결이 목적이 되면 데이터만 쌓이고, 쓰는 사람은 없습니다.

2층 — 감시와 예측: 이상을 먼저 보는 층

연결이 되면 다음은 보는 일입니다. SCADA는 공장 전체를 한눈에 감시하는 시스템, 사이버물리시스템(CPS)은 기계와 디지털이 실시간으로 연결된 구조 자체입니다. 그 위에서 예지정비는 고장나기 전에 기계가 먼저 알려주는 일이고, RUL은 "고장까지 남은 수명"을 숫자로 말하는 지표입니다.

이 층의 핵심은 숫자의 의미입니다. RUL이 "37일 남았다"고 해도, 그 37일이 무엇을 기준으로 한 예측인지 모르면 현장에서는 못 씁니다. 예측 모델의 출력보다 중요한 건, 그 숫자가 어떤 데이터에서 왔고 어느 조건에서 틀리는지를 아는 일입니다. 그래서 예지정비의 성패는 AI 성능보다 데이터 이력 관리에서 갈리는 경우가 많습니다.

3층 — 실행과 운영: 현장에서 굴리는 층

마지막은 실행입니다. MES는 공장 생산을 실시간으로 지시하고 기록하는 시스템, AGV와 AMR은 자재를 나르는 이동 수단입니다. 정해진 길을 달리는 AGV와 스스로 길을 찾는 AMR의 차이는, 결국 현장의 변화에 얼마나 대응하느냐의 차이입니다. 엣지 컴퓨팅은 판단을 현장에서 바로 내리는 방식이고, PoC는 도입 전에 작게 검증하는 절차입니다.

이 층에서 7년차 현장 엔지니어로서 한 줄만 덧붙이면, PoC를 건너뛰고 곧장 전 라인에 붙이는 선택이 가장 비쌉니다. 작게 검증해서 실패 비용을 작게 만드는 게, 사실은 가장 빠른 도입법입니다.

한 장 요약 — 데이터가 흐르는 순서

연결 층에서는 IIoT · OPC UA · MQTT · 디지털 스레드 — 기계가 데이터를 내고, 규약으로 묶고, 제품 일생을 실로 꿴다. 감시·예측 층에서는 SCADA · CPS · 예지정비 · RUL — 공장 전체를 보고, 고장을 미리 숫자로 말한다. 실행·운영 층에서는 MES · AGV/AMR · 엣지 컴퓨팅 · PoC — 생산을 지시하고 나르며, 현장에서 판단하고 작게 검증한다.

흐름으로 읽으면 이렇습니다. 기계가 데이터를 내고(IIoT·OPC UA·MQTT), 그 데이터가 제품의 일생과 이어지고(디지털 스레드), 공장 전체가 한눈에 보이면서(SCADA·CPS) 고장을 미리 알리고(예지정비·RUL), 생산 지시와 물류가 그 위에서 돌고(MES·AGV/AMR), 판단은 현장에서 빠르게(엣지 컴퓨팅), 도입은 작게 검증하며(PoC) 굴러갑니다.

마무리 — 용어를 알면 현장 말이 보입니다

한 달 동안 열두 개 용어를 풀면서 가장 많이 느낀 건, 용어 자체보다 "이 용어가 현장의 어느 자리에 있는가"가 중요하다는 점입니다. 용어 열두 개를 외우는 게 목표가 아니라, 회의에서 "우리 MES랑 SCADA 연동이 안 된다"는 말이 들렸을 때 어느 층의 문제인지 바로 감이 오는 게 목표입니다.

그래서 뭘 하면 되나 — 내일 현장에서 용어 하나를 골라, 그 용어가 우리 공장의 어느 층에 있는지 한 번만 대입해 보세요. 그 한 번이, 다음 회의에서 말이 통하는 시작이 됩니다. 10월 용어 사전은 여기서 마무리합니다. 11월에는 현장의 이야기로 다시 찾아오겠습니다.

관련 글: 예지정비 EP.1(https://developer-archive.tistory.com/126) · 디지털 스레드 EP.2(https://developer-archive.tistory.com/131) · OPC UA EP.3(https://developer-archive.tistory.com/136) · AGV와 AMR EP.4(https://developer-archive.tistory.com/141) · RUL EP.5(https://developer-archive.tistory.com/146) · MQTT EP.6(https://developer-archive.tistory.com/151) · 엣지 컴퓨팅 EP.7(https://developer-archive.tistory.com/157) · 사이버물리시스템 EP.8(https://developer-archive.tistory.com/163) · PoC EP.9(https://developer-archive.tistory.com/168) · MES EP.10(https://de

veloper-archive.tistory.com/173)