프로그래밍 허브

도입

설비가 멈춘 뒤, 현장에서 가장 먼저 나오는 말은 "아까까지만 해도 괜찮았는데"입니다. 문제는 그 '아까'가 정확히 언제인지, 그때 설비가 어떤 상태였는지 아무도 모른다는 겁니다. 알람 로그는 남아 있지만, 알람은 결과만 알려줄 뿐 그 전의 흐름은 보여주지 않습니다.

7년차 현장 엔지니어로서 제가 디지털트윈에서 가장 아쉽게 느끼는 기능이 바로 이 '되돌리기'입니다. 실시간으로 보여주는 트윈은 많은데, 과거의 어느 순간으로 돌아가 "그때 뭐가 달랐나"를 보여주는 트윈은 드뭅니다.

실시간만으로는 원인을 못 잡는다

고장의 원인은 대개 '순간'이 아니라 '흐름' 속에 있습니다. 온도가 한 번에 튄 게 아니라 3시간에 걸쳐 서서히 올랐고, 진동이 갑자기 커진 게 아니라 부하 패턴이 조금씩 바뀌었습니다. 그런데 실시간 화면은 지금 이 순간만 보여줍니다. 고장이 난 뒤에는 이미 늦은 화면만 남습니다.

그래서 현장에서는 결국 사람의 기억에 의존하게 됩니다. "어제 오후쯤부터 소리가 좀 이상했어." 기억은 흐릿하고, 사람마다 다릅니다. 원인을 찾는 회의가 길어지는 이유입니다. 데이터는 있는데, 그 데이터를 '시간 순서대로 다시 보는' 방법이 없는 겁니다.

되돌리기는 세 가지를 바꾼다

디지털트윈에 되돌리기(리플레이) 기능이 있으면, 고장 분석의 방식 자체가 달라집니다.

