📕항공전자 서베이

항공전자 및 비행제어용 AI 신뢰성 검증에 관한 서베이 자율주행 분야와의 비교를 중심으로 초록

항공전자와 비행제어는 실패 비용이 매우 큰 안전중요(safety-critical) 영역이므로, AI/ML 구성요소를 탑재할 경우 기존의 소프트웨어·하드웨어 인증 체계만으로는 충분하지 않다는 문제가 제기된다. 현재 민항 분야의 기본 축은 DO-178C, DO-254, ARP4754A, ARP4761A, DO-297이며, 연결성·보안 측면은 DO-326A/DO-356A/DO-355 계열이 담당한다. 그러나 FAA와 EASA는 최근 별도의 AI 로드맵과 ML 적용 가이던스를 내놓으면서, 기존 표준 위에 **데이터·모델·운용영역·강건성·모니터링·학습 보증(learning assurance)**을 덧붙이는 방향으로 가고 있다. 자율주행 분야는 이미 ISO 26262, ISO 21448(SOTIF), ISO/PAS 8800, UL 4600, ISO/SAE 21434, UNECE R155/R156/R157 등을 조합해 AI 안전성을 논의해 왔고, 이 경험은 항공 분야의 AI assurance 설계에 중요한 비교 기준이 된다. 본 서베이는 항공과 자율주행의 표준·연구를 비교해, 항공 AI 신뢰성 검증의 핵심 공백과 향후 실무적 프레임워크를 제안한다.

1. 서론

항공 분야에서 AI는 조종사 지원, 상태예지, 센서 융합, 시각 인지, 결함 탐지, 자율 기능 등으로 빠르게 확장되고 있다. 문제는 기존 항공 인증 체계가 결정론적 요구사항-설계-구현-검증 추적성을 중심으로 발전해 왔다는 점이다. 반면 ML은 데이터 의존적이고, 성능이 분포 변화와 운용 맥락에 민감하며, 내부 동작 설명 가능성도 제한적일 수 있다. FAA는 2024년 AI Safety Assurance Roadmap에서 항공 AI 안전 보증을 위한 원칙과 연구 과제를 공식화했고, EASA는 2024년 AI Concept Paper Issue 2와 MLEAP 최종보고서에서 Level 1·2 ML applications에 대한 guidance와 learning assurance 개념을 구체화했다.

자율주행은 이보다 먼저 “전통적 기능안전 + 의도된 기능의 한계 + AI 고유 위험 + 운영 후 업데이트/사이버보안”을 한 묶음으로 다루기 시작했다. 그래서 항공은 자율주행의 표준 구조를 그대로 가져오지는 못하더라도, 표준의 역할 분담 방식과 assurance case 중심 접근에서는 많은 교훈을 얻을 수 있다.

2. 항공 분야의 기존 인증 기반 2.1 시스템·안전·소프트웨어·하드웨어의 기본 축

민항 항공전자/비행제어의 기존 인증 체계는 대체로 다음 역할 분담을 가진다. ARP4754A는 항공기/시스템 개발 지침, ARP4761A는 안전평가 프로세스, DO-178C는 airborne software, DO-254는 airborne electronic hardware, DO-297은 IMA 환경의 역할·책임·통합 assurance를 다룬다. RTCA와 SAE의 공식 설명도 이 역할 구분을 그대로 보여준다. 즉, 항공에서 AI를 다룬다고 해도 기존 체계가 사라지는 것이 아니라, 오히려 그 위에 AI-specific assurance가 올라가는 구조다.

이 프레임의 강점은 이미 항공 분야에서 광범위하게 받아들여진 DAL 기반 개발 보증, 요구사항 추적성, 독립 검증, 안전평가 연계가 존재한다는 점이다. 하지만 ML 구성요소는 “요구사항을 코드가 직접 구현한다”기보다 “데이터를 통해 함수 근사기를 학습한다”는 특성이 강하므로, DO-178C의 많은 목표가 그대로 적용되기 어렵다는 지적이 반복적으로 제기된다. NASA와 FAA 관련 보고서들도 이 점을 핵심 문제로 본다.

