소프트웨어 엔지니어들이 구축한 대부분의 IoT 시스템은 본질적으로 정교한 로깅(Logging) 시스템입니다. 센서가 측정값을 방출합니다. 측정값은 데이터베이스로 들어갑니다. 대시보드가 데이터베이스를 쿼리(Query)합니다. 사람이 대시보드를 보고 무엇을 할지 결정합니다.

이러한 아키텍처(Architecture)가 반드시 틀린 것은 아닙니다. 다만 산업 고객들이 실제로 필요로 하는 것이 아닐 뿐입니다. 그들에게 필요한 것은 스스로 무엇을 할지 결정하거나, 적어도 사람이 개입하기 전에 결정 범위를 극적으로 좁혀주는 시스템입니다. 로깅 시스템과 추론(Inference) 시스템의 차이는 데이터를 생성하는 도구와 가치를 생성하는 도구의 차이입니다.

로깅으로서의 IoT에서 추론으로서의 AIoT로 전환하는 것은 거의 모든 계층에서 아키텍처를 재고할 것을 요구하며, 이 과정에 수반되는 도전 과제들은 공학적 관점에서 진정으로 흥미롭습니다.

추론 문제는 당신이 생각하는 곳에 있지 않습니다

IoT 시스템에서 추론을 배치할 가장 명백한 장소는 데이터가 수집되고 집계된 후인 클라우드(Cloud) 계층입니다. 클라우드에서 모델을 학습시키고, 클라우드에서 실행하며, API를 통해 출력을 제공합니다. 이것이 대부분의 ML(머신러닝) 시스템이 작동하는 방식이며, 이를 위한 툴링(Tooling)도 성숙해 있습니다.

문제는 이 아키텍처가 실제 산업 환경에서는 성립하지 않는 두 가지 사항, 즉 신뢰할 수 있는 연결성(Connectivity)과 허용 가능한 지연 시간(Latency)을 가정한다는 점입니다.

창고나 제조 시설에서 네트워크 연결성은 의존할 수 있는 유틸리티가 아닙니다. 액세스 포인트(Access points)는 장비에 의해 차단됩니다. 네트워크 인프라(Infrastructure)는 종종 오래되었고 유지보수가 제대로 되지 않습니다. 중장비는 전자기 간섭(Electromagnetic interference)을 발생시킵니다. 실제 산업 환경에서의 연결성은 안정적인 API 연결이라기보다는 산악 지역의 모바일 신호와 비슷합니다. 대개는 사용 가능하지만 가끔은 안 되며, 정확히 언제 안 될지는 알 수 없습니다.

지연 시간 (Latency) 또한 중요합니다. 만약 작업자가 제한 구역에 진입했음을 감지하고 경고를 생성해야 하는 안전 경고 시스템이라면, 클라우드(Cloud)를 왕복하는 시간은 허용될 수 없습니다. 감지와 경고는 엣지 (Edge)에서 밀리초 (ms) 단위로 이루어져야 하며, 그렇지 않으면 시스템은 제 역할을 수행할 수 없습니다.

python
// 클라우드 우선 (Cloud-first) 가정:
sensor_reading = get_sensor_data()
result = cloud_api.infer(sensor_reading) // 200-800ms, 연결 필요
alert_if_needed(result)

// 엣지에서 실제로 필요한 것:
sensor_reading = get_sensor_data()
result = edge_model.infer(sensor_reading) // 2-15ms, 연결 불필요
alert_if_needed(result)
// 연결 가능할 때 클라우드로 동기화, 충돌 해결 (Conflict resolution)을 신중하게 처리

이는 어려운 엔지니어링 문제를 이미 잘 알려진 모델 학습 (Model training)에서, 고유한 제약 조건과 실패 모드 (Failure modes)를 가진 별도의 분야인 모델 배포 (Model deployment) 및 엣지 추론 (Edge inference)으로 전환시킵니다.

데이터 품질 문제는 추론 문제를 악화시킵니다

산업용 센서 데이터에 대한 엣지 추론은 데이터가 깨끗하다면 다룰 만한 수준일 것입니다. 하지만 그렇지 않습니다.

산업용 센서는 시간이 지남에 따라 드리프트 (Drift) 현상이 발생합니다. 설치 당시 정확하게 교정(Calibrated)되었던 온도 센서라도, 뜨거운 환경에서 6개월 동안 작동한 후에는 체계적으로 높은 수치를 읽을 수 있습니다. 이동이 빈번한 장비에 장착된 진동 센서는 모델이 학습되었을 때와 다른 방향으로 설치될 수 있으며, 이로 인해 이상치 (Anomalies)처럼 보이지만 실제로는 단순히 장착 각도로 인한 아티팩트 (Artifacts)인 수치를 생성할 수 있습니다.

센서 판독값(Sensor readings) 또한 무작위가 아닌 특정 패턴을 가지고 누락됩니다. 연결 실패(Connectivity failures)는 특정 운영 조건에서 발생하는 경향이 있습니다. 예를 들어, 장비가 높은 부하(High load)로 작동하여 더 많은 전자기 간섭(Electromagnetic interference)을 생성할 때나, 시설의 점유율이 최고조에 달해 무선 네트워크가 더 혼잡할 때 발생합니다. 이는 데이터의 공백(Gaps)이 당신이 데이터에 대해 가장 필요로 하는 운영 상태와 상관관계가 있음을 의미합니다. 단순한 공백 채우기(Gap-filling) 전략은 이상치(Anomalies)가 발생할 가능성이 가장 높은 조건들을 체계적으로 과소 대표하게 될 것입니다.

