프로그래밍 허브

휴머노이드가 공장에 들어온다는 뉴스가 쏟아진다. 테슬라 옵티머스, Figure 02의 BMW 라인 투입, 구글 제미나이 로보틱스 2.5의 메르세데스 실증까지. 그런데 오늘(11월 11일) 정부가 내놓은 발표는 시선을 전혀 다른 곳으로 돌린다. 모델이 아니라 부품이다.

정부는 이날 비상경제장관회의에서 '초혁신경제 선도 프로젝트 신규 과제 추진 계획'을 발표했다. 피지컬 AI 핵심부품 3개 분야 — 차세대 센서, 액추에이터, 휴머노이드용 이차전지 — 를 미래 성장동력으로 키우겠다는 내용이다. 액추에이터 등 로봇 핵심부품 기술개발 사업에는 2029년까지 총 1,000억 원 규모가 투입된다.

1. 숫자가 말해주는 현실 — 구동부 국산화율 19.7%

가장 눈에 들어오는 숫자는 국산화율이다. 국내 로봇 부품 국산화율은 2023년 기준 44.9%. 그런데 액추에이터를 포함한 구동부 국산화율은 19.7%에 불과하다. 액추에이터는 로봇의 팔·다리·손가락을 움직이는 부품으로, 휴머노이드 원가의 60~70%를 차지한다.

정부의 목표는 이 국산화율을 80%까지 끌어올리는 것이다. 2029년 상용화를 목표로 고출력·고내구성·경량 액추에이터 핵심기술 개발을 지원하고, 국산 부품의 실증을 통해 조기 상용화를 추진한다.

현장에서 일하는 입장에서 이 숫자는 낯설지 않다. 로봇이 멈추는 이유는 대부분 모델이 아니라 구동부다. 모터가 뜨거워지고, 감속기가 마모되고, 케이블이 끊어진다. AI가 아무리 똑똑해져도, 몸이 버티지 못하면 라인은 선다. 부품 국산화율이 낮다는 건 곧 유지보수 리드타임이 길고, 고장 한 번에 라인이 길게 멈추는다는 뜻이다.

2. 센서 안에 AI를 넣는다 — '온-센서 AI'와 휴머노이드 배터리

두 번째 축은 차세대 센서다. 핵심은 센서 내부에서 AI 연산을 수행하는 '온-센서 AI' 기술이다. 2027년 원천기술 확보, 2028년 모듈 시제품, 2029년 센서 소자·신호변환칩·AI 반도체를 결합한 통합 모듈, 2030년 시스템 시제품 실증 순으로 간다. 온-센서 AI 반도체 기술개발에는 내년부터 2030년까지 국비 498억 원이 투입된다.

세 번째 축은 휴머노이드용 이차전지다. 2027년 배터리 표준 개발, 2028년 소재·셀 개발, 2029년 실증을 거쳐 2030년 상용화가 목표다. 휴머노이드가 하루 종일 일하려면 가볍고 오래 가는 배터리가 필수인데, 이 역시 지금은 해외 의존도가 높은 영역이다.

같은 날 열린 '2026 초혁신경제 포럼'에서도 같은 얘기가 나왔다. 윤국진 KAIST AI대학장은 피지컬 AI의 제조 현장 적용을 위해 핵심부품 경쟁력 강화와 실제 작업 환경에서의 성능 검증이 필요하다고 짚었다. 부품 개발과 현장 실증은 한 묶음이라는 얘기다.

3. 그래서 현장에서는 뭘 보면 되나

7년차 현장 엔지니어로서, 이 발표에서 진짜로 봐야 할 건 돈의 규모가 아니라 '어디에 먼저 쓰이느냐'다. 정부가 로봇·방산·모빌리티 분야를 대상으로 단계별 개발을 진행한다고 밝힌 만큼, 제조 현장에 들어올 첫 수혜는 방산·모빌리티 같은 검증 환경이 갖춰진 곳부터일 가능성이 크다.

그래서 뭘 하면 되나 — 당장 할 일은 세 가지다. 첫째, 우리 라인에 들어올 로봇의 구동부·센서가 어느 회사 부품인지, 국산 대체품이 있는지 지금부터 파악해둘 것. 둘째, 부품 교체 주기와 고장 모드를 로그로 남겨둘 것. 국산 부품 실증이 시작되면 현장 데이터가 있는 곳이 먼저 테스트베드가 된다. 셋째, 온-센서 AI처럼 '센서 단에서 판단하는' 구조가 들어오면 기존 PLC·엣지 아키텍처와 어떻게 붙일지 미리 그려둘 것.

피지컬 AI의 승부는 이제 모델 성능이 아니라 '몸값'과 '몸의 내구성'에서 갈린다. 로봇이 공장에 들어오는 속도를 정하는 건 결국 부품이다. 1,000억 원이 어디에 어떻게 쓰이는지, 앞으로 3년이 그 답을 가른다.

