Behavior Tree 작업을 하며 느낀 점..

최근에 회사에서 AI 작업을 하는데 비헤이비어 트리(Behavior Tree)를 작성해보며 느낀 점을 간략히 적어봅니다. 장점이야 익히 알려져 있다시피 기존에 주로 쓰이던 FSM/HFSM과 달리 중복 코드가 없어지고 더 깨끗하게 모듈화가 된다는 점이구요. 여기서는 단점을 좀 적어볼게요.

비헤이비어 트리(이하 BT)는 기법 이름이 나타내듯 AI가 하나의 트리로 구성이 되는데, 이게 코드/스크립트로 수정하기에는 직관성이 아주 떨어집니다. 기존의 FSM/HFSM은 기본적으로 스크립트를 읽으면 AI의 동작이 그대로 읽혀서 머릿속으로 시뮬레이션이 편하게 되는데, BT는 스크립트로 트리를 구성하므로 사람이 읽기가 나빠요. 동작 하나를 수정하려 해도 트리를 수정하려면 코드를 수정하는것과 감각이 아주 달라서 프로그래머 입장에서 편하게 작업할 수 있는 환경이 아닙니다.

이걸 편하게 하려면 결국 시각적인 편집 도구를 따로 제공하는 수 밖에 없어요. 근데 쓸만한 시각적인 편집도구를 지원하는게 쉬운 일은 아니잖아요? 참고 삼아 써보니 UnrealEngine4의 경우에는 블루프린트 기반의 BT 편집도구를 제공하는데, 이것도 BT의 특성을 고스란히 반영하는 물건은 아니고, 블루프린트를 BT에 끼워 맞춘듯한 도구더군요. 적당히 편집이 되고 어느정도 디버깅이 된다 정도지 BT를 편하게 편집하는 도구라는 인상은 받을 수가 없어요. 물론 BT를 손으로 직접 편집하는 것에 비하면 훨씬 편한 도구임은 분명하죠. 어찌됐든 BT는 편집도구가 가장 큰 문제가 되더군요.

앞서 이야기한 편집 문제를 겪으며 개인적으로 얻은 결론인데, BT는 편집도구까지 개발해서 기획팀이 AI를 수정하는 작업 방식일 때 쓰는게 가장 좋을 듯해요. 기획팀이 수정하지 않더라도 AI 개발이 많아서 시각적인 개발 및 디버깅 도구를 지원할 필요가 있을때 채용하면 효과가 좋을 것 같습니다. AI 개발을 많이 할 게 아니면 그냥 FSM/HFSM으로 개발하는게 개발 효율면에서 나을 것 같습니다. 중복 코드가 좀 나오더라도 편집의 어려움을 감안하면 약간 정도는 감수할 만 하다고 생각이 드는데, AI 개발이 많지 않아서 편집도구까지는 개발할 생각이 없다면 그냥 FSM/HFSM을 쓰는게 나아요.