13.1 Zenoh-Flow 개요와 철학

13.1 Zenoh-Flow 개요와 철학

네트워크 프로토콜인 Zenoh가 “데이터를 지점 A에서 지점 B로 효율적으로 전송하는 방법(Data Routing)“에 집중한다면, Zenoh-Flow는 “전송되는 스트림 데이터를 네트워크 상의 물리적 분산 노드들을 넘나들며 어떻게 가공, 병합, 파생할 것인가(Distributed Data Computing)“를 제어하는 선언적 데이터플로우 프레임워크(Declarative Dataflow Framework)이다.

본 절에서는 단일 컴퓨터 내에서 중앙 통제 방식으로 연산되는 폰 노이만 구조적 제어 흐름(Control Flow)을 탈피하여, 데이터 생성 자체에 의해 파이프라인(Pipeline)이 자율적으로 구동되는 데이터플로우 프로그래밍(Dataflow Programming)의 본질적 철학과 Zenoh-Flow의 아키텍처적 당위성을 학술적 관점에서 정립한다.

1. 데이터플로우 프로그래밍(Dataflow Programming) 패러다임 이해

로보틱스의 비전(Vision) 파이프라인, 즉 카메라의 프레임 획득부터 객체 인식 추론(Inference), 기구학적 모터 제어 명령 도출까지 이어지는 일련의 과정은 거대한 연산 체인을 요구한다.

1. 제어 흐름(Control Flow) 기반 명령형 아키텍처의 한계
전통적인 절차적 프로그래밍 패턴에서는 메인 스레드나 중앙 제어기(Orchestrator)가 “데이터 A를 읽어 함수 B에 전달하고, 반환값을 C에 주입하라“는 식으로 연산의 타이밍과 순서를 엄격히 통제(Synchronous Invocation)한다. 그러나 분산 환경에서 물리적 노드가 증가할수록 이러한 중앙 집중적 구조는 락(Lock) 경합, 네트워크 지연(Latency Bottleneck), 분산 상태 불일치(Inconsistency) 등 치명적인 스파게티 시스템 복잡도를 야기한다.

2. 통제권의 역전: 데이터 주도형(Data-driven) 실행 모델
데이터플로우 패러다임에서는 “메인 제어루프“가 존재하지 않는다. 전체 연산 기능은 상호 독립적이고 상태를 내포하지 않는(Stateless) 작업 단위(Node)들로 완전 분할된다. 각 단일 노드는 상위 의존성 데이터(Input)가 도착(Trigger)하는 즉시 자율적으로 연산을 시작하며, 결과 값을 인접한 하위 노드로 전파(Propagate)한 후 대기 상태로 전환된다.
명령이 데이터를 호출하는 것이 아니라, **‘데이터의 생성이 연산을 격발하는 현상’**이 시스템 전체로 확산되는 것이 분산 데이터플로우 파이프라인의 본질이다.

graph LR
    classDef sourceClass fill:#e1f5fe,stroke:#333,stroke-width:1px;
    classDef operatorClass fill:#fff3e0,stroke:#333,stroke-width:1px;
    classDef sinkClass fill:#e8f5e9,stroke:#333,stroke-width:1px;

    subgraph "Hardware Node A (Edge Sensor)"
        S1[Camera Source<br>60FPS Stream]
    end

    subgraph "Hardware Node B (GPU Server)"
        O1[Object Detection<br>AI Inference]
        O2[Coordinate<br>Transformation]
    end

    subgraph "Hardware Node C (Robot Controller)"
        K1[Motor Command<br>Sink]
    end

    S1 -->|Raw RGB Frames| O1
    O1 -->|Bounding Boxes| O2
    O2 -->|Kinematic Vectors| K1

    class S1 sourceClass;
    class O1,O2 operatorClass;
    class K1 sinkClass;

2. Zenoh 기반 분산 데이터 컴퓨팅의 필요성 및 장점

현대 소프트웨어 생태계에는 다수의 파이프라인 및 워크플로우 엔진이 존재함에도 불구하고, 로보틱스 및 에지(Edge) 인프라에 Zenoh-Flow가 최적의 솔 솔루션으로 지목되는 공학적 근거는 다음과 같다.

