4.4 엔드포인트(Endpoint) 및 트랜스포트(Transport) 구성

4.4 엔드포인트(Endpoint) 및 트랜스포트(Transport) 구성

Zenoh(제노) 모델의 가장 파괴적인 혁신 중 하나는 데이터가 흘러가는 길, 즉 트랜스포트(Transport) 계층을 특정 네트워크 기술(예: TCP/IP)에 강제로 결속(Coupling)시키지 않고 완전히 플러그인(Plug-in) 형태로 추상화해 두었다는 점이다.

이러한 설계 덕분에 Zenoh 라우터는 해저 케이블을 관통하는 광대역 인터넷망부터, 전파 간섭이 심한 공장의 블루투스(BLE) 통신, 심지어 동일한 서버 내의 프로세스 간 통신(IPC)까지 동일한 데이터 프로토콜 원칙으로 매끄럽게 엮어낼 수 있다.

이번 절에서는 데이터가 진출입하는 관문인 **엔드포인트(Endpoint)**의 개념을 해부하고, 상황에 맞는 최적의 트랜스포트 기술을 라우터에 장착하는 실전 기법을 다룬다.

  • 아키텍처 뷰 (4.4.1): Zenoh가 어떻게 TCP, UDP, QUIC 등 완전히 이질적인 네트워크 프로토콜들을 단일 브릿지로 묶어내는지 트랜스포트 계층의 오버롤(Overall) 아키텍처를 분석한다.
  • 근거리 통신 (4.4.2): 가장 대중적인 로컬 네트워크 연결 방식인 TCP의 신뢰성과 제어, UDP의 브로드캐스트/멀티캐스트 탐색 속성을 라우터에 주입하는 방법을 다룬다.
  • 원거리 및 웹 통신 (4.4.3 & 4.4.4): 대륙 간 통신이나 패킷 로스가 심한 모바일망 환경에서 빛을 발하는 QUIC 프로토콜의 적용법, 웹 브라우저 기반 클라이언트(예: 대시보드 UI)를 라우터로 직접 직결시키는 WebSocket(WS) 연동법을 검토한다.
  • 초제약 환경 및 최적화 (4.4.5 & 4.4.6): 산업용 IoT 센서를 위한 직렬(Serial)/BLE 트랜스포트의 연동 사양을 짚어보고, 하나의 포트(Port) 위에서 여러 프로토콜을 우아하게 받아내는 멀티플렉싱(Multiplexing) 구성을 마스터한다.

이 절을 완전히 소화하고 나면, 인프라의 물리적 한계와 무관하게 모든 데이터 노드를 Zenoh라는 단일 생태계로 결속할 수 있는 통신 지배력을 얻게 될 것이다.

1. 트랜스포트 계층 아키텍처 개요

**Zenoh(제노)**가 자랑하는 “네트워크 독립성(Network Independence)“의 근간에는 하위 물리 네트워크를 완벽하게 가려주는 트랜스포트 계층(Transport Layer) 추상화 아키텍처가 자리 잡고 있다. 이 계층을 제대로 이해해야만 비로소 라우터의 엔드포인트 설정(tcp/, quic/, ws/ 등)을 자유자재로 다룰 수 있다.

1.1 전송 수단의 플러그형(Pluggable) 설계

기존의 미들웨어(예를 들어 초기 설계형 DDS나 특정 브로커)들은 TCP나 UDP 중 어느 하나에 심하게 종속적인 구조를 띠는 경우가 많다. 하지만 Zenoh 아키텍처는 코어 로직(상태 관리, 라우팅 테이블)과 하부 데이터 전달망을 **트랜스포트 API(Transport API)**라는 규약으로 철저히 분리해 내었다.

graph TD
    A[Zenoh Core Routing & Session Management] -->|Transport API| B{Transport Multiplexer}
    B -->|tcp/...| C(TCP Plugin)
    B -->|udp/...| D(UDP Plugin)
    B -->|quic/...| E(QUIC Plugin)
    B -->|ws/...| F(WebSocket Plugin)
    B -->|serial/...| G(Serial / BLE Plugin)

