프로그래밍 허브

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

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

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

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

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

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

마무리

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

관련 글: 디지털트윈이 '실시간'이 되는 조건(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)

7년차 현장 엔지니어로서, 요즘 현장에서 가장 조심스럽게 보는 변화는 AI가 "알려주는" 단계를 넘어 "움직이는" 단계로 들어섰다는 점이다. 상태를 조회하고 보고서를 쓰는 AI와, 밸브를 열고 속도를 바꾸는 AI는 완전히 다른 존재다. 전자는 틀려도 고치면 되지만, 후자는 틀리는 순간 설비와 사람이 직접 영향을 받는다.

행동 권한은 '읽기 권한'과 다르다

현장에서 흔히 하는 실수가 있다. 챗봇에 데이터 조회 권한을 준 경험을 그대로 에이전트에 적용하는 것이다. 읽기 권한은 범위를 넓혀도 피해가 제한적이지만, 행동 권한은 한 번의 오작동이 곧바로 물리적 결과로 이어진다. 그래서 행동 권한은 "무엇을 할 수 있는가"가 아니라 "무엇을 절대 못 하는가"부터 정해야 한다. 정지·안전 관련 신호를 건드리지 못하게 막는 금지 목록이, 허용 목록보다 먼저다.

세 가지 안전 장치부터 설계한다

첫째, 허용 목록이다. 에이전트가 건드릴 수 있는 동작을 사전에 몇 개로 한정한다. "속도를 5% 이내로 조정"처럼 범위까지 숫자로 적는다. 둘째, 범위 제한이다. 한 번의 판단으로 바꿀 수 있는 설비 수, 시간대, 조건을 묶어둔다. 야간 무인 시간대에는 아예 행동을 막는 편이 낫다. 셋째, 사람 승인이다. 되돌리기 어려운 동작은 반드시 현장 담당자의 확인을 거친다. 승인이 번거롭다고 빼면, 그 번거로움이 나중에 사고 보고서로 돌아온다.

그래서 뭘 하면 되나

새 에이전트를 도입하기 전에, 팀이 함께 "행동 권한표" 한 장을 먼저 만들어보자. 동작·범위·금지·승인자 네 칸이면 충분하다. 이 표가 없으면 AI 도입 논의는 성능 자랑으로 끝나고, 표가 있으면 현장 운영 논의가 된다. AI가 똑똑해지는 속도보다, AI에게 어디까지 맡길지 정하는 속도가 더 중요해졌다.

