자율 임무 드론의 감항 인증을 위한 QNX 플랫폼 (DO-178C 및 ISO 21384-3 대응 전략)

2025-11-28, G30DR

1. 서론: 항공 모빌리티의 패러다임 전환과 인증의 장벽

1.1 무인 항공 시스템(UAS)의 부상과 기술적 난제

21세기 항공 산업은 유인 항공기 중심의 체계에서 무인 항공 시스템(UAS: Unmanned Aircraft Systems) 및 도심 항공 모빌리티(UAM: Urban Air Mobility)로의 급격한 패러다임 전환을 맞이하고 있다. 과거 군사용으로 제한되었던 드론 기술은 이제 물류 배송, 인프라 점검, 정밀 농업, 그리고 인명 수송(Air Taxi)에 이르기까지 산업 전반으로 확장되고 있다. 특히 조종사의 개입 없이 복잡한 도심 환경에서 임무를 수행해야 하는 ’자율 임무 드론’은 기존 항공기와는 차원이 다른 기술적 복잡성을 요구한다.1

자율 임무 드론은 고도의 환경 인지(Perception), 경로 계획(Path Planning), 그리고 실시간 비행 제어(Flight Control)를 동시에 수행해야 한다. 이를 위해서는 라이다(LiDAR), 레이더, 고해상도 카메라 등 다양한 센서에서 유입되는 대용량 데이터를 처리할 수 있는 고성능 컴퓨팅 파워가 필수적이다. 동시에, 항공기의 자세를 제어하고 추락을 방지하기 위한 제어 루프는 엄격한 실시간성(Real-time Determinism)을 보장해야 한다. 이 두 가지 상충되는 요구사항—고성능 연산과 결정론적 실시간성—을 제한된 중량과 전력(SWaP: Size, Weight, and Power) 내에서 구현하는 것이 현대 드론 개발의 핵심 난제이다.3

더욱이, 이러한 시스템은 단순히 기술적으로 작동하는 것을 넘어, 항공 규제 당국이 요구하는 안전성 기준을 충족해야 한다. 항공 사고는 지상의 인명과 재산에 치명적인 피해를 줄 수 있으므로, 규제 기관들은 무인기에도 유인 항공기에 준하는, 혹은 그 이상의 엄격한 감항 인증(Airworthiness Certification)을 요구하고 있다. 이는 소프트웨어의 오류 하나가 재앙적인 결과로 이어지지 않음을 수학적, 공학적으로 증명해야 함을 의미한다.

1.2 인증의 복잡성과 표준의 진화

항공 소프트웨어 인증의 사실상 표준(De facto Standard)인 RTCA DO-178C는 소프트웨어 개발 생명주기 전반에 걸친 엄격한 검증을 요구한다.4 그러나 전통적인 연합형 아키텍처(Federated Architecture)—각 기능을 별도의 하드웨어로 분리하는 방식—는 소형 드론에 적용하기에는 너무 무겁고 비효율적이다. 따라서 현대 드론은 다수의 기능을 하나의 고성능 칩(SoC)에 통합하는 통합 모듈형 항공전자(IMA) 아키텍처를 지향하게 되는데, 이는 서로 다른 중요도(Criticality)를 가진 소프트웨어 간의 간섭(Interference) 문제를 야기한다.3

한편, 국제표준화기구(ISO)는 무인기의 안전한 운영을 위해 ISO 21384-3 표준을 제정하였다.1 이 표준은 시스템의 기술적 상세보다는 운영 절차와 안전 관리 시스템(SMS)에 초점을 맞추고 있으나, 그 기저에는 신뢰할 수 있는 비행 제어 시스템이 전제되어야 한다. 즉, 드론 제조사는 ISO 21384-3을 준수하기 위해 DO-178C 레벨의 검증된 소프트웨어를 사용해야 하는 이중고에 직면해 있다.

1.3 연구의 목적 및 범위

본 보고서는 자율 임무 드론이 직면한 이러한 인증의 난제를 해결하기 위해 BlackBerry QNX의 실시간 운영체제(RTOS) 및 하이퍼바이저 기술을 어떻게 적용할 수 있는지 심층적으로 분석한다. QNX는 자동차(ISO 26262), 산업(IEC 61508), 의료(IEC 62304) 등 다양한 미션 크리티컬 분야에서 검증된 이력을 보유하고 있으며, 최근 항공우주 분야로 그 영역을 확장하고 있다.7

본 연구에서는 다음과 같은 핵심 질문에 답하고자 한다.

1. 규제 부합성: QNX의 마이크로커널 아키텍처는 DO-178C와 ISO 21384-3의 안전 요구사항을 어떻게 기술적으로 충족하는가?
2. 기술적 구현: 혼합 중요도 시스템에서 QNX Hypervisor는 어떻게 비행 제어(Safety)와 임무 컴퓨터(Mission) 간의 간섭 없는 자유(Freedom From Interference)를 보장하는가?
3. 인증 전략: 드론 개발사는 QNX가 제공하는 인증 아티팩트(Artifacts)를 활용하여 어떻게 인증 비용과 시간을 절감할 수 있는가?
4. 산업 동향: Joby Aviation, Vertical Aerospace 등 선도 기업들은 어떠한 방식으로 QNX를 활용하고 있는가?

