현대 게임 AI의 기본 문법이 여전히 「비헤이비어 트리에 노드를 걸고, 블랙보드에 불리언을 쓰며, `Update()` 안의 if 연쇄로 NPC의 고수준 의도를 분위기로 붙여 넣는 것」이라면, Jose Antonio Escribano(GitHub: urosidoki)가 2026년 9월 말에 공개한 **htn_planner**는 거의 다른 계보를 공중의 앞에서 엔지니어링 지면으로 되박는 행위에 가깝다. 계층 태스크 네트워크(Hierarchical Task Network, HTN)는 런타임에 해석되는 스크립트 방언일 필요가 없다. **도메인 DSL → AST → IR → 생성된 C**라는 컴파일 파이프라인이 될 수 있다——런타임은 생성된 플래너를 직접 실행하며, 플레이 중에 도메인 소스를 파싱하지 않는다.
이 문장은 컴파일러 슬로건처럼 들릴 수 있다. 진짜 무게는 저자 자신이 공개 설명에서 못 박은 경계에 있다. 그것은 Guerrilla가 《Horizon Zero Dawn》《Horizon Forbidden West》에서 쓴 HTN 플래너의 설계와 양산 경험에서 영감을 받은 **독립 구현**이며, Guerrilla의 플래너 그 자체도, 그 소스 코드의 공개도 **아니다**. 계보는 존중할 수 있다. 저작권과 혈통은 갈라져야 한다.
이 글을 관통하는 이미지는 「백트래킹」이라는 두 글자 자체다. AI 논문의 추상적 탐색이 아니라, 제작 현장에서 디버거가 펼쳐 보일 결정 트리——전제가 실패했을 때 어떻게 물러설지, 메서드 분기가 어떻게 바인딩을 다시 잡을지, 지연 분해가 갱신된 월드 스테이트를 상대로 어떻게 다시 펼쳐질지——그리고 그 모두가 다음 프레임의 임시 불리언이 아니라 버전 있는 C ABI에 착지한다는 것.
一. 기본 논리: 고수준 결정은 비헤이비어 트리이며, 블랙보드 스크립트이며, 런타임 인터프리터다
업계 기본 논리는 깔끔하다. 그래서 게으르기도 하다.
NPC가 「먼저 순찰하고, 경계하고, 목표를 발견한 뒤 지원을 부른다」처럼 초 단위를 넘나드는 의도가 필요해지는 순간, 팀은 익숙한 메뉴를 연다. 비헤이비어 트리를 걸고, 블랙보드에 `enemyVisible` / `lowHealth`를 넣고, 데코레이터와 셀렉터로 우선순위를 트리 UI로 쓰며, 조금 더 「똑똑해」 보이게 하려면 GOAP나 자작 상태 기계를 끼워 넣는다. 플레이어와 제작자도 같은 어휘로 NPC를 읽게 된다——「트리가 정리됐다」, 「보드가 깨끗하다」, 「이 프레임은 생각하는 것처럼 보인다」. 그 암묵이 「고수준 결정 = 런타임에 그래프를 해석한다」를 용서되는 업계 문법으로 만든다.
문제는 비헤이비어 트리 자체가 아니다. 트리는 실행 가능한 반응을 시각화할 수 있는 제어 흐름으로 짜는 데 강하다. 진짜로 버거운 지점은, 결정이 **월드 스테이트 술어**의 조합 탐색을 해야 하고, 실패한 전제에서 체계적으로 물러서야 하며, 「지금 정직하게 쓸 수 있는 국소 계획」과 「나중에야 펼쳐야 할 후속 태스크」를 갈라야 할 때——그리고 그것이 바로 HTN 계보가 오래 맡겠다고 자처해 온 일이다.
Guerrilla의 Decima 엔진은 그 계보를 AAA 공개 연단까지 밀어 올렸다. 2024년 11월 25일, Principal AI Programmer Tim Johan Verweij는 Goldsmiths / AI and Games Conference에서 《HTN Planning in Decima》를 발표하며 내부 구현을 단단히 말했다. 전제 조건에 대한 Prolog식 백트래킹, 그 흐름의 시각화, 그것이 **생성된 C++**에 어떻게 구현되는지, 그리고 게임 안에서 HTN 분해를 어떻게 디버그하는지에 닿는다. 바꿔 말하면 AAA 현장의 HTN은 「스크립트 인터프리터를 한 층 더」라는 낭만이 아니라, 「생성 코드 + 디버그 가능한 분해」라는 제작 제도였다.
htn_planner는 같은 계보의 공개 측에 선다. 그것이 거절하는 것은 비헤이비어 트리가 아니라, 더 은밀한 기본값——NPC의 고수준 의도는 런타임 파싱과 블랙보드 분위기로 영원히 유지할 수 있고, 컴파일도 핫 리로드도 ABI 버전 검사도 필요 없다는 믿음이다.
二. 스크립트를 부수다: 도메인을 「해석」하는 것에서 네이티브 플래너를 「생성」하는 것으로
Jose의 LinkedIn 공개 글(대략 2026-09-27), 이어진 r/gamedev 중계(u/Thhaki, 2026-09-30), GameFromScratch 보도(2026-09-30)는 공학적 주장을 직설적으로 쓴다. 행동 도메인은 Lisp 풍 DSL로 쓰이며 **Domain source → AST → IR → generated C**를 거친다. 생성 후 실행 경로는 인터프리터와 독립하고, 버전 있는 C ABI가 생성 도메인을 호스트 런타임에 연결하며, 선택적으로 C++ 통합 계층을 쓸 수 있다.
저장소 README는 같은 파이프라인을 검증 가능한 단계로 나눈다. 렉서와 소스 범위 → 컴파일러 소유의 AST → 검증과 링킹(선언, include, override, 참조) → IR → `HTNCCodeGenerator`가 C 소스와 정적 메타데이터를 냄 → 클라이언트가 그 C를 게임 또는 도메인 모듈에 넣는다. AST와 IR은 빌드 타임 표현이며, 생성 후 런타임 실행은 그것들을 **유지하지도 의존하지도 않는다**. 이는 슬로건으로서의 「AOT」가 아니라, `HTNTranslator --check`와 코드 생성 명령으로 끝까지 걸을 수 있는 유수선이다.
도메인은 어떤 얼굴인가. S식 풍의 선언적 DSL이지, 범용 Lisp이 아니다. 경비 NPC의 최소 메서드는 이렇게 쓸 수 있다——`guard_on_duty`가 성립할 때 `!move_to`와 `!scan_area` 같은 **원시 태스크**를 계획에 넣는다. 엔진이 그 의미를 부여하고 시작·완료·실패 시점을 정한다. 메서드 분기는 소스 순으로 시도되고, 조건체는 `and` / `or` / `alt` / `not`으로 사실 조회와 공리를 조합하며, `!`는 즉시 계획에 들어가는 원시, 일반 복합 태스크는 즉시 분해, `&`는 **지연 분해**를 낸다——앞선 동작을 먼저 실행하고, 월드 스테이트가 갱신된 뒤에야 후속 메서드를 펼친다.
지연 분해는 이 주장에서 가장 날카롭고, 가장 제작 지향적인 한 칼이다. 완전한 계획이 t0에서 미래 세계에 대해 거짓말할 필요는 없다고 인정한다. 먼저 `!move_to`하고 `&after_arrival`을 도착 뒤에 남겨, 「그때」 여전히 보이거나 이미 잃어버린 목표를 상대로 재분해할 수 있다. 호스트가 스케줄링·취소·재분해 요청을 소유한다. `&` 자체는 타이머가 아니며 조용히 스레드를 열지도 않는다. 계획 시스템은 「지금 정직하게 약속할 수 있는 것」과 「미뤄야 정직한 것」을 가른다——`Update()` 안에서 임시 불리언으로 전 경로를 이미 생각했다고 위장하는 것보다 훨씬 매섭고, 훨씬 깨끗하다.
三. 숫자와 메커니즘이 수사를 누른다: 중첩 백트래킹, C ABI, 핫 리로드, 209 테스트와 여덟 SDK 변형
메커니즘 목록이 없으면 컴파일 서사는 공허한 말로 미끄러진다. 공개 자료가 주는 것은 저장소와 대조할 수 있는 못이다.
**중첩 백트래킹.** 메서드와 공리를 가로지르는 계층 백트래킹은 중첩 호출과 대안 바인딩을 덮는다. `alt`는 대안을 유지하고, `or`는 첫 성공 뒤 남은 경로를 버린다——문안 차이가 아니라, 실패 때 물러나 바인딩을 다시 잡을 수 있는가라는 제도 차이다. Decima 강연은 Prolog식 전제 백트래킹을 강조하고, htn_planner는 같은 부류의 문제를 생성 실행 경로 위의 명시적 정책으로 쓰며, 번역 옵션으로 백트래킹 용량과 런타임 모드 선택을 설정할 수 있다.
**버전 있는 C ABI.** 생성 도메인은 C ABI로 호스트에 걸리고, 동적 로드되는 도메인 모듈은 호환성 검사를 동반한다. 업그레이드는 종종 도메인 재생성과 호스트·런타임 브리지의 **동시** 재빌드를 요구한다——README는 공개 API·도메인 언어·생성 코드 ABI가 여전히 진화 중이라고 반복 경고한다. 귀찮게 들리지만, 그것은 정직함이다. 플래너가 「생성 코드」 차선에 들어선 순간 ABI는 셰이더 변형 계약이지, 영원히 안정하다고 위장할 수 있는 스크립트 문자열이 아니다.
**시각화 디버거.** instrumentation이 켜진 빌드는 계획 논리를 바꾸지 않고 생성 실행을 캡처할 수 있다——메서드, 분기, 조건, 공리, 태스크, 결과, 소스 범위, 스코프 바인딩. 데이터 모델은 ImGui와 독립하며, 엔진은 자체 에디터로 캡처 노드를 그릴 수 있다. HTNDemo는 Domain Runner, 생성 이벤트 디버거, 소형 NPC 시뮬레이션의 세 뷰를 제공한다——데모가 읽는 것은 월드 스테이트 데이터지만, 도메인 정의는 이미 네이티브 생성 플래너에 컴파일되어 있다. Verweij의 「게임 안에서 분해를 디버그한다」는 공개 약속에 대한, 거의 오픈소스의 메아리다.
**핫 리로드.** 동적 도메인 모듈의 참고 통합에서 **호스트 애플리케이션**이 컴파일·로드·리로드 편성을 통제한다. 도메인 반복은 셰이더 핫 리로드와 비슷한 제작 고리가 된다——술어와 메서드 대안을 고친다 → 번역·생성 → 호스트가 리로드 → 새 분해 트리를 바로 본다. Jose는 자체 엔진에 SDK를 통합했고, 그곳에서 계획과 도메인 리로드를 시험했다고 명시한다.
**검증 숫자.** 공개 릴리스 지점에서 저자가 제시한 것은 **v2.0.2가 209개 테스트를 통과**했고, 여덟 개의 Windows SDK 변형에서 외부 컨슈머 검증(생성 도메인 DLL이 필요한 런타임 export를 해석할 수 있는지 검사 포함)을 더했다는 점이다. 그 뒤에도 저장소는 나아간다. CHANGELOG는 2.1–2.3이 도메인 언어 튜토리얼, Linux x64(Ubuntu 24.04 / GCC 14 / Clang 18), 음수 리터럴 등을 차례로 보탰음을 보여 주며, 이 글 작성 시점의 메인라인 VERSION은 준비 중인 2.4.0을 가리킨다. 본문은 「209 + 여덟 변형」을 그 공개 발표 지점에 못 박고, 같은 글에서 다시 보고되지 않은 후속 숫자를 새 슬로건으로 발명하지 않는다.
라이선스는 MIT다. 기여자 주석은 분명하다. 생성 플래너·컴파일 파이프라인·공개 릴리스는 Jose Antonio Escribano가 주도·유지한다. 코어·파싱·월드 스테이트·통합 계층에 남은 **2023년 공유 기반**은 Sandra Alvarez(Sandruski)와의 공저——후자의 저장소 `Sandruski/htn-planner`는 해석형 도메인 언어 노선의 관련 전작이며, 계보는 말해도 되지만 저장소를 섞어서는 안 된다.
四. 환류: 인디가 훔쳐야 할 것은 「Horizon 후광」이 아니라 「계획을 컴파일 시스템으로 다루는 것」이다
오픈소스 이야기의 가장 유용한 결말은 또 하나의 AAA 키워드가 아니라, 제작 윤리의 환류다.
인디와 소규모 팀에게 htn_planner가 아픈 지점은 내일 비헤이비어 트리를 버려야 한다는 점이 아니다. 오래 스튜디오 내부 강의에 잠겨 있던 주장을, 클론 가능한 공학 객체로 번역했다는 점이다. **월드 스테이트 술어와 메서드 대안은 일등 시민**이다. 실패는 다음 프레임에 덮어씌워지는 임시 플래그가 아니라, 탐색 가능한 백트래킹이다. 지연 분해는 시간이 전제를 다시 쓴다는 사실을 인정하게 한다. 핫 리로드는 도메인 변경을 셰이더 변경만큼 검증 가능하게 한다. ABI 버전 검사는 「생성물」을 일회성 export가 아니라 계약으로 다루게 한다.
이 SDK를 쓰지 않아도 된다. 같은 윤리에서 더 작은 제도를 뽑아낼 수 있다. 「적이 보인다 / 탄약 부족 / 엄폐에 닿는다」를 여섯 컴포넌트에 흩어진 불리언이 아니라 명시적 술어표로 쓴다. 「접근 / 구조 요청 / 후퇴」를 움직일 수 없는 거대 트리가 아니라 교체 가능한 메서드 분기로 쓴다. 「도착한 뒤에 결정한다」를 계획이 아직 살아 있다고 위장하는 슬립 코루틴이 아니라 명시적 2단 계획으로 만든다. 계획을 컴파일 시스템으로 다룬다는 것은 각사가 IR을 자작하라는 요구가 아니라, `Update()` 분위기로 감사 가능한 결정 구조를 대체하는 일을 그만두라는 요구다.
수렴: 독립과 AI는 「생성 가능한 백트래킹」 안에서 다시 정의된다
이 오픈소스를 2026년 제작 현장으로 되돌리면, 그것이 진짜로 치는 것은 비헤이비어 트리의 평판이 아니라 더 은밀한 AI의 관성——고수준 의도는 인터프리터와 블랙보드 임시 상태로 영원히 유지할 수 있고, NPC가 「왜 그렇게 움직였는지」 디버그는 로그를 난사하는 운에 맡기면 되며, 인디와 AAA 사이에는 번역할 수 없는 블랙박스 경험이 있다는 믿음이다.
Jose가 보여 준 반례는 투박하고, 매우 공학적이다. Lisp 풍 DSL, AST/IR, 생성된 C, 버전 있는 ABI, 중첩 백트래킹, 지연 분해, 시각화 디버그, 호스트가 통제하는 핫 리로드, 공개 릴리스 지점의 테스트와 SDK 컨슈머 행렬——그리고 반복되는 선언, Guerrilla 경험에서 영감을 받았지만 Guerrilla 소스는 아니라고. 투박한 것은 행동을 번역 가능한 도메인으로 쓰게 만들기 때문이다. 비싼 것은 또 한 프레임의 if가 아니라 진짜 시스템 설계를 소비하기 때문이다.
그리하여 「독립」과 「게임 AI」는 여기서 다시 정의될 수 있다. 독립은 영원히 손글씨 비헤이비어 트리와 같지 않다. 자원이 더 빠듯할 때도 「어떤 결정이 분위기로만 유지되는 순간 게임 안의 타자가 죽는가」를 계속 묻는 일과 같아질 수 있다. 게임 AI도 기능 노드 쌓기와 같지 않다. 그 최소 결정 집합을 위해 컴파일하고 디버그하고 핫 리로드할 수 있는 경로를 마련하려는 의지——설령 그 경로가 NPC를 작은 언어처럼 보이게 해도——와 같아질 수 있다.
실행 가능한 안내는 짧지만, 충분히 매섭고 정직하다.
- 먼저 「월드 스테이트 술어」 목록을 쓴다. 어떤 열 가지 사실이 모호해지는 순간 NPC의 고수준 의도는 설명 불가능해지는가. 최적화와 기능 추가 때 그것들은 거부권을 가진다.
- 적어도 한 조의 상호 배타적 의도를, 서로 덮어쓰는 블랙보드 불리언이 아니라 메서드 대안(분기 + 조건 + 태스크 열)으로 쓴다. 실패 때 「어느 층으로 물러섰는지」 말할 수 있어야 한다.
- 「세계가 바뀐 뒤에야 결정해야 하는」 지점을 하나 찾아, 명시적 2단 계획(지연 분해 또는 동등한 능동 재계획)으로 세운다. 슬립 프레임으로 계획을 위장하는 일을 금한다.
- 도메인/스크립트 핫 리로드를 넣는다면 **호스트**가 컴파일과 로드 편성을 소유하게 하고, 의도적 ABI/버전 불일치 훈련을 한 번 한다——깨끗이 실패하지 못하는 핫 리로드는 아직 시스템이 아니다.
- Verweij 《HTN Planning in Decima》와 htn_planner 도메인 언어 가이드를 읽을 때, 대조하는 것은 「생성 + 디버그 가능한 분해」이지 「Horizon 미술 후광」이 아니다.
9월 말의 공개 글과 보도는 이미 감사 기준을 말해 버렸다. 데모에서 똑똑해 보이는가가 아니다. 고수준 결정이 컴파일되고, 백트래킹되며, 갱신된 세계를 상대로 다시 펼쳐질 수 있는가이다. 그 뒤 제작 현장에 남는 것은 더 차가운 한 문장뿐이다——당신의 NPC는 계획하고 있는가, 아니면 다음 임시 프레임을 위해 계획을 연기하고 있는가.
출처와 더 읽을거리
Jose Antonio Escribano, LinkedIn 공개 릴리스 설명(대략 2026-09-27): I’ve released HTN Planner…
u/Thhaki, r/gamedev 중계(2026-09-30): New Open-Source Enemy/NPC AI planner informed by… Guerrilla…
GameFromScratch(2026-09-30): htn_planner – AAA Inspired Game AI Framework
저장소와 README: urosidoki/htn_planner
도메인 언어 가이드(지연 분해 `&` 포함): docs/DOMAIN_LANGUAGE.md
관련 전작(해석형 노선; 혼동하지 말 것): Sandruski/htn-planner
더 읽기: Exploring HTN Planners through Example; The AI of Horizon Zero Dawn