# 파라미터(Parameter) 서버의 개념

#### ROS1 파라미터 서버와 ROS2 파라미터 관리의 차이

ROS1에서는 모든 노드가 공통으로 참조할 수 있는 전역 파라미터 서버(Parameter Server)가 존재했다. 해당 서버는 ROS 마스터(Master)와 연동되어 전역적으로 노출되는 파라미터를 등록·조회하는 방식으로 작동했다. 그러나 ROS2에서는 이 전역 파라미터 서버가 사라지고, 각 노드(Node)가 스스로 파라미터 서버 역할을 수행하도록 설계가 변경되었다. 즉, 노드별로 필요한 파라미터를 직접 보관하고 관리한다.

이로 인해 다음과 같은 특징이 부각된다.

1. **노드 단위 분리** 노드마다 파라미터 구성이 달라질 수 있으므로, 노드별 유연성을 극대화할 수 있다. 동시에 단일 전역 서버에 의존하지 않으므로, 마스터 노드가 사라진 분산 구조에 더 최적화된다.
2. **네임스페이스(Namespace) 활용** 기존 ROS1과 달리 노드별 파라미터가 자체적으로 관리되므로, 파라미터 네임스페이스를 통해 서로 다른 노드끼리 파라미터 충돌을 피할 수 있다. 원하는 네임스페이스 경로를 지정함으로써 원하는 노드만 파라미터를 검색하거나 교체하는 등의 작업을 수행할 수 있다.
3. **동적 파라미터 구성(Dynamic Reconfigure) 기능 변화** ROS1에서 제공되던 Dynamic Reconfigure와 유사한 기능은 ROS2에서 노드별 파라미터 서버 컨셉에 맞춰 ‘동적으로 갱신 가능한 파라미터’라는 형태로 개편되었다. 이를 통해 파라미터 변경 시 새로운 서비스(SERVICE) 요청이 일어나고, 노드가 이를 반영할지 거부할지 선택할 수 있게 된다.

#### 파라미터 서버 노드의 기본 작동 원리

ROS2에서 "파라미터 서버 노드"라는 개념은 독립된 서버가 아니라 **각 노드가 자신만의 파라미터 인터페이스(Parameters Interface)를 제공**한다는 의미로 이해해야 한다. 즉, 모든 노드는 아래와 같은 과정을 통해 파라미터 관리 서비스를 수행한다.

**노드 초기화**: 노드가 생성될 때, 파라미터 혹은 launch 파일에서 전달받은 여러 설정값을 노드 내부에 저장한다. 이때, 개발자는 C++ 또는 Python API를 이용하여 노드에 파라미터를 선언(Declare)할 수 있다.

```cpp
node->declare_parameter("robot_speed", 1.0);
```

파라미터를 선언하면 노드는 내부적으로 해당 파라미터를 관리하기 위한 구조체를 할당한다.

**파라미터 읽기/쓰기**: 노드 실행 도중 다른 노드나 사용자가 명령어를 통해 파라미터를 읽거나 쓸 수 있다. 예를 들어 파라미터를 명령줄에서 설정하고자 할 때는 다음과 같이 명령한다.

```bash
ros2 param set /my_robot_node robot_speed 2.5
```

이 요청을 받은 대상 노드는 ‘robot\_speed’라는 파라미터 값을 2.5로 변경할 수 있는지 확인한 뒤, 문제가 없으면 파라미터를 갱신한다.

**파라미터 유효성 검증(Validation)**: 파라미터가 변경될 때 노드가 무조건 이를 받아들이는 것은 아니다. 파라미터 변경 콜백을 등록해서 특정 조건을 만족하는지 검사한 다음, 조건을 만족하지 못하면 변경을 거부(Reject)할 수 있다. 예를 들어 모터 속도 파라미터가 음수가 될 수 없도록 유효성 검사를 추가할 수 있다.

