산업용 AIoT(Artificial Intelligence of Things)에는 특정한 종류의 제품 실패 사례가 존재하며, 이는 대부분의 엔지니어들이 시스템을 설계할 때 생각하는 것과는 다릅니다.

그것은 시스템 충돌(Crash)이 아닙니다. 데이터 손실(Data loss)도 아닙니다. 적어도 직접적인 의미에서의 잘못된 예측(Incorrect predictions)도 아닙니다. 그것은 운영 팀이 시스템의 출력값을 더 이상 행동의 근거로 삼을 만큼 신뢰하지 않기로 결정하고, 조용히 시스템을 우회하여 업무를 수행하기 시작하는 바로 그 순간입니다.

이러한 실패 모드(Failure mode)는 표준 제품 지표(Product metrics)에서는 보이지 않습니다. 시스템은 여전히 작동 중입니다. 센서(Sensors)는 여전히 보고하고 있습니다. 모델(Model)은 여전히 예측을 생성하고 있습니다. 하지만 그 예측을 사용해야 했던 사람들은 자신의 의사결정을 시스템의 출력값으로부터 분리해 버렸으며, 당신이 이를 구체적으로 모니터링하고 있지 않는 한 어떤 대시보드(Dashboard)도 그런 일이 일어났음을 알려주지 않을 것입니다.

이런 일이 왜 발생하는지, 그리고 어떻게 이를 방지할 수 있는지를 이해하는 것은 Aperture Venture Studio가 가진 진정한 전문성 중 하나입니다. Aperture가 2021년 벤처 스튜디오(Venture studio)로 공식 설립되기 전, GAO Group of Companies 전반에 걸쳐 수년간 실제 산업용 IoT(Industrial IoT)를 배포하며 쌓아온 경험을 통해 이를 발전시켜 왔습니다.

운영자의 신뢰가 파괴되는 방식 (그리고 왜 다시 구축하기가 그토록 어려운가)

산업 현장의 운영자들은 새로운 시스템과 관계를 맺는 방식이 새로운 동료와 관계를 맺는 방식과 같습니다. 즉, 신뢰를 쌓거나 혹은 깎아먹는 일련의 상호작용을 통해 점진적으로 관계가 형성됩니다.

산업 운영자의 신뢰를 가장 빠르게 깎아먹는 방법은 오탐(False positive) 알림입니다. 즉, 조치를 유발하고 혼란을 일으켰으나 결과적으로 아무것도 아니었던 알림입니다. 이는 오탐 자체가 재앙적이기 때문이 아니라, 오탐이 시스템의 환경 이해도에 대해 무엇을 시사하는지 때문입니다.

식품 가공 시설의 운영 관리자는 단순히 "오탐(false alarm)"이라고 기록하지 않습니다. 그들은 다음과 같이 기록합니다: "이 시스템은 겨울철에 동쪽 하역 문이 열릴 때 열적 대비(thermal contrast)로 인해 7번 센서의 온도 수치가 항상 급증한다는 사실을 모른다. 그리고 앞으로도 영원히 모를 것이다. 왜냐하면 이 시스템을 만든 사람 중 누구도 이 시설에서 교대 근무를 해본 적이 없기 때문이다." 이러한 추론, 즉 시스템 설계자들이 운영 맥락(operational context)을 파악하지 못하고 있다는 사실이 신뢰를 무너뜨립니다. 그리고 한 번 무너진 신뢰를 다시 구축하는 것은 매우 어렵습니다.

공학적 관점에서의 시사점은 알림 보정(alert calibration)이 배포 시점에 끝나는 작업이 아니라는 것입니다. 이는 모니터링 대상 환경을 운영하는 사람들과의 긴밀한 협업이 필요한 지속적인 운영 규율(operational discipline)입니다. 모델은 단순히 과거 데이터뿐만 아니라 운영 팀의 제도적 지식(institutional knowledge)에 맞춰 튜닝되어야 합니다. 이러한 지식은 문서화되는 경우가 드뭅니다. 당신은 그 지식에 접근할 권한을 얻기 위해 노력해야 합니다.

아무도 말하지 않는 통합 계층 (The integration layer nobody talks about)

