Booil Jung

항공 하드웨어 및 소프트웨어 시험평가계획서 작성을 위한 전문가 가이드

항공 시스템의 하드웨어 및 소프트웨어 시험평가계획(Test and Evaluation Plan)은 단순히 규제 준수를 위해 작성하는 서류 작업이 아니다. 이것은 개발 과정에서 발생할 수 있는 기술적 리스크를 사전에 식별하고 체계적으로 완화하며, 시스템이 모든 요구사항을 충족함을 객관적으로 입증하여 최종적으로 감항인증(Airworthiness Certification)을 획득하기 위한 프로젝트의 핵심 전략 문서다.1 성공적으로 수립된 시험평가계획은 개발 초기 개념 정립부터 최종 시스템 납품에 이르는 전 과정에서 중요한 의사결정을 지원하는 명확한 로드맵으로 기능한다.3

현대의 항공 시스템은 하드웨어와 소프트웨어가 극도로 복잡하게 융합되어 있어, 어느 한쪽의 개별적인 시험만으로는 전체 시스템의 안전성과 성능을 보장할 수 없다.5 소프트웨어의 미세한 결함이 하드웨어의 오작동을 유발할 수 있으며, 하드웨어의 타이밍 문제가 소프트웨어 로직을 붕괴시킬 수도 있다.7 따라서 본 가이드는 하드웨어 설계 보증 표준인 DO-254, 소프트웨어 설계 보증 표준인 DO-178C, 그리고 전체 시스템의 시험평가기본계획(TEMP, Test and Evaluation Master Plan)을 하나의 유기적인 프레임워크로 통합하는 실무적 접근법을 제시한다. 이러한 통합 접근법은 요구사항부터 설계, 구현, 시험에 이르는 개발 산출물 간의 완전한 추적성(Traceability)을 확보하고, 특히 하드웨어/소프트웨어 통합(HSIT, Hardware/Software Integration Testing) 과정에서 발생하는 예측 불가능한 문제들을 조기에 발견하여 해결하기 위해 필수적이다.8

본 보고서는 총 3부로 구성된다. 제1부에서는 시험평가계획이 반드시 준수해야 하는 법적, 기술적 기반인 감항인증 제도와 DO-178C/DO-254 표준을 심층적으로 분석하여 계획의 근본적인 토대를 마련한다. 제2부에서는 이를 바탕으로 국제적으로 통용되는 시험평가기본계획(TEMP)의 표준 구조를 설계하고 각 항목의 작성 요령을 상세히 기술한다. 마지막으로 제3부에서는 계획서에 명시된 전략을 실제로 구현하기 위한 구체적인 시험 활동, 즉 시험 항목 설정, 통합 시험, 시스템 수준 검증 및 결과 보고 절차를 상세히 설명한다. 이 보고서의 최종 목표는 독자가 이론적 깊이와 실무적 활용성을 겸비한, 현업에서 즉시 적용 가능한 고품질의 시험평가계획서를 작성할 수 있는 역량을 갖추도록 하는 것이다.

---

이 장에서는 시험평가계획서가 반드시 준수해야 하는 규제 프레임워크와 기술 표준을 심층적으로 분석한다. 이는 계획서의 ‘왜’와 ‘무엇을’에 해당하는 근본적인 토대를 마련하는 과정이다.

감항인증은 개발된 항공기가 비행안전에 적합함을 정부 기관이 공식적으로 증명하는 법적 절차다.10 시험평가계획에 기술된 모든 활동의 궁극적인 목적은 이 인증을 획득하는 데 필요한 객관적인 증거(evidence)를 체계적으로 생성하는 것이다.12 감항인증은 민간 항공기와 군용 항공기에 따라 주관 기관과 법규가 다르므로, 프로젝트의 성격에 맞는 규제 프레임워크를 명확히 이해하는 것이 계획 수립의 첫걸음이다.

• 민간 항공기 감항인증 (국토교통부)
  • 관련 법규: 항공안전법 제23조(감항증명)와 제24조(감항승인)가 법적 근거를 제공한다.10
  • 인증 절차: 일반적으로 설계의 안전성을 증명하는 형식증명(TC, Type Certificate), 설계대로 제작할 능력을 증명하는 제작증명(PC, Production Certificate), 그리고 개별 항공기의 안전 운항 능력을 증명하는 감항증명(AC, Airworthiness Certificate)의 단계를 거친다.11 각 단계에서 시험평가 결과는 인증 심사의 핵심 근거 자료로 제출된다.
  • 핵심 원칙: 민간 항공기 감항인증의 핵심은 해당 항공기가 ‘인가된 설계에 일치하게 제작’되었고 ‘안전하게 운항’할 수 있음을 입증하는 것이다.10 이는 시험평가계획이 설계 요구사항(functional requirements)뿐만 아니라 시스템 안전 요구사항(safety requirements)을 모두 포괄하여 검증해야 함을 의미한다.
• 군용 항공기 감항인증 (방위사업청)
  • 관련 법규: ‘군용항공기 비행안전성 인증에 관한 법률’ 및 관련 업무규정이 적용된다.14
  • ‘사업별/기종별 감항인증계획’: 군용기 사업의 경우, 사업관리기관은 방위사업청이 통보하는 작성지침에 따라 ‘사업별/기종별 감항인증계획안’을 수립하여 승인을 받아야 한다.14 이 계획은 시험평가계획서의 직접적인 상위 문서 역할을 하며, 시험평가의 범위와 방향을 결정한다.
  • 필수 포함 항목: 사업별/기종별 감항인증계획에는 사업개요, 인증 일정 및 조직과 더불어 다음과 같은 핵심 내용이 포함되어야 한다.11
    • 감항인증기준안 및 적합성 검증방법(MOC, Method of Compliance): 이는 시험평가계획의 가장 중요한 입력 정보다. MOC는 각 감항인증기준 항목에 대해 분석(Analysis), 검사(Inspection), 시연(Demonstration), 시험(Test) 중 어떤 방법으로 적합성을 입증할 것인지를 명시한다.
    • 최초 안전비행(SOF, Safety of Flight) 평가 기준: 초도 비행의 안전성을 확보하기 위한 평가 기준을 정의한다.
    • 주요안전품목(CSI, Critical Safety Item) 식별 및 관리 계획: 고장이 치명적인 결과를 초래할 수 있는 품목을 식별하고 특별 관리하는 계획을 포함한다.

감항인증은 법적 절차이며 10, 이를 통과하기 위해서는 감항당국(FAA, EASA, 방사청 등)이 요구하는 기술 표준(DO-178C, DO-254 등)을 충족했다는 ‘증거’를 제출해야만 한다.17 시험평가계획서는 이 증거를 어떻게 생성할 것인지에 대한 구체적인 ‘계획’이자 인증 기관과의 ‘약속’이다.12 따라서 계획서의 모든 항목은 관련 법규 및 규정의 요구사항과 직접적으로 추적 가능해야 한다. 계획서에 명시된 활동을 준수하지 않는 것은 단순한 프로젝트 일정 지연을 넘어, 최악의 경우 감항증명 취소와 같은 법적 문제로 비화될 수 있다.10 이런 관점에서 시험평가계획서는 단순한 기술 문서를 넘어 법적 효력을 갖는 ‘준법 서약서’와 같은 무게를 지닌다.

또한, 감항인증계획에서 정의하는 ‘적합성 검증방법(MOC)’은 시험평가계획의 ‘설계도’와 같다.11 MOC는 각 요구사항을 검증하기 위한 시험, 분석, 검사 등 구체적인 활동 유형을 지정한다.11 시험평가계획서는 이 MOC를 실제로 구현하기 위한 세부 절차, 필요 자원, 일정, 그리고 명확한 합격/불합격 기준을 기술하는 실행 계획서다. 만약 MOC가 모호하거나 부실하게 정의된다면, 이를 기반으로 하는 시험평가계획 전체가 방향성을 잃고 부실해질 수밖에 없다. 그러므로 시험평가계획서 작성에 앞서, 각 요구사항에 대한 MOC를 명확히 정의하고 관련 조직 간에 합의하는 과정이 반드시 선행되어야 한다.

구분	주관기관	관련 법규	주요 인증 절차	시험평가계획 관련 핵심 요구사항
민간 항공기	국토교통부 (지방항공청)	항공안전법	형식증명(TC) –» 제작증명(PC) –» 감항증명(AC)	인가된 설계 일치성 및 안전 운항 능력 입증, DO-178C/DO-254 등 국제 표준 준수 증거 제출 10
군용 항공기 (연구개발)	방위사업청	군용항공기 비행안전성 인증에 관한 법률	형식인증 –» 생산확인 –» 표준감항증명	사업별/기종별 감항인증계획 수립 및 승인, 감항인증기준(ACC) 및 적합성 검증방법(MOC) 정의 15
군용 항공기 (구매)	방위사업청	군용항공기 비행안전성 인증에 관한 법률	형식인증(일부 생략 가능) –» 특별감항증명	원제작사의 감항인증서 및 검증자료 제출, 필요시 추가적인 감항성 심사 계획 수립 15

