2.2 네트워크 노드 유형 및 아키텍처 역할

Zenoh(제노)는 단일한 소프트웨어 바이너리(Binary)나 한 가지 형태의 통신 주체만을 강요하지 않는다. 클라우드 인프라부터 동전 크기의 센서 노드까지 이르는 광범위한 하드웨어 생태계를 단일 프로토콜로 아우르기 위해, Zenoh는 네트워크에 참여하는 노드(Node)의 역할을 철저히 기능적이고 아키텍처적인 관점에서 삼분화(Bifurcation)하였다.

어떤 디바이스가 Zenoh 네트워크에 참여할 때, 그 디바이스의 연산 능력, 네트워크 가시성(Visibility), 그리고 소비 전력 제약에 따라 스스로 가장 적합한 **역할(Role)**을 부여받거나 선택하게 된다. 이 유연한 역할 기반 아키텍처 덕분에 Zenoh는 중앙 집중식과 완전 분산형의 하이브리드(Hybrid) 배포를 자유자재로 구성할 수 있다.

Zenoh 네트워크의 핵심 통신 주체는 아키텍처 역할에 따라 크게 다음 세 가지로 분류된다:

Zenoh 피어(Peer): 동등한 자격으로 상호 통신하며 자율적인 P2P(Peer-to-Peer) 메쉬(Mesh) 망을 구성하는 일급 시민(First-class Citizen) 노드이다. 로컬 네트워크 내에서 브로커 없이 자유로운 데이터 유통을 책임진다.
Zenoh 라우터(Router): 다른 노드들(주로 피어 및 클라이언트)을 중계하고, 분리된 로컬 네트워크(LAN)들을 거대한 광역망(WAN)으로 이어주는 백본(Backbone) 인프라 역할을 수행한다. 라우터끼리 결합하여 거대한 라우팅 트리를 형성한다.
Zenoh 클라이언트(Client): 라우터나 피어에 종속적으로 연결되어 통신을 위임하는 경량화된 말단 노드이다. 연산 능력이 극도로 제한된 마이크로컨트롤러(MCU)나 배터리 기반 에지 디바이스에 적용된다.

이어지는 서브 챕터에서는 물리적 인프라 위에 얹어지는 이 세 가지 논리적 노드들이 어떠한 수학적, 공학적 메커니즘을 통해 상호작용하며 생태계를 이루는지 상세히 해부한다.

1. Zenoh 피어(Peer): 탈중앙화 P2P 통신망 구성 및 역할

**Zenoh 피어(Peer)**는 Zenoh 네트워크 아키텍처에서 가장 독립적이고 주도적인 역할을 수행하는 핵심 노드(Node) 개체이다. 이들은 클라이언트/서버(Client/Server) 아키텍처에서 흔히 볼 수 있는 ’서버’나 ’브로커’에 의존하지 않고, 인접한 다른 피어들과 자율적으로 세션을 맺고 데이터를 교환하는 **동등한 계층구조(Egalitarian Hierarchy)**를 지향한다.

1.1 피어의 정의와 P2P 메쉬(Mesh) 토폴로지

어떤 애플리케이션이나 디바이스가 ‘피어’ 모드로 Zenoh를 구동한다는 것은, 해당 노드가 자신만의 로컬 라우팅 정보(Routing Information)를 능동적으로 생성, 유지하며 이웃 노드들과 이를 동기화하겠다는 의지를 보인 것이다.

피어의 가장 두드러진 특징은 자가 조직(Self-Organizing) 능력이다. 동일한 로컬 에어리어 네트워크(LAN) 내에 새로운 피어가 등장하면, 이들은 멀티캐스트(Multicast) 탐색을 통해 서로를 감지하여 유기적인 P2P 메쉬(Mesh) 망을 엮어낸다. 예를 들어 5대의 자율주행 로봇(각각 피어 노드로 동작)이 군집 주행을 할 때, 1번 로봇이 발행한 충돌 경고 데이터는 중앙 통제 서버를 거치지 않고 곧바로 2, 3, 4, 5번 로봇으로 전파된다.

1.2 피어의 아키텍처 역할과 한계

1.2.1 자율적 데이터 중계 (Data Forwarding)

