ROS 2 Iron이냐 Humble이냐: 로봇 프로젝트 배포판을 EOL까지 남은 개월 수로 고르기

Read in English

Ubuntu 22.04를 새로 깔고 첫 로봇 프로젝트에 ROS 2를 올리려고 검색하면, 2023년 11월 Robotics Stack Exchange에 올라온 “Which ROS2 Distro? Iron or Humble?”이 앞쪽에 나온다. 채택된 답의 요지는 Humble이 LTS라서 더 나을 수 있다는 것이었고, 그때는 맞는 판단이었다. 2026년 10월에는 질문의 전제부터 성립하지 않는다. 공식 Releases 표에서 Iron은 2024년 12월 4일에 지원이 끝났고, Humble도 2027년 5월 종료까지 7개월이 남았을 뿐이다. ROS 2 Iron이냐 Humble이냐를 고르던 자리에는 이제 “지원 종료까지 남은 개월 수가 내 프로젝트 기간보다 긴가”라는 뺄셈 하나가 들어간다.

이 뺄셈은 공식 표의 연·월만 있으면 누구나 할 수 있고, 결과는 어느 Ubuntu를 설치할지와 로봇·노트북을 어떻게 맞출지로 곧장 이어진다. Ubuntu에서 apt로 패키지를 설치해 본 경험과 두 날짜 사이의 개월 수를 세는 산수면 따라올 수 있다. 계산은 파이썬 예제로 검산했고, 공식 ros:jazzy-ros-base 컨테이너에서 5회 다시 돌려 미리 적어 둔 예측과 맞춰 봤더니 예측한 항목은 모두 그대로 나왔다. 둘 다 날짜 산수와 설치된 소프트웨어를 확인한 것이고, 로봇이나 시뮬레이터를 움직인 결과는 아니다.

배포판은 버전을 고정한 묶음이고, EOL은 그 묶음의 손질이 멈추는 날이다

ROS 2의 배포판(distribution, 줄여서 distro)은 버전을 서로 맞춰 고정한 ROS 패키지 묶음이다. Ubuntu 22.04나 24.04처럼 이름 붙은 한 세트라고 보면 된다. Humble, Jazzy가 그 이름이고, 한 번 나온 배포판의 핵심 패키지는 버그 수정과 호환성을 깨지 않는 개선 위주로만 바뀐다(Releases 문서의 배포판 정의). 그래서 배포판은 프로젝트를 시작하기 전에 한 번 고르고 오래 쓰는 대상이 된다.

지원 종료(End-of-Life, EOL)는 그날 이후 공식 유지보수가 끝나는 시점이다. 공식 문서는 EOL 목록으로 옮긴 배포판을 “no longer supported”라고 적는다. 우유 유통기한에 빗대면 남은 기간이 내가 다 마실 기간보다 길어야 한다는 감각과 비슷하다. 비유가 맞는 건 거기까지다. EOL 다음 날 로봇이 멈추는 것이 아니라 버그·보안 수정과 패키지 배포 같은 공식 유지보수가 끝나는 것이고, EOL 이후 저장소와 패키지가 실제로 어떻게 동작하는지는 이 글에서 확인하지 않았다.

배포판에는 두 종류가 있다. 장기 지원(Long Term Support, LTS) 배포판은 짝수 해에 나와 약 5년 지원되고, 일반 배포판(regular release, 흔히 비LTS)은 홀수 해에 나와 1.5년 지원된다. 2026년 10월 4일에 확인한 공식 Releases 표와 배포판별 페이지의 값은 다음과 같다. 마지막 열은 각 배포판이 Tier 1 플랫폼으로 지정한 Ubuntu이며, Tier가 무엇인지는 뒤에서 다룬다.

배포판	출시	EOL	유형	Tier 1 Ubuntu
Humble Hawksbill	2022-05-23	2027년 5월	LTS	22.04 Jammy
Iron Irwini	2023-05-23	2024-12-04, 종료됨	비LTS	22.04 Jammy
Jazzy Jalisco	2024-05-23	2029년 5월	LTS	24.04 Noble
Kilted Kaiju	2025-05-23	2026년 12월	비LTS	24.04 Noble
Lyrical Luth	2026-05-22	2031년 5월	LTS	26.04 Resolute
Makoa Mata-mata(예정)	2027년 5월 예정	2028년 12월 예정	regular release	공식 페이지에 아직 미정

