프로그래밍 허브

[시리즈  이어서 읽기] 1편에서는 데이터가 '나오는 것'과 '쓸 수 있는 것' 사이의 4가지 막힘을 정리했고, 2편에서는 전송이 끊기는 것을 전제로 한 엣지 버퍼링과 재전송 설계를 다뤘습니다. 오늘은 3편으로, 저장 구간의 심화 — 타임스탬프·설비 ID·단위를 통일하는 '스키마 계약' 만들기입니다. 1편 https://developer-archive.tistory.com/148 · 2편 https://developer-archive.tistory.com/153

현장에서 데이터 저장은 보통 이렇게 시작합니다. "일단 쌓아두자." CSV로 날짜별 폴더에 쌓고, 나중에 AI 팀이 달라고 하면 그때 정리하면 된다는 생각입니다.

그런데 7년차 현장 엔지니어로 말씀드리면, 이 방식의 대가는 나중에 한 번에 옵니다. 파일마다 타임스탬프 형식이 다르고, 설비 이름이 현장 약칭으로 적혀 있고, 압력 단위가 어떤 파일은 bar, 어떤 파일은 MPa인 겁니다. 쌓인 건 많은데 쓸 수 있는 건 없는 상태 — 이게 '저장'이 아니라 '방치'입니다. 저장 단계에서 지켜야 할 계약 세 가지를 정리합니다.

1) 타임스탬프 — "어제"가 아니라 "어느 시간대"인가

첫 번째 계약은 시간입니다. 저장할 때는 UTC 기준으로 통일하고, 화면에 보여줄 때만 현지 시간으로 바꾸는 것이 원칙입니다. 설비마다 시계가 몇 초씩 어긋나 있으면, 두 라인의 데이터를 같은 시간축에 얹는 순간부터 순서가 틀어집니다. 그래서 설비 시간 동기화(NTP)는 저장 설계의 일부입니다. "언제"가 흔들리면, 그 뒤의 모든 분석이 흔들립니다.

2) 설비 ID — 약칭은 사람이 쓰고, ID는 시스템이 쓴다

두 번째 계약은 설비 식별입니다. 현장에서는 "1호기" "옆 라인" 같은 약칭이 편합니다. 하지만 데이터에 약칭만 남으면, 라인이 재배치되거나 설비가 교체되는 순간 과거 데이터와 연결이 끊깁니다. 고유한 설비 ID(예: LINE01_PRESS_03)를 마스터 테이블에 고정해 두고, 약칭은 표시용 별명으로만 쓰는 겁니다. ID가 고정돼야 1년 전 데이터와 오늘 데이터가 같은 설비의 이야기가 됩니다.

3) 단위와 값의 의미 — 숫자 뒤에 단위를 붙여라

세 번째 계약은 단위와 값의 의미입니다. 압력 7.2가 bar인지 MPa인지, 온도가 섭씨인지, 결측값은 0인지 빈 값인지 — 이 정보가 데이터와 함께 저장되지 않으면, 숫자는 그냥 숫자일 뿐입니다. 스키마 계약서에는 필드명, 데이터 타입, 단위, 허용 범위, 결측 처리 방식을 한 줄씩 적습니다. 새 센서가 추가될 때마다 계약서를 먼저 갱신하고, 그 다음에 저장을 시작합니다.

3편의 결론 — 스키마 계약은 문서가 아니라 약속이다

정리하면 이렇습니다. 시간은 UTC로 통일하고, 설비는 고유 ID로 고정하고, 숫자는 단위와 함께 저장하는 것. 이 세 가지가 지켜지면, 저장된 데이터는 쌓이는 짐이 아니라 시간이 지날수록 가치가 커지는 자산이 됩니다.

그래서 뭘 하면 되나 — 자사 저장 데이터에서 타임스탬프 형식이 두 종류 이상 섞여 있는지, 설비 이름이 약칭으로만 적혀 있는지, 오늘 바로 한 파일만 열어 확인해 보세요. 섞여 있다면, 그 파일부터 계약을 적용하면 됩니다.

다음 편(4편)은 활용 구간의 심화 — 데이터를 '보는 사람, 보는 주기, 이상 시 연락망'으로 완성하는 운영 설계를 다룹니다.

엣지 컴퓨팅은 클라우드를 대체하는 기술이 아니라, 현장과 클라우드 사이의 역할을 나누는 설계다. 어디까지 현장에서 판단할 것인가 — 이 경계를 정하는 것이 결국 스마트팩토리 설계의 실력이다.

공장이 밤에도 돌아가는 시대입니다. 사람이 없는 시간에 라인이 멈추면, 아침에 발견되는 손실은 단순한 가동 중단이 아닙니다. 납기, 품질 기록, 다음날 작업 계획까지 한꺼번에 흔들립니다. 그래서 저는 야간 무인 운전을 시작하기 전에, 화려한 기술보다 기본 확인부터 끝냅니다. 7년 현장에서 체득한 다섯 가지 체크리스트를 공유합니다.

