부록 부록

A.6 역할별 학습 로드맵

A.6.1 이 부록의 사용법

133개 장을 순서대로 읽는 것은 대부분의 독자에게 최선이 아니다. 역할과 당면 과제에 따라 필요한 부분이 다르고, 지금 필요 없는 것을 읽으면 남지 않는다.

이 부록은 역할별·상황별 경로를 제안한다. 각 경로는 "이것만은"(핵심) → "다음에"(확장) → "필요할 때"(참조) 로 구성된다.

정직: 이 로드맵은 제안이며, 자신의 상황에 맞게 조정해야 한다. 순서가 절대적이지 않고, 건너뛰어도 된다. 각 장의 -01 절에 선수 지식이 적혀 있으므로 그것을 참고하라.

A.6.2 모든 역할의 공통 기반

어떤 역할이든 이것부터 시작한다.

견해: 1.6(QoS)과 5.1·5.2(좌표)를 초기에 읽는 것을 강하게 권한다. 이 둘이 초보자가 가장 오래 시행착오를 겪는 영역이고, 모르면 증상이 이해되지 않는다. "데이터가 안 온다"와 "위치가 이상하다"의 대부분이 여기서 나온다.

견해: 11.1을 일찍 읽는 것이 의외로 효율적이다. 아직 모르는 장을 참조하지만, "문제가 생기면 어디를 보는가"의 지도를 먼저 갖는 것이 학습 속도를 높인다. 전부 이해할 필요 없이 구조만 봐 두면 된다.

A.6.3 입문자 — ROS 2를 처음 쓴다

그다음 필요해질 때 펼칠 것:

견해: 0.6(첫 패키지)을 일찍 하라. 읽기만 하면 안 남는다. 작은 노드를 만들어 실행해 보면 이후의 개념이 이해될 자리가 생긴다.

견해: 2.2~2.6(실행 모델)은 처음에는 건너뛰어도 된다. 중요하지만 깊고, 콜백이 실행되지 않거나 느린 문제를 실제로 만난 뒤에 읽으면 훨씬 잘 이해된다.

A.6.4 제어·하드웨어 담당

견해: 6.2(하드웨어 컴포넌트)가 이 역할의 중심이다. 이것 하나를 제대로 만들면 컨트롤러·MoveIt·Nav2가 전부 연결된다(15.4.4). mock 백엔드(6.2.8)로 시작하면 하드웨어 없이도 진행할 수 있다.

견해: 2.2~2.6(실행 모델)이 이 역할에는 필수다. 제어 주기가 깨지는 원인의 대부분이 실행기·콜백 그룹에 있다(2.3·2.4). 공통 기반 다음으로 읽을 것을 권한다.

A.6.5 인지·센서 담당

견해: 7.1(센서 규약)이 이 역할의 첫 장이어야 한다. 단위·프레임·범위 밖 표현 규약을 모르면, 드라이버가 어긴 것을 발견하지 못하고 이후 모든 것이 조용히 틀린다(7.1.8).

견해: 11.3.8(회귀 데이터셋)과 14.6.5(bag 회귀)를 일찍 읽으라. 인지 개발은 데이터셋 기반 반복 개선이 핵심 방법론인데, 이 인프라 없이 시작하면 나중에 만들기 어렵다.

견해: 7.7(시간 정합)이 과소평가된다. 여러 센서를 융합하는 순간 시각 문제가 지배적이 되며, 스탬프를 덮어쓰는 실수(7.7.4) 하나가 전체를 무너뜨린다.

A.6.6 항법 담당

Nav2의 서버는 전부 라이프사이클 노드다(8.1.4). "실행했는데 아무 반응이 없다"의 절반이 여기서 나오므로 1.12(라이프사이클 노드)를 함께 읽으라.

견해: 5.1·5.2를 확실히 이해하지 않고 Nav2를 시작하면 시행착오를 겪는다. map·odom·base_link의 관계(5.1.7)를 모르면 측위 문제와 오도메트리 문제를 구분할 수 없다.

견해: 8.3(코스트맵)이 항법 문제의 최다 원인 지점이다. "왜 못 가는가"의 답이 대개 코스트맵 설정에 있다(8.3.8). 튜닝 전에 코스트맵을 시각화해 보는 습관(8.8)이 시간을 크게 아낀다.

