제0부 개관과 출발

0.1 ROS 2란 무엇인가 — 미들웨어·프레임워크·생태계

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

ROS 2를 오래 쓴 사람도 "ROS 2가 정확히 무엇이냐"는 질문에는 잘 답하지 못한다. 통신 라이브러리라고 하면 colcon과 launch가 설명되지 않고, 프레임워크라고 하면 DDS를 직접 다루는 순간이 설명되지 않으며, 미들웨어라고 하면 Nav2·MoveIt 2 같은 거대한 응용 스택이 설명되지 않는다. 이 셋을 하나의 정체로 뭉뚱그리는 순간 디버깅이 막힌다 — 문제가 어느 층에 있는지 모르기 때문이다.

이 장은 ROS 2를 세 개의 분리된 정체로 해부하고, 각 정체가 무엇을 보장하고 무엇을 보장하지 않는지 선을 긋는다. 이 선이 이 책 전체의 지도다.

배우는 것:

• ROS 2의 3중 정체 — ① 분산 통신 미들웨어, ② 개발·실행 프레임워크(빌드·구성·도구 규약), ③ 재사용 패키지 생태계. 각각의 경계와 책임.
• 계산 그래프(computation graph) 모델 — 노드·토픽·서비스·액션·파라미터가 무엇을 추상화하며, 이 추상이 감추는 비용은 무엇인가.
• 계층 스택 — 사용자 코드 → rclcpp·rclpy → rcl → rmw → DDS. 각 계층이 존재하는 이유와 층별로 무엇이 결정되는가.
• ROS 2가 보장하는 것과 보장하지 않는 것 — 특히 "ROS 2는 실시간(real-time)인가"라는 질문의 정확한 답.
• ROS 2를 쓰지 말아야 할 경우 — 이 프레임워크가 손해인 상황.

선수 지식: 리눅스 프로세스·소켓의 기본 개념. 분산 시스템 용어(발행·구독, RPC)에 대한 대략적 이해. ROS 1 경험은 필요 없다(대조는 0.2).

정직: 이 장의 서술은 ROS 2 설계 문서·소스 저장소 구조에 근거하지만, "왜 이렇게 설계했는가"의 일부는 저자의 해석이다. 설계 의도를 단정하는 문장에는 근거(설계 문서·REP)를 붙였고, 해석인 곳은 "견해"로 라벨했다. 또한 이 책의 코드·명령은 이 집필 환경에서 실행 검증되지 않았다(목차 3). 144차(123번째 회차)가 0.1.8의 구체적 보장·비보장 주장 두 가지를 실행 확인했다 — 순서 보장은 정확히 맞았고, 종료된 노드 감지 지연은 "수 초"보다 실제로 훨씬 길었다. 아래 0.1.8을 보라.

0.1.2 이름이 주는 오해 — ROS는 운영체제가 아니다

ROS(Robot Operating System) 라는 이름은 역사적 산물이며, 기술적으로는 오해를 부른다. ROS 2는 프로세스를 스케줄링하지 않고, 메모리를 관리하지 않으며, 하드웨어를 추상화한 커널을 제공하지 않는다. 그 일은 리눅스(또는 Windows·RTOS)가 한다.

ROS 2가 실제로 제공하는 것은 "여러 프로세스가 하나의 로봇처럼 협력하게 만드는 규약과 도구" 다. 운영체제라는 비유가 유효한 지점은 하나뿐이다 — 응용이 서로를 직접 알지 않고도 협력할 수 있게 하는 공통 기반이라는 점. 그래서 ROS 2를 "메타 운영체제"라 부르기도 하지만, 이 책은 그 표현조차 쓰지 않는다. 대신 아래 셋으로 나눠 부른다.

이 셋은 서로 다른 팀이 만들고, 서로 다른 주기로 릴리스되며, 서로 다른 품질 수준을 갖는다(품질 수준은 14.7). 장애가 났을 때 "ROS가 이상하다"가 아니라 "①의 QoS 불일치인가, ②의 빌드·환경 문제인가, ③의 Nav2 파라미터 문제인가"로 좁힐 수 있어야 한다.

0.1.3 정체 ① — 분산 통신 미들웨어

