Booil Jung

ROS2 RViz2 소스 코드 구조

RViz2는 로봇 운영 체제(Robot Operating System, ROS) 생태계에서 가장 중요한 3D 시각화 도구 중 하나로, 로봇의 센서 데이터, 상태 정보, 알고리즘 결과 등을 직관적으로 확인하고 디버깅하는 데 필수적인 역할을 수행한다. 단순한 데이터 플로팅 도구를 넘어, RViz2는 고도로 모듈화되고 확장 가능한 프레임워크로 설계되었다. 본 보고서는 RViz2의 소스 코드를 심층적으로 분석하여 그 근간을 이루는 아키텍처 설계 철학, 핵심 컴포넌트의 상호 작용 방식, 그리고 강력한 확장성을 가능하게 하는 플러그인 시스템을 해부한다. 이 분석은 RViz2를 활용하여 복잡한 커스텀 플러그인을 개발하거나, 성능 문제를 해결하거나, 혹은 코어 코드베이스에 직접 기여하고자 하는 고급 개발자 및 연구자를 대상으로 한다. 본 보고서는 표면적인 API 사용법을 넘어, 설계 결정의 이면에 있는 “왜”를 탐구함으로써 RViz2 시스템에 대한 근본적인 이해를 제공하는 것을 목표로 한다.

RViz2는 단일 애플리케이션이 아니라, 세심하게 설계된 프레임워크의 집합체이다. 이 섹션에서는 RViz2의 고수준 아키텍처를 분해하고, 핵심 패키지 간의 관심사 분리(Separation of Concerns) 원칙이 어떻게 모듈성, 추상화, 확장성을 극대화하는지 분석한다.

RViz2 아키텍처를 관통하는 핵심 원칙은 책임의 엄격한 분리이다. 이는 단순한 코드 구성을 넘어 복잡성을 관리하고, 병렬 개발을 촉진하며, 장기적인 유지보수성을 확보하기 위한 전략적 결정이다. 이러한 설계 철학은 패키지 구조에서 명확하게 드러난다. 핵심 로직, 렌더링, 기본 플러그인, 그리고 애플리케이션 진입점은 물리적으로 분리된 패키지에 존재한다.

각 패키지의 책임과 그 안에 포함된 주요 클래스 및 기능에 대한 상세한 분석은 다음과 같다. 개발자가 코드베이스를 처음 접할 때, 이 구조를 이해하는 것은 필수적이다.

패키지 이름 주요 역할 및 책임 핵심 클래스/컴포넌트
rviz_common 비-GUI, 비-렌더링 핵심 로직. 플러그인 인터페이스, 프로퍼티 시스템, TF 변환 관리 등 애플리케이션의 상태와 로직을 총괄. VisualizationManager, FrameManager, Display, Tool, Property
rviz_rendering 3D 렌더링 엔진(OGRE)에 대한 추상화 계층. 씬(Scene) 관리, 객체 생성, 렌더링 창 제어 API 제공. OgreRenderWindow, SceneManager, ManualObject
rviz_default_plugins rviz_common의 인터페이스를 구현하는 기본 플러그인 세트. 외부 플러그인 개발을 위한 참조 예제 역할 수행. GridDisplay, PointCloud2Display, MarkerDisplay, InteractiveMarkerTool
rviz_ogre_vendor OGRE 3D 렌더링 엔진 라이브러리를 벤더링(vendoring)하는 패키지. rviz_rendering이 의존함. -
rviz2 애플리케이션의 진입점(entry point). Qt 애플리케이션을 생성하고 VisualizationManager를 초기화하여 전체 시스템을 부트스트랩. main() 함수, Application 클래스

RViz2의 모듈식 구조는 단순한 코드 정리를 넘어, 시스템의 미래와 유지보수성에 깊은 영향을 미치는 전략적 선택이다.

