ROS2 Humble의 종속성 관리 및 버전 업데이트

개요

ROS2 Humble 배포판을 사용할 때, 시스템 내 여러 패키지와 라이브러리 간 의존 관계를 효과적으로 관리하고, 필요한 시점에 맞추어 버전을 업데이트하는 과정은 프로젝트 안정성과 생산성을 높이는 핵심 요소이다. ROS2는 내부적으로 다양한 DDS 구현체(Fast-DDS, Cyclone DDS 등), 그리고 다양한 언어 및 빌드 툴에 의존하므로, 각종 필수/선택 패키지를 적절히 관리해주는 작업이 매우 중요하다.

또한 ROS2 Humble은 배포판(Distribution) 단위로도 종속성이 관리되지만, 프로젝트 단위(개별 패키지)로도 추가 종속성을 설정해주어야 한다. 이를 관리하기 위해서는 ROS2의 빌드 툴(colcon)과 패키지 매니저(apt, pip 등)를 올바르게 활용해야 하며, 패키지 버전 충돌을 최소화하기 위해 체계적인 버전 업데이트 정책을 세워야 한다.

종속성 분류

ROS2 Humble에서 관리되는 종속성은 크게 다음과 같은 범주로 나뉜다.

1. 시스템 종속성(System Dependencies) 리눅스 OS에서 ROS2가 빌드되고 동작하기 위해 필요한 필수 라이브러리와 개발 툴이다. 예: CMake, gcc, Python3, OpenCV 등.

2. ROS2 기본 종속성(ROS2 Core Dependencies) ROS2 실행과 빌드에 반드시 필요한 rclcpp, rclpy, rmw, Fast-DDS 등. 이러한 종속성은 보통 apt를 통해 설치되며, ROS2 Humble의 버전에 따라 특정 버전의 DDS나 rcl 인터페이스가 고정된다.

3. 추가 패키지 종속성(Extra Packages) 사용자 정의 패키지나 서드파티 패키지(예: navigation, perception 등)에서 추가로 필요한 라이브러리나 툴이다. colcon 빌드시 package.xml 혹은 setup.py에서 의존성을 명시하거나, apt, pip 등을 통해 별도로 설치한다.

종속성 그래프

ROS2 패키지 간 종속 관계는 유향 비순환 그래프(DAG) 형태로 표현될 수 있으며, 이때 각 노드는 패키지를 나타내고 간선은 의존 관계를 나타낸다. 예를 들어, 특정 패키지 A가 패키지 B, C를 필요로 한다면, 아래와 같은 구조가 형성된다.

이때 A를 빌드하기 위해서는 B와 C가 먼저 빌드되어 있어야 한다. colcon은 이 그래프를 내부적으로 계산하여 빌드 순서를 자동으로 결정한다.

버전 충돌과 해결 전략

ROS2 Humble을 사용하는 동안, 다음과 같은 버전 충돌 문제가 발생할 수 있다.

• ROS2 코어 라이브러리 버전 충돌: apt 등을 통해 ROS2 코어 라이브러리를 업데이트했는데, 일부 패키지가 이전 버전에 종속되어 있는 경우.

• 시스템 라이브러리 호환성 문제: 예를 들어 OpenCV 버전이 달라서 이미지 프로세싱 노드가 동작하지 않는 경우.

• 서드파티 라이브러리 충돌: ROS2에서 지원하지 않는 버전의 라이브러리를 억지로 설치하려 할 때 발생하는 문제.

이를 해결하기 위해서는 다음과 같은 접근법이 필요하다.

1. 고정 버전(Version Pinning) 사용 apt의 apt-mark hold 혹은 rosdep 설정 등을 통해 특정 패키지 버전을 고정할 수 있다. 이렇게 하면, 의도치 않은 업데이트로 인한 충돌을 어느 정도 방지할 수 있다.

2. 절차적 업데이트(Incremental Update) 전체 ROS2 패키지를 한꺼번에 업데이트하기보다는, 영향을 덜 주는 패키지부터 순차적으로 업데이트하여 문제 발생 지점을 명확히 파악한다.

3. 격리된 테스트 환경(Overlay Workspace) 활용 실제 운영 환경과 분리된 별도 워크스페이스에서 패키지 버전을 시험적으로 올려보고, 문제없을 시 메인 워크스페이스에 반영하는 방식을 사용한다.

종속성 표현의 수학적 관점

ROS2 패키지 간 의존 관계를 행렬로 나타낼 수도 있다. 예를 들어, 종속성을 다음과 같이 이진(0/1) 값으로 표기할 때,

$$\mathbf{D} = \begin{bmatrix} 0 & 1 & 1 \\ 0 & 0 & 1 \\ 0 & 0 & 0 \end{bmatrix}$$

• $\mathbf{D}$의 행은 '의존성을 갖는 패키지'를,

• 열은 '의존 대상 패키지'를 의미한다.

$\mathbf{D}_{ij} = 1$이라면 $i$번째 패키지는 $j$번째 패키지에 의존한다. 이 행렬을 기반으로, 위상 정렬(Topological Sort)을 수행하여 빌드 순서를 결정할 수 있다.

워크스페이스 오버레이(Overlay) 구조

ROS2는 여러 워크스페이스를 동시에 사용할 수 있도록 설계되어 있다. 예를 들어, “Humble” 배포판의 기본 워크스페이스(base workspace) 위에, 사용자 패키지를 모아둔 오버레이 워크스페이스(overlay workspace)를 설정할 수 있다. 이를 통해 별도의 오버레이 워크스페이스에서 패키지 버전을 테스트하고, 문제가 없음을 확인한 후 실제 프로젝트나 운영 환경에 반영하는 작업을 단계적으로 수행할 수 있다.

오버레이 워크스페이스는 일반적으로 다음과 같이 구성된다.

1. ROS2 Humble 기본 워크스페이스 apt 등을 통해 설치된 ROS2 Humble의 기본 설치 위치이다. 대부분의 핵심 패키지(rclcpp, rclpy 등)가 여기에 존재한다.

