1.1 Zenoh의 개요와 등장 배경

1.1 Zenoh의 개요와 등장 배경

현대의 소프트웨어 및 하드웨어 시스템은 단일 기기 중심의 독립적 운영 구조에서 벗어나, 초연결성(Hyper-connectivity)을 바탕으로 한 거대한 분산 시스템(Distributed System)으로 진화하고 있다. 사물인터넷(IoT, Internet of Things), 자율주행(Autonomous Driving), 스마트 팩토리(Smart Factory), 그리고 대규모 군집 로보틱스(Swarm Robotics)에 이르기까지, 다양한 이기종(Heterogeneous) 디바이스들이 네트워크를 통해 데이터를 교환하고 실시간으로 상호작용하는 환경이 보편화되었다.

이러한 패러다임의 변화는 네트워크 상에서 데이터를 분배하고 처리하는 통신 미들웨어(Communication Middleware)의 역할과 중요성을 기하급수적으로 증대시켰다. 네트워크의 말단(Edge)에서 방대한 센서 데이터가 폭발적으로 생성되고, 동시에 실시간 제어 명령이 요구되는 상황에서 전통적인 클라이언트-서버(Client-Server) 모델이나 중앙 집중형 브로커(Broker) 아키텍처는 데이터 처리량의 한계와 심각한 지연 시간(Latency) 문제를 노출하게 되었다. 특정한 서버에 의존적인 통신 방식은 단일 장애점(Single Point of Failure)을 낳을 뿐만 아니라, 동적으로 변화하는 네트워크 토폴로지(Topology)에 유연하게 대응하지 못하는 치명적인 단점을 지닌다.

이러한 기술적 한계를 극복하고 차세대 통신 인프라의 새로운 표준을 제시하고자 기획된 프레임워크가 바로 제노(Zenoh)이다. Zenoh는 인터넷 규모(Internet-scale)의 물리적 확장성을 보장하면서도, 마이크로컨트롤러(MCU)와 같은 제한적 자원(Resource-constrained) 환경에서도 완벽히 동작할 수 있도록 극도로 최적화된 데이터 분배 네트워크(Data Distribution Network, DDN) 프로토콜이다.

Zenoh가 지향하는 최우선적인 아키텍처적 목표는 네트워크의 기하학적 형상에 구애받지 않고, 데이터가 위치한 곳(Location)과 데이터가 사용되는 곳을 가장 효율적인 논리적 경로로 묶어내는 데이터 추상화(Data Abstraction) 계층을 제공하는 것이다. 이를 통해 시스템을 설계하는 개발자와 데이터 엔지니어는 데이터가 로컬 네트워크에 존재하는지, 혹은 수천 킬로미터 떨어진 원격 클라우드(Cloud) 서버에 존재하는지 등 물리적 레이어의 복잡성을 고려할 필요 없이, 단일화되고 균일한 통신 의미론(Uniform Communication Semantics)을 사용하여 데이터 구독, 발행, 그리고 분산 쿼리를 수행할 수 있다.

graph TD
    classDef edgeClass fill:#f9f2f4,stroke:#333,stroke-width:1px;
    classDef fogClass fill:#e6f7ff,stroke:#333,stroke-width:1px;
    classDef cloudClass fill:#f4f1f8,stroke:#333,stroke-width:1px;

    subgraph Edge_Level [에지 계층 - 센서 및 액추에이터]
        MCU1[마이크로컨트롤러: 센서 노드]
        MCU2[로보틱스: 액추에이터]
        EdgeGateway[에지 게이트웨이 / 라우터]
    end

    subgraph Fog_Level [포그 컴퓨팅 계층 - 로컬 인프라]
        FogServer1[로컬 엣지 서버]
        FogServer2[로컬 데이터베이스]
    end

    subgraph Cloud_Level [클라우드 계층 - 대규모 데이터 센터]
        CloudVM[클라우드 인프라 아키텍처]
        DataLake[엔터프라이즈 데이터 레이크]
    end

    MCU1 <-->|Zenoh: 저전력 및 초저지연| EdgeGateway
    MCU2 <-->|Zenoh: 실시간 P2P 통신| EdgeGateway
    EdgeGateway <-->|Zenoh: 동적 라우팅 및 상태 동기화| FogServer1
    FogServer1 <-->|Zenoh: 분산 쿼리 및 데이터 집계| CloudVM
    FogServer2 <-->|Zenoh: 백엔드 스토리지 연동| CloudVM
    CloudVM <--> DataLake

    class Edge_Level edgeClass;
    class Fog_Level fogClass;
    class Cloud_Level cloudClass;