DO-178C, “Software Considerations in Airborne Systems and Equipment Certification”은 항공기 탑재 소프트웨어의 안전성과 신뢰성을 보장하기 위해 전 세계적으로 통용되는 산업 표준이다.17 이 표준의 목적은 소프트웨어 개발 수명주기 전반에 걸쳐 달성해야 할 목표(Objectives), 이를 달성하기 위한 활동(Activities), 그리고 그 활동의 결과로 생성되어야 하는 증거(Evidence)인 산출물(Life Cycle Data)을 명확히 정의하는 것이다.21

• 설계보증수준 (DAL, Design Assurance Level):

  DAL은 DO-178C의 모든 요구사항의 엄격성을 결정하는 가장 중요한 요소다. 이는 시스템 안전성 평가(System Safety Assessment) 과정에서 특정 소프트웨어의 고장이 항공기와 탑승객에 미치는 영향의 심각도를 분석하여 5개 등급으로 분류된다.17

  • Level A (Catastrophic): 고장이 항공기 손실 및 다수의 인명 사망을 초래할 수 있는 치명적인 상태. 가장 엄격한 수준의 검증이 요구되며, 총 71개의 목표를 달성해야 한다.22
  • Level B (Hazardous/Severe-Major): 고장이 안전 여유를 크게 감소시키거나 심각한 부상을 초래할 수 있는 상태.
  • Level C (Major): 고장이 안전 여유를 감소시키거나 경미한 부상을 초래할 수 있는 상태.17
  • Level D (Minor): 고장이 운용에 약간의 영향을 미치지만 안전과는 무관한 상태.17
  • Level E (No Effect): 고장이 안전이나 운용에 전혀 영향을 미치지 않는 상태.17

• DO-178C 수명주기 프로세스 및 핵심 활동:

  DO-178C는 소프트웨어 수명주기를 크게 계획, 개발, 검증 프로세스와 이 모든 과정을 아우르는 총괄 프로세스로 구분한다.

  • 계획 프로세스 (Planning): 소프트웨어 인증 계획(PSAC, Plan for Software Aspects of Certification)을 수립하는 단계로, 전체 소프트웨어 개발 및 검증 활동의 청사진을 그린다. 개발 및 검증 방법론, 적용할 표준, 사용할 도구, 형상관리 및 품질보증 계획 등을 상세히 정의한다.17
  • 개발 프로세스 (Development): 시스템 요구사항으로부터 상위 수준 요구사항(High-Level Requirements)을 도출하고, 이를 기반으로 소프트웨어 아키텍처를 설계하고 하위 수준 요구사항(Low-Level Requirements)을 정의하며, 최종적으로 소스코드를 작성하고 실행 가능한 목적 코드로 통합하는 전 과정을 포함한다.21 모델 기반 개발(MBD, Model-Based Development)과 같은 현대적인 기법을 활용하여 요구사항 분석과 설계를 수행하고 코드를 자동 생성할 수도 있다.22
  • 검증 프로세스 (Verification): 개발 산출물이 요구사항을 정확하고 완전하게 만족하는지를 확인하는 활동이다. 리뷰(Reviews), 분석(Analyses), 시험(Tests)의 세 가지 방법으로 수행된다.17 특히, 모든 소프트웨어 요구사항이 시험되었음을 보장하는 요구사항 기반 시험(Requirements-Based Testing)과, 시험이 코드 구조를 얼마나 충분히 실행시켰는지를 측정하는 구조적 커버리지 분석(Structural Coverage Analysis)이 핵심적인 검증 활동이다.24
  • 총괄 프로세스 (Integral Processes): 개발 전 과정에 걸쳐 지속적으로 수행되는 지원 활동들이다. 산출물의 변경 이력을 추적하고 통제하는 형상관리(Configuration Management), 계획과 표준이 준수되는지 감시하는 품질보증(Quality Assurance), 개발 및 검증 중 발견된 결함을 문서화하고 해결하는 문제 보고(Problem Reporting), 그리고 인증 기관과의 소통을 담당하는 인증 연락(Certification Liaison)으로 구성된다.17

DO-178C는 ‘무엇을(what)’ 해야 하는지에 대한 목표(Objectives)를 명확히 정의하지만, ‘어떻게(how)’ 그 목표를 달성할 것인지에 대한 구체적인 방법론을 강제하지는 않는다.12 예를 들어, 특정 프로그래밍 언어나 개발 도구, 시험 기법을 지정하지 않는다. 이는 개발 조직에게 프로젝트의 특성과 보유 기술 역량에 맞춰 모델 기반 개발, 자동화 시험 등 가장 효율적이고 적합한 방법을 선택할 수 있는 유연성을 부여한다.22 그러나 이러한 자율성에는 반드시 책임이 따른다. 조직은 자신들이 선택한 방법론이 DO-178C의 목표들을 충분히 만족시킨다는 것을 논리적으로 ‘입증’해야 할 책임을 진다. 이 입증 전략을 구체적으로 문서화한 것이 바로 시험평가계획서의 핵심 내용이 되어야 한다.

특히 시험 자동화 도구의 도입은 신중한 전략적 판단을 요구한다. 코드 생성기나 정적 분석기처럼 검증 활동을 대체하거나 그 노력을 줄여주는 도구를 사용하려면, DO-178C는 그 도구 자체가 신뢰할 수 있음을 증명하도록 요구하는데, 이것이 바로 ‘도구 자격(Tool Qualification)’이다.17 도구 자격을 획득하는 과정은 그 자체로 상당한 비용과 노력이 소요되는 하나의 작은 프로젝트와 같다.25 따라서 시험평가계획 수립 단계에서, 자동화 도구 도입을 통해 얻게 될 효율성 증대 효과와 도구 자격 획득에 필요한 비용, 일정, 그리고 잠재적 리스크를 종합적으로 비교 분석해야 한다. 무분별한 도구 도입은 오히려 인증 실패의 원인이 될 수 있으므로, 효율성과 인증 리스크 간의 트레이드오프를 고려한 전략적 결정이 필수적이다.

DO-254, “Design Assurance Guidance for Airborne Electronic Hardware”는 FPGA(Field Programmable Gate Array), ASIC(Application Specific Integrated Circuit)과 같은 복합 전자 하드웨어(CEH, Complex Electronic Hardware)의 개발 및 인증을 위한 설계 보증 가이드라인이다.18 이 표준의 목적은 하드웨어 개발 수명주기 전반에 걸쳐 체계적인 계획, 설계, 검증 활동을 요구함으로써 비행 중 발생할 수 있는 하드웨어 오류의 위험을 최소화하는 것이다.18

• DO-254 수명주기 프로세스 및 핵심 활동:

  DO-254의 수명주기 프로세스는 DO-178C와 매우 유사하게 계획, 설계, 그리고 이를 지원하는 프로세스로 구성된다.19

  • 계획 프로세스 (Planning): 하드웨어 인증 계획(PHAC, Plan for Hardware Aspects of Certification)을 비롯한 각종 계획 문서를 작성하는 단계다. PHAC는 하드웨어 개발 및 검증 전략, 적용 표준, 형상관리 계획 등을 포함하며, DO-178C의 PSAC와 유사한 역할을 수행한다.
  • 설계 프로세스 (Hardware Development): 시스템 요구사항으로부터 할당된 하드웨어 요구사항을 만족하는 물리적인 하드웨어 아이템을 만들어내는 과정이다.
    • 요구사항 캡처 (Requirement Capture): 시스템 수준에서 할당된 요구사항과 하드웨어 설계 과정에서 파생된 요구사항을 식별하고 문서화한다.27
    • 개념 설계 (Conceptual Design): 요구사항을 만족시키기 위한 하드웨어 아키텍처를 수립하고, 주요 기능 블록과 인터페이스를 정의한다.27
    • 상세 설계 (Detailed Design): 개념 설계를 바탕으로 VHDL이나 Verilog 같은 하드웨어 기술 언어(HDL)를 사용하여 실제 구현을 위한 상세 로직을 설계한다.27
    • 구현 (Implementation): 상세 설계된 HDL 코드를 합성(Synthesis)하고 배치 및 배선(Place & Route)하여 실제 타겟 디바이스(FPGA 등)에 프로그래밍할 비트 파일을 생성하는 과정이다.27
    • 생산 전이 (Production Transition): 개발된 하드웨어 아이템을 일관성 있게 복제하여 양산할 수 있도록 모든 설계 및 제작 데이터를 기준(baseline)으로 설정하고 문서화한다.27
  • 지원 프로세스 (Supporting Processes): 개발 전 과정에 걸쳐 수행되며, 검증 및 확인(V&V), 형상관리, 프로세스 보증, 인증 연락 등의 활동을 포함한다.27