피어는 단순히 নিজের 데이터를 전송하는 데 그치지 않고, 네트워크 토폴로지 상 중간자(Intermediary) 역할을 수행할 수 있다. A-B-C 형태로 피어가 연결되어 있을 때, A 피어와 C 피어는 B 피어를 징검다리 삼아 데이터를 퍼블리시(Publish)하거나 쿼리(Query)할 수 있다. 즉, 피어 스스로 미니 라우터(Mini-Router)와 같은 동작을 수행하는 셈이다.

1.2.2 브로커리스(Broker-less) 환경의 무결성 보장

특정 중앙 노드가 파괴되어도 피어 그룹 전체의 통신망은 붕괴하지 않는다 (No Single Point of Failure). 끊어진 구간이 발생하면 피어들이 지닌 라우팅 엔진은 우회 경로를 실시간으로 재계산한다.

1.2.3 클리크(Clique) 제약 (스케일링의 한계)

그러나 모든 노드가 피어로만 구성된(Full Mesh) 네트워크는 한계에 봉착하기 마련이다. 피어의 대수가 N으로 늘어날 경우 피어 간에 교환해야 하는 상태 업데이트 및 디스커버리 트래픽은 기하급수적으로(O(N²)) 상승한다. 이러한 완전 연결 컴포넌트, 즉 **클리크(Clique)**가 지나치게 비대해지는 것을 방지하고 거대한 스케일의 네트워크로 확장하기 위해, 피어망 밖에는 그들을 묶어주는 거대한 허브 노드가 필요한데, 이것이 바로 다음 절에서 다룰 **Zenoh 라우터(Router)**의 존재 이유가 된다.

2. Zenoh 라우터(Router): 백본(Backbone) 네트워크 및 광역망(WAN) 연동 아키텍처

로컬 네트워크에서 자생하는 ’피어(Peer)’들의 군집만으로는 글로벌 규모(Global Scale)의 분산 시스템을 구축할 수 없다. 분리된 서로 다른 공장의 서브넷(Subnet)을 하나로 묶고, 에지(Edge) 인프라와 퍼블릭 클라우드(Public Cloud)를 관통하는 거대한 데이터 고속도로를 놓기 위해서는 트래픽을 집약하고 중계하는 인프라 노드가 필요하다. 이 핵심 중추 역할을 담당하는 것이 바로 **Zenoh 라우터(Router)**이다.

2.1 라우터의 기능적 분리: 브로커가 아닌 스위칭 허브

전통적인 MQTT 통신 구조의 브로커(Broker)와 Zenoh 라우터를 혼동해서는 안 된다. MQTT 브로커는 통신의 ’목적지’이자 상태를 저장하는 단일 권력 구조인 반면, Zenoh 라우터는 통신망의 트래픽 흐름을 정리(Routing)하고 최적화(Optimization)하는 고도의 **데이터 평면 스위치(Data Plane Switch)**에 가깝다.

라우터 노드는 자체적인 애플리케이션 로직을 갖거나 데이터를 근원적으로 생산하지 않는다. 오직 다른 노드(피어 및 클라이언트)들을 받아들이고, 거대한 이름 공간(Name Space)을 해석하여 데이터를 올바른 방향으로 밀어내는(Forwarding) 백본(Backbone) 임무만을 충실히 수행한다.

2.2 백본 연동 및 라우터-투-라우터(R-to-R) 트리기반 아키텍처

Zenoh 라우터가 투입되는 순간, 파편화되어 있던 네트워크는 논리적인 단일 망으로 통합된다.

2.2.1 광역망(WAN) 통합과 NAT 패스(Traversal)

클라우드 데이터센터에 Zenoh 라우터를 상주(Hosting)시키고 고정 IP를 할당한다. 각 지역 공장의 피어나 클라이언트 노드들은 이 라우터를 향해 상위 방향(Upstream)으로 연결을 개시한다. 이 구조는 에지(Edge) 측의 복잡한 방화벽이나 외부 인터넷에서의 NAT(Network Address Translation) 통과 문제를 우아하게 해결한다. 결과적으로 물리적 거리에 상관없이 factory/1/status라는 데이터는 클라우드 라우터를 거쳐 즉시 수천 킬로미터 밖의 또 다른 공장으로 흐른다.

2.2.2 스파닝 트리(Spanning Tree) 기반 라우터 연결망

