Unreal에서 AI 자동화가 달라지는 지점
Unity에서 MCP를 다룰 때 핵심은 에디터에 접근하는 권한을 작게 나누고, 읽기와 쓰기를 분리하는 것이었다. Unreal에서도 원칙은 같다. 다만 Unreal은 에디터 자체가 더 많은 제작 시스템을 품고 있다. 레벨 배치, 블루프린트 그래프, 머티리얼 그래프, Niagara VFX, Gameplay Ability System까지 많은 작업이 에디터 안에서 시각적으로 이루어진다.
그래서 Unreal에서 AI는 단순히 C++ 코드를 제안하는 도구에 머물지 않는다. 허용된 범위 안에서는 에디터 상태를 읽고, 액터를 배치하고, 블루프린트 노드를 만들고, 컴파일하고, PIE를 실행한 뒤 로그를 확인하는 자동화 파트너가 될 수 있다. PIE는 Play In Editor의 약자로, 에디터 안에서 게임을 실행해 보는 기능이다.
중요한 점은 AI가 Unreal을 직접 이해해서 마음대로 조작하는 것이 아니라는 점이다. AI는 MCP 서버가 공개한 도구 목록을 보고, 그 도구를 호출한다. 실제 에디터 작업은 Unreal 안에 설치된 브리지 플러그인이 수행한다. 이 구조를 이해해야 자동화의 가능성과 위험을 함께 판단할 수 있다.
AI 생성 이미지
UE-MCP의 기본 구조
UE-MCP 계열 구현은 보통 세 부분으로 나뉜다. 첫째, 사용자가 대화하는 AI 클라이언트가 있다. Claude, Cursor, VS Code 계열 도구처럼 자연어 요청을 입력하는 곳이다. 둘째, 로컬 컴퓨터에서 실행되는 TypeScript 또는 Node.js 기반 MCP 서버가 있다. 셋째, Unreal Editor 안에서 동작하는 C++ 브리지 플러그인이 있다.
흐름은 다음과 같다.
사용자가 AI 클라이언트에 요청한다.
AI 클라이언트는 MCP 서버가 제공하는 도구 목록을 확인한다.
MCP 서버는 요청을 Unreal 브리지 플러그인에 전달한다.
Unreal 플러그인은 에디터 API를 사용해 액터 배치, 블루프린트 수정, 로그 조회 같은 작업을 수행한다.
결과가 다시 MCP 서버와 AI 클라이언트로 돌아온다.
UE-MCP 문서에서는 TypeScript MCP 서버와 Unreal 내부 C++ 플러그인이 WebSocket JSON-RPC로 통신하는 구조를 설명한다.1 어렵게 들리지만 개념은 단순하다. WebSocket은 프로그램끼리 계속 연결된 통신 통로이고, JSON-RPC는 어떤 기능을 어떤 인자로 실행할지 JSON 형식으로 주고받는 호출 규칙이다. 비유하면 AI 클라이언트는 요청자, MCP 서버는 통역자, Unreal 플러그인은 실제 작업자다.
이 분리는 실무에서 중요하다. TypeScript 서버는 AI 클라이언트와 MCP 규약에 맞춰 도구를 노출하기 좋다. C++ 플러그인은 Unreal Editor 내부 기능에 접근하기 좋다. 두 역할을 나누면 AI 쪽 연결과 엔진 쪽 실행을 분리해서 관리할 수 있다.
또 하나의 특징은 에디터가 켜져 있지 않아도 일부 정보를 읽을 수 있다는 점이다. 공개 문서에 따르면 프로젝트 설정 INI, C++ 헤더 정보, 에셋 디렉터리 스캔 같은 파일 기반 읽기는 에디터 실행 여부와 별개로 처리될 수 있다.2 즉 AI가 먼저 프로젝트 구조를 파악하고, 에디터 제어가 필요한 단계에서만 브리지를 사용할 수 있다.
AI가 다룰 수 있는 Unreal 작업 범위
Unreal의 자동화 범위는 넓다. 그래서 처음부터 모든 것을 맡기기보다 작업 대상을 나눠 생각해야 한다.
레벨과 액터: 레벨에 액터를 배치하고 위치, 회전, 스케일을 수정한다. 라이트, 볼륨, 트리거, 카메라 같은 기본 요소도 여기에 포함된다.
Blueprint: 그래프를 읽고, 노드를 추가하고, 핀을 연결하고, 변수를 만들고, 컴파일한다. 블루프린트는 Unreal의 시각적 스크립팅 시스템이다.
Material: 머티리얼과 머티리얼 인스턴스를 만들고, 파라미터를 설정한다. 표면의 색, 거칠기, 발광 효과 등을 다룬다.
Niagara VFX: 파티클과 이펙트를 구성한다. 예를 들어 상호작용 지점에 빛나는 입자를 배치하는 작업이 가능하다.
Gameplay Ability System, GAS: 어빌리티, 효과, 속성, 게임플레이 큐를 다룬다. 전투, 버프, 쿨다운처럼 규칙이 복잡한 시스템에 쓰인다.
Editor 제어: 콘솔 명령 실행, PIE 실행, 빌드, 로그 확인, 뷰포트 조작 같은 에디터 작업을 수행한다.
UE-MCP 문서는 레벨, 블루프린트, 머티리얼, VFX, Gameplay, GAS, Editor 등 여러 범주의 도구와 액션을 제공한다고 설명한다.3 하지만 범위가 넓다는 말은 곧 위험도 넓다는 뜻이기도 하다. 블루프린트 노드 하나를 잘못 연결하면 컴파일 오류가 생긴다. 레벨 자동 배치는 씬을 지저분하게 만들 수 있다. GAS 변경은 게임 규칙 전체에 영향을 준다. 따라서 자동화 요청은 작고 검증 가능한 단위로 나누어야 한다.
요청-검증 루프 예시: 상호작용 패드 만들기
간단한 예시로 레벨에 상호작용 패드를 만드는 작업을 보자. 목표는 플레이어가 특정 패드에 들어가면 조명이 켜지고 로그가 남는 기능이다. 이 정도 작업은 레벨 배치, 블루프린트 노드 생성, 컴파일, PIE 실행, 로그 확인을 한 번의 루프로 묶어 연습하기 좋다.
요청은 다음처럼 작성할 수 있다.
목표: 현재 테스트 레벨에 BP_InteractPad를 만들고 배치해 주세요.
현재 상태:
- Unreal 프로젝트는 Third Person 템플릿 기반입니다.
- 테스트 레벨 이름은 L_TestArena입니다.
- 플레이어가 패드 범위에 들어오면 PointLight가 켜지고 Output Log에 InteractPad Triggered를 남기면 됩니다.
제약:
- 새 C++ 코드는 만들지 말고 Blueprint만 사용하세요.
- 기존 레벨 오브젝트는 삭제하지 마세요.
- 새 에셋은 /Game/Prototype/Interaction 아래에 생성하세요.
- 변경 전 프로젝트 상태와 생성할 에셋 목록을 먼저 보고하세요.
검증 기준:
- BP_InteractPad가 컴파일되어야 합니다.
- L_TestArena에 액터 1개가 배치되어야 합니다.
- PIE 실행 후 Overlap 관련 오류가 없어야 합니다.
- 로그에서 InteractPad Triggered 문자열을 확인해야 합니다.좋은 요청은 결과만 말하지 않는다. 현재 상태, 금지할 행동, 생성 위치, 검증 기준을 함께 준다. 이렇게 해야 AI가 불필요하게 C++ 클래스를 만들거나, 기존 레벨을 정리한다는 이유로 오브젝트를 삭제하는 일을 줄일 수 있다.
이 요청을 실제 자동화 루프로 풀면 다음 순서가 된다.
읽기: 프로젝트 상태, 현재 레벨, 기존 에셋 경로, 플러그인 활성 여부를 확인한다.
계획 보고: 생성할 블루프린트, 컴포넌트, 배치 위치, 검증 방법을 사용자에게 보여준다.
액터 배치:
/Game/Prototype/Interaction/BP_InteractPad를 만들고 레벨에 배치한다.Blueprint 구성: Box Collision, Static Mesh, PointLight를 추가한다. BeginOverlap 이벤트에서 PointLight를 켜고 로그를 출력하는 노드를 연결한다.
컴파일: 블루프린트를 컴파일하고 오류나 경고를 확인한다.
PIE 실행: 에디터 안에서 테스트를 실행한다.
로그 확인: Output Log에서 컴파일 오류, 런타임 경고, 지정한 문자열을 확인한다.
결과 보고: 생성된 에셋, 수정된 레벨, 남은 문제, 사람이 확인해야 할 항목을 정리한다.
이 루프의 핵심은 실행보다 검증이다. AI가 액터를 배치했다는 말만으로는 충분하지 않다. 블루프린트가 컴파일되었는지, PIE에서 실제로 작동했는지, 로그에 오류가 없는지를 확인해야 한다. UE-MCP 문서에는 여러 도구를 YAML 워크플로로 연결하고 재시도, 롤백, 단계 참조를 사용하는 Flow Engine 개념도 소개되어 있다.4 이런 기능은 반복 가능한 테스트 루프를 만들 때 도움이 되지만, 처음에는 사람이 각 단계를 확인하는 방식이 더 안전하다.
블루프린트와 머티리얼은 그래프라는 점을 기억하기
Unreal의 블루프린트와 머티리얼은 모두 그래프 기반이다. 그래프는 노드와 연결선으로 이루어진 구조다. AI가 텍스트로 요청을 받아 그래프를 수정할 수는 있지만, 결과가 읽기 쉬운지는 별개의 문제다.
예를 들어 블루프린트에서 AI가 BeginOverlap, Cast, Branch, Set Visibility, Print String 노드를 만들 수 있다. 하지만 노드 이름이 불명확하거나, 이벤트 그래프가 한 화면에 과하게 퍼져 있거나, 변수명이 임시 이름이면 유지보수가 어려워진다. 따라서 요청에 정리 기준도 포함하는 것이 좋다.
Blueprint 그래프를 만들 때 다음 기준을 지켜 주세요.
- 변수명은 bIsActivated, TriggerLight처럼 역할이 보이게 작성하세요.
- Overlap 처리 노드는 Comment Box로 묶고 제목을 Player Enter Trigger로 지정하세요.
- 사용하지 않는 임시 노드나 테스트 문자열은 남기지 마세요.
- 컴파일 후 경고가 있으면 수정하지 말고 먼저 보고하세요.머티리얼도 마찬가지다. AI에게 발광 패드 머티리얼을 요청할 수 있지만, 색상과 밝기 값을 하드코딩하면 나중에 조정하기 어렵다. EmissiveColor, GlowIntensity 같은 파라미터를 만들고 머티리얼 인스턴스에서 조정할 수 있게 하는 편이 실무에 가깝다.
Niagara VFX는 더 주의해야 한다. 이펙트는 작동 여부뿐 아니라 화면 가독성, 성능, 게임 분위기를 함께 봐야 한다. AI는 입자 수와 색상, 수명 값을 만들 수 있지만, 전투 중 시야를 방해하는지 판단하는 일은 사람이 해야 한다.
GAS 작업은 자동화보다 설계가 먼저다
Gameplay Ability System은 강력하지만 복잡하다. Attribute, Ability, Gameplay Effect, Gameplay Cue, Gameplay Tag가 서로 연결된다. AI에게 어빌리티 하나를 만들게 할 수는 있지만, 태그 규칙과 속성 구조가 정리되어 있지 않으면 프로젝트가 금방 혼란스러워진다.
GAS를 AI와 함께 다룰 때는 먼저 설계 문서를 준다.
GAS 규칙:
- 모든 태그는 Ability.*, Status.*, Cooldown.* 접두사를 사용합니다.
- 피해량은 AttributeSet_Combat의 AttackPower를 기준으로 계산합니다.
- 쿨다운은 GameplayEffect_Cooldown_* 에셋으로 분리합니다.
- 새 Ability는 입력 바인딩을 직접 수정하지 말고 목록만 보고합니다.이런 규칙이 있어야 AI가 새 어빌리티를 만들 때 기존 시스템과 맞출 수 있다. GAS는 기능 하나가 아니라 전투 규칙의 언어다. 자동화 전에 언어를 정리해야 한다.
설치와 실행 전에 확인할 것
Unreal MCP 자동화는 플러그인과 로컬 서버가 함께 움직인다. 그래서 프롬프트보다 환경 점검이 먼저다.
엔진 버전: 사용하는 Unreal Engine 버전과 MCP 브리지 플러그인이 맞는지 확인한다. 에디터 API는 버전에 따라 달라질 수 있다.
플러그인 버전: MCP 서버와 C++ 브리지 플러그인의 버전이 서로 맞아야 한다. 한쪽만 업데이트하면 도구 호출 이름이나 인자 형식이 달라질 수 있다.
네이티브 플러그인 빌드: C++ 브리지 플러그인은 프로젝트에 맞게 빌드가 필요할 수 있다. 컴파일 오류가 있으면 AI 자동화 이전에 플러그인 자체가 로드되지 않는다.
필수 Unreal 플러그인: Niagara, GameplayAbilities, Enhanced Input처럼 작업에 필요한 엔진 플러그인이 활성화되어 있는지 확인한다.
보안 토큰과 포트: WebSocket이나 로컬 서버가 인증 없이 외부에 노출되면 위험하다. 보안 토큰을 설정하고, 가능하면 로컬호스트에서만 접근하게 제한한다.
버전 관리 상태: 자동화 실행 전 Git 상태를 확인한다. 큰 변경 전에는 커밋하거나 별도 브랜치에서 테스트한다.
에셋 저장 위치: AI가 임의 경로에 에셋을 만들지 않도록
/Game/Prototype,/Game/UI,/Game/VFX처럼 허용 경로를 지정한다.
특히 보안 토큰은 선택 사항처럼 보이면 안 된다. MCP 서버는 AI가 에디터 작업을 요청하는 입구다. 이 입구가 열려 있으면 누군가 레벨을 수정하거나 파일을 생성하거나 빌드를 실행할 수 있다. 로컬 개발용 서버라도 외부 네트워크에 노출하지 않는 것이 기본이다.
사람이 맡아야 할 판단
Unreal MCP 자동화는 반복 작업을 줄인다. 레벨에 테스트 액터를 배치하고, 블루프린트 초안을 만들고, 머티리얼 파라미터를 정리하고, PIE 후 로그를 확인하는 작업은 AI가 잘 도울 수 있다.
하지만 다음 판단은 사람이 해야 한다.
블루프린트 구조가 팀의 유지보수 기준에 맞는가
머티리얼과 VFX가 게임의 시각적 방향과 맞는가
GAS 태그와 어빌리티 구조가 장기적으로 확장 가능한가
자동 배치된 액터가 플레이 흐름과 레벨 디자인을 해치지 않는가
성능, 네트워크 복제, 플랫폼 제약을 만족하는가
AI에게 에디터 권한을 줄수록 요청은 더 구체적이어야 한다. 목표, 제약, 검증 기준, 중단 조건을 함께 작성해야 한다. Unreal에서 MCP는 강력한 자동 실행 장치가 아니라, 잘 정의된 작업을 빠르게 반복하기 위한 연결 방식이다. 이 차이를 이해하면 AI를 위험한 조작자가 아니라 통제 가능한 제작 파트너로 사용할 수 있다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.