2.7 플러그인 기반 전송 계층(Transport Layer) 연동

2.7 플러그인 기반 전송 계층(Transport Layer) 연동

2.6장에서 살펴본 바와 같이, Zenoh(제노)는 단 5바이트에 불과한 오버헤드를 가지는 극도로 최적화된 와이어 포맷(Wire Format)을 갖추고 있다. 하지만 이 정교한 바이트 배열이 지구 반대편의 노드로 전달되기 위해서는 반드시 물리적인 장비와 운영체제가 제공하는 하위 네트워크 인프라, 즉 **전송 계층(Transport Layer)**의 등에 올라타야만 한다.

과거의 통신 미들웨어들은 태생적 한계를 지니고 있었다. DDS(Data Distribution Service)는 본래 로컬 네트워크의 멀티캐스트(UDP) 파이프라인에 최적화되어 발전했기에 인터넷 게이트웨이를 넘는 순간 설정 지옥이 펼쳐졌다. 반대로 MQTT는 태생부터 TCP 연결만을 고집했기 때문에, 언제 끊길지 모르는 불안정한 위성 통신이나 대역폭이 극도로 좁은 로라(LoRa)망에서는 재전송(Retransmission) 오버헤드 핑퐁으로 인해 시스템이 붕괴하곤 했다.

Zenoh는 특정 네트워크 프로토콜에 종속되는 우를 범하지 않기 위해 전송 계층 자체를 코어 라우팅 엔진에서 완전히 도려내는(Decoupling) 과감한 설계 결정을 내렸다.
본 장에서는 Zenoh가 어떻게 모듈화 된 플러그인(Plugin) 아키텍처를 도입하여 TCP, UDP, QUIC, WebSocket부터 심지어 시리얼(Serial) 케이블이나 블루투스(BLE)까지, 세상에 존재하는 거의 모든 물리적/논리적 통신 매체를 자유자재로 갈아 끼워가며(Hot-swappable) 글로벌 라우팅의 혈관을 개척해 내는지 그 구조적 혁신을 깊이 있게 파헤친다.

1. 멀티 트랜스포트(Multi-transport) 아키텍처 개요

**Zenoh(제노)**의 코어 엔진 내부를 들여다보면, 네트워크 매체(TCP 소켓, 시리얼 포트 등)를 직접 핸들링하는 코드가 중앙 로직에 존재하지 않는다. 대신, 코어 라우터와 물리 계층 사이에는 잘 정의된 추상화 전송 인터페이스(Transport Abstraction Interface) 계층이 샌드위치처럼 삽입되어 있다.

이 인터페이스는 매우 단순하다. 코어 엔진은 트랜스포트 계층에게 그저 “이 바이트 배열(프레임)을 저쪽 노드로 던져줘“라고 명령할 뿐이다. 밑단의 트랜스포트가 3-Way Handshake를 거치는 TCP인지, 신호 간섭이 심한 BLE(Bluetooth Low Energy)인지, 아니면 브라우저 내부의 WebRTC 데이터 채널인지는 코어 엔진의 알 바가 아니다.

1.1 플러그인(Plugin) 기반의 런타임 바인딩

Zenoh의 트랜스포트 계층은 완전히 모듈화된 플러그인(Plugin) 생태계로 동작한다.
개발자가 Zenoh 라우터나 피어(Peer)를 실행할 때 설정 파일(Config)이나 명령줄 옵션에 로드할 트랜스포트를 선언하기만 하면, 런타임에 해당 네트워크 스택이 동적으로 장착된다.

애플리케이션(Publisher/Subscriber) 레벨의 코드는 이 변화에 단 1줄도 영향을 받지 않는다.
어제까지 로컬 네트워크에서 UDP 기반으로 테스트하던 소스를 수정 없이 그대로 들고 가, 내일은 클라우드 환경에서 QUIC 플러그인을 활성화하여 실행해도 동일한 Zenoh 토폴로지가 마법처럼 형성된다.

1.2 이질적 네트워크의 심리스(Seamless) 브릿징

