ROS2 릴리즈 사이클 및 버전 관리

개요

ROS2는 특정 간격으로 새로운 버전을 공개하며, 각 버전은 고유한 코드네임과 버전 번호를 통해 식별된다. 이때, 릴리즈 주기를 어떻게 설정하고 버전을 어떠한 방식으로 관리하느냐는 ROS2를 개발·운영하는 측면에서 매우 중요한 요소다. 릴리즈 사이클은 새 기능 및 개선 사항을 보다 체계적으로 포함하기 위한 일정 계획이 필요하며, 버전 관리는 사용자들의 호환성과 안정성을 보장하기 위한 표준적 규칙을 제공한다.

ROS2 프로젝트는 (주로 OSRF에서) 배포판(Distribution) 형태로 공개되는데, 이러한 배포판은 정기 혹은 비정기적으로 각종 버그 수정, 보안 패치, 기능 개선 등을 포함한다. 특정 릴리즈는 장기간 지원(LTS, Long-Term Support) 형태로 유지되고, 일부 릴리즈는 다음 릴리즈까지 단기간만 유지된 후 EOL(End of Life)에 도달한다. 이 과정을 통해 ROS2 전체가 지속적으로 발전하며, 동시에 기존 사용자들의 시스템 안정성을 보장하려는 목적이 있다.

릴리즈 주기와 배포판 구성

ROS2의 릴리즈 주기는 일반적으로 6개월에서 1년 사이의 간격으로 잡히지만, 실제 적용 시점은 개발 상황과 타 소프트웨어 종속성 등에 영향을 받는다. 그럼에도 불구하고 가장 널리 알려진 점은 다음과 같은 구조다.

• 새로운 기능을 집중적으로 수용하는 일반 릴리즈(Non-LTS)

• 장기간 지원을 보장하는 LTS(Long-Term Support) 릴리즈

이 중 LTS 릴리즈는 몇 년간 보안 패치와 버그 수정을 공식 지원받을 수 있기 때문에 산업 현장이나 연구 분야에서 안정적으로 사용될 수 있다. 반면 일반 릴리즈는 다음 버전이 나오면 상대적으로 빠르게 지원이 종료되므로, 실험적 기능이나 새로운 기술 트렌드를 미리 접하고자 하는 사용자층이 선호한다.

실제 릴리즈 주기는 일정한 패턴을 갖되, 로드맵(roadmap)에 따라 다소 조정될 수 있다. 예컨대, 어느 시점에 LTS 릴리즈를 계획하는지가 이전 릴리즈들의 기능 통합 시기 및 ROS 생태계 변화를 결정한다. 이러한 변동 폭을 수학적으로 표현하기 위해, 가령 릴리즈 버전을 시간축으로 표기해보자.

가령 릴리즈 번호를 나타내는 스칼라 $r_n$이 있을 때, 각 릴리즈가 일정 간격 $\Delta t$ 마다 발생한다고 가정하면,

$$r_{n+1} = r_n + 1, \quad t_{n+1} = t_n + \Delta t$$

여기서 $r_n$은 릴리즈 번호, $t_n$은 그 릴리즈가 공개되는 시간을 의미한다. 실제로는 개발 우선순위, 소프트웨어 의존성 문제, 특정 이벤트(예: 컨퍼런스 등)와의 연동 등을 고려하여 $\Delta t$가 가변적이 될 수 있다.

버전 관리 체계

버전 관리는 새 기능 추가, 버그 수정, API 변경 여부 등에 따라 서로 다른 수준의 버전 번호를 부여하는 방식을 포함한다. ROS2에서는 흔히 메이저(major), 마이너(minor), 패치(patch) 수준을 구분해 왔다. 예를 들어 2.0.0 → 2.1.0과 같은 변화는 비교적 큰 기능의 추가를 의미하고, 2.0.0 → 2.0.1 같은 변화는 간단한 버그 픽스를 의미한다.

배포판(Distribution) 관점에서도 버전 관리가 이루어진다. 예를 들어, “Humble” 배포판에 속한 소프트웨어 패키지들은 대개 해당 릴리즈 기간 동안 정해진 범위 안에서 버전 업그레이드를 거친다. 이를 수학적으로 조금 더 확장해 벡터 형태로 표현해 보자. ROS2 배포판 상태를 나타내는 벡터를

