2.1 Zenoh 아키텍처 개요

기존 통신 미들웨어(Middleware) 체증의 역사를 극복하고 탄생한 **Zenoh(제노)**의 강력함은 단순히 코드를 최적화하여 얻어낸 산물이 아니다. 이는 데이터를 유통하고 보관하는 근본적인 아키텍처(Architecture)의 기반 구조를 백지상태에서 완전히 새롭게(Clean-slate) 설계한 데서 기인한다.

네트워크 파이프라인 상에 존재하는 데이터 프레임을 단순 전송 타깃으로 보지 않고, 네트워크 전체에 걸쳐 생동하는 영속적 ’리소스(Resource)’로 취급하는 Zenoh의 아키텍처는 공간(Space)과 시간(Time)의 결합이라는 전례 없는 패러다임을 확립했다. 마이크로컨트롤러(MCU)부터 데이터센터 클라우드(Cloud)까지를 단일한 통신 규약으로 엮어내는 이 압도적인 유연성은, 고도로 모듈화된 계층형 프로토콜 층(Protocol Layers)과 어떠한 형태의 위상학(Topology) 환경에서도 스스로 생존로를 개척하는 다변형(Polymorphic) 라우팅 엔진에 의해 뒷받침된다.

본 장에서는 Zenoh 프로토콜의 골격을 구성하는 데이터 중심(Data-Centric) 철학의 공학적 기저를 시작으로, 물리적 네트워크 인프라 위에서 활약하는 노드(Node)들의 역할, 그리고 파편화된 통신 패턴과 저장소(Storage)를 하나의 글로벌 인터페이스(Global Interface)로 매끄럽게 흡수해내는 Zenoh 아키텍처의 심장부를 해부해 본다.

1. 데이터 중심(Data-Centric) 네트워킹 철학과 설계 목표

현대 분산 시스템의 네트워크 트래픽 구조를 면밀히 분석해보면, 정보의 생산자와 소비자 간의 관계는 더 이상 일대일(1:1) 점대점(Point-to-Point) 단방향 통신에 국한되지 않는다. 센서가 방출한 단일 프레임의 데이터는 동시에 침입 탐지 시스템, 실시간 대시보드 모니터, 그리고 영속적 시계열 데이터베이스(Time-Series Database)라는 다수의 이질적인 엔드포인트(Endpoint)로 동시다발적으로 흘러들어가야 한다.

이러한 N:M의 복잡한 통신 매트릭스 속에서, 종래의 IP 기반 호스트 중심(Host-Centric) 라우팅 모델은 명백한 한계를 드러낸다. 데이터를 요청하는 애플리케이션은 데이터를 보유한 대상 호스트(Host)의 정확한 물리적 IP 주소와 통신 포트(Port)를 미리 숙지해야만 비로소 통신 파이프라인을 열 수 있었다.

1.1 ’어디(Where)’에서 ’무엇(What)’으로의 관점 전환

Zenoh(제노) 설계팀의 가장 눈부신 통찰은 라우팅의 기준점을 ’데이터의 위치(Where)’가 아닌 ‘데이터의 본질(What)’ 자체로 완전히 전환한 데 있다. 이는 네임드 데이터 네트워킹(Named Data Networking, NDN)과 정보 중심 네트워킹(Information-Centric Networking, ICN)의 가장 진보적인 학술적 개념을 산업계 미들웨어에 성취스레 안착시킨 결과물이다.

Zenoh 아키텍처에서는 IP 주소라는 망령을 쫓아다니지 않는다. 네트워크 망 위를 떠다니는 모든 정보 조각은 철저하게 **‘이름(Name, Key Expression)’**으로 식별된다. 애플리케이션 개발자는 factory/robot_arm/joint/angle이라는 고유한 리소스 명칭만을 선언(Declare)함으로써 쿼리를 발행하거나 데이터를 구독한다. 이렇게 선언된 데이터 중심적 의도(Intent)는 하위의 물리적 TCP/UDP 레이어의 복잡성을 완전히 추상화(Abstraction)시켜버린다. 데이터를 실제로 보유한 생산자가 센서 말단에 있든, 중간 에지 라우터의 캐시(Cache) 메모리에 잠들어 있든, 그것은 전적으로 분산 지능을 지닌 Zenoh 통신망이 스스로 해석하고 추적할 몫이 된다.

1.2 Zenoh 아키텍처의 3대 설계 목표

데이터 중심 생태계를 온전한 형태로 구동하기 위해 Zenoh 코어 아키텍처는 다음의 실천적 목표를 정조준하여 설계되었다.

