제15부 이행·확장

15.5 기여·거버넌스·생태계

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

이 책은 126개 장에 걸쳐 ROS 2를 사용하는 법을 다뤘다. 이 장은 관점을 바꾼다 — 이 소프트웨어는 누가, 어떻게 만들고 유지하는가.

이것을 아는 것이 실무에 도움이 되는 이유는 세 가지다. 첫째, 문제를 만났을 때 어디에 물어야 하는지 알게 된다. 둘째, 왜 어떤 것은 빨리 고쳐지고 어떤 것은 안 고쳐지는지 이해하게 된다. 셋째, 필요한 것을 얻는 가장 효과적인 방법이 기여인 경우가 많다(15.4.8).

배우는 것:

• 생태계 구조 — 누가 무엇을 만드는가.
• 거버넌스 — 결정은 어떻게 내려지는가.
• 정보를 찾는 법 — 어디를 보는가.
• 질문하는 법 — 답을 얻는 방법.
• 기여 — 버그 보고부터 코드까지.
• 조직 차원의 참여 — 회사가 할 수 있는 것.

선수 지식: 14.7(품질 수준), 15.2(배포판 주기), 15.4(확장), A.3(REP 색인 — 함께 읽으면 좋다).

정직: 거버넌스 구조·조직명·절차는 시간에 따라 변한다. 15.5.3·15.5.6이 인용하는 구조(OSRA·TGC·ROS PMC 체계, Contributing 문서의 원칙·메인테이너 절차)는 ros2/ros2_documentation 저장소의 Governance.rst·Contributing.rst를 2026년에 직접 읽어 옮긴 것이며, 명령을 실행해 검증한 것이 아니라 공식 문서를 그대로 인용한 것이다(목차 3의 검증 범위와는 다른 종류의 확인이다 — 컨테이너 실행이 아니라 출처 확인). 이 장은 특정 조직·인물을 평가하지 않으며, 구체적 인원·소속은 계속 바뀌므로 이 책은 구조와 절차만 인용하고 구성원 명단은 옮기지 않는다(확인 필요: 현재 명단은 공식 거버넌스 문서).(→ 195차 확인: ros2_documentation을 git clone으로 직접 재확인했다 — 거버넌스 구조 인용은 한 글자도 틀리지 않고 정확했지만, 이 장이 쓰는 커뮤니티 포럼 도메인(discourse.ros.org)은 옛 주소였다 — 실제로는 discourse.openrobotics.org로 옮겨 갔다. ros2 doctor 명령도 실제로 존재하고 유용함을 확인했다. 아래 각 절의 실행 확인(195차) 참고.)

15.5.2 생태계 구조

견해: "주요 스택은 독립 프로젝트"라는 점이 실무에 중요하다. Nav2와 MoveIt은 각각 자체 거버넌스·릴리스 일정·이슈 트래커를 갖는다. 문제를 코어에 보고하면 답을 못 받고, 해당 프로젝트에 가야 한다. "어디에 속한 문제인가"를 먼저 판별하는 것이 시간을 아낀다.

견해: 드라이버 계층의 품질 편차가 가장 크다. 벤더가 공식 지원하는 것, 커뮤니티가 유지하는 것, 한 사람이 만들고 떠난 것이 섞여 있다. 14.7.4의 평가를 특히 이 계층에 적용해야 한다.

정직: "코어"가 실제로 얼마나 넓은지는 숫자로 보면 규모를 가늠할 수 있다. ros2_documentation의 거버넌스 문서(2026년 확인)는 ROS PMC가 직접 관리하는 저장소를 145개 나열한다 — rclcpp·rmw·rosidl 같은 실제 코어부터 rviz·rqt_* 계열 도구, image_common·laser_geometry 같은 인지 유틸리티, 심지어 robot_state_publisher·urdf 같은 이 책의 다른 부에서 다루는 패키지까지 포함한다. "코어"의 경계가 생각보다 넓고, 15.5.2의 표에서 "도구"로 분류한 것들도 상당수 코어와 같은 거버넌스 아래 있다는 뜻이다 — 다만 이것이 곧 모든 145개 저장소의 품질이 균일하다는 뜻은 아니다. 관리 주체가 같다는 것과 유지보수 활발도는 별개다(15.5.8).

15.5.3 거버넌스

결정이 어떻게 내려지는가.

