프로그래밍 허브

2026년 11월 3일, 대전 한국기계연구원 본원에 국내 첫 휴머노이드 전용 데이터 생산시설 'AI 휴머노이드 데이터 팩토리'가 문을 열었다. 과학기술정보통신부와 한국기계연구원, 한국전자통신연구원(ETRI)이 함께 구축한 시설로, 현재 휴머노이드 12대를 운영하며 팔·다리 동작부터 온몸을 쓰는 작업까지 데이터를 수집한다. 개소식에서는 냉장고에서 물건 꺼내기, 세탁물 다루기, 소파 정리 같은 일상 작업과 자동차 내부 버튼·레버 조작 같은 산업현장 작업이 시연됐다. 국산 휴머노이드 '카이로스(KAIROS)'의 정밀 물체 조작과 전신 움직임 모방 기술도 함께 소개됐다.

 중요한지: 로봇의 병목은 몸이 아니라 '경험'이다

휴머노 뉴스는 대개 키, 속도, 관절 수 같은 스펙으로 전해진다. 하지만 현장에서 로봇이 멈추는 이유는 몸이 약해서가 아니라, 그 작업을 '해본 적'이 없어서다. 물건을 집는 각도, 미끄러운 바닥에서의 무게중심, 사람이 갑자기 끼어들 때의 멈춤 판단 — 이런 것들은 스펙표에 없다. 데이터 팩토리는 사람이 로봇을 원격 조작해 실제 작업을 수행하고, 그 움직임과 작업 과정을 데이터로 기록하는 시설이다. 즉 로봇에게 교과서가 아니라 실습 기록을 주는 곳이다. 2027년 말부터 산·학·연에 단계적으로 개방된다는 계획도 중요하다. 데이터가 한 연구실에 갇히지 않고 현장 검증으로 이어질 때, 비로소 '쓰이는 로봇'이 된다.

 관점: 데이터 팩토리가 진짜로 답해야 할 질문 3가지

7년차 현장 엔지니어로서, 나는 이 시설이 자랑할 숫자가 아니라 다음 질문에 답하는지로 평가하고 싶다. 첫째, 수집한 데이터에 '실패'가 포함되는가. 성공 동작만 모으면 로봇은 예쁜 동작만 배우고, 현장의 예외 상황에서는 여전히 멈춘다. 둘째, 데이터에 시간·힘·접촉 정보가 함께 찍히는가. 영상만으로는 무게감과 미끄러짐을 배울 수 없다. 셋째, 공장에서 나온 데이터와 다시 공장으로 돌아가는 검증 루프가 있는가. 대전에서 배운 동작이 실제 라인에서 10번 중 몇 번 성공하는지, 그 오차 범위를 공개하는 것이 진짜 진전이다. 그래서 뭘 하면 되나 — 지금 현장에 있는 우리부터, 로봇이 배우길 원하는 작업 1개를 골라 '성공 10번, 실패 10번'으로 기록해 두는 것이다. 그 기록이 나중에 데이터 팩토리와 만날 때 가장 값진 자산이 된다.

그, 우리 공장은 무엇을 준비해야 하나

 휴머노이드를 살 필요는 없다. 먼저 할 일은 세 가지다. 작업 지시서를 로봇이 읽을 수 있는 순서대로 다시 쓰는 것, 반복 작업 중 사람이 개입하는 지점을 표시해 두는 것, 그리고 설비의 상태·알람·작업 기록을 같은 시간축으로 맞추는 것이다. 이 준비가 되어 있는 공장일수록, 데이터 팩토리에서 나온 모델을 받아들였을 때 검증이 빠르다. 반대로 기록이 흩어져 있는 공장은 아무리 좋은 모델을 받아도 현장에 붙이는 데 몇 달이 걸린다. 로봇 시대의 경쟁력은 로봇 한 대의 성능이 아니라, 배우고 검증하고 다시 만드는 순환의 속도다. 대전의 데이터 팩토리는 그 순환을 한국 안에서 돌리기 위한 첫 번째 공장이다. 이제 남은 건, 그 순환에 우리 현장의 실제 작업을 올리는 일이다. 출처: 서울신문·디지털투데이·전자신문 2026-11-03, 'AI 휴머노이드 데이터 팩토리' 대전 개소 보도. 운영 주체: 과학기술정보통신부·한국기계연구원·한국전자통신연구원(ETRI).당장래서

