데이터는 흐르는데 못 쓴다 — 현장 데이터 파이프라인의 4가지 막힘 (현장 데이터 파이프라인 EP.1)

[현장 데이터 파이프라인] 시리즈를 시작합니다. 지난 시리즈(합성 데이터 1~5편)가 '데이터가 없다'는 핑계를 없애는 이야기였다면, 이번 시리즈는 정반대 — '데이터는 있는데 못 쓰는' 현장의 배관 문제를 다룹니다. 1편(https://developer-archive.tistory.com/127) · 2편(https://developer-archive.tistory.com/128) · 3편(https://developer-archive.tistory.com/133) · 4편(https://developer-archive.tistory.com/137) · 최종회(https://developer-archive.tistory.com/143).

 

현장에서 가장 흔한 착각 하나. "PLC에서 데이터가 나오고 있으니 데이터 수집은 끝났다."

 

아닙니다. 현장 7년차로 말씀드리면, 데이터가 '나오는 것'과 '쓸 수 있는 것' 사이에는 배관 전체가 놓여 있습니다. 수집-전송-저장-활용, 이 네 구간 중 하나라도 막히면 AI는 목이 말라 죽습니다. 오늘은 제가 현장에서 가장 자주 본 4가지 막힘을 정리합니다.

 

막힘 1 — 수집: 폴링 주기가 '빠른 것'과 '맞는 것'을 헷갈린다

 

PLC 스캔 타임보다 짧은 주기로 읽으면 같은 값이 찍히고, 너무 길면 이벤트를 놓칩니다. 정답은 "설비가 변하는 속도"에 맞추는 것. 온도처럼 느리게 변하는 신호는 수십 초 간격이면 충분하고, 서보 부하처럼 빠르게 바뀌는 신호는 밀리초 단위 버퍼가 필요합니다. 현장에서 1초 폴링으로 다 읽겠다고 하면, 진짜 중요한 건 다 놓치고 디스크만 채웁니다.

 

막힘 2 — 전송: 현장 네트워크는 사무실 네트워크가 아니다

 

MES에 MQTT로 보낸다고 설계해 놓고, 실제 라인의 무선 품질·방화벽 정책·VLAN 분리를 확인 안 한 케이스가 한둘이 아닙니다. 현장에선 전송이 끊기는 게 정상입니다. 그래서 끊김을 가정한 설계가 기본입니다. 엣지에서 일정 기간 버퍼링했다가 복구 후 재전송하는 구조가 없으면, "데이터가 있다"는 말은 낮에만 통하는 말이 됩니다.

 

막힘 3 — 저장: 파일로 쌓아두면 '저장'이 아니라 '방치'다

 

CSV로 날짜별 폴더에 쌓는 건 현장의 오래된 습관입니다. 그런데 타임스탬프 형식이 파일마다 다르고, 설비 ID가 현장 약칭으로 적혀 있으면, AI 팀이 쓰는 첫 달은 전부 정제에 들어갑니다. 저장 단계에서 통일된 타임스탬프(UTC 기준), 설비 고유 ID, 단위 명시가 붙지 않으면, 저장된 데이터는 자산이 아니라 부채입니다.

 

막힘 4 — 활용: 데이터를 보는 '주인'이 없다

 

제일 치명적입니다. 파이프라인이 다 돌아도, 이상 신호를 매일 한 번씩 눈으로 보는 사람이 없으면 아무 일도 안 일어납니다. 대시보드를 만들어 두는 것과 누군가 책임지고 보는 것은 완전히 다릅니다. 파이프라인의 마지막 구간은 기술이 아니라 운영입니다 — 보는 사람, 보는 주기, 이상 시 연락망이 정해져야 배관이 살아 있습니다.

 

1편의 결론 — 배관은 '연결'이 아니라 '유지'다

 

데이터 파이프라인은 만들 때 끝나는 게 아닙니다. 수집 주기가 현장 변화 속도와 맞는지, 전송이 끊김을 가정했는지, 저장이 통일된 규격을 갖는지, 활용에 주인이 있는지. 이 네 가지를 점검표로 만들어 월 1회 돌리는 것만으로도 대부분의 '데이터는 있는데 못 쓴다'는 끝납니다.

 

그래서 뭘 하면 되나 — 오늘 네 막힘 중 자사 라인에 가장 가까운 하나를 골라, 점검 담당자 한 명의 이름부터 적어보세요. 파이프라인은 도면으로 완성되지 않고, 사람의 루틴으로 완성됩니다.

 

다음 편(2편)은 전송 구간의 심화 — 엣지 버퍼링과 재전송 설계의 실제 패턴을 다룹니다.