위의 아키텍처 도표는 Zenoh가 데이터 발생 지점인 에지(Edge), 중간 처리 및 버퍼링을 담당하는 포그(Fog), 그리고 방대한 데이터의 저장과 대규모 연산을 지원하는 클라우드(Cloud)에 이르는 분산 컴퓨팅 스펙트럼 전체에서 어떻게 심리스(Seamless) 통합 커뮤니케이션 계층을 구축하는지를 시각화한 것이다. Zenoh는 서로 다른 네트워크 도메인 간의 단절을 프로토콜 레벨에서 해소하고, 데이터의 명칭(Named Data)을 통한 데이터 중심(Data-centric)의 일관된 연결망을 완성한다. 이는 특정 응용 분야에 국한되는 한계를 넘어, 데이터 패킷 단위의 초소형 제어 디바이스부터 초대형 엔터프라이즈 서버 망까지 동일한 통신 미들웨어 기반 하에 통합 설계될 수 있음을 증명한다.

본 절에서는 과거의 시스템들이 겪어온 발전 과정 속에서 Zenoh라는 새로운 미들웨어가 탄생하게 된 철학적 기원과, 그것이 차세대 네트워크 분산 시스템에 가져온 본질적인 혁신에 대하여 집중적으로 분석한다. 급변하는 IoT 및 지능형 무인 이동체 생태계에서 겪고 있는 물리적, 구조적 데이터 병목 현상을 짚어보고, Zenoh가 도입한 아키텍처적 철학이 이러한 도메인의 발전에 어떠한 실질적인 기여와 패러다임의 전환을 이룩하고 있는지 구체적인 배경 지식을 확립한다.

1. 차세대 데이터 분산 네트워크(Data Distribution Network)란 무엇인가

차세대 데이터 분산 네트워크(DDN, Data Distribution Network)란 끊임없이 실시간 데이터를 생산하는 퍼블리셔(Publisher)와 이를 필요로 하는 서브스크라이버(Subscriber) 사이에서 위치, 형식, 볼륨에 구애받지 않고 데이터를 매끄럽게 분배 및 동기화하는 진보된 형태의 통신 인프라를 의미한다. 이는 단순한 종단 간 메시지 전달(End-to-End Message Passing) 시스템을 뛰어넘어, 물리적으로 흩어진 분산 컴퓨터 네트워크 전체를 하나의 거대한 가상의 데이터 버스(Virtual Data Bus) 혹은 전역 데이터 공간(Global Data Space)처럼 다룰 수 있게 해주는 고도의 논리적 추상화 계층이다.

1.1 기존 콘텐츠 전송 네트워크(CDN)와의 차별성

과거 웹 2.0 시대를 주도했던 콘텐츠 전송 네트워크(CDN, Content Delivery Network)는 주로 정적 파일이나 예측 가능한 비디오 스트림의 빠른 전달을 목적으로 글로벌 캐싱 서버를 활용하여 다운로드 지연을 줄이는 데 주력했다. 반면, 현대의 데이터 분산 네트워크(DDN)는 센서, 로봇, 자율주행 차량 등에서 동적이고 끊임없이 생성되는 실시간 스트리밍 데이터(Real-time Streaming Data)를 초저지연(Ultra-low Latency)으로 다중 지점(Multi-point)에 분배하는 데 그 초점을 맞추고 있다.

