프로그래밍 허브

로봇 한 대를 더 똑똑하게 만드는 시대는 지났다. 이제는 로봇 여러 대가 경험을 나누며 함께 성장하는 시대가 열리고 있다. 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)

공장에 센서를 붙이고 대시보드를 띄우면 뭔가 다 해결될 것 같다. 온도, 진동, 전류가 실시간으로 보이고, 알람도 울린다. 그런데 막상 고장이 나면 현장에서 가장 먼저 나오는 말은 이것이다. "그래서, 왜 고장난 거예요?"

7년차 현장 엔지니어로서, 이 질문에 답을 못 하는 시스템은 반쪽짜리라고 생각한다. 데이터를 모으는 것과 원인을 아는 것은 전혀 다른 일이다.

데이터가 있다고 원인이 보이는 건 아니다

센서 데이터는 '지금 상태'를 보여줄 뿐, '왜 그렇게 됐는지'는 보여주지 않는다. 진동이 커졌다는 사실만으로는 베어링 마모인지, 체결 불량인지, 부하 변화인지 알 수 없다.

현장에서 흔히 보는 함정이 있다. 알람은 수백 건인데, 고장 보고서에는 "원인 불명"이 적힌다. 데이터는 쌓이는데, 원인으로 이어지는 연결고리가 없는 것이다. 센서 값, 설비 이력, 작업 조건, 교체 부품 기록이 각각 따로 놀기 때문이다.

원인 추적은 '연결'부터 설계한다

원인 추적 설계의 핵심은 세 가지 연결이다.

첫째, 시간 연결이다. 고장 시점의 센서 값만 보면 안 된다. 고장 전 몇 시간, 며칠의 변화 추세가 필요하다. 갑자기 튄 값인지, 서서히 악화된 값인지에 따라 원인이 달라진다.

둘째, 설비 연결이다. 한 설비의 이상이 다른 설비의 부하 변화에서 오는 경우가 많다. 라인 전체를 하나의 흐름으로 보지 않으면, 진짜 원인이 있는 설비가 아니라 증상이 나타난 설비만 붙잡게 된다.

셋째, 사람·작업 연결이다. 같은 설비라도 작업자, 교대조, 원자재 로트에 따라 결과가 달라진다. 이 기록이 데이터와 붙어 있지 않으면, AI는 "이상하다"까지만 말하고 멈춘다.

그래서 뭘 하면 되나 — 고장 1건당 '원인 카드' 1장

거창한 시스템부터 만들 필요는 없다. 다음 고장부터 이렇게 해보자. 고장 1건마다 원인 카드 1장을 만든다. 고장 시간, 직전 추세, 관련 설비, 작업 조건, 최종 원인을 한 장에 적는 것이다.

이 카드가 열 장, 스무 장 쌓이면 패턴이 보인다. 그때서야 AI에게 "이런 패턴이면 이 원인을 의심해봐"라고 가르칠 수 있다. 원인 카드 없는 AI는 알람 기계에 불과하다.

관련 글: 예지정비 심화(https://developer-archive.tistory.com/126), 데이터 드리프트(https://developer-archive.tistory.com/133), 모델 평가를 현장 지표로(https://develope

r-archive.tistory.com/164)

뉴스 한 줄 요약

인공지능 인프라 전문기업 리더스시스템즈가 테라다인 로보틱스와 국내 공식 대리점 계약을 맺고 로봇 자동화·피지컬 AI 사업에 본격 진출한다고 2026년 10월 30일 밝혔다. (출처: 서울경제TV, 2026-10-30, 박수열 기자)

이번 계약으로 리더스시스템즈는 테라다인 로보틱스 산하의 협동로봇 브랜드 유니버설 로봇(UR)과 자율주행 모바일 로봇(AMR) 브랜드 미르(MiR)의 국내 유통과 기술 서비스를 전담한다. 제품 사전 시연부터 현장 설치, 맞춤형 엔지니어링, 사후 기술 지원과 정기 유지보수까지 턴키(일괄) 지원 체계를 구축하겠다는 구상이다.