첫째, RViz2는 미래 기술 변화에 대비하고 렌더링 백엔드에 대한 독립성을 확보하도록 설계되었다. rviz_common과 rviz_rendering 사이의 엄격한 분리는 전체 시스템에서 가장 중요한 아키텍처 결정이다. 이 분리는 시각화 로직과 특정 렌더링 엔진(현재는 OGRE)을 분리하는 추상화 계층을 생성한다. rviz_common과 rviz_default_plugins는 rviz_rendering에 정의된 추상 API에 의존할 뿐, rviz_ogre_vendor 패키지에 직접 의존하지 않는다. 이는 핵심 로직과 플러그인들이 자신들이 OGRE와 통신하고 있다는 사실을 인지하지 못함을 의미한다. 결과적으로, 이론적으로는 새로운 렌더링 엔진(예: Vulkan, WebGPU)을 지원하기 위해 새로운 rviz_vulkan_vendor 패키지와 rviz_rendering API의 새로운 구현체(rviz_rendering_vulkan)를 만들기만 하면 된다. 이 경우, rviz_common과 rviz_default_plugins에 있는 기존의 모든 로직과 플러그인은 코드 변경 없이 그대로 작동할 것이다. 이는 RViz2가 미래의 그래픽스 기술 동향에 적응할 수 있도록 하는 강력한 장기적 생존 전략이다.

둘째, “플러그인 우선” 설계는 새로운 기능 기여에 대한 진입 장벽을 낮춘다. rviz_default_plugins를 별도의 패키지로 분리한 것은 미묘하지만 심오한 설계 선택이다. 이로 인해 “내장된” 표준 시각화 기능들이 서드파티 커스텀 플러그인과 완전히 동일한 구조와 방식으로 취급된다. 새로운 시각화 기능을 만들고자 하는 개발자는 rviz_common이나 rviz_rendering의 복잡한 내부 구조를 깊이 이해할 필요가 없다. 대신 rviz_default_plugins에 있는 PointCloud2Display나 MarkerDisplay와 같은 구현체들을 표준적인 예제로 참고하면 된다. 기본 플러그인이 외부 플러그인과 정확히 동일한 패턴을 따르기 때문에, 신규 플러그인 개발자의 학습 곡선은 현저하게 완만해진다. 이는 RViz2의 커스텀 플러그인 생태계가 풍부하고 다양해지는 직접적인 원인이 되며, 커뮤니티의 기여를 훨씬 더 용이하게 만든다.

이 섹션에서는 데이터가 RViz2 시스템을 통해 흐르는 과정을 면밀히 추적한다. sensor_msgs/msg/PointCloud2 메시지를 사례 연구로 삼아, Display 플러그인에 의해 수신된 후 3D 씬의 픽셀로 최종 렌더링되기까지의 여정을 따라간다. 이 분석은 메시지 처리, 좌표 변환, 렌더링 엔진 간의 상호 작용을 명확히 보여줄 것이다.

데이터의 여정은 Display 플러그인이 ROS2 토픽을 구독하면서 시작된다. Display의 서브클래스들은 rclcpp::Subscription을 사용하여 메시지를 수신한다. 여기서 핵심적인 역할을 하는 컴포넌트는 tf2_ros::MessageFilter이다. 이 필터는 수신된 메시지를 버퍼에 저장하고, 해당 메시지를 시각화하는 데 필요한 좌표계 변환(TF) 정보가 사용 가능해질 때까지 대기시킨다. 이는 경쟁 상태(race condition)를 방지하고 데이터가 항상 올바른 위치에 렌더링되도록 보장하는 필수적인 장치이다. 메시지 필터가 메시지를 통과시키면, Display 기본 클래스 인터페이스의 핵심인 processMessage 함수가 호출되어 본격적인 처리 파이프라인이 시작된다.

어떤 렌더링이 일어나기 전에, 데이터는 반드시 올바른 좌표계로 변환되어야 한다. 예를 들어, camera_link 프레임으로 수신된 데이터는 전역 좌표계인 map이나 odom 프레임으로 변환되어야 한다. 이 역할을 전담하는 것이 rviz_common::FrameManager이다. 이 클래스는 tf2_ros::Buffer를 래핑하여 중앙 집중식 서비스를 제공하며, 다른 모든 컴포넌트가 변환 정보를 조회할 수 있는 일관되고 깨끗한 API를 노출한다. Display 플러그인은 자신의 processMessage 함수 내에서 FrameManager의 getTransform이나 transform과 같은 메서드를 호출하여 수신된 데이터의 위치와 방향을 정확하게 계산한다.