1. 알람은 '울리는 것'이 아니라 '구분되는 것'이어야 한다

무인 시간에 가장 무서운 건 알람이 안 울리는 게 아니라, 중요하지 않은 알람이 너무 많이 울리는 것입니다. 경미한 경고와 즉시 조치가 필요한 장애가 같은 소리, 같은 색으로 뜨면 야간 당직자는 결국 둘 다 무시하게 됩니다. 저는 알람을 세 단계로 나눕니다. 즉시 개입, 아침 확인, 기록만 남기기. 그리고 각 단계마다 누가, 어떤 경로로 통보받는지까지 정해둡니다. 알람 설계는 기술이 아니라 운영의 문제입니다.

2. 재시도는 무한이 아니라 횟수와 간격이 정해진 설계다

센서 통신이 잠깐 끊겼다고 라인을 바로 멈출 필요는 없습니다. 반대로 무한 재시도는 고장 난 설비를 계속 두드리며 문제를 키웁니다. 현장에서 쓰는 원칙은 단순합니다. 재시도 3회, 간격은 점진적으로 늘리고, 그래도 안 되면 안전 상태로 멈추고 기록을 남긴다. 이 규칙을 코드가 아니라 운영 문서에 적어두는 것이 중요합니다. 사람이 없어도 설비가 스스로 '어디까지 시도하고 어디서 멈출지' 알아야 하기 때문입니다.

3. 원격으로 볼 수 없는 것은 무인 운전 대상이 아니다

카메라 한 대, 대시보드 한 화면이 있다고 해서 무인 운전이 되는 건 아닙니다. 핵심은 이상이 생겼을 때 원격에서 원인을 가늠할 수 있느냐입니다. 온도, 진동, 전류, 사이클 타임 같은 핵심 신호가 실시간으로 보이는지, 지난 정상 패턴과 비교할 기준선이 있는지를 먼저 확인합니다. 데이터가 없으면 밤새 무슨 일이 있었는지 아침에 재구성할 수도 없습니다. 그래서 뭘 하면 되나 — 무인 운전 전에 '볼 수 있는 항목 목록'을 먼저 만들고, 빈칸이 있으면 그 설비는 무인 대상에서 빼는 것이 정답입니다.

4. 멈췄을 때의 '안전 상태'를 미리 정해둔다

무인 운전의 성패는 잘 돌 때가 아니라 멈췄을 때 갈립니다. 전원이 나가거나 통신이 끊기면 설비는 어디에서, 어떤 자세로 멈춰야 할까요. 로봇은 홈 위치로, 컨베이어는 정지, 가열 설비는 냉각 모드처럼 설비마다 안전한 멈춤을 정의해둬야 합니다. 그리고 복구 절차도 마찬가지입니다. 아침에 사람이 와서 버튼 하나만 누르면 재개되는지, 아니면 수동 점검이 필요한 단계를 거치는지를 문서로 남깁니다. 7년차 현장 엔지니어로서, 저는 "멈추는 설계"가 "돌아가는 설계"보다 중요하다고 봅니다.

5. 아침 첫 10분이 무인 운전의 성적표다

무인 운전이 잘됐는지는 야간 로그 첫 10분으로 판가름 납니다. 밤새 발생한 이벤트 요약, 자동 복구 성공 여부, 아침에 사람이 확인해야 할 항목이 한 화면에 정리돼 있는지가 기준입니다. 로그가 수천 줄로 쌓여 있으면 아무도 안 봅니다. 요약이 있어야 운영이 됩니다. 저는 아침 인수인계 화면을 무인 운전 시스템의 일부로 봅니다. 기술 도입보다 인수인계 설계가 먼저입니다.

무인 운전은 사람을 없애는 기술이 아니라, 사람이 없어도 판단이 이어지게 만드는 설계입니다. 알람 구분, 재시도 규칙, 가시성, 안전 상태, 아침 요약 — 이 다섯 가지가 갖춰지면 비로소 밤에도 현장을 믿고 맡길 수 있습니다. 여러분 현장의 무인 운전 체크리스트에는 어떤 항목이 빠져 있나요?

관련 글

설비 알람 1,000건이 쌓이기 전에 내가 먼저 본 것 — 7년차 현장 엔지니어의 로그 설계 습관 https://developer-archive.tistory.com/130

다시 켜봤어요? — 재부팅으로 안 잡히는 장애를 풀어내는 현장 엔지니어의 장애 대응 루틴 https://developer-archive.tistory.com/135

그래서 뭘 하면 되나 — 오늘 당장, 현장에서 돌고 있는 AI의 "지금 버전"을 세 줄로 적어보세요. 모델 파일명, 학습 데이터 날짜, 프롬프트·규칙 버전. 이 세 줄이 안 적힌다면, 그 AI는 이미 버전이 꼬이기 시작한 상태입니다.