이러한 멀티 트랜스포트 아키텍처가 뿜어내는 진정한 파괴력은 서로 다른 이질적 네트워크망 한가운데 던져진 엣지 라우터(Edge Router)에서 발현된다.

공장 한구석에 놓인 마이크로 Zenoh 라우터는 다음과 같은 다중 인테페이스를 동시에 빙의(Multiplexing)할 수 있다.

  • 하향 링크 (Downlink): 공장 바닥을 기어 다니는 로봇 청소기들과는 좁은 대역폭의 Serial/BLE 플러그인을 열어 통신한다.
  • 측면 링크 (Lateral-link): 옆 동의 다른 라우터와는 실시간 데이터 중계를 위해 UDP 멀티캐스트 플러그인으로 메쉬(Mesh)를 엮는다.
  • 상향 링크 (Uplink): 클라우드에 위치한 통합 관제 센터로는 보안과 신뢰성을 위해 QUIC 플러그인을 열고 장거리 연결(WAN)을 뚫어낸다.

이처럼 하위 매체의 물리적 한계를 완전히 은닉하고 통합된 글로벌 데이터 공간(Global Data Space)을 구축하는 것, 이것이 Zenoh 멀티 트랜스포트 아키텍처 시스템 공학의 절정이다.

2. TCP 및 UDP 네트워크에서의 동작 차이와 최적화

플러그인 아키텍처 위에서 구동되는 수많은 트랜스포트 중, 상용 분산 시스템 구축 시 엔지니어가 가장 빈번하게 마주치는 선택지는 역시 TCP와 UDP 플러그인이다.
Zenoh(제노) 코어 라우터는 어떤 플러그인을 활성화하느냐에 따라 패킷을 다루는 내부 전략(Strategy)을 트랜스포트의 물리적 특성에 맞춰 극적으로 스위칭한다.

2.1 TCP 트랜스포트: 높은 신뢰성과 배치(Batching) 최적화

TCP(Transmission Control Protocol) 플러그인이 로드되면, Zenoh는 기저 대역망이 이미 **‘신뢰성(Reliability)과 순서 보장(In-Order Delivery)’**을 완벽하게 책진진다는 사실을 인지한다.

따라서 Zenoh 코어 엔진은 자체적인 재전송 타이머를 가동하거나 패킷 순서를 맞추는 중복 연산을 과감히 생략(Bypass)한다.
대신, TCP 환경에서 Zenoh는 **배치(Batching) 처리기(2.6.3장)**를 활성화하는 데 전력을 다한다. TCP 소켓의 특성상 잦은 시스템 콜(System Call)과 Nagle 알고리즘의 지연이 성능 하락의 주범이기 때문에, Zenoh는 애플리케이션으로부터 쏟아지는 수백 개의 펍(Pub) 메시지를 하나의 거대한 Nagle-Free TCP 세그먼트로 밀어 뭉친 후 송출한다. 이를 통해 클라우드와 클라우드를 잇는 고대역폭 백본(Backbone) 쇱계에서 단위 시간당 처리량(Throughput)을 극한으로 뽑아낸다.

2.2 UDP 멀티캐스트/유니캐스트: 레이턴시 최소화와 메쉬(Mesh) 개척

반면, UDP(User Datagram Protocol) 플러그인이 가동되면 Zenoh의 전략은 ’대용량 처리형’에서 **‘초저지연(Ultra-Low Latency) 기동형’**으로 완전히 탈바꿈한다.

  • 멀티캐스트(Multicast) 스카우팅: 공장 내부망(LAN)과 같은 로컬 엣지망에 UDP 트랜스포트가 켜지면, Zenoh 라우터들은 멀티캐스트 IP 대역을 활용하여 네트워크상의 다른 Zenoh 피어들을 자동으로 찾아내는 ‘Scouting’ 메커니즘을 가동한다. 이는 중앙 서버 없이 로봇들이 전원만 켜면 스스로 메쉬(Mesh) 네트워크를 도출해 내는 마법의 기반이다.
  • 오버헤드 붕괴와 선제적 전송: UDP 환경에서 Zenoh는 배치 윈도우(Batching Window) 대기 시간을 사실상 없애버리고, 센서 데이터가 입력되는 즉시 5바이트 헤더만 씌워 와이어(Wire)로 집어 던진다.