**파라미터 이벤트(Notification) 브로드캐스트**: 파라미터가 갱신되면, 노드는 해당 파라미터가 변경되었음을 다른 노드들에게 알리는 이벤트를 보내거나, 콜백 함수를 통해 알림을 받도록 설정할 수 있다. 이를 통해 파라미터 값에 의존하는 로직이 자동으로 갱신된다.

#### 노드 수준 파라미터 서버의 장점

* **분산성**: 파라미터에 대한 병목 현상이 사라지고, 중앙 집중식 서버의 의존도가 낮아진다.
* **독립성**: 노드별로 자체 파라미터를 관리하므로, 특정 파라미터가 다른 노드와 충돌하거나 덮어씌워지는 문제가 줄어든다.
* **유연성**: 노드마다 필요한 파라미터만 선언하므로, 중복 혹은 불필요한 파라미터를 제거하고 노드 설계를 단순화할 수 있다.
* **안정성**: 네트워크나 마스터 노드 장애로부터 파라미터가 직접적인 영향을 받지 않는다.

#### 파라미터 접근 방식

ROS2는 파라미터를 접근할 수 있도록 다음과 같은 통신 방식을 제공한다.

1. **서비스(Service) 인터페이스**
   * `SetParameters`, `GetParameters`, `ListParameters` 등의 서비스를 활용하여 파라미터를 동기적으로 수정·조회한다.
   * 서비스 요청이 성공하면 노드는 요청을 승인(accept)하거나 거부(reject)할 수 있다.
2. **파라미터 이벤트 토픽(Parameter Events topic)**
   * 노드에서 파라미터가 변경될 때마다 브로드캐스트되는 토픽이다.
   * 다른 노드가 해당 토픽을 구독하면 실시간으로 파라미터 변경 정보를 모니터링할 수 있다.

#### 파라미터 서버 노드 구현 시 고려 사항

**명확한 파라미터 선언(Declaration)**: ROS2에서는 노드 실행 중 파라미터를 처음 접근하기 전에 반드시 `declare_parameter()` 또는 `declare_parameters()`를 통해 선언해야 한다. 선언되지 않은 파라미터에 접근하면 예외(Exception)가 발생한다.

**기본값(Default Value) 설정**: 파라미터를 선언할 때 기본값을 지정해두면, 파라미터값이 설정되지 않았을 경우를 대비할 수 있다.

```cpp
node->declare_parameter("some_parameter", 10); 
```

**데이터 타입(Type) 일관성 유지**:파라미터를 처리할 때 ROS2가 제공하는 `rclcpp::ParameterType` 유형에 맞춰 적절히 선언해야 한다. 예를 들어 정수형 파라미터로 선언했는데 실수형 값을 입력하면 에러가 발생한다.

**런타임 동적 갱신(Dynamic Updates)**: 실행 중인 노드의 파라미터를 실시간으로 변경하고, 그에 따라 동작 방식을 재설정하려면 파라미터 변경 콜백(Callback) 함수를 등록해야 한다. 이를 통해 변경 요청을 승인하거나 거부할 수 있고, 성공 시 로직에 반영한다.

#### 파라미터 동적 갱신(Dynamic Reconfigure)과 ROS2

ROS1에서의 Dynamic Reconfigure는 별도의 GUI나 CLI를 통해 파라미터를 실시간으로 조정하고 노드가 즉시 반영하도록 지원하는 툴이었다. ROS2에서도 유사한 기능을 제공하지만, 더 이상 ‘하나의 도구’로 제공되기보다는, **노드 자체의 파라미터 서버와 파라미터 이벤트**를 통해 이루어진다.

