# ROS2 Humble 개요

#### 버전 명명 규칙과 주요 목적

ROS2의 각 버전은 알파벳 순서를 따라, 독특한 동물 이름에 특정 형용사를 덧붙이는 방식으로 명명된다. 예를 들어 **Humble Hawksbill**과 같은 식으로, 버전에 해당하는 알파벳(H)을 시작 글자로 하여, 그에 어울리는 동물(Hawksbill)을 선택하는 식이다. 이렇게 만들어진 전체 이름에는 재미와 특징을 더함과 동시에, 버전별 구분을 명확히 할 수 있는 장점이 있다.

이와 같은 버전 명명 방식을 활용하면 아래와 같은 이점이 있다.

* **배포판 식별 용이**: 유사한 시기에 등장하는 다양한 배포판들을 이름만 보고도 직관적으로 구분 가능
* **명명 규칙 일관성**: 영어 알파벳을 순서대로 사용함으로써 버전 차이를 쉽게 확인
* **개발 문화 형성**: 다소 유머러스하거나 친근한 동물명을 붙임으로써 개발자 커뮤니티에서 기억하기 편리

**ROS2 Humble**에 해당하는 **Humble Hawksbill** 역시 앞 글자 **H**에 맞춰 정해진 이름이며, 내부적으로는 기능 안정화와 장기 지원을 고려한 여러 사항이 반영되어 있다.

#### LTS 지원과 정기 릴리스

ROS2는 특정 버전을 LTS(Long Term Support)로 지정하여 장기간 유지보수한다. LTS가 아닌 버전은 상대적으로 짧은 기간 동안 지원되며, 이후 LTS 버전으로 점차 합쳐지는 구조로 운영된다. 일반적으로 ROS2 배포판은 1년에 한 번 정도 정기적으로 공개되며, 그중 일부 버전이 LTS로 채택되면 대략 5년 정도의 지원 기간을 가진다.

LTS 버전으로 선정된 배포판은 중요 보안 패치와 기능 개선 업데이트가 정기적으로 제공되기 때문에, 산업 현장이나 대규모 프로젝트에서 안정적인 플랫폼을 구축하기에 용이하다.

#### 릴리스 주기의 배경

ROS2의 릴리스 주기는 새 기능과 개선 사항을 신속하게 도입하면서도, 사용자들이 장기 지원을 통해 안정적인 환경을 유지할 수 있도록 고안되었다. 이는 학계와 산업계가 동시에 활용할 수 있는 생태계를 구축하기 위한 전략이며, 다음과 같은 고려 사항이 있다.

* 신기능 도입과 호환성 유지 사이의 균형
* 오픈소스 커뮤니티의 광범위한 참여
* 개발 인프라(빌드, 테스트, 통합) 체계화

이를 시각적으로 나타내면 아래와 같은 대략적인 타임라인으로 정리할 수 있다.