왜 중요한가: 로봇 경쟁이 '스펙'에서 '돌아가는 구조'로 이동했다

요즘 로봇 뉴스는 대부분 "누가 더 빠르고, 누가 더 세냐"에 머무른다. 그런데 현장에서 로봇 도입이 실패하는 이유는 스펙이 부족해서가 아니다. 설치는 됐는데 고장 났을 때 올 사람이 없고, 라인이 바뀌었는데 다시 세팅할 사람이 없는 경우가 훨씬 많다.

이번 뉴스가 눈에 띄는 지점이 바로 여기다. 리더스시스템즈는 고성능 AI 컴퓨팅과 엣지 인프라 역량을 가진 회사다. 여기에 UR·MiR이라는 현장에서 이미 검증된 하드웨어가 붙었다. 즉, "AI 연산은 데이터센터에서, 움직임은 현장 로봇에서"라는 피지컬 AI의 그림을, 유통·설치·유지보수라는 운영 구조까지 포함해 풀겠다는 얘기다.

기사에서 회사는 상시 시연이 가능한 데모 로봇과 주요 예비 부품 재고를 확보하고, 사내 로봇 기술 인력을 육성해 예기치 못한 장애나 셧다운에도 긴급 대응하겠다는 계획도 밝혔다. 다운타임 최소화가 목표라는 점이, 이 계약이 단순 판매 대리점이 아니라 운영 파트너십임을 보여준다.

7년차 현장 관점: 진짜 시험대는 '도입 첫 달'이 아니라 '고장 난 날'이다

7년차 현장 엔지니어로서 한 줄로 정리하면, 로봇의 가치는 데모 날이 아니라 고장 난 날 밤에 결정된다. 그날 전화 한 통으로 예비 부품과 기술자가 오는지, 라인을 세우지 않고 우회 운전이 가능한지가 그 회사의 실력이다.

그래서 이번 계약을 볼 때 나는 로봇 대수보다 세 가지를 먼저 본다. 첫째, 데모 로봇을 직접 만져보고 자사 공정으로 개념검증(PoC)을 해볼 수 있는가. 둘째, 설치 후 누가, 얼마나 빨리 유지보수를 해주는가. 셋째, AI 연산 자원과 현장 로봇이 지체 없이 동기화되는 인터페이스가 실제로 준비돼 있는가. 이 세 가지가 갖춰지지 않으면, 좋은 로봇도 결국 창고의 비싼 장식품이 된다.

그래서 뭘 하면 되나

- 로봇 도입을 검토 중이라면, 견적서보다 유지보수·예비 부품·긴급 대응 체계를 먼저 물어보자.

- PoC 단계에서 자사 공정 데이터와 실제 작업 조건을 그대로 넣어보고, 고장·정지 시나리오까지 함께 테스트하자.

- AI 연산과 로봇 제어를 따로 보지 말고, "데이터가 현장에서 얼마나 지체 없이 움직임으로 바뀌는가"를 기준으로 삼자.

마무리

피지컬 AI 경쟁은 이제 로봇을 만드는 회사만의 싸움이 아니다. 로봇을 현장에서 굴려주는 회사, 고장 나도 세우지 않는 회사의 싸움으로 번지고 있다. 리더스시스템즈와 테라다인 로보틱스의 이번 협력은 그 변화의 한 단면이다. 다음에 로봇 뉴스를 볼 때는 스펙표 아래에 있는 "누가, 어떻게 돌려주는가"를 함께 읽어보자.

출처: 서울경제TV, 「리더스시스템즈, 로봇 자동화 사업

진출…테라다인 로보틱스와 협력」, 2026-10-30.

