19.1.3.1. src/examples 디렉토리 하위에 실습용 폴더(px4_uorb_example) 생성

본격적인 텍스트 에디터 기반의 C++ 코딩에 앞서 개발자가 가장 먼저 타격해야 할 물리적 작업은, 우리의 방대한 uORB 발행/구독 비즈니스 로직이 안전하게 둥지를 틀고 거주할 “물리적 집(Directory)“을 파일 시스템 트리 위에 타설하는 것이다. 앞선 섹션의 아키텍처 이론에서 거듭 강조했듯이, 기존 시스템 코어 생태계 소스코드의 메모리 오염이나 브랜치 꼬임을 철저하고 극단적으로 방지하기 위해 우리는 이 집의 절대 주소를 PX4 코어 팀이 공식적으로 허가하고 지정한 유일한 샌드박스(Sandbox) 격리 구역인 src/examples 하위 공간으로 엄격히 확정한다.

개발 PC의 Ubuntu 터미널을 열고 PX4 소스 트리의 최상위 루트 디렉토리(Root Directory)로 이동한 뒤, 다음과 같이 시스템 내에서 그 누구와도 충돌하지 않는 직관적이고 명확한 식별명(Identifier)을 가진 새 전위 기지국 폴더를 생성한다.

# PX4 최상위 루트 디렉토리에서 권한을 획득하여 실행
mkdir -p src/examples/px4_uorb_example

# 생성된 물리적 폴더 공간으로 깊숙이 진입
cd src/examples/px4_uorb_example

1. 모듈 폴더 내 핵심 뼈대 파일(Skeleton Files) 물리 공간 할당

방금 생성한 이 폴더는 빈 껍데기로 남아 있어서는 안 된다. 향후 작성될 거대한 발행자(Publisher)와 구독자(Subscriber) 백그라운드 로직이 총망라되어 담길 메인 C++ 소스 파일 하나와, 이 외딴 소스 파일을 거대한 픽스호크 전체 빌드 시스템 트리망에 강제로 묶어 연결해 줄 거대한 브릿지 명세서인 CMakeLists.txt 스크립트 파일이 가장 기본 뼈대(Skeleton)로 타설되어야만 한다.

지금 당장은 이 파일들의 내부 텍스트 콘텐츠를 채우지 않더라도, 물리적인 파일 객체 자체를 시스템 상에 먼저 touch 명령어로 생성하여 아키텍처의 거시적 워크스페이스 레이아웃을 완벽하게 완성해 둔다.

# 1. 데몬 메인 런타임(Runtime) 진입점이자 코어 비즈니스 로직(uORB Pub/Sub)이 작성될 C++ 소스파일 덤프
touch px4_uorb_example.cpp

# 2. 이 외딴 모듈을 메인 시스템 펌웨어 컴파일 파이프라인(Linking Pipeline)에 강제 편입시킬 빌드 스크립트 타설
touch CMakeLists.txt

위 명령어 라인들이 리눅스 파일 시스템 단에서 어떠한 에러 출력 없이 고요히 실행되었다면, 당신의 src/examples/px4_uorb_example 은밀한 디렉토리 내부는 이제 위대한 비행 제어 설계도를 거침없이 그려넣기 위해 한 점의 티 없이 새하얗게 포맷팅된 단 두 장의 물리적 도화지 파일(px4_uorb_example.cpp, CMakeLists.txt)만을 거룩하게 품게 된다.

코어 시스템에 갓 입문한 초보 개발자들은 흔히 이 초기 단계에서 무작정 구글링한 조잡한 C++ 코드를 복사하여 파일부터 만들고 붙여넣기 바쁜 치명적 실수를 저지른다. 그러나 진정한 코어 아키텍트는 텍스트를 단 한 줄도 코드 에디터에 타이핑하기 전에, 이러한 엄격한 물리적 파일명 네이밍 컨벤션(Naming Convention)과 디렉토리 트리의 상대적 깊이(Depth)가 향후 Makefile과 전체의 컴파일러 헤더 참조 경로를 통제할 때 어떠한 물리적 지렛대 역할을 하게 될지 그 방대한 그림을 머릿속 가상 환경에서 먼저 완벽하게 조감(Bird-eye View)해 낸다.
결국 이 단순해 보이는 한 줄짜리 폴더 및 파일 생성 작업이 명확히 끝났다는 것은, 훗날 닥쳐올 수많은 컴파일 포함(Include) 지뢰밭 스크립트 오류를 가볍게 우회하여 피해 갈 수 있는 가장 완벽하고 결점 없는 물리적 진지 구축이 완료되었음을 묵직하게 의미하는 것이다.