$$\mathbf{V}_n = \bigl(v_1, v_2, \ldots, v_k\bigr)_n$$

와 같이 정의하고, 각 구성 패키지 버전의 집합을 $\mathbf{V}_n$이라 하자. 만약 릴리즈 업그레이드나 새 기능 통합 등으로 인해 일부 구성 요소 버전이 갱신된다면,

$$\mathbf{V}_{n+1} = \mathbf{V}_n + \mathbf{d},$$

와 같은 형태로 버전 벡터가 변경될 수 있다. 여기서 $\mathbf{d}$는 개별 패키지들의 버전 변화량을 나타낸다.

릴리즈 타임라인 예시

ROS2의 대표 릴리즈들을 간단히 살펴보면, 다음과 같은 시계열을 구성할 수 있다(아래는 예시이며, 실제 버전명과 발표 시기는 자료에 따라 다르다).

위 예시에서 몇몇 버전(Dashing, Foxy, Humble 등)은 LTS 배포판이며, 나머지는 비교적 짧은 기간 동안만 지원받는 일반 릴리즈에 해당한다. 이렇게 공개된 각각의 릴리즈는 저마다 호환되는 주요 OS 버전, 사용 가능한 ROS 패키지 수준, 빌드 툴체인 등에 차이가 존재하기 때문에, 적합한 릴리즈를 선택하는 것은 ROS2 사용자들에게 중요한 이슈다.

Rolling 배포판의 특징

ROS2에는 정식 버전 외에 Rolling 배포판도 존재한다. Rolling은 최신 기능을 실시간으로 반영하기 위해 상시 업데이트되는 배포판으로, 향후 정식 버전이 될 코드의 기반(branch) 역할을 수행한다. Rolling 배포판은 일반적인 소프트웨어 개발 과정에서 ‘개발 브랜치(dev branch)’와 비슷한 개념으로 볼 수 있다.

• 상시 업데이트: Rolling은 ROS2의 다양한 패키지에서 발생하는 변경 사항을 누적 반영한다.

• 비안정성(불확실성): Rolling 버전을 사용하면 최신 기능과 수정사항을 빠르게 적용할 수 있지만, 일부 기능은 안정성이 충분히 검증되지 않았을 수 있다.

• 차기 릴리즈의 원형(prototype): Rolling에서 충분히 검증된 기능 및 패치가 차기 ROS2 정식 릴리즈로 편입된다.

이러한 Rolling 배포판은 일반적인 사용자보다는, ROS2 핵심 기능을 개발하거나 신기술을 적극적으로 적용해 보고 싶은 사용자에게 유용하다. Rolling 배포판이 다음 LTS 혹은 일반 릴리즈로 전환될 때, 일부 기능은 기술적 이유나 의존성 문제 등으로 인해 제외될 수도 있다.

Rolling에서 정식 릴리즈로 전환

Rolling 배포판에서 정식 릴리즈로 전환되기 위해서는 여러 개발 단계와 테스트, 리그레이션(regression) 분석 과정을 거친다. 예컨대 ROS2 내 여러 레이어(예: rclcpp, rcl, rmw 등)와 관련된 수많은 패키지들이 상호 의존성을 지니기 때문에, Rolling에 쌓인 변경 사항이 모두 호환되는지 종합적으로 검증해야 한다.

이를 좀 더 형식적으로 나타내면, Rolling에서의 변화량을 $\mathbf{d}_{\text{rolling}}$이라 할 때,

$$\mathbf{V}_{\text{rolling}}(t) = \mathbf{V}_{\text{baseline}} + \int_{t_0}^{t} \mathbf{d}_{\text{rolling}}(\tau) \, d\tau$$

와 같은 누적 개념으로 볼 수 있다. 이때 $\mathbf{V}{\text{baseline}}$은 이전 정식 릴리즈 시점에서의 패키지 버전 벡터이며, $\mathbf{d}{\text{rolling}}(\tau)$는 $\tau$ 시점에서 Rolling에 반영되는 버전 변화량을 의미한다.