2.2 보안과 연결성의 축

AI를 항공전자나 비행제어에 적용할 때는 안전성만이 아니라, 데이터 신뢰성·센서 스푸핑·통신 위협·모델/데이터 변조도 함께 봐야 한다. 이 측면에서 항공의 공식 축은 DO-326A(airworthiness security process), DO-356A(보안 방법/고려사항), DO-355(continued airworthiness security)다. RTCA는 DO-326A가 항공기 설계·인증 과정에서 보안 위협을 관리하는 핵심 요구를 제시하고, DO-356A가 이를 달성하기 위한 구체적 방법을 제공한다고 명시한다.

AI가 들어간 센서 인지나 데이터링크 의사결정은 adversarial perturbation, spoofing, data poisoning, model tampering에 취약할 수 있으므로, 향후 항공 AI assurance는 safety case + security case의 결합 형태로 갈 가능성이 높다. 특히 비행제어 주변에서 AI를 쓰는 경우에는 단순 정확도보다 보안 위협 하의 안전한 한계 행동이 중요하다. 이 점은 FAA, EASA, RTCA 모두 점점 더 강조하는 방향과 맞닿아 있다.

3. 항공 AI 전용 guidance의 최신 흐름 3.1 FAA AI Safety Assurance Roadmap

FAA의 2024 Roadmap은 현재 항공 AI assurance 논의의 가장 중요한 공식 기준점 중 하나다. FAA는 이 문서에서 AI 적용을 위한 안전 보증 원칙을 제시하고, 연구 방향으로 AI 안전 assurance 방법 개발, lifecycle monitoring, AI를 활용한 safety enhancement, certification framework 정립 등을 제시했다. 특히 이 문서가 “living document”라고 명시된 점은, 항공 AI assurance가 아직 완성된 단일 표준보다 진화 중인 규범 체계라는 뜻이다.

FAA 로드맵의 실무적 의미는 크다. 첫째, 기존 DO-178C/DO-254 체계만으로는 ML 특성을 다 커버하지 못함을 사실상 인정했다. 둘째, 항공 AI 검증은 단순한 test accuracy나 benchmark score가 아니라 운용 맥락, 데이터 representativeness, failure modes, monitoring and mitigation까지 포함하는 종합 assurance 문제라고 본다. 셋째, 개발 시점만이 아니라 운용 시점의 지속적 assurance가 필요하다는 방향을 분명히 했다.

3.2 EASA AI Concept Paper Issue 2와 MLEAP

EASA의 2024 AI Concept Paper Issue 2는 항공 ML application approval을 위한 보다 구체적인 기술 언어를 제시한다. EASA는 특히 Level 1 & 2 machine learning applications를 대상으로, operational context와 ODD 유사 개념, trustworthiness objective, W-shaped learning process 등으로 접근한다. 이어 MLEAP 최종보고서는 이 개념을 실제 방법과 도구 추천으로 확장했다.

EASA/MLEAP의 핵심은 “ML 모델 자체”보다 ML 구성요소가 속한 시스템의 운용 개념(ConOps), operational domain, data lifecycle, 검증 evidence 구조를 먼저 정의한다는 데 있다. 이는 자율주행의 ODD, SOTIF, safety case 논리와 상당히 닮아 있다. 따라서 향후 항공 AI assurance의 중심 축은 “DO-178C를 ML용으로 억지 적용”하는 방식보다, 시스템 수준 assurance case에 ML evidence를 결합하는 구조가 될 가능성이 크다.

3.3 EUROCAE WG-114 / SAE G-34

EUROCAE WG-114와 SAE G-34는 AI in Aviation에 대한 공통 표준화 포럼이며, 항공 AI의 선택·구현·인증을 지원하는 기술보고서와 프로세스 문서를 개발 중이다. EUROCAE는 WG-114의 목적을 “aeronautical systems에 탑재되거나 함께 쓰이는 AI 기술의 선택·구현·인증을 위한 technical reports 개발”로 설명하고, SAE도 G-34가 AI in Aviation 관련 기술보고서를 유지·개발하는 위원회라고 밝힌다. 2024년 말에는 양 기관이 AI taxonomy 문서를 공동 발행했다고 발표했다.

