제15부 이행·확장

15.2 Kilted·Rolling 대비

15.2.1 이 장에서 배우는 것 / 선수 지식

15.1이 지난 이행을 다뤘다면, 이 장은 다음 이행이다. Jazzy도 언젠가 EOL이 오고, 그때 또 같은 작업을 하게 된다.

이 장의 관점은 하나다. 이행을 이벤트가 아니라 지속적 활동으로 바꾸라. 2년마다 대규모 이행 프로젝트를 하는 대신, 평소에 조금씩 준비하면 각 이행이 작아진다. 그 수단이 Rolling과의 관계 설정이다.

배우는 것:

• 배포판 주기 — 어떻게 나오고 사라지는가.
• Rolling — 무엇이고 어떻게 쓰는가.
• 선행 대응 — 변화를 미리 만나기.
• REP·설계 변경 추적 — 큰 변화의 신호.
• 버전 전략 — 어느 배포판에 머물 것인가.
• 미래 대비 코드 — 무엇이 오래 가는가.

선수 지식: 0.3(배포판·Tier), 15.1(이행 실무), 14.7(의존성), 4.10(CI), 15.5(생태계 — 함께 읽으면 좋다).

정직: 미래 배포판의 내용·일정·이름은 이 책이 확정적으로 말할 수 없다. 다만 배포판 주기의 규칙(언제 나오고 언제 지원이 종료되는가)은 REP 2000이 명문화하고 있고, 이 장은 그 규칙과 Kilted Kaiju·Rolling Ridley의 REP 2000 등재 값을 2026년에 직접 확인해 인용한다. 향후 배포판(Kilted 다음 LTS 등)의 구체적 내용·정확한 이름은 그 시점의 공식 로드맵·REP·릴리스 노트로 확인해야 하며(확인 필요)(→ 194차 확인: REP 2000 원본 저장소를 직접 클론해 재확인하니 이 마커는 여전히 유효하다 — 다만 REP 2000 밖에서 다음 배포판의 실제 이름을 찾아냈다. 아래 실행 확인(194차) 참고), 여기서는 대비 방법론만 다룬다. 이 장은 이 책에서 가장 빨리 낡을 내용 중 하나다(10.5.10의 10번과 같은 성격) — 특히 15.2.2의 날짜 표는 확인 시점 스냅샷이니 반드시 원문을 다시 보라. 명령 실행은 이 환경에서 검증하지 않았다(목차 3).(→ 194차 확인: git clone으로 REP 저장소·실제 ROS 2 생태계 저장소(Nav2)를 직접 확인했다 — 컨테이너 실행이라기보다 "출처 확인"에 가깝지만(15.5의 구분과 같은 성격), apt-get source 기반 API-diff(83·84·167·168·172차)와 같은 종류의 직접 확인 방법론이라 실행 확인으로 기록한다. 아래 실행 확인(194차) 참고.)

15.2.2 배포판 주기

REP 2000에 등재된 최근 배포판(확인 시점 기준):

정직: 이 표는 REP 2000을 확인한 시점의 스냅샷이다. Kilted 다음 LTS(주기상 2026년 5월경이어야 한다)의 정식 이름·정확한 등재는 확인 시점의 REP 2000에 아직 없었다(확인 필요: 최신 REP 2000)(→ 194차 확인: 재확인해도 여전히 REP 2000엔 없었지만, 생태계 저장소에서 실제 이름을 찾아냈다 — 아래 실행 확인(194차) 참고) — 이 책을 읽는 시점에는 이미 등재돼 있을 가능성이 높다. 원문을 반드시 다시 보라.