오늘(2026년 10월 24일) 나온 제조업 AI 전환 소식이 숫자로는 화려하고, 속으로는 뼈아프다. 한국 제조업 AI 전환(AX) 지원사업에 참여한 42개 사업장에서 생산성이 평균 30.1% 높아졌고, 제품 불량률은 15.5% 줄었다. 반도체 장비 검사부터 자동차 부품 생산, 선박 용접까지 AI가 실제 공정으로 들어간 결과다. 정부는 이 흐름을 이어 2030년까지 AI 팩토리 500곳 구축을 추진한다.

그런데 같은 날 함께 나온 글로벌 수치가 분위기를 바꾼다. 가트너가 10월 19일 미국 올랜도 IT 심포지엄에서 발표한 조사에 따르면 기업별 AI 활용 사업은 1년 새 평균 400% 넘게 늘었지만, 긍정적인 투자수익을 거둔 AI 활용 사업은 전체의 약 20%에 머물렀다. 도입은 폭발했는데, 돈이 되는 곳은 다섯 곳 중 한 곳뿐이라는 얘기다.

42곳의 30.1%는 어디에서 나왔나

기사에 등장하는 현장은 공통점이 있다. AI를 '도입한 공장'이 아니라 '공정과 연결한 공장'이다. 반도체 장비 검사에서는 사람이 눈으로 보던 검사를 AI가 맡아 검사 시간을 줄이고, 자동차 부품 생산에서는 공정 데이터를 실시간으로 보고 이상 징후에 대응하며, 선박 용접에서는 작업 품질 편차를 줄이는 방향으로 쓰였다.

현장에서 생산성 개선은 대개 한 번의 큰 기술이 아니라 작은 병목이 여러 개 풀리면서 쌓인다. 검사 대기 시간이 줄고, 재작업이 줄고, 설비 멈춤이 예고되는 식이다. 30.1%라는 평균 뒤에는 이런 '측정 가능한 변화'들이 있다. 그래서 이 숫자는 AI의 성능 지표가 아니라 운영 지표로 읽어야 한다.

400%와 20%의 간극이 말하는 것

가트너 수치가 불편한 이유는 단순하다. AI 활용 사업의 개수는 늘리기 쉽지만, 그 사업이 매출이나 원가에 닿으려면 공정·데이터·사람이 함께 바뀌어야 하기 때문이다. 모델을 붙였는데 데이터가 늦게 들어오면 판단이 늦고, 판단이 나와도 작업자가 믿지 않으면 실행이 안 된다. 결국 AI 도입 속도와 경제적 성과 속도가 벌어지는 지점이 바로 이 '연결'의 빈틈이다.

제조업에서 성과를 가르는 지표도 기사에 그대로 나와 있다. 생산 시간, 불량률, 설비 가동 시간, 품질검사 비용, 원자재와 에너지 사용량이다. 공장에 AI를 몇 개 깔았는지가 아니라, 이 지표 중 어느 하나라도 꾸준히 좋아졌는지가 전환의 증거다. 반대로 지표가 움직이지 않는데 활용 사업 수만 늘었다면, 그건 전환이 아니라 전시다.

7년차 현장 관점에서 보는 AX의 다음 관문

7년차 현장 엔지니어로서, 이 뉴스를 보며 가장 먼저 든 생각은 이것이다. AI 전환의 병목은 이제 모델이 아니라 '현장과 연결되는 마지막 10미터'다.

그래서 뭘 하면 되나. 공장에 AI를 들이기 전에, 먼저 한 가지 지표를 정하고 그 지표의 기준선부터 재는 것이다. 불량률이든 가동 시간이든, 기준선이 없으면 30.1% 같은 숫자도 남의 얘기가 된다. 그다음에는 데이터가 제때 들어오는지, 판단이 작업자의 손에 닿는지, 결과가 다시 학습으로 돌아오는지 순서대로 확인하면 된다. 42곳의 성과가 말해주는 것도 결국 이것이다. AI는 공장을 바꾸는 게 아니라, 공장이 이미 재고 있던 문제를 더 빨리 보이게 만들 뿐이다.

정부의 AI 팩토리 500곳 계획이 숫자로만 남지 않으려면, 각 현장이 '우리 공장의 30.1%는 무엇인가'라는 질문에 답할 수 있어야 한다. 그 답이 있는 공장부터가 진짜 AI 팩토리다.

출처: KtN(한국트렌디뉴스) 임우경 기자, "[AI 전환②] AI 활용 400% 급증…한국 제조업 42곳 생산성 30.1% 개선", 2026년 10월 24일. 가트너 IT 심포지엄 발표(2026년 10월 19일, 미국 올랜도) 인용.

