← All Posts

UE5 UMG 스킬 UI 복각기 — Unreal MCP 써보기

Reminiscence
UE5 UMG 스킬 UI 복각기 — Unreal MCP 써보기
Content imagemeants.dev

작동하는 것 까지만 구현 완료.
그 이후 과정은 아트 퀄리티 업 과정이라 텍스쳐/머티리얼/애니메이션 키 수정 위주라서 여기서 마무리 하였음.

들어가며

원작 이미지 1meants.dev
원작 이미지 1
원작 이미지 2meants.dev
원작 이미지 2

도파민 최고 업무 중 하나였던 이 사악한 물건은 UI 디자인/애니메이션 전부 머티리얼만으로 스킬 연출 UI를 만들어서 포스트 프로세스에 적용한 결과물이다. 누구에게 일감을 넘겨야 했는지 모르고 재밌어 보여서 덥석 물었지만.. (이 업무 덕분에 다른 팀원도 지옥길을 걸었다.🙃)

제작 목적

UMG와 MCP 사용법을 익히기 위한 스터디. 새로 뭔가 기획부터 하면 시간이 너무 많이 들어서, 예전에 만들어봤던 결과물을 다시 구현하는 방식으로 시간에 대한 비용을 줄였다.

MCP

사용한 MCP

ChiR24/Unreal_mcp (npm: unreal-engine-mcp-server v0.5.21).

  • Epic 공식이 아니라 Chirag Panwar가 만든 커뮤니티 서버이며, TypeScript MCP 서버 + UE에 붙는 C++ 플러그인(McpAutomationBridge) 조합이다.

구조 요약:

plain text
Claude Code ──(stdio)──> MCP 서버 (Node.js/TypeScript)
                              │
                              ├─ HTTP  8090 ┐
                              └─ WS    8091 ┴─> UE Editor
                                               (McpAutomationBridge 플러그인)
  • Claude Code는 .mcp.json으로 MCP 서버 프로세스(dist/cli.js)를 stdio로 띄움
  • MCP 서버는 UE 에디터와 HTTP(8090) / WebSocket(8091)로 통신
  • UE 쪽은 McpAutomationBridge 플러그인이 Remote Control / Automation API 래핑해서 실제 에디터 조작을 실행

처음엔 수정 없이 그대로 돌려봤는데 알고보니 다운받은 MCP는 5.4 기준으로 제작된거라 5.7.4에서 바뀐 API 때문에 일부 기능이 작동하지 않았고 실시간으로 작동되게 고쳐가면서 사용중이다.

MCP한테 시킨 것

  • 화면 연출 / UI 머티리얼 노드 생성 — 반복적인 노드 연결이 많아 MCP에 맞는 작업
  • WBP 일부 세팅 — 위젯 배치, 파라미터 바인딩 같은 기계적인 작업
  • Blueprint 로직 및 노드 생성 — 의도만 명확하면 노드 조합을 빠르게 뽑아줌

손으로 해야 했던 것

  • UI 이미지
    • 이건 언리얼에서 할 수 없는거라.. 😂
  • WBP 애니메이션 키 잡기
    • 애니메이션에 등록만 MCP로 하고 키 잡는건 손으로 진행.
    • 키 잡는 것도 가능할 수도 있겠지만 텍스트로 원하는 애니메이션을 표현하는 과정과 고치는 시간이 오래 걸릴 것 같아 직접 작업하였음.
  • 노드 일부 수제작
    • 처음에는 작동하지 않아서 손으로 작업하다가 MCP를 고쳐가면서 할 수 있도록 진행하였음.

써본 소감

  • 의외로 노드 배열 정리도 가능하다.
    Content imagemeants.dev
  • 원하는 게 명확하지 않을수록 디렉팅 비용은 확실히 증가한다. 디렉션이 정확하지 않으면 MCP는 삽질하니 제작하기 전에 최대한 명확하게 구성할 것을 권장한다.
  • 머티리얼/BP는 손으로 만드는 게 제작 시간은 오히려 빠르다. 대신 MCP에 요청하면 손목을 아낄 수 있다.
  • 그리고 가끔 나보다 더 나은 결과물을 줄 때도 있다. 그 결과물을 바탕으로 디벨롭하거나 역으로 공부하기 좋다.

제작 과정

UI 리소스

이번엔 스터디용이라 전부 그대로 제작하진 않고, 라인(외곽선)만 그려서 준비하였다.

Content imagemeants.dev

머티리얼

원본은 스킬 발동 시 화면 전체를 덮는 포스트 프로세스 머티리얼 하나에 UI와 이펙트를 모두 우겨넣은 구조였다. 이번 제작 땐 두 갈래로 쪼갰다:

  • 포스트 프로세스 머티리얼 — M_PP_VisorHUD
  • UI 머티리얼 — M_UI (공용 템플릿)

