제3부 미들웨어: DDS·RTPS·RMW

3.6 미들웨어 벤더 비교

3.6.1 이 장에서 배우는 것 / 선수 지식

"어떤 RMW가 제일 좋은가"는 이 책이 답하지 않는 종류의 질문이다(BK-04). 벤치마크 결과는 하드웨어·메시지 크기·엔티티 수·QoS 조합에 따라 뒤집히고, 시점에 따라 달라지며, 인터넷의 비교표는 대개 자신의 시스템과 다른 조건에서 측정된 것이다.

대신 이 장은 판단하는 법을 다룬다. 어떤 축으로 비교하고, 무엇을 자신의 환경에서 측정하고, 성능 외에 어떤 요소가 실제 결정을 좌우하는가.

배우는 것:

• 벤더 현황 — 누가 있고 각자 무엇을 지향하는가.
• REP 2000의 티어 — "지원된다"의 공식적 의미.
• 비교 축 여덟 가지 — 성능은 그중 하나일 뿐이다.
• 자기 환경에서 평가하는 절차 — 벤치마크를 직접 만드는 법.
• 선택 프레임워크 — 상황별 ①②③.
• 결정을 미루는 비용 — 왜 초기에 정해야 하는가.

선수 지식: 3.5(RMW 계층·교체 비용), 3.3(디스커버리), 3.2(RTPS), 1.5(QoS).

정직: 이 장에는 성능 수치가 없다. 인용하지 않는 것이 정직하기 때문이다 — 공개된 벤치마크는 특정 조건의 결과이고, 그 조건은 대개 독자의 환경과 다르다. 벤더의 티어·지원 상태·기능 유무는 시점 의존 정보이므로 (확인 필요)로 표시하고, REP 2000과 각 벤더 문서의 현재 상태를 확인하라고 안내한다(목차 3). 아래 성향 서술은 각 프로젝트의 공개된 설계 목표와 문서에 근거한 일반적 이해다. 141차(120번째 회차)가 apt 저장소 조회로 이 장에 실린 다섯 벤더 전부의 Jazzy·Humble 패키지 가용성을 실행 확인했다 — 3.6.2를 보라.

3.6.2 벤더 현황

정직: 위 목록은 널리 알려진 것들이며 전수가 아니다. 또한 각 구현의 Jazzy 지원 여부·티어·유지 상태는 시점에 따라 변한다 — REP 2000과 각 저장소의 현재 상태를 확인해야 한다(확인 필요). 특히 상용 벤더의 배포판 지원은 계약·버전에 따라 다르다.

실행 확인(141차, 2026-08-20, ros:jazzy-ros-base·ros:humble-ros-base의 표준 ROS apt 저장소). apt-cache search rmw-로 위 다섯 벤더 전부의 Jazzy·Humble 패키지 존재를 확인했다 — ros-jazzy-rmw-fastrtps-cpp·-cyclonedds-cpp·-connextdds·-gurumdds-cpp·-zenoh-cpp 모두 apt에 있다. GurumDDS의 "Jazzy 지원 상태"(위 표의 (확인 필요))는 이걸로 답이 나온다 — 최소한 apt 패키지 수준에서는 Jazzy를 지원한다. apt-get install --dry-run으로 실제 설치 가능성도 확인했다: ros-jazzy-rmw-gurumdds-cpp는 gurumdds-3.2 하나만 추가로 끌어와 문제없이 해결됐고, ros-jazzy-rmw-zenoh-cpp도 zenoh-cpp-vendor 하나만으로 해결됐다. ros-jazzy-rmw-connextdds는 흥미로운 점을 보였다 — rti-connext-dds-6.0.1이라는 RTI Connext DDS 런타임 자체를 ROS apt 저장소가 직접 패키징해 함께 설치한다(외부 RTI 계정·별도 다운로드 없이 apt install 하나로 끝난다). 다만 이것이 연구용/평가판 라이선스인지 전체 상용 자격인지는 이번 회차에 확인하지 못했다(확인 필요) — "상용" 딱지가 여전히 유효한 이유다(제품 배포 시 라이선스 조건은 RTI에 직접 확인해야 한다). rmw_cyclonedds_cpp는 실제로 설치·실행까지 완료했다(3.5.3·3.5.4에서 재사용). GurumDDS·zenoh·Connext는 dry-run까지만 하고 실제 설치·실행은 이번 회차에 하지 않았다(용량·시간 예산). 목차 3, tools/gap_harness/gap141.

성향의 차이를 이해하는 것이 표보다 중요하다:

• Fast DDS는 기능을 많이 제공하는 방향이다. Discovery Server(3.4), 공유메모리 전송, 상세한 XML 프로파일(3.7). 손잡이가 많고, 그래서 배울 것도 많다.
• Cyclone DDS는 단순함과 예측 가능성을 지향한다. 설정이 간결하고 코드베이스가 작다. 손잡이가 적은 대신 기본 동작이 견고하기를 노린다.
• Connext는 상용 스택의 강점 — 도구(모니터링·기록·분석), 문서, 지원 계약, 인증 관련 자료. 안전 인증이 필요한 프로젝트에서 검토된다(14.10).
• zenoh는 완전히 다른 접근이다. DDS의 LAN 전제를 버리고 무선·WAN·대규모를 처음부터 겨냥했다(3.10).