여기서 로직과 렌더링의 중요한 분리 원칙이 다시 한번 나타난다. Display 플러그인은 OGRE 엔진에 직접적인 렌더링 명령(예: glDrawArrays)을 내리지 않는다. 대신, rviz_rendering 계층이 제공하는 추상 객체와 상호작용한다. 플러그인은 Ogre::SceneNode 객체를 생성하고 조작하여 씬 내의 위치를 지정하고, 이 노드에 포인트 클라우드나 메시와 같은 시각적 표현물을 부착한다. 예를 들어, 플러그인은 context_->getSceneManager()->createManualObject()를 호출하여 렌더링 가능한 객체를 생성하고, begin(), position(), colour(), end()와 같은 메서드를 사용하여 그 기하학적 형태를 정의한다. 이 방식은 플러그인이 “무엇을” 그릴지 기술하면, 렌더링 엔진이 “어떻게” 그릴지를 처리하도록 하는 강력한 추상화를 보여준다.

전체 프로세스를 조율하는 것은 rviz_common::VisualizationManager가 관리하는 메인 업데이트 루프이다. 이 루프는 고정된 타이머(예: 30Hz)에 맞춰 활성화된 모든 Display 플러그인의 update 메서드를 호출한다. 이전 단계에서 OGRE 씬 그래프에 가해진 모든 변경 사항(객체 생성, 위치 변경 등)이 실제로 화면에 커밋되고 rviz_rendering::OgreRenderWindow를 통해 렌더링되는 시점이 바로 이 update 단계이다.

RViz2의 렌더링 파이프라인 설계는 단순한 기능 구현을 넘어, 성능과 유지보수성을 극대화하기 위한 깊은 고려를 담고 있다.

첫째, 렌더링 파이프라인은 단일 함수 호출이 아닌, 비동기적이고 이벤트 기반으로 동작한다. 흔한 오해는 메시지가 도착하면 즉시 단일 동기 함수 호출 내에서 그려진다는 생각이다. 실제로는 여러 관리자에 의해 조율되는 다단계 비동기 프로세스이다. 그 과정은 다음과 같다:

  1. (이벤트 1) ROS 메시지가 도착하고 MessageFilter에 의해 큐에 추가된다.
  2. (이벤트 2) FrameManager가 새로운 TF 변환 정보를 수신한다.
  3. 두 정보가 모두 준비되면, MessageFilter는 메시지를 Display의 processMessage 콜백으로 전달한다 (이벤트 3).
  4. processMessage는 OGRE 씬 객체의 상태를 업데이트하지만, 즉시 재렌더링을 촉발하지는 않는다. 단지 씬 그래프라는 데이터 구조를 수정할 뿐이다.
  5. (이벤트 4) VisualizationManager의 업데이트 타이머가 발생한다.
  6. 이 타이머에 의해 호출된 update 함수 내에서, OgreRenderWindow가 마침내 수정된 씬 그래프를 화면에 렌더링한다.

이러한 비동기 이벤트 기반 설계는 실시간 시스템의 성능에 매우 중요하다. 이는 ROS 메시지 콜백 스레드가 느린 렌더링 작업에 의해 차단되는 것을 방지한다. 또한 RViz2가 메시지 처리 속도와 프레임 렌더링 속도를 독립적으로 조절함으로써 고주파수 데이터를 우아하게 처리할 수 있게 한다. RViz2의 “랙(lag)” 현상을 디버깅하려면 이 파이프라인을 이해해야 한다. 병목 현상은 메시지 수신, TF 가용성, 씬 그래프 업데이트, 또는 최종 렌더링 중 어디에서든 발생할 수 있으며, 각 단계를 개별적으로 조사해야 한다.