1. 네트워크 위상의 완벽한 추상화 (Location Transparency)
ROS2나 Python 기반 멀티프로세싱 체계는 주로 로컬 호스트(Localhost) 및 분절되지 않은 서브넷 내부에서의 파이프라인 동기화에 국한된다. 그러나 연산 노드가 5G(WAN) 환경이나 방화벽 너머의 퍼블릭 클라우드에 배치될 경우, 개발자는 IP 하드코딩 및 소켓 예외 처리에 매몰된다.
Zenoh-Flow는 전송 계층 전체를 Zenoh 프로토콜 기반 라우팅으로 치환하였다. 노드가 이기종 망 속 어디에 흩어져 있든(Location-Agnostic), 노드 소스 코드 변경 없이 선언적 YAML 설정표만으로 전 지구적 파이프라인 그래프(Graph)를 유연하게 봉합(Bind)한다.

2. 통신 비용 계층별 최적화 (Adaptive Zero-copy Strategy)

  • 단일 호스트 내부 (Local Process): Zenoh-Flow는 노드 간 전송 시 네트워크 루프백(Loopback) 통신을 수행하지 않는다. 공유 메모리(Shared Memory) 상에서 메모리 포인터만을 교환하는 제로 카피(Zero-Copy) 기법을 자동 활성화하여 페이로드 크기나 대역폭 제약을 상쇄한다.
  • 분산 호스트 간 (Remote Edge): 물리적 노드가 서로 격리된 상태임이 판별될 때만 Zenoh의 고도화된 바이너리 멀티캐스트 터널(TCP/QUIC/UDP)을 개통하여 최단 라우팅 패킷 전송을 수행한다.

3. 마이크로서비스 아키텍처(MSA) 및 액터 모델(Actor Model)과의 비교

로보틱스 분산 환경을 설계함에 있어 MSA 등 인접 소프트웨어 패턴과 데이터플로우(Zenoh-Flow) 모델 간의 아키텍처적 적합성을 면밀히 감별해야 한다.

1. 마이크로서비스 아키텍처 (gRPC / REST API)

  • 특성: 클라이언트가 필요한 시점에 상태 전이 요청 구조(Request/Response)를 발생시킨다.
  • 부적합 이유: 로봇의 센서에서 쏟아지는 초당 기가바이트(GB) 스트리밍 원시 데이터를 마이크로서비스로 주입할 경우 직렬화(Serialization) 오버헤드와 HTTP/gRPC 커넥션 풀의 고갈(Exhaustion)에 직면하게 된다.

2. 액터 모델 (Actor Model, e.g., Erlang / Akka)

  • 특성: 액터라 불리는 각 주체가 우편함(Mailbox)을 통해 상태 정보 변환 메시지를 주고받으며 독립 실행된다.
  • 부적합 이유: 액터 모델은 수많은 엣지 케이스를 지닌 마이크로 루틴의 병렬 분기(State Machine)에 유리하지만, 매트릭스(Matrix) 연산이나 텐서(Tensor) 등 육중한 파이프라인 조각들을 선형적으로, 그리고 병렬 분산 환경(Distributed Parallel Compute) 하에 일괄 유수(Flow) 제어하기에는 프레임워크 성질이 부적절하다.

3. 데이터플로우 파이프라인 (Zenoh-Flow)

  • 특성: 명시적 API 계약이나 우편함 관리가 필요 없으며, 철저히 상향식 그래프 포트 계층을 통해 고밀도 텐서 배열 등이 무정지(Zero-stall) 컨베이어 구조로 쏟아져 관통하는 데 최적화된 산업 계산용 물류 인프라스트럭처다. AI 추론 모델, 고주파 신호 처리(DSP) 등 원시 자원이 끊임없이 소비되는 연산 파이프 구조에서 가장 탁월한 메커니즘을 제공한다.

4. 기존 스트림 엔진(Apache Kafka, Flink)과의 생태계 지향성 차이