즉, 항공 AI 인증은 아직 DO-178C처럼 고정된 단일 규격이 아니라, **FAA/EASA 정책 문서 + WG-114/G-34 표준화 작업 + 연구 프로젝트(MLEAP 등)**가 함께 형성하는 단계라고 보는 것이 정확하다.

4. 항공 AI assurance 연구 동향 4.1 기존 표준과 ML의 “불일치”를 다루는 연구

NASA/DLR/TUM 계열 연구는 반복적으로 같은 문제를 지적한다. ML 기반 airborne system은 완전한 요구사항 기술의 어려움, 데이터 기반 개발, 설명 가능성 부족, 비정상 입력·분포 이동 대응, 학습 재현성/구성관리 때문에 기존 design assurance 방식과 충돌한다. “Toward Design Assurance of Machine-Learning Airborne Systems”는 runway sign recognition 사례를 통해 DO-178C 식 certification challenges를 보여주고, “Toward Certification of Machine-Learning Systems for Low Criticality Airborne Applications”는 특정 가정 아래 저위험/저중요도 application에서는 표준 목표 달성이 가능할 수 있다고 본다.

이 계열 연구의 메시지는 꽤 일관적이다. 모든 ML을 일괄 금지/허용하는 방식은 비현실적이며, criticality·기능 범위·감시구조·fallback architecture에 따라 점진적으로 허용범위를 넓혀야 한다는 것이다. 실제로 최근 연구는 DAL B/C/D 수준의 적용 가능성, hybrid architecture, architectural mitigation을 통한 assurance 확보 쪽으로 많이 기울어 있다.

4.2 Overarching Properties(OP)와 goal-based assurance

FAA/NASA 관련 보고서 “Assurance of Machine Learning-Based Aerospace Systems”는 대안적 means of compliance로 Overarching Properties(OP) 중심 접근을 다룬다. 이 접근은 특정 구현 기술보다 **시스템이 만족해야 할 상위 성질(properties)**를 정의하고, hazard analysis와 evidence를 연결해 safety case를 구축하려는 방향이다. 이는 ML처럼 내부 구현이 전통 규범과 다를 때 특히 유용하다.

항공 AI에 OP 접근이 매력적인 이유는, 비행제어 보조·인지 지원·결정지원 등 서로 다른 ML application에 공통 적용 가능한 상위 assurance 언어를 제공할 수 있기 때문이다. 다만 아직까지는 연구·시범적 성격이 강하고, 규제기관 accepted practice로 완전히 굳어졌다고 보기는 어렵다.

4.3 Run-Time Assurance(RTA)

AI를 비행제어나 항공전자에 넣을 때 가장 현실적인 안전장치 중 하나는 Run-Time Assurance다. ASTM F3269는 복잡 기능을 포함한 항공 시스템의 행동을 실시간으로 안전 한계 안에 묶기 위한 아키텍처 프레임워크를 제시한다. ASTM은 이를 “design-time assurance의 대안으로서 runtime assurance를 제공하는 architectural framework”라고 설명한다.

이 방식은 특히 ML이 “주 기능(primary or advanced function)”을 수행하되, 별도의 고신뢰 감시장치와 안전 컨트롤러가 한계 위반 시介入하는 구조에 잘 맞는다. NASA 자료 역시 항공 AI에서 RTA를 실용적 해법으로 제시해 왔고, 연구 차원에서는 aircraft taxiing 등 learning-enabled systems에 RTA를 적용한 예시가 존재한다.

4.4 체계적 리뷰 및 서베이

