개인적으로 UE(Unreal Engine)용 AI 에이전트 통합 플랫폼 플러그인을 최근 개발하고 있습니다.

Claude Code나 Codex와 같은 AI 에이전트가 UE의 Editor(에디터)와 Runtime(런타임)을 「조작·관측·실행·검증」할 수 있는 공통 기반을 제공하는 것입니다.

그러던 중, Okazu님(@pafuhana1213)이 UE5.8에서 늘어난 플러그인들을 정성스럽게 정리하신 이 기사를 보게 되었습니다.

AI부터 Animation(애니메이션), Media(미디어), GDK까지 모든 카테고리를 망라하고 있어, 우선 이 글을 읽으면 UE5.8의 전체상을 한눈에 파악할 수 있습니다.

저도 이 기사를 통해 UE5.8의 AI 대응 현황을 알게 되었습니다.

그중에서도 눈길을 끈 것이 AI Toolsets 카테고리입니다.

내가 만들고 있는 영역이 공식적으로 제공되는 것인가… 라는 생각이 들어, 적어도 영역을 구분할 수 있을지 AI용 플러그인에 집중하여 조사해 보기로 했습니다.

Okazu님의 기사가 106개 전부를 조망하는 「정리(Inventory)」라면, 본 기사는 AI 연동 관련 메커니즘을 심층적으로 파고드는 방향으로 정리했습니다.

아키텍처(Architecture)의 전체상과 각 플러그인의 역할·구현 상황·주의점이 중심입니다.

AI 이외를 포함한 모든 플러그인의 증감을 알고 싶은 분은 먼저 Okazu님의 기사를 확인해 주시기 바랍니다.

조사 환경에 대하여: UE5.8은 아직 정식 출시 전이며, 정식 출시는 6월 중순 예정입니다.

본 기사는 프리뷰 출시 전의 GitHub 리포지토리와 공개된 Preview(프리뷰) 버전 양쪽 모두에서 조사했습니다.

소개하는 플러그인은 모두 Experimental(실험적) 상태이므로, API는 향후 크게 바뀔 가능성이 높다는 전제하에 읽어 주시기 바랍니다.

상태

기사가 조금 길어졌으므로, 요점만 알고 싶은 분은 바로 아래의 「할 수 있는 것 / 할 수 없는 것」과 마지막의 「마치며」를 참조해 주세요.

보충: 여담입니다만, 여기서 언급한 「할 수 없는 것」── 특히 Runtime / PIE 제어나 Artifact 관리, 복수 커맨드의 연쇄 실행 부분은 제가 개인 개발 중인 플러그인에서 중점적으로 커버하고 있는 영역과 거의 일치했습니다.

이를 뒤집어 생각하면, 현시점의 공식 플러그인은 「Editor를 다루는」 수준까지이며, Runtime까지 깊이 들어가 동작 결과를 검증하는 것은 이제부터라는 분위기인 것 같습니다.

자작 플러그인의 존재 의의는 당분간 있어 보여서 조금 안심했습니다...

먼저 대국적인 관점에서 보면, UE5.8의 AI 통합은 3층 구조로 되어 있습니다.

포인트는 각 레이어(Layer)가 완전히 분리되어 있다는 점입니다.

후술하겠지만, Toolset을 하나 추가하는 것만으로도 자동으로 MCP를 통해 호출할 수 있게 되는, 아주 기분 좋은 설계로 되어 있습니다.

ToolsetRegistry는 「어떤 툴이 존재하는가」를 일원 관리하는 레지스트리(Registry)입니다.

개인적으로 가장 감탄한 부분은, meta=(AICallable)을 붙이는 것만으로 툴이 공개된다는 점이었습니다.

UCLASS()
class UMyToolset : public UToolsetDefinition
{
...
}

이 한 줄로 다음과 같은 작업이 자동으로 수행됩니다.

스키마 생성에는 UHT (Unreal Header Tool. UCLASS / UFUNCTION을 해석하여 리플렉션 정보를 생성하는 UE의 툴)가 사용됩니다.

