프로그래밍 허브

로봇이 공장에 들어오는 방식이 바뀌고 있다. 무거운 휴머노이드가 문을 열고 들어오는 게 아니라, 작업복처럼 입는 로봇이 먼저 현장에 스며들고 있다. 한국기계연구원 창업기업 사르텍소가 2026년 11월 5일 공개한 의복형 웨어러블 로봇 '바이오닉 슈트'가 그 신호탄이다. 모터도, 금속 프레임도 없다. 옷감 자체가 힘을 낸다.

'근육옷감'이란 무엇인가

바이오닉 슈트의 핵심은 머리카락보다 가는 형상기억합금 와이어를 코일 형태의 실로 만들어 옷감처럼 직조한 '근육옷감'이다. 숫자가 인상적이다. 근육옷감 10g이 최대 10~15kg을 들어 올린다. 자체 무게의 최대 1,500배에 이르는 힘이다.

이 기술을 적용한 허리 보조용 '바이오닉 슈트 웨이스트'는 배터리와 제어기를 포함해도 무게가 1.3kg에 불과하고, 허리·어깨·팔꿈치를 함께 보조하는 통합형 '바이오닉 슈트 풀'도 1.8kg 이하다. 기존 웨어러블 로봇이 외골격 프레임과 모터 때문에 '입는 기계'에 가까웠다면, 이건 진짜 '입는 옷'에 가깝다. 가격도 허리 보조용 기준 100만 원 이하부터 100만 원 중반대를 검토 중이라고 한다. 웨어러블 로봇의 대중화를 내건 목표와 맞닿아 있다.

왜 지금, 왜 공장인가

사르텍소는 물류·건설·제조업 등 반복적인 중량물 취급이 필요한 산업현장을 우선 공략하겠다고 밝혔다. 양산 기반도 이미 마련했다. 근육옷감을 연속 생산하는 자동직조 기술을 도입해 수작업 중심이던 제작 공정을 자동화했다.

7년차 현장 엔지니어로서 한 줄로 정리하면 이렇다. 현장에서 로봇 도입이 막히는 이유는 성능이 아니라 '착용감과 가격'인 경우가 많다. 무거운 외골격은 한 시간만 차도 작업자가 벗어버린다. 1.3kg짜리 옷이라면 이야기가 달라진다. 휴머노이드가 공장에 들어오기 전, 사람의 몸에 붙는 로봇이 먼저 들어오는 게 순서일 수 있다.

그래서 뭘 하면 되나

첫째, 근력 보조가 필요한 공정을 '작업' 단위가 아니라 '동작' 단위로 나눠본다. 허리를 굽히는 횟수, 드는 무게, 반복 주기가 숫자로 나오면 도입 검토가 시작된다. 둘째, 파일럿은 한 라인, 한 교대부터 작게 시작한다. 셋째, 착용자의 피로도·작업 속도 변화를 도입 전후로 직접 재본다. 숫자가 없으면 확산은 없다.

로보월드 2026(11월 4~7일, 킨텍스)이 보여준 흐름과도 맞닿아 있다. 거대한 휴머노이드 전시 뒤에서, 실제로 현장에 먼저 들어갈 기술은 이렇게 가볍고 조용한 쪽일지 모른다. 로봇의 미래가 꼭 사람 모양일 필요는 없다. 때로는 옷 모양이다.

출처: 아시아경제(2026-11-05) "모터 대신 '근육옷감'…입는 로봇 상용화 나선다", 머니투데이(2026-11-05) "진짜 옷처럼 입는 로봇 나왔다…'1500배' 힘 내는 근육옷감"

이 글은 '현장 AI 운영 노트' 시리즈의 아홉 번째 글입니다. 1편에서는 매일 아침 AI의 건강을 보는 5분 점검표를, 2편에서는 그 점검표를 대시보드 하나로 만드는 법을, 3편에서는 경보가 울렸을 때 누가 어떤 순서로 움직이는지 조치 루틴을, 4편에서는 한 달 돌린 경보 루틴을 숫자로 리뷰하는 법을, 5편에서는 분기 리뷰로 재학습 여부를 정하는 기준을, 6편에서는 재학습한 모델을 현장에 내놓기 전 검증 3단계를, 7편에서는 배포한 뒤 새 모델의 성능을 현장에서 계속 추적하는 모니터링 루틴을 다뤘습니다 (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). 지난 편에서는 모니터링에서 이상 신호가 잡혔을 때 재학습·롤백·기준 수정 중 무엇을 고르는지 의사결정 기준을 다뤘습니다. 이번 편에서는 그 대응 기록을 쌓아 다음 모델의 학습 데이터로 바꾸는 법을 다룹니다.

이상 신호 대응 기록은 보통 보고서로 끝나고 만다. 원인을 적고, 조치 내용을 적고, 종결 버튼을 누르면 파일은 잠긴다. 그런데 현장에서 진짜 아까운 건, 그 기록 안에 다음 모델이 배워야 할 사례가 그대로 들어 있다는 점이다. 틀렸던 사례, 사람이 개입했던 사례, 기준을 바꿨던 사례 — 이게 모이면 다음 학습 데이터의 가장 좋은 재료가 된다.