이 글은 '현장 AI 운영 노트' 시리즈의 세 번째 글입니다. 1편에서는 매일 아침 AI의 건강을 보는 5분 점검표를, 지난 편에서는 그 점검표를 대시보드 하나로 만드는 법을 다뤘습니다 (EP.1 https://developer-archive.tistory.com/175). 이번 편에서는 대시보드에 경보가 울렸을 때, 누가 어떤 순서로 어디까지 확인하는지 — 조치 루틴을 다룹니다.

대시보드가 있어도 경보가 울리면 현장은 잠깐 멈칫합니다. "이거 누가 봐야 하죠?"라는 질문부터 시작되기 때문입니다. 경보 자체보다 비싼 건 경보를 보고도 아무도 움직이지 않는 시간입니다. 그래서 운영에서 진짜로 필요한 건 더 예민한 경보가 아니라, 울렸을 때 바로 움직이는 순서입니다.

1단계: 확인은 현장에서, 판단은 따로

경보가 울리면 첫 번째 확인은 AI 팀이 아니라 현장에서 합니다. 결측률이 튄 원인이 센서인지, 조명인지, 작업 조건이 바뀐 건지 — 이건 화면이 아니라 현장에 가봐야 압니다. 그래서 저는 1단계를 "현장 10분 확인"으로 정해두는 걸 권합니다. 설비 상태, 최근 작업 변경, 청소나 조명 같은 환경 변화, 이 세 가지만 확인하고 결과를 기록합니다. 현장 원인이 보이면 그걸로 끝입니다. AI를 뜯을 이유가 없습니다.

여기서 중요한 건, 현장 확인을 "AI가 틀렸다"는 판정으로 만들지 않는 것입니다. 확인은 원인을 좁히는 일이지, 책임을 가리는 일이 아닙니다. 원인이 현장에 있으면 현장에서 고치고, 원인이 AI 쪽에 있으면 그때 AI 팀으로 넘어갑니다. 순서가 이래야 양쪽 모두 경보를 두려워하지 않습니다.

2단계: AI 쪽으로 넘어가는 기준을 미리 정한다

현장 확인에서 원인이 안 보이면, 그때 AI 쪽 확인으로 넘어갑니다. 입력 분포가 바뀌었는지, 판정 뒤집기가 특정 유형에 몰려 있는지, 최근에 예시나 기준이 바뀐 게 있는지를 봅니다. 그런데 이 단계에서 자주 벌어지는 실수가 "일단 모델을 다시 학습시켜보자"는 것입니다. 원인을 모른 채 재학습부터 하면, 문제는 잠깐 가려질 뿐 나중에 더 큰 형태로 돌아옵니다.

그래서 2단계의 규칙은 단순합니다. 원인 가설 하나를 적고, 그 가설을 확인할 수 있는 숫자 하나를 정한 뒤에야 조치를 바꿉니다. 예를 들어 "조명 반사 건이 뒤집기의 절반"이라는 가설이 있으면, 반사 건만 따로 모아 확인하고 나서 예시를 보강합니다. 가설 없이 바꾸는 건 운영이 아니라 도박에 가깝습니다.

3단계: 어디까지가 현장, 어디부터가 중단인가

가장 미리 정해둬야 할 건, "이 정도면 라인을 세운다"는 기준입니다. 경보마다 심각도를 세 단계로만 나눠두면 충분합니다. ① 지켜본다 — 추이는 보되 당장 조치는 없다 ② 확인한다 — 현장 확인과 AI 확인을 오늘 안에 한다 ③ 멈춘다 — 판정을 믿지 않고 수동 검사로 전환한다. 이 기준이 없으면, 경보는 울리는데 아무도 멈출 결정을 못 하고, 반대로 사소한 경보에 라인이 자주 서는 일이 반복됩니다.

'멈춘다' 기준은 정확도가 아니라 현장 영향으로 정하는 게 좋습니다. 불량 유출 가능성, 안전 관련 여부, 뒤집기 비율이 평소 범위를 얼마나 벗어났는지 같은 기준입니다. 숫자는 라인마다 다르게 정해도 됩니다. 중요한 건, 경보가 울린 뒤에 정하는 게 아니라 경보가 울리기 전에 정해두는 것입니다.

그래서 뭘 하면 되나 — 한 장의 조치 루틴표

이번 주에 이렇게 시작해 보세요. 경보 하나를 골라 한 장으로 적습니다. 경보 이름, 1단계 현장 확인 3가지, AI 쪽으로 넘어가는 기준, 심각도 3단계와 각 단계의 담당자. 담당자 이름까지 적는 게 핵심입니다. "AI 팀이 본다"가 아니라 "누가 본다"여야 움직입니다. 이 표가 있으면, 다음에 경보가 울렸을 때 회의가 아니라 확인부터 시작됩니다.

운영은 시스템을 더 세게 만드는 일이 아니라, 경보가 울렸을 때 사람이 헤매지 않게 만드는 일입니다. 다음 편에서는 이 루틴을 한 달 돌린 뒤 — 경보를 줄이고, 기준을 다듬는 '운영 리뷰'를 다룹니다.

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

per-archive.tistory.com/164)