* **노드 자체의 파라미터 변경 콜백** 기존 ROS1에서 Dynamic Reconfigure 서버를 구성하던 방식 대신, ROS2에서는 노드 내부에서 `add_on_set_parameters_callback()` 혹은 `declare_parameter()` 설정 시 지정하는 콜백 함수를 통해, 파라미터 변경을 실시간으로 처리한다.
* **GUI/CLI 연동** rqt, RViz 등에서 각 노드에 대해 파라미터를 조회·편집할 수 있도록 플러그인이 존재하거나, 별도의 노드로 확장하여 GUI를 구성할 수 있다. CLI 명령어 `ros2 param set`, `ros2 param get` 등을 통해 간단히 동적 갱신을 확인할 수도 있다.
* **이벤트 알림 및 모니터링** 파라미터 변경 시 이벤트 토픽(`/parameter_events`)이 발행(publish)되며, 이를 구독(subscribe)함으로써 다른 노드나 모니터링 툴에서 변경 내용을 즉각 반영할 수 있다.

#### launch\_ros에서의 파라미터 관리 기법

ROS2 Humble 이후에는 `launch_ros` 패키지를 통해 파라미터를 중앙에서 관리·할당하는 기법이 점점 발전하고 있다. 파라미터 파일 사용 외에도 런치 파일 내부에서 파라미터를 직접 인라인(In-line)으로 정의하거나, Substitution 기능을 이용해 조건부 로딩이 가능하다.

**Inline 파라미터 설정**:

```python
from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='my_package',
            executable='my_executable',
            name='inline_param_example',
            parameters=[{
                'robot_speed': 2.0,
                'use_lidar': False
            }]
        )
    ])
```

노드 실행 시 별도의 YAML 파일 없이도 파라미터를 할당할 수 있다.

**Substitution (조건부 파라미터 사용)**: 런치 파일에서 `LaunchConfiguration`, `IfCondition`, `PythonExpression` 등을 활용해 특정 조건을 만족할 때만 파라미터를 적용하거나, 다른 경로의 YAML 파일을 불러오는 등 다양한 로직을 구성할 수 있다.

```python
from launch import LaunchDescription
from launch.actions import DeclareLaunchArgument
from launch.substitutions import LaunchConfiguration
from launch_ros.actions import Node

def generate_launch_description():
    use_lidar_arg = DeclareLaunchArgument('use_lidar', default_value='True')
    use_lidar_val = LaunchConfiguration('use_lidar')

    return LaunchDescription([
        use_lidar_arg,
        Node(
            package='my_package',
            executable='my_executable',
            name='conditional_param_example',
            parameters=[{
                'use_lidar': use_lidar_val
            }]
        )
    ])
```

이를 통해 `$ ros2 launch my_launch.py use_lidar:=False` 명령어로 노드의 파라미터를 조건부로 바꿔줄 수 있다.

#### 파라미터 값 검증(Validation) 패턴

ROS2 노드는 파라미터 값 변경 시 개발자가 정의한 조건을 만족하지 않을 경우, 파라미터 변경을 거절(Reject)할 수 있다. 이를 이용해 노드 안정성을 높일 수 있다.

**온도·전류·속도 등 물리적 한계값 제한**: 예: 로봇 모터 속도가 $v\_{\mathrm{max}}$ 이상으로 설정되는 것을 방지

$$
0 \leq \mathbf{v} \leq v\_{\mathrm{max}}
$$

와 같은 형태로 검증 후 초과 시에는 거절한다.

**데이터 타입 범위 검사**: 파라미터가 정수 혹은 실수형일 때, 특정 범위를 벗어나면 오류를 발생시킨다. 예: 센서 샘플링 주기가 음수나 0일 수 없음.

**상호 종속성(Cross-dependency) 검사**: 예: 만약 `use_lidar`가 `true`라면, `lidar_refresh_rate`가 0보다 큰 값으로 설정돼야 한다. 이런 식으로 두 파라미터가 연관관계를 가질 때 유효성 검사 로직을 구현할 수 있다.

**실시간(Real-time) 시스템에서의 파라미터 제한**: 실시간 ROS2 시스템(RT 커널 기반)에서는 런타임에 파라미터 변경이 빈번히 발생하면 타이밍 문제가 생길 수 있다. 이를 방지하기 위해, 노드가 실시간 우선순위를 가지고 있을 경우 파라미터 변경 자체를 제한하거나, 오직 초기화 시점에만 설정 가능하게 만드는 방법이 있다.

