ROS2 Humble 대 Jazzy 성숙도

1. 군집 드론 연구를 위한 기술 스택 의사결정

본 안내서는 LiDAR, 카메라, IMU, GNSS, 콤파스 센서 융합을 통한 군집 드론 자율 비행 연구라는 명확한 목표를 달성하기 위한 최적의 ROS2(Robot Operating System 2) 배포판 선정을 목표로 한다. 이 선택은 단순히 최신 버전을 따르는 기술적 추종이 아닌, 프로젝트의 성공을 좌우하는 전략적 의사결정이다.

본 안내서에서 ’성숙도’는 단순히 출시 시점이 오래된 것을 의미하지 않는다. 이는 다음 네 가지 핵심 기준으로 평가되는 다차원적 개념이다.

1. 안정성 (Stability): 예측 가능한 동작, 낮은 버그 발생률, 그리고 결정적으로 다중 노드(드론) 환경에서의 통신 견고성.
2. 기능성 (Functionality): 군집 드론 자율 비행에 필수적인 최신 알고리즘과 도구(예: Navigation, Simulation)의 가용성 및 성능.
3. 생태계 (Ecosystem): 하드웨어 드라이버, 서드파티 패키지, 튜토리얼, 커뮤니티 지원의 폭과 깊이.
4. 미래 확장성 (Future-Proofing): 장기적인 기술 지원, 최신 기술 트렌드와의 부합성, 향후 연구로의 확장 가능성.

이 네 가지 기준을 분석의 틀로 삼아 ROS2 Humble Hawksbill과 ROS2 Jazzy Jalisco를 체계적으로 비교하고, 최종적으로 프로젝트의 특성에 맞는 시나리오별 권고안을 제시한다.

2. 배포판 수명 주기 및 플랫폼 종속성: 전략적 기반 분석

배포판 선택의 가장 기본적인 단계는 프로젝트의 시간적 범위와 하드웨어 제약 조건을 고려하는 것이다. 이는 기술 스택의 근간을 이루며, 장기적인 안정성과 유지보수성에 직접적인 영향을 미친다.

2.1 LTS(Long-Term Support) 지원 기간 비교

ROS2 배포판은 매년 5월 23일에 새로운 버전이 출시되며, 짝수 해에 출시되는 버전은 5년간의 장기 지원(LTS)을 제공한다.

• ROS2 Humble Hawksbill: 2022년 5월에 출시된 LTS 배포판으로, 2027년 5월까지 공식 지원이 제공된다. 현재 산업계와 학계에서 가장 널리 사용되며, 지난 2년간의 운영을 통해 안정성이 충분히 검증되었다.
• ROS2 Jazzy Jalisco: 2024년 5월에 출시된 최신 LTS 배포판으로, 2029년 5월까지 지원된다. Humble 대비 2년 더 긴 지원 기간을 보장받을 수 있다.

이 2년의 차이는 단순한 시간 이상의 의미를 가진다. 만약 연구 프로젝트의 기간이 3년을 초과하거나, 개발된 시스템의 장기적인 유지보수가 중요한 경우, Jazzy의 긴 지원 기간은 명백한 전략적 이점이다. Humble을 선택할 경우, 2027년 이전에 다른 배포판으로 시스템 전체를 마이그레이션해야 하는 기술적 부채가 발생하며, 이는 상당한 시간과 비용을 수반한다. 따라서 Jazzy의 2년 더 긴 LTS는 2027년에 발생할 ‘강제 마이그레이션’ 비용을 2년 뒤로 미루거나 원천적으로 방지할 수 있는 중요한 가치를 지닌다.

2.2 OS 및 하드웨어 플랫폼 종속성

ROS2 배포판은 특정 Ubuntu 버전에 강하게 의존하며, 이는 하드웨어 선택에 직접적인 영향을 미친다.

• Humble: Ubuntu 22.04 (Jammy Jellyfish)를 Tier-1 플랫폼으로 공식 지원한다. 이는 지난 2년간 안정화된 운영체제 환경 위에서 개발할 수 있다는 장점을 제공한다.
• Jazzy: Ubuntu 24.04 (Noble Numbat)를 Tier-1 플랫폼으로 요구한다. 이는 최신 리눅스 커널과 시스템 라이브러리를 활용하여 잠재적으로 더 나은 성능을 기대할 수 있다는 장점이 있지만, OS 자체의 초기 불안정성이나 주변 소프트웨어와의 호환성 문제에 노출될 위험도 내포한다.