이 보고서는 도메인 전문가의 시각에서 기술적 메커니즘을 상세히 설명하고, 실제 인증 과정에서 발생할 수 있는 이슈와 해결 방안을 제시함으로써, 자율 드론 개발자 및 인증 전문가들에게 실질적인 가이드를 제공하는 것을 목표로 한다.

2. 자율 비행 시스템의 안전성 및 인증 요구사항 심층 분석

2.1 RTCA DO-178C: 항공 소프트웨어의 바이블

DO-178C “Software Considerations in Airborne Systems and Equipment Certification“은 미 연방항공청(FAA)과 유럽항공안전청(EASA)을 포함한 전 세계 주요 항공 당국이 소프트웨어 승인을 위해 참조하는 주된 문서이다.4 이 표준은 소프트웨어가 안전하게 동작함을 보장하기 위해 ’요구사항 기반 테스트(Requirements-Based Testing)’와 ’구조적 커버리지 분석(Structural Coverage Analysis)’을 강조한다.

2.1.1 설계 보증 레벨 (DAL: Design Assurance Level)

DO-178C는 시스템 안전성 평가(SSA: System Safety Assessment) 결과에 따라 소프트웨어의 실패가 기체에 미치는 영향을 5단계(Level A~E)로 분류한다.9 자율 임무 드론의 경우, 조종사가 탑승하지 않거나 도심 상공을 비행하므로 그 기준이 매우 엄격하다.

자율 드론의 **비행 제어 컴퓨터(FCC)**는 예외 없이 DAL A 또는 DAL B 수준을 요구받는다. 이는 소스 코드의 모든 라인이 요구사항과 추적되어야 하며(Traceability), 분기(Branch) 및 조건(Condition) 커버리지를 포함한 엄격한 테스트가 수행되어야 함을 의미한다. 특히 DAL A의 경우, 컴파일러가 생성한 오브젝트 코드(Object Code)와 소스 코드 간의 일치성까지 검증해야 하는 등 극도의 엄격함을 요구한다.

2.1.2 인증을 위한 핵심 프로세스 및 아티팩트

DO-178C 인증을 위해서는 단순히 코드를 잘 짜는 것뿐만 아니라, 계획부터 검증까지의 모든 과정을 문서화해야 한다. 주요 아티팩트는 다음과 같다.9

• PSAC (Plan for Software Aspects of Certification): 인증을 어떻게 받을 것인지에 대한 계획서. 사용할 OS, 언어, 툴, 프로세스 등을 정의한다. QNX를 사용할 경우, 이 문서에 QNX가 상용 COTS 소프트웨어로서 어떻게 검증되었는지를 명시해야 한다.
• SRS (Software Requirements Data): 소프트웨어 요구사항 명세서.
• SDD (Software Design Description): 아키텍처 및 상세 설계서.
• SVR (Software Verification Results): 테스트 케이스, 절차, 결과 및 커버리지 분석 보고서.
• SCI (Software Configuration Index): 소프트웨어 형상 관리 목록.
• SAS (Software Accomplishment Summary): 모든 계획된 활동이 완료되었음을 요약하는 최종 보고서.

QNX와 같은 상용 OS를 사용할 때 가장 큰 문제는 OS 내부의 소스 코드나 설계 문서를 개발자가 직접 수정하거나 볼 수 없다는 점이다. 따라서 OS 공급사가 이러한 아티팩트를 ‘패키지’ 형태로 제공하거나, 신뢰할 수 있는 제3자 인증 기관의 인증서를 통해 이를 갈음할 수 있는지가 매우 중요하다.

2.2 ISO 21384-3: 무인기 운영 안전의 국제 표준

ISO 21384-3 “Unmanned aircraft systems — Part 3: Operational procedures“는 UAS의 상용 운영을 위한 국제 표준으로, 기체의 기술적 인증보다는 운영 절차와 안전 관리 시스템(SMS)에 중점을 둔다.1 그러나 이 표준은 운영의 안전을 보장하기 위해 기체의 ‘감항성(Airworthiness)’ 유지를 요구하며, 이는 필연적으로 소프트웨어 신뢰성과 연결된다.

• 위험 기반 접근 (Risk-based Approach): SORA(Specific Operations Risk Assessment)와 연계하여 운영의 위험도에 따라 기체에 요구되는 안전 무결성 수준을 결정한다. 인구 밀집 지역 비행이나 비가시권(BVLOS) 비행과 같은 고위험 임무에서는 DO-178C 수준의 소프트웨어 보증이 요구된다.12
• 안전 및 보안 (Safety and Security): ISO 21384-3은 물리적 안전뿐만 아니라 사이버 보안을 강조한다. 데이터 링크 보호, 비인가 접근 차단, 로그 기록 보존 등이 요구되며, 이는 OS 레벨에서의 강력한 접근 제어와 보안 부팅 기능을 필요로 한다.
• 비상 절차 (Emergency Procedures): 통신 두절, GNSS 상실, 동력 상실 등 비상 상황에서 기체가 자율적으로 안전하게 착륙하거나 체공할 수 있는 능력을 요구한다. 이를 위해서는 주 제어 컴퓨터가 다운되더라도 백업 시스템이 즉시 개입하거나, OS가 결함을 격리하고 재부팅하는 ’회복탄력성(Resilience)’이 필수적이다.

