표준 데이터 엔지니어링(Data Engineering)이나 머신러닝(ML) 분야에서 산업용 센서 데이터 분야로 넘어온 엔지니어라면 누구나 비슷한 깨달음을 얻게 됩니다. 산업용 센서의 시계열 데이터(Time-series data)는 익숙해 보입니다. 타임스탬프(Timestamp)가 찍힌 숫자일 뿐이니까요, 그렇지 않나요? 하지만 소비자용 또는 기업용 소프트웨어 데이터에 기반해 구축된 모든 파이프라인(Pipeline)의 가정을 깨뜨리는 방식으로 동작하기 시작할 때까지는 말입니다.

문제는 산업용 센서 데이터가 이질적이라는 것이 아닙니다. 대부분의 ML 엔지니어가 다뤄온 데이터 유형에는 존재하지 않으며, 다른 맥락에서는 너무나 표준적이어서 명시적으로 언급조차 되지 않는 가정들을 위반하는 특정한 통계적 특성과 장애 패턴을 가지고 있다는 점입니다.

가장 중대한 문제들과 각 문제에 대한 견고한 파이프라인 설계 방안은 다음과 같습니다.

정상성(Stationarity) 가정이 예측 가능하지만 명확하지 않은 방식으로 실패함

표준 시계열 분석(Time-series analysis)과 대부분의 ML 접근 방식은 시계열의 통계적 특성이 시간이 지나도 안정적이라는 것, 또는 적어도 비정상성(Non-stationarity)이 모델링 가능한 패턴을 따른다는 것을 가정합니다. 산업용 센서 데이터는 단기 테스트에서는 놓치기 쉽지만, 수개월간의 생산 과정에서는 심각한 문제가 되는 특정한 유형의 비정상성을 가지고 있습니다.

산업용 센서는 하드웨어가 노후화됨에 따라 드리프트(Drift) 현상이 발생합니다. 온도 센서, 압력 트랜스듀서(Pressure transducer), 또는 진동 센서의 기준 출력값은 참조 소자가 열화되고, 진동으로 인한 마모로 장착 특성이 변하며, 환경 노출이 누적됨에 따라 수개월의 작동 기간 동안 점진적으로 변화합니다. 이러한 드리프트는 일일 비교에서는 보이지 않을 정도로 느리지만, 6개월에서 12개월이 지나면 시운전 기간의 데이터로 학습된 모델을 체계적으로 틀리게 만들 정도로 유의미해집니다.

// 월간 데이터 샘플에서 관찰되는 모습 — 정상적으로 보임:
month_1_mean: 42.3, month_1_std: 1.2
month_2_mean: 42.5, month_2_std: 1.2
...

이를 위한 파이프라인을 설계하려면 실제 드리프트 (drift)와 실제 이상치 (anomaly)를 구분할 수 있는 명시적인 베이스라인 추적 (baseline tracking)이 필요합니다. 이는 말처럼 쉽지 않은데, 관련 타임스케일 (timescales)을 주의 깊게 살피지 않으면 실제 이상치가 드리프트처럼 보이는 패턴을 생성할 수 있기 때문입니다.

결측치 (Missingness)는 무작위가 아니라 정보를 담고 있습니다

대부분의 대체 (imputation) 전략은 결측치가 무작위로 발생한다고 가정합니다. 즉, 데이터가 누락될 확률이 해당 데이터가 무엇이었는지와는 독립적이라고 가정하는 것입니다. 하지만 산업용 센서 데이터는 이 가정을 체계적으로, 그리고 특히 문제가 되는 방향으로 위반합니다.

산업 시설의 네트워크 연결성은 운영 부하가 정점에 달할 때 저하됩니다. 가동 중인 중장비는 전자기 간섭 (electromagnetic interference)을 발생시킵니다. 생산량이 많은 기간은 유휴 기간보다 무선 인프라에 더 많은 부담을 줍니다. 그 결과, 장비가 가장 격렬하게 작동하고, 부하가 가장 높으며, 이상 수치가 발생할 가능성이 가장 큰 조건에서 데이터가 가장 빈번하게 누락됩니다.

이는 표준적인 대체 (imputation) 방식을 사용하여 산업 데이터로 학습된 모델이, 이상 탐지 (anomaly detection) 및 예지 보전 (predictive maintenance)에 가장 중요한 조건들이 체계적으로 과소 대표된 데이터셋으로 학습되었음을 의미합니다.

이에 대한 견고한 설계 대응책은 연결 끊김 (connectivity gaps)을 대체해야 할 결측값이 아닌 하나의 피처 (feature)로 취급하는 것입니다. 생산 시간 중 일정 시간 이상의 공백은 네트워크 상태, 장비의 작동 가능성, 그리고 발생했을 법한 측정값에 대한 정보를 담고 있습니다. 공백 지표 (gap indicators)와 공백 지속 시간 (gap duration)을 명시적인 입력 피처로 포함하는 모델은 이를 올바르게 처리하지만, 대체된 값을 실제 측정값과 동일하게 취급하는 모델은 그렇지 못합니다.

