산업 환경에서 AIoT 시스템의 첫 배포는 대개 쉬운 부분입니다. 하드웨어는 갓 교정(calibrated)된 상태입니다. 센서 측정값은 시스템이 학습한 내용과 일치합니다. 운영 팀은 적극적으로 참여하여 모든 경고(alert)를 조사합니다. 플랫폼 지표(metrics)도 양호해 보입니다.

6개월째는 모습이 다릅니다. 그 시점이 되면 배포 전 엔지니어링 단계에서 충분히 고려하지 못한 여러 가지 일들이 발생합니다. 이러한 변화를 잘 처리하는 시스템은 18개월, 2년, 3년이 지나도 여전히 안정적으로 작동합니다. 반면, 이를 잘 처리하지 못하는 시스템은 운영 팀이 출력값(outputs)을 더 이상 신뢰하지 않게 되면서 조용히 전원이 꺼지게 됩니다.

다음은 산업용 AIoT 시스템의 시운전(commissioning)과 장기 운영 사이에 발생하는 구체적인 엔지니어링 문제들과, 이를 처음부터 어떻게 설계해야 하는지에 대한 상세한 설명입니다.

센서 노화는 모델 하단의 데이터 분포를 변화시킨다

산업용 이상 탐지(anomaly detection) 또는 예지 보전(predictive maintenance)을 위한 모델을 학습시킬 때, 여러분은 교정 수명 주기(calibration lifecycle)의 특정 시점에 있는 센서의 데이터로 학습을 진행합니다. 그 데이터는 특정 분포(distribution)—즉, 정상 값의 범위, 특징적인 노이즈 패턴, 그리고 다양한 운영 조건 하에서의 측정값 간의 특정 상관관계(correlations)—를 가지고 있습니다.

6개월에서 12개월이 지나면, 모델이 실행되는 데이터를 생성하는 센서는 시운전 당시의 센서와 동일하지 않습니다. 하드웨어를 교체했다는 의미가 아니라, 물리적 센서가 노화된다는 의미입니다. 온도 센서는 기준 소자(reference elements)가 퇴화함에 따라 드리프트(drift) 현상이 발생합니다. 진동 센서는 장착 부위의 마모가 발생하여 측정 대상 구조물과의 결합(coupling) 상태가 변합니다. 압력 센서는 다이아프램(diaphragm) 피로가 누적됩니다. 정상 측정값의 분포는 개별 측정값으로는 보이지 않지만, 몇 달에 걸쳐 누적되면서 미묘하고 지속적으로 변화합니다.

실질적인 결과는 시운전(commissioning) 시점에 교정(calibration)된 모델이, "정상" 분포가 모델이 정상으로 학습했던 상태로부터 점차 벗어남에 따라 점진적으로 더 많은 오탐(false positives)을 생성하게 된다는 것입니다. 운영 팀은 이를 "모델의 교정이 잘못되었다"라고 인식하는 것이 아니라, "시스템이 문제가 없는 상황에 대해 계속해서 경고를 보낸다"라고 인식합니다. 그들의 대응은 합리적입니다. 즉, 경고를 덜 신뢰하게 되는 것입니다. 시간이 흐르면서 그들은 경고에 따른 조치를 중단하게 됩니다.

이를 위해 설계할 때는 교정을 시운전 시점의 작업이 아닌, 지속적인 운영 프로세스로 취급해야 합니다:

// 단순한 접근 방식: 배포 시 설정된 정적 이상치 임계값 (static anomaly threshold)
const isAnomaly = (reading) => reading > BASELINE_THRESHOLD;

...

롤링 베이스라인(rolling baseline) 접근 방식은 더 복잡하며, 실제 이상치를 정상 분포로 오인하여 쫓아가는 현상을 방지하기 위해 더 세심한 설계가 필요합니다. 하지만 이는 배포의 운영 수명 주기 동안 모델의 유효성(relevance)을 유지할 수 있는 접근 방식입니다.

경고 피로(Alert fatigue)는 되돌리기 어려운 복합적인 역학을 가집니다

산업 환경에서 경고의 정밀도(precision)와 운영자의 행동 사이의 관계는 선형적이지 않습니다. 이는 무시하기에 특히 위험한 임계값 특성(threshold characteristic)을 가지고 있습니다.

특정 오탐률(false positive rate) 미만에서는 운영자들이 대부분의 경고를 조사합니다. 하지만 그 임계값을 넘어서면 운영자들은 조사를 중단합니다. 한꺼번에 중단하는 것이 아니라, 각 오탐이 발생할 때마다 다음 오탐을 위해 워크플로우를 중단하려는 의지를 조금씩 감소시키면서 점진적으로 중단하게 됩니다. 일단 이 임계값을 넘어서면, 시스템은 실제 경고를 놓치는 단계로 진입합니다. 이는 모델이 경고를 생성하지 못해서가 아니라, 운영 팀이 시스템의 출력값에 따른 조치를 중단했기 때문입니다.