• 검증 및 확인 (V&V): DO-254 프로세스의 핵심 활동으로, 설계의 각 단계에서 산출물이 요구사항을 충족하는지를 지속적으로 검증한다. 리뷰, 분석, 그리고 시뮬레이션 및 실제 타겟 하드웨어에서의 테스트를 통해 설계 결함을 조기에 발견하고 수정하는 것을 목표로 한다.18

DO-254와 DO-178C는 계획, 개발, 검증, 형상관리 등 유사한 수명주기 프로세스와 DAL(Design Assurance Level) 개념을 공유하기에 마치 ‘거울 이미지’처럼 보인다.8 그러나 두 표준 사이에는 검증의 초점과 방법론에서 결정적인 차이가 존재한다. DO-178C는 소프트웨어의 논리적 ‘행위(behavior)’를 검증하는 데 집중하며, 시뮬레이션 환경에서의 테스트와 코드의 논리적 경로를 확인하는 구조적 커버리지 분석이 중심이 된다.7 반면, DO-254는 하드웨어의 ‘물리적 구현’과 ‘타이밍’의 정확성을 검증해야 한다. 이는 HDL 시뮬레이션뿐만 아니라, 실제 타겟 하드웨어에서 물리적인 신호가 정확한 타이밍에 발생하는지, 극한의 온도나 진동 같은 환경 스트레스 하에서도 정상적으로 동작하는지를 확인하는 물리적 테스트가 훨씬 더 중요하다는 것을 의미한다.7 이 근본적인 차이를 이해하지 못하고 소프트웨어 검증 방식을 하드웨어에 그대로 적용하려 하면, 타이밍 오류나 환경적 요인으로 인한 치명적인 결함을 놓칠 수 있다.

또한, DO-254 계획 프로세스의 최종 산출물인 PHAC 문서는 단순한 계획서가 아니라 인증 기관과의 ‘협상 계약서’로 인식해야 한다.27 PHAC에는 개발 및 검증 전략, 적용 표준, 도구 사용 계획 등이 포함되는데, 특히 중요한 부분은 ‘하드웨어 설계 보증 목표의 준수 방법’을 인증 기관에 제안하고 사전 동의를 얻는 과정이다.19 이는 프로젝트 초기에 인증 기관과 “우리는 이러한 방식으로 개발하고 검증할 것이며, 이것이 DO-254의 목표를 충분히 만족시킨다”고 공식적으로 합의하는 것과 같다. 이 단계에서 명확한 합의가 이루어지면, 개발 후반부에 인증 기관이 예상치 못한 새로운 요구사항을 제기하거나 기존의 검증 방식을 문제 삼을 리스크를 크게 줄일 수 있다. 따라서 PHAC 작성은 개발팀의 일방적인 계획 수립이 아니라, 인증 기관과의 적극적인 소통을 통한 전략적 협상 과정으로 접근해야 한다.

추적성은 요구사항, 설계, 코드(또는 HDL), 시험 케이스, 시험 결과 등 개발 수명주기 동안 생성되는 모든 산출물 간의 관계를 명시적으로 설정하고 유지하는 활동이다.8 항공 시스템 개발에서 추적성은 선택이 아닌 필수이며, 다음과 같은 질문에 대한 명확한 답을 제공한다: “모든 요구사항이 누락 없이 설계와 구현에 반영되었는가?”, “구현된 모든 코드는 근거가 되는 요구사항을 가지고 있는가?”, “모든 요구사항은 시험을 통해 검증되었는가?”.17

• 양방향 추적성 (Bidirectional Traceability):

  추적성은 반드시 양방향으로 구축되어야 한다.29

  • 순방향 추적 (Forward Traceability): 요구사항에서부터 설계, 구현, 시험으로 이어지는 관계를 추적한다. 이는 특정 요구사항이 어떻게 구현되고 시험되었는지를 보여준다.30 이를 통해 요구사항 누락을 방지할 수 있다.
  • 역방향 추적 (Backward Traceability): 시험, 구현, 설계에서부터 상위 요구사항으로 거슬러 올라가는 관계를 추적한다. 이는 특정 코드나 설계 요소가 어떤 요구사항 때문에 존재하는지를 설명해준다.30 이를 통해 불필요한 기능(gold plating)의 구현을 막을 수 있다.

• 요구사항 추적성 매트릭스 (RTM, Requirements Traceability Matrix):

  RTM은 양방향 추적성을 문서화하는 가장 일반적이고 효과적인 도구다.30 RTM은 일반적으로 표(matrix) 형태로 작성되며, 행에는 개별 요구사항을, 열에는 관련 설계 문서, 소스코드, 시험 케이스, 시험 결과 등을 배치하여 상호 관계를 표시한다.29 RTM은 단순히 요구사항 충족 여부를 보여주는 것을 넘어, 변경 영향 분석(change impact analysis)에서 강력한 힘을 발휘한다. 예를 들어, 특정 요구사항이 변경되었을 때, RTM을 통해 해당 변경이 어떤 설계 문서, 소스코드, 그리고 시험 케이스에 영향을 미치는지 즉시 파악하고, 수정 및 재검증 범위를 정확하게 식별할 수 있다.29

전통적으로 RTM은 엑셀(Excel)과 같은 스프레드시트로 관리되어, 데이터 업데이트가 느리고 오류가 발생하기 쉬운 정적인 문서로 취급되는 경우가 많았다.30 이러한 RTM은 개발이 모두 끝난 후에 규제 기관 제출용으로 형식적으로 작성되는 수동적인 역할에 그치기 쉽다. 그러나 Jama Connect, Perforce Helix ALM과 같은 현대적인 요구사항 관리 및 ALM(Application Lifecycle Management) 도구를 활용하면, RTM은 프로젝트의 건강 상태를 실시간으로 보여주는 ‘동적 대시보드’로 진화할 수 있다.29 이러한 도구들은 요구사항, 테스트 케이스, 결함 등을 데이터베이스로 관리하고 그 관계를 자동으로 연결하여 RTM을 실시간으로 생성한다. 이를 통해 프로젝트 관리자는 “현재 전체 요구사항 대비 시험 커버리지는 몇 퍼센트인가?”, “가장 많은 결함이 발견된 위험한 요구사항은 무엇인가?”, “아직 시험되지 않은 요구사항은 무엇인가?”와 같은 질문에 대한 답을 즉시 얻을 수 있다. 이는 프로젝트의 진행 상황과 리스크를 실시간으로 모니터링하고 데이터 기반의 의사결정을 내리는 데 결정적인 역할을 한다. 따라서 시험평가계획서는 단순히 RTM을 산출물로 정의하는 것을 넘어, 이러한 동적 RTM을 활용하여 프로젝트를 관리하고 리스크를 통제하는 구체적인 전략을 포함해야 한다.

요구사항 ID	요구사항 설명	요구사항 출처	DAL/DAL	설계 문서 ID	소스코드/HDL 모듈	시험 케이스 ID	시험 방법(MOC)	시험 결과 (Pass/Fail)	관련 결함 ID
HLR-001	항공기는 자동 착륙 모드를 제공해야 한다.	시스템 요구사항 명세서 1.2.3	A	SDD-01, SDD-02	AutoLand_Ctrl.c	TC-HLR-001-01	Test	Pass	-
LLR-005	자동 착륙 제어 모듈은 활주로 정렬 신호를 10ms 주기로 처리해야 한다.	HLR-001	A	SDD-02, Sec 4.1	AutoLand_Ctrl.c	TC-LLR-005-01	Test	Pass	-
LLR-006	활주로 정렬 신호가 5회 연속 유실될 경우, 시스템은 경고를 발생시키고 수동 모드로 전환해야 한다.	HLR-001	A	SDD-02, Sec 4.2	AutoLand_Ctrl.c	TC-LLR-006-01	Test	Fail	DEF-1024
…	…	…	…	…	…	…	…	…	…

---

이 장에서는 1부에서 다룬 법적/기술적 기반을 바탕으로 실제 시험평가계획서(TEMP, Test and Evaluation Master Plan)를 어떻게 구조화하고 작성하는지 상세히 안내한다. TEMP는 전체 시험평가 프로그램의 최상위 관리 문서로서, 미 국방부(DoD)와 연방항공청(FAA)에서 사용하는 표준 템플릿을 기반으로 구성하는 것이 일반적이다.1