이러한 종속성은 특정 하드웨어, 특히 최신 임베디드 보드를 사용할 때 중요한 제약 조건으로 작용한다. 예를 들어, 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 지원 여부를 먼저 확정하는 것이 전체 기술 스택을 결정하는 첫 단추가 된다.

3. 핵심 안정성 및 통신 호환성: 군집 시스템의 아킬레스건

군집 드론 시스템의 성공은 개별 드론의 성능만큼이나 드론 간의, 그리고 드론과 지상관제시스템(GCS) 간의 안정적인 통신에 달려있다. 이 관점에서 ROS2 배포판 간의 통신 호환성은 시스템의 근본적인 안정성을 결정하는 치명적인 요소다.

3.1 배포판 간 통신: 불가능한 조합

결론부터 말하자면, 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로의 전환 결정은 연구실 전체의 인프라를 동시에 업그레이드해야 하는 중대한 결정임을 의미한다. 하나의 구성 요소라도 다른 버전을 사용하게 되면, 전체 시스템의 안정성이 위협받을 수 있다.

3.2 API/ABI 안정성 정책

배포판 간의 파괴적인 변화와는 대조적으로, 각 배포판의 수명 주기 내에서는 높은 수준의 안정성이 보장된다. ROS2는 특정 배포판(예: Jazzy)이 출시되면, 해당 버전의 지원이 종료될 때까지 API(Application Programming Interface) 및 ABI(Application Binary Interface) 호환성을 유지하는 것을 원칙으로 한다. 이는 Jazzy용으로 개발된 코드는 Jazzy의 다음 패치 릴리즈(예: Jazzy Patch 1 -> Patch 2)에서도 재컴파일 없이 동작해야 함을 의미하며, 이는 안정적인 시스템 운영에 필수적인 요소다. 새로운 기능 도입이나 구조적 개선을 위한 파괴적 변경(Breaking Changes)은 다음 배포판 출시 시에 이루어진다.

아래 표는 두 배포판의 안정성과 관련된 핵심 차이점을 요약한 것이다.

4. 군집 드론을 위한 기능 심층 비교: Jazzy의 기술적 우위

안정성과 호환성이 시스템의 ’기반’이라면, 기능성은 연구의 ’가능성’을 결정한다. 군집 드론 자율 비행이라는 특정 목표 하에서, Jazzy는 Humble 대비 명백하고 강력한 기능적 우위를 제공한다.

4.1 Navigation (Nav2 스택)

Nav2는 ROS2의 표준 내비게이션 스택으로, 로봇의 자율 주행을 위한 핵심적인 기능들을 포함한다.

• Humble: Humble의 Nav2는 SLAM, Localization, Path Planning 등 기본적인 기능을 안정적으로 제공하며, 관련 튜토리얼과 커뮤니티 예제가 풍부하여 입문자가 사용하기에 용이하다.
• Jazzy: Jazzy의 Nav2는 Iron 배포판 이후 이루어진 대규모 업데이트를 통해 군집 드론 연구에 직접적으로 활용될 수 있는 핵심 기능들이 대거 추가되었다.
• GPS Waypoint Following: GNSS 센서 데이터를 직접 활용하여 장거리 경로점을 추종하는 기능이다. 이는 실외 환경에서 군집 드론을 운용할 때 필수적인 기능으로, Humble에서는 상당한 규모의 자체 개발이 필요했던 부분이다.
• Autodocking Server: 드론이 지정된 도킹 스테이션에 자동으로 착륙하고 충전할 수 있도록 지원하는 전용 서버 및 RViz 플러그인이다. 이는 군집 드론의 장기적인 자율 운용 시나리오를 구현하는 데 매우 유용하다.
• 성능 최적화 및 실시간성 강화: 핵심 경로 추종 컨트롤러 중 하나인 MPPI(Model Predictive Path Integral)의 성능이 45% 향상되었으며, 제어 파이프라인 전체를 소프트-리얼타임(soft-realtime)으로 실행할 수 있는 옵션이 추가되어 더 빠르고 예측 가능한 제어가 가능해졌다.

Nav2 기능만 놓고 본다면, Jazzy는 Humble에 비해 군집 ‘자율 비행’ 연구에 훨씬 더 적합하고 강력한 도구를 기본적으로 제공한다.

4.2 Simulation (Gazebo)

수십, 수백 대의 드론을 동시에 시뮬레이션해야 하는 군집 연구에서, 안정적이고 설정이 간편한 시뮬레이션 환경은 개발 효율성을 좌우하는 핵심 요소다.