둘째, FrameManager를 중앙 집중식 서비스로 설계한 것은 코드 중복을 방지하고 일관성을 보장한다. 중앙 FrameManager가 없다면, 모든 Display 플러그인은 각자 tf2_ros::Buffer와 tf2_ros::TransformListener를 인스턴스화해야 할 것이다. 이는 수십 개의 기본 플러그인과 수많은 서드파티 플러그인에서 TF 리스너 관련 상용구(boilerplate) 코드가 엄청나게 중복되는 결과를 낳을 것이다. 이는 바이너리 크기를 증가시키고 유지보수 부담을 가중시킨다. 더 심각한 문제는 불일치를 유발할 수 있다는 점이다. 서로 다른 플러그인이 다른 캐시 시간으로 설정되거나 다른 소스로부터 TF를 수신하여, 객체들이 서로 어긋나 보이는 기괴한 시각적 오류를 초래할 수 있다. Display의 컨텍스트를 통해 제공되는 싱글턴과 유사한 서비스로서 FrameManager의 존재는 플러그인 코드를 더 단순하고, 작고, 견고하게 만든다. 이는 애플리케이션 내 모든 공간 관계에 대한 단일 진실 공급원(Single Source of Truth)을 강제하며, 이는 일관성 있는 3D 시각화 도구에 있어 타협할 수 없는 요구사항이다.

이 섹션은 RViz2의 강력함과 유연성의 초석인 pluginlib 기반 아키텍처에 대한 결정적인 분석을 제공한다. 플러그인이 어떻게 발견되고, 로드되며, 관리되는지를 해부하고, 확장성을 위한 계약을 정의하는 기본 클래스들을 탐구한다.

RViz2 플러그인 시스템의 기저에는 ROS2의 pluginlib가 있다. pluginlib는 핵심 RViz2 애플리케이션이 컴파일 타임에 링크되지 않은 컴파일된 코드(공유 라이브러리)를 런타임에 로드할 수 있게 해주는 메커니즘이다. 이 동적 로딩 기능 덕분에 사용자는 RViz2를 재컴파일하지 않고도 새로운 기능을 추가할 수 있다. 이 과정의 핵심은 plugin_description.xml 파일이다. 패키지는 이 XML 파일을 통해 자신이 제공하는 플러그인을 ROS2 생태계에 알리며, pluginlib는 이 파일을 사용하여 플러그인 클래스를 발견하고 인스턴스화한다.

RViz2는 다양한 유형의 확장을 지원하기 위해 여러 플러그인 인터페이스를 제공한다. 주요 인터페이스는 다음과 같다.

VisualizationManager는 단순한 관리자를 넘어, 플러그인 시스템의 중앙 지휘자 역할을 한다. 이 클래스는 플러그인 로딩을 처리하는 PluginManager를 생성하고, 활성화된 디스플레이, 도구 및 기타 플러그인들의 목록을 유지 관리한다. 사용자가 UI에서 새로운 “Display”를 추가하면, 이 요청은 VisualizationManager를 통해 pluginlib 로더에 전달된다. 로더는 선택된 Display 클래스를 인스턴스화하고, FrameManager에 대한 포인터와 같은 필수적인 컨텍스트를 전달하며 onInitialize 메서드를 호출하여 플러그인을 초기화한다.

RViz2의 아키텍처를 깊이 들여다보면, 그 본질에 대한 새로운 관점을 얻게 된다.

첫째, 제어의 역전(Inversion of Control, IoC) 원칙이 전체 설계의 중심에 있다. RViz2는 플러그인을 로드할 수 있는 애플리케이션이 아니라, 그 자체가 플러그인 호스트이다. 핵심 rviz2 실행 파일은 환경을 설정하고 제어권을 플러그인에게 넘겨주는 최소한의 셸(shell)에 가깝다. 가장 기본적인 기능조차 플러그인으로 구현되어 있다. VisualizationManager의 메인 루프는 주로 활성화된 플러그인 목록을 순회하며 그들의 update 메서드를 호출하는 것으로 구성된다. 이는 “우리를 부르지 마시오, 우리가 당신을 부를 것이오(Don’t call us, we’ll call you)”라는 할리우드 원칙으로도 알려진 IoC의 전형적인 예이다. 플러그인은 애플리케이션의 흐름을 제어하지 않는다. 대신 프레임워크에 자신을 등록하고, 프레임워크가 적절한 시점(예: update 호출, processMessage 콜백)에 자신의 메서드를 호출해주기를 기다린다. 이 아키텍처 패턴이 RViz2를 이토록 심오하게 확장 가능하게 만드는 이유이다. 프레임워크가 상호작용 패턴을 지시하기 때문에, 많은 서드파티 플러그인이 동시에 실행되더라도 더 안정적이고 예측 가능한 시스템이 된다. 이는 RViz2를 이해하기 위해서는 애플리케이션의 main() 함수가 아니라, 플러그인 기본 클래스의 생명주기와 계약을 이해해야 함을 의미한다.

