프로그래밍 허브

현장 AI를 얘기하면 모델 얘기부터 나오지만, 모델을 현장에 두려면 결국 어딘가에 '상자'가 있어야 합니다. 서버실이 아니라 라인 옆, 설비 바로 옆에 두는 작은 컴퓨터. 엣지 장비입니다. 그런데 라인 옆은 사무실이 아닙니다. 먼지가 날리고, 여름엔 40도를 넘기고, 프레스 진동이 바닥을 통해 전해집니다. #157에서 엣지 컴퓨팅이 "현장에서 바로 계산하는 법"이라고 했는데, 그 계산을 하는 상자 자체가 현장에서 살아남아야 합니다. 오늘은 스펙표에는 없는, 공장 바닥의 엣지 장비 운영 얘기입니다.

먼지 — 팬이 먼저 막힌다

공장 먼지는 집 먼지와 다릅니다. 금속 분진, 섬유 날림, 오일 미스트가 섞여 팬 날개와 방열판 틈에 눌어붙습니다. 냉각이 안 되면 칩 온도가 오르고, 쓰로틀링이 걸려 추론이 느려집니다. "AI가 느려졌다"는 현장 제보의 원인 중 상당수가 모델이 아니라 먼지였던 적이 있습니다.

대책은 거창하지 않습니다. 팬 없는(fanless) 설계를 고르거나, 필터가 있는 장비라면 교체 주기를 달력이 아니라 온도로 정합니다. 내부 온도가 평소보다 5도만 올라도 필터를 먼저 의심합니다. 설치 위치도 중요합니다. 분진 발생원 바로 옆이나 바닥에 두지 말고, 반대편 벽면이나 상부에 두는 것만으로 먼지 유입이 확 줄어듭니다.

발열 — 여름이 오면 AI가 느려진다

여름철 공장 내부는 40도를 쉽게 넘습니다. 박스 안은 그보다 더 뜨겁습니다. 대부분의 산업용 PC는 동작 온도 상한이 50~60도인데, 직사광이나 건조로·용접 열원 근처에 두면 상한을 넘기기 쉽습니다. 온도가 임계점을 넘으면 CPU가 클럭을 낮추고, 심하면 보호 차원에서 꺼집니다. 한여름 라인 정지의 원인이 에어컨이 아니라 엣지 장비 과열인 경우도 있습니다.

설치 전에 정격 동작 온도 범위를 확인하고, 열원으로부터의 거리를 먼저 봅니다. 내부 온도를 주기적으로 기록해 두면, "어느 날부터 느려졌다"는 얘기를 "7월 셋째 주부터 내부 온도가 8도 올랐다"는 숫자로 바꿀 수 있습니다. 경고 기준을 하나 정해두는 것만으로도 여름철 대응이 달라집니다. 75도에서 경고, 85도에서 조치를 취하는 식입니다.

진동과 전원 — 조용히 죽는 두 가지

프레스나 대형 컨베이어가 있는 라인에서는 진동이 바닥을 타고 올라옵니다. 진동은 소리 없이 커넥터를 풀고, M.2 SSD를 이탈시키고, 케이블 접촉을 불안정하게 만듭니다. 전원도 마찬가지입니다. 순간 정전이나 전압 강하가 잦은 라인에서는 파일시스템이 손상돼 부팅이 안 되는 일이 생깁니다. 둘 다 "어제까지 잘 됐는데"라는 말로 시작하는 고장의 전형입니다.

방진 마운트와 케이블 고정, 록킹 커넥터는 비싼 대책이 아닙니다. 전원은 UPS나 슈퍼캡 기반의 안전 종료 회로를 달아, 전원이 끊겨도 쓰기 중이던 데이터를 마무리하고 꺼지게 만듭니다. 읽기 전용 루트 파일시스템도 같은 이유로 많이 씁니다. 장비가 꺼졌다 켜져도, 적어도 부팅은 되게 만드는 것이 목표입니다.