Zenoh 라우터 단일 개체에 과부하가 걸리는 시대착오적인 중앙 집중형 디자인을 피하기 위해, Zenoh 라우터들은 서로 간에 연결(Router-to-Router)되어 거대한 트리(Tree) 계층 구조를 형성한다. 루프(Loop)를 방지하는 최단 경로 알고리즘 기반의 트리 망을 통해, 트래픽은 가장 효율적인 백본 코어를 타고 분산된다.

2.2.3 상태와 트래픽의 병합(Aggregation)

다수의 센서 클라이언트들이 개별적으로 클라우드 라우터로 통신하게 두면 오버헤드가 발생한다. 네트워크 에지에 투입된 로컬 Zenoh 라우터는 하위 노드들의 세션 정보, 쿼리, 목적지 주소를 하나로 요약 및 병합(Aggregation)하여 상위 클라우드 라우터로 쏘아 올린다. 요약된 라우팅 테이블(Routing Table) 교환 메커니즘은 노드 수가 만 단위로 증식하더라도 WAN 밖으로 유출되는 제어 평면(Control Plane) 오버헤드를 O(1)에 수렴케 하는 아키텍처적 경이로움을 보여준다.

3. Zenoh 클라이언트(Client): 자원 제약 환경(에지 디바이스)을 위한 경량 노드

거대한 공장이나 스마트시티의 센서 네트워크 말단에는, 전력 소모와 메모리 제약으로 인해 피어(Peer)처럼 복잡한 라우팅 테이블을 유지하거나 다른 노드의 트래픽을 중계해 줄 여력이 없는 초소형 디바이스들이 무수히 존재한다. 이러한 자원 제약 환경(Constrained Environment)을 스케일 다운(Scale-down)하여 완벽하게 수용하기 위해 고안된 노드 역할이 바로 **Zenoh 클라이언트(Client)**이다.

3.1 클라이언트 노드의 아키텍처적 특성

클라이언트 노드는 스스로 라우팅 결정을 내리거나 타인의 데이터를 중계(Forwarding)하지 않는 완전한 종속형(Dependent) 엔드포인트이다.

상태의 오프로딩(Offloading): 클라이언트 노드는 디스커버리(Discovery)를 수행하여 인접한 피어(Peer)나 라우터(Router) 중 하나와 단단히 결속(Binding)된다. 이후 자신이 발행(Publish)할 데이터나 구독(Subscribe)할 관심사(Interest) 등 모든 통신 제어 평면(Control Plane)의 로직을 상위 노드(Peer 또는 Router)에게 전적으로 위임(Offloading)해버린다.
최소한의 메모리 풋프린트(Memory Footprint): 라우팅 테이블이나 스파닝 트리 알고리즘을 구동할 필요가 없으므로, 클라이언트 모드로 동작하는 Zenoh 인스턴스(특히 Zenoh-Pico)는 수십 킬로바이트(KB) 수준의 극소량 RAM만으로도 생존할 수 있다.
슬립 모드(Sleep Mode) 친화적: 배터리로 구동되는 센서는 하루 종일 깨어있을 수 없다. 클라이언트 노드는 1시간에 한 번씩 깨어나 온도 센서 값을 상위 라우터로 쏜 후(Data in Motion), 소켓을 닫고 다시 깊은 수면(Deep Sleep)에 빠져드는 간헐적 통신 시나리오를 완벽하게 지원한다.

3.2 클라이언트의 토폴로지적 의미

클라이언트는 분산 네트워크망의 끝자락에 매달린 ’잎사귀(Leaf)’와 같다. 거대한 Zenoh 트리 및 메쉬 백본망이 라우터와 피어로 견고하게 직조되어 있다면, 클라이언트 노드들은 그 백본망의 라우터/피어에 수백, 수천 개씩 클러스터링(Clustering)되어 달라붙는 형태(Star Topology)를 띤다.

이처럼 클라이언트 역할의 존재는 디바이스의 극단적인 경량화를 가능케 함과 동시에, 전체 네트워크 백본(라우터 및 피어) 입장에서는 시시각각 깜빡이며 죽고 사는 센서 디바이스들의 상태 변화가 라우팅 망 전체의 토폴로지 동요(Topology Churn)로 번지는 현상을 차단해 주는 강력한 완충(Buffer) 레이어로 작용한다.