관련 글: 공장용 AI 챗봇 권한 문제(https://developer-archive.tistory.com/145), 모델 버전 관리(https://developer-archive.tistory.com/155), 규칙 레이어 설계법(https://developer-archive.tistory.com/140)

LG전자의 이동형 로봇 'LG 클로이드'가 미국 테네시 세탁기 공장과 경남 창원 액추에이터 생산라인에 투입돼 부품 운반·조립·포장 작업을 검증하고 있다. 연구실에서 다듬은 로봇이 실제 생산현장에서 통하는지를 확인하는 단계에 들어선 것이다. 내년 말까지 두 공장의 수십 개 공정으로 적용을 넓힌다는 계획이다.

출처: 뉴스핌, 2026년 10월 26일, "LG 로봇, 연구실 벗어나 美·韓 공장 투입…'원LG' 상용화 시험대"

연구실 데이터와 현장 데이터는 다르다

테네시 공장에서는 세탁기 상판 운반과 배수펌프 정렬·적재를, 창원에서는 액추에이터 조립과 포장을 맡는다. 핵심은 부품 위치나 작업 속도가 달라지는 변수 속에서도 같은 작업을 해내는지다. 연구실에서는 일정한 조건이 반복되지만, 공장 바닥은 그렇지 않다. 그래서 LG전자는 현장에서 발생한 오류와 작업 데이터를 다시 AI 학습에 넣어 부족한 동작을 개선하는 순환 구조를 쓰고 있다.

200대 로봇, 10만 시간 데이터가 말하는 것

이를 뒷받침하는 곳이 서울 양재 데이터팩토리다. 현재 약 100대인 학습용 로봇을 연말까지 200대로 늘리고, 실제 데이터와 가상 데이터를 합쳐 10만 시간 규모의 학습 데이터를 확보한다는 목표다. 로봇 한 대의 성능보다 학습 데이터를 얼마나, 얼마나 실제에 가깝게 모으느냐가 상용화 속도를 가른다는 얘기다.

여기에 계열사 역할 분담도 눈에 띈다. LG전자가 본체와 구동을, LG이노텍이 카메라·센싱을, LG AI연구원이 판단 AI를, LG CNS가 현장 운영 플랫폼 '피지컬웍스'를 맡는 '원LG' 체계다. 로봇 한 대가 아니라 학습부터 현장 운영까지 이어지는 파이프라인을 그룹 차원에서 갖추겠다는 전략이다.

7년차 현장 관점: PoC의 성패는 '수십 개 공정'에서 갈린다

7년차 현장 엔지니어로서 나는 이렇게 본다. 로봇 PoC가 한두 개 공정에서 잘 돌아가는 것과, 수십 개 공정에서 매일 같은 품질로 돌아가는 것은 전혀 다른 문제다. 그래서 뭘 하면 되나 — PoC를 볼 때는 데모 성공률이 아니라, 실패했을 때 라인이 멈추지 않는 복구 절차와 재학습 루프가 있는지를 먼저 물어야 한다.

LG의 이번 행보가 의미 있는 이유는 로봇 자체보다 그 뒤의 구조 때문이다. 데이터를 모으고, 실패를 학습에 되돌리고, 운영 플랫폼으로 현장에 붙이는 이 순환이 돌아가면 로봇은 '전시품'에서 '설비'가 된다. 반대로 이 순환이 없으면 아무리 화려한 로봇도 현장에서는 오래 살아남지 못한다. 내년 말 '수십 개 공정'이라는 목표가 실제로 채워지는지가 피지컬 AI 상용화의 진짜 성적표가 될 것이다.

[현장 데이터 파이프라인 EP.4 — 시리즈 이어서 읽기] 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)

데이터가 잘 쌓였다고 끝이 아닙니다. 현장에서 진짜 자주 보는 장면은 이렇습니다. 대시보드는 있는데 아무도 안 보고, 알람은 울리는데 받는 사람이 없고, 보고서는 매주 나가는데 아무도 그 숫자로 결정을 안 하는 겁니다. 저장까지 잘해 놓고 활용에서 멈추는 파이프라인은, 결국 '잘 정리된 방치'일 뿐입니다. 활용 구간은 기술 설계가 아니라 운영 설계입니다. 누가, 언제, 무엇을 보고, 이상이 생기면 누구에게 어떻게 연락할 것인가 — 이 네 가지를 먼저 정해야 합니다.

1) 보는 사람 — 같은 데이터도 보는 눈은 다르다

첫 번째는 '보는 사람'입니다. 작업자에게 필요한 건 지금 이 순간의 상태입니다. 온도가 정상 범위인지, 라인이 멈췄는지, 지금 당장 손대야 할 게 있는지. 엔지니어에게 필요한 건 추세입니다. 지난주와 비교해 진동이 조금씩 커지고 있는지, 특정 시간대에만 불량이 몰리는지. 관리자에게 필요한 건 요약입니다. 오늘 수율, 이번 주 가동률, 지난달 대비 변화 한 줄.

같은 센서 데이터라도, 보는 사람마다 해상도와 지표가 달라야 합니다. 모두에게 똑같은 대시보드 하나를 보여주는 건, 모두에게 똑같은 옷을 입히는 것과 같습니다. 보는 사람별로 화면을 나누는 것부터가 활용 설계의 시작입니다.

2) 보는 주기 — 실시간이 정답이 아닐 때가 많다

두 번째는 '보는 주기'입니다. 실시간이 무조건 좋은 건 아닙니다. 1초 단위 데이터를 24시간 실시간으로 보는 화면은, 사람이 아니라 기계가 볼 때 의미가 있습니다. 사람이 볼 화면이라면 주기를 정해야 합니다. 작업자 화면은 실시간, 엔지니어 분석은 1분·1시간 집계, 경영 보고는 일·주 단위 요약처럼 말입니다.

