## 0.1 macOS 개발 환경의 제약과 해결책

실리콘 밸리와 모던 소프트웨어 엔지니어들의 영원한 애착 도구인 macOS(맥북) 역시 PX4 툴체인의 토양으로 자주 선택된다. 유닉스(Unix) 기반이라는 태생적 장점 덕분에 윈도우(순수 환경)보다는 훨씬 부드러운 접근성을 제공하지만, 최근 Apple Silicon (M1/M2/M3 등 ARM64 아키텍처)으로의 대대적인 이주는 임베디드 크로스 컴파일 생태계에 새로운 딜레마(Dilemma)와 제약을 던져주었다. 이를 돌파하는 아키텍처적 해결책을 조명한다.

툴체인 패키징의 이질성: Homebrew 생태계
리눅스가 apt를 소환한다면, macOS는 전적으로 Homebrew 패키지 매니저에 툴체인의 존폐를 의탁한다. PX4 설치 스크립트(mac_setup.sh)는 brew tap 명령어를 통해 서드파티 레포지토리를 연결하고, arm-none-eabi-gcc 와 cmake, ninja 를 끌어온다.
문제는 macOS가 메이저 업데이트(예: Sonoma 등)를 할 때마다 Xcode Command Line Tools의 내부 clang 컴파일러나 Python 환경이 강제로 리셋 혹은 격리된다는 점이다. 이로 인해 빌드 도중 파이썬 모듈(jinja2 등)을 찾지 못하거나 디렉토리 권한이 날아가는 에러가 빈번하다. 따라서 맥 사용자는 항상 xcode-select --install 로 Xcode 뼈대를 먼저 확실하게 수리한 뒤 Homebrew 환경을 덧씌우는 루틴을 습관화해야 한다.

Apple Silicon (ARM64)의 이중 번역 제약과 해결
과거 Intel Mac (x86_64) 시절에는 리눅스와 동일한 아키텍처였기에 크로스 컴파일러가 네이티브 속도로 동작했다. 그러나 현재의 M 시리즈 맥북(ARM64)은 기이한 모순에 빠진다.
개발 머신 자체도 ARM이고 타겟 보드(Cortex-M)도 ARM인데, 정작 오픈소스 진영에서 제공하는 gcc-arm-none-eabi 패키지 상당수가 아직 완벽한 macOS ARM64 네이티브 바이너리로 포팅되지 않은 상태로 배포되는 경우가 있다. 이 경우 M 시리즈 맥북은 x86 에뮬레이터인 Rosetta 2를 백그라운드에서 가동하여, x86용 번역기를 ARM 칩에서 돌려, 다시 ARM용 펌웨어를 만들어내는 엽기적인 ’이중 번역 병목(Double Translation Bottleneck)’을 겪는다.

이러한 속도 저하 로제타 제약을 타파하기 위한 해결책은 두 가지다.

ARM Native GCC의 직접 체결: ARM 재단 홈페이지나 Homebrew의 최신 Nightly 빌드를 뒤져서 기어코 aarch64 호스트용으로 컴파일된 네이티브 gcc-arm-none-eabi 바이너리를 직접 다운로드하여 Path에 꽂아 넣는다. 이 순간 컴파일 속도는 로제타 시절 대비 3~4배 수직으로 상승한다.
SITL 시뮬레이션의 네이티브(Native M1) 가동: 펌웨어 디바이스 빌드가 아닌 가상 환경 비행(SITL + Gazebo) 구동 시에는 크로스 컴파일러가 개입하지 않고 Mac 호스트 컴파일러인 Apple Clang이 직접 소스를 번역한다. 이때는 M 시리즈 칩셋의 괴물 같은 성능이 100% 발휘되어 리눅스 데스크톱을 짓밟는 최고의 시뮬레이션 프레임레이트(FPS)와 연산 스피드를 만끽할 수 있다.