협동로봇이 사람 옆에서 일하는 시대다. 안전펜스 없이 작업자와 같은 공간에서 움직이니, 안전 검증은 설치가 끝나고 현장에서 하는 게 아니라 설치 전에 끝나야 한다. 로봇을 직접 움직이며 사람이 옆에서 테스트하면, 사람도 설비도 위험하다. 그래서 나는 안전 검증을 디지털트윈에서 먼저 한다.
협동로봇 안전의 기준은 '속도와 힘'
협동로봇 안전의 핵심은 ISO/TS 15066이 정한 접촉 시 허용 힘과 압력, 그리고 속도와 분리 거리 모니터링이다. 스펙표의 최대 속도가 중요한 게 아니다. 작업자와 닿았을 때 실제로 얼마나 세게 닿는지가 기준이다.
현장에서 진짜 위험한 지점은 로봇이 가장 빨리 움직이는 곳이 아니라, 작업자 동선과 로봇 궤적이 겹치는 곳이다. 부품을 건네받는 지점, 작업자가 몸을 숙여 들어가는 구간, 로봇이 방향을 바꾸는 모서리. 이런 지점은 도면만 봐서는 잘 안 보인다. 트윈에 작업자 동선을 함께 올려야 보인다.
디지털트윈에서 검증하는 3가지
첫째, 궤적과 동선 시뮬레이션이다. 작업자의 이동 경로를 모델에 넣고 로봇 궤적과 겹치는 지점을 찾는다. 겹치는 지점이 나오면 그 지점의 접근 속도부터 낮춘다.
둘째, 속도·힘 제한 검증이다. 제한값을 바꿔가며 접촉 시나리오를 돌려본다. 같은 궤적이라도 속도를 250mm/s에서 150mm/s로 낮추면 접촉 시 충격이 얼마나 줄어드는지 숫자로 확인된다. 감으로 정하던 제한값이 근거를 갖게 된다.
셋째, 비상정지와 복귀 시나리오다. 비상정지를 눌렀을 때 로봇이 어디서 멈추는지, 재가동할 때 어떤 경로로 복귀하는지까지 미리 확인한다. 정지 자체보다 복귀 과정이 더 위험한 경우가 많다.
현장에 가져갈 때 체크리스트
트윈에서 확인한 제한값은 실제 컨트롤러 설정과 반드시 대조한다. 시뮬레이션 값과 현장 설정값이 다르면 검증은 무용지물이다. 첫 가동은 저속 모드로, 사람이 없는 시간대에 한다. 그리고 검증 결과는 기록으로 남긴다. 다음에 라인을 바꾸거나 로봇을 교체할 때 같은 검증을 처음부터 다시 하지 않아도 된다.
그래서 뭘 하면 되나. 협동로봇을 새로 들일 때, 설치 일정에 '트윈 안전 검증 1일'을 먼저 넣어보자. 로봇이 도착하기 전에 궤적과 동선, 제한값을 가상으로 돌려보는 하루다. 현장에서 사람을 세워두고 테스트하는 것보다 훨씬 싸고, 훨씬 안전하다.
안전은 감이 아니라 검증의 문제다. 디지털트윈은 로봇을 안전하게 현장에 들이는 가장 싼 방법이다.
관련 글: 디지털트윈 데이터 수집(https://developer-archive.tistory.com/124), 디지털트윈 실시간 조건(https://developer-archive.tistory.com/132)
주말 새벽 2시, 전화가 울린다. "라인이 멈췄어요." 현장에 가려면 한 시간은 걸리는데, 전화기 너머 목소리는 당장 뭘 해야 할지 묻고 있다. 7년 전 처음 이런 전화를 받았을 때는 나도 당황해서 "일단 리셋 눌러보세요"라고 했다. 그날 배웠다. 현장에 없는 사람의 첫 마디가, 그날 밤의 복구 시간을 정한다.
1. 먼저 묻는 건 "뭐가 멈췄나"가 아니다
전화를 받으면 가장 먼저 확인하는 건 세 가지다. 다친 사람은 없는지, 안전 인터록이 걸린 상태인지, 그리고 지금 라인이 "멈춘 상태"인지 "멈추는 중"인지다. 설비가 멈췄다고 다 같은 멈춤이 아니다. 정상 정지인지, 비상 정지인지, 알람이 뜬 채 멈춘 건지부터 가른다. 이걸 안 묻고 "뭐가 고장 났어요?"부터 물으면, 현장 사람은 고장 원인을 추측하느라 시간을 쓴다. 원인은 나중에 찾으면 된다. 지금 필요한 건 상태 정보다.
두 번째로 묻는 건 "마지막으로 정상이었던 게 언제냐"다. 방금 전까지 돌아가던 라인과 한 시간 전부터 이상했던 라인은 대응이 다르다. "10분 전까진 정상이었어요"라는 말 한마디면, 그 10분 사이에 일어난 변화부터 좁힐 수 있다. 바꾼 설정, 교체한 자재, 새로 들어온 작업자 — 변한 게 뭔지부터 찾는다.
2. 전화로 지시할 수 있는 건 딱 세 가지뿐이다
현장에 없는 내가 전화로 시킬 수 있는 일은 많지 않다. 그래서 순서가 정해져 있다.
첫째, 멈춘 순간의 데이터를 남기게 한다. 알람 화면 사진, 트윈 대시보드 캡처, 로그 화면 — 찍을 수 있는 건 다 찍어두라고 한다. 리셋을 누르기 전에, 전원을 껐다 켜기 전에. 증거는 그 순간에만 있다. 현장에 도착하면 이미 사라져 있는 정보가 대부분이다.
둘째, 무리하게 다시 돌리지 말라고 한다. 멈춘 설비를 "한 번만 더" 돌려보는 건, 고장 원인을 더 키우는 지름길이다. 특히 소리가 났거나, 냄새가 나거나, 진동이 느껴졌다면 재가동은 금지다. 밤에 라인을 세우는 건 아프지만, 설비를 망가뜨리는 것보다 싸다.
셋째, 내가 도착하기 전까지 현장 사람이 할 수 있는 "확인만 하는 일"을 정해준다. 육안 점검, 케이블·커넥터 흔들림 확인, 에어 압력 게이지 읽기. 만지지 않고 보는 일까지만. 손을 대는 작업은 내가 가서, 상태를 보고 결정한다.
3. 가는 길에 하는 일 — 전화가 아니라 "준비"다
현장까지 가는 한 시간은 그냥 이동 시간이 아니다. 차 안에서는 세 가지를 한다. 첫째, 멈추기 전 로그를 원격으로 확인한다. 디지털트윈에 접속해 멈추기 직전 30분의 데이터를 본다. 진동·온도·전류 중 어느 값이 먼저 튀었는지. 둘째, 비슷한 고장의 과거 기록을 찾는다. 인수인계 메모, 예전 장애 기록 — 같은 설비, 같은 알람이 전에 있었는지. 셋째, 필요한 부품과 공구를 미리 챙긴다. 현장에 도착해서 "아, 그 공구가 없네" 하고 다시 돌아오는 게 가장 바보 같은 시간 낭비다.
현장 엔지니어의 실력은 고치는 속도보다, 도착하기 전에 얼마나 좁혀놓느냐에서 갈린다. 전화 한 통, 가는 길 한 시간 — 이 시간에 이미 절반은 풀려 있어야 한다.
마무리 — 전화 받는 사람이 곧 "현장"이다
현장에 없다는 건 변명이 안 된다. 전화기 너머의 내 말이 곧 현장의 판단이 되니까. 그래서 나는 전화를 받을 때마다 같은 순서를 지킨다. 안전 확인, 상태 확인, 데이터 남기기, 그리고 "다시 돌리지 말 것". 이 네 가지만 지켜도, 주말 새벽의 고장은 "복구"로 끝나지 "사고"로 번지지 않는다.
현장 AI가 아무리 똑똑해져도, 새벽 2시 전화를 받는 건 결국 사람이다. 그 전화 한 통의 품질을 높이는 게, 7년차 엔지니어의 진짜 일이라고 생각한다.
관련 글: #130 설비 알람 로그 설계, #135 장애 대응 루틴, #156 야간 무인 운전 전 확인 5가지
현장 AI를 돌리다 보면 언젠가 꼭 듣는 말이 있다. "AI가 틀렸어요." 불량 판정이 잘못됐다, 경보가 엉뚱한 데서 울렸다, 로봇이 가면 안 되는 곳으로 갔다. 보고를 받는 순간 머릿속이 바빠진다. 모델 문제인가, 데이터 문제인가, 설비 문제인가. 그런데 7년차 현장 엔지니어로서 먼저 하는 일은 원인을 찾는 게 아니다. 보고 자체를 정리하는 것부터 시작한다. 틀렸다는 보고가 들어왔을 때의 첫 대응이, 그 뒤의 수습 시간을 결정하기 때문이다.
1. "틀렸다"는 말부터 번역한다 — 뭐가, 어떻게 틀렸는지
"AI가 틀렸어요"라는 말만으로는 아무것도 할 수 없다. 어떤 판정이, 어떤 값으로, 어떻게 틀렸는지를 먼저 물어야 한다. 불량이라고 찍은 게 사실은 양품이었는지, 정상이라고 한 게 불량이었는지부터 다르다. 전자는 과검출, 후자는 미검출이다. 과검출은 생산을 멈추게 하고, 미검출은 불량을 흘려보낸다. 대응의 방향이 정반대다.
그래서 보고를 받으면 가장 먼저 세 가지를 적는다. 언제, 어떤 설비에서, AI가 무슨 판정을 내렸는지. 그리고 현장에서 실제로 무엇이 확인됐는지. 이 네 줄이 없으면, 같은 사건을 놓고도 사람마다 다른 얘기를 한다. "어제 오후쯤, 3번 라인에서" 같은 말은 기록이 아니다. 시간·설비·판정·실측, 이 네 가지를 적는 데 1분이면 된다. 7년차 현장 엔지니어로서 한 줄로 정리하면, 오탐 대응은 모델을 고치는 일이 아니라 보고를 "수습할 수 있는 사실"로 바꾸는 일부터 시작한다.
2. 모델을 의심하기 전에 입력과 현장을 먼저 본다
보고가 정리되면, 그다음으로 보는 건 모델이 아니라 모델이 본 것이다. AI가 틀렸다고 해서 모델이 틀린 건 아니다. 현장에서 AI가 틀리는 경우, 의외로 많은 원인이 입력 쪽에 있다. 센서에 이물질이 붙어 값이 튀었거나, 조명이 바뀌어 카메라 이미지가 달라졌거나, 설비 교체 뒤 기준값이 그대로 남아 있는 경우다. 모델은 달라진 입력을 보고 성실하게 틀린 답을 낸 것뿐이다.
그래서 확인 순서는 정해져 있다. 먼저 그 시간의 입력 데이터를 본다. 센서 값, 이미지, 로그를 그 시간대로 잘라서 본다. 입력이 평소와 다르면, 그건 모델 문제가 아니라 현장 문제다. 입력이 멀쩡한데 답이 틀렸다면, 그제야 모델을 본다. 최근에 재학습했는지, 임계값이 바뀌었는지, 배포된 버전이 무엇인지. 이 순서를 지키면 "모델이 문제다"라는 성급한 결론을 피할 수 있다. 모델부터 뜯는 팀은 원인을 찾기도 전에 라인을 세운다.
3. 임시 조치를 먼저 정하고, 원인 분석은 그다음
원인이 보이기 시작하면, 사람들이 흔히 하는 실수가 있다. 원인을 끝까지 파고들려고 하는 것이다. 그런데 현장에서는 원인 분석보다 임시 조치가 먼저다. 오탐이 계속 나오면 생산이 멈추거나 불량이 흐른다. 그걸 막는 조치를 먼저 정해야 한다. 해당 판정을 일시적으로 수동 확인으로 바꾸는지, 임계값을 잠깐 되돌리는지, 특정 설비만 AI 판정에서 빼는지. 조치는 작아도 된다. 중요한 건 "지금 이 순간부터는 틀린 판정이 나가지 않는다"는 상태를 만드는 것이다.
임시 조치가 정해지면, 그제야 원인 분석을 한다. 분석은 기록과 함께 한다. 언제, 무슨 조치를 했고, 원인은 무엇으로 보이며, 재발을 막으려면 무엇을 바꿔야 하는지. 이 기록이 다음에 같은 보고가 왔을 때의 첫 페이지가 된다. 오탐 대응 루틴이 쌓이면, "AI가 틀렸어요"라는 보고는 당황할 일이 아니라 정해진 순서대로 처리하는 일이 된다.
그래서 뭘 하면 되나
AI가 틀렸다는 보고가 오면, 세 가지만 순서대로 하면 된다. 보고를 사실로 번역하고, 모델보다 입력과 현장을 먼저 보고, 원인 분석 전에 임시 조치부터 정하는 것. 이 세 가지를 적어둔 한 장의 대응표만 있어도, 야간에 보고를 받은 사람도 당황하지 않고 움직일 수 있다. 현장 AI의 신뢰는 틀리지 않는 데서 오는 게 아니라, 틀렸을 때 어떻게 수습하는지에서 쌓인다.
관련 글: 장애 대응 루틴(https://developer-archive.tistory.com/135), 설비 알람 로그 설계(https://developer-archive.tistory.com/130), AI 모델 평가를 현장 지표로(https://developer-archive.tistory.com/164), 모델·데이터·프롬프트 3축 버전 관리(https://developer-archive.tistory.com/155), 현장 AI의 운영 범위 설계법(https://developer-archive.tistory.com/233)
출처: ASUS 프레스룸 "Factory-Proven Physical AI: Why ASUS Is Building a Humanoid Robot" (2026-11-13), Pivot News "Agile Robots says SoftBank led $500M round at $8.5B" (2026-11-13)
오늘 ASUS가 자사 첫 휴머노이드 로봇 '갤럽(Gallop)'을 공개했습니다. 그런데 이 소식에서 진짜로 봐야 할 건 로봇의 스펙이 아닙니다. 갤럽이 일하는 자리가 어디냐는 겁니다. 전시회 무대가 아니라, ASUS 그룹 자사 EMS 공장의 메인보드 액세서리 포장 스테이션. 피지컬 AI의 경쟁이 '만드는 것'에서 '공장에서 증명하는 것'으로 넘어가고 있다는, 가장 솔직한 신호입니다.
15개 부품, 20초 — 숫자가 말해주는 것
갤럽의 첫 임무는 메인보드 액세서리 포장입니다. 부품 15개, 그중 다수는 얇은 투명 비닐봉지에 든 작은 것들, 보드당 약 20초. 언뜻 단순해 보이지만 현장에서 일해본 사람은 압니다. 투명한 비닐은 카메라가 가장 헷갈려하는 대상이고, 작은 부품을 20초 안에 빠짐없이, 품질 기준을 지키며 포장하는 건 '쉬운 일'이 아닙니다.
그래서 ASUS가 내세운 방식이 눈에 띕니다. 갤럽은 숙련 작업자가 일하는 모습을 보고 배우고, 같은 부품으로 같은 자리에서 연습합니다. 로봇 한 대 안에 엔비디아 젯슨 AGX 토르 컴퓨터 한 대로 전부 돌아간다는 점도 현장 관점에선 중요합니다. 클라우드에 기대지 않고 현장에서 바로 판단한다는 뜻이니까요. 모듈러 설계라 AI 모델이 좋아지면 로봇을 새로 만들지 않고 모델만 갈아 끼울 수 있다는 점도, 현장 운영자에게는 유지보수 비용 얘기입니다.
왜 지금 '공장 검증'이 화두인가
오늘 하루만 봐도 흐름이 분명합니다. 국내에서는 티로보틱스가 KAIST 제조피지컬AI연구소와 피지컬 AI 사업화 MOU를 맺었고(이투데이, 2026-11-13), 독일 휴머노이드 기업 애자일 로보츠는 소프트뱅크 주도로 5억 달러 투자를 유치했습니다(Pivot News, 2026-11-13). 대학·연구소·자본이 모두 같은 방향을 보고 있습니다. "로봇을 만들었다"가 아니라 "공장에서 굴려서 증명했다"로요.
ASUS의 일정도 그래서 솔직합니다. 고객 파일럿은 2027년, 시장 출시는 2028년 하반기 목표. 당장 팔겠다는 얘기가 아니라, 1년 넘게 자기 공장에서 검증하겠다는 얘기입니다. 피지컬 AI 뉴스를 볼 때 저는 이 '일정'을 먼저 봅니다. 출시일을 앞당기는 회사보다, 검증 기간을 숨기지 않는 회사가 현장에서는 오래 갑니다.
7년차 현장 관점에서 보는 갤럽의 진짜 시험
포장 스테이션에서 갤럽이 버티는지가 이 로봇의 성적표입니다. 시연 영상에서는 안 보이던 것들이 현장에서는 다 드러나거든요. 비닐이 빛에 반사돼 부품을 못 잡는 날, 전날과 다른 로트의 부품이 들어온 날, 앞 공정에서 불량이 흘러들어온 날. 로봇이 '배웠다'는 건 이런 날에도 20초를 지키느냐로 판가름 납니다.
그래서 뭘 하면 되나 — 휴머노이드를 검토하는 현장이라면, 로봇 카탈로그부터 보지 말고 자기 공장의 작업 하나를 20초 단위로 쪼개보는 것부터입니다. 그 작업을 숙련자가 어떻게 하는지, 손동작이 데이터로 남아 있는지를 먼저 확인하는 겁니다. 갤럽이 보여준 건 로봇의 미래가 아니라, 검증의 순서입니다. 현장에서 증명된 로봇만, 다음 공장으로 갈 수 있습니다.
관련 글: 현장 AI 운영 노트 EP.11 — 도입 검토 단계부터 '운영'을 설계하는 법(https://developer-archive.tistory.com/233), 현장 AI 운영 노트 EP.12 — 운영 노트를 여러 라인으로 넓힐 때, 기준을 맞추는 3가지 방법(https://developer-archive.tistory.com/238)
운영 대시보드가 "오늘 어디부터 볼지"를 정해준다면, 분기 리뷰는 "이대로 가도 되는지"를 묻는 자리다. 한 달 단위 리뷰는 경보 루틴을 숫자로 돌아보는 일이었고, 분기 리뷰는 한 단계 위에서 본다. 경보가 줄었는지, 모델이 현장에 잘 붙어 있는지, 사람이 지치지 않고 돌리고 있는지를 같이 보는 것이다. 분기 리뷰가 없는 현장은, 매일은 바쁜데 분기가 지나도 뭐가 나아졌는지 모른다. 그래서 분기마다 한 번, 운영 노트를 펼쳐놓고 세 가지를 같이 본다.
분기 리뷰에서 가장 먼저 보는 건 경보 건수다. 그런데 건수 자체보다 중요한 건 흐름이다. 이번 분기 경보가 지난 분기보다 줄었는지, 같은 경보가 반복되는지, 대응 시간이 길어지는 경보가 어떤 종류인지를 본다.
같은 경보가 분기 내내 반복된다면, 그건 경보가 아니라 "고쳐지지 않은 문제"다. 임계값을 손보는 걸로 끝낼 일이 아니라, 센서 위치나 설비 상태 자체를 봐야 할 신호다. 반대로 대응 시간이 분기마다 조금씩 길어지고 있다면, 사람이 부족해졌거나, 조치 루틴이 현장과 안 맞는다는 뜻이다. 숫자는 한 달에도 보지만, 분기에는 숫자 뒤에 있는 흐름을 읽는다. 한 달 리뷰가 "이번 달은 어땠나"라면, 분기 리뷰는 "방향이 맞나"를 묻는 자리다.
2. 모델 건강은 재학습 횟수가 아니라 '현장 적응'으로 본다
두 번째로 보는 건 모델의 건강이다. 분기 동안 재학습을 몇 번 했는지는 사실 중요하지 않다. 중요한 건 재학습한 모델이 현장에 잘 붙었는지다. 검증은 통과했는데 현장에서 오판이 늘었다면, 검증 기준이 현장과 어긋난 것이다. 반대로 재학습 없이도 현장 지표가 안정적이면, 굳이 모델을 건드릴 이유가 없다.
그래서 분기 리뷰에서는 재학습 횟수가 아니라 세 가지를 본다. 현장 오판이 분기 전보다 늘었는지, 드리프트 신호가 특정 구간에 몰리는지, 검증 기준이 현장의 질문을 따라가고 있는지. 이 세 가지가 안정적이면 모델은 건강한 것이다. 7년차 현장 엔지니어로서 한 줄로 정리하면, 모델이 건강한지 묻는 건 "모델이 똑똑해졌나"가 아니라 "모델이 현장에 적응하고 있나"를 묻는 일이다.
3. 사람 건강도 운영 지표다 — 담당자가 지치면 AI도 지친다
세 번째로 보는 건 사람이다. 분기 동안 야간 경보 대응이 특정 담당자에게 몰리지 않았는지, 인수인계가 끊긴 구간이 없었는지, 운영 노트에 빈 날이 생기지 않았는지를 본다. AI 운영은 결국 사람이 돌리는 일이라, 담당자가 지치면 경보 대응도 같이 느려진다.
운영 노트에 빈 날이 생겼다는 건, 그날은 경보가 없어서가 아니라 노트를 쓸 여유가 없었다는 뜻인 경우가 많다. 그게 반복되면 운영 기록 자체가 비어간다. 분기 리뷰에서 사람의 피로를 본다는 건, 단순히 걱정하는 게 아니라, "다음 분기에도 이 운영을 지탱할 수 있나"를 확인하는 일이다. 필요하면 담당을 나누고, 야간 대응 기준을 다시 정한다. 사람 건강이 무너지면, 대시보드의 숫자는 그다음 분기부터 같이 무너진다.
그래서 뭘 하면 되나
분기 리뷰는 거창한 회의가 아니다. 대시보드 숫자 세 가지(경보 흐름·모델 적응·사람 상태)를 한 장에 펼쳐놓고, "다음 분기에 바꿀 것 딱 하나"를 정하는 자리다. 바꿀 것 하나만 정해도 된다. 경보 하나를 줄이는 것, 검증 기준 하나를 현장에 맞추는 것, 야간 담당을 한 명 나누는 것. 분기마다 하나씩 바꾸면, 일 년 뒤의 현장은 지금과 달라져 있다. 현장 AI의 운영 건강은 어느 날 갑자기 좋아지는 게 아니라, 분기마다 하나씩 고쳐가며 쌓이는 것이다. 다음 편에서는 분기 리뷰에서 정한 '바꿀 것 하나'를 실제로 현장에 적용할 때, 무엇을 먼저 손대고 무엇을 나중에 두는지 다룹니다.
관련 글: 현장 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), EP.5(https://developer-archive.tistory.com/195), EP.6(https://developer-archive.tistory.com/200), EP.7(https://developer-archive.tistory.com/205), EP.8(https://developer-archive.tistory.com/210), EP.9(https://developer-archive.tistory.com/215), EP.10(https://developer-archive.tistory.com/220), EP.11(https://developer-archive.tistory.com/233), EP.12(https://developer-archive.tistory.com/238), 데이터 드리프트(https://developer-archive.tistory.com/133), 모델 평가 현장 지표(https://developer-archive.tistory.com/164)
현장에서 AI가 틀렸다는 보고가 들어오면, 대부분 가장 먼저 모델을 의심한다. 학습을 다시 해야 하나, 파라미터가 잘못됐나. 그런데 7년차 현장 엔지니어로서 솔직히 말하면, 내가 봐 온 오판의 절반 이상은 모델이 아니라 모델에 들어가는 '입력 데이터'에서 시작됐다. 센서 값이 이상한데도 그대로 믿고 판단을 내보낸 경우다. 모델 정확도는 실험실 숫자이고, 현장의 신뢰도는 입력 검증에서 갈린다.
## 1. 센서 값이 '들어왔다'는 것과 '믿을 만하다'는 건 다르다
현장의 센서는 생각보다 자주 거짓말을 한다. 결측이 생기고, 물리적으로 불가능한 범위를 찍고, 어떤 값에 고정돼 버리는 '고정(stuck)' 상태가 되기도 한다. 온도 센서가 25.0도에 그대로 멈춰 있는데, 모델은 그걸 정상 온도라고 믿고 "이상 없음"을 내보낸다. 통신이 끊긴 구간을 0으로 채워 넣는 경우도 마찬가지다. 데이터가 '들어왔다'는 사실만으로 믿을 만한 입력이 되는 건 아니다. 입력 검증은 모델 앞단에 두는 검문소 같은 것이다. 통과하지 못한 값은 판단 재료에서 빼는 게 맞다.
## 2. 추론 전 3단계 검증 — 범위·변화·일관성
내가 현장에서 쓰는 검증은 거창하지 않다. 세 가지만 본다.
첫째, 범위 체크다. 물리적으로 가능한 범위를 벗어난 값은 바로 차단한다. 압력이 음수가 나올 수는 없는 일이다.
둘째, 변화 체크다. 이전 값과 비교해 급변했거나, 반대로 너무 오래 변하지 않았는지 본다. 갑자기 튀는 값도 문제지만, 몇 시간째 소수점까지 똑같은 값도 센서가 멈췄다는 신호일 수 있다.
셋째, 일관성 체크다. 관련 센서끼리 서로 말이 되는지 본다. 압력은 올라가는데 유량은 그대로라면, 둘 중 하나는 틀린 것이다. 하나의 센서만 보면 놓치는 걸, 센서끼리 대조하면 잡아낸다.
세 단계 중 하나라도 어긋나면 기본값은 '판단 보류 + 사람에게 알림'이다. 애매한 값을 모델에 넘겨서 확신 없는 판단을 받아내는 것보다, 그 판단 하나를 비워 두는 편이 현장에서는 낫다.
## 3. 검증에 실패했을 때 모델이 할 일 — 멈추는 것도 설계다
모델이 "모르겠다"고 말하는 건 실패가 아니라 설계다. 현장 AI에 필요한 건 모든 질문에 답하는 능력이 아니라, 답하면 안 되는 경우를 아는 능력이다. 운영 범위를 정해 두는 일과 같은 맥락이다. (관련 글: 모델이 답하면 안 되는 경우를 먼저 정한다 — 현장 AI의 '운영 범위' 설계법: https://developer-archive.tistory.com/233)
검증에 걸린 입력은 로그에 남기는 것도 잊지 말자. 어떤 입력이, 어떤 규칙에 걸렸는지 기록해 두면, 나중에 "왜 그날 AI가 판단을 안 했나"를 추적할 단서가 된다. 로그 설계가 현장 AI의 기억이다. (관련 글: 설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것: https://developer-archive.tistory.com/130)
## 그래서 뭘 하면 되나
새 모델을 들이기 전에, 입력 검증 규칙 세 개부터 적어 보자. 범위 하나, 변화 하나, 일관성 하나. 이 세 줄이 현장에서 AI를 믿을 만하게 만드는 첫 단추이다. 모델은 똑똑해지는 중이지만, 현장에서 AI를 살리는 건 결국 "무엇을 믿고 판단할 것인가"를 정해 두는 일이다. 입력이 깨끗해야, 판단도 깨끗해진다.
현장 엔지니어에게 "디지털트윈 만들어달라"는 요청이 오면, 제일 먼저 물어보는 게 있습니다. "도면 있나요?" 그런데 현장에 가보면 오래된 설비일수록 도면이 없습니다. 설계 당시 도면은 있지만, 그 사이 배관이 바뀌고 설비가 옮겨지고 간이 구조물이 하나둘 늘었습니다. 도면대로 모델을 만들면 트윈은 설계 당시의 공장이 됩니다. 지금의 공장이 아니라.
그래서 저는 도면이 없을 때 스캔부터 합니다. 3D 스캔은 지금의 현장을 그대로 점(포인트 클라우드)으로 뜨는 방법입니다. 트윈의 첫 단추는 정확한 모델이 아니라, 지금 현장과 같은 모델입니다.
## 3D 스캔이 도면을 대신하는 이유
도면은 "이렇게 지었다"는 기록이고, 스캔은 "지금 이렇게 있다"는 기록입니다. 트윈이 현장과 어긋나는 이유의 절반은, 모델이 옛날 도면 기준이라서 생깁니다. 스캔으로 만든 모델은 처음부터 현장과 같습니다. 설비 위치가 몇 cm 어긋난 건 트윈 화면에서는 작은 차이 같지만, 로봇 경로를 짤 때는 큰 차이가 됩니다.
또 하나, 스캔은 설비 1대부터 시작할 수 있습니다. 공장 전체를 한 번에 뜰 필요가 없습니다. 트윈이 필요한 설비, 자주 고장 나는 라인, 새로 들어올 설비 자리 — 그 부분만 스캔하면 그날부터 트윈의 재료가 됩니다.
## 스캔 방식 3가지, 현장에서 고르는 기준
스캔 방식은 세 가지입니다. 첫째, 지상 LiDAR 스캐너는 넓은 공장 전체와 배관·레이아웃에 잘 맞습니다. 현장에서는 삼각대를 둘 자리와 사람 통행 시간을 피하는 데 주의합니다. 둘째, 사진측량(포토그래메트리)은 좁은 공간과 설비 외형에 잘 맞습니다. 사진 겹침 60% 이상과 일정한 조명이 중요합니다. 셋째, 핸드헬드 스캐너는 복잡한 형상과 지그·분기점에 잘 맞습니다. 기준점을 먼저 붙이고 일정한 속도로 스캔합니다.
비싼 장비부터 살 필요는 없습니다. 사진측량은 카메라와 소프트웨어만으로 시작할 수 있고, 좁은 구역에서는 이걸로 충분한 경우가 많습니다. 중요한 건 장비 등급이 아니라, 스캔한 데이터가 트윈에서 쓸 만큼 정확한가입니다. 그 기준은 트윈의 용도가 정합니다. 레이아웃 확인용이면 cm 단위로도 되고, 로봇 경로용이면 mm 단위가 필요합니다. 용도부터 정하고 장비를 고르는 순서입니다.
## 스캔해서 트윈까지, 현장 순서
첫째, 스캔 전에 기준점부터 붙입니다. 구역을 나눠 스캔하면 나중에 합쳐야 하는데, 기준점이 없으면 합친 모델이 어긋납니다. 현장 좌표와 모델 좌표를 맞추는 일은 스캔이 끝난 뒤가 아니라 시작 전에 정합니다.
둘째, 구역은 겹치게 스캔합니다. 이웃 구역과 30% 이상 겹쳐야 이어붙일 때 틀어지지 않습니다. 한 번에 넓게보다, 겹치게 여러 번이 정확합니다.
셋째, 점군을 그대로 트윈에 올리지 않습니다. 점군은 재료일 뿐, 트윈이 알아보는 건 객체입니다. 설비·배관·구조물로 나누고, 필요한 만큼만 해상도를 남깁니다. 트윈의 해상도는 정밀할수록 좋은 게 아니라, 용도에 맞는 게 좋습니다.
넷째, 스캔에도 날짜를 남깁니다. 현장은 계속 바뀝니다. 스캔 날짜가 없는 모델은 나중에 "이게 지금 모습이 맞나"를 다시 확인하게 만듭니다. 스캔 데이터도 버전으로 관리합니다.
## 현장에서 바로 할 일
- 도면 없는 설비 1대부터 스캔합니다. 공장 전체가 아니라, 트윈이 제일 필요한 곳부터입니다.
- 용도를 먼저 정하고 장비를 고릅니다. 레이아웃용인지, 로봇 경로용인지에 따라 필요한 정밀도가 다릅니다.
- 스캔 날짜와 기준점을 기록에 남깁니다. 다음에 바뀔 때, 어디가 바뀌었는지 아는 게 트윈 유지의 시작입니다.
도면이 없어서 트윈을 미루는 건, 지도가 없어서 출발을 미루는 것과 비슷합니다. 스캔은 출발하는 방법입니다. 한 대, 한 구역부터 뜨다 보면, 트윈은 도면이 아니라 현장에서 자라기 시작합니다.
예지정비 알림이 10분 늦게 뜬 날이 있었다. 모델을 의심했고, GPU를 의심했고, 코드까지 뒤졌다. 그런데 원인은 따로 있었다. 센서에서 나온 데이터가 게이트웨이를 거쳐 엣지 서버에 닿기까지, 네트워크 구간에서 시간을 먹고 있었던 것이다.
현장에서 AI가 느려 보일 때, 모델보다 먼저 네트워크를 의심해야 한다. 7년차 현장 엔지니어로서, 현장 AI 장애의 절반은 모델이 아니라 "데이터가 제때 도착하지 않는" 문제였다고 말할 수 있다.
## 1. 병목은 한 곳이 아니다 — 데이터가 흐르는 길부터 그려라
현장 데이터는 한 번에 도착하지 않는다. 센서에서 게이트웨이로, 게이트웨이에서 엣지 서버로, 엣지에서 클라우드로 — 구간마다 지연이 생긴다. 어디가 느린지 모르면 고칠 곳도 모른다.
그래서 첫 번째 일은 지도를 그리는 것이다. 내 데이터가 어떤 경로로, 어떤 장비를 거쳐 흐르는지 한 장으로 그려본다. 이 지도만 있어도 "여기서부터는 클라우드 왕복" "여기는 무선 구간" 같은 병목 후보가 보이기 시작한다. 구간마다 타임스탬프를 찍어두면, 나중에 지연이 어디서 생겼는지 숫자로 확인할 수 있다.
## 2. 현장 네트워크의 흔한 범인 3가지
첫째, 무선 구간의 간섭과 음영이다. 금속 설비가 빼곡한 공장 안에서는 와이파이나 무선 센서 신호가 생각보다 자주 끊긴다. 지게차가 지나가는 시간에만 데이터가 비는 패턴이 있다면, 무선 구간을 먼저 의심해볼 일이다.
둘째, 게이트웨이와 스위치의 과부하다. 한 대의 게이트웨이에 센서가 계속 붙다 보면, 어느 순간 처리량이 한계에 닿는다. 특정 시간대에만 지연이 생긴다면, 그 시간대에 몰리는 트래픽을 확인해보자. 교대 시간, 특정 설비 가동 시간이 단서가 된다.
셋째, 클라우드 왕복이다. 엣지에서 끝낼 수 있는 판단을 굳이 클라우드까지 보내고 돌아오는 설계가 의외로 많다. 왕복 한 번에 수백 밀리초가 더해지면, "실시간"이라는 말은 그 순간부터 무너진다.
## 3. 진단 순서 — 큰 것부터, 현장에서 확인하는 법
1단계, 엣지에서 직접 확인한다. 엣지 서버에 직접 붙어 응답 시간을 재본다. 여기서 이미 느리면 문제는 엣지 앞단, 즉 센서·게이트웨이 구간이다.
2단계, 구간별 지연을 측정한다. 각 구간에 타임스탬프를 찍고, 어느 구간에서 시간이 늘어나는지 본다. 감이 아니라 숫자로 확인하는 것이 중요하다.
3단계, 시간대 패턴을 확인한다. 지연이 특정 시간대에만 생긴다면, 그 시간에 무슨 일이 일어나는지 현장에 물어본다. 설비 가동 스케줄, 교대 시간, 무선 간섭원이 숨어 있는 경우가 많다.
## 마무리 — 느린 AI의 절반은 네트워크 문제다
모델을 바꾸기 전에, 데이터를 먼저 의심해보자. 현장에서 AI가 제 역할을 못하는 이유 중 상당수는 모델 성능이 아니라 "데이터가 제때, 제대로 도착하지 않는" 문제다.
그래서 뭘 하면 되나 — 이번 주에 한 가지만 해보자. 가장 중요한 AI 서비스 하나를 골라, 엣지 응답 시간과 구간별 지연을 한 번 재보는 것이다. 숫자가 나오면 그다음은 쉽다. 병목이 보이면, 고칠 곳도 보인다.
오늘(11월 12일) 나온 소식 하나가 제조 현장의 로봇 도입 방식을 바꿀 수 있어 보인다. PwC컨설팅과 피지컬 AI 전문기업 리얼월드가 컨소시엄을 꾸려 제조·물류 기업의 로봇 도입과 현장 실증(PoC)을 지원하기로 했다. 핵심은 PwC의 '피지컬 AI 레디 데이터 플랫폼'과 리얼월드의 로봇 파운데이션 모델(RFM) 'RLDX-1'을 결합한다는 점이다. 모델이 좋아졌다는 얘기가 아니라, 모델을 현장에 '붙이는 비용'을 줄이겠다는 얘기다.
## 왜 지금, 왜 컨소시엄인가
피지컬 AI는 AI가 로봇 같은 물리적 장치를 통해 실제 환경에서 움직이고 작업하는 기술이다. 제조·물류 현장에서 활용이 넓어지고 있지만, 공정이나 작업 환경이 바뀔 때마다 데이터를 새로 수집하고 모델을 재학습해야 한다는 한계가 있다. 도입 비용과 시간이 많이 드는 구조다.
컨설팅사와 모델 기업이 손을 잡았다는 건, 지금 시장의 진짜 병목이 모델 성능이 아니라 '도입의 문턱'이라는 신호다. 로봇을 파는 쪽도, 도입을 돕는 쪽도 이제는 "우리 모델이 얼마나 똑똑한가"보다 "현장에 얼마나 빨리, 얼마나 싸게 붙는가"로 경쟁하고 있다.
## 핵심은 'PAU' — 동작을 단위로 쪼개 재사용한다
이번 컨소시엄에서 가장 눈여겨볼 개념은 PAU(Physical Action Unit, 물리적 행동 단위)다. PwC의 데이터 플랫폼은 로봇 동작을 '다가가기·쥐기·들어올리기·내려놓기' 같은 단위로 나눠 구조화하고, 작업 영상과 로봇 상태, 작업 정보를 하나의 데이터 단위로 묶어 다른 공정에서도 재사용할 수 있게 한다.
현장 관점에서 이게 중요한 이유는 간단하다. 공장은 라인이 바뀌면 동작이 비슷해 보여도 조건이 다르다. '쥐기' 하나를 재사용할 수 있으면 PoC 비용이 확 준다. 다만 한 가지 조건이 있다. PAU가 현장에서 통하려면 힘·속도·오차 허용 범위 같은 '현장 조건'까지 단위에 포함돼야 한다. 영상만 묶인 데이터는 시연용이지, 현장용이 아니다.
## 7년차 현장 관점: PoC가 아니라 '두 번째 라인'이 시험대다
7년차 현장 엔지니어로서 한 줄만 남긴다면, 로봇 한 대가 잘 움직이는 걸 보는 건 PoC의 절반이고, 두 번째 라인에 같은 모델을 얹을 때 진짜 도입 비용이 드러난다는 것이다.
그래서 뭘 하면 되나 — 로봇 도입을 검토한다면 모델 스펙보다 '이 데이터를 다음 라인에서 재사용할 수 있는가'를 먼저 물어보라. 동작 단위 데이터가 쌓이는 구조인지, 재학습 없이 공정 변경에 대응하는 범위가 어디까지인지 확인하는 게 현장의 첫 질문이다.
피지컬 AI 경쟁은 이제 모델 성능이 아니라 '현장에 남는 데이터 구조'의 싸움으로 넘어가고 있다. 이번 컨소시엄이 약속한 것도 결국 하나다. 로봇을 들여오는 비용보다, 들여온 뒤 바꾸는 비용을 줄이는 것. 그 약속이 지켜지는지는 첫 PoC가 아니라 두 번째 라인에서 판가름 날 것이다.
출처: 뉴시스, 「PwC컨설팅, 제조·물류현장 피지컬AI 적용 지원…리얼월드와 컨소시엄」, 2026-11-12 13:49
새벽 2시, 라인이 섰다. 노트북을 펴고 PLC 래더를 열었는데, rung마다 접점과 코일만 빼곡할 뿐 주석이 한 줄도 없었다. 누가, 왜, 이 타이머를 3초로 잡았는지 알 수가 없었다. 그날 나는 고장을 고친 게 아니라, 남이 짠 코드를 해독하는 데 밤을 썼다.
7년차 현장 엔지니어로서 단언한다. 래더의 주석은 '예의'가 아니라 '가동률'이다.
## 1. 주석 없는 래더는 '읽는 시간'이 곧 '멈춘 시간'이다
라인이 멈춘 동안 가장 비싼 건 부품이 아니라 시간이다. 주석이 없으면 장애 대응은 두 단계가 된다. 먼저 코드를 읽어서 의도를 추측하고, 그다음에야 원인을 찾는다. 추측이 틀리면 처음부터 다시 읽는다.
반대로 주석이 있으면 대응은 한 단계다. "센서 채터링 방지용 3초 지연" 한 줄이면, 그 타이머를 의심할지 말지 바로 판단할 수 있다. 고장 대응 시간(MTTR)은 결국 '이해하는 시간'에 비례한다. 주석 한 줄이 라인 정지 시간을 줄이는 셈이다.
## 2. 주석은 '무엇'이 아니라 '왜'를 적는다
많은 주석이 "모터 기동" 같은 설명에 그친다. 하지만 래더를 보면 무엇인지는 이미 보인다. 주석에 필요한 건 '왜'다. 왜 이 인터록이 들어갔는지, 왜 이 값을 3초로 잡았는지, 왜 이 조건을 OR로 묶었는지.
예를 들어 "컨베이어 정지 후 5초 대기 — 센서 잔류 검출 방지, 2024년 오작동 사례 반영" 같은 주석은 다음 사람에게 판단 기준을 넘겨준다. 이 한 줄이 없으면, 누군가 나중에 "굳이 5초나?" 하고 1초로 줄였다가 같은 오작동을 재현한다. 현장에서 반복되는 고장의 상당수는, 이유를 모른 채 값을 바꾼 데서 시작된다.
## 3. 주석 습관을 지키는 3가지 방법
첫째, 코드를 고칠 때 주석도 같이 고친다. 로직만 바꾸고 주석을 그대로 두면 주석이 거짓말이 된다. 거짓말하는 주석은 없는 주석보다 나쁘다. 없는 주석은 의심이라도 하지만, 틀린 주석은 사람을 잘못된 방향으로 확신하게 만든다.
둘째, '임시'라는 말을 쓰면 기한을 함께 적는다. "임시 우회 — 11월 정기보수 때 정식 수정 예정"처럼 말이다. 기한 없는 임시는 영구다. 현장에 몇 년째 남아 있는 임시 우회가 몇 개인지, 한 번 세어보면 안다.
셋째, 내 이름을 남기는 걸 부끄러워하지 않는다. "손효기, 2026-11-12" 같은 서명은 책임이 아니라 연락처다. 다음 사람이 "이거 왜 이래?" 하고 물을 때, 물을 사람이 있다는 것만으로 대응 속도가 달라진다.
## 그래서 뭘 하면 되나
이번 주에 래더를 만질 일이 있다면, 수정하는 rung에 주석 한 줄만 덧붙여보자. "왜 이 값인지" 한 줄이면 된다. 그 한 줄이 쌓이면, 언젠가 새벽 2시에 래더를 여는 누군가의 밤이 짧아진다. 그 누군가는 어쩌면 6개월 뒤의 나 자신일 수도 있다.