2. 사용자 정의 워크스페이스 catkin이나 colcon으로 빌드되는 사용자 패키지를 담고 있는 디렉터리이다. 예: ~/ros2_ws/src.

3. 추가 테스트 워크스페이스 새 버전의 패키지를 시험적으로 설치하거나, 특정 서드파티 패키지를 별도로 테스트하기 위한 워크스페이스이다. 배포판 전체 업데이트 전에 이곳에서 종속성 충돌 여부를 미리 점검할 수 있다.

오버레이 워크스페이스 설정 시, source 명령어를 통해 특정 순서로 환경을 등록함으로써, 동시에 설치된 여러 패키지 중 어떤 것을 우선적으로 참조할 것인지 결정하게 된다. 예를 들어 아래 예시와 같이, 먼저 기본 워크스페이스를 참조하고, 그 위에 테스트 워크스페이스, 마지막으로 메인 작업 워크스페이스 순으로 source를 실행함으로써 우선순위를 조정할 수 있다.

source /opt/ros/humble/setup.bash
source ~/test_ws/install/setup.bash
source ~/main_ws/install/setup.bash

colcon과 패키지 버전 관리

ROS2 Humble에서 패키지를 빌드할 때, colcon은 패키지 내 package.xml 혹은 setup.py에 명시된 의존성을 자동으로 확인하고, 필요한 순서대로 빌드한다. 이때, 아래와 같은 전략을 통해 버전 관리를 체계적으로 할 수 있다.

• 선택적 빌드: 특정 패키지만 업데이트 및 빌드하고 싶을 경우, colcon build --packages-select <패키지명> 명령을 활용할 수 있다. 이렇게 하면 전체를 빌드할 필요 없이 부분적인 버전 업데이트 테스트가 가능하다.

• 의존 관계 시각화: colcon graph 명령 등으로 프로젝트 내 패키지 의존 그래프를 확인하고, 업데이트하려는 패키지가 어떤 하위 패키지에 영향을 주는지 파악한다.

• 캐시 활용: colcon은 이전 빌드 결과를 캐시로 남겨두므로, 변경 사항이 없는 패키지는 재빌드하지 않는다. 불필요한 재빌드를 줄이면, 대규모 프로젝트에서도 빠른 업데이트 테스트가 가능하다.

다중 언어 환경에서의 종속성 관리

ROS2 Humble은 C++, Python, (필요하다면) 다른 언어를 동시에 사용할 수 있으므로, 각 언어별 패키지 매니저(gcc, clang, pip, conda 등)와의 버전 충돌도 고려해야 한다. 예를 들어, Python 패키지 버전을 프로젝트마다 다르게 유지하려면 virtualenv나 conda를 활용할 수 있다. 다음과 같은 방식을 활용할 수 있다.

1. Python 가상환경 활용 테스트 워크스페이스마다 별도의 Python 가상환경을 생성하여, 필요한 패키지 버전을 독립적으로 설치해 관리한다.

2. C++ 컴파일러 버전 통일 g++와 clang 등 서로 다른 컴파일러가 공존할 수 있으나, 가능한 한 프로젝트 단위로 통일해 사용하는 것이 빌드 및 런타임 호환성 측면에서 유리하다.

3. CMake 옵션 설정 cmake 옵션 중 -DCMAKE_CXX_STANDARD=17처럼 특정 C++ 표준을 고정하는 설정을 통해, 일부 라이브러리의 호환성 문제를 줄일 수 있다.

부분 업데이트 시 고려해야 할 수학적 접근

ROS2 패키지 간 의존 관계를 $\mathbf{D}$로 표현했을 때, 일부 패키지(예: $p_i$)만 업데이트할 경우, 해당 패키지에 직접적으로 의존하는 다른 패키지(자식 노드), 그리고 자식 노드가 다시 의존하는 패키지(손자 노드) 등 광범위하게 영향이 전파될 수 있다.

즉, $p_i$가 $\mathbf{D}_{ij} = 1$인 모든 $p_j$의 조합에도 간접 영향이 파급된다. 이를 좀 더 일반화하면, 다음과 같은 지표를 정의할 수 있다.

$$\mathbf{R} = \sum_{k=1}^{\infty} \mathbf{D}^k$$

이때 $\mathbf{R}_{ij}$가 1 이상이면, $i$번째 패키지가 업데이트될 때 $j$번째 패키지가 직·간접적으로 영향을 받는다는 의미이다. 물론 실제 계산에서는 무한 합을 쓰지 않고, 그래프의 유한 깊이와 위상 정렬을 통해 실질적인 영향 범위를 산출한다.

CI/CD 환경에서의 버전 업데이트

개발 과정에서 꾸준히 발생하는 패키지 변경 사항과 종속성 갱신을 빠르고 안정적으로 확인하기 위해, CI/CD(Continuous Integration/Continuous Deployment) 파이프라인을 구성하는 경우가 많다. 특히 ROS2 Humble 기반 프로젝트에서는 종속성 충돌을 조기에 발견하고, 자동화된 빌드 및 테스트를 수행하는 과정을 통해 생산성을 높이고 리스크를 줄일 수 있다. 일반적인 CI/CD 파이프라인 구성은 다음과 같은 단계를 포함한다.

1. 빌드(Colcon) 단계

   • 소스 코드를 체크아웃한 후, colcon build를 통해 모든 패키지를 빌드한다.

   • package.xml에 명시된 의존 라이브러리를 rosdep install로 설치하거나, 추가로 필요한 pip 라이브러리를 설정 파일(requirements.txt 등)에 따라 설치한다.

2. 테스트(Colcon Test) 단계

   • 빌드가 성공적으로 끝나면, colcon test를 수행한다.

   • 각 패키지 내 CMakeLists.txt 또는 setup.py에서 정의한 단위 테스트, 통합 테스트를 실행한다.

   • 테스트 결과는 colcon test-result 등을 통해 수집 및 리포팅된다.