이 플러그인 메커니즘 덕분에, 개발자는 zenoh.json5 설정 파일의 문자열 접두사(Locator Prefix) 하나를 바꾸는 것만으로 전체 데이터망의 하부 고속도로를 무정지로 통째로 갈아 끼울 수 있다.

1.2 로케이터(Locator)와 엔드포인트(Endpoint)의 개념

Zenoh 생태계에서 물리적 네트워크 주소를 지칭할 때는 흔히 **로케이터(Locator)**라는 용어를 사용한다.

  • 로케이터의 필수 문법: [프로토콜]/[주소]:[포트]
  • 예시: tcp/192.168.1.100:7447, quic/0.0.0.0:7447, tls/router.mycompany.com:7447

라우터가 이 로케이터를 쥐고 클라이언트의 유입을 수동적으로 기다릴 때 이를 **리슨 엔드포인트(Listen Endpoint)**라 칭하며, 라우터가 다른 타겟을 향해 능동적으로 터널을 파고 들어갈 때 목표 지점을 **커넥트 엔드포인트(Connect Endpoint)**라 부른다.

1.3 프레이밍(Framing)과 다중화(Multiplexing)

단순히 소켓(Socket)을 열었다고 통신이 끝나는 것은 아니다. 각기 다른 트랜스포트는 패킷을 자르고 붙이는 방식(MTU 사이즈 등)이 천차만별이다. Zenoh 트랜스포트 계층은 이 저수준의 바이트 스트림을 이어받아, Zenoh의 규격화된 메시지 프레임(Frame)으로 조립하고 해체하는 프레이밍(Framing) 파이프라인을 내부에 은닉하고 있다.

더불어, 최신 Zenoh 아키텍처는 단일 트랜스포트 연결(세션) 위에서 수천 개의 Publish/Subscribe 스트림이 섞여서 지나가도 병목이 발생하지 않도록 논리적인 채널을 쪼개는 다중화(Multiplexing) 기술을 기본 탑재하고 있어, 연결 수립 오버헤드를 극단적으로 낮춘다.

2. 로컬 네트워크를 위한 TCP 및 UDP 트랜스포트 설정

현대 시스템 인프라 구축에 있어 가장 대중적이고 빈번하게 다루어지는 트랜스포트는 단연코 TCP와 UDP다. 기업 내부망(Intranet), 로봇 기체 내부망(Local Loopback), 혹은 동일한 AWS VPC 내의 컨테이너 간 통신 등 안정성이 어느 정도 담보된 근거리 네트워크 환경에서는 이 두 프로토콜이 라우터의 척추 역할을 수행한다.

2.1 TCP 트랜스포트: 신뢰성의 대명사

Zenoh 데이터 평면(Data Plane)의 기본(Default) 트랜스포트로 가장 널리 쓰이는 것은 TCP 통신이다. 순서가 보장되고(Ordered), 패킷 유실을 자체적으로 재전송(Retransmission)하여 커버해 주는 TCP 고유의 이점이 대다수의 엔터프라이즈 환경에서 환영받기 때문이다.

라우터 설정 파일(zenoh.json5) 혹은 CLI 실행 인자에서 TCP 바인딩은 다음과 같이 이루어진다.

// zenoh.json5
{
  "listen": {
    "endpoints": [
      // 서버의 모든 NIC(Network Interface Card)에서 TCP 7447 포트를 개방한다.
      "tcp/0.0.0.0:7447",
      // 혹은 특정 사설 IP에만 개방하여 보안을 높일 수도 있다.
      "tcp/192.168.10.50:7447" 
    ]
  }
}

