소프트웨어나 ML(Machine Learning) 분야에서 산업용 AIoT로 전환하는 대부분의 엔지니어들은 동일한 혼란을 경험합니다. 기술적 전이와 기본 원리는 적용되지만, 환경 자체가 표준 엔지니어링 관행에 깊게 뿌리박힌 가설들을 무효화하는 특성을 가지고 있으며, 이는 단순한 가설이라기보다 물리 법칙처럼 느껴질 정도입니다.

이러한 무효화된 가설 중 세 가지가 이 분야에서 가장 흥미로운 엔지니어링 작업을 만들어내는 원인이자, 잘 구축된 시스템이 실제 산업 환경을 처음 마주했을 때 실패하는 대부분의 이유이기도 합니다.

문제 1: 모델의 성능 지표(Performance Metric)가 고객의 성공 지표(Success Metric)가 아니다

대부분의 ML(Machine Learning) 맥락에서 모델 성능 지표와 고객 성공 지표는 밀접하게 상관되어 있습니다. 클릭률(Click-through rate)이 높은 추천 모델은 더 나은 사용자 경험을 제공합니다. 정확도(Accuracy)가 높은 이미지 분류기(Image classifier)는 애플리케이션에서 더 적은 오류를 발생시킵니다. 개발 중에 최적화하는 지표는 고객이 중요하게 생각하는 결과에 대한 합리적인 대리 지표(Proxy)가 됩니다.

산업용 AIoT에서는 이러한 상관관계가 즉각적으로 드러나지는 않지만, 첫 실제 배포 이후 매우 명확해지는 방식으로 깨지게 됩니다.

예측 유지보수(Predictive maintenance) 시스템을 생각해 보십시오. 당신의 평가 지표는 홀드아웃 테스트 세트(Held-out test set)에 대한 정밀도(Precision)와 재현율(Recall)입니다. 고객의 성공 지표는 계획되지 않은 다운타임(Unplanned downtime)의 감소입니다. 이 둘은 연관되어 있지만, 그 관계는 당신의 평가 프레임워크에는 나타나지 않는 요소, 즉 시스템의 알림에 따라 행동하려는 운영 팀의 결정에 의해 매개됩니다.

정밀도 (precision) 85%와 재현율 (recall) 90%를 가진 모델은 15%의 확률로 잘못된 알림을 생성합니다. 소비자용 애플리케이션에서는 15%의 오류율이 종종 허용 가능한 수준입니다. 하지만 매 알림마다 유지보수 팀이 가동 중인 생산 라인을 중단해야 하는 제조 환경에서, 15%의 오탐률 (false positive rate)은 6~7번의 중단 중 한 번이 불필요했음을 의미합니다. 불필요한 중단이 충분히 쌓이면, 운영 팀은 시스템을 언제 신뢰하고 언제 신뢰하지 말아야 할지에 대한 멘탈 모델 (mental model)을 형성하게 됩니다. 이는 합리적인 대응이지만, 귀하의 모니터링 대시보드로는 포착할 수 없는 방식으로 시스템의 출력값과 고객의 의사결정 사이를 분리시켜 버립니다.

js// 귀하의 평가 파이프라인 (evaluation pipeline)이 측정하는 것:
precision = true_positives / (true_positives + false_positives) // 0.85
recall = true_positives / (true_positives + false_negatives) // 0.90

// 귀하의 고객이 실제로 경험하는 것:
alert_follow_through_rate_month_1 = 0.97 // 팀이 거의 모든 것을 조사함
alert_follow_through_rate_month_3 = 0.71 // 팀이 직관에 따라 필터링하기 시작함
alert_follow_through_rate_month_6 = 0.43 // 팀이 자신들만의 멘탈 모델을 구축함
// 귀하의 모델 지표 (model metrics)는 변하지 않았습니다.
// 귀하의 고객이 얻는 운영 가치 (operational value)는 붕괴되었습니다.

엔지니어링 측면의 대응책은 더 나은 모델 정확도가 아닙니다. 운영 컨텍스트 (operational context)를 포함하는 더 풍부한 평가 프레임워크를 구축하는 것입니다. "알림이 정확한가?"가 아니라 "운영 팀이 알고 있는 정보를 바탕으로 할 때, 이 알림이 실행 가능한가 (actionable)?"라고 질문해야 합니다. 이러한 재정의는 어떤 모델 아키텍처 (model architectures)가 가장 가치 있는지, 훈련 중에 어떤 데이터가 필요한지, 그리고 배포 후 모니터링에서 무엇을 추적해야 하는지를 변화시킵니다.

두 번째 문제: 엣지 추론 (Edge inference) 제약 조건은 엔지니어링 선호도가 아니라 물리 법칙에 의해 결정된다

웹 및 모바일 엔지니어들은 성능이나 개인정보 보호를 이유로 엣지 추론 방식을 선택합니다. 지연 시간 (latency)이 허용 가능하다면 클라우드 추론 (cloud inference)으로 전환할 수 있습니다. 만약 장치가 모델을 처리할 수 없다면, 클라우드 엔드포인트 (cloud endpoint)에서 서비스를 제공할 수 있습니다.

