많은 "AIoT" 관련 글들은 단순히 "AI + IoT = 스마트"라는 표면적인 부분만을 다룹니다. 하지만 엔지니어라면, 센서를 모델에서 작동하도록 설정하는 과정이 매우 흥미로울 것입니다. 왜냐하면 장치와 모델 사이의 파이프라인이 현장의 데이터와 예측 가능한 데이터 사이를 이어주는 엔지니어링이자 접착제(glue) 역할을 하기 때문입니다. 이 접착제가 실패하면, 여러분의 모델이 아무리 뛰어나더라도 무의미해집니다.

이 글에서는 실제 운영(production) 시나리오에서 유효한 시스템 아키텍처 모델과, 기업들이 공장이나 창고 현장에서 프로토타입 단계에서 운영 단계로 업그레이드할 때 흔히 범하는 실수들을 살펴봅니다.

산업용 데이터 파이프라인은 왜 다른 IoT 파이프라인과 다른가?

소비자용 IoT 파이프라인은 일반적으로 관용적입니다. 스마트 온도 조절기가 몇 분 동안 수치를 읽지 못한다고 해서 큰 영향이 있지는 않습니다. 하지만 산업용 파이프라인에서는 이것이 선택 사항이 아닙니다. 압축기(compressor)의 진동을 수집하는 센서가 작동을 멈추거나, 안전 카메라에서 프레임이 누락되는 경우, 그것이 바로 사고나 고장을 예측할 수 있었던 단 하나의 데이터 포인트였을 수도 있기 때문입니다.

이는 모든 것에 대한 시스템 엔지니어링 요구사항을 변화시킵니다:

• 장비가 신뢰할 수 있는 네트워크를 갖추지 못했을 수 있으며, 대개 제약이 있습니다. (산업용 Wi-Fi, LTE-M, LoRaWAN)
• 데이터는 조용한 오류(silent errors)가 아닌, 간헐적 끊김(intermittence) 상황에서도 생존해야 합니다.
• 속도에 대한 요구사항은 사용 방식에 따라 다양합니다. 안전 경보의 경우 1초 미만의 트리거가 필요하며, 재고 추세를 위한 데이터는 몇 분 정도 늦어도 괜찮습니다.
• 모델 구현은 엣지(edge)에서 클라우드(cloud) 사이의 무엇이든 될 수 있으며, 동일한 위치에 고정되어 있지 않습니다.

아키텍처의 예시

다양한 용도(자산 추적, 직원 안전, 장비 모니터링)에 걸쳐 일반화할 수 있는 예시는 다음과 같습니다:

Edge 계층 (The Edge layer) – 장치(센서, RFID 리더, 카메라, PLC)가 로컬 게이트웨이(Gateway)로 원시 데이터(raw data)를 전송합니다.
Edge 계층 전처리 (The Edge layer preprocessing) – 네트워크 부하와 지연 시간(latency)을 줄이기 위해 장치 자체에서 필터링(filters), 중복 제거(dedup), 일부 미니 모델(예: 이상 징후 플래그(anomaly flags))이 구현됩니다.
버퍼링된 전송 계층 (Buffered transport layer) – 메시지 큐(MQTT)는 일반적으로 네트워크 중단 시 데이터 손실을 방지하기 위해 로컬 버퍼링을 포함합니다.
데이터 수집 계층 (The data collection layer) – 벤더(vendor)마다 데이터를 다르게 보고하는 경향이 있으므로, 들어오는 페이로드(payloads)를 표준 스키마(standard scheme)에 매핑합니다.
시계열 데이터베이스 (A Time Series Database) – 일반적인 데이터베이스와 달리 이 특정 사용 사례에 맞게 설계되었습니다(예: InfluxDB, TimescaleDB). 이는 쿼리(query)가 보통 시간 범위를 대상으로 하기 때문입니다.
모델 (The Model) – 요구 사항에 따라 배치(Batch) 및/또는 스트림 추론(stream inference)을 수행합니다. 예측 결과는 운영 인터페이스로 전송되거나 자동으로 동작을 트리거합니다.

많은 사람들이 모델에 원시 센서 데이터를 전달하기 위해 이 전체 스택을 건너뛰곤 합니다. 이는 이상적인 상황에서 단 하나의 장치 유형만 사용할 때는 작동합니다. 하지만 다른 벤더의 장비를 도입하거나 네트워크가 불안정해지면 시스템은 무너집니다.