주의할 점: TCP는 무겁다. 수만 대의 마이크로센서가 동시에 접속을 시도할 경우, 운영체제의 소켓 고갈(Socket Exhaustion) 혹은 TCP 핸드셰이크(Handshake) 오버헤드로 인해 라우터가 몸살을 앓을 수 있으므로 대규모 접속 환경에선 후술할 QUIC 등을 고려해야 한다.

2.2 UDP 트랜스포트: 스카우팅(Scouting)과 멀티캐스트의 무기

Zenoh에서 순수 UDP 전송은 대용량 데이터 전송의 주력으로 쓰이기보다는, **동적 노드 탐색(Discovery)**과 경량 멀티캐스트(Multicast) 전송 기능에 핵심적인 비중을 차지한다.

특히, 중앙 서버의 주소를 하드코딩하지 않아도 로봇들이 스스로 라우터를 찾아가게 만드는 ‘스카우팅(Scouting)’ 메커니즘은 100% UDP 멀티캐스트의 힘을 빌린다.

// zenoh.json5
{
  "scouting": {
    "multicast": {
      // 스카우팅 기능 자체의 활성화 여부
      "enabled": true,
      // 라우터가 비콘(Beacon)을 발송할 때 사용할 기본 멀티캐스트 그룹 주소
      "address": "224.0.0.225:7447",
      // 비콘 발송 주기를 제어하여 네트워크 백그라운드 노이즈를 튜닝한다
      "interval": 200
    }
  }
}

UDP는 연결을 맺고 끊는 과정(Connection-less)이 없으므로 지연 시간(Latency)이 극단적으로 짧지만, 패킷 유실에 대한 보능이 없다. 따라서 제노 코어는 UDP 트랜스포트 위에서 동작할 때 Reliability 라우팅 옵션을 통해 유실율을 자체 튜닝(Best-effort vs Reliable)하는 독자적인 보조 메커니즘을 작동시킨다.

3. 고성능 및 원거리 통신을 위한 QUIC 프로토콜 활용

QUIC(Quick UDP Internet Connections) 프로토콜은 차세대 웹 표준인 HTTP/3의 심장부로 채택될 만큼 현대 네트워크 지형을 송두리째 뒤바꾸고 있는 핵심 기술이다. 구글이 주도하여 개발한 이 프로토콜은, UDP를 하부 구조로 삼으면서도 TCP의 신뢰성(Reliability)과 TLS의 강력한 보안성을 공간적(Overhead) 낭비 없이 흡수한 무결점 트랜스포트로 평가받는다.

Zenoh(제노) 코어는 이러한 QUIC 프로토콜을 트랜스포트 플러그인에 완벽하게 올려두어, 대륙을 횡단하는 하이 라텐시(High Latency) 네트워크 환경에서도 대역폭 한계를 돌파하게 해준다.

3.1 TCP의 치명적 한계(Head-of-Line Blocking) 돌파

글로벌 클라우드 네트워크 망이나, 달리는 자율주행 차량의 LTE/5G 모바일 망처럼 패킷 유실률이 높은 광역 네트워크(WAN) 환경에서 TCP는 치명적인 약점을 드러낸다. 단 한 개의 패킷에 드롭(Drop)이 발생하더라도 후속 패킷들은 앞선 패킷이 재전송될 때까지 큐(Queue)에 멈춰서 기다려야 하는 HOL(Head-of-Line) 차단 현상이 발생하기 때문이다.

Zenoh가 적용한 QUIC 트랜스포트는 내장된 독립 스트림(Independent Streams) 구조를 통해 이 병목을 우회한다. 하나의 스트림에서 패킷 로스가 나더라도, 다른 센서 데이터를 전송하는 스트림은 거침없이 목적지 라우터를 향해 직진할 수 있다.

3.2 QUIC 엔드포인트 바인딩

설정은 싱거울 정도로 단순하다. zenoh.json5 파일의 listen 계층에서 접두사로 quic/를 붙여주기만 하면, 즉각적으로 고도화된 QUIC 모듈이 활성화된다.