현장에서 바로 할 일

1. 설치 전에 확인합니다. 동작 온도 범위와 방진·방수 등급, 팬 유무를 스펙표에서 먼저 봅니다.
2. 필터와 팬을 월 1회 봅니다. 교체 주기는 달력이 아니라 내부 온도 추이로 정합니다.
3. 온도를 알람에 넣습니다. 내부 온도와 디스크 상태를 모니터링 항목에 포함해, 느려지기 전에 먼저 압니다.
4. 예비품을 한 세트 둡니다. 팬·필터·전원 어댑터는 고장 나면 바로 갈아야 하니, 현장에 한 세트씩 비치해 둡니다.

엣지 AI의 성능은 모델 정확도표가 아니라, 공장 바닥에서 몇 달을 버티느냐로 갈립니다. 먼지·발열·진동은 스펙표에 안 보이는 변수지만, 현장에서는 매일 장비의 수명을 갉아먹습니다. 상자를 설치할 때 "이 자리에 1년 뒤에도 있을 수 있나"를 한 번만 물어봐도, 나중에 "어제까지 잘 됐는데"라는 말을 줄일 수 있습니다.

관련 글: 엣지 컴퓨팅 https://developer-archive.tistory.com/157 · 설비 알람 로그 설계 https://developer-archive.tistory.com/130 · 프로토콜 선택 가이드 https://developer-archive.tistory.com/124 

AI 도입 프로젝트가 실패하는 이유를 꼽으라면, 모델 성능보다 먼저 나오는 말이 있다. "현장이 원하는 걸 잘못 들었다." 스펙 시트에 적힌 기능은 멀쩡했는데, 막상 라인을 돌려보니 아무도 안 쓴다. 그럴 때 문제는 대개 기술이 아니라, 시작점에서 현장의 말을 제대로 듣지 않은 데 있다.

1. 작업자는 '기능'이 아니라 '불편'을 말한다

현장에 가서 "어떤 AI 기능이 필요하세요?"라고 물으면 돌아오는 답은 뻔하다. "뭐, 잘 되면 좋죠" 수준이다. 그런데 질문을 바꾸면 이야기가 달라진다. "하루 일하면서 제일 귀찮은 순간이 언제예요?"라고 물으면, 그때부터 진짜가 나온다. "이 버튼 누르면 3초를 기다려야 해요", "알람이 울리는데 뭔지 몰라서 그냥 꺼요", "교대할 때 전 사람이 뭘 했는지 몰라서 처음부터 다시 봐요."

작업자는 기능을 말하지 않는다. 불편을 말한다. 그리고 불편이 곧 요구사항이다. 인터뷰는 회의실이 아니라 라인 옆에서, 10분씩, 교대조별로 나눠서 하는 게 좋다. 같은 라인이라도 오전조와 야간조의 불편은 다르다. 메모는 그 자리에서, 작업자의 말을 그대로 적는다. 요약해서 적으면 내 해석이 끼어든다.

2. 불편을 요구사항으로 바꾸는 3단계

모은 불편을 그대로 개발 목록에 올리면 안 된다. 세 단계를 거친다.

첫째, 빈도와 영향을 잰다. 하루에 열 번 일어나는 불편과 한 달에 한 번 일어나는 불편은 무게가 다르다. 둘째, AI로 풀 문제와 사람이 풀 문제를 나눈다. "알람이 너무 많다"는 알람 분류·요약 AI의 일감이지만, "센서가 자주 고장 난다"는 정비 프로세스 문제일 수 있다. 셋째, 해결 뒤 모습을 한 문장으로 적는다. "교대할 때 전 작업 내용을 30초 안에 파악한다"처럼, 측정 가능한 문장이어야 한다.

이 한 문장이 요구사항의 완성본이다. 기능 목록이 아니라, 현장의 하루가 어떻게 달라지는지를 적는 것이다.

3. 인터뷰 없이 만든 AI는 현장에서 외면받는다