#### 파라미터 다루기에서 흔히 겪는 문제

**파라미터 미선언 오류**: 파라미터를 사용하기 전에 `declare_parameter()`하지 않으면 예외가 발생한다.

**데이터 타입 불일치**: 예: `declare_parameter<int>("my_param", 10)`로 선언했는데 YAML에서 `"my_param": 10.5`로 설정한 경우, 런타임 에러 혹은 경고가 발생한다.

**동적 변경 시점 관리**: 변경 콜백이 블로킹(Blocking) 로직을 포함하거나, 변경 빈도가 지나치게 잦으면 노드 성능이 저하될 수 있다.

**네임스페이스 혼동**: 노드가 특정 네임스페이스에서 실행 중인데, 잘못된 네임스페이스 경로로 파라미터를 설정하려고 시도하면 반영되지 않는다.

#### 파라미터 보안(Security) 관점

ROS2는 DDS(Data Distribution Service) 기반으로 네트워크 상에서 노드 간 통신을 수행한다. 파라미터 또한 서비스와 토픽 통신으로 처리되므로, DDS-Security를 구성하거나 파라미터 변경 권한을 특정 노드·사용자에게만 부여하는 기능이 필요할 수 있다.

**DDS-Security 프로파일 설정**: 파라미터 변경 서비스와 이벤트 토픽에 대한 암호화·인가(Authorization)·무결성 보호를 활성화한다.

**액세스 제어(Access Control)**: 중요한 파라미터(예: 제어 루프 게인, 안전 임계값)는 임의 노드에서 마음대로 바꿀 수 없도록, 인증된 노드에서만 변경할 수 있게 설정할 수 있다.

#### 노드 간 파라미터 연동(Composition 및 Lifecycle Node)

ROS2의 핵심 철학 중 하나는 ‘컴포지션(Composition)을 통한 자원 효율성’이다. 여러 노드를 단일 프로세스 내에서 동적으로 조합·실행하려면, 각 노드가 자신의 파라미터를 별도로 관리하며 동시에 상호간 파라미터 충돌 없이 구동되어야 한다.

**컴포지트 노드(Composable Nodes) 구조**: 하나의 프로세스(Process)에 여러 노드를 넣어 실행할 경우, 각 노드가 이름·네임스페이스·파라미터를 고유하게 가져야만 파라미터 충돌을 피할 수 있다. 런치 파일에서 이를 설정하거나, 노드 생성 시점에 명시적으로 네임스페이스를 부여하면 된다.

```cpp
auto node1 = std::make_shared<MyRobotNode>(rclcpp::NodeOptions().namespace_("/ns1"));
auto node2 = std::make_shared<MyRobotNode>(rclcpp::NodeOptions().namespace_("/ns2"));
```

위와 같이 네임스페이스를 다르게 두면, node1과 node2의 파라미터 이름이 동일하더라도 구분된다.

**라이프사이클 노드(Lifecycle Node)와 파라미터**: Lifecycle Node는 특정 상태(Active, Inactive, Unconfigured 등)를 가지며, 상태 전이에 따라 노드의 동작을 제어하는 ROS2 기능이다. 파라미터 선언·변경 시점이 각 상태와 어떻게 연관되는지 명확히 정의해야 한다. 예를 들어 노드가 `Inactive` 상태인 동안에만 파라미터 변경을 허용하고, `Active` 상태가 되면 파라미터를 고정(Lock)하는 방식을 취할 수 있다.

#### 파라미터의 로깅(Logging) 및 디버깅 기법

파라미터가 자주 변경되는 시스템에서는, 누가 언제 어떤 파라미터를 변경했는지 추적할 필요가 있다. 이는 시스템 장애 분석이나 버그 추적에 크게 도움이 된다.

파라미터 이벤트 토픽 기록: ROS2의 `/parameter_events` 토픽을 rosbag2로 녹화해두면, 어느 시점에 어떤 노드 파라미터가 바뀌었는지 재생(Replay) 가능하다.