이때 함께 정해야 할 게 다운샘플링입니다. 1초 데이터를 1년 내내 원본 그대로 보관하면 저장 비용과 조회 속도가 둘 다 무너집니다. 원본은 일정 기간만 두고, 오래될수록 1분·1시간 평균으로 줄여 보관하는 규칙을 두는 겁니다. "얼마나 오래, 얼마나 세밀하게 볼 것인가"를 주기별로 정해 두면, 조회가 느려져서 아무도 안 보는 대시보드를 만들지 않을 수 있습니다.

3) 이상 시 연락망 — 알람이 아니라 '받는 사람'이 설계다

세 번째는 '이상 시 연락망'입니다. 임계값을 정해 알람을 울리는 건 쉽습니다. 어려운 건 그다음입니다. 알람을 누가 받는지, 밤에는 누가 받는지, 받은 사람이 10분 안에 응답하지 않으면 누구에게 넘어가는지. 이게 정해지지 않은 알람은 소음에 불과합니다. 현장에서는 알람이 너무 자주 울리면, 결국 아무도 안 보게 됩니다. 그래서 알람에도 등급이 필요합니다. 즉시 조치해야 할 것과, 다음 날 아침에 확인해도 되는 것을 나누는 겁니다.

연락망은 한 번 정하고 끝이 아닙니다. 담당자가 바뀌고, 야간 근무표가 바뀌고, 라인이 늘어나면 함께 바꿔야 합니다. 연락망이 최신 상태인지 정기적으로 확인하는 것 자체가 활용 구간의 유지보수입니다.

4편의 결론 — 활용은 화면이 아니라 습관이다

정리하면 이렇습니다. 보는 사람별로 화면을 나누고, 보는 주기별로 집계 규칙을 정하고, 이상이 생겼을 때 받는 사람과 에스컬레이션 순서를 정하는 것. 이 세 가지가 갖춰져야 저장된 데이터가 현장의 판단으로 이어집니다.

그래서 뭘 하면 되나 — 오늘 우리 팀 대시보드에 이 세 가지를 물어보세요. 누가 보는지, 어느 주기로 보는지, 알람이 울리면 누가 받는지. 하나라도 대답이 안 나온다면, 그곳부터가 활용 구간의 첫 공사 지점입니다.

다음 편(5편)은 시리즈 마무리 — 파이프라인 전체를 한 장의 운영 점검표로 정리하는 최종회를 다룹니다.

AI 모델 발표 자료에는 늘 정확도 99% 같은 숫자가 맨 앞에 나온다. 그런데 공장에 들어가면 그 숫자가 통하지 않는 경우가 많다. 불량 검출 모델이 99%를 찍었는데도 현장에서는 "차라리 안 쓰겠다"는 말이 나오는 이유, 오늘은 그 간극을 현장 관점에서 풀어본다.

정확도는 '무엇을 틀렸는지'를 숨긴다

정확도는 맞힌 비율 하나만 보여준다. 불량 100개 중 99개를 맞혔는데, 놓친 1개가 고객사로 나가는 치명 결함이라면 그 모델은 현장에서 실패한 것이다. 반대로 양품을 불량으로 오판하는 1%가 검사원의 재작업을 폭증시킨다면, 그 모델도 현장에서 살아남지 못한다.

현장에서 틀림은 다 같은 틀림이 아니다. 미검출과 오탐은 비용도, 책임지는 사람도, 복구 방법도 다르다. 하나의 숫자로 합쳐버리는 순간, 정작 중요한 정보가 사라진다.

현장 지표로 바꿔라 — 세 가지 질문

모델을 평가할 때 정확도 대신 이렇게 물어보자.

첫째, 틀렸을 때 누가 치르는가. 미검출은 고객 클레임과 라인 정지로, 오탐은 재검사와 납기 지연으로 이어진다. 둘째, 그 비용을 숫자로 적을 수 있는가. "미검출 1건당 얼마, 오탐 1건당 얼마"가 나와야 비교가 된다. 셋째, 시간이 지나도 유지되는가. 배포 첫 주 성능이 한 달 뒤에도 같은지, 데이터가 조금씩 바뀌는 현장에서 성능이 얼마나 버티는지도 지표다.

그래서 나는 미검출률, 오탐률, 단위 시간당 처리량, 재학습 주기 내 성능 유지율을 따로 본다. 네 숫자를 따로 보면 어디서 새는지가 보인다.

그래서 뭘 하면 되나 — 평가표 바꾸기 3단계