ML safety assurance 일반론에서는 2022년 systematic literature review가 AI-based systems safety assurance 문헌 329건을 직접 분석했고, 2025년 automated vehicles AI safety assurance survey는 연구·표준·규제의 상호작용을 한 번에 다루려 했다. 항공 특화 리뷰도 2024~2026년에 증가하고 있다. 다만 항공 특화 review의 상당수는 아직 “문제 제기와 프레임 정리” 수준이 많고, 구체적 accepted verification recipe까지 정리된 경우는 드물다.

5. 자율주행 분야는 어떤 표준으로 AI 신뢰성 검증을 하나 5.1 기능안전: ISO 26262

자율주행에서 가장 기본이 되는 축은 ISO 26262다. ISO는 이 표준이 road vehicles의 E/E safety-related systems에 대한 functional safety framework를 제공한다고 설명한다. 핵심은 hazard analysis와 ASIL(Automotive Safety Integrity Level)에 따라 lifecycle 전반의 안전 요구를 관리하는 것이다.

하지만 ISO 26262는 기본적으로 malfunctioning behaviour, 즉 고장 기반 위험을 다루는 표준이다. 그래서 perception AI처럼 “고장은 아니지만 의도된 기능이 상황적으로 부족해서 생기는 위험”은 충분히 커버하지 못한다는 한계가 있었다. 이 틈을 메우기 위해 나온 것이 SOTIF다.

5.2 의도된 기능 안전: ISO 21448 (SOTIF)

ISO 21448은 SOTIF, 즉 Safety of the Intended Functionality를 다룬다. ISO는 이를 “hazard caused by functional insufficiencies”와 reasonably foreseeable misuse로 인한 unreasonable risk의 부재라고 정의한다. 쉽게 말해 시스템이 고장 나지 않았더라도, 인지·판단 기능이 특정 환경에서 본질적으로 부족하면 생기는 위험을 다루는 표준이다. 자율주행 perception과 decision-making AI에 매우 중요하다.

항공 AI에도 이 개념은 매우 중요하다. 예를 들어 시각 기반 활주로 표지 인식, 영상 기반 obstacle detection, GNSS/vision-aided navigation ML은 “fault-free but unsafe” 상황이 가능하다. 따라서 항공은 아직 공식적으로 SOTIF를 그대로 채택하진 않았지만, 실질적 문제 구조는 상당히 유사하다. 이 점이 자율주행 표준을 항공에 참고해야 하는 가장 큰 이유다.

5.3 AI 안전 전용: ISO/PAS 8800

ISO/PAS 8800:2024는 safety-related vehicle systems에 사용되는 AI에 대한 framework를 제공하며, ISO는 이 문서가 ISO 26262와 ISO 21448을 tailoring/extension하는 방식이라고 설명한다. 즉 자동차 분야에서는 이미 “기능안전 + SOTIF + AI 전용 추가 요구”라는 3층 구조가 형성되고 있다.

이 점은 항공 분야에 직접적 시사점을 준다. 항공도 결국 ARP4754A/ARP4761A/DO-178C/DO-254를 버리는 것이 아니라, 그 위에 AI-specific extension layer를 얹는 쪽으로 갈 가능성이 높다. EASA Concept Paper와 MLEAP도 사실상 같은 방향이다.

5.4 Safety case 중심: UL 4600

UL 4600은 자율 제품, 특히 자율주행차의 safety evaluation을 위한 goal-based, technology-agnostic 표준으로 잘 알려져 있다. UL과 관련 설명 자료는 이 표준이 특정 기술을 강제하지 않고, autonomous product가 안전하게 설계·개발·검증되었음을 **안전사례(safety case)**로 입증하는 구조라고 설명한다. ML 기반 기능 검증도 여기에 포함된다.

항공 AI가 UL 4600을 그대로 채택하진 않더라도, assurance case / claims-arguments-evidence 구조는 항공에도 매우 유용하다. 실제 AMLAS나 OP 접근, EASA learning assurance 역시 결국 같은 방향의 논리 구조를 갖는다.

5.5 사이버보안·업데이트·형식승인