가장 핵심적인 정체다. ROS 2는 여러 프로세스(대개 여러 대의 컴퓨터에 흩어진)가 이름 기반으로 데이터를 주고받게 하는 미들웨어다. 제공하는 것은 다음 네 가지 통신 원시(primitive)와 그것을 뒷받침하는 인프라다.

여기에 디스커버리(누가 어디 있는지 자동으로 찾기), 직렬화(구조체를 바이트로), QoS(신뢰성·내구성·시간 제약의 계약), 타입 검사(같은 메시지 정의를 쓰는지)가 인프라로 연결된다.

이 미들웨어 정체가 주는 실질적 이득은 결합도 제거다. 카메라 드라이버는 자기 이미지를 누가 받는지 모르고, 인지 노드는 이미지가 실제 카메라에서 오는지 rosbag 재생에서 오는지 시뮬레이터에서 오는지 모른다. 이 무지가 곧 교체 가능성이며, 로봇 개발에서 가장 값진 자산이다 — 실기 없이 개발하고(10.1), 기록으로 회귀 시험하며(11.3), 부분만 교체해 실험할 수 있다.

대가도 명확하다. 함수 호출 한 번이면 될 일이 직렬화 → 전송 → 역직렬화 → 콜백 스케줄링이 되고, 그 경로 어디서든 지연·유실·순서 뒤바뀜이 생긴다. 이 책 제1~3부의 대부분은 그 경로를 눈으로 볼 수 있게 만드는 데 쓰인다.

0.1.4 정체 ② — 개발·실행 프레임워크

미들웨어만으로는 로봇을 만들 수 없다. ROS 2는 코드를 어떻게 묶고(패키지), 어떻게 빌드하고(ament·colcon), 어떻게 실행하고(launch), 어떻게 설정하고(파라미터·YAML), 어떻게 관찰할지(CLI·rviz2·rosbag2) 에 대한 규약 묶음을 함께 제공한다.

이 규약이 만드는 효과는 "남의 패키지를 내 로봇에 탑재할 수 있다" 는 것이다. package.xml의 의존성 선언(4.4), rosdep의 시스템 패키지 매핑(4.6), 표준 인터페이스 정의(sensor_msgs·geometry_msgs), 좌표 규약(REP 103·105, 7.1) — 이 공통 기반이 있어서 전 세계의 드라이버와 알고리즘이 조립 가능해진다.

동시에 이 정체는 ROS 2 입문의 가장 큰 마찰 지점이기도 하다. 환경변수·오버레이(0.5), CMake 매크로(4.2), launch 시스템(14.3)은 통신과 아무 관계가 없는데도, 여기서 막히면 아무것도 못 한다. 이 책이 제4부(빌드)와 제14부(launch·테스트)에 상당한 지면을 쓰는 이유다.

0.1.5 정체 ③ — 재사용 패키지 생태계

세 번째 정체는 ROS 2 코어 위에 쌓인 응용 스택이다. 코어(ros2/ros2 저장소 묶음)와는 별개 프로젝트이며, 자체 유지보수 팀·릴리스 주기·품질 수준을 갖는다.

중요한 구분: 코어가 안정적이라는 사실이 생태계 패키지도 안정적이라는 뜻은 아니다. Nav2가 특정 버전에서 회귀를 겪거나, 어떤 드라이버가 Jazzy 지원을 아직 안 했거나, 어떤 패키지가 유지보수자를 잃고 방치되는 일은 흔하다. 의존성을 고를 때 "ROS 2 패키지니까 괜찮다"는 추론은 성립하지 않는다 — 유지보수 상태·품질 선언·이슈 활동을 직접 봐야 한다(14.7).

0.1.6 계산 그래프 — ROS 2가 세상을 보는 방식

ROS 2 응용은 노드(node)의 그래프로 모델링된다. 노드는 "하나의 목적을 가진 계산 단위"이고, 노드 사이의 간선은 토픽·서비스·액션이다.

이 모델의 힘은 그래프가 런타임에 관측 가능하다는 점이다. ros2 node list·ros2 topic info -v·rqt_graph로 실행 중인 시스템의 실제 배선을 볼 수 있다(0.7). 코드를 읽지 않고도 시스템 구조를 파악할 수 있다는 것은 대규모 로봇 소프트웨어에서 대단히 중요한 성질이다.

동시에 이 모델은 세 가지를 감춘다. 이 책의 상당 부분이 이 감춰진 것을 드러내는 작업이다.