첫째, 현장 비용표부터 만든다. 품질팀, 생산팀과 함께 미검출 1건과 오탐 1건의 실제 비용을 적는다. 둘째, 임계값(threshold)을 정확도가 가장 높은 지점이 아니라 총비용이 가장 낮은 지점에서 잡는다. 의외로 임계값을 조금만 옮겨도 현장 체감이 크게 바뀐다. 셋째, 배포 후 모니터링을 평가의 일부로 둔다. 데이터가 바뀌면 성능이 조용히 무너진다. 주기적으로 현장 지표로 다시 재는 루틴이 없으면, 99%는 금방 옛날 숫자가 된다.

7년차 현장 엔지니어로서 한 줄 정리하자면, 모델 평가는 논문이 아니라 현장 운영비로 해야 한다. 정확도 99%를 자랑하기 전에, 틀린 1%가 누구 지갑에서 나가는지부터 적어보자. 그 한 줄이 바뀌면 모델 고르는 기준 자체가 바뀐다.

오늘 아침 쇼츠 '제조AI 용어 사전 EP.8 — 사이버물리시스템' 심화판입니다. 쇼츠에서 30초로만 훑은 개념을, 현장에서 어떻게 굴러가는지까지 블로그 분량으로 풀어봅니다.

사이버물리시스템, 한 줄 정의

사이버물리시스템(Cyber-Physical System, CPS)은 물리 세계의 기계·센서·액추에이터와 사이버 세계의 계산·제어·데이터 분석이 실시간으로 연결되어 서로 영향을 주고받는 시스템입니다. 센서가 현실을 읽고, 소프트웨어가 판단하고, 그 판단이 다시 기계를 움직입니다. 이 '닫힌 루프'가 CPS의 본질입니다.

단순히 데이터를 모으는 게 아닙니다. 수집만 하고 제어가 돌아오지 않으면 모니터링이고, 제어가 실시간으로 닫혀야 CPS입니다.

디지털트윈·엣지 컴퓨팅과는 뭐가 다를까

헷갈리기 쉬운 개념들을 정리하면 이렇습니다. 디지털트윈은 현실의 가상 복제본으로 시뮬레이션·예측이 핵심이며, CPS의 사이버 측을 구현하는 대표 수단입니다. 엣지 컴퓨팅은 현장 가까이에서 바로 계산하는 방식으로, CPS의 실시간성을 떠받치는 계산 방식입니다. OPC UA / MQTT는 기기 간 통신 규약으로, CPS를 잇는 신경망 같은 통로입니다. 그리고 CPS 자체는 물리+사이버의 실시간 결합 시스템 전체로, 위 개념들을 아우르는 상위 틀입니다.