15.5.3.1 실제 구조(2026년 확인)

2024년부터 ROS 2는 Open Source Robotics Alliance(OSRA)의 관리 아래 있다. 위에서 아래로 세 층이다.

정직: 위 구조는 ros2_documentation의 Governance.rst(2026년 확인)를 그대로 옮긴 것이다. 구체적 구성원 명단(2026년 확인 시점 기준으로 PMC 구성원 다수·커미터 다수가 등재돼 있었고, 소속은 한 회사에 쏠리지 않고 KUKA·eProsima·Intrinsic·Honu Robotics·Outrider·Polymath Robotics·FieldAI 등 여러 조직과 독립 개발자가 섞여 있었다)은 이 책이 확정적으로 옮기지 않는다 — 명단은 자주 바뀌고, 이 장은 특정 인물을 평가하지 않는다는 원칙(15.5.1)과도 맞다. 다만 "한 회사가 아니라 여러 조직이 참여한다"는 사실 자체는 15.5.8의 "여러 조직의 사용" 신호와 정확히 같은 종류의 증거다.

PMC 회의는 매주 화요일 17:00 UTC에 Zoom으로 열리고, 커뮤니티는 관찰할 수 있으며 PMC 구성원을 통해 안건을 제출할 수 있다(공개 캘린더로 접속 정보 제공). 논의를 지켜보고 싶다면 이 회의가 가장 직접적인 창구다 — discourse.ros.org의 게시판보다 실시간성이 높다(→ 195차 정정: 이 회의 시각·구성 서술은 Governance.rst와 한 글자도 다르지 않게 정확했지만, 게시판 주소는 옛 도메인이다 — 아래 실행 확인(195차) 참고).

실행 확인(195차) — 위 거버넌스 구조 전체를 github.com/ros2/ros2_documentation을 직접 git clone해 원문과 대조했다. 결과는 한 글자도 틀리지 않았다: "Since 2024, the ROS 2 project has been governed by the Open Source Robotics Alliance (OSRA)"가 원문 그대로 있었고, TGC 구성("a combination of paid members, project management leaders, OSRF leaders, and members based on merits")·ROS PMC 구성("the Project Leader, the ROS PMC Members (who have full voting rights), a Supporting Individual Representative, and the Chair of the TGC")·회의 일정("every Tuesday at 17:00 UTC")까지 전부 원문과 정확히 일치했다. 다만 커뮤니티 포럼 주소는 낡았다 — 이 절과 15.5.4·15.5.6이 쓰는 discourse.ros.org는 저장소 전체에서 정확히 3번만 나오는데, 그 3번 전부 2020~2023년 릴리스 노트(Foxy·Galactic·Iron)가 그 시절의 논의 링크를 연결해 둔 것이었다 — 포럼이 그사이 이사했다. 현재 문서(Governance.rst·Contributing.rst·Contact.rst·Roadmap.rst·2024~2025년 게시물 전부)는 예외 없이 discourse.openrobotics.org(27회 등장, ROS 카테고리는 discourse.openrobotics.org/c/ros/111)를 쓴다. 책이 옛 주소를 그대로 옮긴 것으로 보인다 — 정정한다. 원본: tools/gap_harness/gap194/governance_check/(Governance.rst·Contributing.rst·findings.log·findings_summary.txt).

견해: REP를 읽는 습관이 생태계를 이해하는 가장 빠른 길이다(A.3). "왜 이렇게 설계되었나"에 대한 답이 대부분 REP에 있고, 논의 과정과 기각된 대안까지 기록되어 있어 맥락을 준다. REP 자체의 세 종류·발의 절차는 15.2.4에서 다뤘다 — 함께 읽으라.

견해: "왜 이 기능이 없는가"의 답이 대개 REP나 이슈 논의에 있다. 없는 것이 아니라 의도적으로 안 만든 것이거나, 논의 중이거나, 다른 방식으로 해결하도록 설계된 경우가 많다. 불평하기 전에 찾아보면 대개 답이 있다.

견해: "PMC가 병합을 결정한다"는 구조를 알면 큰 PR을 제출하는 태도가 달라진다. PR을 병합하는 것은 익명의 자동 절차가 아니라, 능력 기반으로 선정된 소수의 사람이 자신의 판단으로 승인하는 행위다. 15.5.6의 "논의 없이 큰 PR을 제출하면 안 되는 이유"가 여기서 더 구체적으로 이해된다 — 그 사람들의 시간과 신뢰를 쓰는 일이기 때문이다.

