1291.58 XML 기반 선언적 정의의 용이 (Ease of XML-Based Declarative Definition)

1. 선언적 명세 패러다임과 행동 트리

1.1 선언적 정의의 개념

선언적 정의(declarative definition)란 시스템의 동작을 “무엇(what)“의 관점에서 기술하는 명세 방식이다. 이는 “어떻게(how)” 동작하는가를 단계별로 기술하는 절차적 정의(procedural definition)와 대비된다. 선언적 명세에서 실행의 구체적 메커니즘은 해석기(interpreter) 또는 실행 엔진(execution engine)에 위임되며, 명세 작성자는 시스템이 달성하여야 할 목표 상태와 구조만을 기술한다.

소프트웨어 공학에서 선언적 접근법은 SQL(Structured Query Language), HTML(HyperText Markup Language), 그리고 다양한 설정 기술 언어(configuration description language)에서 광범위하게 채택되어 왔다. 이 접근법의 공학적 이점은 명세의 추상화 수준을 높여 구현 세부사항으로부터 사용자를 격리(isolation)시키고, 명세의 가독성(readability)과 이식성(portability)을 향상시키는 데에 있다.

1.2 행동 트리에서 선언적 정의의 역할

행동 트리(Behavior Tree, BT)에서 선언적 정의란, 트리의 구조적 구성(노드의 계층적 배치, 노드 유형의 선택, 노드 간 데이터 흐름의 설정)을 프로그래밍 언어의 소스 코드가 아닌 외부 명세 파일(external specification file)에 기술하고, 실행 엔진이 이 명세를 해석하여 트리 객체를 동적으로 구성(instantiation)하는 방식을 의미한다. BehaviorTree.CPP 프레임워크에서는 XML(Extensible Markup Language)이 행동 트리의 선언적 명세 형식으로 채택되어 있으며, 이 선택은 XML 언어 자체의 구조적 특성이 행동 트리의 자료 구조와 높은 대응성을 갖기 때문이다.

절차적 방식으로 행동 트리를 구성하는 경우, 노드의 생성, 부모-자식 관계의 설정, 포트 매핑의 지정이 모두 C++ 코드의 API 호출로 이루어진다. 이 방식에서는 행동 논리의 구조적 파악이 코드의 실행 흐름을 추적하여야만 가능하며, 구조의 변경이 코드의 수정과 재컴파일(recompilation)을 필요로 한다. 선언적 방식은 이러한 절차적 구성의 한계를 해소한다.

2. XML의 행동 트리 표현 적합성

2.1 계층적 구조의 직접적 대응

XML은 요소(element)의 중첩(nesting)에 의하여 계층적 구조를 표현하는 마크업 언어이다. XML 문서에서 하나의 요소가 다른 요소를 포함하면, 포함하는 요소가 부모(parent), 포함되는 요소가 자식(child)이 되어 트리 형태의 계층 구조를 형성한다. 이 구조적 특성은 행동 트리의 트리 자료 구조에 직접적으로 대응한다.

<BehaviorTree ID="MainTree">
    <ReactiveFallback>
        <Sequence name="EmergencyHandler">
            <Condition ID="IsEmergencyDetected"/>
            <Action ID="ExecuteEmergencyStop"/>
        </Sequence>
        <Sequence name="NormalOperation">
            <Condition ID="IsMissionActive"/>
            <Action ID="ExecuteMission"/>
        </Sequence>
    </ReactiveFallback>
</BehaviorTree>

이 XML 명세에서 <ReactiveFallback> 요소의 자식으로 배치된 두 <Sequence> 요소는 행동 트리에서 ReactiveFallback 노드의 자식 노드로 해석된다. 각 <Sequence> 내부의 <Condition>과 <Action> 요소는 해당 Sequence 노드의 자식 노드가 된다. XML의 들여쓰기(indentation)와 중첩 구조가 트리의 계층적 관계를 시각적으로 명시하므로, XML 명세를 읽는 행위가 트리 구조를 파악하는 행위와 동일해진다.

