# ROS2 테스트의 중요성

#### 테스트 개념과 ROS2 맥락

ROS2 시스템에서 테스트는 단순히 코드가 원하는 대로 동작하는지를 확인하는 절차를 넘어, 로보틱스 애플리케이션을 실제 환경에서 안전하게 운용하기 위한 필수적인 과정이다. 일반 소프트웨어와 달리 로봇 플랫폼은 물리적 동작, 센서 입력, 네트워크 레이턴시, 분산 시스템 등 예측하기 어려운 변수가 많다. 이런 불확실성을 제어하기 위해서는 자동화된 테스트뿐만 아니라 체계적이고 반복 가능한 테스트 절차가 필요하다.

ROS2는 네트워크 기반 통신을 통해 노드 간 메시지를 송수신하고, 다양한 드라이버와 하드웨어 시스템을 지원한다. 이러한 복잡성은 시스템 결함이 특정 노드에만 머무르지 않고 다른 노드나 센서, 혹은 액추에이터로 전이(Propagation)될 위험을 만든다. 테스트 전략이 부재할 경우, 시스템의 결함이 어디에서 비롯됐는지 파악하기 어렵고, 유지보수 비용이 크게 증가한다. 따라서 ROS2 개발 환경에서 테스트의 중요성은 다른 소프트웨어보다 더 크다고 볼 수 있다.

#### 테스트 전략으로 해결 가능한 문제

ROS2에서의 테스트는 다음과 같은 문제를 사전에 방지하고 해결하는 데 큰 도움이 된다.

1. **통신 지연 및 메시지 손실 검출**
   * 다중 노드 구조에서 한 노드의 통신 지연이나 메시지 손실이 전체 애플리케이션에 어떤 영향을 미치는지 모니터링한다.
   * 시뮬레이션 환경과 실제 하드웨어 환경에서 동일하게 재현되는지 비교하여, 시스템 안정성을 높일 수 있다.
2. **노드 간 상호작용 검증**
   * 퍼블리셔-서브스크라이버(Pub-Sub) 형태로 연결된 노드가 예상대로 메시지를 주고받는지 검증한다.
   * 액션(Action) 인터페이스, 서비스(Service) 요청 등 다양한 통신 패턴에 대한 테스트로, 상호작용에서 발생할 수 있는 데이터를 세밀하게 검토한다.
3. **비동기 이벤트 처리를 통한 예외 상황 점검**
   * 로봇이 이동 중 돌발 상황(충돌 직전, 센서 오작동 등)에 어떻게 대응하는지를 자동화된 테스트로 반복 점검한다.
   * 비동기 콜백에서 발생할 수 있는 에러나 경쟁 상태(Race Condition)를 조기에 발견할 수 있다.

#### 테스트 범위와 커버리지

ROS2에서 테스트는 단순히 함수 단위(Unit) 테스트만을 의미하지 않는다. 노드 단위(Test Node), 시스템 단위(System-Level) 등 다양한 수준에서 진행할 수 있다. 특히 시스템 통합 테스트(Integration Test)와 기능 테스트(Functional Test)를 통해 전체 로봇 시스템이 의도된 목적을 달성하는지 체계적으로 확인한다.

**기능별 커버리지(Function Coverage)**: 테스트 설계 시, 기능별 커버리지를 추적하기 위해 다음과 같은 방식으로 지표를 활용할 수 있다.

$$
\text{Coverage} = \frac{\text{Number of tested functionalities}}{\text{Total functionalities}} \times 100%
$$

이 지표는 개발자가 놓칠 수 있는 기능적 공백을 찾고 우선순위를 부여할 때 유용하다.

**상태 및 전이(Transition) 커버리지**: 로봇 상태 머신(State Machine)에 대한 전이 검증은 로봇 동작 테스트에서 매우 중요하다. 예를 들어, 특정 상태에서 센서가 정상 범위를 벗어나면 다음 상태로 전이되어 안전 모드로 진입해야 한다. 이를 엄밀하게 확인하기 위해 상태 전이(Transition)를 모두 커버하는 테스트 시나리오가 필요하다.

