## 0.1 Docker 기반 격리된 빌드 환경(Containerized Build) 구축

## 0.1 Docker 기반 격리된 빌드 환경(Containerized Build) 구축

호스트 OS가 Ubuntu든 Windows든 macOS든, 시간이 지날수록 개발자의 로컬 PC는 온갖 프로젝트의 쓰레기 라이브러리와 꼬여버린 경로 환경 변수로 오염되어, 결국 “내 PC에서는 빌드되는데 네 PC에서는 왜 안되냐?“라는 클래식한 지옥(ITIL: It works on my machine)에 직면하게 된다. 이를 무자비하게 단죄하는 궁극의 인프라 전략이 바로 도커(Docker) 기반 방탄 빌드 컨테이너 아키텍처다.

컨테이너 라이프사이클과 불변의(Immutable) 환경
PX4 생태계는 공식적으로 자체 유지보수하는 극한의 컨테이너 이미지(예: px4io/px4-dev-nuttx-focal 등)를 Docker Hub에 제공하고 있다. 이 수 기가바이트(GB) 짜리 이미지 내부에는 리눅스 코어, CMake, Ninja, 정밀하게 버전이 세팅된 arm-none-eabi-gcc, 그리고 가상 환경 Python 모듈 세트가 방부 처리된 미라처럼 ’영원히 변하지 않는 상태(Immutable state)’로 진공 포장되어 있다.

실행 명령어의 아키텍처를 해부해 보면 그 완벽한 격리성을 실감할 수 있다.
docker run --rm -it -v $(pwd):/src/px4 px4io/px4-dev-nuttx-focal bash -c "cd /src/px4 && make px4_fmu-v6c_default"

  1. 일회용 진공관 구동 (--rm -it): 도커 엔진은 무균실과 같은 컨테이너를 0.1초 만에 띄워내고 컴파일 프롬프트를 연다. 빌드가 끝나면 이 무균실 공간 자체를 완전히 삭제(--rm)하여 어떠한 오염 잔재도 남기지 않는다.
  2. 호스트 소스트리의 바인드 마운트 (-v $(pwd):/src/px4): 호스트 PC(개발자의 바탕화면 폴더 등)에 클론 되어 있는 PX4 레포지토리를 가상 무균실 안의 /src/px4 폴더 위치로 동기화(Volume Mount)시킨다. 도커는 호스트 컴퓨터의 그 어떤 파일도 건드리지 못한 채, 오직 렌즈 구멍 하나만 뚫어 소스코드를 열람하고, 컴파일된 목적 파일(.px4) 결과물만을 호스트 폴더로 슬며시 토해낸 뒤 자폭한다.

도커 전략의 한계와 실무적 결단 (USB 패스스루의 절벽)
도커 컨테이너 빌드는 100% 동일한 바이너리를 보장하는 “재현 가능성(Reproducibility)“의 최고봉이지만, 치명적인 약점이 하나 존재한다. 바로 타겟 플래싱(Hardware Flashing) 및 3D 시뮬레이션(Gazebo)과의 이질감이다.
가상의 네트워크 장막 안에 갇혀버린 도커 컨테이너가 윈도우나 맥의 밖으로 튀어나와 USB 포트에 꽂힌 Pixhawk 하드웨어 보드에 직접 접근(make upload)을 하거나 화면 그래픽 랜더링 파이프라인(X11/Wayland)을 뚫고 3D 화면을 렌더링하기 위해서는 끝도 없는 소켓 열기, 권한 풀기, 데몬 매핑의 지옥을 통과해야 한다.

따라서 현업 엔지니어링 아키텍트의 결단은 명확하다. **“빌드 머신(CI/CD)이나 순수 펌웨어 팩토리(Factory) 용도라면 Docker를 절대적으로 신뢰하고 돌리되, 일일이 보드 플래싱을 굽고 디버깅을 돌려야 하는 하위 로컬 데스크톱 개발은 호스트 네이티브 환경(Ubuntu, WSL2)을 이중으로 가져가는 투 트랙(Two-track) 디자인”**을 전개하라.