산업용 고객을 위한 소프트웨어 제품을 구축할 때 가장 적게 논의되는 측면 중 하나는, 제품 개발 루프 (product development loop)가 소비자용 또는 엔터프라이즈 SaaS 개발과 얼마나 다르게 느껴지는가 하는 점입니다.

전형적인 SaaS 제품 개발 주기에서 루프는 매우 타이트합니다. 기능을 출시하고, 참여 지표 (engagement metrics)를 관찰하며, A/B 테스트를 실행하고, 2주 단위의 스프린트 (sprints)로 반복합니다. 고객은 가까이 있으며, 때로는 제품 내 피드백 메커니즘을 통해 실시간으로 소통할 수 있습니다. 또한 잘못된 가정이 초래하는 비용은 단순히 스프린트 하나를 낭비하는 수준이며, 실제 운영 시설에 대한 접근 권한을 부여한 엔터프라이즈 고객과의 관계가 손상되는 수준은 아닙니다.

산업용 AIoT 제품 개발은 이런 방식으로 작동하지 않습니다. 고객들은 대규모 시설 전역에 물리적으로 분산되어 있습니다. "이 모델 업데이트를 배포했다"에서부터 "이것이 더 나은 성능을 보이는지 혹은 나쁜 성능을 보이는지 이해했다"에 이르는 피드백 사이클은 몇 주가 걸릴 수 있는데, 이는 당신이 예측하거나 방지하려는 이벤트들이 설계상 저빈도 (low-frequency)이기 때문입니다. 무언가를 잘못했을 때의 비용은 단순히 지표가 하락하는 것이 아닙니다. 그것은 운영 관리자 (operations manager)가 당신의 시스템을 신뢰할 수 없다고 판단하고, 시스템을 우회하여 경로를 지정하기 시작하는 것입니다.

이를 이해하고 이를 고려한 제품 개발 관행을 구축하는 것은 Aperture Venture Studio가 GAO Group of Companies 내부에서의 초기 산업용 배포를 거쳐, 2021년부터 독립적인 벤처 창출 플랫폼으로서 쌓아온 역사 속에서 개발한 가장 가치 있는 것 중 하나입니다.

산업용 AIoT에서의 모델 업데이트 문제

소비자용 ML (머신러닝) 제품에서 모델 업데이트는 빈번하며, 성능 퇴보 (regression)의 결과는 대개 회복 가능합니다. 추천 모델의 성능이 며칠 동안 저하될 수 있습니다. 하지만 집계 지표 (aggregate metrics)를 통해 이를 감지하고, 롤백 (roll back)하거나 수정을 배포하면 피해는 제한적입니다.

산업용 AIoT에서는 모델 업데이트에 다른 주기 (cadence)와 다른 검증 철학이 필요합니다. 그 이유는 다음과 같습니다.

산업용 AI 모델은 특정 환경—특정 센서, 특정 장비, 그리고 특정 운영 패턴—에서 수집된 데이터로 학습됩니다. 환경 A에서 성능이 좋은 모델이 환경 B에서는 성능이 좋지 않을 수 있으며, 이는 두 환경이 상위 수준의 설명(high-level description)으로는 유사해 보일지라도 마찬가지입니다. 환경 간의 분포 변화 (distribution shift)는 미묘하지만 중대한 결과를 초래합니다. 즉, 서로 다른 센서 교정 (calibration) 상태, 서로 다른 운영 리듬, 그리고 모델이 학습 과정에서 노출되지 않았던 서로 다른 환경 변수들이 존재합니다.

고객 시설의 장치에 모델 업데이트를 배포할 때, 여러분은 단순히 소프트웨어를 업데이트하는 것이 아닙니다. 여러분은 고객의 운영 팀이 관계를 형성해 온 시스템의 추론 (inference) 동작을 변경하는 것입니다. 이 관계는 정답이었던 알람과 오탐 (false positive)으로 판명된 알람의 특정 기록을 바탕으로 구축된 것입니다. 모델 업데이트로 인해 오탐률이 아주 조금이라도 상승한다면, 운영 팀이 수개월 동안 시스템에 대해 쌓아온 신뢰를 무너뜨릴 수 있습니다. 그리고 한 번 무너진 신뢰는 빠르게 회복되지 않습니다.

Python // 소비자용 ML 배포 사고방식 (Consumer ML deployment mindset):
if new_model.benchmark_accuracy > current_model.benchmark_accuracy:
deploy(new_model)