TCP의 무거운 3-Way Handshake 세션을 유지할 여력이 없는 이동형 마이크로 로봇 수십 대가 얽힌 공간에서, UDP 모드로 구동되는 Zenoh 통신망은 장애물을 회피하는 무리의 새 떼처럼 가장 빠르고 기민하게 동작한다. 부족한 ’신뢰성(Reliability)’의 영역은 추후 2.8장에서 다룰 Zenoh 자체의 애플리케이션 레벨 QoS 제어기로 넘겨 우아하게 보상받는다.

3. 직렬 통신(Serial), BLE 등 비표준 네트워크 계층 연동 원리

현대의 사물인터넷(IoT) 생태계는 IP(Internet Protocol) 기반의 이더넷과 Wi-Fi망으로 완전히 통일되지 않았다. 현장에는 여전히 RS-232, RS-485 같은 고전적인 직렬 케이블(Serial Cable)이 로봇 관절 모터들을 잇고 있으며, 웨어러블 센서들은 배터리를 아끼기 위해 오직 블루투스 저전력(Bluetooth Low Energy, BLE)으로만 대화한다.

이러한 비표준(Non-IP) 네트워크 구역은 전통적인 클라우드 미들웨어들이 발을 들이지 못하는 ’통신의 격오지’였다. 하지만 **Zenoh(제노)**의 멀티 트랜스포트 아키텍처는 이 척박한 땅조차 글로벌 라우팅 공간으로 편입시켜 버린다.

3.1 페이로드의 순수성 (Payload Purity)

IP 스택(IP/Mac Header)이 존재하지 않는 통신 매체 위를 달릴 수 있는 비결은, 2.6장에서 다룬 프레이밍(Framing) 기술에 있다.
Zenoh가 생성해 낸 [5바이트 헤더 + 페이로드] 덩어리는 그 자체로 자족적(Self-contained)이다. 이 바이트 배열은 반드시 TCP 소켓의 send() 버퍼에 담길 필요가 없다.

MCU 위에서 동작하는 Zenoh-Pico 에이전트는 생성된 바이트 배열을 그대로 UART(Universal Asynchronous Receiver-Transmitter) 전송 레지스터에 1바이트씩 쑤셔 넣어(Bit-banging) 구리선을 태워 실어 보낸다. 수신 측 라우터의 ’Serial 트랜스포트 플러그인’은 USB-Serial 컨버터로 들어온 아날로그 파동을 다시 바이트로 읽어 들여 Zenoh 코어 엔진에 건네준다.
결과적으로 코어 라우팅 엔진 입장에서는 이것이 광케이블로 들어온 데이터인지 낡은 구리 케이블로 들어온 데이터인지 구분조차 되지 않는다.

3.2 대역폭 지혈(Gauze)과 배터리 구명(Lifesaver) 로직

비표준망을 다룰 때 Zenoh 트랜스포트 플러그인의 역할은 단순한 파이프 연동에 그치지 않는다.
BLE나 LoRa망의 초당 전송량 제한(Bandwidth Limit)은 가혹하다. 이들 플러그인 위로 거대한 Pub(데이터 송출) 덩어리가 떨어지게 되면, 플러그인 내부의 스케줄러(Scheduler)가 개입한다.

  • 패킷 크기를 BLE의 GATT(Generic Attribute Profile) 페이로드 한계인 20바이트 내외로 초미세 단편화(Micro-Fragmentation)를 강제 적용한다.
  • 펌웨어 단에서 슬립-웨이크업(Sleep-Wakeup) 듀티 사이클에 맞춰, 무선 모듈이 깨어났을 때만 모아둔 데이터를 일괄 전송(Burst)하여 센서 노드의 코인 배터리를 수개월 이상 연명시킨다.

