## 0.1 Python 모듈의 data_files 스키마 튜플 구조와 CMake install 문법 간 의미론적 차이점

ROS2의 멀티-랭귀지 바인딩 특성에 따라 컴포넌트 생태계는 C/C++ 기반의 ament_cmake 파이프라인과 순수 파이썬 모듈 기반의 ament_python 파이프라인으로 이분화된다. 두 빌드 체계는 정적 리소스(런치 파일, 파라미터 맵 등)를 운영체제 전역이나 작업공간의 설치 접두사(Installation Prefix) 공간으로 이주시키는 과정에서 문법적 구조와 의미론적(Semantic) 패러다임의 극명한 차이를 드러낸다. ament_cmake가 제어 흐름에 기반한 명령형(Imperative) 스크립팅 언어를 통해 절차적 파일 제어를 수행한다면, ament_python은 setup.py 내에 종속된 setuptools 프레임워크의 선언적(Declarative) 자료구조인 data_files 튜플(Tuple) 스키마를 통해 매핑(Mapping) 관계를 정의한다. 이 두 병렬적 접근 방식은 궁극적으로 동일한 ROS 리소스 파일 계층 표준(FHS) 레이어에 수렴해야 하지만, 그 전개 과정의 기저 계층에서 프로그래밍 추상화 수준의 차이를 보인다.

ament_cmake 빌드 환경의 CMakeLists.txt에서 통용되는 install(DIRECTORY ... DESTINATION ...) 문법 체계는, 소스 디렉토리 계층에 위치한 원본 파일 집합을 빌드 구동기(Make, Ninja 등)를 통해 목적지(Destination) 경로로 물리적으로 전송하라는 구체적인 입출력(I/O) 명령이다. 이 명령형 문법은 디렉토리 트리의 재귀적 복사(Recursive Copy), POSIX 소유권(Ownership) 및 실행 권한(Permission) 설정, 정규 표현식을 결합한 세밀한 파일 스필터링(Regex Filtering) 등 저수준의 시스템 제어 권한을 툴체인 엔지니어에게 위임한다. 예를 들어 특정 런치 폴더에 대한 install 구문은 소스의 위상 기하학적 폴더 구조를 해체하지 않고 그대로 목적 폴더로 포팅(Porting)하라는 명시적 제어 흐름(Control Flow)을 의미한다.

반면, ament_python 파이프라인 중심의 setup.py 파일 내에 선언되는 data_files 파라미터는 리스트(List) 컬렉션 내에 불변의 튜플 구조체를 다수 내장하는 파이썬 특유의 자료구조이다. 각 튜플은 (설치_목적지_경로_문자열, [원본_파일_경로의_리스트]) 쌍으로 엄격하게 바인딩된다. 이러한 선언적 방식은 툴체인에게 ’어떻게 복사할 것인가’를 지시하는 행동(Behavior) 스크립트가 아니라, 최종 런타임 단계의 특정 패키지 경로에 ’어떤 파일 객체들이 존재해야 하는가’라는 결과적 상태의 청사진(Blueprint)을 기술하는 정적 매핑 집합에 가깝다. 특히 표준 setuptools 패러다임 상에서는 디렉토리 노드 자체를 순회하여 하위 에셋 전체를 일괄 전송하는 재귀적 복사 구문이 추상화되어 있지 않다. 따라서 개발자는 os나 glob와 같은 파이썬 표준 내장 모듈을 통해 소스 트리의 파일 엔티티들을 빌드 타임에 동적 순회(Dynamic Traversal)하여 스키마 데이터 구조를 절차적으로 생성해 내는 부가적인 메타빌드 로직(Metabuild Logic)을 구현해야만 한다.

두 배포 시스템 간의 가장 결정적인 시스템적 괴리는 Ament 전역 인덱스 네트워크(Ament Index)에 대한 컴포넌트 존재감 증명 방식에서 도출된다. CMake 중심의 빌드 파이프라인에서는 ament_package() 매크로의 호출 평가 과정에 Ament 인덱스 마커(Marker) 파일 생성이 캡슐화되어 암묵적으로 전개된다. 반면 인터프리터 언어 기반의 패키지 서술 체계인 setup.py에서는 인프라가 내부 상태를 자동 추론하지 않으므로, 개발자가 직접 data_files 배열 요소로 ('share/ament_index/resource_index/packages', ['resource/<패키지명>']) 형태의 로우 레벨 코드를 삽입하여 컴포넌트 마커 파일의 위치를 하드코딩(Hard-coding)해야 한다. 이러한 의미론적 비대칭성은 네이티브 바이너리 애플리케이션의 링킹 제어에 초점이 맞춰진 CMake 설계 철학과 범용 인터프리터 모듈의 의존성 배포에 근간을 둔 setuptools 생태계 간의 이념적 차이에서 비롯된 피할 수 없는 결과물이다. ROS2 컴파일 오케스트레이터인 Colcon은 이 두 개의 상이한 스키마 모델을 단일한 글로벌 리소스 맵스페이스로 결합 컨버팅하여 이기종 노드로 구성된 자율 에이전트 드론의 무결한 런타임을 지원한다.