현장이드

왜

현장에서 AI를 써보면 정확도 숫자보다 더 자주 마주치는 말이 있다. "AI가 95% 확신합니다." 그런데 그 95%를 그대로 믿고 라인을 돌렸다가, 남은 5%에서 불량이 터진 경험이 있는 사람이라면 이 숫자를 다르게 본다. 확신도는 AI의 자신감이지, 현장의 보증서가 아니다. 오늘은 확신도를 현장에서 안전하게 쓰는 기준을 정리한다.

확신도는 확률이 아니라 AI의 '자신감'이다

분류 모델이 내놓는 확신도는 "이 답이 맞을 가능성"처럼 보이지만, 사실은 모델이 학습한 데이터 안에서 계산한 점수에 가깝다. 학습 때 본 적 없는 불량 유형, 조명이 바뀐 검사 이미지, 센서 노이즈가 섞인 입력 앞에서는 확신도가 높게 찍혀도 틀릴 수 있다. 그래서 확신도 자체를 믿기보다, 확신도가 현장에서 얼마나 맞았는지부터 확인해야 한다. 과거 판정 기록을 확신도 구간별로 나눠 실제 정답률과 비교해보는 것만으로도, 우리 모델의 자신감이 과장돼 있는지 금방 드러난다.

기준은 하나가 아니라 구간으로 나눈다

현장에서는 확신도를 통과·보류·차단 세 구간으로 나누는 게 실용적이다. 예를 들어 95% 이상은 자동 통과, 80~95%는 작업자 확인 후 진행, 80% 미만은 자동 판정을 쓰지 않고 재검사나 수동 판정으로 넘기는 식이다. 구간 경계는 논문 수치가 아니라 불량 유출 비용과 검사 인력으로 정한다. 유출되면 큰 사고로 이어지는 공정일수록 통과 기준을 높이고, 확인 인력 여유가 없을 때는 보류 구간을 좁히는 식으로 조정한다. 중요한 건 기준을 정하고 끝내는 게 아니라, 매주 구간별 실제 정답률을 보며 기준을 조금씩 고치는 일이다.

확신도가 낮을 때가 오히려 귀한 데이터다

확신도가 낮은 판정은 귀찮은 예외가 아니라 다음 개선의 재료다. 낮은 구간에 쌓인 사례를 모아보면 조명·각도·이물질처럼 반복되는 원인이 보인다. 이 사례들에만 사람이 라벨을 다시 달아 재학습에 쓰면, 모델은 현장에서 실제로 틀리는 지점부터 좋아진다. 반대로 확신도가 높은데 틀린 사례, 이른바 '자신만만한 오답'은 따로 모아 원인을 추적해야 한다. 데이터가 오염됐는지, 센서가 드리프트됐는지, 공정 자체가 바뀌었는지부터 확인하는 것이다.

현장에서 바로 쓸 체크리스트

첫째, 확신도 구간별 실제 정답률을 한 번이라도 계산해본다. 둘째, 자동 통과·사람 확인·재검사 세 구간과 담당자를 정해둔다. 셋째, 낮은 확신도 사례와 자신만만한 오답을 따로 모아 매주 한 번 검토한다. 넷째, 공정 변경·센서 교체·조명 변경이 있을 때는 확신도 기준을 다시 검증한다.

AI를 현장에 들이는 일은 정확도를 올리는 경쟁이 아니라, 틀릴 수 있다는 전제 위에서 어떻게 안전하게 쓰느냐의 설계다. 확신도는 그 설계의 첫 번째 계기판이다. 숫자를 맹신하지 않고 구간으로 나누고 기록으로 검증하면, AI는 현장에서 훨씬 믿을 만한 동료가 된다.

