ML (머신러닝) 시스템을 구축해 본 대부분의 엔지니어들은 너무나 표준적이어서 거의 가정이라고 인식조차 못 할 정도의 일련의 가정 하에 작업을 수행해 왔습니다. 학습 데이터 (Training data)는 풍부하고 비교적 깨끗합니다. 추론 (Inference)은 신뢰할 수 있는 연결성과 본질적으로 무제한에 가까운 컴퓨팅 자원을 갖춘 클라우드 환경에서 발생합니다. 잘못된 예측의 실패 모드 (Failure mode)는 최적화되지 않은 사용자 경험일 뿐입니다. 그리고 무언가 고장 나면, 수정 사항을 푸시(push)하고, 그것은 시스템의 모든 인스턴스에 즉각적으로 전파됩니다.

산업용 Edge AI는 이러한 조건 중 거의 어느 것도 충족하지 않는 환경에서 작동합니다. 데이터는 가장 중요한 곳에서 부족하며, 예측하기 어려운 방식으로 노이즈 (Noisy)가 섞여 있고, 당신이 예측하고자 하는 운영 상태와 구조적으로 상관관계가 있습니다. 추론은 실제 전력 및 컴퓨팅 제약이 있는 하드웨어에서 수행되어야 하며, 종종 네트워크 연결이 전혀 없는 상태에서 이루어지기도 합니다. 잘못된 예측은 운영적, 재무적, 또는 — 안전이 중요한 애플리케이션의 경우 — 물리적인 결과를 초래할 수 있습니다. 그리고 세 개의 시간대가 떨어진 시설의 무인 장비실에 있는 장치에서 무언가 고장 난다면, "수정 사항을 푸시한다"는 말은 결코 간단한 문장이 아닙니다.

그 결과, 겉보기에는 ML처럼 보이지만 내부적으로는 완전히 다르게 느껴지는 분야가 탄생했습니다. 무엇이 변하는지 아래에서 살펴보겠습니다.

가장 중요한 곳에서의 데이터 희소성

산업 데이터의 역설은 데이터가 너무 많으면서도, 정작 필요한 종류의 데이터는 부족하다는 점입니다.

현대적인 산업 환경은 온도, 진동, 압력, 유량, 음향 신호 (Acoustic signatures), 전력 소모, 그리고 움직임과 같은 엄청난 양의 센서 판독값을 생성합니다. 문제는 데이터의 양이 아닙니다. 문제는 당신이 가장 예측하고 싶어 하는 이벤트들이 설계상 희귀하다는 점입니다. 잘 관리되는 시설에서 장비 고장은 발생 빈도가 낮습니다. 다행히도 대부분의 환경에서 안전 사고는 흔치 않습니다. 잘 운영되는 물류 센터에서의 재고 품절은 발생 빈도가 매우 낮아서, 단일 시설에서 1년 동안 라벨링된 (Labeled) 예시를 몇 개밖에 얻지 못할 수도 있습니다.

이는 다음과 같은 특정한 모델 개발 과제들을 만들어냅니다:

// 예측 유지보수 (Predictive Maintenance)에서의 클래스 불균형 (Class Imbalance) 문제
// 베어링은 18개월에 한 번 고장 날 수 있음
// 센서는 30초마다 데이터를 보고할 수 있음
...

클래스 불균형 (Class Imbalance)을 해결하기 위한 표준 기술들—오버샘플링 (Oversampling), 언더샘플링 (Undersampling), 그리고 비용 민감 학습 (Cost-sensitive learning)—이 도움이 되기는 하지만 문제를 완전히 해결하지는 못합니다. 산업 현장의 고장 데이터 구조는 단순한 클래스 불균형보다 더 복잡하기 때문입니다. 고장 전 신호 (Pre-failure signals)는 종종 미묘하고, 비정상성 (Non-stationary)을 띠며, 개별 장비의 특정 운전 이력에 매우 의존적입니다. 한 기계에 맞춰 보정된 동일한 모델이라도, 서로 다른 부하 프로필 (Load profiles) 하에서 작동해 온 겉보기에 동일한 다른 기계에서는 성능이 저하될 수 있습니다.

이것이 바로 전이 학습 (Transfer learning)과 퓨샷 적응 (Few-shot adaptation) 접근 방식이 산업용 머신러닝 (ML)에서 특히 유의미한 이유이며, 실제 배포를 통해 축적된 운영 데이터가 이 분야에서 가장 가치 있는 자산 중 하나인 이유입니다.

1급 엔지니어링 제약 조건으로서의 엣지 추론 (Edge inference)

웹 및 모바일 머신러닝 (ML)에서 "엣지 (Edge)"는 보통 지연 시간 (Latency)이나 개인정보 보호를 이유로 선택된 사용자의 기기를 의미합니다. 기기가 연산 (Compute)을 처리할 수 없는 경우, 클라우드 추론 (Cloud inference)으로 전환하는 것이 가능한 경우가 많습니다.