둘째, plugin_description.xml은 패키지 간 통신을 위한 공식적인 계약서이다. 이 XML 파일은 단순한 목록 이상이다. 이는 한 패키지가 ROS 생태계의 나머지 부분에 제공하는 기능을 공식적이고 기계가 읽을 수 있는 형태로 선언하는 계약서 역할을 한다. pluginlib는 컴파일 타임이 아닌 런타임에 플러그인을 발견한다. 플러그인에 대해 알 수 있는 유일한 방법은 해당 플러그인의 plugin_description.xml 파일을 찾아 파싱하는 것이다. 이 파일에는 플러그인의 이름, 타입(구현하는 기본 클래스, 예: rviz_common::Display), 그리고 플러그인이 포함된 라이브러리 정보가 담겨 있다. 이 메커니즘은 플러그인 소비자(RViz2)와 플러그인 제공자를 완전히 분리한다. 사용자는 RViz2 플러그인이 포함된 새 패키지를 설치하기만 하면, RViz2 자체를 재컴파일할 필요 없이 “Add Display” 대화 상자에 새 플러그인이 나타나는 것을 볼 수 있다. 이것이 바로 작고 독립적이며 재사용 가능한 여러 패키지로 복잡한 시스템을 구축하는 ROS 철학의 기반이다. XML 파일은 이러한 런타임 구성이 안정적으로 이루어지도록 하는 접착제 역할을 한다.

이 섹션에서는 고수준 아키텍처에서 벗어나 가장 중요한 C++ 클래스들을 상세히 검토한다. RViz2 프레임워크의 근간을 이루는 디자인 패턴, 책임, 상속 구조를 분석하여, 핵심 시스템과 상호작용하거나 수정해야 하는 개발자에게 로드맵을 제공한다.

RViz2에서는 전역적인 서비스를 제공하기 위해 매니저(Manager) 클래스와 싱글턴(Singleton) 디자인 패턴이 널리 사용된다.

플러그인 계약을 정의하는 추상 기본 클래스들은 RViz2 확장성의 핵심이다.

rviz_common::Property 클래스와 그 서브클래스들(FloatProperty, StringProperty, BoolProperty 등)은 단순한 값 저장 클래스가 아니다. 이는 전체 UI 및 설정 시스템의 기반이 되는 핵심 컴포넌트이다. 프로퍼티들은 부모-자식 관계를 가질 수 있는 트리 구조를 형성하며, 이는 “Displays” 패널의 확장 가능한 트리 뷰와 직접적으로 미러링된다. 이 시스템은 플러그인의 매개변수를 사용자에게 노출하고, UI와 동기화하며, 설정 파일에 저장하는 모든 과정을 담당한다.

다음 표는 개발자가 코드베이스를 탐색할 때 빠른 참조 가이드 역할을 하도록, 가장 중요한 클래스들의 책임과 위치를 요약한 것이다.

클래스 이름 위치 (rviz_common 기준) 주요 책임
VisualizationManager src/rviz_common/visualization_manager.cpp 애플리케이션의 메인 루프, 씬 관리, 플러그인 라이프사이클, 시간 관리 등 전반적인 오케스트레이션.
FrameManager src/rviz_common/frame_manager.cpp 모든 좌표계 변환(TF) 요청을 처리하는 중앙 서비스. tf2_ros::Buffer를 래핑.
Display include/rviz_common/display.h 데이터 시각화를 위한 플러그인의 추상 기본 클래스. 생명주기 및 메시지 처리 메서드 정의.
Tool include/rviz_common/tool.h 사용자 상호작용을 위한 도구 플러그인의 추상 기본 클래스. 마우스/키보드 이벤트 처리.
Property include/rviz_common/properties/property.h 플러그인 매개변수를 위한 기본 클래스. UI 생성, 값 변경 시그널, 설정 저장을 지원.
PropertyTreeModel src/rviz_common/properties/property_tree_model.cpp Property 객체 트리와 Qt의 QTreeView 사이를 연결하는 어댑터. MVC 패턴의 핵심.
Config include/rviz_common/config.h .rviz 설정 파일(YAML 형식)을 읽고 쓰기 위한 API. 트리 구조의 데이터를 처리.