```bash
ros2 bag record /parameter_events
```

로그 출력(Logging) 활용: 파라미터 변경 콜백 내에서 `RCLCPP_INFO`, `RCLCPP_WARN` 등 로그를 남기면, 변경 시점과 값이 로깅된다.

```cpp
RCLCPP_INFO(this->get_logger(), "Parameter '%s' changed to: %f", 
            param.get_name().c_str(), param.as_double());
```

**CLI 도구**: `ros2 param dump`, `ros2 param list`, `ros2 param describe` 등을 통해 현재 노드의 파라미터 상태나 타입, 설명 등을 확인할 수 있다.

#### 멀티머신/원격 파라미터 관리

ROS2는 DDS를 기반으로 분산 환경에서 운용될 수 있다. 여러 물리적 머신(PC, 임베디드 장치 등)에 노드가 퍼져 있을 때, 서로의 파라미터에 접근하거나 변경할 수 있는 구조가 필요하다.

**디스커버리(Discovery)와 네트워크 토폴로지**: 분산 환경에서는 서비스 호출이 네트워크 지연(Latency)이나 QoS 정책에 따라 제한될 수 있다. 파라미터 관리 역시 서비스·토픽 통신을 사용하므로, DDS 디스커버리 설정이나 QoS(History, Reliability 등)를 적절히 구성해야 한다.

**보안(Security) 이슈**: 원격 기기에서 임의 노드가 파라미터를 변경하지 못하도록, 인증된 디스커버리나 보안 프로파일을 구성해야 한다. 예를 들어 DDS-Security 설정 파일에서 파라미터 서비스 접근을 제한 가능하다.

**WAN(광역 네트워크) 활용 시**: 로컬 네트워크 내에서만 접근할 수 있었던 ROS2 파라미터를 VPN 혹은 클라우드 브릿지(Bridge) 구성 등을 통해 WAN 환경에서도 변경 가능하게 만들 수 있다. 이때는 지연과 패킷 손실을 고려하여 QoS 프로파일을 더욱 신중히 설계해야 한다.

#### 파라미터 사용 팁 및 모범 사례

**초기화 시점에 모든 파라미터를 철저히 선언**: 실행 중 필요해질 것 같은 파라미터를 미리 ‘가능한 범위 내’에서 선언해두면, 미선언 오류나 데이터 타입 불일치를 방지할 수 있다.

**단일 책임 원칙(Single Responsibility Principle)**: 한 노드가 너무 많은 파라미터를 관리하지 않도록, 기능별로 노드를 나누고 각 노드가 자신의 파라미터만 담당하도록 설계한다.

**공통 파라미터 vs. 전역 변수**: 노드 간에 완전히 동일한 값을 공유해야 한다면, 파라미터로 중복 선언하기보다는 통신 메시지를 통한 주기적 방송(Broadcast)이나 TF(Transform) 체계 등을 재검토해보자. 파라미터는 ‘초기 설정값’이나 ‘제어 파라미터’에 가깝다.

**런타임 변경 빈도 최소화**: 파라미터는 본질적으로 ‘설정값’에 해당하므로, 매 주기(밀리초 단위)마다 변경이 필요한 값이라면 토픽 메시지나 서비스 호출을 사용하는 편이 좋다.

#### 예외 처리(에러 핸들링) 전략

**파라미터 변경 거부 시 사용자 피드백**: 콜백에서 `successful = false`를 반환할 경우, 명령줄 사용자나 상위 로직에서 어떤 이유로 거절되었는지 알 수 있도록 `reason` 필드를 채워준다.

**예기치 못한 파라미터 해제(Undeclare) 시나리오**: ROS2에서 ‘undeclare\_parameter()’ API로 파라미터를 제거하는 기능도 있으나, 실무에서 빈번히 사용되지는 않는다. 만약 해제 후 다시 선언하는 로직을 사용할 때는, 데이터 타입 충돌에 유의해야 한다.