현장의 참여 없이 만든 AI는 도입 첫 주에 조용히 외면받는다. 아무도 항의하지 않는다. 그냥 안 쓸 뿐이다. 반대로 작업자는 "내 말이 들어갔다"고 느끼는 순간부터 쓰기 시작한다. 피드백도 그때부터 온다. "이건 좋은데, 이 부분은 이렇게 바꾸면 더 편해요"라는 말이 나오는 AI는 이미 현장의 도구가 된 것이다.

7년차 현장 엔지니어로서, AI 도입의 첫 단계는 모델 선택이 아니라 귀를 여는 일이라고 생각한다. 설비 데이터보다 먼저 들을 것은 사람의 말이다. 데이터는 현상의 기록이지만, 불편은 원인의 방향을 알려준다.

그래서 뭘 하면 되나. 다음 주에 라인 한 곳을 골라 작업자 세 명과 10분씩 이야기해보고, 불편 열 개를 그대로 적어보는 것부터 시작하면 된다. 그 열 줄이, 다음 AI 프로젝트의 가장 정확한 요구사항 정의서가 된다.

이전 글: 공장용 AI 챗봇이 첫 주에 망한 이유 — 프롬프트가 아니라 '권한' 문제였다 https://developer-archive.tistory.com/145 · 모델이 바뀌어도 현장 AI는 살아남는다 — 프롬프트 위의 '규칙 레이어' 설계법 https://developer-archive.tistory.com/140 · 설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것 — 7년차 현장 엔지니어의 로그 설계 습관 https://developer-archive.tistory.com/130 

11월 9일, 서울 코엑스에서 열린 '엔비디아 AI 데이 서울 2026'에서 엔비디아 로보틱스·엣지 AI 부문 디푸 탈라 부사장은 "지난해 AI 모델과 시뮬레이션 기술이 성숙하면서 로봇공학의 황금기가 시작됐다"고 말했다. 이날 엔비디아는 현대자동차그룹·두산·SK하이닉스·LG전자 등 국내 기업과의 피지컬 AI 협력 사례를 한꺼번에 공개했다. 생성형 AI 다음 무대가 '몸을 가진 AI'라는 선언을, 한국 제조 현장의 이름들로 채운 셈이다.

LG 데이터 팩토리 — 50만 시간짜리 데이터 플라이휠

이날 가장 구체적인 숫자를 내놓은 건 LG전자였다. LG전자는 로봇 지능의 거점인 'LG 데이터 팩토리'를 공개하며, 데이터 수집·생성·증폭·정제·모델 학습·현장 투입·검증·배포를 잇는 데이터 플라이휠을 구축하겠다고 밝혔다. 목표 데이터 확보량은 50만 시간. 엔비디아의 아이작(Isaac) 로봇 두뇌와 코스모스(Cosmos) 합성 데이터 기술을 결합한 가속화 솔루션도 함께 소개됐다.

실증 사례도 있었다. 가전 제조 공장의 '세탁기 상판 로딩' 공정 — 약 4kg짜리 상판을 헹거에 반복해 거는 고난도 작업을 로봇이 대신 수행하도록 공정 분석을 진행한 결과다. 데모가 아니라 실제 공장 공정에서 나온 이야기라는 점이 중요하다.

현대차·두산·SK, 각자의 시험대

협력 사례는 기업마다 시험대가 달랐다. 현대차그룹과는 옴니버스와 아이작을 활용한 자동차 제조 공정 로봇 시뮬레이션, 두산과는 자동차 도어 표면을 정밀 연마하는 로봇 기술(아이작 랩·뉴턴 물리 엔진 활용), SK하이닉스·SK텔레콤과는 대규모 설비를 가상 공간에 구현하고 AI 에이전트가 이상 원인을 분석하는 디지털 트윈이다. 삼성·SK하이닉스의 반도체 공장 디지털 트윈 협력도 언급됐다.

