1.23 데이터 전송 및 데이터 저장 통합 관리 비전

1. 통신과 저장소의 이분법적 구조 탈피

전통적인 소프트웨어 아키텍처에서는 통신 네트워크를 흐르는 ’이동 중인 데이터(Data in Motion)’와 데이터베이스에 쌓여 있는 ’저장된 데이터(Data at Rest)’를 다루는 기술 스택이 완전히 분리되어 있었다. 애플리케이션 개발자는 실시간 데이터 전송을 위해 메시지 브로커(MQTT, Kafka 등)를 구성해야 했고, 과거의 데이터 로그나 정적인 상태 값을 조회하기 위해 별도의 수단(SQL, REST API 등)으로 백엔드 데이터베이스에 접근해야만 했다.

이러한 이분법적 시스템은 엣지 컴퓨팅(Edge Computing) 환경에서 데이터 정합성(Consistency) 유지의 어려움을 유발하고, 이중화된 클라이언트 라이브러리로 인해 애플리케이션을 무겁게 만드는 근본적인 원인이 되었다. 이러한 불필요한 복잡도를 제거하고자, 데이터 중심 네트워킹(Data-Centric Networking)을 실현하는 과정에서 데이터 전송과 저장을 단일 프로토콜로 통합하려는 원대한 비전이 탄생했다.

2. 쿼리어블(Queryables)과 통합된 라우팅 패러다임

Zenoh 아키텍처는 발행/구독(Pub/Sub) 모델의 실시간 배포 트리와 질의/응답(Query/Reply) 모델을 동일한 키 표현식(Key Expression) 기반 하에 네이티브하게 통합함으로써 이 비전을 현실화했다.

네트워크 상의 특정 노드가 Zenoh의 쿼리어블(Queryables) 기능을 이용해 자신이 특정 데이터 블록(예: 센서 히스토리)을 관장함을 선언하면, 애플리케이션은 해당 데이터가 로컬 스토리지에 있는지, 지리적으로 분산된 원격 서버(Geo-distributed Storages)에 있는지 알 필요 없이 셀렉터(Selector)를 통해 즉각 질의할 수 있다. 라우터(Router)는 실시간으로 구독자에게 데이터를 푸시(Push)하는 배포 알고리즘과 동시에, 쿼리를 적절한 데이터 보유자에게 라우팅하여 풀(Pull) 방식으로 응답을 끌어오는 두 가지 역할을 유기적으로 수행한다.

3. 플러그 가능한 스토리지 매니저와 연속성의 완성

이러한 통합 관리 체계를 더욱 강력하게 만드는 것은 Zenoh에 내장된 고성능 스토리지 매니저(Storage Manager)이다. 이 매니저는 프로토콜 스택과 느슨하게 결합되어 플러그인 형태로 동작하며, RocksDB, InfluxDB, PostgreSQL 등 다양한 백엔드(Backends) 데이터베이스 트레이트(Trait)를 즉각 지원한다.

따라서 네트워크를 통해 발행되는 데이터들은 별도의 ETL 파이프라인이나 로그 수집 에이전트 없이도 라우팅 계층의 설정에 따라 투명하게 영구 저장(Data Persistence)된다. 나아가 이러한 시스템 구조는 복제(Replication)와 샤딩(Sharding) 같은 고급 분산 데이터베이스 메커니즘을 네트워크 수준의 라우팅 알고리즘으로 위임하는 혁신을 낳았다.

결과적으로 Zenoh가 제시하는 통합 비전은 데이터 전송의 제로 오버헤드(Zero Overhead)와 저장소 접근의 단위적 위치 투명성을 완벽하게 조화시켜, 클라우드에서 마이크로컨트롤러까지(Cloud-to-Microcontroller Continuum) 이어지는 거대 분산 시스템의 아키텍처 설계 복잡성을 획기적으로 낮추는 결정적인 이정표가 되었다.