현장 AI가 이상한 답을 내놓으면, 대부분 프롬프트부터 고칩니다. 문장을 다듬고, 지시문을 길게 쓰고, 다시 돌려봅니다. 그런데 몇 번 고쳐도 답이 그대로인 경우가 있습니다. 그럴 때 저는 프롬프트가 아니라 예시를 봅니다. AI에게 보여준 예시 몇 개가, 사실은 답의 기준을 정하고 있기 때문입니다.

예시는 '정답'이 아니라 '기준'이다

few-shot 방식에서 예시는 참고 자료가 아니라 판단 기준입니다. "이건 불량, 이건 정상"이라는 예시 몇 개가 AI의 눈금을 정합니다. 현장 용어가 섞인 판정, 애매한 경계 케이스, 작업자마다 다르게 부르는 이름까지 모두 예시 안에 들어갑니다. 그래서 예시가 낡았거나 한쪽으로 치우치면, 프롬프트를 아무리 정교하게 써도 답은 그 예시를 따라갑니다. 프롬프트는 방향을 말하고, 예시는 기준을 보여줍니다.

예시를 고를 때 보는 세 가지

첫째, 경계 케이스를 꼭 넣습니다. 명확한 정상과 명확한 불량만 보여주면, AI는 애매한 경우를 자기 마음대로 정합니다. 현장에서 실제로 논쟁이 됐던 케이스, "이건 불량으로 볼까, 말까" 했던 사례가 가장 값진 예시입니다.

둘째, 최신 기준을 반영합니다. 판정 기준이 바뀐 뒤 옛날 예시가 남아 있으면 AI는 옛날 기준으로 답합니다. 기준이 바뀌면 예시도 함께 바꿔야 합니다. 이걸 놓치면 모델이 아니라 예시가 구버전이 됩니다.

셋째, 한쪽으로 치우치지 않게 섞습니다. 정상만 잔뜩 보여주면 AI는 웬만한 걸 다 정상이라 하고, 불량만 보여주면 과민해집니다. 정상·불량·애매한 경우를 골고루, 현장 비율과 너무 동떨어지지 않게 구성하는 게 중요합니다.

예시를 관리하는 습관

예시도 코드처럼 관리해야 합니다. 저는 예시 목록을 따로 모아두고, 바꾼 날짜와 바꾼 이유를 함께 적어둡니다. 틀린 답이 나오면 프롬프트를 뜯기 전에 예시부터 의심합니다. "이 답이 나온 근거가 된 예시가 뭐였지?"를 먼저 묻는 겁니다. 그리고 주기적으로 예시를 갈아줍니다. 현장이 바뀌면 예시도 바뀌어야 하니까요. 예시 관리에 들인 30분이, 프롬프트를 붙잡고 보낸 하루보다 값질 때가 많습니다.

프롬프트를 고치는 건 쉽고 눈에 잘 띕니다. 하지만 현장 AI의 품질은 대부분 예시에서 갈립니다. 오늘 당장 할 일은 세 가지입니다. 지금 쓰고 있는 예시 목록을 한곳에 모으고, 경계 케이스 하나를 추가하고, 기준이 바뀐 옛날 예시가 있는지 확인하는 것. 그다음에 프롬프트를 고쳐도 늦지 않습니다.

관련 글: 모델 평가를 현장 지표로 바꾸는 법 https://developer-archive.tistory.com/164 · 프롬프트 위의 '규칙 레이어' 설계법 https://developer-arc

