AMR Engineering Process and Development Manual — Ch.12: Testing and Validation Process [KR]

STATERA Library · Series 02 · Volume 10 · Chapter 12 · KR
Source: https://github.com/Statera-Library/02_Vol_10_AMR_Engineering_Process_and_Development_Manual/blob/main/12_Testing_and_Validation_Process/12_Testing_and_Validation_Process_KR.md

Volume10. AMR Engineering Process and Development Manual

Chapter12. Testing and Validation Process

12.01 Testing Strategy and Framework

시험 전략 및 프레임워크(Testing Strategy and Framework)는 자율이동로봇(Autonomous Mobile Robot, AMR)이 초기 개발 단계부터 양산 출시, 그리고 실제 현장 운용에 이르기까지 어떤 방식으로 평가될 것인지를 정의한다. 이 프레임워크는 제품 요구사항(Product Requirements), 시스템 위험(System Risk), 엔지니어링 근거(Engineering Evidence), 시험 환경(Test Environment), 합격 기준(Acceptance Criteria), 출시 의사결정(Release Decision)을 하나의 통합된 프로세스로 연결한다. 그 목적은 개발 마지막 단계에서 단순히 결함을 찾는 것이 아니라, 결함을 사전에 예방하고, 조기에 발견하며, 의도된 동작을 검증하고, 실제 운용 환경에서 로봇이 안전하고 신뢰성 있게 임무를 수행할 수 있음을 입증하는 데 있다.

효과적인 시험 전략은 제품과 그 사용 목적, 그리고 고장이 발생했을 때의 영향을 명확히 이해하는 것에서 시작된다. 엔지니어링 팀은 로봇의 운용 환경, 페이로드(Payload), 주행 속도, 작업 주기(Duty Cycle), 주행 구역, 사람과의 상호작용, 충전 방식, 통신 인프라, 유지보수 개념을 식별해야 한다. 시험의 우선순위는 이러한 조건을 반영해야 한다. 병원 배송 로봇(Hospital Delivery Robot), 견인 로봇(Towing Robot), 실외 점검 로봇(Outdoor Inspection Platform)은 유사한 하드웨어와 소프트웨어를 사용할 수 있지만, 요구되는 시험 시나리오, 위험 관리, 성능 한계, 운용 승인 기준은 서로 다를 수 있다.

프레임워크는 요구사항과 검증 활동(Verification Activity) 사이의 직접적인 추적성(Traceability)을 유지해야 한다. 기능(Function), 성능(Performance), 안전(Safety), 신뢰성(Reliability), 환경(Environment), 사이버보안(Cybersecurity), 인터페이스(Interface)에 대한 모든 요구사항은 하나 이상의 시험 방법(Test Method)과 측정 가능한 합격 기준에 연결되어야 한다. 요구사항이 변경되더라도 이러한 연결 관계는 유지되어야 한다. 추적성은 단순 시연에서 정상적으로 동작했다는 이유만으로 기능이 올바르다고 가정하는 것을 방지하며, 모든 기능이 승인된 방법을 통해 분석, 시뮬레이션, 시험 또는 기타 검증 절차를 거쳤음을 입증하는 근거를 제공한다.

시험은 모든 기능에 동일한 노력을 투입하기보다는 위험(Risk)을 기준으로 계획해야 한다. 사람의 부상, 충돌, 제어 상실, 임무 중단, 장비 손상, 현장 복구의 어려움을 초래할 수 있는 기능은 높은 위험 요소로 분류해야 한다. 새로운 기술, 긴밀하게 결합된 인터페이스, 동작 여유가 적은 부품, 과거에 문제가 발생했던 기능 역시 높은 수준의 시험이 필요하다. 위험 기반 계획(Risk-Based Planning)은 시험의 깊이, 반복 횟수, 독립성, 환경 스트레스, 계측 장비, 검토 권한을 결정하는 동시에 영향이 작은 기능에 과도한 자원을 사용하는 것을 방지한다.

전체 시험 전략은 가능한 한 낮은 수준에서 결함을 발견할 수 있도록 계층적 검증(Layered Verification)을 사용해야 한다. 개별 알고리즘, 소프트웨어 기능, 전자 모듈, 기계 조립체, 센서, 액추에이터는 상위 시스템에 통합되기 전에 먼저 시험되어야 한다. 이후 명확하게 정의된 인터페이스를 기반으로 서브시스템 시험을 수행한 뒤 전체 차량 시험을 진행해야 한다. 이러한 접근 방식은 디버깅을 단순화한다. 전체 로봇 시험에서 발견된 문제는 여러 구성요소의 상호작용에서 발생하는 경우가 많기 때문이다. 조기에 결함을 분리할수록 개발 속도는 향상되고 수정 비용은 감소한다.

일반적으로 사용되는 시험 프레임워크는 시험 피라미드(Test Pyramid)를 따른다. 빠르고 비용이 낮은 하위 수준 시험을 많이 수행하고, 복잡하고 비용이 높은 시스템 시험과 현장 시험은 상대적으로 적게 수행하는 구조이다. 정적 분석(Static Analysis), 코드 검사(Code Check), 단위 시험(Unit Test), 인터페이스 시험(Interface Test), 부품 시험(Component Test), 시뮬레이션(Simulation)은 자주 수행해야 한다. 반면 통합 시험(Integration Test), 하드웨어 인 더 루프(Hardware-in-the-Loop, HIL), 차량 수준 시험(Vehicle-Level Test), 내구 시험(Endurance Test), 안전 시험(Safety Test), 현장 시험(Field Test)은 주요 개발 단계에서 수행한다. 시험 피라미드는 실제 환경 시험을 줄이라는 의미가 아니라, 상위 시험 전에 품질을 높여 비용이 큰 시험 자원을 효율적으로 활용하기 위한 구조이다.

시험 수명주기(Test Lifecycle)는 구현 이후가 아니라 요구사항과 시스템 아키텍처를 정의하는 단계에서 시작되어야 한다. 엔지니어는 요구사항이 측정 가능한지, 인터페이스가 관측 가능한지, 고장을 주입할 수 있는지, 중요한 상태를 기록할 수 있는지를 검토해야 한다. 시험 포인트(Test Point), 진단 메시지(Diagnostic Message), 시뮬레이션 인터페이스, 데이터 로깅(Data Logging), 교정 접근성, 서비스 모드(Service Mode), 안전 절연 기능은 제품 설계 단계에서부터 포함되어야 한다. 내부 상태를 확인할 수 없는 시스템은 정상적으로 동작하는 것처럼 보여도 실제 검증은 매우 어려울 수 있다. 따라서 시험 가능성(Testability)은 하나의 시스템 요구사항으로 간주되어야 한다.

시험 계획(Test Plan)은 시험 범위(Scope), 목적(Objective), 책임(Responsibility), 시험 수준(Test Level), 시험 환경(Environment), 장비(Equipment), 데이터 요구사항, 시작 조건(Entry Condition), 종료 조건(Exit Condition), 보고 절차를 정의해야 한다. 또한 개발 시험(Development Test), 공식 검증(Formal Verification), 검증(Validation), 생산 시험(Production Test), 시운전(Commissioning), 운용 모니터링(Operational Monitoring)을 명확히 구분해야 한다. 개발 시험은 문제를 찾고 디버깅을 지원하는 데 목적이 있지만, 공식 검증은 승인된 요구사항 충족을 입증하는 것이며, 검증(Validation)은 제품이 실제 목적에 적합한지를 확인하는 과정이다.

시작 조건(Entry Criteria)은 시험 대상이 의미 있는 평가를 수행할 준비가 되었는지를 판단하는 기준이다. 필요한 소프트웨어와 하드웨어 버전이 식별되어 있어야 하고, 알려진 중대한 결함을 검토했으며, 교정 상태가 유효하고, 시험 환경과 계측 장비가 준비되어 있으며, 안전 절차가 승인되어 있어야 한다. 불안정한 구성이나 문서화되지 않은 변경 상태에서 공식 시험을 수행하면 신뢰할 수 있는 결과를 얻을 수 없다. 종료 조건(Exit Criteria)은 합격률, 허용 가능한 잔여 결함, 완료된 보고서, 검토된 이상 현상, 다음 단계 진행을 승인할 권한을 정의해야 한다.

시험 환경(Test Environment)은 현실성과 복잡성을 점진적으로 높이는 구조를 가져야 한다. 소프트웨어는 개발 환경, 자동 빌드 시스템, 시뮬레이션에서 먼저 평가할 수 있다. 이후 서브시스템은 벤치 장비(Bench Rig), 센서 시뮬레이터, 모터 에뮬레이터, 네트워크 시험 장비, HIL 시스템을 활용하여 시험한다. 완전한 로봇은 실내 시험장, 통제된 실외 시험장, 실제 고객 환경, 감독 하의 현장 운용으로 단계적으로 진행할 수 있다. 시뮬레이션은 반복성과 대규모 시험에 강점을 가지며, 실제 하드웨어 시험은 센서 특성, 타이밍, 환경, 기계적 영향과 같은 현실적인 요소를 검증하는 역할을 한다.

시뮬레이션(Simulation)은 다양한 시나리오를 대량으로 생성하고, 드물게 발생하는 상황을 반복하며, 하드웨어가 준비되기 전에 소프트웨어를 검증하는 데 매우 유용하다. 지도(Map), 로봇 동역학(Robot Dynamics), 센서 모델, 교통, 보행자, 장애물, 통신 환경, 고장 조건 등을 체계적으로 변경할 수 있다. 그러나 시뮬레이션 결과는 모델의 정확도(Model Fidelity)에 의존하므로 실제 성능을 자동으로 보장하지는 않는다. 따라서 시험 전략은 어떤 기능은 시뮬레이션으로 충분히 검증할 수 있는지, 어떤 기능은 실제 측정 데이터와의 상관관계가 필요한지, 어떤 기능은 반드시 실제 하드웨어와 환경에서 검증해야 하는지를 정의해야 한다.

하드웨어 인 더 루프(Hardware-in-the-Loop, HIL) 시험은 실제 제어기나 컴퓨팅 하드웨어를 가상의 센서, 액추에이터, 차량 동역학, 환경 모델과 연결하여 수행한다. 이를 통해 제어 로직(Control Logic), 타이밍(Timing), 통신, 전원 상태, 진단 기능, 고장 대응을 실제 차량을 위험에 노출시키지 않고 반복적으로 평가할 수 있다. HIL 시스템은 실제와 유사한 업데이트 주기, 지연, 노이즈, 메시지 손실, 액추에이터 한계, 고장 조건을 재현해야 한다. 또한 모델과 인터페이스는 버전 관리되어야 하며, 부정확한 모델은 잘못된 신뢰를 제공하거나 존재하지 않는 결함을 만들어낼 수 있다.

시스템 통합 시험(System Integration Test)은 기계(Mechanical), 전기(Electrical), 소프트웨어(Software), 센싱(Sensing), 제어(Control), 통신(Communication), 안전(Safety), 사용자 인터페이스(User Interface)가 함께 정상적으로 동작하는지를 검증한다. 통합은 모든 모듈을 한 번에 연결하는 것이 아니라 계획된 순서에 따라 진행해야 한다. 인터페이스 계약(Interface Contract), 메시지 정의, 좌표계, 단위, 타이밍, 전원 상태, 고장 코드, 명령의 소유권을 확인해야 한다. 많은 시스템 오류는 개별 구성요소가 잘못된 것이 아니라 서로 다른 구성요소 간의 인터페이스 불일치에서 발생하므로 강력한 로깅과 동기화된 측정이 필요하다.

시나리오 기반 시험(Scenario-Based Testing)은 개별 기능이 아니라 실제 운용 상황 전체를 기준으로 로봇을 평가한다. 시나리오에는 임무 할당, 초기화, 위치추정(Localization), 경로 계획(Path Planning), 장애물 회피, 도킹(Docking), 페이로드 처리, 충전, 비상 정지, 복구, 임무 보고가 포함될 수 있다. 각 시나리오는 초기 조건, 환경 요소, 참여 객체, 예상 동작, 측정 가능한 결과, 종료 조건을 명확히 정의해야 한다. 속도, 적재량, 조명, 노면 상태, 장애물 밀도, 네트워크 상태, 사람의 행동을 다양하게 변화시켜 운용 한계를 평가해야 한다.

공식적인 시나리오 라이브러리(Scenario Library)는 정상 사례(Nominal Case), 경계 조건(Boundary Condition), 성능 저하 모드(Degraded Mode), 오용 조건(Misuse Condition), 희귀 상황(Rare Event), 엣지 케이스(Edge Case)를 포함해야 한다. 정상 사례는 일상적인 동작을 확인하며, 경계 조건은 최대 적재량, 최소 통과 공간, 저배터리, 높은 교통량, 약한 통신, 극한 온도, 낮은 센서 품질을 평가한다. 성능 저하 시험은 로봇이 감속, 정지, 지원 요청, 안전 위치 복귀, 제한된 기능으로 임무를 지속할 수 있는지를 확인한다. 엣지 케이스는 시뮬레이션, 현장 로그, 사고 기록, 고객 피드백을 통해 지속적으로 추가되어야 한다.

안전 시험(Safety Testing)은 정상 기능 시험과 독립적으로 계획되어야 한다. 정상적인 임무 수행이 위험 감소를 입증하는 것은 아니기 때문이다. 비상정지 장치(Emergency Stop), 보호 영역(Protective Field), 안전 토크 차단(STO), 브레이크, 속도 감시, 인터록, 재시작 방지, 고장 대응은 응답 시간과 정지 거리와 함께 측정 가능한 방식으로 평가되어야 한다. 단일 고장, 채널 불일치, 센서 차단, 통신 상실, 액추에이터 고장, 비정상 상태 전이도 포함해야 하며, 안전성 평가는 구현 담당자와 독립된 권한을 가진 인원이 검토해야 한다.

신뢰성 시험(Reliability Testing)은 로봇이 장기간 반복 운전에서도 허용 가능한 성능을 유지하는지를 평가한다. 내구 주행, 반복 도킹, 충전 사이클, 커넥터 체결 반복, 액추에이터 반복 동작, 진동, 열 노출, 전원 반복 인가, 장시간 소프트웨어 운전을 포함해야 한다. 단순한 고장뿐 아니라 성능 저하, 온도 상승, 통신 오류, 교정 변화, 배터리 열화, 유지보수 요구도 기록해야 한다. 가속 시험(Accelerated Test)을 사용할 수 있지만, 가속 조건과 실제 고장 메커니즘이 기술적으로 타당해야 한다.

성능 시험(Performance Testing)은 주행 정확도, 정지 정확도, 위치추정 안정성, 장애물 검출 거리, 제동 거리, 임무 완료 시간, 처리량, 에너지 소비, 충전 효율, 적재 능력, 네트워크 지연, 컴퓨팅 자원 사용률을 측정해야 한다. 지표(Metric)는 서로 다른 팀과 시험 장소에서도 동일한 의미를 가지도록 명확히 정의해야 한다. 평균값만으로는 충분하지 않으며, 백분위수(Percentile), 최악 조건, 변동성, 신뢰구간(Confidence Interval), 환경에 따른 변화도 함께 평가해야 한다.

인공지능 기반 인식 및 의사결정 기능(AI-Based Perception and Decision Function)은 학습 데이터와 운용 환경의 영향을 받기 때문에 별도의 검증이 필요하다. 시험 전략은 데이터셋 평가, 오프라인 모델 시험, 시뮬레이션, 통제된 차량 시험, 현장 모니터링을 구분해야 한다. 객체 종류, 거리, 조명, 날씨, 배경, 센서 상태, 환경 변화에 따라 성능을 평가해야 한다. 잘못된 신뢰도, 분포 변화(Distribution Shift), 센서 열화, 희귀한 조합도 검증 대상에 포함되어야 한다. 또한 모델 버전, 데이터셋 버전, 파라미터, 배포 구성을 모두 추적 가능하게 관리해야 한다.

회귀 시험(Regression Testing)은 변경 사항이 기존 기능에 영향을 주지 않는지를 확인한다. 소프트웨어 업데이트, 하드웨어 변경, 파라미터 수정, 지도 변경, 센서 교체, 안전 설정 변경, 통신 변경은 모두 위험 기반 회귀 시험을 수행해야 한다. 자동화 시험은 지속적 통합(Continuous Integration) 과정에서 자주 실행하고, 벤치, HIL, 차량, 현장 시험은 영향도에 따라 수행한다. 회귀 시험에는 과거에 발생했던 결함과 중요한 고객 시나리오를 포함해야 하며, 한 번 발생한 결함은 가능하면 영구적인 시험 항목으로 유지해야 한다.

시험 자동화(Test Automation)는 안정적이고 반복 가능한 절차에서 적용할 때 큰 효과를 가진다. 자동화 도구는 소프트웨어 빌드, 환경 설정, 시뮬레이션 실행, 인터페이스 자극, 로그 수집, 성능 계산, 결과 비교, 보고서 생성을 수행할 수 있다. 그러나 자동화는 시험 논리를 숨기거나 실패 원인을 이해하기 어렵게 만들어서는 안 된다. 시험 스크립트, 설정, 기준 데이터, 합격 기준은 제품 소프트웨어와 동일한 수준으로 검토 및 버전 관리되어야 하며, 자동화 결과도 정기적으로 유효성을 확인해야 한다.

형상 관리(Configuration Management)는 시험 결과가 정확히 어떤 시스템에서 얻어진 것인지를 보장하기 위해 필수적이다. 기록에는 로봇 일련번호, 하드웨어 버전, 소프트웨어 패키지, 펌웨어(Firmware), AI 모델, 교정 파일, 지도, 파라미터, 시험 스크립트, 시뮬레이션 모델, 지그(Fixture), 환경 설정이 포함되어야 한다. 시험 중 통제되지 않은 변경은 결과 비교와 재현을 어렵게 만든다. 따라서 승인된 기준 버전(Baseline), 실험 버전, 출시 후보 버전의 관리 절차를 명확히 정의해야 한다.

시험 데이터(Test Data)는 동기화된 타임스탬프와 함께 충분한 맥락(Context)을 포함하여 수집되어야 한다. 센서 데이터, 위치추정 결과, 제어 명령, 액추에이터 피드백, 안전 상태, 전력 정보, 네트워크 통계, 시스템 자원 사용률, 고장 코드, 작업자 조작, 환경 조건, 기준 측정값이 포함될 수 있다. 데이터 수집은 목적 없는 대량 저장이 아니라 특정 질문에 답할 수 있도록 설계되어야 하며, 저장 방식, 이름 규칙, 메타데이터, 보존 기간, 접근 권한, 개인정보 보호 기준을 사전에 정의해야 한다.

기준값(Ground Truth)과 기준 측정(Reference Measurement)은 정확도 평가를 위해 필수적이다. 주행 시험에서는 측량 기준점, 모션 캡처(Motion Capture), 토털 스테이션(Total Station), 교정된 기준 센서, 정밀 측정 장비를 사용할 수 있다. 타이밍 시험에는 하드웨어 트리거와 동기화된 시계가 필요하며, 하중 시험에는 교정된 추나 로드셀(Load Cell)이 필요하다. 기준 장비의 측정 불확도는 합격 허용오차보다 충분히 작아야 하며, 시험 보고서에는 불확도와 교정 상태를 명시해야 한다.

결함 관리(Defect Management)는 시험 실패를 조사, 수정, 재검증, 종료까지 연결하는 체계를 가져야 한다. 보고서에는 실제 동작, 기대 동작, 시험 환경, 구성 정보, 재현 절차, 로그, 심각도, 운용 영향, 임시 대응 방법을 포함해야 한다. 또한 보고된 증상과 근본 원인(Root Cause)을 구분해야 한다. 결함을 종료하기 위해서는 수정 결과와 관련 기능이 영향을 받지 않았음을 입증해야 하며, 반복되는 문제는 단순 수정이 아니라 시스템 구조, 개발 프로세스, 공급망, 요구사항까지 재검토해야 한다.

시험 결과(Test Result)는 명확한 엔지니어링 및 경영 의사결정을 지원해야 한다. 대시보드(Dashboard)는 시험 범위, 합격률, 미해결 결함, 안전 상태, 신뢰성 진행률, 시나리오 수행률, 요구사항 검증 상태를 요약할 수 있지만, 이러한 지표는 항상 상세한 근거와 연결되어야 한다. 출시 여부는 단순히 통과한 시험 개수가 아니라 남아 있는 위험, 운용 제한, 임시 대응, 모니터링 가능성, 복구 절차까지 고려하여 결정해야 한다. 기술적으로 동작하는 제품이라도 중요한 조건이 충분히 시험되지 않았다면 출시해서는 안 된다.

시험 조직(Test Organization)은 책임과 독립성을 명확히 정의해야 한다. 개발자는 단위 시험과 부품 시험을 담당하고, 통합 시험 팀은 인터페이스와 전체 기능을 평가한다. 안전, 사이버보안, EMC, 환경, 신뢰성, AI, 현장 시험은 전문 인력이 담당할 수 있으며, 품질 및 승인 조직은 공식 결과와 미해결 문제를 검토해야 한다. 구현한 사람이 자신의 기능을 스스로 승인하는 구조는 바람직하지 않으며, 독립적인 검토는 객관성과 잠재적 문제를 발견하는 데 도움이 된다.

시험 프레임워크는 시험 결과를 요구사항, 시스템 아키텍처, 구현, 생산, 운용으로 다시 연결하는 피드백 루프(Feedback Loop)를 제공해야 한다. 실패한 시험은 구현 오류뿐 아니라 비현실적인 요구사항, 불완전한 인터페이스, 취약한 진단 설계, 부적절한 부품 선정, 누락된 운용 규칙을 드러낼 수도 있다. 따라서 시험 결과는 시스템 관점에서 분석되어야 하며, 이를 통해 설계 기준, 체크리스트, 시뮬레이션 모델, 시나리오 라이브러리, 생산 시험, 서비스 절차, 차세대 제품 계획을 지속적으로 개선해야 한다.

현장 검증(Field Validation)은 로봇이 실제 운용 환경에서 정상적으로 동작하는지를 최종적으로 확인하는 과정이지만, 주요 기능을 처음 평가하는 단계가 되어서는 안 된다. 현장 시험은 단계적 배포, 숙련된 감독자, 롤백 계획(Rollback Plan), 복구 장비, 명확한 운용 제한을 기반으로 수행해야 한다. 또한 현장 성능을 시뮬레이션과 통제된 시험장의 결과와 비교하여 차이를 분석하고 모델을 개선해야 한다. 고객 업무 절차, 사람의 행동, 시설 구조, 무선 환경, 바닥 상태, 유지보수 방식은 실험실에서는 발견하기 어려운 새로운 상호작용을 드러낼 수 있다.

시험은 배포 이후에도 운용 모니터링(Operation Monitoring)과 플릿 학습(Fleet Learning)을 통해 계속된다. 로봇은 상태 정보, 안전 이벤트, 임무 결과, 위치추정 품질, 배터리 상태, 통신 오류, 작업자 개입 횟수, 새로운 고장 패턴을 지속적으로 보고해야 한다. 이러한 데이터는 환경 변화, 부품 노화, 소프트웨어 회귀, 새로운 엣지 케이스를 발견하는 데 활용된다. 운용 모니터링은 출시 전 검증을 대체하지 않지만, 유지보수, 소프트웨어 업데이트, 지속적 개선, 위험 관리의 핵심 근거가 된다. 중요한 현장 발견 사항은 반드시 회귀 시험과 승인 시험에 다시 반영되어야 한다.

성숙한 시험 전략 및 프레임워크(Testing Strategy and Framework)는 요구사항 추적성, 위험 기반 계획, 계층적 검증, 시뮬레이션, HIL, 시스템 통합, 시나리오 시험, 안전 평가, 신뢰성 시험, 시험 자동화, 데이터 관리, 결함 관리, 현장 피드백을 하나의 체계로 통합한다. 이러한 체계는 초기 설계 가정부터 실제 운용 성능까지 이어지는 연속적인 검증 근거를 제공한다. 시험을 단순한 개발 마지막 단계가 아니라 제품 수명주기 전체에 걸친 핵심 엔지니어링 활동으로 운영할 때, AMR 개발팀은 결함을 조기에 발견하고 기술적 위험을 효과적으로 관리하며, 신뢰할 수 있는 출시 결정을 내리고, 실제 환경에서 안전하고 신뢰성 있으며 측정 가능하고 지속적으로 운용 가능한 로봇을 개발할 수 있다.

12.02 Unit and Integration Testing

단위 시험(Unit Testing)과 통합 시험(Integration Testing)은 자율이동로봇(Autonomous Mobile Robot, AMR)의 검증 프로세스를 구성하는 가장 기본적인 기술적 기반이다. 단위 시험은 개별 함수(Function), 클래스(Class), 노드(Node), 알고리즘(Algorithm), 드라이버(Driver), 하드웨어 모듈(Hardware Module)을 독립적으로 검증하는 과정이며, 통합 시험은 이러한 요소들이 연결되었을 때 데이터(Data), 명령(Command), 타이밍(Timing), 전력(Power), 상태 정보(State Information)를 올바르게 교환하는지를 검증하는 과정이다. 두 시험은 전체 시스템 시험(System Test)이나 현장 시험(Field Test) 이전에 결함을 발견하고, 디버깅 복잡도를 줄이며, 로봇 내부 구성요소와 인터페이스가 정의된 계약(Contract)에 따라 정상적으로 동작함을 반복 가능한 방식으로 입증하는 역할을 수행한다.

단위(Unit)의 범위는 단순히 소스 파일의 크기가 아니라 하나의 책임(Responsibility)과 관찰 가능한 동작(Observable Behavior)을 기준으로 결정해야 한다. 하나의 단위는 수학 함수(Mathematical Function), 위치추정 필터(Localization Filter), 경로 계획 알고리즘(Route Planning Method), 상태 기계(State Machine)의 전이(Transition), 통신 파서(Communication Parser), 모터 제어 계산(Motor Control Calculation), 진단 루틴(Diagnostic Routine), 센서 드라이버(Sensor Driver), 전원 제어 모듈(Power Control Module) 등이 될 수 있다. 각 단위는 명확한 입력(Input), 출력(Output), 상태(State), 오류(Error), 의존성(Dependency)을 가져야 한다. 하나의 단위가 너무 많은 책임을 가지면 하나의 시험 실패가 여러 원인에서 발생할 수 있어 분석이 어려워진다.

각 단위 시험은 하나의 명확한 동작만을 검증하도록 설계해야 한다. 시험은 초기 상태(Initial State), 입력 데이터, 예상 출력(Expected Output), 허용 오차(Tolerance), 시간 조건(Timing Assumption), 부수 효과(Side Effect)를 명확히 정의해야 한다. 정상 입력뿐 아니라 경계값(Boundary Value), 잘못된 입력(Invalid Value), 누락된 정보, 반복 호출, 상태 전이도 함께 검증해야 한다. 성공적인 시험은 단순히 프로그램이 종료되지 않았음을 의미해서는 안 된다. 정확한 결과를 반환하고, 의도한 상태만 변경하며, 적절한 진단 정보를 생성하고, 시스템을 예측 가능한 상태로 유지하는지를 확인해야 한다.