즉 엔비디아의 전략은 '로봇 하나'가 아니라 '공장 전체를 학습 환경으로 만드는 것'이다. 시뮬레이션에서 배우고, 현장에서 검증하고, 다시 시뮬레이션으로 돌려보내는 폐쇄 루프(Closed-Loop)가 핵심 구조다.

7년차 현장 관점 — 황금기의 조건은 데이터 루프다

LG전자가 이날 스스로 꼽은 남은 과제도 눈여겨볼 만하다. 데모 수준을 넘어선 실 공장 투입용 연속 동작 성능, 가상과 실제의 차이(Sim-to-Real 갭) 최적화, 생산 계획·배치 변동에 대응하는 강건성이다. 현장에서 일해본 사람이라면 이 세 가지가 '나중에'가 아니라 '지금 당장'의 문제라는 걸 안다.

7년차 현장 엔지니어로서 한 줄로 정리하면 이렇다. 로봇이 배우는 속도보다, 현장이 데이터를 주는 속도가 병목이다. 50만 시간이라는 숫자가 중요한 이유도 여기에 있다. 모델은 공개돼 있고, 시뮬레이터도 쓸 수 있다. 없는 건 내 공정의 데이터다.

그래서 뭘 하면 되나. 거창한 로봇 도입부터 고민할 필요는 없다. 지금 굴러가는 공정 하나에서 "무슨 데이터를, 얼마나 자주, 어떤 품질로 모으는가"부터 설계하는 게 먼저다. 데이터가 쌓이는 구조가 없으면, 황금기는 남의 이야기다.

출처: 머니투데이(2026-11-09) '엔비디아 로보틱스 부사장 "韓, 피지컬 AI 핵심"…현대차·두산·SK·LG 협력 사례 공개', 위키리크스한국(2026-11-09) '[엔비디아 AI데이] LG전자, 50만 시간 데이터 확보 목표로 로봇 자율화·고도화 박차'

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

현장에 AI를 들여올 때, 대부분 검토표는 정확도와 비용으로만 채워진다. 모델 정확도가 몇 퍼센트인지, 도입 비용이 얼마인지, 투자 회수 기간이 얼마나 되는지. 그런데 정작 운영이 시작되고 나서야 알게 된다. "이 모델, 누가 매일 보지?" "경보가 울리면 누가 판단하지?" "기준이 틀렸을 때 누가 바꾸지?" 이 질문에 답이 없으면, 아무리 정확도가 높아도 현장은 그 모델을 오래 못 쓴다. 도입 검토 단계에서 운영을 설계한다는 건, 이 질문들을 정확도 질문과 같은 무게로 검토표에 올리는 일이다.

1. 도입 검토표에 '운영 담당자' 칸을 먼저 넣는다

도입 검토 회의에서 가장 먼저 물어야 할 질문은 "정확도가 몇인가"가 아니라 "이 모델을 매일 볼 사람이 있는가"다. 담당자가 없으면 점검표는 만들어지지 않고, 점검표가 없으면 경보 루틴도, 리뷰도, 재학습 판단도 없다. 시리즈 1편부터 10편까지의 내용이 전부 이 한 칸에서 시작한다.

검토 단계에서 정해야 할 운영 담당자는 세 가지 역할이다. 첫째, 매일 아침 5분 점검을 볼 사람. 둘째, 경보가 울렸을 때 판단할 사람. 셋째, 분기 리뷰에서 재학습 여부를 결정할 사람. 세 역할이 한 사람일 필요는 없다. 교대조별로 나누거나, 설비 담당과 품질 담당이 나눠 맡아도 된다. 중요한 건 도입 전에 이름이 정해져 있다는 것이다. 이름이 없는 운영은 시작되지 않는다.

2. PoC 단계에서 '운영 노트 1쪽'을 함께 만든다