관련 글: LG 클로이드 https://developer-archive.tistory.com/166  · 테슬라 옵티머스 https://developer-archive.tistory.com/161  · 인티그리트 예측형 피지컬 AI https://developer-archive.tistory.com/149

출처: 이투데이, "정부, 피지컬 AI 핵심부품 키운다…로봇부품 개발에 1000억 투입", 2026-11-11 / 뉴시스, "차세대 센서·액추에이터·로봇용 이차전지, 미래 성장동력으로 키운다", 2026-11-11 / 이투데이, "피지컬 AI, 제조 현장 적용 어떻게…재경부 초혁신경제 포럼", 2026-11-11

이 글은 '현장 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). 10편에서는 이렇게 쌓인 운영 기록을 팀 인수인계 자료로 바꾸는 법을, 11편에서는 도입 검토 단계부터 운영을 설계하는 법을, 12편에서는 운영 노트를 여러 라인으로 넓힐 때 기준을 맞추는 3가지 방법을 다뤘습니다 (EP.10 https://developer-archive.tistory.com/220 · EP.11 https://developer-archive.tistory.com/233 · EP.12 https://developer-archive.tistory.com/238). 이번 편에서는 여러 공장의 운영 노트를 한데 모아, 현장 AI의 '운영 대시보드'를 만드는 법을 다룹니다.

운영 노트가 라인 하나에서 잘 돌기 시작하면, 다음 질문은 꼭 이걸로 온다. "그럼 다른 공장 것도 한 화면에서 볼 수 있나?" 각 공장의 운영 노트를 한데 모아 대시보드를 만들자는 얘기다. 그런데 공장마다 노트를 그대로 합치면, 대시보드는 금방 숫자의 무덤이 된다. A공장 경보 120건, B공장 경보 80건, C공장 경보 200건. 숫자는 모였는데, 그래서 어느 공장이 위험한지, 어디부터 가봐야 하는지는 안 보인다. 운영 대시보드의 본질은 숫자를 모으는 게 아니라, '어디를 먼저 봐야 하는지'를 한눈에 보여주는 일이다.

1. 대시보드는 '공장별 숫자'가 아니라 '판단 순서'를 보여준다

여러 공장의 대시보드를 만들 때 가장 흔한 실수는, 공장마다 같은 지표를 나란히 붙이는 것이다. 경보 횟수, 대응 시간, 재학습 주기를 공장별로 표로 나열하면 보기는 깔끔한데, 보는 사람은 그 표를 보고도 다음 행동을 정하지 못한다. C공장 경보가 200건이면, 그게 많은 건지 적은 건지, 가봐야 하는 건지 지켜봐도 되는 건지 표만으로는 모른다.

그래서 대시보드의 첫 화면은 지표가 아니라 '오늘 볼 곳'이어야 한다. 기준을 넘은 공장을 먼저 보여주고, 그다음에 왜 기준을 넘었는지 보여주는 순서다. 예를 들어, 경보 대응이 24시간 넘게 안 끝난 공장이 있으면 그 공장을 맨 위에 올린다. 대응이 늦은 이유가 재학습 대기인지, 담당자 부재인지, 기준 자체의 문제인지를 두 번째 화면에서 보여준다. 숫자는 그 뒤에 온다. 대시보드는 보고용이 아니라, 아침에 "오늘은 여기부터 간다"고 정하는 도구다.

2. 공장마다 다른 건 숫자, 같이 보는 건 '상태'다

지난 편에서 기준은 '중앙 뼈대 + 현장 숫자'로 나눈다고 했다. 대시보드도 같은 원리로 만든다. 공장마다 경보 임계값이 다르고, 설비도 다르고, 공정이 다르다. 그래서 경보 횟수 같은 절대 숫자를 공장끼리 직접 비교하면, 조건이 다른 걸 같은 잣대로 재는 꼴이 된다.

비교할 수 있는 건 숫자가 아니라 '상태'다. 각 공장의 AI가 지금 정상인지, 주의인지, 대응 중인지, 세 가지 상태로만 나눠서 보여주는 것이다. 상태의 기준은 공장마다 다르다. A공장은 경보 3건이면 주의 상태고, B공장은 경보 30건이 일상이다. 하지만 상태는 같다. "주의"라는 말은 어느 공장이든 "지금 확인이 필요하다"는 같은 뜻이다. 대시보드에서 공장끼리 비교하는 건 숫자가 아니라 상태이고, 상태가 같아야 어느 공장을 먼저 봐야 하는지 정할 수 있다. 상태가 정리되면, 그제야 숫자(경보 횟수, 대응 시간, 재학습 주기)를 들여다볼 이유가 생긴다.