정식 릴리즈로 전환할 시점에

$$\mathbf{V}_{\text{stable}} = \mathbf{V}_{\text{rolling}}(T)$$

와 같이 특정 시점 $T$에서 Rolling이 가진 누적 상태를 ‘동결(freeze)’하여, 버그 픽스나 보안 패치 외에는 큰 기능 추가가 이루어지지 않도록 통제한다. 이후 충분한 검증 기간을 거쳐 새 버전을 최종 확정하게 된다.

EOL(End of Life) 및 유지보수 정책

ROS2 각 릴리즈는 정해진 기간 동안 유지보수와 패치가 제공되며, 이후에는 공식 지원이 중단되어 EOL 상태가 된다. LTS 릴리즈의 경우 EOL까지 비교적 긴 기간(약 3년 이상)으로 유지보수를 받지만, 일반 릴리즈나 Rolling은 그보다 짧은 유지 기간을 갖는다.

EOL 정책은 대체로 다음과 같은 절차를 따른다.

1. EOL 예정 공지 릴리즈 관리팀이 특정 버전의 EOL 시점을 사전에 공지한다.

2. 최종 패치 배포 EOL 직전까지 주요 버그 및 보안 취약점 패치를 제공한다.

3. EOL 도달 릴리즈 관리팀이 해당 버전에 대한 이슈, 버그 리포트, 보안 취약점 보고 등을 더 이상 처리하지 않는다.

이를 시간축으로 표현해 보면, 각 버전의 릴리즈부터 EOL까지의 기간을 $\Delta T_n$이라 할 때,

$$t_{\text{EOL}}^{(n)} = t_{\text{release}}^{(n)} + \Delta T_n$$

$\Delta T_n$의 크기는 LTS 혹은 일반 릴리즈 여부에 따라 달라진다.

버전 충돌 및 호환성 이슈

버전 관리 과정에서 종종 발생하는 문제 중 하나는, 서로 다른 릴리즈 간에 호환되지 않는 API나 메시지 형식 등이 존재하는 경우다. 예컨대 Dashing과 Galactic 사이에 통신 레이어의 일부가 변경되어, 메시지 타입이 호환되지 않을 수 있다. 이를 방지하기 위해 ROS2는 엄격한 REP(ROS Enhancement Proposals) 규칙을 적용하려 노력한다.

• REP-2000: 각 ROS1/ROS2 배포판이 사용하는 OS 버전, C++ 표준, 기본 의존성 패키지 등을 규정한다.

• API 호환성 가이드: 라이브러리 수준에서 API가 변경될 경우, 최소 한 릴리즈 이전부터 관련 사항을 예고한다.

하지만 실제 현장에서는 여전히 여러 버전이 혼재되어 쓰이기 때문에, 다중 ROS 버전(예: 멀티 로봇 환경에서)이 병행 활용될 때 통합 테스트가 까다로워진다. 이런 상황을 완화하기 위해서는 릴리즈 노트나 ROS2 포럼 등을 수시로 참고하여, 업데이트 내용을 빠르게 추적하고 문제 발생 시 적극적으로 이슈를 공유하는 것이 권장된다.

ROS2 릴리즈 사이클 및 버전 관리

Ubuntu 등 OS 버전과의 연동

ROS2는 여러 운영체제를 지원하지만, 특히 Ubuntu LTS 버전과의 연동이 중요하게 취급된다. 이는 다음과 같은 이유에 기인한다.

• 패키지 관리 편의성: Ubuntu의 APT 저장소를 통한 ROS2 패키지 설치 및 업데이트가 용이하다.

• 빌드 환경 일관성: ROS2는 다양한 라이브러리(예: DDS 구현체, rclcpp, rcl 등)에 의존하므로, 비교적 안정된 Ubuntu LTS에서 제공되는 라이브러리가 기준이 될 때 빌드 및 런타임 문제가 줄어든다.

• 장기 지원: Ubuntu의 LTS 주기(5년 지원)와 ROS2 LTS 주기를 맞추는 것이 산업 현장 등에서 보수적인 업그레이드 전략을 취하는 데 유리하다.