3. 정적 분석(Static Analysis) 및 코드 스타일 검사

   • ROS2 Humble에서는 ament_lint 계열(ament_lint_auto, ament_cpplint 등)의 패키지를 통해 코딩 규칙이나 포맷을 검사할 수 있다.

   • 빌드 단계와 별도로 수행하거나, 빌드 전후로 자동화하여 코드 품질을 점검한다.

4. 패키지 버전 검증

   • 만약 특정 패키지에 대한 새 버전을 테스트한다면, 해당 패키지 및 연관 패키지(직접·간접 의존하는 패키지)까지 포함해 빌드와 테스트를 진행해 본다.

   • CI 시스템 상에서 성공하면, 메인 브랜치나 릴리스 브랜치에 반영하도록 한다.

5. 배포(Deployment) 또는 Docker 컨테이너 생성

   • CI 단계가 모두 성공했다면, 실제 로봇 또는 시뮬레이션 환경에 적용하기 위한 배포 단계를 진행한다.

   • Docker를 사용하는 경우, Dockerfile 안에 ROS2 Humble과 필요한 라이브러리, 새 패키지를 모두 설치한 이미지를 빌드해 레지스트리에 업로드한다.

이처럼 CI/CD 파이프라인 내에서 버전을 자동으로 업데이트, 빌드, 테스트, 배포하는 과정을 표준화하면, 프로젝트 규모가 커지더라도 의존성 충돌과 호환성 문제를 빠르게 발견하고 해결할 수 있다.

rosdep을 활용한 자동 의존성 설치

ROS2 Humble 기반 패키지를 설치할 때 가장 일반적인 방법 중 하나가 rosdep 유틸리티를 통한 자동 의존성 해결이다. package.xml 파일에서 선언된 <depend> 태그를 기준으로, apt(또는 brew, yum 등 OS 패키지 매니저)를 사용해 필요한 라이브러리를 자동으로 설치해준다. 주로 다음 과정을 통해 진행한다.

# rosdep 초기화(최초 1회)
sudo rosdep init
rosdep update

# 워크스페이스로 이동
cd ~/ros2_ws

# 패키지별 의존성 설치
rosdep install --from-paths src --ignore-src -r -y

• --from-paths src는 현재 워크스페이스 내 src 디렉터리 아래 모든 패키지의 의존성을 검사하겠다는 의미다.

• --ignore-src는 소스에서 빌드해야 하는 ROS2 패키지는 제외하고, 순수 라이브러리(apt 등으로 설치 가능한 항목)만 처리한다.

• -r -y는 의존성 설치 중 사용자에게 일일이 확인을 요구하지 않고(automatic), 필수 패키지가 누락된 경우 에러를 낸다는 의미다.

이 과정을 자동화 스크립트나 CI 파이프라인에 연동해 두면, 새로운 개발 환경을 구성하거나 변경된 종속성을 반영할 때 편리하게 설치 과정을 진행할 수 있다.

Docker를 이용한 환경 격리

ROS2는 다양한 종속성 패키지와 충돌이 발생할 수 있으므로, 실제 로봇 플랫폼과 별개로 Docker를 활용해 격리된 환경을 구성하는 사례가 많다. 도커 이미지를 통해 특정 버전의 ROS2 Humble과 종속 라이브러리를 동일하게 유지하면, 로컬 개발 환경이나 CI/CD 서버 어느 곳에서도 일관된 빌드 및 실행 환경을 재현할 수 있다.

다음은 간단한 예시 Dockerfile이다.

FROM ubuntu:22.04

# 1. 필수 패키지 및 ROS2 설치
RUN apt-get update && apt-get install -y curl gnupg2 lsb-release
RUN curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | apt-key add -
RUN sh -c 'echo "deb http://packages.ros.org/ros2/ubuntu `lsb_release -cs` main" > /etc/apt/sources.list.d/ros2-latest.list'
RUN apt-get update && apt-get install -y ros-humble-desktop

# 2. 의존 라이브러리 설치
RUN apt-get install -y python3-colcon-common-extensions python3-rosdep

# 3. rosdep 초기화
RUN rosdep init && rosdep update

# 4. 환경 변수 설정
SHELL ["/bin/bash", "-c"]
RUN echo "source /opt/ros/humble/setup.bash" >> /root/.bashrc

CMD ["/bin/bash"]

이후 컨테이너 내에서 rosdep install 등을 추가로 실행하며, 프로젝트 빌드를 위한 준비가 끝난다. 이렇게 생성된 도커 이미지를 CI 파이프라인과 연동할 수도 있고, 개발 팀 전체가 동일한 베이스 이미지를 사용해 협업함으로써 버전 충돌 문제를 최소화할 수 있다.

런타임 환경에서의 버전 업데이트 고려 사항

ROS2 Humble 기반 노드를 실제 로봇에 배포하거나, 상시 가동되는 서버 환경에서 운영할 경우, 런타임 업데이트 시나리오도 고려해야 한다.

1. 무중단 업데이트(Zero-downtime Update) 노드 간 통신이 DDS로 이루어지므로, 일부 노드를 종료하고 업데이트한 뒤 재시작해도 다른 노드가 재연결 과정을 자동으로 수행한다. 다만, 중요한 데이터 흐름에 끊김이 발생하지 않도록 순차적인 롤링 업데이트 전략을 세워야 한다.

2. 버전 호환성 노드 간 메시지 타입이 변경되었을 경우, 새 버전 노드와 구 버전 노드 간 통신 호환성이 깨질 수 있다. 이때는 메시지 정의(.msg 파일 등)를 확장하거나, 임시 변환 노드를 두어 점진적으로 마이그레이션하는 접근이 필요하다.

3. 보안 패치 ROS2 코어 라이브러리와 관련된 보안 취약점 패치가 배포된 경우, 운영 환경에서 빠르게 반영해야 할 수도 있다. 이때 종속 패키지들과의 호환성을 시험하기 위해, 별도의 테스트 워크스페이스나 Docker 이미지를 먼저 사용해 보는 것이 안전하다.

From-Source Installation vs Binary Installation