실행 확인(194차) — REP 2000 원본 저장소(github.com/ros-infrastructure/rep)를 직접 git clone해 재확인하니, 이 마커는 여전히 정확했다. rep-2000.rst의 배포판 절 제목을 순서대로 추출하니 Kilted Kaiju (May 2025 - November 2026) 다음이 곧바로 Rolling Ridley (June 2020 - Ongoing)로 끝났다 — 후속 LTS가 여전히 등재돼 있지 않았다. 이 저장소의 HEAD 커밋(11ca24a)은 2025-10-24로, 이 회차(2026-08-22 세션 기준)에서도 그 이후 갱신이 없었다는 뜻이다. 그런데 REP 2000이 침묵하는 사이, 실제 생태계 저장소에는 이미 다음 배포판이 이미 존재했다 — Nav2(ros-navigation/navigation2)를 클론해 확인하니 lyrical이라는 이름이 네 갈래 독립 증거로 확인됐다: ① .github/workflows/build_main_against_distros.yml의 빌드 매트릭스가 [jazzy, lyrical], ② 전용 의존성 파일 tools/underlay.lyrical.repos가 실재, ③ update_ci_image.yaml의 브랜치 트리거 목록이 [main, lyrical, jazzy, humble], ④ git ls-remote --heads origin에 refs/heads/lyrical이 humble·jazzy·kilted와 나란히 실제 브랜치로 존재. "Lyrical"은 ROS 2의 순차 알파벳 명명 규칙(Ardent·Bouncy·Crystal·Dashing·Eloquent·Foxy·Galactic·Humble·Iron·Jazzy·Kilted 다음 L)과도 정확히 들어맞는다. 정직한 한계: 이 이름은 REP 1·2000·2002 어디에도 공식 등재된 것이 아니라 생태계 인프라(Nav2의 CI·브랜치)에서 발견한 정황 증거다 — 공식 발표 이전에 이름이 바뀐 선례가 없는지는 확인하지 않았다. 부수 발견: 같은 조사에서 ros2/rclcpp를 클론해 보니 GitHub Actions 워크플로 자체가 없었다(.github/workflows/ 디렉터리 부재) — 핵심 클라이언트 라이브러리는 ROS 빌드팜(Jenkins 기반)에서 CI를 실행하고, Nav2 같은 생태계·응용 계층 프로젝트만 GitHub Actions를 쓴다는 층위 차이를 확인했다(15.2.3 참고). 원본: tools/gap_harness/gap193/rep2000_check/(findings.log·build_main_against_distros.yml·update_ci_image.yaml·findings_summary.txt).

견해: "LTS만 쓴다"가 대부분의 제품 개발에 맞는 전략이다. 비LTS는 지원 기간이 1.5년뿐이라 곧 다시 이행해야 하므로, 운영 시스템은 LTS에 머무는 것이 비용이 낮다. 위 표에서 Kilted Kaiju는 2025년 5월에 나와 2026년 11월이면 지원이 끝난다 — Jazzy(2029년 5월까지)보다 2년 반이나 먼저 종료된다. 연구·프로토타입은 다를 수 있다.

견해: OS 페어링이 이행 일정을 강제한다는 점을 인식하라(4.4). 표에서 보듯 Iron과 Humble, Kilted와 Jazzy는 같은 Ubuntu를 공유한다 — ROS 배포판은 그 사이에 새 Ubuntu가 안 나왔으면 이전 LTS를 그대로 쓴다. 그래도 ROS 배포판 자체의 EOL은 그와 무관하게 REP 2000의 지원 기간 규칙(5년/1.5년)을 따른다. 둘 중 먼저 끝나는 쪽이 실질 기한이다.

15.2.3 Rolling

개발이 진행되는 곳이다.

정직: Rolling의 타깃 플랫폼은 고정이 아니라 "그때그때의 최신 배포판을 따라간다"는 것이 REP 2000의 문면이다("Rolling Ridley의 타깃 플랫폼은 새 상류 배포판이 ROS 2 개발 대상으로 선정될 때마다 갱신된다"). 확인 시점에는 Kilted Kaiju와 같은 플랫폼이었지만, 이 책을 읽는 시점엔 이미 다음 LTS의 플랫폼으로 넘어갔을 수 있다 — Rolling에서 작업 중이라면 지금 타깃이 무엇인지 그때그때 확인해야 한다.

활용 방법:

견해: "Rolling CI를 비차단으로 실행하는 것"이 비용 대비 효과가 가장 좋다. 깨져도 개발을 막지 않지만, 무엇이 다가오는지 알려준다. 이행 시점에 "이미 아는 문제 목록"이 있으면 작업이 훨씬 예측 가능해진다.

함정: Rolling CI를 차단(필수)으로 두면 개발이 멈춘다. Rolling은 상류 사정으로 언제든 깨질 수 있고, 그것이 우리 잘못이 아닌 경우가 많다. 비차단으로 두고 정기적으로 확인하는 것이 맞다.