특히 인더스트리얼 4.0(Industrial 4.0)이나 다중 로봇 시스템(Multi-Robot Systems)과 같이 동적인 에지(Edge) 환경에서는 노드들의 물리적 이동에 따른 네트워크 편입과 이탈이 빈번하게 발생하며, 데이터 발생의 진원지 또한 계속해서 이동한다. DDN은 이러한 네트워크 토폴로지(Topology)의 잦은 변화 속에서도 단일 장애점(SPoF, Single Point of Failure)을 극복하고, 동적 라우팅 알고리즘을 통해 1 밀리초(ms) 단위의 결정론적(Deterministic) 통신을 보장하는 것을 목표로 한다.

1.2 이상적인 DDN의 3대 아키텍처적 특성

학술적 및 공학적 관점에서 볼 때 차세대 데이터 분산 네트워크가 필수적으로 갖춰야 할 핵심 아키텍처 특성은 크게 다음 세 가지로 요약된다.

1.2.1 데이터 중심(Data-centric) 아키텍처의 채택

기존의 전통적인 소켓(Socket) 통신 방식은 통신 당사자의 IP 주소나 물리적 식별자(MAC Address 등)를 기반으로 P2P 채널을 형성했다. 반면 DDN은 데이터가 지닌 의미적 이름(Named Data)이나 토픽(Topic)을 기반으로 라우팅이 결정된다. 아래의 다이어그램은 퍼블리셔와 서브스크라이버 간의 강한 결합(Tight Coupling)이 어떻게 공간과 시간의 차원에서 해제(Decoupling)되는지를 보여준다.

sequenceDiagram
    participant Publisher as 센서 노드 (퍼블리셔)
    participant DDN as 데이터 분산 네트워크 (임의의 버스)
    participant Subscriber as 제어 서버 (서브스크라이버)

    Subscriber->>DDN: 관심 데이터 선언 (Subscribe "/robot/telemetry")
    Note over Publisher,Subscriber: 통신 엔티티 간의 물리적 주소를 알 필요 없음 (공간적 분리)
    Publisher->>DDN: 데이터 게시 (Publish "/robot/telemetry", Data: {...})
    DDN-->>Subscriber: 조건에 맞는 데이터 실시간 라우팅 및 전달
    Note over Publisher,Subscriber: 퍼블리셔가 종료된 후에도 캐시된 데이터를 나중에 읽을 수 있음 (시간적 분리)

이러한 분리(Decoupling)는 특정 네트워크 인프라에 장애가 발생하거나 대상 장비의 IP 주소가 변경되더라도 전체 시스템의 논리적인 서비스 연속성을 보장하게 한다.

1.2.2 하이브리드 토폴로지(Hybrid Topology)의 유연한 융합

이상적인 DDN은 피어-투-피어(P2P, Peer-to-Peer) 모델과 브로커(Broker) 모델의 장점을 환경에 맞게 동적으로 전환할 수 있어야 한다. 어떤 애플리케이션은 무선 애드혹 네트워크(MANET, Mobile Ad-hoc Network) 환경에서 중앙 서버 중재 없이 로컬 기기 간 즉각적인 발견(Discovery)과 P2P 통신이 필요하며, 또 어떤 애플리케이션은 대규모 인터넷망을 가로질러 백엔드 스토리지 리소스를 활용하기 위해 라우터(Router) 트리 구조의 개입이 필요하다. DDN은 이 두 가지 이질적인 접근을 하나의 평면(Plane)으로 자연스럽게 융합한다.

1.2.3 지연 시간과 처리량 간의 파레토 최적(Pareto Optimal) 달성

로보틱스 도메인 내에는 극단적으로 대비되는 두 가지 트래픽이 공존한다. 하나는 모터와 액추에이터를 제어하기 위한 크리티컬 제어 명령(Control Command)으로, 대역폭 요구량은 작지만 통신 지연이나 패킷 손실이 치명적인 사고로 직결된다. 다른 하나는 라이다(LiDAR)나 고해상도 카메라 센서가 생산하는 원시 데이터(Raw Data)로 지연보다는 기가바이트(GB) 단위의 막대한 처리량(Throughput) 확보가 중요하다. 차세대 DDN은 단일 프로토콜 패킷 프레임워크 내에서 QoS(Quality of Service) 및 우선순위 큐잉을 통해 이러한 이질적 트래픽을 상호 간섭 없이 동시 다중화(Multiplexing)할 수 있어야 한다.