관련 글: https://developer-archive.tistory.com/124, https://developer-archive.tistory.com/126, https://developer-archive.tistory.com/145

현장 데이터 파이프라인 EP.2 — 시리즈 이어서 읽기. 1편에서는 데이터가 '나오는 것'과 '쓸 수 있는 것' 사이의 4가지 막힘(수집·전송·저장·활용)을 정리했습니다. 오늘은 2편으로, 4가지 중 현장에서 제일 자주 깨지는 전송 구간을 깊게 팝니다. 끊김을 '장애'가 아니라 '전제'로 설계하는 법입니다.

현장 7년차로 말씀드리면, 이 문장으로 망가진 설계가 가장 많습니다. "MES로 MQTT 보내면 끝이죠?"

그렇게 만든 시스템은 시운전 때 잘 돌아갑니다. 그런데 주말 야간에 무선 AP가 한 번 재부팅되거나, 방화벽 정책이 바뀌거나, 라인 재배치로 VLAN이 분리되면, 그날의 데이터는 그대로 허공에 증발합니다. 월요일 아침에 대시보드를 열면 밤 11시부터 아침 6시까지가 통째로 비어 있는 겁니다. 현장에서 전송이 끊기는 건 예외가 아니라 일상입니다.

끊김을 가정한 설계의 세 가지 원칙

1) 엣지에서 먼저 쌓아라 — "보내고 지우는" 순서 금지

데이터를 클라우드·MES로 보낸 뒤 로컬에서 지우는 설계는 한 번의 전송 실패에 무조건 데이터가 깨집니다. 반대로 합니다. 엣지(게이트웨이 PC, 산업용 미니 PC)에 먼저 쓰고, 전송이 확인된 것만 나중에 정리하는 겁니다.

현장에서는 보통 SQLite 같은 로컬 파일 DB나, 용량이 작으면 순환 링 버퍼(circular buffer)를 씁니다. "보낼 때까지 지우지 않는다" — 이 한 줄이 전송 구간의 첫 번째 생명선입니다.

2) 재전송은 '언제' '얼마나'가 문제 — 단순 무한 재시도가 답이 아니다

연결이 끊겼다고 매번 즉시 재시도하면, 네트워크가 살아나는 순간 수천 건이 한꺼번에 몰려 다시 죽습니다. 현장에서 쓰는 실전 패턴은 이렇습니다.

백오프(지수적 대기): 첫 재시도는 5초, 다음은 10초, 20초… 이렇게 늘려가며 서버·네트워크에 숨 쉴 틈을 줍니다.

배치 전송: 건별 전송이 아니라 100~1,000건을 묶어서 보내면 오버헤드가 확 줄어듭니다.

우선순위 분리: 알람·이상 신호는 실시간 큐로, 주기 계측 데이터는 지연 허용 큐로. 끊김이 길어질 땐 중요한 것부터 살아돌아옵니다.

3) 끊김 자체를 '관측'하라 — 전송률 모니터링이 곧 품질 지표

재전송이 조용히 잘 돌아간다고 끝이 아닙니다. 전송 구간의 건강을 보는 세 지표를 둡니다: ① 전송 성공률 (보낸 대비 서버 도착), ② 재전송 건수, ③ 최대 지연 시간(끊김 후 복구까지 가장 오래 걸린 시간). 이 셋을 대시보드 한 줄에 얹어두면, "어제 밤 라인이 끊겼다"는 사실을 다음날 아침에, 숫자로, 정확히 알 수 있습니다. 관측 없는 복구는 운이고, 관측 있는 복구는 운영입니다.

2편의 결론 — 네트워크를 믿지 말고, 버퍼를 믿어라

정리하면 이렇습니다. 엣지에서 먼저 쌓고(원칙 1), 똑똑하게 재전송하고(원칙 2), 끊김을 관측으로 붙잡는 것(원칙 3). 현장 네트워크가 100% 안정적인 공장은 제가 본 적이 없습니다. 그러니 설계의 전제는 단 하나 — "어느 날 밤은 끊긴다."

그래서 뭘 하면 되나 — 자사 엣지 게이트웨이에서 전송 실패 시 데이터를 로컬에 보관하는지, 보관한다면 최대 며칠치인지, 오늘 바로 확인해 보세요. 보관 자체가 없으면, 그 라인의 데이터는 네트워크 상태에 완전히 맡겨져 있는 겁니다.

다음 편(3편)은 저장 구간의 심화 — 타임스탬프·설비 ID·단위 통일의 '스키마 계약' 만들기를 다룹니다.

"예지정비 모델 하나 만드는 데 2주." 제철소 설비 엔지니어에게는 꽤 일상적인 숫자였다. 데이터를 모으고, 분석 코드를 짜고, 모델을 학습·검증·배포하는 전 과정이 전문가의 손을 거쳐야 했기 때문이다. 포스코 광양제철소가 AWS와 함께 공개한 'InnoPIMS'는 이 숫자를 "2일"로 바꿨다. 비결은 더 좋은 알고리즘이 아니다. AI '에이전트'가 개발 과정 자체를 맡았기 때문이다.