첫째, '언제부터'를 찾을 수 있습니다. 고장 시점에서 시간을 거꾸로 돌리며 어느 지점부터 값이 평소와 달라졌는지 확인합니다. 온도·진동·부하 곡선을 같은 화면에 겹쳐 보면, 세 곡선이 동시에 어긋나기 시작한 지점이 보입니다. 그 지점이 곧 조사의 출발점입니다. '실시간'의 조건을 다룬 이전 글(https://developer-archive.tistory.com/132)에서 말했듯, 트윈의 가치는 화면의 빠르기가 아니라 시간의 정확도에 있습니다.

둘째, 재현이 가능해집니다. "같은 조건에서 다시 돌려보면 어떻게 되나"를 트윈 안에서 시험할 수 있습니다. 실제 설비를 멈추지 않고, 그날의 조건을 그대로 불러와 원인을 확인하는 겁니다. 현장에서 '한 번 더 돌려보자'는 말은 설비를 세워야 해서 쉽게 못 하지만, 트윈 안에서는 가능합니다.

셋째, 기록이 자산이 됩니다. 되돌린 장면을 '그날의 교훈'으로 저장해 두면, 다음에 비슷한 징후가 보일 때 비교 기준이 생깁니다. 설비의 '상태'를 모델링한다는 건 결국 이런 장면들의 축적이라는 점에서, 이전 글 '신호는 보이는데 상태는 안 보인다'(https://developer-archive.tistory.com/162)와 같은 맥락입니다.

되돌리기를 설계할 때 현실적인 조건

물론 되돌리기는 공짜가 아닙니다. 모든 데이터를 초 단위로 다 저장하면 저장 비용이 금방 불어납니다. 그래서 현장에서는 '무엇을, 얼마나 촘촘히' 저장할지부터 정해야 합니다. 핵심 설비는 1초 단위, 일반 설비는 1분 단위로 나누는 식입니다. 해상도를 용도별로 다르게 가져가야 한다는 점은 이전 글 '디지털트윈의 해상도'(https://developer-archive.tistory.com/147)에서도 다뤘습니다.

또 하나, 되돌리기는 '과거의 트윈'이 '지금의 트윈'과 같은 모델이어야 의미가 있습니다. 그 사이에 모델이 바뀌었다면, 과거 데이터에 지금 모델을 얹는 건 다른 설비를 보는 것과 같습니다. 모델 변경 이력과 데이터의 버전을 함께 관리해야 되돌리기가 믿을 만해집니다. 모델 버전 관리의 중요성은 이전 글(https://developer-archive.tistory.com/155)에서도 다룬 바 있습니다.

마무리

디지털트윈은 '지금'을 보여주는 도구로 시작했지만, 현장에서 진짜 값을 내는 순간은 '그때'를 다시 볼 수 있을 때입니다. 고장은 이미 지나간 일이고, 우리가 할 수 있는 건 그 지나간 시간을 얼마나 정확히 되짚느냐입니다.

그래서 뭘 하면 되나 — 당장 전체 트윈에 되돌리기를 붙일 필요는 없습니다. 고장이 잦은 설비 하나만 골라, 고장 전후 1시간의 데이터를 시간 순서대로 다시 볼 수 있는 화면부터 만들어보세요. 그 한 장면이, 다음 고장의 원인을 찾는 시간을 절반으로 줄여줄 겁니다.

함께 읽으면 좋은 글:

디지털트윈이 '실시간'이 되는 조건 https://developer-archive.tistory.com/132

디지털트윈의 해상도 https://developer-archive.tistory.com/147

모델 버전 관리 https://developer-archive.tistory.com/155

신호는 보이는데 상태는 안 보인다 — 설비 상태 모델링 https://developer-archive.tistory.com/162

AI가 산업용 로봇 시장을 키운다는 소식은 이제 낯설지 않다. 그런데 11월 8일 나온 S&P 글로벌 보고서는 한 줄을 덧붙였다. "커지는 시장의 과실은 로봇 제조사보다 로봇을 쓰는 고객 쪽으로 더 간다." 시장이 커지는데 파는 쪽이 덜 번다는 역설, 현장에서 보면 의외로 납득이 간다.

로봇은 더 팔리는데, 왜 제조사는 덜 벌까

국제 로봇 연맹(IFR) 자료에 따르면 2025년 전 세계 산업용 로봇 신규 설치 대수는 60만 3,000대로 전년 대비 11% 늘었고, 가동 중인 로봇은 약 510만 대로 9% 증가했다. AI는 잦은 생산 변경과 복잡한 프로그래밍이 필요했던 공정을 자동화하기 쉽게 만들어 시장 자체를 넓힌다.

그런데 로봇 한 대가 더 유연해지고 가동률이 올라가면, 고객은 굳이 로봇을 더 사지 않아도 된다. 기존 설비로 더 많은 일을 하게 되니 신규 수요가 상쇄되는 구조다. 여기에 소프트웨어 업체가 가치의 일부를 가져간다. 프로그래밍·시뮬레이션·애플리케이션 엔지니어링이 AI로 쉬워지면서, 돈은 하드웨어가 아니라 소프트웨어 쪽으로 이동한다.

현장에서 먼저 오는 건 '완전 자율'이 아니다

보고서가 짚은 순서도 현장 감각과 맞는다. 완전 자율 로봇이 상용화되기 전에, AI 기반 프로그래밍·시뮬레이션·애플리케이션 엔지니어링 개선이 먼저 온다. 로봇을 새로 사는 것보다, 지금 있는 로봇을 더 쉽게 가르치고, 시뮬레이션으로 먼저 검증하고, 공정 변경에 빨리 대응하는 능력이 먼저 돈이 된다.

7년차 현장 엔지니어로서 한 줄로 정리하면, "로봇 도입의 병목은 이제 로봇값이 아니라 '가르치는 비용'이다."

그래서 뭘 하면 되나

- 새 로봇 견적 전에, 기존 로봇의 가동률과 재프로그래밍 시간을 먼저 잰다. 남는 가동률이 곧 '안 사도 되는 로봇'이다.

- 공정 변경이 잦은 라인부터 시뮬레이션 기반 프로그래밍을 도입한다. 티칭 시간을 줄이는 게 곧 투자 회수다.

- 소프트웨어 역량을 외주에만 맡기지 말고, 현장에 '로봇을 가르치는 사람'을 둔다. 앞으로의 경쟁력은 하드웨어 스펙이 아니라 가르치는 속도에서 갈린다.

마무리 — 사는 쪽에게는 오히려 기회다

AI 시대의 로봇 경쟁은 '누가 더 많이 파느냐'가 아니라 '누가 현장에서 더 빨리 가르치느냐'로 옮겨가고 있다. 로봇을 사는 쪽이라면, 이 역설은 오히려 기회다. 이미 가진 로봇을 더 유연하게 쓰는 회사가, 다음 로봇을 사기 전에 한 발 앞서 나간다.

출처: S&P 글로벌 보고서, 이코노믹타임스 2026-11-08; IFR 설치 대수 자료(2025년 신규 60만 3,000대, 가동 중 약 510만 대).

디지털트윈 도입 상담에서 가장 많이 듣는 말이 있다. "우리 공장 전체를 트윈으로 만들고 싶어요." 현장에서 7년을 일한 입장에서, 그 말부터 다시 짚어야 한다. 전 공장을 한 번에 트윈으로 만드는 건, 지도를 그리기 전에 나라 전체를 측량하겠다는 말과 같다. 가능은 해도, 처음부터 그 크기로 시작하면 대부분 중간에 멈춘다.

왜 '전 공장 한 번에'는 실패하기 쉬운가

첫째, 데이터 수집부터 막힌다. 설비마다 프로토콜도, 주기도, 단위도 다르다. 전 공장 단위면 수집 대상만 수백 개가 된다. 수집이 끝나기도 전에 일정과 예산이 먼저 바닥난다.

둘째, 현장의 신뢰를 잃는다. 첫 화면이 틀리면 "트윈은 안 맞는다"는 인식이 굳는다. 모델을 고치는 데 드는 비용보다, 그 신뢰를 되돌리는 데 드는 시간이 더 크다.

셋째, 검증 단계가 사라진다. 작게 시작하지 않으면 PoC가 아니라 '구축'이 돼버린다. 납품받는 순간부터 유지보수 부담만 남고, 현장에선 아무도 안 보는 대시보드가 된다.

파일럿 라인을 고르는 3가지 기준

첫째, 고장이 잦고 고장 비용이 보이는 라인이다. 효과가 숫자로 보여야 다음 단계 예산이 나온다. "월 3번 멈추던 라인이 1번으로 줄었다"는 말이 가장 강한 근거다.

둘째, 데이터가 이미 어느 정도 있는 라인이다. 센서나 MES 기록이 있으면 수집 비용이 확 준다. 없는 곳부터 뚫는 건 두 번째 단계에서 해도 늦지 않다.

셋째, 현장 운영자가 협조적인 라인이다. 트윈은 결국 사람이 쓰는 도구라, 쓰는 사람의 협조가 성패를 가른다. "이거만 되면 좋겠다"고 말하는 운영자가 있는 라인이 정답에 가깝다.

작게 시작해 키우는 순서

1단계는 라인 하나, 설비 5~10대, 신호 20~30개로 시작하는 것이다. 2단계는 4주 정도 돌려보며 '트윈이 틀린 날'을 기록하는 것이다. 틀린 날짜가 곧 모델을 고치는 목록이 된다. 3단계는 맞춘 뒤에야 옆 라인으로 확장하는 것이다. 이때 태그 명명, 주기, 단위 같은 데이터 구조를 표준으로 고정해두면 확장이 훨씬 빨라진다.

그래서 뭘 하면 되나. 이번 주, 우리 공장에서 파일럿으로 삼을 라인 하나를 골라보자. 고장 기록이 가장 많은 라인, 운영자가 "이거만 되면 좋겠다"고 말하는 라인부터다. 디지털트윈은 크게 그리는 그림이 아니라, 작게 맞추는 습관이다.

함께 읽으면 좋은 글:

디지털트윈의 진짜 엔진은 3D가 아니라 '데이터 수집'이다 https://developer-archive.tistory.com/124

디지털트윈이 '실시간'이 되는 조건 https://developer-archive.tistory.com/132

PoC, 도입 전에 작게 검증하는 법 https://developer-archive.tistory.com/168

MES, 공장 생산을 실시간으로 지시하고 기록하는 시스템 https://developer-archive.tistory.com/173

현장에서 설비가 멈추면 제일 먼저 찾는 게 뭘까요? 매뉴얼입니다. 그런데 매뉴얼은 PDF로, 도면은 다른 폴더에, 지난 고장 이력은 메신저 대화 속에 흩어져 있습니다. 베테랑은 "그거 3년 전에도 났었지" 하고 기억을 더듬지만, 신입은 어디서부터 찾아야 할지 모릅니다.

AI 챗봇을 현장에 들여놨는데 "이 에러 코드 뭐예요?"라고 물으면, 모델은 그럴듯하게 지어냅니다. 현장 매뉴얼을 학습한 적이 없으니까요. 여기서 RAG(검색 증강 생성)가 등장합니다. 모델을 더 크게 만드는 게 아니라, 현장 지식을 모델에 연결하는 일입니다.

RAG가 현장에서 필요한 이유

일반 챗봇과 현장 AI의 차이는 '아는 것'이 아니라 '찾는 것'에 있습니다. 범용 모델은 인터넷 지식으로 답하지만, 우리 공장의 설비 매뉴얼·사양서·점검 이력은 그 안에 없습니다. 그래서 현장 AI는 두 가지 조건을 만족해야 합니다. 첫째, 답의 근거가 현장 문서에 있을 것. 둘째, 모르면 모른다고 말할 것.

RAG는 이 두 가지를 구조로 해결합니다. 질문이 들어오면 먼저 현장 문서에서 관련 내용을 검색하고, 그 내용을 근거로 답을 만듭니다. 답과 함께 "어느 문서 몇 페이지에서 가져왔다"는 출처까지 보여주면, 현장 사람은 답을 그대로 믿는 대신 검증할 수 있습니다. 이건 #125에서 다룬 재현성, #145에서 다룬 권한 문제와 같은 선상에 있습니다. 현장 AI의 신뢰는 정확도가 아니라 검증 가능성에서 나옵니다.

현장 RAG의 3단계 설계

1단계 — 수집과 나누기(청킹). 매뉴얼·도면·점검표·고장 이력을 한곳에 모으고, 검색이 가능한 단위로 나눕니다. 한 문서는 너무 크고, 한 문장은 너무 작습니다. 현장에서는 '에러 코드 하나 + 조치 방법'처럼, 하나의 질문에 답할 수 있는 덩어리가 적당합니다. 표는 표대로, 주의사항은 주의사항대로 덩어리를 유지하는 게 중요합니다. 도면 속 텍스트는 OCR로 뽑아두면 검색에 포함됩니다.

2단계 — 검색(리트리버). 나눈 덩어리에 임베딩을 붙여 벡터로 저장하고, 질문과 의미가 가까운 덩어리를 찾습니다. 현장에서는 키워드 검색과 의미 검색을 함께 쓰는 하이브리드 방식이 잘 맞습니다. "E-204" 같은 에러 코드는 키워드로 정확히 잡아야 하고, "모터가 뜨거워져요" 같은 증상 설명은 의미로 잡아야 하니까요. 설비명·라인·날짜 같은 메타데이터로 범위를 좁히면 오답이 크게 줄어듭니다.

현장 RAG 검색의 뼈대 (의사코드):

chunks = chunk_documents(manuals, chunk_size="에러 코드 + 조치 1건")
index = build_index(chunks, metadata=["설비명", "라인", "개정일"])
results = index.search(question, top_k=5, filter={"설비명": "사출기-3호"})
answer = llm.generate(question, context=results, cite_sources=True)

3단계 — 생성과 검증. 검색된 내용을 근거로 답을 만들고, 출처를 함께 표시합니다. 여기서 중요한 규칙이 하나 있습니다. 검색 결과가 없으면 답을 만들지 말고 "문서에서 찾지 못했습니다"라고 말하게 할 것. #140의 규칙 레이어와 같은 맥락입니다. 현장에서는 틀린 답보다 '모른다'는 답이 훨씬 안전합니다. 답을 낸 뒤에는 사람이 확인하는 루프를 두는 게 좋습니다. 확인된 답은 다시 학습 데이터가 아니라, 검증된 문서로 돌아가야 합니다.

일반 챗봇과 현장 RAG는 이렇게 다릅니다. 답의 근거는 일반 챗봇이 모델 학습 데이터라면, 현장 RAG는 현장 매뉴얼·이력 문서입니다. 최신 정보는 일반 챗봇이 학습 시점까지만 알지만, 현장 RAG는 문서만 업데이트하면 반영됩니다. 출처 표시는 일반 챗봇은 불가하지만, 현장 RAG는 문서명·페이지 표시가 가능합니다. 모를 때 일반 챗봇은 지어내기 쉽지만, 현장 RAG는 "찾지 못했습니다"로 설계할 수 있습니다.

현장에서 바로 할 일

매뉴얼 1종부터 시작합니다. 전 설비를 한 번에 옮기려 하지 말고, 고장이 잦은 설비 1대의 매뉴얼과 이력부터 RAG에 올립니다.

검색 품질부터 측정합니다. 자주 묻는 질문 20개를 뽑아, 정답 문서가 검색 상위 5개 안에 드는지부터 확인합니다. 생성 품질은 그다음입니다.

출처 표시를 기본값으로 둡니다. 답만 주는 AI는 현장에서 오래 못 갑니다. "어디서 가져왔는지"가 보이는 AI가 신뢰를 얻습니다.

RAG는 화려한 기술이 아닙니다. 현장 지식을 찾아서, 근거 있게, 모르면 모른다고 말하는 AI를 만드는 일입니다. 모델이 똑똑해지는 것보다, 현장의 기록이 제때 찾아지는 게 먼저입니다. 그게 제조 현장에서 AI가 살아남는 순서입니다.

관련 글: 재현성 https://developer-archive.tistory.com/125 · 규칙 레이어 https://developer-archive.tistory.com/140 · 챗봇 권한 문제 https://developer-archive.tistory.com/145 

도입

현장에서 20년 일한 선배는 설비 소리만 듣고도 "오늘 안에 베어링 갈아야겠다"고 말합니다. 신입은 같은 소리를 듣고도 고개를 갸웃합니다. 그 차이가 '손 감각'이고, 제조 AI가 가장 배우기 어려워하는 것도 바로 이 감각입니다. 데이터는 쌓이는데, 왜 AI는 선배의 판단을 따라가지 못할까요.

7년차 현장 엔지니어로서 제가 본 답은 간단합니다. 손 감각이 데이터로 옮겨진 적이 없기 때문입니다. AI는 없는 것을 배울 수 없습니다.

손 감각이 사라지는 구조

숙련자의 판단은 대부분 '말로 안 남는' 형태입니다. "소리가 좀 거칠어졌네", "진동이 평소랑 달라", "냄새가 좀 타는 것 같아". 이런 말은 회의록에도, MES에도, 센서 로그에도 남지 않습니다. 그래서 선배가 퇴직하면 판단 기준 자체가 사라집니다. 설비는 그대로인데, 설비를 읽는 눈이 없어지는 겁니다.

더 아쉬운 건, 이런 감각이 사실은 데이터와 연결돼 있다는 점입니다. "소리가 거칠어졌다"는 말 뒤에는 진동 센서 값의 미세한 상승이 있고, "냄새가 탄다"는 말 뒤에는 온도 곡선의 완만한 상승이 있습니다. 다만 아무도 그 말과 그 숫자를 같은 줄에 적어본 적이 없을 뿐입니다.

노하우를 데이터로 옮기는 기록법

그래서 저는 현장에서 세 가지를 실천하고 있습니다.

첫째, 판단의 '순간'을 기록합니다. 설비에 이상이 느껴졌을 때, 그 순간의 센서 값을 캡처하고 한 줄 코멘트를 붙입니다. "14:32, 프레스 3호기 소음 증가 — 진동 2.3→3.1mm/s." 한 줄이면 됩니다. 완벽한 보고서가 아니라, 판단과 숫자가 같은 줄에 있는 기록이 중요합니다.

둘째, 틀린 판단도 남깁니다. "베어링인 줄 알았는데 벨트였다"는 기록이 쌓이면, AI는 '비슷한 소리라도 원인이 다르다'는 걸 배웁니다. 맞은 판단만 남기면 AI는 확신만 배우고, 틀린 판단까지 남기면 AI는 조심성을 배웁니다. 관련해서는 이전 글 '설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것' https://developer-archive.tistory.com/130 에서 로그 설계 습관을 다뤘습니다.

셋째, '왜 그렇게 봤는지'를 묻습니다. 선배에게 "왜 베어링이라고 보셨어요?"라고 물으면 "소리 주기가 달라졌거든" 같은 단서가 나옵니다. 그 단서가 곧 AI의 특징(feature) 후보입니다. 노하우 전수는 기술 이전이 아니라, 질문으로 뽑아내는 작업입니다. 운영 기록을 학습 자산으로 바꾸는 흐름은 '현장 AI 운영 노트' 시리즈 https://developer-archive.tistory.com/215  에서도 이어지고 있습니다.

마무리

AI가 현장을 배우는 속도는 모델 성능이 아니라, 현장의 노하우가 얼마나 데이터로 옮겨졌느냐로 정해집니다. 숙련자의 손 감각은 사라질 운명이 아니라, 기록하면 자산이 됩니다.

그래서 뭘 하면 되나 — 오늘부터 한 가지만 해보세요. 설비에 이상을 느꼈을 때, 그 순간의 센서 값과 한 줄 코멘트를 같은 곳에 적어두는 것. 그 한 줄이 쌓이면, AI가 배울 수 있는 '현장의 교과서'가 됩니다.

관련 글: 설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것 https://developer-archive.tistory.com/130 · 현장 AI 운영 노트 EP.9 https://developer-archive.tistory.com/215 

11월 6일, 독일 뮌헨에서 열린 Humanoid Europe 2026에서 스위스 로봇 스타트업 Embodied AI가 휴머노이드 로봇 AIR를 공개했다. EPFL(스위스 로잔 연방공과대) 스핀아웃인 이 회사는 연구 단계에서 산업용 휴머노이드까지 9개월 만에 도달했고, 이미 글로벌 대기업(OEM)들과 계약을 맺고 양산 준비에 들어갔다고 밝혔다. 그런데 이번 발표에서 진짜 주목할 지점은 로봇의 생김새가 아니다. '어떻게 배우는가'다.

첫날부터 일하고, 한 달 만에 혼자 일한다

AIR는 공장에 들어가는 첫날부터 일을 시작한다. 처음에는 작업자가 원격으로 조종(텔레오퍼레이션)하고, 로봇은 그 모든 동작을 기록한다. 이 기록이 곧 학습 데이터가 된다. AI 스택이 이 데모 데이터에서 작업 방식을 배우면, 보통 한 달 안에 같은 작업을 혼자 수행할 수 있게 된다. 회사가 밝힌 일정이다.

타깃은 분명하다. 기존 산업용 로봇이 프로그래밍 비용 때문에 손대지 않았던, 자주 바뀌는 반복 수작업이다. 정해진 동작을 무한히 반복하는 로봇이 아니라, 현장에서 일하는 법을 배우는 로봇이라는 점이 AIR의 핵심이다.

안전을 '설계'로 푼다 — 힘줄 구조와 협동 규격

AIR의 팔은 텐던(힘줄) 구동 방식이다. 모터와 기어박스, 전자장치는 몸통에 두고, 팔은 가볍게 만들어 접촉 시 충격을 흡수하도록 설계했다. 하체는 바퀴 기반, 상체에 가벼운 두 팔을 단 구조다. 무거운 팔을 사람 옆에 두지 않는다는 발상이다.

안전 규격도 처음부터 염두에 뒀다. 협동로봇 안전 규격 ISO/TS 15066:2016에 맞춰 설계했고, 2027년 CE 인증을 목표로 하고 있다. 아직 인증을 받은 상태는 아니다. '안전하다'는 말이 아니라, 어떤 규격에 맞춰 설계했는지를 보는 것이 현장에서 안전을 판단하는 기준이다.

왜 중요한가 — 도입의 병목은 '첫날'이다

7년차 현장 엔지니어로서 한 줄만 덧붙이면, 로봇 도입이 막히는 지점은 스펙이 아니라 '첫날'이다. 첫날부터 라인을 세우지 않고 일을 시작할 수 있는가. 그 답을 먼저 묻는 것이 현장 도입의 출발점이다.

AIR의 AI 스택은 이미 유료 공장 배치에서 검증된 이력이 있다. 여기에 별도로 2개 팔을 갖춘 산업용 셀 형태에서는 공장 케이블 작업 평가에서 98%의 신뢰도를 기록했다는 게 회사의 설명이다. 현장에서 '배웠다'는 말은 데모 영상이 아니라, 유료 배치와 수치로 증명해야 한다.

물론 과제도 있다. 데모에서 배우는 AI는 데모의 품질이 곧 학습의 품질이다. 작업자의 숙련도와 기록 설계가 그대로 모델에 들어간다. 그래서 실연 데이터를 모으는 설계 — 누가, 어떤 순서로, 어떤 예외까지 보여주느냐 — 가 도입의 성패를 가른다. 합성 데이터로 훈련하는 방식(이전 글 '합성 데이터 1편' https://developer-archive.tistory.com/127 참고)과 비교하면, 실연 데이터는 현장의 예외를 그대로 담는 대신 그만큼 '가르치는 사람'의 역할이 커진다.

휴머노이드 경쟁의 질문이 바뀌고 있다. '얼마나 잘 걷는가'에서 '현장의 일을 얼마나 빨리 배우는가'로. AIR의 답은 데모다. 사람이 보여주고, 로봇이 배우고, 한 달 뒤에는 혼자 일한다. 그 학습 속도가 다음 휴머노이드의 경쟁력이 될 것이다.

출처: Business Wire, "Embodied AI Unveils AIR, a Physically Safe Humanoid Robot That Learns on the Job" (2026-11-06) / The AI Insider, "Switzerland's Embodied AI Unveils Humanoid Robot Designed to Learn Factory Tasks From Workers" (2026-11-06) / Industrial Equipment News (IEN), "Embodied AI's Humanoid Robot Is Built to Work Next to People" (2026-11-06)

1. 정확도 99% 모델이 현장에서 외면받는 이유

모델 평가표에서는 정확도 99%를 찍은 불량 검사 AI가 있었습니다. 그런데 현장에서는 작업자들이 그 AI를 잘 안 썼습니다. 이유를 물어보니 답은 단순했습니다. "판정 뜨는 데 3초씩 걸려요. 컨베이어는 기다려주지 않거든요."

현장의 시간은 개발자의 시간과 다릅니다. 노트북에서 3초는 "금방"이지만, 분당 수십 개가 지나가는 라인에서는 3초가 곧 병목입니다. 작업자는 AI 판정을 기다리느라 라인을 세울 수 없으니, 결국 자기 눈으로 보고 넘깁니다. 모델이 아무리 정확해도, 현장의 속도 안에 들어오지 못하면 없는 거나 마찬가지입니다.

2. '지연 예산'을 먼저 정하는 법

그래서 현장 AI를 설계할 때는 정확도보다 먼저 '지연 예산'을 정합니다. 판정이 나오는 데 쓸 수 있는 시간을 공정 단위로 끊어보는 겁니다. 예를 들어 검사 공정이 개당 1.2초 주기로 돌아간다면, AI 판정에는 넉넉잡아 0.8초까지만 줄 수 있습니다. 나머지는 카메라 노출, 이미지 전송, 판정 표시 같은 주변 시간이 가져가니까요.

이 예산이 정해지면 모델 선택 기준이 달라집니다. "가장 정확한 모델"이 아니라 "예산 안에 들어오는 가장 정확한 모델"을 고릅니다. 큰 모델을 억지로 쓰는 대신 작은 모델로 바꾸거나, 입력 이미지를 줄이거나, 판정 로직을 가볍게 만드는 결정이 여기서 나옵니다. 11월 5일 글에서 다룬 경량화·온디바이스 전환도 결국 같은 얘기입니다. 작아지는 게 목적이 아니라, 현장의 시간 안에 들어가는 게 목적입니다.

3. 느려질 때를 대비한 3단계 설계

예산 안에 들어가는 모델을 골랐다고 끝이 아닙니다. 현장은 변합니다. 조명이 바뀌고, 먼지가 쌓이고, 네트워크가 흔들립니다. 그래서 저는 지연이 예산을 넘을 때를 미리 설계합니다. 첫째, 판정이 늦어지면 "판정 보류"가 아니라 "이전 판정 유지 + 경고 표시"로 떨어지게 합니다. 라인을 세우지 않고, 작업자가 눈으로 확인할 수 있게 알리는 겁니다. 둘째, 지연이 반복되면 자동으로 가벼운 모드로 전환합니다. 정밀 검사는 잠시 접고, "명백한 불량만 거른다"는 식으로요. 셋째, 지연 기록을 남깁니다. 언제, 어느 공정에서, 얼마나 늦었는지. 이 기록이 다음 모델 교체 때 가장 먼저 보는 자료가 됩니다.

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

현장 AI를 도입하거나 고를 때, 정확도 숫자 옆에 "판정까지 몇 초?"를 꼭 물어보세요. 그리고 그 숫자가 내 공정의 주기 안에 들어가는지 직접 확인하세요. 모델이 똑똑한 것보다, 현장의 속도에 맞춰 제때 답하는 것이 먼저입니다. 7년차 현장 엔지니어로서, AI가 현장에서 살아남는 조건은 정확도가 아니라 "제때"라는 걸 다시 한 번 적어둡니다.

관련 글:

정확도 99%가 현장에서 쓸모없을 수 있다 — AI 모델 평가를 현장 지표로 바꾸는 법

경량화·온디바이스 전환

확신도 활용법

"우리 라인 가동률 85%예요." 현장에서 흔히 듣는 말이다. 그런데 트윈 대시보드에 같은 숫자를 올려놓고 보면, 뭔가 이상하다. 설비는 돌아가는데 불량이 많고, 속도는 느린데 가동률만 높게 찍힌다. 숫자 하나만 보고 "잘 돌아가네" 하고 넘어가면, 정작 고쳐야 할 곳을 놓친다.

7년차 현장 엔지니어로서, 가동률은 숫자 하나가 아니라 세 개의 숫자를 곱한 결과라고 보는 게 맞다고 생각한다. 오늘은 OEE(설비종합효율)를 디지털트윈에 제대로 올리는 법을 정리한다.

1. OEE는 곱셈이다 — 가동률 × 성능률 × 품질률

OEE는 세 가지 비율을 곱해서 만든다. 가동률은 계획된 시간 중 실제로 설비가 돌아간 비율, 성능률은 정해진 속도로 뽑았는지, 품질률은 만든 것 중 쓸 만한 것이 몇 개인지다. 세 개가 각각 90%면 곱하면 73%다. "90%씩 잘하고 있는데"라는 느낌과 실제 73% 사이의 간극, 그게 OEE를 보는 이유다.

현장에서 흔한 실수는 이 셋을 섞어서 보는 것이다. 설비가 멈춘 시간을 줄였는데도 OEE가 안 오르면, 문제는 가동이 아니라 성능이나 품질 쪽에 있다는 뜻이다. 반대로 불량이 줄었는데도 OEE가 제자리면, 멈춤 시간이 발목을 잡고 있는 거다. 트윈에 올릴 때도 마찬가지다. 세 숫자를 따로 보여줘야, 어디를 건드려야 할지 보인다.

세 요소는 이렇게 잰다. 가동률은 계획 시간 대비 실제 가동 시간으로, 트윈에서는 고장·교체·대기로 멈춘 시간으로 확인한다. 성능률은 정해진 속도 대비 실제 속도로, 미세 정지·속도 저하 구간으로 확인한다. 품질률은 생산 수량 대비 양품 수량으로, 불량 발생 시점·설비 조건으로 확인한다.

이 구분이 트윈 설계의 출발점이다. 세 요소마다 필요한 데이터가 다르고, 데이터가 오는 곳도 다르다. 가동률은 설비 상태 신호에서, 성능률은 생산 카운터에서, 품질률은 검사 결과에서 온다. 한 대시보드에 숫자 하나만 띄우면, 이 차이는 통째로 사라진다.

2. 트윈에 올릴 때 가장 먼저 틀리는 것 — '시간'의 기준

OEE를 트윈에 올릴 때 현장에서 가장 많이 틀리는 건 시간의 기준이다. 계획 가동 시간에서 뭘 빼고 뭘 넣느냐에 따라 같은 설비도 가동률이 달라진다. 계획 정지(예방 정비, 교대 준비)를 빼는지, 넣는지. 점심시간을 계획 시간에 포함하는지. 이 기준이 설비마다, 라인마다 다르면 트윈의 숫자는 비교 자체가 안 된다.

그래서 내가 현장에서 먼저 정하는 건 '시간 분류표'다. 계획 시간, 계획 정지, 비계획 정지, 미세 정지, 속도 저하, 불량 생산 — 이 여섯 칸을 먼저 정의하고, 각 칸에 들어갈 신호를 정한다. 예를 들어 설비 상태 신호가 '정지'인데 작업자가 교체를 하고 있으면 계획 정지, 원인을 모르고 멈춰 있으면 비계획 정지다. 이 분류가 없으면 트윈은 멈춘 시간만 세고, 왜 멈췄는지는 말해주지 않는다.

또 하나, 속도의 기준이다. 성능률은 '정해진 속도' 대비 실적이다. 그런데 정해진 속도가 설비 스펙표의 최대 속도면, 현실적인 성능률은 영원히 낮게 나온다. 현장에서 실제로 유지 가능한 속도를 기준 속도로 정하고, 트윈에도 그 기준을 명시해두는 게 맞다. 기준이 바뀌면 과거 숫자와 비교가 안 되니, 기준을 바꿀 때는 날짜를 남긴다.

3. 숫자가 아니라 '어디서 잃는가'를 보여주는 화면

OEE를 트윈에 올리는 목적은 숫자를 예쁘게 보는 게 아니다. 잃는 시간을 어디서 잃는지 찾아내는 것이다. 가동·성능·품질 중 어느 요소가 가장 많이 깎아먹는지, 그게 어느 설비에서, 어느 시간대에 일어나는지를 보여주는 화면이 되어야 한다.

현장에서 내가 쓰는 방식은 단순하다. 트윈 화면에 OEE 숫자 하나와, 그 아래에 세 요소의 '손실 시간'을 막대로 나란히 보여준다. 이번 주에 가장 큰 손실이 미세 정지에서 나왔으면, 그 구간을 눌렀을 때 어떤 설비에서 몇 분씩 멈췄는지까지 내려가 볼 수 있게 한다. 숫자를 보는 사람(관리자)과 고치는 사람(현장 엔지니어)이 같은 화면을 보고, 같은 손실을 가리킬 수 있어야 한다.

이렇게까지 하면 OEE는 보고용 지표가 아니라 현장 운영 도구가 된다. "가동률 85%"라는 말 대신, "이번 주는 미세 정지로 6시간, 속도 저하로 4시간을 잃었다"는 말이 나온다. 그 다음 회의에서는 뭘 고칠지, 그걸 정하는 데 시간이 훨씬 덜 든다.

마무리 — OEE는 대시보드가 아니라 '공통 언어'다

디지털트윈에 OEE를 올릴 때 목표는 숫자를 높이는 게 아니다. 현장과 관리자가 같은 숫자를 보고 같은 문제를 가리키는 것, 그게 먼저다. 기준 시간을 정하고, 세 요소를 따로 재고, 어디서 잃는지 보여주는 화면 — 이 세 가지만 갖추면 트윈의 OEE는 비로소 현장 말이 된다.

오늘 할 일은 세 가지다. 첫째, 우리 라인의 시간 분류표(계획 정지·비계획 정지·미세 정지)를 한 장으로 적어본다. 둘째, 가동·성능·품질 세 숫자가 각각 어디서 오는지 데이터 출처를 확인한다. 셋째, 트윈 화면에 OEE 숫자 아래 손실 시간을 나란히 띄울 수 있는지 본다. 거창한 시스템부터 바꿀 필요는 없다. 기준·출처·화면, 이 세 가지만 정리해도 트윈의 가동률은 현장에서 쓸 수 있는 숫자가 된다.

관련 글:

디지털트윈의 진짜 엔진은 3D가 아니라 '데이터 수집'이다

디지털트윈이 '실시간'이 되는 조건 — 샘플링·지연시간·동기화 설계하기

트윈 대시보드는 예쁜데 현장에서 안 본다 — 운영자가 실제로 보는 화면 설계 3원칙

7년차 현장 엔지니어로서, 불량 검출 AI를 현장에 붙여본 경험이 있다. 정확도는 99%였는데, 작업자들이 한 달 만에 AI 판정을 안 믿기 시작했다. 이유를 물어보니 답이 한결같았다. "AI가 불량이라는데, 어디가 어떻게 불량인지 모르겠어요."

정확도가 문제가 아니었다. 설명이 문제였다.

설명 없는 판정은 현장에서 '판정'이 아니다

현장에서는 판정이 곧 행동이다. 불량 판정이 나오면 라인을 세울지, 재검사를 할지, 그냥 흘려보낼지 누군가 결정해야 한다. 그런데 AI가 "불량 확률 97%"만 내놓으면, 그 결정을 내릴 근거가 없다. 작업자는 자기 손으로 다시 확인하고, 결국 AI를 거치지 않고 눈으로 검사한다. 그러면 AI는 장식품이 된다.

모델 평가를 현장 지표로 바꿔야 한다는 얘기를 지난 글에서 했다. 설명 가능성도 같은 맥락이다. 실험실에서는 정확도가 답이지만, 현장에서는 "왜"가 답이다.

현장에서 통하는 설명 3가지 형태

첫째, 위치를 짚어주는 설명이다. "이 부품의 왼쪽 모서리 3mm 지점에서 스크래치가 검출됐습니다"처럼, 불량의 위치를 이미지 위에 표시하는 방식이다. 작업자는 판정문을 읽지 않아도 화면만 보고 바로 알 수 있다.

둘째, 근거를 숫자로 보여주는 설명이다. 어떤 특징 때문에 불량으로 봤는지, 그 특징이 정상 범위를 얼마나 벗어났는지 보여준다. "표면 거칠기 기준 0.8인데 측정값 1.4" 같은 식이다. 현장 사람들은 추상적인 확률보다 기준 대비 실측값을 훨씬 신뢰한다.

셋째, 비슷한 과거 사례를 보여주는 설명이다. "지난달 같은 불량 12건 중 11건이 같은 위치에서 나왔다"는 말 한 줄이면, 작업자는 자기 경험과 연결해서 판단한다. AI의 판정이 '처음 보는 얘기'가 아니라 '아는 얘기'가 되는 순간이다.

이 세 가지를 모두 구현할 필요는 없다. 우리 현장에서는 위치 표시 하나만으로 작업자들의 신뢰가 달라졌다.

설명을 설계할 때 빠지는 함정

설명 가능성을 나중에 붙이려고 하면 실패한다. 모델을 다 만들고 나서 "설명 기능도 달자" 하면, 모델 내부가 블랙박스라 설명할 재료 자체가 없다. 설명은 모델 설계 단계에서 같이 정해야 한다. 어떤 설명을 보여줄지 먼저 정하고, 그 설명을 만들 수 있는 모델 구조와 데이터를 고르는 순서다.

또 하나, 설명이 너무 길면 안 된다. 현장에서는 판정 후 5초 안에 다음 행동을 정한다. 설명이 보고서 한 장이면 아무도 안 읽는다. 한 화면, 세 줄 이내가 기준이다. 자세한 분석은 나중에 볼 수 있게 로그로 남겨두고, 현장 화면에는 결론과 근거 한 줄만 둔다.

그래서 뭘 하면 되나 — 지금 쓰는 불량 검출 AI가 있다면, 작업자에게 "AI 판정을 믿고 라인을 세운 적 있나" 물어보라. 답이 "아니요, 다시 확인해요"라면 정확도가 아니라 설명이 부족한 거다. 위치 표시부터 달아보자. 그 한 줄이 AI를 장식품에서 도구로 바꾼다.

이전 글:

정확도 99%가 현장에서 쓸모없을 수 있다 — AI 모델 평가를 현장 지표로 바꾸는 법

검증 통과한 AI가 한 달 만에 틀리기 시작했다 — 제조 현장의 데이터 드리프트와 재학습 루프

불량 데이터가 없어서 못 만드는 제조 AI — 합성 데이터로 훈련하는 법

오늘(2026년 11월 6일) 아침, 로봇 업계 뉴스가 하나 눈에 띄었습니다. 유진로봇·뉴로메카·나우로보틱스가 일제히 '팔 달린 AMR', 즉 모바일 매니퓰레이터(AMMR) 경쟁에 뛰어들었다는 소식입니다. 정부가 2030년까지 2조 3,000억 원을 들여 국산 휴머노이드 1,080대를 구매하기로 하면서, '지정된 경로로 자재만 나르던' 이동형 로봇이 피킹·분류·포장까지 하는 복합 작업 로봇으로 바뀌는 경쟁이 본격화됐습니다. (출처: 이비엔(EBN), 2026-11-06 06:00, 이수진 기자)

휴머노이드 얘기가 나오면 으레 두 발로 걷는 로봇을 떠올리지만, 공장에 먼저 들어오는 건 바퀴 달린 형태일 가능성이 큽니다. 왜 그런지, 오늘 뉴스를 현장 관점으로 풀어봅니다.

왜 하필 '팔 달린 AMR'인가

핵심은 이미 검증된 것을 버리지 않는다는 데 있습니다. 유진로봇은 자사의 AMR 플랫폼 '고카트(GoCart) 180~1500'에 타사의 로봇팔과 비전 센서를 얹어 현장 맞춤형 휴머노이드를 만드는 전략입니다. 특정 하드웨어에 종속되지 않고 AMR·자동화 설비·소프트웨어를 묶은 토털 솔루션으로 팔겠다는 구상이고, 한국산업기술기획평가원(KEIT) 주관 국책과제를 통해 실제 물류센터에서 피킹·분류·적입·검사 실증에 들어갑니다.

나우로보틱스도 같은 방향입니다. 2017년 7억 원 수준이던 매출이 올해 123억 원 규모로 커질 전망이고, 내포첨단산업단지에 1만 6,529㎡ 로봇 제조센터를 새로 지었습니다. 과학기술정보통신부 주관 신규 과제로 24억 원의 사업비를 확보해 내년 12월까지 자사 이동 플랫폼에 양팔 로봇을 결합한 AMMR을 시연할 계획입니다. 국산 신경망처리장치(NPU)와 시각·언어·행동(VLA) 모델을 접목하고, 감속기·액추에이터 특허 5건으로 핵심 부품 내재화까지 마쳤다고 합니다.

업계 관계자의 한 마디가 이 전략을 잘 요약합니다. "이족보행 로봇은 서 있을 때도 밸런스 유지를 위해 배터리를 계속 소모하지만, 휠 기반 로봇은 전원을 꺼도 자세 유지가 가능하다. 잘 정비돼 있는 제조 환경에서는 굳이 두 발로 다니며 일할 이유가 없다." 공장은 사람이 일하기 편하게 설계된 공간이고, 그 공간에서 가장 실용적인 이동 방식은 바퀴라는 얘기입니다.

뉴로메카 '두뇌'의 승부수 — PSF와 제로샷

하드웨어가 '팔'이라면, 승부는 '두뇌'에서 갈립니다. 뉴로메카는 기존 모방 학습 방식의 한계를 넘겠다며 독자 피지컬 AI 플랫폼 '피지컬 스킬 파운데이션(PSF)'을 내놨습니다. 시나리오 기반 엔드 투 엔드 방식은 작업 성공률이 95% 수준에 머물고, 완벽한 구현에는 10만 년 분량의 데이터가 필요하다는 맹점이 있었는데, 인지(Perception)·생성(Generative)·반사(Reflex) 단계를 거치는 '파이프 모듈' 형식으로 이를 풀겠다는 겁니다.

결과물인 이동형 휴머노이드 '나미(NAMI)'는 4륜 캐스터 기반 휴머노이드 '에이르(EIR)'와 AMR 플랫폼 '모비(MOBY)'를 결합해 8~12시간 연속 작업이 가능합니다. VLA 모델이 탑재된 PSF 덕분에 별도 코딩 없이 자연어 스크립트나 이미지만으로 대상물 위치를 추정해, 제로샷으로 집기·조립·뚜껑 열기 같은 과업을 수행한다고 합니다. 황성훈 뉴로메카 로봇플랫폼사업본부 본부장은 "실제 사람한테 가르치듯이 명령을 내릴 수 있다"며 "기존 룰 베이스 기반과는 전혀 다른 패러다임"이라고 했습니다.

말만 번지르르한 게 아니라, 이미 현장에 들어가 있습니다. 에스엘(SL)의 인쇄회로기판(PCB) 가공, 아진산업의 자동차 외장 부품 조립, 화신정공의 물류 운송 현장에 양팔 휴머노이드 로봇을 직접 배치해 실증(PoC) 중이고, 내년 양산 라인 도입이 목표입니다.

현장에서 먼저 확인할 것

7년차 현장 엔지니어로서 한 줄로 정리하면, 로봇이 공장에 들어오는 기준은 '얼마나 사람 같냐'가 아니라 '밤새 멈추지 않고 몇 시간 일하냐'입니다. 두 발이 아니라 바퀴를 택한 것도, 자연어로 가르치는 방식을 택한 것도, 결국은 같은 기준에서 나온 선택입니다. 멈추지 않고, 가르치기 쉽고, 실패했을 때 다시 세우기 쉬운 로봇이 먼저 살아남습니다.

그래서 뭘 하면 되나 — AMMR 도입을 검토한다면 스펙표의 자유도나 속도를 보기 전에 이 세 가지를 먼저 물어보세요. 첫째, 연속 가동 시간은 몇 시간인가. 둘째, 새 작업을 가르칠 때 코딩이 필요한가, 아니면 말과 사진으로 되는가. 셋째, 실패했을 때 누가, 얼마나 빨리 복원하는가.

정부가 1,080대 구매로 수요를 만들었습니다. 이제 현장이 준비할 건 '사는 것'이 아니라 '돌리는 것'입니다. 팔 달린 AMR이 공장에 먼저 들어오는 이유를, 도입 검토표의 첫 줄에 적어두면 좋겠습니다.

출처: 이비엔(EBN) "유진로봇은 '팔'·뉴로메카는 '두뇌'…차세대 물류로봇 시장 선점 경쟁", 2026-11-06 06:00, 이수진 기자

관련 글:

LG 클로이드 美·韓 공장 실전 검증 — 피지컬 AI의 시험대는 결국 공장 바닥이다

테슬라 옵티머스 3세대 양산 준비 — 휴머노이드 대전, 이제 '공장 입증'이 남았다

ROKAE 휴머노이드 힘제어 암 1만 대 출하 — 로봇이 '힘을 아는' 시대가 왔다