1.3 결론: DDN의 종착점으로서의 Zenoh

이러한 맥락에서 Zenoh는 차세대 데이터 분산 네트워크의 이상적인 스펙을 가장 현대적이고 파괴적인 방식으로 구현한 프로토콜 기술의 정수이다. 프로토콜 헤더를 1바이트 단위까지 깎아내어 통신 오버헤드(Overhead)를 극단적으로 최소화하였으며, 무거운 IP 의존성 대신 트리 구조 형식의 풍부한 네임스페이스 리소스 식별자(URI)만을 사용하여 데이터에 접근한다.

결론적으로, 차세대 DDN인 Zenoh는 거대한 퍼플릭 클라우드의 엔터프라이즈 환경, 보안이 밀집된 프라이빗 포그(Fog) 인프라, 그리고 전력 소모의 한계에 부딪히는 마이크로컨트롤러 기반의 말단 에지 디바이스들을 이음새 없이(Seamless) 연결하는 강력한 전역 신경망과 고속도로의 역할을 수행하고 있다.

2. IoT 및 로보틱스 생태계의 급격한 변화와 진화

사물인터넷(IoT, Internet of Things) 기술이 인공지능(AI) 및 지능형 무인 이동체(Unmanned Vehicle) 기술과 본격적으로 결합하기 시작하면서, 분산 시스템(Distributed System) 생태계의 물리적 규모와 소프트웨어적 복잡성은 과거와 비교할 수 없을 정도로 급격히 팽창하고 있다. 초기 사물인터넷 환경은 아키텍처 관점에서 볼 때 비교적 단순한 원격 측정(Telemetry) 수집 모델에 불과했다. 주로 온도, 습도, 진동 등을 측정하는 저전력 센서 노드들이 단방향으로 데이터를 중앙 데이터베이스로 전송하고, 주기적인 분석 결과를 바탕으로 애플리케이션 계층에서만 제한적인 피드백을 수행하는 정적(Static) 구조였다.

그러나 오늘날 생태계의 패러다임은 완전히 역동적인 형태로 전환되었다. 수천 대에서 수만 대에 이르는 이기종(Heterogeneous) 디바이스들이 중앙 서버의 일방적인 통제 없이 자율적으로 상호작용하고 스스로 판단하는 거대한 유기체적 분산 시스템으로 진화한 것이다.

특히 로보틱스(Robotics) 도메인에서 이러한 패러다임 전환이 가장 가시적으로 나타나고 있다. 현대의 자율주행 차량(Autonomous Vehicles), 무인 항공기(UAV, Unmanned Aerial Vehicle), 그리고 산업용 협동 로봇(Cobot, Collaborative Robot)들은 더 이상 단일 개체로서 제어되는 1차원적인 차원에 머무르지 않는다. 이들은 다중 로봇 시스템(Multi-Robot Systems)의 형태로 상호 간섭을 최소화하며 군집 제어(Swarm Control)와 고도의 협력 미션(Collaborative Mission)을 동시에 수행하도록 설계되고 있다.

2.1 동적이고 이질적인 데이터의 범람

대표적인 예로 대규모 스마트 물류 창고나 완전 자동화 항만 시스템을 상상해 보라. 수백 대에 달하는 무인 자율 이동 로봇(AMR, Autonomous Mobile Robot)들은 고정된 궤도 없이 작업장 내의 동적 장애물이나 다른 로봇과의 충돌을 실시간으로 회피하며 계속해서 최적의 이동 경로를 재계산(Re-planning)해야만 한다.

이 과정에서 개별 로봇은 환경 인지를 위해 라이다(LiDAR), 밀리미터파 레이다(mmWave Radar), 그리고 고해상도 비전 카메라(Vision Camera) 등의 다중 센서 퓨전(Sensor Fusion) 기법을 활용하며, 기기 1대당 1초에도 수백 메가바이트(MB)에 이르는 막대한 양의 점군(Point Cloud) 및 영상 스트림 데이터를 생산한다. 이와 동시에, 이웃 위치의 로봇들이나 에지(Edge) 구역의 작업 스케줄러와 끊임없이 벤 브로커(Broker)를 통하지 않고 고빈도의 제어 명령(High-frequency Control Command)을 직접 주고받아야 하는 극한의 통신 임무를 띠게 된다.

