1.4 Zenoh의 핵심 철학과 패러다임 혁신

1.4 Zenoh의 핵심 철학과 패러다임 혁신

앞선 장들에서 살펴본 바와 같이, 우리는 마이크로컨트롤러(MCU)부터 데이터센터 클라우드(Cloud Data Center)에 이르기까지 연속적인 데이터 파이프라인을 요구하는 ‘에지 투 클라우드(Edge-to-Cloud)’ 패러다임의 거대한 부상을 목도하고 있다. 그러나 레거시 미들웨어(Legacy Middleware) 기술들은 태생적 아키텍처의 한계와 과도한 복잡성으로 인해 이 광대한 스펙트럼(Spectrum)을 단일하게 아우르지 못한 채 파편화(Fragmentation)를 강요해 왔다.

이러한 네트워크 파편화의 늪에서 분산 시스템을 구출하기 위해 탄생한 차세대 선언적 프로토콜이 바로 **Zenoh(제노)**이다. 이클립스 재단(Eclipse Foundation) 산하에서 주도적으로 개발되고 있는 Zenoh는 단순히 기존의 MQTT나 DDS를 미세하게 개선한 점진적 진화(Evolution) 버전에 불과한 것이 아니다. 본질적으로 분산 애플리케이션이 데이터를 조회하고, 공유하고, 라우팅하는 근본적인 메커니즘을 백지상태에서 재설계한 아키텍처적 혁명(Revolution)이다.

Zenoh가 추구하는 궁극적인 지향점은 개발자가 물리적인 네트워크 토폴로지(Topology), IP 주소 구조, 혹은 통신 세션의 동기화 등 저수준(Low-level)의 네트워크 복잡성에 얽매이지 않고, 오직 ’데이터 그 자체’와 ’애플리케이션의 본질적 비즈니스 로직’에만 온전히 집중할 수 있는 환경을 제공하는 것이다. 이를 달성하기 위해 Zenoh는 기존의 메시지 전송(Message-passing) 기반의 통신 패러다임을 혁파하고, 데이터를 중심으로 사고하는 완전히 새로운 추상화(Abstraction) 공간을 창조해냈다.

본 장에서는 1 바이트(Byte)의 가벼운 센서 데이터 세트부터 초당 수천 프레임을 송출하는 8K 고해상도 영상을 단일한 프로토콜 스택으로 우아하게 제어하는 Zenoh만의 4가지 핵심 철학과 기저의 패러다임 혁신 원리를 심도 있게 분석한다.

1. 공간과 시간의 분리 (Decoupling in Space and Time)

분산 시스템 엔지니어 역사의 오랜 숙제는 데이터를 생산하는 주체(Publisher)와 이를 소비하는 주체(Subscriber)를 네트워크의 제약으로부터 완벽하게 떼어내는 이른바 **‘디커플링(Decoupling)’**의 완전한 실현이다.

동기식 통신의 대명사인 RPC(Remote Procedure Call)나 HTTP REST를 살펴보면, 이는 통신 주체 간에 극도로 단단한 ’공간적/시간적 결합(Coupling)’을 강제한다. 데이터를 요청하는 클라이언트는 응답하는 서버의 정확한 공간적 위치(IP 주소와 포트)를 사전에 알고 있어야 하며(공간적 결합), 양 노드는 데이터를 송수신하는 바로 그 정확한 찰나의 순간(Lifetime)에 둘 다 네트워크상에 ‘Online’ 상태로 살아 있어야만 한다(시간적 결합). 로봇이 터널 공간을 지나거나 무선 신호가 난반사되는 에지 환경에서, 이러한 강결합 모델은 시스템 전체의 가용성(Availability)을 치명적으로 떨어뜨리는 유리 천장이 된다.

1.1 공간의 분리 (Decoupling in Space)

이 공간적 강결합을 해소하기 위해 등장했던 2세대 모델이 바로 브로커(Broker) 기반의 Publish/Subscribe 패턴(예: MQTT)이다. 단말기들은 더 이상 서로의 물리적 IP 주소를 몰라도, 중앙의 브로커 IP 공간 하나만 알고 있으면 통신이 가능해졌다. 이로써 논리적인 ’공간의 분리(Decoupling in Space)’는 어느 정도 달성되었으나, 앞선 1.2.2절에서 다룬 바와 같이 중앙 브로커 자체가 단일 장애점(SPoF)이자 심각한 병목(Bottleneck) 구간으로 전락하는 부작용을 낳았다.