자율주행차에서는 AI safety만 따로 떼어 보지 않는다. ISO/SAE 21434가 차량 E/E 시스템의 lifecycle cybersecurity engineering을, UNECE R155가 cybersecurity management system, UNECE R156이 software update management system, UNECE R157이 ALKS 형식승인 요구를 다룬다.

이 조합은 항공에 중요한 힌트를 준다. 즉, AI assurance는 “모델이 잘 맞느냐”만의 문제가 아니라, 보안·업데이트·configuration control·운용 후 변경 승인을 함께 다뤄야 한다는 것이다. 항공의 DO-326A/DO-355 계열과도 구조적으로 평행성이 있다.

6. 항공과 자율주행의 비교 6.1 공통점

양 분야 모두 AI 안전성 검증에서 다음 요소를 공통적으로 중시한다. 첫째, 운용영역 정의. 자동차의 ODD, 항공의 operational domain/ConOps 개념은 사실상 같은 문제를 다룬다. 둘째, 데이터 거버넌스. 대표성, 품질, 편향, 분포 이동, OOD 대응이 핵심이다. 셋째, assurance case. 테스트 점수만으로 충분치 않으며, 위험원-주장-증거 연결이 필요하다. 넷째, runtime monitoring and mitigation. 특히 복잡한 ML에서는 design-time proof만으로 부족하다.

6.2 차이점

다만 차이도 크다. 항공은 이미 매우 성숙한 certification ecosystem을 가지고 있고, catastrophic failure tolerance가 극도로 낮다. 따라서 자율주행보다 보수적 도입과 고신뢰 아키텍처 분리를 선호할 가능성이 높다. 반면 자율주행은 다양한 도로 환경과 빠른 소프트웨어 업데이트를 전제로 해, 더 빠르게 safety case·SOTIF·continuous validation 구조를 발전시켰다.

실무적으로 보면, 항공에서 AI는 당분간 보조/감시/예지/인지 지원처럼 제한된 역할부터 확대될 공산이 크고, 폐루프 비행제어에 직접 깊게 들어가는 경우에는 RTA, formal guard, fallback channel, envelope protection 같은 architectural mitigation이 사실상 필수에 가깝다.

7. 항공전자/비행제어 AI 신뢰성 검증을 위한 제안 프레임워크 7.1 1단계: 시스템 수준 안전/기능 배치

우선 AI를 “어디에 쓸지”가 중요하다. 항공은 기능 자체의 criticality allocation이 먼저다. ARP4754A/ARP4761A 체계 아래에서 AI 기능을 시스템 기능으로 배치하고, FHA/PSSA/SSA 맥락에서 hazard contribution을 분석해야 한다. 이때 “AI를 안 쓰면 대체 아키텍처가 있는가”, “AI failure가 즉시 hazard로 이어지는가”, “crew or automation monitor가 있는가”를 먼저 따져야 한다.

7.2 2단계: AI/ML 구성요소의 operational domain 명세

EASA와 MLEAP 흐름에 맞춰, 항공도 AI/ML constituent에 대해 ConOps, operational domain, admissible input envelope, expected nuisance/failure behaviour를 명시해야 한다. 이것이 없으면 데이터셋 adequacy, robustness, OOD 검증 기준을 세울 수 없다.

7.3 3단계: 데이터·모델 assurance

이 단계에서는 다음 항목이 필요하다. 데이터 provenance, labeling quality, train/validation/test independence, corner-case coverage, OOD stress tests, adversarial/spoofing tests, retraining configuration control, reproducibility, uncertainty calibration 등이다. FAA와 EASA 문서, 그리고 항공 ML 연구는 모두 “dataset and model lifecycle evidence”를 중요하게 본다.

7.4 4단계: 아키텍처적 안전장치

AI를 비행제어 인근에 둘수록, RTA monitor, independent safety controller, cross-check with physics/rule-based channel, envelope protection, degradation mode가 필요하다. ASTM F3269는 바로 이런 runtime bounding architecture를 다루며, 항공 AI의 초기 인증 가능성을 높여 주는 실용적 도구다.