파트	섹션 제목	핵심 기술 내용	관련 표준(DO-178C/254) 연계점
Part I	서론 (Introduction)	목적, 임무, 시스템 개요(KPPs, 인터페이스), 특별 인증 요구사항	DO-178C/254 준수 요구사항 및 DAL 명시
Part II	관리 및 일정 (T&E Management and Schedule)	조직 및 역할(R&R), 결함 보고 절차, 통합 시험평가 일정	DO-178C의 품질보증, 형상관리, 문제 보고 프로세스와 연계
Part III	시험평가 전략 (T&E Strategy)	DT/OT 접근법, 평가 프레임워크(Metrics), M&S 활용, 시험 한계	DO-178C/254의 검증(Verification) 활동(리뷰, 분석, 시험) 계획
Part IV	자원 요약 (Resource Summary)	예산, 시험 장비/시설, 인력 요구사항	도구 자격(Tool Qualification)이 필요한 소프트웨어/하드웨어 도구 명시

TEMP의 서론은 단순히 배경을 설명하는 부분이 아니다. 이 부분은 계획서의 나머지 모든 내용을 정당화하는 논리적 근거를 제공하는 핵심적인 역할을 한다. 시스템의 임무와 핵심 성능 요구사항이 명확하게 정의되지 않으면, 후속 시험 전략과 자원 계획은 설득력을 잃게 된다.

• 1.1 목적 (Purpose): 이 TEMP가 어떤 목적(예: 신규 항공기 체계 개발, 기존 시스템 성능 개량)으로 작성되었으며, 어떤 중요한 의사결정(예: 상세설계검토(CDR) 통과, 운용시험평가(IOT&E) 진입 승인)을 지원하기 위한 것인지 명확하고 간결하게 기술한다.34
• 1.2 임무 기술 (Mission Description): 개발 대상 시스템이 실제 운용 환경에서 어떤 임무를, 어떤 개념(CONOPS, Concept of Operations)으로 수행할 것인지 구체적으로 서술한다.34 예를 들어, 정찰용 무인기라면 ‘적진 상공에서 특정 해상도의 영상 정보를 실시간으로 획득하여 지상 통제소로 전송하는 임무’와 같이 기술한다. 이는 특히 시스템의 운용 적합성을 평가하는 운용시험평가(OT)의 시나리오를 설계하는 데 있어 가장 근본적인 기반이 된다.
• 1.3 시스템 기술 (System Description): 평가 대상 시스템을 기술적으로 상세히 정의한다.
  • 주요 성능 파라미터 (KPPs, Key Performance Parameters) 및 주요 시스템 속성 (KSAs, Key System Attributes): 시스템이 반드시 달성해야 하는 가장 중요한 성능 지표들을 정량적으로 명시한다.34 예를 들어, ‘탐지 거리: 100 km 이상’, ‘목표물 식별 정확도: 95% 이상’, ‘시스템 응답 시간: 0.5초 이내’와 같이 측정 가능한 목표치(Threshold)와 희망치(Objective)를 구분하여 기술한다. 이 KPP와 KSA는 제3부에서 기술될 모든 시험평가의 구체적인 합격/불합격 기준을 설정하는 직접적인 근거가 된다.
  • 주요 인터페이스: 시스템이 상호작용하는 모든 외부 시스템(예: 위성 통신 시스템, 지상 관제 시스템, 다른 탑재 장비)과의 물리적, 전기적, 데이터 인터페이스를 정의한다.34 이는 하드웨어/소프트웨어 통합 시험(HSIT)의 범위와 복잡성을 결정하는 중요한 요소다.
  • 특별 시험/인증 요구사항: 본 시스템 또는 그 구성품에 적용되는 DO-178C, DO-254와 같은 특정 산업 표준이나 인증 요구사항을 명시한다.34 예를 들어, ‘비행 제어 소프트웨어는 DO-178C Level A 요구사항을 준수해야 함’과 같이 기술한다. 이는 1부에서 분석한 법적/기술적 기반과 본 계획서를 직접적으로 연결하는 고리 역할을 한다.

이처럼 서론에 KPP(예: 특정 탐지 거리)와 DAL(예: Level A)이 명확히 정의되면, 이 KPP를 검증하기 위해 제3부 ‘시험평가 전략’에서 특정 시험 시나리오와 데이터 수집 요구사항이 논리적으로 도출된다. 또한, Level A를 만족시키기 위해 MCDC(Modified Condition/Decision Coverage) 분석과 독립적 검증 활동이 계획에 포함되어야 한다. 이러한 시험들을 수행하기 위해 제4부 ‘자원 요약’에서는 고가의 시험 장비와 특정 자격을 갖춘 인력이 필요하게 된다. 즉, 서론의 모든 기술 내용은 후속 계획의 필요성과 규모를 결정하는 논리적 출발점이므로, 명확하고 구체적으로 작성되어야 한다.

이 부분은 시험평가라는 복잡한 프로젝트를 ‘어떻게 관리하고 실행할 것인가’에 대한 계획을 담는다.

• 2.1 시험평가 관리 조직 (T&E Management): 시험평가 활동을 주관하고 참여하는 모든 내부 및 외부 조직(예: 사업 관리 조직, 개발팀, 주 계약업체, 독립 시험평가 기관, 최종 사용자 대표)을 명시하고, 각 조직의 역할과 책임(R&R, Roles and Responsibilities)을 명확하게 정의한다.34 효과적인 의사소통과 의사결정 구조(예: T&E WIPT - Test and Evaluation Working-level Integrated Product Team)를 함께 기술하는 것이 중요하다.
• 2.2 결함 보고 및 처리 절차 (Deficiency Reporting): 시험 중 발견된 모든 결함(Deficiency) 또는 문제점을 어떻게 보고, 추적, 분석, 수정하고, 수정 결과를 재검증할 것인지에 대한 표준화된 절차를 수립한다.34 이 절차는 결함의 심각도 분류 기준(예: Critical, Major, Minor), 결함 관리 시스템(예: JIRA, Bugzilla), 그리고 결함 검토 위원회(DRB, Deficiency Review Board) 운영 방안을 포함해야 한다. 이는 DO-178C의 문제 보고(Problem Reporting) 프로세스와 직접적으로 연계되어야 한다.17
• 2.3 통합 시험평가 일정 (Integrated Test Program Schedule): 전체 사업 기간 동안의 개발, 시험, 평가, 인증과 관련된 모든 주요 활동을 포함하는 통합 마스터 스케줄을 제시한다.34 이 일정에는 단위 시험, 통합 시험, 시스템 시험과 같은 개발시험평가(DT) 활동, 운용시험평가(OT) 활동, 그리고 각종 기술 검토 회의(PDR, CDR 등)와 같은 주요 마일스톤이 모두 표시되어야 한다.35

복잡한 항공 시스템 개발에서 일정 계획은 단순히 활동을 시간 순서대로 나열하는 ‘이벤트 기반’ 접근법을 넘어서야 한다. 기술적 불확실성이 높은 항공 시스템 개발의 특성을 고려할 때, 효과적인 일정은 ‘리스크 기반’으로 수립되어야 한다. 예를 들어, “DT 시작 –» DT 종료 –» OT 시작”과 같은 단순한 순서가 아니라, “가장 리스크가 높은 신기술(예: 새로운 항법 알고리즘)에 대한 조기 프로토타입 시험 및 시뮬레이션 –» 통합 리스크가 가장 큰 하드웨어/소프트웨어 인터페이스에 대한 조기 통합 시험(HSIT) –» 기술적으로 안정화된 기능에 대한 후반부 시스템 수준 회귀 시험”과 같이, 프로젝트의 성공에 가장 큰 위협이 되는 리스크를 조기에 식별하고 완화하는 순서로 활동을 배열해야 한다. 이러한 리스크 기반 접근법은 개발 후반부에 치명적인 결함이 발견되어 전체 프로젝트가 좌초되는 최악의 상황을 예방하는 가장 효과적인 전략이다.

이 부분은 TEMP의 핵심으로, “요구사항을 어떻게 검증하고 시스템의 성능을 어떻게 평가할 것인가”에 대한 구체적인 전략과 방법론을 기술한다.

• 3.1 개발시험평가(DT)와 운용시험평가(OT) 접근법:

  • 개발시험평가 (DT, Developmental Test): 주로 개발 주관사 또는 계약자가 수행하며, 시스템이 기술 요구사항 명세서와 설계 사양을 정확히 만족하는지 검증(Verification)하는 데 초점을 맞춘다.36 주로 통제된 실험실 환경에서 정밀 계측 장비를 사용하여 수행되며, DO-178C와 DO-254에서 요구하는 대부분의 검증 활동(단위 시험, 통합 시험, 코드 커버리지 분석 등)이 이 단계에서 이루어진다.
  • 운용시험평가 (OT, Operational Test): 정부 시험평가기관이나 최종 사용자 대표와 같은 독립적인 조직이 주관하며, 시스템이 실제와 유사한 운용 환경에서 주어진 임무를 효과적으로 수행할 수 있는지 확인(Validation)하는 데 초점을 맞춘다.36 이는 ‘시스템이 올바르게 만들어졌는가(built the system right)’를 넘어 ‘올바른 시스템을 만들었는가(built the right system)’를 평가하는 과정이다.