2.3 보안과 안전의 융합 (Safety-Security Convergence)

현대의 자율 드론은 ‘연결된(Connected)’ 디바이스이다. 지상 관제소(GCS), 클라우드 서버, 다른 드론(V2V)과 끊임없이 통신한다. 이는 해킹의 위협에 노출됨을 의미하며, 보안이 뚫리면 안전도 무너진다(If it’s not secure, it’s not safe).13

예를 들어, 해커가 드론의 모터 제어 권한을 탈취한다면, 아무리 견고한 비행 제어 알고리즘도 무용지물이 된다. 따라서 DO-178C(안전)와 DO-326A(항공 사이버 보안) 또는 ISO 21434(자동차 사이버 보안, 드론에도 참조됨)를 동시에 고려해야 한다. QNX는 이러한 보안 요구사항을 충족하기 위해 심층 방어(Defense in Depth) 전략을 OS 아키텍처 내재화하고 있다.

3. QNX Neutrino RTOS의 아키텍처와 안전 메커니즘

자율 드론의 인증 전략을 수립하기 위해서는 QNX Neutrino RTOS의 핵심인 마이크로커널(Microkernel) 아키텍처가 어떻게 항공 안전 표준의 철학을 기술적으로 구현하는지 이해해야 한다.

3.1 마이크로커널 아키텍처: 결함 격리의 토대

리눅스와 같은 모놀리식(Monolithic) 커널은 파일 시스템, 네트워크 스택, 디바이스 드라이버 등 방대한 코드가 하나의 커널 메모리 공간에서 실행된다. 이는 성능면에서는 이점이 있을 수 있으나, 안전성 측면에서는 취약점을 가진다. 와이파이 드라이버의 작은 버그가 커널 메모리를 침범하여 시스템 전체를 패닉(Panic) 상태로 만들 수 있기 때문이다.13 비행 중인 드론에게 이는 치명적이다.

반면, QNX는 커널의 기능을 최소화(스케줄링, 인터럽트 처리, 타이머, IPC)하고, 나머지 모든 서비스(파일 시스템, 네트워크, 드라이버, 응용 프로그램)를 사용자 공간(User Space)의 독립된 프로세스로 실행한다.

• 메모리 보호 (Memory Protection): 각 프로세스는 MMU(Memory Management Unit)에 의해 보호되는 고유의 가상 주소 공간을 가진다. 어떤 컴포넌트도 다른 컴포넌트의 메모리에 접근할 수 없다.
• 결함 격리 (Fault Containment): 예를 들어, 자율 드론의 카메라 드라이버 프로세스가 충돌하더라도, 이는 해당 프로세스만 종료될 뿐 커널이나 비행 제어 프로세스에는 영향을 주지 않는다.
• 자가 치유 (Self-Healing): QNX의 고가용성 관리자(HAM: High Availability Manager)는 프로세스의 상태를 감시하다가 비정상 종료를 감지하면, 밀리초(ms) 단위로 해당 프로세스만 재시작할 수 있다. 이는 ISO 21384-3에서 요구하는 ’지속적인 운영 능력’을 보장하는 핵심 기술이다.15

3.2 결정론적 실시간 성능과 스케줄링

자율 드론의 제어 루프는 엄격한 데드라인을 준수해야 한다. 센서 데이터를 읽고, 자세를 계산하고, 모터 출력을 조절하는 과정이 정해진 주기(예: 400Hz) 내에 완료되지 않으면 기체는 불안정해진다. QNX는 선점형 커널(Preemptive Kernel)을 통해 높은 우선순위의 작업이 언제든지 CPU를 즉시 점유할 수 있도록 보장한다.

3.2.1 적응형 파티셔닝 스케줄러 (APS)

드론 시스템에서 리눅스 기반의 AI 프로세스(비안전 영역)와 RTOS 기반의 제어 프로세스(안전 영역)가 공존할 때, AI 프로세스가 CPU 자원을 독점하여 제어 프로세스를 기아 상태(Starvation)로 만드는 것을 방지해야 한다. QNX의 APS(Adaptive Partitioning Scheduler)는 이를 위한 강력한 해결책이다.16

• 최소 예산 보장: 시스템 설계자는 각 파티션(예: Flight Control 파티션, Mission 파티션)에 최소 CPU 예산을 할당한다 (예: Flight Control 30%, Mission 70%). 시스템 부하가 100%에 달해도 Flight Control 파티션은 30%의 CPU 시간을 절대적으로 보장받는다.
• 유연한 자원 활용: 만약 Flight Control 파티션이 할당된 30%를 다 쓰지 않고 유휴 상태라면, APS는 남는 자원을 Mission 파티션에 동적으로 할당한다. 이는 고정 시간 분할(Fixed Time Partitioning) 방식의 비효율성을 해결하면서도, ARINC 653과 유사한 수준의 시간적 격리(Temporal Isolation)를 제공한다. 이는 DO-178C 인증 시 ’강력한 파티셔닝’을 입증하는 근거가 된다.