1. 지능적인 인-네트워크(In-Network) 라우팅: 거대한 이름(Name) 공간을 효율적으로 필터링하고 목적지를 산출한다. 와일드카드(* 혹은 **)가 포함된 계층적 요청이 발동되었을 때, 응용 단까지 트래픽을 올려보내지 않고 라우터 계층망 내부에서 데이터를 병합(Aggregation)하거나 필터링하여 불필요한 네트워크 대역폭 소모를 극적으로 차단한다.
2. 이동(Motion)과 정지(Rest) 상태 데이터의 단일 인터페이스 통합: 데이터가 소켓(Socket) 위를 흘러가는 과정(Data-in-Motion)이든 비활성 잉여 상태로 스토리지에 적재된 상태(Data-at-Rest)이든 사용자 측에서는 동일한 로직(Read/Write, Pub/Sub)으로 제어할 수 있는 궁극의 추상화 층을 제공한다.
3. 토폴로지 독립성과 동적 결합(Dynamic Coupling): 중앙 브로커(Broker)나 마스터 노드에 의존하지 않고 각 클라이언트 피어(Peer) 노드들이 능동적으로 디스커버리(Discovery)를 수행하여, 네트워크 붕괴나 단절 환경 속에서도 스스로 우회로를 형성하는 P2P 유연성을 확보한다.

결과적으로 Zenoh의 데이터 중심 아키텍처 철학은, 개발자가 “이 데이터를 ‘어떤 IP 서버’로 보내야 하는가?“라는 인프라적 제약 조건에서 영원히 해방시키고, 오직 “이 데이터의 ‘이름’은 무엇이며 어떤 가치를 지니는가?“라는 진정한 비즈니스 로직에만 몰두할 수 있게 해주는 거대한 해방구(Sanctuary)를 선사한다.

2. 클라우드-투-마이크로컨트롤러(Cloud-to-Microcontroller) 통합의 확장성

분산 컴퓨팅 네트워크의 양극단에는 서로 완전히 상반된 컴퓨팅 제약을 가진 두 세계가 존재한다. 한쪽 끝에는 테라바이트(TB) 단위의 메모리와 무제한에 가까운 연산 능력을 자랑하는 데이터센터 클라우드(Cloud)가 버티고 있으며, 정확히 반대편 끝에는 고작 수 킬로바이트(KB)의 메모리와 동전 배터리 하나로 수년을 버텨야 하는 제약의 끝판왕, 마이크로컨트롤러(MCU)가 매달려 있다.

통신 아키텍처 관점에서 이 거대한 스펙트럼(Spectrum)을 단일 프로토콜로 통합하려는 시도는 공학적 딜레마(Dilemma)였다. 클라우드에 적합한 HTTP/gRPC나 DDS(Data Distribution Service)와 같은 무거운 미들웨어 스택을 8비트(Bit) 기반의 센서 노드에 욱여넣는 것은 물리적으로 불가능하다. 반대로 MCU에 최적화된 CoAP와 같은 초경량 프로토콜을 백엔드 관제 서버들의 코어 통신망으로 사용하기에는 그 기능성과 확장성이 턱없이 부족했다. 그 결과, 산업계는 필연적으로 에지 게이트웨이(Edge Gateway) 단위에서 서로 다른 통신 패킷을 번역하고 짐을 다시 꾸리는 기형적인 다중 병목 아키텍처를 양산해 냈다.

2.1 극단적 스케일 다운(Scale-down): Zenoh-Pico

Zenoh(제노) 코어 아키텍처는 프로토콜의 복잡도를 동적으로 덜어내는(Scale-down) 타협 없는 모듈화 설계를 통해 이 난제를 정면 돌파했다.

Zenoh의 와이어 프로토콜(Wire Protocol)은 그 자체로 극단적인 페이로드(Payload) 최적화를 지원한다. 헤더오버헤드(Header Overhead)가 최소 4바이트(Byte) 수준까지 압축될 수 있으며, 이는 배터리로 구동되는 저전력 무선 통신망(LPWAN) 환경에서조차 패킷 드롭(Packet Drop) 없이 데이터를 전송할 수 있는 임계점 미만의 크기를 유지한다.

특히, Zenoh 재단은 MCU 및 임베디드(Embedded) 펌웨어 환경을 완벽하게 겨냥하여 표준 C 언어로 작성된 순정(Native) 라이브러리인 Zenoh-Pico 프로젝트를 출범시켰다. 운영체제(OS)의 도움이나 스레드(Thread)는 물론, 동적 메모리 할당(Dynamic Memory Allocation, malloc)조차 지원하지 않는 열악한 베어메탈(Bare-metal) 환경에서도 Zenoh-Pico는 제약 조건 없이 동작한다.