// zenoh.json5
{
  "listen": {
    "endpoints": [
      // UDP 백본 기반의 QUIC 암호화 스트림 포트 개방
      "quic/0.0.0.0:7447"
    ]
  }
}

3.3 강력한 이점: 0-RTT 연결과 원네이티브(Native) TLS 결합

QUIC의 또 다른 무기는 **극단적으로 짧은 연결 수립 시간(Connection Time)**이다. 모바일 로봇이 터널을 통과하며 기지국 핸드오버(Handover)를 반복하여 IP 주소가 파편화될 때, TCP 트랜스포트는 번번이 무거운 3-Way Handshake와 TLS 협상을 다시 맺어야 한다.

그러나 QUIC은 0-RTT(Zero Round-Trip Time) 기능과 프로토콜 설계 단부터 융합된 TLS 1.3 암호화를 통해, 기존 세션만 살아있다면 즉시 데이터를 암호화하여 밀어 넣을 수 있다. 즉, Zenoh 라우터를 클라우드에 띄워두고 세계 전역의 모바일 에지 로봇들을 관제할 때, 연결 비용과 반응 속도를 최고 수준으로 최적화하려면 QUIC 바인딩을 주력으로 고려해야 한다.

4. 웹 기반 클라이언트를 연동하기 위한 WebSocket(WS) 설정

클라우드 통합 관제 센터나 로봇의 로컬 터치 패널에서 돌아가는 프론트엔드 대시보드(React, Vue 등)는 브라우저 보안 정책 샌드박스에 갇혀 있기 때문에, 운영체제 수준의 원시 TCP나 UDP 소켓을 마음대로 열 수 없다.

과거에는 이러한 웹 클라이언트들을 백엔드 데이터 메커니즘과 연동하기 위해 무거운 REST API 폴링(Polling) 서버나 별도의 MQTT 브릿지를 중간에 두어야 했다. 하지만 **Zenoh(제노)**는 웹 생태계의 표준 실시간 양방향 통신 규격인 **WebSocket(WS)**을 네이티브 트랜스포트로 내장하여, 브라우저에서 곧바로 라우터 코어로 다이렉트 스트림을 꽂을 수 있게 해준다.

4.1 WebSocket 엔드포인트 개방

zenoh.json5 설정 파일에서 ws/ 접두어를 사용하여 라우터에 웹소켓 리스너를 달아준다. 일반적으로 웹 트래픽을 처리하는 8000번대 포트를 할당하는 것이 관례다.

// zenoh.json5
{
  "listen": {
    "endpoints": [
      // 기존 백본용 통신 포트
      "tcp/0.0.0.0:7447",
      // 웹 관리자 대시보드 연동을 위한 전용 WebSocket 포트
      "ws/0.0.0.0:8000"
    ]
  }
}

이렇게 라우터만 설정해 두면 끝난다. 8000번 포트로 들어오는 WebSocket 프레임은 라우터 내부에서 자동으로 Zenoh 와이어 프로토콜로 역프레이밍(De-framing)되어, 마치 TCP로 직접 접속한 C++ 노드와 완벽하게 동일한 권한으로 라우팅 테이블에 참여하게 된다.

4.2 브라우저(TypeScript/JavaScript) 클라이언트 연동

라우터에서 WS 포트를 열어두었다면, 웹 브론트엔드 개발자는 @eclipse-zenoh/zenoh-ts 라이브러리를 통해 한 줄의 코드로 로봇 데이터망에 진입할 수 있다.

import { open, Config } from '@eclipse-zenoh/zenoh-ts';

async function connectToRobot() {
  // 라우터의 WS 로케이터 지정
  const config = Config.fromSession({
    mode: "client",
    connect: { endpoints: ["ws/192.168.1.100:8000"] }
  });

  // 로봇의 심박(Heartbeat) 토픽을 웹에서 직접 구독
  const session = await open(config);
  const subscriber = await session.declareSubscriber('robot/telemetry/heartbeat', (sample) => {
    console.log("로봇 상태 수신:", new TextDecoder().decode(sample.payload));
  });
}