• 3.2 평가 프레임워크 (Evaluation Framework): 제1부에서 정의한 KPP, KSA, 그리고 기타 주요 운용 이슈(COIs, Critical Operational Issues)를 어떻게 측정하고 평가할 것인지에 대한 구체적인 계획을 제시한다.34 각 평가 항목(예: 탐지 거리)에 대해, 측정 지표(Metrics, 예: km), 성공 기준(예: 100 km 이상), 데이터를 수집할 시험 이벤트(예: 고고도 순항 시나리오), 그리고 필요한 데이터의 종류(예: 레이더 원시 데이터, GPS 위치 데이터)를 명확히 정의한 표(Evaluation Framework Matrix) 형태로 작성하는 것이 효과적이다.37 이 프레임워크는 요구사항 추적성 매트릭스(RTM)와 직접적으로 연결되어, 모든 요구사항이 평가 계획에 포함되었음을 보장한다.

• 3.3 모델링 및 시뮬레이션 (M&S) 활용 전략:

  M&S는 현대 항공 시스템 시험평가에서 비용과 시간을 절감하고 안전을 확보하기 위한 필수적인 도구다. 실제 비행시험이 불가능하거나(예: 적의 위협 환경), 위험하거나(예: 엔진 고장 상황), 비용이 많이 드는(예: 수천 번의 반복 시험) 시나리오를 지상에서 효과적으로 시험할 수 있게 해준다.22 TEMP에는 HIL(Hardware-in-the-Loop), SIL(Software-in-the-Loop), 전체 시스템 시뮬레이션 등 어떤 M&S 기법을 개발 및 시험의 어느 단계에서, 어떤 목적으로 활용할 것인지 구체적인 전략을 명시해야 한다.38

• 3.4 시험 한계 및 리스크 (Test Limitations and Risks): 시험 환경, 가용 자원, 일정, 기술적 제약 등으로 인해 완벽하게 시험할 수 없는 영역(한계)을 솔직하게 식별하고 기술해야 한다.34 예를 들어, ‘특정 전자전 위협 신호는 시뮬레이션으로만 모사 가능하며, 실제 위협 환경에서의 시험은 수행 불가함’과 같이 명시한다. 그리고 이러한 한계로 인해 발생하는 리스크(예: 실전에서 예상치 못한 성능 저하 가능성)와 그 리스크를 완화하기 위한 방안(예: 추가적인 분석, 유사 위협 신호 시험)을 함께 제시해야 한다.

전통적으로 DT와 OT는 명확히 분리되어 순차적으로 진행되었으나, 이는 동일한 시험을 중복 수행하거나 DT에서 수집된 귀중한 데이터가 OT에서 제대로 활용되지 못하는 비효율을 초래했다.4 현대적인 시험평가 접근법은 DT와 OT를 연계하는 통합 시험(Integrated Testing)을 지향한다.40 예를 들어, DT 단계에서부터 OT를 염두에 두고 실제와 유사한 운용 시나리오를 일부 포함시키거나, DT와 OT 팀이 초기부터 공동으로 시험을 계획하고 일부 시험을 함께 수행하는 것이다. 이를 통해 DT에서 얻은 시스템 성능 데이터를 OT의 기초 자료로 활용함으로써, OT에 소요되는 시간과 비용을 획기적으로 줄일 수 있다. TEMP는 이러한 통합 시험 전략을 명시적으로 기술하여 시험평가 프로그램 전체의 효율성을 극대화해야 한다.

이 부분은 시험평가 전략을 실행하는 데 필요한 모든 ‘군수 지원’ 계획을 담는다. 필요한 자원을 구체적이고 현실적으로 산정하는 것이 중요하다.

• 4.1 시험 예산: 시험 인력의 인건비, 시험 장비 구매 및 임대 비용, 시험 시설 사용료, 출장비, 소모품비 등 시험평가 활동 전반에 걸쳐 소요되는 모든 비용을 항목별로 추정하여 제시한다.1
• 4.2 시험 물자 및 장비: 시험 대상 시제품(UUT, Unit Under Test)의 수량, 시험을 지원하는 각종 장비(GSE, Ground Support Equipment), 오실로스코프나 로직 분석기와 같은 계측 장비, 데이터 수집 및 분석 시스템 등 시험에 필요한 모든 하드웨어 및 소프트웨어 자원의 목록과 사양을 구체적으로 명시한다.1
• 4.3 시험 인력 및 시설: 시험을 수행할 엔지니어, 시험 조종사, 정비사, 데이터 분석가 등 필요한 인력의 자격 요건과 인원수를 기술한다.42 또한, 시험에 필요한 특정 시설(예: HIL 실험실, 전파 무향실, 환경 시험 챔버, 시험 비행을 위한 공역, 격납고 등)을 명시하고 확보 계획을 제시한다.1

자원 계획을 수립할 때, 단순히 “A 장비 1대, B 인력 2명”과 같이 필요한 자원의 목록만 나열하는 것으로는 부족하다. 핵심은 그 자원이 ‘언제’ 필요한지를 명확히 하는 ‘적시성’에 초점을 맞추는 것이다. 예를 들어, HIL 시뮬레이터는 하드웨어/소프트웨어 통합 시험 단계인 프로젝트 중반에 집중적으로 필요하고, 고가의 환경 시험 챔버는 특정 인증 시험 기간에만 단기적으로 필요할 수 있다. 효과적인 자원 계획은 제2부에서 수립한 통합 시험 일정과 긴밀하게 연계되어, 각 자원이 필요한 정확한 시점(need-by date)과 예상 사용 기간을 명시해야 한다. 이는 고가의 장비 임대 기간을 최적화하여 비용을 절감하고, 여러 프로젝트에서 공유하는 핵심 인력의 스케줄이 충돌하지 않도록 사전에 조율하는 데 필수적이다.

---

이 장에서는 계획서에 기술된 전략을 실제로 실행하기 위한 구체적인 ‘How-to’를 다룬다. 성공적인 시험평가는 명확한 기준, 체계적인 통합, 그리고 실전과 같은 검증에 달려 있다.

모호한 기준은 모호한 결과만을 낳는다. 시험평가의 신뢰성은 얼마나 명확하고 객관적인 잣대를 가지고 있느냐에 따라 결정된다.

• 검증 가능한 시험 목표(Verifiable Test Objectives) 수립:

  모든 시험 목표는 SMART 원칙(Specific, Measurable, Achievable, Relevant, Time-bound)에 따라 구체적이고 측정 가능하게 기술되어야 한다.42 “시스템은 잘 동작해야 한다”와 같은 모호한 목표는 평가가 불가능하다. 대신 “시스템은 고도 10,000 ft, 속도 250 kts의 순항 조건에서, 전방 50 km에 있는 RCS

  1m2 크기의 목표물을 1초 이내에 탐지해야 한다”와 같이 구체적인 조건과 성능 값을 명시해야 한다. 또한, 모든 시험 목표는 상위 요구사항 문서(예: 시스템 요구사항 명세서)의 특정 항목과 직접적으로 추적 가능해야 한다.36

• 합격/불합격 기준 (Pass/Fail Criteria) 정의:

  각 시험 목표에 대해 성공과 실패를 판단할 수 있는 명확하고 객관적인 기준을 사전에 정의해야 한다.43

  • 정량적 기준: 성능 지표에 대한 구체적인 수치를 제시한다. 예를 들어, ‘평균 응답 시간은 100ms 미만이어야 한다’, ‘항법 정확도 오차는 10m 이내여야 한다’, ‘평균 전력 소모는 5W 이하여야 한다’ 등이 해당된다.44
  • 정성적 기준: 특정 기능의 정상적인 동작 여부를 기술한다. 예를 들어, ‘비상 상황 시, 경고 메시지가 화면 중앙에 빨간색으로 정확히 표시되어야 한다’와 같이 예상되는 결과를 명확히 서술한다.43
  • 진입/종료 기준 (Entry/Exit Criteria): 각 시험 단계를 시작하기 위한 선행 조건(진입 기준)과, 해당 단계를 성공적으로 완료하고 다음 단계로 넘어가기 위한 조건(종료 기준)을 정의한다.45 예를 들어, 통합 시험의 진입 기준으로 ‘관련된 모든 소프트웨어/하드웨어 모듈의 단위 테스트 통과’를 설정할 수 있으며, 종료 기준으로는 ‘발견된 심각(Critical) 등급 결함 0개, 전체 테스트 케이스 통과율 95% 이상’과 같이 구체적인 목표를 설정할 수 있다.46