수치 알고리즘(Numerical Algorithm)에 대한 단위 시험은 신중하게 선택된 기준값(Reference Value)과 허용 오차를 사용해야 한다. 위치추정(Localization), 좌표 변환(Coordinate Transformation), 궤적 생성(Trajectory Generation), 속도 제어(Speed Control), 에너지 추정(Energy Estimation), 센서 필터링(Sensor Filtering)은 부동소수점(Floating Point) 계산을 사용하므로 프로세서나 라이브러리에 따라 결과가 약간 달라질 수 있다. 따라서 정확한 값 비교가 아니라 기술적으로 타당한 허용 오차를 사용해야 한다. 또한 0 값, 매우 작은 값과 큰 값, 음수, 각도 래핑(Angular Wraparound), 좌표계 경계, 오버플로(Overflow), 0으로 나누기(Division by Zero), 무한대(Infinity), 숫자가 아님(Not-a-Number, NaN)과 같은 예외 상황도 반드시 검증해야 한다.

상태 기계(State Machine)는 AMR 소프트웨어에서 매우 중요한 시험 대상이다. 임무 수행(Mission Execution), 충전(Charging), 도킹(Docking), 복구(Recovery), 안전 제어(Safety Coordination), 전원 관리(Power Control)는 모두 상태 기반(State-Based)으로 동작하기 때문이다. 시험은 정상 상태 전이, 허용되지 않는 전이, 진입 및 종료 동작, 타임아웃 처리, 반복 이벤트, 이벤트 순서, 중단 이후 복구를 모두 검증해야 한다. 또한 예상하지 못한 메시지나 중복 메시지를 수신하더라도 정의되지 않은 상태에 들어가지 않아야 하며, 모든 안전 및 임무 관련 상태 전이는 명확한 조건과 관찰 가능한 결과를 가져야 한다.

센서 처리(Sensor Processing) 단위는 정상적인 데이터뿐 아니라 손상되거나 성능이 저하된 입력도 시험해야 한다. 예를 들어 LiDAR 처리 함수는 빈 스캔, 잘못된 거리값, 부분 스캔, 예상하지 못한 타임스탬프, 설정 영역 밖의 점(Point)을 입력받을 수 있다. 카메라(Camera)와 깊이 센서(Depth Sensor)는 프레임 손실, 해상도 변경, 픽셀 포화(Saturated Pixel), 메타데이터 손상, 지연된 프레임을 받을 수도 있다. 시험은 실제 센서 없이도 필터링(Filter), 좌표 변환, 객체 추출(Object Extraction), 신뢰도 처리(Confidence Handling), 진단 기능이 정상적으로 수행되는지를 확인해야 한다.

통신 파서(Communication Parser)와 프로토콜 처리기(Protocol Handler)는 정상 패킷, 길이 오류, 잘못된 식별자, 체크섬 오류, 순서가 뒤바뀐 메시지, 중복 메시지, 누락된 필드, 타임아웃, 재연결을 모두 시험해야 한다. 파서는 잘못된 데이터를 수신하더라도 내부 상태를 손상시키거나 위험한 명령을 생성해서는 안 된다. 직렬화(Serialization)와 역직렬화(Deserialization)는 데이터의 단위(Unit), 부호(Sign), 정밀도(Precision), 의미가 손실되지 않는지를 확인해야 한다. 서로 다른 소프트웨어 버전이나 프로그래밍 언어에서 생성된 메시지 간의 호환성도 검증 대상이 될 수 있다.

장치 드라이버(Device Driver)는 하드웨어 접근(Hardware Access)과 제어 로직(Decision Logic)을 분리하여 단위 시험을 수행해야 한다. 하드웨어는 추상화 계층(Abstraction Layer), 모의 객체(Mock Object), 에뮬레이터(Emulator), 기록된 응답(Recorded Response)으로 대체할 수 있다. 이를 통해 정상 통신, 응답 지연, 장치 미존재, 잘못된 레지스터 값, 통신 오류, 예기치 않은 리셋을 반복적으로 시험할 수 있다. 또한 초기화, 설정, 데이터 변환, 재시도 횟수, 오류 보고, 종료, 복구까지 실제 하드웨어 없이 검증할 수 있어야 한다.

모의 객체(Mock Object)와 테스트 더블(Test Double)은 외부 의존성을 통제 가능한 형태로 대체한다. 이들은 센서, 데이터베이스(Database), 네트워크(Network), 시계(Clock), 파일 시스템(File System), 모터 제어기(Motor Controller), 안전 인터페이스(Safety Interface), 플릿 관리 시스템(Fleet Management System) 등을 대신할 수 있다. 좋은 모의 객체는 실제 인터페이스 계약을 유지하면서 시험이 원하는 응답을 자유롭게 생성하고 상호작용을 확인할 수 있어야 한다. 그러나 과도한 모의 객체 사용은 실제 시스템 대신 인공적인 환경만 검증하는 결과를 만들 수 있으므로, 중요한 가정은 이후 실제 구성요소를 사용하는 통합 시험으로 반드시 확인해야 한다.

시간 의존(Time-Dependent) 기능은 가능한 한 제어 가능한 시계(Controllable Clock)를 사용하여 시험해야 한다. 실제 시간을 기다리는 방식은 시험 속도를 늦추고 비결정적(Nondeterministic) 오류를 유발할 수 있다. 가상 시계는 타임아웃(Timeout), 재시도(Retry), 스케줄링(Scheduling), 워치독(Watchdog), 만료 시간(Expiration)을 즉시 반복적으로 검증할 수 있다. 또한 지연 이벤트, 시계 점프, 타임스탬프 오버플로, 오래된 데이터, 누락된 업데이트, 동일한 시각에 발생하는 이벤트를 확인해야 한다. 실제 실시간 성능은 통합 시험에서 별도로 검증하지만 논리적 시간 처리 자체는 단위 시험에서 결정론적으로 검증해야 한다.

동시성 시험(Concurrency Testing)은 여러 스레드(Thread), 비동기 콜백(Asynchronous Callback), 공유 메모리(Shared Memory), 큐(Queue), 실행기(Executor)를 사용하는 경우 반드시 수행해야 한다. 시험은 경쟁 상태(Race Condition), 교착 상태(Deadlock), 우선순위 충돌, 알림 손실, 중복 처리, 공유 상태 접근 오류를 검증해야 한다. 이러한 문제는 특정 타이밍에서만 나타나므로 반복 실행, 스케줄 순서 변경, 스레드 및 메모리 오류 검출 도구를 활용해야 한다. 공유 자원의 소유권은 명확해야 하며, 시간에 민감한 실행 경로에서는 블로킹(Blocking) 호출을 피해야 한다.

오류 처리(Error Handling) 시험은 예상 가능한 모든 실패가 탐지되고 보고되며 안전하게 처리되는지를 확인해야 한다. 단위는 복구 가능한 오류와 치명적인 오류를 구분해야 하며, 오류를 정상 처리처럼 숨겨서는 안 된다. 시험은 오류 코드(Error Code), 예외 처리(Exception Handling), 진단 메시지, 대체 값(Fallback Value), 재시도 동작, 자원 정리(Resource Cleanup)를 확인해야 한다. 함수가 중간에 실패하더라도 잠금(Lock), 파일, 통신 채널, 액추에이터, 내부 상태가 불일치한 상태로 남아 이후 문제를 일으켜서는 안 된다.

자원 관리(Resource Management) 시험은 반복 실행 시 메모리 누수(Memory Leak), 파일 디스크립터(File Descriptor) 누수, 스레드 증가, 큐 증가, 해제되지 않은 통신 자원이 발생하지 않는지를 확인한다. 초기화와 종료를 반복하거나 객체를 반복 생성·삭제하거나 장시간 데이터를 처리하는 시험을 수행할 수 있다. 메모리 분석기(Memory Analyzer)와 새니타이저(Sanitizer)는 일반 기능 시험에서 발견하기 어려운 문제를 찾아낼 수 있다. 장기간 연속 운전하는 로봇에서는 이러한 자원 관리가 매우 중요하다.

단위 시험은 서로 독립적이어야 한다. 하나의 시험은 실행 순서, 이전 시험에서 남겨진 데이터, 공유 설정, 외부 네트워크 서비스에 의존해서는 안 된다. 각 시험은 필요한 상태를 스스로 생성하고 종료 후 정리해야 한다. 이러한 독립성은 병렬 실행을 가능하게 하고 결과 재현성을 높인다. 공통 장비를 공유해야 하는 경우에도 한 시험이 다른 시험의 조건을 변경하지 않도록 관리해야 한다. 숨겨진 의존성은 간헐적 실패를 유발하고 시험 결과에 대한 신뢰를 떨어뜨린다.

단위 시험 모음(Unit Test Suite)은 코드가 변경될 때마다 빠르게 실행될 수 있어야 한다. 개발자는 코드 병합(Merge) 이전에 즉시 피드백을 받아야 한다. 빠른 시험은 자주 실행되지만 느리거나 불안정한 시험은 무시되기 쉽다. 따라서 빠른 로컬 시험과 보다 포괄적인 자동화 시험으로 구분할 수 있지만, 핵심 단위 기능은 항상 가장 짧은 피드백 루프 안에 포함되어야 한다. 지속적 통합(Continuous Integration, CI)은 코드 컴파일, 시험 실행, 결과 수집을 자동으로 수행하고 품질 기준(Quality Gate)을 만족하지 못하는 변경은 거부해야 한다.

코드 커버리지(Code Coverage)는 실행되지 않은 코드, 분기, 조건, 함수를 찾는 데 유용하지만, 커버리지 비율만으로 시험 품질을 보장할 수는 없다. 코드를 실행했다고 해서 결과를 올바르게 검증한 것은 아니며, 높은 커버리지에서도 중요한 조합을 놓칠 수 있다. 따라서 커버리지는 검토를 위한 지표로 활용해야 하며, 안전 관련 분기, 오류 처리 경로, 경계 조건, 상태 전이는 별도의 의도적인 시험이 필요하다. 단순한 실행 횟수보다 의미 있는 검증과 위험 기반 시나리오가 훨씬 중요하다.

변이 시험(Mutation Testing)은 단위 시험의 품질을 보다 깊이 평가하는 방법이다. 조건 반전, 상수 변경, 함수 호출 제거, 연산자 변경과 같은 작은 코드 변경을 의도적으로 수행한 후 시험이 실패하는지를 확인한다. 좋은 시험 모음은 이러한 변경을 반드시 탐지해야 한다. 많은 변이가 살아남는다면 시험은 코드를 실행하기만 할 뿐 올바른 동작을 검증하지 못하고 있다는 의미일 수 있다. 계산 비용은 높지만 중요한 알고리즘, 안전 로직, 공용 라이브러리에서는 매우 유용하다.

속성 기반 시험(Property-Based Testing)은 사람이 선택한 입력 사례뿐 아니라 자동 생성된 다양한 입력에 대해 일반적인 규칙이 항상 성립하는지를 확인한다. 예를 들어 좌표 변환 후 역변환을 수행하면 원래 위치가 복원되어야 하며, 속도 제한기는 설정값을 초과하는 결과를 생성해서는 안 된다. 경로 비용(Route Cost)은 항상 0 이상이어야 하고, 직렬화 후 역직렬화는 정보를 그대로 유지해야 한다. 이러한 시험은 사람이 예상하지 못한 조합과 경계 조건을 발견하는 데 효과적이다.

통합 시험(Integration Testing)은 둘 이상의 검증된 구성요소를 실제 또는 실제와 유사한 인터페이스를 통해 연결하면서 시작된다. 목적은 데이터 흐름(Data Flow), 명령의 소유권(Command Ownership), 타이밍, 자원 공유(Resource Sharing), 오류 전파(Error Propagation), 상태 협조(State Coordination)를 검증하는 것이다. 개별적으로는 정상인 구성요소도 단위(Unit), 좌표계(Coordinate Frame), 타임스탬프, 식별자, 상태 이름을 다르게 해석하여 함께 동작할 때 문제가 발생할 수 있다. 따라서 통합 시험은 내부 계산보다 인터페이스 계약을 중심으로 수행된다.

인터페이스 계약(Interface Contract)은 메시지 구조(Message Structure), 데이터 형식(Data Type), 단위(Unit), 허용 범위(Valid Range), 좌표계, 타임스탬프 기준, 갱신 주기(Update Rate), 품질 정보(Quality Indicator), 타임아웃, 소유권, 오류 처리 방식을 정의해야 한다. 서비스(Service)나 명령(Command)은 사전 조건, 응답 코드, 재시도 규칙, 멱등성(Idempotency), 취소(Cancellation) 조건도 포함해야 한다. 단순히 데이터가 전송되었다고 해서 인터페이스가 검증된 것은 아니며, 수신 측이 이를 정확히 해석하고 의도한 시스템 수준의 결과를 생성해야 한다.

점진적 통합(Incremental Integration)은 모든 소프트웨어를 한 번에 연결하는 방식보다 일반적으로 효과적이다. 센서 드라이버와 전처리부터 시작하여 위치추정, 지도 생성, 경로 계획, 제어, 안전 제어, 미션 관리, 플릿 통신, 사용자 인터페이스를 단계적으로 추가한다. 각 단계는 시작 조건, 기대 데이터 흐름, 상태 지표, 롤백 기능을 가져야 한다. 문제가 발생하면 가장 최근에 추가된 인터페이스를 집중적으로 분석할 수 있어 원인 파악이 쉬워진다.

상향식 통합(Bottom-Up Integration)은 하위 구성요소부터 시작하여 점차 상위 시스템으로 확장하는 방식이다. 센서 드라이버를 필터링과 인식 기능에 연결하고, 이후 위치추정과 경로 계획으로 확장할 수 있다. 모터 제어기는 속도 제어와 주행 거리 계산(Odometry)에 먼저 연결한 뒤 내비게이션 명령을 받도록 구성할 수 있다. 이 방법은 하위 계층의 실제 동작을 상위 계층에 제공하지만, 초기에는 임시 명령 생성기나 드라이버가 필요할 수 있다.

하향식 통합(Top-Down Integration)은 미션 관리나 응용 로직부터 시작하고 하위 계층은 스텁(Stub)과 시뮬레이터로 대체하는 방식이다. 이를 통해 전체 내비게이션이나 하드웨어가 준비되기 전에도 미션 순서, 작업 할당, 복구 로직, 사용자 인터페이스를 검증할 수 있다. 개발이 진행되면 스텁은 실제 구현으로 교체된다. 이 방식은 상위 구조의 문제를 조기에 발견할 수 있지만, 스텁과 실제 시스템 간의 타이밍 및 오류 차이를 관리해야 한다.

혼합 통합(Hybrid Integration)은 상향식과 하향식 방식을 함께 사용하는 전략이다. 안정적인 하드웨어 인터페이스는 하위에서 구축하고, 미션 수준 기능은 시뮬레이션을 이용해 상위에서 검증한다. 이후 두 개발 흐름은 명확하게 관리되는 인터페이스 기준(Interface Baseline)을 통해 연결된다. 기계, 전기, 임베디드, 내비게이션, 플릿, 응용 소프트웨어 팀의 개발 속도가 서로 다른 AMR 프로젝트에 특히 적합한 방식이다.

ROS 2 통합 시험은 노드 검색(Node Discovery), 토픽 이름(Topic Name), 메시지 형식(Message Type), 서비스 품질(Quality of Service, QoS), 네임스페이스(Namespace), 파라미터(Parameter), 서비스(Service), 액션(Action), 라이프사이클 상태(Lifecycle State), 실행기(Executor), 콜백 동작을 검증해야 한다. 동일한 메시지 형식을 사용하더라도 신뢰성(Reliability), 내구성(Durability), 큐 크기(Queue Depth) 설정이 다르면 통신이 실패할 수 있다. 따라서 시작 순서, 노드 재시작, 탐색 지연, 메시지 손실, 중복 발행자, 파라미터 변경, 상태 전이를 모두 확인해야 한다.

QoS 설정은 네트워크 환경과 데이터 속도에 따라 동작이 달라지므로 실제 환경에서 검증해야 한다. 대용량 센서 데이터는 Best-Effort 방식을 사용할 수 있지만, 명령이나 안전 관련 상태는 Reliable 방식이 필요할 수 있다. 큐 오버플로, 늦게 연결되는 구독자, 발행자 중단, 네트워크 혼잡, 노드 재연결을 시험해야 한다. 하나의 개발 PC에서 정상적으로 동작하던 설정도 여러 컴퓨터와 관리형 스위치 환경에서는 다르게 동작할 수 있으므로 실제 토폴로지를 재현해야 한다.

좌표계(Coordinate Frame) 통합은 AMR에서 매우 흔한 오류 원인이다. 좌표계 이름, 부모-자식 관계, 축 방향, 단위, 정적 변환, 동적 변환, 타임스탬프 일관성을 확인해야 한다. 센서 데이터는 처리 시점이 아니라 측정 시점의 변환 정보를 사용해야 한다. 변환 정보가 누락되거나 중복되거나 불연속적이면 위치추정과 경로 계획이 불안정해질 수 있다. 기준 위치와 알려진 기하학적 구조를 이용하면 전체 변환 체인이 올바른지를 확인할 수 있다.

시간 동기화(Time Synchronization)는 센서, 제어기, 컴퓨터, 로깅 시스템 전체에서 검증해야 한다. 카메라, LiDAR, IMU, 휠 오도메트리, GNSS, 명령, 액추에이터 피드백은 서로 다른 시계와 통신 경로를 사용한다. 통합 시험에서는 시계 오프셋, 드리프트, 지터(Jitter), 타임스탬프 지연, 동기화 상실 이후의 동작을 측정해야 한다. 작은 시간 오차도 센서 융합이나 고속 주행에서는 큰 위치 오차로 나타날 수 있다.

내비게이션 통합 시험(Navigation Integration Test)은 위치추정, 지도 생성, 전역 경로 계획(Global Planning), 지역 경로 계획(Local Planning), 장애물 처리, 속도 제어, 차량 피드백을 하나의 체계로 연결하여 검증한다. 모든 모듈이 동일한 지도, 비용 표현(Cost Representation), 로봇 형상(Footprint), 제한값, 갱신 주기를 사용하는지 확인해야 한다. 경로 생성, 동적 재계획, 장애물 발생, 위치추정 성능 저하, 막힌 경로, 목표 취소, 복구 동작을 포함한 다양한 시나리오를 시험해야 한다.

모션 제어 통합(Motion Control Integration)은 속도 또는 궤적 명령이 실제 모터 구동과 차량 이동으로 올바르게 연결되는지를 검증한다. 스케일, 부호, 바퀴 기하학, 조향 방향, 가속 제한, 브레이크 해제, 활성화 순서, 워치독 동작이 일치해야 한다. 정지 명령, 데드밴드(Deadband) 근처의 작은 명령, 최대 명령, 방향 전환, 통신 중단, 엔코더 오류, 액추에이터 포화(Saturation)를 모두 시험해야 한다. 명령과 피드백은 동기화된 시간으로 기록하여 지연, 진동, 추종 오차를 분석해야 한다.

안전 통합 시험(Safety Integration Test)은 안전 기능과 일반 제어 기능 사이의 경계를 검증한다. 보호 정지, 비상 정지, 안전 토크 차단(STO), 브레이크 동작, 속도 제한, 보호 영역 변경, 리셋, 재시작 방지는 설계된 대로 모션 시스템에 영향을 주어야 한다. 일반 소프트웨어는 상태를 보고하고 복구할 수 있을 만큼의 정보를 받아야 하지만, 안전 결정을 무시해서는 안 된다. 상태 메시지가 지연되거나 모순되거나 없어지는 경우도 검증 대상이다.

전원 상태 통합(Power-State Integration)은 BMS, 접촉기, 컨버터, 안전 제어기, 컴퓨터, 센서, 모터 드라이브, 페이로드, 충전 시스템의 협조 동작을 검증한다. 기동 순서, 종료, 절전, 깨우기, 비상 절연, 저배터리 대응, 충전 연결, 부분 전원 손실 후 복구를 확인해야 한다. 개별적으로는 정상인 모듈도 과도한 기동 전류나 지연된 준비 상태, 반복 재부팅으로 인해 통합 문제를 일으킬 수 있으므로 전원 상태와 소프트웨어 상태를 함께 관찰해야 한다.

플릿 및 미션 통합(Fleet and Mission Integration)은 로봇 수준 자율성과 외부 미션 관리 시스템 간의 연동을 검증한다. 미션 할당, 수락, 거부, 진행 보고, 취소, 우선순위 변경, 일시정지, 재개, 통신 상실, 중복 명령, 재연결 후 복구를 시험해야 한다. 메시지가 재전송되었다는 이유로 동일한 미션이 두 번 수행되어서는 안 된다. 미션 식별자, 로봇 상태, 지도 버전, 자원 소유권, 결과 보고는 플릿 시스템과 로봇 사이에서 항상 일치해야 한다.

시험 하네스(Test Harness)는 통합 시험을 위한 입력, 관측 지점, 시뮬레이터, 기록기, 비교 도구를 제공한다. 시험 하네스는 필요한 노드를 실행하고, 센서 데이터를 생성하며, 서비스를 모의하고, 메시지를 기록하고, 지연을 주입하며, 예상 결과를 자동으로 평가할 수 있다. 또한 개발 환경과 지속적 통합 환경에서 동일한 시험을 반복할 수 있도록 의존성과 설정을 명확히 관리해야 하며, 실패 시 로그와 설정을 보존하여 정확한 재현이 가능하도록 해야 한다.

기록 데이터 재생(Recorded-Data Playback)은 인식, 위치추정, 지도 생성, 경로 계획의 반복 가능한 통합 시험에 매우 유용하다. 동일한 센서 데이터를 서로 다른 소프트웨어 버전으로 처리하여 결과를 비교할 수 있다. 재생 과정은 타임스탬프, 순서, 좌표계, 메타데이터를 그대로 유지해야 한다. 그러나 기록 데이터는 로봇의 행동이 이후 센서 데이터를 변화시키는 폐루프(Closed Loop) 상황을 재현할 수 없으므로 시뮬레이션 및 실제 시험을 보완하는 용도로 사용해야 한다.

고장 주입(Fault Injection)은 인터페이스나 의존성이 실패했을 때 연결된 구성요소가 어떻게 반응하는지를 검증한다. 메시지 손실, 응답 지연, 잘못된 타임스탬프, 손상된 데이터, 고정된 센서 값, 대역폭 제한, 프로세스 종료, 노드 재시작, 저장 공간 부족, 높은 CPU 부하, 설정 파일 손실 등을 포함할 수 있다. 수신 시스템은 이러한 상태를 탐지하고, 영향을 제한하며, 적절한 성능 저하 상태 또는 안전 상태로 진입하고, 정의된 절차에 따라 복구해야 한다. 재연결 과정도 불안정한 반복 루프를 만들지 않는지 반드시 시험해야 한다.

부정 통합 시험(Negative Integration Testing)은 인터페이스의 가정을 의도적으로 위반한다. 구성요소는 알 수 없는 버전, 불가능한 값, 잘못된 좌표계, 과도한 데이터 속도, 허가되지 않은 명령을 받을 수 있다. 서비스는 오류를 반환하거나 응답하지 않거나 부분적인 결과만 제공할 수도 있다. 이러한 경우 잘못된 정보는 거부되거나 안전하게 격리되어야 하며, 제어되지 않은 이동이나 숨겨진 데이터 손상을 일으켜서는 안 된다. 특히 외부 장비나 클라우드 서비스와 연결되는 경우 이러한 방어적 설계가 중요하다.

성능 통합 시험(Performance Integration Testing)은 여러 구성요소가 동시에 동작할 때의 지연(Latency), 처리량(Throughput), CPU 사용률, GPU 사용률, 메모리, 네트워크 대역폭, 큐 깊이, 스케줄링을 평가한다. 각각의 노드는 정상 성능을 만족하더라도 카메라, LiDAR, 위치추정, 경로 계획, 시각화, 데이터 기록, AI 추론이 동시에 수행되면 시스템 자원이 부족해질 수 있다. 실제 최대 데이터 속도와 미션 부하를 재현하여 병목(Bottleneck), 우선순위 역전(Priority Inversion), 자원 부족(Resource Starvation), 성능 저하를 확인해야 한다.

결정성(Determinism)과 반복성(Repeatability)은 동일한 입력에서 동일한 결과가 기대되는 경우 반드시 평가해야 한다. 멀티스레드, 비동기 통신, GPU 처리, 난수 기반 알고리즘, 타이밍 차이는 실행마다 결과를 달라지게 만들 수 있다. 일부 차이는 허용될 수 있지만 허용 범위를 명확히 정의해야 한다. 난수 시드(Random Seed), 스케줄링 설정, 구성 정보도 함께 기록해야 하며, 예기치 않은 비결정성은 디버깅을 어렵게 하고 드문 오류를 숨길 수 있다.

통합 시험 실패(Integration Test Failure)는 모든 구성요소에서 동기화된 증거를 확보해야 한다. 로그에는 동일한 타임스탬프, 노드 식별자, 메시지 ID, 상태 전이, 명령, 응답, 오류 코드가 포함되어야 한다. 분산 추적(Distributed Tracing)은 하나의 미션이나 요청이 여러 서비스와 노드를 거치는 과정을 추적할 수 있다. 이러한 상관관계가 없으면 각 구성요소는 정상처럼 보이지만 전체 시스템은 잘못 동작할 수 있다. 시험 프레임워크는 실패 시 필요한 데이터를 자동으로 보존해야 한다.

플래키 시험(Flaky Test)은 제품이 변경되지 않았는데도 통과와 실패가 반복되는 시험을 의미한다. 이는 제어되지 않은 타이밍, 공유 자원, 난수 데이터, 외부 서비스, 불완전한 정리 작업, 불안정한 시험 환경 때문에 발생할 수 있다. 플래키 시험은 시험 시스템 자체의 결함으로 간주해야 하며, 단순히 다시 실행하여 통과했다고 해서 합격으로 처리해서는 안 된다. 이러한 시험은 신뢰도를 크게 떨어뜨리므로 원인을 분석하여 제거해야 한다.

회귀 시험 모음(Regression Suite)은 변경 영향도에 따라 단위 시험과 통합 시험을 적절히 조합해야 한다. 수학 함수 변경은 관련 단위 시험만으로 충분할 수 있지만, 메시지 정의, 타이밍, 전원 관리, 안전 인터페이스, 공용 라이브러리 변경은 광범위한 통합 시험이 필요하다. 과거에 발생한 결함은 가능한 한 영구적인 시험 항목으로 유지해야 하며, 개발자는 먼저 빠른 피드백을 받고 이후 보다 광범위한 통합 시험을 수행하는 구조가 바람직하다.

시험 결과(Test Result)는 소프트웨어 버전, 하드웨어 버전, 설정 파일, 지도(Map), 교정(Calibration), 데이터셋(Dataset), 시험 하네스 버전과 함께 관리되어야 한다. 어떤 구성에서 수행된 시험인지 재현할 수 없다면 시험 결과의 가치도 크게 감소한다. 지속적 통합 시스템은 보고서, 로그, 성능 지표, 실패 데이터를 고유한 빌드 번호(Build Identifier)와 함께 저장해야 한다. 또한 공식 통합 기준(Baseline)은 여러 저장소와 장치에서 호환 가능한 버전을 명확히 정의해야 한다.