ROS2 Humble은 공식적으로 apt 패키지(우분투 기준), dnf 패키지(페도라 기준) 등을 통해 바이너리(Binary) 형태로 설치할 수 있다. 그러나 일부 상황에서는 ROS2를 소스(Source) 레벨에서 직접 빌드해 사용하는 것이 유리할 수 있다. 두 방식 간 주요 차이점은 다음과 같다.

1. 설치 편의성과 안정성

   • 바이너리 설치: 배포판 레포지토리에서 제공하는 검증된 버전을 바로 설치하므로, 설치 편의성이 높고 시험이 잘 된 조합으로 안정성이 높다.

   • 소스 설치: 의존 라이브러리 버전을 사용자가 정밀하게 제어할 수 있으나, 설치에 더 긴 시간이 걸리고, 빌드 실패 위험성이 존재한다.

2. 버전 커스터마이징

   • 바이너리 설치: 각종 라이브러리의 버전은 ROS2 Humble 배포판과 연동된 패키지 레포지토리에 의해 결정되므로, 자율적 선택 폭이 좁다.

   • 소스 설치: core 라이브러리(예: rclcpp, rmw)부터 DDS 구현체, 서드파티 종속성(OpenCV, PCL 등)까지 자유롭게 버전을 지정해 빌드할 수 있다.

3. 의존성 관리 난이도

   • 바이너리 설치: 대부분의 필수 라이브러리가 패키지 매니저에 의해 자동 해결되므로, 의존성 충돌이 상대적으로 적다.

   • 소스 설치: colcon, rosdep, CMake 옵션 등 다양한 레벨에서 종속성을 관리해야 하므로, 프로젝트 규모가 커질수록 체계적인 빌드 스크립트와 문서화가 필수적이다.

4. 업데이트 및 유지보수

   • 바이너리 설치: apt 업그레이드를 통해 전체 버전을 일괄 업데이트할 수 있으며, ROS2 메인테이너가 제공하는 보안 패치 등을 빠르게 반영하기 쉽다.

   • 소스 설치: 개별 패키지마다 git pull 등의 방식으로 최신 커밋을 적용한 후, 빌드를 다시 수행해야 한다. 버전 호환성 이슈가 발생할 수 있으므로, 빌드 및 테스트 자동화가 중요하다.

Cross-Compilation for Embedded Systems

ROS2 Humble을 임베디드 장치(소형 컴퓨팅 보드, 마이크로컨트롤러 등)에서 사용하기 위해서는 크로스 컴파일(Cross-Compilation) 기술을 적용해야 할 때가 많다. ARM 아키텍처용 ROS2 빌드를 예로 들면, 호스트(데스크톱 PC 등 x86-64)에서 ARM용 Toolchain(gcc-arm, clang 등)을 설정한 뒤, 다음과 같은 과정을 거친다.

1. 크로스 컴파일 도구 및 툴체인 설정

   • 예: arm-none-linux-gnueabihf-gcc 또는 aarch64-linux-gnu-gcc 등.

   • CMake 또는 colcon 빌드 스크립트에서 CMAKE_TOOLCHAIN_FILE을 지정하여, 타겟 아키텍처와 라이브러리 경로를 설정한다.

2. sysroot 구성

   • 임베디드 보드의 루트 파일 시스템(혹은 유사 환경)을 로컬에 복사해두거나, chroot 또는 도커 이미지 형태로 준비한다.

   • ROS2 Humble 빌드 과정에서 필요한 기본 라이브러리(glibc, libstdc++ 등)를 sysroot 경로로부터 찾도록 설정한다.

3. 단계적 빌드

   • 먼저 core 라이브러리(rcl, rmw, rmw_*_cpp 등)를 크로스 컴파일한다.

   • 이후 의존성이 큰 패키지(sensor_msgs, nav2 등) 순으로 빌드 범위를 넓혀간다.

   • colcon build --merge-install --packages-up-to <패키지명> 등을 통해 단계별로 필요한 패키지만 우선 빌드해볼 수 있다.

4. 런타임 테스트

   • 빌드가 성공하면, 생성된 install 디렉터리(또는 .deb 패키지 등)를 임베디드 보드에 복사한다.

   • 보드에서 ROS2 노드를 실행해 정상 동작 여부를 확인한다. DDS 구현체(Fast-DDS, Cyclone DDS 등)가 타겟 환경에 맞는지, RTOS 환경이라면 지원되는 DDS 버전이 있는지 등을 추가로 점검해야 한다.

이러한 과정을 통해, 컴퓨팅 리소스가 제한된 임베디드 보드에서도 ROS2 Humble을 동작시킬 수 있으며, 프로젝트 요구 사항에 따라 필요한 패키지만 선택적으로 빌드해 용량을 최소화할 수 있다.

Bloom을 이용한 ROS2 패키지 배포

ROS2 Humble 기반 패키지를 좀 더 공식적으로 관리하고, ROS 빌드 팜(ROS Build Farm)을 통해 자동 빌드를 진행하기 위해서는 Bloom 도구를 활용해 배포(Release) 과정을 진행할 수 있다. Bloom은 ROS 생태계에서 개발된 패키지 배포 자동화 유틸리티로, 다음과 같은 절차를 따른다.

1. 소스 저장소(Upstream Repository)

   • GitHub, GitLab 등에서 ROS2 패키지(예: my_ros2_pkg)의 소스를 관리한다.

   • package.xml, CMakeLists.txt(또는 setup.py) 등의 파일에 종속성 및 버전을 정확하게 명시한다.

2. 릴리스 저장소(Release Repository)

   • Bloom은 배포에 필요한 메타데이터와 패치 정보를 저장하는 별도 저장소(예: my_ros2_pkg-release)를 자동으로 생성한다.

   • 이 과정에서 Debian 메타데이터 등을 포함한 패치가 자동으로 추가되어, ROS Build Farm에서 .deb 패키지를 빌드할 수 있도록 구성된다.

3. bloom-release 명령

   • 로컬 환경에서 bloom-release --rosdistro humble --track humble <패키지명> 명령을 실행하면,

   • Bloom이 소스 저장소와 최신 태그(tag) 상태를 확인하고, 릴리스 저장소로 필요한 파일을 생성/업데이트한다.