현장에서 태블릿으로 디지털트윈을 열었는데, 로봇이 벽 안에 박혀 있었다. 실제 로봇은 멀쩡히 서 있는데 화면 속 로봇만 어긋나 있었다. 모델이 잘못된 게 아니었다. 현장 좌표와 모델 좌표가 서로 다른 언어를 쓰고 있었던 것이다. 7년차 현장 엔지니어로서, 디지털트윈이 어긋나는 이유의 절반은 3D 정밀도가 아니라 좌표 기준이 맞지 않아서 생긴다고 생각한다.

좌표가 어긋나는 세 가지 지점

첫째, 원점이 다르다. 도면의 원점, 3D 스캔의 원점, 로봇 베이스의 원점이 각자 다르다. 어느 하나를 기준으로 삼지 않으면 같은 설비도 세 곳에 존재하는 것처럼 보인다. 둘째, 축 방향이 다르다. 위쪽을 Y로 잡는 모델과 Z로 잡는 모델이 섞이면 설비가 눕거나 뒤집힌다. 오른손 좌표계와 왼손 좌표계가 섞이면 좌우가 바뀐다. 셋째, 단위와 오차가 쌓인다. 밀리미터와 미터가 섞이면 설비가 1,000배로 커지고, 스캔 정합 오차가 구간마다 조금씩 쌓이면 라인 끝으로 갈수록 어긋남이 커진다.

기준점 하나로 맞추는 순서

해법은 의외로 단순하다. 움직이지 않는 기준점을 먼저 정하는 것이다. 기둥 모서리, 바닥 볼트 중심, 고정 지그처럼 설비가 바뀌어도 그대로 있는 점 세 곳 이상을 고른다. 그리고 현장에서 잰 좌표와 모델 속 좌표를 한 표로 나란히 적는다. 원점, 축 방향, 단위를 이 표에서 한 번에 통일한다. 기준점이 하나만 있으면 위치는 맞고 방향은 틀릴 수 있다. 세 점이 있어야 위치와 방향을 함께 잡을 수 있다. 기준점은 사진과 함께 기록해 두면, 나중에 온 사람도 같은 점을 찾을 수 있다.

맞췄다고 끝이 아니다