3. 대시보드는 '한 장'으로 시작하고, '한 달'에 한 번 고친다

운영 대시보드를 처음부터 완벽하게 만들려고 하면, 지표 정의 회의만 한 달이 간다. 공장마다 보여주고 싶은 게 다르고, 다 넣다 보면 화면이 열 개가 된다. 그래서 대시보드는 한 장으로 시작하는 게 맞다. 첫 장에는 딱 세 가지만 둔다. 첫째, 오늘 볼 공장(상태가 주의 이상인 곳). 둘째, 각 공장의 상태. 셋째, 대응이 가장 오래 걸리고 있는 건 한 줄. 이 세 가지만 있어도 대시보드는 이미 "오늘 어디부터 가는지"를 정해준다.

그리고 한 달에 한 번, 대시보드를 고친다. 한 달 돌려보면 어떤 숫자는 한 번도 안 보고, 어떤 질문은 대시보드에 없어서 매번 전화로 묻는다는 게 보인다. 안 본 숫자는 빼고, 전화로 묻던 질문을 화면에 넣는다. 대시보드는 만드는 날 완성되는 게 아니라, 한 달씩 돌리며 현장의 질문에 맞춰지는 도구다. 7년차 현장 엔지니어로서 한 줄로 정리하면, 운영 대시보드는 공장들의 숫자를 모으는 화면이 아니라 "오늘 어디부터 볼지"를 정해주는 한 장의 화면이다. 그래서 뭘 하면 되나, 이번 주 할 일은 세 가지다. 첫째, 우리 현장의 공장(또는 라인)별 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://developerarchive.tistory.com/133), 모델 평가 현장 지표(https://developer-archive.tistory.com/164)

예지정비 알람이 울렸습니다. "3번 컨베이어 모터, 베어링 고장 확률 82%." 그런데 현장에서 진짜로 필요한 답은 그게 아니었습니다. "그래서 지금 뭘 해야 하죠? 이번 주말 정기보수 때 교체하면 되나요, 당장 세워야 하나요?"

예측 AI는 질문의 절반만 답해 줍니다. 2026년 제조 AI의 흐름은 그 나머지 절반, 즉 '처방'으로 넘어가고 있습니다.

예측은 절반의 답이다

예지정비는 분명히 진전했습니다. 진동·온도 센서가 이상을 잡고, 모델이 고장 확률을 숫자로 내줍니다. 그런데 숫자만으로는 작업 지시가 되지 않습니다. 같은 "고장 확률 80%"라도, 다음 정기보수까지 버틸 수 있는 설비와 당장 세워야 하는 설비는 대응이 완전히 다릅니다.

현장에서 알람이 무시되는 이유도 여기에 있습니다. "언제 고장 날지"만 알려주고 "지금 무엇을, 어떤 순서로, 누구와" 해야 하는지 말해주지 않으면, 알람은 결국 또 하나의 소음이 됩니다. 예측의 정확도를 90%에서 95%로 올리는 것보다, 예측 뒤에 붙는 '다음 행동'을 설계하는 게 먼저입니다.

처방형 AI는 무엇이 다른가

처방형 정비(Prescriptive Maintenance)는 예측 결과에 결정 엔진을 붙인 것입니다. "베어링 마모가 진행 중입니다"에서 끝나지 않고, "이번 주 정기보수 시간에 교체하세요. 예비품은 창고 2번 선반에 있고, 교체 후 진동 기준값은 이렇게 다시 잡으세요"까지 이어집니다.

IoT Analytics의 2026년 분석도 같은 방향을 가리킵니다. 이제 병목은 예측 정확도가 아니라, 숙련 정비사의 노하우가 빠져나가는 '지식 손실'이라는 것입니다. 베테랑이 은퇴하면 "이 설비는 이런 소리가 나면 윤활부터 보라"는 판단이 함께 사라집니다. 처방형 AI는 센서 데이터에 수리 절차·매뉴얼·과거 조치 이력을 함께 엮어, 그 판단을 시스템 안에 남기는 쪽으로 가고 있습니다.

현장에서 시작하는 법

거창하게 시작할 필요는 없습니다. 알람 하나에 '다음 행동' 한 줄을 붙이는 것부터입니다.

첫째, 알람마다 조치 항목을 함께 기록합니다. 어떤 부품을, 어떤 공구로, 누가, 얼마나 걸려서 교체했는지. 이 기록이 쌓여야 AI가 "다음엔 이렇게 하라"는 말을 할 수 있습니다. 둘째, 오탐을 따로 셉니다. 처방이 틀린 횟수가 쌓이면 현장은 처방 자체를 안 믿게 됩니다. 오탐이 왜 났는지, 기준값을 어떻게 고쳤는지까지 남겨야 합니다. 셋째, 처음부터 자동 실행하지 않습니다. 처방은 사람이 승인하는 구조로 두고, 승인·거절 이력을 다시 학습 데이터로 씁니다.