4. rosdistro PR 생성

   • Bloom은 릴리스 저장소를 업데이트한 뒤, rosdistro(ROS2 패키지 인덱스) 저장소에 Pull Request를 자동 생성하거나, 생성할 수 있도록 안내한다.

   • rosdistro에 반영되면, ROS Build Farm이 해당 패키지 빌드를 자동으로 스케줄링하고, 최종적으로 apt 레포지토리에 .deb 파일이 등록된다.

아래는 Bloom 기반 배포 프로세스를 간단히 나타낸 mermaid 플로차트 예시다.

릴리스 버전 관리와 Semantic Versioning

ROS2 Humble 패키지의 버전을 관리할 때는 Semantic Versioning(semver) 규칙을 권장한다. 예를 들어, MAJOR.MINOR.PATCH 형태의 버전 번호를 사용한다면,

• MAJOR 버전: 호환성을 깨는 API 변경(메시지 타입 변경, 주요 함수 시그니처 변경 등)이 있을 때 증가

• MINOR 버전: 호환성은 유지되지만, 기능이 추가된 경우 증가

• PATCH 버전: 호환성은 유지되며, 버그 수정이나 마이너 개선만 있을 때 증가

package.xml의 <version> 태그를 통해 버전 번호를 관리하고, Bloom 릴리스 과정에서 Git 태그와 연동하여 해당 버전을 빌드·배포하게 된다.

rosdistro와 인덱스 관리

ROS 생태계는 각 ROS 배포판(Humble, Iron 등)에 대해 별도의 인덱스 정보를 rosdistro 저장소에서 관리한다. 예:

• humble/distribution.yaml

• rolling/distribution.yaml

각 배포판의 distribution.yaml에는 패키지 이름과 릴리스 저장소 URL, 버전 정보 등이 기술된다. Bloom으로 새 릴리스를 진행하면, rosdistro에 추가된 Pull Request가 머지(Merge)된 후 ROS Build Farm이 새 패키지를 빌드 및 배포한다. 따라서 rosdistro 저장소는 ROS2 패키지 배포를 위한 가장 중요한 관리 포인트이며, 패키지 버전 충돌이 발생하지 않도록 신중하게 등록해야 한다.

릴리스에 따른 의존성 업데이트

Bloom이 특정 패키지를 Humble에 릴리스할 때, 해당 패키지가 의존하는 다른 패키지도 정상적으로 Humble용 .deb 형태로 배포 가능한지 확인해야 한다. 예를 들어,

• my_navigation_pkg가 my_msg_pkg(메시지 정의 패키지)에 의존한다면, my_msg_pkg 역시 Humble 배포판에 배포되어 있어야 한다.

• 만약 하위 패키지가 아직 Humble에 릴리스되지 않았다면, 먼저 하위 패키지를 빌드·배포한 뒤 상위 패키지를 릴리스해야 한다.

이때 의존 관계가 복잡한 대규모 프로젝트에서는 의존성 그래프를 적절히 관리하거나, 빌드 파이프라인에서 자동 검증(예: colcon graph 또는 종속성 검사 스크립트)을 수행하여 누락 사항을 확인하는 것이 중요하다.

Git Flow와 버전 태그

ROS2 패키지를 Git Flow(또는 유사한 브랜치 전략)로 운영할 경우, 릴리스 시점마다 태그를 생성하는 프로세스를 권장한다. 예를 들어, 다음과 같은 정책을 세울 수 있다.

• develop 브랜치: 새로운 기능 개발이 진행되는 브랜치

• release-humble 브랜치: Humble용 배포를 위한 안정화 브랜치

• 버전 태그: 릴리스 직전 커밋에 v1.2.3과 같이 부여

Bloom은 Git 태그를 기준으로 소스 코드를 참조하므로, 태그를 올바르게 부여하고 관리하는 것이 패키지 배포 프로세스의 핵심이다.

Windows 환경에서의 종속성 관리

ROS2 Humble은 리눅스(특히 Ubuntu) 환경을 우선 지원하지만, 윈도우(Windows) 환경에서도 기본적으로 동작할 수 있도록 공식 바이너리 패키지를 제공한다. 다만 윈도우 환경에서 ROS2 패키지를 빌드하거나 특정 라이브러리를 연동할 때는, 리눅스와 다른 종속성 설치/업데이트 방식을 주의 깊게 살펴봐야 한다.

1. Chocolatey, winget 등 패키지 매니저 활용

   • 윈도우 환경에서는 apt 대신, Chocolatey(choco)나 winget을 통해 개발 툴과 라이브러리를 설치할 수 있다.

   • 예를 들어, CMake, Visual Studio Build Tools 등을 자동화 스크립트에서 설치하려면 choco install cmake visualstudio2019buildtools -y와 같은 명령어를 사용할 수 있다.

2. Visual Studio 컴파일러 사용

   • ROS2 윈도우 빌드는 일반적으로 Visual Studio(예: VS2019, VS2022)로 진행된다.

   • C++ 컴파일러 버전에 따라 C++17 이상 표준 지원 여부 등이 달라질 수 있으므로, ROS2 Humble에서 요구하는 수준(대개 C++17)을 충족해야 한다.

   • colcon 빌드를 수행할 때, 명령 프롬프트를 Visual Studio용 Native Tools Command Prompt 환경으로 설정하거나, PowerShell 스크립트에서 컴파일러 환경 변수를 로드해야 한다.

3. Python 패키지 및 가상환경

   • ROS2의 일부 패키지(rclpy, rosidl_python 등)는 Python 3.8 이상(또는 해당 배포판에서 지정된 버전)을 요구한다.

   • pip install -U pip setuptools 등으로 파이썬 패키지 버전을 최신 상태로 관리하고, 필요하면 venv(가상환경)를 구성해 다른 프로젝트 간 충돌을 방지할 수 있다.

