보스 패턴 기획: 행동 트리 시각화 팁
보스의 공격 의도와 전환 조건을 행동 트리로 정리하면 패턴 기획과 구현 검토를 같은 언어로 진행할 수 있다. 읽기 쉬운 트리 구조와 디버깅 관점의 시각화 방법을 살펴본다.

행동 트리가 보스 패턴 기획에 잘 맞는 이유
보스 패턴은 단순히 공격 목록을 나열하는 일이 아니다. 플레이어와의 거리, 현재 체력, 공격 후 경직, 투사체 수, 페이즈 전환처럼 여러 조건이 동시에 얽힌다. 이 관계를 문서의 문장으로만 관리하면 어떤 조건이 우선하는지 실패한 행동 뒤에 무엇을 해야 하는지 빠르게 확인하기 어렵다.
행동 트리(Behavior Tree)는 선택과 순서를 계층 구조로 드러내기 때문에 보스의 의사 결정을 검토하기 좋다. 특히 기획 단계에서는 ‘어떤 공격을 할까’보다 ‘지금 이 공격을 해도 되는가’를 분리해 두는 편이 효과적이다.

먼저 노드의 의미를 팀 안에서 고정한다
행동 트리는 엔진과 도구마다 세부 표현이 다르지만 기획 문서에서 쓰는 기본 의미를 통일하면 대화 비용이 줄어든다.
- Selector: 일반적인 Selector/Fallback에서는 왼쪽 자식부터 실행해 실패하면 다음 자식으로 넘어가고, 성공하면 선택을 끝낸다. 실행 중(
Running)인 자식은 다음 틱에 이어서 처리하는 등 세부 규칙이 구현마다 다를 수 있다. - Sequence: 자식을 순서대로 실행해 하나라도 실패하면 중단하고, 모두 성공해야 전체가 성공한다. 실행 중인 자식이 있으면 보통 해당 자식을 다음 틱에 이어서 처리한다.
- Condition: 거리, 쿨다운, 체력, 시야, 페이즈 등 실행 가능 여부를 확인한다.
- Action: 이동, 애니메이션 재생, 투사체 생성, 무적 부여처럼 실제 행동을 수행한다.
- Decorator: 보통 자식 하나를 감싸 자식의 실행 여부나 결과를 조정한다. 쿨다운·반복·성공/실패 반전 등을 만들 수 있지만, 지원 노드와 중단 규칙은 도구마다 다르다.
예를 들어 BehaviorTree.CPP의 Fallback과 Sequence는 위와 같은 성공·실패 흐름을 따르지만, 비동기·반응형 노드는 Running 상태의 처리와 재평가 시점이 다릅니다. 실제 구현 전에 사용하는 도구의 노드 규칙을 확인하세요. (Fallback 문서, Sequence 문서, Decorator 문서)
중요한 점은 거리 확인과 돌진을 하나의 불투명한 노드로 합치지 않는 것이다. 조건과 행동이 분리되어야 디자이너는 공격 선택 기준을 바꾸고 프로그래머는 실패와 중단을 정확히 처리할 수 있다.
최상위는 페이즈와 안전장치부터 배치한다
트리를 아래쪽의 개별 공격부터 만들면 예외 처리가 위로 새어 올라오기 쉽다. 먼저 전투 불가 상태, 페이즈 전환, 강제 반응, 일반 공격 선택 순으로 큰 우선순위를 세운다. 예를 들어 경직 중인 보스가 새 공격을 시작하지 않도록 하려면 경직 처리 가지가 일반 공격보다 앞에 있어야 한다.
flowchart TD
Root[보스 전투 루트] --> S{Selector}
S --> Dead[사망 처리]
S --> Phase[페이즈 전환 처리]
S --> Stun[경직 또는 강제 반응]
S --> Attack{공격 선택}
Attack --> Charge[근거리 돌진]
Attack --> Volley[원거리 연사]
Attack --> Reposition[거리 재조정]
이 그림은 완성된 구현 트리라기보다 기획 검토용 지도다. 각 가지가 언제 실패하고 다음 가지로 넘어가는지까지 함께 적어야 실제 의사 결정이 된다. 예를 들어 근거리 돌진은 목표가 사거리 밖이면 실패하고 돌진 중 벽에 막혔을 때는 회복 행동으로 전환할지 즉시 실패 처리할지를 정해야 한다.
공격 하나는 ‘진입 조건-실행-종료’로 묶는다
개별 공격 가지는 세 덩어리로 읽혀야 한다. 화면을 확대하지 않아도 공격의 시작과 끝을 파악할 수 있는 구조가 좋다.
진입 조건
조건은 가능한 한 측정 가능한 값으로 쓴다. 플레이어가 가까움 대신 거리 4m 이하, 최근 6초 동안 돌진하지 않음처럼 기준을 명시한다. 다만 수치를 행동 트리 노드 이름에 전부 넣기보다 노드는 의도를 나타내고 값은 별도 설정 패널이나 데이터 표에서 관리하는 편이 변경에 강하다.
실행 단계
실행 단계에는 준비 동작, 판정 발생, 후딜을 분리한다. 공격 애니메이션 하나로 뭉치면 플레이어가 회피할 수 있는 시점과 공격 취소 가능 시점을 검토하기 어렵다.
flowchart TD
Seq["Sequence (->): 돌진 공격"]
Seq --> C1["1. Condition: 목표 거리 2m ~ 8m"]
Seq --> D1["2. Decorator: 쿨다운 6초"]
Seq --> A1["3. Action: 조준 0.45초"]
Seq --> A2["4. Action: 돌진 시작"]
Seq --> A3["5. Action: 충돌 판정 / 최대 거리 이동"]
Seq --> A4["6. Action: 후딜 0.7초"]
위 구조에서 충돌 판정 또는 최대 거리 도달은 명확한 종료 조건이다. 이동 시간이 프레임률이나 경로 탐색 결과에 따라 길어져도 공격이 끝나지 않는 문제를 줄일 수 있다.
종료와 복구
행동이 성공했을 때뿐 아니라 실패하거나 중단됐을 때의 복구 경로를 표시한다. 대표적인 중단 원인은 피격 경직, 페이즈 전환, 목표 사망, 지형 충돌, 연출 강제 재생이다. 중단 뒤에 애니메이션 상태와 이동 속도, 무적 판정, 예약된 투사체를 어느 상태로 되돌릴지 명시해야 한다.

