소프트웨어에서 AIoT로 전환하는 모든 엔지니어는 결국 어떤 순간을 맞이하게 됩니다. 이는 실험실 설정이나 세심하게 통제된 파일럿 단계가 아니라, 실제 장비와 실제 이해관계가 얽힌 실제 운영 환경에서의 첫 번째 실질적인 산업 배포(industrial deployment) 중에 찾아옵니다.

그 순간은 "테스트에서는 시스템이 작동한다"와 "이 시설에서 시스템이 작동한다" 사이의 간극이 더 나은 코드를 작성하는 것만으로는 메워질 수 없다는 것을 깨닫는 순간입니다. 이는 애초에 "작동한다"는 정의를 어떻게 내릴 것인지부터 다시 생각할 것을 요구합니다.

소프트웨어에서 "작동한다"는 것은 대체로 이진적(binary)입니다. 함수가 올바른 출력을 반환합니다. API가 예상된 페이로드(payload)로 응답합니다. 테스트 스위트(test suite)가 통과합니다. AIoT—산업용 IoT(Industrial IoT) 시스템과 통합된 인공지능(Artificial Intelligence)—에서 "작동한다"는 것은 훨씬 더 까다로운 정의를 가진 스펙트럼입니다. 기술적으로는 정확하지만 운영자가 신뢰할 수 없는 출력을 생성하는 시스템은 작동하는 것이 아닙니다. 정상적인 조건에서는 잘 작동하지만 센서가 고장 났을 때 예측 불가능하게 성능이 저하되는 시스템은 작동하는 것이 아닙니다. 정확한 예측을 생성하지만 운영 워크플로우(operational workflow)에 맞지 않는 채널을 통해 전달하는 시스템은 작동하는 것이 아닙니다.

이러한 차이를 이해하고, 더 까다로운 정의를 충족하는 시스템을 구축하는 것이 AIoT 엔지니어링을 다른 대부분의 엔지니어링 분야와 구분 짓는 요소입니다.

캘리브레이션(Calibration) 문제는 당신이 생각하는 것과 다릅니다

대부분의 엔지니어는 모델 캘리브레이션(model calibration)을 학습(training) 문제로 생각합니다. 모델의 신뢰도 점수(confidence scores)가 실제 확률을 반영하기를 원합니다. 즉, 90%의 신뢰도로 내린 예측은 약 90%의 확률로 맞아야 합니다. 이는 확립된 기술들이 있는 잘 알려진 문제이며, 대부분의 현대적 ML 프레임워크는 이를 해결하기 위한 도구를 제공합니다.

산업용 AIoT에는 ML 문헌에는 등장하지 않는 두 번째 캘리브레이션 문제가 있습니다. 바로 시스템의 동작을 그것이 배포된 특정 환경의 운영 컨텍스트(operational context)에 맞게 캘리브레이션하는 것입니다.

제조 장비를 모니터링하는 온도 센서를 예로 들어보겠습니다. 여러분의 이상 탐지 (anomaly detection) 모델에는 임계값 (threshold)이 설정되어 있습니다. 즉, 특정 값 이상의 수치가 읽히면 경고 (alert)가 발생합니다. 학습 데이터 (training data)에서 이러한 높은 수치는 항상 장비의 스트레스와 연관되어 있었습니다. 하지만 이 특정 시설에서는, 여름철에 장비 인근의 하역장 문이 열릴 때도 이 특정 센서에서 높은 온도 수치가 나타납니다. 주변 온도와 에어컨 냉기 사이의 열적 대비 (thermal contrast)가 센서가 감지할 수 있는 국소적인 열 상승 기류 (thermal plume)를 만들기 때문입니다.

여러분의 모델은 이 사실을 알지 못합니다. 다른 시설에서 수집되었거나 통제된 조건 하에서 수집된 학습 데이터에는 이러한 패턴이 포함되어 있지 않습니다. 그래서 따뜻한 날 하역장 문이 열릴 때마다 모델은 경고를 생성합니다. 세 번째 또는 네 번째 오경보 (false alert)가 발생한 후, 유지보수 팀은 해당 센서의 경고를 무시하기 시작합니다. 열 번째가 되면, 그들은 여러분의 시스템을 신뢰할 수 없는 것으로 정신적으로 분류해 버립니다.

python // 모델이 알고 있는 것:
temperature > threshold → alert

// 환경이 알고 있는 것:
temperature > threshold AND NOT (dock_door_open AND ambient_temp > 25) → alert

// 문제점: 모델은 dock_door_open에 접근할 수 없음
// 더 깊은 문제: 아무도 dock_door_open이 변수라는 사실을 알려주지 않음
// 진짜 문제: 이러한 교란 요인 (confounders)을 배포를 통해 직접 발견해야 함. 왜냐하면 사전에 요구사항을 아무리 많이 수집하더라도 이 모든 것을 드러낼 수는 없기 때문입니다.