3.3 메시지 전달(Message Passing) 기반 IPC

QNX의 모든 프로세스 간 통신은 메시지 전달 방식을 사용한다.14 MsgSend(), MsgReceive(), MsgReply()로 이루어진 이 동기적 통신 구조는 다음과 같은 이점을 제공한다.

• 명확한 인터페이스: 데이터 흐름이 명시적이어서 시스템의 동작을 추적하고 디버깅하기 쉽다.
• 네트워크 투명성: 로컬 프로세스 간 통신이나 네트워크를 통한 원격 프로세스 간 통신이나 동일한 코드를 사용한다. 이는 분산형 아키텍처를 가진 대형 드론 시스템 설계 시 유리하다.
• 병목 현상 방지: 메시지 복사 오버헤드를 줄이기 위해 소형 메시지는 레지스터를 통해 전달하거나, 대용량 데이터는 공유 메모리 참조를 통해 전달하는 등 최적화되어 있다.

3.4 QNX OS for Safety 2.2: 인증된 베이스라인

항공 인증을 위해 개발자가 OS 커널을 직접 검증하는 것은 불가능에 가깝다. ’QNX OS for Safety 2.2’는 이러한 부담을 덜어주기 위해 사전 인증된(Pre-certified) 상태로 제공된다.7

• 인증 범위: ISO 26262 ASIL D (자동차), IEC 61508 SIL 3 (산업용). 비록 DO-178C 직접 인증은 아니지만, 이들 표준은 DO-178C와 유사한 수준의 엄격함을 요구하므로, QNX 커널의 설계 품질과 안전성을 보증하는 강력한 근거가 된다.
• 구성 요소: 안전 인증된 마이크로커널, 프로세스 관리자, 안전 인증된 C 라이브러리(libc), 그리고 ASIL B 등급의 C++ 라이브러리가 포함된다. 특히 C++ 라이브러리의 안전 인증은 객체 지향 프로그래밍을 사용하는 현대 드론 소프트웨어 개발에 큰 이점을 제공한다.

4. 혼합 중요도 시스템과 QNX Hypervisor 기술

자율 임무 드론은 고성능 AI(상황 인식, SLAM)와 고신뢰성 제어(비행 자세 제어)가 하나의 칩에서 공존해야 하는 ‘혼합 중요도(Mixed-Criticality)’ 시스템이다. 이를 물리적으로 분리하는 것은 무게와 전력 소모를 증가시키므로, 가상화를 통한 논리적 통합이 필수적이다.

4.1 가상화를 통한 시스템 통합 아키텍처

QNX Hypervisor는 Type 1 하이퍼바이저로서 하드웨어(베어메탈) 위에서 직접 실행되며, 여러 개의 가상 머신(VM)을 호스팅한다.17 전형적인 자율 드론 아키텍처는 다음과 같이 구성될 수 있다.

이러한 구조에서 QNX Hypervisor는 VM 1의 안전성을 보장하기 위해 VM 2로부터의 간섭을 완벽하게 차단해야 한다. 이것이 바로 간섭 없는 자유(FFI: Freedom From Interference) 개념이다.

4.2 간섭 없는 자유(FFI) 구현 메커니즘

QNX Hypervisor는 FFI를 보장하기 위해 다음과 같은 다층적인 보호 메커니즘을 제공한다.5

4.2.1 시간적 격리 (Temporal Isolation)

하이퍼바이저 스케줄러는 각 VM에 할당된 CPU 시간을 엄격하게 관리한다. 리눅스 VM이 무한 루프에 빠지거나 과도한 연산을 수행하더라도, QNX RTOS VM에 할당된 타임 슬롯은 침해받지 않는다. 이는 앞서 언급한 APS 기술이 하이퍼바이저 레벨로 확장된 것이다.

4.2.2 공간적 격리 (Spatial Isolation) 및 SMMU

가장 중요한 보호 메커니즘은 메모리 격리이다. 하이퍼바이저는 2단계 주소 변환(Stage 2 Translation)을 통해 각 VM이 접근할 수 있는 물리 메모리 영역을 제한한다. 하지만 이것만으로는 부족하다. DMA(Direct Memory Access)를 사용하는 디바이스(GPU, 네트워크 카드 등)는 CPU를 거치지 않고 직접 메모리에 접근하므로, 악의적이거나 오작동하는 디바이스가 안전 영역의 메모리를 덮어쓸 위험이 있다.