이처럼 IP 프로토콜의 특권을 과감히 벗어던진 덕분에, 드론의 텔레메트리(지상파 라디오 TX/RX), 수중 로봇의 음향 통신 파동(Acoustic Modem)조차도 C/C++로 간단한 Zenoh 트랜스포트 플러그인만 작성해 주면, 전 세계 어디서든 셀렉터(Selector, 예: ocean/robot1/depth)로 원격 쿼리를 쏠 수 있는 완벽한 엔드-투-엔드(End-to-End) 투명성을 달성하게 된다.

4. QUIC 및 WebSockets를 활용한 클라우드 및 브라우저 네이티브 통합 방안

엣지 컴퓨팅망을 훌륭하게 묶어낸 Zenoh(제노) 라우터가 최종적으로 도달해야 할 목적지는 방대한 관제 시스템이나 데이터 레이크(Data Lake)가 구축된 퍼블릭 클라우드(AWS, GCP 등)다. 또한, 사용자들은 별도의 클라이언트 프로그램 설치 없이 웹 브라우저만 창을 열어 이 모든 하드웨어를 통제(Monitoring & Control)하기를 원한다.

하지만 인터넷 공유기의 가장 바깥에 서 있는 NAT(Network Address Translation) 통과 문제, 클라우드 로드밸런서의 엄격한 포트 제한, 그리고 브라우저의 샌드박스 정책으로 인해 순수 UDP나 TCP만으로는 이 장벽을 넘기가 불가능에 가깝다. Zenoh는 이러한 ’클라우드와 웹 네이티브 장벽’을 돌파하기 위해 QUIC과 WebSockets 트랜스포트 플러그인을 기본으로 지원한다.

4.1 QUIC 플러그인: WAN 보안과 혼잡 제어의 대가

로봇이나 공장 라우터가 퍼블릭 인터넷(WAN)을 건너 클라우드 라우터로 연결될 때, 전송되는 데이터는 반드시 암호화(Encryption)되어야 하며 잦은 패킷 로스에도 굴복하지 않아야 한다.

Zenoh가 지원하는 QUIC 플러그인은 구글이 개발한 UDP 기반의 차세대 인터넷 표준 전송 프로토콜을 그대로 계승한다.

  • 제로 라운드트립 타임(0-RTT) 연결: 기존 TCP+TLS 조합이 3~4번의 왕복을 거쳐야만 암호화 세션이 뚫리던 것과 달리, QUIC은 단 한 번의 패킷 교환(혹은 즉시)만으로 보안 연결을 수립한다. 모바일 네트워크 엣지에서 기지국(Cell Tower) 핸드오버가 발생하여 IP가 바뀌더라도 연결이 끊어지지 않으므로, 고속 주행 중인 커넥티드 카나 자율주행 트럭을 클라우드에 연동할 때 필수적인 트랜스포트이다.
  • 스트림 분리와 Head-of-Line Blocking 해소: 하나의 연결 통로 안에서 영상, 오디오, 텍스트 여러 스트림을 전송할 때, 하나가 유실되어도 다른 데이터의 전송이 멈추지 않는다.

4.2 WebSockets 플러그인: 브라우저 네이티브 직접 포워딩

대시보드 웹 개발자가 브라우저에서 드론의 좌표를 실시간으로 받아보려면 보통 WAS(Web Application Server)에 웹소켓 서버를 띄우고, 백엔드에서 드론과 MQTT로 통신한 뒤 이를 다시 브라우저로 쏴주는 이중 중계 아키텍처를 쓰게 마련이다.

하지만 Zenoh의 멀티 트랜스포트 기저에는 브라우저 친화적인 WebSockets 플러그인이 장착되어 있다.

  • 클라우드 라우터의 설정 파일에서 WebSocket 포트를 tcp/ws://[::]:8000 형태로 개방해두면 끝이다.
  • 프론트엔드 개발자는 zenoh-ts (TypeScript API) 라이브러리를 임포트(Import)한 뒤 별도의 백엔드 없이 브라우저 앱에서 클라우드 라우터로 다이렉트(Direct) WebSockets 세션을 꽂아 넣는다.

