패턴으로서, 엔지니어에게 진정으로 흥미로운 점은 일부 조직이 보통 제품당 하나의 스택을 제공하여 중복된 인프라를 가진 별도의 코드 베이스로 격리하는 방식 대신, 이러한 제품들을 지원하는 단일하고 포괄적인 데이터/AI 계층을 구축하는 방식입니다. Aperture Venture Studio가 이를 어떻게 수행하고 있는지 자세히 살펴보겠습니다. 이는 결정을 내릴 때 모두가 명시적으로 언급하지는 않는 트레이드오프 (tradeoff)에 대한 좋은 사례 연구입니다.

가장 저항이 적은 경로: 제품당 하나의 스택

만약 우리가 자산 추적 (asset-tracking) 제품을 만드는 사업을 하고 있고, 예를 들어 인력 안전 (workforce-safety) 제품을 별도로 만든다면, 엔지니어링 관점에서 자연스러운 일은 그냥 그것들을 두 개의 별도 스택으로 만드는 것입니다. 이는 별도의 인제스션 파이프라인 (ingestion pipelines), 그리고 별도의 정규화 (normalisation) 및 모델 학습 (model training) 인프라를 수반합니다.

초기에는 후자가 다른 문제 세트를 가지고 있는 것이 분명해 보이므로, 왜 이를 결합하겠느냐고 생각할 수 있습니다.

조기 최적화 (premature optimisation) 문제는 말할 것도 없습니다.

하지만 이 결정은 반드시 당신을 괴롭히게 될 것입니다. 왜냐하면 두 제품 모두 근본적으로 똑같이 어렵거나 혹은 더 어려운 두 가지 문제를 해결해야 하기 때문입니다: 서로 다른 하드웨어 벤더 간의 일관되지 않은 센서 페이로드 (sensor payloads)가 정규화되고 적절하게 표현되도록 보장하는 것, 연결 끊김이 발생하는 경우 데이터 손실을 방지하는 것, 모델 오염 전에 센서 데이터 드리프트 (data drift)를 탐지하는 가장 좋은 방법은 무엇인지, 그리고 마지막으로 필요에 따라 엣지 (edge) 또는 클라우드 추론 (inference)을 지원하는 것입니다. 이러한 구성 요소들을 사일로 (silos) 형태로 구축한다는 것은 두 팀이 정확히 똑같은 어려운 문제들을 가장 어려운 방식으로 해결하고 있음을 의미합니다. 그리고 이러한 사일로 안에서는 지식이 한 팀에서 다른 팀으로 스스로 전파되지 않습니다.

대안적으로 구조화된 공유 계층

Aperture Venture Studio가 채택한 방식(자산 추적부터 재고 최적화, 인력 안전에 이르기까지 포트폴리오 기업들을 지원하는 공유 기반 인프라 계층 역할을 하는 ApertureAIoT를 사용하는 방식)은 이와 정반대입니다. 즉, 본질적으로 구축하기 가장 어렵고(또한 모든 제품에 공통적으로 적용되는) 요소를 동일한 재사용 가능한 인프라 계층으로 구축하는 데 사전에 투자함으로써, 개별 제품 팀이 자신의 문제 도메인과 관련된 고유한 부분에만 집중할 수 있도록 합니다.

이를 설명하기 위해, 아키텍처(Architecture) 관점에서 인프라를 다음 두 가지 계층으로 분리하는 것을 예로 들 수 있습니다:

공유 계층 (Shared) (한 번 구축하여 재사용 가능):

• 디바이스 커넥터/프로토콜 (device connectors/ protocols)
• 여러 하드웨어 제조사에 걸친 데이터 수집(ingestion), 정규화(normalization), 버전 관리(versioning)
• 시계열 데이터베이스 (time-series databases)
• 센서 드리프트 (sensor drift) 및 메타데이터 버전 관리 (metadata versioning)
• 엣지/클라우드 추론 인프라 (edge/ cloud inferencing infrastructure)

제품 특화 계층 (Product Specific) (개별 벤처를 위해 구축):