재시도 로직으로 인한 중복 측정값은 수집 단계에서 명시적인 중복 제거가 필요합니다

산업용 IoT (Industrial IoT) 펌웨어는 일반적으로 장치 수준에서 재시도 로직 (retry logic)을 구현합니다. 데이터 전송이 확인 응답 (acknowledgment)을 받지 못하면, 장치는 측정값을 재전송합니다. 이는 불안정한 연결성 환경에서 데이터 전달을 보장하기 위한 올바른 동작이지만, 파이프라인 측면에서는 과제를 안겨줍니다. 동일한 물리적 측정값이 동일하거나 거의 동일한 타임스탬프 (timestamp)와 함께 여러 번 도착하며, 데이터 자체에는 어떤 것이 원본이고 어떤 것이 재전송된 것인지 식별할 수 있는 정보가 전혀 없기 때문입니다.

집계된 머신러닝 (ML) 학습 데이터에서, 이는 연결 실패가 빈번했던 기간—앞서 언급했듯이 부하가 높은 기간이기도 한—에 발생한 측정값의 비중을 비정상적으로 높입니다. 결과적으로 모델은 부하가 높은 운영 상태가 실제로 어떤 모습인지에 대해 편향된 (biased) 버전을 학습하게 됩니다.

수집 (ingestion) 단계에서의 중복 제거 (deduplication)는 엄격한 타임스탬프 일치 방식보다는 윈도우 기반 (window-based) 전략을 필요로 합니다. 펌웨어의 클록 드리프트 (clock drift)로 인해 재전송된 측정값의 타임스탬프가 원본과 몇 초 정도 차이가 날 수 있기 때문입니다.

// 단순한 중복 제거 방식 (펌웨어 클록 드리프트 발생 시 실패):
const deduplicated = readings.filter((r, i, arr) =>
  arr.findIndex(x => x.timestamp === r.timestamp) === i
...

이러한 전처리 세부 사항은 실제 산업 현장에 배포된 파이프라인에서만 나타나는 특징입니다. 이것이 바로 Aperture Venture Studio의 Aperture AIoT 플랫폼과 같이 실제 운영을 통해 개발된 플랫폼 인프라가 설계 단계부터 이를 처리하는 반면, 이론적으로 구축된 인프라는 보통 운영 환경 (production)에 도달해서야 이 문제를 발견하게 되는 이유 중 하나입니다.

측정값을 해석 가능하게 만드는 운영 컨텍스트는 데이터 안에 있지 않습니다

산업용 센서의 측정값은 데이터베이스 스키마(database schemas)가 포착하지 못하는 방식으로 문맥 의존적(contextually dependent)입니다. 동일한 센서에서 측정된 동일한 온도 값이라도, 장비가 풀 로드(full load)로 가동 중인지, 공회전(idling) 중인지, 예열(warming up) 중인지, 아니면 유지보수 후 냉각(cooling) 중인지에 따라 의미가 달라집니다. 베어링에서 측정된 동일한 진동 값 또한 베어링의 노후도, 유지보수 이력, 그리고 최근의 부하 프로파일(load profile)에 따라 달라집니다.

이러한 문맥 중 그 어느 것도 센서 데이터 스트림(data stream)에는 포함되어 있지 않습니다. 이러한 정보는 생산 시스템—MES(제조 실행 시스템), 작업 지시 관리(work order management), 유지보수 관리 소프트웨어—에 존재하며, 이러한 시스템들은 ML 추론 파이프라인(ML inference pipeline)의 실시간 쿼리(real-time query)를 위해 설계되지 않았습니다.

운영 문맥(operational context)을 고려하는 모델을 구축하려면, 생산 시스템 데이터를 ML 파이프라인으로 수집하거나(자체적인 API 제약이 있는 레거시 시스템과의 양방향 통합), 센서 데이터만으로 프록시 피처(proxy features)를 구축해야 합니다. 두 방법 모두 명시적인 설계가 필요한 트레이드오프(tradeoffs)를 가지고 있습니다. 운영 문맥을 무시하는 모델은 잘못된 양성(false positive) 패턴을 생성하며, 이는 수개월간의 배포 과정에서 운영자의 신뢰를 떨어뜨리기 때문입니다.

산업용 센서 데이터의 전처리 단계 중 귀하의 모델의 실제 성능에 가장 큰 영향을 미친 것은 무엇인가요? 댓글로 들려주세요.

iot #ai #machinelearning #embedded #architecture #discuss #programming #industry40 #mlops #softwareengineering #reliability #deeptech #timeseries