견해: 8.7(안전)을 기능 개발과 함께 읽으라. 항법은 로봇을 움직이므로, 안전 고려가 나중이 되면 위험하다.

A.6.7 매니퓰레이션 담당

견해: URDF·SRDF(5.3~5.5·9.1)가 매니퓰레이션의 기초 공사다. 모델이 부정확하면 계획도 제어도 맞지 않는다. 관성·충돌 형상·조인트 한계를 제대로 넣는 것이 먼저다(5.3.5).

견해: 9.6(정확도·캘리브레이션)을 초기에 읽으라. "계획은 되는데 실제로 안 맞는다"의 원인이 여기 있고, 캘리브레이션 없이 정밀 작업은 불가능하다(9.6.4).

A.6.8 시스템 아키텍트·리드

견해: 14.1(경계 긋기)과 12.4(지연 예산)가 아키텍트의 두 축이다. 하나는 어디에 선을 긋는가, 다른 하나는 시간을 어떻게 배분하는가다. 이 둘이 시스템의 성질을 대부분 결정한다.

견해: 14.10(안전의 위치)를 프로젝트 초기에 읽으라. 안전 요구가 있다면 아키텍처가 그것을 전제로 설계되어야 하고, 나중에 붙이는 것은 어렵다(13.1.10과 같은 논리).

견해: 12.6(성능 안티패턴)을 팀 공유 자료로 쓰라. 리뷰에서 반복 지적하는 것들이 대부분 여기 있으므로, 목록을 공유하면 지적 자체가 줄어든다.

A.6.9 DevOps·플랫폼 담당

견해: 14.8(배포)과 13.4(운영 보안)이 이 역할의 중심이다. "전원을 켜면 기동되는가", "업데이트하고 되돌릴 수 있는가", "누가 접근할 수 있는가" — 이 셋이 운영의 핵심 질문이다.

견해: 4.10(CI)과 14.6(통합 시험)을 함께 읽으라. 로봇 CI는 일반 소프트웨어 CI와 다른 제약(하드웨어·시뮬·시간)이 있어서, 무엇을 어디서 실행할지 설계해야 한다.

A.6.13 ROS 2 위에 만드는 개발자 — 미들웨어·드라이버·프레임워크

BK-02가 말한 2차 독자 중 "ROS 2 위에 무언가를 만드는" 쪽이다. 남이 쓸 드라이버·RMW·확장을 구현하는 사람은 쓰는 사람과 읽는 순서가 다르다 — 계층의 경계와 계약을 먼저 봐야 한다.

견해: 3.5(rmw 계층)를 가장 먼저 읽으라. 무엇을 만들든 "내가 어느 계층에 위치하는가"가 첫 질문이고, 그 답이 API 형태·성능 한계·이식성을 전부 결정한다. RMW를 직접 만들지 않더라도 그 경계를 알아야 위쪽 계층의 제약이 왜 그런지 이해된다.

견해: 만드는 쪽에는 14.7(품질 수준·REP 2004)가 쓰는 쪽보다 훨씬 중요하다. 남이 의존할 패키지라면 문서·테스트·유지보수 약속이 곧 인터페이스의 일부다. 코드가 동작하는 것과 남이 믿고 쓸 수 있는 것은 다르다.

함정: 확장 포인트를 쓰기 전에 "이미 있는 것"을 찾으라. pluginlib·ros2cli 확장·rmw 구현·컨트롤러 인터페이스처럼 이 책이 다룬 확장 지점만 여럿이다(15.4). 새 메커니즘을 만들기 전에 그중 하나로 되는지 보는 편이 대개 빠르다.

A.6.14 연구실·대학원생 — 연구 코드를 시스템으로 발전시킬 때

BK-02가 말한 "연구 코드를 시스템으로 발전시키는" 경로다. 알고리즘은 이미 동작하는데 로봇에 탑재하면 무너지는 상황이 전형이다 — 원인은 대개 알고리즘이 아니라 시간·경계·재현성에 있다.