// 산업용 AIoT 배포 사고방식 (Industrial AIoT deployment mindset):
if (new_model.site_specific_accuracy(facility_id) > current_model.site_specific_accuracy(facility_id)
AND new_model.false_positive_rate(facility_id) <= current_model.false_positive_rate(facility_id)
AND new_model.has_passed_shadow_mode_validation(facility_id, min_days=14)):
schedule_deployment(new_model, maintenance_window=next_planned_downtime)

배포 결정 로직의 차이는 모델과 운영 환경 사이의 근본적으로 다른 관계를 반영합니다. 산업용 AIoT 모델은 총체적인 벤치마크 성능 (benchmark performance)을 향상시키기 위해 업데이트되는 것이 아닙니다. 대신, 해당 환경의 특정 사고 이력 (incident history) 및 운영 컨텍스트 (operational context)를 기준으로 측정된 특정 환경에서의 성능을 개선하기 위해 업데이트됩니다.

공유 인프라가 학습할 수 있는 내용을 어떻게 변화시키는가

Aperture가 사용하는 벤처 스튜디오 (venture studio) 모델의 구조적 장점 중 하나는 Aperture AIoT 플랫폼이 여러 벤처를 동시에 서비스한다는 점입니다. 이는 독립적인 스타트업이 가질 수 없는 관찰적 우위 (observational advantage)를 창출합니다. 즉, 여러 산업 환경의 여러 배포 사례에서 나타나는 패턴이 가시화되고 실행 가능한 정보가 되는 반면, 단일 제품 기업은 동일한 패턴을 한두 번만 접하고 이를 체계적인 현상이 아닌 일회성 에지 케이스 (edge case)로 해석할 수 있습니다.

습도가 높은 시설의 베어링 온도 센서에 영향을 미치는 센서 교정 드리프트 (sensor calibration drift) 패턴은 체계적인 패턴입니다. 교대 근무 기반의 운영 환경에서 AI 시스템이 근무 마지막 시간대에 너무 많은 알림을 생성할 때 발생하는 알림 피로 (alert fatigue) 역학 또한 체계적인 패턴입니다. 오래된 SCADA 시스템이 설계된 용량 범위의 한계점에서 작동할 때 데이터를 잘못 표현하는 구체적인 방식들도 체계적인 패턴입니다.

여러 산업 환경에 동시에 배포되는 플랫폼은 그 어떤 단일 배포 시스템보다 이러한 패턴에 대한 민감도를 더 빠르게 발달시킵니다. 이러한 민감도는 더 나은 제품 결정, 더 나은 모델 교정 (model calibration), 그리고 각 배포를 운영하는 팀을 위한 더 나은 운영 가이드로 피드백됩니다.

실제 산업 수요에서 시작할 때 변화하는 것들

Aperture가 구축하는 벤처(ventures)는 투영된 시장 기회가 아니라, GAO가 수십 년간 고객과 교류하며 확인한 실제 산업 고객들이 해결책을 적극적으로 찾아온 문제의 실제 패턴, 즉 관찰된 산업 수요에 기반을 두고 있습니다. 이러한 출발점은 제품 개발 역학을 특정한 방식으로 변화시킵니다. 팀은 가상의 고객을 대상으로 제품을 만들며 현실이 가설과 일치하기를 바라는 것이 아닙니다. 그들은 문서화된 실제 필요의 패턴을 향해 제품을 구축하며, 이는 초기 고객과의 대화가 문제가 실제로 존재하는지 검증하는 것이 아니라, 정교화(refinement)와 적합성(fit)에 관한 것이 됨을 의미합니다.

엔지니어들에게 이 차이는 처음 생각하는 것보다 더 중요합니다. 제품 개발에서 가장 사기를 저하시키는 경험은, 기술적으로는 매우 뛰어나지만 고객이 이를 수용하기 위해 행동을 바꿀 만큼 시급하지 않은 문제를 위해 무언가를 만드는 것입니다. 경험적으로 문서화된 수요에서 시작하는 것이 그 위험을 완전히 제거하지는 못하지만, 위험을 상당히 줄여줍니다. 그리고 낭비되는 엔지니어링 노력의 감소는 제품의 수명 주기 동안 상당한 복리 효과를 가져옵니다.

산업 현장이나 물리적 제약이 있는 환경에서 제품을 출시한 후, 제품 개발에 접근하는 방식에서 가장 크게 변화한 점은 무엇인가요? 댓글로 들려주세요.

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