1. InnoPIMS는 무엇인가 — 코딩 없이 모델을 만드는 AI 에이전트

InnoPIMS는 포스코 광양제철소가 AWS 클라우드와 AI 에이전트 기반으로 개발한 설비 이상예지 모델이다(AWS Summit Seoul 2026에서 EIC기술부 조현영 리더가 소개). 핵심은 단순하다. 설비 고장과 관련된 데이터를 AI 에이전트가 자동으로 분석하고, 현장 엔지니어가 별도의 코딩 없이 이상예지 모델을 직접 만들고 적용할 수 있게 한 것이다.

숫자로 보면 이렇게 된다. 평균 2주 걸리던 이상예지 모델 개발 기간이 약 2일로, 약 80% 단축됐다(파일럿 운영 실측). 그 바탕에는 포스코의 스마트 설비관리 시스템 PIMS(POSCO Intelligent Maintenance System)가 있다. PIMS를 활용한 설비장애 예방 효과가 쌓이면서 2026년 8월 기준 설비장애로 인한 긴급정비 건수는 전년 동기 대비 약 50% 감소했다(출처: 매일경제, 매일신문·경북일보 2026-10-05 보도).

2. 왜 중요한가 — "개발 기간 단축"이 진짜 핵심이 아니다

여기서 한 번 멈춰보자. 2주→2일은 인상적이지만, 진짜 변화는 기간이 아니라 '만드는 사람'이다. 지금까지 제조 AI는 "데이터팀이 만들어 현장에 전달"하는 구조였다. 에이전트는 이 흐름을 뒤집는다. 현장을 아는 엔지니어가 직접 모델을 만들고 고치는 구조다.

이게 왜 큰 일인지, 현장에 있어본 사람은 안다. 제조 AI가 현장에서 안 통하는 이유 1순위는 정확도가 아니라 "현장 언어를 모르는 모델"이다. 설비의 이상 징후가 어떤 맥락에서 나왔는지 아는 사람은 현장 엔지니지, 데이터팀이 아니다. 도메인 지식과 AI 도구가 같은 사람의 손에 들어오는 순간, 보도에서 언급된 "직원 역량 편차로 인한 품질 유지의 한계"도 함께 풀리기 시작한다.

3. 7년차 현장 관점 — 에이전트가 공장에서 살아남는 조건 3가지

뉴스는 장밋빛이지만, 현장 엔지니어의 눈으로 보면 에이전트가 진짜로 살아남으려면 세 가지가 따라와야 한다.

첫째, 노하우의 자산화. 포스코는 같은 달 '예지정비 고도화 원팀'을 본격 가동했다(포항·광양 설비부문+기술전략실). PIMS 활용 우수사례를 사내망에 등록·공유하고, 우수제안 가이드라인과 보상체계까지 만들었다. 에이전트가 아무리 좋아도 현장의 노하우가 데이터로 쌓이지 않으면, 에이전트는 매번 처음부터 시작하는 셈이다.