4. 윈도우용 DDS 구현체

   • 기본적으로 Fast-DDS, Cyclone DDS 등은 윈도우 환경에서도 동작하지만, 버전 호환성 문제가 있을 수 있으므로 공식 문서나 릴리스 노트를 확인해야 한다.

   • 소스 빌드 시에는 CMake를 통해 FindFastRTPS.cmake, FindCycloneDDS.cmake 등이 제대로 인식하는지 점검해야 한다.

5. rosdep 윈도우 지원

   • rosdep은 윈도우 환경에서도 동작하지만, 리눅스처럼 모든 종속성을 완벽하게 자동 설치해주지는 못할 수 있다.

   • 패키지 매니저와의 매핑(chocolatey: cmake, python 등)을 직접 설정해야 하거나, 일부 라이브러리는 수동으로 설치해야 할 수도 있다.

MacOS 환경에서의 종속성 관리

ROS2 Humble은 공식적으로 우분투, 윈도우를 주로 지원하며, 맥OS(MacOS)에 대해서는 실험적 지원(community support) 수준이다. 그럼에도 불구하고 다음과 같은 과정을 통해 빌드 및 실행이 가능하다.

1. Homebrew 설치

   • MacOS에서 패키지를 설치하기 위해 Homebrew를 많이 사용한다.

   • brew install cmake python colcon llvm 등의 명령으로 ROS2 빌드에 필요한 툴체인을 준비한다.

2. Xcode Command Line Tools

   • C++ 컴파일러를 사용하기 위해서는 Xcode Command Line Tools 설치가 필수다.

   • xcode-select --install 명령으로 쉽게 설치할 수 있으며, CMake가 내부적으로 clang을 인식하도록 환경 변수가 설정된다.

3. 나이틀리(Nightly) 빌드 확인

   • ROS2는 MacOS용 나이틀리 빌드를 제공할 때가 있으므로, 해당 바이너리를 활용할 수도 있다.

   • 그러나 커스텀 패키지나 최신 종속 라이브러리가 필요한 경우, 소스에서 빌드해야 할 수도 있다.

4. Python, pip, rosdep

   • 파이썬 패키지 종속성은 리눅스, 윈도우와 동일하게 pip, rosdep으로 관리할 수 있으나, 맥OS 대응 패키지 매핑이 완벽하지 않을 수 있다.

   • 이 경우, brew install <라이브러리명>으로 먼저 시스템 라이브러리를 설치해두고, rosdep에서 해당 라이브러리의 이름을 매핑하도록 설정한다.

GPU 및 하드웨어 종속성

ROS2 Humble에서 컴퓨터 비전, 딥러닝, SLAM 등 고성능 연산이 필요한 노드를 실행하려면, GPU(CUDA, OpenCL 등)에 대한 종속성을 고려해야 한다.

1. CUDA 버전 충돌

   • 엔비디아(NVIDIA) GPU를 사용하는 경우, CUDA 툴킷 버전과 드라이버 버전이 맞지 않으면 일부 ROS2 패키지(특히 딥러닝 라이브러리 연동)에서 문제가 발생한다.

   • CUDA 11.x, 12.x 간의 호환성 문제를 피하기 위해, 사용 중인 패키지(예: TensorRT, PyTorch, OpenCV-CUDA)에서 지원하는 정확한 버전을 확인해야 한다.

2. OpenCL, Vulkan 등 대체 연산 API

   • 특정 하드웨어에서 OpenCL, Vulkan 등을 사용하는 경우, ROS2 패키지 레벨에서 이를 지원하는지 확인하고, 해당 라이브러리를 설치해야 한다.

   • 하드웨어 가속을 적극적으로 활용하기 위해서는, 각 노드에서 제공하는 CMake 옵션(예: -DUSE_CUDA=ON) 등을 적절히 설정해야 한다.

3. 하드웨어별 전용 드라이버

   • NVIDIA Jetson, Intel Movidius, AMD GPU 등 다양한 하드웨어가 있는데, 각 하드웨어마다 종속성이 다르다.

   • 예를 들어 Jetson 계열은 Tegra 드라이버, TensorRT 등을 별도로 관리해야 하며, Intel 계열은 OpenVINO를 사용할 수 있다.

여러 ROS 배포판 동시 사용 시나리오

하나의 시스템에서 여러 ROS2 배포판(예: Humble, Iron, Rolling)을 동시에 사용해야 하는 경우, 상이한 버전의 패키지가 충돌하지 않도록 주의해야 한다.

1. 다중 설치 위치

   • /opt/ros/humble, /opt/ros/iron 등 서로 다른 디렉터리에 설치하고, 필요할 때만 해당 버전의 setup.bash를 소스한다.

   • colcon 워크스페이스를 따로 구성해서, 각 배포판 전용 패키지를 완전히 분리 관리한다.

2. Docker 컨테이너 분리

   • Docker를 사용한다면, 버전별로 서로 다른 이미지를 만들어 충돌을 원천 차단할 수 있다.

   • 예: ros:h humble-base, ros:i iron-base처럼 이미지 태그를 구분하고, 각 환경에서 빌드·테스트를 수행한다.

3. 패키지 간 호환성

   • 어떤 패키지는 Iron에서만 지원하는 기능이 있고, 어떤 패키지는 Humble에서만 호환되는 경우가 있다.

   • 이때 여러 버전의 ROS2를 단일 프로젝트에서 섞어서 사용하는 것은 위험하므로, 브리지 노드나 통신 프로토콜의 호환성 방안을 미리 고려해야 한다.

추가 수학적 관점: 동적 의존성 갱신

ROS2 패키지를 런타임 중 업데이트할 때, 그래프 구조 $\mathbf{D}$가 동적으로 변할 수도 있다. 예를 들어, 새 패키지를 추가하여 노드를 교체하는 시나리오가 발생할 수 있다. 이를 모델링하기 위해서는 시간축을 포함한 다음 형태로 확장할 수 있다.

$$\mathbf{D}(t) = \begin{cases} \mathbf{D}_0, & t < t_u \\ \mathbf{D}_1, & t \ge t_u \end{cases}$$

