8.1 TypeScript와 Zenoh의 통합 개요

8.1 TypeScript와 Zenoh의 통합 개요

현대 웹 및 서버리스(Serverless) 아키텍처에서 JavaScript와 그 상위 언어인 TypeScript는 프론트엔드와 백엔드를 아우르는 범용적인 개발 표준으로 자리 잡았다. 기존의 웹 통신 생태계는 클라이언트-서버 모델에 기반한 요청-응답(Request-Response) 구조인 HTTP(REST) 또는 중앙 집중형 브로커(Broker)에 의존하는 WebSocket 통신 모델에 고착되어 있었다.

그러나 Zenoh의 도입은 웹 브라우저나 Node.js 런타임 자체가 거대한 분산 네트워크망의 동등한 P2P(Peer-to-Peer) 노드로 직접 참여할 수 있는 패러다임 전환을 의미한다. 본 절에서는 TypeScript 생태계가 Zenoh와 통합됨으로써 기존의 HTTP 및 브로커 기반 아키텍처를 어떻게 혁신하는지, 그리고 브라우저와 서버 런타임에서의 동작 원리와 구조적 차이를 학술적 관점에서 분석한다.

1. 웹 및 JS/TS 생태계에서의 분산 통신 패러다임 변화

전통적인 웹 브라우저와 로보틱스 또는 IoT 디바이스 간의 통신 아키텍처는 심각한 구조적 병목을 내포하고 있었다.

1. 폴링(Polling) 모델의 한계 (REST API 아키텍처)
웹 클라이언트가 센서 데이터를 주기적으로 확인하기 위해 서버에 반복적인 HTTP 요청을 전송하는 방식이다. 이는 데이터가 갱신되지 않은 상태에서도 불필요한 HTTP 헤더 트래픽을 유발하며, 네트워크 대역폭(Bandwidth)을 심각하게 낭비한다.

2. 중앙 집중형 소켓 통신 (WebSocket 및 MQTT 기반)
로봇 제어기 등에서 발생한 데이터가 MQTT 브로커를 거쳐 Node.js 웹 서버로 전달되고, 다시 WebSocket을 통해 브라우저로 전송되는 다단계 구조이다. 브로커 서버가 단일 장애점(Single Point of Failure, SPOF)으로 작용하며, 개발자는 서버 측 통신 로직과 클라이언트 측 수신 로직을 중복으로 관리해야 하는 설계 상의 결함을 발생시킨다.

3. Zenoh의 데이터 중심(Data-Centric) 아키텍처 도입
Zenoh는 중간 미들웨어 서버를 소거하고 강력한 데이터 라우팅 계층을 프론트엔드에 직접 제공한다.

  • P2P(Peer-to-Peer) 직결 통신: TypeScript로 작성된 클라이언트 코드가 Zenoh의 글로벌 데이터 공간(Global Data Space)에 직접 접근한다.
  • 서버리스(Serverless) 로보틱스 제어: 백엔드 중계 없이, 웹 브라우저에서 분산 쿼리(Distributed Query)를 발행하여 C++/Rust 기반의 로봇 제어 노드로부터 직접 응답(Reply)을 수신한다.
  • 타입 안정성(Type Safety) 보장: TypeScript의 정적 타이핑(Static Typing)을 통해 런타임 환경에서 직렬화(Serialization)된 페이로드(Payload) 데이터를 안전한 인터페이스(Interface) 객체로 캐스팅(Casting)할 수 있다.

2. Zenoh TypeScript API의 아키텍처와 내부 동작 원리

zenoh-ts 패키지는 구동되는 런타임 환경(Environment)에 따라 내부 코어 엔진이 동적으로 전환되는 하이브리드(Hybrid) 아키텍처를 채택하고 있다.

graph TD
    classDef tsClass fill:#e6f7ff,stroke:#333,stroke-width:1px;
    classDef wasmClass fill:#fff2e8,stroke:#333,stroke-width:1px;
    classDef napiClass fill:#f4f1f8,stroke:#333,stroke-width:1px;
    classDef zClass fill:#e8f4f8,stroke:#333,stroke-width:2px;

    subgraph "zenoh-ts API Layer"
        TS_API[TypeScript API Interfaces<br>Session, Publisher, Subscriber]
    end

    subgraph "Node.js / Deno Runtime"
        NAPI[N-API / FFI Layer<br>Rust Native Compiled Driver]
    end

    subgraph "Web Browser Runtime"
        WASM[WebAssembly WASM Layer<br>Compiled Rust Core]
    end
    
    subgraph "Physical Network Layer"
        TCP_UDP[TCP / UDP Socket<br>Multicast Scouting]
        WS[WebSocket WSS<br>Target Router IP Required]
    end

    ZRouter((Zenoh Router / Peer Network))

    TS_API -->|When in Node.js| NAPI
    TS_API -->|When in Browser| WASM

    NAPI --> TCP_UDP
    WASM --> WS

    TCP_UDP <-->|Native Speed| ZRouter
    WS <-->|Sandbox Bridging| ZRouter

    class TS_API tsClass;
    class WASM,WS wasmClass;
    class NAPI,TCP_UDP napiClass;
    class ZRouter zClass;