단위 시험과 통합 시험의 검토는 단순히 시험 개수만 보는 것이 아니라 요구사항 커버리지(Requirement Coverage), 위험 커버리지(Risk Coverage), 경계 조건, 오류 경로, 인터페이스 계약, 실제 타이밍, 복구 동작, 시험 독립성, 검증 내용의 품질을 함께 평가해야 한다. 중요한 시험은 구현자가 아닌 다른 엔지니어도 쉽게 이해할 수 있어야 한다. 명확한 시험 이름, 문서화된 목적, 통제된 시험 환경, 이해하기 쉬운 실패 메시지는 시험 모음을 단순한 스크립트가 아니라 중요한 엔지니어링 자산으로 만들어 준다.

성숙한 단위 시험 및 통합 시험(Unit and Integration Testing) 프로세스는 개별 기능의 정확성에서부터 여러 서브시스템의 협조 동작까지 연속적인 검증 체계를 구축한다. 단위 시험은 알고리즘, 상태, 오류 처리, 개별 책임을 빠르게 검증하고, 통합 시험은 인터페이스, 타이밍, 데이터 흐름, 명령 소유권, 전원 상태, 진단, 복구 기능을 연결된 구성요소 전체에서 확인한다. 이 두 수준의 시험이 자동화되고, 추적 가능하며, 형상 관리되고, 지속적으로 개선될 때 결함은 훨씬 더 이른 단계에서 발견되며, AMR은 HIL 시험, 차량 시험, 안전 시험, 현장 시험에 훨씬 더 안정적이고 신뢰성 높은 기반을 가지고 진입할 수 있다.

12.03 Hardware in the Loop Testing

하드웨어 인 더 루프 시험(Hardware-in-the-Loop Testing, HIL)은 실제 로봇 제어기(Controller), 임베디드 컴퓨터(Embedded Computer), 통신 장치(Communication Device), 일부 전기 인터페이스(Electrical Interface)를 시뮬레이션된 로봇과 운용 환경에 연결하는 시험 기법이다. 이는 소프트웨어 통합 시험(Software Integration Testing)과 실제 차량 시험(Complete Vehicle Testing) 사이에 위치하는 검증 단계이다. 목적은 실제 시설에서 완전한 로봇을 움직이지 않고도 생산용 하드웨어와 생산용 소프트웨어를 실제와 유사한 센서 신호, 액추에이터 응답, 타이밍 특성, 통신 트래픽, 전원 상태, 고장 상황에 노출시키는 것이다.

HIL 환경은 일반적으로 시험 대상 시스템(System Under Test, SUT), 실시간 시뮬레이션 컴퓨터(Real-Time Simulation Computer), 인터페이스 및 신호 조정 장비(Interface and Signal Conditioning Equipment), 시험 자동화 소프트웨어(Test Automation Software), 계측 장비(Measurement Instrument), 안전 제어 장치(Safety Control)로 구성된다. 시험 대상 시스템은 모터 제어기(Motor Controller), 안전 제어기(Safety Controller), 배터리 관리 시스템(Battery Management System, BMS), 내비게이션 컴퓨터(Navigation Computer), 산업용 PC(Industrial PC), 또는 전체 분산 컴퓨팅 플랫폼(Distributed Computing Platform)이 될 수 있다. 시뮬레이터(Simulator)는 실제 하드웨어 대신 차량 동역학(Vehicle Dynamics), 센서(Sensor), 액추에이터(Actuator), 환경(Environment), 통신 대상, 물리적 프로세스를 재현한다.

HIL 시험의 가장 큰 장점은 실제 구현과 제어 가능한 시뮬레이션을 결합한다는 점이다. 소프트웨어 전용 시뮬레이션은 프로세서 스케줄링(Processor Scheduling), 운영체제 지연(Operating System Latency), 장치 드라이버(Device Driver), 통신 제어기 한계, 전기 인터페이스, 하드웨어 리셋과 같은 실제 하드웨어의 특성을 완전히 재현할 수 없다. 반면 실제 차량 시험은 이러한 특성을 포함하지만 비용이 높고 반복성이 낮으며 위험성이 존재한다. HIL은 실제 하드웨어의 동작을 현실적으로 평가하면서도 시험 시나리오와 고장을 완전히 통제할 수 있는 중간 단계의 검증 환경을 제공한다.

HIL 시험의 범위는 검증 목적에 따라 정의되어야 한다. 제어기 수준 HIL은 하나의 임베디드 제어기와 시뮬레이션된 센서 및 액추에이터를 연결한다. 서브시스템 HIL은 내비게이션 컴퓨터, 모터 제어기, 안전 제어기, 통신 네트워크를 포함할 수 있다. 전체 스택 HIL(Full-Stack HIL)은 실제 컴퓨팅 구조에서 대부분의 생산용 소프트웨어를 실행하면서 기계적 차량과 외부 환경만 시뮬레이션으로 대체한다. 범위가 커질수록 현실성은 높아지지만 구성의 복잡성과 디버깅 난이도도 증가한다.

HIL 구조는 가능한 한 실제 제품에서 사용하는 인터페이스를 그대로 유지해야 한다. 차량이 CAN, CAN FD, Ethernet, EtherCAT, RS-485, 디지털 입출력(Digital I/O), 아날로그 신호(Analog Signal), 엔코더 펄스(Encoder Pulse), PWM(Pulse Width Modulation)을 사용한다면 HIL도 동일한 인터페이스를 사용해야 한다. 개발 과정에서는 내부 변수에 직접 값을 주입하는 방법이 편리할 수 있지만, 이는 드라이버, 프로토콜 스택, 배선, 타이밍 효과를 우회하게 된다. 따라서 공식 검증은 실제 제품과 동일한 인터페이스를 통해 시스템을 자극해야 한다.

실시간 실행(Real-Time Execution)은 HIL의 가장 중요한 요구사항이다. 시뮬레이션된 플랜트(Plant)는 실제 제어기가 기대하는 시간 안에 응답해야 한다. 모터 제어기는 수백 마이크로초 단위의 응답을 요구할 수 있으며, 내비게이션과 미션 시스템은 그보다 느린 주기로 동작할 수 있다. 시뮬레이터는 다음 시스템 상태를 계산하고, 센서 출력을 생성하며, 제어 명령을 수신하고, 플랜트 모델을 결정론적인 주기로 갱신해야 한다. 데드라인(Deadline)을 놓치거나 과도한 지터(Jitter)가 발생하면 제품이 아니라 시험 환경의 특성을 측정하게 된다.

실시간 모델(Real-Time Model)은 시험 목적에 필요한 물리적 거동을 적절하게 표현해야 한다. 모션 제어 HIL은 바퀴 관성(Wheel Inertia), 타이어 반경, 조향 기구, 마찰(Friction), 구동계 지연(Drivetrain Delay), 모터 토크(Motor Torque), 제동력(Braking Force), 차량 질량, 적재 중량(Payload)을 모델링할 수 있다. 내비게이션 중심 HIL은 위치(Pose), 오도메트리(Odometry), 장애물 위치, 센서 시야(Field of View), 지도(Map) 제약조건도 포함할 수 있다. 모든 물리 현상을 완벽히 재현할 필요는 없지만, 생략된 요소가 검증 결과를 왜곡해서는 안 된다.

모델 충실도(Model Fidelity)는 명확하게 관리되어야 한다. 어떤 물리 효과를 모델링했고, 어떤 부분을 단순화하거나 제외했는지를 문서화해야 한다. 예를 들어 상태 전이나 통신 복구를 검증하기에는 충분한 모델이라도 실제 제동 거리까지 검증하기에는 부족할 수 있다. 상관성 검증(Correlation Test)은 실제 로봇이나 부품 시험 결과와 시뮬레이션 결과를 비교하여 수행해야 한다. 차이가 발생하면 이를 정량적으로 분석하고, 추적 가능한 데이터를 이용해 모델 파라미터를 보정한 뒤 HIL 결과를 공식 검증 자료로 사용해야 한다.

센서 시뮬레이션(Sensor Simulation)은 여러 수준에서 수행할 수 있다. 가장 낮은 수준에서는 전기 신호(Electrical Signal), 엔코더 펄스, 디지털 상태, 프로토콜 메시지를 생성하여 센서를 모사할 수 있다. 더 높은 수준에서는 위치, 거리, 속도, 객체 목록(Object List)과 같은 처리된 측정값을 제공할 수도 있다. 고급 HIL은 카메라 영상(Camera Image), LiDAR 포인트 클라우드(Point Cloud), GNSS 데이터, IMU 신호, 레이더 검출(Radar Detection)까지 생성할 수 있다. 선택한 수준에 따라 실제 검증되는 센서 처리 체인의 범위가 달라진다.

휠 엔코더(Wheel Encoder)와 오도메트리 시뮬레이션은 펄스 주파수(Pulse Frequency), 회전 방향(Direction), 양자화(Quantization), 휠 슬립(Wheel Slip), 펄스 손실(Missed Pulse), 노이즈, 기하학적 오차를 재현해야 한다. 이러한 요소는 속도 추정, 위치추정, 경로 추종(Path Tracking), 진단 기능에 직접 영향을 준다. 정지 상태, 매우 낮은 속도, 가속, 방향 전환, 좌우 바퀴 속도 차이, 엔코더 손실, 비현실적인 피드백을 모두 시험해야 하며, 제어기는 이러한 이상 상태를 탐지하고 안전하게 대응해야 한다.

IMU 시뮬레이션은 가속도(Acceleration), 각속도(Angular Velocity), 중력(Gravity), 바이어스(Bias), 드리프트(Drift), 노이즈, 포화(Saturation), 축 방향(Axis Orientation), 스케일 오차(Scale Error), 타임스탬프를 포함해야 한다. 센서 융합(Sensor Fusion)은 이상적인 데이터에서는 안정적으로 동작하더라도 바이어스나 지연이 존재하면 쉽게 불안정해질 수 있다. 따라서 초기 정렬, 정지 상태, 회전, 진동, 통신 중단, 센서 리셋 상황을 시험해야 하며, 차량 운동과 생성된 IMU 데이터는 항상 물리적으로 일관성을 유지해야 한다.

GNSS 시뮬레이션(GNSS Simulation)은 실외 AMR에서 매우 유용하다. HIL은 위성 가시성(Satellite Visibility) 변화, RTK 보정(RTK Correction) 손실, 다중경로(Multipath) 오차, 위치 점프(Position Jump), 메시지 지연, 정확도 저하를 재현할 수 있다. 시험은 고정밀 모드와 성능 저하 모드 간의 전환, 무결성 검사(Integrity Check), 위치추정 대체(Localization Fallback), 미션 제한, 보정 복구를 검증해야 한다. 위치 품질 정보는 단순한 메타데이터가 아니라 실제 시스템 동작에 반영되어야 한다.

LiDAR와 카메라 시뮬레이션은 인식(Perception), 위치추정, 장애물 회피 시험에 활용될 수 있지만 계산량은 매우 크다. 환경 모델은 로봇 위치, 장면 기하학(Scene Geometry), 센서 장착 위치, 시야, 가림(Occlusion), 거리 한계, 갱신 주기 사이의 일관성을 유지해야 한다. 정적 장애물, 이동하는 사람, 반사 표면, 좁은 통로, 센서 차단, 프레임 손실, 조명 변화와 같은 시나리오를 포함해야 하며, 필요에 따라 기록 데이터와 생성 데이터를 함께 사용할 수도 있다.

액추에이터 및 플랜트 모델(Actuator and Plant Model)은 제어 명령을 실제와 유사한 물리적 응답으로 변환하여 제어 루프(Control Loop)를 완성한다. 모터 토크, 휠 속도, 조향각, 브레이크 상태, 리프트 위치, 적재물 움직임은 실제 한계와 지연을 반영해야 한다. 포화(Saturation), 데드밴드(Deadband), 백래시(Backlash), 마찰, 열 제한(Thermal Derating), 전압 저하도 필요에 따라 모델에 포함해야 한다. 액추에이터 모델이 부정확하면 제어기는 실제보다 이상적인 피드백을 받게 되어 중요한 제어 문제를 발견하지 못할 수 있다.

HIL 시스템은 실제 제품의 통신 구조를 그대로 재현해야 한다. 스위치(Switch), 게이트웨이(Gateway), 제어기, 주소 체계(Addressing), 메시지 우선순위, 통신량(Traffic)을 실제와 동일하게 구성해야 한다. 분산형 AMR은 고속 센서 데이터, 제어 명령, 진단 정보, 안전 상태, 플릿 메시지를 동시에 교환한다. 통합 시험에서는 지연(Latency), 지터, 패킷 손실(Packet Loss), 큐 증가, 버스 사용률(Bus Utilization), 혼잡 시 동작을 측정해야 한다.

CAN 및 CAN FD 시험은 정상 통신, 최대 버스 부하, 우선순위 경쟁, 메시지 타임아웃, 오류 프레임(Error Frame), Bus-Off 상태, 노드 손실, 잘못된 식별자, 복구를 포함해야 한다. 시험 환경은 모터 드라이브, BMS, 충전기, I/O 모듈을 에뮬레이션하면서 실제 제어기의 반응을 관찰할 수 있다. 메시지 카운터, 체크섬, 롤링 코드(Rolling Code), 진단 상태를 확인해야 하며, 반복 전송이 동일 명령의 중복 실행으로 이어져서는 안 된다.

Ethernet 및 ROS 2 기반 HIL 시험은 노드 탐색(Node Discovery), 네트워크 시작 순서, 주소 변경, 시간 동기화, QoS 호환성, 대역폭 제한, 재연결을 검증해야 한다. 카메라와 LiDAR 스트림은 제어 및 진단 트래픽과 경쟁하여 지연을 발생시킬 수 있다. 따라서 실제 데이터 속도와 메시지 크기를 재현해야 하며, 스위치, 케이블, 프로세스, 네트워크 인터페이스가 일시적으로 중단되더라도 노드가 정상적으로 복구되는지를 확인해야 한다.

시간 동기화(Time Synchronization)는 여러 실제 장치와 시뮬레이션을 함께 사용하는 HIL에서 매우 중요하다. 실제 컴퓨터는 PTP, GNSS 시간, NTP, 하드웨어 트리거, 단조 시계(Monotonic Clock)를 사용할 수 있다. 시험에서는 시계 오프셋, 드리프트, 타임스탬프 지연, 동기화 복구를 측정해야 한다. 센서 융합, 분산 로깅, 모션 제어, 고장 분석은 시간 정보가 일관되지 않으면 쉽게 오류를 일으키므로 정상 상태뿐 아니라 동기화 상실도 반드시 검증해야 한다.

전원 상태 시뮬레이션(Power-State Simulation)은 HIL을 데이터 인터페이스 수준을 넘어 확장한다. 시동(Ignition), Enable, Wake, Sleep, 저전압(Low Voltage), 종료(Shutdown), 충전(Charging), 비상 절연(Emergency Isolation)을 재현할 수 있다. 프로그래머블 전원 공급기와 전자 부하(Electronic Load)를 이용해 전압 변화나 전류 제한을 실제 제어기에 인가할 수 있다. 기동 순서, 브라운아웃(Brownout), 순간 전원 차단, 느린 전압 감소, 재부팅, 복구 과정을 시험해야 하며, 전원 상태와 소프트웨어 상태를 함께 기록해야 한다.

배터리 및 충전 HIL은 충전 상태(State of Charge), 팩 전압, 전류, 온도, 셀 불균형(Cell Imbalance), 접촉기 상태, 충전기 상태, 배터리 고장을 시뮬레이션할 수 있다. 이를 통해 실제 배터리를 반복적으로 충방전하지 않고도 에너지 관리 시스템을 검증할 수 있다. 임무 중 저배터리, 충전 실패, 통신 손실, 과열, 접촉기 고장, 충전 후 재시작과 같은 시나리오를 시험해야 하며, 에너지 계산은 시뮬레이션된 부하와 실제 시간에 맞게 일관성을 유지해야 한다.

안전 제어기 HIL(Safety Controller HIL)은 매우 신중하게 설계되어야 한다. 비상정지(E-Stop), 보호 영역 상태, 속도 제한, 브레이크 피드백, 접촉기 상태, 안전 엔코더, 리셋 입력을 자극하여 STO, 재시작 방지, 채널 불일치 검출, 응답 시간을 검증할 수 있다. 그러나 HIL만으로 안전 인증을 대체할 수는 없다. 안전 관련 결과는 검증된 모델, 교정된 계측, 통제된 구성, 적절한 검토 절차를 기반으로 해야 한다.

고장 주입(Fault Injection)은 HIL의 가장 큰 장점 중 하나이다. 실제 로봇을 손상시키지 않고도 위험하거나 드문 고장을 반복적으로 발생시킬 수 있기 때문이다. 단선(Open Circuit), 단락(Short Circuit), 신호 고정(Stuck Signal), 잘못된 센서 값, 데이터 정지, 통신 지연, 메시지 손상, 노드 종료, 제어기 리셋, CPU 과부하, 메모리 부족, 기계적 고장을 재현할 수 있다. 모든 고장은 발생 시점, 지속 시간, 심각도, 탐지 방법, 예상 반응, 복구 조건을 명확히 정의해야 한다.

단일 고장 시험(Single-Fault Testing)은 하나의 고장이 적절히 격리되는지를 검증하고, 복합 고장 시험(Combined-Fault Testing)은 여러 성능 저하 조건이 동시에 발생할 때의 상호작용을 평가한다. 예를 들어 위치추정 센서가 고장 난 상태에서 통신 품질도 저하될 수 있고, 저배터리 상황에서 장애물 회피를 수행해야 할 수도 있다. 복합 고장은 무작위가 아니라 위험 분석(Hazard Analysis)을 기반으로 선정해야 하며, HIL은 이러한 시나리오를 반복 가능하게 만들어 준다.

워치독(Watchdog)과 복구 동작은 의도적인 타이밍 오류와 프로세스 중단을 통해 검증해야 한다. 센서 업데이트 중단, 명령 지연, 프로세스 정지, 제어기 재시작, 네트워크 참여자 제거 등을 수행할 수 있다. AMR은 오래된 정보를 탐지하고, 안전하지 않은 출력을 차단하며, 정의된 성능 저하 상태로 진입하고, 정상 조건이 복원된 후에만 안전하게 복구해야 한다. 반복 리셋이 진동이나 중복 미션, 비정상적인 액추에이터 활성화, 데이터 손상을 일으키지 않는지도 확인해야 한다.

내비게이션 HIL은 실제 위치추정, 경로 계획, 제어 소프트웨어를 시뮬레이션된 이동 로봇과 연결한다. 제어 명령은 시뮬레이션된 차량을 움직이고, 그 결과는 다시 센서 입력으로 반영되는 폐루프(Closed Loop)를 형성한다. 경로 추종, 동적 장애물, 막힌 경로, 좁은 복도, 도킹, 목표 취소, 위치추정 성능 저하, 지도 불일치와 같은 다양한 시나리오를 시험할 수 있다. 이는 기록 데이터 재생과 달리 로봇의 결정이 이후 센서 입력에 영향을 미치는 실제 자율주행 특성을 검증할 수 있다.

도킹(Docking) 및 정밀 정지(Precision Stop) 시험은 위치 오차, 휠 슬립, 조향 오차, 센서 노이즈, 마커 가시성, 최종 접근 경로를 모델링할 수 있다. 제어기는 지정된 허용 오차 안으로 수렴해야 하며, 속도와 안전 제한도 동시에 만족해야 한다. 시작 위치, 자세, 적재 중량, 바닥 마찰, 센서 품질을 반복적으로 변경하여 성능 분포를 분석하고 실제 장비에 부담을 주기 전에 제어 파라미터를 최적화할 수 있다.

미션 수준 HIL(Mission-Level HIL)은 작업 할당, 이동, 충전 요구, 고장, 일시정지, 취소, 외부 서비스 요청에 대한 로봇의 반응을 검증한다. 플릿 관리 시뮬레이터는 명령을 보내고 응답, 상태 변화, 미션 결과를 확인할 수 있다. 로봇은 재연결과 재시작 이후에도 미션 ID를 유지해야 하며, 동일한 미션을 중복 수행해서는 안 된다. 또한 성능 저하 상태를 외부 시스템에 명확하게 전달해야 한다.

페이로드 인터페이스(Payload Interface)는 리프트(Lift), 컨베이어(Conveyor), 로봇 암(Robot Arm), 검사 장비(Inspection Module), 맞춤형 장비와의 연동도 포함할 수 있다. HIL은 장비 준비 상태, 인터록, 적재 상태, 작업 완료, 고장, 전력 소비를 시뮬레이션할 수 있다. 명령 순서, 소유권, 타임아웃, 안전 중단, 복구를 확인해야 하며, 모바일 베이스는 페이로드가 안전하지 않은 상태에서 이동해서는 안 되고, 반대로 페이로드도 위치추정이나 안전 조건이 만족되지 않으면 동작해서는 안 된다.

HIL의 장점을 극대화하기 위해서는 시험 자동화(Test Automation)가 필수적이다. 시험 소프트웨어는 벤치를 구성하고, 모델을 로드하며, 제어기를 초기화하고, 시나리오를 실행하고, 고장을 주입하며, 데이터를 수집하고, 합격 기준을 평가하며, 보고서를 생성해야 한다. 자동화는 반복성과 야간 회귀 시험을 가능하게 하지만, 시험 스크립트는 이해하기 쉽고 버전 관리되어야 한다. 잘못된 모델이나 설정을 사용하면 자동화는 잘못된 결과를 대량으로 생성할 수 있다.

재사용 가능한 시나리오 정의(Scenario Description)는 초기 상태, 환경, 모델 파라미터, 소프트웨어 구성, 입력 이벤트, 고장 일정, 예상 동작, 성능 지표, 종료 조건을 포함해야 한다. 동일한 시나리오는 SIL(Software-in-the-Loop), HIL, 실제 차량 시험에서 모두 사용할 수 있다. 이를 통해 시험 수준 간 추적성이 향상되고 결과 비교가 가능해진다. 단, 단순화된 HIL 시나리오 통과가 실제 환경 검증 완료를 의미해서는 안 된다.

계측 및 로깅(Measurement and Logging)은 실제 시스템과 시뮬레이션 플랜트를 동기화된 시간으로 함께 기록해야 한다. 제어기 입출력, 모델 상태, 버스 트래픽, CPU 사용률, 메모리, 전력, 안전 신호, 상태 전이, 고장 주입 이벤트를 모두 저장해야 한다. 트리거 기반 기록(Triggered Recording)은 실패 전후의 데이터를 보존할 수 있으며, 각 데이터가 실제 하드웨어에서 생성되었는지 시뮬레이션에서 생성되었는지를 명확히 표시해야 원인 분석이 쉬워진다.

합격 기준(Acceptance Criteria)은 가능한 한 정량적으로 정의해야 한다. 제어 오차, 응답 시간, 정지 시간, 메시지 지연, 탐지 시간, 복구 시간, 누락된 주기, CPU 사용률, 버스 부하, 미션 결과 등을 포함할 수 있다. 모든 기준에는 허용 오차와 측정 불확도를 함께 정의해야 한다. 단순히 제어기가 안정적으로 보였다는 관찰만으로는 충분하지 않으며, 자동 평가 시스템은 결과를 승인된 기준과 비교하면서 상세 데이터를 함께 저장해야 한다.

형상 관리(Configuration Management)는 HIL 결과가 수많은 버전의 조합에 의존하기 때문에 매우 중요하다. 생산 소프트웨어, 펌웨어(Firmware), 하드웨어 버전, 시뮬레이션 모델, 모델 파라미터, 인터페이스 설정, 시험 스크립트, 교정 정보, 네트워크 설정, 시험 장비를 모두 기록해야 한다. 임시 수정 사항과 디버깅 기능도 문서화해야 하며, 동일한 시험 환경을 재현할 수 없는 결과는 공식 출시 근거로 사용할 수 없다.

HIL 벤치(HIL Bench) 자체도 검증과 유지관리가 필요하다. 인터페이스 채널은 교정(Calibration)되어야 하며, 신호 범위, 타이밍, 안전 기능, 시뮬레이터 성능을 주기적으로 확인해야 한다. 기준 시험(Reference Test)은 실제 제품 시험 전에 벤치가 알려진 출력을 생성하는지를 검증한다. 인터페이스 보드, 운영체제, 실시간 소프트웨어, 모델, 배선이 변경되면 HIL 벤치도 다시 검증해야 한다. 시험 시스템을 통제되지 않는 실험 장비처럼 취급하면 모든 시험 결과의 신뢰성이 떨어진다.

HIL과 실제 차량 시험의 상관성(Correlation)은 지속적으로 검토해야 한다. 일부 시나리오는 HIL과 실제 로봇에서 모두 수행하여 모션, 타이밍, 전력, 통신, 고장 반응의 차이를 비교해야 한다. 실제 현장에서 새로운 현상이 발견되면 모델과 회귀 시험도 함께 업데이트해야 한다. 목표는 모든 수치를 완전히 동일하게 만드는 것이 아니라, 실제 의사결정에 영향을 주는 핵심 거동과 위험을 정확하게 예측하는 것이다.

HIL은 명확한 한계도 가지고 있다. 타이어와 바닥의 상호작용, 기계 마모, 진동, 전자기 간섭(EMI), 복잡한 광학 효과, 사람의 행동, 환경 오염, 설치 조건은 모델링하지 않는 한 완전히 재현할 수 없다. 또한 최종 안전 시험, 성능 시험, 내구 시험, 고객 현장 시험을 대체할 수도 없다. HIL의 역할은 불확실성을 줄이고 결함을 조기에 발견하여 실제 차량 시험이 반드시 필요한 영역에 집중하도록 돕는 것이다.

성숙한 HIL 프로세스는 지속적 통합(Continuous Integration, CI)의 일부로 운영되어야 한다. 새로운 소프트웨어가 빌드되면 자동으로 HIL 벤치에서 스모크 시험(Smoke Test), 서브시스템 회귀 시험, 고장 주입 시험, 성능 시험이 수행될 수 있다. 벤치 예약, 상태 관리, 결과 저장도 중앙에서 관리되어야 하며, 실패 시 관련 데이터와 시험 구성을 자동으로 보존해야 한다. 이를 통해 HIL은 특별한 시험이 아니라 일상적인 개발 파이프라인의 일부가 된다.

우수한 HIL 전략은 명확한 요구사항, 실제와 유사한 인터페이스, 검증된 실시간 모델, 통제된 고장 주입, 동기화된 계측, 추적 가능한 형상 관리에서 시작된다. 이후 시험 결과를 결함 관리, 회귀 시험, 시스템 통합, 최종 현장 검증과 연결한다. 이러한 HIL 체계가 제대로 구축되면 타이밍, 통신, 전원, 제어, 복구와 관련된 문제를 실제 로봇 이전 단계에서 발견할 수 있으며, 개발 비용을 절감하고 안전하고 신뢰성 높은 AMR을 구축하기 위한 견고한 기반을 제공할 수 있다.