• Humble: Humble 시절에는 Gazebo Classic, Ignition Gazebo, Gazebo Garden 등 여러 시뮬레이터 버전이 혼재되어 사용자에게 큰 혼란을 주었다. 버전 간 호환성 문제와 복잡한 설정 과정은 개발의 큰 장벽이었다.
• Jazzy: Jazzy부터는 Gazebo Harmonic과의 연동을 공식적으로 권장하고, gz_*_vendor라는 벤더 패키지를 통해 ROS2와의 통합을 대폭 간소화했다. 이는 복잡한 설정 없이도 안정적인 시뮬레이션 환경을 빠르게 구축할 수 있게 해준다.

이러한 변화는 특히 대규모 군집 시뮬레이션 환경을 구축하고 유지보수해야 하는 연구팀에게 큰 이점이다.

4.3 Middleware (DDS & Zenoh): 군집 통신의 게임 체인저

미들웨어는 ROS2 노드 간의 통신을 책임지는 심장과 같다. Jazzy는 이 부분에서 가장 혁신적인 변화를 담고 있다.

• DDS (Data Distribution Service): ROS2의 기본 미들웨어로, eProsima의 Fast DDS와 Eclipse의 Cyclone DDS 등이 주로 사용된다. DDS는 강력한 QoS(Quality of Service) 설정 등 다양한 기능을 제공하지만, UDP 멀티캐스트 기반의 디스커버리 메커니즘으로 인해 일반적인 Wi-Fi 네트워크 환경에서는 설정이 까다롭고 성능 저하를 겪는 경우가 많다.
• Zenoh (Jazzy의 핵심 변화): Zenoh는 DDS의 대안으로 등장한 새로운 RMW(ROS Middleware) 구현체(rmw_zenoh)이다.
• 안정성: DDS와 달리 TCP 기반 통신을 지원하여, UDP 패킷 유실이 잦은 불안정한 Wi-Fi 환경에서 훨씬 안정적인 연결을 제공할 수 있다.
• 성능: 독립적인 벤치마크 결과, Zenoh는 최적화된 DDS 구현체 대비 **3배 이상의 압도적인 처리량(Throughput)**을 보여준다. 이는 각 드론이 생성하는 대용량 센서 데이터(예: LiDAR 포인트 클라우드, 고해상도 카메라 이미지)를 지연 없이 주고받아야 하는 군집 드론 환경에 이상적이다.
• 공식 지원: Zenoh는 Jazzy에서 바이너리 패키지로 제공되어 쉽게 설치하고 사용할 수 있으며, 차기 버전인 Kilted부터는 Tier-1 등급의 공식 RMW로 지정될 예정이다.

Zenoh의 등장은 Jazzy를 선택해야 하는 매우 강력한 이유가 된다. 이는 군집 드론 통신의 고질적인 문제였던 Wi-Fi 환경에서의 불안정성과 대역폭 한계를 극복할 수 있는 잠재력을 가졌기 때문이다. Zenoh의 도입은 단순히 통신 방법을 바꾸는 것을 넘어, 군집 드론 아키텍처 자체를 혁신할 기회를 제공한다. 기존 DDS 기반 시스템이 ’어떻게든 통신을 안정시킬까’에 집중했다면, Zenoh 기반 시스템은 ’이 넓은 대역폭으로 어떤 새로운 애플리케이션을 만들까’로 연구의 초점을 이동시킬 수 있다. 예를 들어, 각 드론이 촬영한 고화질 영상을 중앙 서버로 실시간 스트리밍하여 통합된 3D 모델을 생성하는 등의 고도화된 연구가 가능해진다.

4.4 기타 주요 기능 개선

• rosbag2: Jazzy의 rosbag2는 서비스(Service) 호출을 기록하고 재생할 수 있는 기능이 추가되었다. 이는 복잡한 분산 시스템에서 문제의 원인을 추적하고 디버깅하는 데 매우 유용하다.
• RViz2: 정규 표현식을 이용한 TF 필터링, 토픽 주파수 상태 바 표시 등 사용자 편의성을 높이는 다양한 기능이 개선되었다.