연구 코드는 대개 Python으로 시작한다 — 2.8(rclpy 심층)을 일찍 읽으면 "왜 느린가"·"왜 콜백이 실행되지 않는가"를 스스로 설명할 수 있다. C++ 예제를 Python으로 옮겨 쓸 때는 2.8.12(비대칭 열 축)를 옆에 펴 두라 — 논문 코드를 포팅하다 겪는 함정이 거기 모여 있다.

견해: 11.3(기록 전략)을 가장 먼저 읽으라. 연구에서 가장 비용이 큰 자산은 다시 만들 수 없는 데이터다. 실험을 bag으로 남겨 두면 알고리즘을 바꿔 가며 같은 입력으로 비교할 수 있고, 이것이 "논문 그림을 다시 그릴 수 있는가"를 가른다(11.2.13.3의 복구 수단도 함께 알아 두라).

견해: "시뮬에선 되는데 실기에선 안 된다"의 대부분은 시간 문제다. 스탬프를 언제 기록하는가(1.10.6), 여러 센서를 어떻게 맞추는가(7.7), 시뮬 시간을 쓰는가(1.10.3) — 알고리즘을 의심하기 전에 이 셋을 확인하라.

함정: 연구 코드는 대개 노드 하나에 전부 들어 있다. 그대로도 실행되지만 문제가 생겼을 때 어디가 느린지 알 수 없다. 14.1(경계 긋기)을 읽고 측정 지점이 생기도록 나누는 것이 첫 리팩터링이다 — 성능을 위해서가 아니라 관측을 위해서다.

견해: 품질 수준(14.7)은 졸업 후를 위한 것이 아니다. 연구실을 떠날 때 코드가 남에게 넘어가는지 버려지는지가 여기서 갈린다. package.xml·README·테스트 하나만 있어도 다음 사람이 이어받을 수 있다.

A.6.10 상황별 진입점

지금 문제가 있어서 왔다면.

A.6.11 학습 방법에 관한 견해

견해: 읽기와 실행을 번갈아 하라. 이 책은 실행 검증 없이 쓰였으므로(A.5.1), 독자가 실행해 보며 읽는 것이 이 책의 한계를 넘는 방법이다. 차이를 발견하면 그것이 여러분 환경의 진실이다.

견해: "함정 카탈로그"를 먼저 읽는 것도 좋은 전략이다. 각 장 뒤에서 두 번째 절에 있으며, 증상 중심으로 정리되어 있어 "이런 문제가 있구나"를 먼저 알면 본문이 잘 읽힌다.

견해: 모르는 것을 표시하며 읽으라. (확인 필요) 표기가 있는 곳은 여러분의 환경에서 확인해야 하는 지점이므로, 확인 결과를 적어 두면 팀의 문서가 된다.

견해: 한 번에 이해하려 하지 말라. 특히 실행 모델(2.2~2.6), QoS(1.6), 실시간(12.1~12.3)은 실제 문제를 만난 뒤에 다시 읽으면 훨씬 잘 이해된다. 처음에는 "이런 것이 있다"만 남겨도 충분하다.

견해: 가장 빠른 학습은 "고장 난 시스템을 고쳐 보는 것"이다. 잘 동작하는 튜토리얼보다, 문제가 있는 상태에서 원인을 좁혀 가는 경험이 훨씬 많이 남는다. 11.1의 절차를 따라 해 보는 것이 좋은 연습이다.

A.6.12 마치며

이 책은 0.1에서 "ROS 2가 무엇인가"로 시작해 133개 장을 지나왔다. 통신과 실행, 좌표와 하드웨어, 센서와 인지, 항법과 조작, 시뮬레이션과 도구, 실시간과 보안, 설계와 운영과 이행.

이 책이 반복한 것을 마지막으로 정리한다.

견해: 이 원칙들은 ROS 2에만 해당하지 않는다. 로봇 시스템을 만드는 일 전반에 적용되며, 도구가 바뀌어도 남는 부분이다. 이 책의 API·명령 서술은 낡겠지만(A.5.7), 이 원칙들은 오래 유효할 것이다.

정직: 이 책은 실행 검증 없이 쓰였고, 틀린 부분이 있을 수 있다(A.5.8). 여러분이 실제로 실행해 확인한 것이 이 책보다 정확하다. 이 책은 시작점이지 종착점이 아니다.

여러분의 로봇이 잘 동작하기를 바란다.