15.5.4 정보를 찾는 법

문제를 만났을 때 어디를 보는가.

견해: "소스가 최종 진실"이라는 원칙을 편하게 받아들이라. 문서가 불명확하거나 낡았을 때, 소스를 여는 것이 추측보다 빠르다. 특히 기본값·동작 순서·예외 처리는 소스에서만 확실히 알 수 있는 경우가 많다.

함정: 블로그·영상은 배포판이 다를 수 있다. ROS 1 자료가 ROS 2 검색에 섞이고, 옛 배포판 자료가 상위에 나타난다. 날짜와 배포판을 먼저 확인하는 습관이 필요하다 — 이 책도 마찬가지이며, Jazzy 기준으로 쓰였고 시간이 지나면 낡는다(목차 3).

견해: 이슈 트래커 검색이 과소평가된 수단이다. 우리가 만난 문제를 이미 누군가 겪었을 확률이 높고, 닫힌 이슈에 해법이 있는 경우가 많다. 오류 메시지의 특징적인 부분으로 검색하면 대개 나온다.

15.5.5 질문하는 법

답을 얻는 확률을 높이는 방법이다.

견해: "최소 재현 예제"를 만드는 과정에서 스스로 답을 찾는 경우가 많다. 문제를 좁히다 보면 원인이 드러나기 때문이다. 질문을 준비하는 것 자체가 디버깅이라는 점에서, 이것은 손해 보는 일이 아니다.

견해: 환경 정보를 빠뜨리면 답을 못 받는다. 배포판·RMW·설치 방식에 따라 동작이 다르므로, 이 정보가 없으면 아무도 답할 수 없다. ros2 doctor 같은 진단 출력을 함께 붙이는 것도 방법이다(확인 필요: 명령)(→ 195차 확인: 실제로 존재하고 그대로 유용하다 — 아래 실행 확인(195차) 참고).

실행 확인(195차) — ros2 doctor를 실제로 실행했다. ros2 doctor는 실제 명령이며 "All 5 checks passed"처럼 즉시 통과·실패 여부를 알려준다(패키지별 최신 버전 대비 경고도 함께 낸다). ros2 doctor --report는 더 상세한 보고서를 내는데, 네트워크 설정(인터페이스·IP·MTU)과 설치된 모든 ROS 패키지의 로컬·최신 버전 전체 목록을 담고 있었다 — 정확히 이 절이 권하는 "환경 정보"에 해당하는 실제 출력이었다. 원본: tools/gap_harness/gap194/governance_check/findings.log.

견해: "장소를 맞추는 것"이 응답률을 크게 좌우한다. Nav2 문제를 일반 포럼에 게시하는 것보다 Nav2 저장소 이슈에 등록하는 것이 답을 얻을 확률이 높다. 15.5.2의 계층 구분이 여기서 실용적 의미를 갖는다.

15.5.6 기여

필요한 것을 얻는 가장 효과적인 방법인 경우가 많다.

견해: "좋은 버그 보고"가 가장 저평가된 기여다. 재현 가능한 보고 하나가 여러 사용자의 문제를 해결하고, 만드는 비용은 질문을 잘 준비하는 것과 같다(15.5.5). 어차피 문제를 조사했다면 보고까지 하는 비용은 작다.

공식 Contributing 문서가 시작 전에 지키라고 명시하는 네 가지 원칙(ros2_documentation, 2026년 확인)이 있다 — 이 책의 여러 견해가 실은 이 원칙들의 구체화다.

"어디서부터 시작할까"에 대한 실무 답도 문서에 있다. help wanted·good first issue 라벨이 붙은 이슈를 GitHub에서 검색하도록 안내하며, 아이디어를 논의할 곳은 discourse.ros.org(→ 195차 정정: 옛 주소, 현재는 discourse.openrobotics.org — 아래 실행 확인(195차) 참고)의 ROS 포럼이다. 큰 변경일수록 구현 전에 포럼에서 먼저 제안하라는 것이 문서의 명시적 조언이다 — 15.5.6 아래 "함정: 큰 PR을 예고 없이 제출하면…"이 바로 이 조언의 반대 사례다.