Jazzy의 기능 개선은 개별적으로도 뛰어나지만, 서로 결합될 때 더 큰 시너지를 낸다. 예를 들어, Gazebo Harmonic의 안정적인 시뮬레이션 환경에서 Nav2의 GPS Waypoint Following을 테스트하고, 이때 발생하는 모든 통신을 Zenoh를 통해 실제 환경과 유사하게 검증한 뒤, rosbag2로 서비스 호출까지 모두 기록하여 디버깅하는 워크플로우는 Humble에서는 구현하기 매우 어려운, 고도로 통합된 개발 환경이다.

아래 표는 군집 드론 연구에 직접적으로 영향을 미치는 핵심 기능들의 차이를 요약한 것이다.

5. 생태계 성숙도: 현실적인 제약과 기회

최신 기능의 매력에도 불구하고, 실제 연구 개발에서는 생태계의 지원 수준이 프로젝트의 진행 속도를 결정하는 현실적인 변수로 작용한다.

5.1 커뮤니티 및 패키지 지원

• Humble의 강점: Humble은 2년 이상 시장의 표준으로 자리 잡으면서 방대한 양의 튜토리얼, 커뮤니티 질의응답(ROS Answers, Discourse), 블로그 포스트, 그리고 서드파티 패키지가 축적되었다. 개발 중 문제에 부딪혔을 때 해결책을 찾기가 상대적으로 용이하다.
• Jazzy의 현주소: Jazzy는 출시 초기 단계로, Humble에 비해 문서나 커뮤니티 지원이 아직은 부족하다. Humble용 튜토리얼을 Jazzy 환경에 적용하려다 문법 차이나 패키지 의존성 문제로 어려움을 겪는 사례가 보고되고 있다.

5.2 센서 드라이버 지원 현황

LiDAR, 카메라, IMU 등 주요 센서 제조사들은 새로운 ROS2 배포판 출시에 맞춰 드라이버를 빠르게 업데이트하는 경향이 있다. 예를 들어, LDLiDAR나 ZED 카메라 등은 이미 Jazzy를 공식 지원하고 있다. 따라서 프로젝트에서 최신 상용 센서를 사용할 계획이라면, 두 버전 간의 드라이버 지원 격차는 크지 않을 가능성이 높다. 다만, 연구용으로 제작된 특수 센서나 더 이상 유지보수되지 않는 구형 센서를 사용해야 할 경우, 해당 드라이버가 Jazzy를 지원하는지 사전에 반드시 확인해야 한다.

5.3 결정적 요인: 비행 컨트롤러(FC) 연동

군집 드론 시스템의 전체 성능과 안정성은 가장 취약한 구성요소에 의해 결정된다. Jazzy가 아무리 뛰어난 Nav2와 Zenoh 기능을 제공하더라도, 비행의 핵심인 비행 컨트롤러(FC)와의 통신이 불안정하거나 불가능하다면 아무 소용이 없다. 현재 시점에서 비행 컨트롤러 연동은 Jazzy 채택의 가장 큰 기술적 허들이다.

• ArduPilot: ArduPilot이 제공하는 네이티브 DDS 인터페이스(AP_DDS)는 MAVLink 프로토콜을 거치지 않고 PX4의 uORB 메시지와 ROS2 노드가 직접 통신하는 고성능 방식이다. ArduPilot의 공식 문서는 이 기능이 현재 ROS2 Humble만 지원한다고 명시하고 있다.
• PX4: PX4 역시 공식 문서에서 Humble을 주력 지원 배포판으로 권장하고 있다. 일부 사용자들이 Jazzy와 연동을 시도하고는 있지만, 이는 아직 공식적으로 검증된 경로가 아니다.
• MAVROS2: MAVLink 메시지를 ROS2 토픽으로 변환해주는 mavros2 패키지는 Jazzy와 호환되는 것으로 보고된다. 하지만 이는 MAVLink 프로토콜을 한번 거치기 때문에 네이티브 DDS 방식에 비해 잠재적인 성능 저하와 지연 시간을 가질 수 있으며, 군집 드론과 같이 실시간성이 중요한 시스템에서는 이 차이가 문제가 될 수 있다.
• micro-ROS: 마이크로컨트롤러를 위한 micro-ROS 역시 Humble에서 Jazzy로 마이그레이션 시 빌드 오류가 보고되는 등, 최신 배포판 지원에는 시간이 필요한 상황이다.