EOL은 이미 끝난 Iron만 날짜까지 적혀 있고 나머지는 월까지만 나온다. 이 차이가 뒤의 계산에서 오차의 크기를 정한다. 표에 없는 Rolling은 EOL이 없는 개발용 배포판인데, 깨지는 변경이 그대로 들어올 수 있어 공식 문서는 대부분의 사용자에게 Rolling 대신 가장 최근 안정 배포판을 쓰라고 권한다(Releases L238-L239). 이 글은 EOL이 있는 안정 배포판만 계산한다.

남은 개월에서 프로젝트 기간을 빼면 판정이 나온다

계산식은 두 줄이다. 단위는 정수 개월이다.

개월 수 = (EOL 연도 − 기준 연도) × 12 + (EOL 월 − 기준 월)
여유    = 남은 개월 − 프로젝트 기간

기준 연·월에 출시 월을 넣으면 지원 기간이, 이번 달을 넣으면 남은 개월이 나온다. 여유가 0 이상이면 프로젝트가 끝나기 전에 지원이 끝나지 않고, 음수면 프로젝트 도중에 EOL을 맞는다.

숫자를 따라가기 위해 2026년 10월에 18개월짜리 프로젝트를 시작한다고 가정해 보자. 실제 사례가 없는 설명용 가정이다. Humble은 (2027−2026)×12+(5−10)=7개월이 남았으니 여유가 7−18=−11, 프로젝트 중간에 11개월이 모자란다. Jazzy는 (2029−2026)×12+(5−10)=31개월이 남아 여유가 +13이다. 원래 질문의 Iron은 (2024−2026)×12+(12−10)=−22로, 프로젝트 기간을 빼기 전부터 음수다.

이 계산은 HuntLab이 공식 표 날짜로 만든 자체 예제 example.py에 11개 사례로 들어 있다. Humble·Iron·Jazzy·Kilted의 지원 기간 4개, 2026년 10월 기준 남은 개월 5개, 18개월 프로젝트 판정 2개다. 각 값을 assert로 기대값과 비교하므로 11개가 모두 통과하고 종료 코드가 0이면 정상, AssertionError나 0이 아닌 종료 코드가 나오면 실패로 본다. 검산 기록은 verification.json에 있고, 리서치 단계에서 같은 공식 날짜로 따로 다시 계산해 11개 값이 모두 일치함을 확인했다. 예제는 파이썬 표준 라이브러리만 쓰므로 ROS 2 설치 없이도 돌릴 수 있다.

월 단위로 계산하는 탓에 생기는 오차도 알아 둘 만하다. Humble의 “7개월”은 2026년 10월 4일부터 2027년 5월 중 어느 날까지를 뜻한다. 공식 표에 일(day)이 없으니 실제 종료일과 몇 주 차이가 날 수 있다. 여유가 0이나 1로 나오면 통과보다는 경계로 읽는 편이 안전하다.

60개월과 19개월은 Ubuntu LTS 주기에서 나온다

같은 식에 출시 월을 넣으면 Humble·Jazzy·Lyrical은 60개월, Iron·Kilted는 19개월이 나온다. 아직 나오지 않은 Makoa도 (2028−2027)×12+(12−5)=19개월이다. 짝수 해 배포판과 홀수 해 배포판이 두 무리로 깔끔하게 갈리는 데는 이유가 있다.

ROS 2의 출시 주기와 대상 플랫폼을 정한 공식 문서인 REP 2000(ROS Enhancement Proposal 2000)에 따르면 새 배포판은 12개월마다 나온다. 짝수 해 배포판은 Ubuntu LTS가 나온 한 달 뒤, 보통 5월에 출시되고 그 Ubuntu LTS의 표준 지원 5년이 끝날 때까지, 곧 출시 후 4년 11개월 동안 지원된다. 홀수 해 배포판은 이전 LTS와 같은 Ubuntu를 대상으로 1.5년만 지원되는데, 다음 LTS와 6개월 겹치게 해서 옮겨 갈 시간을 주려는 설계다. ROS 2의 지원 기간이 Ubuntu LTS 일정에 묶여 있는 셈이다.