7년차 현장 엔지니어로서, 저는 이렇게 봅니다. 예측 AI가 "언제"를 알려줬다면, 처방형 AI는 "어떻게"를 알려주는 단계입니다. 그래서 뭘 하면 되나 — 내일 아침, 가장 자주 울리는 알람 하나를 골라 그 뒤에 "그래서 뭘 해야 하는지"를 한 줄로 적어보세요. 그 한 줄이 모이면, 우리 현장만의 처방집이 됩니다.

관련 글: 제조AI 용어 사전 EP.1 — 예지정비 https://developer-archive.tistory.com/126 · 디지털트윈이 '실시간'이 되는 조건 https://developer-archive.tistory.com/132 

출처: IoT Analytics 분석 (IoT Business News, 2026-06-16) — 산업 AI, 예측에서 지식 보존·처방형 정비로 이동

현장 AI를 얘기하면 정확도부터 물어봅니다. "몇 % 맞히나요?" 그런데 현장에서 진짜 무서운 건 모델이 틀리는 게 아니라, 틀릴 만한 상황에서 아무렇지 않게 답하는 겁니다. 센서가 얼어붙은 값을 보내고 있는데도 "정상"이라고 답하고, 본 적 없는 불량 패턴에 "양품"이라고 답하는 것. 그래서 저는 모델을 현장에 두기 전에, 모델이 답하면 안 되는 경우를 먼저 정합니다. 그걸 '운영 범위'라고 부릅니다. 답할 수 있는 조건의 목록입니다.

운영 범위란 무엇인가

운영 범위는 모델이 답해도 되는 조건을 미리 적어둔 목록입니다. 크게 세 가지로 나뉩니다. 첫째, 입력 범위입니다. 센서 값이 어느 구간 안에 있어야 하는지, 이미지 밝기나 초점 같은 품질 조건은 어떤지. 둘째, 설비 상태입니다. 라인이 정상 가동 중일 때만 답할 것인지, 예열 중이나 청소 중에도 답할 것인지. 셋째, 데이터 품질입니다. 결측이 몇 %를 넘으면, 같은 값이 몇 분째 그대로면 답하지 않을 것인지.

범위를 벗어난 입력에 모델이 낸 답은, 정확도가 아니라 추측입니다. 추측을 현장 판단에 쓰면 안 됩니다. 범위 밖에서는 "모른다"가 정답입니다. "모른다"를 설계에 넣는 것, 그게 운영 범위의 시작입니다.

범위를 정하는 3가지 질문

어떤 입력인가 — 진동 센서 값이 평소 범위의 2배이면 센서 고장 의심, 답하지 않는다.

어떤 설비 상태인가 — 예열 중, 청소 중, 교체 직후이면 정상 가동 상태가 아니면 답하지 않는다.

결과가 어디까지 가나 — 불량 판정이 라인 정지로 이어지면 영향이 크면 사람 확인을 거친다.

이 표를 채우는 방법은 간단합니다. 지난 3개월의 장애 기록을 펼쳐서, "그때 모델이 답했어야 했나"를 한 건씩 물어보는 겁니다. 답하면 안 됐던 날이 곧 범위의 경계가 됩니다. 경계는 처음부터 완벽할 필요가 없습니다. 한 달에 한 번, 기각 로그를 보며 경계를 다듬으면 됩니다.

범위 밖이면 어떻게 할 것인가

범위 밖 입력이 들어오면 세 가지를 합니다. 첫째, 답하지 않고 기각합니다. "판정 불가"라는 답을 내는 겁니다. 둘째, 사람에게 넘깁니다. 기각된 건은 작업자나 엔지니어의 확인 대기열로 갑니다. 셋째, 안전 상태를 유지합니다. 라인을 세우는 게 아니라, 마지막으로 확인된 안전한 상태를 유지하면서 사람을 기다립니다.

그리고 기각은 그냥 버리지 않습니다. 기각 로그를 남깁니다. 어떤 입력이, 왜 범위 밖이었는지. 이 로그가 쌓이면 두 가지가 보입니다.  하나는 기준이 잘못된 경우 — 범위를 너무 좁게 잡아 멀쩡한 입력까지 기각하는 경우. 다른 하나는 현장이 바뀐 경우 — 새 설비나 새 자재 때문에 입력 분포 자체가 달라진 경우. 기각률이 갑자기 오르면, 모델이 아니라 현장이 먼저 바뀐 신호일 수 있습니다.

현장에서 바로 할 일

한 장짜리 운영 범위 문서를 씁니다. 입력 범위·설비 상태·데이터 품질, 세 가지만 적습니다.