산업 현장은 가장 중요한 상황에서 이러한 유연성을 제거합니다.

작업자 안전 시스템은 구역 침범을 감지하고 2초 이내에 경고를 발생시켜야 합니다. 가장 많은 작업자가 이동하고 가장 많은 장비가 가동되는 오전 교대 근무 시간에는 시설의 무선 네트워크가 최고 혼잡 상태에 도달합니다. 클라우드 추론 엔드포인트 (cloud inference endpoint)까지의 RTT (Round-Trip Time)는 정상 조건에서는 800ms이지만, 교대 근무 시간의 부하 상황에서는 2,400ms에 달합니다. 귀하의 2초 요구 사항은 때때로 충족되지만 나머지 시간에는 충족되지 않습니다. 요구 사항을 충족하지 못하는 경우가 바로 안전 사고가 발생할 가능성이 가장 높은 고활동 상황이기 때문에, 시스템의 안전 보장은 정작 가장 필요한 순간에 가장 취약해집니다.

이 요구 사항을 무조건적으로 충족하는 유일한 아키텍처는 핵심 결정 루프 (decision loop)가 네트워크 가용성에 의존하지 않는 장치에서의 엣지 추론 (edge inference)입니다. 이는 귀하의 모델이 수십 달러의 비용이 들고, 밀리와트 (milliwatts) 단위의 전력을 소비하며, 냉동 창고나 주조 공장 바닥과 같은 온도 범위에서 작동하는 하드웨어의 연산 및 메모리 예산 (compute and memory budget) 내에 들어와야 함을 의미합니다.

모델 복잡도 (model complexity), 추론 지연 시간 (inference latency), 전력 예산 (power budget), 그리고 하드웨어 비용 사이의 트레이드오프 (tradeoffs)에는 깔끔한 해결책이 없습니다. 이는 각 배포의 구체적인 운영 맥락에 기반한 엔지니어링적 판단을 필요로 하며, 이러한 판단은 실제 환경에서 이러한 트레이드오프가 어떻게 나타나는지를 반복적으로 경험함으로써 더욱 정교해집니다. Aperture Venture Studio와 같이 공유 플랫폼 기반의 AIoT 벤처 포트폴리오를 보유한 조직들은, 단일 배포 팀이 습득하는 데 훨씬 더 오랜 시간이 걸리는 이러한 트레이드오프에 대한 체계적인 접근 방식을 개발합니다.

세 번째 문제: 가장 필요한 데이터가 가장 얻기 어렵다

산업용 AI는 우연이 아닌 구조적인 클래스 불균형 (Class Imbalance) 문제에 직면해 있습니다. 여러분이 가장 예측하고 싶어 하는 사건들—즉, 잘 관리되는 운영 환경에서의 장비 고장, 안전 사고, 재고 품절 등은 정의상 발생 빈도가 매우 낮습니다.

그 결과, 가장 중요한 모델이 정작 학습 데이터가 가장 적은 모델이 되는 모순이 발생합니다. 특정 유형의 장비를 위한 베어링 고장 모델의 경우, 전체 고객 이력을 통틀어 레이블이 지정된 (Labeled) 고장 시퀀스가 고작 4~5개뿐일 수 있습니다. 안전 사고 탐지 모델은 여러 시설에 배포된 사례를 모두 합쳐도 레이블이 지정된 예시가 10개 미만일 수 있습니다.

SMOTE, 비용 민감 학습 (Cost-sensitive learning), 임계값 조정 (Threshold adjustment)과 같은 표준적인 클래스 불균형 기술들이 도움이 되기는 하지만, 핵심 문제를 해결하지는 못합니다. 핵심 문제는 희귀한 산업 이벤트들이 복잡하고 고차원적인 전조 징후 (Precursor signatures)를 가지고 있어, 소수의 예시만으로는 학습하기가 매우 어렵다는 점입니다. 가장 효과적인 접근 방식은 도메인 지식(이전에 고장을 경험했던 엔지니어와 운영자로부터 얻는 지식)을 관련 장비 유형으로부터의 전이 학습 (Transfer learning) 및 레이블이 지정된 고장 예시가 전혀 필요 없는 이상 탐지 (Anomaly detection) 프레임워크와 결합하는 것입니다.

이를 제대로 수행하려면 산업 운영 팀과 매우 긴밀하게 협력하여 그들의 제도적 지식 (Institutional knowledge)이 모델 개발 프로세스에 인코딩될 수 있도록 해야 합니다. 이는 대부분의 ML 팀이 익숙한 방식과는 다른 종류의 협업이며, 경험이 쌓일수록 그 가치가 크게 커지는 기술입니다.

실무에서 마주친 이 세 가지 문제 중 가장 어려웠던 버전은 무엇이었나요? 이 커뮤니티에서는 어떤 접근 방식이 효과적이었는지 궁금합니다.

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