12.04 Field Testing and Scenario Testing

현장 시험(Field Testing)과 시나리오 시험(Scenario Testing)은 자율이동로봇(Autonomous Mobile Robot, AMR)이 소프트웨어, 벤치(Bench), 또는 하드웨어 인 더 루프(Hardware-in-the-Loop, HIL) 환경만으로는 완전히 재현할 수 없는 실제 물리적 환경에서 의도된 임무를 수행할 수 있는지를 검증하는 과정이다. 이러한 시험은 통합된 로봇을 실제 바닥, 조명, 날씨, 사람, 인프라(Infrastructure), 무선 네트워크, 페이로드(Payload), 교통 흐름, 운용 절차에 노출시킨다. 목적은 전체 시스템의 동작을 검증하고, 실제 환경에서만 나타나는 상호작용을 발견하며, 로봇이 제한된 환경에서 안전하게 운용될 수 있음을 입증하는 것이다.

현장 시험은 하위 수준의 검증을 통해 시스템이 충분히 안정화된 이후에 시작되어야 한다. 단위 시험(Unit Testing), 통합 시험(Integration Testing), 하드웨어 인 더 루프 시험(Hardware-in-the-Loop Testing), 안전 시험(Safety Check), 교정(Calibration), 기본 차량 시험(Basic Vehicle Test)은 사전에 합의된 수준까지 완료되어야 한다. 현장 시험은 단순한 소프트웨어 오류, 잘못된 배선, 누락된 파라미터, 명백한 인터페이스 불일치를 발견하기 위한 단계가 아니다. 현장 시험의 진정한 가치는 실험실에서는 쉽게 분리하여 검증할 수 없는 실제 환경의 상호작용을 평가하는 데 있다.

점진적인 현장 시험 전략(Progressive Field-Testing Strategy)은 환경의 복잡성을 단계적으로 증가시켜 위험을 줄인다. 초기 시험은 명확한 주행 경로와 인공 장애물, 제한된 접근 구역을 갖춘 작업장이나 실내 시험 공간에서 수행할 수 있다. 이후 문, 통로, 경사로, 교차로, 도킹 스테이션, 보행 구역을 포함하는 폐쇄 시험장으로 확장할 수 있다. 마지막 단계에서는 감독 하에 고객의 실제 현장에서 시범 운용(Pilot Operation)을 수행한 뒤 제한적인 실제 운용으로 이어질 수 있다. 각 단계는 명확한 시작 조건(Entry Criteria)과 종료 조건(Exit Criteria)을 가져야 한다.

시험 장소(Test Site)는 목표 운용 설계 영역(Operational Design Domain, ODD)에 맞추어 선정되어야 한다. 시험 환경에는 공장, 창고, 병원, 캠퍼스, 실외 도로, 적재 구역, 주차장, 건설 현장, 실내·실외 혼합 경로 등이 포함될 수 있다. 시험 장소는 실제 운용에서 예상되는 바닥 재질, 공간 크기, 경사도, 교통 흐름, 가시성, 통신 품질, 인프라를 최대한 재현해야 한다. 깨끗하고 넓고 평평한 바닥에서만 검증된 로봇이 좁고 먼지가 많으며 젖어 있거나 울퉁불퉁한 환경에서도 동일하게 동작한다고 가정해서는 안 된다.

시험을 시작하기 전에 시험팀은 현장 조사(Site Survey)를 수행하고 물리적·운용적 조건을 문서화해야 한다. 조사 항목에는 경로 형상(Route Geometry), 바닥 재질, 경사로, 계단, 틈새, 배수로, 문, 엘리베이터, 적재장, 충전 스테이션, GNSS 가시성, 무선 통신 품질, 조명, 반사면, 제한 구역, 비상 접근 경로가 포함되어야 한다. 또한 사람의 이동, 지게차(Forklift), 카트(Cart), 차량, 임시 장애물도 조사 대상이다. 이러한 정보는 시나리오 설계의 기초가 되며 별도의 안전 대책이 필요한 위험 요소를 식별하는 데 활용된다.

현장 시험 계획(Field Test Plan)은 시험 목적(Objective), 시나리오(Scenario), 책임(Responsibility), 일정(Schedule), 필요한 장비, 소프트웨어 및 하드웨어 기준(Baseline), 안전 대책(Safety Control), 데이터 수집(Data Collection), 합격 기준(Acceptance Criteria), 시험 중단 조건(Abort Condition)을 정의해야 한다. 또한 탐색적 엔지니어링 시험(Exploratory Engineering Trial)과 공식 검증(Formal Validation)을 명확히 구분해야 한다. 탐색 시험은 동작을 이해하기 위해 절차를 수정할 수 있지만, 공식 시험은 승인된 절차와 통제된 구성에서 수행되어야 한다. 두 방식 모두 중요하지만 생성하는 검증 근거(Evidence)의 수준은 다르므로 명확하게 구분하여 관리해야 한다.

시나리오 시험(Scenario Testing)은 운용 요구사항과 위험 분석 결과를 반복 가능한 실제 상황으로 변환하는 과정이다. 하나의 시나리오는 초기 로봇 상태, 미션, 환경, 주행 경로, 참여 객체, 장애물, 인프라, 페이로드, 통신 조건, 이벤트 순서, 예상 반응, 성능 지표, 종료 조건을 포함해야 한다. 다른 팀도 동일한 상황을 재현할 수 있을 정도로 충분한 세부 정보를 제공해야 한다. 단순히 로봇이 사람을 회피해야 한다는 설명만으로는 충분하지 않으며, 속도, 접근 각도, 가시성, 거리, 사람의 이동 방식까지 정의되어야 한다.

체계적인 시나리오 라이브러리(Scenario Library)는 정상(Nominal), 경계(Boundary), 성능 저하(Degraded), 오용(Misuse), 희귀(Rare), 엣지 케이스(Edge Case)를 포함해야 한다. 정상 시나리오는 일상적인 임무 수행을 확인하고, 경계 시나리오는 속도, 적재량, 경사도, 배터리, 센서 범위, 네트워크 품질, 위치추정 정확도의 한계를 검증한다. 성능 저하 시나리오는 제한된 기능으로의 운용을 평가하며, 오용 시나리오는 사용자의 예상 가능한 실수를 다룬다. 희귀 상황과 엣지 케이스는 드물지만 큰 영향을 미칠 수 있는 상황을 포함한다.

정상 현장 시나리오(Nominal Field Scenario)는 실제 운용에서 반복될 일상적인 작업 흐름을 반영해야 한다. 로봇 기동(Start-up), 미션 할당, 경로 주행, 장애물 회피, 도킹(Docking), 페이로드 전달, 충전, 미션 완료, 종료 과정이 포함될 수 있다. 로봇은 이러한 작업을 반복 수행하면서 불필요한 사람의 개입 없이 안정적으로 동작해야 한다. 또한 단순한 성공 여부뿐 아니라 수행 시간, 경로, 정밀도와 같은 반복성도 함께 측정해야 한다.

경계 시험(Boundary Testing)은 정의된 운용 한계 근처에서 시스템 성능을 평가한다. 최대 적재량, 최소 통로 폭, 최대 허용 경사, 저배터리, 최소 여유 공간, 높은 교통량, 약한 통신 환경, 강한 조도 대비와 같은 조건을 시험할 수 있다. 이러한 조건은 요구사항과 위험 분석을 기반으로 선택되어야 하며 임의로 결정해서는 안 된다. 시험은 성능이 점진적으로 저하되는지, 또는 특정 지점에서 급격히 변하는지를 확인해야 하며, 정상 운용과 위험 상태 사이에는 충분한 안전 여유(Margin)가 존재해야 한다.

성능 저하 모드 시나리오(Degraded-Mode Scenario)는 하나 이상의 지원 기능이 정상적으로 동작하지 않을 때 로봇이 어떻게 행동하는지를 검증한다. 부분적인 센서 차단, 위치추정 정확도 저하, GNSS 보정 손실, 네트워크 지연, 플릿 서비스 중단, 저배터리, 모터 출력 제한, 경로 차단 등이 예가 될 수 있다. 이러한 상황에서 로봇은 속도를 줄이거나 운용 영역을 제한하고, 안전하게 정지하거나 도움을 요청하고, 알려진 위치로 복귀하거나, 이후 복구를 위해 미션 상태를 유지해야 한다. 성능 저하 동작은 의도적이고 관찰 가능하며 운용자가 쉽게 이해할 수 있어야 한다.

오용 시험(Misuse Testing)은 의도된 사용 절차는 아니지만 실제 운용 중 충분히 발생할 수 있는 사람의 행동을 평가한다. 사용자가 로봇을 밀거나 센서 앞에 물체를 두거나, 잘못된 적재를 하거나, 도킹을 중단하거나, 충전기를 분리하거나, 로봇 앞을 가로지르거나, 고장이 해결되기 전에 강제로 재시작을 시도하는 상황을 포함할 수 있다. 이러한 시험은 오용을 장려하기 위한 것이 아니라, 일반적인 사람의 실수가 즉시 위험한 움직임이나 숨겨진 손상, 불안전한 복구로 이어지지 않는지를 확인하기 위한 것이다.

희귀 이벤트 시험(Rare-Event Testing)은 일상적인 운용에서는 거의 발생하지 않지만 안전이나 임무에 큰 영향을 줄 수 있는 상황을 검증한다. 예를 들어 장애물 뒤에서 갑자기 사람이 나타나는 경우, 두 개의 문이 동시에 상태를 변경하는 경우, 네트워크 손실과 저배터리가 동시에 발생하는 경우, 예상하지 못한 차량이 진입하는 경우, 이동하던 장애물이 갑자기 정지하는 경우, 교차로에서 위치추정이 갑자기 크게 변하는 경우 등이 포함될 수 있다. 이러한 상황은 실제 환경에서 반복하기 어렵지만, 통제된 현장 시험을 통해 안전하게 반복 검증할 수 있다.

엣지 케이스(Edge Case)는 하나의 극단적인 변수보다 여러 조건이 동시에 발생할 때 만들어지는 경우가 많다. 예를 들어 반사되는 바닥, 낮은 태양광, 부분적인 센서 오염, 어두운 장애물이 동시에 존재하면 각각은 허용 범위 안에 있더라도 전체 인식 성능이 크게 저하될 수 있다. 무거운 적재물, 젖은 경사로, 비상정지가 동시에 발생하면 개별 시험보다 훨씬 긴 제동거리가 나타날 수도 있다. 따라서 시나리오 설계는 위험 분석, 시뮬레이션, 현장 사고, 엔지니어링 경험을 기반으로 의미 있는 조합을 포함해야 한다.

차량 동역학 시험(Vehicle Dynamics Testing)은 가속(Acceleration), 제동(Braking), 조향(Steering), 회전 반경(Turning Radius), 안정성(Stability), 접지력(Traction), 휠 슬립(Wheel Slip), 바닥 마찰 변화에 대한 반응을 검증해야 한다. 필요에 따라 적재물의 질량과 무게중심도 변경해야 한다. 직선 주행, 급회전, 후진, 비상정지, 경사로, 바닥 재질 변화, 울퉁불퉁한 노면을 포함해야 하며, 과도한 진동이나 바퀴 들림, 견인 불안정, 예상치 못한 움직임으로 인한 위치추정 손실이 발생하지 않아야 한다.

내비게이션 시험(Navigation Testing)은 실제 환경에서 위치추정(Localization), 경로 계획(Path Planning), 장애물 회피, 재계획(Replanning), 복구(Recovery), 도킹, 경로 완료를 검증한다. 개방 공간, 좁은 복도, 교차로, 사각지대, 반복 구조, 반사 환경, 동적 장애물이 존재하는 구역을 포함해야 한다. 지도(Map), 의미 기반 제한(Semantic Restriction), 속도 제한 구역, 일방통행 구역, 진입 금지 구역도 함께 검증해야 한다. 또한 경로가 막히거나 목표가 이동 중 취소될 때도 시스템은 예측 가능한 방식으로 동작해야 한다.

동적 장애물 시나리오(Dynamic-Obstacle Scenario)는 사람, 카트, 지게차, 차량, 동물, 다른 로봇이 다양한 속도와 방향으로 이동하는 상황을 재현해야 한다. 접근 각도, 가시성, 거리, 교차 시점, 정지와 이동의 반복, 여러 사람이 함께 이동하는 상황을 변화시켜 시험해야 한다. 로봇은 관련 객체를 정확히 탐지하고 추적하며 안전 거리를 유지하고 속도를 부드럽게 조절해야 한다. 또한 주변 사람이나 장비에 새로운 위험을 만들 정도로 급격한 경로 변경을 수행해서는 안 된다.

사람-로봇 상호작용(Human-Robot Interaction, HRI) 시험은 사람이 로봇의 의도와 상태를 쉽게 이해할 수 있는지를 평가한다. 조명(Light), 소리(Sound), 디스플레이(Display), 투사 표시(Projected Indicator), 이동 방식은 시작, 정지, 회전, 양보, 고장, 도움 요청 상태를 명확하게 전달해야 한다. 시험에는 숙련된 작업자뿐 아니라 일반 사용자도 포함하는 것이 바람직하다. 관찰자는 망설임, 오해, 위험한 접근, 반복적인 개입을 기록해야 하며, 사용성 문제는 결국 운용 안전 문제로 이어질 수 있다.

문(Door), 엘리베이터(Elevator), 게이트(Gate), 인프라(Infrastructure) 연동 시나리오는 디지털 통신과 물리적 상호작용을 동시에 검증해야 한다. 로봇은 접근 요청, 승인 대기, 문 열림 확인, 제한된 공간 진입, 위치 유지, 통과 후 재출발을 수행해야 한다. 응답 지연, 부분 개방, 갑작스러운 문 닫힘, 사용 중인 엘리베이터, 서비스 중단, 통신 손실도 포함해야 한다. 실제 물리 상태와 디지털 상태가 일치하지 않는 경우에는 진입하거나 이동을 계속해서는 안 된다.

도킹 및 충전 시나리오(Docking and Charging Scenario)는 접근, 정렬, 최종 정지 정확도, 전기 연결, 충전 승인, 에너지 전달, 충전 종료, 미션 재개를 평가한다. 초기 위치, 자세, 적재물, 바닥 마찰, 충전기 상태, 마커 가시성을 다양하게 변경해야 한다. 연결 실패를 인식하면 제한된 횟수 내에서 재시도하고, 필요한 경우 운용자에게 도움을 요청해야 한다. 또한 실제 충전이 이루어지지 않았는데도 충전 중이라고 잘못 판단하는 상태가 발생해서는 안 된다.

페이로드 및 물류 처리 시나리오(Payload and Material-Handling Scenario)는 적재, 운반, 하역, 결합, 분리, 컨베이어, 리프트, 트레일러, 랙, 로봇 암과의 상호작용을 검증한다. 적재 질량, 무게 분포, 무게중심, 고정 상태, 식별 정보, 센서 가시성을 변화시켜 시험해야 한다. 로봇은 페이로드 인터페이스가 준비되고 안전하게 결합되었는지를 확인한 후 이동해야 하며, 인터록(Interlock)이 만족되지 않으면 출발해서는 안 된다. 운송 중 페이로드 고장이 발생하면 안전하게 대응해야 한다.

플릿 수준 현장 시험(Fleet-Level Field Testing)은 여러 대의 로봇과 플릿 관리 시스템(Fleet Management System)의 협조 동작을 검증한다. 동시에 여러 미션을 할당하거나, 교차로에서 여러 대가 만나는 상황, 좁은 통로 공유, 충전 대기, 우선순위 변경, 경로 차단, 로봇 고장, 네트워크 중단을 포함해야 한다. 플릿 시스템은 교착 상태(Deadlock), 기아 상태(Starvation), 미션 중복 수행, 위험한 혼잡을 방지해야 한다. 또한 로봇 수와 미션 수를 증가시키면서 지연, 처리량, 교통 효율, 운용자 부담도 함께 평가해야 한다.

통신 시험(Communication Testing)은 실제 무선 통신 환경을 재현해야 한다. 무선 커버리지, 간섭, 핸드오버(Handover), 대역폭 제한, 지연, 일시적인 연결 끊김을 포함해야 한다. 외부 서비스가 중단되더라도 로봇은 안전한 로컬 자율성을 유지해야 하며, 재연결 후에는 상태를 정확히 동기화해야 한다. 재전송으로 인해 동일한 명령이 두 번 수행되어서는 안 되며, 오래된 명령도 거부되어야 한다. 또한 충전기, 문, 엘리베이터, 플릿 서버, 원격 모니터링 시스템과의 통신도 검증 대상이다.

실외 시나리오(Outdoor Scenario)는 비(Rain), 먼지(Dust), 바람(Wind), 햇빛(Sunlight), 그림자(Shadow), 온도, 물웅덩이(Puddle), 불규칙한 노면, 식생(Vegetation), GNSS 환경, 바닥 상태 변화를 포함해야 한다. 시험은 허용된 환경 조건 안에서 수행되어야 하며 적절한 안전 대책을 적용해야 한다. 목적은 센서 성능, 접지력, 가시성, 열 부하, 통신 품질이 동시에 변화할 때 시스템이 어떻게 반응하는지를 평가하는 것이다. 환경 시험실은 이러한 실제 상호작용을 완전히 재현할 수 없다.

야간 및 저조도 시험(Night and Low-Light Testing)은 카메라 성능, 조명 장치, 장애물 검출, 시각 표시, 운용자의 가시성을 평가해야 한다. 인공 조명, 전조등, 반사, 눈부심(Glare), 그림자, 밝고 어두운 구역 사이의 급격한 변화도 포함해야 한다. 로봇 자체의 조명이 카메라나 사람의 시야를 방해해서는 안 된다. 인식과 위치추정 성능을 주간 시험과 비교하고, 필요한 경우 속도 제한이나 제한 운용 모드가 자동으로 활성화되어야 한다.

장시간 현장 시험(Long-Duration Field Test)은 반복적인 미션 수행을 통해 내구성(Endurance), 신뢰성(Reliability), 열 안정성(Thermal Stability), 에너지 소비(Energy Consumption), 메모리 증가(Memory Growth), 통신 품질, 유지보수 요구사항을 평가한다. 로봇은 수시간 또는 수일 동안 경로 주행, 도킹, 적재물 처리, 충전을 반복해야 한다. 완전한 고장뿐 아니라 개입 횟수 증가, 미션 시간 증가, 위치추정 드리프트, 열 제한, 배터리 추정 오차, 기계적 변화도 함께 기록해야 한다. 이러한 경향은 짧은 시험에서는 발견되지 않는 문제를 보여줄 수 있다.

모든 현장 시험에서는 안전 관리(Safety Management)가 필수적이다. 시험 계획에는 시험 책임자(Test Leader), 안전 감시자(Safety Observer), 비상정지 담당자(Emergency-Stop Operator), 현장 관리자(Site Coordinator), 기술 지원 담당자의 역할을 정의해야 한다. 접근 통제, 안전 펜스, 경고 표지, 개인 보호 장비(PPE), 속도 제한, 지오펜싱(Geofencing), 통신 절차도 필요할 수 있다. 모든 참가자는 시험 중지 명령과 비상 대피 절차를 이해해야 하며, 특별히 승인된 경우를 제외하고는 실제 제품의 안전 기능을 비활성화해서는 안 된다.

시험 중단 조건(Abort Condition)은 시험 시작 전에 미리 정의되어야 한다. 비상정지 기능 상실, 제어되지 않는 움직임, 예상하지 못한 가속, 적재물 불안정, 과열, 연기, 배터리 이상, 허용 시간을 초과한 통신 장애, 승인되지 않은 사람의 진입, 현장 통제 상실 등이 대표적인 중단 조건이다. 안전 감시자는 관리자의 승인을 기다리지 않고도 즉시 시험을 중단할 수 있어야 한다.

계측 및 데이터 수집(Instrumentation and Data Collection)은 로봇의 동작과 환경 이벤트를 시간 동기화(Time Synchronization)하여 기록해야 한다. 온보드 로그(Onboard Log), 센서 데이터, 액추에이터 피드백, 안전 상태, 전력 정보, 네트워크 통계, 외부 비디오, 천장 카메라, 기준 측량점, 모션 캡처(Motion Capture), GNSS 기준 데이터, 운용자 메모를 함께 수집할 수 있다. 계측 시스템은 중요한 이벤트 전후의 데이터를 모두 저장해야 하며, 공통 시간 기준을 사용하여 인식, 판단, 명령, 이동, 외부 환경을 정확히 비교할 수 있어야 한다.

기준값(Ground Truth)은 위치 정확도, 도킹 정밀도, 제동 거리, 속도, 장애물 거리, 미션 시간, 경로 오차를 평가하기 위해 필수적이다. 토털 스테이션(Total Station), 모션 캡처 시스템, 측량 기준점, 교정된 카메라, 레이더 속도계, 로드셀(Load Cell), 정밀 거리 측정 장비를 사용할 수 있다. 기준 시스템의 측정 불확도는 합격 허용 오차보다 충분히 작아야 하며, 단순한 육안 관찰만으로는 공식적인 정량 검증을 대신할 수 없다.

현장 시험 성능 지표(Field-Test Metric)는 실제 운용 요구사항과 안전 요구사항에 직접 연결되어야 한다. 대표적인 지표는 미션 성공률, 개입 빈도, 위치추정 오차, 도킹 정확도, 최소 장애물 거리, 제동 거리, 경로 완료 시간, 처리량(Throughput), 에너지 소비, 충전 성공률, 통신 가용성, 복구 시간, 고장 탐지 지연 등이다. 결과는 평균값뿐 아니라 분포와 최악 조건(Worst Case)도 함께 제시해야 하며, 실패하거나 경계 수준에 가까운 결과는 별도로 분석해야 한다.

현장 시험은 사람, 조명, 날씨, 교통, 무선 환경이 계속 변화하기 때문에 반복성(Repeatability)을 확보하기가 어렵다. 시험팀은 통제 가능한 변수는 표준화하고, 통제할 수 없는 변수는 반드시 기록해야 한다. 장애물 위치, 경로 표시, 사람의 이동 경로, 시작 상태, 적재물, 시간 조건을 표준화하면 반복성을 높일 수 있다. 충분한 반복 시험을 통해 변동성을 파악해야 하며, 서로 다른 환경에서 수행된 결과를 동일한 조건으로 간주해서는 안 된다.

사람이나 차량이 시험에 참여하는 경우에는 사전에 정의된 행동 시나리오(Script)를 따라야 한다. 스크립트는 시작 위치, 이동 경로, 속도, 이벤트 발생 시점, 예상 상호작용, 안전한 대피 경로를 포함해야 한다. 사전 교육과 리허설은 변동성을 줄이고 참가자의 안전을 보장한다. 사람을 불필요한 위험에 노출시켜 로봇의 반응을 시험해서는 안 되며, 충돌 가능성이 있는 경우에는 더미(Dummy), 부드러운 표적, 원격 제어 플랫폼을 사용하는 것이 바람직하다.

탐색적 시험(Exploratory Testing)은 모든 중요한 상호작용을 사전에 예측할 수 없기 때문에 여전히 가치가 있다. 숙련된 운용자와 엔지니어는 경로, 장애물, 미션 순서, 환경 조건을 변화시키며 예상하지 못한 문제를 찾을 수 있다. 이러한 결과는 충분한 설정 정보와 함께 기록되어야 하며, 중요한 문제가 발견되면 이를 공식적인 시나리오로 전환하여 입력 조건, 측정 방법, 합격 기준을 명확히 정의해야 한다.

현장에서 발견된 결함은 시스템을 재시작하거나 수정하기 전에 증거를 확보해야 한다. 로그, 영상, 설정, 지도, 교정 정보, 환경 조건, 운용자 조작, 물리적 관찰 결과를 모두 수집해야 한다. 또한 최종 증상보다 기대 동작에서 처음 벗어난 시점을 찾아야 한다. 이후 동일한 시나리오는 기록 데이터 재생, 시뮬레이션, HIL, 폐쇄 시험장, 통제된 현장 시험 등 가능한 가장 작은 환경에서 재현해야 한다.

수정 사항(Corrective Action)은 먼저 통제된 환경에서 검증한 후 전체 현장 시나리오에서 다시 확인해야 한다. 하나의 소프트웨어 수정은 타이밍, 경로 선택, 안전 여유, 에너지 소비, 복구 동작에도 영향을 줄 수 있다. 따라서 회귀 시험(Regression Test)은 원래 문제뿐 아니라 관련 시나리오와 기본 정상 시나리오도 함께 포함해야 한다. 수정 결과는 실제 환경에서 정상적으로 동작함이 입증되고 형상 관리(Configuration Management)가 완료된 후에만 결함을 종료해야 한다.

현장 시험에서는 형상 관리(Configuration Management)가 특히 중요하다. 시험 결과는 로봇 일련번호, 하드웨어 버전, 소프트웨어와 펌웨어(Firmware) 버전, AI 모델, 지도(Map), 교정 정보, 파라미터, 안전 설정, 페이로드, 배터리 상태, 네트워크 구성, 인프라 버전, 시나리오 스크립트와 함께 기록해야 한다. 시험 중 임시 조정도 반드시 문서화해야 하며, 실제 배포 구성과 다른 환경에서 수행된 시험은 출시 근거로 사용할 수 없다.

공식 시험 보고서(Formal Test Report)는 시험 목적, 요구사항, 시험 장소, 장비, 구성 정보, 시나리오, 안전 대책, 환경 조건, 수행 이력, 결과, 이상 현상, 성능 지표, 증거 자료, 결론을 포함해야 한다. 승인된 절차에서 벗어난 내용도 명확하게 기록해야 한다. 사진과 그림은 참고 자료로 사용할 수 있지만 정량적인 측정 결과를 대신해서는 안 된다. 또한 각 시나리오가 합격(Pass), 실패(Fail), 판정 불가(Inconclusive) 중 어느 상태인지와 그 근거를 명확하게 제시해야 한다.

출시 결정(Release Decision)은 단순한 합격률이 아니라 시험 범위(Coverage)와 잔여 위험(Residual Risk)을 함께 고려해야 한다. 대부분의 시험을 통과했더라도 중요한 시나리오가 검증되지 않았거나 치명적인 결함에 대한 신뢰성 있는 대응책이 없다면 제품을 출시해서는 안 된다. 운용 제한, 감독 수준, 환경 조건, 복구 절차, 유지보수 요구사항, 모니터링 기능도 함께 검토해야 한다. 제한 조건이 명확하고 실제로 적용 가능하며 충분한 근거가 있는 경우에는 조건부 출시도 가능하다.

시범 운용(Pilot Deployment)은 제한된 실제 운용 환경에서 현장 시험을 확장하는 단계이다. 제한된 시간, 승인된 경로, 낮은 속도, 제한된 적재량, 지원 인력이 있는 조건에서 로봇을 운용할 수 있다. 시범 운용에서는 미션 성공률, 사람의 개입, 사용자 만족도, 인프라 호환성, 유지보수 노력, 새로운 위험 요소를 평가해야 한다. 확장은 정의된 합격 기준을 만족한 이후에만 수행되어야 하며, 단순히 로봇이 유용해 보인다는 이유로 승인되지 않은 실제 운용으로 이어져서는 안 된다.