대규모 빅데이터 및 엔터프라이즈 서버군에서 보편적으로 사용되는 스트림 파이프라인 엔진과 IoT/로보틱스 에지에 뿌리를 둔 Zenoh-Flow의 철저한 지향점 분기를 이해해야 한다.

1. 런타임 덩치와 엔진 오버헤드 (JVM vs. Native Rust)

  • Kafka / Flink: 자바 가상 머신(JVM) 의존성이 막대하여 구동 및 유지보수에 수 기가바이트 수준의 램(RAM) 용량과 무거운 가비지 컬렉션(GC) 런타임을 요구한다. 이는 임베디드 단말이나 자율주행 차단막 제어 보드 환경에서는 구동을 보장할 수 없는 자원 탕진 구조다.
  • Zenoh-Flow: 순수 C/C++ 및 Rust 런타임 코어로 컴파일되어 초소형 마이크로시스템 환경에서도 수십 메가바이트(MB) 이하의 극보수적 점유율을 차지하며 네이티브 하드웨어 가속(Native CPU/GPU Acceleration)을 직결할 수 있다.

2. 데이터 매개 브로커(Broker) 결여의 극강의 장점

  • Kafka: 모든 발행 데이터 조각은 불변 로그(Log Append) 형태로 강력하고 거대한 중앙 집중 노드(Brokers)의 디스크 버퍼에 일차 수용되었다가 복제된 후 밖으로 토출된다.
  • Zenoh-Flow: 브로커 노드가 일절 배제된 순수한 파이프-투-파이프 네트워크 아키텍처다. 에지 노드에서 창출된 데이터는 그 자체로 전산 노드(Worker) 코어로 P2P(Peer-to-Peer) 직행 분배되며, 지연 시간(Latency)은 0.01ms 수준까지 압축된다. 즉, 데이터의 ’보관’이 아닌 철저하고 기민한 실시간 ’가공과 파생’의 연속을 위한 도구다.

5. 클라우드-에지 융합(Edge-to-Cloud Continuum)의 주요 활용 분야

단일 하드웨어 내의 파이프라인을 구축하는 것을 넘어선, 즉 클라우드 서버 클러스터부터 에지 디바이스 말단에 이르기까지 전산 능력을 연결집적(Federated Computation)하는 Zenoh-Flow의 타겟 도메인은 다음과 같다.

1. 분할 인공지능 (Split AI Inference 및 Federated Learning)
에지 디바이스(로봇 전방 카메라)는 상대적으로 경량화된 합성곱 신경망(Lightweight CNN) 모델로 초기 국소 데이터 텐서나 특징점을 추출한 뒤 이를 Zenoh-Flow 파이프 투입구(Source)로 흘려보낸다. 전력 여유가 높은 지하실 딥러닝 서버군(Operator)은 이 압축 텐서를 수신하여 대규모 데이터베이스와 일치 확인하는 다단계 딥러닝 체인을 수행 후 판독 결과를 반환(Sink)한다.

2. 다중 자율주행 차량 간의 협력적 센서 퓨전 (Cooperative Sensor Fusion)
교차로 등 사각지대 환경 내에서, 선행 자율주행 개체와 주변 환경 인프라(V2X RSU 노드)가 취득한 부분 전경 포인트 클라우드(Point Cloud Map)를 실시간으로 합산, 회전 변환 행렬 도출 필터(Transform Operator) 노드에 분배하여 단일 차량이 파악할 수 없는 전체 지형 데이터를 단일 거대 계산망 내에서 파생해낸다.

3. 지능형 스마트팩토리 비전 불량 검출 네트워크
전체 조립 라인(1~100 스테이션)에서 개별적으로 구동되는 비전 스냅샷 소스(Source) 모듈군으로부터 파생되는 고해상도 이미지 스트림을 병렬 수합 파이프(MUX Node) 구조를 통해 소수 GPU 분석 전용 서버(Operators)군으로 자동 밸런싱 인입 시킴으로써, 자원 분배 효율성과 불량률 판정 연산 단계를 물리적 통신망 구속력 없이 선언형 매니페스트로 재배치할 수 있다.