QNX는 SMMU(System Memory Management Unit) Manager를 통해 이 문제를 해결한다. SMMUMAN 서비스는 하드웨어 SMMU를 프로그래밍하여, 각 디바이스가 자신에게 허용된 메모리 영역 외에는 절대 접근하지 못하도록 강제한다.19 예를 들어, 리눅스 VM에 할당된 AI 가속기가 버그로 인해 QNX VM의 비행 제어 데이터를 덮어쓰려 시도하면, 하드웨어 수준에서 트랜잭션이 차단되고 오류가 보고된다. 이는 소프트웨어의 논리적 오류뿐만 아니라 하드웨어의 오작동까지 방어하는 강력한 수단이다.

4.2.3 안전한 통신 (Safe Inter-VM Communication)

격리된 VM 간에도 데이터 교환은 필요하다. 예를 들어, 리눅스 VM의 AI가 인식한 장애물 좌표를 QNX VM의 비행 제어기로 전송해야 한다. QNX는 이를 위해 공유 메모리 기반의 안전한 통신 채널(VirtIO, Shared Memory Objects)을 제공한다.20

• 대역폭 제한: 통신 채널에 흐름 제어(Flow Control)를 적용하여, 비안전 영역에서 과도한 메시지를 보내 안전 영역의 처리 능력을 마비시키는 서비스 거부(DoS) 공격을 방지한다.
• 데이터 검증: 공유 메모리 영역은 엄격한 타입 정의와 접근 제어를 통해 관리되며, 메시지 전달 시 데이터 무결성을 검증하는 절차를 포함한다.

5. DO-178C 인증을 위한 QNX 적용 가이드

QNX 플랫폼을 사용하여 실제 DO-178C 인증을 획득하기 위해서는 전략적인 접근이 필요하다. QNX는 자동차용 ISO 26262 인증을 받았지만, 항공용 DO-178C 인증서는 기본적으로 제공하지 않는다(DO-178C는 기체/시스템 단위 인증이기 때문). 그러나 QNX는 인증을 지원하기 위한 강력한 에코시스템을 갖추고 있다.

5.1 SEooC (Safety Element out of Context) 개념의 확장 적용

ISO 26262의 SEooC 개념은 DO-178C의 ‘재사용 가능한 소프트웨어 컴포넌트(Reusable Software Component)’ 개념과 유사하다. QNX OS for Safety는 특정 드론 시스템에 종속되지 않은 상태에서(Out of Context) 안전성이 검증된 요소로 제공된다.7

개발사는 QNX가 제공하는 **안전 매뉴얼(Safety Manual)**을 성경처럼 따라야 한다. 이 매뉴얼에는 OS의 각 기능을 안전하게 사용하기 위한 조건(Constraints), 가정(Assumptions), 그리고 금지 사항(Prohibitions)이 명시되어 있다. 예를 들어, “실시간성을 보장하기 위해 특정 API는 인터럽트 핸들러 내에서 호출하지 말 것” 등의 지침을 준수하고 이를 문서화하는 것이 인증의 첫걸음이다.

5.2 툴 자격 (Tool Qualification) 지원 (DO-330)

DO-178C는 소프트웨어 자체뿐만 아니라, 그 소프트웨어를 컴파일하고 검증하는 도구에 대해서도 신뢰성을 요구한다. 이를 다루는 것이 DO-330 표준이다.11

• QNX C/C++ 컴파일러 (qcc): QNX는 자사의 툴체인에 대해 ISO 26262 TCL 3 및 IEC 61508 T3 등급의 자격을 획득했다.8 이는 DO-178C의 툴 자격 기준(TQL)을 충족시키는 데 필요한 증거 자료(Tool Qualification Kit)를 제공할 수 있음을 의미한다.
• 검증 도구: QNX Momentics IDE와 연동되는 Valgrind, Code Coverage 도구 등은 소프트웨어 검증 결과를 생성하는 데 사용되므로, 이들 도구의 신뢰성 입증 또한 QNX가 제공하는 문서 패키지를 통해 지원받을 수 있다.

5.3 멀티코어 간섭 및 CAST-32A 대응

최신 드론은 멀티코어 프로세서를 사용하므로, FAA의 CAST-32A(또는 EASA AMC 20-193) 지침을 준수해야 한다. 이는 멀티코어 환경에서 코어 간 간섭으로 인한 최악 실행 시간(WCET) 증가를 분석하고 완화할 것을 요구한다.25

QNX는 이에 대응하기 위해 다음과 같은 기능을 제공한다.

• 바운딩(Bounding) 메커니즘: APS와 캐시 파티셔닝 기술을 통해 간섭의 상한선을 예측 가능하게 만든다.
• 분석 도구: QNX System Profiler는 코어 간 간섭 현상을 시각화하고, 병목 지점을 식별하여 스케줄링 정책을 최적화할 수 있도록 돕는다. 이는 인증 당국에 “우리는 멀티코어 간섭을 이해하고 통제하고 있다“는 것을 증명하는 강력한 도구이다.

5.4 인증 아티팩트 활용 비용 절감

QNX를 사용함으로써 개발사는 다음과 같은 아티팩트 작성 비용을 절감할 수 있다.27

