ROS 2 Jazzy 대전(大全)

이 책은 무엇인가

ROS 2 Jazzy Jalisco를 원리 수준에서 파고드는 심화 종합서다. ros2 run 한 줄이 rclcpp → rcl → rmw → DDS → RTPS 패킷까지 어떻게 내려가는지, 어디서 지연·유실·데드락이 생기는지, 그리고 그 위에 실제 로봇 시스템(제어·인지·항법·매니퓰레이션·시뮬레이션·운영·보안)을 어떻게 설계·배포·디버깅하는지까지 한 권에서 연결해 설명한다.

기준 배포판은 Jazzy Jalisco — 2024년 5월 릴리스, LTS, 2029년 5월 EOL, Tier 1 플랫폼 Ubuntu 24.04 Noble, 기본 RMW rmw_fastrtps_cpp. 자세한 정의·독자·범위는 BOOK.md.

읽는 법

• 순서대로 읽는 경우 — 제0부(개관) → 제1부(그래프 코어) → 제2부(실행 모델) → 제3부(미들웨어)까지가 이 책의 뼈대다. 여기까지 읽으면 나머지 부는 어느 순서로 읽어도 된다. 제4부 이후는 응용·운영 영역이라 필요에 따라 골라 읽는다.
• 문제부터 들어오는 경우 — "토픽이 끊긴다"면 1.5·1.6(QoS)과 3.3(디스커버리), "콜백이 실행되지 않는다"면 2.2~2.4(executor·콜백 그룹), "느리다"면 11.7·12.4·12.6(측정·지연 예산·안티패턴), "실기에서만 안 된다"면 3.9(네트워크)·10.6(Sim2Real)·11.1(디버깅 플레이북).
• 검증된 사실로 진입 — 목차 6(주제별 실측 색인) 에서 "무엇이 Jazzy 실물로 확인됐나"를 주제별로 찾을 수 있다. 재현 방법은 11.7.13.
• 역할별 진입 — 부록 A.6(역할별 학습 로드맵)에서 아홉 트랙의 최단 경로를 제시한다: 입문자·제어/하드웨어·인지/센서·항법·매니퓰레이션·시스템 아키텍트·DevOps·ROS 2 위에 만드는 개발자(미들웨어·드라이버·프레임워크)·연구실/대학원생(연구 코드를 시스템으로).
• 용어·명령이 막히면 — 부록 A.1(CLI 레퍼런스), A.2(QoS·환경변수), A.4(용어집·약어).
• 각 장은 첫 절에서 배우는 것·선수 지식을, 마지막에 체크포인트를 둔다. 다른 장 참조는 RJ-NN 또는 RJ-NN-MM 단독 표기.

정직성 고지 — 이 책의 코드·명령은 어디까지 믿을 수 있나

이 책은 ROS 2가 설치되지 않은 환경에서, 공식 문서(docs.ros.org)·REP·소스 저장소를 근거로 집필되었다. 즉 대부분의 서술은 실행으로 검증된 것이 아니다.

다만 2026-08-14부터 23까지 178차례(누적, 아래 표)에 걸쳐 이 책의 서술을 점검했다. 이 178차례가 전부 "컨테이너를 기동해 확인"한 것은 아니다 — 164차례("N차 검증")는 실제로 컨테이너를 실행·측정까지 했고, 나머지 14차례("N차 점검"·"N차 정리")는 컨테이너 실행 없이 목차·본문·카탈로그를 대조하거나 기존 실측을 정리했다. 구분 규칙은 표 아래(104차가 확정)를 따른다. 확인된 범위는 다음과 같다 — 이만큼만 점검되었고, 나머지는 아니다.

확인하지 않은 것이 훨씬 많다 — 성능·지연 특성, Nav2·MoveIt 2·ros2_control·Gazebo의 동작과 파라미터, 벤더별 RMW 거동, 실기 통합, 그리고 코어 API 중에서도 위 목록 밖의 것들. 다음 원칙으로 읽기 바란다.

번호 체계가 둘이라는 것(72차가 발견) — 94차에 병기로 해소. 이 표의 "N차"는 CHANGES.md의 CHG 항목 제목("갭 점검 N차")과 같은 수가 아니다 — 두 카운터가 원래부터 서로 다른 것을 세고 있어 하나로 합칠 수 없다. 94차에 위 표의 71개 행 전부에 실제 CHG 번호를 병기했다 — 각 행의 **N차 검증(날짜 · CHG-NNN)**에서 CHG-NNN을 그대로 CHANGES.md에서 찾으면 된다. 병기는 RJ 참조 번호·특징적 수치(예: "41개 절"·"54.7%")로 각 행을 해당 CHG 본문과 대조해 확정했으며, 96개 CHG(CHG-21~116) 중 정확히 72개가 표에 매칭되고 나머지 24개(CHG-24·30·31·36~39·46·52~66·76)는 표에 오르지 않은 회차임을 확인했다 — 72(표) + 24(표 밖) = 96(CHG-21~116) 산수가 정확히 맞는다.

이 표의 "N차"가 정확히 무엇을 세는가(102~104차 세 회차 이월 끝에 104차가 확정). 위 문단이 처음 썼던 설명("N차는 실행·실측을 동반한 회차만 센다")은 부정확했다 — 위 표를 다시 보면 79·81·82차처럼 "점검"이라는 낱말이 붙고 본문에 "새 실측 없이"라고 스스로 적은 행이 이미 여러 개 있다(104차 기준 9개 "점검" + 3개 "정리" = 12개, 나머지 71개가 "검증"). 즉 표는 처음부터 "실행 검증"과 "실행 없는 점검·정리"를 같은 번호열에 함께 세고 있었고, 그 구분은 각 행 제목의 낱말(검증/점검/정리)에만 있었을 뿐 문서 어디에도 규칙으로 적힌 적이 없었다. 104차가 이것을 세 갈래로 공식화한다:

유형	낱말	뜻	표에 행이 생기나	현재 행 수
실행 검증	"N차 검증"	컨테이너를 실제로 기동해 뭔가를 실행·측정·컴파일했다	그렇다	72
커버리지·깊이 점검	"N차 점검"	컨테이너 실행 없이 목차·본문·함정 카탈로그를 대조했다(book-gap의 커버리지·일관성 갭 점검)	그렇다	9
정리	"N차 정리"	컨테이너 실행 없이 이미 확정된 실측 결과를 재배열·색인·도구화했다(새 사실 확정은 없음)	그렇다	3
장 보강형	(번호 없음)	book-gap이 아니라 book 스킬 성격 — 장의 골격은 그대로 둔 채 절 안의 산문·예시·코드를 채운다(최초 사례 CHG-127)	아니다	0

"검증"·"점검"·"정리" 셋은 모두 같은 N차 번호열을 공유한다 — "N차"는 "실행 여부"가 아니라 "이 회차가 표 한 행으로 요약할 수 있는, 책의 서술을 갱신한 회차인가"를 센다(실행이 그 조건 중 하나일 뿐, 전부는 아니다). 반대로 "장 보강형"은 번호를 받지 않는다 — 표의 각 행은 "한 회차 = 한 주제의 대조·실측 결과 한 뭉치" 형식인데, 장 보강형은 여러 장을 전면 개정하는 성격이라 이 형식에 맞지 않기 때문이다(CHG-127-03이 처음 내린 판단을 104차가 일반 규칙으로 승격했다). 장 보강형 회차는 CHANGES.md에 CHG 번호로 기록하고 목차 3.1에 산문으로 요약한다 — 그 회차 중 부수적으로 컨테이너 실행이 있었던 부분(CHG-127의 rmw.h·ros1_bridge 확인처럼)은 "실행 확인 장 수" 집계에는 반영되지만 N차 순번에는 포함되지 않는다. "회차 순번(N차)"과 "실행 확인 장 수"는 서로 다른 두 집계라는 뜻이다. 이 규칙에 따라 CHG-127은 82차 다음 번호를 받지 않았고, 실제 컴파일 검증을 한 이번 104차(CHG-128)가 83차 자리를 채운다 — BOOK.md BK-03이 한때 CHG-127을 "83번째 회차"라 부르던 것은 이 규칙이 확정되기 전의 표현이었다(104차가 정정).

2차 검증이 말해 주는 것. 실행해 보니 환경변수 3종이 실존하지 않았고, ros2 topic echo에 관한 서술은 Jazzy에서 이미 틀린 이야기였다. 둘 다 "공식 문서 기준으로는 맞았던" 서술이 배포판을 거치며 어긋난 경우다. 미검증 영역에도 같은 밀도의 오류가 남아 있다고 보는 편이 안전하다 — 특히 생태계 패키지(Nav2·MoveIt 2·Gazebo) 장들은 실행 검증이 전혀 없다.

3차 검증이 말해 주는 것 — 오류보다 누락이 문제다. 3차(2026-08-16)는 틀린 서술을 찾는 대신 "이 책이 완전히 누락한 것" 을 찾았고, 실제로 다섯 가지가 나왔다(위 표). 그중 셋은 책 스스로 "저 장에서 다룬다"고 적어 놓고 다루지 않은 것이었다. 동시에 참조 오지정 75건을 고쳤다 — 대부분 파라미터를 1.7(서비스)로, 액션을 1.9(파라미터)으로, 디스커버리를 1.5(QoS)로 가리키던 같은 원인의 혼동이며, ID가 실재하므로 링크 검사로는 검출되지 않는 종류다. 이 두 가지 — 누락과 오지정 — 는 정오표로 드러나지 않으므로, 독자가 어떤 절을 근거로 삼기 전에 그 절이 실제로 그 주제를 다루는지 확인하기를 권한다.

• 원리·아키텍처 서술 — 문서·소스에 근거하며 배포판이 바뀌어도 대체로 유효하다.
• API 시그니처·기본값 — Jazzy 시점 기준. 패치 릴리스로 바뀔 수 있어 흔들릴 만한 곳은 (확인 필요)를 붙였다.
• 성능 수치 — 하드웨어·커널·네트워크·DDS 설정에 따라 자릿수가 바뀐다. 이 책은 측정 방법과 지배 요인을 가르치며, 절대 수치는 조건과 함께 예시로만 쓴다.
• 생태계 패키지(Nav2·MoveIt 2·ros2_control·Gazebo) — 별도 릴리스 주기를 갖는다. 아키텍처·판단 기준까지 다루고, 파라미터 전수는 각 프로젝트 문서를 가리킨다.

장별 검증 상태 — 지금 읽는 장이 확인됐는지 보는 법

위 표는 회차별 기록이라 "19차에 무엇을 했나"는 알려 주지만 "내가 지금 펼친 장이 검증됐나"는 알기 어렵다. 그 질문에 답하는 요약을 둔다(2026-08-16 기준).

가장 확실한 방법은 장을 펼쳐 보는 것이다. 두 가지 표기가 그 장의 상태를 말한다:

검증이 특히 두꺼운 장(실행 확인 표기 수 기준):