graph TD
    classDef robotClass fill:#e6f7ff,stroke:#333,stroke-width:1px;
    classDef edgeClass fill:#fff2e8,stroke:#333,stroke-width:1px;

    subgraph "Swarm Robotics Environment (AMR)"
        AMR1[AMR 1: 텔레메트리 & 라이다 Data]
        AMR2[AMR 2: 네비게이션 & 제어 명령]
        AMR3[AMR 3: 비전 센서 스트림]
        AMR4[AMR 4: 협업 미션 상태]
    end

    subgraph "Edge Infrastructure"
        EdgeScheduler[에지 작업 스케줄러]
        LocalDB[로컬 궤적 저장소]
    end

    AMR1 <-->|P2P 실시간 장애물 회피 (초저지연)| AMR2
    AMR2 <-->|P2P 협력 제어| AMR3
    AMR3 <-->|P2P 경로 공유| AMR4
    
    AMR1 -.->|상태 보고 (다중화)| EdgeScheduler
    AMR4 -.->|상태 보고 (다중화)| EdgeScheduler
    EdgeScheduler <--> LocalDB

    class AMR1,AMR2,AMR3,AMR4 robotClass;
    class EdgeScheduler,LocalDB edgeClass;

위의 AMR 간 군집 제어 다이어그램에서 보듯이, 디바이스들이 능동적으로 데이터를 발생시키는 동시에 다른 피어(Peer)의 데이터를 실시간으로 소비하는 생산 및 소비의 주체가 되었다. 로봇이나 사물이 물리적으로 이동함에 따라 무선 통신망의 토폴로지가 시시각각 변화하는 모바일 애드혹 네트워크(MANET, Mobile Ad-hoc Network) 환경이 열리게 된 것이다.

2.2 컴퓨팅 자원 스펙트럼의 극단적 양극화

기존 클라이언트-서버(Client-Server) 중심의 통신 구조는 이 역동적인 환경을 수용하기에 너무 무겁고 경직되어 있다. 특정 고정 IP 주소에 의존하거나, 모든 트래픽이 중앙의 단일 브로커(Broker) 노드를 거쳐야만 하는 통신 방식은 물리적인 네트워크 홉(Hop)을 추가하여 심각한 병목(Bottleneck) 현상과 불필요한 레이턴시(Latency)를 발생시킨다. 로보틱스 인프라에서 단 1 밀리초(ms)의 통신 단절이나 제어 반환 지연은 곧 로봇 간의 파괴적인 물리적 충돌이나 치명적인 인명 사고로 직결될 수 있는 매우 중대한 문제이다.

더불어 분산 컴퓨팅 자원의 극심한 양극화 현상 역시 현대 생태계 진화의 중요한 특징이다. 최상단의 클라우드(Cloud)와 에지 서버(Edge Server)는 가상화 기술을 바탕으로 점점 거대한 연산 능력과 방대한 스토리지(Storage)로 무장하고 있는 반면, 가장 밑단의 IoT 단말이나 마이크로컨트롤러(MCU, Microcontroller Unit)들은 여전히 전력 소비를 극도로 최소화하고 단가를 낮추기 위해 수십 킬로바이트(KB) 수준의 극히 한정적인 메모리 자원만을 운용하는 제약 조건(Condition of Constraint)을 안고 있다.

결과적으로, 이토록 이질적인(Heterogeneous) 하드웨어 스펙트럼 위에서 거대하고 예측 불가하게 움직이는 초연결 생태계를 뒷받침하기 위해서는 무거운 전통적 IT 미들웨어를 완전히 대체할 혁신적인 분산 통신 프레임워크가 요구되었다. 네트워크 단절과 연결이 수시로 반복되는 환경에서도 실시간으로 라우팅 경로를 자체 복원하고, 중앙 서버의 통신 릴레이이나 오버헤드(Overhead) 없이 피어 간의 신속한 의사소통(Peer-to-Peer Communication)을 완벽하게 보장해야 한다는 시장의 절대적인 요구가 형성되었고, 이는 Zenoh 프로토콜의 설계 근간을 이루는 핵심 배경이 되었다.