1. OS 레벨의 요구사항 및 설계 문서: QNX가 제공하는 문서를 참조(Reference)함으로써 작성 생략.
2. OS 레벨의 테스트 결과: QNX의 검증 리포트로 대체.
3. 알려진 문제(Known Problems) 관리: QNX가 제공하는 결함 리포트(Defect Reports)와 워크어라운드(Workaround) 정보를 사용하여 안전성 분석 수행.

연구에 따르면, 검증된 COTS OS를 사용할 경우 자체 OS 개발 대비 인증 비용과 시간을 50% 이상 절감할 수 있는 것으로 알려져 있다.29

6. FACE 기술 표준 및 개방형 아키텍처

미국을 중심으로 한 군사 및 항공 분야에서는 FACE(Future Airborne Capability Environment) 표준 준수가 중요한 요구사항으로 떠오르고 있다. FACE는 항공 소프트웨어의 이식성(Portability)과 재사용성(Reusability)을 높여 비용을 절감하기 위한 개방형 아키텍처 표준이다.30

6.1 QNX의 FACE 준수 현황

QNX는 FACE 기술 표준 3.1의 **일반 목적 프로파일(General Purpose Profile)**에 대한 적합성 인증을 획득했다.30

• POSIX 호환성: FACE 일반 목적 프로파일은 675개 이상의 POSIX API 지원을 요구하며, QNX는 태생적으로 POSIX 호환 OS이기에 이를 완벽하게 충족한다. 이는 리눅스 기반으로 개발된 오픈소스 드론 소프트웨어(예: ROS, PX4의 일부 모듈)를 QNX로 포팅하기 매우 쉽게 만든다.
• ARINC 653 지원: QNX는 ARINC 653 파티셔닝 개념을 지원하여(필수는 아니지만 옵션으로), 기존 레거시 항공 소프트웨어와의 호환성도 제공한다.

6.2 자율 드론에서의 FACE 이점

드론 기술은 빠르게 발전하므로 하드웨어 업그레이드 주기가 짧다. FACE 호환 소프트웨어로 개발하면, 하드웨어가 바뀌거나 OS가 업데이트되어도 응용 소프트웨어를 재작성할 필요 없이 재사용할 수 있다. 또한, 다양한 공급업체의 소프트웨어 컴포넌트(예: A사의 매핑 소프트웨어 + B사의 비행 제어기)를 QNX라는 공통 플랫폼 위에서 통합(Integrate)하기 용이해진다.

7. 산업 사례 연구: 선도 기업들의 QNX 도입 전략

실제 시장에서 QNX가 어떻게 적용되고 있는지 분석하는 것은 이론적 논의보다 더 확실한 증거를 제공한다.

7.1 Vertical Aerospace & Honeywell Anthem

영국의 Vertical Aerospace는 자사의 eVTOL 기체인 VX4의 핵심 항공전자로 Honeywell의 Anthem 시스템을 채택했다.31

• Honeywell Anthem: 업계 최초의 클라우드 연결 콕핏 시스템으로, QNX OS 기반으로 구동된다. 이는 조종사에게 직관적인 터치 인터페이스를 제공하면서도, 백그라운드에서는 비행 제어와 내비게이션 기능을 안전하게 수행한다.
• 협력 모델: Honeywell은 QNX의 안전성과 보안성을 바탕으로 Anthem 플랫폼을 구축하고, Vertical Aerospace는 이 검증된 플랫폼을 기체에 통합함으로써 기체 전체의 인증(Type Certification) 과정을 가속화한다.33 특히 NXP의 i.MX 8 프로세서와 QNX의 결합은 고성능 그래픽과 안전한 제어를 동시에 가능하게 했다.

7.2 Embraer Eve & Thales FlytX

Embraer의 자회사 Eve Air Mobility는 Thales와 협력하여 비행 제어 및 항공전자 시스템을 개발 중이다.34

• Thales FlytX: Thales의 차세대 항공전자 슈트인 FlytX는 헬리콥터와 UAM을 타겟으로 하며, 15인치 대형 터치스크린을 특징으로 한다. 이 시스템 역시 QNX OS를 기반으로 하여 기존 대비 40%의 무게, 크기, 전력 소비 감소를 달성했다.36
• 시사점: 대형 항공전자 기업(Thales)이 차세대 UAM 시장을 위해 자체 OS 대신 QNX를 선택했다는 것은, QNX의 인증 준비성(Certification Readiness)과 성능이 업계 표준으로 인정받고 있음을 보여준다.

7.3 Joby Aviation & NVIDIA

Joby Aviation은 자율 비행 기술의 고도화를 위해 NVIDIA와 파트너십을 맺었다.38

• 고성능 컴퓨팅: NVIDIA의 Thor 또는 Orin 플랫폼은 자율주행차를 위해 개발되었으나, 그 강력한 AI 연산 능력 때문에 드론 업계에서도 주목받고 있다.
• QNX의 역할: NVIDIA 플랫폼 위에서 안전성(Safety)을 보장하기 위해서는 리눅스만으로는 부족하다. 따라서 NVIDIA Drive OS의 안전 기반이 QNX인 것처럼, Joby의 비행 컴퓨터 아키텍처에서도 QNX(또는 그에 준하는 RTOS)가 하이퍼바이저를 통해 AI 가속기와 비행 제어기를 중재하는 역할을 수행할 것으로 분석된다.39 이는 ’Software Defined Drone’으로 가는 길목에서 QNX가 필수적인 인프라임을 증명한다.

