25.1.1 Format 3 표준 명세(REP 149)에 기반한 패키지 위상 및 식별자 구조

ROS 2의 메타 빌드 시스템과 의존성 해결 메커니즘을 지원하기 위한 package.xml의 문법 및 의미론(Semantics)은 REP(ROS Enhancement Proposal) 149에 규정된 “Format 3” 표준 명세를 엄격히 따른다. Format 3는 과거 ROS 1 생태계에서 과도기적으로 사용되었던 Format 1 및 2의 기능적 모호성을 극복하고, 패키지의 생명 주기(빌드, 실행, 테스트, 배포) 단계를 명확히 분리하기 위해 고안된 구조적 확장안이다.

1. 최상위 선언 및 파서(Parser) 호환성 제어

Format 3 표준의 준수 여부는 매니페스트 파일의 최상단에서 <package format="3"> 태그를 선언함으로써 보장된다. 이 명시적인 버전 선언은 colcon 빌드 스케줄러와 rosdep 의존성 분석기가 XML 문서를 파싱(Parsing)할 때 구문 해석 엔진의 분기점을 결정하는 트리거(Trigger)가 된다. 만약 런타임 환경에서 하위 버전의 파셔만을 지원하는 레거시 도구가 Format 3를 읽으려 시도할 경우, 설계된 표준 위반 시스템에 따라 파싱을 즉각 중단하고 오류를 반환하여 빌드 파이프라인의 오염을 방지한다.

2. 식별자 구조 (Identifier Structure)

패키지의 정체성을 정의하고 전역 네임스페이스 내에서 유일한 위상(Topology)을 점유하기 위해, Format 3는 다음과 같은 필수 식별자 구조를 요구한다.

식별 명칭 <name>
목적 소프트웨어를 캡슐화하는 최상위 심볼이다. 시스템 내 충돌을 방지하기 위하여 반드시 알파벳 소문자, 숫자, 그리고 밑줄(Underscore, _)의 조합으로만 구성되어야 하며, 첫 글자는 반드시 알파벳이어야 한다는 어휘 규칙(Lexical rule)을 갖는다. (예: geometry_msgs, nav2_planner)
의미론적 버전 제어 <version>
소프트웨어 공학의 Semantic Versioning(SemVer) 모델을 차용하여 Major.Minor.Patch (예: 1.0.4)의 3단위 체계를 강제한다. 이는 릴리스 과정에서 API의 역호환성(Backward compatibility) 위반 여부를 기계가 서드파티 패키지 의존성과 대조하여 수학적으로 결정할 수 있도록 지원하는 핵심 식별자이다.
형상 정보 레지스트리
협력적 오픈소스 생태계 시스템의 투명성을 위해 패키지의 의도와 목적을 설명하는 <description>, 유지보수 주체와 이메일 주소가 명시된 <maintainer>, 그리고 OSI(Open Source Initiative)에서 승인된 라이선스 규약(예: Apache-2.0, MIT)을 선언하는 <license> 태그가 존재한다. 상용 시스템으로 배포될 자율 드론 아키텍처에서 이 형상 정보 및 라이선스 태그는 빌드 타임 패키징 검증 도구들에 의해 엄격한 감사(Audit) 대상이 된다.

3. 빌드 위상(Topology) 및 메타 유형의 정의

Format 3 규격의 가장 큰 위상학적 특징은, ament 인덱스 체계 내에 패키지의 종속 위치를 고정하기 위한 기반 속성을 익스포트 영역에 선언한다는 점이다. 특히, <export> 컨테이너 내부의 <build_type> 태그 (예: <build_type>ament_cmake</build_type> 또는 <build_type>ament_python</build_type>)는 해당 패키지가 C++ 크로스 컴파일 파이프라인을 거칠 것인지, 역동적 바인딩 기반의 Python 인터프리터 경로에 스태킹될 것인지를 선험적으로(A priori) 결정한다.
이 속성을 통해 Colcon은 빌드 스케줄링 시점 이전에 각 패키지가 요구하는 메모리 자원 크기와 병렬 스레드 할당 전략을 최적화할 수 있는 추상화 모델을 구축한다. (참고 버전: REP-149)