(확인 필요)가 621건 남아 있다는 사실을 감추지 않는다. 그리고 이 수는 검증이 진행되며 단조롭게 줄지 않았다 — 2026-08-16에 570건이던 것이 66차 점검 시점(618건, 목차 3.1 위 표)까지 늘었다가, 이후 회차에서 여러 건을 해소하며 614건(94·95·96차)·613건(97차)·615건(98차)에 이르렀고, 99차는 커널 타임스탬프로 미확인 하나("도착 순서 대 executor 우선순위")를 닫으면서도 새 미확인("초기 7~12회가 왜 안전한가", "97·98차가 갈린 이유의 나머지", "rclpy의 EventsExecutor가 다른 실험에서도 같은가")을 여럿 남겨 순증했다(자동 재계산 기준 — 아래 설명 참조). 본문(1.8.13)에서는 97차(CHG-120)가 추론으로 남긴 "패킷 재정렬" 가설을 98차가 tcpdump·tshark로 실측 확정했고, 99차는 로컬 warm 손실이 네트워크 도착 순서와 무관함(커널 타임스탬프로 확정)과 rclpy가 이 손실 계열 전체에 면역임(240회 + 소스)을 새로 확정했다 — 그런데도 총량은 줄지 않았다. 97·98·99차를 이으면 이 실험 계열에서만 하네스 관련 의심 또는 재확인이 네 차례(CHG-120-05 두 건 + 98차 정정 + 99차의 병렬 컨테이너 부수 관측) 나온 셈이며, "놀라운 결과는 측정 장치부터 의심하라"는 이 책의 원칙이 실측 축 자체에도 반복 적용돼야 함을 보여 준다. tools/book_check.py의 자동 집계는 본문의 남아 있는 미확인 표기와 이 역사 서술을 구분하지 않고 문자열 그대로 센다. 숫자를 예쁘게 만들려고 서술을 바꾸지 않고, 도구가 실제로 세는 값을 그대로 적는다. 모순이 아니라 구조다: 한 항목을 확인하면 그 옆의 미확인이 드러나기 때문이다. 예컨대 타이머 지터를 측정하고 나니 "RT 커널에서는 어떤가"가 새로 생겼고(2.5.13.5), Fast DDS의 XML을 확인하니 "전송·메모리 정책은 어떻게 확인하나"가 남았다(3.7.12.4). 각 실측 절 끝의 "확인하지 못한 것"이 그 출처이며, 그것을 적지 않는 편이 숫자는 예뻐도 정직하지 않다. 그중 상당수는 없애면 안 되는 것이다 — 조직 관행·판단, 성능 수치(이 책은 절대 수치를 제시하지 않는다 — 3.6.1), 하드웨어·커널이 있어야만 확인되는 것이 그렇다.

100차(CHG-123)는 새 실측을 하지 않고, 93~99차가 남긴 실측을 대조만 했는데도 총량은 소폭 늘었다(위 표의 값). 신규 컨테이너 실험이 없었으니 실측 결과가 새로 바뀐 것은 없다. 늘어난 몇 건은 이번 회차가 이 문서(목차 3)에 스스로 남긴 서술 안에 있다 — 위 표의 새 행과 이 문단이 "무엇이 낡았고 무엇을 고쳤는지"를 설명하며 (확인 필요)라는 문자열 자체를 몇 차례 인용했고, tools/book_check.py는 그 인용도 남아 있는 미확인 표기와 구분하지 않고 그대로 센다. 본문의 낡은 서술 세 곳(12.5.4·2.2.9·2.3.6)을 고친 것은 이 증가와 무관하다 — 그 세 곳은 이미 몇 회차 전에 실측으로 닫힌 사실을 반영하지 않은 채 "확인 안 함"으로만 적혀 있던 것이라, 고쳐도 각 자리의 (확인 필요) 태그 자체는 하나씩 그대로 남겨 두었으므로 개수에는 영향이 없다 — 개수는 그대로인데 내용이 실측과 어긋나 있었을 뿐이었다. 정리하면 이번 회차의 증가는 지금까지 반복 관찰된 "확인하면 옆의 미확인이 드러난다"는 패턴과는 다른, 더 사소하지만 같은 원인의 사례다 — 자동 집계는 뜻이 아니라 문자열을 센다는 것을 이 문단 자신이 실시간으로 증명한다.

101차(CHG-124)는 새 실험을 했는데도(675 트라이얼) 순수하게 새로 연 (확인 필요)는 1건뿐이다(621→627 중 나머지 5건은 이 문서 자신의 서술이 그 문자열을 인용한 결과 — 100차가 CHG-123-05에서 이미 설명한 패턴과 같은 원인이다) — 실험 대부분이 "무엇을 확정했다"가 아니라 "78차의 관찰이 재현되지 않았다"로 끝났기 때문이다. CPU 주파수·/proc 스케줄링 정보로 "초기 무사 구간의 원인"을 좁히려 했으나 답을 얻지 못했고, 대신 그 구간 자체가 오늘은(같은 하네스·같은 방법으로) 재현되지 않는다는 것을 45회 반복으로 보였다 — 새로 연 (확인 필요)는 "78차와 오늘의 유일한 확인된 차이인 호스트 부하가 원인인지" 하나뿐이다(1.8.13). 부차적으로 CHG-122(99차)가 견해로만 남겨 뒀던 C++/Python 열 번째 비대칭 축(2.8.12.11, rclpy의 액션 피드백 면역)을 정식 절로 승격했는데, 이것은 이미 확정돼 있던 수치를 옮긴 것이라 (확인 필요)에 영향이 없다.

102차(CHG-125)는 커버리지·깊이 갭 점검이라 실측을 하지 않았고, (확인 필요) 627건도 그대로다. 다만 이번 회차 자신이 수동으로 grep을 여러 방식으로 시도하며 599건·572건·521건 등 627과 다른 값을 여럿 얻었다 — 원인은 집계 스크립트가 tools/book_check.py의 re.findall(r'\(확인 필요', s)를 목차-목차.md 자신을 포함한 전체 134개 파일에 실행하는 반면(목차 자신의 회차별 서술이 그 문자열을 여러 차례 인용하므로 55건이 여기서 나온다), 수작업 점검은 통상 "장 본문만" 세려고 목차-목차.md를 빼거나 정규식을 약간 바꾸기 때문이다. tools/book_check.py의 정확한 정규식으로 다시 실행하자 627로 정확히 일치했다 — 수치 자체는 정확했고, 집계 방식의 차이가 혼동을 낳을 뻔한 사례로 남긴다.

103차(CHG-126)도 순수 문서 점검이라 실측을 하지 않았고, (확인 필요) 627건·실행 확인 86장 모두 그대로다. 102차가 지목한 다음 회차 제안 ①(나머지 11개 부 헤더 대조)과 ②(pitfall_scan.py 잔여 64쌍 재검토)를 이어받아 처리했다 — 새 실측 없이 목차·본문 대조와 함정 카탈로그 재독만으로 진행했으므로 (확인 필요) 카운트에 영향이 없다(정확히 82차 표 행과 함께 tools/book_check.py로 재확인).

실행 확인 86장 → 88장(2026-08-19, CHG-127) — 102차가 사용자 결정 대기로 남긴 제15부 보강. 81차(CHG-125)가 발견하고 보류한 "제15부 다섯 장이 산문·예시가 얕다"는 항목을 이번에 보강했다(15.1~15.5). 이 작업은 위 표에 새 번호("N차 검증/점검")로 집계하지 않았다 — 다섯 장 전체를 고쳐 쓰는 보강이라 위 표의 한 행으로 요약하기 어렵고, 각 장이 무엇을 얻었는지는 CHANGES.md의 CHG-127이 장별로 적는다. 다만 그 과정에서 ros:jazzy-ros-base 컨테이너에 실제로 들어가 /opt/ros/jazzy/include/rmw/rmw/rmw.h를 읽어 공개 함수 71개·헤더 45개를 세고(15.4.6), apt-cache search ros1-bridge가 빈 결과를 낸다는 것을 실행해 확인했다(15.3.1·15.3.3) — 둘 다 이 책의 실행 검증 관례(목차 3)를 그대로 따른 것이라 해당 두 장에 실행 확인 표기가 새로 생겼다. tools/book_check.py가 이 불일치(86 vs 실제 88)를 자동으로 검출해 이 문단과 위 요약 표·BOOK.md BK-03을 함께 정정했다. 이 회차는 CHG-127의 방식 자체가 옳았음을 사후에 보여 준 사례이기도 하다 — "장 보강형은 표에 행을 안 만든다"는 판단을 104차가 위 범례로 공식화했다.

실행 확인 88장 → 89장 + (확인 필요) 627 → 640건(2026-08-19, CHG-128, 104차) — 15.1의 API diff 5건을 실제로 컴파일. 82차(CHG-126)와 CHG-127이 각각 남긴 "15.1을 실제로 컴파일해 재현 검증하라"는 제안을 실행했다. ros:jazzy-ros-base(ros-jazzy-rclcpp 28.1.21)에서 다섯 항목을 각각 최소 재현 코드로 컴파일한 결과 — 넷은 릴리스 노트와 일치(tf2_*.h→.hpp, qos_event.hpp 제거, get_typesupport_handle 폐기 경고, ros2 bag record --exclude→--exclude-regex), 하나는 릴리스 노트와 실물이 어긋남(비-const shared_ptr<MessageT> 구독 콜백이 "Jazzy에서 완전히 제거"라는 문서와 달리 실제로는 경고 없이 컴파일됨 — 원인은 헤더에 남은 템플릿 특수화로 소스 수준까지 확인했으나, "왜 릴리스 노트와 어긋나는지"는 미확정으로 남겼다). 15.1을 정정했고, 15.1에 실행 확인 표기가 새로 생겨 88 → 89장이 됐다. (확인 필요)는 627 → 640건으로 늘었는데, 두 겹의 이유가 섞여 있다. ① 15.1 본문 편집으로 633건이 됐다 — 새로 연 미확인("정확한 원인" 1건)과 기존 태그를 더 구체적으로 다시 쓰며 생긴 변화가 섞여 있어(예: 일반형 (확인 필요) 하나를 (확인 필요: gz_math_vendor 빌드)로 구체화) 정확한 순증감의 원인별 내역은 세지 않았다(확인 필요: 정확한 집계). ② 그 뒤 이 문서(목차 3) 자신이 위 범례·이 문단에서 이 미확인 표기 문자열 자체를 여러 차례 인용하며 633 → 640건으로 더 늘었다 — 100차(CHG-123)가 처음 짚은 "확인하면 옆의 미확인이 드러난다"·"자동 집계는 문자열을 그대로 센다"는 패턴이 이번에도 실시간으로 재현된 것이다. 이 두 번째 증가는 책의 실제 서술이 미확인해진 것이 아니라 이 요약 문서가 스스로를 설명하는 과정에서 생긴 자기지시적 증가이므로, tools/book_check.py가 실제로 세는 값을 그대로 적었다(예쁘게 보이려고 숫자를 다듬지 않았다 — 이 문단을 쓰는 동안에도 값이 한 번 더 움직였을 수 있다는 것 자체가 이 현상의 증거다). 부수적으로 이 회차가 목차 3의 "N차" 카운터 정의를 확정했다 — 위 범례("검증·점검·정리·장 보강형") 참고. tools/book_check.py 23종은 편집 전 ⑳ 2건(88 vs 89 불일치) → 편집 후 0건.

실행 확인 89장 유지, (확인 필요) 640건 유지(순증감 0으로 측정, 2026-08-19, CHG-129, 105차) — 15.1의 원인 해소와 2.8의 신규 미확인이 상쇄됐다. 이번 회차가 15.1에서 "정확한 원인" 미확인 1건을 실제로 해소(원인을 ros2/rclcpp·ros2_documentation 커밋 이력으로 확정)했고, 동시에 2.8.12.12(신설)에서 rclpy EventsExecutor 크래시·바인딩 순서의 미확인 2건을 새로 열었다 — 편집 단위로는 -1, +2 = 순증 +1이 산수상 맞다. 그런데 tools/book_check.py로 편집 전후를 각각 측정해 보니 둘 다 640건으로 나왔다 — 즉 이번 회차 편집 전(세션 시작 시점)의 실제 값이 이미 640이 아니라 639였을 가능성이 있다(104차가 문서에 적어 둔 "640"과 1건 어긋난다). 정확한 지점(104차가 640을 잘못 셌는지, 그 뒤 이 문서 자신의 다른 자기지시적 인용이 이미 한 번 더 움직였는지)은 추적하지 않았다 — 100차(CHG-123) 이후 반복 관찰된 "자동 집계는 문자열을 그대로 세고, 이 요약 문서 자신도 그 문자열을 인용해 스스로를 움직인다"는 패턴과 같은 원인으로 보고, tools/book_check.py가 실제로 세는 현재값(640)을 그대로 적는다. 이번 회차가 만든 것은 목차 4.3(제2부 소개, 누락 4개 장 보강)·15.1(원인 확정)·2.8.12.12(신설, C++/Python 열한 번째 축)·2.10.11.3(교차참조 1문단)이고, 새 실험 하네스는 tools/gap_harness/gap105/에 남겼다. tools/book_check.py 23종은 편집 전후 모두 0건.

