1291.19 상태 머신의 선언적 표현 부족

1291.19 상태 머신의 선언적 표현 부족

1. 선언적 프로그래밍과 절차적 프로그래밍

프로그래밍 패러다임은 크게 선언적(declarative) 접근과 절차적(procedural, imperative) 접근으로 구분된다. 선언적 프로그래밍은 “무엇(what)을 달성할 것인가“를 기술하며, 달성 방법의 세부사항은 실행 엔진에 위임한다. 반면, 절차적 프로그래밍은 “어떻게(how) 실행할 것인가“를 단계별로 명시한다.

선언적 표현의 장점은 다음과 같다:

  1. 추상화 수준의 향상: 구현 세부사항을 은폐하여 설계 의도를 명확하게 전달한다.
  2. 가독성의 개선: 행동의 목적이 코드에 직접적으로 표현되므로 이해가 용이하다.
  3. 비전문가의 접근성: 프로그래밍 전문 지식이 없는 도메인 전문가도 정의를 읽고 수정할 수 있다.
  4. 도구 지원의 용이성: 선언적 정의를 파싱하여 검증, 시뮬레이션, 시각화 도구로 연결하기 용이하다.

2. FSM의 절차적 특성

유한 상태 머신(FSM)은 본질적으로 절차적 모델이다. FSM은 “상태 q_i에서 이벤트 \sigma를 수신하면 행동 a를 실행하고 상태 q_j로 전이하라“라는 형태로 동작을 명시한다. 이는 실행의 각 단계를 구체적으로 기술하는 절차적 명세에 해당한다.

FSM의 절차적 특성이 선언적 표현을 저해하는 구체적 측면은 다음과 같다:

2.1 전이 규칙의 분산적 기술

FSM에서 하나의 행동 목표(예: “장애물을 회피하라”)를 달성하기 위한 로직이 다수의 전이 규칙으로 분산되어 기술된다. “장애물 회피“라는 단일 행동 목표가 “탐지 시 감속”, “회피 경로 계획”, “회피 기동 실행”, “원래 경로 복귀” 등의 전이로 분해되며, 이 전이들의 조합이 행동 목표를 달성하는 절차를 구성한다. 설계자가 전이 규칙의 집합에서 행동 목표를 역으로 추론(reverse inference)하는 것은 어렵다.

2.2 의도와 메커니즘의 혼재

FSM의 전이 규칙에서 “왜 이 전이가 필요한가(의도)“와 “이 전이가 어떻게 실행되는가(메커니즘)“가 분리되지 않는다. 전이 규칙 \delta(q_A, \sigma_{\text{obstacle}}) = q_B는 “장애물 감지 시 회피 상태로 전환“이라는 메커니즘을 기술하지만, “로봇의 안전을 보장한다“라는 상위 의도는 규칙 자체에 포함되지 않는다.

2.3 제어 흐름의 명시적 정의

FSM에서 행동의 실행 순서는 전이 규칙에 의하여 명시적으로 정의된다. “A를 수행한 후 B를 수행하라“라는 순차적 실행을 FSM으로 표현하려면 q_A \rightarrow q_B의 전이를 명시적으로 정의해야 하며, “A 또는 B를 시도하라“라는 대안적 실행을 표현하려면 분기 조건과 전이를 명시적으로 정의해야 한다.

이와 대비하여 선언적 표현에서는 “A를 수행한 후 B를 수행하라“를 Sequence(A, B)로, “A 또는 B를 시도하라“를 Fallback(A, B)로 간결하고 직관적으로 표현할 수 있다.

3. 선언적 표현 부족의 실무적 영향

3.1 설계 의도의 불투명성

FSM의 전이 규칙만으로는 설계자의 원래 의도를 파악하기 어렵다. 리뷰어나 유지보수 엔지니어가 기존 FSM을 분석할 때, 각 전이 규칙의 존재 이유와 전체 행동 전략을 역공학(reverse engineering)으로 재구성해야 한다. 이는 지식 전달 비용을 증가시키며, 문서화에 대한 의존도를 높인다.

3.2 도메인 전문가의 참여 제한

로봇 임무의 행동 로직은 도메인 전문가의 지식에 기반하여 설계되어야 하나, FSM의 전이 규칙 형식은 도메인 전문가에게 직관적이지 않다. 도메인 전문가가 “로봇은 먼저 목표 지점으로 이동하고, 실패하면 대안 경로를 시도하며, 그래도 실패하면 대기하라“라는 자연어적 행동 기술을 FSM으로 변환하는 것은 소프트웨어 엔지니어의 전문적 중재를 요구한다.

3.3 자동 생성 및 검증 도구와의 비친화성

선언적 표현은 파싱, 검증, 최적화, 코드 생성 등 자동화 도구와의 통합에 유리하다. FSM의 절차적 정의는 이러한 도구에 의한 자동 분석이 상대적으로 어려우며, 특히 전이 규칙의 의미론적 일관성을 자동으로 검증하는 것이 복잡하다.

4. 행동 트리의 선언적 표현

행동 트리(Behavior Tree)는 본질적으로 선언적 설계 모델이다. 행동 트리에서 각 노드는 “무엇을 수행/평가할 것인가“를 선언하며, 제어 흐름 노드는 자식 노드의 조합 방식을 선언한다.

<BehaviorTree>
  <Sequence>
    <Condition ID="IsBatteryOK"/>
    <Fallback>
      <Sequence>
        <Action ID="MoveToGoal"/>
        <Action ID="PerformTask"/>
      </Sequence>
      <Action ID="ReturnToBase"/>
    </Fallback>
  </Sequence>
</BehaviorTree>

위의 XML 기반 행동 트리 정의는 다음과 같은 행동을 선언적으로 표현한다: “배터리가 정상이면, 목표로 이동하여 작업을 수행하고, 실패하면 기지로 복귀하라.” 이 정의에서 제어 흐름의 세부 메커니즘(Tick 순서, 반환값 처리 등)은 실행 엔진에 의하여 암묵적으로 관리되며, 설계자는 행동의 목적과 조합 방식만 기술하면 된다.

이러한 선언적 특성은 비프로그래머의 접근성을 향상시키고, 시각적 편집 도구(Groot 등)를 통한 그래픽 기반 행동 설계를 가능하게 하며, 자동화된 검증 및 코드 생성 도구와의 통합을 촉진한다 (Colledanchise & Ögren, 2018).

5. 참고 문헌

  • Colledanchise, M., & Ögren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press.
  • Lloyd, J. W. (1987). Foundations of Logic Programming. 2nd ed., Springer-Verlag.

v0.1.0