9.1.3.1 하드웨어 제약 및 RAM 가용성에 따른 C 바인딩 및 zenoh-pico 선별

사물인터넷(IoT)과 로보틱스 산업 현장의 끝자락(Edge)은 성능과 전력 소모의 적막한 생존 경쟁이 펼쳐지는 공간이다. 인텔(Intel) 제온 CPU에서 구동되는 수 기가바이트(GB) 대역의 풀 스택 노드가 있는가 하면, 배터리를 쥐어짜며 작동해야 하는 ARM Cortex-M 기반 단말은 고작 32KB의 SRAM(정적 램)만으로 버텨내야 한다.

Zenoh 프로토콜 생태계는 범용 zenoh-c 바인딩과, 뼛속까지 덜어낸 초경량 모듈 zenoh-pico를 동시에 제공한다. 하드웨어 스펙이라는 물리적인 RAM 한계 용량과 통신 대역폭 제약 조건에 따라, 이 두 통신 라이브러리 중 어느 것을 탑재할지 아키텍처적 선별(Decision Making) 기준을 확립하는 것이 매우 중요하다.

1. 기능적 완결성(zenoh-c)과 극단적 경량화(zenoh-pico)의 분기점

zenoh-c는 단일 Rust 코어 기반이 래핑된 풀스택(Full-stack) 바인딩으로서 공유 메모리 통제, 완전한 보안(TLS/QUIC) 세션, 다이나믹 라우팅 테이블(DHT), 멀티캐스트 디스커버리 기능 전체를 포함하고 있다. 이 패키지를 탑재하기 위한 마지노선(Minimum Requirement)은 대략 메가바이트(MB) 체급의 메모리 가용성과 POSIX 스레드를 관리할 수 있는 Linux 또는 완전한 RTOS 기반 환경에 한정된다.

반면 zenoh-pico는 완전한 독립 구동을 목적으로 순수 100% C 코드로 바닥부터(From Scratch) 다시 재작성된 특수 돌연변이 프로토콜 스택이다. 이 모듈의 목표는 단 하나, 10초 내외의 수면(Sleep) 주기 사이에서 깨어나 1KB짜리 작은 텔레메트리 바이트를 쏘아 보내고 다시 수면으로 돌입하는 센서 터미널의 역할(Stub)만을 소화하는 것이다. 컴파일 된 바이너리의 크기(Footprint)는 2~5KB 수준에 불과하며, 의존성 라이브러리가 존재하지 않아 8-bit 단일 코어 마이크로컨트롤러 환경의 베어메탈(Bare-metal) 메모리에도 우아하게 기생할 수 있다.

graph TD
    A[Hardware RAM Availability] --> B{Available RAM size}
    B -->|> 2MB, Linux/Rich RTOS| C[zenoh-c (Rust Core Binding)]
    B -->|< 128KB, FreeRTOS/Baremetal| D[zenoh-pico (Pure C Implementation)]
    
    C -->|Feature| E[Full Router/Peer Mode, TLS, WebSockets]
    D -->|Feature| F[Client Mode Only, Manual Discovery, UDP/Serial]

2. 브라더(Brother)와 클라이언트(Client) 토폴로지의 단절

하드웨어 제약으로 인해 zenoh-pico를 선별하게 된 단말은 태생적으로 글로벌 Zenoh 메타 공간에서의 신분이 클라이언트 모드(Client Mode)로 강등된다.
zenoh-c 혹은 zenoh-python 풀 패키지 노드들은 상호 간 피어(Peer) 모드로 자가 결속하며 라우터 없이도 직접 메시지를 송수신하는 대칭적 그물망(Mesh)을 구축할 수 있다. 그러나 SRAM 자산이 없는 Pico 노드는 라우팅 경로를 연산할 메모리 지도가 존재하지 않는다.

따라서 zenoh-pico를 장착한 온도 칩셋, 서보 모터 엔드포인트 장비들은 반드시 네트워크 외곽에 배치된 강력한 zenoh-c (혹은 Router डे몬) 노드의 주소(IP 혹은 시리얼 포트)를 정적으로(Statically) 설정 받아, 1:1 세션의 탯줄을 연결하는 클라이언트/서버 중계 아키텍처를 따라야만 한다. 멀티캐스트 오토 디스커버리 트래픽은 저전력 장비의 네트워크 인터럽트를 깨워 전력을 방전시키므로, Pico 환경은 이러한 백그라운드 라디오 주파수 청취 기능 자체를 아예 생략해 버린다.

3. 네트워크 파편화 제어와 단편화(Fragmentation) 한계

zenoh-pico는 메모리 동적 할당(malloc)을 극렬히 배척하기 위해, 전송하려는 페이로드(Payload)의 최대 크기가 컴파일 타임에 MAX_FRAME_SIZE 변수로 물리적 재단되어 고정된다.
센서 단말 측에서 이 설정 크기를 한 바이트라도 넘어서는 메시지 스트림(예: 저해상도 카메라 캡처 JPG)을 송출하려 할 경우, 런타임 버퍼는 가차 없이 세그먼트 오실레이션을 빚거나 혹은 패킷을 잘라(Truncate) 먹어버리는 치명상이 발생한다.

역으로 zenoh-c 장비로부터 거대한 객체 스트림을 수신 받아야 하는 입장이라면, 라우터 측에서 Pico 노드에게 배달하기 전 사전에 페이로드 슬라이싱(Slicing) 및 분할 패키징을 수동으로 수행하여, 작은 바이트 단위로 쪼개어(Chomp) 보내주어야 하는 프로토콜 디자인의 섬세한 단편화 회피 전술이 동반되어야 한다. 이러한 네트워크 조립 체계야말로 기계공학적 하드웨어의 생명 연장(Life Extension)과 소프트웨어의 결정론을 동시에 부양하는 최후의 진지다.