• $\mathbf{D}_0$: 업데이트 이전의 의존 관계 행렬

• $\mathbf{D}_1$: 업데이트 이후의 의존 관계 행렬

• $t_u$: 업데이트 시점

이 경우, 빌드 순서나 상호 의존성 분석도 시점 $t$에 따라 달라질 수 있으므로, $\mathbf{D}(t)$가 변할 때마다 위상 정렬을 재수행하거나, 런타임 상태 전이를 관리해줘야 한다.

SROS2와 보안 종속성

ROS2 Humble은 보안 기능을 기본적으로 고려하도록 설계되었으며, SROS2(Secure ROS2) 패키지를 통해 DDS 계층에서의 암호화, 인증, 접근 제어를 제공한다. 보안 관련 종속성을 관리하려면 다음 사항을 유의해야 한다.

1. DDS 보안 플러그인 의존성

   • DDS 구현체마다 보안을 위한 플러그인이 별도로 제공되거나, 외부 라이브러리에 의존한다.

   • 예를 들어 Fast-DDS Security, Cyclone DDS Security 등이 있으며, OpenSSL 등을 활용하는 경우도 있으므로 이를 미리 설치해야 한다.

2. SROS2 툴

   • sros2 패키지에 포함된 CLI 도구(sros2 keystore, sros2 policy 등)는 보안 아티팩트(키, 인증서, 정책 파일)를 생성하고 관리한다.

   • Python 종속성(cryptography 라이브러리 등)이 필요하므로, pip install cryptography 등의 과정을 거칠 수 있다.

3. 정책 파일과 작업공간 관리

   • ROS2 노드별로 권한(토픽 Publish/Subscribe, 서비스 호출/응답 등)을 정의하는 정책 파일을 작성해야 하며, 이는 YAML 또는 XML 형태로 표현된다.

   • 정책 파일 내 노드 이름, 토픽 이름 등이 실제 코드 및 launch 파일과 일관성을 유지하도록 버전 관리를 해야 한다.

4. 배포 및 운영 시나리오

   • 보안 아티팩트를 포함한 키스토어(keystore) 디렉터리는 운영 환경으로 배포해야 한다.

   • 이는 일반적으로 민감 정보이므로, Git과 같은 소스 저장소에서 제외하거나(예: .gitignore), 암호화된 형태로 저장하는 등 별도의 보안 프로세스를 마련해야 한다.

5. CI/CD와 SROS2

   • CI 단계에서 보안 노드를 테스트할 경우, 테스트용 인증서와 정책 파일(테스트용 keystore)이 필요하다.

   • 운영용 키스토어를 직접 사용하면 보안 문제가 발생할 수 있으므로, 테스트 전용 인증서를 생성해두고, 빌드/테스트 파이프라인에서만 사용하도록 격리한다.

보안 측면에서의 종속성 관리는 단순히 라이브러리 설치를 넘어, 정책 파일 버전, 키스토어 관리 등 전반적인 생명주기 관리가 포함된다. 따라서 다른 ROS2 종속성과 마찬가지로, 체계적인 버전 업데이트와 테스트가 필수적이다.

RMW(ROS Middleware) 교체 시 종속성 고려

ROS2는 DDS 구현체를 플러그인 형태(rmw 계층)로 교체할 수 있다. 대표적인 예로 Fast-DDS, Cyclone DDS, RTI Connext DDS, GurumDDS 등이 있으며, 이를 교체하려면 다음과 같은 사항을 고려해야 한다.

1. 라이선스 및 배포 방식

   • RTI Connext DDS나 GurumDDS 등 일부 DDS 구현체는 상업용 라이선스를 적용하거나, 특정 국가/지역에 배포 제한이 있을 수 있다.

   • 프로젝트 및 조직 요구사항(비영리, 상업 프로젝트 등)에 따라 적합한 RMW를 선택해야 한다.

2. Colcon 빌드 옵션

   • --packages-up-to rmw_fastrtps_cpp, --packages-up-to rmw_cyclonedds_cpp처럼 원하는 RMW 패키지를 빌드할 수 있다.

   • 소스 레벨에서 DDS 구현체를 교체하려면, rmw_*.xml 파일 혹은 CMakeLists.txt의 find_package(rmw_* REQUIRED) 부분을 수정해야 할 수 있다.

3. 퍼포먼스 및 QoS

   • DDS 구현체마다 QoS 설정(신뢰성, 내구성 등)의 기본값이나 구현 세부사항이 다를 수 있다.

   • 성능 벤치마크, 메시지 손실률 등을 사전에 측정하고, 교체 후에도 같은 QoS 프로파일이 적용되는지 확인한다.

4. 버그 및 호환성 이슈

   • 새 DDS 구현체에 존재하는 알려진 버그나, 특정 OS/하드웨어 환경에서 호환성 문제(예: 윈도우에서만 발생하는 이슈)가 있을 수 있다.

   • ROS2 이슈 트래커나 DDS 벤더의 릴리스 노트를 읽고, 프로젝트 환경에 영향을 미치는 이슈가 있는지 확인해야 한다.

5. 업데이트 정책

   • DDS 구현체도 주기적으로 릴리스되거나 패치가 나오므로, ROS2 Humble의 릴리스 노트를 참고해 어떤 버전을 사용하는 것이 권장되는지 확인한다.

   • OS 레벨에서 apt를 통해 설치하는 경우, ROS 패키지 레포지토리에 올라온 버전만 사용할 수 있지만, 소스 빌드라면 직접 원하는 버전을 선택할 수도 있다.

이처럼 RMW를 교체하면 프로젝트 의존성이 상당 부분 달라질 수 있으며, 종속성 충돌이나 성능 저하를 초래할 수 있으므로 사전 테스트와 계획이 필수적이다.

대규모 프로젝트에서의 모듈화

ROS2 Humble을 기반으로 수십~수백 개 이상의 노드(패키지)를 운영하는 대규모 프로젝트에서는, 모듈화(Modularization)와 계층화된 의존성 관리가 요구된다.

