5.1 Rust와 Zenoh: 완벽한 결합

5.1 Rust와 Zenoh: 완벽한 결합

Zenoh는 단순한 네트워크 미들웨어가 아니라, C++의 성능과 Python의 생산성을 동시에 잡겠다는 거대한 야망을 품고 탄생했다. 그리고 그 야망을 스레드 경합(Data Race)이나 메모리 누수(Memory Leak) 없이 실현할 수 있는 유일한 도구로 Rust를 선택했다.

시스템 언어의 왕좌가 C/C++에서 Rust로 넘어가고 있는 현대 인프라 환경에서, Zenoh는 Rust 생태계의 비동기(Async) 처리, 소유권(Ownership) 모델, 그리고 엄격한 타입 시스템의 특장점을 극한까지 빨아들인 네이티브(Native) 프레임워크다.

이 장에서는 “왜 수많은 런타임 중 하필 Rust 기반의 Zenoh API를 써서 백엔드를 짜야 하는가?“에 대한 아키텍처적 근거를 짚고, Rust의 엄격한 컴파일러가 어떻게 엔지니어의 네트워크 실수를 배포 전에 완벽하게 차단해 주는지 그 ’결합의 미학’을 해부한다.

1. Zenoh 코어 모듈이 Rust로 작성된 이유와 그 이점

분산 시스템의 라우팅 코어(zenohd)를 만들 때, 구글의 Go 런타임을 썼다면 개발 속도는 두 배 빨랐을 것이다. C++를 썼다면 레거시 통합이 더 편했을 것이다. 그럼에도 코어 개발팀이 가비지 컬렉터(Garbage Collector, GC)가 없는 Rust를 심장부 언어로 채택한 데에는 명확한 공학적 계산이 깔려 있다.

1.0.1 가비지 컬렉션(GC) 멈춤 현상(Stop-The-World)의 완벽한 배제

로봇이 시속 100km로 질주하며 초당 1,000개의 라이다(LiDAR) 포인트를 Publish 하고 있다고 가정하라.
Go나 Java 기반의 미들웨어는 메모리 정리를 위해 필연적으로 수십 밀리초(ms)의 GC 멈춤 현상을 발생시킨다. 이 찰나의 지연시간(Latency Spike)은 자율주행에서는 즉각적인 추돌 사고로 이어진다.

  • [이점] Rust는 컴파일 시점에 메모리 해제 타이밍을 결정하므로, GC Pause가 물리적으로 발생하지 않는다. 로봇의 틱 레이트(Tick Rate)가 마이크로초(us) 단위로 완벽하게 예측 가능해진다(Deterministic).

1.0.2 제로 카피(Zero-Copy)와 소유권(Ownership)의 결합

네트워크 스택에서 패킷이 수신되어 사용자 애플리케이션 콜백으로 넘어갈 때, C 언어에서는 메모리 이중 구역 해제 버그(Double Free Bug)를 막기 위해 데이터를 memcpy로 복사해서 넘기는 멍청하고 안전한 방법을 쓴다.

  • [이점] Rust는 소유권(Ownership) 시스템을 통해 포인터를 넘기더라도 컴파일러 단위에서 Data Race를 원천 차단한다. ZBytes 페이로드 100MB는 단 한 번의 복사 없이 커널 영역에서 V8/User 영역으로 다이렉트 맵핑된다.

1.0.3 두려움 없는 동시성 (Fearless Concurrency)

라우터는 수만 개의 연결(Connections)에서 쏟아지는 트래픽을 스레드 풀(Thread Pool)로 분산 처리한다.

  • C++에서 뮤텍스(Mutex)를 잘못 잡으면 발생하는 교착 상태(Deadlock)나 스레드 안전성 파괴(Segfault).
  • [이점] Rust 환경에서 Zenoh 코어는 특성(Trait, Send 및 Sync)을 강제하므로, 개발자가 비동기 큐에 이웃 라우터의 상태 데이터를 넘기는 과정에서 단 한 개의 스레드 버그도 낼 수 없게 컴파일러가 매를 든다. 프로덕션 환경에서의 극단적 안정성(99.9999%)은 바로 이 컴파일러의 강제성에서 발현된다.

2. Rust 생태계에서의 Zenoh 아키텍처 위치

Rust 생태계(Ecosystem)는 파편화된 라이브러리들의 집합이 아니라, 철저하게 검증된 거대한 톱니바퀴들의 모음이다. Zenoh는 독고다이 체제로 굴러가지 않고, Rust의 최상위 티어(Top-tier) 라이브러리 생태계 위에 안착하여 강력한 시너지를 낸다.

2.0.1 [아키텍처 도해도] Zenoh Rust 스택

graph TD
    subgraph User Application
        App[Your Rust App]
    end

    subgraph Zenoh Ecosystem
        Zenoh_API[zenoh crate]
        Zenoh_Config[zenoh-config]
        Zenoh_Protocol[zenoh-protocol]
        Zenoh_Transport[zenoh-transport]
    end

    subgraph Rust Tier-1 Ecosystem
        Tokio[Tokio Async Runtime\n비동기 런타임 및 I/O]
        Serde[Serde\n직렬화/역직렬화]
        Tracing[Tracing / Log\n이벤트 로깅 및 추적]
        Quinn[Quinn\nQUIC 프로토콜 엔진]
    end

    App -->|Uses| Zenoh_API
    Zenoh_API --> Zenoh_Config
    Zenoh_API --> Zenoh_Protocol
    Zenoh_Protocol --> Zenoh_Transport
    
    Zenoh_Transport -.->|Depends on| Tokio
    Zenoh_Transport -.->|Depends on| Quinn
    Zenoh_Config -.->|Depends on| Serde
    Zenoh_Ecosystem -.->|Logs to| Tracing