ROS2 LTS 릴리즈가 Ubuntu LTS에 맞춰 발표되는 경우가 많으며, 이때 ROS2 LTS 릴리즈의 EOL 시점은 해당 Ubuntu LTS의 지원 기간과 유사하게 설정되는 경향이 있다. 그러나 항상 일대일로 정확히 일치하는 것은 아니며, 일부 시점에서는 서로 다른 주기로 인해 지원 기간이 어긋나기도 한다.

소스 기반 설치와 이슈

ROS2를 소스(source) 기반으로 설치할 경우, 릴리즈 주기 및 버전 관리를 더욱 세심하게 살펴야 한다. 대부분의 사용자는 바이너리 패키지를 이용해 ROS2를 설치하지만, 소스 기반 설치를 통해 특정 기능을 조정하거나 추가 패치를 적용하기도 한다.

소스 기반으로 설치하는 시나리오에서 자주 발생하는 문제점은 다음과 같다.

1. 의존성 충돌: ROS2의 수많은 패키지들이 서로 다른 버전의 라이브러리를 필요로 할 수 있다.

2. 컴파일 실패: Rolling 또는 최신 브랜치에서 빌드 시, 문서화되지 않은 API 변경으로 인해 컴파일이 실패할 수 있다.

3. 장시간 빌드: ROS2 전체 패키지를 한 번에 빌드할 경우, 시스템 사양에 따라 긴 빌드 시간이 필요하다.

이를 수학적으로 살펴보면, ROS2 전체를 구성하는 패키지 세트를 $\mathbf{P}$라 할 때, 소스 설치 시 필요한 종속 라이브러리 집합을 $\mathbf{L}_i$라 하자. 즉,

$$\mathbf{P} = \{ p_1, p_2, \dots, p_n \}, \quad \mathbf{L}_i = \{ \ell_{i1}, \ell_{i2}, \dots \},$$

여기서 $p_i$는 i번째 ROS2 패키지, $\ell_{ij}$는 $i$번째 패키지 빌드·실행에 필요한 $j$번째 라이브러리를 의미한다. 전체 시스템이 올바르게 빌드·실행되기 위해서는

$$\bigcup_{i=1}^{n} \mathbf{L}_i$$

에 속한 라이브러리들이 서로 충돌 없이 만족해야 한다. Rolling이나 특정 신규 릴리즈의 경우 $\mathbf{L}i$가 보다 최신 버전을 요구하거나, 서로 호환되지 않는 조건($\ell{ij}\neq \ell_{kj}$)이 나타나면 빌드가 실패할 수 있다.

유지보수를 위한 브랜치 전략

ROS2 코어 레포지토리(예: rclcpp, rcl, rmw 등)를 비롯해 관련 패키지 레포지토리는 각 릴리즈에 대해 별도의 브랜치를 생성하여 유지보수를 진행한다. 예를 들어 Humble용 브랜치는 humble로 명시되고, Foxy용 브랜치는 foxy 등의 이름을 가진다.

• 핫픽스(Hotfix): 심각한 버그나 보안 취약점이 발견되면 해당 릴리즈 브랜치에 바로 패치가 적용되고, 필요 시 새 패치 버전을 배포한다.

• 새 기능 개발: Rolling 또는 메인 개발 브랜치에서 먼저 구현된 뒤, 안정성이 검증된 기능은 다음 정식 릴리즈 브랜치에 반영될 수 있다.

• 백포트(Backport): LTS 릴리즈에 중요 기능이 필요한 경우, Rolling이나 최신 버전에서 먼저 구현된 변경 사항을 해당 LTS 브랜치에 되돌려 반영하는 절차를 거친다.

각 릴리즈 브랜치는 일정 시점이 지나면 EOL을 맞이하고, 이후에는 새로운 패치가 공식적으로 제공되지 않는다. 따라서 사용자 입장에서는 자신이 사용하는 릴리즈 브랜치의 유지보수 상태를 수시로 확인해야 한다.

멀티 플랫폼 지원과 버전 관리 복잡성