PoC는 보통 정확도만 검증하고 끝낸다. 그런데 PoC는 운영을 미리 연습할 수 있는 가장 싼 기회다. PoC 기간에 운영 노트 1쪽만 만들어두면, 본 도입 때 운영 설계가 반은 끝난다. 그 1쪽에 들어갈 건 세 가지다. 첫째, PoC 기간에 울린 경보와 그때의 판단. 둘째, 기준을 바꿨던 사례가 있다면 그 이유. 셋째, 담당자가 "이건 사람이 봐야 한다"고 느낀 지점.

이 1쪽은 PoC 보고서의 부록이 아니라, 본 도입 운영 노트의 1페이지다. PoC에서 나온 판단 사례가 쌓이면, 도입 첫날부터 "이럴 때는 이렇게 판단한다"는 기준이 있다. 반대로 PoC 때 운영을 연습하지 않으면, 본 도입 첫 달은 경보 하나하나에 회의가 열리는 달이 된다.

3. 도입 조건에 '운영 지속 가능성'을 넣는다

도입 승인 조건에 정확도 목표만 적혀 있으면, 현장 AI는 "돌아가긴 하는데 아무도 안 보는 모델"이 되기 쉽다. 그래서 승인 조건에 운영 조건을 함께 넣는 것이 좋다. 예를 들어, "첫 한 달간 매일 점검표가 채워질 것" "분기 리뷰가 한 번 열릴 것" "경보 대응 기록이 10건 이상 쌓일 것" 같은 조건이다. 숫자는 작아도 된다. 중요한 건 운영이 도입 조건의 일부라는 선언이다.

7년차 현장 엔지니어로서 한 줄로 정리하면, 현장 AI의 성패는 도입 날이 아니라 도입 후 첫 한 달의 운영에서 갈린다. 그래서 뭘 하면 되나, 이번 주 할 일은 세 가지다. 첫째, 진행 중인 도입 검토표에 운영 담당자 세 역할의 이름을 적는다. 둘째, PoC가 있다면 경보 판단 기록 1쪽을 운영 노트 첫 페이지로 만든다. 셋째, 도입 승인 조건에 "첫 달 점검표·분기 리뷰·대응 기록" 같은 운영 조건 한 줄을 넣는다. 잘 도입된 현장 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 · 데이터 드리프트 https://developer-archive.tistory.com/133 · 모델 평가 현장 지표 https://developer-archive.tistory.com/164 

7년차 현장 엔지니어로서, 설비 고장을 처음 알아채는 순간은 대부분 '눈'이 아니라 '귀'나 '손'이 먼저였다. 평소와 다른 진동, 낯선 금속음, 미묘하게 뜨거워진 모터 하우징. 그런데 지금까지 현장에 들어온 AI는 대부분 한 가지 감각만 봤다. 카메라로 외관 불량을 보거나, 진동 센서 숫자로 베어링 수명을 재거나. 따로따로였다.

이제는 소리·진동·이미지를 함께 보는 '멀티모달 AI'가 제조 현장의 예지정비에 들어오고 있다. 오늘은 이 흐름이 왜 중요한지, 현장 관점에서 풀어본다.

한 가지 감각만으론 고장을 놓친다

설비는 고장 전에 여러 신호를 동시에 낸다. 베어링이 마모되면 진동 스펙트럼이 바뀌고, 윤활이 마르면 마찰음이 달라지고, 온도가 오른다. 그런데 진동만 보는 모델은 소리의 변화를 모르고, 이미지만 보는 모델은 내부 마모를 못 본다. 현장에서 "센서는 정상인데 현장은 멈췄다"는 말이 나오는 이유 중 하나가 여기에 있다. 각 센서가 따로따로 정상 범위 안에 있어도, 감각들을 합쳐 보면 이미 고장의 징조가 보이는 경우가 많다.

멀티모달 AI의 핵심은 이 '합쳐 보기'다. 진동 파형, 음향 스펙트럼, 열화상·외관 이미지를 하나의 모델이 함께 학습해, 어느 한 신호만으로는 애매한 상태를 더 일찍, 더 정확하게 잡아낸다.

그래서 뭘 하면 되나 — 감각을 합치는 순서