기업용 산업 현장 배포에서는 다른 형태의 실패 모드가 나타납니다. 바로 기술 벤더가 예상하는 것보다 훨씬 오래되었고, 문서화가 훨씬 덜 되어 있으며, 운영 워크플로에 훨씬 더 깊숙이 박혀 있는 레거시 시스템(legacy systems)과의 통합 문제입니다.

대부분의 산업 시설은 수년 또는 수십 년 동안 ERP, MES, WMS, SCADA 시스템의 조합을 운영해 왔습니다. 이러한 시스템은 사라지지 않습니다. 이들과 통합하는 대신 이들을 대체하려는 모든 AIoT 제품은 배포 단계에 도달하지 못하고 실패할 것입니다. 핵심 운영 시스템을 교체하는 데 드는 전환 비용(switching cost)과 운영 리스크는 산업 고객이 새로운 벤더로부터 수용할 수 없는 영역이기 때문입니다.

실질적인 시사점은 귀하의 데이터 계층(data layer)이 REST API가 존재하기 전에 구축된 시스템들의 프로토콜을 이해하고 통신할 수 있어야 한다는 것입니다. 귀하의 출력값은 재학습(retraining)을 요구하지 않고도 기존의 운영 워크플로(operational workflow)에 즉시 적용될 수 있는 형식으로 표현될 수 있어야 합니다. 귀하의 알림 시스템은 운영 팀이 이미 확인하고 있는 곳에 알림을 전달해야 합니다. 그곳은 현대적인 웹 대시보드가 아니라, 15년 된 SCADA 콘솔일 수도 있습니다.

python
// 통합 계층(integration layer)이 갖추기를 원하는 모습:
aiot_system.alert_channel = modern_webhook_endpoint

// 실제로 지원해야 하는 모습:
aiot_system.alert_channels = [
OpcUaNode("ns=2;s=PlantAlerts.Zone3"), // SCADA 시스템, 대략 2009년경
ModbusTcpRegister(host="192.168.1.45", register=4012), // PLC, 직접 연결
EmailSMTP(to="ops-floor@plant.internal"), // 네, 정말로요
modern_webhook_endpoint // 아마도, 언젠가는
]

이를 제대로 수행하려면 시스템 통합 가이드에서 읽은 내용이 아니라, 실제 시설에서 직접 해본 경험이 필요합니다.

AIoT 제품이 어떻게 구축되어야 하는지에 대한 의미

실제 산업 현장 배포에서 얻은 교훈들은 일반적인 소프트웨어 제품 개발 관점에서는 직관에 반하는 일련의 원칙들로 수렴됩니다:

데이터가 아닌 운영자 워크플로(operator workflow)부터 시작하십시오. 채택되는 시스템은 운영 팀이 시스템에 맞추기 위해 워크플로를 변경해야 하는 시스템이 아니라, 운영 팀이 이미 일하는 방식에 부합하는 시스템입니다.

신뢰(trust)를 일급 제품 지표(first-class product metric)로 취급하십시오. 모델의 정확도(accuracy)뿐만 아니라, 운영자가 시스템의 권장 사항을 무시(override)하는 비율을 추적하고, 모든 무시 사례를 조사하십시오. 높은 무시 비율은 정확도 지표가 무엇을 말하든 간에, 시스템의 출력값이 운영 컨텍스트(operational context)에 맞게 조정되지 않았다는 신호입니다.

최고의 성능 (peak performance)을 목표로 구축하기 전에, 우아한 성능 저하 (graceful degradation)를 고려하여 구축하십시오. 산업 환경에서는 연결성 문제나 센서 장애가 발생했을 때 80%의 품질로 작동하는 시스템이, 이상적인 조건에서는 100% 성능을 내지만 조건이 이상적이지 않을 때 완전히 실패하는 시스템보다 훨씬 더 가치 있습니다.

이러한 것들이 실제 산업 환경에서의 진정한 배포 경험 없이는 얻기 힘든 엔지니어링 및 제품 관련 교훈들입니다. 이는 진지한 AIoT 제품들이 구축되는 토대입니다.

물리적 세계 환경에 배포한 후, 제품 신뢰성 (product reliability)에 접근하는 방식에서 가장 크게 변한 점은 무엇인가요? 댓글로 들려주세요.

iot #ai #startup #buildinpublic #productdevelopment #machinelearning #industry40 #showdev #softwareengineering #discuss #career #deeptech #reliability