ROS2는 Windows, macOS 등 다양한 운영체제를 지원하지만, 실제로는 Linux(특히 Ubuntu) 위주의 지원이 가장 활발하다. 플랫폼이 다양해질수록 다음과 같은 추가적 복잡성이 발생한다.

• 빌드 툴체인 차이: Windows는 MSVC, Linux는 GCC/Clang, macOS는 Clang 등 다양한 컴파일러를 동시에 고려해야 한다.

• 운영체제별 종속 라이브러리 차이: 일부 DDS 구현체나 GUI 라이브러리가 OS마다 설치 경로나 명칭이 상이할 수 있다.

• 테스트 인프라 확장: 모든 플랫폼에서 통합 테스트를 자동화하기 위해서는 CI/CD 환경이 더 복잡해진다.

버전 관리 측면에서는, 이를 쉽게 표현하기 위해 ‘플랫폼 스펙트럼’을 추가 차원으로 간주할 수 있다. 예컨대 ROS2 버전을 수학적으로 $\mathbf{V}$라 할 때, 지원 플랫폼을 $\mathbf{S}$로 나타내면,

$$\mathbf{V} \times \mathbf{S} = \{ (v, s) \mid v \in \mathbf{V}, \, s \in \mathbf{S} \}$$

와 같은 형태로 확장된다. 즉, 버전 vv와 플랫폼 ss의 조합에 대해 별도의 테스트와 유지보수가 필요한 셈이다. 릴리즈 주기가 바뀌거나 새로운 기능이 추가될 때, 해당 조합을 모두 만족하는지 확인하는 것은 상당한 인력과 시간이 요구되는 작업이다.

Semantic Versioning의 적용

ROS2에서는 일반적으로 Semantic Versioning(semver) 규칙을 따르려 노력한다. semver는 $\mathbf{x.y.z}$ 형태로 버전을 표현하며, 다음과 같은 해석을 제공한다.

• x (Major): 하위 호환성을 깨뜨리는 변경사항이 포함될 때 증가한다.

• y (Minor): 하위 호환성을 유지하면서 새 기능이 추가될 때 증가한다.

• z (Patch): 하위 호환성을 유지한 채 버그나 보안 취약점이 수정될 때 증가한다.

이 규칙은 ROS2 자체 버전에만 적용되는 것이 아니라, ROS2에 소속된 여러 패키지(예: rclcpp, rmw, nav2, perception 등)에서도 권장된다. 예를 들어 특정 패키지가 버전 2.3.1에서 2.4.0으로 올라갈 경우, 이는 새로운 기능이 추가되었고 하위 호환성은 깨지지 않았음을 의미한다.

그러나 실제 ROS2 프로젝트 전반에 이 규칙이 완벽히 통일되어 적용된다고 보긴 어렵다. 일부 패키지는 아직도 초기 개발 단계를 거치고 있어, semver 관점에서 ‘Major 버전’이 명확히 구분되지 않을 수 있다. 또한 Rolling 배포판에서는 하루가 다르게 API가 변하기 때문에, semver를 엄격히 지키기가 현실적으로 쉽지 않다.

미리보기(Alpha, Beta) 및 RC(Release Candidate)

ROS2는 정식 버전을 내놓기 전, Alpha 혹은 Beta 단계의 미리보기 릴리즈를 공개하는 경우도 있다. 일반 사용자보다는 ROS2 내부 개발자나 핵심 기능 테스트에 참여하려는 이들을 위해 배포되며, 주로 다음과 같은 단계를 거칠 수 있다.

1. Alpha 버전: 기능이 기초적으로 구현되었지만 아직 불안정하고, 변경 가능성이 큰 상태.

2. Beta 버전: 기본 기능이 안정화되어가지만, 여전히 주요 버그나 성능 문제가 발견될 수 있는 상태.

3. RC (Release Candidate): 실제 정식 릴리즈 후보 버전으로, 치명적 결함이 발견되지 않으면 그대로 정식 버전으로 전환될 가능성이 높다.

이러한 사전 버전들은 ‘테스트용’ 성격이 강하며, 하위 호환성을 보장하지 않거나 자주 깨트릴 수 있다. 따라서 연구·개발 목적이 아닌 프로덕션 환경에서는 사용이 권장되지 않는다.