범위 밖 답은 "판정 불가"로 통일합니다. 애매한 답보다 명확한 기각이 현장에서는 안전합니다.

기각 로그를 월 1회 봅니다. 기각이 늘면 기준을 넓힐지, 현장이 바뀐 건지부터 확인합니다.

모델의 실력은 맞힌 개수로만 보이지 않습니다. 답하면 안 되는 곳에서 입을 다무는 것도 실력입니다. 운영 범위를 먼저 정해두면, 모델은 틀릴 만한 날에 조용해지고, 사람은 그 조용함을 보고 현장에 먼저 갑니다. 그게 현장 AI가 현장에서 오래 살아남는 방법이라고, 저는 생각합니다.

관련 글: 확신도 활용법 https://developer-archive.tistory.com/203 · 라벨링 기준 통일 https://developer-archive.tistory.com/204 · 행동 권한 https://developer-archive.tistory.com/167 · 규칙 레이어 https://developer-archive.tistory.com/140 

설비 3D 모델은 정밀한데, 정작 그 앞을 오가는 사람은 트윈에 없다. 그래서 시뮬레이션은 늘 "설비만 있는 공장"을 돌리고, 현장은 "사람이 있는 공장"에서 돌아간다. 그 간극이 예측이 빗나가는 첫 번째 이유다.

왜 사람까지 모델에 넣어야 하나

설비의 상태는 센서가 알려주지만, 작업자의 동선은 아무도 트윈에 안 넣는다. 그런데 같은 설비도 누가 다루느냐에 따라 가동률이 달라진다. 숙련자는 고장 전 징후를 손으로 느끼고, 신입은 알람이 뜬 뒤에야 멈춘다. 트윈이 이 차이를 모르면, "이상 없음"이라는 판정만 내놓는다.

7년차 현장 엔지니어로서, 트윈이 현장과 어긋나는 이유의 절반은 설비 모델이 아니라 사람 모델의 부재라고 본다. 설비는 데이터를 내뿜는데, 사람은 데이터가 아니라 행동으로 현장을 바꾼다.

사람 모델의 3가지 층

첫째, 동선이다. 작업자가 어떤 경로로 움직이는지, 어느 설비 앞에 얼마나 머무는지. 이건 UWB 태그나 카메라 기반 위치 추적으로 이미 잴 수 있다. 동선을 넣으면 "왜 이 구간만 가동률이 낮은가"가 보인다. 답은 설비가 아니라 이동 거리일 때가 많다.

둘째, 숙련도다. 같은 작업도 숙련자에겐 10분, 신입에겐 25분이다. 작업 시간의 분산을 개인별 숙련도 곡선으로 모델링하면, 생산 계획의 오차가 눈에 띄게 줄어든다. 중요한 건 사람을 평가하는 게 아니라, 계획의 전제를 현실에 맞추는 것이다.

셋째, 개입 패턴이다. 알람이 떴을 때 누가, 얼마나 빨리, 어떤 순서로 대응하는가. 이 패턴을 트윈에 넣으면 "알람 100건 중 몇 건이 실제로 조치됐는지"가 보인다. 조치되지 않은 알람은 센서 문제가 아니라 사람 문제일 수 있다.

작게 시작하는 방법

사람 모델이라고 해서 전 직원의 디지털 휴먼을 만들 필요는 없다. 라인 하나, 교대조 하나부터 시작하면 된다. 동선은 한 구역만, 숙련도는 작업 시간 분산만, 개입 패턴은 알람 대응 시간만. 이 세 가지만 넣어도 트윈의 예측은 "설비 중심"에서 "현장 중심"으로 바뀐다.

그래서 뭘 하면 되나 — 이번 주, 우리 라인에서 가장 오래 머무는 작업자 동선 구간 하나를 골라 지도에 그려보자. 설비 배치가 아니라 사람의 움직임이 보이는 순간, 트윈이 왜 현장과 달랐는지 답이 나온다.

관련 글:

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

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

같은 설비인데 트윈 속 위치가 다르다 — https://developer-archive.tistory.com/202 

오늘(11월 10일) HD현대로보틱스가 피지컬 AI 소식 두 가지를 한 번에 전했다. 자체 개발한 '지능형 양팔로봇' 공개, 그리고 팔란티어와의 협력으로 로봇 작업 개선 기간을 63% 단축했다는 발표다. 따로 보면 로봇 뉴스지만, 붙여 보면 현장 AI의 다음 단계가 보인다. 로봇이 손을 얻은 것보다, 로봇을 현장에 맞추는 속도가 빨라진 게 더 큰 뉴스다.

양팔 로봇의 진짜 관건은 '손'이 아니라 '판단'이다

