# 1. NuttX RTOS 개요 및 PX4 도입 배경

라즈베리 파이에 깔린 우분투(Ubuntu)와 픽스호크(Pixhawk)에 깔린 NuttX의 가장 치명적인 차이는 속도가 아니다. 바로 **결정론적 응답성(Deterministic Responsiveness)**이다. 시스템 아키텍트를 꿈꾼다면 왜 전 세계 유수의 비행 제어기들이 이 가벼운 RTOS에 목숨을 거는지 그 근본적인 역사와 구조적 배경을 직시해야 한다.

RTOS의 존재 이유: 데드라인(Deadline) 절대수호 원칙
초당 400번씩 회전 모멘트를 연산해야 하는 멀티콥터(mc_att_control)를 상상해 보라. 2.5 밀리초(ms)마다 한 번씩 루프가 돌아야 기체가 뒤집어지지 않는다. 일반적인 범용 OS(리눅스, 윈도우)는 스케줄러가 ’공평함(Fairness)’을 중시하여 백그라운드에서 바이러스 백신이 돌거나 파일 입출력이 생기면 CPU를 빼앗아 버린다. 비행루프가 2.5ms가 아니라 10ms 뒤에 돌아올 수도 있다는 뜻이며, 이 지터(Jitter)는 즉각적인 추락으로 이어진다.
반면 RTOS인 NuttX는 ‘공평함’ 따위는 개나 줘버린다. 오직 철저한 우선순위(Priority) 기반의 선점형(Preemptive) 스케줄링만을 따른다. 자세 제어 스레드의 우선순위를 최고로 설정해 두면, 시스템에 아무리 막대한 로그 기록(I/O) 부하가 걸리더라도 커널은 2.5ms가 되는 순간 하위 스레드의 모가지를 잘라버리고 CPU 제어권을 자세 제어기에게 칼같이 바친다. 이것이 ’경성 실시간(Hard Real-Time)’의 개념이며, 생명이 걸린 드론에 NuttX가 이식된 절대적 사유다.

왜 하필 NuttX인가? POSIX 표준의 기적
초기 임베디드 시장에는 FreeRTOS, ChibiOS 등 수많은 RTOS가 난립했다. 그럼에도 2012년 당시 PX4의 창시자(Lorenz Meier)가 무명의 NuttX를 채택한 이유는 단 하나, “가장 완벽한 POSIX(리눅스 표준 API) 호환성” 때문이었다.

1. 리눅스 생태계 복제: NuttX는 단순히 스케줄러만 제공하는 것이 아니라, 리눅스에서 앵간히 쓰이는 pthread_create(), open(), read(), ioctl() 등의 시스템 콜(System Call) 인터페이스를 100% 동일하게 구현해 놓았다.
2. SITL 시뮬레이션의 혁명: PX4 엔진을 개발할 때, 동일한 C/C++ 소스 코드를 boards/px4 로 타겟팅하면 NuttX용 .px4 펌웨어가 튀어나오고, platforms/posix 로 타겟팅하면 개발자의 맥북 램(RAM) 위에서 도는 SITL(Software In The Loop) 리눅스 데몬으로 컴파일된다. 동일한 API를 쓰기 때문에 코드 수정이 단 한 줄도 필요 없다.
3. 마운트 가능한 파일 시스템(VFS): 플래시 기반 임베디드 보드임에도 리눅스처럼 /fs/microsd, /dev/ttyS1 같은 디렉토리 트리 구조(VFS)를 지원하여 디바이스 드라이버를 파일 다루듯 제어할 수 있다.

이 유학파 태생 수준의 고급스러운 아키텍처 덕분에 PX4 펌웨어는 고립된 칩셋에 갇히지 않고 거대한 글로벌 소프트웨어 스위트(Suite)로 거듭날 수 있었던 것이다.