합격/불합격 기준을 설정할 때, 엔지니어는 종종 기술적 완벽성을 추구하려는 경향이 있다. 그러나 현실적으로 모든 시스템에는 결함이 존재하며, 모든 결함이 임무 실패를 의미하는 것은 아니다.46 중요한 것은 기술적 완벽성이 아니라 ‘운용 적합성(Operational Suitability)’ 관점에서 기준을 설정하는 것이다. 즉, “이 결함이 최종 사용자의 임무 수행에 실질적인 방해를 초래하는가?”라는 질문을 던져야 한다. 예를 들어, 거의 사용되지 않는 메뉴 화면의 사소한 텍스트 오타는 운용에 영향을 주지 않지만, 주 사용 화면에서 핵심 정보를 표시하지 못하는 버그는 치명적이다.47 따라서 합격/불합격 기준, 특히 종료 기준을 설정할 때는 개발팀뿐만 아니라 시스템을 실제로 운용할 최종 사용자나 운용자 대표가 반드시 참여하여 현실적인 기준에 대해 합의하는 과정이 필수적이다.

HSIT는 개별적으로 개발된 하드웨어 컴포넌트와 소프트웨어 컴포넌트를 결합하여 하나의 서브시스템 또는 시스템으로 올바르게 상호작용하는지를 검증하는 핵심적인 단계다.

• 통합 전략:

  통합은 체계적인 전략에 따라 점진적으로 수행되어야 한다.

  • 상향식 (Bottom-up): 가장 낮은 수준의 단위(Unit) 또는 모듈을 먼저 시험하고, 이를 점차 통합하여 더 큰 컴포넌트와 서브시스템을 만들어가며 시험하는 방식이다.9 하드웨어 드라이버, 인터페이스 로직 등 하위 수준 인터페이스의 결함을 조기에 발견하는 데 유리하다.
  • 하향식 (Top-down): 시스템의 최상위 수준 컴포넌트(예: 메인 제어 소프트웨어)부터 시험을 시작하며, 아직 개발되지 않은 하위 컴포넌트는 그 기능을 모방하는 가짜 모듈인 스텁(Stub)으로 대체한다.9 시스템의 전체적인 아키텍처와 주요 제어 흐름을 초기에 검증할 수 있다는 장점이 있다.
  • 실제 대규모 프로젝트에서는 상위 수준의 제어 로직은 하향식으로, 하위 수준의 드라이버와 인터페이스는 상향식으로 통합하여 중간에서 만나는 ‘샌드위치(Sandwich)’ 또는 ‘빅뱅(Big Bang)’의 변형된 형태의 혼합 전략이 흔히 사용된다.

• HIL (Hardware-in-the-Loop) 시뮬레이션 환경 활용:

  HSIT는 HIL 시뮬레이션 환경에서 수행되는 경우가 많다.38 HIL 환경은 시험 대상인 실제 하드웨어(예: 비행 제어 컴퓨터)를 시뮬레이터와 연결하여, 실제 항공기의 나머지 부분(예: 엔진, 조종면, 센서)과 외부 비행 환경을 소프트웨어로 모사한다. 이를 통해 실제 항공기 없이도 지상에서 안전하고 반복적으로 비행 제어, 엔진 제어, 전기 시스템 등 복잡한 시스템 간의 동적인 상호작용을 시험할 수 있다.5

• HSIT의 주요 시험 항목:

  HSIT에서는 개별 단위 시험에서는 발견하기 어려운 인터페이스 관련 문제들을 중점적으로 검증해야 한다. 주요 시험 항목은 다음과 같다.9

  • 인터페이스 타이밍 및 프로토콜: 하드웨어와 소프트웨어 간의 데이터 교환 타이밍, 인터럽트 처리 지연, 데이터 버스(예: ARINC-429, MIL-STD-1553, 이더넷) 통신 프로토콜의 정확성
  • 자원 공유: 공유 메모리, DMA(Direct Memory Access) 채널 등 공유 자원에 대한 접근 충돌 문제
  • 실행 시간 및 스케줄링: 실시간 운영체제(RTOS) 하에서 태스크들의 실행 시간(execution time)이 예산을 초과하는지, 우선순위에 따른 스케줄링이 올바르게 동작하는지
  • 내장형 시험(BIT, Built-In Test) 기능: 소프트웨어에 의해 제어되는 하드웨어 BIT 기능이 고장을 정확히 탐지하고 보고하는지

HSIT의 진정한 목적은 단순히 명세서에 정의된 인터페이스의 기능 검증을 넘어선다. 개별적으로는 완벽하게 동작하던 하드웨어와 소프트웨어를 통합했을 때 발생하는 문제들은 대부분 명시적인 요구사항 문서에는 없었던, 두 컴포넌트의 복잡한 상호작용에서 비로소 드러나는 ‘미발견 속성(Emergent Properties)’ 또는 ‘미발견 요구사항(Emergent Requirements)’인 경우가 많다. 예를 들어, 특정 순서로 시스템을 부팅할 때만 발생하는 경쟁 상태(race condition)나 타이밍 문제가 이에 해당한다. 따라서 HSIT 계획은 단순히 정의된 인터페이스 사양을 하나씩 확인하는 긍정적 시험(positive testing)을 넘어, 예상치 못한 상호작용을 의도적으로 유발할 수 있는 스트레스 시나리오(예: 최대 부하 상태에서 데이터 버스 포화), 경계값 및 예외 조건과 같은 엣지 케이스(edge case) 시나리오를 적극적으로 포함해야 한다.6

모든 컴포넌트가 통합된 전체 시스템을 대상으로, 최종 사용자의 운용 환경과 유사한 조건에서 요구사항을 만족하는지 검증하는 마지막 단계다.

• 시험 유형:

  • 기능 시험 (Functional Testing): 시스템이 요구사항 명세서에 정의된 모든 기능(예: 자동 항법, 목표물 추적, 데이터 링크 통신)을 올바르게 수행하는지 확인한다.42
  • 성능 시험 (Performance Testing): 시스템의 응답 시간, 처리량, 정확도, 탐지 거리 등 제1부에서 정의한 KPP와 KSA를 만족하는지 정량적으로 측정하고 평가한다.42
  • 환경 시험 (Environmental Testing): 고온, 저온, 고습, 진동, 충격, 전자기파(EMI/EMC) 등 항공기가 실제 임무 중에 겪을 수 있는 극한의 물리적, 전자기적 환경을 모사하여 시스템의 내구성과 신뢰성을 검증한다.42
  • 신뢰성/안정성 시험 (Reliability/Stability Testing): 장시간(수십~수백 시간) 동안 시스템을 연속적으로 운용하면서 소프트웨어 행(hang), 재부팅, 성능 저하 등의 문제가 발생하는지 확인하고, 평균 고장 시간 간격(MTBF, Mean Time Between Failures)과 같은 신뢰도 지표를 측정한다.44

• 시험 절차서 (Test Procedure) 작성:

  각 시스템 수준 시험 케이스에 대해서는 상세한 시험 절차서를 작성해야 한다.41 절차서에는 시험의 구체적인 목적, 시험에 필요한 장비 및 인력, 시험 환경 구성 방법, 단계별 수행 절차, 각 단계에서 확인해야 할 예상 결과, 그리고 기록해야 할 데이터 항목 등이 명확하게 기술되어야 한다. 잘 작성된 시험 절차서는 누가 시험을 수행하더라도 동일한 조건에서 동일한 결과를 얻을 수 있도록 재현 가능성(reproducibility)을 보장해야 한다.

• 운용시험평가(OT)와의 연계:

  시스템 수준의 개발시험평가(DT) 결과는 OT 진입 여부를 결정하는 중요한 근거가 된다. OT에서 확인해야 할 핵심적인 운용 시나리오나 위험도가 높은 기능들을 DT 단계의 시스템 시험에서 미리 검증하고 안정화함으로써, 값비싼 비행시험 자원이 소요되는 OT의 리스크와 기간을 줄일 수 있다.40

시험은 결과를 기록하고 분석하여 개선으로 이어질 때 비로소 그 가치를 가진다.

• 시험 결과 보고서 (Test Report) 작성:

  모든 시험 활동이 완료되면, 그 결과를 공식적인 시험 결과 보고서로 문서화해야 한다. 보고서에는 시험의 목적과 범위 요약, 수행한 시험 목록 및 일정, 각 시험 케이스별 합격/불합격 결과, 발견된 모든 결함의 상세 목록, 주요 성능 데이터 분석 결과, 그리고 결론 및 후속 조치 권고안이 포함되어야 한다.42 이 보고서는 감항인증 심사를 위한 핵심 제출 자료 중 하나이므로, 모든 내용이 객관적인 데이터를 기반으로 정확하고 명료하게 작성되어야 한다.

