1261.68 행동 제어의 테스트와 검증 방법론

1. 행동 제어 테스트의 필요성과 목표

로봇 행동 제어 시스템은 센서 입력, 액추에이터 출력, 통신 프로토콜, 의사결정 로직이 복합적으로 결합된 구조이며, 이러한 시스템의 정확성과 안전성을 보장하기 위해서는 체계적인 테스트와 검증(Verification and Validation, V&V) 방법론이 필수적이다. 행동 제어 테스트의 핵심 목표는 로봇이 명세된 행동을 정확히 수행하는지, 예상치 못한 환경 조건에서 안전하게 대응하는지, 그리고 행동 간 전이가 설계된 규칙에 따라 이루어지는지를 체계적으로 확인하는 데 있다.

행동 제어 시스템의 테스트는 일반적인 소프트웨어 테스트와 구별되는 고유한 난제를 포함한다. 첫째, 행동 제어는 물리적 환경과의 상호작용에 의존하므로 순수한 논리적 검증만으로는 불충분하다. 둘째, 행동의 실행 결과가 비결정적(non-deterministic) 센서 데이터에 따라 달라지며, 동일한 테스트를 반복하여도 동일한 결과가 보장되지 않을 수 있다. 셋째, 실시간 제약 조건(real-time constraints)이 존재하여 행동의 정확성뿐 아니라 시간적 적시성(timeliness)까지 검증해야 한다.

2. 검증과 확인의 구분

소프트웨어 공학에서 검증(verification)과 확인(validation)은 명확히 구분된다. 검증은 “시스템이 명세에 맞게 올바르게 구현되었는가“라는 질문에 답하며, 확인은 “시스템이 사용자의 실제 요구를 충족하는가“라는 질문에 답한다(Boehm, 1984).

행동 제어 시스템의 맥락에서 검증은 행동 명세서(behavior specification)에 정의된 전제 조건, 사후 조건, 상태 전이 규칙이 구현 코드에서 정확히 반영되었는지를 확인하는 과정이다. 확인은 설계된 행동이 실제 운용 환경에서 로봇의 임무 목표를 달성하는 데 적합한지를 평가하는 과정이다.

3. 테스트 수준과 계층 구조

행동 제어 시스템의 테스트는 다수의 계층적 수준으로 구조화된다.

3.1 단위 테스트

단위 테스트(unit test)는 개별 행동 모듈(behavior module) 또는 행동 프리미티브(behavior primitive)를 독립적으로 테스트하는 단계이다. 이 단계에서는 행동 모듈의 입력-출력 관계, 상태 전이 로직, 예외 처리 경로 등을 격리된 환경에서 검증한다.

단위 테스트를 위해서는 외부 의존성을 모의 객체(mock object)로 대체하는 것이 필수적이다. 센서 입력은 사전 정의된 테스트 데이터로 공급하며, 액추에이터 출력은 기록 및 비교 대상으로 캡처한다. ROS2 환경에서는 rclcpp 테스트 유틸리티와 Google Test(GTest) 프레임워크를 결합하여 행동 노드의 단위 테스트를 구성할 수 있다.

행동 상태 전이의 단위 테스트에서는 다음의 검증 항목이 포함된다.

• 초기 상태에서 실행 시작 시 RUNNING 상태로의 전이
• 목표 달성 시 SUCCESS 상태로의 전이
• 오류 발생 시 FAILURE 상태로의 전이
• 취소 요청 시 CANCELLED 상태로의 전이
• 잘못된 전제 조건에서의 즉시 실패 반환

3.2 통합 테스트

통합 테스트(integration test)는 다수의 행동 모듈이 결합되어 작동할 때의 상호작용을 검증한다. 행동 트리 또는 상태 머신에서 복수의 행동이 순차적, 병렬적, 또는 조건부로 실행되는 시나리오를 테스트한다.

통합 테스트에서 검증해야 할 핵심 항목은 다음과 같다.

• 행동 간 데이터 전달(blackboard 또는 공유 변수)의 정확성
• 행동 전환 시점의 올바른 트리거링
• 병렬 실행 시 자원 경합(resource contention)의 부재
• 선점(preemption) 발생 시 이전 행동의 정리(cleanup) 완료
• 통신 채널(토픽, 서비스, 액션)을 통한 행동 간 메시지 교환의 정확성

ROS2 환경에서는 launch_testing 프레임워크를 활용하여 다수의 노드를 동시에 기동하고, 노드 간 통신을 포함한 통합 테스트를 자동화할 수 있다.

3.3 시스템 테스트

시스템 테스트(system test)는 전체 행동 제어 시스템을 하나의 단위로 취급하여, 완전한 임무 시나리오의 실행을 검증한다. 시스템 테스트는 시뮬레이션 환경 또는 실제 하드웨어에서 수행되며, 로봇이 주어진 임무를 처음부터 끝까지 정상적으로 수행하는지를 평가한다.