운용 피드백(Operation Feedback)은 시나리오 라이브러리를 지속적으로 업데이트해야 한다. 플릿 로그(Fleet Log), 고객 지원 사례, 사고 직전 상황(Near Miss), 운용자 의견, 유지보수 기록, 고객 작업 흐름 변화는 초기 검증에서 고려하지 못한 새로운 조건을 보여줄 수 있다. 중요한 현장 사건은 시뮬레이션, HIL, 폐쇄 시험장, 고객 현장 시험의 회귀 시나리오로 추가되어야 한다. 이러한 피드백 루프(Feedback Loop)는 제품과 환경, 사용자 행동이 변화하더라도 시험 체계가 함께 발전하도록 만들어 준다.

성숙한 현장 시험 및 시나리오 시험(Field Testing and Scenario Testing) 프로세스는 요구사항, 위험 분석(Hazard Analysis), 통제된 시험장, 실제 고객 환경, 시간 동기화된 데이터, 정량적인 합격 기준, 결함 재현, 수정 검증, 운용 피드백을 하나의 체계로 연결한다. 이를 통해 개별 기능뿐 아니라 실제 바닥, 사람, 인프라, 통신, 페이로드, 다양한 환경 변화 속에서 전체 AMR 시스템이 예측 가능하고 안전하며 신뢰성 있게 동작함을 입증할 수 있다. 단계적이고 체계적인 시험 전략을 적용하면 실제 제품 출시를 위한 최종 엔지니어링 근거를 확보하고, 장기간 안정적으로 운용 가능한 AMR 시스템을 개발할 수 있다.

12.05 AI Model Validation

AI 모델 검증(AI Model Validation)은 학습된 모델이 자율이동로봇(Autonomous Mobile Robot, AMR)의 운용 설계 영역(Operational Design Domain, ODD) 내에서 의도된 기능을 신뢰성 있게 수행하는지를 확인하는 과정이다. 단순히 시험 데이터셋(Test Dataset)의 정확도(Accuracy) 하나만을 평가하는 것이 아니라 데이터 품질(Data Quality), 작업 성능(Task Performance), 불확실성(Uncertainty), 강건성(Robustness), 실행 시간(Timing), 하드웨어 성능(Hardware Execution), 시스템 상호작용(System Interaction), 고장 동작(Failure Behavior), 실제 현장 적합성(Field Suitability)까지 종합적으로 검토한다. 궁극적인 목적은 실제 운용 환경에서 모델이 안전하고 신뢰할 수 있는 로봇 동작에 기여한다는 객관적인 근거를 확보하는 것이다.

모델 검증은 먼저 로봇 시스템 구조(System Architecture)에서 AI 모델이 수행하는 역할을 명확히 정의하는 것부터 시작해야 한다. AI 모델은 사람 검출(Person Detection), 장애물 분류(Obstacle Classification), 주행 가능 영역 분할(Traversable Ground Segmentation), 깊이 추정(Depth Estimation), 팔레트 인식(Pallet Recognition), 이동 예측(Motion Prediction), 이상 탐지(Anomaly Detection), 위치추정 지원(Localization Support), 내비게이션 행동 선택(Navigation Behavior Selection) 등 다양한 역할을 수행할 수 있다. 각 기능은 위험 수준과 허용 기준이 다르다. 단순 참고 정보를 제공하는 모델은 일부 오류를 허용할 수 있지만, 제동, 조향, 경로 선택에 직접 영향을 주는 모델은 훨씬 엄격한 성능 기준과 독립적인 안전 장치를 요구한다.

검증 계획(Validation Plan)은 모델 요구사항을 시스템 요구사항(System Requirement)과 위험 분석(Hazard Analysis)에 연결해야 한다. 검증 계획에는 목표 객체(Target Object), 운용 환경(Environment), 센서 구성(Sensor Configuration), 환경 한계(Environmental Limit), 성능 지표(Performance Metric), 실행 시간(Runtime Constraint), 신뢰도(Confidence) 동작, 장애 대응 전략(Fallback Strategy), 출시 기준(Release Criteria)이 포함되어야 한다. 요구사항은 평균 성능뿐 아니라 로봇 근처에 있는 부분적으로 가려진 사람을 탐지하거나 주행 전에 위험 지형을 인식하는 것과 같은 중요한 상황까지 명확히 기술해야 한다. 또한 모든 요구사항은 데이터셋, 시험 시나리오, 시험 결과와 추적 가능하도록 연결되어야 한다.

데이터셋 분리(Dataset Separation)는 신뢰할 수 있는 AI 검증의 가장 기본적인 원칙이다. 학습 데이터(Training Set), 검증 데이터(Validation Set), 최종 시험 데이터(Test Set)는 완전히 분리되어야 하며, 모델 최적화나 설계 선택에 사용되지 않은 데이터로만 최종 성능을 평가해야 한다. 동일한 장소, 동일한 주행 경로, 동일한 촬영 세션에서 생성된 데이터가 서로 다른 데이터셋에 포함되면 숨겨진 데이터 누수(Data Leakage)가 발생하여 성능이 과대평가될 수 있다. 최종 시험 데이터는 모델이 공식 평가를 받을 때까지 변경하거나 반복적으로 사용해서는 안 된다.

검증 데이터(Validation Data)는 단순히 수집하기 쉬운 데이터가 아니라 실제 운용 설계 영역을 대표해야 한다. 다양한 작업 장소, 바닥 재질, 객체 종류, 적재물, 로봇 속도, 센서 장착 위치, 조명, 날씨, 계절, 교통 흐름, 배경, 거리, 가림(Occlusion) 수준을 포함해야 한다. 실외 로봇은 비(Rain), 먼지(Dust), 눈부심(Glare), 그림자(Shadow), 식생(Vegetation), 젖은 노면, GNSS 관련 조건을 포함해야 할 수 있으며, 실내 로봇은 반사 바닥, 반복 구조, 좁은 통로, 인공 조명, 많은 사람의 이동 환경을 포함해야 한다.

데이터 분포(Data Distribution)는 전체 평균 성능만이 아니라 의미 있는 하위 그룹(Subgroup) 단위로 분석해야 한다. 거리, 객체 크기, 방향, 조명, 날씨, 이동 속도, 설치 장소, 센서 종류, 클래스(Class) 빈도에 따라 성능은 크게 달라질 수 있다. 예를 들어 사람 검출기는 전체 재현율(Recall)은 높지만 멀리 있는 작은 사람이나 부분적으로 가려진 사람을 잘 찾지 못할 수도 있다. 지형 인식 모델은 아스팔트에서는 우수하지만 젖은 금속판에서는 실패할 수 있다. 따라서 결과는 실제 운용에 중요한 조건별로 분류하여 각각의 허용 기준과 비교해야 한다.

레이블 품질(Label Quality)은 검증 결과의 신뢰성을 결정하는 핵심 요소이다. 정답 데이터(Ground Truth)는 승인된 정의, 라벨링 도구(Labeling Tool), 검토 절차를 따라 생성되어야 한다. 애매한 사례는 일관된 기준으로 처리해야 하며, 불확실한 데이터를 억지로 특정 클래스로 분류해서는 안 된다. 바운딩 박스(Bounding Box), 분할 마스크(Segmentation Mask), 이동 궤적(Trajectory), 자세(Pose), 객체 식별(Object Identity)은 각각 다른 품질 검사가 필요하다. 검증 데이터의 일부는 독립적인 검토를 수행하고 의견 불일치율도 함께 측정해야 한다. 잘못된 레이블은 자동으로 모델 오류나 성공으로 해석해서는 안 된다.

성능 지표(Performance Metric)는 로봇이 수행하는 작업과 오류가 미치는 영향을 반영해야 한다. 분류(Classification)는 정밀도(Precision), 재현율(Recall), F1 점수(F1 Score), 혼동 행렬(Confusion Matrix), 클래스별 오류율을 사용할 수 있다. 객체 검출(Object Detection)은 평균 정밀도(Average Precision), 거리별 재현율, 위치 오차(Localization Error), 중요한 객체의 누락률을 사용할 수 있다. 영상 분할(Segmentation)은 IoU(Intersection over Union), 경계 정확도(Boundary Accuracy), 주행 가능 영역 오류를 사용할 수 있다. 위치추정(Localization)은 위치 오차(Position Error), 방향 오차(Heading Error), 드리프트(Drift), 실패율, 복구 시간을 평가해야 한다. 하나의 지표만으로 모든 AI 기능을 평가할 수는 없다.

안전 관련 검증(Safety-Relevant Validation)은 거짓 양성(False Positive)과 거짓 음성(False Negative)을 실제 운용 영향에 따라 구분해야 한다. 거짓 양성 장애물은 불필요한 정지나 효율 저하를 발생시키지만, 거짓 음성 사람 검출은 심각한 안전 위험으로 이어질 수 있다. 그러나 지나치게 많은 거짓 양성도 작업자가 경고를 무시하거나 급정지를 반복하게 만들어 새로운 위험을 초래할 수 있다. 따라서 임계값(Threshold)은 안전성과 미션 성능을 함께 고려하여 설정해야 하며, 모델 출력이 계획(Planning)과 제어(Control)에 어떤 영향을 주는지도 함께 분석해야 한다.

신뢰도 점수(Confidence Score)는 단순히 확률로 가정해서는 안 되며 별도로 검증해야 한다. 특히 학습 데이터와 다른 입력에서는 잘못된 예측에도 높은 신뢰도를 출력하는 경우가 있다. 신뢰도 보정(Calibration)은 예측 신뢰도와 실제 정확도를 비교하는 과정이며, 신뢰도 다이어그램(Reliability Diagram), 예상 보정 오차(Expected Calibration Error, ECE), 클래스별 보정 지표 등을 사용할 수 있다. 시스템은 신뢰도에 따라 속도를 줄이거나 센서 융합을 수행하거나 사람의 확인을 요청하거나 안전 정지를 수행하도록 정의되어야 한다. 신뢰도 값은 적절한 시스템 동작으로 연결될 때만 의미가 있다.

임계값 선택(Threshold Selection)은 승인된 검증 데이터를 사용하여 수행해야 하며, 최종 시험 데이터를 반복적으로 사용하여 조정해서는 안 된다. 객체 검출 임계값, 비최대 억제(Non-Maximum Suppression), 분할 기준값, 이상 탐지 점수, 불확실성 기준은 실제 운용 성능을 크게 변화시킬 수 있다. 다양한 임계값에서 누락 탐지(Missed Detection), 오경보(False Alarm), 지연(Latency), 시스템 안정성을 비교하여 최적의 운용 지점을 선택해야 한다. 또한 실제 환경 변화에 대한 충분한 여유(Margin)를 확보하고 설정값을 공식 형상(Configuration)으로 관리해야 한다.

강건성 시험(Robustness Testing)은 센서 데이터가 이상적이지 않을 때도 모델이 허용 가능한 성능을 유지하는지를 검증한다. 입력에는 블러(Blur), 노이즈(Noise), 압축(Compression), 픽셀 손실(Missing Pixel), 노출 변화(Exposure Change), 진동(Vibration), 비, 먼지, 렌즈 오염, 부분 가림, 타임스탬프 오류, 포인트 클라우드 희소화(Point Cloud Sparsity), 프레임 손실(Dropped Frame)이 포함될 수 있다. 이러한 조건은 실제 현장에서 관찰되는 수준으로 적용해야 하며, 목표는 모든 왜곡을 완전히 극복하는 것이 아니라 성능이 저하되는 한계를 파악하고 위험 상태 이전에 로봇이 안전하게 대응하는지를 확인하는 것이다.

도메인 변화(Domain Shift)는 실제 운용 데이터가 개발 과정에서 사용한 데이터와 달라질 때 발생한다. 새로운 공장, 다른 카메라, 렌즈 교체, 장착 높이 변경, 전처리 소프트웨어 변경, 계절 변화, 새로운 작업복, 낯선 차량, 다른 바닥 재질 등이 원인이 될 수 있다. 검증은 가능한 한 서로 다른 장소와 서로 다른 하드웨어에서 수집한 데이터를 포함해야 한다. 이러한 교차 환경 시험(Cross-Site Evaluation)은 모델이 실제 작업 특성을 학습했는지, 아니면 특정 배경이나 데이터 수집 환경에 과적합(Overfitting)되었는지를 확인할 수 있다.

분포 외 데이터 시험(Out-of-Distribution Testing)은 학습되지 않은 입력을 대상으로 수행한다. AMR은 특이한 기계, 손상된 팔레트, 연기(Smoke), 동물, 공사 장비, 침수 구역 등 학습에 포함되지 않은 환경을 만날 수 있다. 이러한 객체를 정확하게 분류하지 못하는 것은 자연스러운 일이지만, 모델은 지나치게 높은 신뢰도로 잘못된 예측을 해서는 안 된다. 또한 보조 센서, 규칙 기반 검사, 보수적인 안전 동작이 이러한 상황의 위험을 줄이는지도 함께 검증해야 한다.

엣지 케이스 검증(Edge-Case Validation)은 드물지만 실제 운용에서 매우 중요한 상황을 집중적으로 평가해야 한다. 예를 들어 카트 뒤에 부분적으로 가려진 어린이, 바닥에 쓰러진 작업자, 투명한 유리판, 그림자 속의 검은 물체, 강한 햇빛 아래의 반사 안전조끼, 센서 사각지대의 장애물, 서로 겹쳐 보이는 객체 등이 있다. 이러한 사례는 자연스럽게 수집된 데이터에서는 거의 포함되지 않으므로 의도적으로 수집하거나 실제 환경을 재현하거나 시뮬레이션을 통해 생성해야 하며, 실제 데이터와 합성 데이터(Synthetic Data)는 명확히 구분해야 한다.

적대적 시험(Adversarial Testing)은 수학적인 이미지 변형보다 실제 환경에서 발생 가능한 물리적 또는 디지털 교란에 초점을 맞추어야 한다. 줄무늬 작업복, 혼동을 유발하는 표지판, 강한 반사, 반복 무늬, 센서 스푸핑(Sensor Spoofing), 손상된 통신 메시지, 변조된 모델 파일, 비정상적인 전처리 값 등이 포함될 수 있다. 이러한 시험의 목적은 모델을 혼란스럽게 만들 수 있는 현실적인 상황을 찾는 것이다. 또한 모델 무결성(Model Integrity), 인증된 배포(Authentication), 설정 보호, 무단 모델 교체 탐지 기능도 함께 검증해야 한다.

시간적 검증(Temporal Validation)은 영상(Video)이나 포인트 클라우드(Point Cloud)를 연속적으로 사용하는 모델에서 반드시 필요하다. 프레임 단위 정확도만으로는 깜빡이는 분류(Flickering), 추적 불안정, 탐지 지연, 일시적인 탐지 실패를 발견할 수 없다. 최초 탐지 시간(Time to First Detection), 추적 연속성(Track Continuity), 객체 ID 변경, 가림 후 복구, 예측 안정성, 프레임 손실 후 복구 시간을 함께 평가해야 한다. 또한 차량 속도와 제동 거리를 고려할 때 충분히 빠르게 위험을 인식해야 하며, 시간 필터(Temporal Filtering)가 위험 탐지를 과도하게 지연시켜서는 안 된다.

다중 센서 AI 모델(Multi-Sensor AI Model)은 개별 센서와 센서 융합(Sensor Fusion) 모두를 검증해야 한다. 카메라(Camera), LiDAR, 레이더(Radar), 초음파(Ultrasonic), IMU, 지도(Map)는 서로 다른 거리, 시간, 해상도, 고장 특성을 가진다. 정상 동기화, 시간 오차, 일부 센서 누락, 교정 오류, 상충되는 센서 정보를 포함한 시험이 필요하다. 하나의 센서가 고장 났을 때 융합 모델이 오히려 더 나쁜 결과를 내서는 안 되며, 입력이 부족하면 승인된 성능 저하 모드(Degraded Mode)로 전환해야 한다.

폐루프 검증(Closed-Loop Validation)은 AI 모델의 출력만 보는 것이 아니라 실제 움직이는 로봇에 미치는 영향을 평가한다. 작은 인식 오류 하나가 경로 변경, 속도 진동, 반복 정지, 안전 거리 감소, 미션 교착 상태를 유발할 수도 있다. 시뮬레이션(Simulation), HIL, 폐쇄 시험장, 현장 시험은 AI 모델을 실제 계획 및 제어 소프트웨어와 연결하여 검증해야 한다. 이를 통해 로봇의 행동이 이후 센서 입력을 다시 변화시키는 피드백 구조를 확인할 수 있으며, 최종적인 평가는 시스템 전체의 성능으로 이루어져야 한다.

실행 성능(Runtime Performance)은 실제 엣지 컴퓨터(Edge Computing Platform)에서 검증해야 한다. 데스크톱 환경의 추론 속도(Inference Speed)는 실제 로봇 환경과 다르다. 실제 시스템에서는 GPU 부하, CPU 스케줄링, 메모리 대역폭, 열 제한(Thermal Limit), 센서 처리, 로깅, 통신이 동시에 수행된다. 따라서 종단 간 지연(End-to-End Latency), 처리량(Throughput), 지터(Jitter), 메모리 사용량, 시작 시간, 소비 전력, 열 안정성을 측정해야 한다. 특히 평균 속도보다 최악의 실행 시간(Worst-Case Timing)이 훨씬 중요하다.

모델 최적화(Model Optimization)는 정확도를 변화시킬 수 있으므로 별도의 검증이 필요하다. 양자화(Quantization), 가지치기(Pruning), 컴파일(Compilation), 연산자 융합(Operator Fusion), TensorRT 변환, 저정밀 연산(Reduced Precision), 하드웨어 가속(Hardware Acceleration)은 수치 오차를 발생시킬 수 있다. 따라서 최적화된 실제 배포 모델은 원본 모델과 동일한 데이터를 사용하여 비교해야 하며, 전처리, 후처리, 실행 라이브러리(Runtime Library), 하드웨어 구성이 모두 실제 제품과 동일해야 한다. 학습 프레임워크의 모델만 시험하는 것은 충분하지 않다.

반복성(Repeatability)과 결정성(Determinism)도 검증해야 한다. 일부 AI 파이프라인은 비동기 처리, 비결정적 커널(Non-Deterministic Kernel), 무작위 데이터 증강(Random Augmentation), 타이밍 의존 처리 때문에 동일한 입력에서도 다른 결과를 생성할 수 있다. 동일한 입력에 대한 반복 추론 결과는 허용 범위 내에서 일관성을 유지해야 하며, 완전한 결정성이 불가능하다면 변동성을 정량적으로 분석하고 시스템에 미치는 영향을 평가해야 한다. 재현 가능한 시험 환경과 고정된 실행 조건은 문제 발생 시 원인 분석을 가능하게 한다.

설명 가능성(Explainability) 도구는 모델 검증을 지원할 수 있지만 그것만으로 모델의 정확성을 입증할 수는 없다. 어텐션 맵(Attention Map), 살리언시 맵(Saliency Map), 특징 시각화(Feature Visualization), 유사 사례(Nearest Example), 오류 군집(Error Cluster)은 모델이 배경, 그림자, 라벨 오류, 불필요한 특징에 의존하는지를 보여줄 수 있다. 이러한 도구는 가설을 세우고 데이터셋 문제를 발견하는 데 활용해야 하며, 최종 승인은 실제 성능, 강건성, 시스템 동작, 공식 시험 결과를 기반으로 이루어져야 한다.

편향(Bias)과 데이터 커버리지(Coverage)는 사람, 객체, 환경 그룹별로 성능 차이가 존재하는지를 분석해야 한다. 사람 주변에서 동작하는 AMR은 작업복, 체형, 보행 보조기, 자세, 휴대 물체, 가시성 조건에 따라 탐지 성능이 달라질 수 있다. 목적은 사람의 불필요한 개인정보를 추론하는 것이 아니라 특정 사용자 집단에서 안전 성능이 저하되지 않는지를 확인하는 것이다. 성능이 낮은 그룹이 발견되면 추가 데이터 수집, 라벨 수정, 모델 개선 또는 운용 제한이 필요하다.

오류 분석(Error Analysis)은 모든 실패를 하나의 숫자로 처리하지 말고 원인별로 분류해야 한다. 작은 객체 누락, 클래스 혼동, 위치 오차, 중복 검출, 분할 경계 오류, 응답 지연, 신뢰도 불안정, 보정 실패, 전처리 오류, 환경 특화 오류와 같은 범주로 구분할 수 있다. 각 오류 유형은 실제 사례와 운용 영향을 함께 분석해야 하며, 이를 통해 데이터 부족인지, 라벨 문제인지, 모델 구조인지, 임계값 설정인지, 센서 문제인지, 후속 로직 문제인지를 판단할 수 있다.

새로운 모델을 승인하려면 기준 모델(Baseline Model)과의 비교가 필수적이다. 기준 모델은 현재 운영 중인 모델, 기존 알고리즘, 이전 AI 구조, 규칙 기반 시스템이 될 수 있다. 비교는 동일한 데이터셋, 시나리오, 하드웨어, 허용 기준에서 수행해야 한다. 단순히 하나의 성능 지표가 향상되었다는 이유만으로 모델을 교체해서는 안 되며, 희귀 클래스 성능, 실행 시간, 메모리 사용량, 신뢰도 보정, 실제 운용 안정성, 미션 성능도 함께 비교해야 한다. 새로운 장점이 새로운 위험보다 충분히 커야 한다.

회귀 시험(Regression Testing)은 이전 버전에서 발생했던 현장 오류, 사고 직전 상황(Near Miss), 고객 사례, 어려운 테스트 사례를 지속적으로 유지해야 한다. 새로운 모델은 이러한 회귀 시험을 먼저 통과해야 하며, 새 데이터에서 좋은 성능을 보이더라도 기존 문제를 다시 발생시킨다면 모델 변경은 승인되어서는 안 된다. 회귀 시험은 모델 입력뿐 아니라 폐루프 시나리오도 포함해야 하며, 시험 내용은 신중하게 관리되어야 한다.

가능한 경우에는 그림자 모드(Shadow Mode)를 활용한 검증도 수행해야 한다. 새로운 모델은 실제 로봇에서 실행되지만 로봇을 직접 제어하지 않고 출력만 기록하여 현재 운영 모델과 비교한다. 이를 통해 실제 환경 데이터를 사용하면서도 위험을 최소화할 수 있다. 그림자 시험은 도메인 변화, 실행 시간 문제, 오경보, 새로운 객체 분포를 발견하는 데 도움이 되지만, 로봇 움직임에 직접 영향을 주지 않기 때문에 폐루프 성능을 완전히 검증할 수는 없다.

단계적 배포(Staged Deployment)는 실험실과 현장 검증 이후의 위험을 줄이는 방법이다. 새로운 모델은 내부 로봇, 소규모 시험 플릿(Pilot Fleet), 제한된 고객 현장, 전체 플릿 순으로 확대 적용할 수 있다. 초기 단계에서는 속도, 미션 종류, 운용 환경, 운용 시간을 제한하는 것이 일반적이다. 운영 중에는 기존 모델과 새로운 모델을 비교하면서 오류 지표, 개입 횟수, 신뢰도, 실행 시간, 미션 성공률을 지속적으로 모니터링해야 하며, 사전에 정의된 롤백(Rollback) 기준도 준비되어 있어야 한다.

실행 중 모니터링(Runtime Monitoring)은 데이터 변화(Data Drift), 성능 변화, 시스템 자원 문제, 비정상적인 신뢰도 패턴을 탐지해야 한다. 실제 현장에서는 즉시 정답 데이터를 얻기 어려우므로 센서 통계, 클래스 빈도, 임베딩 거리(Embedding Distance), 신뢰도 분포, 센서 간 불일치, 사람의 개입, 안전 정지, 운용자 보고 등을 활용할 수 있다. 이러한 정보는 공식 검증을 대신하지는 않지만, 기존 가정이 더 이상 유효하지 않을 가능성을 알려준다. 중요한 변화가 감지되면 추가 데이터 수집, 원인 분석, 운용 제한 또는 롤백을 수행해야 한다.

AI 모델 검증은 엄격한 형상 관리(Configuration Management)와 버전 관리(Version Management)가 필수적이다. 학습 코드, 데이터셋 버전, 라벨 정의, 모델 구조, 가중치(Weight), 하이퍼파라미터(Hyperparameter), 전처리, 후처리, 실행 엔진(Runtime Engine), 보정 데이터, 임계값, 하드웨어 플랫폼, 시험 스크립트를 모두 기록해야 한다. 출시 모델은 고유한 식별자(Identifier)와 필요에 따라 암호학적 무결성(Cryptographic Integrity)을 가져야 한다. 동일한 실행 환경을 재현할 수 없다면 시험 결과는 의미가 없다.

검증 보고서(Validation Report)는 모델의 사용 목적(Intended Use), 사용 제한(Prohibited Use), 데이터 범위, 시험 방법, 성능 지표, 하위 그룹 분석, 강건성 시험, 실행 시간, 하드웨어 성능, 알려진 한계(Known Limitation), 잔여 위험, 필요한 안전 대응(Fallback Behavior)을 포함해야 한다. 성공 사례뿐 아니라 실패와 판정 불가 결과도 함께 기록해야 하며, 검토자는 모델이 어디에서 잘 동작하고 어디에서 근거가 부족한지를 명확히 이해할 수 있어야 한다. 또한 운용 환경이나 시스템 인터페이스가 변경되면 모델 문서도 함께 업데이트해야 한다.

출시 승인(Release Approval)은 AI 개발자뿐 아니라 로봇 소프트웨어, 시스템 엔지니어링(System Engineering), 안전(Safety), 시험(Test), 운영(Operation), 제품 관리(Product Management) 담당자가 함께 수행해야 한다. AI 개발자는 모델의 동작을 설명할 수 있지만, 시스템 전문가는 그 오류가 실제 주행, 미션 수행, 사람과의 상호작용에 어떤 영향을 미치는지를 평가해야 한다. 특히 데이터 수집, 모델 학습, 허용 기준을 모두 동일한 팀이 수행한 경우에는 독립적인 검토가 매우 중요하다. 최종 승인은 모델이 모든 환경에서 완벽하다는 의미가 아니라, 정의된 운용 설계 영역에서 충분한 검증 근거를 확보했다는 것을 의미한다.

성숙한 AI 모델 검증(AI Model Validation) 프로세스는 대표성 있는 데이터, 보호된 시험 데이터셋, 하위 그룹 분석(Subgroup Analysis), 신뢰도 보정(Calibrated Confidence), 강건성 시험, 도메인 변화 평가(Domain Shift Evaluation), 실시간 하드웨어 성능 측정, 폐루프 시나리오(Closed-Loop Scenario), 회귀 시험(Regression Suite), 단계적 배포(Staged Deployment), 지속적인 모니터링(Continuous Monitoring)을 하나의 체계로 통합한다. 단순한 정확도만으로는 로봇의 안전성과 실용성을 보장할 수 없으며, 시스템 엔지니어링과 현장 피드백을 함께 반영할 때 AI 모델은 추적 가능하고 정량적으로 검증되며 신뢰할 수 있는 AMR 구성 요소로 유지될 수 있다.