2.0.2 [Runbook] 생태계 결합의 파괴력

1. Tokio와의 비동기 밀월
Zenoh는 블로킹 스레드를 쓰지 않는다. tokio-rs 엔진 위에서 스케줄링 되므로, 1대의 저렴한 Edge PC가 수십만 개의 센서 TCP 커넥션을 물고 있어도 CPU 코어당 문맥 교환(Context Switching) 오버헤드가 제로에 가깝다.

2. Serde(Serializer/Deserializer) 무임승차 기법
Cargo.toml에 Zenoh를 넣었다면 serde_json이나 bincode 등을 활용한 페이로드 직렬화를 숨 쉬듯 사용할 수 있다. 복잡한 로봇 구조체(Struct) 메모리가 단 한 줄의 매크로 #[derive(Serialize, Deserialize)] 를 통해 0.1밀리초 만에 ZBytes로 갈아입는다.

3. Quinn (QUIC 엔진) 탑재
원거리 5G망에서 TCP의 Head-of-Line Blocking을 박살 내기 위해 투입되는 QUIC 트랜스포트 레이어의 근간이 바로 Rust 생태계의 가장 위대한 걸작인 quinn 라이브러리다. Zenoh는 이 생태계의 위력 덕분에 C++ 시절보다 훨씬 압도적인 속도로 차세대 프로토콜을 백본으로 편입시킬 수 있었다.

3. Rust API의 설계 철학 (안전성, 동시성, 성능)

개발자가 코드를 작성하며 zenoh::open() 을 치는 순간부터 당신은 거대한 Rust 컴파일러의 감독 아래에 놓인다. C/C++ 미들웨어 API들이 “메뉴얼(Documentation)대로 메모리를 꼭 풀어주세요“라고 부탁한다면, Zenoh Rust API는 “그렇게 짜면 빌드를 안 시켜준다“라고 철창을 내려친다.

3.0.1 안전성 (Safety): 소유권의 지배

세션 라이프사이클 런북
과거 C 미들웨어에서는 session_close() 함수를 누락하면 커널에 좀비 소켓이 남아 서버를 죽였다. Zenoh의 Session 객체는 RAII(Resource Acquisition Is Initialization) 패턴을 극한으로 준수한다.

async fn do_something() {
    let session = zenoh::open(Config::default()).res().await.unwrap();
    // 블라블라 로직...
} // 함수 스코프가 종료되어 session이 버려지는(Drop) 순간, 
  // Rust 코어가 백그라운드 스레드를 멈추고 리눅스 Network 소켓을 강제 회수한다.

메모리 릭(Leak)과 좀비 커넥션이 구조적으로 발생할 수 없다.

3.0.2 동시성 (Concurrency): 멀티스레드 구독의 우아함

클라우드 백엔드에서 robot/*/status라는 10,000대의 로봇 데이터를 수신하면서 데이터베이스에 비동기로 넣어야 한다고 해보자.

// [Runbook] 백엔드 무한 비동기 스레드 파쇄기
let subscriber = session.declare_subscriber("robot/*/status").res().await.unwrap();

// 비동기 스트림(Stream) 인터페이스를 통해 패킷을 가져온다.
while let Ok(sample) = subscriber.recv_async().await {
    // 수신된 데이터를 Tokio 워커 스레드 100개로 찢어서(spawn) 넘겨버린다!
    tokio::spawn(async move {
        // Data Race? 뮤텍스 락? Rust에서는 그딴 걱정 없이 DB insert 가 가능하다.
        insert_to_database(sample).await;
    });
}

Zenoh 페이로드(Sample) 내의 버퍼 구조체는 원자적 참조 카운팅(Arc<[u8]>) 등 Thread-safe 한 포장재로 싸여 있어서, 1,000개의 스레드에 데이터를 막 찢어 복사해 넘겨도 C언어에서 겪던 Segmentation Fault 구역을 원천적으로 비켜 간다.

3.0.3 성능 (Performance): 제로 비용 추상화(Zero-cost Abstraction)

타입이 엄격하다고 해서 속도가 느린 게 아니다.
구조체를 직렬화해서 ZBytes로 바꿀 때 깎여나가는 CPU 틱(Tick) 오버헤드는 사실상 0이다. C 코드를 잘 짜는 엔지니어가 비트 연산으로 직접 우겨넣는 코드의 파이프라인 컴파일 결과물과, Rust에서 zenoh.put(buffer)로 우아하게 넘긴 바이너리의 어셈블리어 구조는 똑같다.

이 압도적인 성능 지표(Throughput)야말로, HFT(고빈도 거래, High Frequency Trading) 증권가나 자율주행 라이다 센서 스트리밍에 Zenoh + Rust 조합이 지배자로 군림하는 이유다.