7.5 5단계: safety-security 통합 assurance

AI가 센서·통신·데이터링크에 연결될수록, safety case만으로는 부족하다. DO-326A/DO-356A에 따라 spoofing, malicious data injection, model tampering을 포함한 security threats를 함께 hazard chain에 넣어야 한다. 자율주행의 ISO/SAE 21434 + UNECE R155/R156 조합이 참고 모델이 될 수 있다.

7.6 6단계: assurance case로 통합

최종적으로는 UL 4600, AMLAS, OP 접근처럼 claims–arguments–evidence 구조로 정리하는 것이 바람직하다. 예를 들면 “AI-based perception function is acceptably safe within defined operational domain” → “domain is bounded and justified” → “dataset is representative” → “model is robust to relevant disturbances” → “runtime monitor bounds residual risk” → “security threats are mitigated” 같은 논리로 안전사례를 구축하는 방식이다.

8. 핵심 연구 공백

첫째, 항공에는 아직 AI 전용의 성숙한 accepted means of compliance가 없다. FAA roadmap와 EASA guidance는 방향 제시 단계에 가깝다.

둘째, SOTIF에 대응하는 항공 내 명시적 프레임이 약하다. 항공도 perception/ML 한계로 인한 위험을 체계적으로 다룰 언어가 더 필요하다.

셋째, 데이터와 모델의 configuration control·change approval 문제가 아직 충분히 정리되지 않았다. retraining과 dataset drift를 기존 항공 변경승인 체계에 어떻게 넣을지가 큰 이슈다.

넷째, multicore/IMA/분산환경과 AI assurance의 결합도 더 연구가 필요하다. IMA와 mixed-criticality, multicore timing predictability 자체가 여전히 활발한 연구 주제이며, 여기에 AI 가속기나 복잡 inference chain이 들어가면 timing/safety/security coupling이 더 어려워진다.

9. 결론

항공전자와 비행제어에 AI를 넣을 때의 신뢰성 검증은, 단순히 “DO-178C를 AI에 적용할 수 있느냐”의 문제가 아니다. 실제로는 기존 항공 인증 축(ARP4754A/ARP4761A/DO-178C/DO-254/DO-297) 위에, AI-specific guidance(FAA Roadmap, EASA Concept Paper, MLEAP, WG-114/G-34), 그리고 runtime assurance, assurance case, data/model governance, security integration을 덧붙이는 문제다.

자율주행 분야는 이미 ISO 26262, SOTIF, ISO/PAS 8800, UL 4600, ISO/SAE 21434, UNECE R155/R156/R157을 조합해 이 문제를 풀어 가고 있다. 항공은 규제 강도가 더 높고 보수적이지만, 구조적으로는 비슷한 방향으로 움직이고 있다. 따라서 향후 항공 AI assurance의 가장 현실적인 경로는 저위험 기능부터 시작해, bounded operational domain, architectural mitigation, runtime assurance, assurance case 기반 evidence 축적을 통해 점진적으로 확대하는 방식이라고 볼 수 있다.

참고문헌 성격의 핵심 자료 선정 항공 쪽 우선 읽기 FAA, Roadmap for Artificial Intelligence Safety Assurance (2024). EASA, Artificial Intelligence Concept Paper Issue 2 (2024). EASA, MLEAP Final Report / Executive Summary (2024). NASA/Dmitriev et al., Toward Design Assurance of Machine-Learning Airborne Systems (2022). FAA/NASA/GE, Assurance of Machine Learning-Based Aerospace Systems (2023). ASTM F3269 Run-Time Assurance. 기존 항공 인증 기반 RTCA DO-178C. RTCA DO-254. SAE ARP4754A. SAE ARP4761A. RTCA DO-297. RTCA DO-326A / DO-356A / DO-355. 자율주행 비교축 ISO 26262. ISO 21448 (SOTIF). ISO/PAS 8800. UL 4600. ISO/SAE 21434. UNECE R155 / R156 / R157. AMLAS methodology.