4. 동적 노드 탐색(Discovery) 및 피어 간 세션 협상(Negotiation) 절차

수십, 수백 개의 Zenoh 노드(피어, 라우터, 클라이언트)가 물리적인 네트워크에 흩뿌려졌을 때, 이들이 중앙 서버의 통제 없이 스스로 상대방의 존재를 각성하고 거대한 가상의 유기체로 결합해 나가는 과정은 정교한 분산 알고리즘과 세션 협상(Negotiation) 절차에 의해 통제된다.

4.1 단계: 동적 노드 탐색 (Dynamic Discovery)

가장 먼저 이루어지는 단계는 공간상에 존재하는 타 노드의 IP와 포트를 확보하는 디스커버리 단계이다.
Zenoh는 멀티캐스트(Multicast), 브로드캐스트(Broadcast), 그리고 유니캐스트(Unicast)를 조합한 스크립트 탐색(Scouting) 메커니즘을 사용한다 (상세한 메커니즘은 차장 2.2.5에서 다룬다).

어떤 피어(Peer) 노드 A가 네트워크에 부팅하면, 자신이 Zenoh 통신망에 존재함을 알리는 짧은 식별자 비콘(Beacon) 패킷을 로컬 네트워크상에 뿌린다.
이 비콘을 수신한 기존의 피어 B나 라우터 C는 자신들의 청취용 엔드포인트(Locator, 예: tcp/192.168.1.10:7447) 정보를 담은 응답(Hello 메시지)을 노드 A에게 돌려보낸다.

4.2 단계: 피어 간 동적 연결 (Session Initialization)

상대의 Locator를 파악한 노드 A는 즉각 TCP 단일 소켓이나 QUIC, UDP 등 설정된 와이어 프로토콜(Wire Protocol)을 사용하여 물리적 파이프라인(Session) 연결을 시도한다.
흥미로운 점은 Zenoh는 클라이언트/서버 통신의 본질적인 한계인 대칭성(Symmetry) 문제를 P2P 관점에서 훌륭하게 극복한다는 사실이다. TCP 소켓은 누가 connect()를 걸고 누가 accept()를 받는지가 기동(Initiation) 단계에서 정해지지만, 소켓이 연결된 직후부터 해당 파이프라인은 완전한 양방향 다중화(Full-duplex Multiplexed) 통신로로 추상화되어 양측이 완전히 동등하게 데이터를 밀어 넣을 수 있게 된다.

4.3 단계: 세션 협상 메커니즘 (Session Negotiation)

물리적인 TCP/UDP 세션이 열렸다고 해서 곧바로 방대한 사용자 데이터가 쏟아지는 것은 아니다. 데이터 평면이 열리기 직전, 양 끝단의 노드는 서로의 아키텍처적 역량과 제약을 조율하는 아주 짧고 결정적인 초기 협상(Init/Open Negotiation) 국면을 거친다.

프로토콜 버전 및 암호화 협상: Zenoh 와이어 프로토콜의 버전을 맞추고, 플러그인된 TLS 등 보안 인증 레이어가 있다면 이를 교환하여 신뢰(Trust)를 수립한다.
역할(Role) 검증: 내가 라우터인지, 너는 클라이언트인지 상호 간의 식별자를 교환한다. 클라이언트가 피어에게 연결을 요청하면, 피어는 기꺼이 상위 노드로서의 라우팅 책임을 수락한다.
라우팅 정보의 압축 전파: 세션이 타결되면, 기존 네트워크에 존재하던 피어/라우터들은 자신이 알고 있는 목적지 경로표(Routing Table)와 구독(Subscription) 상태의 변화분을 즉각 델타(Delta) 형태로 새로운 노드에게 브리핑해 준다.

이 일련의 3단계를 통해, 새로 태어난 노드는 불과 수 밀리초(ms) 만에 고립된 객체에서 벗어나 전 세계를 아우르는 Zenoh 생태계의 능동적 세포(Cell)로 병합(Merge)되는 것이다.

5. 스크립트 탐색(Scouting) 메커니즘과 멀티캐스트/유니캐스트 비콘(Beacon)