이러한 현실을 처리하는 추론(Inference) 시스템을 구축하려면 다음 사항들이 필요합니다:

• 센서별 교정 드리프트(Calibration drift) 감지 및 자동 베이스라인(Baseline) 조정
• "이벤트 없음"과 "데이터 없음"을 구분하는 공백 인지 모델(Gap-aware models)
• 특정 유형의 모든 센서에 단일 임계값(Threshold)을 적용하는 대신, 센서별 노이즈 프로필(Noise profiles)을 고려하는 이상치 탐지(Anomaly detection)
• 모델 출력값에 대한 불확실성(Uncertainty)의 명시적 표현 (손상된 데이터로 만들어진 예측은 깨끗한 데이터로 만들어진 예측보다 더 적은 가중치를 가져야 하기 때문)

이 중 불가능한 것은 없습니다. 다만 이 모든 것에는 표준 머신러닝 (ML) 튜토리얼에는 등장하지 않는 엔지니어링 결정이 필요합니다. 표준 ML 튜토리얼은 데이터가 이미 깨끗하다고 가정하기 때문입니다.

배포 라이프사이클(Deployment lifecycle)은 당신이 익숙한 것과는 다릅니다

웹 및 모바일 배포는 빌드, 테스트, 배포, 모니터링, 반복(Iterate)이라는 익숙한 리듬을 따릅니다. 반복 주기는 며칠에서 몇 주 단위이며, 롤백(Rollback)은 명령어 하나로 가능합니다.

산업 환경에서의 AIoT 배포는 거의 모든 측면에서 다르게 작동합니다.

에지 디바이스(Edge device)에 대한 펌웨어 업데이트(Firmware updates)는 원자적(Atomic)이어야 하며 롤백(Rollback)이 안전하게 보장되어야 합니다. 무인 장비실에 있는 원격 장치의 업데이트가 실패하는 것은 즉각적인 해결책이 없는 심각한 운영상의 문제이기 때문입니다. 모델 업데이트(Model updates)는 단순히 모델의 일반적인 벤치마크 성능이 아니라, 해당 센서의 설치 환경을 반영하는 과거 데이터, 즉 이 환경에서, 이 센서에서, 그리고 센서의 교정(Calibration) 수명 주기 상의 이 시점에서 발생한 데이터에 대한 성능을 바탕으로 검증되어야 합니다.

고객의 수용 기준(Acceptance criteria) 또한 다릅니다. AIoT 시스템을 평가하는 산업 고객은 짧은 기간 동안의 집계된 지표(Aggregate metrics)를 보지 않습니다. 그들은 특정 사건을 살펴봅니다. 시스템이 3월에 발생한 베어링 고장을 감지했는가? 2월에 장비가 정상임에도 점검을 위해 유지보수 인력을 보낸 오경보(False alarm)를 놓치지는 않았는가? 이러한 평가는 소비자 제품의 지표와는 달리 사례별(Case-by-case)로 이루어집니다.

여러 산업 수직 계열(Verticals)에 걸쳐 AIoT 제품을 구축하고 있는 Aperture Venture Studio와 같은 기업들은, 실제 환경에서 반복적으로 작업을 수행하는 것 외에는 습득하기 매우 어려운 이러한 배포 현실에 기반한 운영 역량(Operational muscle)을 개발합니다. 이러한 어렵게 얻은 지식은 복리로 쌓이는 경향이 있습니다.

이것이 엔지니어링 측면에서 주목할 가치가 있는 이유

AIoT의 엔지니어링 문제들—제약 조건 하에서의 에지 추론(Edge inference), 센서 드리프트(Sensor drift) 및 연결성 공백이 존재하는 상황에서의 데이터 품질, 물리적으로 접근 불가능한 환경에서의 배포 수명 주기(Deployment lifecycles), 그리고 안전이 중요한 경보 시스템에서의 교정된 불확실성(Calibrated uncertainty)—은 진정으로 어려우며 아직 표준화된 방식으로 해결되지 않았습니다.

이러한 솔루션이 필요한 시장은 거대하고, 고객들은 실제 예산을 보유하고 있으며, 실제 운영 환경(Production)에서 이러한 문제들과 직접 씨름해 본 엔지니어의 공급은 매우 적습니다.

만약 당신이 가치 있고 희소한 깊은 전문성을 어디에서 쌓아야 할지 고민하고 있다면, 물리적 세계(Physical world)는 살펴볼 만한 합리적인 장소입니다.

산업 환경이 시스템이 작동해야 하는 방식에 대한 여러분의 가정을 깨뜨린 가장 놀라운 사례는 무엇인가요? 댓글로 남겨주세요.

iot #ai #machinelearning #embedded #edgecomputing #architecture #discuss #programming #industry40 #softwareengineering #deeptech #career #artificialintelligence