이 방식을 통해 웹 브라우저는 중간 서버나 브릿지 없이 데이터 소스(로봇)의 데이터를 마이크로초 단위의 지연만으로 실시간 렌더링할 수 있다.

4.3 보안 확장: WSS (WebSocket Secure)

공용 인터넷 망을 통해 대시보드를 서비스해야 한다면, 평문으로 전송되는 WS 대신 TLS 암호화가 씌워진 WSS를 강제해야 한다. Nginx나 HAProxy 같은 리버스 프록시(Reverse Proxy)를 라우터 앞단에 두어 443(HTTPS) 포트에서 TLS 오프로딩(Offloading)을 수행한 뒤, 뒷단의 Zenoh WS 포트로 트래픽을 넘겨주는 아키텍처가 실무에서 가장 안정적이다.

5. 블루투스(BLE) 및 시리얼(Serial) 트랜스포트 연결 기초 (IoT 환경 대비)

**Zenoh(제노)**의 유연성은 거대한 클라우드 데이터센터에 머무르지 않는다. 공장 바닥을 굴러다니는 배달 로봇의 휠 모터 제어기, 혹은 비닐하우스 구석에 박혀있는 초저전력 온습도 센서 등 전형적인 IP(Internet Protocol) 네트워크가 존재조차 하지 않는 **자원 제약 환경(Microcontroller, IoT)**까지 데이터망을 뻗어 나갈 수 있다.

이러한 척박한 환경을 공략하기 위해 고안된 것이 10장(마이크로컨트롤러를 위한 Zenoh-Pico)의 핵심인 **블루투스(BLE)**와 시리얼(Serial/UART) 통신 기반의 비표준 트랜스포트다.

5.1 시리얼(Serial) 트랜스포트의 포용

전통적인 임베디드 장비(예: Arduino, STM32 코어 보드 등)는 이더넷 잭은커녕 와이파이 칩셋도 없는 경우가 수두룩하다. 이들은 오직 USB C단자나 RS-232, I2C 같은 구시대적 로컬 시리얼 케이블로만 바깥세상과 소통한다.

Zenoh 라우터(혹은 브릿지 역할을 하는 라즈베리 파이 피어)는 리눅스 커널에 물려있는 /dev/ttyUSB0 같은 물리 제어 포트를 곧바로 데이터 버스의 입구로 치환해 낼 수 있다.

// zenoh.json5 (시리얼 트랜스포트 바인딩)
{
  "listen": {
    "endpoints": [
      "tcp/0.0.0.0:7447",
      // USB 시리얼 포트를 보드레이트(Baud Rate) 115200으로 열어둔다.
      "serial//dev/ttyACM0?baudrate=115200" 
    ]
  }
}

케이블 반대편에 물려있는 센서가 Zenoh-Pico (C언어 기반 프레임워크)로 작성된 클라이언트라면, 아무런 IP 스택 없이도 오직 전선 두 가닥(TX/RX)만으로 클라우드의 라우터 테이블과 동일한 계층으로 데이터를 쏘아 올리게 된다.

5.2 블루투스 엑세스 (BLE - Bluetooth Low Energy)

스마트 팩토리의 수많은 센서는 선을 연결하기조차 힘든 벽면이나 회전체 표면에 부착되어 있다. Zenoh는 이들을 위해 블루투스(BLE) 트랜스포트를 개방한다.

에지 컴퓨터(Edge Gateway)에서 구동되는 Zenoh 라우터는 내장된 블루투스 모듈을 켜서 주변 센서들의 BLE 비콘을 감지하고, 이 MAC 어드레스를 마치 IP 주소처럼 취급하여 세션을 맵핑해 버린다.

// zenoh.json5 (BLE 바인딩 예시)
{
  "listen": {
    "endpoints": [
      // 호스트의 hci0 블루투스 어댑터를 바인딩
      "ble/hci0"
    ]
  }
}