• 결함 처리 및 회귀 시험 (Regression Testing):

  시험 중에 발견된 결함은 심각도와 우선순위에 따라 체계적으로 관리되어야 한다.34 결함이 수정되면, 반드시 동일한 시험을 다시 수행하여 문제가 해결되었음을 확인하는 재시험(re-test)을 거쳐야 한다. 여기서 더 중요한 것은 회귀 시험(Regression Testing)이다. 회귀 시험은 특정 부분의 코드를 수정하거나 기능을 변경했을 때, 그 수정이 의도치 않게 기존에 정상적으로 동작하던 다른 기능에 악영향(side effect)을 미치지 않았는지를 확인하는 과정이다.9 예를 들어, 항법 알고리즘의 일부를 수정했다면, 항법 기능뿐만 아니라 이 알고리즘의 결과를 사용하는 비행 제어 기능, 디스플레이 기능 등 관련된 모든 기능 영역의 테스트 케이스들을 다시 수행해야 한다. 시험평가계획서에는 회귀 시험의 범위(예: 전체 시험 케이스의 20% 또는 특정 기능 영역)와 자동화 전략을 명시하여, 변경에 따른 리스크를 효과적으로 통제해야 한다.52

시험을 통해 생성된 방대한 데이터는 단순히 해당 프로젝트의 결함을 수정하고 보고서를 작성하는 데 사용된 후 사라지는 일회성 정보가 아니다. 이 데이터는 조직의 미래를 위한 귀중한 ‘자산’으로 관리되어야 한다. 예를 들어, 축적된 결함 데이터를 통계적으로 분석하면, ‘어떤 소프트웨어 모듈에서 결함이 가장 집중적으로 발생하는가?’, ‘개발자들이 가장 흔하게 저지르는 실수의 유형은 무엇인가?’, ‘시험에 가장 많은 시간이 소요되는 기능 영역은 어디인가?’와 같은 패턴을 발견할 수 있다.53 이러한 분석 결과는 다음 프로젝트를 계획할 때, 기술적 리스크가 높은 영역을 사전에 예측하여 자원을 집중하고, 개발자 교육의 초점을 맞추며, 비효율적인 시험 절차를 개선하는 등 조직 전체의 개발 및 시험 역량을 근본적으로 향상시키는 데 활용될 수 있다. 이는 시험평가 활동을 단순한 비용이 아닌, 조직의 역량을 강화하는 장기적인 투자로 전환시키는 중요한 관점이다.

---

항공 하드웨어 및 소프트웨어 시험평가계획서는 단순히 작성하는 것만으로 끝나지 않는다. 성공적인 시험평가 프로그램은 잘 만들어진 계획서를 기반으로, 변화에 유연하게 대응하고 지속적으로 개선될 때 완성된다. 다음 세 가지 원칙은 계획을 살아있는 성공 전략으로 만드는 데 핵심적인 역할을 한다.

• 인증 기관과의 조기 및 지속적 협력 (Certification Liaison): 가장 값비싼 실수는 개발이 거의 끝난 시점에 인증 기관으로부터 “이 검증 방법은 부적절하다”는 통보를 받는 것이다. 이러한 재앙을 피하는 가장 효과적인 방법은 계획 단계부터 인증 기관(FAA, EASA, 방사청 등)과 적극적으로 소통하여 시험평가 전략, MOC, 도구 활용 계획 등에 대한 공감대를 형성하고 사전 동의를 얻는 것이다.18 이는 개발 후반에 발생할 수 있는 예상치 못한 요구사항 변경이나 재작업 리스크를 최소화하고, 최종 인증 과정을 원활하게 만드는 가장 확실한 보험이다.
• 자동화 도구의 전략적 활용: 요구사항 관리, 추적성 매트릭스(RTM) 생성, 형상관리, 정적 분석, 시험 케이스 실행 및 구조적 커버리지 분석 등 개발 및 검증 수명주기 전반에 걸쳐 검증된 자동화 도구를 전략적으로 활용해야 한다.18 자동화는 단순히 효율성을 높이는 것을 넘어, 반복적인 작업에서 발생하는 인간의 실수를 근본적으로 줄여 품질을 향상시키는 역할을 한다. 단, 본문에서 강조했듯이, 검증 활동을 대체하는 도구의 경우 ‘도구 자격(Tool Qualification)’이라는 추가적인 부담이 발생할 수 있으므로, 도입에 따른 이득과 비용을 종합적으로 분석하여 전략적인 선택을 해야 한다.
• 동적 계획 관리: 시험평가계획은 한번 작성하고 책장에 꽂아두는 정적인 문서가 아니다. 개발 과정에서 설계가 변경되고, 새로운 리스크가 식별되며, 예상치 못한 시험 결과가 도출되는 것은 필연적이다. 시험평가계획은 이러한 변화를 즉시 반영하여 지속적으로 검토되고 업데이트되며, 모든 변경 이력이 형상 관리되는 ‘살아있는 문서(Living Document)’여야 한다.34 성공적인 시험평가는 완벽한 초기 계획을 수립하는 능력보다, 예측 불가능한 변화에 효과적으로 대응하는 유연한 계획 관리 능력에 달려 있다.

결론적으로, 잘 만들어진 시험평가계획서는 기술적 로드맵이자, 법적 준수 서약서이며, 리스크 관리 도구이고, 최종적으로는 항공기의 안전을 보장하는 핵심적인 초석이다. 본 가이드에서 제시한 원칙과 방법론을 바탕으로 체계적이고 실용적인 계획을 수립하고 실행함으로써, 복잡하고 어려운 항공 시스템 개발 프로젝트를 성공적으로 완수할 수 있을 것이다.

1. Test & Evaluation Master Plan (TEMP)

   www.dau.edu, accessed July 30, 2025, https://www.dau.edu/acquipedia-article/test-evaluation-master-plan-temp

2. t_TEMPforInvProgs.docx - FAA, accessed July 30, 2025, https://www.faa.gov/sites/faa.gov/files/about/office_org/headquarters_offices/ang/t_TEMPforInvProgs.docx
3. Test and Evaluation Master Plan Template for Investment Programs - FAA, accessed July 30, 2025, https://www.faa.gov/sites/faa.gov/files/2022-02/temasterplanv6.0.pdf
4. 국방무기 시험평가시스템 효율화방안 연구 - Korea Science, accessed July 30, 2025, https://koreascience.kr/article/JAKO201336448942758.pdf
5. How to Enhance System Integration Test Rigs with Open-Source Real-Time Control and Data Acquisition, accessed July 30, 2025, https://www.acscm.com/wp-content/uploads/System-Integration-Test-Rigs-with-Open-Source-Real-Time-Control-and-DAQ.pdf
6. Hardware/Software Integration Testing for the new Airbus Aircraft Families. - ResearchGate, accessed July 30, 2025, https://www.researchgate.net/publication/37928946_HardwareSoftware_Integration_Testing_for_the_new_Airbus_Aircraft_Families
7. DO-254 vs. DO-178C: The avionics certification battle slowing down eVTOLs, accessed July 30, 2025, https://flyingcarsmarket.com/do-254-vs-do-178c-the-avionics-certification-battle-slowing-down-evtols/
8. DO-254 및 DO-178C 방위 전자 제품의 추적성 요구 사항 - Altium Resources, accessed July 30, 2025, https://resources.altium.com/kr/p/do-254-and-do-178c-traceability-requirements-defense-electronics
9. DO-178C Integration Testing Compliance for Aerospace & Defense - Parasoft, accessed July 30, 2025, https://www.parasoft.com/learning-center/do-178c/integration-testing/

10. 인증제도 상세

    e나라 표준인증, accessed July 30, 2025, https://www.standard.go.kr/KSCI/crtfcSystem/searchCrtfcSystemView.do?crtfcstId=0000000445&crtfcstReformNo=0000&viewPage=system&firstChk=ok&menuId=60373&topMenuId=536&upperMenuId=537

11. 항공기 SW 감항인증 - Mktg.co.kr, accessed July 30, 2025, http://www.mktg.co.kr/windforum/download/AnD_Session_5.pdf
12. DO-178C란? - (주)모아소프트, accessed July 30, 2025, https://moasoftware.co.kr/software/do-178c%EB%9E%80/
13. 항공기인증 - 항공안전기술원, accessed July 30, 2025, https://www.kiast.or.kr/kr/sub03_01_01.do

14. 군용항공기 비행안전성 인증에 관한 업무규정

    국가법령정보센터

    행정규칙, accessed July 30, 2025, https://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000191917

15. 법령 - 인증제도 상세

    e나라 표준인증, accessed July 30, 2025, https://www.standard.go.kr/KSCI/crtfcSystem/searchCrtfcSystemView.do?crtfcstId=0000000429&crtfcstReformNo=0000&viewPage=system&firstChk=ok&menuId=60373&topMenuId=536&upperMenuId=537