견해: Rolling에서 깨진 것을 즉시 고칠 필요는 없다. 상류가 아직 변화 중일 수 있으므로, 기록해 두고 배포판이 확정될 때 대응하면 된다. 다만 우리 코드의 문제가 드러난 경우(잘못된 API 사용·미정의 동작)는 지금 고치는 것이 낫다.

견해: 팀 규모가 작으면 Rolling CI가 부담일 수 있다. 유지보수 대상이 하나 늘고, 실패를 무시하는 습관이 생기면 오히려 해롭다(14.5.8). 감당할 수 있을 때만 도입하라.

"비차단"을 CI 설정에서 실제로 어떻게 표현하는가. 대부분의 CI 시스템은 한 작업의 실패가 전체 파이프라인을 막지 못하게 하는 옵션을 제공한다(4.10). GitHub Actions라면 continue-on-error가 그 스위치다:

# .github/workflows/ci.yml (개념 예시)
jobs:
  jazzy:
    runs-on: ubuntu-24.04
    steps: [ ... ]              # 실패하면 파이프라인 전체가 실패 — 이것이 "차단"
  rolling:
    runs-on: ubuntu-24.04
    continue-on-error: true     # 실패해도 파이프라인은 계속 "성공"으로 표시됨
    steps: [ ... ]               # 결과는 별도로 확인 — 이것이 "비차단"