시스템 테스트에서는 정상 시나리오(nominal scenario)뿐 아니라, 비정상 시나리오(off-nominal scenario)도 반드시 포함해야 한다. 비정상 시나리오에는 센서 장애, 통신 단절, 장애물 돌발 출현, 배터리 부족 등 운용 중 발생 가능한 예외 상황이 포함된다.

4. 형식 검증 방법

4.1 모델 검사

모델 검사(model checking)는 행동 제어 시스템의 상태 공간을 체계적으로 탐색하여, 주어진 속성(property)이 모든 가능한 실행 경로에서 만족되는지를 자동으로 검증하는 형식적 방법이다. 행동 제어 시스템을 유한 상태 전이 시스템(finite-state transition system)으로 모델링한 후, 시간 논리(temporal logic) 공식으로 표현된 속성을 검증한다.

행동 제어 시스템에서 모델 검사로 검증 가능한 속성의 유형은 다음과 같다.

안전성 속성(safety property): “로봇이 금지 구역에 진입하는 행동 상태에 도달하지 않는다“와 같이, 바람직하지 않은 상태가 절대 발생하지 않음을 보장하는 속성이다. 선형 시간 논리(Linear Temporal Logic, LTL)에서 \Box \lnot \phi 형태로 표현된다. 여기서 \Box는 “항상(always)” 연산자이고, \phi는 금지된 조건을 나타낸다.

활성 속성(liveness property): “로봇은 결국 목표 지점에 도달한다“와 같이, 바람직한 상태가 언젠가는 반드시 발생함을 보장하는 속성이다. LTL에서 \Diamond \psi 형태로 표현되며, \Diamond는 “결국(eventually)” 연산자이다.

공정성 속성(fairness property): 특정 행동이 무한히 활성화 기회를 부여받을 경우 무한히 실행됨을 보장하는 속성으로, 기아 상태(starvation)의 부재를 검증한다.

SPIN(Simple Promela Interpreter)(Holzmann, 2004)과 NuSMV(Cimatti et al., 2002)는 행동 제어 시스템의 모델 검사에 활용되는 대표적 도구이다.

4.2 정리 증명

정리 증명(theorem proving)은 행동 제어 시스템의 속성을 수학적 정리로 표현하고, 공리(axiom)와 추론 규칙에 따라 해당 정리의 참(truth)을 연역적으로 증명하는 방법이다. 모델 검사와 달리 상태 공간 폭발(state space explosion) 문제에 제약받지 않으나, 증명 과정에 인간 전문가의 개입이 요구되는 경우가 많다.

Coq, Isabelle/HOL 등의 대화형 정리 증명기(interactive theorem prover)가 행동 제어 시스템의 정형적 검증에 활용될 수 있으며, 특히 안전 필수(safety-critical) 로봇 시스템에서는 형식 검증의 필요성이 더욱 높다.

5. 테스트 기법

5.1 시나리오 기반 테스트

시나리오 기반 테스트(scenario-based testing)는 로봇의 운용 시나리오를 사전에 정의하고, 각 시나리오에서 행동 제어 시스템의 응답을 검증하는 방법이다. 시나리오는 초기 조건, 환경 이벤트의 시간적 시퀀스, 기대되는 행동 시퀀스로 구성된다.

시나리오의 체계적 생성을 위해 조합 테스트(combinatorial testing) 기법을 적용할 수 있다. 환경 조건(조도, 장애물 분포, 바닥 재질), 로봇 상태(배터리 잔량, 센서 정상/비정상), 임무 파라미터(목표 위치, 제한 시간) 등의 조합을 체계적으로 열거하여 테스트 시나리오를 생성한다.

5.2 돌연변이 테스트

돌연변이 테스트(mutation testing)는 원본 행동 제어 코드에 의도적으로 결함(mutant)을 삽입한 후, 기존 테스트 스위트가 해당 결함을 탐지할 수 있는지를 평가하는 기법이다. 탐지되지 않는 돌연변이가 존재하면, 해당 부분을 검증하는 테스트 케이스가 부족하다는 것을 의미한다.

행동 제어 시스템에서 적용 가능한 돌연변이 연산자(mutation operator)에는 다음이 포함된다.

• 상태 전이 조건의 반전(condition negation)
• 성공/실패 반환값의 교환
• 행동 실행 순서의 변경
• 조건 분기에서의 비교 연산자 변경(\leq를 <로 변경 등)
• 타임아웃 값의 변경

5.3 회귀 테스트

회귀 테스트(regression testing)는 행동 제어 시스템에 수정이 가해진 후, 기존에 정상 작동하던 기능이 영향을 받지 않았는지를 검증하는 과정이다. 지속적 통합(Continuous Integration, CI) 파이프라인에 행동 제어 테스트 스위트를 통합하여, 코드 변경 시마다 자동으로 회귀 테스트를 실행하는 것이 권장된다.

