## 0.1 호스트 PC 하드웨어 최적화 권장 사양 (CPU 스레드, RAM, SSD IOPS가 빌드 시간에 미치는 영향)

엔지니어의 생산성은 곧 make 키를 엔터하고 나서 프롬프트가 다시 떨어지는 대기 시간(Turnaround Time)에 완벽히 비례한다. 수백만 라인의 C++ 코드와 수천 개의 크로스 컴파일 객체를 다중 포크(Fork) 방식으로 갈아 마시는 PX4 Ninja 툴체인의 특성상, 호스트(개발 PC)의 특정 하드웨어 스펙이 타임 라인에 미치는 극적인 상관관계를 이해해야 한다.

CPU 스레드 수 (병렬 처리의 절대적 지배자)
앞서 언급한 Ninja 제너레이터는 코어 하나를 아끼는 선처를 베풀지 않는다. 소스 트리에 종속성이 없는 타겟(.cpp) 100개가 포진해 있다면 PC가 가진 모든 논리적 스레드 창구로 동시에 목적 파일(.o) 연산 지시를 발포한다.
Intel i5 (4코어/8스레드) 급 머신과 최신 Ryzen 9 / Apple M Max (16코어 이상) 사이의 클린 컴파일 속도는 거의 물리적인 스레드 숫자 자릿수 배율에 비례하여(Linear Scaling) $5$ 분 대 $30$ 초 급의 궤를 벗어난 생산성 격차를 빚어낸다. 다다익선(多多益善)의 진리 영역이다.
RAM (메모리 뱅크 용량과 프로세스 오버플로우)
강력한 CPU에 의해 수십 개의 arm-none-eabi-g++ 무거운 콤파일러 프로세스가 동시에 RAM 위에 상주하게 된다. GCC의 링크 타임 자원 최적화(-flto 등)나 거대한 EKF 수학 파싱 단계는 엄청난 메모리 버퍼를 집어삼킨다.
최소 $8GB$ 환경의 구형 노트북이나 가벼운 가상 머신(VM)에서 $16$ 스레드 동시 빌드를 강행하면, RAM이 고갈되어 하드디스크 스왑(Swap Memory)에 손을 대는 순간 컴파일 속도는 $1/10$ 수준으로 곤두박질치는 OOM(Out of Memory) 스로틀링 참사가 터진다. PX4 현대적 툴체인 구축의 마지노선 물리 RAM 권장 한계는 $16GB$ 이며, 쾌적한 샌드박스 구동은 $32GB$ 가 적격이다.
저장 장치 IOPS (NVMe SSD의 무작위 입출력 속도)
컴파일의 본질은 무수한 파편 텍스트 소스(.h, .cpp) 파일 수천 개를 $0.001$ 초 간격으로 읽어 낸 뒤 수천 개의 목적 파일(.o)로 잘라 다시 깡통에 쏟아붓는(Write) “극한의 무작위 단위 입출력(Random I/O)” 전투다. 구형 HDD 기어 디스크나 저가의 SATA SSD에서는 1초당 입출력 한계치(IOPS) 병목에 걸려, 아무리 CPU 코어가 많아도 디스크 바늘이 다 돌아갈 때까지 대기(I/O Wait) 상태에 빠져버린다. NVMe 급 대역폭과 DRAM 캐시가 적용된 하이-티어 SSD의 체결만이 툴체인에게 날개를 달아줄 수 있다.