현장에서 멀티모달을 도입할 때, 한 번에 모든 센서를 붙이려 하면 실패한다. 내가 권하는 순서는 이렇다.

첫째, 지금 고장이 잦은 설비 하나를 고른다. 둘째, 그 설비의 고장 이력을 뒤져서 "고장 전에 어떤 신호가 먼저 바뀌었는지"를 사람 눈으로 먼저 확인한다. 진동이 먼저였는지, 소리가 먼저였는지. 셋째, 먼저 바뀐 신호 하나와 그다음 신호 하나, 두 가지만 묶어본다. 두 감각이 합쳐졌을 때 오탐이 얼마나 줄었는지를 숫자로 확인하고, 그다음에 세 번째 감각을 더한다.

이 순서가 중요한 이유는, 멀티모달의 가치가 '센서를 많이 붙이는 것'이 아니라 '어떤 감각의 조합이 고장을 가장 일찍 잡는지'를 아는 데 있기 때문이다. 센서를 늘리는 건 비용이고, 조합을 아는 건 설계다.

현장에서 조심할 것 두 가지

첫째, 동기화다. 소리·진동·이미지의 시간축이 어긋나면 모델은 엉뚱한 상관관계를 배운다. 샘플링 주기와 타임스탬프를 먼저 맞추는 게 모델 성능보다 앞선다. 둘째, '설명 가능성'이다. 여러 감각이 합쳐진 판단은 "왜 고장이라고 했나"를 설명하기 더 어려워진다. 어느 신호가 판단에 얼마나 기여했는지, 현장 사람이 확인할 수 있는 형태로 남겨두는 설계가 필요하다. 설명이 안 되는 AI는 현장에서 두 번 쓰이지 않는다.

마무리

멀티모달 AI는 "더 똑똑한 센서"가 아니라 "고장을 더 일찍 알아채는 눈·귀·손의 조합"이다. 한 가지 감각에 의존하던 예지정비가 여러 감각을 함께 보는 쪽으로 넘어가는 지금, 현장 엔지니어가 할 일은 새 모델을 외우는 게 아니다. 우리 설비가 고장 전에 어떤 순서로 신호를 내는지, 그 순서를 아는 것부터다. 그 순서를 알면, 어떤 AI를 들여와도 어디에 붙여야 할지 보인다.

관련 글: 예지정비 심화 https://developer-archive.tistory.com/126 · 디지털트윈 실시간 조건 https://developer-archive.tistory.com/132 · AI 모델 평가 https://developer-archive.tistory.com/164 

공장 전기요금 고지서를 받아본 적 있으신가요? 전체 사용량은 보이는데, 어느 설비가 얼마나 먹는지, 언제 새는지는 안 보입니다. 현장에서는 "대기 전력"이라는 말이 자주 나옵니다. 설비가 일하지 않는데도 전기를 먹고 있다는 뜻입니다. 문제는 그게 어느 설비인지, 얼마나 새는지 숫자로 아는 사람이 거의 없다는 겁니다.

그래서 에너지 관리는 절전 캠페인으로 시작하면 안 됩니다. 먼저 설비별 전력 데이터를 보이게 만드는 일부터 해야 합니다. 전력량계를 붙이고, 그 숫자를 디지털트윈에 올리는 것. 트윈은 3D 모델이 아니라 데이터를 모으는 그릇이라는 #124의 얘기와 같은 맥락입니다. 전력이 보이기 시작하면, 낭비는 생각보다 빨리 드러납니다.

전력 데이터는 어디서, 어떻게 모으나

설비별 전력을 보려면 측정 지점부터 정해야 합니다. 가장 쉬운 시작은 분전반 단위입니다. 라인별·공정별 사용량을 먼저 보고, 그다음 낭비가 의심되는 설비에 개별 계측기를 답니다. 전 설비에 한 번에 붙이려 하면 비용도, 공사도 커집니다. 의심 가는 곳부터, 한 대씩이 현실적인 순서입니다.