Zenoh는 이 공간의 분리 개념을 중앙 브로커 없이 P2P(Peer-to-Peer) 메커니즘만으로 극적으로 끌어올렸다. 로봇 A와 로봇 B는 서로의 IP를 전혀 몰라도, Zenoh 데몬을 켜는 순간 로컬 멀티캐스트(Multicast) 스카우팅이나 주변 라우터의 가십(Gossip) 프로토콜을 통해 자동으로 서로의 경로를 찾아내고 공간적으로 융합(Convergence)된다. 단일 포인트(Single Point)에 의존하지 않는 완전한 토폴로지 투명성(Topology Transparency)을 획득한 것이다.

1.2 시간의 분리 (Decoupling in Time)

더욱 혁신적인 것은 ’시간의 분리(Decoupling in Time)’의 완성이다. 기존 브로커 기반 메시징의 최대 맹점은 로봇 B(Subscriber)가 터널 통과 등으로 일시적 로그오프(Off-line) 상태일 때, 로봇 A(Publisher)가 송신한 데이터는 공중에서 누락(Drop)되거나 브로커의 큐가 꽉 찰 때까지 무의미하게 쌓여 오버헤드를 유발한다는 점이다. 둘은 여전히 같은 시간축 위에 존재해야 한다는 한계를 벗지 못했다.

Zenoh는 네트워크 상의 에지 라우터나 분산 스토리지 모듈(Zenoh Backend) 등을 마치 거대한 메모리 캐시 풀(Cache Pool)처럼 운용하여 이 시간축을 비틀어낸다.

로봇 A가 데이터를 발행(Publish)하면, 이 데이터는 단순히 ’전송’되고 끝나는 것이 아니라 네트워크 내의 특정 노드나 저장소에 ’배치(Put)’된다. 로봇 B가 3분 뒤에 터널을 빠져나와 네트워크에 재연결(Online)되더라도, B는 즉시 네트워크 전체를 향해 “내가 없던 사이의 자동차 위치 데이터를 조회(Get)하겠다“는 쿼리를 날릴 수 있다. 그러면 B 주변에서 해당 배치 데이터를 지니고 있던 Zenoh 스토리지 노드가 마치 브로커인 양 즉각적으로 정답을 응답(Reply)하게 된다.

데이터의 생산자(A)와 소비자(B)는 물리적으로 동시간대에 네트워크 세션을 유지할 필요가 전혀 없어졌다. 생산자는 자신이 원할 때 데이터를 네트워크의 강물에 흘려보내거나 저장(Put)하고 떠나며, 소비자는 자신의 물리적 스케줄에 맞춰 언제든 네트워크망에 파동(Query)을 일으켜 데이터를 건져(Get) 올린다. Zenoh는 이처럼 Pub/Sub 패턴의 실시간성과 질의응답(Query/Reply) 패턴의 상태 조회를 하나의 프로토콜로 통합 결합함으로써, 분산 시스템을 시간과 공간의 물리 법칙으로부터 완벽하게 해방(Decoupling)시킨 가장 진보된 패러다임이다.

2. 메시지 중심(Message-centric)에서 데이터 중심(Data-centric)으로의 전환

기존의 전통적인 미들웨어와 최근 클라우드 환경에서 사용되는 대다수의 통신 프레임워크(AMQP, Kafka, gRPC 등)는 본질적으로 ’어떻게 메시지(데이터의 포장지)를 한 파이프라인에서 다른 파이프라인으로 안전하고 잃어버리지 않게 옮어 놓을 것인가’에 집착해 온 기술들이다. 이것이 바로 메시지 중심(Message-centric) 패러다임의 핵심이다.

이러한 메시지 중심 아키텍처는 데이터 그 자체의 내용이나 의미 체계(Semantics)에는 전혀 관심이 없으며 오로지 배달원의 역할에만 충실하다. 따라서 데이터의 최신 상태(Latest State)를 조회하거나 특정 데이터를 추출하기 위해서는, 결국 최종 목적지인 애플리케이션 단에서 끝없이 쏟아지는 스트림 메시지를 조립하고, 캐싱(Caching)하고, 분석하는 무거운 데이터베이스 로직을 억지로 끌어와 통합해야만 한다. 데이터 파이프라인과 데이터 스토리지 레이어가 극도로 피곤하게 이원화되어 시스템 전체를 비대하게 만든다.