2.2 속성 기반 매개변수화

XML 요소의 속성(attribute)은 행동 트리 노드의 포트 매핑(port mapping)과 매개변수(parameter) 설정을 기술하는 데 활용된다.

<Action ID="ComputePathToPose"
        goal="{target_pose}"
        planner_id="GridBased"
        path="{nav_path}"/>

이 표현에서 goal, planner_id, path는 노드의 입출력 포트에 대한 매핑이다. 중괄호({})로 감싸인 값은 블랙보드(blackboard) 키에 대한 참조를 나타내고, 중괄호 없는 문자열 값은 상수(constant)를 나타낸다. 속성 기반 매개변수화에 의하여, 동일한 노드 유형을 상이한 매개변수로 다수 인스턴스화하는 작업이 XML 수준에서 간결하게 수행된다. 이는 절차적 코드에서 개별 노드마다 포트 매핑 함수를 호출하는 것에 비하여 현저히 축약된 표현이다.

2.3 자기 서술적 명세 특성

XML의 태그(tag) 명칭은 해당 요소의 의미론적 역할을 직접 기술한다. 행동 트리의 XML 명세에서 노드 유형이 태그 명칭으로 표현되므로, <Sequence>, <Fallback>, <Action>, <Condition> 등의 태그 자체가 해당 노드의 기능적 역할을 명시한다. 이 자기 서술적(self-descriptive) 특성에 의하여, XML 명세가 별도의 주석(comment)이나 외부 문서 없이도 행동 논리의 전체 흐름에 대한 문서 역할을 수행한다.

3. BehaviorTree.CPP의 XML 스키마 구조

3.1 최상위 문서 구조

BehaviorTree.CPP 프레임워크에서 XML 명세의 최상위 구조는 <root> 요소로 시작한다.

<root BTCPP_format="4">
    <BehaviorTree ID="MainTree">
        <!-- 주 트리의 구조 정의 -->
    </BehaviorTree>

    <BehaviorTree ID="PatrolSubTree">
        <!-- 서브트리 정의 -->
    </BehaviorTree>

    <TreeNodesModel>
        <!-- 노드 인터페이스 선언 -->
    </TreeNodesModel>
</root>

<root> 요소의 BTCPP_format 속성은 XML 스키마의 버전 번호를 지정한다. BehaviorTree.CPP 4.x에서는 이 값이 "4"로 설정된다. 하나의 XML 파일 내에 다수의 <BehaviorTree> 블록을 정의할 수 있으며, <root> 요소의 main_tree_to_execute 속성으로 진입점(entry point) 트리를 지정한다. 이 구조에 의하여 하나의 XML 파일이 주 트리와 다수의 서브트리를 포괄하는 완전한 행동 명세 단위가 된다.

3.2 TreeNodesModel에 의한 노드 인터페이스 선언

<TreeNodesModel> 블록은 각 사용자 정의 노드 유형의 포트 인터페이스를 명시적으로 선언한다.

<TreeNodesModel>
    <Action ID="NavigateToWaypoint">
        <input_port name="waypoint" type="geometry_msgs::msg::PoseStamped"/>
        <input_port name="speed" type="double" default="0.5"/>
        <output_port name="distance_remaining" type="double"/>
    </Action>
    <Condition ID="IsBatteryAboveThreshold">
        <input_port name="threshold" type="double" default="0.2"/>
    </Condition>
</TreeNodesModel>

이 선언은 세 가지 공학적 기능을 수행한다. 첫째, XML 명세의 로드 시점에서 노드 유형의 존재 여부와 필수 포트의 매핑 상태를 정적으로 검증(validation)하는 기반을 제공한다. 둘째, Groot 등의 시각적 편집 도구에서 노드의 포트 정보를 자동으로 표시하는 메타데이터 역할을 수행한다. 셋째, 노드 인터페이스의 명세를 XML 수준에서 문서화하여, 노드의 사용법을 C++ 소스 코드를 참조하지 않고도 파악할 수 있게 한다.

