본 보고서는 LiDAR, 카메라, IMU, GNSS, 콤파스 센서 융합을 통한 군집 드론 자율 비행 연구라는 명확한 목표를 달성하기 위한 최적의 ROS2(Robot Operating System 2) 배포판 선정을 목표로 한다. 이 선택은 단순히 최신 버전을 따르는 기술적 추종이 아닌, 프로젝트의 성공을 좌우하는 전략적 의사결정이다.
본 보고서에서 ‘성숙도’는 단순히 출시 시점이 오래된 것을 의미하지 않는다. 이는 다음 네 가지 핵심 기준으로 평가되는 다차원적 개념이다.
이 네 가지 기준을 분석의 틀로 삼아 ROS2 Humble Hawksbill과 ROS2 Jazzy Jalisco를 체계적으로 비교하고, 최종적으로 프로젝트의 특성에 맞는 시나리오별 권고안을 제시한다.
배포판 선택의 가장 기본적인 단계는 프로젝트의 시간적 범위와 하드웨어 제약 조건을 고려하는 것이다. 이는 기술 스택의 근간을 이루며, 장기적인 안정성과 유지보수성에 직접적인 영향을 미친다.
ROS2 배포판은 매년 5월 23일에 새로운 버전이 출시되며, 짝수 해에 출시되는 버전은 5년간의 장기 지원(LTS)을 제공한다.
이 2년의 차이는 단순한 시간 이상의 의미를 가진다. 만약 연구 프로젝트의 기간이 3년을 초과하거나, 개발된 시스템의 장기적인 유지보수가 중요한 경우, Jazzy의 긴 지원 기간은 명백한 전략적 이점이다. Humble을 선택할 경우, 2027년 이전에 다른 배포판으로 시스템 전체를 마이그레이션해야 하는 기술적 부채가 발생하며, 이는 상당한 시간과 비용을 수반한다. 따라서 Jazzy의 2년 더 긴 LTS는 2027년에 발생할 ‘강제 마이그레이션’ 비용을 2년 뒤로 미루거나 원천적으로 방지할 수 있는 중요한 가치를 지닌다.
ROS2 배포판은 특정 Ubuntu 버전에 강하게 의존하며, 이는 하드웨어 선택에 직접적인 영향을 미친다.
이러한 종속성은 특정 하드웨어, 특히 최신 임베디드 보드를 사용할 때 중요한 제약 조건으로 작용한다. 예를 들어, Raspberry Pi 5는 공식적으로 Ubuntu 22.04를 지원하지 않으므로, 네이티브 환경에서는 ROS2 Jazzy 사용이 사실상 강제된다. 물론 Docker와 같은 컨테이너 기술을 사용하여 Raspberry Pi 5에서 Humble을 구동하는 방법도 있지만, 이는 시스템 설정의 복잡성을 증가시키고 잠재적인 성능 오버헤드를 유발할 수 있다.
이러한 관계는 기술 스택 선택 과정에서 간과하기 쉬운 숨겨진 인과관계를 드러낸다. 연구팀은 종종 최고의 성능을 위해 최신 온보드 컴퓨터(예: NVIDIA Jetson 최신 모델)를 선택하고자 한다. 그러나 이러한 최신 하드웨어는 최신 OS(Ubuntu 24.04)에서 최적의 성능과 드라이버 지원을 제공하는 경향이 있다. Ubuntu 24.04는 ROS2 Jazzy를 위한 Tier-1 플랫폼이므로, 결국 ‘최고의 성능’을 위한 하드웨어 선택이 ‘최신이지만 아직 덜 검증된’ Jazzy 배포판 사용으로 이어지는 기술적 트레이드오프를 발생시킨다. 이는 안정성을 최우선으로 고려하는 팀에게는 매우 중요한 결정 요인이다. 따라서, 군집 드론에 사용할 온보드 컴퓨터의 사양과 OS 지원 여부를 먼저 확정하는 것이 전체 기술 스택을 결정하는 첫 단추가 된다.
군집 드론 시스템의 성공은 개별 드론의 성능만큼이나 드론 간의, 그리고 드론과 지상관제시스템(GCS) 간의 안정적인 통신에 달려있다. 이 관점에서 ROS2 배포판 간의 통신 호환성은 시스템의 근본적인 안정성을 결정하는 치명적인 요소다.
결론부터 말하자면, ROS2 Humble과 Jazzy는 동일 네트워크상에서 절대 혼용해서는 안 된다. 이는 단순한 권장 사항이 아닌, 시스템 전체의 안정성을 위한 필수 원칙이다.
이러한 비호환성의 근본적인 원인은 ROS2 Iron(Humble 다음, Jazzy 이전 배포판)부터 도입된 ‘Type Description Distribution’ 기능 때문이다. 이 기능은 메시지 타입에 대한 정보를 동적으로 공유하여 유연성을 높이지만, 이 과정에서 메시지를 네트워크로 전송하기 위해 직렬화(serialization)하는 방식에 근본적인 변화를 가져왔다. 구체적으로, Iron 이후 버전부터는 메시지에 타입 해시(type hash)와 같은 추가적인 메타데이터가 포함되는데, Humble은 이 구조를 이해하지 못한다.
이로 인해 발생하는 문제는 단순한 통신 실패를 넘어선다. Humble 기반의 노드가 실행 중인 네트워크에 Jazzy 노드가 연결되어 디스커버리 메시지를 보내는 것만으로도, Humble 노드에서 심각한 메모리 누수가 발생하여 수 초 내에 시스템 전체가 멈추는(Out-of-Memory) 현상이 보고되었다. 이는 군집 드론 운영 중 단 하나의 비호환 장비가 네트워크에 접속하는 것만으로도 전체 군집이 추락할 수 있는 치명적인 위험을 의미한다.
ROS 개발팀의 공식 입장 역시 명확하다. 그들은 서로 다른 배포판을 혼용하여 운영하는 시나리오를 테스트하지 않으며, 이에 대한 어떠한 호환성도 보장하지 않는다.
이 ‘배포판 혼용 불가’ 원칙은 단순히 드론 기체에만 국한되지 않는다. 군집 드론 연구 시스템은 비행하는 드론뿐만 아니라, 이를 제어하는 지상관제시스템(GCS), 비행 전 알고리즘을 검증하는 시뮬레이션 환경, 비행 후 데이터를 분석하는 컴퓨터, 그리고 개발자들의 개인 PC까지 포함하는 복잡한 생태계다. 이 모든 구성 요소들이 ROS 네트워크를 통해 상호작용하므로, Jazzy로의 전환 결정은 연구실 전체의 인프라를 동시에 업그레이드해야 하는 중대한 결정임을 의미한다. 하나의 구성 요소라도 다른 버전을 사용하게 되면, 전체 시스템의 안정성이 위협받을 수 있다.
배포판 간의 파괴적인 변화와는 대조적으로, 각 배포판의 수명 주기 내에서는 높은 수준의 안정성이 보장된다. ROS2는 특정 배포판(예: Jazzy)이 출시되면, 해당 버전의 지원이 종료될 때까지 API(Application Programming Interface) 및 ABI(Application Binary Interface) 호환성을 유지하는 것을 원칙으로 한다. 이는 Jazzy용으로 개발된 코드는 Jazzy의 다음 패치 릴리즈(예: Jazzy Patch 1 -> Patch 2)에서도 재컴파일 없이 동작해야 함을 의미하며, 이는 안정적인 시스템 운영에 필수적인 요소다. 새로운 기능 도입이나 구조적 개선을 위한 파괴적 변경(Breaking Changes)은 다음 배포판 출시 시에 이루어진다.
아래 표는 두 배포판의 안정성과 관련된 핵심 차이점을 요약한 것이다.
| 평가 기준 | ROS2 Humble Hawksbill | ROS2 Jazzy Jalisco | 핵심 근거 및 시사점 |
|---|---|---|---|
| 배포판 간 통신 호환성 | 불가능 (치명적 오류 발생) | 불가능 (치명적 오류 발생) | Humble 노드에서 심각한 메모리 누수 발생 가능. 연구실 내 모든 장비의 배포판 통일 필수. |
| 비호환성 기술 원인 | Pre-Iron (Type Hash 미적용) | Post-Iron (Type Hash 적용) | Iron 배포판부터 도입된 메시지 직렬화 방식의 근본적 차이. |
| 배포판 내 API/ABI 안정성 | 보장됨 | 보장됨 | 각 배포판의 LTS 기간 동안 안정적인 패치 및 업데이트 지원. |
안정성과 호환성이 시스템의 ‘기반’이라면, 기능성은 연구의 ‘가능성’을 결정한다. 군집 드론 자율 비행이라는 특정 목표 하에서, Jazzy는 Humble 대비 명백하고 강력한 기능적 우위를 제공한다.
Nav2는 ROS2의 표준 내비게이션 스택으로, 로봇의 자율 주행을 위한 핵심적인 기능들을 포함한다.
Nav2 기능만 놓고 본다면, Jazzy는 Humble에 비해 군집 ‘자율 비행’ 연구에 훨씬 더 적합하고 강력한 도구를 기본적으로 제공한다.
수십, 수백 대의 드론을 동시에 시뮬레이션해야 하는 군집 연구에서, 안정적이고 설정이 간편한 시뮬레이션 환경은 개발 효율성을 좌우하는 핵심 요소다.
gz_*_vendor라는 벤더 패키지를 통해 ROS2와의 통합을 대폭 간소화했다. 이는 복잡한 설정 없이도 안정적인 시뮬레이션 환경을 빠르게 구축할 수 있게 해준다.이러한 변화는 특히 대규모 군집 시뮬레이션 환경을 구축하고 유지보수해야 하는 연구팀에게 큰 이점이다.
미들웨어는 ROS2 노드 간의 통신을 책임지는 심장과 같다. Jazzy는 이 부분에서 가장 혁신적인 변화를 담고 있다.
rmw_zenoh)이다.
Zenoh의 등장은 Jazzy를 선택해야 하는 매우 강력한 이유가 된다. 이는 군집 드론 통신의 고질적인 문제였던 Wi-Fi 환경에서의 불안정성과 대역폭 한계를 극복할 수 있는 잠재력을 가졌기 때문이다. Zenoh의 도입은 단순히 통신 방법을 바꾸는 것을 넘어, 군집 드론 아키텍처 자체를 혁신할 기회를 제공한다. 기존 DDS 기반 시스템이 ‘어떻게든 통신을 안정시킬까’에 집중했다면, Zenoh 기반 시스템은 ‘이 넓은 대역폭으로 어떤 새로운 애플리케이션을 만들까’로 연구의 초점을 이동시킬 수 있다. 예를 들어, 각 드론이 촬영한 고화질 영상을 중앙 서버로 실시간 스트리밍하여 통합된 3D 모델을 생성하는 등의 고도화된 연구가 가능해진다.
rosbag2는 서비스(Service) 호출을 기록하고 재생할 수 있는 기능이 추가되었다. 이는 복잡한 분산 시스템에서 문제의 원인을 추적하고 디버깅하는 데 매우 유용하다.Jazzy의 기능 개선은 개별적으로도 뛰어나지만, 서로 결합될 때 더 큰 시너지를 낸다. 예를 들어, Gazebo Harmonic의 안정적인 시뮬레이션 환경에서 Nav2의 GPS Waypoint Following을 테스트하고, 이때 발생하는 모든 통신을 Zenoh를 통해 실제 환경과 유사하게 검증한 뒤, rosbag2로 서비스 호출까지 모두 기록하여 디버깅하는 워크플로우는 Humble에서는 구현하기 매우 어려운, 고도로 통합된 개발 환경이다.
아래 표는 군집 드론 연구에 직접적으로 영향을 미치는 핵심 기능들의 차이를 요약한 것이다.
| 기능 | ROS2 Humble Hawksbill | ROS2 Jazzy Jalisco | 핵심 가치 |
|---|---|---|---|
| Nav2 (GPS 경로 추종) | 미지원 (자체 개발 필요) | 지원 (내장 기능) | 실외 자율 비행 연구의 핵심 기능 |
| Nav2 (자동 도킹) | 미지원 (자체 개발 필요) | 지원 (내장 기능) | 장기 자율 운용 시나리오 구현 |
| 시뮬레이션 (Gazebo 연동) | 복잡함 (버전 파편화) | 간소화 (Harmonic 표준) | 대규모 군집 시뮬레이션 개발 효율 증대 |
| 미들웨어 (통신) | DDS (Fast/Cyclone) | DDS + Zenoh (고성능 옵션) | Wi-Fi 환경 통신 안정성 및 처리량 극대화 |
| rosbag2 (서비스 로깅) | 미지원 | 지원 | 복잡한 시스템의 디버깅 효율성 향상 |
최신 기능의 매력에도 불구하고, 실제 연구 개발에서는 생태계의 지원 수준이 프로젝트의 진행 속도를 결정하는 현실적인 변수로 작용한다.
LiDAR, 카메라, IMU 등 주요 센서 제조사들은 새로운 ROS2 배포판 출시에 맞춰 드라이버를 빠르게 업데이트하는 경향이 있다. 예를 들어, LDLiDAR나 ZED 카메라 등은 이미 Jazzy를 공식 지원하고 있다. 따라서 프로젝트에서 최신 상용 센서를 사용할 계획이라면, 두 버전 간의 드라이버 지원 격차는 크지 않을 가능성이 높다. 다만, 연구용으로 제작된 특수 센서나 더 이상 유지보수되지 않는 구형 센서를 사용해야 할 경우, 해당 드라이버가 Jazzy를 지원하는지 사전에 반드시 확인해야 한다.
군집 드론 시스템의 전체 성능과 안정성은 가장 취약한 구성요소에 의해 결정된다. Jazzy가 아무리 뛰어난 Nav2와 Zenoh 기능을 제공하더라도, 비행의 핵심인 비행 컨트롤러(FC)와의 통신이 불안정하거나 불가능하다면 아무 소용이 없다. 현재 시점에서 비행 컨트롤러 연동은 Jazzy 채택의 가장 큰 기술적 허들이다.
AP_DDS)는 MAVLink 프로토콜을 거치지 않고 PX4의 uORB 메시지와 ROS2 노드가 직접 통신하는 고성능 방식이다. ArduPilot의 공식 문서는 이 기능이 현재 ROS2 Humble만 지원한다고 명시하고 있다.mavros2 패키지는 Jazzy와 호환되는 것으로 보고된다. 하지만 이는 MAVLink 프로토콜을 한번 거치기 때문에 네이티브 DDS 방식에 비해 잠재적인 성능 저하와 지연 시간을 가질 수 있으며, 군집 드론과 같이 실시간성이 중요한 시스템에서는 이 차이가 문제가 될 수 있다.이러한 상황은 연구팀에게 중요한 선택을 강요한다. Jazzy의 최신 기능을 활용하기 위해서는, 시스템의 가장 근간이 되는 비행 컨트롤러와의 통신 방법을 해결해야 하는 딜레마에 빠진다. 이는 ‘새로운 기능’과 ‘기본적인 작동’ 사이의 트레이드오프다. Jazzy를 선택한다는 것은, 연구팀의 개발 리소스 중 일부를 ‘자율 비행 알고리즘 연구’가 아닌 ‘기반 시스템(FC 드라이버, 레거시 패키지 등) 포팅 및 안정화’에 투입해야 함을 의미할 수 있다. 프로젝트의 인력 구성과 개발 역량을 고려하여 이 전환 비용을 감당할 수 있는지 현실적으로 판단해야 한다.
지금까지의 분석을 종합하여, 군집 드론 자율 비행 연구를 위한 ROS2 배포판 선택에 대한 최종 권고를 제시한다.
| 평가 기준 | ROS2 Humble Hawksbill | ROS2 Jazzy Jalisco | 핵심 근거 |
|---|---|---|---|
| 안정성 및 성숙도 | 매우 높음 (Highly Mature) | 성숙 중 (Maturing) | Humble은 2년간 검증됨. Jazzy는 최신 버전으로 초기 안정화 기간 필요. |
| 장기 지원 (LTS) | 양호 (Good, ~2027) | 우수 (Excellent, ~2029) | Jazzy가 2년 더 긴 지원 기간 제공. |
| 군집 비행 핵심 기능 | 보통 (Fair) | 매우 우수 (Very Strong) | Nav2 GPS Waypoint Following, Autodocking 등 Jazzy의 기능이 압도적. |
| 군집 통신 (Middleware) | 보통 (Fair) - DDS | 매우 우수 (Very Strong) - Zenoh | Zenoh는 Wi-Fi 환경에서 DDS보다 월등한 안정성과 성능 제공 가능성. |
| 시뮬레이션 편의성 | 보통 (Fair) | 우수 (Excellent) | Jazzy는 Gazebo Harmonic과 표준화된 연동으로 설정이 간편함. |
| 생태계 (패키지/문서) | 매우 우수 (Very Strong) | 양호 (Good) | Humble은 축적된 자료와 커뮤니티 지원이 풍부함. |
| 비행 컨트롤러 연동 | 매우 우수 (Very Strong) | 주의 필요 (Caution Needed) | ArduPilot/PX4의 네이티브 DDS는 Humble을 우선 지원. Jazzy는 검증/개발 필요. |
두 배포판 중 어느 하나가 절대적으로 우월하다기보다는, 프로젝트의 우선순위와 감수할 수 있는 리스크에 따라 선택이 달라진다.
AP_DDS)나 PX4와의 검증된 연동이 필수적인 경우.Humble은 ‘검증된 안정성’을, Jazzy는 ‘미래를 향한 잠재력’을 제공한다. 군집 드론 연구의 특성상 통신 성능이 매우 중요하므로 Jazzy의 Zenoh는 매우 매력적인 카드다. 하지만 비행의 근간이 되는 FC 연동이라는 현실적인 제약이 Jazzy의 발목을 잡고 있다.
따라서, “우리의 비행 컨트롤러와 Jazzy 간의 안정적인 통신을 보장할 수 있는가?” 라는 질문에 대한 답이 최종 선택을 결정짓는 가장 중요한 기준이 될 것이다. 이 질문에 대한 긍정적인 답을 얻기 전까지는, Humble이 더 안전하고 현실적인 선택지이다. 만약 이 문제를 해결할 수 있는 기술력과 시간이 있다면, Jazzy는 군집 드론 연구의 수준을 한 단계 끌어올릴 수 있는 강력한 무기가 될 것이다.