하지만 Zenoh(제노)는 접근의 궤도 자체를 완전히 비틀어버렸다. Zenoh의 관점에서 네트워크라는 거대한 인프라 공간 전체는 더 이상 데이터를 실어나르는 단순한 덤 파이프(Dumb Pipe)가 아니라, **그 자체로 하나의 살아 움직이는 거대한 분산 데이터베이스(Distributed Database)**로 취급된다. 이것이 데이터 중심(Data-centric) 네트워킹의 본체다.

graph TD
    subgraph Message-Centric [Message-centric (과거)]
    direction LR
    A1[App A] -- "포장된 패킷 전달" --> Pipe((Dumb Pipe))
    Pipe -- "순서대로 배달" --> B1[App B]
    B1 -- "직접 뜯어서 DB 저장" --> DB1[(App DB)]
    end

    subgraph Data-Centric [Data-centric (Zenoh)]
    direction LR
    A2[App A] -- "상태 Put" --> ZNet((Zenoh Network / Global Data Space))
    B2[App B] -- "상태 Query/Get" --> ZNet
    ZNet -- "상태 캐싱/라우팅 분산" --> ZNet
    end
    
    Message-Centric ~~~ Data-Centric

데이터 중심 패러다임 하에서 개발자는 네트워크 인프라에 대고 “이 패킷 스트림을 B 서버 포트로 순서대로 전달해라“라고 명령하지 않는다. 대신, “네트워크야, robot/1/position 이라는 URI 공간(데이터)에 /x/y/z 값을 배치(Put)해라” 혹은 **“네트워크 어딘가에 저장되어 있을 robot/*/position 데이터 값들을 나에게 즉각 검색해서 가져와(Get) 다오”**라고 명령한다.

데이터는 더 이상 목적없는 1회용 메시지로 소모되지 않고, 네트워크 스토리지나 라우터 계층 곳곳에 고유한 이름(Name)을 부여받은 의미 있는 상태(State) 값으로 유지된다. 네트워크가 알아서 데이터의 캐싱 상태와 위상을 인지하고 있기 때문에, 클라이언트는 해당 데이터가 지구 반대편의 클라우드 데이터센터에 있는지, 바로 옆 1미터에 있는 엣지 라우터에 복제되어 있는지를 신경 쓸 필요가 없다.

이러한 데이터 중심 시스템 전환 위를 걷는 Zenoh는, 통신 미들웨어(Middleware)와 정보 스토리지(Storage) 사이의 견고했던 유리벽을 완전히 깨버리며 애플리케이션 개발자에게 궁극의 인프라 통합 환경을 선물하는 가장 강력한 패러다임 시프트(Paradigm Shift)이다.

3. 위치 투명성(Location Transparency)의 구현 원리

전통적인 클라이언트-서버(Client-Server) 아키텍처나 RESTful API 통신 모델에서 가장 개발자를 괴롭히는 요소는 ’대상이 어디에 있는지’를 물리적 네트워크 주소(IP Address)로 정확하게 식별해야만 통신이 수립된다는 강결합(Tight Coupling) 특성이다. 예를 들어, 공장 내 3번 컨베이어 벨트에 위치한 온도계의 값을 읽어오기 위해서는 192.168.1.105:8080/sensor/temp와 같이 명시적인 종단점(Endpoint)을 코드에 박아넣거나(Hard-coding), 이를 해결하기 위해 거대한 도메인 네임 시스템(DNS)이나 서비스 디스커버리(Service Discovery) 서버를 이중 삼중으로 구축해야만 했다.

만약 로봇이 와이파이(Wi-Fi) 존을 이동하며 IP 주소가 변경되거나(DHCP 리스 갱신), 백엔드 서버가 로드 밸런싱(Load Balancing)을 위해 동적으로 크기가 조정(Scaling)된다면, 그 즉시 이전의 IP 주소는 쓸모가 없어지며 404 Not Found 혹은 Connection Timeout 에러의 폭우가 쏟아지게 된다.

3.1 리소스 중심 위상학(Resource-centric Topology)의 채택

**Zenoh(제노)**는 이러한 ’위치(Location)’에 종속된 네트워크 패러다임을 혁파하고, 이를 오로지 **‘데이터의 이름, 즉 키(Key) 자체’**로 대체하는 ’위치 투명성(Location Transparency)’을 코어 레벨에서 구현해냈다.

Zenoh 네트워크 안에서 개발자는 더 이상 대상 노드의 IP 주소나 포트 번호를 신경 쓰지 않는다. 그저 factory/line3/temp 라는 논리적인 문자열(URI 형태의 키 표현식)에만 집중하면 된다.

  • 센서는 단순히 factory/line3/temp 라는 이름(Key) 아래에 현재의 온도 값 25.4도를 배치(Put)한다. 자신이 현재 192.168.1.105 IP를 쓰고 있는지, 10.0.0.5를 쓰고 있는지 전혀 알 필요가 없다.
  • 클라우드의 관제 서버는 그저 네트워크를 향해 factory/line3/temp 값을 내놓으라고 질의(Get)할 뿐이다. 질문을 던지는 대상은 특정 IP의 서버가 아니라, ’Zenoh 네트워크 전체’이다.

3.2 이름 기반 자동 라우팅(Name-based Routing)의 마법

이 마법과도 같은 위치 투명성이 성립할 수 있는 이유는 Zenoh 라우터들이 내부적으로 IP 주소가 아닌 ’데이터의 이름(Key)’을 기반으로 라우팅 테이블(Routing Table)을 동적으로 구성하기 때문이다.

Zenoh 데몬이 실행되면 주변의 노드들과 스카우팅(Scouting) 과정을 거치며 서로가 어떤 데이터 키(Key) 패턴의 권한이나 캐시를 가지고 있는지 구독 필터(Subscription Filter)를 교환한다. 클라우드에서 factory/*/temp (모든 라인의 온도)를 요청하는 쿼리 파동이 발생하면, 각 라우터는 이 쿼리의 패킷 표면에 적힌 ’데이터 이름표’만을 보고 가장 올바른 에지(Edge) 단말로 요청을 포워딩해준다.