AI에게 보여줄 툴의 설명문도 Description=과 같은 전용 메타 지정자가 아니라, UFUNCTION 바로 위의 /** ... */ 툴팁(Tooltip) 주석이 그대로 채택되는 방식이었습니다.

즉,

C++의 타입 정보와 주석이 그대로 AI를 위한 API 사양이 되는 것입니다. UnrealC++에서는 익숙한 메타 지정자와 문서 주석이, 여기서는 「AI를 위한 API 공개」로서 역할을 하게 됩니다.

여기서부터는 예상입니다만, 앞으로는 AI를 위한 정보를 전달하기 위한 메타 지정자가 더 늘어날 것이라고 생각합니다.

AICallable은 「AI에게 공개할 것인가」를 결정하는 플래그이지만, 예를 들어 「이 인자가 가질 수 있는 값의 예시」, 「부작용(Side effect)의 유무」, 「파괴적인 조작인지 여부(실행 전 확인을 거치게 함)」와 같은 힌트를 메타 지정자로 덧붙일 수 있게 된다면, AI 측에서 더욱 안전하고 정확하게 툴을 사용할 수 있게 될 것입니다.

리플렉션 정보를 그대로 AI의 컨텍스트(Context)에 흘려보내는 이 메커니즘과는 궁합이 좋기 때문에, UnrealC++의 지정자가 「인간용」뿐만 아니라 「AI용」으로도 확장되어 가는 미래는 충분히 가능성이 있다고 느꼈습니다.

FToolsetRegistry::ExecuteTool("Toolset.ToolName", JsonInput)
→ "."로 Toolset 이름과 Tool 이름으로 분할
→ UFUNCTION을 리플렉션을 통해 호출
...

반환값은 반드시 JSON 문자열 형식입니다.

이 플러그인은 UE 에디터 그 자체를 MCP (Model Context Protocol. Anthropic이 제정한 AI와 외부 툴을 연결하는 표준 프로토콜) 서버로서 외부에 공개합니다.

Claude Code 등의 AI 에이전트에서 직접 접속할 수 있게 됩니다.

툴이 대량으로 늘어나면 이번에는 AI 측의 컨텍스트 창(Context window)을 압박하게 됩니다.

bDeferredToolLoading=true로 설정하면, 처음에는 3개의 메타 툴만 공개하는 지연 로딩(Deferred loading) 모드가 됩니다.

초기 공개 툴(3종류)
├─ list_toolsets ── 어떤 Toolset이 있는지 확인
├─ describe_toolset ── Toolset의 상세 내용 확인
...

모두 한꺼번에 공개하는 것이 아니라, AI가 필요한 것을 스스로 찾아 로드하는 방식입니다.

컨텍스트 효율을 고려한 실용적인 설계로 되어 있었습니다.

UE5.8 시점(Experimental)에서의 각 Toolset 상황입니다.

참고로 Toolset은 이 외에도 Conversation / Niagara / Physics / UMG / StateTree / GameFeatures / LiveCoding 등 다수 존재합니다.

여기서는 제가 내용까지 확인한 주요 항목으로 한정하므로, 전체 리스트는 앞서 언급한 Okazu 씨의 기사를 확인해 주세요.

에디터의 UI를 AI로부터 직접 조작하기 위한 툴 그룹입니다.

스크린샷을 찍고, 위젯 트리(Widget Tree)를 덤프하며, 버튼을 클릭합니다.

사람이 에디터를 조작하는 동작을 한 차례 대신 수행해 줍니다.

AI가 테스트를 실행 → 결과를 받아 판단 → 수정하는 루프를 구성할 수 있다는 점은 좋지만, 이 루프 자체는 AutomationTest를 커맨드 라인에서 헤드리스(Headless) 실행하면 이전부터 구성할 수 있었던 것이며, 이 Toolset은 동일한 작업을 AI를 전제로 다루기 쉽게 만들어 주는 것이라는 위치 선정입니다.

GASToolsets는 실제로는 AbilitySystemInspector / AttributeSet / GameplayCue의 3가지 Toolset 클래스로 나뉘어 있으며, 합계 14개 정도의 툴이 있습니다(위 표는 대표적인 것의 발췌. ExecuteCueOnSelectedActor는 GameplayCue 측).