RViz2의 핵심 클래스 설계에는 특정 디자인 패턴이 의도적으로 사용되었으며, 이는 실용적인 이점을 위해 이론적인 순수성과 타협한 결과를 보여준다.

첫째, Property 시스템은 그 자체로 완전한 모델-뷰-컨트롤러(Model-View-Controller, MVC) 구현체이다. Property 객체는 단순한 데이터 컨테이너가 아니라, 백엔드 로직, UI 표현, 설정 지속성을 자동으로 연결하는 MVC 패턴을 내장하고 있다.

  1. 모델(Model): Property 객체(예: FloatProperty)는 상태(float 값)와 비즈니스 로직(예: 최소/최대 제약)을 보유한다.
  2. 뷰(View): PropertyTreeModel은 Property 객체들을 관찰하고, 이에 해당하는 Qt 위젯(슬라이더, 텍스트 박스 등)을 패널에 생성한다.
  3. 컨트롤러(Controller): Qt의 시그널/슬롯 메커니즘은 뷰에서의 사용자 상호작용을 Property 객체의 setValue 메서드로 다시 연결하고, 이 변경 사항은 변경을 수신 대기하는 모든 C++ 코드에 통지된다.

이 우아한 설계는 플러그인 개발자에게 엄청난 이점을 제공한다. 개발자는 어떠한 Qt UI 코드도 작성할 필요가 없다. 단지 자신의 Display 생성자에서 FloatProperty를 인스턴스화하기만 하면, RViz2가 자동으로 UI 위젯을 생성하고, 사용자 입력을 처리하며, .rviz 설정 파일에 값을 저장하고 불러오는 모든 복잡한 과정을 추상화하여 처리해준다.

둘째, VisualizationManager 싱글턴의 사용은 실용적인 트레이드오프의 결과이다. 순수한 소프트웨어 공학 관점에서 싱글턴 패턴이나 “갓 오브젝트”는 강한 결합과 전역 상태를 유발하므로 안티패턴으로 간주될 수 있다. 그러나 RViz2의 맥락에서는 이는 의도적이고 실용적인 선택이다. RViz2 플러그인은 동적으로 로드되는 공유 라이브러리이므로, 별도의 메모리 공간에 존재하여 상태를 쉽게 공유하기 어렵다. FrameManager와 같은 서비스가 필요한 모든 객체에 컨텍스트 객체(즉, VisualizationManager에 대한 포인터)를 일일이 전달하는 것은 매우 번거롭고 여러 계층을 통해 “속성 내리기(prop-drilling)”를 요구할 것이다. 이에 대한 대안은 중앙 집중적이고 전역적으로 접근 가능한 서비스 로케이터이며, VisualizationManager가 바로 그 역할을 효과적으로 수행한다. 플러그인은 초기화 시 한 번 매니저를 얻고 나면, getFrameManager(), getSceneManager() 등 필요한 모든 코어 서비스에 접근할 수 있다. 이는 이론적인 순수성을 일부 희생하는 대신, RViz2의 주요 목표 중 하나인 플러그인 개발 경험의 단순화를 극대화하는 실용적인 선택이다.

이 섹션은 RViz2의 사용자 대면 측면에 초점을 맞추어, C++ 백엔드가 Qt 프론트엔드와 어떻게 통신하고 전체 애플리케이션 상태가 어떻게 지속되고 재로드되는지 분석한다.