역할을 이렇게 나눈 덕에 애셋 복잡도 자체도 같이 해소됐다. 원본은 머티리얼 한 장에 UI·이펙트·애니가 섞여 있어서 노드 그래프를 열면 어디를 수정해야 하는지 시간도 걸리고, 유지보수도 힘들었는데, 이번엔 역할별로 파일이 쪼개져 있어서 어디를 볼지가 바로 보인다. Image 자체는 12장이지만 좌우 반전으로 공유되는 파츠가 있어 실제 MI 애셋은 5장 수준이다.

UMG(WBP) + Blueprint 구성

원본은 포스트 프로세스 머티리얼 하나가 UI까지 전부 들고 있었지만, 이번엔 UMG 학습이 목적이라 파츠 단위로 잘라 WBP에 적용하였다.

위젯 WBP

원본 PP 한 장에 다 들어있던 UI 파츠를 12개로 잘라 배치하고, 각 파츠가 공용 UI 머티리얼 인스턴스를 물고 독립적으로 제어되도록 했다. 파츠별 등장/해제 타이밍은 위젯 애니메이션 트랙으로 따로 만들어 머티리얼과 완전히 분리했다.

인게임 컨트롤러 — BP_VisorHUDController

포스트 프로세스 머티리얼·위젯·MPC 사이의 신호를 한 곳에서 모아주는 허브. 매 프레임 버프 진행도를 머티리얼로 흘려보내고, 경고 페이즈 진입 순간을 한 번 기록해 PP에 적용하며, 위젯엔 진행도와 경고 색상 신호를 전달해 12개 파츠가 동시에 반응하게 한다.

전체 연결 흐름

flowchart LR
    subgraph BP_Group["BP"]
        Controller[BP_VisorHUDController]
    end
    subgraph WBP_Group["WBP"]
        Widget[WBP_VisorHUD]
    end
    subgraph Mat_Group["Material"]
        MPC[("MPC_VisorHUD<br/>BuffProgress")]
        PPMID["M_PP_VisorHUD MID"]
        UIMID["M_UI × 12 MID"]
    end

    Controller -->|"Tick: BuffProgress 갱신"| MPC
    MPC -.->|"읽기"| PPMID
    Controller -->|"WarningStartTime (1회)"| PPMID
    Controller -.->|"AddOrUpdateBlendable"| PPMID
    Controller -->|"UpdateProgress(Progress)"| Widget
    Controller -->|"SetWarningColors(BlendValue)"| Widget
    Widget -->|"Progress (TopMiddle03만)"| UIMID
    Widget -->|"WarningBlend (12 팬아웃)"| UIMID

결과 & 회고

작동 모션은 상단의 원본과 비슷하지만, 내부 구조는 꽤 달라졌다. 이전에 작업했을 때에는 애니메이션까지 포스트 프로세스 머티리얼에 전부 들어가 있어서 셰이더 자체가 꽤 무거웠지만 이번엔 UMG를 도입해서 UI 머티리얼이 UI 표현 하는 정도로 매우 가벼워졌고, 파츠별 등장/해제 타이밍도 Widget Animation(Render Opacity)으로 빠졌다.

다만 그렇게 전체가 가벼워졌다고 단정하긴 이르다. 런타임엔 12개 Image 각자가 MID를 물고 움직이는 구조라 드로우콜/UI 블렌드 쪽에서 새로운 비용이 생겼을 가능성이 있다. 머티리얼 한 장에 몰아넣었을 때의 셰이더 부담 vs. Image 12장 × MID 업데이트 × UI 오버드로우, 어느 쪽이 실제로 더 무거운지는 추후 퍼포먼스 테스트로 비교해볼 예정이다.

MCP는 제작 골격이 잡힌 뒤에 써야 훨씬 더 빠른 결과물을 낼 수 있다. MID 12개 선언, SetScalarParameterValue 팬아웃처럼 똑같은 노드가 반복되는 블록은 확실히 빠르다. 반면 초반처럼 뭘 만들지 자체가 흐릿할 땐 "이 Lerp의 B쪽에 이걸 붙이고…"를 말로 풀어내는 비용이 에디터에서 직접 드래그하는 것보다 더 번거롭고 AI 비용을 헛되게 쓸 수 있다. 골격이 잡힌 뒤의 기계적인 작업만 넘기는 게 안정적이었지만 색수차, 글리치 표현 같은 명사 단위로 표현할 수 있는 작업은 의외의 좋은 결과물을 가져오기도 했다.