이 로봇은 사람의 상체처럼 두 팔과 다섯 손가락을 갖췄다. 양팔은 각각 7kg의 가반하중과 630mm의 작업 반경을 확보했다. 스펙만 보면 기존 협동로봇과 크게 달라 보이지 않을 수 있다. 차이는 안에 있다. HD현대로보틱스가 자체 개발한 로봇 파운데이션 모델을 탑재해, 주변 환경을 인식하고 작업에 필요한 동작을 스스로 생성하는 것이 특징이다.

투입 순서는 부품 묶음(키팅)과 조립 공정부터, 이후 용접·도장으로 넓힌다. 향후 바퀴형 이동 플랫폼과 이족보행 기술도 적용할 방침이다.

7년차 현장 관점으로 보면, 키팅과 조립은 "정해진 동작의 반복"이 아니라 매번 조금씩 다른 부품을 집고 놓는 일이다. 로봇이 동작을 스스로 만든다는 건 티칭 시간을 줄이는 차원이 아니라, "가르치는 방식" 자체가 바뀐다는 뜻이다.

더 주목할 숫자는 63% — AI 에이전트가 바꾼 '개선 기간'

팔란티어와의 협력은 로봇 자체보다 로봇을 현장에 들이는 과정을 겨냥했다. 양사는 지난 8월부터 로봇 프로그램 개선 과정에 AI 에이전트를 도입했고, 관련 작업에 걸리는 기간이 평균 21.5일에서 7.9일로 약 63% 줄었다. HD현대로보틱스는 로봇 프로그래밍 비용도 50% 이상 절감할 수 있을 것으로 기대하고 있다. HD현대로보틱스 안성환 최고기술책임자(CTO)는 최근 뉴욕에서 열린 팔란티어 '소버리니티 부트캠프'에서 기조연설을 하며 이 협력을 소개했다.

현장에서 로봇 도입이 막히는 지점은 대개 로봇값이 아니다. 라인에 맞게 고치고, 다시 고치고, 또 고치는 시간이다. 21.5일이 7.9일이 됐다는 건 파일럿이 양산으로 넘어가는 문턱이 낮아졌다는 뜻이다. 이 숫자가 중요한 이유는, 로봇 스펙은 카탈로그에 적히지만 개선 기간은 현장의 일정표에 그대로 찍히기 때문이다.

그래서 뭘 하면 되나 — 현장 엔지니어의 체크리스트

첫째, 로봇 파운데이션 모델이 들어오는 라인은 "티칭 데이터"가 자산이 된다. 지금부터라도 키팅·조립 공정의 작업 영상과 실패 사례를 모아둘 것. 모델은 잘한 동작보다, 틀렸던 동작에서 더 많이 배운다.

둘째, AI 에이전트 도입을 검토한다면 먼저 "개선 작업이 어디서 시간을 잡아먹는지"부터 측정할 것. 21.5일이라는 기준선이 있어야 63% 단축이 의미가 있다. 측정 없는 도입은 효과도, 책임도 흐려진다.

셋째, 양팔 로봇은 아직 고정형에 가깝다. 이동 플랫폼과 이족보행이 붙기 전까지는 "어느 공정부터 고정형 양팔로 바꿀지"를 정하는 게 먼저다. 로봇이 걸어 다니기를 기다리기보다, 지금 자리에서 손이 필요한 공정을 찾는 쪽이 빠르다.

로봇이 손을 얻었다는 소식은 화려하다. 하지만 현장에서 진짜로 체감되는 변화는 그 손을 내 공정에 맞추는 데 걸리던 3주가 1주일로 줄었다는 사실이다. 피지컬 AI 경쟁의 승부는 로봇 스펙이 아니라, "현장에 안착시키는 속도"에서 갈릴 것이다.

7년차 현장 관점 한 줄: 로봇 도입의 병목은 로봇값이 아니라 가르치는 비용이다 — 21.5일이 7.9일이 됐다는 건, 그 병목이 처음으로 숫자로 줄었다는 뜻이다.

출처: 더팩트(2026-11-10) "HD현대로보틱스, 팔란티어와 피지컬 AI 협력 확대…지능형 양팔로봇도 선보여" https://news.tf.co.kr/read/economy/2386816.htm, 매일경제(2026-11-10) "HD현대로보틱스, 팔란티어 손잡고 피지컬 AI 승부수" https://www.mk.co.kr/news/business/12203529 

이 글은 '현장 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). 10편에서는 이렇게 쌓인 운영 기록을 팀 인수인계 자료로 바꾸는 법을, 11편에서는 도입 검토 단계부터 운영을 설계하는 법을 다뤘습니다 (EP.10 https://developer-archive.tistory.com/220). 이번 편에서는 그 운영 노하우를 한 라인에서 여러 라인, 여러 공장으로 넓힐 때 기준을 어떻게 맞추는지 다룹니다.