RViz2는 사용자 인터페이스를 구축하기 위해 Qt의 핵심 메커니즘인 시그널과 슬롯을 광범위하게 사용한다. 특히 중요한 것은 PropertyTreeModel이다. 이 클래스는 C++ rviz_common::Property 객체와 이를 표시하는 Qt QTreeView 위젯 사이의 핵심 어댑터 역할을 한다. 이는 UI의 데이터 바인딩 심장부이다. Property 객체의 값이 C++ 코드 내에서 변경되면, 해당 Property는 시그널을 방출한다. PropertyTreeModel은 이 시그널을 수신하여 연결된 UI 위젯을 업데이트한다. 반대로, 사용자가 UI 위젯을 조작하면, 위젯은 시그널을 방출하고, 이는 슬롯을 통해 Property 객체의 값을 변경하는 메서드를 호출한다. 이 양방향 통신 덕분에 백엔드 로직과 프론트엔드 UI가 항상 동기화된 상태를 유지할 수 있다.

RViz2의 전체 세션 상태(추가된 디스플레이, 각 디스플레이의 속성, 카메라 위치 등)는 .rviz 확장자를 가진 YAML 파일에 저장된다. 이 설정 시스템의 중심에는 rviz_common::Config 클래스가 있다. 이 클래스는 트리 구조의 데이터를 읽고 쓰는 API를 제공하며, 이는 YAML 형식의 계층 구조와 직접적으로 매핑된다. VisualizationManager와 각 Display의 save 및 load 함수는 이 Config 클래스를 사용한다. 상태를 저장할 때, 시스템은 Property 객체 트리를 순회하며 각 프로퍼티의 이름과 값을 Config 객체에 기록하고, 이 Config 객체는 최종적으로 YAML 파일로 직렬화된다. 상태를 로드할 때는 그 반대 과정이 일어난다.

RViz2의 설정 저장 및 로드 기능이 매끄럽게 작동하는 것은 우연이 아니라 잘 설계된 엔지니어링의 결과이다.

핵심은 .rviz 파일이 Property 객체 트리의 직접적인 직렬화(serialization) 결과물이라는 점이다. .rviz YAML 파일의 구조는 임의적이지 않다. 이는 메모리 내에 존재하는 Property 객체들의 부모-자식 계층 구조를 일대일로 정확하게 반영한다. 예를 들어, Grid Display는 “Cell Count”, “Color”, “Plane”과 같은 자식 프로퍼티를 가진다. Config::save 함수는 이 트리를 재귀적으로 순회한다. 각 Property에 대해, 프로퍼티의 이름을 키로, 그 값을 값으로 하는 YAML 맵 엔트리를 생성한다. 그 결과, 파일의 들여쓰기와 구조가 애플리케이션의 내부 상태 트리를 완벽하게 미러링하게 된다. 이처럼 인-메모리 상태와 디스크 상의 표현이 긴밀하게 결합되어 있기 때문에 설정 시스템은 매우 견고하고 단순하다. 복잡한 매핑이나 변환 계층이 존재하지 않는다. 상태를 저장하려면 트리를 순회하며 쓰고, 상태를 로드하려면 파일을 읽고 트리를 순회하며 값을 설정하면 된다. 이러한 단순성은 우아한 소프트웨어 설계의 전형적인 특징이다.

이 마지막 섹션은 보고서 전체의 분석을 종합하여 개발자를 위한 실행 가능한 전문가 수준의 지침을 제공한다. 단순한 설명을 넘어, 우리가 구축한 아키텍처에 대한 깊은 이해를 바탕으로 한 규범적인 조언을 제시한다.

RViz2를 효과적으로 다루기 위해서는 올바른 정신 모델을 갖는 것이 중요하다. RViz2는 이벤트 기반의, 플러그인 호스팅 프레임워크이다. 개발자는 애플리케이션을 직접 제어하려 하기보다는, 프레임워크가 제공하는 서비스(FrameManager, SceneManager 등)를 사용하고 이벤트(메시지 도착, UI 클릭, 업데이트 틱)에 응답하는 컴포넌트(플러그인)를 제공하는 방식으로 생각해야 한다. 이 “제어의 역전” 패러다임을 내면화하는 것이 RViz2 개발의 첫걸음이다.

RViz2의 코어 패키지에 기여하고자 하는 개발자를 위한 최종 권장 사항은 다음과 같다.