13.4.4.1 사다리타기(Fork) 및 합치기(Join) 무제한 허용 아키텍처와 오버헤드 최소화

13.4.4.1 사다리타기(Fork) 및 합치기(Join) 무제한 허용 아키텍처와 오버헤드 최소화

단일한 센서 소스에서 폭포수처럼 떨어지는 데이터 스트림을 단순히 하나의 필터 노드로만 통과시키는 파이프라인은 초보적인 선형(Linear) 공정에 불과하다.
진보된 로보틱스 자율주행 파이프라인에서는 자율차의 전방 카메라가 포착한 단 하나의 원본 픽셀 데이터 블록을 가지고, 동시에 “Yolo 기반의 차선 인식(Lane Detection)”, “보행자 추적(Pedestrian Tracking)”, 그리고 “클라우드 VOD 저장을 위한 압축(Compression)” 이라는 세 마리 토끼를 동시에 때려잡아야만 한다.

데이터 파형 하나를 여러 갈래로 찢어버리는 사다리타기(Fork/Split) 와, 갈라진 여러 파생 데이터를 하나의 통제 연산구(Sink)로 다시 병합시키는 합치기(Join/Merge) 과정은 필연적으로 메모리 복사와 병목을 유발한다. 본 절에서는 Zenoh-Flow 선언적 매니페스트 안에서 멀티팬아웃(Multi-Fanout) 연결망을 무제한으로 허용하면서도, 치명적인 복사 연산 오버헤드(Zero-copy Overhead)를 학살해버리는 기술적 런북을 설파한다.

1. 무한 직조(Infinite Weaving): 분기(Fork)와 병합(Join)의 선언

Zenoh-Flow 파이프라인 야믈(YAML) 상에서, 하나의 퍼블리셔(Output) 포트는 오직 1개의 Input 포트에만 연결되어야 한다는 폐쇄적 룰은 존재하지 않는다.
특정 노드의 단일 Output 배관은 10개든 100개든 원하는 만큼 무제한(Unrestricted)으로 타 노드들의 Input 구멍에 꽂아 넣어 문어발식 팬아웃(Fan-out / Fork)을 완성할 수 있다.

# [Fork(다중 분기) 강제 생성 매니페스트 런북]
links:
  # 카메라 원본(RawFrame_Out) 하나가 3개의 각기 다른 노드 구멍으로 맹렬하게 갈라진다
  - from: { node: "front_cam", output: "RawFrame_Out" }
    to: { node: "lane_detector", input: "Image_In" }
    
  - from: { node: "front_cam", output: "RawFrame_Out" }
    to: { node: "pedestrian_tracker", input: "Image_In" }
    
  - from: { node: "front_cam", output: "RawFrame_Out" }
    to: { node: "db_archiver", input: "Image_In" }

이와 역으로, 여러 노드에서 뻗쳐 나온 결과물들(Output)을 거대한 단일 융합(Fusion) 연산자의 다중 Input 포트들로 집어넣어, 갈라졌던 운명을 다시 하나의 의사결정으로 합치기(Join) 하는 것 역시 완벽히 대칭적인 문법으로 지원된다. 분산 스트림 모델에서 그래프 직조의 자유도는 극한까지 풀려있다.

2. 딥 카피(Deep Copy)의 재앙과 런타임 제로 카피(Zero-Copy) 메커니즘

그러나 1개의 영상 프레임을 3개의 노드로 분기(Fork)시켰다는 것은 운영체제의 RAM 관점에서는 엄청난 공포의 시작이다.
3MB짜리 FHD 원본 이미지 배열이 3개의 다른 오퍼레이터 구멍으로 들어갈 때마다, 멍청한 미들웨어는 C++ 포인터 메모리 할당(malloc)과 복제(memcpy)를 3번이나 강제하여 9MB의 RAM 대역폭 버스를 산산조각 내버린다.

이 지독한 오버헤드를 진압하기 위해, Zenoh-Flow 런타임은 분기(Fork) 배관이 선언된 양측 노드가 “동일한 물리적 컴퓨터(Edge Host)” 내에 위치하는가를 1차로 판별한다. 만약 그렇다면 데몬은 즉결적으로 딥 카피(Deep Copy) 루프를 도살해버린다.

대신 Arc (Rust) 또는 std::shared_ptr (C++) 와 같은 레퍼런스 카운팅(Reference Counting) 포인터 락기법을 발동시킨다. 3MB의 카메라 영상 버퍼는 힙(Heap) 메모리 한구석에 고고하게 1번만 안착되어 있으며, 3개의 개별 노드 스레드들에게는 오직 “그곳의 주소(Address)“를 가리키는 8바이트짜리 참조표(Reference)만 가벼운 깃털처럼 던져진다. RAM 자원 소비는 1 Fork든 100 Fork든 완벽한 수학적 상수인 O(1) 의 비용으로 수렴(Convergence)하게 된다.

3. 원격 팬아웃(Remote Fan-out) 시의 멀티캐스트 폭발

만약 카메라 영상이 Fork 된 3개의 노드 중, 두 노드는 또 다른 로봇 컴퓨터(원격 망)에 존재한다면 어찌할 것인가?
TCP 유니캐스트 기반으로 3대의 원격 로봇에게 똑같은 3MB 화면을 따로따로(1:1) 전송한다면, LTE 라우터 공유 안테나는 네트워크 쓰루풋 피크를 견디지 못하고 불타버린다.

Zenoh 라우터망은 이 원격 사다리 분기(Remote Fork) 트래픽을 인지한 순간, 밑단의 L2/L3 네트워크 인프라 협업을 요청하여 와이어 프로토콜을 UDP 멀티캐스트(Multicast) 패브릭으로 둔갑시킨다. 송신측 원본 노드는 허공에 3MB짜리 데이터를 단 한 번만(Single Shot) 쏘아 날리고, 네트워크망의 스위치 분배기가 이를 복제하여 수십 대의 원격지 워커 파드(Pod)들에게 우수수 부어버리는 하드웨어 가속 강제 스킵핑이 자행된다.

사다리타기(Fork)와 합치기(Join)의 무제한 분기 허용은 아키텍트에게 무한한 뇌내 논리 창조의 권능을 열어주지만, 그 밑바닥에는 런타임 엔진이 메모리 포인터 복사본과 네트워크 브로드캐스트를 칼같이 제어해 내는 처절한 “오버헤드 학살극“이 뒷받침되어 있음을 영원히 명심해야 한다.