즉 디지털트윈이 '거울'이라면, CPS는 거울을 보고 손을 움직이는 '몸'까지 포함한 전체입니다. 이전 글에서 다룬 예지정비(#126), OPC UA(#136), MQTT(#151), 엣지 컴퓨팅(#157)이 모두 CPS 안에서 각자의 자리를 맡습니다.

현장에서 CPS가 동작하는 순서

현장에서 CPS는 보통 이렇게 돕니다.

1. 감지: 센서가 온도·진동·위치·부하 같은 물리량을 읽습니다.

2. 전송: OPC UA나 MQTT 같은 규약으로 데이터를 사이버 측으로 보냅니다.

3. 판단: 엣지나 서버에서 모델이 상태를 판정합니다. 이상 징후면 경보, 정상이면 계속 운전입니다.

4. 제어: 판단 결과가 액추에이터로 돌아가 속도·압력·경로를 조정합니다.

5. 학습: 운전 기록이 쌓여 모델이 다음 판단을 더 잘하게 됩니다.

7년차 현장 엔지니어로서 강조하고 싶은 건, 이 루프에서 가장 자주 무너지는 지점이 기술이 아니라 '시간'이라는 점입니다. 센서 주기와 제어 주기가 어긋나면, 아무리 좋은 모델도 현장에서는 늦은 판단이 됩니다. 그래서 뭘 하면 되나 — 도입 전에 샘플링 주기, 통신 지연, 제어 응답 시간을 하나의 표로 먼저 맞추는 게 CPS 설계의 첫걸음입니다.

도입 전에 점검할 3가지

첫째, 실시간의 기준을 정하세요. 밀리초 단위가 필요한 공정과 초 단위로 충분한 공정이 다릅니다. 기준 없이 '실시간'만 외치면 과설계가 됩니다.

둘째, 고장 시 기본 동작을 정하세요. 통신이 끊겼을 때 기계가 멈출지, 마지막 명령을 유지할지, 안전 상태로 갈지를 미리 정해두지 않으면 CPS는 오히려 위험해집니다.

셋째, 작게 닫고 넓히세요. 한 설비, 한 루프부터 닫힌 루프를 증명하고 라인·공장으로 넓히는 순서가 현장에서 가장 덜 아픕니다.

마무리

CPS는 거창한 미래 기술이 아니라, 센서·통신·계산·제어가 실시간으로 맞물리는 설계 방식입니다. 용어만 외우지 말고 "우리 공장의 루프는 어디서 끊기는가"를 물어보는 것부터가 CPS의 시작입니다.

관련 글: 예지정비 EP.1(#126), OPC UA EP.3(#136), MQTT EP.6(#151), 엣지 컴퓨팅 EP.7(#157)

공장 모니터를 켜면 숫자는 넘친다. 온도, 압력, 속도, 전류. 그런데 정작 현장에서 필요한 질문에 답은 잘 안 나온다. "지금 이 설비는 정상인가, 곧 멈출 것인가, 아니면 이미 품질이 흔들리고 있는가." 7년차 현장 엔지니어로서, 이 간극의 이름은 '신호는 있는데 상태가 없다'이다.

신호와 상태는 다른 층이다

신호는 측정값이다. 상태는 판단이다. 센서가 82도를 보고했다고 해서 그 설비가 과열 상태인 것은 아니다. 같은 82도라도 예열 중인지, 연속 운전 중인지, 방금 제품을 바꾼 직후인지에 따라 의미가 완전히 달라진다. 신호만 쌓아두면 대시보드는 화려해지지만, 운영자는 여전히 "그래서 지금 괜찮은 거야?"를 묻는다. 상태 모델링은 이 질문에 답하기 위해 신호 위에 '맥락'을 얹는 작업이다.

상태는 세 가지로 나눠서 정의한다

나는 상태를 크게 세 층으로 나눠 정의하는 편이다. 첫째, 운전 상태다. 가동, 대기, 정지, 고장처럼 설비가 지금 어떤 모드에 있는지다. 둘째, 건강 상태다. 진동 추세, 온도 편차, 사이클 시간의 drift처럼 "아직 멈추지 않았지만 예전 같지 않다"는 신호를 수치화한 것이다. 셋째, 품질 상태다. 지금 나오는 제품이 스펙 안에 있을 확률, 즉 공정 능력의 현재값이다. 세 층을 분리하면 알람도 달라진다. 운전 상태가 '정지'인데 온도 알람이 울린다면 그건 고장이 아니라 운전 모드에 맞지 않는 임계값 설정 문제다.

상태 전이는 '규칙'으로 적어둔다

상태 모델링에서 가장 많이 빠지는 것이 전이 규칙이다. "언제 정상에서 주의로 바뀌는가"를 사람 머릿속이 아니라 문서와 코드로 남겨야 한다. 예를 들어 진동 실효값이 기준 대비 20% 상승하고 3사이클 연속 유지되면 '주의', 40% 상승이면 '점검'으로 전이한다. 기준값의 출처(설계값인지, 과거 정상 구간의 통계인지)도 함께 적는다. 이렇게 해야 야간 근무자와 주간 엔지니어가 같은 '주의'를 같은 의미로 쓴다. 관련 글: 디지털트윈의 데이터 수집(https://developer-archive.tistory.com/124), 디지털트윈이 실시간이 되는 조건(https://developer-archive.tistory.com/132), 디지털트윈의 해상도(https://developer-archive.tistory.com/147).

그래서 뭘 하면 되나

이번 주에 설비 하나만 골라 상태 세 층을 한 장짜리 표로 정리해 보자. 운전 상태 4~5개, 건강 지표 2~3개, 품질 지표 1개, 그리고 각 상태로 바뀌는 조건 한 줄씩. 이 표 하나가 있으면 대시보드는 '보는 화면'에서 '판단하는 화면'으로 바뀐다. 신호를 더 모으기 전에, 이미 있는 신호로 상태를 먼저 말할 수 있게 만드는 것이 순서다.

휴머노이드 로봇 뉴스가 또 한 번 '데모'에서 '양산' 쪽으로 무게중심을 옮겼다. 글로벌이코노믹(2026-10-25) 보도에 따르면 테슬라의 3세대 휴머노이드 로봇 옵티머스가 양산 준비를 마치고 첫 생산 라인 건설에 들어갔다고 한다. 중국 매체가 미국 증권거래위원회 제출 서류를 인용해 전한 내용이다. 아직 테슬라의 공식 양산 선언이라고 단정하기는 어렵지만, 적어도 업계의 질문이 바뀌었다는 신호는 분명하다. "걸을 수 있나"에서 "공장에서 매일 돌릴 수 있나"로.

양산 준비가 의미하는 것

로봇 한 대를 무대에서 걷게 하는 것과, 같은 로봇 수천 대를 라인에서 굴리는 것은 완전히 다른 문제다. 부품 수급, 불량률, 안전 인증, 유지보수 체계가 갖춰지지 않으면 양산은 숫자에 불과하다. 그래서 이번 소식에서 주목할 부분은 '3세대'라는 버전보다 '첫 생산 라인'이라는 표현이다. 생산 라인이 생긴다는 건, 로봇 자체보다 로봇을 만드는 공정을 설계하기 시작했다는 뜻이기 때문이다. 샤오펑 로보틱스가 2026년 말 양산, 2027년 상반기 출하를 예고하고, 로직 로보틱스가 누적 생산 2만 대를 넘겼다는 같은 보도의 흐름도 같은 방향을 가리킨다. 경쟁이 모델 성능이 아니라 생산 능력으로 옮겨가고 있다.

숫자는 뜨겁지만, 공장의 답은 아직이다

시장의 반응은 뜨겁다. 보도에 따르면 지난 한 주 휴머노이드 로봇 지수는 11% 넘게 올랐고, 시장조사기관 IDC 집계로는 2026년 상반기 전 세계 휴머노이드 출하량이 전년 동기보다 400% 넘게 늘어 약 2만 5,000대에 이르렀다. 상하이는 2028년까지 공장에 휴머노이드 8,000대를 도입하겠다는 계획까지 내놨다.

하지만 같은 날 나온 또 다른 시선도 함께 봐야 한다. The Hans India(2026-10-25)가 전한 분석에 따르면, 중국의 휴머노이드 로봇은 화려한 시연 뒤에 상업적으로 지속 가능한 대량 배치로 이어지는 데는 아직 의문이 남는다. 공연·전시·교육·데이터 수집이 전체 활용의 60%를 넘고, 지능형 제조는 13% 수준에 머문다는 주간 브리핑 수치도 같은 맥락이다. 주가가 오르는 것과 공장에서 통하는 것은 다른 검증이다. 7년차 현장 엔지니어로서 나는 이렇게 본다 — 로봇의 진짜 시험대는 무대가 아니라, 예측 불가능한 변수가 매일 터지는 공장 바닥이다.

한국 제조업이 볼 포인트

이 뉴스를 한국 제조 현장의 언어로 바꾸면 질문은 세 가지로 좁혀진다. 첫째, 우리 공정에 휴머노이드가 필요한 작업인가, 아니면 기존 협동로봇·AMR로 충분한가. 둘째, 로봇이 멈췄을 때 라인을 세우지 않고 복구할 절차가 있는가. 셋째, 로봇이 만드는 데이터를 누가 소유하고, 어떤 기준으로 품질을 판단할 것인가. 경북도가 10월 25일 권역별 AI 로봇 기업협의회 출범을 알리며 부품 공급망 참여 지원을 내건 것도 같은 맥락이다. 대기업의 로봇 투자가 커질수록, 중소 부품 기업이 어떤 검증과 실증으로 공급망에 들어갈지가 관건이 된다.

그래서 뭘 하면 되나 — 휴머노이드 도입을 검토하는 현장이라면, 멋진 데모 영상이 아니라 '하루 8시간, 한 달 연속'이라는 조건으로 검증 계획을 먼저 써보길 권한다. 고장 시나리오, 안전 정지, 작업자 동선, 유지보수 주기가 그 계획에 들어가지 않으면, 그 로봇은 아직 공장의 동료가 아니라 전시품에 가깝다.

휴머노이드 대전은 이제 시작이다. 승자는 가장 먼저 걷는 로봇이 아니라, 가장 오래 공장에서 버티는 로봇을 만드는 쪽이 될 것이다.

출처: 글로벌이코노믹 "테슬라 '옵티머스' 양산 카운트다운…불붙은 글로벌 로봇 대전"(2026-10-25), The Hans India "China's humanoid robots are unproven in factories: Report"(2026-10-25), 연합뉴스·서울신문 경북 AI 로봇 기업협의회 출범 보도(2026-10-25). 수치·일정은 보도 인용이며, 테슬라의 공식 발표가 추가로 확인되면 내용을 보완하겠습니다.

현장에서 센서가 이상 신호를 보냈다고 치자. 이 데이터를 클라우드로 보내고, 분석하고, 다시 명령을 내려보내는 데 1초가 걸린다면 괜찮을까? 라인 속도가 빠른 공정에서는 1초도 길다. 엣지 컴퓨팅은 이 질문에서 출발한다. 계산을 굳이 먼 클라우드까지 보내지 않고, 데이터가 생기는 현장 가까이에서 바로 처리하는 방식이다.

엣지 컴퓨팅이란 — 클라우드와 뭐가 다른가

엣지는 '가장자리'라는 뜻이다. 네트워크의 가장자리, 즉 센서·PLC·로봇 바로 옆에 있는 게이트웨이나 산업용 PC에서 데이터를 처리하는 것이 엣지 컴퓨팅이다. 모든 데이터를 클라우드로 올리는 것이 아니라, 현장에서 1차 판단(필터링·이상 감지·간단한 추론)을 끝내고, 필요한 요약만 클라우드로 보낸다.

계산 위치를 보면, 클라우드는 원격 데이터센터에서 계산하고 엣지는 현장 게이트웨이·산업용 PC에서 계산한다. 지연시간은 클라우드가 네트워크 왕복만큼 발생하지만, 엣지는 현장에서 즉시 처리한다. 잘 맞는 일은 클라우드가 대규모 학습·장기 통계에 맞고, 엣지는 실시간 판단·라인 제어 연계에 맞다. 약점은 클라우드가 지연·회선 의존이고, 엣지는 현장 장비 관리 부담이다.

둘 중 하나를 고르는 문제가 아니다. 학습은 클라우드에서, 판단은 엣지에서 — 이렇게 나누는 것이 현장에서 가장 흔한 조합이다.

현장에서 엣지가 필요한 세 가지 순간

첫째, 속도가 돈이 될 때다. 예지정비(지난 글 #126)에서 진동 스펙트럼이 임계값을 넘었다면, 그 판단은 현장에서 즉시 나와야 한다. 둘째, 회선이 불안정할 때다. 전송이 끊기는 것은 예외가 아니라 정상이라는 전제로 설계해야 한다 — 지난 현장 데이터 파이프라인 글(#148·#153)에서도 다뤘던 이야기다. 셋째, 데이터를 다 올릴 수 없을 때다. 고속 카메라 한 대가 뿜는 영상 데이터를 전부 클라우드로 올리는 것은 비용도, 대역폭도 감당하기 어렵다. 현장에서 불량 후보 프레임만 골라내는 것이 현실적이다.

그래서 뭘 하면 되나 — 작은 것부터

7년차 현장 엔지니어로서 권하고 싶은 시작은 거창하지 않다. 첫째, '현장 판단이 필요한 신호' 하나를 고른다. 둘째, 그 신호의 임계값 판단을 엣지 장비 하나로 옮긴다. 셋째, OPC UA(#136)나 MQTT(#151) 같은 기존 통신 규약 위에 얹어, 판단 결과만 상위 시스템으로 보낸다. 이렇게 하면 클라우드를 바꾸지 않고도 현장 대응 속도가 먼저 좋아진다.

엣지 컴퓨팅은 클라우드를 대체하는 기술이 아니라, 현장과 클라우드 사이의 역할을 나누는 설계다. 어디까지 현장에서 판단할 것인가 — 이 경계를 정하는 것이 결국 스마트팩토리 설계의 실력이다.