1. 간선에도 비용이 든다. 화살표 하나가 직렬화·복사·전송·역직렬화·스케줄링을 뜻한다. 4K 이미지 토픽 하나가 CPU의 절반을 점유하는 일은 흔하다(7.8·12.6).
2. 간선은 계약이 필요하다. 이름과 타입이 같아도 QoS가 맞지 않으면 연결되지 않는다 — 그리고 대개 조용히 실패한다(1.5·1.6). ROS 2 입문자가 가장 많이 잃는 시간이 여기다.
3. 노드는 프로세스가 아니다. 노드는 논리 단위이고, 여러 노드를 한 프로세스에 담을 수 있다(컴포지션, 1.13). 이 선택이 성능을 자릿수 단위로 바꾼다(intra-process 통신, 2.7).

0.1.7 계층 스택 — 위에서 아래로

ROS 2의 내부 구조는 의도적으로 층이 나뉘어 있다. 층마다 교체 가능성과 책임이 다르다.

이 계층 구조가 실무에서 뜻하는 것:

• 증상의 층을 특정하면 절반은 푼 것이다. "토픽이 전혀 안 보인다"는 대개 디스커버리(DDS 층, 3.3·3.9), "보이는데 데이터가 안 온다"는 QoS(rmw 층의 계약, 1.5), "오는데 콜백이 실행되지 않는다"는 executor(rclcpp 층, 2.2~2.4), "실행되는데 느리다"는 직렬화·복사·스케줄링(전 층에 걸침, 11.7·12.4).
• 언어를 바꿔도 의미론은 같다. rclpy와 rclcpp는 rcl을 공유하므로 이름 해석·리매핑·파라미터 규칙이 동일하다. 다른 것은 실행 모델과 성능이다(2.8).
• DDS 벤더를 바꿔도 코드는 그대로다. 다만 성능·디스커버리 동작·설정 방식이 크게 다르다(3.6~3.8). "코드가 같다"와 "동작이 같다"는 전혀 다른 말이다.

0.1.8 ROS 2는 무엇을 보장하는가 — 그리고 무엇을 보장하지 않는가

이 절이 이 장에서 가장 실무적인 부분이다. 잘못된 기대는 잘못된 아키텍처로 이어진다.

보장하는 것(문서화된 계약):

보장하지 않는 것(자주 오해되는 것):

실행 확인(144차, Humble·Jazzy 양쪽) — 순서 보장은 확인됐고, 종료된 노드 감지 지연은 정정이 필요하다.

순서 보장(위 표 확인). 자체 발행자·구독자로 std_msgs::Int32 시퀀스(0..4999)를 속도 제한 없이 최대한 빠르게 발행해, 큐가 감당 못 할 부하를 일부러 만들었다 — 수신된 약 2000개(Jazzy 1410개·Humble 565개, 나머지는 아래 유실) 중 역전(out-of-order)은 0건이었다. "동일 발행자→동일 구독자 순서 유지"는 부하가 커도 정확히 지켜진다.

부수 발견 — "메시지는 반드시 도착한다" 오해(위 표)를 더 강한 형태로 재확인했다. 큐 깊이를 기본값(10)이 아니라 1000으로 넉넉히 두고, 구독자도 spin_some()으로 쉬지 않고 처리했는데도(즉, "느린 구독자" 시나리오가 아닌데도) Jazzy 71%·Humble 87%가 유실됐다. RELIABLE + 깊은 큐라도 발행 속도 자체가 전송·프로토콜 처리량을 넘어서면 유실된다 — 표가 "구독자가 느리면"으로 든 원인 외에, 발행자 폭주도 같은 결과를 낸다는 것이 이번 회차의 새 관찰이다. 정확한 유실 메커니즘(라이터 리소스 한도 대 네트워크 처리량)은 이번 회차에 분리하지 않았다(확인 필요, 다음 회차 후보). (→ 145차 실행 확인: 원인은 큐 깊이가 아니라 발행 속도(burst rate) 그 자체로 좁혀졌다 — 아래 참고.)