8. 결론 및 전략적 제언

자율 임무 드론의 상용화를 가로막는 가장 큰 장벽은 ’기술’이 아니라 ’인증’이다. BlackBerry QNX는 이 장벽을 넘기 위한 가장 현실적이고 강력한 도구를 제공한다.

8.1 요약

1. 아키텍처: QNX의 마이크로커널 아키텍처는 결함 격리와 자가 치유 능력을 통해 ISO 21384-3의 안전 요구사항을 본질적으로 충족한다.
2. 혼합 중요도: QNX Hypervisor와 SMMUMAN 기술은 고성능 AI(리눅스)와 결정론적 제어(RTOS)가 단일 칩에서 안전하게 공존할 수 있는 ’간섭 없는 자유(FFI)’를 보장한다.
3. 인증 지원: ISO 26262/IEC 61508 인증 이력과 풍부한 아티팩트, 툴 자격 지원은 DO-178C 인증 비용과 리스크를 획기적으로 낮춘다.

8.2 드론 개발사를 위한 제언

• 초기부터 인증 고려: 프로토타입 단계에서는 리눅스로 개발하더라도, 양산 및 인증을 고려한다면 아키텍처 설계 단계부터 POSIX 호환성을 유지하여 QNX로의 전환을 대비해야 한다.
• 플랫폼 접근 방식: OS, 하이퍼바이저, 미들웨어(FACE/ROS)를 통합한 ’안전 플랫폼’을 먼저 구축하고, 그 위에서 응용 애플리케이션을 개발하는 계층화된 접근이 필요하다.
• 보안 내재화: 안전(Safety) 인증뿐만 아니라 보안(Security) 인증(ISO 21434 등)이 필수화될 것이므로, QNX의 보안 기능을 활용하여 ’Secure by Design’을 구현해야 한다.

결론적으로, QNX는 단순한 운영체제를 넘어 자율 임무 드론이 복잡한 도심 하늘을 안전하게 비행할 수 있게 하는 ’디지털 신뢰의 기반(Foundation of Digital Trust)’이다. 드론 제조사들은 QNX를 전략적 파트너로 활용함으로써 인증이라는 거대한 산을 넘어 시장을 선점할 수 있을 것이다.

9. 참고 자료

