# 향후 ROS2 버전과의 연동 방안

#### ROS2 Rolling 및 Iron 등 향후 버전 개요

ROS2는 정식 배포판뿐 아니라 Rolling(개발용 배포판)을 통해 다음 버전에서 적용될 기능을 미리 적용하고 시험한다. 예를 들어 Humble 이후에는 Iron 등이 뒤따르는 식이다. Humble에서 개발된 노드나 패키지가 향후 버전에서 활용될 수 있으려면 다음 사항들을 고려해야 한다.

1. **ROS2 Core 라이브러리 변경**
   * ROS2에서는 `rcl`, `rclcpp`, `rclpy` 등 핵심 라이브러리의 버전 상승 시 기존 API와 호환성을 유지하려고 하지만, 특정 메서드가 Deprecated로 지정되는 경우가 빈번하다.
   * 향후 버전에서 API나 QoS(서비스 품질) 파라미터 관련 변경이 발생할 가능성을 대비해, 코드 내에서 Deprecated 경고를 주기적으로 확인하고, 해당 경고가 발생하는 API는 새 버전에 맞춰 수정이 권장된다.
2. **RMW(ROS Middleware) 계층 변화**
   * ROS2에서 DDS(Dataplicity Distribution Service) 계층을 구현하는 RMW 구현체는 Fast-DDS, Cyclone DDS 등 여러 종류가 있다. 각 RMW마다 버전별 기능 차이가 있으므로, 특정 RMW에 종속되지 않도록 주의해야 한다.
   * 향후 버전에서 RMW 구현체가 변경되더라도 Humble에서 작성된 패키지가 정상 구동되려면 QoS 프로필을 명시적으로 지정하고, DDS 벤더별 확장 기능(예: 보안 설정, 실시간 QoS 등)에 대한 설정은 최소화하는 편이 좋다.
3. **빌드 및 의존성 관리**
   * 다음 버전에서 빌드 도구나 의존성 관리 도구(CMakeLists.txt, package.xml 등)의 스펙이 약간씩 달라질 수 있다. 예컨대, Rolling 배포판에서만 지원하는 새로운 CMake macro가 Iron 버전에 반영되면, Humble에서는 찾을 수 없는 경우가 생길 수 있다.
   * 이러한 문제를 방지하려면 CMake 또는 colcon 설정 시, 최소 요구 버전을 명시하고, 특정 함수나 기능이 필요한 경우에는 해당 함수를 사용하는 ROS2 버전을 조건부로 구분하여 빌드 스크립트를 작성하는 전략이 필요하다.
4. **플랫폼 및 OS 호환성**
   * 향후 ROS2 버전마다 지원하는 OS와 플랫폼에 차이가 있을 수 있다. 예를 들어, Ubuntu 20.04 LTS(Focal)를 기준으로 개발한 Humble과는 달리, 다음 버전에서 Ubuntu 22.04 LTS(Jammy) 혹은 그 이상의 버전을 요구할 수 있다.
   * 따라서 패키지를 작성할 때에는 OS 의존적 기능을 지양하고, 특정 버전에서만 동작하는 의존 라이브러리가 있다면 다른 대안도 함께 고려해야 한다.

#### DDS 최적화와 확장 고려

DDS를 통해 노드 간 통신을 처리할 때, 향후 ROS2 버전에서 DDS 레이어 최적화가 진행될 가능성이 높다. 특히 Real-Time ROS2와 같이 실시간 성능을 강조하는 부분에서 다음 사항을 염두에 둘 수 있다.

* **ROS2/DDS 간 QoS 매핑 개선** 향후 버전에서 QoS 프로필의 설정 범위가 더욱 세분화되거나, 실제 노드에서 동적으로 QoS를 조정할 수 있는 기능이 확대될 수 있다. 예컨대, `Deadline` 혹은 `LatencyBudget`과 같은 DDS QoS 정책이 ROS2 레벨에서 좀 더 세밀하게 설정 가능해질 수 있다.
* **XRCE-DDS와의 연동** 마이크로컨트롤러 보드를 위한 XRCE-DDS(XRCE: eXtremely Resource Constrained Environment)를 지원하는 ROS2 Micro 버전 등과의 연동을 염두에 두어야 할 수 있다. 이를 통해 소규모 임베디드 장치도 ROS2 통신에 참여할 수 있는데, 그 과정에서 메시지 타입 등 사소한 차이가 존재하므로, 동일 패키지를 확장할 때 주의해야 한다.
* **분산 환경에서의 DDS 설정** WAN(광역 네트워크)이나 다중 서브넷을 통한 분산 운영 시, Discovery 메커니즘이나 메시지 라우팅을 효율적으로 구성해야 한다. 향후 ROS2 버전에서 DDS Multicast Discovery 방식을 더욱 다양하게 지원할 수 있으므로, Humble 패키지 단계에서부터 고정된 Discovery 방식을 사용하는 대신 설정 유연성을 확보하는 전략이 필요하다.