145차 후속 — 원인을 좁혔다: 큐 깊이가 아니라 순수 발행 속도다. 같은 부하(5000개, 속도 제한 없음)를 큐 깊이만 10·100·1000·5000·10000으로 바꿔 가며 측정해 봤다 — 수신율이 42%·17%·8%·53%·55%로 깊이와 무관하게 불규칙했고, 같은 깊이(10)를 반복해도 수신율이 42%·10%·16%로 회차마다 크게 흔들렸다(잡음이 깊이 효과를 압도). 결정적 대조 실험: 같은 최소 깊이(10, ROS 2 기본값)에서 발행 사이에 200µs 간격만 주고(속도 제한, 총 소요 시간은 무제한 폭주와 비슷하게 맞춤) 5000개를 다시 보내니 3회 전부 5000/5000(무손실)이었다. 큐를 아무리 깊게 둬도 폭주 상태에서는 소용없고, 얕은 큐라도 속도만 억제하면 완전히 안전하다 — 유실의 실질적 원인은 큐 깊이가 아니라 순수 발행 속도(burst rate)였다. 라이터 리소스 한도 자체가 정확히 어느 지점에서 병목이 되는지(예: 초당 몇 건부터 위험한지)는 이번 회차로도 정량화하지 않았다(확인 필요). 하네스는 tools/gap_harness/gap145/. 목차 3.

종료된 노드 감지 지연 — "수 초"를 정정한다. 컴파일된 talker 바이너리를 직접 kill -9(우아한 종료가 아닌 실제 비정상 종료)로 강제 종료한 뒤, ros2 node list에서 사라질 때까지의 시간을 측정했다 — Jazzy 19231 ms·19224 ms(2회), Humble 19800 ms. 세 번 다 19~20초로 사실상 고정값이었다(Fast DDS 기본 참가자 lease 기간으로 보인다). "수 초 단위"라는 표현이 자연스럽게 암시하는 한 자릿수 초와는 자릿수가 다르다 — 감지에 의존하는 감시·장애조치 설계라면 이 20초 근방의 값을 실제 최소 지연으로 가정해야 한다. 방법론 메모: 처음엔 ros2 run demo_nodes_cpp talker &의 PID를 강제 종료했더니 ros2 run이 자식 프로세스를 fork하는 래퍼라서 실제 노드는 종료되지 않고 30초 넘게 계속 실행 중이었다 — 컴파일된 바이너리를 직접 실행해 그 PID를 강제 종료해야 실제 테스트가 된다(이 자체가 "ros2 run은 대상 실행 파일이 아니다"라는 작은 실무 함정이기도 하다). 목차 3, tools/gap_harness/gap144.

0.1.9 "ROS 2는 실시간인가" — 정확한 답

가장 자주 나오는 질문이고, 가장 자주 잘못 답해지는 질문이다. 정확한 답은 이렇다.

*ROS 2 자체는 실시간 보장을 제공하지 않는다. 그러나 ROS 2는 실시간 시스템을 만드는 것을 방해하지 않도록 설계된 부분을 갖고 있다.*

실시간성은 "빠름"이 아니라 "최악 지연의 상한(worst-case bound)이 증명 가능한가" 의 문제다(12.1에서 정식화한다). 그 상한은 다음 모든 층이 함께 결정한다.

ROS 2가 제공하는 실시간 친화적 요소: 무할당 경로를 위한 allocator 커스터마이징과 loaned message(2.6), 메시지 복사를 없애는 intra-process·zero-copy(2.7), 실행 순서를 통제할 수 있는 콜백 그룹·executor 선택(2.3·2.4), 실시간 안전한 자료구조를 쓰는 realtime_tools(ros2_control 계열, 6.6).

ROS 2가 제공하지 않는 것: 기본 경로의 무할당 보장(기본 rclcpp 경로에는 동적 할당과 뮤텍스가 있다), executor의 우선순위 기반 결정론적 스케줄링, DDS 내부 스레드의 실시간 보장(벤더·설정 의존), 그리고 무엇보다 OS 수준 보장(PREEMPT_RT 커널·CPU 격리·메모리 잠금은 사용자가 구성해야 한다, 12.2·12.3).

실무적 결론(견해): 밀리초 이하의 경성 실시간 루프(예: 1 kHz 토크 제어)는 ROS 2 통신 경로 밖에서 실행하는 것이 안전하다 — 실시간 스레드는 ros2_control의 제어 루프나 별도 RT 프로세스·MCU(6.8)에 두고, ROS 2 토픽은 그 루프와 비실시간 경계를 넘는 통로로 쓴다. 반대로 10~100 Hz의 연성 실시간(항법·인지)은 ROS 2 경로 안에서 충분히 다룰 수 있다. 근거는 12.1~12.4에서 지연 예산으로 전개한다.