색과 배치는 정보의 종류에만 사용한다
노드마다 다른 색을 쓰면 보기 좋을 수는 있어도 빠르게 읽기 어렵다. 색은 적은 범주에만 배정한다. 예를 들어 조건은 파랑, 행동은 초록, 강제 중단과 오류 복구는 주황처럼 구분한다. 페이즈별 공격을 구별해야 한다면 색보다 그룹 이름이나 접힌 하위 트리를 우선 사용한다.
배치도 일관성이 중요하다. 자식 노드를 항상 왼쪽에서 오른쪽 또는 위에서 아래로 같은 방향으로 읽게 하고 우선순위가 높은 가지를 먼저 놓는다. 선이 길어지거나 교차한다면 공용 조건을 상위로 올리거나 하위 트리로 분리할 신호다.
다음 항목은 노드 이름 또는 인접한 메모에서 바로 확인할 수 있게 두면 좋다.
- 선택 조건과 우선순위
- 쿨다운과 반복 제한
- 공격의 시작·판정·종료 시점
- 성공, 실패, 중단 시 다음 상태
- 페이즈별 활성 여부
런타임 디버그 화면에는 ‘현재 경로’를 보여 준다
정적인 트리는 설계 검토에 유용하지만 실제 문제는 실행 중에 발견되는 경우가 많다. 런타임 디버그 화면에서는 현재 실행 중인 노드만 밝게 표시하고 최근에 실패한 조건과 남은 쿨다운을 짧게 보여 주는 방식이 실용적이다.
예를 들어 보스가 원거리 연사를 반복한다면 원인은 대개 세 가지다. 근거리 공격의 거리 조건이 계속 실패했거나 원거리 공격의 쿨다운이 적용되지 않았거나 공격 성공 뒤 선택 노드가 즉시 다시 평가됐을 수 있다. 최근 평가 결과가 보이면 애니메이션이나 투사체 코드부터 추측하며 살필 필요가 줄어든다.
로그도 모든 틱을 기록하기보다 상태 전환만 남기는 편이 좋다. 페이즈 2 진입, 돌진 선택, 돌진 중단: 벽 충돌, 거리 재조정 선택 정도면 전투 한 번을 재현하며 흐름을 따라갈 수 있다.
기획 검토 체크리스트
새 보스 패턴을 추가하기 전에 다음 질문에 답해 보자.
- 이 공격은 어떤 플레이 상황을 겨냥하는가?
- 실행 조건이 다른 공격과 충돌할 때 우선순위는 무엇인가?
- 플레이어가 공격을 인지하고 대응할 시간은 어디에 있는가?
- 공격이 실패하거나 중단되면 보스는 어느 상태로 돌아가는가?
- 같은 패턴이 연속해서 선택되지 않도록 제한할 필요가 있는가?
- 디버그 화면에서 이 공격이 선택된 이유를 확인할 수 있는가?
행동 트리는 복잡한 보스 AI를 자동으로 단순하게 만들지는 않는다. 대신 우선순위, 조건, 실패 경로를 눈에 보이게 만들어 기획의 빈틈을 일찍 드러낸다. 트리의 목표는 노드를 많이 만드는 것이 아니라 전투 중 보스가 왜 그 행동을 선택했는지 팀 전체가 설명할 수 있게 만드는 데 있다.



