디지털 환경과 산업 환경 모두에서 시스템을 출시(shipping)해 본 엔지니어들의 커리어에는 공통된 패턴이 나타납니다. 그들은 산업 환경에서의 경험을 이야기할 때, 마치 유독 까다로운 제약 조건들과 함께 일했던 경험을 이야기하듯 회고적인 좌절감과 진심 어린 감사함이 뒤섞인 태도를 보입니다. 좌절감은 실재합니다. 하지만 감사함은 그 제약 조건들이 그들에게 배우도록 강제했던 것들에 대한 것입니다.

산업 환경은 소프트웨어 엔지니어링의 가설들을 너무나 철저하게, 그리고 너무나 많은 차원에서 동시에 깨뜨려 버립니다. 그렇기에 그곳에서의 구축은 더 관대한 환경에서의 구축과는 달리 진정으로 성장을 가속화합니다. 여기서는 어떤 가설들이 깨지는지, 그리고 그것들을 무엇이 대체하는지에 대한 구체적인 기록을 다룹니다.

데이터 모델은 API와의 계약이 아니라 물리 법칙과의 협상이다

대부분의 백엔드 시스템에서 데이터 모델은 계약(contract)입니다. 스키마를 정의하고, 타입을 강제하며, 값을 제한하고, API 경계에 도달하는 데이터가 명세(specification)를 준수한다고 신뢰합니다. 만약 준수하지 않는다면, 그것은 호출자(caller) 측의 버그이며 수정되어야 할 대상입니다.

산업용 AIoT에서 데이터 모델은 협상(negotiation)입니다. 센서는 현재의 교정(calibration) 상태, 환경적 노출, 그리고 실행 중인 펌웨어(firmware) 상태에서 가능한 데이터를 보고합니다. 이러한 요소들은 버전이 관리되지도, 문서화되지도 않은 방식으로 시간이 지남에 따라 변화합니다. 당신은 이를 배포를 통해 발견하게 됩니다.