0.1.10 ROS 2를 쓰지 말아야 할 때

프레임워크의 가치를 아는 방법은 그것이 손해가 되는 경우를 아는 것이다. 다음 상황에서 ROS 2는 비용이 이득을 넘는다.

• 단일 프로세스로 충분하고, 외부 재사용 계획이 없는 소프트웨어 — 통신 미들웨어의 이득(교체 가능성·관측성)이 없는데 빌드·환경·직렬화 비용만 낸다. 라이브러리로 만들고 필요할 때 ROS 2 래퍼를 씌우는 편이 낫다(이 구조는 14.1의 핵심 권고이기도 하다).
• 경성 실시간 제어 루프 자체 — 위 0.1.9.
• 자원이 극도로 제약된 MCU 단독 시스템 — 표준 ROS 2는 리눅스급 자원을 전제한다. MCU라면 micro-ROS를 검토하되(6.8), 그조차 부담이 크면 자체 프로토콜이 맞다.
• 안전 인증(IEC 61508·ISO 13849 등)이 요구되는 안전 기능 경로 — ROS 2 코어는 일반적으로 안전 인증 제품이 아니다. 안전 기능은 인증된 별도 채널(안전 PLC·안전 릴레이)에 두고 ROS 2는 비안전 경로로 쓰는 구조가 표준적이다(14.10).
• 초저지연 대용량 스트리밍이 유일한 요구 — 예컨대 카메라 원본을 GPU로만 넘기면 되는 경우, ROS 2를 거치는 것보다 전용 경로가 단순하다. 다만 관측성·기록(11.2)을 잃는다는 점은 계산에 넣어야 한다.

반대로 ROS 2가 확실히 이득인 경우: 여러 팀이 각자 노드를 만들고 조립해야 할 때, 하드웨어가 아직 없어 시뮬레이션·기록으로 개발해야 할 때, 현장 데이터를 기록해 회귀 시험을 실행해야 할 때, 검증된 항법·매니퓰레이션 스택을 재사용해야 할 때. 즉 시스템이 커지고 사람이 늘어날수록 이득이 커진다.

0.1.11 이 책의 지도 — 어디서 무엇을 다루나

앞으로 다룰 내용을 이 장의 3중 정체에 대응시키면 다음과 같다.

가로지르는 주제(실시간·성능 제12부, 보안 제13부)는 세 정체 모두에 걸친다 — 그래서 뒤로 뺐다. 앞부분을 읽지 않고 제12부부터 읽으면 용어가 걸린다.

0.1.12 체크포인트

• ROS 2의 세 정체를 구분해 말할 수 있는가 — 통신 미들웨어, 개발·실행 프레임워크, 패키지 생태계. 셋의 릴리스 주기와 품질 보증이 왜 다른지 설명할 수 있는가.
• 계층 스택 5층(사용자 코드 · rclcpp/rclpy · rcl · rmw · rmw 구현+DDS)을 순서대로 말하고, 각 층에서 결정되는 것을 하나씩 댈 수 있는가.
• "토픽이 안 보인다", "보이는데 데이터가 없다", "데이터는 오는데 콜백이 늦다" — 각각을 어느 층의 문제로 좁힐 것인가.
• ROS 2가 보장하지 않는 것 다섯 가지를 말할 수 있는가(전달 보장, 전역 순서, 즉시 실행, 즉시 장애 감지, 기본 보안).
• "ROS 2는 실시간인가"에 한 문장으로 정확히 답할 수 있는가. 1 kHz 토크 제어 루프를 ROS 2 콜백 안에 두는 설계의 위험을 설명할 수 있는가.
• 현재 담당 시스템에서 ROS 2를 쓰지 않는 편이 나은 컴포넌트가 있는지 하나 지목해 보라. 그 판단 근거는 0.1.10의 어느 항목인가.

다음 장 0.2는 이 설계가 ROS 1에서 어떻게 도달했는지를 다룬다 — 무엇을 버리고 무엇을 얻었으며, 그 대가로 어떤 새 문제가 생겼는지. ROS 1 경험이 없다면 "왜 이렇게 복잡한가"에 대한 답으로 읽어도 좋다.