정책 문장의 4년 11개월(59개월)과 1.5년(18개월)은 표에서 뺀 60개월, 19개월과 1개월씩 어긋난다. EOL이 월까지만 적혀 있어서 생기는 경계 효과다. 그래서 이 글의 60과 19는 “공식 지원 기간”이 아니라 “공식 표 날짜로 계산한 개월 수”로 부른다.

출처끼리 날짜가 다른 곳도 있다. REP 2000은 Iron을 “May 2023 – November 2024″(L970), Kilted를 “May 2025 – November 2026″(L1204)으로 적는데, Releases 표는 Iron을 2024년 12월 4일, Kilted를 2026년 12월로 적는다. 현재 지원 중인 배포판을 표시하는 쪽이 Releases 표라서 계산은 그 표를 따랐다. REP 2000 날짜를 쓰면 2026년 10월 기준 Kilted의 남은 개월은 2가 아니라 1, Iron은 −22가 아니라 −23이다. 어느 쪽을 쓰든 두 배포판으로 새 프로젝트를 시작할 수 없다는 판단은 그대로다. 확인한 REP 2000 판(2025-10-23 커밋)에는 Lyrical 절이 없어서, Lyrical의 날짜와 플랫폼은 ROS 2 문서로만 확인했다.

배포판을 고르면 Ubuntu도 함께 고른 셈이다

REP 2000은 “A single ROS 2 distribution will only have full Tier 1 support for a single Ubuntu LTS”라고 적는다(L36-L39). 한 배포판을 Tier 1으로 받쳐 주는 Ubuntu LTS는 하나뿐이라는 뜻이다.

지원 등급(support tier)은 개발팀이 그 플랫폼을 얼마나 직접 시험하고 고치는지를 나눈 단계다. 같은 문서의 정의(L77-L97)로 Tier 1은 단위 테스트와 지속적 통합(continuous integration, CI, 코드가 바뀔 때마다 자동으로 빌드·시험하는 작업), 야간 작업, 패키징, 성능 시험을 자주 돌리고 거기서 나온 버그를 우선 고치는 플랫폼이다. Tier 2는 주기적인 CI 시험을 받고 오류는 여력이 되는 대로 고친다. Tier 3은 커뮤니티 보고상 동작한다는 수준이며 개발팀이 테스트를 돌리지 않는다.

apt로 바로 설치할 수 있느냐는 등급과 따로 표시된다. 배포판 페이지의 플랫폼 표에서 [d]는 데비안·RPM 같은 배포판 전용 패키지가 나온다는 뜻이다. [a]는 미리 빌드한 전체 패키지를 압축 파일 하나로 받는 방식, [s]는 소스에서 직접 컴파일하는 방식이다(Jazzy 페이지 L57-L66). 등급과 apt 제공이 같은 말이 아니라는 것은 같은 표의 Windows 10 칸이 Tier 1인데도 [d] 없이 [a][s]만 달고 있다는 데서 보인다.

Ubuntu 칸만 보면 등급과 표시가 짝을 이룬다. 표의 마지막 열대로 Humble은 22.04, Jazzy와 Kilted는 24.04, Lyrical은 26.04가 Tier 1이고, 그 칸에는 [d]가 붙어 있다. Humble의 플랫폼 표에서 Ubuntu 22.04는 Tier 1 [d][a][s]다. 반면 Jazzy의 플랫폼 표는 22.04를 amd64 행에만 Tier 3 [s]로 올려 두었다. 같은 페이지 위쪽의 등급별 목록에는 22.04가 나오지 않으니 표의 amd64 행을 봐야 한다. Lyrical의 지원 플랫폼 표는 24.04를 [d] 없는 Tier 3으로 두고 소스 빌드가 필요하다고 적으며, 그 24.04 지원도 2029년 6월 1일에 일찍 끝낸다.

그래서 원래 질문자처럼 Ubuntu 22.04에 머문다면 apt 패키지([d])로 받을 수 있는 지원 중 배포판은 Humble 하나다. 계산한 여유가 음수로 나오면 OS 업그레이드를 계획할 때가 됐다는 신호로 읽으면 된다. 24.04로 올리면 Jazzy가, 26.04로 올리면 Lyrical이 Tier 1이 된다.