이러한 비표준 트랜스포트를 엮어내는 아키텍처는, 과거 “시리얼 통신 파서 모듈 -> 데이터베이스 연동 모듈 -> 서버 전송 모듈“로 첩첩산중 이어지던 이기종 프로토콜 드라이버 개발의 악몽을 단 칼에 썰어버리고, 모든 하드웨어 통신을 Pub/Sub API 하나로 단일화 시킨다는 엄청난 파괴력을 지닌다.

6. 리스너(Listener) 바인딩 및 멀티플렉싱(Multiplexing) 구성

지금까지 우리는 4.4 절을 관통하며 TCP, UDP, QUIC, WebSocket, 그리고 척박한 시리얼(Serial) 환경에 이르기까지 Zenoh(제노) 라우터가 소화해 내는 방대한 트랜스포트의 스펙트럼을 확인했다. 이 장의 종착지로, 이질적인 트랜스포트들을 실무 운영 환경에서 어떻게 단일 라우터 안에 효율적으로 버무리고 분배하는지를 설계하는 멀티플렉싱(Multiplexing) 기술을 다룬다.

6.1 다중 리스너(Listener)의 오케스트레이션

현실의 에지 컴퓨팅(Edge Computing) 게이트웨이는 수많은 이기종 장비들의 한복판에 놓인다. 하나의 라우터 프로세스(zenohd)는 설정 파일에 로케이터 접두사(Prefix)만 콤마로 나열해 준다면, 두 개, 세 개, 혹은 수십 개의 각기 다른 트랜스포트 포트를 동시에 개방할 수 있다.

// zenoh.json5
{
  "listen": {
    "endpoints": [
      // 1. 코어 백본망 연결을 위한 QUIC 포트
      "quic/0.0.0.0:7447",
      // 2. 사내 레거시 로봇망 통신을 위한 로컬 TCP 포트
      "tcp/192.168.10.1:7447",
      // 3. 디버깅 및 UI 관제를 위한 웹소켓 포트
      "ws/0.0.0.0:8000",
      // 4. 구형 텔레메트리 보드를 위한 시리얼 포트
      "serial//dev/ttyUSB1?baudrate=9600"
    ]
  }
}

이 코드가 적용된 라우터는 QUIC으로 날아오는 클라우드 영상 스트림과, 시리얼 선을 타고 들어오는 단순한 1바이트 펄스를 **동일한 Zenoh 데이터 공간(Global Data Space)**에 수렴시킨다. 개발자 입장에서는 상대방이 어떤 네트워크 망을 타고 들어왔는지 따질 필요 없이 토픽(Key Expression) 구조만 바라보면 된다.

6.2 멀티플렉싱(Multiplexing) 기반의 연결 오버헤드 최적화

백만 개의 마이크로 센서가 각자 별도의 TCP 커넥션과 Thread를 요구한다면 아무리 강력한 데이터베이스 서버라도 뻗어버릴 것이다. 라우터는 이를 막기 위해 트랜스포트 내부의 프레이밍 논리를 고도화하여 **멀티플렉싱(Multiplexing)**을 강제한다.

  • 세션(Session) 하나 안에 수만 개의 비동기 데이터 채널(Streams)이 마치 꼬인 전선 다발처럼 효율적으로 얽혀 스케줄링된다.
  • 연결 수립(Handshake)의 오버헤드는 단 한 번만 치른 후, 내부의 경량화된 토큰(ID) 교환만으로 데이터를 라우팅하므로, OS 커널의 컨텍스트 스위칭(Context Switching) 부하를 극한으로 낮춘다.

개발자는 아키텍처를 설계할 때 “어느 트랜스포트로 들어오는가?” 보다 **“데이터의 계층과 토픽(Topic) 구조를 어떻게 나눌 것인가?”**에만 온전히 집중하면 된다. Zenoh 트랜스포트는 보이지 않는 곳에서 조용하고 완벽한 하이웨이를 유지할 것이다.