// 데이터 모델 명세에 넣는 내용:
{
  sensor_id: string,       // 필수, 8자리 16진수
...

이 모든 상황을 올바르게 처리하려면, 파이프라인에 각 사례에 대한 구체적이고 의도적인 로직이 필요합니다. 이는 단순히 일반적인 null 처리나 이상치 탐지(outlier detection)를 의미하는 것이 아니라, 특정 하드웨어의 고장 모드 어휘(failure mode vocabulary)를 이해하고 실제 이상 징후(anomaly)와 계측 아티팩트(instrumentation artifact)를 구분할 수 있는 로직을 의미합니다.

그러한 로직을 작성하려면 어떤 고장 모드(failure modes)를 예상해야 하는지 알아야 합니다. 어떤 고장 모드를 예상해야 하는지 알기 위해서는, 그것들을 직접 마주할 수 있을 만큼 충분한 배포(deployment) 과정을 거쳐야 합니다. 이것이 바로 실제 배포를 통해 구축된 산업용 AIoT 인프라가, 겉으로 보이는 엔지니어링 노력의 수준이 동일하더라도 이론적으로 구축된 인프라보다 구조적으로 더 우수한 핵심적인 이유입니다.

배포 환경은 프로덕션(production)에 대한 비유가 아니다

웹 및 모바일 개발에서 "프로덕션(production)"은 특정 설정이 적용된 배포 대상입니다. 스테이징(staging)과 프로덕션 사이의 격차는 대개 규모(scale)와 데이터 볼륨의 차이입니다.

산업용 AIoT에서 개발 환경과 실제 산업 시설 사이의 격차는 물리(physics)의 문제입니다. BLE 신호를 저하시키는 대형 모터의 RFI(무선 주파수 간섭), 게이트웨이를 설치하려 계획했던 바로 그 지점에 데드 존(dead zone)을 만드는 금속 구조물, 새벽 4시에 엣지 디바이스(edge device)의 SD 카드를 재장착하게 만드는 진동 프로필, 여름철 오후 생산 피크 시간대에 센서 태그를 작동 사양의 한계치까지 몰아붙이는 주변 온도 범위 등이 그것입니다.

이 중 그 어떤 것도 개발 환경에서는 나타나지 않습니다. 이 모든 것들은 배포 시에 나타납니다. 그리고 차폐 케이블(shielded cabling), 게이트웨이 배치 프로토콜, 하드웨어 선정 기준, 인클로저(enclosure)를 위한 열 관리와 같은 각각의 공학적 대응책은 부분적으로 문서화될 수는 있지만, 기본적으로는 그것을 직접 마주한 경험을 통해 학습되는 지식입니다.

이것이 바로 공유 생산 플랫폼 위에서 산업용 AI 벤처 포트폴리오를 개발하는 Aperture Venture Studio와 같이, 여러 실제 배포 사례를 통해 공유 AIoT 플랫폼 인프라를 구축하는 조직들이 단일 배포 팀은 복제할 수 없는 방식으로 배포 전반에 걸쳐 복리로 쌓이는 운영 지식을 축적하는 이유 중 하나입니다.

신뢰성 공학(Reliability engineering)은 단계가 아니라 지속적인 규율이다

소프트웨어 분야에서 신뢰성 공학 (reliability engineering)은 일반적으로 양호한 모니터링 체계를 구축하고, 런북 (runbooks)을 작성하며, 우아한 성능 저하 (graceful degradation)를 고려하여 설계하는 것을 의미합니다. 이는 중요한 요소입니다. 하지만 산업용 AIoT에서는 이러한 요소들이 필요하긴 하지만 충분하지는 않습니다. 왜냐하면 고장 모드 (failure modes)가 소프트웨어 신뢰성 공학에서는 보통 다루지 않는 차원, 즉 운영 환경에서의 하드웨어 물리적 열화 (physical degradation)를 포함하기 때문입니다.

저온 저장 환경의 센서 태그는 6개월 동안 대부분의 가전제품이 수년 동안 겪는 것보다 더 많은 열 사이클링 (thermal cycling)을 경험합니다. 지게차에 장착된 BLE 비콘은 고정 설치용으로 설계된 장치의 사양을 초과하는 진동 노출을 축적합니다. 냉난방 시설이 없는 장비실의 에지 게이트웨이 (edge gateway)는 소프트웨어 중심의 엔지니어들이 데이터 시트의 작동 온도 사양만 보고는 예상하지 못할 여름철 고온 속에서 작동합니다.

신뢰할 수 있는 AIoT 시스템을 구축하려면 하드웨어 수명과 환경 노출을 별도로 처리해야 할 조달 (procurement) 문제가 아니라, 일급 엔지니어링 변수 (first-class engineering variables)로 취급해야 합니다. 펌웨어 업데이트 전략은 하드웨어의 열화로 인해 동작 방식이 변하는 장치들을 고려해야 합니다. 모니터링 시스템은 단순히 소프트웨어의 상태뿐만 아니라 하드웨어의 건강 상태를 나타내는 지표들을 추적해야 합니다. 교체 주기 또한 제품 사양서의 명목상 사양 (nominal specifications)이 아니라, 실제 배포된 운영 환경을 기반으로 고장이 발생하기 전에 계획되고 실행되어야 합니다.

이것이 바로 산업 환경이 당신에게 강제로 습득하게 만드는 엔지니어링 규율 (engineering discipline)입니다. 이는 대부분의 소프트웨어 공학 커리큘럼에는 존재하지 않습니다. 이는 시스템이 특정한 방식으로 실패하는 것을 지켜보고, 왜 실패했는지 이해하며, 다음 반복 (iteration) 단계에서 실패를 줄이도록 설계하는 축적된 경험을 통해 구축됩니다. 그 과정은 결코 단축될 수 없는 방식으로 진정으로 교육적입니다.

산업 환경이나 물리적 제약이 있는 배포의 어떤 측면이 당신의 신뢰성 공학 (reliability engineering) 접근 방식을 변화시켰나요? 댓글로 공유해 주세요 — 이것들이 바로 교과서에는 실리지 않는 교훈들입니다.

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