둘째, 검증 루프. 에이전트가 만든 모델을 누가, 어떤 기준으로 검증하는가. 자동으로 만들어진 모델일수록 "왜 이런 판단을 했는지"를 따지는 과정이 빠져서는 안 된다. 모델의 재현성이 무너지면 현장의 신뢰도 함께 무너진다(관련 글: #125 'AI 데모는 됐는데 현장에서 안 되는 이유').

셋째, 권한 설계. 예지정비가 '알려주는 것'에서 멈추지 않고 '조치'까지 가려면, AI에게 어디까지 허용할지를 먼저 정해야 한다. 모델이 자동으로 밸브를 잠그게 할 것인가, 아니면 알람만 울리게 할 것인가. 이 경계 없이 에이전트를 현장에 풀면, 가장 먼저 깨지는 건 기술이 아니라 조직의 신뢰다(관련 글: #145 '공장용 AI 챗봇이 첫 주에 망한 이유 — 프롬프트가 아니라 권한 문제였다').

7년차 현장 엔지니어로서 한 줄 정리하자면, 에이전트 시대의 제조 AI는 더 이상 'AI를 아는 사람'의 전유물이 아니다. 현장을 아는 사람이 AI를 직접 다루는 시대가 왔다.

그래서 뭘 하면 되나. 우리 공정의 이상 징후 데이터를 에이전트가 읽을 수 있는 형태로 정리하는 것부터 시작하자. 모델보다 데이터 파이프라인이 먼저다(관련 글: #124 '디지털트윈의 진짜 엔진은 3D가 아니라 데이터 수집이다', #126 '예지정비 EP.1').

오늘 아침 쇼츠에서는 "MQTT는 센서들이 가볍게 메시지를 주고받는 규약이에요"라고 30초로 정리했습니다. 그런데 막상 현장에 MQTT를 들여놓으려면 '가볍다'는 말만으로는 부족합니다. 브로커는 어디에 두고, 토픽은 어떻게 짓고, 어떤 데이터에 QoS를 몇으로 주는지 — 오늘은 그 설계 감각을 정리합니다.

MQTT는 왜 공장에서 쓰는가

MQTT(Message Queuing Telemetry Transport)는 발행(publish)·구독(subscribe) 방식의 경량 메시징 규약입니다. 핵심 차이는 '누가 연결을 여는가'가 아니라 '누가 누구와 연결되는가'입니다. HTTP처럼 센서가 서버에 직접 요청을 보내는 대신, 모든 기기가 브로커라는 중계자에 메시지를 발행하고, 필요한 쪽이 토픽을 구독합니다.

현장 관점에서 이 구조가 좋은 이유는 세 가지입니다.

대역폭이 작다: 헤더가 2바이트부터 시작합니다. 저사양 센서 노드에서도 부담이 적고, 와이파이가 불안정한 공장 구석에서도 돌아갑니다.

연결이 단순하다: 기기는 브로커하고만 연결하면 됩니다. 설비가 100대로 늘어나도 각 기기가 알아야 할 상대는 브로커 하나뿐입니다.

실시간성이 자연스럽다: 주기적 폴링이 아니라 "값이 바뀌면 발행"입니다. 디지털트윈의 데이터 흐름과 궁합이 좋습니다.

용어 3종 세트: 브로커 · 토픽 · QoS

브로커(Broker)는 메시지를 받아 구독자에게 전달하는 중계 서버입니다. 현장 비유로는 공장의 우체통입니다. 토픽(Topic)은 메시지의 주소로, 계층 구조로 씁니다. 예: factory/line2/robot3/temperature. QoS는 메시지 전달 보장 수준으로 0·1·2 세 단계입니다. 현장 비유로는 일반·등기·내용증명입니다.

QoS 0은 '보내고 끝'입니다. 온도처럼 주기적으로 오르고 유실돼도 괜찮은 데이터에 씁니다. QoS 1은 '적어도 한 번'입니다. 알람처럼 놓치면 안 되는 신호에 씁니다(중복 수신 가능). QoS 2는 '정확히 한 번'입니다. 과금이 걸리는 지령처럼 엄격한 경우에만 씁니다. 트래픽 비용이 크니 남발하지 않습니다.

현장에서 쓰는 MQTT 설계 3원칙

① 토픽 계층은 처음에 잡는다. "현장/라인/설비/센서" 같은 규칙을 문서로 먼저 정합니다. 나중에 토픽이 200개가 돼서 섞이면 구독자 쿼리가 지옥이 됩니다.

② QoS는 데이터 성격으로 고른다. 주기 텔레메트리는 QoS 0, 알람은 QoS 1, 제어 지령은 QoS 1~2. 전부 QoS 2로 주면 브로커가 버거워집니다.

③ 장애를 미리 알린다. MQTT에는 LWT(Last Will, 유언 메시지)와 Retained(최신값 유지) 기능이 있습니다. 설비가 네트워크에서 끊기면 브로커가 미리 등록된 '연결 끊김' 메시지를 자동으로 발행하고, 새로 구독한 대시보드는 retained 메시지로 최신값을 즉시 받습니다. 이 두 줄 설정이 관제실 전화 몇 통을 막아줍니다.

그래서 뭘 하면 되나

MQTT는 기술보다 '설계 약속'이 먼저입니다. 오늘 할 일은 하나. 노트북에 Mosquitto 브로커를 띄우고, 토픽 규칙을 한 장으로 적어보세요. 설비 데이터의 절반은 MQTT로 충분하고, 나머지 절반은 그때 OPC UA를 꺼내면 됩니다.

지난 회차: 제조AI 용어 사전 EP.3 — OPC UA (https://developer-archive.tistory.com/136), EP.1 — 예지정비 (https://developer-archive.tistory.com/126)

도입 — "공장"을 교실에 가져온 날

몇 달 전, 한 고등학교에서 특강 제안을 받았습니다. 주제는 "유니티로 만드는 스마트팩토리". 학생들 앞에서 컨베이어 벨트가 움직이고, 로봇팔이 박스를 집는 미니 공장을 유니티로 직접 돌려보는 수업이었습니다.

강의 준비하면서 저는 꽤 자신 있었습니다. 7년차 현장 엔지니어로 스마트팩토리는 매일 보는 풍경이니까요. 그런데 수업이 끝나고 집에 돌아오는 길, 깨달았습니다. 가르친 건 저였는데, 배운 것도 저였습니다. 오늘은 그날 다시 배운 세 가지를 적어봅니다.

1. 현장은 "데이터 수집"부터 말하는데, 교실은 "3D"부터 말한다

첫 시간, 학생들에게 물었습니다. "스마트팩토리 하면 뭐가 떠올라?" 돌아온 답은 열에 아홉이 "멋진 3D 공장 시뮬레이션"이었습니다. 그래서 7년차 현장 엔지니어로서 한 마디를 던졌습니다.

"현장에서 디지털트윈이 안 굴러가는 이유 1위는 3D가 아니라 데이터 수집이에요."

이전 글(https://developer-archive.tistory.com/124)에서도 썼지만, 현장의 디지털트윈은 PLC·센서에서 데이터를 제대로 뽑아내지 못하면 3D가 아무리 화려해도 그냥 동영상일 뿐입니다. 모드버스 주소 맵 하나, OPC UA 노드 하나가 화면의 컨베이어보다 먼저라는 걸, 학생들은 그날 처음 알았습니다.

2. "쉬운 질문"이 제일 어렵다 — "왜 이걸 자동화해야 돼요?"

수업 중반, 한 학생이 손을 들었습니다. "선생님, 사람이 하면 되는데 왜 굳이 로봇이 해요?"

처음엔 웃었습니다. 그런데 이 질문은 사실 업계가 10년째 답하는 질문입니다. 저는 이렇게 답했습니다. "사람이 지루해서 그래. 같은 동작을 8시간 반복하면 사람도 지치고, 지치면 품질이 무너져. 로봇은 지루함을 모르니까."

그 학생의 눈빛이 바뀌는 걸 봤습니다. '자동화 = 일자리를 뺏는 기술'이라는 프레임이 '자동화 = 사람을 지루함에서 해방하는 기술'로 바뀐 순간이었습니다. 7년차 현장 엔지니어로서, 저는 정작 현장에서 이 쉬운 질문에 답할 준비를 해본 적이 없다는 걸 반성했습니다.

3. 학생들이 만든 공장은 "돌아가야" 의미가 있다

마지막 실습에서 학생들은 각자 미니 공장을 만들었습니다. 어떤 학생은 컨베이어 속도를 너무 빠르게 해서 박스가 다 떨어졌고, 어떤 학생은 로봇팔 위치를 안 맞춰 박스를 허공에서 잡았습니다.

저는 고치지 않았습니다. 대신 물었습니다. "왜 박스가 떨어졌을까?" 학생이 스스로 속도를 낮추고, 다시 돌려서 박스가 무사히 이동하자 교실 전체가 박수를 쳤습니다.

현장에서 시운전할 때도 똑같습니다. 기계가 처음부터 잘 도는 일은 없어요. 틀리고, 원인 찾고, 고치고, 다시 돌리는 이 루프 자체가 엔지니어의 일입니다. 학생들이 그날 배운 건 유니티 사용법이 아니라, 이 루프를 두려워하지 않는 법이었습니다.

마무리 — 그래서 뭘 하면 되나

7년차 현장 엔지니어로서, 이 강의를 계기로 하나를 다짐했습니다. 현장 경험을 "교실 언어로 번역하는" 습관을 계속 들이자는 것. 기술은 복잡할수록 쉬운 말로 풀 수 있어야 진짜 이해한 것이고, 그 이해가 쌓이면 현장이 조금씩 좋아집니다.

그래서 뭘 하면 되나? 이번 주에 한 가지, 내가 아는 기술을 "초등학생에게 설명하듯" 세 문장으로 정리해 보세요. 못 쓰겠으면, 아직 모르는 게 있다는 뜻입니다. 저도 다음 강의 전에 다시 연습하려고 합니다.

오늘(2026년 10월 23일) 온디바이스 AI·로보틱스 기업 인티그리트가 로봇의 행동과 위험을 미리 예측하는 AI 기술에 관한 국내 특허 4건을 등록했다고 밝혔다(CNB뉴스). 단순히 "물체를 옮겨라"는 명령을 수행하는 수준을 넘어, "내가 이렇게 움직이면 물건이 어떻게 될까, 설비에 이상은 없을까"를 실행 전에 예측하는 기술이다. 시각·언어·행동 모델(VLA)에 월드모델(World Model)과 시계열 기반 모델(TSFM)을 결합한 '예측형 피지컬 AI 플랫폼'을 개발 중이라는 발표다.

'움직이는 AI'에서 '예측하는 AI'로

세 기술의 역할을 나누면 이렇다. VLA는 로봇이 카메라와 센서로 주변 환경을 인식하고 사람의 언어 명령과 상황을 이해해 행동을 생성하는 기술이다. 예를 들어 물체를 옮기라는 명령을 받으면 대상 물체와 주변 환경을 파악한 뒤 필요한 움직임을 결정하는 데 쓰인다. 지금까지 피지컬 AI 논의의 대부분은 이 단계에 머물러 있었다.

여기에 두 가지 예측 기술이 붙는다. 월드모델은 로봇이 특정 행동을 실행하기 전에 물체의 위치와 상태, 주변 환경이 어떻게 달라질지를 예측한다. TSFM은 시간에 따라 축적되는 로봇과 설비의 작동 데이터를 분석해 반복적으로 나타나는 변화와 이상 징후를 파악하고, 향후 상태나 잠재적 위험을 예측한다. 월드모델이 "행동에 따른 물리적 변화"를 본다면, TSFM은 "시간의 흐름에 따른 상태 변화와 위험 징후"를 본다. 인티그리트는 이 예측 결과를 로봇의 행동 계획과 실행 과정에 연결하는 통합 AI 구조를 개발하고 있다.

7년차 현장 관점에서 본 의미 — 안전은 '설계'의 문제가 된다

현장에서 로봇 한 대가 충돌 하나로 멈추면, 그 로봇만 멈추는 게 아니다. 라인이 선다. 지금까지 로봇의 안전은 펜스, 라이트커튼, 토크 제한 같은 하드웨어의 영역이었다. 로봇 스스로 행동 전에 결과를 예측할 수 있다면 안전은 소프트웨어의 영역으로 넘어온다.

7년차 현장 엔지니어로서 한 줄로 정리하면 이렇다. 로봇 사고의 대부분은 '못 봐서'가 아니라 '못 예측해서' 일어난다 — 예측이 들어가는 순간, 안전은 감지의 문제가 아니라 설계의 문제가 된다.

또 하나, 이 기술은 디지털트윈의 진화형으로 보는 게 정확하다. 지금까지 디지털트윈은 '현재의 거울'이었다. 실제 설비와 동기화된 상태를 보여주는 것까지가 역할이었다. 월드모델은 거기에 시간축을 얹는다. '미래의 거울'이 되는 셈이다. TSFM은 내가 앞서 다룬 예지정비의 로봇 버전이다. 시계열 데이터로 이상 징후를 보는 방식이 같기 때문이다(관련 글: 제조AI 용어 사전 EP.1 예지정비 https://developer-archive.tistory.com/126).

생태계 승부 — 2027년 1월 개발키트가 관전 포인트

눈여겨볼 대목은 플랫폼 전략이다. 인티그리트가 개발하는 플랫폼은 특정 휴머노이드 제조사나 하드웨어에 종속되지 않는 개방형 구조를 지향한다. 로봇 제조기업이 자체 하드웨어를 유지하면서 VLA와 예측모델을 적용하고, 센서 및 제어 시스템을 연동할 수 있도록 지원하는 방식이다.

자체 기술 스택도 공개됐다. 에어패스(AirPath)는 로봇에서 AI를 실행하기 위한 엣지 컴퓨팅 및 구동환경, 시나AI(SynaAI)는 온디바이스 AI 모델과 실행기술, 플라잉렛 시냅스(FlyingLet Synapse)는 로봇의 작업 임무와 AI 모델, 현장 데이터를 통합하는 역할을 맡는다. 이들을 연결해 AI 모델 최적화부터 로봇 제어, 현장 데이터 수집, 모델 검증까지 수행할 수 있는 개발·운영환경을 구축한다는 구상이다. 활용 분야로는 반도체·제조·물류·시설관리 등 산업현장과 가정용 휴머노이드가 제시됐다.

현장에는 이미 여러 브랜드의 로봇이 섞여 있다. "어떤 로봇이냐"가 아니라 "어떤 실행환경이냐"로 승부가 넘어가는 셈이다. 2027년 1월 관련 개발키트 공개가 예고돼 있는데, 이 생태계가 실제로 열리는지가 내년 피지컬 AI 시장의 관전 포인트가 될 것이다.

이번 주 흐름을 놓고 보면 그림이 선명하다. 모델 전쟁이 인프라 전쟁으로 넘어가는 가운데(10-21 트렌드 글 참조), 피지컬 AI도 '움직이는 모델' 경쟁에서 '예측하는 플랫폼' 경쟁으로 이동 중이다. 현장 엔지니어에게 남는 숙제는 예나 지금이나 같다. 데이터 수집이다. 예측의 정확도는 쌓인 시계열 데이터의 질로 갈린다.

뉴스 출처: CNB뉴스, 「인티그리트, 로봇 행동-위험 예측 AI 개발…핵심 특허 4건 등록」, 2026-10-23

등록 특허 4건: ① VLM 기반 다중 조건 행동 우선순위 결정 및 설명 시스템 ② 적응형 VLA 컨시어지를 위한 홈 게이트웨이 시스템 ③ 상황별 멀티미디어 데이터 생성형 홈 로봇 시스템 ④ 비전 인식 기반 자율주행 및 무선통신 지원 이동 로봇 시스템