자율 드론 시스템의 핵심에는 고차원의 목표를 실행 가능한 일련의 행동으로 변환하고, 예측 가능하며 안전한 운용을 보장하는 임무 관리 시스템(Mission Management System)이 자리 잡고 있다. 이 시스템은 드론의 인지적 중추 신경계 역할을 수행하며, 비행의 모든 단계를 조율하고 외부 환경 변화와 내부 시스템 상태에 동적으로 대응한다. 임무 관리의 견고성과 효율성은 드론의 자율성 수준과 직결되며, 단순한 경로점 비행부터 복잡한 실시간 의사결정이 요구되는 임무에 이르기까지 그 중요성은 아무리 강조해도 지나치지 않다.
이러한 임무 관리 시스템을 구축하기 위한 가장 근본적이고 검증된 패러다임 중 하나가 바로 유한 상태 기계(Finite State Machine, FSM)이다. FSM은 시스템의 동작을 유한한 개수의 ‘상태(state)’와 상태 간의 ‘전이(transition)’로 모델링하는 수학적 개념이다.1 특히 무인 항공기(UAV)와 같이 안전이 최우선이며 자원이 제한된 환경에서, FSM은 그 직관성과 예측 가능성 덕분에 오랫동안 핵심적인 제어 아키텍처로 사용되어 왔다.3 시스템이 특정 순간에는 단 하나의 명확한 상태에만 존재할 수 있다는 FSM의 기본 원칙은 복잡한 자율 시스템의 동작을 이해하고 디버깅하는 것을 용이하게 만든다.
본 보고서는 FSM을 기반으로 한 드론 임무 관리에 대한 포괄적인 기술적 분석을 제공하는 것을 목표로 한다. 이를 위해 상태 기반 제어의 이론적 원리를 심도 있게 탐구하고, 현재 드론 업계를 주도하는 오픈소스 생태계인 PX4와 ArduPilot에서의 실제 구현 사례를 비교 분석한다. 더 나아가, 행동 트리(Behavior Tree)와 같은 현대적인 대안 아키텍처와의 구조적 장단점을 평가하고, 인공지능 기술과의 융합을 통해 FSM이 어떻게 진화하고 있는지를 조망함으로써 드론 임무 관리 기술의 현재와 미래에 대한 깊이 있는 통찰을 제시하고자 한다.
이 장에서는 FSM의 핵심 모델과 그 특성을 정의하고, 시스템 복잡성 증가에 대응하기 위해 진화해 온 계층적, 확장된 FSM 모델을 탐구함으로써 상태 기반 제어의 근본적인 개념을 확립한다.
FSM은 계산의 수학적 모델로서, 유한한 집합의 상태($S$), 입력 알파벳($Σ$), 그리고 현재 상태와 입력에 따라 다음 상태를 결정하는 전이 함수($δ$)로 구성된다.1 이를 형식적으로 표현하면 5-튜플 $(\Sigma, \Gamma, S, s_0, \delta)$로 나타낼 수 있으며, 여기서 $Γ$는 출력 알파벳, $s_0$는 초기 상태를 의미한다.1 FSM의 가장 핵심적인 원칙은 시스템이 임의의 한 시점에는 반드시 단 하나의 상태에만 존재한다는 것이다.5 이러한 배타적 상태는 시스템의 현재 동작을 명확하게 정의하며, 복잡한 로직을 단순하고 체계적으로 구성할 수 있게 한다.
이 추상적인 개념을 구체적인 예시를 통해 이해할 수 있다. 예를 들어, 자판기는 ‘대기’, ‘금액 투입’, ‘상품 선택’, ‘상품 배출’, ‘거스름돈 반환’과 같은 명확한 상태들로 모델링될 수 있다.7 사용자의 입력(동전 투입, 버튼 누름)은 상태 전이를 유발하는 이벤트가 된다. 로봇 공학에서는 간단한 장애물 회피 로봇을 FSM으로 설계할 수 있다. 로봇은 ‘전진(FORWARD)’, ‘후진 후 우회전(BACKUP_RIGHT)’, ‘후진 후 좌회전(BACKUP_LEFT)’ 등의 상태를 가진다.3 전방의 좌측 또는 우측 스위치가 눌리는 입력에 따라 ‘전진’ 상태에서 다른 상태로 전이된다.
구현 측면에서 FSM은 주로 switch/case 문과 enum 타입을 활용하여 프로그래밍된다. 각 enum 값은 FSM의 개별 상태를 나타내고, switch 문은 현재 상태에 따라 수행할 동작과 다음 상태로의 전이 조건을 검사하는 역할을 한다. 이러한 방식은 Arduino 튜토리얼 예제에서도 쉽게 찾아볼 수 있으며, FSM의 직관적인 구조를 코드로 간결하게 표현하는 효과적인 방법이다.8
FSM의 가장 큰 강점은 그 단순성에서 비롯되는 예측 가능성과 견고함이다. 각 상태와 전이가 명확하게 정의되므로 시스템의 동작을 추론하고 디버깅하기가 용이하다.6 이러한 결정론적 특성은 드론과 같은 안전 최우선 시스템(safety-critical system)에서 필수적이다. FSM은 멀티스레딩 환경이나 외부의 예측 불가능한 교란(disturbance) 속에서도 미리 정의된 규칙에 따라 안정적으로 동작을 보장할 수 있다.10
그러나 이러한 단순성은 복잡성이 증가함에 따라 심각한 한계에 직면하는데, 이를 ‘상태 폭발(state explosion)’ 문제라고 한다. 시스템이 수행해야 할 기능의 수와 처리해야 할 입력의 종류가 늘어날수록, 필요한 상태의 수와 상태 간 전이의 수가 기하급수적으로 증가한다. 결과적으로 FSM은 설계하고 유지보수하기가 매우 어려워지며, 그 구조를 한눈에 파악하기 힘든 복잡한 거미줄 형태가 되어버린다.11
학술 문헌에서는 복잡하게 얽힌 FSM을 초창기 프로그래밍 언어의 무분별한 ‘GOTO’ 문 사용에 비유하기도 한다.12 GOTO 문이 프로그램의 제어 흐름을 예측하기 어렵게 만드는 것처럼, 과도하게 확장된 FSM은 수많은 전이 화살표로 인해 초기 설계의 명료성을 잃고, 작은 수정이 시스템 전체에 예기치 않은 파급 효과를 일으키는 취약한 구조가 될 수 있다.
상태 폭발 문제를 해결하고 FSM의 표현력을 높이기 위해 여러 진화된 모델이 제안되었다.
계층적 유한 상태 기계 (Hierarchical Finite State Machine, HFSM): HFSM은 관련된 상태들을 그룹화하여 계층 구조로 만듦으로써 복잡성을 관리하는 직관적인 해결책이다.14 HFSM에서 상태는 또 다른 FSM(하위 상태 기계)을 내부에 포함할 수 있다. 예를 들어, 드론의 ‘비행(FLIGHT)’이라는 상위 상태는 ‘이륙(TAKEOFF)’, ‘순항(CRUISE)’, ‘착륙(LAND)’과 같은 하위 상태들로 구성될 수 있다. 이러한 계층적 추상화는 복잡한 임무를 논리적인 단위로 분할하고 재사용성을 높여주며, 비행 시뮬레이터나 탐색 및 구조와 같은 복잡한 UAV 제어 작업에 효과적으로 적용된다.14
확장 유한 상태 기계 (Extended Finite State Machine, EFSM): EFSM은 상태의 수를 직접적으로 줄이기 위해 변수(variable) 형태의 메모리를 도입하는, HFSM과는 다른 차원의 해결책이다.1 FSM의 상태 전이는 단순한 입력뿐만 아니라, 이 변수들의 값에 대한 조건(guard)에 의해 결정될 수 있다. 또한, 상태가 전이될 때 변수의 값을 변경하는 동작(action)을 수행할 수 있다. 예를 들어, 60초 타이머를 구현하기 위해 60개의 개별 상태를 만드는 대신, EFSM은 단 하나의 ‘타이머 동작 중’ 상태와 ‘카운터’ 변수 하나만으로 동일한 기능을 구현할 수 있다.1 이는 상태 공간을 극적으로 줄여 모델을 간결하게 만든다. 이처럼 EFSM은 단순한 반응적 모델을 넘어, “5분간 정찰 비행”이나 “2초간 후진”과 같이 시간이 포함된 의도적인 행동을 모델링할 수 있게 해준다. 이는 FSM이 단순히 “현재 입력이 무엇인가?”를 묻는 것을 넘어, “충분한 시간이 경과했는가?”와 같은 내부 상태를 고려하게 함으로써, 단순 반응형 모델에서 계획된 절차를 수행할 수 있는 모델로 격상시킨다.
이러한 진화 과정은 예측 가능성과 표현력 사이의 근본적인 공학적 절충을 보여준다. 단순 FSM은 최고의 예측 가능성을 제공하지만 표현력이 제한된다. 계층 구조(HFSM), 변수(EFSM)와 같은 각 진화 단계는 더 복잡한 작업을 처리하기 위해 표현력을 높이지만, 동시에 시스템의 직관적인 명확성과 검증 가능성을 잠재적으로 저해할 수 있는 새로운 복잡성 계층을 도입한다.
병렬 계층적 유한 상태 기계 (Parallel Hierarchical FSM, PHFSM): 탐색 및 구조와 같은 매우 복잡한 시나리오를 위해 제안된 고급 개념으로, 여러 상태 기계가 병렬적으로 동시에 실행될 수 있도록 한다.16 각 병렬 FSM은 클럭에 의해 동기화되고 우선순위 시스템에 의해 관리된다. 이 구조는 드론이 ‘안전 비행 유지’와 ‘표적 추적’과 같은 독립적인 행동들을 동시에 관리해야 하는 임무에 필수적이다.16 이처럼 FSM의 진화는 문제 발생(복잡성 증가) -> 해결책 제시(HFSM/EFSM) -> 새로운 문제 발생(동시성 요구) -> 새로운 해결책 제시(PHFSM)라는 인과적 연쇄 반응을 통해 이루어져 왔으며, 이는 제어 시스템 설계의 핵심적인 흐름을 반영한다.
이 장에서는 이론을 넘어 실제 드론 제어 시스템에서 FSM이 어떻게 구현되고 있는지를 분석한다. 세계적으로 가장 널리 사용되는 오픈소스 오토파일럿인 PX4와 ArduPilot의 상태 관리 아키텍처를 심층적으로 해부하고 비교한다.
PX4의 상태 관리는 Commander라는 단일 모듈에 의해 중앙 집중적으로 이루어진다.20
Commander는 전체 PX4 시스템의 유일하고 권위 있는 상태 기계로서, 모든 고수준 비행 모드 전환, 시동/비시동(arming/disarming) 로직, 그리고 페일세이프(failsafe) 동작을 총괄한다.20 이 중앙 집중식 설계는 기체의 의도된 상태에 대한 ‘단일 진실 공급원(Single Source of Truth)’을 보장하여 시스템 전체의 일관성을 유지하는 데 결정적인 역할을 한다.
Commander 모듈의 상태는 uORB 메시징 시스템을 통해 다른 모듈과 통신한다. 특히 commander_state 메시지는 Commander의 공개 인터페이스 역할을 하며, 이 메시지 내의 main_state 필드가 현재 활성화된 비행 모드를 시스템 전체에 전파한다.23 이 main_state는 PX4의 핵심적인 동작 모드를 정의하는 열거형(enumeration)으로, 사용자가 드론에게 원하는 동작을 나타낸다.23
표 1: PX4 commander_state의 주요 상태 및 설명
| 상태 (State) | 상수 (Constant) | 설명 |
|---|---|---|
| 수동 (Manual) | MAIN_STATE_MANUAL |
사용자가 모든 제어 입력을 직접 조종한다. 23 |
| 고도 제어 (Altitude Control) | MAIN_STATE_ALTCTL |
기체의 고도는 자동으로 유지되며, 롤/피치는 사용자가 제어한다. 23 |
| 위치 제어 (Position Control) | MAIN_STATE_POSCTL |
고도와 수평 위치(GPS 기반)가 자동으로 유지된다. 23 |
| 자동 임무 (Auto Mission) | MAIN_STATE_AUTO_MISSION |
사전에 계획된 웨이포인트 임무를 자동으로 수행한다. 23 |
| 자동 정지 (Auto Loiter) | MAIN_STATE_AUTO_LOITER |
현재 위치와 고도를 자동으로 유지하며 선회한다. 23 |
| 자동 귀환 (Auto RTL) | MAIN_STATE_AUTO_RTL |
이륙 지점(Home)으로 자동으로 귀환한다. 23 |
| 곡예 (Acro) | MAIN_STATE_ACRO |
자동 수평 유지 기능 없이 각속도를 직접 제어하는 전문가용 모드이다. 23 |
| 오프보드 (Offboard) | MAIN_STATE_OFFBOARD |
외부 컴퓨터(Companion Computer)의 제어 명령에 따라 비행한다. 23 |
이 표는 PX4가 제공하는 다양한 수준의 자동화와 제어 방식을 명확하게 보여준다. main_state는 단순한 상태 값을 넘어, 시스템의 모든 하위 제어기들이 따라야 할 최상위 지침이 된다.
Commander의 상태 전이는 단순한 FSM이 아니라 복잡한 EFSM의 형태를 띤다. 상태 전이는 하나의 입력이 아닌, 여러 조건의 조합으로 구성된 가드(guard)에 의해 통제된다.
AUTO_MISSION 모드로 진입하기 위해서는 유효한 GPS 신호 수신, 센서 상태 정상, 임무 계획 업로드 완료 등의 조건이 충족되어야 한다.21 이러한 비행 전 점검(Pre-flight Check)을 통과하지 못하면 Commander는 상태 전이를 거부하고 사용자에게 그 이유를 알린다.21Commander는 사용자의 입력과 무관하게 강제적으로 AUTO_RTL과 같은 안전 모드로 상태를 전이시킨다.20이처럼 사용자가 조종기 스위치를 조작하여 모드를 변경하는 단순해 보이는 행위 뒤에는, Commander FSM의 복잡한 내부 로직이 숨어 있다. 상태 전이는 보장되는 것이 아니라, 수많은 비행 전후 안전 점검이라는 ‘가드’를 통과해야만 허용된다. 이는 FSM이 단순한 모드 전환기를 넘어, 기체가 위험한 상태로 진입하는 것을 막는 핵심적인 안전 게이트키퍼 역할을 수행함을 보여준다.
PX4 개발팀 스스로도 Commander 모듈의 복잡성을 인지하고 있다. GitHub의 관련 논의(#10584)에서는 Commander를 “선언적(declarative)”이고 “모델 기반(model-driven)”이며, 문서가 자동으로 생성되는 상태 기계로 재작성하고자 하는 요구사항이 제기되었다.24 이는 거대하고 수작업으로 코딩된 C++ FSM의 유지보수 문제를 해결하고, 보다 형식적이고 검증 가능한 방법론으로 나아가려는 명확한 의지를 보여준다.
ArduPilot은 PX4와는 대조적으로 분산되고 모듈화된 아키텍처를 채택한다. 각 비행 모드는 mode_stabilize.cpp, mode_rtl.cpp와 같이 독립된 클래스와 소스 파일로 캡슐화되어 있다.25 최상위 레벨의 update_flight_mode() 함수는 디스패처(dispatcher) 역할을 하며, 현재 활성화된 모드의 run() 메서드를 주기적으로 호출하는 구조이다.25
ArduPilot은 매우 풍부하고 세분화된 비행 모드를 제공하는 것으로 유명하며, 콥터(Copter) 펌웨어의 경우 25가지 이상의 비행 모드를 지원한다.27 각 모드 클래스는 GPS 요구 여부, 수동 스로틀 제어 여부, 해당 모드에서의 시동 가능 여부 등 자신만의 고유한 속성과 동작을 정의한다.26
표 2: ArduPilot Copter의 주요 비행 모드 및 특성
| 비행 모드 | 고도 제어 | 위치 제어 | GPS 요구 | 요약 |
|---|---|---|---|---|
| Stabilize | - | + | 아니요 | 롤/피치 축의 자동 수평 유지를 지원한다. 27 |
| Alt Hold | s | + | 아니요 | 고도를 자동으로 유지하며, 롤/피치는 사용자가 제어한다. 27 |
| Loiter | s | s | 예 | GPS를 사용하여 현재 위치와 고도를 정밀하게 유지한다. 27 |
| PosHold | s | + | 예 | Loiter와 유사하나, 조종 스틱이 중앙에 있지 않을 때는 수동으로 롤/피치를 제어한다. 27 |
| Auto | A | A | 예 | 사전에 계획된 미션을 자동으로 수행한다. 27 |
| RTL | A | A | 예 | 이륙 지점으로 자동으로 귀환한다. 27 |
범례: - (수동 제어), + (제한이 있는 수동 제어 및 자동 수평 유지), s (안정화된 제어), A (자동 제어)
각 비행 모드의 run() 함수는 조종사의 입력이나 임무 명령을 해석하여 특정 목표값(예: 기울기 각도, 상승률)으로 변환하고, 이를 저수준의 AC_AttitudeControl(자세 제어) 및 AC_PosControl(위치 제어) 라이브러리로 전달하는 책임을 진다.25 이 구조는 고수준의 상태 로직(어떤 비행을 할 것인가)과 저수준의 PID 제어 루프(어떻게 그 비행을 구현할 것인가)를 명확하게 분리한다.
ArduPilot의 모듈식 아키텍처는 확장성을 염두에 두고 설계되었다. 개발자 문서에는 기본 Mode 클래스를 상속하는 새로운 클래스를 생성하여 신규 비행 모드를 추가하는 방법이 명확하게 안내되어 있다.26 이는 커뮤니티 기여를 장려하고 새로운 기능을 쉽게 통합할 수 있는 기반이 된다.
PX4의 중앙 집중식 Commander와 ArduPilot의 분산된 비행 모드 객체 구조는 두 프로젝트의 근본적인 철학 차이를 반영한다.
중앙 집중 대 분산: PX4는 단일 모듈에서 모든 상태를 관리하여 전역 상태의 일관성과 중앙화된 페일세이프 로직을 보장한다. 반면 ArduPilot은 각 모드를 독립적인 객체로 분리하여 코드 격리와 확장성을 극대화한다.
철학적 배경: 이러한 아키텍처 차이는 프로젝트의 기원과 목표에서 비롯된다. PX4는 학술적 연구에서 출발하여 잘 구조화된 범용 “UAV 운영체제”를 지향하는 반면(BSD 라이선스 채택 등), ArduPilot은 더 오랜 개발 역사를 바탕으로 특정 기체 유형에 대한 풍부한 기능 축적과 “즉시 현장에 투입 가능한” 실용성에 중점을 둔다.29
장단점: PX4의 중앙 집중화는 시스템 전체의 상태를 형식적으로 추론하고 검증하기에 용이하다. ArduPilot의 모듈성은 새로운 기능(비행 모드)을 추가하려는 커뮤니티 기여자의 진입 장벽을 낮춘다. ArduPilot이 “새로운 비행 모드 추가 방법” 가이드를 제공하는 반면 26, PX4 내부에서는
Commander의 형식적 재작성을 논의하는 것 24은 이러한 철학적 차이를 명확히 보여주는 사례다.
GCS와의 상호작용: 두 아키텍처 모두 QGroundControl(주로 PX4용)이나 Mission Planner(주로 ArduPilot용)와 같은 GCS 소프트웨어를 통해 관리된다.30 GCS는 사용자가 FSM과 상호작용하는 주된 인터페이스로서, 모드를 선택하고 임무를 업로드하는 창구 역할을 한다. 상호 호환성도 일부 존재하지만, 각 펌웨어에 최적화된 GCS를 사용하는 것이 일반적이다.32
이 장에서는 시야를 넓혀, 로봇 공학 분야에서 FSM과 경쟁하거나 상호 보완하는 다른 주요 제어 아키텍처들을 비판적으로 평가한다.
행동 트리(Behavior Tree, BT)는 매 “틱(tick)”마다 루트(root) 노드부터 평가되는 트리 구조의 제어 패러다임이다.11 BT는 주요 노드 타입으로 구성된다: 복합 노드(Composite Node)는 자식 노드들의 실행 순서를 제어하며, 시퀀스(Sequence, AND처럼 동작)와 셀렉터(Selector/Fallback, OR처럼 동작)가 대표적이다. 데코레이터(Decorator Node)는 자식 노드의 결과를 변형하며(예: Inverter), 리프 노드(Leaf Node)인 액션(Action) 또는 조건(Condition) 노드는 실제 행동을 수행하거나 상태를 점검한다.15 각 노드는 실행 후 Success, Failure, 또는 Running(작업이 여러 틱에 걸쳐 진행될 때) 상태 중 하나를 반환한다.15
FSM과 BT의 근본적인 차이는 ‘전이 로직이 어디에 위치하는가’에 있다.33 FSM에서는 로직이 상태 내부에 존재하여, 각 상태는 자신이 전이할 수 있는 다른 모든 상태를 알아야 한다. 이는 상태 간의 강한 결합(tight coupling)을 유발한다. 반면 BT에서는 전이 로직이 트리의 구조 자체에 내재되어 있다. 액션 노드는 다른 액션에 대해 전혀 알 필요가 없으며, 상위의 복합 노드가 어떤 액션을 실행할지 결정한다. 이 단 하나의 설계 차이가 모듈성, 반응성, 확장성 등 모든 면에서 두 패러다임의 극명한 차이를 만들어낸다.
표 3: FSM과 행동 트리(BT)의 속성 비교 분석
| 속성 | 유한 상태 기계 (FSM) | 행동 트리 (BT) |
|---|---|---|
| 전이 로직 위치 | 상태(State) 내부에 명시적으로 코딩됨 33 | 트리 구조(Tree Structure)에 암시적으로 내재됨 11 |
| 모듈성 | 낮음. 상태 추가/삭제 시 다수의 전이 수정 필요 11 | 높음. 하위 트리는 재사용 가능한 독립적 모듈 11 |
| 반응성 | 낮음. 고우선순위 이벤트 처리를 위해 모든 상태에서 전이 필요 13 | 높음. 루트에 가까운 노드가 우선적으로 평가되어 즉각적 반응 가능 13 |
| 확장성 | 낮음. ‘상태 폭발’ 문제로 복잡도 급증 11 | 높음. 모듈식 구조로 복잡한 행동을 체계적으로 확장 가능 13 |
| 유지보수성 | 복잡해질수록 어려움. ‘스파게티 코드’화 경향 13 | 상대적으로 용이. 로직이 지역화되어 수정 용이 35 |
| 가독성 | 단순한 경우 매우 직관적이나, 복잡해지면 파악 어려움 13 | 목표 지향적 구조. 단, 초심자에게는 학습 곡선 존재 33 |
계층적 임무 네트워크(Hierarchical Task Network, HTN)는 FSM이나 BT와는 근본적으로 다른 패러다임이다. HTN은 반응형 제어기가 아니라, 선언적 계획기(deliberative planner)이다. HTN은 “소포 배달”과 같은 고수준의 추상적인 임무(abstract task)를 “메서드(method)” 라이브러리를 사용하여 더 작은 단위의 원시 행동(primitive action)들로 분해한다.37
FSM과 BT는 기본적으로 현재 시점에서 “지금 무엇을 할 것인가?”를 결정하는 반응형(reactive) 아키텍처다. 반면 HTN은 실행을 시작하기 전에 목표를 달성하기 위한 전체 행동 순서, 즉 ‘계획(plan)’을 생성하는 숙고형(deliberative) 아키텍처다.11 HTN의 관심사는 “어떻게 목표를 달성할 것인가?”이며, 이는 FSM/BT의 관심사와는 차원이 다르다.
HTN은 복잡하고 다단계로 이루어진 임무를 계획하는 데 적합하다. 예를 들어, 여러 대의 드론이 협력하여 물류를 처리하거나, 정해진 순서에 따라 정찰과 특정 행동을 수행해야 하는 군사 작전과 같은 시나리오에서 HTN은 효과적인 계획을 수립할 수 있다.40
모든 문제를 해결할 수 있는 단 하나의 “만능(silver bullet)” 아키텍처는 존재하지 않으며, 문제의 특성에 따라 최적의 선택이 달라진다.33
가장 강력한 자율 시스템은 종종 이러한 패러다임들을 결합한 하이브리드 접근 방식을 채택한다. 이 세 가지 패러다임은 단순히 상호 교환 가능한 대안이 아니라, 순수한 ‘반응(reaction)’에서 순수한 ‘숙고(deliberation)’에 이르는 제어의 스펙트럼을 형성한다. 완전한 자율 시스템은 이 스펙트럼 전체를 아우를 필요가 있다. 즉, 고수준 임무 계획을 위한 HTN, 전술적 실행과 반응을 위한 BT, 그리고 그 기반에서 안전을 보장하는 핵심 비행 모드 관리를 위한 FSM이 조화롭게 결합된 형태가 될 것이다.
이 마지막 장에서는 결정론적 세계의 FSM이 확률적이고 적응적인 인공지능(AI) 및 머신러닝(ML)과 만나는 최첨단 연구 동향을 탐구한다.
AI/ML과 FSM의 통합은 FSM을 대체하는 것이 아니라 보강하는 하이브리드 아키텍처 형태로 나타나고 있다. 이 구조에서 FSM은 “무엇을 할 것인가(what to do)”에 해당하는 고수준 임무 상태를 관리하는 역할을 유지하며, ML 모델은 “어떻게 그것을 잘할 것인가(how to do it well)”에 해당하는 복잡하고 불확실한 하위 문제를 해결한다.43
고전적인 FSM은 ‘버튼 눌림’과 같이 단순하고 이산적인 입력을 요구한다. 그러나 현실 세계는 복잡하고, 연속적이며, 고차원적인 데이터로 가득 차 있다. AI, 특히 딥러닝 기반의 인식 기술은 이러한 복잡한 현실 세계의 센서 데이터(이미지, LiDAR 등)를 FSM이 이해할 수 있는 깨끗하고 상징적인 입력(예: obstacle_detected=true, target_identified=true)으로 변환하는 ‘의미론적 압축기(semantic compressor)’ 역할을 한다. 예를 들어, 전력선 검사 임무를 수행하는 FSM은 ‘결함 발견’이라는 입력을 필요로 한다.46 카메라 영상으로부터 이 입력을 얻기 위해, 결함을 식별하도록 훈련된 컴퓨터 비전 모델이 사용된다.43 이처럼 ML 모델은 고차원의 물리적 세계와 FSM의 상징적 세계 사이의 간극을 메워주며, FSM이 훨씬 더 풍부한 환경 이해를 바탕으로 동작할 수 있게 한다.
결함 탐색(SEARCH_FOR_DEFECT) 상태에 있을 때, 결함 검사(INSPECT_DEFECT) 상태로의 전이는 단순한 센서 값이 아니라 결함을 식별하도록 훈련된 컴퓨터 비전 모델의 출력에 의해 촉발된다.46 여기서 ML 모델은 FSM의 ‘이벤트 기반’ 전이를 위한 ‘이벤트’를 생성하는 역할을 한다.강화학습(Reinforcement Learning, RL)의 통합은 제어 시스템 설계 패러다임에 근본적인 변화를 가져오고 있다. 엔지니어가 직접 PID 게인을 튜닝하거나 특정 기동을 위한 규칙을 명시적으로 코딩하는 대신, 이제는 보상 함수(reward function)와 훈련 환경을 설계하고, 최적의 정책은 시스템이 스스로 ‘학습’하게 된다.49
상태 내 정책 최적화: RL은 FSM의 특정 상태에 해당하는 복잡한 행동을 위한 최적의 정책을 학습하는 데 적용될 수 있다. 예를 들어, 움직이는 표적에 자율적으로 착륙하는 정책 52, 복잡한 공중 투하 기동을 수행하는 정책 53, 또는 장애물을 회피하며 항해하는 정책 50을 학습할 수 있다. 이 경우 RL 에이전트는 특정 FSM 상태
내에서 취해야 할 최적의 행동을 학습한다.
상태 전이 자체의 최적화: 더 진보된 적용 사례는 상태 간의 ‘전이’ 자체를 최적화하는 것이다. 수직이착륙기(VTOL)의 비행 모드 전환 제어 연구가 대표적인 예다. RL 에이전트는 ‘호버링(HOVER)’ 상태에서 ‘전진 비행(FORWARD_FLIGHT)’ 상태로 안전하고 효율적으로 전환하기 위한 최적의 제어 시퀀스를 학습한다.54 이는 엔지니어가 수작업으로 설계하기 매우 어려운 비선형적인 제어 문제를 해결하는 강력한 방법이다.
미래: 전이 정책 학습: 가장 발전된 형태는 FSM의 고수준 전이 로직 자체를 RL로 학습하는 것이다. 여러 선택지가 있는 복잡한 상황에서, RL 에이전트는 전체 임무 목표와 학습된 가치 함수를 기반으로 전이할 최적의 다음 상태를 선택하는 정책을 학습할 수 있다.55 이는 FSM을 하드코딩된 로직 다이어그램에서 동적이고 목표 지향적인 의사결정 엔진으로 변모시킬 잠재력을 가진다.
드론 자율성의 미래는 FSM과 AI의 대결이 아니라 그들의 통합과 합성에 있다. 가장 견고하고 유능한 시스템은 하이브리드 아키텍처가 될 것이다. 이를 “지능형 FSM(Intelligent FSM, iFSM)”이라는 개념적 모델로 구상해 볼 수 있다.
이륙, 이동, 정찰, 귀환 등 명확하게 정의된 임무 단계를 유지한다. FSM의 구조적 예측 가능성은 그대로 유지된다.이 하이브리드 모델은 전체 임무 흐름에 대한 FSM 구조의 예측 가능성, 검증 가능성, 안전성을 유지하면서, 동시에 인식의 복잡성, 환경의 불확실성, 행동의 최적화를 처리하기 위해 AI의 강력한 성능을 활용한다.
본 보고서는 유한 상태 기계(FSM)가 그 예측 가능성과 신뢰성 덕분에 드론 임무 관리의 견고한 기반으로 지속적인 역할을 하고 있음을 확인했다. 동시에, 복잡성이 증가함에 따라 발생하는 내재적인 확장성 문제를 해결하기 위해 계층적(HFSM), 확장(EFSM) 모델로 진화해왔음을 살펴보았다. PX4와 ArduPilot의 사례 분석을 통해, FSM 아키텍처가 각 프로젝트의 핵심 철학을 어떻게 반영하는지(중앙 집중형 대 분산형)를 명확히 했다.
또한, 행동 트리(BT)와 계층적 임무 네트워크(HTN)와 같은 대안 패러다임과의 비교를 통해 각 아키텍처의 장단점을 분석했다. BT는 복잡하고 동적인 에이전트 행동에 요구되는 모듈성과 반응성 측면에서 우월하며, HTN은 고수준의 선언적 임무 계획에 강점을 가진다. 이들은 FSM을 대체하는 것이 아니라, 반응에서 숙고에 이르는 제어 스펙트럼 상에서 상호 보완적인 역할을 수행한다.
본 보고서의 핵심 결론은 미래 드론 아키텍처가 FSM의 완전한 대체가 아닌, FSM을 핵심 요소로 포함하는 하이브리드 시스템으로 발전할 것이라는 점이다. 안전 최우선 시스템에서 FSM이 제공하는 예측 가능성과 검증 가능성은 포기하기에는 너무나도 가치 있는 특성이기 때문이다. 따라서 미래는 FSM의 강화와 더 큰 하이브리드 아키텍처로의 통합 방향으로 나아갈 것이다.
궁극적으로 미래의 드론 임무 관리 시스템은 다음과 같은 다층적(multi-layered) 하이브리드 아키텍처로 수렴할 것으로 전망된다.
이러한 비전은 FSM의 전통적인 강점인 안정성과 AI의 혁신적인 능력인 적응성을 결합하여, 더욱 유능하고 견고하며 진정으로 자율적인 드론 시스템을 향한 명확한 경로를 제시한다. 이는 본 보고서의 모든 분석을 종합하여 도출한, 해당 기술 분야에 대한 논리적이고 미래지향적인 예측이다.