언리얼 EQS(Environment Query System)를 공부하며 이해한 것

AI를 구현하면서 EQS(Environment Query System)를 사용하게 되었다.

처음에는 단순히 "AI 추적 시스템" 정도로 생각했지만, 직접 적용해보면서 생각이 많이 바뀌었다.

이번 글에서는 EQS가 무엇인지, 언제 사용하는 것이 좋은지, 그리고 실제 AI 구현 과정에서 어떻게 활용했는지 정리해보려고 한다.

---

EQS란 무엇인가?

처음 EQS를 접하면 AI가 플레이어를 추적하는 시스템처럼 보인다.

하지만 실제로 사용해보니 EQS의 역할은 조금 달랐다.

EQS는 AI가 행동을 결정하는 시스템이 아니라, 어디로 이동할지 결정하는 시스템에 가깝다.

내가 이해한 AI 구조는 다음과 같다.

• AI Perception : 무엇을 감지했는가
• Behavior Tree : 무엇을 할 것인가
• EQS : 어디로 갈 것인가
• MoveTo : 실제 이동

즉 EQS는 AI의 "두뇌"라기보다는 "위치 선택기"에 가깝다.

---

처음에 했던 오해

처음에는 플레이어를 추적하는 모든 상황에서 EQS를 사용해야 한다고 생각했다.

예를 들어 플레이어를 발견하면 EQS가 플레이어 위치를 계산해서 추적한다고 생각했다.

하지만 구현을 진행하면서 오히려 이런 경우에는 EQS가 필요 없다는 것을 알게 되었다.

플레이어를 이미 보고 있다면 AI는 플레이어 위치를 알고 있다.

따라서 단순히 TargetActor를 대상으로 MoveTo를 실행하면 된다.

마찬가지로 소리를 들은 경우에도 이미 소리가 발생한 위치를 알고 있다.

이 경우 역시 HeardLocation으로 이동하면 되기 때문에 EQS가 필요하지 않다.

---

그럼 EQS는 언제 사용하는가?

EQS가 진짜 빛을 발하는 순간은 목표 위치가 애매할 때다.

대표적인 예가 플레이어를 놓친 상황이다.

플레이어를 추적하던 중 시야에서 사라졌다고 가정해보자.

AI는 마지막으로 플레이어를 본 위치는 알고 있지만 현재 위치는 알 수 없다.

이때 AI는 "어디부터 찾아야 할까?"를 결정해야 한다.

이런 상황에서 EQS를 사용한다.

마지막 목격 위치 주변에 여러 후보 지점을 생성하고, 조건에 따라 가장 적절한 위치를 선택해 수색을 시작한다.

---

내가 이해한 EQS의 핵심

EQS는 크게 3단계로 동작한다.

1. 후보 위치 생성

먼저 여러 개의 후보 위치를 만든다.

내가 사용한 설정은 Simple Grid Generator였다.

플레이어 주변 또는 특정 위치 주변에 격자 형태로 여러 개의 후보 위치를 생성한다.

이 단계에서는 단순히 "갈 수 있는 후보들"을 만드는 과정이라고 이해하면 된다.

📷 Generator 설정 화면

---

2. 후보 평가

생성된 후보 위치들을 다양한 조건으로 평가한다.

내가 사용했던 것은 Trace Test와 Distance Test였다.

Trace Test는 특정 대상과 시야가 연결되는지 확인한다.

Distance Test는 특정 대상과 얼마나 가까운지를 평가한다.

예를 들어 플레이어 주변 위치를 찾는 EQS라면,

• 플레이어에게 너무 멀지 않은 위치
• 플레이어에게 바로 노출되지 않는 위치

같은 조건으로 점수를 계산할 수 있다.

---

3. 최종 위치 선택

모든 테스트가 끝나면 가장 높은 점수를 받은 위치가 선택된다.

Behavior Tree는 이 결과를 받아 MoveTo를 실행한다.

즉 EQS는 직접 이동하지 않는다.

어디로 이동할지 결정하는 것까지만 담당한다.

---

NavMesh가 있는데 EQS가 필요한 이유

처음에는 이런 의문도 들었다.

"어차피 NavMesh가 있는데 EQS가 필요한가?"

하지만 둘의 역할은 다르다.

NavMesh는 이동 가능한 영역을 정의한다.

반면 EQS는 이동 가능한 영역 중에서 어떤 위치를 선택할지를 결정한다.

또한 EQS에 Pathfinding Test를 추가하면 도달할 수 없는 위치를 미리 제거할 수 있다.

그렇지 않으면 EQS가 선택한 위치가 실제로는 이동 불가능해서 MoveTo가 실패할 수도 있다.

---

소리 감지에 EQS를 적용하려고 했던 경험

AI Hearing을 구현하면서 처음에는 소리를 들으면 EQS를 실행하려고 했다.

하지만 생각해보니 이미 소리가 발생한 위치를 알고 있었다.

굳이 EQS를 돌릴 필요가 없었다.

그래서 현재 구조는 다음과 같다.

소리를 들으면 HeardLocation을 저장하고, 해당 위치로 이동한다.

만약 도착했는데 플레이어를 발견하지 못했다면 그때 EQS를 실행해서 주변을 수색하는 방식이 더 자연스럽다고 판단했다.

이 과정에서 EQS는 "조사"보다 "수색"에 더 잘 어울린다는 것을 느꼈다.

---

정리

EQS를 공부하면서 가장 크게 바뀐 생각은 이것이다.

처음에는 EQS를 추적 시스템이라고 생각했다.

하지만 실제로는 수색 시스템에 더 가깝다.

플레이어 위치를 알고 있다면 MoveTo만으로 충분하다.

반대로 목표 위치가 불확실하다면 EQS가 매우 강력한 도구가 된다.

내가 현재 이해한 기준으로 정리하면 다음과 같다.

EQS를 사용하기 좋은 경우

• 플레이어를 놓친 경우
• 순찰 위치 선택
• 수색 위치 선택
• 엄폐물 선택
• 도난 발생 후 탐색
• 도망 위치 선택

EQS를 사용할 필요가 없는 경우

• 플레이어를 보고 있는 경우
• 소리 발생 위치를 알고 있는 경우
• 특정 오브젝트 위치를 알고 있는 경우
• 단순 이동

결국 EQS는

"목표를 알고 있을 때 사용하는 시스템"이 아니라

"목표를 모를 때 가장 적절한 위치를 찾기 위한 시스템"

이라고 이해하게 되었다.