행동 트리(Behavior Trees)와 유한 상태 기계(FSM)에 대한 포괄적 분석
자율 에이전트, 복잡한 비디오 게임 캐릭터 및 산업용 로봇 시스템의 기반을 형성하는 의사 결정 메커니즘은 현대 소프트웨어 공학 및 인공지능 연구에서 가장 비판적이고 가장 많이 논의되는 분야 중 하나를 구성합니다. 에이전트가 끊임없이 변화하는 환경적 자극에 어떻게 반응할지, 손에 쥔 수많은 목표 중 어떤 것에 우선순위를 둘지, 그리고 특정 작업을 어떤 순서로 실행할지는 전적으로 그 기반이 되는 의사 결정 아키텍처의 견고성과 유연성에 달려 있습니다. 역사적 발전 과정을 살펴보면 이 분야는 수년 동안 유한 상태 기계(Finite State Machines - FSM)에 의해 지배되어 왔음을 알 수 있습니다. 그러나 디지털 세상과 물리적 로봇 작업의 복잡성이 증가함에 따라 개발자와 연구자들은 더 확장 가능하고 반응성이 뛰어나며 모듈화된 구조를 찾게 되었고, 이러한 탐구는 행동 트리(Behavior Trees - BT)와 같은 혁신적인 계층적 구조의 탄생을 이끌었습니다.
본 보고서는 자율 시스템의 의사 결정 및 행동 모델링을 위해 오늘날 업계 표준으로 인정받는 이 두 가지 핵심 아키텍처를 모든 기술적 세부 사항, 수학적 기반, 역사적 진화, 산업적 사용 사례 및 상호 간의 구조적 장단점 맥락에서 심층적으로 검토합니다. 또한 현대 게임 엔진(예: Unreal Engine)의 최신 하이브리드 접근 방식과 상태 트리(State Trees)와 같은 차세대 솔루션도 이 분석의 필수적인 부분으로 평가됩니다.
유한 상태 기계(FSM): 이론적 인프라와 수학적 기초
유한 상태 기계(Finite State Machine, FSM)는 시스템이 한 번에 단 하나의 미리 정의된 상태(state)에만 머물 수 있으며, 특정 외부 입력이나 내부 이벤트(inputs/events)에 반응하여 상태 간 전환(transition)을 수행하는 추상적인 머신 모델입니다. 계산 이론의 가장 근본적인 빌딩 블록 중 하나인 이 모델은 컴퓨터 과학에서 알고리즘 설계부터 디지털 전자 회로 구축에 이르기까지 광범위하게 활용됩니다.
FSM은 이론적으로 결정론적(deterministic) 또는 비결정론적(non-deterministic)의 두 가지 주요 범주로 나누어 설계될 수 있습니다. 그러나 계산 이론의 핵심 정리 중 하나는 임의의 비결정론적 유한 상태 기계에 대해, 완전히 동일한 언어를 인식하고 동일한 행동 출력을 생성하는 동등한 결정론적 유한 상태 기계가 항상 구축될 수 있음을 증명합니다. 이 정리는 소프트웨어 엔지니어가 복잡한 시나리오를 더욱 예측 가능한 결정론적 구조로 환원할 수 있도록 해줍니다.
논리적 표현과 상태 전환 동역학
유한 상태 기계는 본질적으로 방향성 그래프(directed graph) 또는 상태 다이어그램(state diagram)으로 시각화되고 표현됩니다. 이 방향성 그래프에서 노드(nodes)는 추상 머신의 내부 상태를 나타내고, 이 노드들을 연결하는 방향성 화살표(edges)는 상태 전환을 나타냅니다. 임의의 "t" 시점에서 시스템의 현재 상태는 항상 이전 상태와 현재 시스템에 들어오는 입력의 결정론적 함수로 계산됩니다.
수학적 맥락에서 이 상태 전환 함수는 다음과 같이 표현됩니다.
이 공식에서 시스템의 다음 상태를, 머신의 이전(현재) 상태를, 현재 입력(input) 값을, 그리고 은 상태 전환 함수(state transition function)를 나타냅니다. 이 관계는 문헌에서 종종 상태 집합(S)과 입력 집합(I)의 데카르트 곱을 다시 상태 집합으로 매핑하는 연산, 즉 의 형태로도 표시됩니다. 상태 기계는 생성하는 출력(output)의 성격에 따라 두 가지 주요 아키텍처 하위 클래스로 나뉩니다. 무어 머신(Moore Machine) 모델에서는 출력 함수가 시스템의 현재 상태에만 의존하는 반면(), 밀리 머신(Mealy Machine) 모델에서는 출력 함수가 현재 상태와 즉각적인 입력 모두에 동시적으로 의존합니다().
시스템 설계에서 상태와 입력은 일반적으로 이진(binary) 알파벳 또는 미리 정의된 열거형(enum)으로 표현되며, 과 함수는 대개 룩업 테이블(look-up table) 또는 상태 전환 테이블(state transition table) 형태로 코딩됩니다. 소프트웨어 아키텍처에서 전환의 발생은 단순히 입력의 존재 여부뿐만 아니라 추가 조건(guards)의 충족 여부에도 좌우됩니다. 전형적인 UML 상태 다이어그램이나 모던 엔진 구현에서 전환의 표기는 대개 트리거[조건]/효과 (trigger[guard]/effect) 구문으로 표현됩니다. 여기서 트리거(trigger)는 신호, 호출, 타이밍 또는 변경 이벤트일 수 있습니다. 조건(guard)은 전환이 일어나기 위해 검증되어야 하는 추가적인 논리적 테스트입니다. 효과(effect)는 전환 중에 실행되는 특정 작업입니다.
그럼에도 불구하고 FSM 아키텍처의 강점은 단순히 상태 간 전환에만 있는 것이 아니라, 특정 상태에 진입할 때, 그 상태에 머물 때, 그리고 그 상태를 벗어날 때 실행될 수 있는 액션에도 있습니다. FSM 상태에 진입할 때(entry action), 상태 내부에 있는 동안 주기적으로(during action), 그리고 상태를 벗어날 때(exit action) 특수 코드 블록이 실행될 수 있습니다. 예를 들어 무선 시스템에서 기기가 "라디오" 상태일 때 "다음" 버튼을 누르면 다음 라디오 방송국으로 전환되는 반면, 기기가 "CD" 상태일 때 동일한 "다음" 버튼을 누르면 다음 트랙으로 전환이 트리거됩니다. 이처럼 정확히 동일한 외부 자극이 머신이 위치한 맥락적 상태에 따라 완전히 다른 액션을 생성합니다.
산업 표준에서의 FSM 위치와 실용적 장점
유한 상태 기계는 디지털 회로 설계부터 게임 산업에 이르는 방대한 역사적 배경 속에서 산업 표준으로 자리매김해 왔습니다. 가장 두드러진 장점은 개념적으로 이해하기 매우 쉽고, 아키텍처가 단순하며, 하드웨어/소프트웨어 수준에서 엄청난 실행 속도를 자랑한다는 점입니다. 디자이너가 캐릭터나 시스템이 무엇을 할 수 있는지, 어떤 상태로 전환할 수 있는지를 상자와 화살표 다이어그램("box and arrow" diagram)을 통해 시각화할 수 있다는 점은 FSM을 코딩 과정에서 매우 직관적이고 디버깅(debugging)이 쉬운 구조로 만들어 줍니다.
특히 시스템의 실시간 모드, 애니메이션 단계, 또는 캐릭터의 물리적 상태를 명확하고 불투명한 경계로 정의하는 것이 중요한 영역에서 FSM은 대체 불가능합니다. FSM이 완벽하게 작동하는 구체적인 맥락은 다음과 같습니다.
첫째, 격투 게임(fighting games)은 FSM 아키텍처가 가장 빛을 발하는 응용 분야 중 하나입니다. 격투 게임에서 캐릭터의 "공격", "점프", "스턴(Stunned)", "웅크리기", 또는 "방어" 상태는 서로 명확하고 논리적인 선으로 구분되어야 합니다. 예를 들어 캐릭터가 상대에게 강력한 일격을 맞아 "스턴" 상태에 진입한 경우, 플레이어가 점프 버튼을 누르더라도 캐릭터는 점프할 수 없습니다. FSM 아키텍처를 사용하지 않는다면 캐릭터가 어떤 액션을 시도할 때마다 수십 개의 "만약 캐릭터가 스턴 상태가 아니고, 공중에 있지 않으며, 공격 애니메이션에 갇혀있지 않다면..."과 같이 끝없이 이어지고 유지보수가 불가능한 중첩 조건문(conditional)을 작성해야 합니다. FSM은 "캐릭터가 A 상태라면, 오직 B 또는 C 상태로만 전환할 수 있다"라는 로직을 완벽하게 처리하여 코드 블록의 거대한 스파게티 혼란을 방지합니다.
둘째, 캐릭터 애니메이션 컨트롤러는 대개 FSM 기반입니다. 업계 리더인 Unreal Engine과 같은 최신 게임 엔진에서는 캐릭터 애니메이션이 백그라운드에서 상태 기계를 실행하는 "Animation Blueprints"(애니메이션 블루프린트)라는 인터페이스로 제어됩니다. 캐릭터가 "대기(Idle)" 애니메이션에서 "걷기(Walk)" 애니메이션으로, 거기서 다시 "달리기(Run)" 애니메이션으로 언제 어떻게 전환될지는 이 상자와 화살표 인터페이스로 관리되는 FSM의 핵심 기능입니다.
셋째, 아케이드 시스템과 단순한 의사결정 로직이 필요한 게임에서 FSM은 "KISS"(Keep It Simple, Stupid - 단순하게 유지하라) 원칙에 따라 작동하기에 이상적입니다. 아케이드 스타일 게임의 상당수에서 적들은 "순찰", "추적", "공격" 또는 "도망"과 같이 매우 제한적이고 구체적인 상태를 가집니다. Native C++ 환경에서 구현된 FSM은 최신 프로세서에서 나노초 수준으로 작동하여 뛰어난 성능을 제공합니다. 소프트웨어 개발자는 익명 열거형(unnamed enums)을 사용하여 상태를 정의하고, "단일 거대한 switch"(one big switch) 구문이나 비트 마스킹 기법을 통해 이러한 상태를 이벤트 ID(event IDs)에 연결할 수 있습니다. 이 구조가 가져오는 깔끔한 코드 아키텍처는 FSM의 런타임 컴파일(hot-recompiling)을 허용하며, SetState() 같은 서브루틴 대신 이벤트 핸들러(event handlers)에서 0이 아닌 상태 ID를 반환함으로써 안전하고 중단 없는 실행(execution safety)을 보장합니다. 이러한 선형적 실행 흐름은 게임 루프에서 어떠한 끊김(stuttering)도 방지하여 높은 프레임 레이트(framerate) 달성을 가능하게 합니다.
아키텍처 위기 지점: 상태 폭발(State Explosion) 문제
FSM은 제한된 수의 상태를 가진 결정론적 행동 모델에 대해 완벽하고 고성능이지만, 자율 시스템의 복잡성, 환경 변수의 수, 그리고 인공지능이 갖출 것으로 기대되는 행동 레퍼토리가 증가함에 따라 구조적으로붕괴하는 경향이 있습니다. 문헌에서는 이 만성적인 취약성을 "상태 폭발(State Explosion)"이라고 부릅니다.
FSM 아키텍처의 근본적인 제약은 머신이 한 번에 단 하나의 상태에만 머물 수 있다는 점입니다. 만약 캐릭터가 동시에 달리면서 사격도 해야 한다면, FSM 아키텍처에서 캐릭터는 "달리기"와 "사격" 상태에 동시에 존재할 수 없습니다. 대신 "달리면서 사격하기"라는 완전히 새로운 하이브리드 상태를 만들어야 합니다. 시스템에 추가되는 모든 새로운 변수는 기존의 모든 상태와의 가능한 조합만큼 새로운 상태를 생성할 것을 요구합니다. 모델이 표현해야 하는 상태의 수는 변수 집합들의 데카르트 곱만큼 거대한 규모로 치솟습니다.
더욱 치명적인 문제는 증가하는 상태 수로 인해 발생하는 전환(transition) 복잡성입니다. FSM에 상태를 추가하는 것은 단순히 그 상태를 생성하는 것을 의미하지 않으며, 새로 추가된 이 상태로 시스템 내의 다른 모든 관련 상태에서 어떻게 진입할 수 있고, 이 상태에서 다시 어떤 상태로 돌아갈 수 있는지 하나하나 구체적인 규칙으로 코딩해야 함을 뜻합니다. 컴퓨터 과학 저조(jargon)에서 상태 수의 증가에 따른 전환 복잡성의 증가 속도는 제곱 비례로 표현됩니다. 이 기하급수적 증가 속도는 통신망의 가치가 사용자 수의 제곱에 비례한다는 네트워크 경제학의 메트칼프 법칙(Metcalfe's Law)과 유사한 누적 복잡성 부하를 창출합니다.
FSM이 약 10개의 상태에 도달하면 관리가 어려워지고, 상태 수가 40개에 달할 때(예: 고급 세키로 또는 다크 소울 스타일의 보스 전투 AI), 코드 파일은 수백 줄의
전환 로직으로 가득 차게 되며 말 그대로 "스파게티 코드"(Spaghettification)로 변모합니다. 13 이 단계에 이르면 코드 유지보수(maintenance)나 디버깅(debugging)은 악화로 변질됩니다. 발생한 논리적 버그(bug)의 근본 원인이 수십 가지 다른 상태 전환 중 하나에서의 잘못된 트리거, 잘못 설계된 우선순위, 또는 잊혀진 전환 화살표일 수 있기 때문입니다. 23
이러한 상태 폭발을 완화하고 스파게티 코드의 형성을 어느 정도 방지하기 위해 "계층적 유한 상태 기계"(Hierarchical Finite State Machines - HFSM)가 개발되었습니다. HFSM 모델에서는 상태가 중첩 가능한 방식으로 설계되며, "부모 상태(parent state)"가 그 안에서 독립적으로 작동하는 하위 상태(substates)들을 품습니다. 예를 들어 "전투"라는 메인 상태는 그 안에 "엄폐", "조준", "사격" 하위 상태를 실행하는 서브 머신을 가질 수 있습니다. 시스템이 "전투" 메인 상태에 있을 때 플레이어가 멀어지면, 어떤 하위 상태에 있었는지와 상관없이 메인 상태에서 "순찰" 상태로 단 한 번의 "그룹 전환(Group Transition)"을 수행하는 것만으로 내부의 각 하위 상태마다 개별적으로 탈출 또는 취소 코드를 작성해야 하는 필요성이 사라집니다. 8 전환 포인트(transition points)와 이벤트 트리거 우선순위(event triggering precedence) 덕분에 HFSM은 FSM의 역량을 한 차원 더 끌어올립니다. 24 그러나 시스템 복잡성이 특정 임계값을 초과할 때(예: 수십 개의 상태와 수백 개의 전환을 포함하는 복잡한 태스크 플래너에서), HFSM조차도 시각적 복잡성에 굴복하며 구조적으로 취약해집니다. 8
행동 트리(Behavior Trees): 진화, 구조 및 실행 로직
FSM(유한 상태 기계)과 HFSM이 가져온 기하학적 확장성 장벽으로 인해, 자율 캐릭터와 에이전트의 의사 결정 과정에서 완전히 새로운 아키텍처 패러다임의 탄생이 필수가 되었습니다. 행동 트리(Behavior Trees - BT)는 정확히 이러한 정체 현상을 극복하고, 인공지능에게 "이것이 발생하면, 저것을 수행하라"는 식의 엄격한 전환 미로 속에서 길을 잃지 않는 시각적이고 명확한 로드맵을 제공하기 위해 개발된 모듈식 계층적 의사 결정 구조입니다. 2
역사적 기원과 산업적 채택 과정
행동 트리가 정확히 언제, 어디서 등장했는지에 대한 학술적 및 산업적 설명에는 약간의 차이가 있지만, 이러한 구조가 고도의 연구실보다는 게임 개발 스튜디오의 최전선에서 직접 탄생했다는 것이 널리 인정받고 있습니다. 2 문서화된 가장 초기 사례 중 하나는 Maxis가 개발한 1996년작 게임 SimCopter입니다. 전 Maxis 개발자인 돈 홉킨스(Don Hopkins)의 설명에 따르면, 게임 내 NPC를 제어하기 위해 "SimAntics"라고 불리는 시각적 언어가 사용되었으며, 이는 게임 코드의 people.df 파일에서 "반응 트리(reaction trees)"로 언급되었습니다. 이 파일의 주석에는 "한 반응 트리가 다른 반응 트리에서 호출될 수는 있지만 그동안 중단될 수는 없다"와 같은 현대 행동 트리 메커니즘을 연상시키는 정의가 포함되어 있습니다. 25
그러나 행동 트리 아키텍처가 현대적인 의미로 공식화되고, 산업 표준으로 자리 잡으며, 견고한 학술적 기반을 갖추게 된 것은 대다수 데미안 아이슬라(Damian Isla)가 2005년 게임 개발자 콘퍼런스(GDC)에서 Halo 2 게임의 혁신적인 AI 아키텍처를 발표한 상징적인 강연("Handling Complexity in the Halo 2 AI")을 통해서였습니다. 3 Halo 2 개발 과정에서 Bungie 팀은 FSM이 야기한 두 가지 큰 난제에 직면했습니다: 급증하는 행동 다양성 앞에서 시스템이 확장성을 잃는 것과, AI가 빠른 결정들 사이에서 갈피를 잡지 못하는 현상인 "디더링(dithering)" 문제입니다. 3
FSM으로 인해 발생하는 이러한 정신적 과부하(mental bandwidth)를 해결하고자 한 팀은 캐릭터 행동을 "행동 DAG(Directed Acyclic Graphs - 방향성 비순환 그래프)"라고 부르는 계층 구조 안에 안착시켰습니다. 3 이 시스템은 약 50개의 서로 다른 핵심 행동을 담고 있었습니다.
아이슬라가 정의한 구조에서 트리의 상단에 있는 노드들은 의사 결정 알고리즘을 담당하고, 가장 말단의 리프 노드들은 행동 실행을 담당했습니다. 이 접근법은 AI가 무엇을 해야 할지 알 뿐만 아니라 상식적인(common sense) 행동을 하도록 만들었습니다. 또한 캐릭터들은 목표를 인식하기 위해 자체적인 "목표 리스트(target lists)"와 공간적 인식 능력(firing positions)을 가지고 있었습니다. 3 이 모듈식 구조는 매우 유연하고 결함 허용력이 뛰어나며 가독성이 좋아서, 이 개념은 순식간에 로봇 공학 분야와 학계로도 확산되었습니다. 오늘날 무인 항공기부터 산업용 협동 로봇(collaborative robots) 및 자율 주행 시스템에 이르기까지 광범위한 분야에서 행동 트리는 사실상의 표준(de facto standard)이 되었습니다. 1
BT의 구조적 아키텍처와 노드(Node) 계층 구조
행동 트리는 행동과 결정을 디지털 레고 블록처럼 연결하는 계층적 트리 자료 구조입니다. 2 고전적인 결정 트리(Decision Trees)와 달리 BT는 결과에 도달할 때까지 단 하나의 경로만 추적하는 것에 그치지 않고, 노드의 논리적 제어, 비동기 실행 프로세스(execution flows), 그리고 인터럽트(interrupts)를 트리의 루트(root)에서 리프(leaves)로 전달되는 정기적인 신호(보통 "틱(tick)"이라고 함)를 통해 관리합니다. 1
이 아키텍처의 작동에서 가장 중요하고 차별화되는 개념은 각 노드가 자신에게 전달된 "틱" 작업의 결과로 상위 노드(parent node)에 반드시 논리적 상태(status)를 반환한다는 점입니다. 이 반환 상태는 세 가지 보편적인 종류로 구성됩니다:
Success (성공): 노드가 작업을 완전하고 원활하게 완료했거나 테스트된 조건이 참입니다.
Failure (실패): 노드가 작업을 수행하지 못했거나, 장애물에 부딪혔거나, 테스트된 조건이 거짓입니다.
Running (실행 중): 작업이 아직 완료되지 않았으며, 행동을 완료하기 위해 여러 번의 시간 주기(tick/frame)가 필요합니다. 8
바로 이 "Running" 상태의 존재가 행동 트리를 다른 모든 고전적 트리 구조와 구분 짓는 기술적 도약입니다. 27 물리적인 로봇이 "목표로 걸어가기" 명령을 0.1초 만에 끝내거나 게임 캐릭터가 "상자 열기" 애니메이션을 즉시 완료할 것으로 기대할 수는 없습니다. Running 상태는 트리의 해당 특정 분기가 백그라운드에서 비동기적으로 행동을 계속 수행할 수 있도록 허용하는 동시에, 시스템이 차단되어 멈추는 현상(blocking the execution thread)을 방지합니다. 27
행동 트리는 구조적으로 세 가지 주요 노드 범주로 구성됩니다: 컴포지트, 데코레이터, 그리고 리프. 28
1. 컴포지트 노드 (Composite Nodes)
컴포지트 노드는 트리의 분기점입니다. 둘 이상의 하위 노드(자식)를 가지며, 자신에게 연결된 이러한 하위 노드가 어떤 순서로, 어떤 조건으로, 또는 동시에 실행될지 결정하는 빌딩 블록입니다. 28
선택자 (Selector / Fallback Nodes): 기본 프로그래밍 로직의 OR 연산자의 반영입니다. 자신에게 연결된 하위 노드들을 왼쪽에서 오른쪽으로 순서대로 실행합니다. 하위 노드 중 하나가 Success 또는 Running을 반환하면, 선택자 노드는 다른 자식들의 테스트를 즉시 중단하고 이 상태를 상위 노드로 전달합니다. 선택자 노드가 Failure(실패)를 반환하는 유일한 경우는 자신에게 연결된 모든 하위 노드가 실패하는 경우입니다. 이 구조는 에이전트의 생존 우선순위나 대체 계획(fallback)을 결정하는 데 완벽합니다: 시스템은 먼저 "체력 회복" 옵션을 시도하고, 실패하면 "엄폐하기" 옵션으로 넘어가며, 그마저도 안 되면 "도망치기" 옵션을 시도합니다. 어느 하나가 성공하는 순간 행동 체계가 충족됩니다. 8
시퀀스 (Sequence Nodes): 기본 프로그래밍의 AND 연산자에 해당하는 행동 트리 버전입니다. 하위 노드들을 왼쪽에서 오른쪽으로 시도합니다. 그러나 선택자와 달리 시퀀스는 하위 노드 중 하나가 Failure를 반환하면 즉시 작업을 중단하고 상위 노드에 Failure를 반환합니다. 시퀀스가 Success를 반환하려면 포함된 모든 하위 노드가 예외 없이 성공해야 합니다. 이 노드는 작업의 논리적 단계 체인을 구축하는 데 사용됩니다: NPC가 문을 통과하는 데 필요한 체인은 "문으로 걷기", 이어서 "잠금 해제하기", 이어서 "손잡이 내리기", 이어서 "안으로 들어가기" 형태로 구성됩니다. 문이 잠겨 있고 캐릭터가 잠금을 해제할 수 없는 경우(Failure)에는 다음 단계로 넘어갈 이유가 없으므로 시퀀스가 실패하고 캐릭터는 문을 통과하려는 계획을 포기합니다. 8
병렬 노드 (Parallel Nodes): 컴포지트 패밀리에서 가장 복잡한 구성원 중 하나입니다. 하위 노드들을 왼쪽에서 오른쪽으로 순서대로가 아니라 동시에(동기식으로) 실행합니다. 특정 성공 또는 실패 정책에 따라(예: "하위 노드 중 어느 하나라도 성공하면 작업 종료" 또는 "모두 성공할 때까지 대기") 트리에 결과를 반환합니다. 캐릭터가 "말을 하면서 동시에 손짓을 하는 것"이나 로봇 차량이 "레이더 스캔을 수행하면서 동시에 목표를 향해 전진하는 것"과 같은 동시 작업 제어에 사용됩니다. 30
2. 데코레이터 노드 (Decorator Nodes)
디자인 패턴의 Decorator 패턴과 유사하게, 단 하나의 하위 노드만 가질 수 있으며 해당 하위 노드가 반환한 결과를 다양한 정책에 따라 수정하거나 실행을 조건에 묶어주는 노드입니다. 8
Inverter (반전기): 고전 프로그래밍의 NOT 연산자입니다. 하위 노드의 Success 결과를 Failure로, Failure 결과를 Success로 변환합니다.
Limiter (제한기): 하위 노드가 특정 초 단위로 또는 전체 수명 주기 동안 지정된 횟수만큼만 실행되도록 허용하며, 이 할당량을 초과하는 경우 실패를 반환합니다.
Timer (타이머): 하위 노드의 행동을 즉시 실행하는 대신 일정 시간 동안 지연시킵니다. 8
3. 리프 노드 (Leaf Nodes)
트리의 가장 말단, 최하위 수준에 위치하며 본질적으로 어떠한 하위 노드도 가질 수 없는 실행 노드입니다. 29 리프는 가상 게임 세상이나 실제 로봇 센서와 직접 상호 작용하며 시스템이 구체적인 결과를 만들어내는 종착점입니다. 22
행동 (Actions/Tasks): 세상에 물리적 또는 논리적 변화를 만들거나, 애니메이션을 재생하거나, 소리를 내거나, 모터에 전력을 보내는 실제 코드 블록입니다 ("발사하기", "목표로 걷기", "모터 정지").
조건 (Conditions/Queries): 대개 Success 또는 Failure를 반환하며 어떠한 행동도 수행하지 않는 논리적 즉각 제어 및 센서 쿼리입니다 ("적이 시야 범위 내에 있는가?", "남은 탄약이 있는가?", "배터리 잔량이 20% 미만인가?"). 8
이벤트 기반 (Event-Driven) 행동 트들과 관찰자 (Observers)
초기의 고전적인 BT는 매 "틱" 작업(대개 매 시각적 프레임)마다 트리를 루트부터 시작해 지속적으로 아래 방향으로 재평가하는 폴링(polling) 로직으로 작동했습니다. 19 이 방식은 반응성 측면에서는 완벽했지만, 매 프레임을 계산할 때마다 엄청난 중앙처리장치(CPU) 부하를 발생시켰습니다. 트리가 깊어질수록 매 프레임마다 맨 위에서 맨 아래까지 모든 조건을 반복해서 테스트하는 비용은 감당하기 힘들어졌습니다. 9
Unreal Engine과 같은 현대의 게임 엔진과 산업 표준들은 이러한 하드웨어적 병목 현상을 극복하기 위해 아키텍처를 "이벤트 기반 행동 트리(Event-Driven Behavior Trees)" 모델로 진화시켰습니다. 32 이 혁신적인 구조에서 시스템은 매 "틱"마다 조건을 처음부터 끝까지 경찰처럼 검사하는 대신, "관찰자 중단(Observer Aborts)"이라고 불리는 반응형 데코레이터를 사용합니다. 예를 들어, 고양이 AI가 쥐를 쫓고 있다면, 고전적인 병렬 노드는 쥐가 구멍으로 들어갔는지 매초마다 질문합니다. 이벤트 기반 구조에서는 "쥐를 관찰할 수 있는가?" 조건이 Observer로
트리에 배치됩니다. 쥐가 구멍으로 도망치는 순간(event), 이 이벤트가 트리거되고 관찰자는 고양이의 현재 "달리기"와 "점프" 시퀀스를 즉시 중단(abort)시킵니다. 이를 통해 인공지능은 실제로 상태가 변경되었을 때만 재계산을 수행하므로 CPU 전력의 엄청난 절감 효과를 거두고, 복잡한 트리에서의 동시 작업 경로가 최소화되며, 시스템 최적화가 믿을 수 없을 정도로 쉬워집니다. 또한, Unreal Engine 시스템에서는 컴포지트 노드에 "서비스(Services)"라는 특수 노드를 추가할 수 있습니다. 서비스는 하위 트리가 활성화되어 있는 동안 특정 주기마다(예: 2초마다) 실행되어 FSM의 주기적인 "during" 액션을 대체하고 적 추적과 같은 데이터를 지속적으로 업데이트합니다.
메모리 문제와 블랙보드 (Blackboard) 메커니즘
행동 트리가 가진 엄청난 모듈러리티에는 대가가 따릅니다: BT 노드는 설계상 완전히 격리되어 있고 상태가 없습니다(stateless). 즉, "목표로 걷기" 행동 노드는 바로 왼쪽에 있는 "적 찾기" 조건 노드가 무엇을 찾았는지 또는 이전 주기에서 어떤 결정이 내려졌는지 알지 못합니다. FSM과 달리 BT는 과거의 결정이나 실시간 센서 데이터를 자체 내부 구조에 저장하지 않습니다.
이러한 결정적인 소통 공백을 채우고 트리에 일종의 "단기 기억"을 부여하기 위해 Blackboard(블랙보드) 디자인 패턴이 사용됩니다. 블랙보드는 트리의 모든 노드가 실행 중에 읽고 쓸 수 있는 외부의 공통 데이터 풀입니다(프로그래밍 언어에서는 대개 Dictionary, Hash Map 또는 Variant 데이터 구조로 구성됩니다).
작동 방식은 다음과 같습니다: 트리가 "적 보기" 조건 노드에 도달하면, 이 노드는 적의 좌표를 감지하지만 이 정보를 자체적으로 보유하지 않고 블랙보드에 TargetPosition = 형태로 직접 기록합니다. 트리 흐름이 다음 단계인 "거기로 이동" 행동 노드에 도달하면, 행동 노드가 블랙보드에 연결되어 TargetPosition 데이터를 읽고 경로를 계획합니다.
블랙보드 아키텍처는 행동 트리의 순수한 모듈성과 노드 격리성을 위협하지 않으면서도 노드와 분기 간에 믿을 수 없을 정도로 강력하고 유연하며 빠른 데이터 다리를 구축합니다.
비교 분석: FSM과 행동 트리의 충돌
바닥부터 인공지능 시스템의 기초를 다지려는 아키텍처 설계자들에게 유한 상태 기계(FSM)와 행동 트리(BT) 사이의 선택은 단순한 구문이나 엔진의 선호도를 넘어, 프로젝트의 전체 수명 주기에 깊은 영향을 미칠 핵심적인 아키텍처 결정입니다. 게임 개발자 컨퍼런스(GDC) 발표 자료, 산업계 사례 연구, 그리고 최근 몇 년간 발표된 학술적 로보틱스 시뮬레이션들은 의사결정, 모듈러리티, 반응성, 가독성, 확장성 측면에서 이 두 시스템의 구조적 성능을 포괄적으로 비교하고 있습니다.
1. 의사결정(Decision-Making) 대 상태 제어(State Control)
소프트웨어 업계에서 가장 강력한 합의는 BT가 "의사결정" 프로세스에, FSM은 "상태 제어" 프로세스에 특화되어 있다는 점입니다.
행동 트리는 동적이고 끊임없이 변화하는 환경 조건에 반응하며, 다수의 논리적 분기를 포함하고 우선순위가 요구되는 인지적 결정("에이전트가 지금 무엇을 해야 하는가?")을 내리도록 특별히 최적화되어 있습니다. 반면 FSM은 이미 내려진 결정이 실행되는 방식, 시스템의 일관되고 고립된 물리적 모드 관리, 그리고 순차적 흐름("에이전트가 이 행위를 어떻게, 어떤 단계로 수행해야 하는가?")을 명확한 경계로 제어하는 데 안성맞춤입니다.
다음 표는 이러한 근본적인 철학적 차이를 체계적으로 요약하고 있습니다:
2. 모듈러리티와 결합도(Coupling)의 위기
BT는 업계에서 인정받듯 "결합도가 낮은"(low-dependency) 아키텍처입니다. BT의 리프 노드(예: "목표를 향해 달리기" 액션)는 트리의 어디에 위치하든 완전히 독립적이고 스스로 완결된 캡슐화된 객체입니다. 이 노드를 복사하여 "중기관총 방어 모드"라는 완전히 다른 분기 안으로 드래그해도 소스 코드를 전혀 수정하지 않고 원활하게 작동합니다.
반면 FSM에서 "상태"(state)는 자신 다음에 어떤 구체적인 상태로 전환될 수 있는지, 그리고 이 전환이 어떤 조건에서 이루어지는지 자기 자신 내부나 매니저 내부에 직접 정의해야 합니다. 이러한 "강한 결합"(tight coupling) 접근 방식은 작성된 코드 블록을 프로젝트에서 복사해 다른 인공지능으로 이식하는 것을 거의 불가능하게 만듭니다. FSM에서 이루어지는 모든 사소한 변경이나 새로운 상태의 추가는 해당 상태에 연결되는 모든 진입 및 진출 화살표(transitions)를 하나씩 재보정해야 함을 의미합니다. 로보틱스 제어 연구에 따르면 FSM 기반 시스템에 새로운 결함 허용 행동(예: 배터리가 방전될 때 자율 충전으로 복귀)을 추가하는 것이 BT 시스템에 비해 몇 배나 더 어렵다는 점이 통계적으로 입증되었습니다.
3. 표현력(Expressiveness)과 반응성의 충돌
로보틱스 제어 아키텍처에서 수행된 실험실 비교는 두 아키텍처의 본질적인 철학적 차이를 매우 인상적인 지표로 보여줍니다.
표현력(Expressiveness): 예상과 달리 학술 연구들은 FSM이 BT보다 더 "표현력"이 뛰어나다는 것을 입증했습니다. FSM이 위치한 활성 상태는 과거에 내려진 결정들의 구체적인 물리적 축적물입니다. FSM이 "현재 경보 상태입니다"라는 신호를 보낸다면, 이 정보 안에는 과거에 위협이 감지되었고, 시스템이 이 위협을 유효하다고 판단했으며, 일련의 액션을 시작했다는 사실이 내재되어(inherently) 있습니다. 반면 BT는 완전히 망각적입니다. 매 새로운 "틱"(tick) 주기마다 트리는 마치 세상이 새로 창조된 것처럼 루트 노드부터 탐색을 시작합니다. 과거의 행동이나 모드를 기억하기 위해 블랙보드(Blackboard) 상의 외부 데이터에 전적으로 의존해야 합니다.
반응성: 모듈러리티의 대가로 FSM에서는 반응성이 취약합니다. FSM 설계자가 "로봇이 물건을 운반하는 동안 갑자기 화재 경보가 울리면 다음 상태로 전환하라"와 같은 전환 화살표를 그려놓지 않았다면, 로봇은 손에 든 상자를 놓지 않은 채 결코 도망치지 않을 것입니다. 반면 BT는 FSM보다 월등히 반응성이 뛰어납니다. 매 주기마다 세계를 처음부터 다시 확인하거나 옵저버(Observers)를 사용하기 때문에, 아주 작은 환경 변화만 발생해도 트리가 즉시 가장 우선순위가 높은 분기(예: "긴급 탈출")로 향하고 현재 "Running" 상태인 물건 운반 액션을 즉시 선점(preempt)할 수 있습니다.
4. 구축 비용, 디버깅(Debugging) 및 유지보수
의사결정 시스템에서 유지보수 비용(maintenance)은 개발자들이 가장 많은 시간을 소비하는 영역입니다. FSM은 초기 단계에서 매우 낮은 비용으로, 몇 가지 간단한 열거형(enum)과 switch-case 문을 통해 단 몇 분 만에 바닥부터 구축할 수 있습니다. 그러나 시간이 흘러 시스템이 커지면 이러한 장점은 증발하고 디버깅은 완전한 혼돈으로 변합니다.
반면 행동 트리는 처음부터 무거운 "보일러플레이트"(상용구 코드) 부담을 안고 시작합니다. 루트 메커니즘, 틱 시스템, 블랙보드 연동 등 시스템을 가동하는 것만으로도 상당한 아키텍처 투자가 필요합니다. 그러나 이 대가를 한 번 지불하고 나면, 실시간 시각적 디버깅(visual debugging)이 제공하는 이점은 엄청납니다. Unreal Engine 내장 BT 도구나 Godot용으로 개발된 Beehave 플러그인 같은 시스템에서는 개발자가 게임플레이나 시뮬레이션 실행 중 트리 상의 데이터 흐름(초록색으로 빛나는 상태, 빨간색 상태)을 실시간으로 모니터링할 수 있으며, 어떤 액션 노드가 왜 실패했는지 수초 내에 파악할 수 있습니다. FSM 기반의 "거미줄" 속에서 시각적으로 오류의 원인을 찾는 것은 대개 수 시간이나 걸립니다.
고급 하이브리드 아키텍처 응용 및 목표 지향 시스템
단 하나의 아키텍처 패턴에만 매달리는 것은 자율 시스템 프로젝트에서 빈번한 실패를 유발합니다. 순수한 FSM 접근법은 확장성의 벽에 부딪히는 반면, 아주 사소한 이동 루프나 점프 알고리즘조차 BT를 사용하여 설계하려고 하면 "Observer" 수를 늘려 불필요한 조건 검사와 막대한 CPU 비용을 초래합니다. 따라서 현대 AAA 게임과 산업용 로보틱스 솔루션에서는 이 두 아키텍처가 서로의 약점을 보완하도록 영리하게 통합된 하이브리드(혼합) 설계가 "골든 스탠다드"입니다.
행동 트리와 상태 머신 융합 (Layered AI)
가장 효율적이고 업계에서 인정받는 하이브리드 설계에서는 AI 시스템이 레이어(layers)로 분할됩니다. 캐릭터가 무엇을 해야 하는지에 대한 상위 레벨의 인지적 결정은 구조상 계층적이고 분기에 능숙한 행동 트리가 내리는 반면, 이렇게 선택된 결정을 현장에서 물리적이고 알고리즘적으로 실행하는 역할은 하위의 FSM이나 HFSM에 위임됩니다.
예를 들어, 고도화된 적 AI나 자율 감시 에이전트에서 시스템은 다음과
같이 작동합니다:
1. 결정 레이어 (BT - 전략적 두뇌): 캐릭터 주변의 위협 수호, 자신의 체력 및 탄약을 블랙보드를 통해 읽어들입니다. 선택적 평가 결과에 따라 "전술적 후퇴" 결정이 내려집니다.35
2. 실행 레이어 (FSM - 모터 스킬): "전술적 후퇴" 명령은 캐릭터의 스켈레톤 시스템에 통합된 상태 머신으로 트리거(trigger)를 통해 전달됩니다. FSM은 캐릭터를 현재 "공격 애니메이션" 상태에서 즉시 빼내어 "질주" 상태로, 그곳에서 다시 엄폐물 뒤의 "웅크리기" 애니메이션 상태로 매끄러운 순서에 따라 전환합니다.
이러한 계층적 접근 덕분에 BT는 매 프레임(frame)마다 불필요하게 "캐릭터의 왼쪽 발이 앞인가 오른쪽 발인가?" 같은 실행 세부 사항으로 씨름하지 않으며, FSM은 "적이 어디에 있는가?" 같은 거시적 전략 결정을 묻지 않아도 됩니다.22
로보틱스 분야에서도 유사한 평행성이 나타납니다. 물류 창고에서 일하는 AGV(자율 유도 운반 로봇)의 최상위 모드 변경(인간 수동 제어, 자율 임무 모드, 하드웨어 오류/비상 모드)은 가독성을 보장하기 위해 매크로 HFSM에 의해 조율됩니다.27 그러나 로봇이 "자율 임무 모드"에 진입하면, 목표물로 향하는 경로상의 동적 장애물 회피, 정밀한 객체 조작, 즉각적인 센서 피드백 등의 처리는 BT의 독보적인 계층적 반응성에 맡겨집니다.27 문헌에 따르면 역방향 체이닝(backward-chaining) 플래너를 사용하여 목표로부터 역방향으로 조건을 정렬함으로써 처음부터 자율 행동 트리를 동적으로 생성하는 고도화된 솔루션도 성공적으로 적용되고 있습니다.27
자율 의사결정의 다른 차원: GOAP의 맥락
아키텍처의 복잡성을 온전히 이해하기 위해, 업계에서 FSM과 BT 시스템을 넘어선 "목표 지향 액션 플래닝"(Goal-Oriented Action Planning - GOAP) 개념을 다루는 것도 중요합니다. 1971년 학술적 STRIPS 플래닝 이론에 기반을 두고 F.E.A.R. 게임의 전설적인 적 AI 아키텍트인 제프 오킨(Jeff Orkin)에 의해 대중화된 GOAP는 의사결정 프로세스에 전혀 다른 차원을 부여했습니다.13
GOAP 시스템에서는 액션들이 미리 고정된 트리에 결합되지 않습니다. 시스템에는 단지 "액션"(Actions - 예: 문 열기), "전제조건"(Preconditions - 예: 문 근처에 있기), 그리고 "결과"(Effects - 예: 문이 열림) 목록만 제공됩니다. 시스템은 (주로 A* 탐색 알고리즘을 사용하여) 원하는 "목표" 상태에 도달하기 위해 런타임(runtime)에 이 액션들을 결합하여 가장 이상적인 플랜을 자동으로 생성합니다. F.E.A.R.의 천재성은 배후의 이 거대한 자율 플래닝 엔진이 생성한 플랜을 실행하기 위해 실제로는 단 3개의 상태(GoTo, Animate, Use Smart Object)만 가진 매우 단순하고 미니멀한 FSM을 사용한다는 점입니다.13 현대의 BT 하이브리드와 마찬가지로, 두뇌는 복잡한 알고리즘인 반면 근육은 언제나 견고한 FSM으로 이루어져 있습니다.
차세대 게임 엔진 에코시스템: Unreal Engine "State Trees" (상태 트리) 비전
게임 엔진 기술과 자율 시스템 시뮬레이션 분야의 글로벌 선두 주자인 에픽게임즈(Epic Games)는 Unreal Engine 5의 혁신적인 구조(특히 5.5 업데이트에서 두드러진 형태)와 함께, 행동 트리와 상태 머신 간의 수십 년 된 갈등을 종식시키고자 하는 비전 있는 도구를 업계에 선보였습니다: 바로 "State Trees"(상태 트리)입니다.36
특정 규모를 넘어서면 비대해지기 쉬운 전통적 행동 트리(BT)의 "스테이트리스(stateless)" 본성과, 유연성이 부족하고 스파게티 코드를 유발하기 쉬운 FSM의 엄격한 경계가 State Trees 개념 안에서 영리하게 조합되었습니다.36 에픽게임즈는 State Tree 아키텍처를 통해 구형 BT가 지닌 구조적 취약성을 해소하고, FSM의 선형적 힘을 현대적인 결정 메커니즘으로 무장시켰습니다.
State Tree 아키텍처의 두드러진 특징은 다음과 같습니다:
● 기본 작동 흐름으로서, BT의 지속적인 틱(tick) 발생과 "조건을 끊임없이 검사하는" 프로세서 친화적이지 않은 구조 대신, FSM이 제공하는 최적화된 상태 제어(state flow) 성능을 기반으로 삼습니다.36 ● 상태 간 전환을 정의할 때 FSM의 가장 취약한 점인 "서로 강하게 결합된 복잡한 전환 화살표"를 사용하는 대신, 행동 트리가 사용하는 폴백(Fallback) 노드의 유연성으로부터 혜택을 받습니다. ● 이를 한 걸음 더 나아가 유틸리티(Utility/가중치 채점) 알고리즘을 상태 선택에 직접 통합합니다.38 개발자는 목표를 향한 "전투" 또는 "도망" 액션을 위해 정적이고 깨지기 쉬운 전환 화살표를 그리는 대신, 각 상태에 수학적 가중치(weight) 파라미터와 확률 분포를 정의할 수 있습니다. 캐릭터의 체력이 낮아질수록 "도망" 상태를 계산하는 함수의 유틸리티(utility) 점수가 "전투" 상태의 점수를 앞지르게 됩니다.38 이런 방식으로 트리는 수많은 전환 화살표 없이 마치 결정 트리의 우아함으로 상태에서 상태로 유기적인 전환을 수행합니다.38
이러한 차세대 기술 행보는 자율 의사결정 분야에서 게임의 규칙을 바꿀 일보 전진입니다. 에픽게임즈 엔지니어들이 새로운 하드웨어 및 시스템 구축 과정에서 State Tree 아키텍처에 직접 무게를 싣고 있다는 점은, 순수 클래식 행동 트리가 미래에 서서히 도태되면서 FSM의 성능으로 무장하고 유틸리티 함수로 풍성해진 하이브리드 "상태 트리"로 자리를 넘겨줄 것이라는 명확한 투영을 보여줍니다.36
결론
자율 캐릭터, 로봇 팔, 무인 차량, 그리고 비디오 게임 내 고도화된 AI 에이전트의 의사결정 백본을 설계할 때 "어떤 아키텍처가 더 우수한가?"라는 질문에 대한 절대적이고 단 하나의 이론적 정답은 존재하지 않습니다. 컴퓨터 과학과 소프트웨어 공학에서 취해지는 모든 아키텍처적 결정은 심도 있는 트레이드오프(trade-off) 계산을 동반합니다.
유한 상태 머신(FSM)은 결정론적 상태 전환에서 제공하는 고속 성능, 개발자 관점에서의 논리적 이해 용이성, 그리고 명확한 하드웨어적 경계로 이루어진 본질 덕분에 특히 저수준 게임 컨트롤, 격투 게임, 아케이드 메커니즘, 그리고 복잡한 애니메이션 시스템에서 대체 불가능한 빌딩 블록으로 남을 것입니다. 하지만 표현되는 변수의 수가 늘어나고 환경 조건이 순간적으로 변화하는 인지적 시나리오에서, FSM이 유발하는 "상태 폭발(State Explosion)"은 프로젝트를 순식간에 유지보수 불가능한 스파게티 코드로 내몰 위험한 구조적 위기로 돌변합니다.
반면 행동 트리(Behavior Trees)는 유연성, 극도의 모듈러리티, 컴포넌트 기반 재사용성, 그리고 높은 반응성 패러다임을 업계에 안겨주며 게임 AI와 로보틱스 자율성에 진정한 의미의 도약을 선사했습니다. 시간을 아우르는 액션을 비동기적으로 실행할 수 있는 "Running" 개념의 존재와, 코드를 다시는 건드릴 필요 없이 다른 에이전트에 붙일 수 있는 독립적인 레고 조각처럼 형상화하는 능력은 BT를 거대한 오픈 월드 시뮬레이션의 논쟁의 여지 없는 두뇌로 만들었습니다. 그러나 이 유연성의 대가인 스테이트리스(statelessness)는 시스템 설계자로 하여금 블랙보드와 같은 외부 메모리 다리를 구축하게 만들며, 성능 최적화를 보장하기 위해 무거운 이벤트 구동(event-driven) 디자인을 구현하도록 강제합니다.
최종 분석에서, 성공적인 현대 자율 시스템 설계는 아키텍트가 프로젝트를 어떤 추상화(abstraction) 수준에서 관리하기로 선택하는가에 달려 있습니다. 실무 산업 현장은 부정할 수 없는 진실을 증명하고 있습니다: 자율 시스템의 목표가 정해지고 어떤 액션을 선택할지에 대한 반응적 결정은 행동 트리로 처리하며, 선택된 이 액션의 물리적 조율, 애니메이션 단계, 모드 전환은 FSM으로 관리하는 계층적 하이브리드 아키텍처야말로 오늘날 소프트웨어가 도달한 가장 우아하고 정교한 지점을 대변합니다. 미래의 의사결정 메커니즘은 경계가 더욱 모호해지고 아키텍처들이 FSM과 BT를 하나의 몸체로 융합하는(Unreal Engine State Trees 사례에서 보듯이) 차세대 시스템 진화를 계속해서 맞이하게 될 것입니다.
*정보 : 이미지는 Google Gemini에 의해 생성되었습니다.