{% @mermaid/diagram content="flowchart LR
A\["Humble 버전"]
B\["Iron 버전"]
C\["Rolling"]
A --> B
B --> C
A --> C" %}

#### 버전 간 호환성 유지 전략

다음 ROS2 버전과의 호환성을 높이려면, 개발 과정에서 ‘확장 가능성’을 최대한 고려해야 한다.

* **메시지 타입 설계** 메시지 정의(.msg 파일)에 변경이 발생하면, 메시지를 사용하는 노드들 간 버전 불일치가 발생할 수 있다. 이런 상황을 대비해 필드를 제거하기보다는 새 필드를 추가하는 식으로 확장성 있게 정의하는 편이 좋다.
* **API 활용 시 주의** ROS2 C++ API(`rclcpp`)나 Python API(`rclpy`)에서 Deprecated로 표시된 기능은 곧 사라질 가능성이 있으므로, 코드 작성 시 새 API 활용이 권장된다. 특히 Iron 이후 버전에서 Deprecated API가 완전히 제거될 수 있으므로 미리 대체 API를 검토해 두어야 한다.

#### API 변경 대응

API가 변경될 경우, 해당 API를 사용하는 패키지 전반에서 수정이 이루어져야 한다. 이를 효율적으로 관리하려면 다음 접근을 고려할 수 있다.

* **ROS2 Core Repo 추적** ROS2의 핵심 레포지토리(예: rcl, rclcpp, rmw 등)의 GitHub 이슈나 Pull Request를 수시로 확인하고, 변경점을 조기에 파악하는 것이 바람직하다.
* **테스트 자동화 및 CI 활용** ROS2 Rolling이나 Iron 환경에서 해당 패키지를 주기적으로 빌드하고 테스트하는 CI 파이프라인을 구성해 두면, API 변경으로 인한 빌드 실패나 Warning을 빠르게 감지할 수 있다.

#### 신규 기능 반영 방식

ROS2 Iron 이후 버전에서 새로 추가되는 기능을 활용하기 위해서는, 기존 Humble 패키지와 Iron 환경에서 동시에 동작 가능한 구조를 구축해야 한다.

* **Condition Macro 활용** CMakeLists.txt에서 ROS2 버전에 따라 서로 다른 라이브러리나 함수를 링크하도록 Condition Macro(예: if, else, endif 등)를 활용할 수 있다.
* **Rolling Snapshot 분석** Rolling 배포판은 향후 Iron, Jade 등 새 버전에 대거 반영될 기능들이 미리 포함되어 있다. Humble용 패키지를 개발하더라도 Rolling 환경을 주기적으로 테스트해서, 향후 버전의 변동사항을 사전에 파악하는 전략이 유효하다.

#### 마이그레이션 체크리스트

Humble에서 개발된 패키지가 Iron 이후 버전까지 무리 없이 이식될 수 있으려면, 미리 체크해야 할 사항들이 있다.

* **간접 의존성 점검** ROS2 Core 라이브러리가 아닌, 외부 서드파티 라이브러리(예: OpenCV, PCL 등)의 버전 호환성을 주기적으로 확인한다.
* **메시지 및 서비스 파일 변경 기록** 메시지(.msg), 서비스(.srv), 액션(.action) 파일 변경 시, 세부 변경 내역을 별도로 기록해 두어야 한다. 그래야 Iron으로 마이그레이션하거나 Rollback 상황이 발생했을 때 추적이 쉽다.
* **노드 네이밍 규칙 준수** ROS2 노드, 토픽, 서비스 이름은 OS 및 DDS 구현체에 따라 허용되는 문자 세트와 길이가 달라질 수 있다. 차기 버전에서 이 규칙이 더욱 엄격해질 가능성도 있으므로, 가급적 표준 Naming Convention을 준수한다.

#### 크로스 컴파일 및 임베디드 적용 고려

임베디드 플랫폼이나 ARM 계열 칩셋 등에서 ROS2를 활용하려면, 호환성을 유지하기 위한 사전 준비가 필요하다.

* 크로스 컴파일 환경 설정
  * Humble에서 사용하는 크로스 컴파일 도커 이미지나 툴체인이 Iron 이후 버전에서도 동일하게 동작하는지 점검해야 한다.
  * 특정 빌드 플래그나 cmake 변수 설정이 차기 버전에서 달라질 수 있으므로, Dockerfile이나 빌드 스크립트에 명시된 옵션을 꼼꼼히 검토한다.
* 임베디드 디바이스 리소스 제한
  * 임베디드 디바이스의 RAM이나 Flash 등 하드웨어 리소스가 부족한 경우, Rolling이나 Iron에서 추가된 기능(예: 로깅, 보안 기능 등)이 디바이스 성능에 부담이 될 수 있다.
  * 따라서 실제 배포 시에는 필요한 기능만 빌드하는 옵션(예: `BUILD_TESTING=OFF`, `BUILD_SHARED_LIBS=ON` 등)을 활용해 빌드 아티팩트를 최소화하는 전략을 사용한다.

#### 보안(Security) 기능 변화

ROS2는 DDS에 탑재되는 보안 계층(DDS-Security)을 통해 노드 간 통신을 암호화하거나 인증하는 기능을 제공한다. 향후 버전에서 해당 보안 기능이 더 엄격해지거나, 설정 방식이 달라질 수 있으므로 아래 사항을 고려해야 한다.

* 보안 프로파일 호환성
  * SROS2(Security for ROS2)에서 생성하는 인증서, 정책 파일이 Iron 등에서 새 포맷을 요구할 가능성이 있으니 문서를 통해 주기적으로 확인한다.
* 보안 관련 성능 이슈
  * 보안을 활성화하면 CPU 오버헤드가 발생한다. Humble에서는 문제가 없었던 성능이 Iron에서 변경된 DDS 암호화 알고리즘으로 인해 크게 영향을 받을 수도 있다.
  * 이를 사전에 시험하기 위해 Rolling이나 Iron 환경에서 보안 활성화 상태로 성능 테스트를 진행하고, 결과를 비교 분석해야 한다.

#### 지속적 유지보수(Continuous Maintenance)

ROS2 생태계는 각 버전이 일정 기간 지원된다. Humble이나 Iron과 같은 LTS(장기 지원) 버전의 경우, 더 오래 지원되지만 그 사이에 단기 지원 버전들도 잇따라 출시된다.

* LTS 버전 간 마이그레이션
  * 장기 지원(LTS) 버전 간에만 마이그레이션을 고려해도 충분한 경우가 많다. 예컨대 Humble -> Iron이 서로 LTS 버전일 때 주로 진행하며, Rolling 등은 테스트용으로 사용한다.
* 부모 패키지 및 의존 패키지 동향 파악
  * 내 패키지가 의존하는 상위 레벨 패키지(예: navigation2, moveit2, perception 등)에서 Iron 버전 이후 지원 계획을 미리 발표하는 경우가 많다. 이 정보를 근거로 언제 마이그레이션 작업을 진행할지 계획을 세운다.

#### 병행 운영 시나리오

현업 환경에서는 Humble 기반 시스템과 Iron 기반 시스템을 동시에 운영해야 하는 상황이 발생할 수 있다. 이를 고려한 병행 운영 시나리오를 준비하는 것도 중요하다.

* Bridge 활용
  * ROS1 <-> ROS2 간 Bridge가 존재하듯, 다른 ROS2 버전 간 브릿지가 공식적으로 제공되지는 않지만, 별도의 DDS 설정이나 브로커 노드(Bridge Node)를 구성하여 메시지를 변환할 수 있다.
* 네트워크 격리
  * Humble 시스템과 Iron 시스템을 동일 네트워크에서 동작시키는 경우, Discovery 단계에서 충돌이 발생할 가능성이 있으므로, VLAN 혹은 서브넷 분리를 고려한다.

{% @mermaid/diagram content="sequenceDiagram
participant Humble\_Node
participant Bridge\_Node
participant Iron\_Node

```
Humble_Node->>Bridge_Node: Humble 버전 메시지 전송
Bridge_Node->>Iron_Node: 메시지 변환 후 재전송
Iron_Node->>Bridge_Node: Iron 버전 응답
Bridge_Node->>Humble_Node: 응답 변환 후 전달" %}
```

#### 시험 및 검증(Test & Validation) 절차

ROS2 버전이 업그레이드됨에 따라, Humble에서 정상 동작하던 기능이 Iron이나 이후 버전에서 예기치 않은 문제를 일으킬 수 있다. 이러한 오류를 예방하기 위해서는 철저한 시험 및 검증 절차를 마련해야 한다.

* **통합 테스트(Integration Test)**
  * 멀티 노드 시나리오(예: 센서 노드 → SLAM 노드 → 내비게이션 노드)에서 전체 데이터 흐름이 정상적으로 작동하는지 테스트한다.
  * Iron 이상의 환경에서도 동일 시나리오를 수행해 보고, 성능 차이(지연, CPU 사용률 등)를 기록한다.
* **단위 테스트(Unit Test)**
  * Humble에서 작성된 각 노드별 API 호출 검증, 메시지 송수신 기능, QoS 설정 등이 Iron 버전에서 의도대로 동작하는지 개별 테스트를 수행한다.
  * GTest나 pytest 등의 테스트 프레임워크를 활용한다.
* **성능 측정(Performance Benchmark)**
  * 메시지 지연, 스루풋(throughput), CPU 자원 사용률 등을 비교 측정한다.
  * 특정 노드에서 성능 저하가 발생하면, Iron에서 새로 추가된 기능이나 변경된 QoS 설정이 원인인지 확인해야 한다.
* **회귀(regression) 점검**
  * 기존 버전(Humble)에서 해결된 문제가 Iron에서 재발하는지를 확인한다.
  * 버그나 이슈 트래킹 시스템(JIRA, GitHub Issues 등)을 통해, 이전에 해결했던 문제가 되살아나는지 추적한다.

#### 릴리스 전략

Humble 기반 패키지를 Iron 이상 버전까지 확장해 나갈 때, 어떤 방식으로 버전을 관리하고 배포하는지 전략이 필요하다.

* **브랜치 전략**
  * 버전별로 Git 브랜치를 분리하여, Humble 전용 브랜치와 Iron 전용 브랜치를 운영할 수 있다.
  * Rolling에서 발견된 개선 사항이나 버그 패치는 Iron과 Humble에 병합할지 여부를 결정하는 프로세스를 명확히 정해 둔다.
* **배포 패키지 구조**
  * ROS2 패키지를 .deb 형태(apt) 또는 .rpm 형태(yum/dnf) 등으로 배포하는 경우, 패키지 이름에 ROS2 버전을 명시해 혼동을 줄이거나, 빌드 시점에 이용할 수 있는 ROS\_DISTRO 환경 변수를 통해 분기 처리를 할 수 있다.
  * 대규모 패키지(예: navigation2, moveit2)처럼 의존성 트리가 복잡한 경우, 각 버전에 맞는 분리된 메타 패키지를 제공하는 방법도 있다.

#### 출시 일정과 Community 동향 모니터링

ROS2는 일정에 따라 새로운 디스트리뷰션이 출시되고, EOL(End Of Life)도 명시되어 있다. Humble, Iron 이후의 Jade, K 버전(가칭) 등이 언제, 어떻게 출시되는지 정확한 일정을 파악하는 것이 중요하다.

* **ROS2 공식 Release Roadmap**
  * ROS2 공식 웹사이트나 ROS Discourse 등을 통해 차기 버전의 알파, 베타 출시 일정, 코드 프리징(Code Freeze) 시점 등을 주시한다.
  * EOL 시점이 가까워지면 긴급 보안 패치 등이 제한될 수 있으므로, 미리 대체 버전(예: Humble → Iron)으로 이전 준비를 시작해야 한다.
* **ROS2 Community 유지보수**
  * 유지보수 규모가 큰 패키지(예: rclcpp, rclpy, sensor\_msgs 등)는 Community 기여가 활발하므로, GitHub 이슈나 PR을 통해 피드백을 활발히 주고받는다.
  * Community에서 Iron 버전 테스트 관련 보고가 나오면, 그 정보를 참고해 Humble 패키지에 대한 대응 계획을 세울 수 있다.