12.06 Safety and Reliability Testing

안전성 및 신뢰성 시험(Safety and Reliability Testing)은 자율이동로봇(Autonomous Mobile Robot, AMR)이 의도된 임무를 수행하는 과정에서 허용할 수 없는 위험을 발생시키지 않으며, 요구되는 서비스 수명(Service Life) 동안 예측 가능한 성능을 지속적으로 유지할 수 있는지를 검증하는 과정이다. 안전성 시험(Safety Testing)은 사람, 재산, 인프라(Infrastructure), 적재물(Payload), 환경에 대한 피해를 방지하는 데 초점을 둔다. 신뢰성 시험(Reliability Testing)은 정의된 조건에서 일정 기간 동안 로봇과 하위 시스템이 요구된 기능을 수행할 확률을 평가하는 데 초점을 둔다. 두 영역은 밀접하게 연결되어 있으며, 반복적인 고장, 성능이 저하된 부품, 잘못된 유지보수는 결국 안전 문제로 이어질 수 있다.

시험 전략(Test Strategy)은 로봇의 의도된 사용 목적(Intended Use), 운용 환경(Operating Environment), 미션 프로파일(Mission Profile), 적재 범위(Payload Range), 속도 제한(Speed Limit), 사람과의 상호작용(Human Interaction), 인프라 인터페이스(Infrastructure Interface), 기대 수명(Expected Lifetime)을 명확히 정의하는 것에서 시작해야 한다. 이러한 조건은 운용 설계 영역(Operational Design Domain, ODD)을 구성하며, 어떤 위험 요소와 고장 메커니즘을 고려해야 하는지를 결정한다. 창고 운반 로봇, 실외 검사 로봇, 대형 견인 AMR은 서로 다른 안전 요구사항과 신뢰성 목표를 가진다. 따라서 검증 결과는 반드시 명확하게 정의된 적용 분야와 시스템 구성(Configuration)에 연결되어야 의미를 가진다.

위험 분석(Hazard Analysis)은 안전성 시험의 기반이 된다. 위험 및 리스크 평가(Hazard and Risk Assessment), 고장 형태 및 영향 분석(Failure Mode and Effects Analysis, FMEA), 고장수 분석(Fault Tree Analysis, FTA), 작업 기반 위험 분석(Task-Based Risk Analysis)과 같은 기법을 이용하여 부상, 충돌(Collision), 협착(Crushing), 끼임(Entrapment), 전도(Tipping), 감전(Electrical Shock), 화재(Fire), 의도하지 않은 이동(Unintended Motion), 미션 실패(Mission Loss)를 유발할 수 있는 상황을 식별해야 한다. 각 위험 요소는 본질적 안전 설계(Inherently Safe Design), 보호 장치, 안전 제어 기능(Safety Control Function), 운용 제한, 경고 시스템, 유지보수 절차, 운용자 교육과 같은 위험 저감 대책(Risk Reduction Measure)과 연결되어야 하며, 시험은 이러한 대책이 의도대로 동작하는지를 확인해야 한다.

안전 요구사항(Safety Requirement)은 반드시 측정 가능하고 추적 가능해야 한다. 하나의 요구사항은 시험 조건, 기대되는 시스템 반응, 허용 응답 시간, 허용 오차, 최종 안전 상태(Safe State)를 명확하게 정의해야 한다. 예를 들어 보호 정지(Protective Stop)는 장애물 탐지 조건, 로봇 속도, 최대 응답 시간, 제동 동작, 최종 안전 거리까지 포함해야 한다. 단순히 "로봇은 안전하게 정지해야 한다"와 같은 표현은 측정 기준이 없으므로 적절한 요구사항이 아니다. 모든 중요한 안전 요구사항은 하나 이상의 검증 절차와 시험 결과에 연결되어야 한다.

계층형 안전 구조(Layered Safety Architecture)는 각각의 보호 장치를 개별적으로 시험하는 것이 아니라 전체 시스템으로 통합하여 검증해야 한다. 일반적으로 기계적 보호(Mechanical Protection), 센서(Sensor), 안전 제어기(Safety Controller), 속도 제한(Motion Limitation), 제동(Braking), 비상 정지(Emergency Stop), 소프트웨어 감시(Software Supervision), 통신 감시(Communication Monitoring), 운용자 인터페이스, 운용 절차가 함께 구성된다. 하나의 보호 계층이 실패하더라도 다른 계층이 위험을 줄이거나 시스템을 안전 상태로 전환해야 한다. 시험은 정상적인 협조 동작뿐 아니라 특정 보호 계층이 고장 난 경우의 시스템 동작도 함께 확인해야 한다.

비상 정지 시험(Emergency-Stop Testing)은 비상 정지 장치가 요구된 시간과 거리 안에서 위험한 움직임을 제거하거나 제어할 수 있는지를 검증한다. 모든 비상 정지 버튼, 원격 제어기, 안전 범퍼(Safety Bumper), 외부 인터페이스, 운용자 제어 장치를 시험해야 한다. 시험은 다양한 속도, 주행 방향, 적재량, 경사, 배터리 상태, 노면 조건에서 수행되어야 한다. 또한 비상 정지를 해제했다고 해서 로봇이 자동으로 다시 움직여서는 안 되며, 모든 안전 조건이 만족된 이후에 운용자의 명시적인 재시작 명령이 있어야 한다.

보호 정지 시험(Protective-Stop Testing)은 안전 스캐너(Safety Scanner), 범퍼(Bumper), 에지 센서(Edge Sensor), 충돌 감지기(Collision Detector), 외부 안전 시스템에 의해 자동으로 발생하는 정지 기능을 검증한다. 장애물 위치, 접근 각도, 물체 크기, 반사율, 이동 속도, 센서 커버리지를 다양하게 변경하여 시험해야 한다. 로봇은 지정된 거리 안에서 위험을 탐지하고, 불안정하거나 위험한 접촉 없이 제어된 방식으로 정지해야 한다. 보호 정지는 빠른 재시작을 위해 전원을 유지할 수 있지만, 보호 구역이 안전하게 확보되고 재시작 조건이 만족될 때까지 움직임은 허용되어서는 안 된다.

안전 속도 및 분리 감시(Safe Speed and Separation Monitoring)는 로봇의 전체 운동 범위(Motion Envelope)에 대해 검증되어야 한다. 로봇은 고정 속도 구역, 동적 보호 구역(Dynamic Protective Field), 사람과의 거리 추정, 인프라 명령을 이용하여 속도를 제한할 수 있다. 시험은 목표 속도(Commanded Speed)와 실제 속도(Actual Speed)가 허용 범위 내에 있는지, 그리고 속도 변화에 따라 보호 영역이 올바르게 변경되는지를 확인해야 한다. 속도 감소가 늦거나 진행 방향을 잘못 판단하거나 안전 스캐너 구성이 잘못된 경우에는 실제 제동 거리가 부족해질 수 있으므로 반드시 검증해야 한다.

제동 성능 시험(Braking Performance Testing)은 가장 불리한 승인 조건에서 수행되어야 한다. 최대 적재량, 최고 속도, 저전압 배터리, 고온 및 저온 브레이크, 젖은 바닥, 저마찰 노면, 경사로, 마모된 바퀴, 비상 정지 명령 등을 포함해야 한다. 정지 시간과 정지 거리는 반복 측정을 통해 평가해야 하며, 단순한 설계 계산만으로 판단해서는 안 된다. 또한 방향 안정성, 바퀴 잠김(Wheel Lock), 미끄러짐(Skidding), 경사에서의 후진(Rollback), 정지 후 위치 유지 능력도 함께 확인해야 한다.

조향 및 구동 안전 시험(Steering and Drive Safety Testing)은 조향 명령, 피드백, 액추에이터가 비정상일 때에도 로봇이 제어 상태를 유지하는지를 검증한다. 조향각 오류, 모터 토크 불균형, 엔코더 손실, 과전류, 휠 슬립, 고정된 제어 명령, 통신 중단 등이 대표적인 시험 항목이다. 로봇은 이러한 이상 상태를 감지하고 제어되지 않는 회전, 편향 이동, 급가속을 방지해야 한다. 특히 대형 또는 고속 AMR은 하나의 구동 장치 고장만으로 안전 기능이 상실되지 않도록 독립 제동이나 이중 안전 감시가 필요할 수 있다.

충돌 및 접촉 시험(Collision and Contact Testing)은 충돌 회피뿐 아니라 충돌 에너지 제한(Energy Limitation)도 함께 검증해야 한다. 접촉이 허용되지 않는 경우에는 사람이나 보호 대상에 도달하기 전에 정지하거나 경로를 변경해야 한다. 제한적인 접촉이 허용되는 경우에는 힘(Force), 압력(Pressure), 속도, 충돌 에너지가 허용 기준 이내에 있어야 한다. 시험에는 계측 장비가 장착된 더미(Dummy), 힘 센서, 연성 목표물을 사용해야 하며 실제 사람을 불필요한 위험에 노출해서는 안 된다. 또한 범퍼, 모서리, 돌출부, 적재물 가장자리와 같이 실제 충돌 형상을 변화시키는 요소도 모두 포함해야 한다.

협착 및 끼임 위험(Crushing and Trapping Hazard)은 저속 로봇이라도 큰 힘을 발생시킬 수 있기 때문에 특별한 주의가 필요하다. 벽, 랙(Rack), 문, 도킹 스테이션, 엘리베이터, 컨베이어, 작업 셀, 좁은 통로에서 사람이 끼일 수 있는 상황을 검증해야 한다. 로봇은 충분한 안전 간격을 유지하거나 사람의 접근을 감지하고 움직임을 제한하거나 위험한 압착이 발생하기 전에 정지해야 한다. 적재물이나 부착 장치가 변경되면 새로운 협착 지점이 생길 수 있으므로 다시 평가해야 한다.

안정성 시험(Stability Testing)은 정상 및 예상 가능한 이상 상황에서 로봇이 전도(Tipping), 전복(Rolling), 미끄러짐(Sliding), 제어 상실을 일으키지 않는지를 검증한다. 적재 질량, 무게 중심, 가속, 회전 속도, 경사, 횡경사, 노면 변화, 바퀴 낙하, 제동, 바람, 매니퓰레이터(Manipulator)의 움직임 등을 고려해야 한다. 동적 시험은 이러한 요소가 동시에 작용하는 상황을 포함해야 하며, 제조 오차, 적재 오차, 타이어 상태, 실제 주행 경로 편차까지 고려한 충분한 안전 여유를 확보해야 한다.

적재물 안전 시험(Payload Safety Testing)은 적재물의 고정, 감지, 유지, 전달, 고장 대응을 검증한다. 적재물이 제대로 고정되지 않았거나 허용 범위를 벗어나거나 위험한 위치에 있는 경우에는 로봇이 이동해서는 안 된다. 리프트 테이블, 컨베이어, 로봇 암, 트레일러, 특수 장비는 새로운 위험 요소를 만들 수 있으므로 전체 시스템 시험에 포함되어야 한다. 인터록(Interlock)은 정상 작업뿐 아니라 작업 중단, 통신 손실, 비상 정지, 전원 복구 상황에서도 검증해야 하며, 위험성이 큰 경우에는 적재물 식별 결과를 독립적인 방법으로 확인해야 한다.

전기 안전 시험(Electrical Safety Testing)은 절연(Insulation), 접지(Grounding), 본딩(Bonding), 과전류 보호, 커넥터 무결성, 배터리 절연, 충전 회로, 사용자가 접근 가능한 전압을 평가해야 한다. 절연 저항, 내전압 시험(Dielectric Withstand), 누설 전류, 극성, 단락 보호, 접지 연속성 등을 포함할 수 있다. 실제 생산 배선과 커넥터, 인클로저(Enclosure), 설치 방법을 사용해야 하며, 임시 실험실 배선은 진동, 습기, 조립 문제를 숨길 수 있으므로 최종 제품을 대표할 수 없다.

배터리 안전 시험(Battery Safety Testing)은 정상 운용, 충전, 과전류, 과온도, 저전압, 셀 불균형(Cell Imbalance), 통신 손실, 접촉기 고장, 비정상 종료를 포함해야 한다. 배터리 관리 시스템(Battery Management System, BMS)은 위험한 상태를 탐지하고 필요할 경우 배터리를 안전하게 차단해야 한다. 온도 센서, 퓨즈(Fuse), 접촉기, 서비스 분리 장치(Service Disconnect), 화재 완화 기능도 개별적으로 그리고 통합적으로 검증해야 한다. 또한 에너지가 부족한 경우 로봇이 적절한 미션 상태로 전환하며 위험한 장소에서 갑자기 정지하지 않는지도 확인해야 한다.

충전 안전 시험(Charging Safety Testing)은 접근, 정렬, 연결, 충전 승인, 전원 인가, 에너지 전달, 분리, 출발 과정을 모두 검증해야 한다. 충전 중에는 노출된 전원 단자, 불완전한 접촉, 아크(Arc), 과열, 역극성, 연결 상태에서의 이동을 방지해야 한다. 위치 오차, 오염, 물기, 손상된 커넥터, 통신 장애, 충전 중단도 시험에 포함해야 한다. 또한 로봇은 단순한 기계적 연결과 실제 에너지 전달을 구분해야 하며, 반복 실패 시에는 운용자에게 도움을 요청해야 한다.

열 시험(Thermal Testing)은 전자 장치, 배터리, 모터, 브레이크, 컴퓨팅 장치가 허용 온도 범위 안에서 동작하는지를 검증한다. 최대 연산 부하, 높은 주변 온도, 낮은 공기 흐름, 반복 가속, 경사 주행, 충전, 장시간 운용을 포함해야 한다. 열 포화(Thermal Soak) 시험은 짧은 시험으로는 발견되지 않는 장기적인 열 축적을 확인할 수 있다. 온도가 허용 범위를 초과하기 전에 로봇은 성능을 제한하거나 충전을 제한하거나 안전하게 정지해야 한다.

환경 안전 및 신뢰성 시험(Environmental Safety and Reliability Testing)은 먼지, 물, 습도, 결로, 온도 사이클, 부식, 자외선, 화학물질, 세척 환경 등을 실제 사용 조건에 맞게 재현해야 한다. 보호 등급(IP Rating)과 커넥터 사양은 실제 실링(Seal), 케이블 글랜드(Cable Gland), 체결 방식, 설치 방향을 포함한 최종 제품에서만 유효하다. 따라서 실제 생산품으로 시험해야 하며, 작은 배선 변경이나 실링 차이도 보호 성능을 크게 변화시킬 수 있다.

진동 및 충격 시험(Vibration and Shock Testing)은 운송, 거친 노면, 연석 통과, 충격, 적재물 이동, 장기 운용에서 시스템이 견딜 수 있는지를 검증한다. 짧은 벤치 시험에서는 정상 동작하던 부품도 반복 진동 후에는 풀리거나 균열이 생기거나 연결이 끊어질 수 있다. 커넥터, 회로기판, 센서, 배터리, 구조물, 케이블 지지대, 체결부, 교정 안정성을 모두 평가해야 하며, 시험 중과 시험 후 기능을 함께 확인해야 한다.

구조 신뢰성 시험(Structural Reliability Testing)은 차체, 프레임, 커버, 장착부, 인양부, 견인부, 적재 인터페이스, 보호 구조가 요구 하중을 충분한 여유를 가지고 견디는지를 검증한다. 정적 하중, 반복 하중, 충격 하중, 비틀림(Torsion), 피로(Fatigue)를 포함할 수 있다. 구조 변형은 센서, 바퀴, 문, 커넥터, 안전 거리 확보에 영향을 주어서는 안 되며, 시험 후에는 균열, 영구 변형, 느슨한 체결부를 반드시 점검해야 한다.

신뢰성 목표(Reliability Target)는 제품 특성과 사업 모델에 맞는 지표로 정의되어야 한다. 미션 성공 확률(Mission Completion Probability), 평균 고장 간격(Mean Time Between Failures, MTBF), 평균 수리 시간(Mean Time To Repair, MTTR), 가용성(Availability), 개입 빈도, 부품 수명, 충전 성공률, 허용 다운타임 등을 사용할 수 있다. "높은 신뢰성"과 같은 표현은 시험 가능한 목표가 아니며, 운용 시간, 주행 거리, 시작과 정지 횟수, 회전, 도킹, 충전, 적재, 환경 조건을 포함한 미션 프로파일이 함께 정의되어야 한다.

신뢰성 입증 시험(Reliability Demonstration Testing)은 반복 운용을 통해 통계적으로 목표 신뢰성을 만족하는지를 확인하는 시험이다. 필요한 시험 시간은 목표 신뢰성, 고장 분포, 시험 대상 수, 허용 고장 수에 따라 달라진다. 하나의 시제품이 몇 시간 동안 정상 동작했다고 해서 플릿(Fleet) 전체의 신뢰성을 입증할 수는 없다. 시험 계획은 운용 시간, 주행 거리, 사이클 수, 고장 계산 방법을 명확히 정의해야 하며, 중단된 시험이나 수리된 장비도 일관된 기준으로 관리해야 한다.

가속 수명 시험(Accelerated Life Testing)은 높은 온도, 진동, 하중, 반복 속도, 습도, 전기적 스트레스를 이용하여 실제 운용 중 발생할 수 있는 고장 메커니즘을 단기간에 확인하는 방법이다. 목적은 단순히 제품을 파괴하는 것이 아니라 실제 서비스 환경에서 나타날 약점을 조기에 발견하는 것이다. 지나치게 높은 스트레스는 현실에서는 발생하지 않는 인위적인 고장을 만들 수 있으므로, 실제 환경과의 상관관계 및 물리적 고장 분석이 반드시 필요하다.

고가속 시험(Highly Accelerated Testing)은 개발 초기 단계에서 설계 여유와 취약 부품을 찾기 위해 사용된다. 급격한 온도 변화, 다축 진동, 전압 변화, 반복 전원 사이클을 통해 간헐적인 접촉 불량, 납땜 불량, 냉각 부족, 소프트웨어 재시작 문제, 구조 공진 등을 발견할 수 있다. 이러한 시험은 설계 개선에는 매우 유용하지만 공식적인 수명 입증 시험과 동일하게 해석해서는 안 되며, 스트레스 수준과 실제 고장 메커니즘을 함께 고려해야 한다.

미션 사이클 시험(Mission-Cycle Testing)은 각 하위 시스템을 따로 시험하는 것이 아니라 실제 운용 순서를 그대로 재현해야 한다. 기동, 가속, 주행, 회전, 장애물 정지, 도킹, 적재 작업, 충전, 통신 장애, 종료를 하나의 반복 사이클로 구성해야 한다. 이렇게 하면 열 부하, 배터리 상태, 소프트웨어 자원, 기계 마모, 통신의 상호작용을 확인할 수 있다. 일정한 속도의 단순 주행만 반복해서는 실제 신뢰성을 올바르게 평가할 수 없다.

장시간 자율 운용 시험(Long-Duration Autonomous Testing)은 메모리 누수(Memory Leak), 데이터 축적, 위치추정 드리프트, 타임스탬프 오류, 열 포화, 네트워크 성능 저하, 센서 오염과 같은 장기 문제를 발견하는 데 목적이 있다. 로봇은 최소한의 사람 개입으로 실제 미션을 반복 수행해야 하며, 자동 시험 시스템은 모든 재시작, 일시정지, 재시도, 경로 실패, 오탐지, 충전 실패, 운용자 개입을 기록해야 한다. 작은 개입이 반복되는 현상도 신뢰성 저하의 중요한 지표가 될 수 있다.

고장 주입 시험(Fault Injection Testing)은 시스템이 고장을 정확히 탐지하고 정의된 안전 상태 또는 성능 저하 상태로 전환하는지를 검증한다. 센서 손실, 비정상 데이터, 통신 지연, Bus-Off, 프로세서 재시작, 설정 오류, 액추에이터 피드백 불일치, 저전압, 과열 경고, 안전 채널 불일치 등을 인위적으로 발생시킬 수 있다. 모든 고장은 발생 시점, 탐지 시간, 진단 코드, 운용자 메시지, 움직임 반응, 복구 절차가 미리 정의되어 있어야 한다.

단일 고장 시험(Single-Fault Testing)은 하나의 고장이 허용할 수 없는 위험을 만들지 않는지를 확인하며, 복합 고장 시험(Multiple-Fault Testing)은 여러 조건이 동시에 발생하는 경우를 평가한다. 예를 들어 센서가 가려진 상태에서 네트워크도 불안정하거나, 최대 적재량 상태에서 브레이크 이상과 젖은 경사로가 동시에 발생하는 상황을 시험할 수 있다. 모든 조합을 시험하는 것은 불가능하므로 위험 분석을 통해 중요한 조합을 선정해야 하며, 전원, 통신, 냉각, 소프트웨어를 공유하는 요소는 독립성 가정을 다시 검토해야 한다.

이중화 시험(Redundancy Testing)은 단순히 동일한 부품이 두 개 존재하는지를 확인하는 것이 아니라 고장 탐지, 격리, 자동 전환, 성능 저하 운용, 진단 범위, 공통 원인(Common Cause)에 대한 저항성을 검증해야 한다. 동일한 전원, 커넥터, 드라이버, 설치 위치를 공유하는 센서는 동시에 고장 날 수 있다. 따라서 이중화된 조향, 제동, 통신, 위치추정 기능은 각 채널을 개별적으로 비활성화하면서 나머지 시스템이 안전 기능을 유지하는지를 확인해야 한다.

페일세이프 동작(Fail-Safe Behavior)은 고장이 발생했을 때 위험을 줄이는 상태로 시스템이 전환되는 것을 의미한다. 이는 정지, 속도 제한, 페이로드 비활성화, 안전 지역 복귀, 현재 위치 유지 등이 될 수 있다. 어떤 상태가 가장 안전한지는 상황에 따라 다르다. 교차로나 철도 건널목에서 즉시 정지하는 것이 오히려 더 위험할 수도 있다. 따라서 시험은 상황에 맞는 안전 동작이 수행되는지와 동시에 미션보다 안전이 항상 우선되는지를 확인해야 한다.

점진적 성능 저하(Graceful Degradation)는 모든 기능을 사용할 수 없더라도 제한된 운용을 지속하는 기능이다. 예를 들어 하나의 센서가 고장 난 경우 속도를 줄이거나, 위치추정 품질이 떨어질 경우 제한된 경로만 사용하거나, 중요하지 않은 페이로드 고장 후에는 안전한 복귀 미션만 수행할 수 있다. 이러한 성능 저하 모드는 명확하게 정의되어야 하며, 자동으로 진입하고 운용자에게 표시되며 승인된 범위를 넘어서 사용되지 않도록 검증해야 한다. 정상 상태로 복귀하기 위해서는 실제 고장이 제거되었다는 근거가 필요하다.

진단 시험(Diagnostic Testing)은 시스템이 고장을 정확하게 식별하고 운용자에게 유용한 정보를 제공하는지를 검증한다. 센서 가림, 센서 분리, 교정 오류, 통신 시간 초과, 과열, 내부 오류를 가능한 한 구분해야 한다. 진단 코드(Diagnostic Trouble Code), 로그(Log), 표시 장치, 원격 경보, 유지보수 메시지는 일관성을 유지해야 한다. 불명확한 오류 메시지는 다운타임을 증가시키고 잘못된 정비를 유도할 수 있으므로 오탐지와 미탐지도 함께 평가해야 한다.

복구 가능성 시험(Recoverability Testing)은 재시작, 재부팅, 전원 복구, 통신 복구, 미션 재개, 수동 복구, 견인(Towing), 정비 절차를 검증한다. 로봇은 이미 완료된 작업을 반복하지 않으면서 중요한 상태 정보를 유지해야 하며, 적재물도 안전하게 관리해야 한다. 복구 절차는 개발자가 아닌 일반 정비 인력이 수행하여 실제로 이해하기 쉽고 적용 가능한지를 확인해야 한다. 수동 브레이크 해제, 인양, 견인 과정에서도 기술자가 위험에 노출되어서는 안 된다.

유지보수성(Maintainability)은 실제 운용 신뢰성에 큰 영향을 준다. 정비가 어렵거나 오래 걸리면 다운타임이 증가하고 잘못된 수리가 발생할 가능성도 커진다. 시험에서는 접근 시간, 진단 시간, 부품 교체 시간, 교정 시간, 정상 복구 시간을 측정해야 한다. 커넥터, 커버, 필터, 바퀴, 센서, 배터리, 제어기는 주변 부품을 손상시키지 않고 교체할 수 있어야 하며, 정비 후에는 실링, 접지, 케이블 배선, 교정, 안전 설정이 모두 원래 상태로 복원되어야 한다.

예방 유지보수(Preventive Maintenance) 주기는 시험 데이터, 마모 측정, 부품 제조사 기준, 실제 운용 경험을 기반으로 결정해야 한다. 타이어, 브레이크, 베어링, 실링, 냉각 팬, 커넥터, 배터리, 리프트 장치는 서로 다른 속도로 열화된다. 신뢰성 시험은 온도, 진동, 전류, 저항, 압력, 백래시(Backlash), 치수 변화를 지속적으로 모니터링해야 하며, 위험 수준에 도달하기 전에 유지보수를 수행해야 한다. 반대로 불필요한 부품 교체도 새로운 고장을 만들 수 있으므로 피해야 한다.

소프트웨어 신뢰성 시험(Software Reliability Testing)은 반복 실행, 예외 처리, 프로세스 복구, 자원 고갈, 업데이트, 설정 로딩, 데이터 무결성을 평가해야 한다. 장시간 시험에서는 메모리 증가, 파일 시스템 한계, 로그 과부하, 경쟁 상태(Race Condition), 교착 상태(Deadlock)를 발견할 수 있다. 워치독(Watchdog)은 실패한 프로세스를 탐지해야 하지만 반복적인 재부팅 루프를 만들면 안 된다. 예방할 수 없는 소프트웨어 오류는 움직임과 안전 기능에 영향을 주지 않도록 격리되어야 하며, 안전 기능은 복잡한 일반 소프트웨어만을 신뢰해서는 안 된다.

통신 신뢰성 시험(Communication Reliability Testing)은 대역폭 제한, 지연(Latency), 지터(Jitter), 패킷 손실(Packet Loss), 네트워크 핸드오버, 서버 장애, 중복 메시지, 오래된 명령, 재연결을 포함해야 한다. 플릿이나 클라우드 서비스가 중단되어도 로봇은 자체적인 안전 기능을 유지해야 하며, 복구 후에도 미션과 상태가 중복되지 않도록 동기화해야 한다. 통신이 안전 기능에 직접 영향을 주는 경우에는 구조, 진단, 타임아웃, 장애 대응을 위험 수준에 맞게 검증해야 한다.