이것이 시사하는 바는 산업용 AIoT에서의 경고 캘리브레이션 (alert calibration)이 배포 전의 일회성 작업이 아니라는 점입니다. 이는 모델의 출력값과 운영 결과 (operational outcomes)를 연결하는 피드백 메커니즘, 그리고 모델이 알지 못하는 환경적 요인을 드러낼 수 있을 만큼 운영 팀과 긴밀한 관계를 유지해야 하는 지속적인 운영 프로세스입니다.

협조적이지 않은 환경을 위한 연결성 아키텍처 (Connectivity architecture)

대부분의 소프트웨어 시스템에 내장된 네트워크 가정은 너무나 근본적이어서 엔지니어들이 이를 명시적으로 설명하는 경우가 거의 없습니다. 즉, 클라이언트가 서버에 도달할 수 있고, 서버가 데이터베이스에 도달할 수 있으며, 네트워크가 실패하면 시스템은 에러를 표시하고 대기한다는 가정입니다.

산업 환경은 이러한 가정에 협조적이지 않습니다. 공장과 창고의 네트워크 인프라는 종종 노후화되어 있고, 불균등하게 분포되어 있으며, 중장비의 간섭을 받기 쉽습니다. 금속 랙(racking), 컨테이너, 대형 장비들은 시설 레이아웃이 변경됨에 따라 이동하는 데드 존(dead zones)을 생성합니다. 결정적으로, 가장 무거운 네트워크 부하가 발생하는 시점은 운영 용량이 정점에 달할 때이며, 이는 바로 안전 및 모니터링 시스템을 위해 신뢰할 수 있는 연결성이 가장 절실히 필요한 순간입니다.

이는 대부분의 소프트웨어 엔지니어들이 한 번도 내려본 적 없는 명시적인 아키텍처 결정을 강요합니다:

무엇을 엣지(edge)에서 실행해야 하는가? 최악의 연결 중단 상황보다 짧은 지연 시간(latency) 요구 사항을 가진 모든 로직이 대상입니다. 만약 안전 경고가 2초 이내에 발생해야 하는데 연결이 40분 동안 끊길 수 있다면, 탐지 및 경고 기능은 클라우드가 아닌 장치(device) 상에 존재해야 합니다.

시스템이 어떻게 우아하게 재연결(reconnect)되는가? 장치가 연결이 끊긴 동안 축적된 읽기 데이터 버퍼를 가지고 다시 온라인 상태가 되었을 때, 동기화 계층(sync layer)은 타임스탬프 충돌, 순서의 모호성, 그리고 불완전한 정보로 내려진 결정들을 처리할 수 있어야 합니다. 이는 분산 시스템(distributed systems) 문헌에서 설명하는 합의(consensus) 문제라기보다는, 엄격한 일관성(consistency)이 아닌 일관된 운영 내러티브를 목표로 하는 조정(reconciliation) 문제입니다.

물리적으로 손댈 수 없는 모델을 어떻게 업데이트하는가? 산업용 엣지 장치에서의 OTA(Over-the-Air) 모델 업데이트는 원자적 배포(atomic rollout), 실패 시 자동 롤백(automatic rollback), 그리고 업데이트가 성공했다고 선언하기 전 로컬 데이터 분포에 대한 장치 내 검증(on-device validation)을 필요로 합니다. 무인 장비실에 있는 장치의 업데이트 실패는 단순한 티켓(ticket) 문제가 아니라, 운영 사고(operational incident)입니다.

공유 배포 플랫폼(shared deployment platform) 기반으로 산업용 AI 벤처를 구축하는 Aperture Venture Studio와 같이, 대규모로 AIoT를 개발하는 조직들은 반복적인 실제 환경 배포를 통해 이러한 문제들에 대한 체계적인 대응 방안을 축적합니다. 그러한 지식은 문서만으로는 전달될 수 없으며, 반드시 직접 경험을 통해 얻어야 하는 것입니다.

이것이 어디에서 구축할지를 결정하는 엔지니어들에게 의미하는 바

산업용 AIoT의 문제들은 특정한 방식으로 어렵습니다. 이는 거대 모델을 학습시키는 것과 같은 화려한 어려움(glamour-hard)이 아니라, 물리적 세계가 당신의 가설에 따를 의무가 없기 때문에 예측하지 못한 방식으로 고장 나는 시스템이 주는 겸손한 어려움(humility-hard)입니다.

이러한 문제들을 해결하며 얻게 되는 기술들—에지-클라우드 아키텍처(edge-cloud architecture)의 깊이, 실제 분포 변화(distribution shift) 상황에서의 신뢰성 공학(reliability engineering), 그리고 현대적인 API 관례가 생기기 이전부터 존재했던 레거시 시스템(legacy systems)과의 통합 능력—은 진정으로 희소하며, 산업용 AI 시장이 가속화됨에 따라 그 가치가 더욱 높아지고 있습니다.

물리적 환경이 신뢰할 수 있는 시스템을 구축하는 것에 대해 당신에게 가르쳐준 가장 직관에 반하는(counterintuitive) 사실은 무엇인가요? 댓글로 남겨주세요.

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