브라우저에서 session.get('drone/1/gps')를 호출하는 순간, 이 요청은 WebSockets의 틀을 타고 라우터를 통과하여 지구 반대편의 드론까지 도달한다. 즉, 브라우저 샌드박스 내부의 탭(Tab) 하나조차 거대한 분산 시스템의 완전한 Zenoh 피어(Peer)로 편입시키는 놀라운 통일성을 달성한다.

5. 공유 메모리(Shared Memory) 트랜스포트를 이용한 노드 간(IPC) 통신 가속화

멀티 트랜스포트 아키텍처가 전 세계를 아우르는 통신을 가능케 한다면, 역으로 **‘단 하나의 컴퓨터, 단일 OS 위에서 여러 프로세스가 통신할 때’**는 어떤 전략이 필요할까?

하나의 강력한 하이퍼바이저나 리눅스(Linux) 보드 안에서 카메라 비디오 캡처 프로세스(Publisher)와 AI 비전 분석 프로세스(Subscriber)가 동시에 구동된다고 가정해 보자. 이들 간의 통신에 이더넷 케이블을 타고 나가는 로컬호스트(localhost) TCP 소켓이나 커널의 로프백(Loopback) 인터페이스를 사용한다면, 기가바이트(GB) 단위의 트래픽이 매초마다 유저 스페이스(User Space)와 커널 스페이스(Kernel Space)를 넘나드는 병목과 과도한 메모리 복사 연산을 유발한다.

이러한 로컬 통신 오버헤드를 제로(0) 수준으로 소멸시키기 위해 **Zenoh(제노)**는 단일 OS 내 프로세스 간 통신(IPC)용 특화 트랜스포트인 공유 메모리(Shared Memory, SHM) 플러그인을 자랑한다.

5.1 커널 우회(Kernel Bypass)를 통한 진정한 제로 카피(Zero-Copy)

공유 메모리 트랜스포트가 가동되면, 동일 장비 안에서 구동되는 Zenoh 프로세스(노드)들은 데이터를 물리적 네트워크 카드나 커널 소켓 버퍼로 밀어 넣지 않는다.

  1. 할당 (Allocation): Publisher인 카메라 프로세스는 OS로부터 할당받은 거대한 글로벌 공유 메모리 영역(Shared Memory Segment)의 한 구역에 4K 이미지의 원시 바이트(Raw Byte)를 직접 쏟아붓는다.
  2. 포인터 발행 (Pointer Publishing): 메모리에 적재가 끝나면, 무거운 이미지 데이터 자체를 전송하는 것이 아니라 **“A번지부터 B번지까지 데이터가 준비됨”**이라는 가벼운 꼬리표(포인터 혹은 토큰)를 담은 몇 바이트짜리 작은 신호 패킷만을 로컬 Unix Domain Socket(또는 UDP 로컬호스트) 플러그인을 거쳐 날린다.
  3. 수신 및 직접 참조 (Direct Access): 이 알림을 수신한 Subscriber(AI 비전 분석기)는 자신의 메모리 공간에 카메라 데이타를 복사(Copy)해오지 않는다. 그저 전달받은 포인터를 읽고 파드득 커널 매핑을 수행한 뒤, 카메라 프로세스가 적재해 놓았던 그 물리적 메모리 구역을 **직접 들여다보고 곧바로 추론 연산에 돌입(Zero-Copy)**한다.

5.2 마이크로서비스 및 ROS 2 생태계에서의 파급력

자율주행 아키텍처처럼 하나의 차체 컴퓨터 안에 자율주행 인지, 판단, 제어 스택이 별도의 마이크로서비스 콘테이너로 쪼개져 있는 환경에서, Zenoh SHM 플러그인의 파괴력은 절대적이다.

특히 ROS 2와 같이 노드 간 막대한 데이터를 주고받는 로봇 미들웨어에서, 기본 DDS가 겪는 로컬 루프백 소켓의 통신 지연 문제를 극복하기 위해 Zenoh를 차세대 로컬 RMW(ROS Middleware) 트랜스포트로 채택하는 사례가 급격히 늘고 있다. 네트워크망이 닿지 않는 단일 실리콘의 차가운 메모리 회로 위에서도 Zenoh의 라우팅 마법은 가장 압도적인 성능(Throughput)으로 작동한다.