반면 산업용 IoT (IIoT)에서 엣지 추론 (Edge inference)은 선택 사항이 아닌 경우가 많습니다. 이는 물리적 환경에 의해 강제되는 아키텍처 요구 사항입니다.

작업자가 제한 구역에 들어갔는지 감지해야 하는 작업자 안전 시스템을 예로 들어보겠습니다. 감지는 2초 이내에 경고를 발생시켜야 합니다. 만약 교대 근무 피크 시간대에 시설의 네트워크가 혼잡하다면—피크 시간대는 가장 무거운 장비들이 가동되어 가장 많은 RF 간섭 (RF interference)을 생성하는 시간대이므로 혼잡할 수밖에 없습니다—정보를 클라우드로 라우팅하는 과정에서 발생하는 지연 시간이 추가되어 2초 이내라는 요구 사항을 충족할 수 없게 될 수도 있습니다.

또 다른 예로, 원격 시설의 회전 장비(rotating equipment)에 적용된 예지 보전 (predictive maintenance) 시스템을 생각해 보십시오. 해당 시설은 기상 조건이 좋지 않을 때 한 번에 30분에서 60분 동안 연결이 끊기는 위성 인터넷 연결 환경일 수 있습니다. 시스템은 연결이 끊긴 동안에도 모니터링과 경고를 계속 수행해야 합니다. 그렇지 않으면 고장을 유발하는 환경 조건이 나타날 가능성이 가장 높은 시기에 아무런 보호를 제공하지 못하게 됩니다.

이러한 요구 사항에 대한 엔지니어링적 대응은 계층형 추론 아키텍처 (tiered inference architecture)입니다. 즉, 에지 (edge)에서의 실시간 탐지를 위한 경량화된 양자화 모델 (quantized models), 로컬 게이트웨이 또는 온프레미스 (on-premises) 서버에서의 패턴 분석 및 장기 예측을 위한 더 복잡한 모델, 그리고 연결이 가능할 때 동기화되는 클라우드 기반 학습 및 모델 관리 단계로 구성됩니다.

Aperture Venture Studio와 같은 스튜디오 — 공유 산업용 AI 플랫폼을 기반으로 AIoT 벤처 포트폴리오를 구축 중인 곳 — 는 다양한 산업 환경과 연결 프로필에 걸친 반복적인 배포 경험을 통해 이러한 계층형 아키텍처에 대한 체계적인 접근 방식을 개발합니다.

즉각적인 수정 사항을 배포할 수 없을 때의 모델 수명 주기 관리 (Model lifecycle management)

산업용 IoT에서의 OTA (Over-the-Air) 업데이트는 웹 개발의 CI/CD 파이프라인과는 다릅니다. 이는 오히려 수술 절차에 더 가깝습니다. 즉, 신중하게 계획되어야 하고, 실행 전 광범위하게 테스트되어야 하며, 명시적인 롤백 (rollback) 기능이 설계되어야 합니다. 왜냐냐하면 원격 장치에서 업데이트가 실패했을 때의 비용은 로그 파일의 500 에러가 아니라, 해당 장치의 출력이 실제 운영 결정에 영향을 미칠 수 있는 환경에서 손상된 모델로 작동하는 장치 그 자체이기 때문입니다.

산업용 Edge AI에서 양호한 모델 생명주기 관리 (model lifecycle management)를 위해서는 최소한 세 가지가 필요합니다. 첫째, 배포 전 현장 특화 검증 (site-specific validation)입니다. 여기에는 섀도 모드 (shadow mode)—전환 (cutover) 전 기존 모델과 함께 새 모델을 실행하여, 업데이트된 모델이 현지의 센서 분포 (sensor distribution)에 대해 올게 작동하는지 확인하는 방식—가 포함됩니다. 둘째, 원자적 업데이트 전달 (atomic update delivery)입니다. 업데이트는 완전히 완료되거나, 부분적인 상태 (partial state) 없이 장치가 깔끔하게 이전 상태로 복구 (revert)되어야 합니다. 셋째, 배포 후 모니터링 (post-deployment monitoring)입니다. 이는 경고 발생률 (alert rate)의 변화를 감지하고, 시스템에 대한 운영 신뢰도 (operational trust)가 영향을 받기 전에 인간의 검토 (human review) 단계로 에스컬레이션 (escalate)해야 합니다.

이러한 요구 사항들로 인해 산업용 Edge AI 모델 생명주기 관리는 표준적인 MLOps와는 구별되는 별도의 분야가 되며, 자신이 구축한 시스템이 처한 운영 맥락 (operational context)을 내재화한 엔지니어에게 보상이 돌아갑니다.

Edge 또는 산업 환경에서 겪었던 가장 어려운 모델 생명주기 문제는 무엇이었나요? 댓글로 남겨주세요.

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