한 라인에서 잘 돌아가던 운영 노트가 두 번째 라인에 가면 어긋나기 시작한다. A라인에서는 "경보가 하루 3번 울리면 점검"인데, B라인에서는 같은 경보가 하루 30번 울린다. 담당자는 "B라인이 더 망가진 거냐"고 묻고, 나는 "아니요, 기준이 다를 뿐입니다"라고 답해야 했다. 운영 노트를 넓히는 일의 본질은, 노트를 복사하는 게 아니라 기준을 맞추는 일이다. 기준이 안 맞으면 같은 노트가 라인마다 다른 말이 된다.

1. '같은 경보'의 정의부터 맞춘다

라인을 넓힐 때 가장 먼저 깨지는 건 경보의 정의다. A라인의 "진동 이상"은 센서값이 기준치의 1.5배를 넘었을 때고, B라인의 "진동 이상"은 작업자가 "이상하다"고 느꼈을 때다. 이름은 같은데 조건이 다르다. 이 상태로 노트를 공유하면, B라인 담당자는 A라인 기록을 보고 "우리도 저렇게 해야 하나" 하고 혼란스러워한다.

그래서 넓히기 전에 할 일은 경보 정의를 한 줄로 다시 쓰는 것이다. "이 경보는 어떤 수치가, 어떤 조건에서, 몇 번 연속으로 울릴 때 발생한다." 이 한 줄이 라인마다 같은 형식으로 적혀 있어야 한다. 형식이 같아지면, 경보 횟수를 라인끼리 비교할 수 있고, 비교가 돼야 어느 라인이 정말 문제인지 보인다. 정의가 안 맞은 채로 숫자를 모으면, 그건 데이터가 아니라 오해다.

2. 기준은 '중앙에서 정하고, 현장에서 조정한다'

기준을 맞춘다고 해서 모든 라인을 똑같이 만들면 안 된다. 설비가 다르고, 공정이 다르고, 작업자 숙련도도 다르다. B라인의 진동 기준을 A라인과 똑같이 맞추면, B라인은 경보 홍수에 빠지거나 반대로 아무것도 못 잡는다. 그래서 기준은 두 층으로 나눈다. 중앙 기준은 "어떤 항목을, 어떤 형식으로, 얼마나 자주 기록한다"는 운영의 뼈대다. 이건 전 라인이 같다. 현장 기준은 "이 라인의 경보 임계값은 얼마인가" 같은 숫자다. 이건 라인마다 다르다.

이 구분이 중요한 이유는, 나중에 라인을 비교할 때 뼈대가 같아야 비교가 되기 때문이다. 기록 형식이 같으면 경보 횟수, 대응 시간, 재학습 주기를 라인끼리 나란히 놓고 볼 수 있다. 숫자(임계값)가 다른 건 문제가 안 된다. 숫자는 현장의 조건을 반영한 것이니까. 뼈대는 통일하고, 숫자는 현장에 맡기는 것. 그게 여러 라인을 한 장의 운영 노트로 묶는 방법이다.

3. 넓힐 때는 '한 라인씩, 한 달씩' 옮긴다

운영 노트를 전 라인에 한 번에 펼치면, 첫 달에 온갖 예외가 쏟아진다. 정의가 안 맞는 경보, 기록 형식이 다른 항목, 담당자가 없는 시간대. 한 번에 펼치면 어느 게 진짜 문제인지 가려낼 수 없다. 그래서 넓히는 속도는 한 라인씩, 한 달씩이 적당하다. 새 라인 하나를 골라 한 달 동안 운영 노트를 돌려본다. 그 한 달 동안 나온 예외를 정리해 중앙 기준에 반영한다. 그다음 라인으로 간다.

한 라인씩 넓히면 좋은 점이 하나 더 있다. 먼저 넓힌 라인이 다음 라인의 교본이 된다는 것이다. "A라인은 이렇게 맞췄다"는 사례가 있으면, B라인 담당자는 처음부터 기준을 맞추는 법을 안다. 운영 노트는 문서가 아니라, 라인을 하나씩 거치며 단단해지는 습관이다. 7년차 현장 엔지니어로서 한 줄로 정리하면, 운영을 넓히는 일은 노트를 복사하는 게 아니라 기준의 뼈대를 맞추고 숫자는 현장에 맡기는 일이다. 그래서 뭘 하면 되나, 이번 주 할 일은 세 가지다. 첫째, 우리 현장의 경보 정의를 한 줄 형식으로 다시 쓴다. 둘째, 운영 기준을 '전 라인 공통 뼈대'와 '라인별 숫자'로 나눠 적는다. 셋째, 다음으로 넓힐 라인 하나를 골라 한 달 시범 운영을 시작한다. 잘 넓혀진 운영 노트는 모든 라인이 똑같은 게 아니라, 모든 라인이 같은 언어로 이야기하는 것이다. 다음 편에서는 여러 공장의 운영 노트를 한데 모아, 현장 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년차 현장 엔지니어로서, 예비품 관리는 재고 관리가 아니라 정지 시간을 사는 일이라고 생각한다.