정직: 위 네 원칙과 라벨·포럼 안내는 ros2_documentation의 Contributing.rst를 그대로 옮긴 것이며(2026년 확인), 그 이후 문서가 개정됐을 수 있다(확인 필요)(→ 195차 확인: git clone으로 재확인하니 네 원칙·라벨 안내는 원문 그대로였다 — 아래 실행 확인(195차) 참고).

실행 확인(195차) — Contributing.rst를 직접 대조했다. 네 원칙("Respect what came before"·"Engage Open Robotics as early as possible"·"Adopt community best-practices..."·"Think about the community as a whole")과, 논의 없이 구현부터 하면 "거절되거나 설계를 크게 다시 하라는 요청을 받을 위험"을 진다는 문구까지 원문과 정확히 일치했다. help wanted·good first issue 라벨 안내도 실재했다. 다만 포럼 링크는 여기서도 낡아 있었다 — 정확한 현재 주소는 discourse.openrobotics.org/c/ros/111이다(15.5.3의 실행 확인(195차) 참고, 같은 도메인 이전).

견해: 문서 개선이 진입 장벽이 가장 낮다. 우리가 시행착오를 겪은 지점은 다른 사람도 겪는다. "이 부분이 불명확했다"를 고치는 PR은 리뷰가 빠르고, 기여 절차를 익히는 좋은 시작점이다.

코드 기여의 실무:

함정: 큰 PR을 예고 없이 제출하면 병합되지 않을 가능성이 높다. 방향이 프로젝트 계획과 다르거나, 리뷰 부담이 커서 미뤄진다. 먼저 이슈로 논의하고 합의한 뒤 작게 나눠 제출하는 것이 실효성 있는 경로다.

견해: 메인테이너의 시간은 희소 자원이다. 대부분 자원봉사이거나 다른 업무와 병행한다. 리뷰가 느린 것을 무성의로 해석하지 말고, 작고 명확한 변경으로 리뷰 부담을 줄이는 것이 협조적이다.

메인테이너가 되는 길도 공식 문서가 절차로 명시해 둔다. ros2·ament 조직의 각 저장소는 별도의 메인테이너 집합을 가지며, 초대는 초청제(invitation-only)다 — 신청서를 내는 절차가 아니다. 조건은 두 가지다: 최근 1년 안에 그 저장소에 상당한 양의 코드 기여를 했고, 최근 1년 안에 들어오는 PR을 상당량 리뷰했어야 한다. ROS 2 팀은 약 3개월마다 전체 저장소의 기여 현황을 검토해 새 메인테이너를 초대하고, 초대를 수락하면 짧은 교육 과정을 거친 뒤 쓰기 권한을 받는다.

견해: "PR 몇 개 병합됐다고 메인테이너가 되는 것이 아니라, 코드와 리뷰 둘 다 상당량 필요하다"는 조건이 실질적인 신호다. 코드만 내고 리뷰를 안 하는 기여자는 후보에서 빠진다 — 리뷰도 기여로 친다는 뜻이다. 15.5.6의 "③ 질문에 답하기"가 왜 기여 형태로 꼽혀 있는지가 여기서 더 분명해진다. 3개월이라는 주기는 "당장 급하게 요청해서 되는 일이 아니다"라는 것도 말해 준다 — 메인테이너가 되고 싶다면 꾸준함이 신청서보다 낫다.

견해: 기여 시점을 이행 계획에 넣으라. 필요한 기능을 상류에 넣으면 다음 배포판부터는 유지 부담이 사라진다(15.4.8). 다만 병합까지 시간이 걸리므로, 그동안은 로컬 패치로 운용하는 이중 경로를 준비한다.

15.5.7 조직 차원의 참여

회사가 할 수 있는 것들이다.

견해: "업스트림 우선"을 정책으로 두면 장기 비용이 준다. 급할 때 로컬 패치를 쓰되, 기여를 기본 경로로 정하면 포크 부채가 쌓이지 않는다(14.7.6). 이것은 개인의 선의가 아니라 조직의 유지보수 전략이다.

견해: 의존하는 프로젝트의 건강이 우리 시스템의 건강이다(14.7.2의 전이성). 핵심 의존성이 유지보수 부족으로 정체되면 우리가 영향을 받는다. 후원·기여가 자기 이익에 부합하는 구조다.

견해: "우리가 쓰는 것에만 기여해도 충분하다." 생태계 전체에 기여할 필요는 없고, 의존성 목록(14.7.5)에 있는 것들에 버그 보고와 작은 수정을 하는 것만으로도 실질적 참여다.