이러한 상황은 연구팀에게 중요한 선택을 강요한다. Jazzy의 최신 기능을 활용하기 위해서는, 시스템의 가장 근간이 되는 비행 컨트롤러와의 통신 방법을 해결해야 하는 딜레마에 빠진다. 이는 ’새로운 기능’과 ‘기본적인 작동’ 사이의 트레이드오프다. Jazzy를 선택한다는 것은, 연구팀의 개발 리소스 중 일부를 ’자율 비행 알고리즘 연구’가 아닌 ’기반 시스템(FC 드라이버, 레거시 패키지 등) 포팅 및 안정화’에 투입해야 함을 의미할 수 있다. 프로젝트의 인력 구성과 개발 역량을 고려하여 이 전환 비용을 감당할 수 있는지 현실적으로 판단해야 한다.

6. 종합 분석 및 최종 권고

지금까지의 분석을 종합하여, 군집 드론 자율 비행 연구를 위한 ROS2 배포판 선택에 대한 최종 권고를 제시한다.

6.1 의사결정 매트릭스

6.2 시나리오 기반 최종 권고

두 배포판 중 어느 하나가 절대적으로 우월하다기보다는, 프로젝트의 우선순위와 감수할 수 있는 리스크에 따라 선택이 달라진다.

6.2.1 시나리오 1: 안정성과 빠른 개발 착수가 최우선일 경우 –>> ROS2 Humble 권고

• 적합한 프로젝트:
• 프로젝트 기간이 1-2년 내로 비교적 짧은 경우.
• ArduPilot의 네이티브 DDS(AP_DDS)나 PX4와의 검증된 연동이 필수적인 경우.
• 팀의 ROS 개발 경험이 많지 않아, 풍부한 튜토리얼과 검증된 패키지 생태계에 의존해야 하는 경우.
• 기반 시스템 구축보다 상위 레벨의 자율 비행 알고리즘 연구에 즉시 집중하고 싶을 때.
• 감수해야 할 점:
• Nav2의 GPS Waypoint Following, Autodocking 등 최신 기능은 직접 구현하거나 대안을 찾아야 한다.
• Wi-Fi 환경에서의 DDS 통신 안정화를 위한 튜닝 노력이 필요할 수 있다.
• 2027년 지원 종료에 따른 마이그레이션 계획을 장기적으로 염두에 두어야 한다.

6.2.2 시나리오 2: 장기적인 기술 우위와 미래 확장성이 최우선일 경우 –>> ROS2 Jazzy 권고

• 적합한 프로젝트:
• 프로젝트가 3년 이상의 장기 과제일 경우.
• Zenoh 미들웨어를 활용하여 통신 성능을 극대화하고, 이를 기반으로 한 새로운 연구(예: 고화질 영상 스트리밍 기반 실시간 3D 재구성)를 계획하는 경우.
• 최신 Nav2 기능과 Gazebo 시뮬레이션 환경을 적극적으로 활용하여 개발 효율을 높이고자 하는 경우.
• 팀 내에 비행 컨트롤러 드라이버 포팅이나 초기 불안정성 문제 해결에 투입할 수 있는 개발 역량이 충분할 때.
• 필수 선행 조건:
• 가장 중요한 것은, 프로젝트 시작 전 비행 컨트롤러(PX4/ArduPilot)와 Jazzy 간의 통신(네이티브 DDS 또는 MAVROS2)을 실제 하드웨어에서 검증하는 것이다. 이 검증에 실패하면 Jazzy 채택은 심각한 리스크를 안게 된다.
• 감수해야 할 점:
• 초기 생태계 부족으로 인해 문서 검색 및 문제 해결에 더 많은 시간이 소요될 수 있다.
• 일부 서드파티 패키지의 호환성 문제 발생 가능성 및 직접 포팅의 필요성이 있을 수 있다.

6.3 최종 결론

Humble은 ’검증된 안정성’을, Jazzy는 ’미래를 향한 잠재력’을 제공한다. 군집 드론 연구의 특성상 통신 성능이 매우 중요하므로 Jazzy의 Zenoh는 매우 매력적인 카드다. 하지만 비행의 근간이 되는 FC 연동이라는 현실적인 제약이 Jazzy의 발목을 잡고 있다.

따라서, “우리의 비행 컨트롤러와 Jazzy 간의 안정적인 통신을 보장할 수 있는가?” 라는 질문에 대한 답이 최종 선택을 결정짓는 가장 중요한 기준이 될 것이다. 이 질문에 대한 긍정적인 답을 얻기 전까지는, Humble이 더 안전하고 현실적인 선택지이다. 만약 이 문제를 해결할 수 있는 기술력과 시간이 있다면, Jazzy는 군집 드론 연구의 수준을 한 단계 끌어올릴 수 있는 강력한 무기가 될 것이다.