3.3 서브트리 참조와 포트 리매핑

서브트리(SubTree)는 XML 명세 내에서 별도로 정의된 트리를 참조하여 재사용하는 메커니즘이다.

<BehaviorTree ID="MainTree">
    <Sequence>
        <SubTree ID="NavigationSubTree"
                 target_pose="{current_goal}"
                 result="{nav_result}"/>
        <Action ID="ReportCompletion"/>
    </Sequence>
</BehaviorTree>

<BehaviorTree ID="NavigationSubTree">
    <Sequence>
        <Action ID="ComputePath" goal="{target_pose}" path="{planned_path}"/>
        <Action ID="FollowPath" path="{planned_path}" result="{result}"/>
    </Sequence>
</BehaviorTree>

<SubTree> 요소의 속성은 주 트리의 블랙보드 키와 서브트리 내부의 블랙보드 키 간의 매핑(port remapping)을 정의한다. 이 매핑에 의하여 서브트리는 자신의 내부 블랙보드 네임스페이스를 유지하면서도 외부 트리와 데이터를 교환할 수 있다.

4. 선언적 정의의 공학적 이점

4.1 행동 논리와 실행 코드의 관심사 분리

XML 기반 선언적 정의의 핵심적 이점은 행동 논리(behavior logic)와 실행 코드(execution code)의 관심사 분리(separation of concerns)이다.

관심사 영역	XML 명세의 책임	C++ 구현의 책임
트리의 계층적 구조	노드의 부모-자식 관계 정의	—
노드 유형의 선택	태그 명칭에 의한 유형 지정	—
포트 매핑	속성 값에 의한 데이터 흐름 설정	—
노드의 실행 로직	—	`tick()` 메서드의 알고리즘 구현
ROS2 통신 인터페이스	—	액션 클라이언트, 서비스 클라이언트 호출
센서 및 액추에이터 접근	—	하드웨어 추상화 계층(HAL) 호출

이 분리 구조에서 행동 트리의 구조적 변경(노드 순서의 교환, 서브트리의 추가 또는 제거, 분기 조건의 변경)은 XML 파일의 편집만으로 달성된다. C++ 소스 코드의 수정이나 재컴파일이 불필요하다. 반대로, 개별 노드의 내부 알고리즘 개선은 C++ 코드의 수정만으로 달성되며, XML 명세에는 영향을 미치지 않는다. 이 양방향 독립성이 개발과 유지보수의 효율성을 높인다.

4.2 재컴파일 없는 행동 수정

XML 명세의 수정만으로 행동 트리의 구조를 변경할 수 있다는 특성은 다음의 실용적 시나리오에서 공학적 가치를 갖는다.

현장 행동 튜닝(field tuning): 로봇이 운용 환경에 배치된 후, 현장의 물리적 조건이나 임무 요구사항에 맞추어 행동 트리의 구조나 매개변수를 조정하여야 하는 경우가 빈번하다. XML 기반 정의에서는 현장 엔지니어가 XML 파일을 수정하고 로봇 시스템을 재시작하는 것만으로 행동 조정이 가능하다. 별도의 개발 환경이나 크로스 컴파일(cross-compilation) 도구 체인이 필요하지 않다.

임무별 행동 트리 교체: 동일한 로봇 플랫폼이 탐사, 순찰, 물자 운반 등 상이한 임무 유형에 투입되는 경우, 각 임무에 대응하는 XML 파일을 별도로 관리하고, 임무 할당 시 해당 XML 파일을 로드하는 방식으로 행동 전환이 수행된다.

점진적 행동 개발: 최소 기능 행동 트리로부터 시작하여, 현장 테스트 결과에 기반하여 노드를 점진적으로 추가하는 반복적 개발(iterative development)이 XML 수준에서 수행된다.

4.3 버전 관리 시스템과의 통합