Docker 이미지와 버전 태깅

최근 ROS2는 Docker Hub 및 GitHub Container Registry 등을 통해 공식 Docker 이미지를 제공한다. 각 이미지는 ROS2 릴리즈 버전에 따라 태그를 갖는다.

• 예: ros:humble, ros:foxy, ros:rolling 등

• 패치 버전이 업데이트되면 ros:humble-<패치번호> 형태로 세부 태그가 생성된다.

Docker를 활용하면 다양한 OS 환경에서 ROS2 버전을 손쉽게 실험하거나 배포할 수 있다. 하지만 Docker 이미지 또한 ROS2 릴리즈 주기를 반영하므로, 특정 시점의 이미지를 그대로 쓰는 경우 빠른 시일 내 보안 패치나 버그 수정이 누락될 수 있다. 이를 방지하려면 주기적으로 이미지를 재빌드하거나, :latest 대신 명시적 버전 태그를 사용하여 신중하게 업데이트할 필요가 있다.

예시로 Docker 기반 테스트 파이프라인을 간단히 도식화해 보면 아래와 같다.

위 구조에서 ROS2 버전 태그를 교체하거나, Rolling 이미지를 기반으로 신규 테스트를 수행함으로써 버전별 호환성과 성능을 비교할 수 있다.

커뮤니티 참여와 TSC(Technical Steering Committee)

ROS2 릴리즈 사이클과 버전 관리는 TSC(Technical Steering Committee) 주도로 결정된다. TSC는 OSRF(Open Source Robotics Foundation)와 커뮤니티 대표, 기업 파트너 등이 모여 다음 사항을 논의한다.

• 릴리즈 로드맵 확정

• LTS 버전 선정 및 지원 기간 결정

• 개발 우선순위 설정(핵심 기능, 안정화 작업 등)

• 주요 의사결정(큰 규모 API 변경, DDS 구현체 정책 등)

커뮤니티 구성원들은 ROS2 레포지토리의 이슈·PR(풀 리퀘스트)을 통해 의견을 제시할 수 있고, REP(ROS Enhancement Proposals)를 제출하여 공식 제도화된 절차로 논의에 참여할 수 있다. 이를 통해 버전 관리를 포함한 ROS2 전반의 방향성이 결정된다.

임베디드·IoT 환경에서의 릴리즈 고려사항

ROS2는 임베디드 환경이나 소형 IoT 기기에서도 동작할 수 있도록 경량화와 실시간성 등을 고려하고 있다. 이러한 요구 사항은 릴리즈 주기와 버전 관리에 추가적인 복잡성을 부과한다.

• 하드웨어 아키텍처 다양성: x86_64뿐만 아니라 ARM(예: Raspberry Pi) 계열 등 다양한 프로세서 아키텍처에 대한 바이너리 혹은 소스 빌드를 고려해야 한다.

• 크로스 컴파일 지원: 제한된 리소스의 임베디드 시스템에서는 직접 컴파일이 어렵기 때문에, 호스트 PC(개발용 환경)에서 크로스 컴파일한 후 타깃 기기로 배포하는 전략을 사용한다.

• 실시간 커널·RTOS: 일반 데스크톱용 OS가 아닌 실시간(Real-Time) OS를 사용하는 경우, ROS2 코어를 구성하는 DDS나 rclcpp 등이 해당 커널 환경에서 정상 동작하도록 패치가 필요할 수 있다.

이를 조금 더 수식적으로 나타내면, 특정 릴리즈 $r_n$에서 지원 가능한 하드웨어 플랫폼·OS 조합을 $\mathbf{C}(r_n)$이라 정의할 수 있다. 즉,

$$\mathbf{C}(r_n) = \bigl\{ (arch, os) \mid \text{ROS2 릴리즈 } r_n \text{이 정상 동작하는 아키텍처 } arch \text{와 OS } os \bigr\}$$

임베디드·IoT 기기의 요구 사항이 까다로울수록 $\mathbf{C}(r_n)$에서 빠지는 조합이 늘어날 수 있으며, 이는 사실상 릴리즈 주기와 버전 관리에 제약을 가한다.