(확인 필요) 카운터를 직접 세어 실제 값으로 통일했다(2026-08-19, CHG-130, 106차) — 639 대 640 불일치는 정확한 지점을 못 찾은 채 넘어간다. 105차가 "편집 전후 둘 다 640으로 나왔는데 세션 시작 시점의 실제값이 이미 639였을 수도 있다"고만 적고 추적하지 않은 것을 이어받아, 106차가 이 문단을 쓰기 전 시점에 tools/book_check.py와 동일한 방식(전체 134개 파일에서 여는 괄호 뒤 "확인 필요"로 시작하는 문자열 수)으로 다시 세니 643건이었다 — 104·105차가 문서에 적어 둔 "640"과도, 105차가 추정한 "639"와도 다르다. 정확히 어디서 얼마나 어긋났는지는 이번에도 추적하지 못했다(639→640→643 사이 몇 건이 106차 이전의 다른 편집에서 조용히 늘었는지, 애초에 104차의 "640" 자체가 부정확했는지 — 100차 이후 반복 확인된 자기지시적 잡음과 같은 성격으로 보인다)(확인 필요). 매 회차 정확한 델타를 재구성하기보다 tools/book_check.py로 그때그때 실측하는 것이 유일하게 신뢰할 수 있는 방법이라는 결론에 106차도 도달했다. 이 문단·아래 요약 표를 쓰는 동안 106차 자신의 편집(새 행·새 문단)이 카운터를 다시 움직였으므로, 아래 표의 최종 수치는 이번 CHG-130 편집이 전부 끝난 뒤 tools/book_check.py로 마지막에 한 번 더 측정한 값이다 — 이 문단에 적은 "643"은 그 편집 이전의 중간값이며 최종값과 다를 수 있다.

107차(CHG-131)도 같은 방법을 그대로 썼다. 2.8.12.14(신설)·이 표의 86차 행·2.8.12/2.10.11 색인 갱신을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 한 번 더 세니 652건이었다 — 106차가 최종적으로 남긴 값(이 표에는 "649"로 적혀 있었다)보다 3건 늘었는데, 이번 회차가 새로 연 미확인(타이머·클라이언트 미실험 1건, py::set 순서가 여전히 완전히 균등하다고 증명하지는 못했다는 것 1건)과 (확인 필요)라는 문자열 자체를 인용하는 이 문단들이 스스로를 얼마나 움직였는지가 뒤섞여 있어 정확한 델타 분해는 이번에도 하지 않았다 — 100차 이후 반복 확인된 자기지시적 잡음과 같은 성격으로 본다. tools/book_check.py의 ⑳ 검사(허용 오차 15건)는 이번에도 통과했다.

108차(CHG-132)는 새 미확인을 여는 대신 오래된 미확인 하나를 닫았다 — 15.1.3의 (확인 필요: 직접 재현)(104차부터 이월)를 실제 재현으로 해소했다. 대신 이번 실험 자체가 연 새 미확인(타이머·서비스·클라이언트·waitable의 같은-타입 순서 미실험, MultiThreadedExecutor 미실험, 6.7% 이탈의 ASLR 여부 미확인 — 이 도커 환경이 personality()를 막아 시도조차 못함)이 최소 3건이라 순증가할 것으로 예상했지만, tools/book_check.py와 동일한 방식으로 이 문단·표 편집을 전부 마친 뒤 마지막에 측정하니 657건으로 107차의 652건보다 5건 늘었다 — 대략 예상과 부합한다(하나를 닫고 몇을 새로 열면 순증한다는 통상 패턴). 이번 회차도 정확한 델타 분해(닫은 1건·새로 연 3~4건·이 문서 자신의 자기지시적 인용이 얼마나 움직였는지)는 하지 않았다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다.

109차(CHG-133)는 108차가 연 미확인 두 건(타이머·서비스·클라이언트·waitable의 같은-타입 순서, MultiThreadedExecutor에서의 재현)을 닫으면서, 동시에 새 미확인도 열었다 — 서비스·클라이언트의 높은 이탈률 중 해시 순서분과 DDS 왕복 타이밍 잡음분을 분리하지 못한 것, MultiThreadedExecutor 실험을 구독·스레드 2·4개로만 한정한 것 두 가지다. tools/book_check.py와 동일한 방식으로 이 문단·표·2.3.14·15.1.3·2.2.7 편집을 전부 마친 뒤 마지막에 측정하니 659건으로 108차의 657건보다 2건 늘었다 — 대략 예상과 부합한다(두 건을 닫고 두 건을 새로 열면 상쇄에 가까울 것으로 예상했는데, 그 자체는 대체로 맞았다). 이번 회차도 정확한 델타 분해(닫은 2건·새로 연 2건·이 문서 자신의 자기지시적 인용이 얼마나 움직였는지)는 하지 않았다 — 100차 이후 반복 관찰된 패턴과 같은 원인으로 본다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다.

110차(CHG-134)는 107차부터 세 회차째 이월됐던 미확인 하나(타이머·클라이언트 미실험)를 실측으로 닫으면서, 동시에 새 미확인 하나를 열었다(py::set 순서가 212회로도 완전한 균등분포임을 증명하지는 못했다는 것 — 62회 표본 때도 이미 있던 것과 같은 종류의 미확인이라 사실상 이월에 가깝다). 편집을 전부 마친 뒤 같은 방식으로 측정하니 659건으로 109차와 정확히 같았다 — 하나를 닫고 하나를 열어 순증감이 0이 되는, 이 표가 처음 보인 우연한 상쇄 사례다. 부수적으로 이 절 자체의 서두("87차례")가 88차(CHG-133) 행 추가 때 갱신되지 않아 한 회차만큼 뒤처져 있던 것을 발견해, 이번 회차 자신의 행 추가와 함께 "89차례"로 바로잡았다(목차 3 서두). tools/book_check.py의 ⑳ 검사는 이번에도 통과했다.