**런치 파일 에러 처리**: 런치 파일로 파라미터를 로드하다가 YAML이 잘못되었거나, 노드 생성에 실패하면 런치 시스템에서 예외가 발생한다. 이를 try-catch로 제어하거나, 미리 YAML 문법 검사 같은 방어 코드를 둘 수 있다.

#### 파라미터 QoS(Quality of Service) 활용

ROS2 파라미터 시스템은 기본적으로 서비스(서비스 콜)와 이벤트 토픽을 통해 동작한다. 이때 통신 안정성·지연·내구성 등을 결정하는 QoS 설정이 매우 중요하다.

**파라미터 이벤트 토픽 QoS**: `/parameter_events` 토픽은 노드가 파라미터를 변경할 때마다 메시지를 발행한다. 보통 “신뢰성(Reliable)” 모드와 “수신 전까지 이력(Transient Local)”을 크게 요구하지 않는 편이지만, 시스템에 따라 다음과 같이 조정 가능하다.

* **Reliability**: “Best Effort”에서 패킷 유실이 발생해도 괜찮다면 기본값을 사용. 파라미터 변경이 아주 중요한 경우 “Reliable”로 설정해서 놓치지 않도록 할 수 있다.
* **Durability**: “Volatile”이면 새로 구독을 시작한 노드는 기존 파라미터 이벤트를 받을 수 없지만, “Transient Local”이면 최근 변경 이력을 저장해서 뒤늦게 구독한 노드도 파라미터 변경 사실을 재수신할 수 있다.

**파라미터 서비스 QoS**:`SetParameters`, `GetParameters` 같은 서비스들은 대부분 신뢰적(Reliable)이고 일대일(One-to-One) 통신으로 진행된다. 특별히 수정할 필요가 없을 수 있으나, 네트워크 환경이 좋지 않은 경우엔 재시도 횟수, 타임아웃 등을 늘려야 할 수 있다.

**실시간(Real-time) 파라미터 통신**: 실시간 시스템에서는 노드가 높은 우선순위를 가지고 동작할 때, 서비스 호출(ROS2 서비스)로 인한 스레드 스위칭이 지연을 발생시킬 수 있다. 이 경우 별도의 실시간 안전(Real-time Safe) 방식(예: Lock-free, Zero-copy QoS)을 고려하거나, 파라미터를 런타임에 자주 바꾸지 않는 방향으로 설계한다.

#### 파라미터 업데이트 시 동작 순서(Sequence)

파라미터가 변경되는 순간 노드 내부에서는 다음 순서로 동작한다.

**서비스 콜 혹은 CLI 요청**: `ros2 param set /my_node param_name value` 형태의 요청이 서비스 호출로 전송된다.

**콜백에서 유효성 검증**: 노드가 `add_on_set_parameters_callback()` 등을 통해 변경 가능 여부를 확인하고, 필요시 거부한다.

**반영(Commit) 및 노드 로직 적용**: 승인이 떨어지면, 파라미터 값이 메모리에 반영된다. 이어서 노드 내부 로직(제어값 재계산, 센서 설정 재실행 등)을 업데이트한다.

**파라미터 이벤트 토픽 발행**: 변경이 성공적으로 이루어지면, 노드는 `/parameter_events` 토픽에 파라미터 변경 사실을 알린다.

이를 타임라인 차트로 표시하면 아래와 같다:

