시중에 나와 있는 "AI의 미래"에 관한 콘텐츠 중 상당수는 실행에 옮기기에는 너무 모호한, 매우 추측에 기반한 종류입니다. 이것은 그런 것이 아닙니다. 다음에 이어지는 내용은 오늘날 산업용 AIoT 배포 현장에서 목격되고 있는 인프라 및 툴링(tooling)의 변화입니다. 이 지식은 이 분야에서 무언가를 구축하고 있다면 필수적인데, 이는 2년 전 우리가 알고 있었던 것과 비교했을 때 무엇이 "좋은 아키텍처 (good architecture)"를 구성하는지에 대한 정의를 근본적으로 바꾸기 때문입니다.

1. TinyML이 참신함에서 기본값(Default)으로 이동하고 있음

과거에는 마이크로컨트롤러급 하드웨어에서 추론하는 연구의 영역이었습니다. 오늘날 많은 엣지(edge) 배포, 특히 클라우드 왕복(round-trip)의 오버헤드를 감당할 수 없는 안전 모니터링이나 출입 통제와 같이 지연 시간(latency)에 민감한 애플리케이션의 경우, 이는 그저 당연하게 이루어지는 방식입니다. TensorFlow Lite Micro 및 Edge Impulse와 같은 프레임워크는 저렴한 ARM Cortex-M 칩에서 양자화된(quantised) 모델을 사용하는 것이 더 이상 최첨단 실험이 아니라, 상당히 일상적인 엔지니어링 선택이 될 정도로 성숙했습니다.

이것이 변화시키는 것: 모델 설계는 훈련 후 최적화 단계로 취급하는 것이 아니라, 처음부터 대상 배포 하드웨어를 본질적으로 고려해야 합니다. 팀들은 전체 정밀도(full-precision) 모델이 압축 과정에서 살아남기를 기대하는 대신, 처음부터 양자화 인식(quantisation-aware) 방법을 사용하여 훈련하는 경우가 점점 늘어나고 있습니다.

2. 시계열 데이터베이스가 몇 가지 표준을 중심으로 통합되고 있음

몇 년 전만 해도 산업용 데이터 파이프라인을 구축하는 사람은 각기 다른 장단점을 가진 시계열 저장 솔루션의 혼란스러운 지형에 직면해야 했습니다. 이제 그것이 하나로 합쳐지고 있습니다. InfluxDB와 TimescaleDB는 대부분의 새로운 산업용 데이터 파이프라인을 위한 기본 솔루션으로 부상했습니다. 이는 대시보드 통합부터 데이터 보존 정책(retention policies) 및 다운샘플링(downsampling)에 이르기까지, 이전에는 광범위한 맞춤형 엔지니어링이 필요했던 모든 기능에 대해 내장된 지원을 제공하는 성숙한 생태계 덕분입니다.

이것이 변화시키는 것: 자체적인 커스텀 스토리지 레이어 (storage layers)를 구축하고 유지 관리하는 데 드는 시간은 줄이고, 모델 성능에 훨씬 더 중요한 실제 데이터 품질 및 정규화 (normalisation) 문제에 더 많은 시간을 집중할 수 있습니다.

3. MQTT는 대체되는 것이 아니라 확장되고 있습니다

산업용 메시징을 위해 MQTT가 더 새롭고 현대적인 무언가로 대체될지 업계가 잠시 의문을 가졌던 시기가 있었습니다. 현실은 MQTT가 강화되고 있다는 점입니다. MQTT 5는 개선된 오류 처리 (error handling), 메시지 만료 (message expiration), 토픽 별칭 (topic aliasing) 기능을 도입하여, 프로토콜의 완전한 전면 개편을 요구하지 않으면서도 기존의 많은 단점들을 완화했습니다. 더 중요한 것은, MQTT를 기반으로 구축된 Sparkplug B가 산업용 페이로드 구조 (payload structure)를 표준화하는 능력 덕분에 널리 확산되고 있다는 점입니다. 이는 통합 과정에서 너무 많은 시간을 소모하게 만들었던 "모든 벤더가 서로 다른 스키마 (schema)를 가진다"는 골칫거리를 해결하는 중요한 개선 사항입니다.