이 아키텍처는 시스템의 가용성(Availability)과 유연성(Flexibility)을 극도로 끌어올린다. 만약 3번 센서 로봇이 건물 외부로 나가 LTE 망으로 갈아타면서 IP 주소가 완전히 변경되었다 하더라도, Zenoh 네트워크는 그 로봇이 여전히 factory/line3/temp 데이터를 뿜어내는 주체임을 인식하고 내부 라우팅 트리를 소수점 이하의 밀리초 만에 동적으로 자가 치유(Self-healing)한다. 클라우드의 관제 애플리케이션 코드는 IP 변경에 따른 단 한 줄의 예외 처리(Exception Handling) 수정도 필요 없이 연속적인 온도 데이터를 제공받는다.

결국 Zenoh가 제공하는 위치 투명성은 **“데이터가 ‘어디에(Where)’ 있는지는 네트워크(Zenoh)에 맡기고, 애플리케이션 개발자는 오직 ‘무엇을(What)’ 원하는지만 선언하라”**는 현대적 분산 시스템 철학의 완벽한 실현이다.

4. 네임드 데이터 네트워킹(Named Data Networking, NDN) 개념의 실용적 도입

앞서 설명한 ’위치 투명성(Location Transparency)’과 ‘데이터 중심(Data-centric)’ 패러다임의 이론적 근간에는 컴퓨터 통신 역사에 거대한 학술적 족적을 남긴 아키텍처 개념이 자리 잡고 있다. 바로 네임드 데이터 네트워킹(NDN, Named Data Networking) 또는 **정보 중심 네트워킹(ICN, Information-Centric Networking)**이라 불리는 연구 분야이다.