벤더별 맞춤 배포판(Vendor Distributions)

일부 기업(예: Apex.AI, ADLINK, AWS 등)은 자체적으로 ROS2를 커스터마이징해 벤더별 배포판을 제공하기도 한다. 이들은 ROS2의 릴리즈 사이클을 기본적으로 준수하면서도, 산업 안전 표준(예: ISO 26262)이나 보안 인증 등을 충족하기 위해 특정 버전을 장기 유지하거나 독자 패치를 적용한다.

• 산업용 안전 인증: 자율주행·로보틱스 분야에서 안전 표준을 만족하기 위해, LTS 기반으로 엄격한 테스트와 코드 분석(Static/Dynamic Analysis)을 수행한다.

• 클라우드 연동 기능 특화: AWS나 Azure 같은 클라우드 서비스와 긴밀히 연동되는 패키지를 포함해, ROS2 버전을 재배포하기도 한다.

• 하드웨어 최적화: GPU 가속 라이브러리(CUDA 등)나 FPGA 기반 가속을 위해, 특정 DDS 구현체나 커스텀 미들웨어를 추가한다.

이로 인해 ROS2 “공식” 배포판과 벤더별 “확장” 배포판 간 버전 호환성 문제도 발생할 수 있다. 예를 들어, 특정 벤더 배포판에서 변경된 API가 공식 ROS2 릴리즈에는 반영되지 않은 상태라면, 사용자 입장에서 혼란이 생길 수 있다.

멀티 릴리즈 동시 운영 시나리오

일부 프로젝트나 기업은 동시에 여러 ROS2 릴리즈를 병행해서 운영한다. 예를 들어, 기존 시스템은 Foxy 기반으로 개발되었고, 신규 기능은 Humble 기반으로 개발하고 있을 수 있다. 이 경우 다음과 같은 운영 전략이 고려된다.

1. 분리된 인프라 각 릴리즈마다 별도의 개발·배포 파이프라인을 운영한다. 장점은 충돌 위험을 줄일 수 있다는 것이나, 비용이 크다.

2. 단계적 전환(Migration) 새 릴리즈에 대응하는 패키지를 먼저 도입하고, 구 릴리즈 기반 패키지와 상호 연동이 되는지 점진적으로 확인한다.

3. 컨테이너 활용 Docker 등으로 서로 다른 ROS2 버전을 격리된 환경에서 실행하며, 네트워크 인터페이스(DDS, ROS 메시지 브리지 등)로 통신을 주고받는다.

이를 수학적·집합적으로 나타내면, 회사나 프로젝트 전반에서 사용 중인 ROS2 릴리즈 집합을 $\mathbf{R}$라 할 때,

$$\mathbf{R} = \{ r_1, r_2, \dots, r_m \},$$

각 릴리즈마다 사용되는 패키지 버전 벡터 $\mathbf{V}_{r_i}$가 존재한다. 동시에 운영하기 위해서는

$$\forall r_i, r_j \in \mathbf{R}, \quad \text{호환성 조건 } H\bigl(\mathbf{V}_{r_i}, \mathbf{V}_{r_j}\bigr) \text{ 이 충족되어야 한다.}$$

여기서 HH는 메시지 타입 호환성, 미들웨어 레벨의 통신 가능성 등을 종합적으로 나타내는 함수다.

릴리즈 사이클 정보 공유 및 최신화

ROS2 생태계는 빠르게 진화하므로, 최신 릴리즈 정보를 공식 문서나 커뮤니티 채널을 통해 공유하고 있다.

• ROS Discourse: 릴리즈 일정, 새로운 REP, 주요 변경사항 공지

• ROS2 공식 문서: 각 버전별 설치 방법, 호환 OS/플랫폼 리스트, 알려진 이슈 목록

• ROSCon 등 컨퍼런스: 실제 사용자 사례와 베스트 프랙티스 발표

사용자는 주기적으로 이러한 정보를 확인함으로써, 향후 릴리즈 업데이트를 대비할 수 있다. 예컨대 LTS 릴리즈 EOL 시점이 다가올 때, 다음 LTS나 Rolling 버전으로 미리 전환하는 시나리오를 고민할 수 있다.