공식 Jazzy 컨테이너에서 예측과 실행 결과를 맞춰 봤다

앞의 계산과 “Jazzy는 Ubuntu 24.04″라는 결합이 실제 배포 이미지에서도 그대로인지 보려고, 공식 ros:jazzy-ros-base 이미지 안에서 세 가지를 재는 스크립트 experiment.py를 실행했다. 첫째는 설치된 배포판과 Ubuntu 버전, 둘째는 실행하는 날의 컨테이너 시계로 다시 계산한 남은 개월과 여유, 셋째는 같은 Jazzy 설치 안에서 별도 프로세스 두 노드가 메시지를 주고받는지다. 노드(node)는 하나의 기능을 맡아 메시지를 주고받는 ROS 2 실행 단위이고, 토픽(topic)은 노드끼리 메시지를 흘려보내는 이름 붙은 통로다. 본 실행 전에 리서치 값으로 예측을 plan.md에 적어 두었고, 재현 스크립트와 실행별 원본 출력은 실험 저장소 폴더의 results.json에 공개했다.

측정 환경은 이렇다.

• 이미지: ros:jazzy-ros-base를 다이제스트로 고정했다. 다이제스트(digest)는 이미지 내용으로 만든 해시 주소라서, 나중에 다른 내용을 가리킬 수 있는 태그와 달리 같은 이미지를 다시 받게 해 준다.
• Python 3.12.3, rclpy 데비안 패키지 7.1.12-1noble.20260902.053513
• RMW: rmw_fastrtps_cpp(기본값). RMW(ROS middleware)는 ROS 2 코드와 실제 통신 라이브러리 사이에 끼운 교체 가능한 층이고, 이 구현은 그 자리에 Fast DDS를 쓴다. DDS(Data Distribution Service)는 노드끼리 서로를 찾아 메시지를 나르는 통신 표준이다.
• 통신 설정: 전달 품질 설정(Quality of Service, QoS) 가운데 신뢰 전달(RELIABLE), 즉 빠진 메시지를 다시 보내는 모드에 대기열 깊이 100. 발행 노드가 std_msgs/String 100개를 약 10 ms 간격으로 보낸다.
• 지연 측정: 각 메시지에 보낸 시각을 담고 받은 시각에서 뺐다. 시각은 단조 시계(monotonic clock), 곧 시스템 시간을 고쳐도 되돌아가지 않고 앞으로만 가는 시계로 쟀다. 두 프로세스가 같은 컨테이너에 있어 같은 시계를 본다.
• 조건: 네트워크 없음(--network none), CPU 1개, 메모리 1 GiB, 5회 반복

Docker가 설치된 리눅스 셸이라면 빈 디렉터리에서 다음 두 줄로 같은 조건을 재현할 수 있다. 정상은 세 가지가 모두 맞을 때다. 종료 코드가 0이고, 마지막 summary 줄이 "ok": true이며, same_distro_pubsub 줄이 "received": 100, "unique_seq": 100, "in_order": true여야 한다. 스크립트의 ok는 한 개 이상 받았는지와 발행 측 배포판이 jazzy인지만 보기 때문에, 100개 중 일부만 도착해도 true가 찍힌다. 그래서 수신 개수와 순서를 따로 본다. 0이 아닌 종료 코드, 100개보다 적은 수신, 순서 뒤바뀜, 발행 측 배포판 불일치는 모두 실패다. 개월 수는 실행하는 달에 따라 달라진다.

curl -fLO https://raw.githubusercontent.com/sungpyo9053/blog/main/experiments/ros2-distro-choice-iron-humble-remaining-support-months/experiment.py
docker run --rm --network none --cpus 1 --memory 1g -v "$PWD":/work ros@sha256:066420e07f60aa18262f2479981def87ebcfcec42eefb0c0c57c4a46098348ca bash -c "source /opt/ros/jazzy/setup.bash && python3 /work/experiment.py"