사이버보안 시험(Cybersecurity Testing)은 무단 접근이나 데이터 변조, 악의적인 제어가 위험한 움직임이나 장시간 다운타임을 유발할 수 있기 때문에 안전성과 신뢰성에도 중요한 요소이다. 인증(Authentication), 권한 관리(Authorization), 보안 부팅(Secure Boot), 소프트웨어 무결성, 암호화 통신, 네트워크 분리(Network Segmentation), 업데이트 보호, 계정 관리, 이벤트 로그를 검증해야 한다. 허가되지 않은 명령이나 소프트웨어 교체, 메시지 재생(Replay Attack), 안전 파라미터 변경은 반드시 차단되어야 하며, 정당한 비상 조치와 유지보수는 방해하지 않아야 한다.

생산 일관성(Production Consistency)도 안전성과 신뢰성 프로그램의 일부로 관리되어야 한다. 시제품은 시험을 통과했더라도 양산품은 조립 편차, 공급업체 변경, 체결 토크, 실링 손상, 배선, 교정, 소프트웨어 설치 오류 때문에 동일한 성능을 보장하지 못할 수 있다. 생산 종료 시험(End-of-Line Test)은 중요한 안전 기능, 전기적 무결성, 통신, 제동, 조향, 센서, 비상 정지, 설정 정보를 확인해야 한다. 모든 제품을 검사할 수 없는 항목은 샘플링과 공정 감사(Process Audit)를 통해 관리해야 한다.

변경 영향 시험(Change Impact Testing)은 하드웨어, 소프트웨어, 센서, 적재물, 공급업체, 재료, 지도, 안전 파라미터, 생산 공정이 변경될 때 반드시 수행해야 한다. 작은 변경도 제동 거리, 열 성능, 전자파 특성, 타이밍, 교정, 고장 반응을 바꿀 수 있다. 따라서 기존 시험 결과 중 어떤 것이 계속 유효한지, 어떤 시험을 다시 수행해야 하는지를 명확히 판단해야 한다. 과거 시험 결과를 무분별하게 재사용해서는 안 된다.

현장 신뢰성 향상(Field Reliability Growth)은 실제 운용에서 발생한 고장을 체계적으로 수집하고 분석하는 과정에 달려 있다. 플릿 로그, 유지보수 기록, 고객 보고, 교체 부품, 운용자 개입, 사고 직전 상황(Near Miss)을 로봇 구성과 운용 조건에 연결해야 한다. 또한 단순히 고장 난 부품이 아니라 실제 물리적 또는 논리적 근본 원인(Root Cause)을 찾아야 하며, 수정 사항은 통제된 시험과 실제 운용에서 다시 검증하여 고장률이 실제로 감소하는지를 확인해야 한다.

신뢰성 향상 시험(Reliability Growth Testing)은 시험, 고장 발견, 원인 분석, 수정, 재시험을 반복하는 과정이다. 초기에는 설계 약점이 많이 발견되며, 시간이 지나면 마모나 드문 조합의 문제가 나타난다. 모든 진행 상황은 동일한 정의와 운용 데이터를 기준으로 비교해야 한다. 단순히 고장 부품을 교체하는 것만으로는 신뢰성이 향상되지 않으며, 중요한 고장은 설계 개선, 공급업체 관리, 소프트웨어 수정, 유지보수 정책, 모니터링, 운용 제한과 연결되어야 한다.

시험 데이터(Test Data)는 안전 신호, 제어 명령, 센서 입력, 액추에이터 피드백, 네트워크, 전원, 온도, 외부 관찰 정보를 모두 시간 동기화(Time Synchronization)하여 저장해야 한다. 정지 응답, 접촉기 동작 시간, 안전 채널 차이, 간헐적 통신 장애를 분석하기 위해서는 고속 기록이 필요할 수도 있다. 시험 보고서는 로봇 ID, 하드웨어 버전, 소프트웨어 버전, 교정 정보, 적재물, 노면, 환경 조건, 계측 장비를 포함해야 하며, 이러한 정보 없이 단순히 합격 또는 실패만 기록해서는 충분한 근거가 되지 않는다.

합격 기준(Acceptance Criteria)은 측정 불확도(Measurement Uncertainty)와 반복 시험에 따른 변동성까지 고려해야 한다. 정지 거리, 응답 시간, 충돌 힘, 온도, 미션 성공률, 신뢰성 지표는 자연스럽게 변동한다. 기준값에 매우 근접한 결과는 생산 편차와 측정 오차를 고려할 때 충분한 안전 여유를 제공하지 못할 수 있다. 따라서 통계 분석을 통해 무작위 오차, 체계적 오차, 이상값을 구분해야 하며, 평균값보다 최악 조건과 고장 분포가 더 중요한 경우가 많다.

독립적인 검토(Independent Review)는 안전성과 신뢰성 검증 결과의 신뢰도를 높인다. 개발자는 시스템을 가장 잘 이해하지만 일정이나 기존 가정의 영향을 받을 수도 있다. 시험 절차, 위험 분석 범위, 계측, 절차 변경, 고장, 결론은 설계에 직접 참여하지 않은 전문가가 검토해야 한다. 제품이나 적용 분야에 따라 외부 인증(Certification)이 필요할 수도 있으며, 검토의 목적은 단순한 문서 확인이 아니라 실제 검증 근거를 확인하는 것이다.

출시 결정(Release Decision)은 남아 있는 위험 요소, 시험 범위, 신뢰성 수준, 알려진 제한 사항, 유지보수 준비 상태, 진단 기능, 예비 부품, 교육, 운용 절차를 함께 고려해야 한다. 많은 시험을 통과했다고 해서 하나의 심각한 위험을 무시할 수는 없다. 속도, 경로, 적재량, 운용 환경, 감독 수준, 운용 시간을 제한하는 조건부 운용은 허용될 수 있지만, 이러한 제한은 실제로 적용 가능하고 명확하게 전달되어야 한다. 잔여 위험과 제한 사항은 운용자, 고객, 유지보수 담당자, 플릿 관리 시스템 모두에게 공유되어야 한다.

성숙한 안전성 및 신뢰성 시험(Safety and Reliability Testing)은 제품 출시 이후에도 계속되어야 한다. 실제 운용에서는 비정상적인 정지 횟수, 온도 상승, 반복 재시작, 센서 성능 저하, 충전 실패, 브레이크 마모, 통신 장애, 사람의 개입 증가를 지속적으로 모니터링해야 한다. 이러한 정보는 위험한 고장이 발생하기 전에 시스템 열화를 발견할 수 있게 해준다. 또한 실제 운용 결과는 위험 분석, 유지보수 주기, 시험 시나리오, 설계 요구사항, 회귀 시험을 지속적으로 개선하는 데 활용되어야 한다.

효과적인 안전성 및 신뢰성 시험은 위험 기반 검증(Hazard-Based Verification), 기능 안전 시험(Functional Safety Testing), 기계 및 전기 평가(Mechanical and Electrical Evaluation), 환경 내구성(Environmental Durability), 고장 주입(Fault Injection), 신뢰성 입증(Reliability Demonstration), 유지보수성(Maintainability), 생산 품질 관리(Production Control), 현장 피드백(Field Feedback)을 하나의 통합된 체계로 운영한다. 이를 통해 AMR은 위험한 동작을 예방하거나 제어하고, 예상 가능한 고장을 견디며, 예측 가능한 방식으로 복구하고, 장기간 안정적인 미션 성능을 유지할 수 있음을 입증할 수 있다. 이러한 활동이 개발과 실제 운용 전 과정에 통합될 때 비로소 안전하고 신뢰성이 높으며 경제적으로 지속 가능한 자율이동로봇 시스템을 구축할 수 있다.

12.07 Test Result Management

시험 결과 관리(Test Result Management)는 자율이동로봇(Autonomous Mobile Robot, AMR) 시험 과정에서 생성되는 모든 증거(Evidence)를 체계적으로 수집하고, 정리하며, 검토하고, 보존하며, 활용하는 관리 프로세스이다. 이는 개별 측정값과 관찰 결과를 시스템 요구사항(System Requirement), 결함(Defect), 위험(Risk) 평가, 제품 출시 승인(Release Approval)과 연결하는 역할을 수행한다. 시험 결과 관리 체계가 제대로 구축되지 않으면 시험 자체가 성공적으로 수행되었더라도 시험 대상 구성(Configuration), 환경 조건(Environmental Condition), 원시 데이터(Raw Data), 분석 방법(Analysis Method), 최종 판단이 불분명해질 수 있다. 효과적인 결과 관리는 모든 결론이 신뢰할 수 있고 재현 가능한 근거를 기반으로 추적될 수 있도록 보장한다.

시험 결과 관리 프로세스는 시험이 시작되기 이전부터 준비되어야 한다. 모든 시험은 고유 식별번호(Test Identifier), 시험 목적(Objective), 연결된 요구사항(Requirement), 시험 절차 버전(Procedure Version), 예상 결과(Expected Result), 합격 기준(Acceptance Criteria), 책임자(Owner), 필요한 장비(Equipment), 저장 위치(Storage Location)를 미리 정의해야 한다. 이러한 요소들은 이후 결과를 정확하게 해석하기 위한 기반이 된다. 시험이 끝난 후에 결과를 정리하기 시작하면 중요한 상황 정보(Context Information)가 이미 사라졌을 가능성이 높다. 따라서 시험 기록(Test Record)은 계획 단계에서 생성되고, 시험 수행, 분석, 검토, 종료 과정까지 지속적으로 갱신되어야 한다.

시험 결과(Test Result)는 단순히 합격(Pass) 또는 실패(Fail) 여부만을 의미해서는 안 된다. 시험 당시의 조건, 측정값(Measured Value), 관찰된 동작(Observed Behavior), 비교 방법(Comparison Method), 허용 오차(Tolerance), 그리고 이에 대한 공학적 해석(Engineering Interpretation)까지 포함해야 한다. 예를 들어 로봇이 내비게이션 미션을 성공적으로 완료했더라도 과도한 진동(Oscillation), 늦은 장애물 반응, 반복적인 복구 동작이 발생했다면 이러한 정보 역시 반드시 기록되어야 한다. 미션 성공 여부만 기록한다면 중요한 문제를 놓칠 수 있으므로 최종 판정과 그 근거를 함께 보존해야 한다.

시험 식별(Test Identification)은 실험실(Laboratory), 시뮬레이션(Simulation), 하드웨어-인-더-루프(Hardware-in-the-Loop, HIL), 폐쇄 시험장(Closed Course), 파일럿 현장(Pilot Site), 고객 현장(Customer Site) 등 모든 환경에서 일관성을 유지해야 한다. 일반적으로 제품군(Product Family), 하위 시스템(Sub-System), 요구사항 그룹(Requirement Group), 시험 종류(Test Type), 순번(Sequence Number), 개정 번호(Revision)를 포함하는 명명 규칙(Naming Convention)을 사용한다. 절차나 결과가 변경되더라도 시험 식별자는 유지되어야 하며, 이를 통해 보고서, 결함 정보, 로그(Log), 영상(Image), 형상 정보(Configuration Record)가 동일한 시험을 참조할 수 있다.

형상 정보(Configuration Information)는 AMR의 동작이 하드웨어(Hardware), 소프트웨어(Software), 교정(Calibration), 지도(Map), AI 모델(Model), 적재물(Payload), 시스템 설정(Parameter)의 조합에 따라 달라지므로 매우 중요하다. 모든 시험 결과에는 로봇 모델, 일련번호(Serial Number), 하드웨어 버전(Hardware Revision), 센서 구성(Sensor Configuration), 펌웨어(Firmware), 운영체제(Operating System), 응용 소프트웨어(Application Software), 안전 파라미터(Safety Parameter), AI 모델 버전, 지도 버전, 교정 패키지(Calibration Package), 적재물, 시험 도구 버전(Test Tool Version)이 포함되어야 한다. 이러한 정보가 없다면 동일한 결과가 다른 제품에도 적용되는지 확인할 수 없다.

환경 및 운용 조건(Environmental and Operational Condition)은 결과 차이를 설명할 수 있을 만큼 충분히 상세하게 기록되어야 한다. 날짜(Date), 시간(Time), 장소(Location), 온도(Temperature), 습도(Humidity), 조명(Lighting), 날씨(Weather), 바닥 재질(Floor Material), 경사(Slope), 노면 상태(Surface Condition), 네트워크 품질(Network Quality), 사람의 이동량(Human Traffic), 적재 질량(Payload Mass), 무게 중심(Center of Gravity), 배터리 상태(Battery State), 로봇 속도(Robot Speed), 미션 시간(Mission Duration) 등이 포함될 수 있다. 모든 시험에서 모든 정보를 기록할 필요는 없지만 시험 종류별로 반드시 기록해야 하는 항목은 명확하게 정의되어야 한다.

시험 수행 기록(Test Execution Record)은 시험 수행자(Test Operator), 관찰자(Observer), 시작 시간(Start Time), 종료 시간(End Time), 수행된 절차(Procedure), 절차 변경 여부(Deviation)를 포함해야 한다. 수기로 기록한 메모도 시간 정보(Time Stamp)와 함께 저장되어야 한다. 절차 일부를 생략하거나 변경하거나 반복 수행한 경우에는 그 이유를 즉시 기록해야 한다. 승인된 시험 절차를 따르지 않았다면 최종 결과가 정상으로 보이더라도 시험 결과를 유효한 것으로 간주해서는 안 된다.

원시 데이터(Raw Data)는 분석 결과와 별도로 보존되어야 한다. 센서 기록(Sensor Recording), ROS2 Bag, CAN 로그(CAN Log), Ethernet Trace, 제어기 로그(Controller Log), 안전 이벤트(Safety Event), 이미지(Image), 영상(Video), 열 데이터(Thermal Data), 전력 측정(Power Measurement), 시간 분석 데이터(Timing Trace), 운용자 메모는 이후의 분석을 위해 필요할 수 있다. 원시 데이터는 수집 이후 수정되어서는 안 되며, 후처리 결과나 그래프는 이를 대체할 수 없다. 원시 데이터를 유지해야 분석 방법이 변경되더라도 새로운 해석이 가능하다.

시간 동기화(Time Synchronization)는 여러 데이터 소스를 비교할 때 반드시 필요하다. 로봇, 시험 장비, 카메라(Camera), 측정 장비, 서버(Server), 외부 관찰 장치는 동일한 시간 기준(Time Reference)을 사용하거나 시간 오프셋(Time Offset)이 명확히 정의되어야 한다. 충돌 회피 시험에서는 장애물 출현, 센서 탐지, 안전 제어기 출력, 모터 명령, 브레이크 동작, 차량 정지 시점을 정확하게 비교해야 한다. 시간 정보가 일치하지 않으면 응답 시간(Response Time) 분석이 잘못될 수 있으므로 시간 동기화 품질도 시험 결과의 일부로 관리해야 한다.

메타데이터(Metadata)는 가능한 한 자동으로 생성되어야 한다. 일련번호, 소프트웨어 버전, 파라미터 파일(Parameter File), 교정 정보(Calibration Identifier), 시험 시간을 사람이 직접 입력하면 오타나 누락이 발생하기 쉽다. 시험 자동화 시스템(Test Automation)은 시험 전에 로봇 정보를 자동으로 읽어 형상 정보를 저장하고 결과와 연결할 수 있다. 자동 수집은 관리 부담을 줄이고 신뢰성을 높여주지만, 운용자는 실제 시험 환경과 일치하는지도 확인해야 한다.

표준화된 결과 패키지(Standardized Result Package)는 시험 결과를 이해하고 검토하기 쉽게 만든다. 일반적으로 요약 정보(Summary Record), 시험 절차(Procedure Reference), 형상 정보(Configuration Snapshot), 환경 조건(Environmental Condition), 원시 데이터 목록(Raw Data Index), 분석 결과(Processed Metric), 그래프(Visualization), 사진(Photograph), 절차 변경 기록(Deviation Record), 결함 정보(Defect Link), 검토 의견(Review Comment), 최종 승인(Final Approval)을 포함한다. 모든 팀이 동일한 구조를 사용하면 시험 결과를 쉽게 비교할 수 있으며, 중요한 자료가 개인 PC나 메신저에만 저장되는 문제를 방지할 수 있다.

데이터 무결성(Data Integrity)은 저장된 파일이 손상되지 않았음을 보장해야 한다. 체크섬(Checksum), 디지털 서명(Digital Signature), 변경 불가능한 저장소(Immutable Storage), 형상 관리 저장소(Controlled Repository), 접근 기록(Access Log)을 이용하여 시험 데이터를 보호할 수 있다. 대용량 센서 데이터는 여러 저장 장치 사이를 이동하기 때문에 손상이나 덮어쓰기 위험이 존재한다. 따라서 파일 크기(File Size), 체크섬, 전송 상태, 패키지 완전성을 자동으로 확인해야 하며, 필요한 데이터가 누락된 경우에는 보고서를 승인해서는 안 된다.

저장 구조(Storage Architecture)는 개발 중 사용하는 활성 저장소(Active Storage)와 장기 보관용 아카이브(Archive Storage)를 구분해야 한다. 활성 저장소는 분석과 협업을 빠르게 지원해야 하며, 장기 저장소는 인증(Certification), 고객 지원(Customer Support), 현장 조사(Field Investigation)를 위해 데이터를 안전하게 보존해야 한다. 보관 정책(Retention Policy)은 데이터 종류에 따라 보존 기간을 정의해야 하며, 안전성 관련 증거는 일반 디버깅 데이터보다 훨씬 오래 보존될 수 있다.

접근 제어(Access Control)는 중요 시험 데이터를 보호하면서 필요한 협업을 가능하게 해야 한다. 개발자는 업로드와 분석 권한을, 검토자는 읽기와 승인 권한을, 고객이나 외부 평가자는 제한된 자료만 볼 수 있도록 권한(Role-Based Permission)을 설정해야 한다. 승인된 시험 결과는 수정할 수 없으며, 변경이 필요한 경우에는 새로운 개정 버전(Revision)을 생성하고 이전 버전을 그대로 보존해야 한다. 시스템은 누가 언제 무엇을 변경했는지 이력(History)을 유지해야 한다.

시험 상태(Test Status)는 단순히 합격, 실패, 미시험으로만 구분해서는 안 된다. 일반적으로 계획됨(Planned), 준비 완료(Ready), 수행 중(Running), 중단됨(Interrupted), 분석 중(Under Analysis), 합격(Passed), 실패(Failed), 조건부 합격(Conditionally Passed), 무효(Invalid), 차단됨(Blocked), 면제(Waived), 종료됨(Closed)과 같은 상태를 사용할 수 있다. 각 상태는 명확한 정의와 상태 전이 규칙(State Transition)을 가져야 한다.

합격 기준(Acceptance Criteria)은 시험 결과와 함께 명확하게 관리되어야 한다. 수치 기준(Numerical Limit), 논리 조건(Logical Condition), 관찰 조건(Required Observation), 통계 기준(Statistical Threshold), 안전 여유(Safety Margin)는 시험 전에 정의되어야 한다. 시험 결과를 본 이후에 기준을 변경하면 객관성을 잃게 된다. 기준이 변경될 경우에는 별도의 변경 관리(Change Management)를 수행하고 버전 정보를 기록해야 한다.

측정 불확도(Measurement Uncertainty)와 반복성(Repeatability)은 허용 한계 근처의 시험 결과를 판단할 때 반드시 고려해야 한다. 예를 들어 허용 정지거리가 2.00m인데 측정 결과가 1.99m라 하더라도 측정 오차가 0.05m라면 단순히 합격이라고 판단할 수 없다. 반복 시험, 장비 정확도, 교정 상태, 환경 변화, 데이터 처리 방법을 함께 고려하여 최종 결정을 내려야 한다.

예상하지 못한 관찰 사항(Unexpected Observation)은 정식 실패가 아니더라도 반드시 기록해야 한다. 이상 진동, 경고 메시지, 일시적인 위치추정 오류, 느린 복구, 비정상적인 발열, 반복 재시도, 네트워크 이상은 향후 큰 문제의 초기 신호일 수 있다. 이러한 정보는 이상 현상(Anomaly) 또는 개선 항목(Improvement Opportunity)으로 관리해야 하며, 단순히 합격했다는 이유로 무시해서는 안 된다.

실패한 시험 결과(Failed Result)는 체계적인 결함 관리(Defect Management) 프로세스로 연결되어야 한다. 시험 결과는 결함 번호, 심각도(Severity), 관련 요구사항, 영향받는 하위 시스템(Sub-System), 담당 부서, 목표 수정 버전(Target Release), 현재 상태(Status)와 연결되어야 한다. 결함 관리 시스템은 반드시 원래 시험 결과를 참조해야 하며, 단순한 설명만 복사해서는 안 된다.

실패 분류(Failure Classification)는 여러 시험에서 발생한 문제를 체계적으로 분석하는 데 도움을 준다. 요구사항 오류, 절차 오류, 시험 장비 문제, 형상 불일치(Configuration Mismatch), 환경 영향, 소프트웨어 결함, 하드웨어 결함, 교정 오류, 데이터 품질 문제, 사람의 실수, 원인 미확인(Unknown Cause) 등으로 구분할 수 있다. 초기 판단은 이후 조사 과정에서 변경될 수 있으므로 모든 변경 이력도 함께 관리해야 한다.

무효 시험(Invalid Test)은 실제 실패와 명확히 구분되어야 한다. 잘못된 소프트웨어 설치, 센서 미교정, 계측 장비 고장, 절차 오류, 환경 조건 미충족과 같은 경우 시험은 무효가 된다. 이를 단순히 실패 또는 합격으로 처리하면 제품 품질 데이터가 왜곡된다. 무효 사유는 기록되어야 하며, 해당 시험은 다시 수행되어야 한다.

재시험(Retesting)은 최초 실패와 수정 결과를 연결하여 관리해야 한다. 수정 후 시험은 새로운 시험 기록을 생성하지만 이전 실패 기록, 수정 버전(Fix Version), 결함 정보와 연결되어야 한다. 검토자는 최초 실패부터 수정, 회귀 시험(Regression Test), 종료까지 전체 과정을 확인할 수 있어야 한다.

회귀 시험 결과(Regression Result)는 제품 품질의 기준(Baseline)으로 관리되어야 한다. 소프트웨어, 하드웨어, 파라미터, AI 모델이 변경되면 승인된 회귀 시험을 다시 수행하고 이전 결과와 비교해야 한다. 새롭게 실패한 항목, 개선된 항목, 변화된 성능을 비교함으로써 장기적인 품질 변화를 확인할 수 있다.

자동 시험 시스템(Automated Test System)은 시험 결과를 중앙 저장소(Central Repository)에 자동 업로드하는 것이 바람직하다. 실행 로그, 성능 지표, 화면 캡처, 형상 정보가 자동으로 연결되면 사람의 실수를 줄일 수 있다. 단순한 합격 여부는 자동 판단할 수 있지만, 중요한 시험은 반드시 전문가의 검토를 거쳐야 한다.

분석 스크립트(Analysis Script)와 계산 방법(Calculation Method)은 버전 관리되어야 한다. 필터(Filter), 좌표 변환(Coordinate Transformation), 시간 계산(Time Rule), 통계 처리 방식이 변경되면 동일한 데이터에서도 다른 결과가 나올 수 있다. 따라서 분석에 사용한 스크립트 버전, 의존 라이브러리, 파라미터도 시험 결과와 함께 저장해야 한다.

시각화(Visualization)는 결과를 이해하기 쉽게 도와주지만 수치 데이터를 대신해서는 안 된다. 시간 그래프(Time Plot), 이동 궤적(Trajectory), 히트맵(Heat Map), 혼동 행렬(Confusion Matrix), 응답 시간 분포(Latency Distribution), 정지 거리 그래프(Stop Distance Chart), 결함 타임라인(Fault Timeline), 영상 오버레이(Video Overlay)는 중요한 패턴을 보여줄 수 있다. 모든 그래프는 데이터 출처, 단위(Unit), 축(Axis), 필터(Filter)를 명확히 표시해야 한다.

시험 대시보드(Test Dashboard)는 프로젝트 전체의 진행 상황을 한눈에 보여준다. 요구사항 충족률, 시험 진행률, 합격률, 미해결 실패, 차단된 시험, 안전 관련 결함, 재시험 진행 상황, 형상 커버리지(Configuration Coverage), 품질 추세를 제공할 수 있다. 그러나 단순한 녹색 표시(Green Indicator)만으로는 충분하지 않으며, 실제 근거 자료(Evidence)까지 연결되어야 한다.

커버리지 관리(Coverage Management)는 시험 결과와 요구사항을 연결해야 한다. 하나의 요구사항은 여러 시험으로 검증될 수 있으며, 하나의 시험도 여러 요구사항을 만족할 수 있다. 시스템은 검증 완료, 부분 검증, 실패, 면제, 미검증 상태를 명확하게 보여주어야 하며, 다양한 형상과 환경도 함께 고려해야 한다.

요구사항 추적성(Requirement Traceability)은 양방향(Bidirectional)으로 유지되어야 한다. 요구사항에서 시험과 결과를 찾을 수 있어야 하며, 시험 결과에서도 관련 요구사항, 위험 요소(Risk), 설계 요소(Design Element), 출시 결정(Release Decision)을 추적할 수 있어야 한다. 이는 특히 안전 기능에서 매우 중요하다.

위험 기반 우선순위(Risk-Based Prioritization)는 대량의 시험 결과를 효율적으로 관리하기 위해 필요하다. 안전 관련 실패, 심각한 운용 문제, 고객에게 자주 발생하는 문제, 여러 시험을 막는 결함은 우선적으로 처리해야 한다. 그러나 우선순위가 낮다는 이유로 결함을 무시해서는 안 되며, 모든 미해결 문제는 담당자와 처리 계획을 가져야 한다.

절차 변경 관리(Deviation Management)는 승인된 시험 계획과 다르게 시험을 수행한 경우 반드시 기록해야 한다. 장비 교체, 환경 변화, 절차 수정, 표본 수 감소, 센서 사용 불가, 다른 측정 방법 사용 등이 이에 해당한다. 변경 내용, 이유, 승인자, 결과에 미치는 영향을 명확하게 기록해야 하며, 필요한 경우 시험을 다시 수행해야 한다.

면제(Waiver)와 예외 승인(Concession)은 정상적인 합격과 별도로 관리되어야 한다. 일부 요구사항이 미완료 상태라도 제한된 운용 조건이나 고객 승인으로 임시 허용될 수 있다. 이러한 면제는 적용 제품, 형상, 적용 기간, 위험 분석, 보완 조치, 승인자, 종료 조건을 포함해야 하며, 원래 시험 결과는 실패 상태로 유지되어야 한다.

검토 절차(Review Workflow)는 시험의 중요도에 따라 달라져야 한다. 단위 시험(Unit Test)은 자동 승인될 수 있지만, 차량 수준 안전 시험은 시험팀, 시스템 엔지니어링(System Engineering), 안전 담당자, 제품 책임자의 검토를 받아야 한다. 검토자는 절차 준수 여부, 데이터 완전성, 기준 적용, 형상 정보, 결론의 타당성을 확인해야 한다.

시험 결과 검토(Result Review)는 사실(Fact)과 해석(Interpretation)을 구분해야 한다. 측정값, 시간 정보, 이미지, 이벤트는 객관적인 사실이며, 원인 분석과 허용 여부는 공학적 해석이다. 이를 구분하면 나중에 새로운 정보가 생겨도 원시 데이터는 그대로 유지한 채 해석만 수정할 수 있다.

