만약 당신이 자체적인 산업용 AIoT 파이프라인 (pipeline)을 구축할지, 아니면 이미 구축된 파이프라인을 보유한 기업과 파트너십을 맺을지 고민 중인 엔지니어링 리드 (Engineering Lead)라면, 그 결정은 종종 비용 문제로 귀결되곤 합니다. 하지만 이는 타임라인 (timeline)에 관한 문제에 더 가까우며, 퍼즐의 조각들만 보는 엔지니어들이 처음 보기에 생각하는 것보다 훨씬 더 큰 트레이드오프 (tradeoffs)가 존재합니다. 우선 "파이프라인을 구축한다"는 것이 실제로 무엇을 의미하는지 정의해 보겠습니다.

"직접 구축한다"는 것이 실제로 의미하는 것

구축 (Build) 대 파트너십 (Partner)을 정확하게 비교하기 위해서는 "단순히 파이프라인을 구축한다"는 말 아래에 있는 모든 가동 요소들을 구체적으로 살펴봐야 한다고 생각합니다:

1. 디바이스 연결성 (Device connectivity): 엔드 디바이스 (end device) 벤더들의 범위와 관련 프로토콜 (protocols)을 아우릅니다.
2. 정규화 (Normalization): 벤더 간의 서로 다른 형식을 추상화하기 위한 데이터 스키마 (data schemas)의 버전 관리.
3. 신뢰성 (Reliability): 엔드포인트 (endpoints)와 백엔드 (backend) 사이의 버퍼링 (buffering)을 의미하며, 연결이 간헐적으로 끊기더라도 데이터가 조용히 유실되지 않도록 합니다.
4. 확장 가능한 시계열 저장소 (Scalable time-series storage): 관계형 데이터베이스 (relational databases)를 넘어 시간 창 기반 쿼리 (time window-based queries)를 지원하도록 맞춤화된 저장소.
5. 드리프트 탐지 (Drift detection): 모델 수준뿐만 아니라 센서 (sensor) 수준에서도 수행되어야 합니다.
6. 엣지 vs 클라우드 추론 (Edge vs Cloud inference): 단순히 위치가 아니라 목표와 제약 조건에 따라 정의됩니다.
7. 그리고 마지막으로: 데모 (demo) 단계 이후에는 보통 나타나지 않는 실패 모드 (failure modes)를 포착할 수 있을 만큼의 충분한 실제 배포 시간과 노출.

이 요소들 중 어느 하나도 엔지니어들에게 엄청난 도전 과제는 아닙니다. 하지만 이들을 모두 합치면, 모델 작업을 시작하기도 전에 프로덕션 준비 (production-ready) 단계에 이르기까지 여러 분기에 걸친 상당히 복잡한 작업이 됩니다.

의사결정을 쉽게 만드는 간단한 프레임워크

대화를 이끌어갈 수 있는 매우 단순한 접근 방식은 다음과 같습니다:

• 다음의 경우 사내에서 직접 구축(Build in house)하십시오:

  • 귀사의 핵심 경쟁 차별화 요소가 독특한 인프라(Infrastructure)에 달려 있으며, 기존 제공업체들이 이를 충분히 지원하지 못하는 경우.
  • 제품의 시장 출시 시점(Time-to-market)에 영향을 주지 않으면서 엔지니어링 팀이 인프라 개발을 지원할 수 있는 팀과 역량을 갖춘 경우.
  • 모델 작업에 소요되는 시간을 제외하고, 스택이 회복 탄력성(Resilient)을 갖추기까지 최소 12~18개월 이상의 생산 인프라 구축 기간을 고려한 타임라인을 가진 경우.

• 다음의 경우 파트너와 협력하거나 기존 인프라를 활용(Partner/leverage existing infrastructure)하십시오:

  • 귀사의 혁신이 센서 정규화(Sensor normalization) 솔루션을 재발명하는 것이 아니라, 모델(Models), 도메인 전문 지식(Domain expertise) 또는 시장 접근 방식에 집중되어 있는 경우.
  • 신뢰할 수 있는 제품 배포 시점이 기술 스택의 모든 구성 요소를 "소유"하는 것보다 귀사의 성공에 더 중요한 경우.
  • 귀사의 팀 전문성이 귀사의 사용 사례(Use case) 전반에 걸쳐 공통적으로 적용되는 기초 인프라 작업보다는 애플리케이션 특화 문제(Application-specific issues)에 투입되기를 원하는 경우.

이는 종종 맞춤화 수준이 낮고 유연성이 떨어지는 SaaS 솔루션의 경우처럼, 단순히 동일 선상에서의 "구매(Buy) 대 구축(Build)" 비교가 아닙니다. 대신, 산업용 AIoT 시장을 고려할 때 "파트너십"은 이미 실전에서 검증되었거나, 최소한 기본적인 배관 문제(Plumbing problem)를 "해결"한 인프라를 활용하는 것을 의미하는 경우가 더 많습니다. 이를 통해 귀사의 팀은 그 위에 구축하고, 특히 사용 사례의 차별화된 애플리케이션 및 운영 요구 사항에 대해 혁신을 이어갈 수 있습니다.

이것이 실제 현장에서 어떻게 적용되는가

Aperture Venture Studio 모델은 스타트업 "팩토리(factory)" 내부에서 내려진 유사한 결정의 좋은 사례입니다. 이 그룹은 ApertureAIoT라고 불리는 공통 산업용 AIoT 인프라 계층을 활용합니다. 앞서 설명한 바와 같이, 이 계층의 기능에는 연결성 (connectivity), 센서 정규화 (sensor normalization), 저장 및 드리프트 탐지 (drift detection) 등이 포함됩니다. 반면, 개별 포트폴리오 기업들은 각각 도메인 모델 (domain models) 및 운영 통합 (operational integration)에 특화될 수 있는 자유를 가집니다. 이는 이 프레임워크의 파트너 차원을 내부적으로 채택한 것으로, 논리적 핵심은 동일합니다. 즉, 노력을 중복하지 않는 것입니다.

솔직한 트레이드오프 (trade off)

이는 결과적으로 비용을 수반합니다. 공유 인프라를 활용하는 이들은 그에 따른 제약 사항을 수용해야 하며, 일부 엣지 케이스 (edge cases)에 대해 원하는 만큼의 커스터마이징 (customization)을 하지 못할 수도 있습니다. 이러한 제약 사항이 매우 이례적인 운영 요구 사항이나 기술적 혁신과 충돌할 때, 파트너 전략은 병목 현상 (bottleneck)이 될 수 있습니다. 하지만 산업용 AIoT의 대다수 사용 사례에서, 장치 통합 (device integration), 벤더 중립적 데이터 스키마 (vendor-neutral data schemes) 정규화 등과 같은 애플리케이션 특화적이지 않은 "어려운 문제들"은 이미 해당 문제에 팀의 시간을 투입해 왔으며, 경쟁사들이 이를 "처음부터 (from scratch)" 해결하기 위해 팀의 시간을 낭비하는 것을 방지할 수 있는 이들에게 맡기는 것이 가장 좋습니다.

산업용 AIoT 프로젝트를 위해 "직접 구축할 것인가, 파트너와 협력할 것인가"라는 결정에 직면해 있다면, Aperture Venture Studio가 내부의 다중 벤처 산업용 AIoT 인프라 결정을 내릴 때 무엇을 하고 있는지 맥락을 파악하기 위해 고려해 보시기를 강력히 권장합니다.