XML은 텍스트 기반 형식이므로, Git 등의 버전 관리 시스템(Version Control System, VCS)에서 변경 이력의 추적과 차분 비교(diff)가 직관적으로 수행된다. 행동 트리의 구조적 변경이 XML 텍스트의 삽입, 삭제, 수정으로 기록되므로, 코드 리뷰(code review) 과정에서 행동 논리의 변경 사항을 정확히 식별할 수 있다.

 <ReactiveFallback>
     <Sequence name="EmergencyHandler">
         <Condition ID="IsEmergencyDetected"/>
         <Action ID="ExecuteEmergencyStop"/>
     </Sequence>
+    <Sequence name="LowBatteryHandler">
+        <Condition ID="IsBatteryLow"/>
+        <Action ID="ReturnToChargingStation"/>
+    </Sequence>
     <SubTree ID="PrimaryMission"/>
 </ReactiveFallback>

위의 차분 비교 예시에서, 배터리 부족 대응 시퀀스가 추가되었음이 명확히 식별된다. 이진 형식(binary format)이나 프로그래밍 언어 코드 내의 API 호출 기반 구성에서는 이러한 직관적 변경 추적이 불가능하다.

4.4 정적 유효성 검사

BehaviorTree.CPP의 XML 로더(loader)는 TreeNodesModel에 선언된 노드 인터페이스 정보에 기반하여 XML 명세의 구조적 유효성을 실행 전에 검사한다. 검증 대상은 다음을 포함한다.

미등록 노드 유형(unregistered node type)의 사용 검출
필수 입력 포트(required input port)의 매핑 누락 검출
포트 데이터 유형의 정합성(type consistency) 검증
서브트리 참조의 존재 여부 확인

이 정적 분석(static analysis)에 의하여 행동 트리의 구조적 오류가 로드 시점에서 조기 검출(early detection)되며, 실행 시점의 런타임 오류(runtime error)로 인한 디버깅 비용이 절감된다.

5. 유한 상태 머신 명세 방식과의 비교

유한 상태 머신(Finite State Machine, FSM)의 명세에서는 로봇공학 분야에서 통일된 선언적 표준 형식이 확립되어 있지 않다. W3C가 SCXML(State Chart XML)을 상태 머신의 XML 기반 표준으로 권고(recommendation)하였으나, 로봇공학 분야에서의 실질적 채택은 제한적이다. 대다수의 로봇 FSM 프레임워크(SMACH, FlexBE 등)에서는 상태 정의와 전이 규칙이 Python 등의 프로그래밍 언어 코드로 직접 기술된다.

비교 항목	유한 상태 머신 (SMACH, FlexBE 등)	행동 트리 (BehaviorTree.CPP)
명세 형식	프로그래밍 언어 코드 (절차적)	XML 파일 (선언적)
구조 변경 절차	코드 수정 → 재실행 (인터프리터) 또는 재컴파일	XML 파일 편집 → 재로드
시각적 도구 연동 방식	프레임워크별 독자적 형식	XML 기반 표준화된 입출력
버전 관리 친화성	코드 수준의 diff (논리 흐름 파악 요구)	XML 텍스트의 구조적 diff
로드 시점 유효성 검사	프로그래밍 언어의 정적 분석에 의존	XML 스키마 및 노드 모델 기반 검사
도메인 전문가 접근성	프로그래밍 언어 숙련 필요	XML 구조의 이해로 충분

행동 트리의 XML 기반 선언적 정의는, 상태 머신의 절차적 코드 기반 정의에 비하여, 행동 명세의 독립성, 도구 지원의 표준화, 그리고 비프로그래머의 참여 가능성에서 구조적 이점을 갖는다.

6. 도메인 전문가의 행동 설계 참여