Edge vs. Cloud: 모델을 언제 구현해야 하는가?

이것은 제가 가장 많이 받는 질문이며, 유일하게 정확한 답변은 여러분이 어떤 리스크(risk)를 가장 중요하게 생각하느냐에 달려 있다는 것입니다.

만약 리스크가 탐지하지 못했을 때 발생하는 경우라면(예: 직원 안전, 출입 통제), 반드시 엣지(edge)에서 실행되어야 합니다. 클라우드와의 연결 여부에 의존해서는 안 됩니다.
만약 리스크가 트렌드 데이터(trend data)를 분석하는 데 있다면(예: 창고 전체의 재고 최적화), 클라우드에서의 배치 추론(batch inference)이 더 합리적입니다. 이는 일반적으로 업그레이드를 배포하기에도 더 쉽습니다.
종종 우리는 이른바 "하이브리드 설정(hybrid setup)" 상황을 마주하게 됩니다. 긴급한 이벤트를 표시하기 위한 작은 엣지 모델과, 더 깊은 분석을 수행하기 위한 더 강력한 클라우드 모델을 함께 사용하는 방식입니다.

데이터 품질의 문제 (The Problem of Data Quality)

산업용 센서에서 발생하는 데이터는 튜토리얼에서 접하는 것과는 다릅니다. 센서는 드리프트 (Drift) 현상이 발생하거나 교정 (Calibration) 범위를 벗어날 수 있고, 장치의 위치가 이동할 수 있으며 이에 대한 정보 전달이 지연될 수 있고, 서로 다른 시스템에서 수신되는 타임스탬프(Timestamp)가 순서가 뒤바뀐 채 도착하기도 합니다. 입력 데이터가 깨끗하고, 정렬되어 있으며, 적절하게 레이블링 (Labeling) 되어 있다고 가정하는 모든 모델은 문제가 발견되기도 훨씬 전에 잘못된 데이터로 인해 오류를 일으킬 것입니다.

실제 환경에서의 해결책 (Real-world solutions):

• 센서를 재교정하거나 위치를 이동한 후 발생하는 데이터의 변화를 문제로 오해하는 것을 방지하기 위해, 장치 메타데이터 (Device metadata)를 센서 측정값과 별도로 버전 관리할 수 있습니다.
• 드리프트 탐지 (Drift detection)는 단순히 모델 내부에만 구축하는 것이 아니라 시스템 자체에 내장되어야 합니다. 즉, 센서의 기준점 (Baseline)이 변하여 모델 성능에 영향을 미치기 전에 이를 식별해야 합니다.
• 메시지가 순서대로 도착하지 않는 것을 예외가 아닌 표준 사례로 가정하고, 시계열 데이터베이스 (TSDB) 쓰기 작업을 적절하게 계획해야 합니다.

이것은 다음과 같은 결과로 이어집니다...

이러한 기술들은 복잡한 것이 아닙니다. 이미 오랫동안 존재해 왔습니다 (MQTT, 시계열 데이터베이스 (Time series DB), 엣지 추론 (Edge inference)). 산업용 AIoT에서 어려운 점은 규율 (Discipline)입니다. 실제 네트워크 환경, 맞지 않는 장비, 그리고 지저분한 데이터 (Dirty data) 앞에서도 무너지지 않는 데이터 파이프라인이 필요합니다. 이는 깨끗한 시뮬레이션이 아니라 현장의 현실에 맞춰 구축되어야 합니다.

과거에 시스템 통합 과정을 경험해 본 팀은 처음부터 시작하는 사람들에 비해 훨씬 유리한 위치에 있습니다. 이것이 바로 우리가 스타트업에서 제로 베이스로 시작하는 것보다 대규모 인프라 제공업체 내에서 점점 더 많은 AIoT 솔루션이 개발되는 것을 목격하게 되는 이유이기도 합니다.

Aperture Venture Studio는 이미 이 전략을 상세히 다룬 바 있습니다.

만약 여러분이 유사한 사업을 시작하면서 여기서 설명한 클라우드/엣지 분할 (Cloud/edge partitioning), 버퍼 (Buffers), 또는 데이터 품질 문제로 어려움을 겪고 있다면, 다른 이들이 이를 어떻게 해결했는지 듣고 싶습니다. 아래 댓글로 여러분의 생각을 남겨주세요!