15.5.8 생태계를 읽는 눈

패키지·프로젝트를 평가하는 관점이다(14.7.3의 연장).

견해: "기여자가 한 사람뿐"이 가장 큰 위험 신호다. 그 사람이 떠나면 프로젝트가 멈추고, 우리는 포크하거나 대체를 찾아야 한다. 핵심 의존성일수록 이 축을 확인하라(14.7.4의 ⑤ 이탈 비용).

견해: "여러 조직이 운영에 쓰고 있는가"가 강한 신호다. 실전에서 검증되었다는 뜻이고, 유지보수가 계속될 가능성이 높다. 논문·데모용으로만 쓰인 것과는 성숙도가 다르다.

15.5.9 제15부를 마치며

제15부가 반복한 것은 셋이다.

1. 이행은 이벤트가 아니라 지속적 활동이다. 미룰수록 격차가 커지고 위험이 비선형으로 는다. 평소에 조금씩 준비하면 각 이행이 작아진다(15.1·15.2).
2. 기본값과 내부에 의존하지 말라. 명시적 설정, 공개 API, 표준 규약에 기대는 코드가 오래 간다. 이것이 이행 비용을 구조적으로 줄이는 방법이다(15.1.9·15.2.5).
3. 혼자 유지하지 말라. 확장은 만드는 비용보다 유지 비용이 크고, 상류에 넣으면 그 부담이 사라진다. 의존하는 프로젝트의 건강이 우리 시스템의 건강이다(15.4.8·15.5.7).

여기까지가 제15부 이행·확장이며, 이 책의 본문이 끝난다.

0.1에서 "ROS 2가 무엇인가"로 시작해, 계산 그래프와 실행 모델과 미들웨어를 지나, 좌표와 하드웨어와 센서를 거쳐, 항법과 조작과 시뮬레이션을 다루고, 도구와 실시간과 보안을 살피고, 시스템 설계와 운영과 이행에 이르렀다. 127개 장이다.

남은 것은 부록(A.1~A.6) — 찾아보기 위한 자료들이다. CLI 레퍼런스, QoS·환경변수 레퍼런스, REP 색인, 용어집, 참고자료, 그리고 역할별 학습 로드맵.

15.5.10 함정 카탈로그

15.5.11 체크포인트

• 생태계의 다섯 계층과 각각의 성격은?
• "주요 스택은 독립 프로젝트"라는 사실의 실무적 함의는?
• 품질 편차가 가장 큰 계층과 그 대처는?
• 거버넌스 수단 다섯 가지와, REP를 읽는 것의 가치는?
• "왜 이 기능이 없는가"의 답이 어디에 있는가.
• 정보 출처 여섯 가지의 강점·한계와, "소스가 최종 진실"의 의미는?
• 블로그·영상 참고 시 주의점은?
• 이슈 트래커 검색이 과소평가된 이유는?
• 좋은 질문의 여섯 요소와, 최소 재현 예제를 만드는 부수 효과는?
• 질문 장소가 응답률을 좌우하는 이유는?
• 기여 다섯 형태와 각각의 난이도·가치는?
• "좋은 버그 보고"가 저평가된 기여인 이유는?
• 코드 기여의 다섯 단계와, 큰 PR을 예고 없이 제출하면 안 되는 이유는?
• 기여 시점을 이행 계획에 넣으라는 조언과, 그동안의 이중 경로는?
• 조직 차원 참여 여섯 가지와, "업스트림 우선"이 유지보수 전략인 이유는?
• 프로젝트 평가의 일곱 신호와, 가장 큰 위험 신호는?
• 제15부가 반복한 세 원칙을 말할 수 있는가.
• OSRA·TGC·ROS PMC 세 층의 역할을 구분할 수 있는가.
• ROS PMC 회의는 언제 열리고, 커뮤니티는 어떻게 참여할 수 있는가?
• 공식 Contributing 문서가 명시하는 네 원칙과, "설계 단계부터 참여시키라"는 원칙을 어기면 어떤 위험이 있는가?
• 메인테이너 초대의 두 조건과, "약 3개월마다"가 말해 주는 것은?
• ROS PMC가 관리하는 저장소가 145개라는 사실이 "코어"의 경계에 대해 말해 주는 것은?