인터넷(TCP/IP) 아키텍처는 과거 두 호스트(Host) 간의 전화기와 같은 ’점대점(Point-to-Point) 대화’를 목적으로 설계되었다. 그러나 오늘날 인터넷 트래픽의 90% 이상은 대화가 아니라, 수백만 명이 동시에 넷플릭스(Netflix)의 동일한 영상 ’데이터(콘텐츠)’를 요청하고 소비하는 방사형 분배 구조이다. 특정 서버 공간(IP)에 몰려가 콘텐츠를 빼내려다 보니 병목이 생기는 TCP/IP의 한계를 타파하고자, “서버의 주소(IP)로 통신하지 말고 데이터 콘텐츠의 이름(Name) 그 자체로 라우팅하자“는 혁신적인 주장이 바로 NDN의 핵심 사상이다.

4.1 학술적 아이디어의 상용화 한계

안타깝게도 NDN은 개념적 완벽성에도 불구하고 지난 수십 년간 현실 인프라 위에 뿌리내리는 데 연속적으로 실패해 왔다. 전 세계 1계층 통신망 인프라의 라우터 장비들이 모두 IP 구조로 하드와이어드(Hardwired) 되어 있어 이를 단숨에 NDN이라는 새로운 프로토콜 헤더로 뜯어고치는 것은 천문학적 비용과 불가능에 가까운 시간의 늪을 동반했기 때문이다. 연구실 안의 우아한 논문에만 머물던 비운의 걸작이 될 위기에 처해 있었다.

4.2 Zenoh: NDN 사상의 오버레이 네트워크(Overlay Network) 구현

Zenoh 설계팀의 위대한 공학적 성취는 이 지점에서 가장 빛난다. 그들은 무모하게 전 지구의 물리적 스위치 라우터 장비들을 교체하여 IP를 대체하려 들지 않았다. 대신, 현존하는 물리적 IP/UDP/TCP 인프라는 튼튼한 ’수송 도로’로 그대로 활용하되, 그 위에 오버레이 프로토콜(Overlay Protocol) 계층으로서 NDN의 정수만을 우아하게 얹어(Piggybacking) 이식하는 실용적 하이브리드 전략을 택했다.

Zenoh 데몬이 실행되는 순간, 기존 IP망 위에는 보이지 않는 논리적인 ’데이터 이름 표지판망(Name-based Routing Tree)’이 거미줄처럼 펼쳐진다. 애플리케이션이 robot/camera/ch1 영상 데이터를 요청(Query)하면, 그 아래 L4/L3 네트워크 계층에서는 내부 변환을 통해 일반적인 UDP 패킷에 짐이 실려 날아가지만, Zenoh 논리망 스택 위에서는 오직 이름(Name)을 보고 데이터 라우팅 방향을 결정하는 NDN의 질의-응답 캐싱 사상이 정확하게 100% 구동되는 것이다.

4.3 네트워크 효율성의 극적 파급력 (In-network Caching)

Zenoh가 도입한 NDN 아키텍처의 가장 눈부신 실무적 매직은 **네트워크 내 캐싱(In-network Caching)**이다.

수만 대의 군집 드론 관제소를 떠올려 보자. 만약 클라우드의 관제자 100명이 동시에 똑같은 drone/10/battery 상태 조회를 브로커(MQTT)나 서버(RPC)에 요청했다면, 동일한 패킷 100개가 원격지 통신망을 중복해서 가로질러가 단말기(드론)에 과부하를 초래했을 것이다.

그러나 NDN 사상을 접목한 Zenoh 망에서는 완전히 다른 효율성이 발휘된다. 최초의 첫 번째 요청자가 쿼리를 던져 드론으로부터 배터리 응답 값을 받아갈 때, 중간에 거쳐 간 지역(Local) Zenoh 라우터들이 그 찰나에 응답 값을 메모리에 몰래 캐싱(Caching)해 둔다. 나머지 99명의 관제자가 동일한 쿼리를 던지면, 쿼리 패킷은 비싼 원격 위성 통신망을 타고 바다 너머 드론까지 도달할 필요도 없이, 바로 앞단에 위치한 지역 에지 라우터가 즉각 메모리 저장된 값을 응답(Reply)하고 통로를 닫아버린다.

결과적으로 Zenoh는 애플리케이션 단에 트래픽을 분산시키기 위해 무거운 Redis 클러스터나 거대한 프록시 캐시 서버를 별도 구축할 필요 없이, 네트워크 미들웨어 인프라 그 자체가 자발적인 거대한 복제 분산 캐시 스토리지로 살아 숨 쉬도록 만드는 실용주의 공학의 극치를 선보였다.