왜 예비품은 늘 없을 때만 생각날까

예비품이 없는 이유는 대개 세 가지다. 첫째, 뭐가 고장 날지 모른다고 생각해서다. 둘째, 부품이 비싸서 "나중에 사자"고 미루기 때문이다. 셋째, 사놓고도 어디 뒀는지 몰라서다. 이 세 가지는 모두 "고장 기록이 없다"는 한 가지 뿌리에서 나온다. 어떤 부품이 얼마나 자주, 어떤 계절에, 어떤 설비에서 고장 났는지 기록이 없으면 예비품은 감(感)으로 사게 되고, 감으로 산 재고는 항상 빗나간다.

그래서 내가 먼저 하는 일은 단순하다. 설비 알람 로그와 교체 이력을 한 표로 모으는 것이다. 부품명, 교체 날짜, 고장 증상, 라인 정지 시간. 이 네 칸만 채워도 "이 부품은 1년에 두 번은 간다"는 사실이 보인다. 그게 보이면 예비품 수량은 계산이 된다. 감이 아니라 숫자다.

세 등급으로 나누면 재고가 가벼워진다

모든 부품을 다 쌓아둘 수는 없다. 그래서 나는 예비품을 세 등급으로 나눈다.

A등급 — 라인이 멈추는 부품. 센서, 서보 드라이버, 통신 모듈처럼 없으면 라인이 서는 것. 이건 현장 창고에 1개는 반드시 둔다. 비싸도 둔다. 한 번의 정지 손실이 부품값보다 크기 때문이다.

B등급 — 성능은 떨어지지만 버틸 수 있는 부품. 필터, 벨트, 베어링처럼 교체가 급하지 않은 것. 이건 납기 기간을 보고 주문 시점을 정한다. 납기가 2주면 재고가 1개 남았을 때 주문한다.

C등급 — 표준품·소모품. 볼트, 커넥터, 퓨즈처럼 어디서든 구할 수 있는 것. 이건 최소 수량만 유지하고, 다 쓰면 그때 산다.

이렇게 나누면 재고는 가벼워지고, 정작 필요한 건 항상 손에 있다. "다 쌓아두자"도 "없으면 사자"도 아닌, 멈추는 부품만 미리 갖는 것이 핵심이다.

위치와 라벨이 곧 속도다

부품이 있어도 못 찾으면 없는 것과 같다. 나는 예비품마다 두 가지를 붙인다. 첫째, 어느 설비의 어느 위치에 쓰이는지를 라벨에 적는다. "서보 드라이버 400W — 3호기 컨베이어"라고 적혀 있으면 밤샘 교대 근무자도 5분 안에 찾는다. 둘째, 교체 절차 한 줄을 같이 둔다. 전원을 끄고, 커넥터 순서를 사진으로 찍고, 교체 후 원점 복귀를 확인한다. 이 한 줄이 야간에 고장 났을 때 실수를 줄인다.

현장에서 예비품 관리를 잘하는 팀의 특징은 창고가 크다는 게 아니다. 찾는 데 5분, 교체에 15분이라는 감각을 갖고 있다는 것이다. 그 감각은 재고 목록에서 나오지 않는다. 라벨과 위치에서 나온다.

그래서 뭘 하면 되나

이번 주에 할 일은 세 가지다. 첫째, 최근 6개월 교체 이력을 한 표로 정리해본다. 둘째, 그중 라인을 멈추게 한 부품 5개만 골라 A등급으로 지정한다. 셋째, 그 5개에 설비명·위치·교체 절차 한 줄을 적은 라벨을 붙인다. 이걸로 예비품 관리의 절반은 끝난다.

디지털트윈이 설비의 상태를 실시간으로 보여준다면, 예비품 관리는 그 트윈이 멈췄을 때 현장이 얼마나 빨리 다시 움직이는지를 결정한다. 고장은 예고 없이 오지만, 준비는 예고하고 할 수 있다. 고장 난 뒤에 주문하는 팀과 고장 나기 전에 갖춰둔 팀의 차이는 결국 이 한 장의 표와 다섯 개의 라벨에서 갈린다.

관련 글: 설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것 https://developer-archive.tistory.com/130 · 다시 켜봤어요? — 재부팅으로 안 잡히는 장애를 풀어내는 현장 엔지니어의 장애 대응 루틴 https://developer-archive.tistory.com/135 

현장 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