1291.16 상태 머신의 팀 협업 개발 어려움

1291.16 상태 머신의 팀 협업 개발 어려움

1. 팀 기반 개발의 요구사항

현대 로봇 시스템의 개발은 단일 엔지니어가 아닌 다수의 전문가—소프트웨어 엔지니어, 제어 엔지니어, 시스템 통합 엔지니어, 도메인 전문가—로 구성된 팀에 의하여 수행된다. 팀 기반 개발에서는 시스템의 구성 요소를 독립적으로 분담하여 병렬적으로 개발하고, 개발된 구성 요소를 통합하는 작업 흐름이 필수적이다. 이러한 작업 흐름의 효율성은 시스템 아키텍처의 모듈성과 구성 요소 간 인터페이스의 명확성에 의하여 결정된다.

2. FSM의 팀 협업 장벽

2.1 상태와 전이의 전역적 결합

유한 상태 머신(FSM)에서 상태와 전이는 전체 시스템 수준에서 정의되며, 개별 상태를 독립적 작업 단위로 분할하기 어렵다. 특정 상태를 담당하는 개발자는 해당 상태의 행동뿐만 아니라, 해당 상태로의 진입 전이와 퇴출 전이를 정의해야 하며, 이 전이의 원본/대상 상태는 다른 개발자가 담당하는 영역에 속한다.

이러한 교차 의존성(cross-dependency)은 다음과 같은 협업 장벽을 생성한다:

  1. 인터페이스 합의 부담: 상태 A를 담당하는 개발자와 상태 B를 담당하는 개발자가 A→B 전이의 조건, 이벤트, 행동에 대하여 합의해야 하며, 이 합의가 변경되면 양측 모두 영향을 받는다.
  2. 병렬 개발의 제한: A→B 전이에 대한 합의가 완료되기 전에는 양측의 상태 구현이 완결될 수 없으므로, 병렬 개발의 효율성이 저하된다.
  3. 통합 시 충돌: 독립적으로 개발된 상태들을 하나의 FSM으로 통합할 때, 전이 규칙 간의 충돌(동일 상태에서 동일 이벤트에 대한 상이한 전이 정의)이 발생할 수 있다.

2.2 버전 관리의 어려움

FSM의 전이 규칙이 단일 파일(상태 테이블, XML 정의, 소스 코드 파일)에 집중되어 있을 경우, 복수의 개발자가 동시에 해당 파일을 수정하면 버전 관리 시스템(Git 등)에서 병합 충돌(merge conflict)이 빈번하게 발생한다. FSM의 전이 규칙은 상호 참조적이므로, 텍스트 수준의 자동 병합(auto-merge)이 논리적으로 올바른 결과를 보장하지 않으며, 수동 병합과 검증이 필요하다.

2.3 작업 분할의 불균등

FSM에서 각 상태의 복잡도—진입/퇴출 전이의 수, 내부 행동의 복잡도—가 불균등하게 분포하는 경우가 일반적이다. 중앙 허브(hub) 역할을 하는 상태(예: “대기” 상태)는 다수의 전이가 집중되어 복잡도가 높은 반면, 말단 상태(예: “비상 정지”)는 비교적 단순하다. 작업 분할 시 이러한 불균등을 반영해야 하나, FSM의 구조에서 자연스러운 분할 경계를 찾기 어렵다.

3. 도메인 전문가의 참여 제한

로봇 임무의 행동 로직은 소프트웨어 엔지니어만으로는 정의할 수 없으며, 도메인 전문가(로봇 조작자, 임무 설계자, 안전 엔지니어 등)의 지식이 필수적이다. FSM의 상태-전이 형식은 프로그래밍 배경이 없는 도메인 전문가에게 진입 장벽으로 작용한다.

도메인 전문가가 FSM에 기여하기 어려운 이유는 다음과 같다:

  1. 형식적 표기법의 장벽: 전이 함수 \delta(q_i, \sigma) = q_j와 같은 형식적 표기는 비전문가에게 직관적이지 않다.
  2. 전역적 맥락 이해 필요: 하나의 행동을 수정하려면 해당 행동이 전체 FSM에서 차지하는 위치와 전이 관계를 이해해야 한다.
  3. 변경 영향 예측의 어려움: 도메인 전문가가 “이 상황에서는 이렇게 행동해야 한다“는 요구사항을 제시해도, 이를 FSM의 전이 규칙으로 변환하고 기존 규칙과의 정합성을 확인하는 것은 소프트웨어 엔지니어의 전문 영역이다.

4. 코드 리뷰와 품질 보증

팀 개발에서 코드 리뷰(code review)는 품질 보증의 핵심 활동이다. FSM의 코드 리뷰에서 겪는 어려움은 다음과 같다:

  1. 변경의 파급 범위 파악: 하나의 전이 규칙 수정이 미치는 영향 범위를 리뷰어가 파악하려면, 해당 전이를 포함하는 모든 실행 경로를 분석해야 한다.
  2. 의도와 구현의 괴리 탐지: 리뷰어가 수정된 전이의 의도(왜 이 전이가 필요한가)를 파악하기 어려우며, 구현이 의도에 부합하는지 검증하기 위한 맥락 정보가 부족하다.
  3. 리뷰 시간의 비선형적 증가: FSM의 규모가 증가함에 따라 리뷰에 필요한 시간이 변경 크기에 비례하지 않고 초선형적으로 증가한다.

5. 행동 트리의 협업 친화성

행동 트리는 팀 기반 개발에 적합한 구조적 특성을 제공한다. 서브트리의 독립성에 의하여 각 서브트리를 다른 개발자가 독립적으로 개발하고 독립적으로 테스트할 수 있다. 서브트리 간의 인터페이스는 블랙보드 포트로 명확하게 정의되며, 서브트리를 별도의 XML 파일로 분리하여 버전 관리의 병합 충돌을 최소화할 수 있다.

또한 행동 트리의 시각적 표현은 도메인 전문가에게 직관적이며, Groot 등의 시각적 편집 도구를 통하여 비프로그래머도 행동 로직의 설계와 검토에 참여할 수 있다. 이는 FSM에서 도메인 전문가의 참여가 제한되는 것과 대비되는 중요한 협업 장점이다.

6. 참고 문헌

  • Colledanchise, M., & Ögren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press.
  • Conway, M. E. (1968). “How Do Committees Invent?” Datamation, 14(4), 28–31.
  • Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.

v0.1.0