본 실행 전 시험 실행에서 스크립트를 고친 부분이 있다. 첫 시험에서는 발행 노드 이름이 _NODE_NAME_UNKNOWN_으로 기록됐다. 발견 직후 첫 조회 때 이름이 아직 전파되지 않았기 때문이라, 이름이 잡힐 때까지 다시 읽도록 바꿨다. 신뢰성 설정이 enum 정수로 찍히던 것도 이름(RELIABLE)으로 기록하게 했다. 두 번째 시험에서는 버전이 빈 ros-jazzy-rmw-connextdds와 ros-jazzy-rmw-cyclonedds-cpp가 섞여 나왔는데, dpkg가 이름만 알고 실제로는 설치하지 않은 항목이었다. 설치 상태가 ii인 패키지만 세고 나머지는 따로 기록하도록 고친 뒤, 세 번째 시험이 정상 종료한 다음 아래 5회를 실행했다.

5회 실행 시각은 2026-10-04T14:52:16Z부터 14:52:33Z(UTC)까지이며, 5회 모두 종료 코드 0과 "ok": true로 끝났다.

항목	실행 전 예측(plan.md)	실행 결과(results.json, 5회)
ROS_DISTRO	jazzy	jazzy
Ubuntu	24.04 noble	24.04 noble, 공식 Tier 1과 일치
/opt/ros 아래 배포판	jazzy 하나	jazzy 하나
설치된 ros-* 패키지	모두 ros-jazzy- 이름, noble 빌드	201개 모두 ros-jazzy-, 버전 접미사도 201개 모두 noble
남은 개월: Humble·Jazzy·Kilted·Lyrical·Iron	7·31·2·55·−22	7·31·2·55·−22
표 기준 지원 기간	Humble·Jazzy·Lyrical 60, Iron·Kilted·Makoa 19	같음
18개월 프로젝트 여유: Humble·Jazzy·Kilted·Lyrical	−11·13·−16·37	−11·13·−16·37
Jazzy로 18개월 프로젝트를 시작할 수 있는 마지막 달	2027-11	2027-11
같은 배포판 두 노드: 받은 메시지	보낸 100개 모두	100개 중 100개, 순서 유지, 중복 없음
구독 생성부터 첫 수신까지	예측하지 않음	0.371~0.384초
지연 중앙값 / p95 / 최댓값	예측하지 않음	0.431~0.455 / 0.497~0.653 / 0.556~1.684 ms

p95는 100개 지연을 짧은 순서로 늘어놓았을 때 95번째 값이다. 예측과 다른 값은 없었다. 배포판·OS·개월 수 줄은 5회 모두 같았고, 지연만 회차마다 조금씩 달랐다.

스크립트는 6·12·18·24·36개월 다섯 가지 프로젝트 기간의 여유도 함께 계산했다(기준 2026-10). Iron은 모든 기간에서 −28부터 −58까지 음수라 표에서 뺐다.

프로젝트 기간	Humble	Jazzy	Kilted	Lyrical	여유가 0 이상인 출시 배포판
6개월	1	25	−4	49	humble, jazzy, lyrical
12개월	−5	19	−10	43	jazzy, lyrical
18개월	−11	13	−16	37	jazzy, lyrical
24개월	−17	7	−22	31	jazzy, lyrical
36개월	−29	−5	−34	19	lyrical

1회차 원본 출력에서 플랫폼·통신·요약 줄을 그대로 옮긴다. 개월 줄은 위 두 표로 대신했다.

{"kind": "platform", "ros_distro_env": "jazzy", "ubuntu_version_id": "24.04", "ubuntu_codename": "noble", "opt_ros_distros": ["jazzy"], "opt_ros_distro_count": 1, "ros_packages_total": 201, "ros_packages_known_not_installed": ["ros-jazzy-rmw-connextdds", "ros-jazzy-rmw-cyclonedds-cpp"], "ros_packages_by_distro_prefix": {"jazzy": 201}, "version_suffix_codenames": {"noble": 201}, "packages_with_build_stamp": 201, "packages_without_build_stamp": [], "oldest_build_date": "20260121", "newest_build_date": "20260903", "distinct_build_dates": 14, "rclpy_deb_version": "7.1.12-1noble.20260902.053513", "ros_apt_suites": ["noble"], "official_tier1_for_running_distro": "24.04", "running_ubuntu_matches_official_tier1": true}
{"kind": "same_distro_pubsub", "rmw_implementation_env": "(unset: default)", "sent": 100, "received": 100, "unique_seq": 100, "in_order": true, "publisher_distros_seen": ["jazzy"], "seconds_to_first_message": 0.376, "latency_ms_median": 0.436, "latency_ms_p95": 0.509, "latency_ms_max": 0.569, "publisher_endpoint": {"node_name": "distro_check_publisher", "topic_type": "std_msgs/msg/String", "topic_type_hash": "RIHS01_df668c740482bbd48fb39d76a70dfd4bd59db1288021743503259e948f6b1a18", "reliability": "RELIABLE"}, "publisher_exit_code": 0}
{"kind": "summary", "ok": true, "running_distro": "jazzy", "ubuntu": "24.04", "tier1_match": true, "months_remaining": 31, "received": 100, "sent": 100, "elapsed_seconds": 3.52}