1. Global Benchmark for Drone Operations: ISO Advances 3rd Edition of Key Standard - Unifly, https://www.unifly.aero/global-benchmark-for-drone-operations-iso-advances-3rd-edition-of-key-standard/
2. Building digital platforms to enable advanced air mobility | McKinsey, https://www.mckinsey.com/industries/aerospace-and-defense/our-insights/building-digital-platforms-to-enable-advanced-air-mobility
3. Distributed Real-time Architecture for Mixed Criticality Systems - CORDIS, https://cordis.europa.eu/docs/projects/cnect/0/610640/080/deliverables/001-dreamsd932whitepaperonmixedcriticalityresearchandinnovationr10.pdf
4. DO-178C - Wikipedia, https://en.wikipedia.org/wiki/DO-178C
5. Elevating cluster software development with QNX Hypervisor on AWS | AWS for Industries, https://aws.amazon.com/blogs/industries/elevating-cluster-software-development-with-qnx-hypervisor-on-aws/
6. INTERNATIONAL STANDARD ISO 21384-3, https://cdn.standards.iteh.ai/samples/70853/7ec34c8a22bf46958423b7e3a2e43693/ISO-21384-3-2019.pdf
7. Products & Updates - QNX, https://www.qnx.com/download/group.html?programid=7807
8. QNX OS for Safety 2.2.3 - Webvar, https://webvar.com/marketplace/products/qnx-os-for-safety-223/prodview-26pvihq76slfa
9. Understanding DO-178C Certification Artifacts and Software Life Cycle Data Items for Various DALs - eInfochips, https://www.einfochips.com/blog/understanding-do-178c-certification-artifacts-and-software-life-cycle-data-items-for-various-dals/
10. DO-178C Certification Explained | ConsuNova, Inc., https://consunova.com/do-178c/certification-unpacked-a-practical-guide-to-do-178c-certification-explained/
11. DO-178() Software Standards Documents & Training - RTCA, https://www.rtca.org/do-178/
12. AW-Drones proposed standards – 3rd iteration (SORA), https://www.aw-drones.eu/wp-content/uploads/2022/02/AW-Drones_D4.3_SORA_v00.01.00.pdf
13. Using a Microkernel RTOS to Build Secure, Fault-Tolerant Systems - QNX, https://blackberry.qnx.com/content/dam/qnx/whitepapers/2009/qnx_secure_kernel_whitepaper_RIM_MC411.67.pdf
14. Microkernel architecture - QNX, https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.sys_arch/topic/intro_MICROKERNELARCH.html
15. QNX Software Systems - Military, security, and defense, https://support7.qnx.com/download/download/10038/QNX%20Defense.pdf
16. An Introduction to BlackBerry QNX - Toradex, https://docs.toradex.com/109212-qnx-building-safe-high-performing-systems-just-got-easier.pdf
17. QNX Hypervisor - Edaway, https://www.edaway.com/product/qnx-hypervisor/
18. Protection strategies - QNX, https://www.qnx.com/developers/docs/8.0/com.qnx.doc.hypervisor.user/topic/qhs/isolation.html
19. SMMUMAN in a QNX hypervisor system, https://www.qnx.com/developers/docs/8.0/com.qnx.doc.smmuman.user/topic/use/use_guest.html
20. Sharing memory through the direct mapping of physical addresses - QNX, https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.prog/topic/mapping_phys_addr.html
21. qnx | Memory Barrier - WordPress.com, https://membarrier.wordpress.com/tag/qnx/
22. QNX Launches QNX OS for Safety (QOS) 8.0 to Accelerate Development of Safety- and Security-Critical Embedded Systems - i4.0 Today Magazine, https://www.i40today.com/qnx-launches-qnx-os-for-safety-qos-8-0-to-accelerate-development-of-safety-and-security-critical-embedded-systems/
23. DO Qualification Kit (for DO-178 and DO-254) - MATLAB - MathWorks, https://www.mathworks.com/products/do-178.html
24. BlackBerry QNX Adds Another Certification to its Embedded Software Portfolio, https://www.prnewswire.com/news-releases/blackberry-qnx-adds-another-certification-to-its-embedded-software-portfolio-301165498.html
25. Use of Virtual Machines in Avionics Systems and Assurance Concerns - Federal Aviation Administration, https://www.faa.gov/sites/faa.gov/files/aircraft/air_cert/design_approvals/air_software/TC-19-22.pdf
26. A Comprehensive Survey on the Use of Hypervisors in Safety-Critical Systems - IEEE Xplore, https://ieeexplore.ieee.org/iel7/6287639/10005208/10092745.pdf
27. Lynx DO-178C Off-the-Shelf Certification Solutions for Safety-Critical Systems, https://www.lynx.com/hubfs/Data%20sheets/D0-178C%20Certification%20Datasheet.pdf
28. BLACKBERRY RECEIVES THE 2023 - Frost & Sullivan, https://www.frost.com/wp-content/uploads/2024/02/BlackBerry-Award-Write-Up.pdf
29. Revolutionizing Container Terminal Transportation - BlackBerry, https://images.blackberry.com/is/content/blackberry/blackberry-qnx-com/en/resource-center/success-stories/qnx-fernride-case-study-12mar25.pdf
30. Blackberry QNX Meets FACE Adoption: And Now for Something Completely Different - RTI, https://www.rti.com/blog/blackberry-qnx-meets-face-and-now-for-something-completely-different
31. Honeywell and Vertical Aerospace Deepen Certification Partnership - Flight Plan, https://flightplan.forecastinternational.com/2025/05/09/honeywell-and-vertical-aerospace-deepen-certification-partnership/
32. EIIRTrend - Embedded. Design &Testing Services: Data, Acquisitions, Deals and Contracts, https://eiirtrend.com/services/service.php?sector=16
33. Honeywell and NXP Expand Partnership to Accelerate Next-generation Aviation Technology, https://www.honeywell.com/us/en/press/2025/01/honeywell-and-nxp-expand-partnership-to-accelerate-next-generation-aviation-technology
34. Eve Names eVTOL Avionics, Flight Controls and Thermal Management System Suppliers, https://www.eveairmobility.com/eve-names-evtol-avionics-flight-controls-and-thermal-management-system-suppliers/
35. Eve and Thales enter a partnership to develop eVTOL aircraft, https://www.eveairmobility.com/eve-and-thales-enter-a-partnership-to-develop-evtol-aircraft/
36. FlytX tactile large display flight deck for aircraft & rotorcraft - Thales Group, https://www.thalesgroup.com/en/solutions-catalogue/civil-aviation/flytx-tactile-large-display-flight-deck-aircraft-rotorcraft
37. FlytX, Thales’ new connected avionics suite selected by VR-Technologies for its civil helicopter, https://www.thalesgroup.com/en/news-centre/press-releases/flytx-thales-new-connected-avionics-suite-selected-vr-technologies-its
38. Joby’s Superpilot is First Aviation Project For Nvidia’s IGX Thor Platform | AIN, https://www.ainonline.com/aviation-news/defense/2025-10-30/joby-first-aviation-partner-nvidias-igx-thor-platform
39. “Joby stock Soars on NVidia AI partnership” and QNX does not get any credit for NVidia partnership?. It explains why Joby soars with NVidia partnership because NVidia provides that Safety and Cybersecurity with AI. Only BB shareholders understand that explanation? - Reddit, https://www.reddit.com/r/BB_Stock/comments/1p4zrt3/joby_stock_soars_on_nvidia_ai_partnership_and_qnx/