#### 테스트 자동화와 지속적 통합(CI)

ROS2 개발 흐름에서 테스트 자동화와 지속적 통합(CI)는 품질 향상의 열쇠다. 예를 들어, GitHub Actions, GitLab CI/CD, Jenkins 같은 CI 도구를 활용해 모든 커밋마다 빌드와 테스트를 자동으로 실행하면, 결함을 빠르게 발견하고 수정할 수 있다. 이는 시스템 통합의 복잡도를 줄이고, 배포 과정에서 발생할 수 있는 위험을 사전에 방지한다.

테스트 자동화가 제대로 작동하려면, 테스트 스크립트나 셸 명령을 통해 ROS2 환경을 설정하고 테스트를 실행하는 절차가 표준화되어 있어야 한다. 예를 들어, 다음과 같이 테스트 셸 스크립트를 작성할 수 있다.

```bash
#!/usr/bin/env bash

colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release
colcon test --merge-install
colcon test-result --verbose
```

이를 CI 환경에 적용하면, 매 빌드마다 위 스크립트가 자동으로 실행되어 테스트 상태를 보고해 준다.

#### 테스트 절차를 시각화하기

아래는 ROS2 테스트 절차를 간단히 표현한 플로우차트 예시이다.

{% @mermaid/diagram content="flowchart LR
A\[Plan Testing\nStrategy] --> B\[Implement\nTests]
B --> C\[Run ROS2 Nodes\nwith Tests]
C --> D\[Analyze Test\nResults]
D --> E\[Refine\nand Re-test]" %}

이처럼 반복적이고 체계적인 테스트 프로세스를 구축하면, 출시 전에 발견하기 힘든 오류나 성능 이슈를 사전에 찾아낼 가능성이 크게 높아진다.

#### 시뮬레이션 환경에서의 테스트

로보틱스 시스템은 실제 하드웨어가 고가이거나, 작동 과정에서 위험 요소가 있을 수 있기 때문에 시뮬레이션 환경을 적극적으로 활용한다. ROS2에서는 Gazebo, Webots, Ignition 등의 시뮬레이션 툴과 연동하여 실제 센서·액추에이터와 유사한 조건을 가정한 테스트를 수행할 수 있다. 시뮬레이션 기반 테스트는 다음과 같은 장점을 제공한다.

* **비용 절감** 실제 하드웨어를 무리하게 동작시키거나, 반복적으로 사용해 발생할 수 있는 물리적 손상을 최소화한다.
* **풍부한 시나리오 설정** 다양한 환경 조건(조도, 바람, 마찰력 등)을 가정하고 노드를 테스트할 수 있어, 예외 상황을 쉽게 재현할 수 있다.
* **자동화 용이성** 테스트 스크립트 내에서 시뮬레이터를 구동하고, 테스트가 끝난 뒤 시뮬레이터를 종료하는 과정을 자동화하기가 쉽다.

ROS2의 노드는 실제 하드웨어 환경이나 시뮬레이션 환경에서 동일한 인터페이스를 사용하므로, 시뮬레이션 단계에서 발견된 문제를 사전에 수정해 실기기 단계에서의 리스크를 크게 줄일 수 있다.

#### Hardware-In-the-Loop(HIL) 테스트

시뮬레이션 환경이 아무리 실제 상황에 가깝다 해도, 물리적 특성과 센서 잡음, 네트워크 지연 같은 요소는 실물 기반 테스트를 완전히 대체하기 어렵다. 따라서 최종적으로는 실제 하드웨어(제어기, 센서, 모터, GPU 등)와의 연동이 필수적이다.

HIL(Hardware-In-the-Loop) 테스트는 시뮬레이션과 실제 하드웨어를 접목하여, 다음을 확인한다.

* **실제 센서 데이터 검증** 시뮬레이션에서 가정했던 센서 노이즈와 실제 노이즈가 얼마나 차이가 있는지, 센서 융합 알고리즘이 예상대로 동작하는지 확인한다.
* **실제 액추에이터 제어 특성 파악** 모터나 서보 같은 구동부를 실제로 제어할 때, 시뮬레이션과 어떤 차이가 발생하는지 비교한다.
* **메시지 전달 지연 분석** 물리적인 케이블, 무선 통신 환경에서 발생하는 지연이 시뮬레이션에서 예상했던 값과 어떻게 다른지 파악한다.

ROS2 시스템에 HIL 테스트를 구축하기 위해서는, 소프트웨어와 하드웨어 인터페이스가 명확히 정의되어 있어야 한다. 예를 들어, 센서 드라이버 노드의 입출력 포맷이 표준화되어 있어야 실제 하드웨어를 교체하거나 추가할 때 최소한의 수정만으로 테스트가 가능하다.

#### 실시간성(Real-Time)과 동시성(Concurrency) 검증

ROS2는 멀티쓰레딩, 비동기 콜백, RTOS(Real-Time OS) 지원 등을 통해 복잡한 로보틱스 응용에도 적용 가능하도록 설계되었다. 다만, 실시간성 요구사항(Strict Deadline)이나 고도로 동시성(Concurrency)이 필요한 시스템이라면 테스트 전략이 더 엄격해져야 한다.

* **실시간 스케줄링 검증** 실시간 운영체제나 리눅스의 RT 패치(RT-Preempt) 같은 환경에서, ROS2 노드의 스케줄링이 의도한 주기(Period)와 마감 시간(Deadline)을 만족하는지 확인한다.
* **동시 데이터 접근 및 경쟁 상태(Race Condition) 점검** 여러 콜백 함수가 동시에 자원을 참조·갱신할 때, Lock이나 Mutex를 적절히 사용했는지 확인한다. 잘못된 동기화는 결과 불일치, 데드락, 혹은 시스템 크래시를 유발할 수 있다.
* **타이머 기반 콜백, QoS 설정 검증** ROS2의 QoS(Profile) 설정이 요구사항을 충족하는지, 예를 들어 Best Effort 통신이 아닌 Reliable 통신이 필요한 상황에서 QoS를 올바르게 구성했는지 등을 점검한다.

이러한 검증을 위해서는 실시간성 로거(Real-Time Logger)나 트레이싱 툴을 사용하는 것이 좋다. ROS2 노드 간 메시지 전달 타이밍, 쓰레드 스위칭(Threads Switching) 등을 세밀히 추적하여 문제 발생 지점을 찾는다.

#### 장애 주입(Injection) 테스트

테스트 범위를 더욱 넓히기 위해, ROS2 노드에 고의로 장애나 결함을 주입해보는 기법을 사용할 수 있다. 이를 통해 다음과 같은 상황에 대한 복원력(Resilience)을 점검한다.

* **의도된 예외 상황에서의 노드 동작 확인** 예를 들어, 특정 토픽에 이상치 데이터를 전송하여 노드가 이를 어떻게 처리하는지 모니터링한다.
* **네트워크 패킷 손실, 지연 시뮬레이션** 실제 로봇에서 무선 네트워크가 불안정해진 상황을 재현하기 위해, 일부 패킷을 인위적으로 유실시키거나 지연시킨다.
* **시스템 장애 복구 테스트** 노드가 예외 상황 이후 재시작하거나, 네트워크가 복구되었을 때 어떻게 정상 동작으로 돌아오는지 평가한다.

이는 꼭 시뮬레이션 환경 뿐만 아니라 실제 하드웨어를 사용하는 HIL 테스트에서도 적용 가능한 강력한 방법이며, 안정성을 높이는 데 큰 도움이 된다.

#### 정적 분석(Static Analysis)과 코드 품질

ROS2 애플리케이션을 작성할 때, 코드 레벨에서 발견 가능한 잠재적 오류와 스타일 위반 사항을 미리 잡아내기 위해 정적 분석 도구를 활용한다. 대표적으로 C++ 계열에서는 clang-tidy, cppcheck, cpplint 등이 쓰이며, Python 계열에서는 flake8, pylint 등을 사용할 수 있다. 정적 분석 단계는 실제 런타임 테스트 이전에 코드를 점검함으로써 다음을 기대할 수 있다.

* **코드 품질 향상** 변수 사용 범위, 메모리 누수, 잘못된 포인터 연산 등을 사전에 확인해 런타임 오류로 이어질 가능성을 줄인다.
* **일관된 코딩 스타일 유지** 여러 명이 협업하는 ROS2 프로젝트에서 코딩 스타일을 자동으로 점검하여 가독성 문제와 유지보수성 문제를 해소한다.
* **컴파일 타임에 오류 검출** 테스트 코드와 애플리케이션 코드를 함께 정적 분석 대상으로 삼으면, 빌드 전에 문제를 확인해 수정할 수 있다.

ROS2 패키지 구조상, CMakeLists.txt와 package.xml 내부에서 정적 분석을 위한 빌드 옵션을 추가하거나, colcon 빌드 파이프라인을 수정해 자동 실행을 설정할 수 있다.

#### 동적 분석(Dynamic Analysis)과 프로파일링

실제 ROS2 노드를 실행시키고, 런타임에 발생하는 메모리 사용, CPU 부하, 스레드 동작 등을 살펴보는 동적 분석 기법도 매우 중요하다. 특히 다음과 같은 도구가 많이 사용된다.

* **Valgrind** 메모리 누수, 잘못된 메모리 접근 등을 추적할 수 있다. ROS2 노드가 여러 개 실행되는 상황에서도, 특정 노드만을 대상으로 분석 범위를 제한할 수 있다.
* **GDB/Lldb** 디버거를 통해 노드 크래시 시점을 분석하거나, 콜스택(Call Stack)을 추적한다.
* **perf, eBPF, sysstat** 리눅스 환경에서 CPU·메모리 사용량, 스레드 스위칭(Threads Switching), Page Fault 발생 여부 등을 모니터링하여 병목 현상을 찾아낸다.

동적 분석을 통해, 실제로 노드가 의도된 주기로 센서를 읽거나, 부하가 많은 작업을 처리하는 과정에서 예기치 못한 병목(Bottleneck)이 발생하는지 확인할 수 있다. 이를 통해 ROS2 애플리케이션의 성능과 안정성을 개선한다.

#### 코드 커버리지(LCOV, gcov) 측정

코드 커버리지는 특정 테스트 스위트가 전체 코드 중 몇 퍼센트를 실행했는지를 나타내는 정량적인 지표다. C++ 코드의 경우 gcov, lcov 등을 이용해 함수, 라인, 분기(Branch) 단위 커버리지를 측정한다. 예시 명령어는 아래와 같다.

```bash
# 빌드 시 커버리지 옵션 적용
colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="--coverage" 

# 테스트 실행
colcon test

# 커버리지 정보 수집
lcov --directory . --capture --output-file coverage.info
genhtml coverage.info --output-directory coverage_report
```

이렇게 수집된 커버리지 리포트를 통해 “어떤 부분이 테스트되지 않았는지”를 식별하고, 추가 테스트 케이스를 설계하는 근거로 삼을 수 있다. 로봇 제어 알고리즘이나 에러 핸들링 로직처럼 중요한 코드 영역이 커버되지 않았다면, 시스템 안정성에 문제가 될 수 있으므로 우선순위를 높여 테스트 시나리오를 추가해야 한다.

#### BDD/ATDD와 시나리오 기반 테스트

개발·테스트 프로세스에서, 요구사항을 시나리오 형태로 명세한 뒤 이를 자동화된 테스트로 구현하는 접근이 BDD(Behavior-Driven Development) 또는 ATDD(Acceptance Test-Driven Development)이다. ROS2에서도 다음과 같은 방법으로 시나리오 기반 테스트를 적용할 수 있다.

1. **사용자 스토리 정의** “로봇이 주행 중 장애물을 발견하면, 일정 거리 전에 멈춘다” 같은 시나리오를 텍스트 형태로 작성한다.
2. **시나리오를 테스트 코드로 변환** 시나리오에 따라 토픽 메시지를 퍼블리시해 주고, 기대되는 응답(예: 정지 명령)이 제대로 나오는지 확인한다.
3. **시나리오 반복 실행** 시나리오 수행을 자동화해, CI 파이프라인에서 빌드 후 반복적으로 테스트한다.

이 기법은 최종 사용자 입장에서 요구사항이 충족되고 있는지를 직관적으로 확인하기에 적합하다. 예컨대 Cucumber, Behave 등의 BDD 툴을 ROS2 테스트에 접목하기도 한다.

#### 방어적 프로그래밍과 어서션(Assertion)

테스트는 사후 검증이지만, 코드 자체에 잘못된 입력 또는 비정상 상태를 조기에 감지하기 위한 안전장치(Assertion)를 두면 테스트가 더욱 효율적이 된다. 예를 들어, 센서에서 들어오는 데이터 범위가 $\[0, 100]$를 넘지 않는다고 가정할 경우, 이를 코드 내에서 명시적으로 검증하고 에러 로그를 남길 수 있다.

* **ROS2 Logging** `RCLCPP_ERROR`, `RCLCPP_WARN` 등의 매크로를 사용해 비정상 상황에서 적절한 메시지를 출력한다.
* **조건 검사** `assert(value >= 0 && value <= 100)` 같은 C/C++ 표준 어서션을 통해 가정이 깨졌을 때 즉시 감지한다.
* **에러 핸들링 및 리턴** 함수를 종료하거나, 노드를 안전 모드로 전환시키는 로직을 코드 내에 명시해 예외 상황을 유연하게 처리한다.

이런 방법을 병행하면, 테스트 단계에서 발견하기 어려운 경계값 오류나 논리적 오류를 실시간으로 확인하여 디버깅할 수 있다.

#### 자동화된 회귀 테스트(Regression Testing)와 버그 추적

ROS2 애플리케이션은 자율주행, 팔 제어 등 기능이 복잡하고 상호 의존성이 높다. 이때 새 기능을 추가하거나 기존 기능을 수정하면, 예상치 못한 부분에서 동작 이상이 발생할 수 있다. 이를 방지하기 위해 **자동화된 회귀 테스트**를 구축하고, 조직적으로 버그를 추적하는 절차가 중요하다.

* **회귀 테스트 세트 구성** 과거에 보고된 버그와 그 수정 사항을 중심으로 테스트 케이스를 만들고, 이를 CI 파이프라인에 포함시킨다. 이렇게 하면 동일한 유형의 문제가 재발했는지 쉽게 확인할 수 있다.
* 버그 추적 시스템

  Jira, Redmine, GitHub Issues 등 버그 추적 시스템을 통해 ROS2 노드별 결함 상황, 영향 범위, 재현 절차 등을 정리한다.

  * 재현 가능한 최소 사례(Minimal Reproducible Example)를 함께 기록해, 같은 버그가 발생했을 때 신속히 대응할 수 있도록 한다.
* **테스트 자동 실행** “PR(풀 리퀘스트)을 올리면 빌드와 테스트가 자동으로 돌아가고, 결과를 확인한다”는 패턴이 일반화되어야 한다. 코드를 머지하기 전에 자동화된 테스트가 통과되지 않으면 합치지 않는 정책을 세우면, 품질을 일정 수준 이상으로 유지할 수 있다.
* **로깅과 알림(Notifications)** 회귀 테스트 중에 새 결함이 발견되면, 구성원에게 자동으로 알림이 가도록 설정한다. 이를 통해 수정 시점을 앞당기고, 빠르게 회귀 테스트를 반복 수행할 수 있다.

#### 테스트 문서화와 추적성(Traceability)

로보틱스 시스템은 실제 현장에서 안전과 직결될 수 있어, 테스트가 단순 권장사항이 아니라 필수 요구사항으로 간주되기도 한다. 이때 테스트 결과를 문서화하고, 각 테스트가 어떤 요구사항을 검증하는지 “추적성(Traceability)”을 확보하는 과정이 필요하다.

* **요구사항-테스트 매핑** 요구사항 목록을 번호나 태그로 관리하고, 각각의 테스트 케이스가 어느 요구사항을 만족하거나 검증하는지 매핑 테이블로 관리한다. 이를 통해 테스트 누락을 줄이고, 요구사항 변경 시 영향을 받은 테스트 케이스를 빠르게 찾는다.
* **테스트 계획서와 결과서** 테스트 범위, 방법, 환경, 일정 등을 정리한 계획서를 작성하고, 실제 테스트 수행 후에는 결과서(Report)를 작성한다. ROS2 프로젝트에서 주로 사용되는 colcon test-result 보고서 등과 연계해 더 자세한 수치를 남길 수 있다.
* **이슈 트래킹과 통합** 버그나 개선 요청이 들어올 때, 어떤 테스트 케이스가 실패했는지 또는 어떤 테스트 케이스를 추가해야 하는지를 연동해 관리한다. 이렇게 하면 로보틱스 프로젝트의 규모가 커져도 일관된 품질 관리가 가능하다.

#### 테스트 조직과 협업

ROS2 프로젝트는 종종 소프트웨어 엔지니어, 로보틱스 엔지니어, 하드웨어 엔지니어, 데이터 사이언티스트 등 다양한 분야의 전문가들이 협업하는 형태로 진행된다. 테스트 관점에서도 역할과 책임을 명확하게 구분하는 것이 효율적이다.

* **테스트 엔지니어/QA 팀** 소프트웨어 테스트 전문가가 테스트 계획 수립, 테스트 프레임워크 관리, CI/CD 파이프라인 설정 등을 주도한다. 로보틱스 특유의 하드웨어 연동 이슈가 있으므로, 하드웨어 팀과의 긴밀한 협업이 필요하다.
* **개발자(로보틱스 엔지니어) 참여** 로직 단위(Unit) 테스트, 노드 단위(Integration) 테스트 등 개발자가 직접 작성·유지할 필요가 있다. 특히 ROS2 메시지 구조나 노드 그래프에 대한 깊은 이해가 필요한 부분은 개발자가 주도적으로 작성하는 것이 효율적이다.
* **운영/현장 피드백** 현장에서 운용 중 발생하는 문제를 바로 버그 트래커에 등록하고, 테스트 케이스로 환원(Feedback)하는 체계를 마련한다. 실증 환경(Production Environment)에서 얻은 피드백이 가장 가치 있는 테스트 시나리오가 되기도 한다.

#### ROS2 표준 테스트 프레임워크와 툴체인

ROS2는 기본적으로 ament 빌드 시스템을 사용하며, 여기에 여러 테스트 프레임워크를 간편하게 연동할 수 있도록 지원한다. 대표적으로 다음과 같은 툴체인과 플러그인을 통해 다양한 언어와 테스트 유형을 손쉽게 설정·실행할 수 있다.

**ament\_gtest**: C++ 기반 테스트 프레임워크 Google Test(GTest)를 ROS2 패키지에서 사용할 수 있게 하는 플러그인이다. CMakeLists.txt에 아래와 같은 형태로 간단히 추가할 수 있다.

```cmake
find_package(ament_cmake_gtest REQUIRED)

ament_add_gtest(my_test test/test_my_code.cpp)
if(TARGET my_test)
  target_link_libraries(my_test
    my_library  # 테스트 대상 라이브러리
  )
endif()
```

이렇게 빌드하면 `colcon test` 명령으로 자동 실행되어 결과를 수집할 수 있다.

**ament\_pytest**: Python 기반 로직을 테스트할 때 주로 사용한다. Pytest를 이용해 작성한 테스트 스크립트가 ROS2 패키지 내부에서 동작하도록 연결해 준다.

```cmake
find_package(ament_cmake_pytest REQUIRED)
ament_add_pytest_test(test_python_code
  test/test_my_python_code.py
)
```

파이썬 스크립트 내에서 ROS2 노드를 직접 실행하거나, Mock 객체를 사용해 노드 간 통신을 시뮬레이션하는 것이 가능하다.

**ament\_lint, ament\_cpplint**: 코드 스타일 점검과 간단한 정적 분석을 지원하는 플러그인이다. $package.xml$ 또는 CMakeLists.txt에 설정해두면, `colcon test` 시점에 자동으로 스타일 위반 여부가 체크되어 결과 리포트를 출력한다.

#### 분산 환경 테스트와 로깅

ROS2는 네트워크 상에서 여러 물리적 장비 혹은 컨테이너에서 분산 실행될 수 있으므로, 다음과 같은 사항도 고려해야 한다.

**멀티머신 테스트 설정**: 두 대 이상의 PC나 SBC(Single Board Computer)를 통해 실제 네트워크 환경을 재현해야 할 경우, 각 머신에서 동일한 ROS2 버전과 워크스페이스를 세팅한 뒤 테스트 스크립트에 SSH 연결 또는 원격 명령을 삽입할 수 있다.

```bash
ssh user@remote-machine 'source /opt/ros/humble/setup.bash && ros2 run package node'
```

**로깅 및 메트릭 수집**: 네트워크 지연, CPU 사용량, 토픽 퍼블리시 빈도 등을 실시간으로 로깅해 중앙 서버에서 수집·분석하는 방안을 마련하면, 분산 테스트 시나리오를 더 정교하게 구성할 수 있다. 예를 들어, [ros2\_tracing](https://gitlab.com/ros-tracing/ros2_tracing) 패키지를 사용해 분산 노드 간 메시지 처리 시간을 시각화할 수도 있다.

#### 안정성(Availability)와 페일오버(Failover) 시나리오

안정성을 요구하는 로봇 시스템에서는 노드가 충돌(Crash)하거나 네트워크 연결이 끊어져도 빠르게 복구(Failover)하거나 대체 노드로 전환해 계속 동작해야 하는 경우가 많다. 이에 대한 테스트 시나리오를 수립할 때, 다음과 같은 기법을 활용한다.

**리더-팔로워(Leader-Follower) 구조 검증**: 한 노드가 종료(Shutdown)되었을 때 자동으로 팔로워 노드가 리더 역할을 대신 수행하는지 테스트한다. 예를 들어, 다수의 동기화된 로봇이나 분산 SLAM 환경에서 중요한 기법이다.

**ROS2 라이프사이클(Lifecycle) 노드**: ROS2는 노드가 활성(Active), 비활성(Inactive) 상태를 전환하며 동작할 수 있는 Lifecycle Node를 제공한다. 이를 테스트해서, 오류 상태로 전이 시 어떻게 복구할지를 반복 검증한다.

**네트워크 장애 발생 시나리오**: 라우터나 Wi-Fi 어댑터를 재부팅하거나, 특정 시간 동안 네트워크를 차단하는 방식으로 장애를 재현하여, ROS2 노드가 일정 시간 안에 다시 연결되는지 확인한다.

#### 대규모 실증 테스트 시 고려 사항

여러 대의 로봇이나 센서가 동시에 동작하는 대규모 테스트 환경에서는 테스트 자동화와 모니터링 수단이 더욱 중요해진다.

**로그 저장 및 집계(Logging Aggregation)**: 수십 개 노드에서 나오는 로그를 한 곳에 모아, 타임스탬프(Clock Synchronization)를 기준으로 맞춰 본다. 그래야 이벤트의 순서나 상관관계를 쉽게 파악할 수 있다.

**클라우드 기반 시뮬레이션/테스트**: 대형 로보틱스 프로젝트는 클라우드 상에서 CI 파이프라인과 시뮬레이션을 병행해, 동시다발적으로 여러 테스트 사례를 실행하고 결과를 통합할 수도 있다.

**분산 기기(Edge) 업데이트 테스트**: 배포(Deployment) 자동화와 함께, 새로운 테스트 결과에 따라 펌웨어나 소프트웨어를 에지 디바이스(Edge Device)에 무중단으로 업데이트하는 시나리오를 마련해두면 운영 과정에서 발생할 수 있는 리스크를 줄인다.