여기서부터는 해석이다. 공식 Jazzy 이미지에 설치된 ros-* 패키지 201개는 모두 Jazzy용, Ubuntu 24.04 빌드였고 apt 저장소도 noble 하나만 가리켰다. 문서가 말하는 “배포판을 고르면 Ubuntu가 정해진다”는 결합이 배포 이미지에서도 그대로 드러난 셈이다. 이것은 apt로 받은 바이너리 이미지 하나의 모습이고, 22.04에서 Jazzy를 소스로 빌드하는 [s] 경로를 막는다는 뜻은 아니다. 설치된 바이너리의 빌드 날짜가 2026년 9월 초까지 이어진 것은 지원 중인 배포판에 빌드가 계속 들어온 흔적으로 볼 수 있지만, 앞으로도 그렇다는 보장은 아니다.

개월 수가 예측과 똑같았다는 점은 새로운 발견이라기보다 확인에 가깝다. 같은 식을 실행 날짜로 다시 계산해도 값이 유지됐다는 뜻이고, 다른 달에 돌리면 이 줄은 달라진다. 같은 배포판 두 프로세스 사이에서는 100개 메시지가 순서대로 모두 도착했다. 지연 수치는 네트워크 없는 1 CPU 컨테이너 안에서 잰 값이라 실제 로봇 네트워크의 성능으로 옮겨 읽으면 안 된다. 출력의 타입 해시(RIHS01_…)는 관측값으로만 남겼다. 이 값이 배포판 사이 호환성과 어떤 관계인지는 확인한 자료가 없다.

로봇은 Humble, 노트북은 Jazzy라면

계산을 마치고 배포판을 정해도 한 가지가 남는다. 팀의 장비가 서로 다른 배포판을 쓰면 어떻게 되는가. 공식 문서의 답은 분명하다.

Nodes are not guaranteed to be able to communicate across distributions. (…) It may or may not work, but it is not supported and should not be relied upon. — ROS 2 Releases, Cross-Distribution Communications

배포판이 다른 노드끼리는 통신이 보장되지 않고, 될 수도 안 될 수도 있지만 지원 대상이 아니니 기대지 말라는 뜻이다. 같은 절은 한 배포판 안에서도 서로 다른 RMW 구현 사이의 통신은 보장되지 않는다고 덧붙인다. 그러니 로봇 탑재 PC, 개발 노트북, 시뮬레이션 PC, Docker 이미지를 모두 같은 배포판으로 맞추는 것이 기본이다. 이 기준은 공식 지원 범위에서 끌어낸 행동 지침이다. 앞 실험의 100개 중 100개 수신은 두 노드가 모두 Jazzy인 경우이고, 배포판이 다를 때 통신이 깨지는 장면은 HuntLab이 재현하지 않았다.

네 가지 상황으로 직접 판정해 보기

아래는 모두 2026년 10월에 시작한다고 가정한 연습 문제다. 답을 보기 전에 먼저 계산해 보면 식이 손에 붙는다.

Ubuntu 22.04 노트북으로 6개월짜리 졸업 과제를 한다. Humble의 여유는 7−6=+1이다. 계산상 통과지만 1개월은 월 단위 근사의 오차 안에 들어가는 경계값이다. 22.04에서 apt 패키지로 받을 수 있는 지원 중 배포판은 Humble뿐이니 일정이 밀리지 않을 자신이 있으면 Humble, 밀릴 여지가 있으면 24.04로 올리고 Jazzy를 쓰는 편이 낫다.