버전 관리(Version Management)는 승인된 모든 결과와 이후 개정을 보존해야 한다. 메타데이터 오류, 분석 오류, 결론 변경이 발생하면 새로운 버전을 생성하고 변경 내용을 기록해야 한다. 이전 결과를 조용히 수정하면 시험 결과의 신뢰성이 사라진다. 이러한 버전 관리는 인증(Certification)과 고객 승인(Customer Acceptance)에서도 매우 중요하다.

출시 기준선(Release Baseline)은 특정 제품 버전에 대한 모든 시험 결과를 하나로 관리한다. 시험 절차, 승인 결과, 변경 사항, 면제 사항, 형상 정보, 알려진 제한 사항, 출시 승인 정보를 포함하며, 승인 이후에는 변경되지 않도록 보호해야 한다. 새로운 버전은 이전 기준선과 비교하여 어떤 시험을 다시 수행했는지도 함께 기록해야 한다.

시험 결과 관리(Test Result Management)는 제품 변형(Product Variant)도 효율적으로 지원해야 한다. 공통 플랫폼 시험은 여러 모델에 적용될 수 있지만, 센서, 배터리, 구동 방식이 다르면 추가 검증이 필요하다. 다른 모델에 시험 결과를 재사용하는 경우에는 반드시 공학적 근거와 적용 범위를 함께 기록해야 한다.

협력사와 공급업체(Supplier)의 시험 결과도 체계적으로 관리해야 한다. 외부 시험 보고서는 시험 대상, 버전, 환경, 기준, 장비, 승인 기준, 수행 기관을 포함해야 하며, 실제 로봇에 그대로 적용 가능한지를 내부에서 다시 검토해야 한다. 부품 인증(Component Certification)만으로는 전체 시스템의 안전성을 보장할 수 없다.

현장 시험(Field Test)과 파일럿 운용(Pilot Deployment) 결과도 실험실 시험과 동일한 수준으로 관리해야 한다. 실제 환경에서는 완전한 정답 데이터를 얻기 어렵지만, 반복적인 개입, 충전 실패, 사고 직전 상황, 복구 이벤트는 실제 운용 신뢰성을 보여주는 중요한 자료가 된다.

개인정보 보호(Privacy)와 기밀성(Confidentiality)도 시험 결과 관리에서 중요하다. 영상, 지도, 고객 설비, 오디오, 네트워크 정보에는 민감한 데이터가 포함될 수 있다. 필요한 정보만 수집하고, 익명화(Anonymization), 암호화(Encryption), 접근 제한을 적용해야 하며, 기술적인 가치도 함께 유지할 수 있도록 계획해야 한다.

백업과 재해 복구(Backup and Disaster Recovery)는 시험 데이터의 안전성을 보장한다. 데이터는 로봇이나 개인 PC에만 저장되어서는 안 되며, 자동 전송, 이중 저장, 정기적인 백업 확인, 복구 시험을 수행해야 한다. 백업은 실제 복구 시험을 수행하기 전까지는 신뢰할 수 없으며, 복구 시에도 메타데이터와 버전 이력이 유지되어야 한다.

보존 및 폐기 정책(Retention and Disposal Policy)은 데이터 종류에 따라 정의되어야 한다. 임시 디버깅 데이터는 분석 후 삭제할 수 있지만, 안전성, 신뢰성, 고객 승인, 출시 관련 자료는 제품 수명 동안 보관해야 할 수 있다. 폐기 시에는 승인 절차와 삭제 기록을 남기고 기밀 정보가 외부로 유출되지 않도록 해야 한다.

품질 감사(Quality Audit)는 시험 결과 관리 절차가 실제로 잘 수행되고 있는지를 확인한다. 요구사항 연결, 형상 정보, 절차 준수, 데이터 보관, 결함 추적성, 승인 절차, 보관 무결성을 점검하며, 반복되는 메타데이터 누락이나 일관성 없는 판단은 프로세스 개선으로 이어져야 한다.

시험 프로세스의 핵심 성과 지표(Key Performance Indicator, KPI)는 신중하게 해석해야 한다. 시험 완료율, 최초 합격률(First-Pass Yield), 재시험 빈도, 결함 해결 시간, 무효 시험 비율, 자동화 수준, 증거 완전성, 요구사항 검증률 등을 사용할 수 있다. KPI의 목적은 좋은 숫자를 만드는 것이 아니라 시험 품질과 제품 완성도를 향상시키는 것이다.

시험 과정에서 얻은 교훈(Lessons Learned)은 성공과 실패 모두에서 수집해야 한다. 반복되는 형상 오류, 신뢰성이 낮은 시험 장비, 어려운 측정 방법, 모호한 기준, 환경 문제, 효과적인 진단 방법은 이후 프로젝트의 절차, 체크리스트(Checklist), 자동화, 설계 지침(Design Guideline), 교육 자료에 반영되어야 한다. 축적된 지식을 재사용하면 동일한 실수를 반복하지 않고 보다 성숙한 검증 체계를 구축할 수 있다.

성숙한 시험 결과 관리 시스템(Test Result Management System)은 개발 초기부터 제품 출시, 실제 운용, 고객 지원, 차기 제품 개발까지 모든 단계의 연속성을 제공한다. 원시 데이터, 형상 정보, 분석 결과, 승인 기록, 이력을 신뢰할 수 있는 형태로 보존하며, 실패는 수정 활동과 연결하고 성공은 요구사항 충족과 연결한다. 시험 결과 관리가 형상 관리(Configuration Management), 결함 관리(Defect Tracking), 위험 관리(Risk Management), 출시 관리(Release Governance)와 통합될 때 시험은 일회성 프로젝트 자료가 아니라 장기간 활용 가능한 공학적 증거(Engineering Evidence)가 된다.

12.08 Testing Checklists and Reports

시험 체크리스트와 보고서(Testing Checklists and Reports)는 개별 시험 활동을 일관성 있는 공학적 증거(Engineering Evidence)로 전환하는 체계적인 프레임워크(Framework)를 제공한다. 시험 절차(Test Procedure)가 시험 수행 방법을 정의한다면, 체크리스트(Checklist)는 준비, 수행, 관찰, 종료 과정에서 중요한 작업이 누락되지 않도록 보장한다. 시험 보고서(Test Report)는 실제 수행된 내용을 기록하고, 수집된 증거를 요약하며, 절차 변경 사항과 한계를 명확히 하고, 제품 수명주기(Product Lifecycle) 전반의 기술적 의사결정을 지원한다. 이 두 요소는 반복성(Repeatability), 추적성(Traceability), 의사소통(Communication), 그리고 자율이동로봇(Autonomous Mobile Robot, AMR) 검증에 대한 신뢰도를 향상시키는 핵심 수단이다.

체크리스트(Checklist)는 공학적 판단(Engineering Judgment)을 대체하는 것이 아니라 이를 지원하는 검증 도구(Verification Aid)로 이해되어야 한다. 체크리스트의 목적은 사람의 실수를 줄이고, 여러 팀 간의 일관성을 높이며, 필수 작업이 올바른 순서로 수행되도록 하는 것이다. 숙련된 엔지니어도 반복 작업에서는 중요한 세부 사항을 놓칠 수 있다. 잘 설계된 체크리스트는 형상 설정(Configuration), 안전 확인(Safety Confirmation), 교정(Calibration), 문서화(Document Preparation)와 같은 핵심 항목이 모든 시험에서 동일한 수준으로 수행되도록 지원한다.

체크리스트 개발(Checklist Development)은 개별 점검 항목을 나열하는 것이 아니라 전체 시험 워크플로(Test Workflow)를 분석하는 것에서 시작해야 한다. 일반적으로 계획(Planning), 장비 준비(Equipment Preparation), 로봇 설정(Robot Configuration), 환경 확인(Environment Verification), 안전 점검(Safety Confirmation), 시험 수행(Procedure Execution), 결과 수집(Result Collection), 데이터 검토(Data Review), 보고서 작성(Report Preparation), 수정 조치(Corrective Action), 최종 승인(Final Approval)의 순서로 진행된다. 각 단계에는 누락이나 오해가 발생할 가능성이 존재하므로 실제 작업 흐름에 맞추어 체크리스트를 구성하면 불필요한 반복을 줄이고 작업 효율성을 높일 수 있다.

시험 수준(Test Level)에 따라 체크리스트 구조도 달라져야 한다. 단위 시험(Unit Testing)은 소프트웨어 설정, 인터페이스 검증, 입력 조건, 출력 확인에 중점을 둔다. 통합 시험(Integration Testing)은 통신, 시간 동기화(Synchronization), 하위 시스템 간 상호작용, 인터페이스 호환성을 중심으로 한다. 시스템 시험(System Testing)은 미션 수행(Mission Execution), 내비게이션(Navigation), 안전 기능(Safety Function), 실제 운용 시나리오를 포함한다. 현장 시험(Field Testing)은 여기에 환경 조건, 인프라 상호작용, 사람의 활동, 기상 조건, 장시간 운용까지 추가된다. 따라서 하나의 공통 체크리스트만으로 모든 시험을 충분히 지원하기는 어렵다.

계획 체크리스트(Planning Checklist)는 시험을 시작할 준비가 완료되었는지를 확인하는 역할을 한다. 시험 목표(Objective)가 승인되었는지, 요구사항(Requirement)이 정의되었는지, 최신 시험 절차가 준비되었는지, 합격 기준(Acceptance Criteria)이 설정되었는지, 책임자가 지정되었는지, 필요한 장비와 교정 인증서(Calibration Certificate)가 준비되었는지, 환경 조건이 적절한지, 필요한 허가(Permission)가 확보되었는지를 확인해야 한다. 준비 부족은 무효 시험(Invalid Test), 일정 지연, 증거 부족으로 이어질 수 있으므로 시험 시작 전 철저한 점검이 중요하다.

형상 확인 체크리스트(Configuration Checklist)는 시험 전에 올바른 하드웨어(Hardware)와 소프트웨어(Software)가 설치되어 있는지를 검증한다. 여기에는 로봇 일련번호(Serial Number), 하드웨어 버전(Hardware Revision), 펌웨어(Firmware), 운영체제(Operating System), 미들웨어(Middleware), 응용 소프트웨어(Application Software), AI 모델(AI Model), 안전 설정(Safety Configuration), 교정 파일(Calibration File), 지도(Map), 적재물(Payload), 배터리 상태(Battery Status), 통신 설정(Communication Setting), 파라미터(Parameter)가 포함될 수 있다. 작은 설정 오류 하나만으로도 전체 시험 결과가 무효가 될 수 있으므로 시험 전에 이를 반드시 확인해야 한다.

장비 준비 체크리스트(Equipment Preparation Checklist)는 계측 장비(Measuring Equipment)가 정상적으로 동작하는지를 확인한다. 카메라(Camera), LiDAR, 힘 센서(Force Sensor), 열화상 카메라(Thermal Camera), 오실로스코프(Oscilloscope), 네트워크 분석기(Network Analyzer), 데이터 로거(Data Logger), 전력 분석기(Power Analyzer), GPS 수신기, 시간 동기화 장치(Timing System), 교정 장비(Calibration Equipment)의 상태를 점검해야 한다. 또한 장비의 배터리, 저장 공간(Storage Capacity), 시간 동기화 설정, 샘플링 주파수(Sampling Frequency), 인터페이스, 센서 정렬도 함께 확인해야 한다.

환경 확인 체크리스트(Environment Verification Checklist)는 시험 환경이 목표 조건을 만족하는지를 확인한다. 실내 시험은 조명(Lighting), 바닥 상태(Floor Condition), 통로 폭(Aisle Width), 장애물 배치, 무선 통신(Wireless Communication), 비상구(Emergency Exit), 사람의 출입 여부를 확인한다. 실외 시험은 여기에 날씨(Weather), 바람(Wind), 가시거리(Visibility), 노면 습도(Surface Moisture), GNSS 수신 상태, 교통 상황(Traffic Condition), 기온, 주변 위험 요소를 추가로 점검한다. 이러한 환경 정보는 결과 재현성과 문제 원인 분석에 매우 중요한 자료가 된다.

안전 체크리스트(Safety Checklist)는 시험 과정에서 가장 중요한 문서 중 하나이다. 시험 전에 비상 정지 장치(Emergency Stop Device), 보호 스캐너(Protective Scanner), 통신 상태, 배터리 상태, 소화기(Fire Extinguisher), 응급 장비(First Aid Equipment), 대피 경로(Evacuation Route), 통제 구역(Restricted Area), 경고 표지(Warning Sign), 개인 보호 장비(Personal Protective Equipment), 비상 연락 절차를 반드시 확인해야 한다. 안전 점검은 형식적인 절차가 아니라 실제 위험을 예방하기 위한 핵심 활동이다.

운용 준비 체크리스트(Operational Readiness Checklist)는 로봇이 실제 시험을 수행할 준비가 되었는지를 확인한다. 배터리 충전 상태, 타이어 상태, 조향(Steering), 제동(Braking), 센서 청결도(Sensor Cleanliness), 적재물 고정 상태, 통신 품질, 위치추정(Localization), 진단 메시지(Diagnostic Message), 소프트웨어 초기화 상태를 점검해야 한다. 예기치 않은 경고나 해결되지 않은 진단 오류가 존재한다면 시험을 중단하고 원인을 먼저 해결해야 한다.

시험 수행 체크리스트(Execution Checklist)는 승인된 시험 절차를 올바른 순서로 수행하도록 지원한다. 초기 위치 확인, 데이터 기록 시작, 시간 동기화 확인, 미션 시작, 주요 이벤트 관찰, 운용자 개입 기록, 필요한 측정 수행, 예기치 않은 현상 기록 등이 포함된다. 이는 여러 엔지니어가 동일한 시험을 반복 수행할 때 높은 일관성을 유지하도록 도와준다.

관찰 체크리스트(Observation Checklist)는 예상된 동작뿐 아니라 예상하지 못한 현상도 체계적으로 기록하도록 한다. 정상적인 작업 완료, 이상 진동(Vibration), 과도한 소음(Noise), 발열(Thermal Change), 응답 지연, 위치추정 불안정, 통신 장애, 반복 재시도, 경고 메시지, 센서 오염, 환경 변화 등을 기록해야 한다. 이러한 관찰 정보는 자동 기록 데이터만으로는 발견하기 어려운 문제를 이해하는 데 중요한 역할을 한다.

데이터 수집 체크리스트(Data Collection Checklist)는 필요한 모든 데이터가 정상적으로 저장되었는지를 확인한다. 센서 로그(Sensor Log), ROS2 Bag, CAN 메시지, Ethernet 데이터, 제어기 로그, 열 영상(Thermal Recording), 이미지(Image), 비디오(Video), GPS 데이터, 시간 정보(Timestamp), 운용자 메모 등이 모두 저장되었는지를 확인해야 한다. 또한 파일 이름(File Naming), 저장 공간, 백업(Backup), 시간 동기화 상태도 현장에서 바로 확인해야 하며, 시험 종료 후 데이터 누락을 발견하면 동일한 시험을 다시 수행해야 할 수도 있다.

시험 종료 체크리스트(Post-Test Checklist)는 시험을 안전하게 마무리하기 위한 절차를 정의한다. 데이터 백업, 장비 전원 차단, 배터리 충전 또는 분리, 임시 장애물 제거, 안전 장치 복원, 시험 구역 점검, 형상 변경 사항 기록을 포함해야 한다. 남아 있는 결함이나 경고, 장비 손상, 특이 사항도 즉시 기록해야 하며 나중에 기억에 의존해서는 안 된다.

체크리스트의 사용성(Usability)은 매우 중요한 설계 요소이다. 지나치게 긴 체크리스트는 사용자가 내용을 건너뛰거나 형식적으로만 확인하게 만들 수 있다. 반대로 너무 짧으면 중요한 항목을 빠뜨릴 수 있다. 효과적인 체크리스트는 관련 항목을 함께 배치하고, 명확한 표현을 사용하며, 모호성을 줄이고, 실제 작업 순서에 맞게 구성해야 한다. 특히 중요한 안전 항목은 강조하되 문서 전체가 복잡해지지 않도록 균형을 유지해야 한다.

디지털 체크리스트(Digital Checklist)는 종이 문서보다 많은 장점을 제공한다. 전자 시스템은 시간(Time Stamp), 작업자 정보(Operator Identity), 형상 정보(Configuration), 장비 상태, GPS 위치, 사진, 전자 서명(Signature)을 자동으로 기록할 수 있다. 또한 필수 항목이 완료되지 않으면 다음 단계로 진행하지 못하도록 하거나, 로봇으로부터 소프트웨어 버전을 자동으로 읽어올 수도 있다. 그러나 네트워크 장애 시에도 사용할 수 있어야 하며, 비상 상황에서는 소프트웨어가 안전 조치를 방해해서는 안 된다.

적응형 체크리스트(Adaptive Checklist)는 시험 종류에 따라 필요한 항목만 표시하도록 구성할 수 있다. 실내 내비게이션, AI 인식(AI Perception), 배터리 안전, 환경 내구성(Environmental Durability), 장기 신뢰성(Long-Term Reliability) 시험은 서로 다른 확인 항목을 요구한다. 따라서 로봇 형상, 하위 시스템, 시험 환경에 따라 필요한 체크리스트만 자동으로 제공하면 작업 부담을 줄이면서도 기술적 완전성을 유지할 수 있다.

시험 보고서(Test Report)는 충분한 증거를 수집하고 검토한 후 작성된다. 보고서는 다른 엔지니어가 무엇을 시험했고, 어떻게 수행했으며, 어떤 증거를 수집했고, 어떤 결론을 얻었으며, 어떤 한계가 남아 있는지를 이해할 수 있도록 작성되어야 한다. 시험 보고서는 수행자뿐 아니라 검토자, 프로젝트 관리자(Project Manager), 인증 기관(Certification Authority), 고객(Customer), 유지보수 담당자, 향후 개발자에게도 중요한 자료가 된다.

보고서는 일반적으로 문서 식별 정보(Administrative Information)로 시작한다. 보고서 번호(Report Identifier), 프로젝트(Project Name), 제품 버전(Product Version), 시험 제목(Test Title), 보고서 버전(Report Revision), 작성자(Author), 검토자(Reviewer), 승인자(Approval Authority), 시험 수행 날짜를 포함해야 한다. 또한 관련 요구사항, 위험 요소(Risk), 설계 변경 사항(Engineering Change), 출시 단계(Release Milestone)와 연결되어야 한다.

목적(Purpose) 항목에서는 왜 이 시험을 수행했는지, 어떤 기술적 질문에 답하기 위한 것인지를 설명해야 한다. 예를 들어 비상 정지 응답 시간(Emergency Stop Response Time), 도킹 반복 정밀도(Docking Repeatability), 위치추정 정확도(Localization Accuracy), AI 인식 강건성(AI Perception Robustness), 장기 미션 신뢰성(Long-Duration Mission Reliability)과 같은 구체적인 목표를 기술해야 한다. 명확한 목적은 보고서 해석 범위를 올바르게 설정하는 데 도움이 된다.

시험 형상(Test Configuration) 항목은 시험 대상 시스템을 다시 재현할 수 있을 만큼 상세하게 기술해야 한다. 로봇 모델, 일련번호, 하드웨어 버전, 소프트웨어 버전, AI 모델, 교정 데이터, 센서 구성, 적재물, 안전 설정, 통신 환경, 계측 장비, 시험 환경 등을 포함해야 하며, 가능한 경우 형상 관리(Configuration Management) 시스템과 연동된 공식 정보를 사용해야 한다.

시험 절차 요약(Procedure Summary)은 실제 수행한 시험 방법을 설명한다. 모든 절차를 그대로 반복하는 것이 아니라 수행 순서, 주요 확인 항목, 변경 사항, 절차 수정 이유를 요약한다. 승인된 절차와 실제 수행 내용이 다를 경우 그 차이가 결과의 유효성에 어떤 영향을 주었는지도 함께 설명해야 한다.

시험 결과(Result) 항목은 분석 이전의 객관적인 데이터를 제시해야 한다. 측정값, 시간 데이터, 정확도 통계, 환경 조건, 이벤트 순서, 진단 정보, 그래프, 사진, 화면 캡처 등을 시험 목적에 맞게 정리해야 한다. 요약 정보만 보고서에 포함하더라도 원시 데이터(Raw Data)는 별도로 추적 가능해야 한다.

그래프(Graph), 표(Table), 시간선(Timeline), 이동 경로(Trajectory Plot), 혼동 행렬(Confusion Matrix), 열화상(Thermal Image), 이벤트 순서(Event Sequence), 비교 그래프(Comparison Chart)는 복잡한 결과를 이해하기 쉽게 표현한다. 그러나 모든 그림에는 축(Axis), 단위(Unit), 범례(Legend), 시간 정보(Time Stamp), 데이터 출처가 명확하게 표시되어야 하며, 시각화는 원시 데이터를 대신할 수 없다.

분석(Analysis) 항목은 측정 결과가 공학적으로 어떤 의미를 가지는지를 설명한다. 결과는 합격 기준(Acceptance Criteria), 이전 버전, 시뮬레이션 결과, 설계 목표, 위험 분석과 비교되어야 한다. 또한 객관적인 사실과 공학적 해석을 구분해야 하며, 여러 가능성이 존재하는 경우에는 불확실성(Uncertainty)을 인정해야 한다.

승인된 절차와 다른 방식으로 수행된 경우에는 절차 변경 사항(Deviation)을 명확히 기록해야 한다. 장비 교체, 환경 변화, 시험 중단, 소프트웨어 변경, 반복 시험, 일부 데이터 누락, 합격 기준 변경이 포함될 수 있다. 변경 사항이 결과의 유효성에 미친 영향과 재시험 필요 여부도 함께 설명해야 한다.

예상하지 못한 관찰 사항(Unexpected Observation)은 시험 실패 여부와 관계없이 반드시 기록해야 한다. 간헐적인 통신 장애, 원인 불명의 재시작, 일시적인 위치추정 드리프트(Localization Drift), 비정상적인 소음, 반복적인 경고 메시지, AI 신뢰도 변화는 이후 현장 운용에서 중요한 단서가 될 수 있다.

결론(Conclusion)은 단순히 결과를 반복하는 것이 아니라 시험 목적에 대한 최종 기술적 판단을 제시해야 한다. 요구사항 충족 여부, 남아 있는 기술적 문제, 해결되지 않은 위험 요소, 추가 시험 필요성을 함께 설명해야 하며, 제한된 시험 결과만으로 모든 환경에서의 성능을 일반화해서는 안 된다.

권고 사항(Recommendation)은 향후 개발 방향을 제시한다. 설계 개선, 소프트웨어 수정, 파라미터 변경, 추가 계측, 환경 시험 확대, 합격 기준 수정, 절차 개선, 자동화 강화, 유지보수 개선 등을 제안할 수 있으며, 중요도와 구현 난이도에 따라 우선순위를 제시하는 것이 바람직하다.

추적성(Traceability) 항목은 보고서를 요구사항, 위험 요소, 결함(Defect), 설계 변경, 회귀 시험(Regression Test), 출시 결정, 데이터셋과 연결한다. 양방향 추적성을 유지하면 설계 변경 시 어떤 시험 결과가 영향을 받는지를 쉽게 확인할 수 있으며, 인증과 고객 승인에서도 매우 중요한 역할을 한다.

검토 및 승인 절차(Review and Approval Workflow)는 시험의 중요도에 따라 달라져야 한다. 일반적인 하위 시스템 보고서는 담당 엔지니어 검토로 충분할 수 있지만, 안전 관련 시험은 시스템 엔지니어링(System Engineering), 품질(Quality), 기능 안전(Functional Safety), 제품 관리(Product Management), 독립 검토자까지 포함될 수 있다. 전자 승인 시스템은 검토 의견(Comment), 개정 이력(Revision History), 승인 날짜(Date), 전자 서명(Digital Signature)을 모두 보존해야 한다.

문서 버전 관리(Document Version Management)는 보고서 수정 이력을 투명하게 유지해야 한다. 분석 수정, 형상 정보 변경, 추가 시험, 결론 수정이 발생할 경우 변경 내용과 이유를 기록해야 하며, 이전 버전도 함께 보존해야 한다. 이는 고객 검토, 인증 심사, 유지보수 과정에서 매우 중요하다.

기밀성 및 정보 보안(Confidentiality and Information Security)은 고객 정보, 시설 배치도, AI 알고리즘, 운영 지도(Map), 사진, 영상, 네트워크 구조, 안전 파라미터가 포함된 보고서에서 반드시 고려해야 한다. 적절한 등급(Classification), 접근 제어(Access Control), 암호화(Encryption), 배포 제한, 보관 절차를 적용하여 민감한 정보를 보호해야 하며, 필요한 경우 외부 공개용 보고서는 일부 내용을 삭제하여 제공할 수 있다.

표준 보고서 템플릿(Standardized Report Template)은 프로젝트 간 일관성을 높이고 작성 시간을 줄여준다. 일반적으로 목적, 형상 정보, 절차, 결과, 분석, 결론, 권고 사항, 승인, 부록(Appendix)을 포함한다. 모든 보고서가 동일한 구조를 사용하면 교육, 검토, 자동 처리, 장기 유지보수가 쉬워지며, 동시에 시험 특성에 따라 필요한 내용을 유연하게 추가할 수 있어야 한다.

부록(Appendix)은 본문 흐름을 방해하지 않으면서 상세한 자료를 제공한다. 측정 데이터, 교정 인증서, 환경 기록, 소프트웨어 버전, 파라미터 파일, 원시 데이터 위치, 추가 그림, 통계 계산, 위험 분석, 보조 사진 등을 포함할 수 있다. 이러한 자료를 분리하여 관리하면 본문은 읽기 쉬우면서도 기술적 완전성을 유지할 수 있다.

교훈(Lessons Learned)은 시험 과정에서 발견된 프로세스 개선 사항, 어려운 문제, 효과적인 진단 방법, 반복되는 형상 오류, 성공적인 엔지니어링 사례를 기록해야 한다. 이러한 경험은 이후 시험 절차, 체크리스트, 보고서 템플릿, 교육 자료, 설계 지침으로 반영되어야 하며, 단순히 회의 기록으로만 남겨서는 안 된다.

시험 체크리스트와 보고서(Testing Checklists and Reports)는 자율이동로봇 개발을 위한 중요한 지식 관리 시스템(Knowledge Management System)이다. 체크리스트는 사람의 실수를 줄이고 절차의 일관성을 높여 시험 수행 품질을 향상시키며, 보고서는 기술적 증거, 공학적 판단, 개발 이력을 제품 수명주기 전체에 걸쳐 보존한다. 이러한 체계가 형상 관리(Configuration Management), 요구사항 추적성(Requirement Traceability), 결함 관리(Defect Tracking), 안전성 평가(Safety Assessment), 지속적 개선(Continuous Improvement)과 통합될 때 개별 시험은 제품 개발, 인증, 양산, 장기 운용을 지원하는 신뢰성 높은 공학적 기반으로 발전할 수 있다.