결과적으로 지구 반대편 데이터센터에서 구동되는 수십 기가바이트(GB) 짜리 Rust 기반의 Zenoh 코어 라우터와, 공장 현장의 쇳물 온도 센서에 장착된 30KB짜리 Zenoh-Pico 클라이언트 노드는 어떠한 프록시(Proxy)나 트랜슬레이터(Translator)의 개입 없이, 완벽하게 동일한 선언적 분산 API를 사용하여 네이티브(Native)하게 대화하게 된다. 이는 현대 시스템 아키텍트들이 그토록 갈망하던 진정한 ’클라우드-투-마이크로컨트롤러(Cloud-to-Microcontroller) 연속성(Continuum)’의 완성이다.

3. 공간(Space)과 시간(Time)의 결합: Data in Motion과 Data at Rest의 단일화

기존 정보통신 공학의 멘탈 모델(Mental Model)에서 네트워크 통신과 데이터베이스 스토리지는 물과 기름처럼 섞일 수 없는 파이프라인의 양극단에 존재했다. 네트워크 기술자들은 랜선 위를 맹렬하게 질주하는 ’이동 중인 데이터(Data in Motion)’의 스루풋(Throughput) 개선에만 집착했고, 데이터베이스 기술자들은 디스크에 차갑게 굳어버린 ’정지된 데이터(Data at Rest)’의 인덱싱(Indexing)에만 몰두했다.

이는 결과적으로 응용 계층의 개발자들에게 두 겹의 이중고를 강요했다. 살아 숨 쉬는 현재 상태 데이터를 가져오기 위해서는 WebSocket이나 MQTT 기반의 구독(Subscribe) 코드를 작성해야 했고, 불과 5초 전의 히스토리 데이터를 열람하기 위해서는 SQL 커넥션을 맺어 SELECT 쿼리를 날려야 했다.
애플리케이션은 파편화된 공간(현재, 네트워크)의 상태와, 굳어버린 시간(과거, 스토리지)의 상태를 각각 다른 언어와 문법으로 긁어모아 수동으로 조립하는 혼돈의 도가니(Melting Pot)로 전락했다.

3.1 Zenoh 라우터: 네트워크 노드를 스토리지 마름모로 변형하다

**Zenoh(제노)**의 설계 목표 중 가장 파괴적이고 심미적인 혁신은 바로 이 공간(네트워크)과 시간(스토리지)의 절대적인 결합이다.

Zenoh 아키텍처의 세계관에서 데이터베이스나 타임시리즈(Time-Series) 캐시 엔진은 네트워크의 영구적인 종착지가 아니다. 이들은 단지 네트워크 평면(Global Data Plain) 상에 일시적으로 플러그인(Plug-in)되어 시간을 지연시키는 특별한 Zenoh 노드(Node)의 일종일 뿐이다.
개발자가 1.7.3장에서 다루었던 백엔드(Backend) 시스템(예: RocksDB, InfluxDB)을 Zenoh 라우터에 플러그인으로 마운트하는 순간, 해당 스토리지는 거대한 Zenoh망의 일부분으로 완벽하게 용해(Dissolve)된다.

• Data in Motion (공간적 접근): 애플리케이션 피어(Peer)가 sensor/+/temp 리소스를 구독(Subscribe)하면, 그 순간 세상 어딘가에서 다른 피어가 발행(Publish)하는 뜨거운 실시간 스트림 데이터들이 네트워크 공간을 가로질러 즉시 도착한다.
• Data at Rest (시간적 접근): 동일한 애플리케이션 피어가 동일한 sensor/+/temp 리소스를 질의(Query, 쿼리)하면, Zenoh 네트워크 망은 지능적으로 라우터 내부에 마운트되어 있는 스토리지 백엔드(데이터베이스)로 접근해 과거의 ‘정지된’ 역사적 데이터를 발굴하여 끄집어낸다.

이 압도적인 아키텍처의 백미는, 이 모든 과정에서 애플리케이션은 데이터가 현재 물리적인 구리선 위에 흐르고 있는지(Motion), 물리적인 SSD 디스크 위에 적재되어 있는지(Rest) 아키텍처적으로 구분할 필요조차 없다는 점이다. 하나의 통합된 선언적 인터페이스(Declarative Interface)와 단일한 이름 공간(Namespace) 통제 규약만으로, Zenoh는 공간을 관통하는 통신과 시간을 관통하는 스토리지를 우아하고 투명하게 결속시킨 최초의 시공간 통합 미들웨어 문법을 완성시켰다.