ROS2 환경에서는 colcon test를 통해 패키지 수준의 자동화된 회귀 테스트를 수행할 수 있으며, GitHub Actions, Jenkins 등의 CI 도구와 연동하여 빌드-테스트-보고의 자동화 파이프라인을 구축할 수 있다.

6. 커버리지 지표

행동 제어 시스템의 테스트 충분성을 평가하기 위해 다양한 커버리지 지표(coverage metric)가 활용된다.

행동 트리 기반 시스템에서는 트리 노드 커버리지(tree node coverage)와 경로 커버리지(path coverage)가 추가적으로 적용된다. 트리 노드 커버리지는 행동 트리의 모든 노드(행동 노드, 조건 노드, 제어 노드)가 최소 한 번 이상 실행(tick)되었는지를 측정한다.

7. 테스트 오라클과 평가 기준

7.1 오라클 문제

행동 제어 시스템의 테스트에서 오라클 문제(oracle problem)는 특히 심각한 난제이다. 오라클(oracle)이란, 주어진 입력에 대해 기대되는 올바른 출력을 제공하는 메커니즘이다. 물리적 환경에서 동작하는 로봇의 행동은 연속적이고 비결정적이므로, 이산적 소프트웨어 시스템에서와 같은 정확한 기대값 비교가 어렵다.

이 문제를 완화하기 위해, 행동 제어 테스트에서는 정확한 값 일치(exact match) 대신 다음의 평가 기준을 채택한다.

• 허용 구간(tolerance band): 로봇의 최종 위치가 목표 위치로부터 허용 오차 \epsilon 이내에 있는지를 판정한다.
• 시간 제약(temporal constraint): 행동이 지정된 시간 한계(deadline) 내에 완료되었는지를 판정한다.
• 불변 조건(invariant): 행동 실행 중 특정 안전 조건(예: 속도 제한, 금지 구역 미진입)이 항상 유지되었는지를 판정한다.
• 순서 제약(ordering constraint): 행동이 명세된 순서에 따라 실행되었는지를 판정한다.

7.2 통계적 검증

센서 노이즈와 환경 불확실성으로 인해 단일 실행의 결과만으로 행동 제어의 정확성을 판단하는 것은 불충분하다. 통계적 검증(statistical verification) 접근법에서는 동일한 테스트 시나리오를 다수 회 반복 실행하여, 성공률, 평균 완료 시간, 경로 편차의 분포 등을 통계적으로 분석한다.

몬테카를로 시험(Monte Carlo testing)은 환경 파라미터를 확률 분포에 따라 무작위 샘플링하여 다수의 테스트 인스턴스를 생성하는 기법이다. 이를 통해 행동 제어 시스템의 강건성(robustness)을 정량적으로 평가할 수 있다.

8. 테스트 자동화 인프라

행동 제어 시스템의 테스트 자동화를 위해 다음의 인프라 구성이 필요하다.

• 테스트 프레임워크: GTest, pytest, launch_testing(ROS2) 등의 프레임워크를 사용하여 테스트 케이스를 정의하고 실행한다.
• 시뮬레이션 환경: Gazebo, Isaac Sim, Webots 등의 시뮬레이터를 활용하여 물리적 환경을 모사한 테스트를 자동화한다.
• 지속적 통합: 코드 변경 시마다 자동으로 빌드, 테스트, 보고를 수행하는 CI 파이프라인을 구축한다.
• 테스트 데이터 관리: rosbag2를 활용하여 실제 운용 데이터를 기록하고, 기록된 데이터를 재생하여 행동 제어 로직을 오프라인으로 검증한다.

이러한 인프라를 통해, 행동 제어 시스템의 품질을 개발 주기 전반에 걸쳐 체계적으로 관리할 수 있다.

참고 문헌

• Boehm, B. W. (1984). “Verifying and Validating Software Requirements and Design Specifications.” IEEE Software, 1(1), 75–88.
• Holzmann, G. J. (2004). The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley.
• Cimatti, A., Clarke, E. M., Giunchiglia, E., Giunchiglia, F., Pistore, M., Roveri, M., Sebastiani, R., & Tacchella, A. (2002). “NuSMV 2: An Open Source Tool for Symbolic Model Checking.” Proceedings of the 14th International Conference on Computer Aided Verification (CAV).
• Afzal, W., Torkar, R., & Feldt, R. (2009). “A Systematic Review of Search-Based Testing for Non-Functional System Properties.” Information and Software Technology, 51(6), 957–976.
• Araiza-Illan, D., Western, D., Pipe, A. G., & Eder, K. (2016). “Systematic and Realistic Testing in Simulation of Control Code for Robots in Collaborative Human-Robot Interactions.” Proceedings of the 15th Annual Conference Towards Autonomous Robotic Systems (TAROS).

v0.1.0