3.6.3 REP 2000의 티어 — "지원된다"의 의미

REP 2000은 플랫폼과 RMW의 지원 티어를 정의한다. 이것이 "지원된다"는 말의 공식적 근거다.

실무적 함의:

정직: Jazzy에서 각 RMW의 정확한 티어는 REP 2000을 직접 확인해야 한다(확인 필요). 티어는 배포판마다 바뀌며, 이 책의 서술이 오래될 수 있다. 기본 RMW가 rmw_fastrtps_cpp라는 것은 BK-05에 명시된 이 책의 기준이며, 그것이 Tier 1이라는 점은 안전한 가정이다.

견해: 제품 시스템이라면 Tier 1을 벗어날 때 그 결정을 문서화하라. "성능이 더 좋아서 Tier 2를 쓴다"는 유효한 판단일 수 있지만, 문제가 생겼을 때 커뮤니티 지원이 얇다는 대가를 팀이 알고 있어야 한다. 특히 배포판 업그레이드 시 Tier 2·3 구현이 뒤늦게 따라오거나 지원이 완전히 끊길 수 있다(15.1).

3.6.4 비교 축 여덟 가지

성능은 여덟 축 중 하나일 뿐이며, 실제 결정에서 지배적이지 않은 경우가 많다.

① 성능 — 지연·지터·처리량·CPU·메모리.

• 주의: 워크로드에 따라 순위가 바뀐다. 작은 메시지 고빈도와 큰 메시지 저빈도는 다른 결론을 준다.

② 확장성·디스커버리 — 노드 수가 늘 때의 거동, Discovery Server 같은 대안 제공(3.3·3.4).

• 주의: 참가자 매핑 방식이 여기 직결된다(3.3.5).

③ 네트워크 적합성 — 무선·손실 링크·WAN·서브넷 경계·멀티캐스트 없는 환경(3.9).

• 실무에서 자주 결정적이다. 성능이 좋아도 우리 네트워크에서 디스커버리가 안 되면 소용없다.

④ 기능 — loaned message·공유메모리(2.6·2.7), 보안(13.3), 특수 전송(TCP — 3.2.9).

⑤ 라이선스·비용 — 오픈소스 여부, 상용 라이선스 조건, 재배포 조건.

• 제품 출하 시 법무 검토가 필요한 영역이다. 개발용 무료와 배포용 유료가 다른 경우가 있다.

⑥ 지원·생태계 — 티어, 문서 품질, 커뮤니티 활성도, 상용 지원 계약, 이슈 대응 속도.

⑦ 운영·설정 복잡도 — XML 학습 비용, 디버깅 도구, 팀이 감당할 수 있는가.

• 과소평가되는 축이다. 튜닝 여지가 많다는 것은 튜닝해야 한다는 뜻이기도 하다.

⑧ 인증·규제 — 안전 인증(ISO 26262·IEC 61508) 관련 자료, 추적성 문서(14.10).

• 해당되는 프로젝트에서는 다른 모든 축을 압도한다.

견해: 팀이 실제로 겪는 문제는 ③·⑥·⑦에서 나오는 경우가 많다. "지연이 20% 낮다"보다 "우리 Wi-Fi에서 디스커버리가 된다", "문제가 생겼을 때 검색하면 답이 나온다", "설정 파일을 팀원이 이해할 수 있다"가 실제 운영을 좌우한다. 성능 벤치마크로 벤더를 고르고 나머지에서 고생하는 패턴을 여러 번 볼 수 있다.

3.6.5 자기 환경에서 평가하는 절차

남의 벤치마크 대신 자기 워크로드로 측정하는 것이 이 절의 목표다.

1. 대표 워크로드 정의 — 실제 시스템을 축약한 것이어야 한다.

함정: 유선 개발 환경에서 측정하고 무선 로봇에 배포하는 것이 가장 흔한 평가 실수다. ③(네트워크 적합성)은 실제 네트워크에서만 드러난다.

2·4. 측정 항목

# 종단 지연 (2.7.8) — 가장 중요
# 헤더 스탬프 기반, p50 · p99 · max

# 처리량
ros2 topic hz /topic --window 1000
ros2 topic bw /topic

# CPU · 메모리
top -H -p $(pgrep -f my_node)
ps -o rss,vsz -p $(pgrep -f my_node)

# 디스커버리 시간
# 노드 시작 → 첫 데이터 수신까지 측정

# 디스커버리 트래픽 (3.2.8)
sudo tcpdump -i any -w d.pcap 'udp portrange 7400-7700'

측정 원칙:

3. 교체는 환경변수 하나지만, 검증은 3.5.6의 목록 전체다.

5. 비기능 축 평가

- 문서를 읽고 원하는 설정을 찾는 데 얼마나 걸렸나?
- 문제를 검색했을 때 답이 나오는가?
- 팀원이 설정 파일을 이해할 수 있는가?
- 라이선스가 우리 배포 형태에 맞는가?
- 이 벤더가 다음 LTS를 지원할 것으로 보이는가?