hive.tistory.com/140

오늘 아침 쇼츠 '제조AI 용어 사전 EP.12 — 산업용 사물인터넷'의 심화판입니다. 30초짜리 정의만으로는 현장에서 왜 IIoT가 어려운지 설명이 안 됩니다. 기계에 센서를 붙였다고 해서 끝이 아니기 때문입니다.

1. IIoT는 일반 IoT와 뭐가 다를까

집에서 쓰는 IoT는 편리함이 목적입니다. 전등을 켜고, 온도를 맞추고, 가끔 연결이 끊겨도 큰일이 나지 않습니다. 산업용 사물인터넷(IIoT, Industrial Internet of Things)은 다릅니다. 설비·센서·제어기가 24시간 돌아가는 공장에서 데이터를 주고받아야 하고, 끊김 하나가 불량이나 정지로 이어질 수 있습니다.

그래서 IIoT에서는 '연결됐다'는 말보다 '얼마나 빠르고, 얼마나 믿을 수 있게, 얼마나 안전하게' 주고받느냐가 중요합니다. 속도, 신뢰성, 보안이 제품 스펙이 아니라 운영 조건이 되는 셈입니다.

2. 현장에서 데이터가 흐르는 4단계

현장 데이터는 네 단계를 거칩니다. 첫째 수집 단계에서는 센서·PLC·설비에서 값을 읽고, 현장에서 흔한 실수는 무슨 값인지 정의 없이 모으는 것입니다. 둘째 전송 단계에서는 MQTT·OPC UA 등으로 보내고, 흔한 실수는 프로토콜만 정하고 주기·품질을 안 정하는 것입니다. 셋째 저장·가공 단계에서는 시간 순서대로 쌓고 맥락을 붙이고, 흔한 실수는 설비 ID·시간 기준이 제각각인 채로 쌓는 것입니다. 넷째 활용 단계에서는 모니터링·예지정비·AI 분석을 하고, 흔한 실수는 대시보드만 만들고 행동 기준을 안 만드는 것입니다.

저는 이 표를 거꾸로 읽어보길 권합니다. 활용에서 필요한 판단이 뭔지 먼저 정해야, 수집할 값과 전송 주기가 정해집니다. 데이터부터 모으고 나중에 쓰임새를 찾는 순서가 현장에서 가장 비싼 순서입니다.

3. 도입 전에 먼저 정할 3가지

첫째, 시간 기준입니다. 설비마다 시계가 조금씩 다르면, 같은 순간의 사건도 다른 시간으로 기록됩니다. 장애 원인을 찾을 때 이 어긋남이 그대로 혼란이 됩니다.

둘째, 이름과 단위입니다. 같은 온도를 어떤 설비는 'TEMP', 어떤 설비는 'T1'이라 부르면, 나중에 합치는 사람이 전부 다시 해석해야 합니다. 이름 짓기는 사소해 보이지만, IIoT에서 가장 오래 남는 부채입니다.

셋째, 끊겼을 때의 동작입니다. 네트워크가 끊기면 데이터를 버릴지, 현장에 쌓아뒀다가 다시 보낼지, 경보를 울릴지를 미리 정해야 합니다. 전송이 끊기는 건 정상 상황으로 설계해야 현장에서 버팁니다.

마무리 — 그래서 뭘 하면 되나

IIoT는 센서를 많이 붙이는 기술이 아니라, 현장의 사건을 '같은 시간, 같은 이름, 같은 기준'으로 기록하는 약속입니다. 이번 주에 한 가지만 해본다면, 담당 라인에서 가장 중요한 값 5개만 골라 이름·단위·주기·끊겼을 때의 동작을 한 장으로 적어보세요. 그 한 장이 나중에 디지털트윈, 예지정비, 제조 AI로 이어지는 가장 싼 출발점이 됩니다.

관련 글: #124 데이터 수집이 디지털트윈의 엔진인 이유, #136 OPC UA, #151 M

QTT, #157 엣지 컴퓨팅, #173 MES