데이터 수집은 기존 통신 인프라를 재활용하는 게 좋습니다. 전력량계는 대부분 모드버스나 펄스 출력을 갖고 있어, #124에서 다룬 프로토콜 선택 가이드를 그대로 적용할 수 있습니다. 수집 주기는 1분이 적당합니다. 1초 단위는 트래픽만 늘리고, 1시간 단위는 낭비의 원인을 놓칩니다. 수집한 데이터는 설비명·라인·시간을 붙여 저장합니다. "몇 시에, 어떤 설비가, 얼마나 썼는지"가 나중에 분석의 재료가 됩니다.

트윈에 올리면 보이는 3가지 낭비

전력 데이터를 트윈에 올리는 이유는 '보는 것' 자체가 아니라, 설비 상태와 겹쳐서 보는 데 있습니다. 생산 상태·가동 여부·전력을 한 화면에 올리면, 그동안 가려져 있던 낭비 세 가지가 드러납니다.

첫째, 대기 전력입니다. 생산이 멈춘 시간에도 전력을 먹는 설비가 의외로 많습니다. 히터가 식지 않게 유지되는 설비, 펌프가 공회전하는 라인, 꺼지지 않은 집진기 같은 것들입니다. 대기 중 전력만 따로 모아보면, "이건 꺼도 되는가"를 판단할 근거가 생깁니다. 트윈에서는 비가동 시간대 전력 곡선으로 확인하고, 현장에서는 대기 모드 전환·전원 차단 기준을 마련해 대응합니다.

둘째, 피크 시간대의 겹침입니다. 설비들이 동시에 가동되면 계약 전력을 넘길 수 있고, 요금은 기본요금 구간이 올라갑니다. 시간대별 전력 곡선을 트윈에서 보면, 어느 설비의 시작 시간을 10분만 미뤄도 피크가 낮아지는 경우가 보입니다. 순서를 바꾸는 것만으로 요금이 줄 수 있다는 뜻입니다. 트윈에서는 시간대별 설비 전력 합산으로 확인하고, 현장에서는 가동 순서 조정으로 피크를 분산시켜 대응합니다.

셋째, 설비 이상 징후입니다. 같은 제품을 만드는데 전력 사용량이 조금씩 늘고 있다면, 설비가 노후화되고 있다는 신호일 수 있습니다. 베어링 마모, 필터 막힘, 냉각 효율 저하는 전력 곡선에 먼저 나타납니다. 예지정비의 관점에서 전력은 진동만큼이나 정직한 신호입니다. 트윈에서는 동일 생산 조건 대비 전력 증가로 확인하고, 현장에서는 점검·정비 시점 판단 근거로 활용합니다.

현장에서 바로 할 일

- 분전반 단위부터 측정합니다. 라인별 사용량만 보여도, 어느 라인이 전기를 많이 먹는지부터 보입니다. 개별 계측기는 그다음입니다.

- 생산 상태와 함께 봅니다. 전력 숫자만 따로 보면 의미가 없습니다. 가동·대기·정지 상태와 겹쳐야 낭비가 보입니다.

- 작은 개선부터 숫자로 증명합니다. "히터 대기 전력을 줄였더니 한 달에 이만큼"처럼, 개선 전후를 같은 화면에서 보여주면 다음 개선의 동력이 됩니다.

에너지 관리는 거창한 시스템 도입이 아니라, 설비별 전력이라는 숫자 하나를 보이는 데서 시작합니다. 트윈에 올린 전력 데이터는 절전의 근거이자, 설비 상태를 읽는 또 하나의 센서가 됩니다. 전기가 새는 곳을 아는 것, 그게 스마트팩토리 에너지 관리의 첫걸음입니다.

함께 읽으면 좋은 글:

프로토콜 선택 가이드 https://developer-archive.tistory.com/124

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

디지털트윈-MES 경계 https://developer-archive.tistory.com/139

도입

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

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