3. 데이터 폭증 시대의 네트워크 대역폭 한계와 지연 문제

정보 통신 기술(ICT, Information and Communications Technology)의 발전 역사상 전례 없는 데이터 폭증(Data Explosion)의 시대를 맞이하면서, 과거의 유산인 클라이언트-서버 기반 네트워크 아키텍처가 지닌 물리적 및 구조적 한계가 최신 시스템 성능과 경제성을 크게 저해하는 심각한 병목(Bottleneck)으로 작용하고 있다. 학계와 산업계의 통계에 따르면, 해마다 전 세계적으로 생산되는 디지털 데이터의 총량은 제타바이트(Zettabyte) 단위를 가볍게 경신하며 기하급수적으로 폭증하고 있다. 이러한 데이터 쓰나미(Data Tsunami)의 주된 발원지는 인터넷의 중심부가 아니라, 네트워크의 가장 말단(Edge)에서 동작하는 수십억 대의 스마트 센서, 자율주행 차량, 소형 드론, 그리고 지능형 산업용 로봇들이다.

하지만 지능형 데이터의 발원지가 네트워크 말단(Edge)으로 완전히 이동했음에도 불구하고, 대다수의 레거시 시스템 아키텍처는 여전히 생성된 모든 원시 데이터(Raw Data)를 중앙의 클라우드 데이터 센터(Cloud Data Center)로 전송하여 무거운 후속 연산을 수행하고 그 결과를 다시 분배하는 전통적인 클라우드 집중형 방식을 무비판적으로 답습하고 있다. 이러한 낡은 데이터 스트리밍(Data Streaming) 및 처리 파이프라인은 필연적으로 다음의 두 가지 치명적인 공학적 한계 상황을 초래한다.

3.1 네트워크 대역폭(Network Bandwidth)의 물리적 고갈

첫 번째 한계는 네트워크 대역폭(Network Bandwidth)의 물리적 고갈과 무의미한 인프라 투자 비용의 낭비이다.

예를 들어, 한 대의 완전 자율주행 차량(Level 4 Autonomous Vehicle)은 다수의 3D 라이다(LiDAR), 고주파 레이다(Radar), 그리고 4K 해상도의 서라운드 비전 카메라(Surround Vision Camera)를 다중으로 탑재하여, 차량 1대당 초당 기가바이트(GB/s) 단위에 육박하는 거대한 센서 스트림 데이터를 쉴 새 없이 생성한다. 만약 단일 스마트 시티(Smart City) 구역 내에 수천 대의 자율 주행 모빌리티가 동시에 모든 텔레메트리(Telemetry) 원본 데이터를 중앙 서버로 전송하려 시도할 경우, 5G와 같은 최신 이동통신망이라 할지라도 무선 기지국과 백본망(Backbone Network)의 최대 수용 대역폭은 불과 수 초 만에 포화 상태(Saturation)에 이르게 된다.

graph TD
    classDef edgeClass fill:#fff2e8,stroke:#333,stroke-width:1px;
    classDef cloudClass fill:#f4f1f8,stroke:#333,stroke-width:1px;

    subgraph "Legacy Cloud-Centric Architecture"
        Device1[자율주행차 1: 센서 스트림 1GB/s]
        Device2[자율주행차 2: 센서 스트림 1GB/s]
        DeviceN[자율주행차 N: 센서 스트림 1GB/s]
        
        Gateway[로컬 무선 기지국 / 스마트 톨게이트]
        Cloud[중앙 클라우드 데이터 센터]
        
        Device1 -->|Upstream: 대용량 트래픽| Gateway
        Device2 -->|Upstream: 대용량 트래픽| Gateway
        DeviceN -->|Upstream: 대용량 트래픽| Gateway
        
        Gateway -->|백본망 대역폭 포화 / 트래픽 잼| Cloud
        Cloud -.->|Downstream: 제어 명령 지연 발생| Device1
    end
    
    class Device1,Device2,DeviceN edgeClass;
    class Cloud cloudClass;