이것이 변화시키는 것: 오늘 새로운 산업용 파이프라인 (pipeline)을 시작한다면, 초기에 Sparkplug B 컨벤션 (conventions)을 표준화함으로써 과거에는 프로젝트마다 커스텀으로 처리해야 했던 상당한 양의 정규화 노력을 절약할 수 있습니다.

4. 드리프트 탐지 (Drift Detection)는 사후 고려 사항이 아닌, 일급 파이프라인 구성 요소가 되고 있습니다

모델 모니터링이 홀드아웃 테스트 세트 (held-out test set)에 대한 정확도를 가끔 확인하는 것을 의미하던 시대는 지났습니다. 특히 산업 분야에서는 데이터 파이프라인에 직접 내장된 더욱 강력한 드리프트 탐지 (drift detection)를 볼 수 있습니다. 이는 모델 출력 드리프트 (output drift)뿐만 아니라 센서 수준에서의 통계적 드리프트 (statistical drift)까지 모니터링하여, 센서가 하류 (downstream) 예측을 조용히 오염시키기 전에 엔지니어에게 센서 고장이나 성능 저하를 알립니다. 한때 주로 표준 ML-ops 파이프라인의 영역이었던 Evidently 및 Great Expectations와 같은 도구들이 산업 환경에서 점점 더 많이 등장하고 있습니다.

이것이 변화시키는 것: "데이터 엔지니어링 (data engineering)"과 "ML 모니터링 (ML monitoring)" 사이의 경계가 모호해지고 있습니다. 종종 단일 파이프라인 구성 요소가 이 두 가지 역할을 모두 담당하게 됩니다.

5. 연합 및 온프레미스 (On-Prem) 배포의 확대, 축소가 아닌 성장

업계 전반의 흐름은 클라우드 네이티브 (Cloud-native)를 강력하게 추진하는 추세이지만, 우리는 점점 더 많은 산업용 AIoT 배포가 연합 (Federated) 또는 완전한 온프레미스 (On-premises) 학습 및 추론 (Inference) 방식으로 이동하는 것을 목격하고 있습니다. 이는 데이터 주권 (Data sovereignty)에 대한 우려, 임계 지연 시간 (Critical latency) 요구 사항, 그리고 많은 경우 민감한 운영 데이터를 자체 구내에 유지하려는 고객의 선호도에 의해 주도되고 있습니다. 광범위한 SaaS 운동에 반하는 이러한 역트렌드는 산업용 구매자들이 줄곧 원해왔던 것과 일치하며, 이제야 툴링 (Tooling)이 이를 실용적으로 구현할 수 있도록 따라잡기 시작한 것입니다.

이것이 변화시키는 것: 아키텍트 (Architects)들은 이제 온프레미스를 엔터프라이즈 고객을 위한 부차적인 추가 기능으로 간주하는 대신, 처음부터 클라우드와 온프레미스 배포 경로를 모두 계획해야 합니다.

공통된 맥락

이러한 변화 중 그 어느 것도 근본적으로 더 "똑똑한" 모델을 포함하고 있지 않다는 점에 주목하는 것이 중요합니다. 대신, 이는 인프라 구성 요소들이 성숙해지고 있음을 의미합니다. 즉, 표준화 (Standardisation), 모니터링 (Monitoring), 배포 (Deployment), 주권 (Sovereignty)과 같은 까다롭고 맞춤화된 통합 문제들이 매번 새로운 배포마다 맞춤형 솔루션을 요구하는 대신, 기존 도구들로 관리 가능한 수준이 되고 있다는 것입니다. 이는 산업용 AIoT 구축을 예상보다 오래 걸리게 만들었던 역사적 장벽을 제거한다는 점에서 매우 중요한 진화입니다.

수많은 프로젝트를 통해 이러한 변화를 적극적으로 추적하고 이를 기반으로 구축해 온 Aperture Venture Studio와 같은 기업 및 스튜디오들은 그 이점을 누리고 있으며, 이러한 과제에 처음 직면한 이들보다 상당한 우위를 점하고 있습니다.

다른 분들은 툴링 측면에서 무엇을 관찰하고 계신지 궁금합니다. 이미 운영 환경에서 Sparkplug B를 배포하고 계신 분이 계신가요, 아니면 여전히 공급업체별 전용 페이로드 (Payload) 형식의 늪을 헤치고 계신가요?