정직: 위 YAML은 GitHub Actions의 일반 문법을 옮긴 개념 예시이며, ROS 2 저장소가 실제로 Rolling CI에 쓰는 정확한 워크플로 파일은 각 저장소(ros2/*)의 .github/workflows/가 정본이다(확인 필요)(→ 194차 확인: 이 단서가 예상보다 더 중요했다 — 저장소마다 CI 체계 자체가 다르다. 아래 실행 확인(194차) 참고). 핵심은 도구가 무엇이든 "실패해도 전체를 안 막는다"는 옵션이 대부분 있고, 15.2.3의 조언은 그 옵션을 켜라는 것이라는 점이다.(→ 194차 확인: ros2/rclcpp를 직접 클론해 확인하니 .github/workflows/ 디렉터리 자체가 없었다 — 핵심 클라이언트 라이브러리는 GitHub Actions가 아니라 ROS 빌드팜(Jenkins)에서 CI를 실행한다. 반면 Nav2(ros-navigation/navigation2) 같은 생태계 프로젝트는 GitHub Actions를 실제로 쓴다(lint.yml·build_main_against_distros.yml 등 확인). "정확한 워크플로 파일을 보라"는 조언 자체가 맞았을 뿐 아니라, 어떤 CI 체계를 쓰는지부터가 계층에 따라 다르다는 것을 실측으로 확인했다. 15.2.1의 실행 확인(194차) 참고.)

15.2.4 변화 추적

무엇을 지켜보는가.

견해: REP를 지켜보는 것이 큰 변화를 미리 아는 가장 확실한 방법이다(A.3). 설계 결정이 REP로 기록되므로, 새 REP나 개정이 나오면 방향이 바뀐다는 신호다. 전부 읽을 필요는 없고, 제목과 요약만 읽어도 개요가 파악된다. REP 자체는 세 종류로 나뉜다(REP 1이 정의) — Standards Track(새 기능·구현 제안), Informational(설계 논의·권고, 따르지 않아도 됨), Process(개발 절차·도구 변경, 커뮤니티 합의가 필요하고 권고 이상의 구속력을 가짐). REP 2000·2001·2004처럼 이 책에서 자주 인용하는 것들은 대부분 Informational이다 — "공식 기록이지만 반드시 따라야 하는 표준은 아니다"라는 뜻이다. REP의 제안·논의는 discourse.ros.org(→ 195차 정정: 옛 주소다 — 현재 공식 문서가 쓰는 도메인은 discourse.openrobotics.org다. 15.5.3의 실행 확인(195차) 참고)에서 이뤄지며, 제안자("챔피언")가 커뮤니티 합의를 이끄는 책임을 진다(15.5.3에서 이어 다룬다).

견해: "우리가 쓰는 것"으로 범위를 좁히라. 생태계 전체를 따라가는 것은 불가능하다. 의존성 목록(14.7.5)에 있는 것들의 릴리스 노트만 봐도 충분한 경우가 많다.

견해: 폐기 예고를 목록으로 관리하라. "다음 배포판에서 제거 예정"이라는 경고를 만나면 이슈로 만들어 두면, 이행 시점에 무엇을 해야 하는지 이미 정리되어 있다.

15.2.5 미래 대비 코드

어떤 코드가 오래 가는가.

견해: "ROS 계층을 얇게 유지하라"가 이행 관점에서도 값을 한다(14.5.3의 세 번째 이유가 여기 추가된다). 핵심 알고리즘이 ROS와 무관하면, 배포판이 바뀌어도 얇은 계층만 고치면 된다. 성능·결정성·시험 용이성·이행 용이성이 모두 같은 구조를 가리킨다.

견해: 내부 API(detail 네임스페이스·비공개 헤더)를 쓰지 말라. 편의를 위해 수정하면 다음 이행에서 깨진다. 공개 API로 불가능한 것이 있다면 상류에 요청하는 편이 장기적으로 낫다(15.5).

함정: "지금 동작하니까"로 미정의 동작에 의존하면 미래에 깨진다. 실행 순서(12.5.4)·타이밍·초기화 순서에 의존하는 코드가 대표적이다. 명시적으로 보장된 것에만 의존하는 것이 미래 대비다. 15.1.3이 실제 사례를 하나 보여준다 — Jazzy에서 executor의 콜백 순서 보장이 조용히 사라졌다(내부적으로 static executor 방식을 쓰도록 바뀌면서). 컴파일 오류 없이 넘어가고 대부분 문제도 없지만, 순서를 암묵적으로 가정한 코드만 깨진다. "보장 문서에 안 적혀 있으면 없는 것"이라는 태도가 이런 사례를 막는다.

폐기부터 제거까지의 실제 간격. 15.1.3이 인용한 Jazzy 릴리스 노트 사례들을 보면 패턴이 보인다 — 구독 콜백 시그니처는 Humble에서 폐기 예고되고 두 배포판(Iron 건너뛰고) 뒤인 Jazzy에서 제거됐고, rclcpp/qos_event.hpp는 Iron에서 폐기 예고되고 바로 다음 배포판인 Jazzy에서 제거됐다. 표본이 둘뿐이라 일반 법칙으로 단정할 수는 없지만(확인 필요: 더 넓은 표본), "폐기 예고 후 최소 한 배포판(1년), 대개 한두 배포판의 유예"라는 감을 준다. 즉 폐기 경고가 출력되면 다음 이행 전에는 반드시 정리해야 한다는 15.1.9의 조언이 여기서 숫자로 뒷받침된다.

15.2.6 버전 전략

견해: ②(안정화 후 이행)가 대부분에 맞는다. 새 LTS가 나온 직후에는 상위 스택(Nav2·MoveIt 등)이 아직 준비 중일 수 있고, 초기 버그도 있다. 몇 달 기다렸다가 시작하면 남들이 겪은 문제를 피할 수 있다.

견해: ④(건너뛰기)는 대체로 좋지 않은 선택이다. 이행 횟수는 줄지만 한 번의 격차가 커져 위험이 비선형으로 는다. 두 배포판 분량의 변경을 한꺼번에 다루는 것은 각각 다루는 것보다 훨씬 어렵다.

견해: 전략을 팀에서 명시적으로 정하고 문서화하라. "언제 이행하는가"가 정해져 있지 않으면 항상 미뤄지고, 결국 ③이나 ④가 된다. "새 LTS 릴리스 후 6개월 내 시작" 같은 규칙이 있으면 계획에 들어간다.

견해: 위 네 전략에 다섯 번째 변형이 있다 — "비LTS는 건너뛴다." 15.2.2의 표가 보여주듯 Kilted Kaiju 같은 비LTS는 지원이 1.5년뿐이라, Jazzy에서 Kilted로 옮겼다가 다음 LTS로 또 옮기는 것은 실질적으로 이행을 두 번 하는 것과 같다. 새 기능이 비LTS에만 있어 급히 필요한 경우가 아니라면, "LTS에서 LTS로"가 대개 ②(안정화 후 이행)와 결합해 가장 적은 이행 횟수로 계속 지원되는 상태를 유지하는 경로다 — 이것은 15.2.6의 ④(LTS 건너뛰기)와는 다르다. ④는 LTS를 건너뛰어 격차가 누적되는 것이고, 이 변형은 비LTS를 건너뛰어 오히려 격차를 줄이는 것이다.

15.2.7 큰 변화에 대한 태도

때로는 점진적 변경이 아닌 근본적 변화가 온다.

견해: 큰 변화가 예고되면 조기에 실험하되 성급히 채택하지 말라. 새 방식이 성숙하기까지 시간이 걸리고, 초기 채택자는 문제를 다 겪는다. 실험 환경에서 평가하고, 운영은 안정된 뒤에 옮기는 것이 대체로 옳다.

견해: "기존 방식이 언제까지 지원되는가"를 확인하라. 새 방식이 나와도 기존 것이 오래 지원되면 급할 것이 없다. 폐기 일정이 있는지가 판단의 핵심이다.

정직: 어떤 변화가 올지는 이 책이 예측하지 않는다. 3.10에서 zenoh를, 10.5에서 시뮬레이터 현황을 다루며 같은 태도를 취했다 — 현재 상태를 확인하고, 자신의 요구로 판단하라는 것이 이 책이 줄 수 있는 조언이다.

견해: "이미 공식 조직 안에 들어왔는가"가 큰 변화의 성숙도를 가늠하는 실질적 신호다. 예를 들어 rmw_zenoh(3.10.10)는 확인 시점 기준 ROS PMC가 관리하는 저장소 목록(ros2/rmw_zenoh)에 정식으로 등재돼 있다(15.5.3의 저장소 목록) — 개인 실험 포크가 아니라 프로젝트가 공식적으로 수용한 대안이라는 뜻이다. 관리 저장소 목록에 있는가, discourse에서만 논의 중인가를 구분하면 "지켜볼 것"과 "곧 써도 될 것"을 가를 수 있다.

15.2.8 조직 차원의 준비

견해: 이행을 "예정된 작업"으로 만드는 것이 핵심이다. 예정에 없으면 항상 급한 일에 우선순위를 내주고, 결국 위기가 되어서야 한다. 연간 계획에 넣으면 자원이 배분된다.

견해: "변화 추적 담당"을 정하는 것이 작은 팀에서도 효과적이다. 한 사람이 월 한 시간씩 릴리스 노트와 REP를 검토하고 팀에 공유하면, 놀랄 일이 크게 준다. 비용이 매우 작은 데 비해 효과가 크다.

15.2.9 함정 카탈로그

15.2.10 체크포인트

• 배포판 종류 셋과 각각의 성격은?
• "LTS만 쓴다"가 제품 개발에 맞는 이유는?
• OS 페어링이 이행 일정에 미치는 영향은?
• Rolling의 다섯 성격과, 운영에 쓰면 안 되는 이유는?
• Rolling CI를 비차단으로 두라는 조언의 근거 둘은?
• Rolling에서 깨진 것을 언제 고쳐야 하고 언제 미뤄도 되는가?
• 변화 추적의 여섯 대상과, REP를 보는 것의 가치는?
• 추적 범위를 좁히는 방법은?
• 미래 대비 코드의 여덟 성질과, "ROS 계층을 얇게"가 네 번째 이유를 얻는 맥락은?
• 내부 API를 피하라는 조언과 그 대안은?
• 버전 전략 네 가지와, 권장안·비권장안의 근거는?
• LTS 건너뛰기가 왜 위험이 비선형으로 느는가.
• 이행 전략을 문서화하라는 조언의 근거는?
• 큰 변화에 대한 태도와, 판단의 핵심 질문은?
• 조직 차원의 준비 여섯 가지와, "변화 추적 담당"의 효과는?
• REP 2000이 정의하는 릴리스 주기·LTS/비LTS 지원 기간의 정확한 숫자는?
• Kilted Kaiju가 Jazzy보다 훨씬 먼저 EOL을 맞는 이유는?
• REP의 세 종류와, 이 책이 인용하는 REP들이 대개 어느 종류인가?
• 큰 변화의 성숙도를 가늠하는 실질적 신호는 무엇인가?

다음 장 15.3는 다른 방향의 이행 — ROS 1과의 상호운용을 다룬다.