111차(CHG-135)는 89차(CHG-134)가 이월했던 미확인 하나("타이머 세그폴트의 정확한 메모리 재사용 타이밍")를 ASan·valgrind 추적으로 닫으면서, 동시에 새 미확인 두 건을 열었다 — ASan에서 관찰된 크래시 주소가 실행마다 18바이트씩 증가하는 정확한 이유, glibc tcache가 이 작은 블록을 재사용해 85%/15% 비율을 만든다는 설명이 추론일 뿐 직접 계측하지 않았다는 것이다. 편집(2.8.12.15 확장, 이 표의 90차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 664건으로 89차의 659건보다 5건 늘었다 — 하나를 닫고 둘을 열면서, 이 문단·표 자신이 그 미확인 태그 문자열을 인용하는 자기지시적 증가도 섞였다(100차 이후 반복 관찰된 패턴과 같은 원인). 정확한 델타 분해(닫은 1건·새로 연 2건·자기지시적 증가분)는 이번에도 하지 않았다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다.

112차(CHG-136)는 CHG-133이 세 회차째(CHG-133→134→135) 이월했던 세 항목(도착-대-디스패치 분리, MultiThreadedExecutor 확장, 통계 검정)을 전부 닫으면서 새 미확인도 열었다 — Humble의 set_on_new_request_callback이 서비스에서 종종 콜백을 두 번 반복 호출하는 원인 미상, 타이머의 스레드 수에 대한 비단조 패턴 미해석 두 가지다(ASLR 관련 미확인은 108차부터 이어지는 기존 항목이라 새로 연 것으로 세지 않았다). 편집(2.3.14 확장, 15.1.3·2.2.7·2.10.11.3 정직 문단, 이 표의 91차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 667건으로 90차의 664건보다 3건 늘었다 — 세 항목을 닫고 둘을 새로 연 것치고는 순증이 작은데, 이는 세 항목 중 둘(②③)이 "미확인을 닫는다"기보다 기존에 이미 표본이 작다고 명시했던 관측을 큰 표본으로 확정하는 성격이라 애초에 미확인 표기를 달고 있지 않았기 때문이다(①만 명시적 표기가 달려 있었다). 정확한 델타 분해는 이번에도 하지 않았다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음 — 이미 실행 확인 표기가 있던 장만 편집).

113차(CHG-137)는 112차가 남긴 세 제안을 전부 처리했는데, 그중 둘(②③)은 미확인을 닫는 대신 기존 소표본 관측을 뒤집는 성격이었다 — 타이머의 스레드 수 비단조 패턴, 타이머·서비스의 Jazzy·Humble 통계 검정 "잠정적" 판단 모두 큰 표본(각 50~60회)으로 측정해 보니 근거가 사라지거나(비단조 패턴) 유의성이 없다고 확정됐다(타이머·서비스 통계). 새로 연 미확인은 ①(Humble 서비스 콜백 이중 호출)뿐이다 — 원인 후보(rclcpp의 2단계 등록 패턴)를 소스로 찾았지만 타이밍이 맞지 않아 배제했고, 66회의 재현 시도도 전부 실패해 미확인 자체는 닫지 못한 채 원인 후보 하나만 배제한 상태로 남았다. 편집(2.3.14 확장, 15.1.3·2.2.7 정직 문단, 이 표의 92차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 672건으로 91차의 667건보다 5건 늘었다 — 미확인을 새로 연 것은 사실상 하나뿐인데 순증이 5인 것은, 이 문단·표 자신이 여러 차례 그 표기 문자열을 인용하는 자기지시적 증가가 대부분을 차지하는 것으로 보인다(100차 이후 반복 관찰된 패턴과 같은 원인, 정확한 델타 분해는 이번에도 하지 않았다). tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음).

114차(CHG-138)는 113차가 남긴 세 제안을 전부 처리했고, 그중 둘(①③)이 이전 판단을 뒤집었다 — 서비스 통계 검정은 "유의하지 않다"(113차, $p=0.072$)에서 "유의하다"(114차, $p=1.87\times10^{-4}$)로, py::set 균등성은 "기각하지 못한다"(106~110차 내내)에서 "기각한다"(114차, $p=0.0248$)로 바뀌었다 — 둘 다 표본을 충분히 늘리자 이전 회차들의 소표본 판단이 유효하지 않았음이 드러난 사례다. Humble 이중 호출(②)은 새 조건(엔티티 선행 실행)을 시도했지만 111회째도 재현되지 않아 미확인 자체는 닫히지 않았다. 편집(2.3.14 확장, 15.1.3·2.2.7·2.8.12.15 정직 문단, 이 표의 93차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 675건으로 92차의 672건보다 3건 늘었다 — 정확한 델타 분해는 이번에도 하지 않았다(100차 이후 반복 관찰된 자기지시적 증가와 같은 원인으로 본다). tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음).

115차(CHG-139)는 114차가 남긴 세 제안을 전부 처리했다 — ①은 세 번째로 같은 패턴(소표본 "유의하지 않다"가 표본 확대로 뒤집힘)을 재현했고, ③은 108차부터 여섯 회차 이월된 ASLR 차단을 마침내 풀었다. 타이머 통계 검정을 150회로 늘리니 서비스와 똑같이 뒤집혔다(Jazzy 8.7% 대 Humble 26.7%, $p=4.36\times10^{-5}$). docker run --privileged가 이 환경의 personality() 차단을 실제로 풀어 준다는 것을 확인해 ASLR을 껐다 — 껐어도 이탈률이 0%가 되지 않아(30.0%) "ASLR이 유일한 원인"이라는 가설을 반증하는, 미확인을 닫는 방향의 결과를 얻었다. Humble 이중 호출은 재현 대신 환경 포렌식으로 접근해 새 단서(112차 관측 창에만 겹친 무관한 컨테이너 기동)를 찾았지만 인과관계는 증명하지 못해 미확인 자체는 열린 채로 남았다. 편집(2.3.14 확장, 15.1.3·2.2.7 정직 문단, 이 표의 94차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 679건으로 93차의 675건보다 4건 늘었다 — 정확한 델타 분해는 이번에도 하지 않았다(100차 이후 반복 관찰된 자기지시적 증가와 같은 원인으로 본다). tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음).

116차(CHG-140)는 115차가 남긴 항목을 전부 처리했고, 그중 하나(Humble 이중 호출)는 사용자 판단에 따라 미확인을 "열어 둔 채" 마무리하는 대신 재현 불가로 명시적으로 종결했다. ASLR 켬·끔 비교는 150회로도 유의성을 확정하지 못했지만($p=0.082$) 방향은 계속 일관됐다. 할당 순서 비결정성 가설은 핸들 주소를 직접 출력해 처음으로 실증했다 — 최소 시나리오는 완전히 결정적이었지만 실제 디스커버리 매칭을 더하면 ASLR을 꺼도 12.5%는 주소가 달라졌다. Humble 소스 추적은 엔티티 수집 자체(콜백 그룹 하나일 때)가 결정적임을 확인해 Humble의 이탈 원인을 데이터 구조가 아니라 스레드 스케줄링으로 좁혔다 — 미확인 하나(정도 차이의 이유)를 새로 열었다기보다 기존 견해를 소스로 뒷받침한 것에 가깝다. 편집(2.3.14 확장, 15.1.3·2.2.7 정직 문단, 이 표의 95차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 683건으로 94차의 679건보다 4건 늘었다 — 정확한 델타 분해는 이번에도 하지 않았다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음).

117차(CHG-141)는 116차가 남긴 세 항목을 전부 닫는 방향으로 처리했다 — 미확인을 새로 열기보다 기존 것을 닫거나 정리한 회차다. ASLR 켬·끔 비교는 300회로 완결해 "무관하다"로 최종 결론지었다(60→150회의 추세는 착시였다) — 이 절이 오래 들고 있던 미확인 하나가 닫혔다. 주소 변동과 디스패치 이탈률의 관계도 같은 프로세스에서 동시 측정해 완전한 상관을 확인함으로써 닫혔다. CHG-122 계열의 stress-ng 통제 실험은 이 책에서 가장 오래 이월된 갭이었는데, 이번 회차가 실제로 설계·실행해 스레드 경합 가설을 정량 확인하면서 닫혔다 — 다만 그 과정에서 Humble 구독의 무반응이라는 새 관찰(원인 미상)이 하나 열렸다. 편집(2.3.14 확장, 15.1.3·2.2.7 정직 문단, 이 표의 96차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 684건으로 95차의 683건보다 1건 늘었다 — 세 미확인을 닫고 하나를 새로 열었으니 산수로는 순감이 예상됐지만, 이 문단·표 자신의 자기지시적 인용이 상쇄한 것으로 보인다(정확한 델타 분해는 이번에도 하지 않았다). tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음).

118차(CHG-142)는 96차의 유력한 가설(Humble의 매 사이클 재구성 비용) 하나를 실제 계측으로 반증했다 — 가설을 세우는 것과 반증하는 것 둘 다 이 표의 역할이다. 소스 대조·stress-ng 임계값 확정·재구성 비용 계측 셋 다 실행했고, 그중 재구성 비용 계측이 예상과 정반대(Jazzy가 더 비쌈)로 나와 기존 가설을 닫으면서 "그럼 실제 이유는 무엇인가"라는 새 미확인을 열었다. stress-ng를 Humble 서비스·타이머로 확장한 것도 예상과 반대 방향(부하가 이탈률을 낮춤)이라는 새 관찰을 하나 더했다. 편집(2.3.14 확장, 15.1.3·2.2.7 정직 문단, 이 표의 97차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 686건으로 96차의 684건보다 2건 늘었다 — 정확한 델타 분해는 이번에도 하지 않았다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음).

119차(CHG-143)는 이 표 전체에서 가장 중대한 정정 중 하나를 냈다 — 미확인 하나를 닫는 수준이 아니라, 91~98차(gap109~118) 실험 전체의 메커니즘 설명이 틀렸다는 것을 발견했다. MultiThreadedExecutor의 "실제 동시 실행"이라 불러 온 것이 사실은 단 한 번도 일어나지 않았다(모든 테스트 엔티티가 기본 MutuallyExclusive 콜백 그룹에 있어 병렬 실행이 애초에 불가능했다) — 직접 계측(동시성 비율 0.0000, 전 조건 예외 없음)으로 확인했다. 측정된 이탈률 수치 자체는 유효하지만 "스레드 스케줄링 경쟁"이라는 설명은 이 테스트 계열에 적용되지 않는다. 이런 종류의 정정은 이 표가 처음 다루는 것이 아니다(ASLR·재구성 비용 가설도 비슷하게 반증됐다) — 다만 이번은 단일 실험이 아니라 여러 회차에 걸쳐 쌓인 해석의 틀 자체가 대상이라는 점에서 규모가 다르다. 부수적으로 entities_need_rebuild_가 68~70%나 걸리는 이유도 완전히 확정했다(interrupt_guard_condition_ 트리거 경로). 편집(2.3.14 확장, 15.1.3·2.2.7 정직 문단, 이 표의 98차 행, 목차 6 색인)을 전부 마친 뒤 tools/book_check.py와 동일한 방식으로 마지막에 측정하니 687건으로 97차의 686건보다 1건 늘었다 — 정확한 델타 분해는 이번에도 하지 않았다. tools/book_check.py의 ⑳ 검사는 이번에도 통과했다(실행 확인 장 수 89개는 변화 없음). 이 정정이 2.3.14의 91~98차 서술 전체(특히 "실제 동시 실행"·"병렬 실행" 표현이 반복 등장하는 문단들)에 미치는 영향을 전면적으로 재검토·재작성하는 일은 이번 회차에서 시작만 했다 — 다음 회차 이후로 이월한다.

120차(CHG-144)는 두 가지를 했다 — 119차가 남긴 "재구성-대기 연쇄" 가설의 직접 계측, 그리고 위에서 "시작만 했다"고 적은 언어 재검토의 완결이다. 계측 쪽: MultiThreadedExecutor::run()의 wait_mutex_ 락이 wait_for_work()의 블로킹 대기 전체를 감싼다는 것을 소스와 480회 실측(13,397개 구간, 겹침 비율 예외 없이 0.0000) 둘 다로 확정했고, Humble은 이 재구성이 항상(100%) 일어나는 반면 Jazzy는 조건부(45~74%)라는 배포판 차이도 확인했다 — 다만 이 연쇄의 빈도가 이탈률을 결정하는 인과적 손잡이라는 것은 확정하지 못했다(12개 설정 전체 상관 $r=0.96$의 대부분이 엔티티 종류 자체의 교란변수 효과였다, 엔티티를 고정하면 상관이 거의 사라진다). 언어 재검토 쪽: 2.3.14 서두에 "읽기 전에" 정정 고지를 신설하고 가장 상세한 개별 주장 넷에 인라인 정정을 추가했으며, 15.1.3·2.2.7도 문단 서두에 같은 고지를 추가했다. 2.10.11.3은 이번까지 정정이 전혀 없었다는 것을 새로 발견해 처음으로 추가했다 — 이 절이 놓쳤던 곳이다. 편집을 마친 뒤 측정하니 (확인 필요)는 687 → 694건으로 순증 8이었다(2.3.14·2.10.11.3을 비롯해 언어 재검토 과정에서 여러 절에 새로 단 정정 태그들의 합 — 정확한 절별 분해는 하지 않았다). tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-144.

121차(CHG-145)는 이 책의 검증 이력 100번째 회차다. 세 갈래를 조사했다. rcl wait.c를 읽어 구독·서비스가 rcl_wait() 안에서 완전히 동일하게 처리됨을 확인해 "rcl 계층에 구조적 차이가 있다"는 가설을 반증했다(119차·CHG-143에 이어 세 번째 계층에서도 차이를 못 찾은 셈이다) — 남은 후보는 rmw/DDS 계층이다. Jazzy의 재구성을 완전히 억제하는 실험용 빌드로 서비스 이탈률을 측정하니 줄지 않았다(오히려 소폭 증가, 비유의) — 120차가 확인하지 못했던 "연쇄 빈도가 인과적 손잡이인가"라는 질문에, 이번엔 "빈도 0이어도 이탈이 유지된다"는 한 걸음 더 나아간 답을 냈다. 그러다 뜻밖의 것을 발견했다 — 같은 계측을 구독으로 확장하는 과정에서 117차의 "Humble 구독은 CPU 부하에 완전히 무반응"이라는 결론이 이번 세션에서는 재현되지 않았다(오히려 유의하게 감소, $p=0.0047$, 계측 없는 순정 빌드로도 같은 방향을 재현해 계측 부작용은 배제했다). 다만 117차의 기준값(4.0%)과 이번 세션의 기준값(24~36%) 자체가 6~9배 차이 나는 이유는 밝히지 못해, 이 구체적 결론을 세션 간 재현성 문제로 명시하고 다음 회차로 이월한다. 편집 후 측정하니 (확인 필요)는 694 → 699건으로 순증 5였다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-145.

122차(CHG-146)는 121차가 세션 간 재현성 문제로 이월한 것을 직접 검증했다. 이 호스트에는 이 순간에도 36개의 무관한 컨테이너(다른 개발 스택들)가 실행 중이다 — 이것이 원인일 것이라는 가설을 /proc/loadavg 자연 변동 상관($r=-0.0149$, 사실상 0)과 통제된 저강도 stress-ng 스윕(0·2·4·8·20워커, 매끄러운 용량-반응 없이 40.0%·40.0%·40.0%·20.0%·30.0%)으로 검증했지만 지지되지 않았다 — 게다가 이 스윕 결과 자체가 같은 세션의 바로 앞 배치(121차)와도 재현되지 않아, 문제가 단순 호스트 부하보다 더 미묘하다는 것만 확인했다. rmw_fastrtps_shared_cpp까지 내려간 것(네 계층째, 이전 세 계층은 119·CHG-143·121차)도 구독·서비스의 코드 경로가 완전히 같다는 같은 결론을 냈다 — 대신 서비스가 요청+응답 DDS 엔티티 쌍을 갖는다는(구독은 하나) 구조적 비대칭을 새 후보로 찾았다. 121차의 "재구성 억제가 이탈을 늘린다"는 경향도 n=100(34.0% 대 33.0%, $p=0.88$)에서 완전히 사라져 소표본 우연으로 확정됐다. 편집 후 측정하니 (확인 필요)는 699 → 705건으로 순증 6이었다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-146.

123차(CHG-147)는 122차가 새로 낸 "서비스는 구독의 두 배 DDS 엔티티" 가설을 검증했다 — 기존 자료 재분석과 직접 조작 둘 다로, 둘 다 가설에 불리하게. 클라이언트도 서비스처럼 엔티티 둘(요청 라이터+응답 리더)을 갖지만, 109·112차 자료를 다시 보니 이 책이 측정한 네 엔티티 종류 중 가장 안정적이었다(서비스 53~80%·75~80% 대 클라이언트 6.7~13.3%·0%) — 소스를 나란히 읽어도 두 테스트는 구조·설계 의도가 대칭인데 결과는 정반대다. 새 실험도 했다 — 구독의 로컬 퍼블리셔를 별도 프로세스로 옮겨 측정 대상 노드엔 리더만 남겼더니 이탈률이 방향은 가설과 일치하게 줄었지만(Jazzy 65.0%→57.5%, Humble 42.5%→32.5%) 어느 쪽도 유의하지 않았다($p=0.49$·$0.36$). "DDS 엔티티 개수"는 주된 설명이 아닐 가능성이 크다 — 서비스가 왜 유독 불안정한지는 여전히 열려 있다. Humble 구독의 세션 간 불안정성은 이번에도 새 기준값(65.0%·42.5%, 또 다른 값)만 추가됐을 뿐 메커니즘 조사는 시간 부족으로 다음 회차로 미뤘다. 편집 후 측정하니 (확인 필요)는 705 → 711건으로 순증 6이었다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-147.

124차(CHG-148)는 세 갈래 모두에서 real한 진전을 냈다 — 다섯 번째로 배제된 계층, 디스커버리 타이밍 기각과 뜻밖의 발견, 그리고 Jazzy에서 처음 유의해진 엔티티 개수 효과. execute_service()·execute_client()(rclcpp)가 다섯 계층째도 완전히 같은 코드임을 확인한 뒤, 112차의 도착-시각 계측 도구로 실제 도착 시각을 재 클라이언트의 응답 도착 시간 폭이 서비스의 요청 도착 시간 폭보다 약 5배 넓다는 새 후보를 찾았다(서버가 상시 스핀하며 순차 응답하는 클라이언트 테스트 구조가 원인으로 보인다 — 엔티티 종류 자체의 속성은 아니라는 점을 명시). Humble 구독의 세션 간 불안정성은 두 회차째 관찰만 하다가 이번에 처음 직접 계측했다 — 디스커버리 타이밍 가설(도착 시각 폭이 이탈과 상관될 것)은 $r=0.07$로 기각됐지만, ARRIVAL_ORDER가 FIRE_ORDER보다 오히려 더 불안정하다(32.0% 대 62.0% 최빈 비율)는 뜻밖의 사실을 발견했다 — executor 디스패치가 어수선한 도착을 부분적으로 정돈하고 있다는 뜻이다. 123차의 엔티티 개수 조작 실험을 n=100으로 늘리니 Jazzy는 통계적으로 유의해졌다(71.0%→54.0%, $p=0.013$) — 이 가설이 Jazzy에 한해 실재하는 부분 효과로 승격됐지만, Humble은 방향이 뒤집혀(34.7%→42.0%, $p=0.29$) 세션 간 불안정성이 여기도 나타났다. 편집 후 측정하니 (확인 필요)는 711 → 717건으로 순증 6이었다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-148.

125차(CHG-149)는 124차의 새 가설(도착 시간 폭)을 직접 조작해 반증하고, "정돈" 메커니즘은 소스에서 정확히 찾았다. service_spread_test(요청 사이 지연 0~200µs)로 서비스 테스트의 도착 창을 클라이언트보다도 3배 넓게 벌려 봤지만 이탈률은 유의하게 바뀌지 않았다(Jazzy는 오히려 비유의하게 증가) — 103~104차가 쌓아 온 상관관계가 인과관계로 이어지지 않는다는 것을 직접 조작으로 확인한 셈이다. 반면 Humble의 "정돈" 메커니즘(ARRIVAL_ORDER보다 FIRE_ORDER가 더 안정적인 이유)은 AllocatorMemoryStrategy::remove_null_handles()가 매 rcl_wait() 후 벡터를 준비된 항목만 등록 순서로 남기고 get_next_subscription()이 항상 처음부터 순회한다는 것으로 소스에서 명확히 설명됐다 — 회차를 더 쓸 필요가 없었다. "엔티티 개수"와 "도착 시간 폭"의 관계도 직접 측정해 봤다 — 라이터가 있으면 도착 시간 폭이 90배 가까이 넓었지만(균일한 확장이 아니라 일부가 ~70ms 늦는 지연 샘플 패턴) 방금 도착 시간 폭 자체가 이탈률을 안 바꾼다는 것을 보였으므로, 둘은 "같은 효과의 두 이름"이 아니라 라이터 유무가 만드는 별개의 두 현상으로 남았다. 편집 후 측정하니 (확인 필요)는 717 → 722건으로 순증 5였다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-149.

126차(CHG-150)는 이 실험 계열 전체에서 가장 큰 단일 효과를 냈고, 그 과정에서 이 책 스스로의 "종결" 판정이 틀렸다는 것을 우연히 발견했다. 서버 사전 스핀을 직접 조작하니(측정 대상 MultiThreadedExecutor를 요청 전송 전에 미리 스핀) Humble의 이탈률이 82.1%에서 0.0%로 완전히 사라졌다($p\approx 0$) — Jazzy는 무변화. 이 실험을 실행하다 fired≠6인 경우가 반복돼 확인해 보니, 116차가 101회의 재현 실패 끝에 "재현 불가로 명시적으로 종결"했던 Humble 서비스 콜백 이중 호출이었다 — 사전 스핀은 이 이중 호출도 줄였지만(Humble 22.0%→8.0%) Jazzy에서는 오히려 0%에서 44.0%로 만들어 내, 113차의 "Jazzy는 이중 호출이 없다"는 확정과도 배치된다. 의도적으로 쫓은 것이 아니라 우연히 마주친 것이며, 정직하게 "종결"을 재개봉한다 — CLD-03에 따라 116차의 문장 자체는 지우지 않고 그 옆에 정정 포인터만 남겼다. 덧붙여 execute_service()가 execute_client()보다 4.7배 더 걸린다는 것을 실측했고(103차의 견해가 확인됨), "지연 샘플" 패턴(125차)을 tcpdump로 캡처하니 하트비트·재전송이 전혀 안 보여 네트워크 수준이 아니라는 것도 확인했다. 편집 후 측정하니 (확인 필요)는 722 → 729건으로 순증 7이었다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-150.

127차(CHG-151)는 126차가 남긴 최우선 질문(사전 스핀이 왜 효과를 내는가)에 대한 두 가설을 실측으로 기각하고, 113차의 조사 전제 자체가 틀렸다는 것을 밝혔다. 사전 스핀의 메커니즘을 "재구성-대기 캐스케이드 횟수 차이" 가설로 측정했지만 두 조건의 캐스케이드 횟수가 거의 같아(28.0 대 27.8) 이탈률 차이(3.3% 대 73.3%)를 설명하지 못해 기각됐고, "스레드 지역성" 가설도 정반대 방향(사전 스핀 쪽이 스레드 전환율 97.0%로 더 높음)이 나와 기각됐다 — 가장 큰 단일 효과(126차)의 실제 원인은 두 회차 연속 못 찾았다. 113차가 Jazzy 이중 호출과 무관한 것으로 배제했던 "2단계 등록" 경로를 다시 확인하니, 그 조사가 애초에 이번 이중 호출을 낸 도구가 쓰지 않는 API를 겨냥한 것이었다는 전제 오류가 드러났다(113차 원문은 보존, 정정 포인터만 추가) — 대신 캐시된 wait_result_의 전진 전용 반복자와 락 밖 DDS take 사이의 미세한 타이밍 간극을 새 후보 원인으로 소스에서 찾았지만 계측으로 확정하지 못했다. "지연 샘플" 패턴은 FastDDS 내부 경고 로그로도 지연 구간에 활동이 전혀 없어 126차 tcpdump에 이어 두 번째 "배제" 판정을 받았다. 편집 후 측정하니 (확인 필요)는 729 → 739건으로 순증 10이었다 — 이번에도 이 문서 자신이 위 표·문단에서 그 표기 문자열을 여러 차례 인용하며 실제 편집(주로 새 절의 미확인 태그 3건) 이상으로 늘어난, 100차 이후 반복 관찰된 자기지시적 증가로 보인다. tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-151.

128차(CHG-152)는 127차가 두 회차 연속 못 찾던 사전 스핀 메커니즘을 마침내 사건 단위 타임스탬프로 찾아냈다. 집계(총 재구성 횟수)가 아니라 재구성 각각의 발생 시각과 요청 도착·디스패치 시각을 같은 프로세스·같은 시계로 측정하니, "마지막 도착~마지막 디스패치" 구간에 재구성이 몇 번 몰리는지가 사전 스핀 7~11회 대 기준 23~28회로 완전히 갈렸다(Welch $t=49.19$) — 총량은 거의 같지만(126·127차가 이미 확인) 그 분포가 완전히 다르다는 것이 핵심이었다. 기준 조건은 스핀 시작 순간 스레드 4개가 이미 준비된 데이터를 두고 뮤텍스를 경합하며 짧은 창에 몰아치고, 사전 스핀은 그 다툼을 400ms에 걸쳐 미리 분산해 소화한다 — 다만 조건 내부에서는 이 개수가 개별 이탈을 예측하지 못해 인과 경로까지는 못 닫았다. 127차의 새 후보 원인(Jazzy wait_result_ 경합 창)를 계측하려 총 240회를 사전 스핀 조건으로 실행했지만 이번 세션엔 이중 호출이 단 한 번도 재현되지 않아, 바로 앞 회차의 44.0%와 대비되는 세션 의존성만 재확인했다. "지연 샘플" 패턴은 gdb 반복 attach가 1회 평균 ~295ms(현상보다 4배 큰 프로브 효과)임을 실측으로 확인해 이 스케일엔 부적합하다고 판단하고, 대신 /proc 스레드 상태 폴링(저오버헤드, ptrace로 안 멈춤)으로 갈아타 세 번째 "배제"(지속적 CPU 활동 없음)를 확인했다 — 방법론 자체의 개선도 이번 회차의 성과다. 편집 후 측정하니 (확인 필요)는 739 → 749건으로 순증 10이었다 — 이번 회차도 실제 새 미확인 태그(①②③ 각 절 끝 + 이 문단·표의 인용)보다 이 문서 자신의 자기지시적 인용이 더해진 값으로 보이며, 정확한 분해는 이번에도 하지 않았다(100차 이후 반복 관찰된 패턴과 같은 원인). tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-152.

129차(CHG-153)는 세 항목 모두에서 실질적 진전을 냈다 — 128차의 "재구성 몰림" 관찰에 마침내 인과 경로가 확인됐다. Humble 소스를 다시 읽어 wait_for_work()·get_next_ready_executable_from_map()이 재구성·필터링·선택을 서로 다른 세 번의 별개 mutex_ 획득으로 처리하고, 무잠금 상태로 블로킹되는 rcl_wait() 도중 다른 스레드가 같은 공유 wait_set_을 자유롭게 다시 짓밟을 수 있다는 것을 확인했다 — 사건 단위 계측으로 측정하니 기준 조건의 이탈 실행 22/22 전부(100%)에서 등록 순서가 처음 깨지는 순간에 다른 스레드의 재구성 또는 실행 창이 겹쳐 있었다(실측 사례: 첫 선택이 등록 순서 0이 아니라 3). 다만 사전 스핀이 이 경합 자체를 왜 원천적으로 막는지는 이번에도 완전히 분리하지 못했다. Jazzy 이중 호출은 86차식 결정론적 결함 주입(경합 창을 최대 800배까지 확대)으로 검증했지만 총 140회 전부 재현되지 않아 127차의 구체적 가설에 불리한 증거가 쌓였다(이 세션 자체의 무주입 재현율도 0%였다는 조건부 단서는 남긴다). "지연 샘플" 패턴은 strace -T로 futex 호출 인자를 직접 봐 정체가 드러났다 — 어떤 스레드가 절대 시각 데드라인이 있는 타임드 웨이트로 블로킹된 뒤 다른 스레드의 웨이크업 신호를 못 받고 자기 데드라인(~62~64ms, 관측된 갭과 거의 일치)이 만료될 때까지 기다렸다가 ETIMEDOUT으로 깨어났다 — 126~128차의 세 배제 판정과 정확히 들어맞는, 웨이크업 경로가 연결 안 된 타임드 폴백이었다. 편집 후 측정하니 (확인 필요)는 749 → 757건으로 순증 8이었다(이번에도 이 문서 자신의 자기지시적 인용이 섞인 값으로 보인다, 100차 이후 반복 관찰된 패턴). tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-153.

130차(CHG-154)는 뜻밖의 정정 하나와 확실한 진전 하나를 냈다. 129차 원시 로그를 재분석해(새 컨테이너 실행 없이) 사전 스핀의 400ms idle 구간이 "계속 순환"이 아니라 "시작 직후 ~935µs 몰아치기 + 이후 399ms 단일 rcl_wait() 블록"이었음을 발견해 127·128차 서술을 정정했다 — 다만 이를 반영한 "첫 PICK 시점 스레드 위상 폭" 지표 자체는 사전 스핀·기준 간 유의한 차이를 못 냈다(Welch $t=-1.93$, 방향도 가설과 안 맞았다) — 129차의 메커니즘을 이 지표로는 확인하지 못했다. Jazzy 이중 호출은 소스를 다시 읽어 busy 플래그가 선택 시점부터 처리 완료까지 전 구간을 감싼다는 것을 확인해, 129차의 지연 지점이 왜 효과가 없었는지 설명이 됐다 — 더 이른 지점(busy 세우기 직전)으로 옮겨도(누적 220회) 재현이 안 돼 127차 가설이 사실상 배제됐다. "지연 샘플" futex는 bpftrace가 BTF 파싱 실패로 막히자 strace -k(라이브러리 unwind, BTF 불필요)로 갈아타 완전히 심볼화됐다 — FastDDS 라이터 쪽 흐름 제어 스레드 FlowControllerImpl::run()이 ~152.6ms 블로킹돼 있다가 깨어난 직후 지연 샘플이 도착했다, 주소만 있던 129차와 달리 정확한 클래스·함수명을 확보한 것 자체가 진전이다. 편집 후 측정하니 (확인 필요)는 757 → 767건으로 순증 10이었다(이번에도 이 문서 자신의 자기지시적 인용이 섞인 값으로 보인다, 100차 이후 반복 관찰된 패턴). tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-154.

131차(CHG-155)는 방법론적 실패 하나를 정직하게 거쳐 락 A 충돌의 명확한 신호를 얻었다. 첫 시도(구간이 실제로 겹치는 횟수)는 뮤텍스로 원천 불가능해 예외 없이 0이었다 — 지표를 "재구성-끝부터 선택까지 다른 스레드의 재구성-시작이 몇 번 개입하는가"로 바꾸니 사전 스핀 30회 전부 0회 대 기준 평균 4.00회(최대 18회)로 완벽하게 갈렸다(Welch $t=4.708$) — 129차의 세 단계 락 경합 메커니즘이 사전 스핀에서 사라진다는 것을 마침내 직접 지표로 확인했다(다만 락 A 개입이 이탈의 유일한 경로는 아니었다, 개입 0인데도 이탈한 실행이 있었다). Jazzy 이중 호출은 rmw_fastrtps_shared_cpp 소스로 unread-count가 캐시가 아니라 실시간 조회임을 확인해 129차 가설이 이 형태로는 성립하지 않는다는 것을 알았고, 스레드 16개 스트레스 테스트(N=6 대비 2.7배 과잉)로도 재현하지 못해(127~131차 누적 270회 0건) 남은 창이 매우 좁거나 특정 호스트 조건 의존일 가능성만 남겼다. "지연 샘플"은 FlowControllerImpl.hpp 소스를 직접 읽어 130차의 "~150ms 페이싱 주기" 해석이 틀렸음을 확인했다 — 실제로는 고정 주기가 전혀 없는 순수 무기한 대기이고, "동기 전달이 실패한" 샘플이 큐에 들어올 때만 깨어난다(→ 130차 정정) — 실제 질문은 "동기 전달이 왜 그 샘플에서만 실패했는가"로 완전히 바뀌었다. 편집 후 측정하니 (확인 필요)는 767 → 777건으로 순증 10이었다(이번에도 이 문서 자신의 자기지시적 인용이 섞인 값으로 보인다, 100차 이후 반복 관찰된 패턴). tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-155.

132차(CHG-156)는 세 항목 모두에서 소스를 더 깊이 조사해 앞선 회차의 결론을 다듬었다. 104차의 "배치 분할"을 129차 원시 로그로 재분석하니 사전 스핀(5.93/6)·기준(5.17/6) 둘 다 N에 가까워 독립 변수가 아니라 락 A 현상의 증상이었음이 드러났다(오히려 무이탈 조건인 사전 스핀 쪽이 더 높았다) — 락 A 개입=0인 기준 실행의 64%가 여전히 이탈해, 락 A 하나만으로는 못 설명하는 잔차가 남았다. Jazzy의 unread-count는 rmw 계층에서만 보면 실시간 조회였지만 더 깊이(RTPSReader까지) 내려가니 total_unread_라는 유지되는 카운터였고(131차 정정), 리스너 경로(get_last_notified())와 실제 take 경로(change_read_by_user())가 서로 다른 기준으로 같은 카운터를 독립적으로 갱신한다는 구조적 경합 여지를 찾았다. "지연 샘플"의 동기 전달 실패는 StatefulReader::processDataMsg()의 반환값으로 정체가 좁혀졌고, KeepLast(1) QoS와 관련된 후보 분기까지 찾았지만 실제 깊이 제한 구현(DataReaderHistory)까지는 내려가지 못했다. 편집 후 측정하니 (확인 필요)는 777 → 787건으로 순증 10이었다(이번에도 이 문서 자신의 자기지시적 인용이 섞인 값으로 보인다, 100차 이후 반복 관찰된 패턴). tools/book_check.py는 편집 전후 모두 0건, 실행 확인 장 수 89개도 변화 없었다. 상세는 CHANGES.md CHG-156.

112차(CHG-157)는 132차가 남긴 세 항목을 순서대로 처리했다. ①(최우선) 132차의 잔차(락 A 개입=0인데도 이탈한 기준 실행 7건)를 129차 원시 로그로 개별 재검토하니 무작위 뒤섞임이 아니라, 등록 순서 안의 어떤 연속 구간(창)에서 그 창의 마지막 원소가 맨 앞으로 이동하고 나머지는 정확히 원래 상대 순서를 유지하는 "국소 창 회전"이었다 — 7건 전부가 이 형태였다. 103·124차가 이미 확립한 "동시에 보내도 실제 도착 순서는 등록 순서와 미세하게 어긋난다"는 현상의 재현으로 보이며, 락 A 개입과는 서로 다른 독립된 이탈 경로로 보인다. ② Jazzy RTPSReader::update_last_notified()의 호출부(StatefulReader::NotifyChanges())를 직접 읽으니 "notified" 워터마크는 개별 변경을 리스너에게 알리기 전에 이미 max_seq까지 미리 당겨지는 결정론적 순서였다 — "드문 경합 창"이 아니라 매 알림마다 항상 일어나는 일이라, 오히려 129~132차의 경합 창 가설에 불리한 증거로 작용했다(결정론적 원인이면 이중 호출도 항상 일어나야 하는데 실제로는 드물다). ③ DataReaderHistory::can_change_be_added_nts()는 전체 리소스 한도만 검사하고, KeepLast(depth)의 실제 강제는 received_change_keep_last()에 있으며 같은 인스턴스에 이미 depth개의 미소비 샘플이 있을 때만 발동한다 — 이 책의 지연 샘플 재현 테스트는 토픽마다 정확히 한 번만 발행하므로 이 분기가 구조적으로 발동할 수 없다는 것이 소스로 확인됐다. 111·132차가 유력 후보로 지목한 KeepLast(1) 깊이 제한 가설은 이로써 배제됐다. "동기 전달 실패"의 실제 원인은 여전히 열려 있다. 편집 후 측정하니 (확인 필요)는 787 → 797건으로 순증 10이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-157.

113차(CHG-158)는 132차가 남긴 세 항목을 직접 계측으로 추적했다. ①(최우선) 133차가 "추정"만 했던 "국소 창 회전=도착 미세 순서 어긋남" 가설을, 128차의 리스너 콜백 기반 도착 시각 계측 도구로 직접 검증했다 — 이탈 실행 28/28(사전 스핀 1 + 기준 27) 전부에서 도착 순서가 완벽한 등록 순서였다(FIRE_ORDER가 크게 뒤섞인 경우조차). 가설은 반증됐고, 이탈은 도착 잡음이 아니라 순수 executor 선택/재구성 경합(락 A)에서만 만들어진다는 것이 확정됐다. ② rmw_wait.cpp를 다시 읽어 rcl_wait()의 실제 준비 판정 게이트가 129~133차가 판 total_unread_와는 완전히 별개인 DataReader::get_first_untaken_info()(data_available_instances_, 실제 애플리케이션 take로만 비워짐)임을 확정했다 — total_unread_ 경로는 리스너 콜백 트리거만 결정할 뿐 대기집합 준비 판정과는 무관했다. ③ processDataMsg()의 후보 분기들을 ros-humble-fastrtps-dbgsym으로 재빌드 없이 GDB 직접 계측했다(최적화 빌드의 "동일 코드 접기"로 소스 줄번호 중단점이 여러 분기를 뒤섞는 함정을 발견하고 우회했다) — 29회·1566회의 실제 동기 전달에서 132·133차가 나열한 후보 전부(can_change_be_added_nts·reserve_cache·get_payload·change_received)가 단 한 번도 실패하지 않았다(다만 이 세션엔 "지연 샘플" 자체가 재현되지 않았다). 편집 후 측정하니 (확인 필요)는 797 → 805건으로 순증 8이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-158.

114차(CHG-159)는 133차가 남긴 세 항목을 결함 주입과 GDB 없는 재계측으로 추적했다. ①(최우선) get_first_untaken_info()의 게이트(data_available_instances_)가 이중 준비 신호를 낼 수 있는지 add_to_instance()·check_and_remove_instance()의 타이밍을 결함 주입(erase 직전 지연 최대 50ms)으로 시험했다 — fastrtps 2.6.12를 실제로 재빌드해 디스커버리 트래픽 포함 9084건의 add/remove 사건을 관찰했는데 개입한 경우가 0건이었다(두 함수가 같은 리더 뮤텍스로 완전히 직렬화돼 구조적으로 불가능). ② processDataMsg()에 GDB 대신 원자적 카운터를 심어 재빌드했다 — "지연 샘플" 재현율이 GDB 세션의 0%에서 40%대(16/40·17/40)로 상승해, GDB 오버헤드가 억누르고 있었다는 우려가 확인됐다. 재현된 33건에서도 후보 분기는 여전히 안 실패했지만, 131차가 지목한 enqueue_new_sample_impl()(동기 실패 시에만 불림)이 40회 전부 0번이었고 대신 무관한 재전송 함수(add_old_sample_impl())가 지연 샘플 유무와 무관하게 매번 정확히 13회 불려, FlowControllerImpl::run() 스레드의 정체가 "동기 실패 처리"가 아니라 "정기 재전송"이었을 가능성을 열었다. ③ 도착-시각 도구와 [GAP129-EVT] 재구성/선택 로그를 사건 단위로 대조하니 스왑(44건)의 79.5%가 락 A 개입과 동반됐다(정상 픽 136건은 6.6%) — 108·110차의 회차-단위 상관을 개별 스왑 하나하나로 확인했다. 편집 후 측정하니 (확인 필요)는 805 → 812건으로 순증 7이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-159.

115차(CHG-160)는 134차가 남긴 세 항목을 결함 주입·개별 재검토·픽 위치 분리로 추적했다. ①(최우선) 재전송(add_old_sample_impl())에 사건 단위 타임스탬프를 남겨 지연 샘플 도착 시각과 직접 겹쳐 보니, "우연"이라던 이전 회차 판단과 달리 지연 샘플 16/16건 전부에서 재전송이 갭 창 안에 2~8회씩 정확히 들어와 있었다(우연 기대치의 약 18배) — 다만 인과 방향은 여전히 열려 있다. ② 락 A 개입 없는 잔차 스왑(9/44)을 60회 표본으로 재검토하니 잔차 스왑 28건(75건 중) 전부에서 그 스레드가 자기 재구성 사이클을 이 실행 안에서 한 번도 기록하지 않았다 — Executor::get_next_executable()이 wait_for_work()(락 A 재구성)보다 get_next_ready_executable()을 먼저 시도하기 때문에 다른 스레드가 남긴 벡터를 자기 재구성 없이 바로 선택하는 "빠른 경로"였다(락 A와 합치면 스왑의 100%가 설명된다). ③ 픽 순번으로 나누니 스왑률이 60.0%(픽#0)→36.7%→25.0%→3.3%→0%→0%로 단조 감소했고, 빠른 경로 스왑 28건 전부가 픽#0~2에만 몰려 있었다 — 첫 픽의 스왑은 락 A 경합과 빠른 경로가 겹치는 스핀-시작 특유의 현상이었다. 편집 후 측정하니 (확인 필요)는 812 → 816건으로 순증 4이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-160.

116차(CHG-161)는 135차가 남긴 세 항목을 처리했다(③은 코디네이터의 제안대로 스왑 메커니즘 대신 Humble-Jazzy 근본 원인으로 무게중심을 옮겼다). ①(최우선) 재전송(add_old_sample_impl())을 실제로 억제하는 결함 주입을 넣어 정상·억제 각 40회를 실행했다 — 정상 40/40은 6개 메시지 전부 수신했지만 억제 40/40은 단 하나도 수신하지 못했다. TRANSIENT_LOCAL 구독이 발행보다 늦게 생기는 이 테스트 구조상, 재전송이 지연 샘플 하나만의 지연이 아니라 6개 메시지 전부의 유일한 전달 경로였다는 것이 결함 주입으로 완전히 확인됐다 — 136차의 "우연 아닌 겹침"을 넘어 인과가 닫혔다. ② "빠른 경로" 픽에 "마지막 재구성자" 스레드를 사건 단위로 남기니 29건 전부(100%)에서 선택한 스레드가 아니라 다른 스레드의 재구성 상태를 물려받았다(그 외 픽은 23.6%만) — "왜 남의 상태인가"까지 완전히 닫혔다. ③ Jazzy의 선택 경로(get_next_ready_executable())를 처음 직접 읽고 계측해 Humble과 같은 세션에서 비교했다 — Jazzy는 공유 wait_result_를 매번 reset()하는 구조로 Humble의 점진적 벡터와 다르다는 것을 확인했지만, 같은 세션 절대 이탈률(Humble 73.3% 대 Jazzy 100%)은 113·114차 기존 기준과 방향이 반대라 계측 오버헤드 의심으로 신뢰하지 않는다 — 다만 Jazzy 스왑의 94.2%가 Humble의 두 메커니즘(락 A·빠른 경로) 어느 쪽에도 안 맞는다는 구조적 사실은 108차의 해시 순서 가설이 별개 메커니즘일 가능성을 뒷받침한다. 편집 후 측정하니 (확인 필요)는 816 → 822건으로 순증 6이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-161.

117차(CHG-162)는 136차가 남긴 세 항목을 처리했다. ①(최우선) service_prespin_evt를 계측 없는 시스템 rclcpp에 그대로 빌드해 같은 세션에서 재비교하니 Jazzy는 여전히 60/60(100%) 이탈이었다(Humble은 73.3%→50.0%로 실제 바뀌었지만 방향은 안 바뀐다) — 116차의 "계측 오버헤드" 추정은 정정한다, 역전은 121·122차의 세션 변동성이었다. ② Jazzy의 선택 순서 정체를 소스로 완전히 확정했다 — collect_entities()→ExecutorEntitiesCollection::ServiceCollection(std::unordered_map<const rcl_service_t*, ...> 상속)→update_entities()의 begin()~end() 순회, 즉 해시 버킷 순서다(108차의 원래 가설). 116차의 Jazzy 60회 로그를 재분석하니 61.7%(37/60)가 정확히 같은 FIRE_ORDER 하나(5,3,2,1,0,4)로 수렴했다 — 순수 레이스로는 설명 안 되는 결정론적 편향의 증거다. ③ processDataMsg()에 GUID 엔티티ID를 남겨 114·115차 측정(1566회, 0건 실패)의 실제 구성을 확인하니 우리 6개 테스트 토픽은 19.7%(360/1830)뿐이었고 80.3%는 배경 트래픽(엔티티ID 하나가 73.8%)이었다 — 우리 자신의 360회는 0건 실패로 재확인됐다. 편집 후 측정하니 (확인 필요)는 822 → 826건으로 순증 4이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-162.

118차(CHG-163)는 137차가 남긴 항목①②를 처리한 뒤(③은 코디네이터의 판단대로 실무 지침 집필로 전환), 32회차(108~139차) executor 디스패치 조사를 정리했다. ① DataReaderHistory의 topic_name_에 공개 접근자를 추가해 배경 트래픽의 정체를 토픽 이름까지 확정했다 — ros_discovery_info(73.8%)·rt/parameter_events(6.6%)였다. ② Jazzy 60회 로그를 재분석하니 4개의 서로 다른 순서가 반복적으로 나타나 전체의 81.7%(49/60)를 차지했다 — "지배적 순서 하나 + 잡음"이 아니라 소수의 안정적인 해시 버킷 순서 후보군이 있는 것으로 보인다(단발 순서 11/60이 잡음인지 표본 부족인지는 못 갈랐다). ③ 코디네이터의 판단대로 두 배포판의 핵심 메커니즘(Humble: 락 A+빠른 경로, Jazzy: 해시 버킷 순서)이 이미 충분히 규명됐다고 보고, 2.3에 신규 절 2.3.15(실무 지침)를 추가해 증명된 것(같은 타입 엔티티 순서 비보장, Humble의 사전 스핀 완화 82.1%→0.0%, TRANSIENT_LOCAL 선발행의 별도 지연 경로)과 증명되지 않은 것(이중 호출 원인·ASLR 부분적 역할·Humble이 더 불리한 정량적 이유)을 정리했다. 2.3.11·2.3.13·15.1.5·15.1.9에도 요약을 반영했다. 편집 후 측정하니 (확인 필요)는 826 → 830건으로 순증 4이었다. tools/book_check.py는 편집 전후 모두 0건. 상세는 CHANGES.md CHG-163.

C++ 예시는 컴파일로 한 번 걸렀다(2026-08-18, 69차). rclcpp를 쓰면서 생략기호가 없는 코드펜스 122개를 추출해 Jazzy 헤더로 -fsyntax-only -Wdeprecated-declarations 컴파일했다. 한계가 분명하다 — 대부분이 문맥에서 떼어낸 조각이라 주변 변수(node_·timer_ 등)가 없어 온전히 통과한 것은 19개이고, 나머지는 그 잡음에 묻힌다. 그래도 잡음과 무관한 신호 넷이 걸렸다: 인자 개수가 틀린 호출 세 곳(1.10.11), 폐기 예정 오버로드 네 곳(2.4·1.7), 폐기 예정 헤더 두 줄(6.4), 그리고 존재하지 않는 메서드 하나(2.10.11.2). 전부 읽어서는 걸러지지 않는 종류이며, 컴파일러만이 인자 개수와 폐기 표시를 센다. 여기 없는 장의 예시는 아직 컴파일해 보지 않았다(확인 필요).

Python 예시는 이름을 런타임과 대조했다(2026-08-18, 70차). 컴파일러가 없으므로 ast로 import·열거 멤버·생성자 키워드를 추출해 실물에 물었다 — 68개 import 전부, 열거 4종, 키워드 4종이 실재했고 문법 오류도 폐기 형태도 없었다. 다만 이름만 본다 — 인자 개수·순서는 못 보므로 C++에서 포착된 종류의 결함은 이 방법으로 걸러지지 않는다. 이름이 있어도 동작이 기대와 다른 경우가 있다는 것도 별개다(2.8.12.10). 방법과 한계는 2.8.13에 적었다.

이름은 잘 맞고, 틀리는 것은 의미다(2026-08-18, 69~71차). 세 차례에 걸쳐 기계로 대조할 수 있는 이름을 전수 확인했다 — C++ import에 해당하는 헤더·타입, Python import·열거·키워드 76개, ros2·colcon 명령 조합 81종과 롱플래그 31종, 인터페이스 타입 53종. 이름에서 나온 결함은 0이다. 반면 같은 기간 의미·서명에서는 꾸준히 나왔다 — 인자 개수, 폐기된 오버로드, 체이닝 가능 여부, 우선순위 방향, 보고값과 실제 동작의 불일치. 이름은 문서의 가장 눈에 띄는 부분이라 옮겨 적어도 잘 맞고, 의미는 문서에 한 줄로만 있어 옮기는 과정에서 사라진다. 그래서 이 책의 남은 확인 노력은 이름이 아니라 의미 쪽에 쓴다.

견해: 이 책을 근거로 무언가를 결정하기 전에, 그 문장에 (실행 확인)이 붙어 있는지 보라. 붙어 있으면 Jazzy에서 그대로 재현된다. 없으면 --help·헤더·ros2 interface show로 5분 안에 확인할 수 있는 경우가 대부분이고, 이 책은 각 장에 그 확인 방법을 함께 적어 두었다.

장 인덱스

상태 범례: ✅ 작성완료 · 🚧 작성중 · ⬜ 미착수

제0부 개관과 출발 (0.1~0.7)

ROS 2가 무엇이고 왜 이렇게 생겼는지를 세운다. 설치하고 첫 패키지를 실행하는 데까지가 목표다. — 처음 시작한다면 여기부터, 순서대로.

• ✅ 0.1 — ROS 2란 무엇인가: 미들웨어·프레임워크·생태계
• ✅ 0.2 — ROS 1에서 ROS 2로: 설계 결정과 그 대가
• ✅ 0.3 — Jazzy Jalisco의 정체: 배포 주기·플랫폼·수명
• ✅ 0.4 — 설치와 환경: apt·소스·Docker·환경변수
• ✅ 0.5 — 워크스페이스·오버레이·언더레이의 원리
• ✅ 0.6 — 첫 패키지 워크스루: C++와 Python
• ✅ 0.7 — ROS 2 CLI 체계와 데몬의 내부

제1부 계산 그래프의 코어 (1.1~1.13)

노드·토픽·서비스·액션·파라미터 — 모든 ROS 2 코드가 딛고 서는 층이다. QoS와 생애주기도 여기 있다. — 현업에서 무엇을 하든 이 부는 전부 필요하다.

• ✅ 1.1 — 노드와 그래프: 이름·네임스페이스·리매핑
• ✅ 1.2 — 인터페이스 정의: msg·srv·action과 IDL
• ✅ 1.3 — 타입 지원과 직렬화: rosidl·CDR·type hash
• ✅ 1.4 — 토픽: 발행과 구독의 전 경로
• ✅ 1.5 — QoS 심층 I: 정책과 호환성 매트릭스
• ✅ 1.6 — QoS 심층 II: 프로파일 설계와 함정
• ✅ 1.7 — 서비스: 요청·응답의 실제와 데드락
• ✅ 1.8 — 액션: 목표·피드백·취소의 상태기계
• ✅ 1.9 — 파라미터: 선언·타입·콜백·이벤트
• ✅ 1.10 — 시간: Clock·ROS Time·sim time·Rate
• ✅ 1.11 — 로깅: 로거 계층·구성·rosout
• ✅ 1.12 — 라이프사이클 노드: 관리형 상태기계
• ✅ 1.13 — 컴포지션: 컴포넌트 노드와 프로세스 내 결합

제2부 실행 모델·클라이언트 라이브러리 내부 (2.1~2.10)

콜백이 언제·어느 스레드에서 실행되는가. rclcpp·rcl·rmw 계층 해부부터 executor·콜백 그룹·타이머·메모리·intra-process, 그리고 rclpy의 GIL·비동기·스레드 안전성·NodeOptions 확장까지 다룬다. — "왜 콜백이 안 불리나"·"왜 느린가"를 쫓을 때.

• ✅ 2.1 — 계층 해부: rclcpp·rcl·rmw·rosidl·DDS
• ✅ 2.2 — wait set과 executor의 원리
• ✅ 2.3 — Executor 종류와 선택
• ✅ 2.4 — 콜백 그룹·동시성·재진입
• ✅ 2.5 — 타이머의 정밀도와 드리프트
• ✅ 2.6 — 메모리 모델: allocator·loaned message
• ✅ 2.7 — intra-process 통신과 zero-copy
• ✅ 2.8 — rclpy 심층: GIL·executor·비동기
• ✅ 2.9 — 스레드 안전성과 흔한 경쟁 조건
• ✅ 2.10 — NodeOptions·노드 인터페이스·확장 포인트

제3부 미들웨어: DDS·RTPS·RMW (3.1~3.10)

ROS 2 아래의 미들웨어 — DDS 개념, RTPS 와이어, RMW 교체, 디스커버리 비용, 네트워크 문제, DDS 아닌 대안 rmw_zenoh. — 여러 대를 추가하거나 통신이 이상할 때 반드시 온다.

• ✅ 3.1 — DDS 개념: DCPS·도메인·엔티티
• ✅ 3.2 — RTPS 와이어 프로토콜
• ✅ 3.3 — 디스커버리: SPDP·SEDP와 그 비용
• ✅ 3.4 — Discovery Server와 대규모 그래프
• ✅ 3.5 — RMW 계층: API와 구현 교체
• ✅ 3.6 — 미들웨어 벤더 비교
• ✅ 3.7 — Fast DDS 튜닝: XML 프로파일·전송
• ✅ 3.8 — Cyclone DDS 튜닝
• ✅ 3.9 — 네트워크: 멀티캐스트·무선·컨테이너
• ✅ 3.10 — rmw_zenoh: DDS 아닌 대안

제4부 빌드·패키징·배포 (4.1~4.10)

빌드·패키징·배포 — ament·colcon·rosdep·워크스페이스 전략·크로스 컴파일·릴리스(bloom)·CI. — 혼자 쓰던 코드를 팀·제품으로 옮기는 단계.

• ✅ 4.1 — ament 빌드 시스템의 구조
• ✅ 4.2 — ament_cmake 심층
• ✅ 4.3 — ament_python과 엔트리포인트
• ✅ 4.4 — package.xml format 3
• ✅ 4.5 — colcon 심층: 그래프·mixin·확장
• ✅ 4.6 — rosdep과 시스템 의존성
• ✅ 4.7 — 소스 빌드·vcstool·워크스페이스 전략
• ✅ 4.8 — 크로스 컴파일과 arm64
• ✅ 4.9 — 릴리스: bloom·rosdistro·빌드팜
• ✅ 4.10 — CI와 품질 게이트

제5부 좌표·모델 (5.1~5.7)

좌표와 로봇 모델 — tf2, URDF/xacro, SDF. 로봇의 "몸"을 소프트웨어에 기술하는 층이다. — 센서를 장착하거나 팔을 움직이기 전에.

• ✅ 5.1 — tf2 아키텍처: 버퍼·리스너·브로드캐스터
• ✅ 5.2 — tf2 실전: 시간·외삽·정적 변환의 함정
• ✅ 5.3 — URDF 심층
• ✅ 5.4 — xacro: 매크로와 조립
• ✅ 5.5 — robot_state_publisher와 관절 상태
• ✅ 5.6 — SDF와 URDF: 기술 형식의 이중성
• ✅ 5.7 — 로봇 모델 품질 검증

제6부 하드웨어 인터페이스 (6.1~6.9)

실제 하드웨어와 잇는다 — ros2_control 전반, 드라이버 작성, micro-ROS, 진단. — 모터가 회전하는 로봇을 만들 때.

• ✅ 6.1 — ros2_control 아키텍처
• ✅ 6.2 — 하드웨어 컴포넌트 작성
• ✅ 6.3 — Resource Manager·Controller Manager 내부
• ✅ 6.4 — 컨트롤러 작성과 체이닝
• ✅ 6.5 — 표준 컨트롤러 카탈로그
• ✅ 6.6 — 실시간 루프와 ros2_control의 제약
• ✅ 6.7 — 드라이버 작성 원칙: 시리얼·CAN·EtherCAT
• ✅ 6.8 — micro-ROS: MCU와 ROS 2
• ✅ 6.9 — 진단: diagnostic_updater와 상태 보고

제7부 센서·인지 파이프라인 (7.1~7.8)

센서 데이터의 규약과 파이프라인 — 메시지 규약, 이미지 파이프라인·카메라·라이다·포인트클라우드, IMU·오도메트리 융합, 시간 동기, 대용량 설계. — 인지 스택을 구축하기 전에.

• ✅ 7.1 — 센서 메시지 규약: REP 103·105·145
• ✅ 7.2 — 이미지 파이프라인: image_transport·cv_bridge
• ✅ 7.3 — 카메라 모델·캘리브레이션·CameraInfo
• ✅ 7.4 — 포인트클라우드: PointCloud2·PCL
• ✅ 7.5 — LiDAR·LaserScan 처리
• ✅ 7.6 — IMU·오도메트리·robot_localization
• ✅ 7.7 — 시간 동기화: message_filters·PTP
• ✅ 7.8 — 대용량 데이터 파이프라인 설계

제8부 항법 (8.1~8.8)

Nav2 전반 — 아키텍처·SLAM Toolbox·AMCL·코스트맵·플래너·행동 트리·복구·튜닝. — 이동 로봇을 자율 주행시킬 때.

• ✅ 8.1 — Nav2 아키텍처 전경
• ✅ 8.2 — 지도와 SLAM Toolbox
• ✅ 8.3 — 위치추정: AMCL 튜닝
• ✅ 8.4 — 코스트맵 2D: 레이어와 센서 통합
• ✅ 8.5 — 플래너·컨트롤러 플러그인
• ✅ 8.6 — 행동 트리와 BT Navigator
• ✅ 8.7 — 복구·상태관리·안전
• ✅ 8.8 — Nav2 튜닝·평가·현장 디버깅

제9부 매니퓰레이션 (9.1~9.6)

MoveIt 2 전반 — 아키텍처·계획 파이프라인·Planning Scene·Servo·픽앤플레이스·배치 실무. — 팔을 계획해 움직일 때.

• ✅ 9.1 — MoveIt 2 아키텍처
• ✅ 9.2 — 계획 파이프라인: OMPL·Pilz·STOMP
• ✅ 9.3 — Planning Scene과 충돌 처리
• ✅ 9.4 — MoveIt Servo와 실시간 제어
• ✅ 9.5 — 픽앤플레이스 통합
• ✅ 9.6 — 매니퓰레이터 배치 실무

제10부 시뮬레이션 (10.1~10.6)

시뮬레이션 — 시뮬 전략, Gazebo 연동, 센서 시뮬, gz_ros2_control, Isaac Sim 등 대안 시뮬레이터, Sim2Real 간극. — 하드웨어 없이 개발하거나 회귀 시험을 만들 때.

• ✅ 10.1 — 시뮬레이션 전략: 무엇을 검증하는가
• ✅ 10.2 — Gazebo Harmonic과 ros_gz
• ✅ 10.3 — 센서 시뮬레이션과 플러그인
• ✅ 10.4 — gz_ros2_control과 시뮬 하드웨어
• ✅ 10.5 — Isaac Sim 등 대안 시뮬레이터
• ✅ 10.6 — Sim2Real 간극과 검증

제11부 도구·관측성 (11.2~11.1)

도구와 관측성 — rosbag2, 기록·재생 전략, RViz2, rqt, 트레이싱, 성능 측정, 현장 디버깅. — 문제가 생겼을 때 펼치는 부. 11.1이 그 입구다.

• ✅ 11.2 — rosbag2 심층: MCAP·저장소·성능
• ✅ 11.3 — 기록·재생 전략
• ✅ 11.4 — RViz2와 플러그인 작성
• ✅ 11.5 — rqt·PlotJuggler·시각 분석
• ✅ 11.6 — 트레이싱: ros2_tracing·LTTng
• ✅ 11.7 — 성능 측정: 지연·지터·처리량
• ✅ 11.1 — 현장 디버깅 플레이북

제12부 실시간·성능 (12.1~12.6)

실시간과 성능 — 결정성, RT 커널·스케줄링, 무할당 경로, 엔드투엔드 지연 예산, 안티패턴. — 주기를 지켜야 하는 제어 루프를 다룰 때.

• ✅ 12.1 — 실시간이란 무엇인가: ROS 2에서의 한계
• ✅ 12.2 — RT 커널·스케줄링·CPU 격리
• ✅ 12.3 — 메모리: 잠금·풀·무할당 경로
• ✅ 12.4 — 엔드투엔드 지연 예산 설계
• ✅ 12.5 — 결정성과 실행 순서 제어
• ✅ 12.6 — 성능 안티패턴 카탈로그

제13부 보안 (13.1~13.5)

보안 — 위협 모델, SROS 2, DDS-Security, 운영 보안, 비용·트레이드오프. — 로봇이 네트워크에 연결되는 순간부터 필요하다.

• ✅ 13.1 — 위협 모델: ROS 2 그래프의 공격면
• ✅ 13.2 — SROS2: 키스토어·enclave·정책
• ✅ 13.3 — DDS-Security 플러그인 상세
• ✅ 13.4 — 운영 보안: 격리·업데이트·비밀 관리
• ✅ 13.5 — 보안의 비용: 성능·운영 트레이드오프

제14부 시스템 설계·품질·운영 (14.1~14.10)

시스템 설계·품질·운영 — 노드 분할, 오케스트레이션, launch 심층, 테스트, 품질 수준, 배포·OTA, 플릿, 안전 표준. — 제품으로 만들고 유지할 때.

• ✅ 14.1 — 노드 분할 설계: 경계 긋기
• ✅ 14.2 — 시스템 오케스트레이션: 모드·부팅·감시
• ✅ 14.3 — launch 심층 I: 구조와 substitution
• ✅ 14.4 — launch 심층 II: 대규모 구성
• ✅ 14.5 — 테스트 I: 단위·모의 그래프
• ✅ 14.6 — 테스트 II: launch_testing·통합·HIL
• ✅ 14.7 — 품질 수준·REP 2004·의존성 위생
• ✅ 14.8 — 배포: systemd·Docker·OTA
• ✅ 14.9 — 다중 로봇·플릿 운영
• ✅ 14.10 — 안전 표준과 ROS 2의 위치

제15부 이행·확장 (15.1~15.5)

이행과 확장 — ROS 1에서 넘어오기, 배포판 이동, 커스텀 RMW, 기여·거버넌스. — 기존 자산을 옮기거나 생태계에 참여할 때.

• ✅ 15.1 — Humble→Jazzy 마이그레이션 실무
• ✅ 15.2 — Kilted·Rolling 대비
• ✅ 15.3 — ROS 1 상호운용: ros1_bridge
• ✅ 15.4 — 커스텀 rmw와 확장 포인트
• ✅ 15.5 — 기여·거버넌스·생태계

부록 (A.1~A.6)

찾아보는 참고 자료 — CLI·QoS·환경변수 레퍼런스, REP 색인, 용어집·약어, 참고자료·출처, 역할별 학습 로드맵. — 본문을 읽다 막히거나, 실무 중 빠르게 찾아볼 때.

• ✅ A.1 — CLI 레퍼런스
• ✅ A.2 — QoS·환경변수·설정 레퍼런스
• ✅ A.3 — REP 색인
• ✅ A.4 — 용어집·약어
• ✅ A.5 — 참고자료·출처
• ✅ A.6 — 역할별 학습 로드맵

주제별 실측 색인 — 무엇이 확인됐고 어디에 있나

목차 3의 검증표는 회차순이라 "타이머 지터 수치가 어디 있더라"를 찾기 어렵다. 이 절은 같은 내용을 주제로 다시 연결한다. 현재 70개 절(제목이 — 실측으로 끝나는 절, 2026-08-19·101차 기준 — 신설 없이 기존 절 확장)이 있고, 아래 표는 그중 71개 항목을 다룬다(일부 절은 확정한 것이 둘 이상이라 행이 더 많다).

이 색인의 항목은 전부 Jazzy 실물에서 확인한 것이다. 표기 규약은 목차 5, 검증 범위와 한계는 목차 3을 보라. 재현 방법은 11.7.13(계측 도구 다섯)에 있다.

QoS·통신 경로

실행 모델·동시성·메모리

계층·미들웨어

네트워크·배포·디버깅

좌표·모델·시간

하드웨어·제어·실시간

센서·인지