ListTags / AddTag / RemoveTag / RenameTag / FindReferencersByTag를 사용할 수 있습니다.

태그의 이름 변경이나 참조처 일괄 검색 등, 수동으로 하면 은근히 번거로운 작업을 AI에게 맡길 수 있다는 점은 실용적이라고 생각합니다.

이 부분은 제가 처음에 잘못 읽었던 부분이라 주의 환기를 위해 적어둡니다.

AnimationAssistantToolset과 AIModuleToolset은 C++ 모듈이 거의 비어 있음(UFUNCTION 제로) 상태여서, 헤더만 보면 "스텁(Stub)인가?"라고 성급하게 판단하기 쉽습니다.

하지만 내용은

Python 측에서 구현되어 있었습니다.

ToolsetRegistry는 C++뿐만 아니라 Python으로 작성한 툴도 등록할 수 있는 설계로 되어 있으며, 위 2개는 해당 경로를 통해 기능합니다.

즉, "C++ 헤더가 비어 있음 = 미구현"이 아니라는 점이 UE5.8의 Toolset을 읽을 때의 함정입니다.

DataflowAgent 역시 "구현 중"이기는커녕 내용은 일단 다 갖춰져 있었습니다. 헤더의 행수만으로 판단하지 말고, Python 측도 함께 확인하는 것이 정답입니다.

Toolset 형태는 아니지만, UE5.8에 추가된 SemanticSearch 또한 AI 통합의 맥락에서 흥미로운 기능이기에 소개합니다.

"캐릭터가 달리는 모션", "붉은 기가 도는 바위 마테리얼"과 같은 자연어 쿼리 (Natural Language Query) 로 프로젝트 내의 에셋을 검색할 수 있습니다.

기존의 키워드 검색(파일명 일치)과 달리, 의미적 유사성 (Semantic Similarity) 을 바탕으로 후보를 좁혀준다는 점이 핵심입니다.

① 쿼리 텍스트 (예: "running animation for character")
↓ MLS 백엔드 (Epic의 ML 서비스)로 HTTPS 전송
② 임베딩 벡터 (Embedding Vector) 생성 (차원 수는 모델에 따라 다름. 응답으로부터 동적으로 결정됨)
...

의미 검색 (Semantic Search)과 전체 텍스트 검색 (Full-text Search) 두 종류를 결합한 하이브리드 검색 (Hybrid Search) 방식입니다.

각각 간단히 보충 설명을 덧붙입니다.

임베딩 벡터 (Embedding): 텍스트의 의미를 수치 배열로 표현한 것. 의미가 가까울수록 벡터 간의 거리도 가까워지며, 차원 수는 고정되지 않고 백엔드의 응답에 따라 동적으로 결정됩니다.

FAISS: 대량의 벡터 중에서 가까운 것을 고속으로 찾는 Meta 제작 라이브러리. 근사 최근접 이웃 탐색 (ANN, Approximate Nearest Neighbor)으로 후보를 좁힙니다. UE5.8에서는 PQ (Product Quantization)를 통해 벡터를 압축하여 보유합니다.

BM25: 키워드 일치 빈도와 문서 길이를 고려한 고전적인 전체 텍스트 검색 스코어링 방식.

RRF (Reciprocal Rank Fusion): 여러 개의 랭킹을 "순위 정보만"을 사용하여 통합하는 기법. 스코어의 스케일 차이를 신경 쓰지 않고 합성할 수 있습니다.

의미 검색은 고유 명사의 완전 일치에 취약하므로 그 부분을 BM25로 보완하고, 마지막에 RRF로 하나의 랭킹으로 합치는 구성입니다.

임베딩 생성은 로컬 추론 (Local Inference)이 아니라, Epic의 ML 백엔드 (코드상 주석에는 "MLS backend services"라고 표기되어 있으며, Machine Learning Service의 약자로 보임)로의 HTTPS 요청을 통해 이루어집니다.

구현된 IEmbeddingProvider는 FRemoteEmbeddingProvider 한 종류뿐이며, FHttpModule을 통해 원격으로 전송하는 구조입니다 (NNE 등의 온디바이스 추론 버전은 인터페이스상 "향후 양쪽 모두 대응 가능"이라고 주석만 달려 있을 뿐 미구현 상태입니다).