6. 결정 문서화 — 이것이 자주 생략되고 나중에 비용이 크다.

## RMW 선택: rmw_fastrtps_cpp
- 결정일: 2026-08-13
- 근거: ① 우리 Wi-Fi에서 멀티캐스트가 불안정 → Discovery Server 필요
        ② Tier 1, 팀이 XML 프로파일 경험 있음
        ③ 지연은 후보 간 유의미한 차이 없었음(측정 첨부)
- 대가: XML 설정이 벤더 전용 → 교체 시 재작성 필요(3.5.6)
- 재검토 시점: 다음 LTS 이행 시

3.6.6 선택 프레임워크

① 기본값을 쓴다 — rmw_fastrtps_cpp

• 맞는 경우: 대부분. 특히 시작 단계, 표준 LAN 환경, 팀에 미들웨어 전문성이 없을 때.
• 근거: Tier 1, 기본값이라 문서·예제·질의응답이 가장 많다. Discovery Server 같은 확장 수단이 준비되어 있다.
• 대가: 손잡이가 많아 설정이 복잡할 수 있다.

② 단순함을 택한다 — rmw_cyclonedds_cpp

• 맞는 경우: 설정을 최소로 두고 싶을 때, 기본 동작으로 충분할 때, 코드베이스가 작은 것을 선호할 때.
• 근거: 간결한 설정, 예측 가능한 동작 지향.
• 대가: Discovery Server 같은 Fast DDS 전용 기능을 못 쓴다. 대안을 따로 찾아야 한다.

③ 상용 지원을 구매한다 — Connext 등

• 맞는 경우: 안전 인증이 필요한 프로젝트, 지원 계약이 요구되는 조직, 상용 도구가 필요한 경우.
• 근거: 문서·도구·지원·인증 자료.
• 대가: 라이선스 비용, 벤더 종속.

④ 미들웨어를 바꾼다 — rmw_zenoh_cpp

• 맞는 경우: 무선·WAN·플릿이 본질적 문제일 때. DDS의 LAN 전제가 맞지 않는 시스템.
• 근거: 처음부터 다른 네트워크 가정 위에 설계(3.10).
• 대가: 생태계 성숙도, 도구·문서가 DDS 대비 얇을 수 있다(확인 필요).

견해: 대부분의 팀에게 정답은 ①이다. 그리고 그것은 소극적 선택이 아니라 합리적 선택이다 — 기본값을 쓰면 문제가 생겼을 때 같은 문제를 겪은 사람이 많고, 그 자체가 큰 가치다. 벤더를 바꿔야 할 구체적이고 측정된 이유가 생기기 전까지는 기본값을 유지하라.

3.6.7 결정을 미루는 비용

"나중에 정하자"가 왜 위험한가.

반대로, 초기에 정하면 얻는 것:

• 튜닝 노력이 한 방향으로 축적된다.
• 팀이 하나의 도구 체계를 깊이 익힌다.
• 성능 기준선이 일관되게 유지된다.

견해: RMW 선택은 "언제든 바꿀 수 있는 설정"이 아니라 "아키텍처 결정"으로 취급하라. rmw 추상 덕분에 기술적으로는 바꿀 수 있지만, 조직적·검증적으로는 비용이 크다. 2.1.9에서 말한 것의 반복이지만, 실무에서 반복해서 틀리는 지점이라 다시 강조한다.

3.6.8 함정 카탈로그

3.6.9 체크포인트

• 주요 RMW 구현 다섯 가지와 각자의 지향을 말할 수 있는가. zenoh가 다른 넷과 근본적으로 다른 점은?
• REP 2000의 티어 세 가지가 실무적으로 무엇을 의미하는가. Tier 1을 벗어날 때 문서화해야 하는 이유는?
• 비교 축 여덟 가지를 들 수 있는가. 실제 팀이 가장 자주 고생하는 축 셋은 무엇이라고 보는가.
• 자기 환경 평가 절차 여섯 단계를 말할 수 있는가. 대표 워크로드에 반드시 포함해야 할 것은?
• 평가에서 가장 흔한 실수는 무엇인가.
• 측정 원칙 다섯 가지를 들 수 있는가. 왜 평균이 아니라 백분위수인가.
• 선택 프레임워크 ①②③④ 각각이 맞는 상황과 대가를 말할 수 있는가. 대부분의 팀에게 정답은 무엇이며 왜 그것이 소극적 선택이 아닌가.
• RMW 결정을 미룰수록 커지는 비용 여섯 가지를 들 수 있는가.
• "RMW 선택은 설정이 아니라 아키텍처 결정"이라는 명제를 3.5.6과 연결해 설명할 수 있는가.

다음 두 장(3.7·3.8)은 선택한 벤더를 실제로 튜닝하는 방법이다. 먼저 Fast DDS의 XML 프로파일·전송·메모리 정책(3.7), 그 다음 Cyclone DDS의 설정 체계(3.8).