{% @mermaid/diagram content="timeline
title "ROS2 릴리스 주기"
dateFormat YYYY-MM
2017-12 : Ardent Apalone
2018-06 : Bouncy Bolson
2019-06 : Dashing Diademata (LTS)
2020-06 : Foxy Fitzroy (LTS)
2021-05 : Galactic Geochelone
2022-05 : Humble Hawksbill (LTS)
2023-05 : Iron Irwini" %}

#### 릴리스 주기의 장점

ROS2는 앞서 언급했듯 1년에 한 번 정도 새로운 버전을 발표하여 사용자들이 최신 기능을 빠르게 활용할 수 있게 해준다. 이 방식은 다음과 같은 장점을 가진다.

* **계속적인 개선 및 피드백 반영** 새 릴리스 때마다 커뮤니티에서 제기된 문제점이나 추가 요구 사항을 빠르게 제품에 반영할 수 있다. 이는 사용자 경험 개선과 함께 프로젝트 성숙도 향상에 직접적인 영향을 미친다.
* **누적 호환성 보장** 라이브러리, 빌드 도구, 주요 ROS 패키지 등 다양한 구성 요소가 동시에 업그레이드되지만, 하위 호환성을 최대한 유지하려는 노력이 병행된다. 이를 통해 기존 코드를 새 버전에서도 큰 수정 없이 사용할 수 있도록 돕는다.
* **다양한 협업 환경 조성** 학계, 산업계, 개인 개발자 등 다양한 주체가 참여하는 오픈소스 특성상, 특정 기능이 필요하면 그에 맞춰 플러그인을 제작하거나 ROS2 내부 모듈을 확장하기 쉽다. 릴리스 주기가 비교적 짧은 편이기 때문에 협업 속도도 빨라진다.

#### 버전별 특징적 변화

각 ROS2 배포판마다 목표하는 스펙이나 적용 범위가 조금씩 달라진다. 예컨대 일부 버전에서는 통신 성능 최적화에 초점을 두고, 다른 버전에서는 GUI 툴킷 지원에 집중할 수 있다. 이러한 방향성은 새로운 배포판이 등장할 때마다 공식 문서와 로드맵을 통해 발표되며, 대표적인 변화 포인트는 다음과 같다.

* **미들웨어 계층 개선** DDS(Datat Distribution Service) 등 통신 계층별 최적화 패치 적용
* **빌드 시스템 업데이트** CMake나 Python 관련 버전 호환성 개선, 크로스 컴파일 지원 확대
* **새로운 로보틱스 기능 추가** ROS2 Navigation, MoveIt 2, TF2 등 주요 패키지의 기능성 향상

**Humble Hawksbill** 버전은 LTS로 지정된 만큼, 기존 **Foxy Fitzroy** 이후 등장한 새로운 기능을 통합하면서도 장기간 유지보수를 염두에 두어 안정성을 크게 강화한 것이 특징이다.

#### LTS 관리 방식

ROS2 LTS 버전은 몇 년 단위로 장기 지원을 받게 되며, 이 기간 동안 다음과 같은 사항이 이루어진다.

* **보안 패치 제공** 시스템 취약점 및 의존 라이브러리의 보안 결함이 발견될 경우, 즉각적으로 패치가 적용된다.
* **주요 버그 수정** ROS 핵심 패키지에서 치명적인 버그가 발생하면 해당 부분을 수정하여 배포한다.
* **기능 유지** 새로운 기능이 대규모로 추가되지는 않지만, 이미 포함된 기능들이 장기간 안정적으로 동작하도록 관리된다.

일반적으로 ROS2 LTS 버전은 5년 가까이 유지되는 편이며, 이 기간 중 새로 등장하는 ROS2 버전들과 중복되는 지원 기간(약 1\~2년)을 통해 사용자가 무리 없이 마이그레이션할 수 있도록 돕는다.

#### LTS 버전과 Rolling Release의 공존

ROS2 생태계에는 LTS 버전과 더불어 **Rolling Release**라고 불리는 상시 개발 버전이 동시에 존재한다. Rolling Release는 최신 기능의 실험적 도입과 빠른 수정이 이루어지는 공간이다. 반면, LTS 버전은 해당 기간 동안 안정성과 신뢰도가 우선시되며, Rolling Release의 기능 중 안정성이 검증된 것들이 필요에 따라 포트(Port)되거나 업데이트된다.

이 구조는 사용자 그룹에 따라 선택할 수 있는 여지를 제공한다. 예를 들어, 연구 프로젝트에서 Cutting Edge 기능을 시험하려면 Rolling Release가 유리하고, 장기 산업 프로덕션 환경에서는 LTS 버전이 적합하다는 식이다.

#### ROS2 버전명에 담긴 특징

ROS2 버전명은 알파벳 순서에 따른 형용사와 동물 이름의 조합으로 이루어지는데, 이를 통해 버전 식별을 직관적으로 지원하는 동시에, 각 버전마다 독특한 이미지와 상징을 부여한다. 이 중 동물 이름은 주로 거북을 포함한 파충류로 선정되는 경향이 있다.

* **거북을 모티브로 한 이유** ROS(ROS1 포함) 초기부터 거북(turtle)을 마스코트로 활용해 왔으며, 이는 실험용 시뮬레이션 및 예제 코드(turtlesim 등)에 자주 등장했다.
* **Humble Hawksbill에서 “Hawksbill”** Hawksbill은 바다거북 중 하나로, 부리가 독수리의 부리를 닮은 것이 특징이며, 멸종 위기종으로 잘 알려져 있다. **Humble** 이라는 형용사와 함께 사용되어, ROS2 ‘H’ 버전의 이름으로 채택되었다.

이렇듯 버전명은 사람들에게 쉽게 각인되고, 오픈소스 커뮤니티에 활기를 더하는 데 기여한다.

#### 버전 업그레이드와 지원 종료 시점

ROS2는 규칙적으로 새 버전을 발표하면서, 동시에 일정 기간이 지나면 기존 버전에 대한 지원을 단계적으로 종료한다(EOL, End Of Life). 이는 불필요하게 많은 버전이 동시에 유지되지 않도록 함과 동시에, 시스템이 최신 기능과 패치를 수용하도록 유도하는 정책이다.

* **EOL 시점 도래** LTS가 아닌 일반 버전은 상대적으로 짧은 기간 안에 EOL이 도래한다(약 1\~2년).
* **LTS 버전의 연장 지원** LTS는 5년 가까운 지원 기간 중 주기적인 유지 보수와 보안 패치가 적용된다.

아래와 같은 예시로 LTS와 일반 버전의 EOL 시점을 도식화할 수 있다.

{% @mermaid/diagram content="gantt
title "ROS2 버전 및 EOL"
dateFormat YYYY-MM-DD
section LTS Versions
Foxy (LTS)         :active, foxy, 2020-06-05, 2023-05-23
Humble (LTS)       :active, humble, 2022-05-23, 2027-05-23

```
section Regular Versions
Galactic           :done, galactic, 2021-05-23, 2022-11-23
Iron               :active, iron, 2023-05-23, 2024-11-23" %}
```

#### Ubuntu 및 기타 OS와의 릴리스 동기

ROS2는 주로 우분투(특히 LTS) 버전을 기반으로 패키징되며, 그 외에도 Windows, macOS, RHEL(CentOS), Yocto 기반의 임베디드 리눅스 등 여러 운영체제를 지원한다. 그러나 배포 타이밍은 우분투 LTS와 연동되는 경향이 강하다. 실제로 ROS2의 LTS 버전은 대체로 우분투 LTS가 발표된 후 얼마 지나지 않아 출시되는데, 이는 아래와 같은 이유가 있다.

* **의존 관계 단순화** ROS2 빌드 및 실행 시, 대부분의 종속 라이브러리가 우분투 리포지토리에 존재한다. 우분투 LTS 버전이 바뀌면 빌드 도구, C++ 런타임 라이브러리 등도 변경될 수 있어, 이를 반영한 새로운 ROS2 배포판이 필요하다.
* **장기 지원 간소화** 우분투 LTS 역시 5년간 지원되므로, ROS2 LTS와 비슷한 주기로 오래 사용 가능한 환경을 제공한다. 이로써 대규모 프로젝트에서 OS와 ROS2를 동시에 장기간 유지보수하기 편리해진다.
* **커뮤니티 협력 극대화** 우분투 LTS 채택 인구가 많아, ROS 개발자들도 해당 OS를 활용하는 경우가 대부분이다. 결과적으로 Ubuntu 기반에서의 오류 보고 및 패치가 빠르게 이루어져 릴리스 주기와 품질 유지에 도움이 된다.

#### 패키징과 배포 채널

ROS2는 소스 빌드뿐 아니라, 패키지 매니저(apt, yum 등)를 통한 설치, Docker 이미지를 통한 컨테이너 방식 실행 등 다양한 배포 채널을 마련하고 있다. 이때 버전 릴리스 주기와 맞춰 최신 패키지들이 순차적으로 업데이트되는 구조다.

* **apt 저장소** 우분투 시스템에서 패키지 리스트를 업데이트하면, LTS 혹은 최신 ROS2 버전 패키지들이 apt로 제공된다.
* **Docker Hub** ROS2 공식 Docker 이미지가 버전별 태그로 올라온다. LTS 버전 이미지는 ‘ros:humble’처럼 명시되어 쉽게 식별된다.
* **소스 빌드** 소규모 임베디드 장치나 특정 의존 관계를 가진 환경에서는 소스로부터 직접 빌드하여 원하는 기능만 축소 또는 확장해 사용할 수 있다.

#### 안정성과 지속 가능성

ROS2는 오픈소스 프로젝트인 만큼, 다수의 기업과 연구기관이 함께 참여하여 유지보수를 진행한다. 각 버전 릴리스 시점마다, 높은 수준의 테스트 자동화(CI/CD)와 검증 절차가 병행된다. 이를 통해 자주 발생하는 소프트웨어 회귀(Regression)나 의존 라이브러리 충돌이 최소화되며, 릴리스 주기가 비교적 짧음에도 전체적인 안정성을 유지한다.

또한, 릴리스 직후 커뮤니티의 피드백이 광범위하게 수용되어 마이너 버전 또는 패치 버전으로 이어진다. 이때 LTS 버전은 크고 작은 버그를 꾸준히 수정하되, 하위 호환성을 깰 수 있는 변화는 자제하는 방식으로 운영된다.

#### 문서화와 커뮤니티

ROS2는 개발 문서, 튜토리얼, API 문서 등이 공식 웹사이트와 저장소(<https://github.com/ros2)에> 정리되어 있다. 버전별로 문서가 별도 관리되어, 사용자는 특정 버전(LTS 포함) 관련 자료만 집중적으로 학습할 수 있다.

* **문서 버전 분리** Humble 문서와 Iron 문서가 별도 분기로 나뉘어, 서로 다른 기능 세트를 참고할 수 있다.
* **토론 및 이슈 트래킹** [answers.ros.org](https://answers.ros.org)를 통해 버전별 사용 질문과 답변이 공유되며, 깃허브 이슈로 버그 및 기능 요청이 추적된다.
* **ROS Discourse** 공식 포럼을 통해 릴리스 계획, 회의록, 설문조사 등 다양한 정보가 공개되고, 개발자 간 협업이 이루어진다.

#### 알파·베타 단계 및 QA 절차

ROS2는 새 버전을 공개하기 전, 알파(Alpha)와 베타(Beta), 그리고 RC(Release Candidate) 단계를 거친다. 이 과정을 통해 많은 사용자와 개발자가 사전에 테스트를 진행하고, 구조적 결함이나 치명적 버그를 빠르게 식별하여 수정한다. 주요 특징은 다음과 같다.

* **알파 버전(Alpha)** 내부적으로 큰 변경사항이 있거나, 새 기능이 본격적으로 통합될 때 배포되는 가장 초기 단계다. 패키지 의존 관계나 API가 빈번히 바뀔 수 있어, 실험적 사용만 권장된다.
* **베타 버전(Beta)** 기능과 API가 어느 정도 안정화되어, 실제 사용자가 시범 적용할 수 있는 수준이 된다. 커뮤니티에서는 이 시점에 대규모 피드백이 몰리며, 버전 명명 규칙과 일부 문서 역시 구체화가 이루어진다.
* **릴리스 후보(RC, Release Candidate)** 베타 버전을 거쳐 결정된 사양과 기능이 최종 점검되는 단계다. API 변경이 최소화되며, 배포 직전의 테스트 인프라(CI/CD)를 풀가동하여 안정성을 검증한다.

이 일련의 과정을 통해 목표한 릴리스 주기에 맞춰 버전이 공식 발표된다. 다수의 기업과 연구실에서 동시에 테스트하기 때문에, 다양한 환경에서 발생할 수 있는 문제를 사전에 파악할 수 있다는 장점이 있다.

#### 버전 동결(Freeze)과 패키지 호환성

ROS2는 정식 버전 발표 직전, 기능 동결(Feature Freeze) 단계에 돌입한다. 이 시기에는 새로운 기능 추가나 큰 구조 변경을 금지하고, 기존 기능의 안정성과 호환성 점검에만 집중한다. 이 방침은 다음과 같은 목적을 가진다.

* **기능 범위 확정** 최종 패키지에 포함될 기능들을 확정 짓고, 충분히 테스트하여 예측 불가능한 리스크를 줄인다.
* **패키지 간 호환성 보장** 여러 ROS 패키지들이 동일한 로직으로 정상 동작하는지 최종 점검하여, 빌드 실패나 런타임 충돌을 방지한다.
* **커뮤니티 홍보 및 준비** 개발자와 사용자들이 정식 버전 공개에 대비해, 예제 코드 및 문서를 미리 업데이트할 수 있도록 돕는다.

#### 시간 기반 vs. 기능 기반 릴리스

ROS2는 일반적으로 ‘시간 기반(Time-based)’ 릴리스 방식을 취한다. 이는 특정 기능 개발이 100% 완료되지 않더라도, 예정된 시점에 맞춰 현재까지 구현된 범위를 정리하여 버전을 발표하는 구조다. 반면, 기능 기반(Feature-based) 릴리스는 목표 기능이 완벽히 구현될 때까지 릴리스를 지연하는 방식을 의미한다.

시간 기반 릴리스를 채택하는 이유는 다음과 같다.

1. **예측 가능성** 프로젝트 참여자가 많아질수록, 배포 시점이 예측 가능해야 커뮤니티 운영과 개발 자원 할당이 수월해진다.
2. **지속적인 개선 사이클** 빠른 주기로 릴리스가 반복됨에 따라, 미완성 기능은 다음 버전에 포함시키는 식으로 유연하게 대처할 수 있다.
3. **기술 부채(Technical debt) 최소화** 과도하게 누적된 작업을 일시에 릴리스하려면 위험이 크지만, 시간 주기에 맞춰 분할 릴리스하면 리스크가 분산된다.

결과적으로, ROS2는 매년 1회 정기 릴리스로 새 버전을 공개하며, 그중 일부를 LTS로 지정하여 장기간 보완해 나가는 전략을 취한다.

#### ROS2 릴리스와 보안 고려

릴리스 주기와 더불어, 보안 이슈 역시 ROS2 운영에서 매우 중요한 요소다. 산업 분야에서 로봇 시스템의 안전성은 필수적이기 때문에, 다음과 같은 활동이 진행된다.

* **Security Working Group** ROS2 커뮤니티 내 보안 전문가들이 모여 DDS 미들웨어에서 발생할 수 있는 취약점, 패키지 간 권한 관리를 점검한다.
* **보안 패치 긴급 반영** 발견된 취약점은 LTS는 물론, 아직 EOL이 아닌 일반 버전에도 즉시 패치가 반영된다.
* **DevOps 파이프라인 상 보안 검사** CI/CD 단계에서 정적 분석(Static Analysis)나 취약성 스캐닝(Vulnerability Scanning)이 자동화되어, 악의적 코드 삽입 등을 방지한다.

이러한 보안 관점은 단발적인 프로세스가 아니라, 버전 명명 규칙과 릴리스 주기 전반에 상시 연결되어 있다. 즉, 새로운 버전에서 단순 기능 추가뿐 아니라, 기존 보안 모듈을 재점검하는 일도 필수 절차로 자리 잡았다.

#### Technical Steering Committee(TSC)와 릴리스 계획

ROS2 전체 로드맵과 릴리스 주기에 대한 주요 결정은 TSC(Technical Steering Committee)를 통해 이뤄진다. TSC는 주요 기업, 연구기관, 오픈소스 커뮤니티 리더 등 다양한 이해관계자가 참여하며, 다음과 같은 역할을 수행한다.

* **우선순위 조정** ROS2 코어 패키지 및 주요 기능 모듈의 개발 우선순위를 조정하여, 어느 부분에 더 집중적으로 리소스를 투자할지 결정한다.
* **릴리스 일정 검토** 시간 기반 릴리스로 진행되는 만큼, 현재 진행 상황(기능 통합률, 테스트 진행도 등)에 따라 알파·베타·RC 등 사전 공개 일정을 논의한다.
* **호환성 정책 수립** 기존 ROS2 버전(특히 LTS)과의 호환성 수준을 설정하고, 새 버전 출시 후 마이그레이션 전략 등을 정의한다.

TSC에서 결정된 사항들은 공개 회의록이나 ROS Discourse 등을 통해 커뮤니티에 투명하게 공유되며, 누구든지 피드백을 제안할 수 있다.

#### REP 2000과 버전 수명 주기 표준화

ROS의 디자인 제안서 중 하나인 REP(ROS Enhancement Proposal) 시리즈에는 배포판의 버전명과 수명 주기에 대한 표준이 명시되어 있다.

* **REP 2000** ROS 배포판(ROS1, ROS2)에 적용되는 릴리스 방식, 버전 명명 규칙, LTS 지정 기준 등을 정의한 문서다.
* **LTS와 일반 버전의 수명 표준** REP 2000을 기반으로, LTS 버전은 대략 5년, 일반 버전은 1년\~2년간 지원한다는 원칙이 유지된다.

이 문서에 따라 **Humble Hawksbill** 역시 LTS 배포판으로 분류되며, 공식적으로 일정 기간(약 5년)의 지원이 보장된다.

#### 마이너 릴리스와 패치 버전

ROS2는 주 버전(예: Humble) 이외에도 마이너(소수점 단위) 또는 패치(소수점 이하) 릴리스가 수시로 이뤄진다. 예컨대 `Humble x.y.z` 형태로 버전이 구분되며, 아래와 같은 상황에 따라 업데이트된다.

* **핫픽스(Hotfix)** 긴급 보안 취약점이나 크리티컬 버그 수정이 필요한 경우, 빠른 속도로 패치 버전을 발표한다.
* **기능 보완** 이미 확정된 기능에서 자잘한 개선 사항(성능 최적화, UI 개선 등)을 반영해, 사용자 편의를 높인다.
* **커뮤니티 피드백 반영** 특정 기능에서 발생하는 이슈나 제안이 모이면, 마이너 릴리스로 업데이트하여 빠르게 적용한다.

이러한 소규모 단위 릴리스도 REP 2000의 전반적 지침을 따르며, LTS 버전은 비교적 안정성에 초점을 둔 수정 위주로 진행된다.

#### 버전 갱신과 유지보수의 연속성

ROS2 Humble 같은 LTS 배포판의 등장은 이전 LTS(Foxy)와의 호환성, 그리고 차기 LTS로의 자연스러운 전환이 이어지도록 설계되어 있다. 다음과 같은 구조 덕분에, 사용자들은 버전 전환 시 큰 부담 없이 마이그레이션할 수 있다.

* **오버랩 기간(Overlap period)** 이전 LTS가 공식 지원을 받는 동안, 새 LTS가 출시되어 둘이 겹치는 기간이 발생한다. 이 시기에 사용자는 프로젝트 요구 사항에 따라 적절한 시점에 업그레이드를 진행할 수 있다.
* **패키지 리포지토리 다중 지원** 기존 LTS 패키지와 새 LTS 패키지 모두가 apt 등으로 동시에 배포되므로, 환경 테스트나 부품 교체가 유연하다.
* **문서·튜토리얼 동시 유지** ROS2 공식 문서는 버전별로 별도 브랜치로 운영되므로, 업그레이드 시 주의점이 명확히 정리되어 있다.

결국 이러한 릴리스 주기 전략으로, ROS2는 빠른 기능 향상과 장기 안정성을 모두 만족시키는 균형점을 추구하게 된다.