여기서 중요한 점은, 연결 대상 URL 및 인증 정보가 Engine/Restricted/NotForLicensees/... 경로 아래의 비공개 Config에서 읽혀진다는 점입니다.

이는 Epic 직원용 파일로, 공개 빌드에는 포함되지 않습니다.

즉, 라이선시(Licensee)가 사용하는 일반적인 엔진에서는 URL이 설정되지 않은 채로 실행되어, Remote Provider가 실질적으로 작동하지 않게 됩니다.

SemanticSearch를 활성화하더라도, 현재의 공개 빌드에서는 이 임베딩 생성이 기능하지 않는다는 이해가 정확합니다.

주의: 반대로 말하면, 연결 대상이 설정된 환경 (Epic 사내 등)에서 실행할 경우, 쿼리 텍스트와 에셋의 캡션 정보가 HTTPS를 통해 외부로 전송됩니다 (쿼리는 {"text": "..."} 형태의 POST, 캡션 생성은 task_preset = "UE_ASSET_TAG_AND_CAPTION_V1" 형태의 multipart).

향후 URL이 일반 제공될 때는 사외비 에셋을 포함하는 프로젝트에서의 취급에 주의가 필요합니다.

IEmbeddingProvider::GenerateEmbeddingAsync()는 API로서 호출 가능한 상태입니다.

다만 앞서 언급했듯이, 공개 빌드에는 연결 대상 URL이 포함되어 있지 않기 때문에 호출하더라도 실제로는 작동하지 않습니다.

"API는 존재하지만, 연결 대상은 아직 라이선시에게 개방되지 않은" 상태입니다.

설령 향후 URL이 제공된다 하더라도,

• MLS 이용이 Epic 자사 제품 및 공식 플러그인만을 상정하고 있는 것인지
• 서드파티(3rd Party) 제작 상용 플러그인에서 MLS를 호출하는 것이 EULA / 이용 약관 범위 내에 있는지

와 같은 점들은 여전히 불분명합니다.

SemanticSearch 자체가 아직 Experimental 상태이기도 하므로, 이용 약관 정비는 기능의 안정화보다 나중이 될 가능성이 높다고 생각됩니다.

당분간은 "공개 빌드에서는 사실상 사용할 수 없다"는 전제로 이해해 두시고, MLS에 의존하는 기능을 상용으로 배포하고 싶다면 사전에 Epic에 확인하는 것이 무난할 것입니다.

여기까지는 "UE가 서버가 되는" 이야기였지만, 역방향 연결도 존재합니다.

UE 측이 외부 MCP 서버로 접속하러 가는 클라이언트 기능입니다.

외부 MCP 서버의 툴(Tool) 군을 로컬의 ToolsetRegistry로 가져와서, 다른 Toolset과 동일한 선상에서 다룰 수 있게 됩니다.

인증 방식은 3단계에 대응하고 있습니다.

OAuth 2.0(비밀번호를 전달하지 않고 액세스 권한을 제3자에게 위임하는 메커니즘)까지 제대로 구현되어 있는 점을 보면, 본격적인 외부 서비스 연동을 상정하고 있다는 것이 느껴지네요.

참고로 PKCE(피크시라고 읽는 모양이네요...)는 인가 코드(Authorization Code)를 탈취당하더라도 단독으로는 사용할 수 없게 만들기 위한 추가 방어책인 것 같습니다.

다만 획득한 토큰은 GEditorPerProjectIni에 평문으로 저장되는 구현이며, 암호화나 보안 스토리지(Secure Storage)는 사용되지 않는다는 점에 유의하십시오.

이것은 Toolset / MCP 서버와는 별개의 독립된 플러그인입니다.

CEF(Chromium Embedded Framework) 기반의 내장 브라우저로, dev.epicgames.com/community/assistant/embedded에 호스트된 **Epic Developer Assistant (EDA)**를 에디터(Editor) 패널로 표시합니다.

EDA는 Epic이 독자적으로 운영하는 AI 어시스턴트이며, 백엔드의 LLM이 무엇인지는 소스 코드만으로는 판별할 수 없었습니다.