16. 행정규칙 > 군용항공기 감항인증 업무규정

    국가법령정보센터, accessed July 30, 2025, https://www.law.go.kr/LSW/admRulInfoP.do?admRulSeq=2000000016402

17. DO-178C란 무엇입니까?, accessed July 30, 2025, https://visuresolutions.com/ko/%ED%95%AD%EA%B3%B5-%EC%9A%B0%EC%A3%BC-%EB%B0%8F-%EB%B0%A9%EC%9C%84/178c%EB%A5%BC%ED%95%98%EB%8B%A4/
18. DO-254 설명: 공중 전자 하드웨어에 대한 설계 보증 지침 - Visure Solutions, accessed July 30, 2025, https://visuresolutions.com/ko/%ED%95%AD%EA%B3%B5-%EC%9A%B0%EC%A3%BC-%EB%B0%8F-%EB%B0%A9%EC%9C%84/254%EC%9D%84/
19. 항공 시스템용 전자 하드웨어 개발을 위한 미국 및 유럽의 가이드라인 …, accessed July 30, 2025, https://www.koreascience.kr/article/JAKO202225947791157.pdf
20. DO-178C DAL Levels - 개준생의 공부 일지 - 티스토리, accessed July 30, 2025, https://eteo.tistory.com/496
21. RTCA DO-178C와 새로운 RESSAC 소프트웨어 … - Korea Science, accessed July 30, 2025, https://koreascience.kr/article/JAKO202010163508625.pdf
22. DO-178C란? - Ansys, accessed July 30, 2025, https://www.ansys.com/ko-kr/simulation-topics/what-is-do-178c
23. MATLAB 및 Simulink를 사용한 항공우주 인증 표준 준수 - MathWorks, accessed July 30, 2025, https://kr.mathworks.com/solutions/aerospace-defense/certification-standards.html
24. Software Verification Tools Assessment Study - FAA, accessed July 30, 2025, https://www.faa.gov/sites/faa.gov/files/aircraft/air_cert/design_approvals/air_software/AR-06-54_VerificationTools.pdf
25. Ensuring Airborne Software Integrity: An Overview to Avionics Tool Qualification - eInfochips, accessed July 30, 2025, https://www.einfochips.com/blog/ensuring-airborne-software-integrity-an-overview-to-avionics-tool-qualification/
26. DO-254 가이드: RTCA DO-254 표준 인증 소개, accessed July 30, 2025, https://visuresolutions.com/ko/do-254-guide/introduction/
27. RTCA/DO-254는 “항공 전자 하드웨어에 대한 설계 보증 지침(Design Assurance Guidance for Airborne Electronic Hardware)” 에 대한 문서이고, 이 문서의 목적은 구조적이고 엄격한 개발 프로세스를 부과함으로써 기내 하드웨어의 안전을 보장하는 것이며, 업계 전문가들로 구성된 위원회에 의해 개발되었다. 마침내 2005년에 미국의 연방 항공 관리(FAA)와 유럽의 유럽 항공 안전기구(EASA)에서 정책적으로 적용하였고, DO-254 문서는 “전자”의 범위로 작성되었다. 이것은 원래 가장 작은 구성 요소에부터 LRU(Line Replacement Unit)까지 모든 것을 의미한다. 우측 그림은 디자인 보증 전략을 위한 상위 레벨 프로세스를 보이며, 임계 또는 실패 조건은 표준에 의해 설명 된 시스템의 안전성 평가 프로세스를 사용하여 결정된다. 이 과정은 장애의 심각도에 따라 레벨 A에서 레벨 E까지 지정한다. - EDMFG, accessed July 30, 2025, http://www.edmfg.com/solution/do254/
28. DO-254 and DO-178C Traceability Requirements for Defense Electronics, accessed July 30, 2025, https://resources.altium.com/p/do-254-and-do-178c-traceability-requirements-defense-electronics
29. What is a Requirements Traceability Matrix (RTM)? - Perforce Software, accessed July 30, 2025, https://www.perforce.com/resources/alm/requirements-traceability-matrix
30. How to Create and Use a Requirements Traceability Matrix - Jama Software, accessed July 30, 2025, https://www.jamasoftware.com/requirements-management-guide/requirements-traceability/how-to-create-and-use-a-requirements-traceability-matrix/
31. Free Download Requirements Traceability Matrix Template - Meegle, accessed July 30, 2025, https://www.meegle.com/en_us/advanced-templates/project_oversight/requirements_traceability_matrix_template
32. Requirements Traceability Matrix: A Comprehensive Guide With Examples And Best Practices - LambdaTest, accessed July 30, 2025, https://www.lambdatest.com/learning-hub/requirements-traceability-matrix
33. How to Create a Requirements Traceability Matrix - with Examples - Perforce Software, accessed July 30, 2025, https://www.perforce.com/blog/alm/how-create-traceability-matrix
34. Test and Evaluation Master Plan TEMP Template v3.0 - AcqNotes, accessed July 30, 2025, https://acqnotes.com/wp-content/uploads/2018/04/Test-and-Evaluation-Master-Plan-TEMP-Template-v3.0.docx
35. 무기체계 시험평가업무 정량적 관리방안 연구 A Study on the Quantitative Management Scheme of Weapon Systems T& - 한국군사과학기술학회, accessed July 30, 2025, https://www.kimst.or.kr/electronic_paper/pdf_down_other.kin?stype=journal&idx=12658
36. Aerospace Engineering Handbook Chapter 2(v): Flight Test Engineering - NASA Technical Reports Server, accessed July 30, 2025, https://ntrs.nasa.gov/api/citations/20140010192/downloads/20140010192.pdf
37. TEMP and Test Plan Review Examples, accessed July 30, 2025, https://www.dote.osd.mil/Portals/97/pub/presentations/AO%20Training%20Classes/Test%20Design%20Stat%20An/3.5_TEMP_Test_Plan_Review_cw.pdf?ver=2019-09-03-142052-150
38. Hardware in the Loop for Aerospace (HIL) - United Electronic Industries, accessed July 30, 2025, https://www.ueidaq.com/applications/hil
39. System Integration Testing - Gantner Instruments, accessed July 30, 2025, https://www.gantner-instruments.com/applications/aerospace/system-integration-testing/
40. Test Planning, An Integrated Approach - AeroTEC, accessed July 30, 2025, https://aerotec.com/wp-content/uploads/2023/07/integrated-test-planning-sfte.pdf
41. EZ Test Plan Template - Commercial and Defense - CVG Strategy, accessed July 30, 2025, https://cvgstrategy.com/ez-test-plan-template/
42. Testing Aerospace Systems Effectively - Number Analytics, accessed July 30, 2025, https://www.numberanalytics.com/blog/testing-aerospace-systems-effectively
43. A Helpful Guide for What it Takes to Perform Thorough Functional Testing - QualityLogic, accessed July 30, 2025, https://www.qualitylogic.com/knowledge-center/learn-what-it-takes-to-perform-thorough-functional-testing/
44. Hardware Testing Process – How to test products during production - Viewpoint Systems, accessed July 30, 2025, https://www.viewpointusa.com/TM/ar/hardware-testing-process/
45. How To Create A Test Plan (Steps, Examples, & Template) - TestRail, accessed July 30, 2025, https://www.testrail.com/blog/create-a-test-plan/
46. 1. Item Pass/Fail Criteria - Test Plan - Coley Consulting, accessed July 30, 2025, https://www.coleyconsulting.co.uk/passfail.htm
47. Criteria for passing/failing the tests : r/QualityAssurance - Reddit, accessed July 30, 2025, https://www.reddit.com/r/QualityAssurance/comments/1aka67g/criteria_for_passingfailing_the_tests/
48. Avionics Systems Integration & Test - Avionics Interface Technologies - A Teradyne Company, accessed July 30, 2025, https://aviftech.com/systems-integration-test/
49. What is Embedded Testing in Software Testing? - GeeksforGeeks, accessed July 30, 2025, https://www.geeksforgeeks.org/software-testing/what-is-embedded-testing-in-software-testing/
50. What You Need To Know About Avionics System Testing - Sital Technology, accessed July 30, 2025, https://sitaltech.com/what-you-need-to-know-about-avionics-system-testing/
51. 5.3 Product Verification - NASA, accessed July 30, 2025, https://www.nasa.gov/reference/5-3-product-verification/
52. Embedded Software Testing: Tools and Techniques Guide, accessed July 30, 2025, https://fidus.com/blog/mastering-embedded-software-testing-a-complete-guide-to-tools-and-techniques/
53. 국방 무기체계 시험평가 수행체계 개선방안 연구, accessed July 30, 2025, http://journal.kidet.or.kr/archive/view_article?pid=jkidt-5-2-1
54. Automated Testing Techniques for Embedded Software Systems - Codewave, accessed July 30, 2025, https://codewave.com/insights/automated-testing-embedded-software-techniques/