앞선 장에서 다룬 ’동적 노드 탐색(Dynamic Discovery)’의 이면에는 통신 생태계의 혈맥을 은밀하게 이어주는 정교한 심장 박동, 즉 비콘(Beacon)과 스크립트 탐색(Scouting) 알고리즘이 박동하고 있다.
산업용 네트워크 환경은 정적인 연구소망과 달리 철 구조물에 의한 끊김 현상(Wi-Fi), 클라우드 방화벽의 패킷 차단, 컨테이너(Docker) 가상망의 고립 등 수많은 장애물 체계로 둘러싸여 있다. Zenoh는 이러한 지옥 같은 토폴로지 파편화 현상을 타파하기 위해 복합적이고 전방위적인 스카우팅(Scouting) 체계를 가동한다.

5.1 멀티캐스트 비콘 (Multicast Beacon) 기반의 근거리 탐색

가장 기본적이고 공격적인 발견 방식은 멀티캐스트(Multicast) 전파를 활용하는 것이다.
기본 설정상 Zenoh 노드가 깨어나면 UDP 멀티캐스트 그룹(예: 기본 포트 7447)으로 자신이 살아있음을 알리는 비콘(Beacon) 메시지를 지속적으로 뿜어낸다.

경량성: 이 비콘 메시지는 자신의 노드 ID, 로케이터(Endpoint IP:Port), 그리고 역할(Peer/Router/Client)만을 담은 초경량 프레임워크로, 대역폭을 낭비하지 않는다.
자가 구성망 파악: 동일한 이더넷 로컬 네트워크(LAN)나 Wi-Fi 대역 내에 존재하는 다른 노드들은 이 멀티캐스트 프레임을 수신하자마자 새로운 노드의 진입을 감지하고, 유ני캐스트(Unicast) Hello 메시지로 화답하여 즉각 세션을 체결한다.

이 방식은 설정 프리(Zero-configuration) 배포에 매우 강력하다. 공장 라인에 10대의 로봇을 추가로 전원만 켜면 알아서 통신군집(Mesh)을 이루게 하는 마법의 원천이다.

5.2 유니캐스트 라우팅 (Unicast Scouting)과 가십(Gossip) 프로토콜

위와 같은 아름다운 멀티캐스트 통신은 라우터(Router 장비)를 하나라도 넘어가거나, 퍼블릭 클라우드(AWS, Azure) 내부망에 진입하는 순간 완벽하게 차단된다. 대부분의 클라우드 플랫폼은 멀티캐스트를 본질적으로 허용하지 않기 때문이다.

이 절망적인 단절의 벽을 넘기 위해 Zenoh는 정밀한 유니캐스트 지향 탐색(Unicast Scouting) 기능을 동시에 제공한다.
에지(Edge)의 피어나 클라이언트는 부팅 시 connect 플래그를 통해 저 멀리 수천 킬로미터 떨어져 있는 클라우드 라우터의 고정 IP(Static IP Endpoint)로 정확하게 타겟팅된 비콘을 발사한다.

가십(Gossip) 프로토콜에 의한 확장: 유니캐스트로 클라우드 라우터 A에 성공적으로 진입한 노드는, 그 라우터 A가 이미 알고 있는 또 다른 라우터 B, C의 존재(Locator list)를 소문(Gossip)처럼 전해 듣게 된다.
이를 통해 말단 노드는 굳이 멀티캐스트의 축복을 받지 못한 격리된 망에 있더라도, 최초의 단일 유니캐스트 진입점(Entry Point) 하나만 뚫어내면 전체 글로벌 라우팅 트리의 백본 맵(Backbone Map)을 순식간에 동기화할 수 있다.

5.3 스카우팅 주기와 생사(Life Cycle) 관리

비콘은 초기 디스커버리에만 쓰이지 않고 죽은 노드를 식별(Liveliness 검증)하는 데에도 사용된다.
노드들은 아주 낮은 빈도(예: 수 초 단위)로 상호 간에 Keep-alive 비콘을 교환하며 생사를 확인한다. 만약 이웃 피어로부터 일정 횟수 이상 비콘이 들어오지 않으면, Zenoh 라우팅 엔진은 해당 노드를 테이블에서 매정하게 삭제(Prune)하고, 그 노드를 통해 우회하던 모든 통신 경로를 즉각 다른 살아있는 경로로 재계산(Reconfigure)해낸다.