11.2 Zenoh를 ROS2에 통합하는 두 가지 핵심 아키텍처

11.2 Zenoh를 ROS2에 통합하는 두 가지 핵심 아키텍처

ROS2의 거대한 인프라를 한꺼번에 뜯어고칠 수는 없다. 때문에 Zenoh 개발진은 시장의 레거시(Legacy) 공포증을 해소하기 위해 완전히 다른 철학을 가진 2가지 통합 루트(Route)를 만들었다.

  1. 내부망은 DDS로 내버려 두고 클라우드로 나갈 때만 문지기(Bridge)를 두는 방식.
  2. 아예 로봇의 심장(RMW)을 적출하여 Zenoh 로 갈아 끼우는 방식.

이 장에서는 당신의 프로젝트 데드라인과 로봇 성능 한계에 맞춰 어떤 아키텍처를 선택해야 하는지 판별하는 아키텍트의 기준을 세운다.

1. 브릿지 기반 통합 (zenoh-bridge-dds)의 개념과 특징

가장 현실적이고 피를 덜 흘리는 전술이다. 로봇의 뇌(ROS2)는 자기가 아직도 DDS를 쓰고 있다고 믿게 만든 채로, 네트워크 밖으로 나가는 데이터만 Zenoh 가 몰래 가로채는 방식이다.

1.0.1 [인스펙션] 브릿지 아키텍처의 비-침투성 (Non-Intrusive)

1. 구조적 분리
로봇 내부에서는 FastDDS 가 그대로 돌아간다. 모터 제어 노드, 카메라 노드는 모두 DDS 로 대화한다. 하지만 이 로봇의 가장 가장자리에 zenoh-bridge-dds 라는 프로세스를 딱 하나 띄워둔다.
이 브릿지는 로봇 내부의 DDS 패킷을 모두 엿듣다가(Sniffing), 클라우드로 보내야 할 토픽들만 낚아채어 Zenoh 패킷으로 압축한 뒤 외부망(WAN)으로 던져버린다. 클라우드에서 온 Zenoh 명령은 다시 DDS 패킷으로 번역하여 로봇 뇌에 주입해 준다.

2. 언제 이 방식을 써야 하는가?

  • 기존 로봇의 펌웨어 소스코드를 수정할 권한이 없을 때. (블랙박스 로봇)
  • ROS2 호환성이 극도로 중요한 레거시 자율주행 스택(Nav2, MoveIt)을 그대로 써야만 할 때.
  • 로봇 안에서의 통신은 DDS 로도 문제없이 도달하지만, “사무실에 있는 관제 웹 대시보드” 에 연동할 구멍(Hole)만 필요할 때.

이 방식의 유일한 단점은 “브릿지 통역원” 이 패킷을 번역하느라 수 밀리초(ms)의 지연(Latency)과 약간의 CPU 부하가 발생한다는 것이다.

2. 기본 RMW 계층 통합 (rmw_zenoh)의 개념과 특징

“통역관의 대기 시간조차 아깝다.”
극한의 성능충, 5G 군집 드론을 개발하는 하드코어 엔지니어들을 위한 전술이다. ROS2 의 가장 밑바닥 네트워킹 심장 구조를 털어버리고 직접 Zenoh 엔진 스왑(Engine Swap)을 시전한다.

2.0.1 [인스펙션] 심장 이식 아키텍처 (Native Integration)

1. 구조적 병합
ROS2 는 설계 단계부터 RMW(ROS Middleware)라는 추상화 계층을 두어 통신 엔진을 갈아 끼울 수 있게 만들었다. 이 자리에 rmw_zenoh_cpp 를 냅다 꽂아버리면, rclcpp::create_publisher 로 생성된 코드들은 내부적으로 단 한 번의 번역 과정 없이 곧바로 순수 Zenoh 패킷을 찍어내기 시작한다.
DDS의 그 무거운 라이브러리(libfastrtps 등)는 아예 메모리에서 증발한다.

2. 통계적 학살 (Statistical Slaughter)
이 방식을 쓰면, 그 끔찍했던 멀티캐스트(Multicast) 디스커버리 트래픽 폭풍이 0 에 수렴한다. DDS 브릿지가 번역하며 까먹던 CPU 사이클과 버퍼 복사(Copy) 오버헤드도 완전히 소멸된다.

3. 언제 이 방식을 써야 하는가?

  • 처음부터 새롭게 ROS2 프로젝트를 시작하는 스타트업.
  • 드론이나 초소형 로봇처럼 CPU와 메모리가 극도로 모자란 스펙(Raspberry Pi Zero 등) 위에 ROS2 를 억지로 올려야 할 때.
  • 수백 대의 로봇 군집(Swarm) 제어 시, 통신 충돌(Collision)에 의한 지연을 물리적으로 박살 내야 할 때.

3. 프로젝트 규모와 네트워크 환경에 따른 통합 방식 선택 가이드

브릿지를 쓸 것인가, 아니면 심장(RMW)을 파낼 것인가?
책임질 수 없는 선택으로 시스템을 박살 내기 전, 로봇 아키텍트가 검열해야 할 조건들을 런북 체크리스트로 벼려냈다.

3.0.1 [Runbook] ROS2 아키텍처 노선 분기(Branching) 체크리스트

[1번 분기: 하드웨어 성능의 여유분]

  • 로봇의 메인 컴퓨터가 X86 i5 급 이상 인가? -> zenoh-bridge-dds (브릿지 번역 오버헤드를 CPU 힘으로 찍어 누른다).
  • 로봇의 두뇌가 ARM Cortex-A53 / Raspberry Pi 수준인가? -> 당장 rmw_zenoh 로 도망쳐라. 브릿지를 쓰면 CPU 코어 하나가 통역하느라 다 타버린다.

[2번 분기: 통신망의 본질적 폐쇄성]

  • 통신이 서로 다른 방화벽 이나 사설망(5G NAT, 클라우드 VPC) 을 넘나들어야 하는가? -> rmw_zenoh 기본 채택 1순위. (DDS 는 NAT 를 뚫는 데 한계가 있다).
  • 오직 보안 철조망 내부 공장 Wi-Fi 에서만 돌고, 모니터링만 외부로 보내면 되는가? -> zenoh-bridge-dds. (가장 안전하게 레거시 유지).

[3번 분기: 규제와 호환성 (레거시 코드 베이스)]

  • 기존 프로젝트가 DDS 특유의 미친듯한 QoS 세팅(Lifespan, Liveliness, History)에 뼈저리게 결합되어 있는가? -> zenoh-bridge-dds. (아직 rmw_zenoh 는 DDS 의 변태적인 극세사 QoS 까지 100% 모방하진 못한다).

아키텍트의 최종 결론:
“완성된 제품 위에 모니터링 구멍 하나 뚫어야 하면 브릿지 를 쓰고, 차대부터 새로 뽑아 클라우드 관제를 올릴 거면 처음부터 RMW Zenoh 를 박아라.”