4. 기존 미들웨어(DDS, MQTT, ROS/ROS2 기본 통신) 구조와의 비교 분석

Zenoh(제노) 아키텍처의 우위성을 객관적으로 증명하기 위해서는, 지난 십수 년간 산업 표준으로 활약해 온 레거시(Legacy) 미들웨어들의 뼈대 구조와 Zenoh 라우팅 엔진 간의 구조적 결함 및 해법을 대조(Contrast)해보는 과정이 필수적이다. 현존하는 분산 시스템은 크게 MQTT와 같은 브로커(Broker) 중심의 퍼블리시/서브스크라이브(Pub/Sub) 모델, 그리고 DDS(Data Distribution Service)와 같은 브로커리스(Broker-less) P2P 모델로 양분된다.

4.1 MQTT 아키텍처의 중앙 집중적 병목(SPoF) 한계 초월

MQTT는 가벼운 프로토콜 헤더(Header)를 무기로 IoT 생태계를 장악했으나, 그 아키텍처 코어에는 치명적인 약점인 **중앙 집중형 브로커(Broker)**가 존재한다. 모든 클라이언트 노드는 브로커의 IP 주소를 알고 있어야 하며, 데이터의 발행과 구독이 무조건 브로커를 거쳐야만 한다. 이는 데이터 경로(Data Path)의 불필요한 우회로(Trombone Routing)를 생성하고, 브로커가 다운되는 순간 전체 망이 마비되는 **단일 실패 지점(Single Point of Failure, SPoF)**을 강제한다.

반면 Zenoh는 특정 중앙 허브에 의존하지 않는 분산 라우팅(Distributed Routing) 엔진을 기본 채택한다. 트래픽의 밀집도와 물리적 거리에 따라 에지 라우터들이 동적으로 그물망(Mesh Topology)을 형성하며, 특정 라우터가 소멸하더라도 인접 피어(Peer) 노드들이 즉각적으로 대안 경로(Alternative Path)를 산출해 내는 자가 치유(Self-healing) 아키텍처로 무장했다.

4.2 DDS 아키텍처의 스케일링(Scaling) 및 디스커버리(Discovery) 폭주 억제

DDS는 브로커가 없는 완벽한 P2P 통신망과 강력한 QoS(Quality of Service) 컨트롤을 제공하여 국방 및 ROS 2 생태계의 패권을 잡았다. 하지만 노드 수가 수백, 수천 개로 스케일 업(Scale-up)될 때, 각 노드들이 네트워크상의 다른 모든 노드를 탐색하기 위해 살포하는 디스커버리 멀티캐스트 트래픽(Discovery Multicast Traffic)의 폭주(Broadcast Storm) 현상이 전체 대역폭을 갉아먹는 치명적인 스케일링 이슈를 겪어왔다. Wi-Fi와 같은 불안정한 무선 환경에서는 이 디스커버리 패킷 자체가 손실되어 통신이 영구 단절되는 현상이 빈번했다.

Zenoh는 완전한 분산 P2P 통신 스택에 **가십 프로토콜(Gossip Protocol)**과 **라우팅 트리(Routing Tree)**의 장점을 결합한 하이브리드(Hybrid) 디스커버리 체계를 융합하여 이 난제를 종식시켰다. 수천 대의 드론 스웜(Swarm) 환경에서도, Zenoh 라우터는 각 피어들에게 전체 디스커버리 브로드캐스팅을 강요하지 않고 라우팅 테이블(Routing Table)을 효율적으로 요약 및 병합하여 전파한다. 이로 인해 트래픽 오버헤드는 O(N²)가 아닌 O(N) 혹은 그 이하 수준으로 극적으로 억제되며, Wi-Fi 및 저대역폭 환경에서도 노드의 생사(Life Cycle)를 완벽히 통제할 수 있게 되었다.

요컨대, Zenoh 아키텍처는 MQTT가 가진 ’가벼움’의 미학을 극대화하면서도, 중심을 파괴하여 SPoF를 도려냈고, DDS가 추구한 P2P 통신의 ’직결성’을 유지하면서도 치명상이었던 디스커버리 오버헤드를 가지치기한, 현존 미들웨어 공학의 정반합(正反合) 그 자체라 할 수 있다.