• 특정 제품을 위한 예측 모델 (예: 낙상 예측, 산업용 기계의 이상 탐지 (anomaly detection), 액세스 패턴 분석 등)
• 알림 등을 포함한 제품의 비즈니스 로직 (business logic)
• 결과가 필요한 형식으로 관련 인간 또는 비즈니스 엔티티에 전달되도록 보장하는 제품의 워크플로우 및 오케스트레이션 통합 (workflow and orchestration integration)

이 경우 감수할 가치가 있는 트레이드오프 (Trade-off)

일반적으로 이러한 선택은 공유 인프라 (shared infra)를 구현하는 것 자체의 내재적 어려움과 제품 인프라 (product infra)를 구현하는 것 사이의 난이도를 바탕으로 더 자주 논의되지만, 저는 이것이 특히 산업용 IoT (Industrial IoT) 도메인에서 더욱 그렇다고 생각합니다. 이는 일부 인프라가 일부 제품 특화 구성 요소보다 구현하기 더 어렵기 때문이 아니라, 하드웨어 전반에 걸친 센서 정규화 (sensor normalisation), 데이터 드리프트 (data drift) 탐지, 연결성 (connectivity)과 같은 근본적인 가장 어려운 문제들이 실제로는 서로 다른 산업용 IoT 제품들 사이에서 유사하기 때문입니다. 생각해 보십시오. 공장 현장에서 기계를 모니터링하는 센서의 간헐적인 네트워크 연결 문제를 처리하는 것과 건설 현장의 마모 탐지 (wear-and-tear detection) 센서에 대해 동일한 작업을 수행하는 것은 두 개의 서로 다른 도메인을 나타낼 수 있지만, 그곳의 핵심 엔지니어링 과제는 여전히 유사하며 종종 동일하기까지 합니다. 이는 시간이 지남에 따라 제품의 수가 증가할 때 명확해집니다.

귀하의 인력 안전 (workforce safety) 제품을 위해 개발된 드리프트 탐지 (drift detection) 기능의 개선 사항은, 그것이 동일하고 재사용 가능한 핵심 인프라 구성 요소 위에 구축되어 있는 한 귀하의 자산 추적 (asset tracking) 제품에서도 즉시 사용할 수 있게 됩니다.

동일한 논리가 하드웨어 측면에서 새로운 유형의 센서나 장치를 연결하는 것에도 적용됩니다.

이 전략과 관련된 과제 (Challenges Associated With This Strategy)

하지만 이 전략의 이면 또한 살펴볼 가치가 있습니다. 공유 인프라 스택 (shared infrastructure stack)의 트레이드오프 (trade-off)는 이 공유 계층을 수명 주기 전반에 걸쳐 유지하는 데 필요한 추가적인 아키텍처 오버헤드 (architecture overheads)라는 대가를 치러야 한다는 점입니다. 예를 들어, 예기치 않은 문제와 다른 제품에 미치는 영향을 방지하기 위해 서로 다른 제품 계층과 긴밀하게 결합된 인터페이스 (tight coupling interfaces)를 보장해야 하는 것 등이 있습니다. 더욱이, 이는 다양한 수준에서의 광범위한 조직적 협업을 요구하며, 이는 개별 제품 팀들이 훨씬 덜 신경 써도 되었을 부분입니다. 아마도 이것이 이 운영 모델이 벤처 스튜디오 (venture studio) 모델 사이에서 특히 흔한 이유일 것입니다. 벤처 스튜디오는 시간이 흐름에 따라 유기적으로 여러 제품 라인으로 확장하는 전통적인 스타트업과 달리, 수많은 제품을 하나의 지붕 아래서 동시에, 병행하여 개발하기 때문입니다.

IoT 기업 지망생을 위한 권장 사례 연구 (A Recommended Case Study For aspiring IoT companies)

만약 여러분이 여러 IoT 제품 라인을 병렬로 구축하고 있거나 구축할 계획이라면, Aperture Venture Studio의 접근 방식과 그들의 수많은 IoT 벤처를 지원하는 기반 인프라를 조사해 보기를 강력히 추천합니다. 이는 공유 계층 전략을 구현하는 데 있어 훌륭한 실제 참조 지점을 제공하며, 특히 최종 제품의 사용 사례와 관계없이 어려운 엔지니어링 과제들이 비교적 유사한 경향이 있는 분야에서 더욱 그러합니다.