본 API 단일화 구조 하에서 개발자는 구동 환경에 구애받지 않고 일관된 코드를 작성할 수 있다.

1. Node.js 백엔드 환경 (N-API 바인딩)
Node.js 런타임에서는 운영체제의 네이티브 자원에 직접 접근할 수 있으므로, C/Rust로 컴파일된 zenoh-rs 코어 엔진이 N-API를 통해 결합된다. 이는 TCP/UDP 소켓 직접 제어, 무복사(Zero-Copy) 메모리 처리, 그리고 스카우팅(Scouting) 프로토콜을 이용한 멀티캐스트 로컬 피어 탐색 기능을 완벽히 지원한다.

2. 브라우저 프론트엔드 환경 (WebAssembly + WebSocket)
웹 브라우저는 보안 샌드박스(Sandbox) 정책으로 인해 임의의 TCP 포트 개방 및 UDP 멀티캐스트 전송을 엄격히 차단한다. 이를 극복하기 위해 Rust 코어를 웹어셈블리(WASM, WebAssembly) 형식으로 컴파일하여 브라우저 메모리에 적재한다. 통신 계층은 오직 브라우저가 지원하는 WebSocket(WS/WSS) 채널로 강제되며, 외부의 Zenoh 라우터 IP를 명시적으로 지정하여 접속하는 클라이언트(Client) 모드로만 동작한다.

3. 실행 환경별 제약 사항 및 고려 요소

TypeScript 런타임 간의 운영 체제 샌드박스 보안 수준 차이는 아키텍처 설계의 핵심 고려 대상이다.

  1. Node.js (서버 백엔드): 운영체제의 네트워크 제원이 완전 개방되어 있으므로 마이크로서비스, 로그 수집, 데이터베이스 브릿징 파이프라인으로 운용된다. 라우터(Router) 모드 혹은 피어(Peer) 모드 운영이 모두 허용된다.
  2. Deno / Bun (모던 런타임): 기본적으로 네트워크 접근(Network Access) 권한 통제 정책(Default Deny)을 지향한다. 따라서 스크립트 런타임 호출 시 --allow-net 플래그를 통해 Zenoh 엔진의 소켓 개방을 명시적으로 위임(Authorization)해야 한다.
  3. Web Browser (보안 클라이언트): 통제된 클라이언트이므로 런타임은 오직 Client 토폴로지 역할에 한정된다. 다른 피어 간의 데이터를 중계할 수 없고, 네트워크 스카우팅이 차단되므로 반드시 진입점(Entry Point)이 될 Zenoh Router 인프라가 사전에 배포되어 있어야 한다.

4. 분산 시스템 관제 화면(Dashboard)에서 TypeScript의 역할

하위 계층의 로보틱스 하드웨어 통신을 C++ 또는 Rust가 전담하더라도, 최종적인 사용자 경험(User Experience)과 통계 대시보드 인터페이스는 TypeScript 및 웹 프레임워크 환경에서 구현된다. Zenoh를 도입함으로써 프론트엔드 컴포넌트는 다음과 같은 세 가지 구조적 우위를 획득한다.

1. 실시간 텔레메트리(Telemetry) 렌더링
단일 이벤트 루프 속에서 60 FPS 이상의 초고주파수 갱신 데이터를 브라우저 렌더링 주기에 맞추어 동기화한다. WebSocket을 통해 유입된 패킷을 DataView 또는 TypedArray로 받아 메모리 재할당 없이 차트 생성기 및 3D 렌더링 엔진으로 직접 전송(Forwarding)한다.

2. 분산 명령 하달 체계 확립
프론트엔드의 제어 인터페이스에서 비상 정지(Emergency Stop) 등 즉각적인 조작 이벤트가 발생할 때, 중앙 집중형 API 서버를 우회하고 P2P 분산 쿼리(예: session.get("robot/*/cmd/stop"))를 직접 발행하여 모든 로컬 노드들에 제어 명령을 확산 캐스팅(Broadcasting)한다.

3. 비정형 계층 구조 데이터(JSON)와의 직교성
로보틱스 장비의 구성 정보와 메타데이터는 대부분 복잡한 계층 구조의 JSON 포맷을 차용한다. TypeScript는 선행 정의된 타입 인터페이스(Interface)를 통해 원시 페이로드를 컴파일 타임에 강건하게 캐스팅하며, 이는 데이터 프로토콜 오류율을 기하급수적으로 감소시키는 아키텍처적 당위성으로 작용한다.