더욱 치명적이고 비효율적인 사실은, 이처럼 힘들게 전송된 거대한 데이터 스트림 중에서 실제 로컬 환경의 자율적 의사 결정(예: 전방 10미터 앞 갑작스러운 보행자 난입에 따른 긴급 제동)에 즉각적으로 유의미한 가치를 지닌 정보는 1% 미만의 극히 일부분에 불과하다는 점이다. 데이터를 발생지와 격리된 수백 킬로미터 밖의 클라우드 공간으로 무작정 밀어내는 아키텍처는 막대한 트래픽 과금과 무의미한 클라우드 스토리지 비용을 초래하게 된다.

3.2 제어 피드백 루프(Control Feedback Loop)에서의 레이턴시 위반

두 번째 한계는 엄격한 레이턴시(Latency, 지연 시간)의 위반과 이에 따른 제어 시스템의 붕괴이다.

인터넷 규모(Internet-scale)의 범용적인 통신망은 기본적으로 통신의 완료만을 목표로 하는 베스트 에포트(Best-Effort) 전송 방식을 취하므로, 패킷의 릴레이 라우팅 경로와 물리적 도착 시간을 완벽하게 확정(Deterministic)할 수 없다. 산업용 다관절 로봇 팔의 고속 정밀 모션 제어나 멀티로터 무인 항공기의 실시간 자세 제어(Attitude Control)와 같은 하드 리얼타임(Hard Real-time) 시스템에서는, 센서에서 환경의 변화를 감지하고, 연산 유닛에서 보상 명령을 생성하여, 액추에이터(Actuator)로 하달되기까지의 루프가 대체로 1 밀리초(ms) 단위의 극히 짧은 데드라인 안에 반드시 완료되어야만 수학적으로 모델링된 안정성(Stability)을 확보할 수 있다.

그러나 주요 제어 명령을 파생시키는 로직이 원거리에 위치한 인터넷상의 중앙 브로커(Broker)나 클라우드를 경유해야 한다면 어떠한 결과가 발생하겠는가? 수백 킬로미터에 이르는 광케이블의 물리적 전파 지연(Propagation Delay), 다수의 네트워크 스위치 장비에서 필연적으로 발생하는 큐잉 지연(Queueing Delay), 그리고 페이로드 대비 지나치게 무거운 HTTP나 TCP/IP 프로토콜 헤더를 직렬화(Serialization) 및 역직렬화(Deserialization)하기 위해 소모되는 연산 오버헤드가 눈덩이처럼 누적된다. 결국 허용 한계치를 초과하는 응답 지연 시간이나 들쭉날쭉한 네트워크 지터(Jitter)는 제어 시스템 전체의 비선형적 발산이나 치명적인 기계적 충돌 사고를 야기하게 된다.

3.3 구조적 혁신의 필연성

결론적으로 데이터 폭증의 시기에 물리적 대역폭의 한계를 효율적으로 극복하고 크리티컬한 실시간성의 원칙을 지켜내기 위해서는, 수동적으로 대역폭 증설에만 의존하는 1차원적 접근으로는 역부족이다.

데이터가 존재하는 물리적 근원지 주변, 즉 에지(Edge) 인프라에서 즉각적으로 연산과 데이터 필터링(Data Filtering)을 수행하고, 중앙 클라우드 노드의 불필요한 개입 없이 같은 공간 내의 기기 간 최단 경로의 피어-투-피어(P2P) 네트워킹을 보장하며, 프로토콜 헤더의 낭비를 제로 오버헤드(Zero Overhead) 구조로 압축하는 ’구조적이고 근본적인 아키텍처 혁신’이 필요해졌다. 바로 이러한 복합적이고 한계에 다다른 산업계의 갈증이 Zenoh(제노)라고 하는 초경량 차세대 통신 프로토콜이 분산 네트워크 시장에 필연적으로 등장할 수밖에 없었던 최적의 기술적 토양이 되었다.