{% @mermaid/diagram content="sequenceDiagram
participant User/CLI
participant ParamService
participant Node
participant /parameter\_events

```
User/CLI->>ParamService: ros2 param set /my_node ...
ParamService->>Node: service call: SetParameters
Node->>Node: 파라미터 변경 콜백(검증)
alt 유효성 검사 통과
    Node->>Node: 파라미터 내부 값 갱신
    Node->>/parameter_events: 파라미터 변경 이벤트 Publish
    ParamService->>User/CLI: 성공 응답
else 유효성 검사 실패
    ParamService->>User/CLI: 실패 응답 + 실패 사유
end" %}
```

#### 대규모 파라미터(High-Density Parameter) 사용 시 고려 사항

* **YAML 파일 분할**: 수십\~수백 개 파라미터가 필요한 복잡한 노드라면, YAML 파일을 기능별로 분할 관리한다. 예: “camera\_params.yaml”, “control\_params.yaml” 등.
* **서브 네임스페이스**: 파라미터 이름에 서브 네임스페이스를 명시적으로 부여해, 관련 파라미터끼리 묶어서 관리한다. 예: `camera.resolution.width`, `camera.resolution.height`.
* **메모리 사용량**: 파라미터가 지나치게 많으면 노드 초기화 시점에 선언/로딩 과정에서 메모리 사용량이 증가하므로, 꼭 필요한 파라미터만 선언하도록 한다.
* **동적 변경 처리 비용**: 대규모 파라미터가 모두 동시에 변경될 가능성이 있는 경우, 콜백 안에서 반복 루프를 도는 데 드는 비용이 적지 않을 수 있다. 상황에 따라서는 한번에 여러 파라미터를 변경하는 게 아니라 필요한 파라미터만 선택적으로 변경하도록 유도하는 방식을 취할 수 있다.

#### 테스트(Testing)와 CI/CD에서의 파라미터 주입

소프트웨어 테스팅 자동화(예: GitHub Actions, Jenkins) 환경에서 ROS2 노드의 파라미터를 다양하게 변경해가며 테스트할 때가 많다.

* **매개변수화(Parameterized) 테스트**: 다양한 파라미터 조합으로 노드를 실행해보며, 원하는 출력(토픽 메시지, 상태 값)이 기대치와 일치하는지 검사한다.
* **테스트 전용 YAML**: 개발·배포용 파라미터 파일과는 별도로 테스트 전용 파라미터 파일을 만들어둔다. 예: “test\_params.yaml” 파일에 극한값(최댓값, 최솟값 등)을 몰아넣고 노드의 거부 로직이 정상 작동하는지 확인한다.
* **Mocking / Fixture**: 노드 내부에서 파라미터를 가져가는 로직을 유닛 테스트할 때, 모의(Mock) 노드나 가짜 파라미터 서버를 구성해 지정값을 리턴하도록 만들어 테스트를 단순화할 수 있다.

#### 파라미터를 이용한 로봇 상태 머신

파라미터는 로봇의 작동 모드 전환(Mode switching), 예비(Backup) 설정값 적용 등에 유용하게 쓰일 수 있다. 예:

정찰(Scout) 모드 → 탐사(Explore) 모드 전환: “robot\_mode”라는 문자열 파라미터로 노드의 상태 머신 로직을 분기할 수 있다.

```cpp
this->declare_parameter<std::string>("robot_mode", "scout");
```

CLI나 런치 파일에서 “explore”로 변경 시, 노드가 경로 탐색 알고리즘을 활성화하도록 한다.

**제어 게인(Controller Gains) 핫스왑**: PID 제어기 같은 노드는 파라미터로 $K\_p, K\_i, K\_d$ 값을 받아 설정한다. 특정 상황(부하 변화 등)에서 파라미터를 바꾸어 즉시 새로운 게인으로 동작하도록 한다.

#### 향후 확장 및 커뮤니티 동향

* **rclcpp, rclpy 최신 API**: ROS2 Humble 이후 Foxy, Galactic, Rolling 등에서 파라미터 시스템이 조금씩 개선되고 있다.
* **ROS2 Control 통합**: 로봇 제어를 위한 “ros2\_control” 프레임워크와 파라미터 연동이 활발히 이루어져, 각 하드웨어 플러그인(Hardware Interface)이 파라미터를 통해 초기화나 동적 변경을 수행한다.
* **플러그인 아키텍처(Pluginlib)와 파라미터**: 노드가 여러 종류의 플러그인을 로드해 쓸 때, 플러그인마다 별도 파라미터 공간을 가질 수 있도록 설계된다. 예: `plugin_name.param_key` 형식.