1. 핵심 코어 패키지

   • 메시지 정의, 로봇 하드웨어 인터페이스, 공용 라이브러리 등 다른 모든 패키지가 공통적으로 참조하는 '코어'를 분리한다.

   • 코어에 대한 버전 업데이트는 신중하게 진행하며, 사전에 모든 의존 패키지에 대한 호환성 테스트를 수행한다.

2. 기능별 서브 패키지

   • 예: 탐색(navigation), SLAM, 센서 드라이버, UI 등 기능별로 독립적인 패키지 그룹을 운영하고, 상호 간 의존성을 최소화한다.

   • colcon 빌드 시 특정 패키지만 선택적으로 업데이트할 수 있도록, src 디렉터리를 세분화한다(예: src/navigation, src/sensors 등).

3. 버전 태그 및 릴리스 규칙

   • 모놀리식 구조를 지양하고, 각 기능 패키지에 별도의 버전 번호를 부여하거나, Git 서브모듈/서브트리 등을 사용해 분리된 저장소로 관리한다.

   • 대규모 팀 협업 시, 패키지 별로 릴리스 규칙(세멘틱 버전, 테스트 프로세스)을 표준화한다.

4. 역방향 종속성 회피

   • 상위 레벨 패키지가 하위 레벨 패키지를 참조하는 것은 일반적이지만, 반대로 하위 레벨에서 상위 레벨 기능을 호출하면 의존 그래프가 복잡해진다(순환 의존성).

   • 이를 회피하기 위해, 공통 인터페이스나 메시지를 별도 패키지에 정의하고, 양방향 의존을 줄이는 구조를 권장한다.

이러한 모듈화 전략은 버전 업데이트 시 영향을 정확히 파악하고, 충돌을 빠르게 해결할 수 있는 체계를 갖추게 해준다.

외부(3rd-Party) 라이브러리 버전 동기화

ROS2 패키지에서는 OpenCV, PCL(Point Cloud Library), Eigen, Boost, YAML-cpp 등 다양한 서드파티 라이브러리를 활용한다. 이때 다음과 같은 요소를 점검해야 한다.

1. ABI 호환성

   • 일부 C++ 라이브러리는 ABI(Application Binary Interface)가 달라지면 동적 라이브러리(.so, .dll) 로딩 시 충돌이 발생할 수 있다.

   • 예: Ubuntu 22.04의 시스템 라이브러리가 제공하는 OpenCV 버전과, 별도로 빌드한 OpenCV 버전이 충돌할 수 있다.

2. CMake 옵션 상충

   • OpenCV를 예로 들면, WITH_QT, WITH_CUDA, WITH_TBB 등 다양한 빌드 옵션이 존재하는데, 이를 다른 패키지와 일관되게 설정하지 않으면 런타임 충돌이 발생할 수 있다.

   • 대규모 프로젝트에서 공통 CMake 옵션을 정의하고, 각 패키지가 이를 참조하도록 구성하는 방식을 사용할 수 있다.

3. ROS2 vs 일반 CMake 프로젝트 간 차이

   • ROS2 패키지는 ament_cmake를 사용하지만, 서드파티 라이브러리는 일반 CMake 기반일 수 있다.

   • FindPackage()를 통해 라이브러리를 찾을 때, ROS2가 제공하는 매크로와 충돌이 나지 않도록 주의한다(예: ament_cmake 대신 pure CMake find_package(OpenCV REQUIRED)를 사용할 때 버전이 달라지는 사례).

4. 패치 버전 관리

   • 서드파티 라이브러리에 버그가 있어, 직접 패치가 필요한 경우도 있을 수 있다.

   • 이 경우, 패치 버전이나 포크(fork)를 별도로 운영하면서, ROS2 빌드시 해당 버전이 적용되도록 CMakeLists.txt를 수정한다.

사용자 정의 메시지와 Action, Service 버전 관리

ROS2 패키지를 개발하는 과정에서, 고유의 메시지(.msg), 서비스(.srv), 액션(.action) 인터페이스를 정의하게 된다. 이를 버전 업데이트할 때 아래 사항을 유념한다.

1. 메시지 필드 추가/삭제

   • 메시지 파일에 필드를 새로 추가하는 것은 하위 호환성이 유지될 수 있으나, 필드 제거나 필드 타입 변경은 상위 호환성을 깨뜨린다.

   • 기존 노드들이 새 메시지를 올바르게 파싱하지 못할 수 있으므로, API 변경점을 정확히 문서화하고 MAJOR 버전을 올리는 세멘틱 버전 규칙을 따른다.

2. Action, Service 변경 시나리오

   • 액션(.action)이나 서비스(.srv)의 요청/응답 구조가 바뀌면, 클라이언트-서버 간 통신이 불가해질 수 있다.

   • 호환 노드를 함께 배포하거나, 일정 기간동안 구버전-신버전 노드를 동시에 구동시키며 점진적으로 전환해야 한다.

3. rosidl_generator, rosidl_py 등 빌드

   • 메시지나 서비스 정의가 바뀌면, ROS2의 인터페이스 빌드 시스템(rosidl_generator_cpp, rosidl_generator_py 등)이 새 코드를 자동 생성한다.

   • 소스 빌드 환경에서 의존 관계를 명확히 하여, 메시지를 먼저 빌드한 뒤 해당 메시지를 사용하는 패키지를 빌드하도록 순서를 맞춘다.

4. 가상화 및 시뮬레이터 테스트

   • 메시지 구조 변경이 로봇 하드웨어에 직접 영향을 줄 경우, 실제 로봇에 배포하기 전에 시뮬레이터나 Docker 기반 가상 환경에서 충분히 테스트한다.

   • 네트워크 프로토콜 레벨에서 변경 사항이 있는지, QoS 설정이 변경되어야 하는지 등을 종합적으로 확인한다.

위와 같은 측면에서 메시지, 서비스, 액션의 정의가 바뀌면 전체 시스템 종속성에도 변동이 생기므로, 버전 업데이트 계획에 포함시켜야 한다.