1. 기록을 '사례'로 바꿀 때 남겨야 할 네 가지

대응 기록을 학습 데이터로 쓰려면, 보고서 문장이 아니라 사례 형태로 남겨야 한다. 첫째, 입력이다. 당시 센서 값과 공정 조건, 모델이 본 그대로의 입력이 필요하다. 둘째, 모델의 판정과 그 근거다. 무엇을 불량이라 했는지, 확신도는 어땠는지. 셋째, 사람의 최종 판단이다. 작업자가 실제로 어떻게 처리했는지, 모델과 달랐다면 왜 달랐는지. 넷째, 결과다. 그 판단이 맞았는지, 나중에 어떻게 확인됐는지.

이 네 가지가 빠지면 기록은 이야기가 될 뿐 데이터가 되지 않는다. 특히 "사람이 왜 다르게 판단했는지" 이유가 빠지면, 다음 모델은 사람의 판단만 흉내 낼 뿐 그 판단의 근거를 배우지 못한다.

2. 바로 학습 데이터에 넣지 않는다 — '검수 통과' 단계가 필요하다

대응 기록을 모았다고 해서 곧바로 학습 데이터에 넣으면 안 된다. 현장 기록에는 노이즈가 많다. 센서 고장으로 입력 자체가 틀렸던 사례, 기준이 바뀌기 전 옛 기준으로 판단했던 사례, 일회성 특이 조건에서만 나온 사례가 섞여 있다. 그래서 넣기 전에 검수 단계를 둔다. 원인이 확인된 사례인지, 라벨이 지금 기준과 맞는지, 같은 유형이 반복되는지 — 이 세 가지를 통과한 사례만 학습 후보로 올린다.

검수를 거친 사례는 '틀렸던 사례'와 '사람이 개입했던 사례'로 나눠 관리한다. 틀렸던 사례는 모델의 약점을 보여주고, 사람이 개입했던 사례는 모델이 아직 모르는 현장의 기준을 보여준다. 두 종류를 구분해 두면, 재학습할 때 무엇을 보강해야 하는지가 분명해진다.

3. 기록이 쌓이면 운영이 아니라 자산이 된다

이렇게 쌓인 사례는 재학습 때마다 다시 쓰인다. 새 모델을 검증할 때는 지난 대응 사례를 테스트 세트로 삼는다. "지난번에 틀렸던 그 사례, 이번 모델은 맞히나?" 이 질문에 답할 수 있는 팀은 재학습의 효과를 숫자가 아니라 사례로 확인한다. 사례가 쌓일수록 팀은 같은 실수를 반복하지 않게 되고, 신입이 와도 지난 대응 기록만 읽으면 현장의 기준을 배울 수 있다.

7년차 현장 엔지니어로서 한 줄로 정리하면, 이상 신호 대응 기록은 끝난 일이 아니라 다음 모델의 교재다. 그래서 뭘 하면 되나, 이번 주 할 일은 세 가지다. 첫째, 대응 기록 양식에 입력·판정·사람 판단·결과 네 칸을 고정한다. 둘째, 학습 후보로 올리기 전 검수 세 가지(원인 확인·현행 기준 일치·반복 여부)를 통과시킨다. 셋째, 재학습 검증 때 지난 대응 사례를 테스트 세트로 먼저 돌린다. 모델을 오래 운영하는 팀은 모델을 잘 만드는 팀이 아니라, 틀린 경험을 데이터로 남기는 팀이다. 다음 편에서는 이렇게 쌓인 운영 기록을 팀 인수인계 자료로 바꾸는 법을 다룹니다.