이 문제가 복합적인 이유는 이러한 행동 변화가 표준 플랫폼 지표(platform metrics)에서는 보이지 않기 때문입니다. 경고 생성률은 정상적으로 보이고, 센서 상태도 정상으로 보입니다. 유일하게 변하는 것은 후속 조치율(follow-through rate) — 즉, 경고가 실제로 얼마나 자주 운영 조치로 이어지는가 — 이지만, 대부분의 AIoT 모니터링 파이프라인은 이를 추적하지 않습니다.

여러 산업 현장에 걸쳐 대규모로 AIoT 플랫폼을 구축하는 조직들 — 예를 들어, 공유 생산 플랫폼 위에서 산업용 AI 벤처 포트폴리오를 개발하는 Aperture Venture Studio와 같은 곳들 — 은 모니터링 아키텍처(monitoring architecture) 내에 명시적인 후속 조치 추적(follow-through tracking) 기능을 구축합니다. 이들은 이러한 역학 관계가 여러 배포 환경에서 어떻게 나타나는지 지켜봐 왔으며, 경고 정밀도(alert precision)가 시스템의 정적인 속성이 아니라 능동적인 유지보수가 필요한 속성임을 이해하고 있기 때문입니다.

산업 환경에서의 하드웨어 고장 모드(failure modes)는 데이터 시트와 다르다

산업용 장비의 데이터 시트(data sheet)는 설계 환경에서의 성능을 나타내는 작동 온도 범위, 진동 허용 오차, IP 등급, 그리고 MTBF(평균 고장 간격) 수치를 명시합니다. 하지만 이는 특정 시설에 존재하는 환경적 스트레스 요인(environmental stressors)의 특정한 조합으로 인해 발생하는 고장 모드(failure modes)를 나타내지는 않습니다.

60°C까지 작동하도록 정격 설계된 BLE 비콘(BLE beacon)이 산업용 오븐 근처에 설치될 경우, 주변 온도와 최대 작동 온도에 가까운 온도 사이를 반복적으로 오가는 열 사이클링(thermal cycling)을 경험할 수 있습니다. 이는 커패시터(capacitor)의 노화를 가속화하여 MTBF를 정격 값보다 현저히 낮게 감소시킬 수 있습니다. IP65 등급을 받은 에지 게이트웨이(edge gateway)가 빈번한 고압 세척이 이루어지는 구역에 설치되면, 점진적인 씰(seal) 퇴화가 발생하여 몇 달 후 수분 침투(moisture ingress)로 이어질 수 있습니다. 규격 내 진동을 견디도록 설계된 RFID 안테나는, 장착 지점에 응력을 집중시키는 공진 주파수(resonance frequencies)를 가진 장비에 설치될 경우 예상보다 일찍 고장 날 수 있습니다.

이러한 고장 모드 중 그 어느 것도 데이터 시트에는 나타나지 않습니다. 하지만 이 모든 것들은 장기적인 산업 현장 배포 환경에서 나타납니다. 이를 고려하여 설계하려면 하드웨어 고장을 확률론적 공학 문제(probabilistic engineering problem)로 취급해야 합니다. 즉, 정격 MTBF를 사용하는 대신 각 설치 환경의 특정 스트레스 요인 하에서의 실제 MTBF를 추정하고, 사후 대응적(reactive)이기보다는 선제적(proactive)인 유지보수 및 교체 일정을 구축해야 합니다.

이러한 추정치를 도출하는 데 가장 가치 있는 입력값은 유사한 환경의 여러 설치 사례에서 축적된 배포 이력입니다. 이것이 바로 AIoT에서의 운영 지식(operational knowledge)이 교과서적 지식과는 다른 방식으로 배포 경험과 결합하여 복리로 쌓이는 이유 중 하나입니다.

이 모든 것이 시사하는 점

장기적인 AIoT 배포 신뢰성은 기본적으로 초기 엔지니어링 품질의 문제가 아닙니다. 이는 운영 드리프트(operational drift), 즉 배포 수명 주기 동안 하드웨어, 소프트웨어, 그리고 이를 둘러싼 인간적 맥락이 변화하는 방식에 대비하여 설계하는 문제입니다.

이러한 관점을 갖춘 엔지니어들은 첫 번째 배포에서도 더 나은 시스템을 구축합니다. 왜냐하면 이들은 시운전 상태(commissioning state)가 영구적일 것이라는 암묵적인 가정 대신, 시스템이 어떻게 진화할 것인지에 대한 명시적인 모델을 가지고 설계하기 때문입니다.

AIoT 또는 산업용 배포에서 가장 놀라웠던 장기 운영 문제는 무엇이었나요? 그에 대응하여 무엇을 구축하셨나요? 댓글로 의견을 나누어 주세요.

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