XML 기반 선언적 정의가 제공하는 중요한 이점 중 하나는 소프트웨어 개발 전문 지식이 없는 도메인 전문가(임무 계획자, 로봇 운용자, 안전 감사관 등)가 행동 트리의 설계 과정에 직접 참여할 수 있다는 점이다. XML 명세의 자기 서술적 특성과 Groot 등 시각적 편집 도구의 지원에 의하여, 도메인 전문가가 트리의 구조를 이해하고 노드의 배치 순서나 매개변수를 조정하는 작업이 프로그래밍 언어의 숙련 없이도 가능하다.

이 특성은 로봇 시스템 개발에서 “행동 설계(behavior design)” 활동을 소프트웨어 구현(software implementation)으로부터 분리하여, 도메인 지식에 기반한 독립적 설계 활동으로 전환하는 기반을 형성한다. 임무 계획자가 행동 트리의 전체 구조를 설계하고, 소프트웨어 엔지니어가 개별 노드의 실행 로직을 구현하는 역할 분담이 XML 명세를 매개로 자연스럽게 이루어진다.

7. XML 기반 선언적 정의의 한계

7.1 복잡한 데이터 변환의 표현 제약

단순한 포트 매핑(블랙보드 키의 참조, 상수 값의 지정)은 XML 속성으로 명료하게 표현되나, 포트 값의 동적 계산이나 복잡한 데이터 변환 로직은 XML의 표현 능력을 초과한다. XML은 범용 프로그래밍 언어가 아니므로, 조건부 연산이나 수학적 변환을 속성 값에 직접 기술할 수 없다. 이러한 경우에는 변환 로직을 별도의 Action 노드로 구현하고, 변환 결과를 블랙보드에 기록하는 간접적 방식으로 우회하여야 한다.

7.2 XML 파싱의 초기화 비용

대규모 행동 트리로 구성된 XML 파일의 로드 시 XML 파싱(parsing)에 소요되는 시간이 시스템의 초기화 지연(initialization latency)을 유발할 수 있다. 다만, 이 파싱은 시스템 시작 또는 트리 전환 시에 한 번만 수행되며, 트리 구성 완료 이후의 tick 실행 성능에는 영향을 미치지 않는다.

7.3 컴파일 시점 타입 안전성의 부재

XML은 본질적으로 문자열(string) 기반 형식이므로, 포트 값의 데이터 유형에 대한 검증이 C++ 컴파일 시점이 아닌 XML 로드 시점에서 이루어진다. 컴파일 시점 타입 검사에 비하여 오류 검출의 시점이 늦어지며, 개발 과정에서의 즉시적 피드백이 감소한다. BehaviorTree.CPP 4.x에서는 TreeNodesModel의 타입 선언과 런타임 타입 변환 검사를 통하여 이 한계를 부분적으로 보완하고 있으나, 정적 타입 언어 수준의 완전한 타입 안전성에는 도달하지 못한다.

7.4 대규모 XML 명세의 관리 복잡도

트리의 규모가 증가하면 단일 XML 파일의 크기 역시 증가하여 가독성과 관리성이 저하될 수 있다. 이에 대한 실용적 대응으로, 서브트리를 별도의 XML 파일로 분리하고, 주 트리에서 파일 참조를 통하여 서브트리를 포함하는 방식이 적용된다. BehaviorTree.CPP는 <include> 메커니즘을 통하여 다수의 XML 파일을 조합하여 하나의 논리적 행동 트리를 구성하는 기능을 지원한다.

8. 참고 문헌

Colledanchise, M., & Ögren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press.
Faconti, D. (2022). BehaviorTree.CPP 4.x Documentation. https://www.behaviortree.dev/
Iovino, M., Scukins, E., Styrud, J., Ögren, P., & Smith, C. (2022). “A Survey of Behavior Trees in Robotics and AI.” Robotics and Autonomous Systems, 154, 104096.
W3C. (2015). State Chart XML (SCXML): State Machine Notation for Control Abstraction. W3C Recommendation.
Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., & Yergeau, F. (2008). Extensible Markup Language (XML) 1.0. 5th ed. W3C Recommendation.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

버전: 2026-04-01