좌표를 맞춘 뒤가 더 중요하다. 설비가 이동하거나 증설될 때마다 기준점은 다시 확인해야 한다. 언제, 누가, 어떤 기준으로 맞췄는지 기록이 없으면 다음 정합 작업은 처음부터 다시 시작된다. 좌표 기준은 모델 파일 안에만 두지 말고, 현장 운영 문서에도 한 줄로 남겨야 한다. 그래서 뭘 하면 되나 — 이번 주 현장에서 움직이지 않는 기준점 세 곳을 사진과 좌표로 기록해 두는 것부터 시작하면 된다. 그 한 장의 기록이 트윈과 현장을 같은 자리에 세우는 첫걸음이다. 관련 글: 디지털트윈의 진짜 엔진은 데이터 수집(https://developer-archive.tistory.com/124), 디지털트윈이 '실시간'이 되는 조건(https://developer-archive.tistory.com/132)

2026년 10월 31일, 경기도 용인 삼성인력개발원에서 삼성 주요 관계사 사장단 50여 명이 샘 올트먼 OpenAI CEO와 마주 앉았다. 주제는 'AI가 바꿀 다음 10년, 기업의 선택'. 같은 날 저녁에는 최태원 SK그룹 회장과의 오찬 회동 소식까지 이어졌다. 모델 발표도, 신제품 공개도 아닌 '경영진 간담회'가 뉴스 1면에 오른 이유는 분명하다. AI 경쟁의 무게중심이 모델 성능에서 도입 방식과 실행 속도로 옮겨가고 있기 때문이다.

왜 중요한지: 협력의 축이 반도체에서 '경영'으로 넓어졌다

삼성과 OpenAI의 협력은 지난해 10월 글로벌 AI 인프라 구축 협력 의향서(LOI)에서 시작됐다. 삼성전자는 OpenAI의 초대형 데이터센터 사업 '스타게이트'에 필요한 메모리 반도체 공급을 추진하고, 삼성SDS는 AI 데이터센터 구축과 기업용 AI 서비스에서, 삼성물산과 삼성중공업은 해상 부유식 데이터센터 공동 개발에서 손을 잡고 있다. 이번 간담회가 다른 점은 협력의 축이 공급망을 넘어 경영 전반으로 넓어졌다는 데 있다. 사장단은 간담회에 앞서 생성형 AI로 경영 자료를 정리하고 의사결정에 활용하는 실습 교육까지 받았다. 삼성은 지난 6월부터 연구개발부터 생산, 마케팅, 지원 업무까지 전 분야에 AI를 도입하는 'AI 대전환'을 추진 중이고, 약 2,300명의 임원을 대상으로 AI 교육을 진행해 2027년 2월까지 전 임직원 교육 완료를 목표로 하고 있다. 올트먼 CEO가 강조한 것으로 전해진 메시지도 "AI를 얼마나 도입했느냐"가 아니라 "어떻게 활용하고 얼마나 빨리 실행하느냐"였다. AI를 사는 기업과 AI로 일하는 방식을 바꾸는 기업이 갈리는 지점이다.

제조 현장에서 읽는 법: 메모리가 곧 '공장의 속도'다

제조업 관점에서 이 간담회는 남의 얘기가 아니다. HBM과 메모리 공급, 데이터센터 협력은 결국 공장의 속도와 직결된다. AI 모델이 커지고 추론 수요가 늘수록, 학습과 추론을 뒷받침하는 메모리와 인프라의 안정성이 생산 계획의 전제가 된다. 설비 투자와 마찬가지로 AI 인프라 투자도 "언제, 어디에, 어떤 용도로"가 먼저 정해져야 한다. 용도 없는 인프라는 창고에 쌓인 재고와 다를 바 없다. 7년차 현장 엔지니어로서 한 줄로 정리하면, 진짜 시험대는 발표장이 아니라 공장 바닥의 업무 흐름이다. 경영진이 AI 실습을 직접 받는 모습은 상징이 아니라 순서다. 결정을 내리는 사람이 AI의 한계와 쓰임새를 몸으로 알아야, 현장의 AI 도입이 '보고서용 시범 사업'에서 멈추지 않는다.

그래서 뭘 하면 되나: 작은 업무 하나를 끝까지 바꿔라

중소 제조 현장에 바로 적용할 체크리스트는 단순하다. 첫째, 전사 도입 선언보다 하나의 반복 업무를 골라 AI 적용 전후의 소요 시간과 오류율을 숫자로 남긴다. 둘째, 그 업무의 데이터 출처와 책임자를 정한다. 데이터가 누구 것인지 모르면 AI는 오래 못 간다. 셋째, 경영진부터 AI를 직접 써보는 시간을 만든다. 위에서 써보지 않은 도구는 아래에서 정착되지 않는다. AI의 다음 10년은 더 큰 모델이 아니라 더 단단한 도입 방식에서 갈릴 것이다. 삼성 사장단 간담회가 던진 메시지는 거창하지 않다. 도입했느냐가 아니라, 일하는 방식을 바꿨느냐고 묻고 있다는 점이다. 출처: 전자신문 2026-10-31 '삼성 사장단, 올트먼에 AI 다음 10년 물었다', 매일경제 2026-10-31 '삼성 사장단, 샘 올트먼 초청 AI 혁신 간담회 개최', EBN 2026-10-31 '샘 올트먼, 삼성 사장단·최태원 연쇄 회동'. SK 회동 구체 논의 내용은 공개되지 않았음.

이 글은 '현장 AI 운영 노트' 시리즈의 여섯 번째 글입니다. 1편에서는 매일 아침 AI의 건강을 보는 5분 점검표를, 2편에서는 그 점검표를 대시보드 하나로 만드는 법을, 3편에서는 경보가 울렸을 때 누가 어떤 순서로 움직이는지 조치 루틴을, 4편에서는 한 달 돌린 경보 루틴을 숫자로 리뷰하는 법을, 지난 편에서는 분기 리뷰로 재학습 여부를 정하는 기준을 다뤘습니다 (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). 이번 편에서는 재학습을 하기로 정한 뒤, 현장에 배포하기 전에 반드시 거치는 검증 단계를 다룹니다.

재학습을 했다고 바로 현장에 올리면 안 됩니다. 학습 데이터에서는 성능이 좋아졌는데, 막상 라인에 세워보면 예전에는 맞추던 걸 틀리는 경우가 생각보다 많습니다. 그걸 현장에서 처음 발견하면, 작업자는 그날부터 모델을 안 믿게 됩니다. 신뢰는 천천히 쌓이고 한 번에 무너집니다. 그래서 저는 배포 전에 검증 단계를 세 개로 나눠, 각 단계의 통과 기준을 미리 적어둡니다. 기준 없이 "괜찮아 보인다"로 넘어가는 검증은 검증이 아닙니다.

1. 오프라인 검증 — 새 모델이 옛날 실수를 반복하지 않는지

첫 단계는 책상 위 검증입니다. 새로 학습한 모델을 과거 데이터에 돌려보되, 전체 정확도만 보지 않습니다. 특히 두 가지를 봅니다. 첫째, 이전 모델이 틀렸던 사례를 새 모델이 얼마나 고쳤는지. 둘째, 이전 모델이 맞추던 사례를 새 모델이 새로 틀리지는 않는지, 즉 '퇴행'이 없는지입니다. 현장에서 써먹는 기준은 단순합니다. 고친 사례가 새로 틀린 사례보다 분명히 많아야 하고, 새로 틀린 사례 중에는 안전이나 품질과 직결되는 치명적 오판이 없어야 합니다. 전체 정확도가 1% 올랐는데 치명적 오판이 하나 생겼다면, 그 모델은 배포하지 않습니다. 숫자보다 먼저 보는 건, 틀리는 방식이 바뀌었는지입니다.

2. 그림자 검증 — 현장 데이터로, 결정은 내리지 않고 지켜보기

두 번째 단계는 그림자 검증입니다. 새 모델을 실제 현장 데이터 흐름에 연결하되, 그 판단이 경보나 정지 같은 실제 동작으로 이어지지 않게 합니다. 모델은 조용히 판단을 내리고, 사람은 기존 방식으로 일하면서 나중에 두 판단을 비교합니다. 짧게는 일주일, 라인이 자주 바뀌는 곳은 2주 정도가 적당합니다. 이 단계에서 볼 것은 정확도가 아니라 '현장 적합성'입니다. 특정 시간대에만 오판이 몰리는지, 특정 로트나 작업자 교대 이후에 판단이 흔들리는지, 센서 노이즈가 많은 구간에서 경보가 폭주하지 않는지. 실험실 데이터에서는 안 보이던 패턴이 여기서 처음 드러납니다. 그림자 기간에 이상 패턴이 나오면, 배포를 미루고 데이터 조건부터 고치는 게 맞습니다.

3. 제한 배포 — 한 라인, 한 교대부터, 되돌릴 준비와 함께

세 단계를 다 통과했으면 마지막은 제한 배포입니다. 전 라인에 한 번에 올리지 않고, 한 라인이나 한 교대부터 시작합니다. 그리고 시작 전에 반드시 되돌림(롤백) 조건을 정해둡니다. 예를 들어 "치명적 오판 1건, 또는 하루 무조치 경보가 기준을 넘으면 즉시 이전 모델로 복귀" 같은 식입니다. 제한 배포 기간에는 EP.1의 아침 점검표가 다시 중요해집니다. 새 모델의 경보 추이를 매일 보고, 이전 모델과 비교한 표를 따로 남깁니다. 문제가 없으면 범위를 넓히고, 문제가 생기면 망설이지 않고 되돌립니다. 되돌림은 실패가 아니라 검증의 일부입니다. 되돌릴 준비가 되어 있어야 현장은 새 모델을 받아들입니다.

그래서 뭘 하면 되나 — 배포 전 검증표 한 장

재학습한 모델을 배포하기 전에, 이 세 줄을 채워보세요. 오프라인 검증에서 퇴행이 없었는지, 그림자 검증에서 현장 패턴 이상이 없었는지, 제한 배포의 범위와 되돌림 조건이 정해졌는지. 세 줄이 모두 채워져야 배포 버튼을 누릅니다. 모델을 바꾸는 일보다 어려운 건, 바꾼 모델을 현장에서 믿게 만드는 일입니다. 검증은 그 믿음을 만드는 가장 싼 방법입니다. 다음 편에서는 배포한 뒤, 새 모델의 성능을 현장에서 계속 추적하는 모니터링 루틴을 다룹니다. 관련 글: 현장 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), 데이터 드리프트(https://developer-archive.tistory.com/133), AI 모델 평가를 현장 지표로(https://developer-archive.tistory.com/164)

스마트팩토리 현장에서 설비를 들여올 때, 스펙표만 보고 결정하면 나중에 꼭 후회합니다. 속도는 빠르고 정밀도도 좋은데, 막상 라인에 세워보면 청소가 어렵고, 고장 났을 때 부품이 늦고, 밤에 알람이 쏟아지는 경우가 있거든요. 그래서 저는 업체 미팅에서 스펙 숫자보다 '운영 조건'을 먼저 물어봅니다. 오늘은 실제로 써먹는 질문 다섯 가지를 정리합니다.

1. 고장 났을 때, 누가 얼마나 빨리 오는가

가장 먼저 묻는 건 복구 시간입니다. "평균 수리 시간(MTTR)이 어떻게 되나요? 부품은 국내에 재고가 있나요, 해외 주문인가요?" 스펙표의 가동률은 평상시 기준이라, 고장 대응이 느리면 그 숫자는 의미가 없습니다. 특히 해외 부품 조달이 2주 이상 걸리는 설비는 예비 부품 보유 여부를 함께 확인합니다. 현장에서는 '안 고장 나는 설비'보다 '빨리 고쳐지는 설비'가 훨씬 소중합니다.

2. 청소와 점검이 현장에서 실제로 가능한가

두 번째는 유지보수 동선입니다. "커버를 열려면 공구가 몇 개 필요한가요? 센서 청소 주기는 어떻게 되나요?" 카탈로그 사진에서는 몰랐던 볼트 위치 하나 때문에 점검 시간이 두 배가 된 적이 있습니다. 분진이 많은 공정이라면 센서 창 청소 난이도를 꼭 현장 조건으로 물어보세요. 점검하기 어려운 설비는 결국 점검이 미뤄지고, 그게 고장의 시작이 됩니다.

3. 우리 데이터와 어떻게 붙는가

세 번째는 연결입니다. "데이터는 어떤 프로토콜로 나오나요? OPC UA, MQTT, 아니면 전용 프로그램만 되나요?" 설비가 아무리 좋아도 MES나 디지털트윈과 붙지 않으면 데이터는 그 기계 안에 갇힙니다. 엑셀 추출만 되는 설비는 도입 첫날부터 수작업이 생깁니다. 통신 방식과 데이터 주기, 타임스탬프 기준까지 미리 확인해 두면 나중에 '경계' 공사를 다시 하지 않아도 됩니다.

4. 야간·주말 무인 운전에서 뭐가 달라지나

네 번째는 무인 조건입니다. "사람이 없을 때 알람 기준이 어떻게 되나요? 스스로 멈추는 조건은 무엇인가요?" 사람이 보는 낮과 무인으로 도는 밤은 같은 설비도 다르게 굴러갑니다. 사소한 진동 알람이 밤에 100건씩 쌓이면, 다음 날 아침에는 아무도 알람을 안 보게 됩니다. 알람 등급과 자동 정지 조건, 원격 확인 방법을 미팅 자리에서 구체적으로 정해 두는 게 좋습니다.

5. 교육과 문서, 끝까지 책임지는가

마지막은 사람입니다. "운영 교육은 몇 시간, 누구에게 하나요? 매뉴얼은 한국어로 최신 버전인가요?" 설비 교체보다 무서운 건, 아는 사람이 퇴사하면 아무도 못 만지는 설비가 되는 일입니다. 교육 범위와 문서 언어를 계약 전에 확인하고, 인수인계 자료를 납품 항목에 넣어 두세요. 이 한 줄이 1년 뒤 현장의 피로를 크게 줄입니다.

마무리: 스펙은 시작일 뿐, 운영이 본질이다

좋은 설비 도입의 기준은 스펙표의 숫자가 아니라, 고장 났을 때·밤에·사람이 바뀌었을 때 어떻게 굴러가는지입니다. 위 다섯 가지 질문을 미팅 전에 체크리스트로 뽑아 두면, 업체 답변의 빈틈이 훨씬 잘 보입니다. 그래서 뭘 하면 되나 — 다음 미팅부터 이 질문 5개를 그대로 가져가 보세요. 현장의 질문이 곧 도입의 품질입니다. 관련 글: https://developer-archive.tistory.com/130, https://developer-archive.tistory.com/135

현장에서 AI 모델이 틀렸다고 할 때, 저는 모델부터 보지 않습니다. 먼저 입력 데이터를 봅니다. 스마트팩토리에서 7년을 일하며 본 실패의 상당수는 모델 성능 문제가 아니라, 센서에서 들어오는 값이 이미 틀어져 있었기 때문입니다. 단위가 섞이고, 시간이 어긋나고, 결측이 조용히 채워지는 곳에서는 아무리 좋은 모델도 현장 답을 못 냅니다.

단위와 스케일이 다른 센서들

현장은 센서마다 말이 다릅니다. 한 설비는 온도를 섭씨로, 다른 설비는 화씨로 보내고, 압력은 bar와 psi가 섞입니다. 진동은 어떤 곳은 mm/s, 어떤 곳은 g 단위입니다. 수집 단계에서 단위를 통일하지 않으면, 모델은 숫자 크기만 보고 판단합니다. 단위가 큰 신호가 중요해 보이는 건 모델의 착각이 아니라, 전처리를 안 한 사람의 실수입니다.

단위 혼용 함정 — 섭씨·화씨, bar·psi 혼재, 먼저 할 일은 수집 시점에 표준 단위로 변환.

스케일 차이 함정 — 진동 0.01, 온도 800이 한 표에, 먼저 할 일은 센서별 기준 범위를 문서로 고정.

샘플링 차이 함정 — 1초·10초·1분 데이터 혼합, 먼저 할 일은 분석 기준 주기로 정렬·보간 규칙 정하기.

결측과 이상치는 '지우는' 게 아니다

센서 값이 비면, 많은 파이프라인이 0이나 평균값으로 메웁니다. 그런데 현장에서 결측은 대개 의미가 있습니다. 설비가 멈췄거나, 통신이 끊겼거나, 센서 자체가 고장 났다는 신호입니다. 0으로 메우면 '설비가 0도에서 잘 돈다'는 거짓 기록이 됩니다. 이상치도 마찬가지입니다. 튀는 값을 무조건 지우면, 고장의 전조를 지우는 셈이 됩니다. 그래서 저는 결측과 이상치를 처리하기 전에 먼저 원인을 묻습니다. 통신 끊김인지, 센서 고장인지, 실제 공정 이상인지. 원인마다 처리법이 다릅니다. 통신 끊김은 구간 표시를 남기고, 센서 고장은 해당 채널을 제외하고, 공정 이상은 지우지 않고 따로 표시합니다. 처리 규칙은 코드 주석이 아니라, 현장 담당자가 읽을 수 있는 문서로 남겨야 합니다. 사람이 바뀌어도 규칙이 남아야 모델이 안 무너집니다.

단위 통일과 결측 표시를 수집 단계에서 고정하는 예시.

def normalize_sensor(df):
    df["temp_c"] = df["temp"].where(df["unit"] == "C", df["temp"].sub(32).mul(5 / 9)) — 화씨에서 섭씨로 변환.
        df["temp_c"] = df["temp_c"].where(df["sensor_ok"], None) — 고장 구간은 채우지 않음.
            return df

전처리 규칙을 코드가 아니라 문서로 남겨라

모델이 바뀌어도, 전처리 규칙은 그대로인 경우가 많습니다. 반대로 전처리만 바꿔도 모델 결과가 통째로 바뀝니다. 그래서 배포 전에 확인하는 목록은 모델 정확도가 아니라 전처리입니다. 단위 변환이 빠진 채널은 없는지, 결측 처리 규칙이 바뀌었는지, 시간 정렬 기준이 같은지. 이 세 가지만 확인해도 현장에서 '어제까지 잘 되던 모델이 오늘 틀리는' 일은 크게 줄어듭니다. 7년차 현장 엔지니어로서 한 줄로 정리하면, 제조 AI의 첫 번째 품질 관리는 모델이 아니라 입력입니다. 그래서 뭘 하면 되나, 이번 주에 할 일은 세 가지입니다. 첫째, 쓰는 센서 목록에 단위와 기준 범위를 적습니다. 둘째, 결측이 생겼을 때 0으로 메우지 말고 원인 표시를 남깁니다. 셋째, 전처리 규칙을 문서 한 장으로 만들어 팀과 공유합니다. 모델은 그 다음에 고쳐도 늦지 않습니다.

현장에 가면 꼭 한 분이 있다. 설비 소리만 듣고 "오늘은 베어링이 맛이 가겠네"라고 말하는 베테랑. 그런데 그분이 휴가를 가면 라인은 같은 소리를 듣고도 멈춘다. AI를 도입해도 사정은 비슷하다. 데이터는 넘치는데, 베테랑의 판단 기준이 데이터에 없기 때문이다. 7년차 현장 엔지니어로서, 나는 이 간극을 "데이터 부족"이 아니라 "기록 부족"으로 본다. 베테랑이 아는 것은 숫자가 아니라, 숫자를 해석하는 순서다.

1. 암묵지는 설명이 아니라 판단 기준이다

"진동이 크면 위험하다"는 누구나 안다. 베테랑이 진짜로 아는 것은 그다음이다. 어느 센서 값을 먼저 보고, 어느 값과 함께 봤을 때 멈추고, 어느 경우에는 그냥 두는지. 이 우선순위가 기록되지 않으면, AI는 평균적인 답만 내놓는다. 현장에서 평균적인 답은 대개 늦은 답이다. 그래서 암묵지를 남길 때는 "어떻게 하느냐"보다 "무엇을 보고 무엇을 버렸느냐"를 적어야 한다. 판단의 근거가 남아야, 나중에 AI도 같은 근거를 배울 수 있다.

2. 기록으로 바꾸는 3가지 방법

첫째, 상황-판단-결과를 한 줄로 적는다. "진동 상승 + 온도 정상 → 베어링 의심, 교체 예약"처럼, 원인과 결정을 붙여서 남긴다. 길게 쓸 필요는 없다. 판단이 한 줄에 들어갈 때, 그 기록은 그대로 학습 예시가 된다. 둘째, 사진 한 장에 한 줄을 붙인다. 설비 상태, 계기판, 작업자 손 위치 같은 장면은 글로는 오래 걸리고, 사진 한 장이면 즉시 전달된다. 사진 없이 글로만 남기면, 다음 사람은 같은 장면을 다시 상상해야 한다. 셋째, 예외 목록을 따로 모은다. "이럴 때는 규칙대로 하지 않는다"는 예외가 쌓여야, AI가 규칙만 외우는 함정에 빠지지 않는다. 예외가 없는 매뉴얼은 현장에서 오래 못 간다.

3. AI 학습 데이터로 연결하는 법

이렇게 모인 기록은 곧바로 AI의 좋은 재료가 된다. 상황-판단-결과 한 줄은 few-shot 예시가 되고, 예외 목록은 평가 케이스가 된다. 반대로 기록이 없으면, AI 도입 프로젝트는 처음부터 데이터 수집부터 다시 시작해야 한다. 그래서 현장 AI의 첫 단계는 모델 선정이 아니라, 베테랑의 판단 한 줄을 모으는 일이다. 그래서 뭘 하면 되나: 이번 주에 베테랑과 한 건의 판단만이라도 "무엇을 보고, 무엇을 버리고, 무엇을 결정했는지" 한 줄로 남겨보자. 그 한 줄이 쌓이면, AI는 비로소 현장의 손맛을 배우기 시작한다. 관련 글: 현장 장애 원인을 빨리 찾는 인터뷰 습관(https://developer-archive.tistory.com/181), 설비 알람 로그 설계 습관(https://developer-archive.tistory.com/130)