Iron으로 쓰인 튜토리얼을 따라 설치하려 한다. Iron은 2024년 12월 4일에 EOL이 됐고 남은 개월이 이미 음수다. 새로 설치할 대상이 아니다.

로봇에는 Humble이 깔려 있고, 새 노트북에는 Jazzy를 깔았다. 배포판 사이 통신은 공식적으로 지원되지 않는다. 남은 개월을 기준으로 한쪽을 정해 통일한다. Humble은 7개월 뒤 EOL이므로, 로봇 PC를 24.04로 올릴 수 있다면 Jazzy로 맞추는 쪽이 계산과도 맞는다.

36개월짜리 연구 과제를 시작한다. Jazzy는 31−36=−5로 마지막 다섯 달을 EOL 이후에 보내게 된다. Lyrical은 55−36=+19로 조건을 만족한다. 다만 Lyrical의 Tier 1은 Ubuntu 26.04이고, 쓰려는 패키지와 드라이버가 Lyrical용으로 나와 있어야 한다. 24.04에 머물러야 한다면 Jazzy로 시작하되 도중에 배포판을 옮기는 일정을 처음부터 넣어 두어야 한다.

계산이 대신 정해 주지 않는 것

남은 개월은 공식 유지보수의 기간만 알려 준다. 로봇 드라이버, Gazebo나 Isaac Sim 같은 시뮬레이터, Nav2와 MoveIt 같은 서드파티 패키지가 그 배포판용으로 배포됐는지는 이 계산으로 알 수 없고, 각 프로젝트 문서에서 따로 확인해야 한다. Jazzy와 Lyrical 사이에서 고민할 때 실제로 갈리는 지점도 이것이다. 장비의 OS를 26.04로 올릴 수 있고 필요한 패키지가 Lyrical용으로 나와 있으면 남은 개월이 가장 길다. 24.04에 머물러야 하면 Jazzy가 Tier 1이다. 공식 문서가 둘 중 하나를 직접 추천하지는 않으며, 앞에서 인용한 “가장 최근 안정 배포판” 권고는 Rolling과 비교하는 맥락의 문장이다. 패키지 생태계가 얼마나 옮겨 갔는지에 대한 수치는 공식 근거를 찾지 못해 쓰지 않았다.

지원 중인 배포판을 골랐다고 로봇 동작이 안전해지는 것도 아니다. 배포판 선택은 소프트웨어 유지보수 기간에 대한 판단이고, 실물 로봇의 안전은 별개로 따져야 한다.

2026년 10월에 새 프로젝트를 시작한다면 Iron과 Kilted는 후보에서 빼고, Humble은 22.04에 묶인 채 7개월 안에 끝나는 작업에만 남긴다. 나머지 대부분은 Jazzy(24.04)와 Lyrical(26.04) 가운데 장비 OS와 필요한 패키지가 허락하는 쪽이다. 이 글의 숫자는 2026년 10월 기준이라 다음 달이면 모두 1씩 줄어든다. 설치 명령을 치기 전에 공식 Releases 표를 열어 오늘 날짜로 남은 개월을 다시 빼 보는 것이 첫 단계다. ROS 2의 다른 기초 개념이 필요하다면 ROS 2와 tf2의 역할을 다룬 글로 이어서 볼 수 있다.

참고 링크

모두 2026년 10월 4일에 확인했다. ROS 2 문서는 커밋 88573f7, REP 2000은 커밋 11ca24a에 고정한 주소다. 제휴·협찬은 없다.

• ROS 2 Documentation — Releases.rst: 배포판 정의, 출시일·EOL 표, Rolling 안내, 배포판 간 통신. 렌더링판은 docs.ros.org Releases
• REP 2000 — ROS 2 Releases and Target Platforms: 출시 주기, LTS·비LTS 지원 원칙, 지원 등급(Tier 1~3) 정의, 배포판별 대상 플랫폼. 렌더링판은 reps.openrobotics.org/rep-2000
• 배포판별 페이지: Humble, Iron, Jazzy, Kilted, Lyrical과 Lyrical 지원 플랫폼, Makoa(예정)
• HuntLab 산술 예제와 검산 기록: example.py, verification.json
• Jazzy 컨테이너 실험: experiment.py, plan.md, results.json