관련 글: 현장 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), 데이터 드리프트(https://developer-archive.tistory.com/133), AI 모델 평가를 현장 지표로(https://developer-archive.tistory.com/164)

요즘 AI 뉴스는 대부분 "더 큰 모델" 이야기입니다. 그런데 공장 바닥에서는 반대 방향의 움직임이 조용히 커지고 있습니다. 모델을 작게 만들어 설비 옆, 센서 옆, 라인 옆에서 바로 돌리는 온디바이스 AI입니다. 왜 현장에서는 큰 모델보다 작은 모델이 먼저일까요.

큰 모델은 현장에서 '무겁다'

클라우드 대형 모델은 성능이 좋지만, 현장에는 맞지 않는 조건이 있습니다. 첫째, 지연시간입니다. 불량 판정이나 안전 정지 같은 판단은 수백 밀리초 안에 끝나야 합니다. 네트워크를 왕복하는 동안 라인은 멈추지 않습니다. 둘째, 연결입니다. 공장은 보안 구간, 전파 음영, 방화벽 때문에 외부 연결이 항상 열려 있지 않습니다. 셋째, 비용입니다. 모든 센서 데이터를 클라우드로 보내면 전송료와 추론료가 쌓이고, 정작 필요한 건 "지금 이 설비의 상태" 하나뿐인 경우가 많습니다. 현장에서 AI가 느리거나, 연결에 기대거나, 비싸면 도입 자체가 막힙니다.

작아졌다고 성능이 작아지는 건 아니다

경량화는 무조건 줄이는 게 아닙니다. 현장에서 실제로 쓰는 방식은 세 가지입니다. 필요한 작업만 남기는 모델 압축, 현장 데이터로 다시 맞추는 파인튜닝, 그리고 판단 범위를 좁히는 전문화입니다. 예를 들어 "이 설비의 이 결함만 본다"는 모델은 범용 모델보다 작아도 현장 정확도가 높을 수 있습니다. 7년차 현장 엔지니어로서 강조하고 싶은 지점은 이겁니다. 현장 AI의 성능은 벤치마크 점수가 아니라, 그 라인·그 설비·그 결함에 대한 적중률로 재야 합니다. 작은 모델이 현장에서 이기는 이유는 '작아서'가 아니라 '현장 조건에 맞춰져서'입니다.

그래서 뭘 하면 되나 — 도입 전 체크 3가지

첫째, 판단 위치를 정하세요. 실시간 판단은 현장에서, 학습·분석·장기 추세는 클라우드에서. 둘째, 연결이 끊겨도 되는지 확인하세요. 오프라인에서도 판단·기록·재전송이 되는 구조인지가 도입의 분수령입니다. 셋째, 업데이트 방식을 정하세요. 현장 모델은 데이터가 바뀌면 낡습니다. 누가, 언제, 어떤 기준으로 모델을 교체할지 운영 규칙부터 정해야 합니다. 큰 모델을 들여오는 것보다, 작은 모델을 현장 조건에 맞게 운영하는 쪽이 제조 AI에서는 훨씬 현실적인 출발점입니다.

스마트팩토리 프로젝트는 기술보다 협업에서 무너지는 경우가 많다. 현장에 가본 적 없는 팀이 만든 화면은 예쁘지만, 라인이 멈춘 밤에는 아무 도움이 되지 않는다. 외주 개발사와 일을 시작하기 전, 나는 계약서보다 먼저 세 가지를 확인한다.

1. 현장에 와본 적이 있는가

설비 옆에 서본 팀과 회의실에서만 들은 팀은 질문이 다르다. 전자는 "이 알람이 떴을 때 작업자는 어디를 보나요"라고 묻고, 후자는 "데이터는 어떤 형식으로 주나요"라고만 묻는다. 현장 방문 경험이 없는 팀이라면, 최소한 첫 주에 현장 동행 일정을 잡자. 센서 위치, 작업 동선, 야간 무인 시간대 같은 정보는 문서로 전달되지 않는다.

2. '완료'의 기준이 문서에 있는가

"대시보드 구축 완료" 같은 문장은 나중에 분쟁이 된다. 완료란, 예를 들어 "특정 설비의 가동·정지·고장 상태가 10초 이내에 화면에 반영되고, 1주일 연속 오표시 0건"처럼 측정 가능해야 한다. 나는 완료 기준을 세 문장으로 적는다. 무엇을, 어떤 조건에서, 어떻게 확인할 것인지. 이 문장이 없으면 검수는 감으로 흐른다.

3. 떠난 뒤에도 고칠 수 있는 구조인가

프로젝트가 끝난 뒤 외주팀이 떠나는 건 당연하다. 문제는 그때부터다. 소스 코드와 설정, 데이터 정의서가 내부 담당자에게 인계되는지, 간단한 문구 수정이나 알람 기준 변경을 현장 담당자가 직접 할 수 있는지를 미리 확인하자. 인계 없는 시스템은 두 번째 의뢰부터 비용이 다시 붙는 구조가 된다.

마무리 — 계약 전 체크리스트

현장 동행 일정이 첫 주에 잡혀 있는가. 완료 기준이 측정 가능한 문장으로 적혀 있는가. 인계 문서와 내부 수정 권한이 명시되어 있는가. 이 세 가지만 확인해도 프로젝트의 후반부가 달라진다. 기술은 나중에 바꿀 수 있지만, 협업의 구조는 처음에 정해진다.

현장 AI를 도입하면 첫 달에는 모델 얘기가 대부분이다. 정확도가 몇 퍼센트인지, 어떤 알고리즘이 좋은지. 그런데 막상 한 달이 지나면 남는 질문은 다르다. "그날 그 설비는 어떤 상태였지?", "누가, 무엇을 보고 판단했지?" 모델은 답을 주지만, 그 답이 나온 맥락은 기록이 없으면 사라진다.

7년차 현장 엔지니어로서, 나는 도입 첫 달에 모델보다 운영 일지를 먼저 챙긴다. 일지는 거창할 필요가 없다. 아래 세 가지만 날짜와 함께 남기면 된다.

1. 그날의 '현장 조건'을 한 줄로 남긴다

같은 알람이라도, 야간 무인 운전 중인지, 설비 교체 직후인지에 따라 의미가 달라진다. 그래서 일지의 첫 줄은 늘 현장 조건이다. "오후 교대, 2호기 센서 교체 후 첫 가동" 같은 한 줄이면 충분하다. 나중에 이상 신호를 다시 볼 때, 이 한 줄이 모델 판정과 현장 현실 사이의 다리가 된다.

2. AI 판정과 사람의 판단을 나란히 적는다

AI가 "불량 가능성 높음"이라고 했을 때, 작업자는 어떻게 판단했는가. 그대로 멈췄는지, 눈으로 한 번 더 확인하고 통과시켰는지. 이 두 판단을 나란히 적어두면, 나중에 모델이 틀렸을 때 원인을 추측하지 않아도 된다. 입력 데이터가 문제였는지, 기준이 달랐는지, 아니면 그날따라 현장 조건이 특별했는지 기록에서 바로 보인다.

3. 예외는 '예외'로 따로 모은다

정상 케이스는 모델이 알아서 잘 처리한다. 진짜 자산은 예외다. "원인은 찾지 못했지만 재가동 후 정상" 같은 애매한 사례, "센서 값은 정상인데 소리가 이상했다"는 감각적인 메모도 버리지 않는다. 예외를 따로 모아두면, 다음 달 모델 개선 회의에서 "무엇을 더 배워야 하는가"가 구체적인 사례로 나온다.

그래서 뭘 하면 되나

도입 첫 달에는 대시보드를 하나 더 만들기 전에, 팀 공용 문서에 날짜·현장 조건·AI 판정·사람 판단·예외, 이 다섯 칸짜리 표 하나를 만들어 보자. 하루 5분이면 충분하다. 한 달 뒤, 그 표가 모델보다 더 오래 남는 현장의 기억이 된다.

관련 글: 설비 알람 로그 설계(https://developer-archive.tistory.com/130), 재부팅으로 안 잡히는 장애 대응 루틴(https://developer-archive.tistory.com/135), 현장 장애 원인을 빨리 찾는 인터뷰 습관(https://developer-archive.tistory.com/181)

11월 4일) 경기도 고양시 킨텍스에서 국내 최대 로봇산업 전시회 '2026 로보월드'가 개막했다. 17개국 402개 기업, 1,198개 부스 규모로 7일까지 나흘간 열린다. 올해 슬로건은 'M.AX the Future with AI Robotics'. 정해진 동작을 반복하는 산업용 로봇이 아니라, 주변을 인식하고 스스로 판단해 움직이는 지능형 로봇이 전시장의 중심이다.

전시장에서 본 것: 시연이 아니라 "현장 적용" 경쟁

눈에 띈 장면은 화려한 퍼포먼스가 아니라 현장으로 향하는 구체성이다. 레인보우로보틱스는 동역학 기반 보행 제어와 강화학습 기반 AI 보행을 적용한 사족보행 로봇을, 로보티즈는 휴머노이드 'AI 사피엔스'의 태권도·댄스 시연으로 부드러워진 관절 움직임을 보여줬다. 에이로봇의 휴머노이드 '앨리스5'는 트레드밀 위 보행으로 동작 제어 기술을 공개했다.

한편 디든로보틱스는 조선소 용접을 위한 사족보행 로봇 '디든 스파이더'를 내놨고, 삼현은 최대 3톤 화물을 운반하는 고하중 자율주행 로봇 '볼덤(BOLDUM)'을 공개했다. 오는 12월 창원 2공장에서 양산해 북미 휴머노이드 제조사에 공급한다는 계획까지 붙어 있다. 제조 자동화 쪽에서는 DN솔루션즈의 머신텐딩, 브릴스의 모듈형 로봇 플랫폼이 나왔다. "할 수 있다"가 아니라 "어디에, 어떻게, 언제 납품되는가"를 묻는 전시회로 바뀌고 있다.

숫자가 말하는 것: AI팩토리 245곳, 그리고 정부의 "첫 고객" 선언

같은 날 전해진 제조 AI 전환(M.AX) 1년 성적표도 함께 봐야 한다. 정부가 추진 중인 AI팩토리는 11월 3일 기준 245곳으로, 올해 상반기 170곳에서 75곳이 늘었다. 우수사례 38건을 분석한 결과 생산성은 평균 30.1% 높아지고 불량률은 15.5% 낮아졌다. 2030년까지 500곳 보급 목표의 절반 가까이에 도달한 셈이다.

여기에 정부가 내년부터 AI 로봇 1,700대 이상을 직접 구매해 공공부문에 보급한다는 계획이 더해졌다. "불완전한 시제품이라도 먼저 사주는 첫 고객이 돼야 한다"는 방향이다. 전시회에서 본 로봇들이 실험실 시연으로 끝나지 않고 실제 구매·배치로 이어지는 연결고리가 만들어지고 있다는 뜻이다.

7년차 현장 관점: 진짜 시험대는 여전히 공장 바닥이다

7년차 현장 엔지니어로서 한 줄로 정리하면, 로봇 스펙표보다 비싼 건 "현장에서 실패한 기록"이다. 전시장 바닥은 평평하고 조명이 좋지만, 공장 바닥은 기름때, 진동, 먼지, 그리고 예측하지 못한 작업자 동선이 있다. 사족보행 로봇이 계단을 오르는 것과 조선소 블록 사이를 다니는 것은 다른 문제다. 그래서 이번 로보월드를 볼 때 나는 시연의 부드러움보다 "어떤 공정에, 어떤 안전 조건으로, 누가 유지보수하는가"를 먼저 본다.

그래서 뭘 하면 되나: 당장 로봇을 살 계획이 없어도, 우리 공정의 "로봇이 들어올 자리"를 한 줄로 적어보는 것부터 시작하면 된다. 투입·배출처럼 반복되고 위험한 구간, 검사처럼 사람이 지치는 구간이 그 자리다. 그 자리가 정해져야 데이터 수집 범위, 안전 울타리, 유지보수 담당이 정해진다. 로봇 도입은 구매가 아니라 "자리 설계"부터다.

마무리: 피지컬 AI, 이제는 "사양"이 아니라 "배치"의 싸움이다

로보월드는 피지컬 AI 경쟁이 시연 단계에서 배치 단계로 넘어가고 있음을 보여준다. AI팩토리 245곳이라는 숫자와 정부 공공구매 계획이 그 배경이다. 앞으로의 질문은 "로봇이 얼마나 사람 같으냐"가 아니라 "우리 공장의 어떤 문제를, 어떤 조건으로 해결하느냐"가 될 것이다. 그 질문에 답할 수 있는 현장이 다음 전시회의 주인공이 된다.

출처: 연합인포맥스(2026-11-04) '태권도 하고 러닝머신도 걷고…피지컬 AI 로봇 한자리에', 전자신문(2026-11-04) 'AI팩토리 245곳 가동…韓 제조, 데이터부터 로봇까지 AI로 다시 짠다', 이투데이(2026-11-04) 'AI 입은 로봇, 제조현장 바꾼다…2026 로보월드 개막'

이 글은 '현장 AI 운영 노트' 시리즈의 여덟 번째 글입니다. 1편에서는 매일 아침 AI의 건강을 보는 5분 점검표를, 2편에서는 그 점검표를 대시보드 하나로 만드는 법을, 3편에서는 경보가 울렸을 때 누가 어떤 순서로 움직이는지 조치 루틴을, 4편에서는 한 달 돌린 경보 루틴을 숫자로 리뷰하는 법을, 5편에서는 분기 리뷰로 재학습 여부를 정하는 기준을, 6편에서는 재학습한 모델을 현장에 내놓기 전 검증 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 · EP.5 https://developer-archive.tistory.com/195 · EP.6 https://developer-archive.tistory.com/200 · EP.7 https://developer-archive.tistory.com/205). 이번 편에서는 지난 편 모니터링에서 이상 신호가 잡혔을 때, 재학습·롤백·기준 수정 중 무엇을 고르는지 의사결정 기준을 다룹니다.

지난 편에서 정한 기준대로, 판정 분포가 바뀌고 사람 개입률이 2주 연속 기준을 넘었다고 치자. 이때 현장에서 가장 흔한 실수는 원인도 가리지 않고 바로 재학습 버튼을 누르는 것이다. 데이터가 문제면 모델을 다시 돌려도 같은 실수를 반복하고, 센서가 문제면 새 모델도 같은 입력에 속는다. 이상 신호가 잡혔을 때의 첫 번째 일은 고치는 게 아니라, 고를 것을 정하는 일이다.

1. 먼저 묻는다 — 뭐가, 얼마나, 어디서 틀렸나

선택하기 전에 세 가지 질문에 답해야 한다. 첫째, 뭐가 틀렸나. 지난 편 주간 리뷰의 분류를 그대로 쓴다. 데이터가 바뀐 건지, 센서가 이상한 건지, 공정 자체가 바뀐 건지, 모델의 한계인지. 둘째, 얼마나 틀렸나. 전체가 틀린 건지, 특정 로트·특정 시간대·특정 불량 유형에서만 틀린 건지. 셋째, 어디서 틀렸나. 입력 신호가 이상한 건지, 판정 기준이 현장과 어긋난 건지.

이 세 답이 나오면 선택지는 저절로 좁아진다. 특정 로트에서만 틀리면 그 로트 데이터를 먼저 보고, 센서 값이 튀면 설비팀에 넘기며, 공정 조건이 바뀐 게 확인되면 기준을 먼저 의심한다. 질문을 건너뛰고 재학습부터 하면 원인은 그대로 둔 채 모델만 지치게 된다.

2. 세 가지 선택지의 갈림길

재학습을 고르는 경우는, 원인이 데이터에 있고 새 데이터가 손에 있을 때다. 현장에서 실제로 틀렸던 사례가 충분히 쌓였고, 그 사례가 다음에도 반복될 조건이라면 재학습이 맞다. 단, 재학습 뒤에는 지난 편 6편의 검증 3단계를 다시 밟는다. 검증 없이 바로 현장에 올리는 재학습은, 이상 신호를 한 번 더 만드는 지름길이다.

롤백을 고르는 경우는, 새 모델이 옛 모델보다 명백히 나쁠 때다. 배포 뒤 특정 불량 유형의 누락이 늘었거나, 사람 개입률이 배포 전보다 높아졌다면 주저하지 말고 이전 버전으로 되돌린다. 롤백은 실패 인정이 아니라 운영의 한 기능이다. 되돌릴 수 없게 만드는 배포가 진짜 문제다. 그래서 배포할 때는 이전 버전과 되돌리는 절차를 함께 남겨둬야 한다.

기준 수정을 고르는 경우는, 모델은 맞는데 현장의 기준이 바뀐 때다. 불량 판정 기준이 바뀌었거나, 공정 조건이 달라져서 옛 기준이 맞지 않게 된 경우다. 이때 모델을 다시 학습시키는 건, 정답지를 바꿔놓고 학생을 탓하는 것과 같다. 기준을 바꾸고, 바뀐 기준에 맞춰 평가 데이터를 먼저 고친다. 기준 수정은 가장 싸고 빠른 조치인데, 현장에서 가장 늦게 떠올려지는 선택지이기도 하다.

3. 결정은 문서로 남기고, 되돌릴 준비까지

무엇을 골랐든, 결정 자체를 기록으로 남긴다. 이상 신호가 무엇이었고, 세 가지 질문에 어떻게 답했으며, 무엇을 골랐고, 누구의 결정인지, 언제 다시 검토할지를 한 장에 적는다. 이 기록이 없으면 다음에 같은 신호가 왔을 때 또 처음부터 논쟁한다. 기록이 쌓이면, 이상 신호 대응은 사람의 감이 아니라 팀의 절차가 된다.

7년차 현장 엔지니어로서 한 줄로 정리하면, 이상 신호 대응의 실력은 빨리 고치는 게 아니라 바르게 고르는 데 있다. 그래서 뭘 하면 되나, 이번 주 할 일은 세 가지다. 첫째, 이상 신호가 오면 재학습부터 누르지 말고 세 가지 질문에 답한다. 둘째, 재학습·롤백·기준 수정 중 하나를 고르고, 그 이유를 한 장으로 남긴다. 셋째, 롤백 절차와 이전 버전을 배포할 때 함께 보관한다. 모델을 오래 운영하는 팀은 모델을 잘 만드는 팀이 아니라, 틀렸을 때 바르게 되돌리는 팀이다. 다음 편에서는 이상 신호 대응 기록을 쌓아, 다음 모델의 학습 데이터로 바꾸는 법을 다룹니다.

관련 글: 현장 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), 데이터 드리프트(https://developer-archive.tistory.com/133), AI 모델 평가를 현장 지표로(https://developer-archive.tistory.com/164)

디지털트윈 프로젝트가 끝나고 나면 꼭 듣는 말이 있다. "화면은 예쁜데, 현장에서 잘 안 봐요." 3D 모델은 그럴듯하게 돌아가는데, 정작 라인을 지키는 운영자는 자기 모니터의 엑셀과 알람 창만 본다. 문제는 트윈이 부족해서가 아니다. 화면이 '보는 사람'의 일을 기준으로 만들어지지 않았기 때문이다.

1. 운영자는 "전체"가 아니라 "지금 내 차례"를 본다

회의실에서 만든 대시보드는 대개 공장 전체를 한눈에 보여준다. 그런데 교대 근무 중인 운영자에게 필요한 건 전체가 아니다. 지금 내 라인이 정상인지, 내가 조치해야 할 게 있는지, 그게 얼마나 급한지다. 전체 지도는 관리자의 화면이지, 운영자의 화면이 아니다.

그래서 운영자용 화면은 "오늘 내 담당 설비"부터 시작해야 한다. 담당 외 설비는 작게, 담당 설비는 크게. 알람이 있으면 원인 설비와 조치 버튼이 한 화면에 있어야 한다. 클릭 세 번을 거쳐야 원인에 닿는다면, 그 화면은 현장에서 이미 진 것이다.

2. 숫자는 "판단"으로 번역돼야 한다

진동 4.2mm/s, 온도 78도. 숫자는 정확하지만, 운영자에게는 질문만 남긴다. 이게 정상인가, 지켜봐야 하나, 지금 멈춰야 하나. 현장에서 숫자는 그 자체로 정보가 아니라, 판단의 재료다.

좋은 화면은 숫자 옆에 기준을 같이 둔다. 정상 범위, 주의 구간, 조치 기준. 그리고 더 중요한 한 줄. "지난주 같은 패턴에서는 3일 뒤 베어링 교체가 필요했다" 같은, 과거의 판단 기록이다. 트윈의 가치는 3D가 아니라, 숫자를 판단으로 바꿔주는 데 있다. 기준이 없는 숫자는 그냥 장식이다.

3. 화면은 "조치"까지 이어져야 한다

많은 트윈 화면이 "보여주기"에서 끝난다. 이상을 알려주는데, 그 다음은 운영자의 몫이다. 매뉴얼을 찾고, 담당자에게 전화하고, 이력을 뒤지는 일은 화면 밖에 있다. 그러니 화면은 안 봐도 되는 것이 된다.

조치까지 이어지는 화면은 다르다. 알람을 누르면 같은 고장의 과거 조치 이력, 점검 순서, 담당자 연락처가 바로 뜬다. 조치 결과를 입력하면 그 기록이 다음 알람의 참고자료가 된다. 화면이 일을 줄여줄 때, 운영자는 화면을 켠다. 예쁜 화면보다 "이거 보고 조치까지 끝냈다"는 경험이 먼저다.

마무리 — 트윈의 완성은 화면이 아니라 습관이다

디지털트윈을 만들 때 가장 많이 쓰는 시간은 모델링과 데이터 연결이다. 그런데 현장에서 트윈이 살아남는지는 다른 곳에서 갈린다. 운영자가 아침에 출근해서 제일 먼저 켜는 화면이 트윈인지 아닌지. 그건 기술의 문제가 아니라 설계의 문제다.

그래서 뭘 하면 되나. 다음에 트윈 화면을 만들 때, 회의실이 아니라 라인 옆에서 물어보자. "지금 화면에서 제일 먼저 보는 게 뭐예요? 그 다음엔 뭘 하세요?" 그 두 가지 답이 화면의 첫 번째 섹션이고, 나머지는 그 뒤다. 예쁜 트윈보다, 매일 켜지는 트윈이 좋은 트윈이다.

현장에 가면 센서를 달고 싶은데 달 수 없는 곳이 꼭 있다. 너무 뜨겁거나, 회전하는 부품 안쪽이거나, 배선을 끌고 오기엔 비용이 너무 큰 곳이다. 그렇다고 그 값을 모른 채 운영할 수는 없다. 이때 이미 있는 신호들을 조합해 원하는 값을 추정하는 방법이 가상 센서, 소프트 센서다. 직접 재지 않고 계산해서 만드는 센서라는 뜻이다.

1. 가상 센서가 필요한 순간

가상 센서가 빛나는 경우는 대체로 세 가지다. 첫째, 물리적으로 직접 측정이 어려운 경우다. 용융 금속의 내부 온도나 고속 회전축의 하중처럼 센서 자체가 버티지 못하는 환경이 대표적이다. 둘째, 비용과 공간의 문제다. 노후 설비 수십 대에 일일이 센서를 붙이고 배선을 새로 까는 일은 예산도, 공사 기간도 만만치 않다. 셋째, 이미 데이터는 있는데 연결이 안 된 경우다. 온도·전류·속도·압력이 따로 놀고 있을 뿐, 조합하면 원하는 값을 꽤 정확히 짐작할 수 있다.

중요한 전제가 있다. 가상 센서는 없는 데이터를 새로 만드는 마법이 아니다. 이미 현장에 흐르고 있는 신호들 사이의 관계를 찾아내는 작업이다. 입력 신호가 부실하면 출력도 부실해진다. 그래서 가상 센서 설계의 절반은 모델이 아니라, 어떤 신호를 믿을 수 있는지 고르는 일이다.

2. 가상 센서를 만드는 3가지 방식

가상 센서를 만드는 방식은 크게 세 가지다. 첫째, 물리 모델이다. 열전달·역학식 등 알려진 공식으로 계산하는 방식인데, 원리가 분명하고 변수가 적은 경우에 잘 맞는다. 조심할 점은 공식이 현실과 어긋나면 오차가 그대로 쌓인다는 것이다. 둘째, 회귀·머신러닝이다. 과거 실측값과 입력 신호의 관계를 학습하는 방식인데, 변수가 많고 관계가 복잡한 경우에 잘 맞는다. 조심할 점은 학습에 없던 조건에서는 예측이 크게 틀릴 수 있다는 것이다. 셋째, 하이브리드다. 물리식으로 뼈대를 잡고 학습으로 오차를 보정하는 방식인데, 현장 적용에서 가장 무난한 절충안이다. 조심할 점은 두 방식을 검증·관리해야 해 운영 부담이 는다는 것이다.

현장에서 자주 쓰는 순서는 하이브리드다. 먼저 물리식으로 대략의 값을 구하고, 실제 측정값과 비교해 남은 오차를 학습으로 줄인다. 예를 들어 전류와 회전 속도로 모터 부하를 추정할 때, 물리식만으로는 마찰이나 온도 영향을 다 담지 못한다. 과거 실측 데이터로 그 차이를 보정하면, 센서 없이도 부하 추이를 꽤 안정적으로 볼 수 있다.

3. 현장에서 실패하지 않게 운영하는 법

가상 센서를 만들 때보다 오래 굴릴 때가 더 어렵다. 세 가지만 챙겨도 실패가 크게 줄어든다. 첫째, 주기적 교정이다. 가끔이라도 실제 측정값과 비교해 오차가 커지면 모델을 다시 맞춘다. 둘째, 드리프트 감지다. 원료나 운전 조건이 바뀌면 입력 신호의 분포가 바뀐다. 그때는 값을 그대로 믿지 말고 경고를 띄우는 편이 낫다. 셋째, 권한을 단계적으로 주는 것이다. 처음에는 참고용·경고용으로 쓰고, 검증이 쌓인 뒤에야 제어 연동이나 자동 판정에 연결한다.

그래서 뭘 하면 되나. 첫째, 계측이 비어 있는 지점을 목록으로 적는다. 둘째, 그 지점과 관계있을 만한 기존 신호를 함께 적는다. 셋째, 한 곳만 파일럿으로 만들어 실제 측정값과 한 달간 비교해 본다. 이 세 단계를 거치지 않고 여러 개를 한꺼번에 만들면, 나중에 어느 가상값이 틀렸는지조차 추적하기 어려워진다.

마무리하자면, 센서를 더 다는 것이 항상 답은 아니다. 이미 있는 데이터를 끝까지 쓰는 설계가 가상 센서다. 직접 잴 수 없는 값을 억지로 재려 하기보다, 있는 신호 사이의 관계를 정직하게 검증하고, 틀릴 수 있다는 전제로 운영하는 것. 그 태도가 갖춰질 때 가상 센서는 현장에서 오래 살아남는다.

고장이 나면 사람들은 트윈 화면을 켭니다. 그런데 화면에 보이는 건 대부분 지금 상태뿐입니다. "지금 압력이 얼마인가"는 알 수 있지만, "10분 전에는 어땠고, 그때 작업자가 뭘 눌렀는가"는 알 수 없습니다. 7년차 현장 엔지니어로서, 저는 이 지점에서 트윈의 가치가 갈린다고 봅니다. 현재값만 보여주는 트윈은 멋진 모니터이고, 시간을 되돌릴 수 있는 트윈은 원인을 찾는 도구입니다.

1. 현재값만 보는 트윈의 함정

현장은 현재값으로만 설명되지 않습니다. 같은 온도라도 서서히 오른 경우와 갑자기 튄 경우는 원인이 다릅니다. 작업자가 설정을 바꾼 뒤 3분 만에 알람이 뜬 경우, 현재값만 보면 "알람이 뜬 설비"만 보입니다. 그 사이의 변화 곡선, 설정 변경 기록, 앞뒤 공정의 상태가 함께 있어야 원인이 보입니다. 트윈이 실시간이라는 말은 "지금 잘 보인다"는 뜻이지, "과거를 설명할 수 있다"는 뜻은 아닙니다.

2. 시간 되돌리기에 필요한 세 가지

첫째, 동기화된 시간입니다. 설비마다 시계가 조금씩 다르면, 같은 사건도 다른 시간에 찍힙니다. 원인 추적의 출발점은 모든 기록이 같은 시간축 위에 놓이는 것입니다. 둘째, 사건 마커입니다. 알람, 설정 변경, 자재 교체, 작업자 교대처럼 "이 순간에 뭔가 바뀌었다"는 표시가 있어야 재생할 구간을 찾을 수 있습니다. 셋째, 구간 재생입니다. 고장 전 10분을 1배속으로, 필요하면 느리게 다시 보는 기능이 있어야 합니다. 데이터가 있어도 구간을 못 자르면, 사람은 결국 기억에 의존하게 됩니다.

3. 현장에서 바로 적용하는 설계 3단계

먼저, 기록할 사건을 10개 이내로 정합니다. 전부 기록하려다 보면 저장도, 검색도 무너집니다. 알람, 모드 변경, 설정 변경, 자재 투입, 정지·재시작처럼 원인 추적에 직접 쓰이는 것만 남깁니다. 다음으로, 시간 동기화를 점검합니다. 설비·서버·트윈의 시계가 같은 기준을 쓰는지, 오차는 어느 정도인지 한 번만 확인해도 추적의 신뢰도가 달라집니다. 마지막으로, "고장 전 10분 재생" 시나리오 하나를 만들어 팀과 함께 돌려봅니다. 실제로 재생이 되는지, 구간을 찾는 데 몇 분이 걸리는지 재보는 것이 도입의 기준이 됩니다.

그래서 뭘 하면 되나 — 이번 주에 고장 전 10분을 되돌려 볼 수 있는지, 팀원 한 명과 함께 직접 확인해 보세요. 안 된다면 3D를 더 정밀하게 만들기에 앞서, 시간축부터 맞추는 것이 순서입니다.

관련 글: 현장 AI의 원인 추적 설계법 https://developer-archive.tistory.com/186 / 설비의 상태를 모델링하는 법 https://developer-archive.tistory.com/162 / 현장 좌표와 모델 좌표를 맞추는 법 https://developer-archive.tistory.com/202