또한 이 플러그인은 NoRedist / 기본적으로 비활성화된 Experimental 상태이므로, 사용하려면 먼저 수동으로 플러그인을 활성화해야 합니다.

HTTP REST가 아니라 **JavaScript 브리지 (JS Bridge)**를 통해 UE와 EDA가 양방향 통신을 한다는 점이 특징입니다.

EDA 프론트엔드 (브라우저 내부)
↕ window.eda.* (JS 브리지)
UE C++ 측 (AIAssistant 플러그인)
...

기동 시 ToolsetRegistry에 등록된 모든 툴 스키마(Tool Schema)를 EDA로 전송하며, EDA는 "어떤 툴을 호출할 수 있는지"를 파악합니다.

EDA가 툴 호출을 요청하면, C++ 측에서 이를 받아 ToolsetRegistry를 통해 실행하고 결과를 반환합니다.

브라우저 내부의 AI와 UE 내부를 window.eda로 연결하고 있는 셈이네요.

• 접속 대상이 dev.epicgames.com이므로, 오프라인 환경에서는 동작하지 않음
• Epic 계정 로그인이 필요할 가능성이 있음 (인증 흐름은 Web 측에서 처리)
• AIAssistant.json의 main_url을 수정하면 접속 대상 자체를 교체하는 것은 가능하지만, window.eda 호환 JavaScript API를 직접 구현해야 함

교체할 수 있는 통로는 일단 마련되어 있지만, 브리지 호환성까지 구현하는 것은 꽤나 까다롭다는 느낌입니다.

마지막으로 사소하지만 중요한 부분인데, 공식 MCP 서버(Model Context Protocol)의 인증은 Origin 헤더를 통한 DNS Rebinding 방지뿐입니다.

이는 로컬에서 동작하는 서비스를 악의적인 웹 페이지가 마음대로 호출하는 공격인데, UE5.8은 요청의 Origin이 기대하는 도메인인지 체크하여 이를 방어합니다.

역으로 말하면, Bearer Token 인증이나 실행 가능한 기능별 권한 제어는 현시점에서는 존재하지 않습니다.

"신뢰할 수 있는 로컬 개발 환경에서의 이용"이 대전제라는 뜻입니다.

외부 네트워크에 노출되는 운용을 하려면 별도로 철저한 대책을 세워야 합니다.

쓰고 싶은 내용을 쓰다 보니 긴 글이 되어버렸습니다.

서두에 썼듯이 저 자신도 마침 비슷한 영역의 플러그인을 개인 개발하고 있어서, 이번에는 개발 중인 플러그인이 사장되는 것은 아닐까 하며 두근거리는 마음으로 확인했습니다.

결론부터 말씀드리면, 공식 플러그인은 "Editor를 다루는" 수준까지였습니다.

Runtime까지 깊게 파고드는 조작·검증이나 커맨드(Command)의 연쇄 실행 같은 부분은 아직 앞으로의 과제라는 인상이었습니다.

그렇기는 하지만, 독자적인 툴을 AICallable 한 줄로 공개할 수 있고, MCP 서버 → ToolsetRegistry → 각 Toolset으로 이어지는 깔끔한 3층 구조로 그것이 성립되는 것을 보니, 지금까지 각 기업이나 개인이 독자적으로 만들어 왔던 영역이 엔진 표준으로서 내려왔구나... 하는 실감이 났습니다.

Experimental(실험적 기능) 단계가 해제되었을 때는, 개인 이용 범위라면 Toolset의 메커니즘에 맞춰 개인용 라이브러리를 만들면 될지도 모르겠습니다.

이번 조사는 UE5.8의 Plugins/Experimental 이하(ModelContextProtocol / ToolsetRegistry / 각 Toolset / SemanticSearch)를 확인하며 진행했습니다.

이 부근의 공식 플러그인은 아직 일본어 정보가 거의 없기 때문에, 앞으로 다양한 정보가 나오기를 기대하고 있습니다!

이 기사가 UE5.8의 AI 관련 기능을 다루는 분들에게 입문서가 된다면 기쁘겠습니다.