Unreal Engine Skills

Unreal Engine Skills for Claude Code는 AI에게 언리얼 에디터를 다루는 방법을 알려 주는 플러그인입니다. 언리얼 에디터는 게임 속 공간과 캐릭터, 화면을 만드는 제작 프로그램입니다. 이 플러그인은 Claude가 그 안의 물건을 조회하고 수정하도록 안내합니다. 다만 실제로 손을 움직이는 도구는 별도로 준비한 엔진 쪽에 있어야 합니다.

이번에는 저장소의 파일을 읽고, 작업 폴더를 알아보는 시작 스크립트를 임시 폴더에서 실행했습니다. 에디터에 연결하거나 게임 테스트를 돌리지는 않았습니다. 설치만 하면 제 게임에서 바로 작동한다고 말할 근거는 아직 없습니다.

AI가 게임 제작 프로그램 안에서 할 일을 고릅니다

예를 들어 「현재 맵에 있는 물건을 보여 줘」라고 요청하면, AI는 관련 도구의 사용법을 확인하고 에디터에 조회를 요청합니다. 물건을 배치하거나 재질을 바꾸는 작업도 같은 경로를 씁니다. 여기서 MCP는 AI와 제작 프로그램 사이에 요청과 결과를 주고받는 통로입니다.

기능 범위는 넓습니다. 하지만 그 기능의 구현이 전부 이 작은 저장소 안에 들어 있다는 뜻은 아닙니다. 에디터가 어떤 도구를 제공하는지는 연결한 엔진과 켠 플러그인에 달려 있습니다.

하려는 일	이 플러그인이 안내하는 경로
맵과 에셋 살펴보기	에디터가 제공하는 조회 도구 찾기
블루프린트·재질 등 편집	입력 형식 확인 후 해당 도구 호출
새 작업 도구 만들기	별도 스킬의 C++·Python 작성 지침 읽기
프로젝트 작업법 알려 주기	에디터에 등록된 프로젝트 스킬 확인

설치 전에 엔진 쪽 부품부터 확인해야 합니다

확인한 파일 구성에는 스킬이 세 개 있었습니다. 하나는 에디터를 사용하는 법, 하나는 새 도구를 만드는 법, 나머지는 프로젝트의 작업 지침을 만드는 법입니다. 시작할 때 작업 폴더를 확인하는 Bash 스크립트도 있습니다.

엔진부터 봐야 합니다. 이 저장소에는 엔진 플러그인의 소스나 실행 파일이 없기 때문에, 자신의 엔진에 필요한 부품이 들어 있는지 확인한 다음에야 연결을 시도할 수 있습니다. 읽은 문서만으로 특정 언리얼 버전이나 모든 런처 설치본에서 된다고 보증할 수는 없습니다.

연결 표시가 떠도 실제 작업이 되는지 한 번 더 봅니다

선택 기능인 프록시는 에디터가 꺼져도 AI 쪽 연결을 유지하도록 돕습니다. 그런데 그때 보이는 도구 목록은 이전에 저장해 둔 것일 수 있습니다. 메뉴가 보인다고 주방이 열려 있는 것은 아닙니다.

확인은 작은 조회로 합니다. 편집을 시키기 전에 실제 에디터에서 정보를 하나 읽어 오게 하고, 그 결과가 성공했는지 확인하는 식입니다. 이 구분은 다른 자동화 도구에도 그대로 가져갈 만합니다.

제가 실행한 것은 게임이 아니라 시작 훅입니다

훅은 AI 세션이 시작될 때 돌아가는 짧은 스크립트입니다. 저는 실제 게임 대신 빈 임시 폴더에 프로젝트 표시 파일을 놓고 여섯 조건을 만들었습니다. 프로젝트 안에서 시작하는 네 조건은 예상한 문맥을 출력했습니다. 프로젝트가 없는 두 조건은 6초 제한 안에 종료하지 않았습니다.

추적해 보니 상위 폴더를 따라 루트까지 간 뒤의 파일 검색이 문제 지점이었습니다. 같은 PC에서 루트 표기를 정리한 대조 실행은 끝났습니다. 이것은 Windows Git Bash에서 확인한 훅의 동작입니다. 다른 운영체제나 에디터 전체의 실패로 넓혀 읽을 결과는 아닙니다.

가져갈 것은 도구 개수보다 확인 순서입니다

제 작업에 적용한다면 먼저 버전 관리가 되는 작은 실험 프로젝트에서 연결과 조회를 확인하겠습니다. 다음 단계가 에셋 하나의 수정과 결과 재조회입니다. 여러 대상을 한꺼번에 바꾸는 일은 그 뒤입니다.

게임 QA에도 쓸 여지는 있습니다. 다만 에디터가 테스트를 실행할 수 있다는 설명만으로 플레이어 입력, 서버 처리, 최종 게임 결과까지 검증됐다고 볼 수는 없습니다. 무엇을 시켰고 어떤 결과를 받아야 성공인지는 테스트마다 따로 정해야 합니다.

여기부터는 자세한 기록입니다

분석 기준은 2026-10-19에 받은 커밋 a6aa73ada02a9fb1f5415bec491f9942c519b297입니다. 메타데이터 버전은 3.1.1입니다. 원문은 github.com/EpicGames/unreal-engine-skills-for-claude-code-plugin에 고정했습니다.

추적 파일 12개에서 실행부와 지침의 경계가 보였습니다

git ls-files 기준 추적 파일은 12개입니다. 그중 SKILL.md는 3개이고, 엔진 플러그인 정의인 .uplugin 파일은 없습니다. 이 수치는 엔진이 제공하는 도구 수가 아니라 이 저장소의 파일 수입니다.

파일	읽고 확인한 역할
skills/unreal-mcp/SKILL.md	실행 중인 에디터의 도구 탐색·호출 지침
skills/create-toolset/SKILL.md	기존 기능 중복 확인, 타입 설계, 도구 구현·테스트 지침
skills/unreal-skill/SKILL.md	에디터 내부 Agent Skill의 작성·등록 지침
hooks/unreal-context.sh	상위 폴더에서 UE 표시를 찾아 세션 문맥 출력

README의 Contents에는 unreal-mcp만 적혀 있었지만, 실제 커밋에는 동반 스킬 둘이 더 있습니다. 문서의 목차와 파일 목록을 같은 것으로 취급하지 않은 덕분에 찾은 차이입니다. 고정 커밋의 파일 구성

수백 개 기능은 필요할 때 찾아서 부릅니다

기본 탐색 모드에서 처음 노출되는 것은 list_toolsets, describe_toolset, call_tool 세 진입점입니다. 대상 도구군을 알면 설명 조회부터 시작하고, 확인한 스키마에 맞춰 호출합니다. 같은 실행 지침은 프로젝트에 등록된 Agent Skill도 별도로 찾아보도록 합니다. 실행 스킬

따라서 제 수확은 「도구 이름을 더 많이 외우자」가 아닙니다. 호출 직전에 현재 인터페이스를 확인하자는 순서입니다. 문맥 절약과 캐시 유지가 설계 의도라는 점은 읽었지만, 토큰 절감량이나 속도는 측정하지 않았습니다.

연결 서버와 실행 도구는 따로 준비합니다

설정 문서는 엔진의 ModelContextProtocol과 AllToolsets를 함께 켜도록 안내합니다. 개별 도구군만 선택할 수도 있습니다. 서버 시작 뒤에는 ModelContextProtocol.GenerateClientConfig ClaudeCode로 클라이언트 설정을 생성합니다. 이 저장소에는 고정 .mcp.json이 없습니다. 설정 원문

문서에는 Codex용 설정 생성도 나옵니다. 그렇다고 Claude Code의 설치 명령과 훅까지 그대로 Codex에 적용된다는 뜻은 아닙니다. 연결 설정을 만들 수 있다는 사실과 클라이언트별 작업 지침이 설치됐다는 사실은 다릅니다.

훅 여섯 조건 중 넷은 완료했고 둘은 시간 초과였습니다

원본 훅을 수정하지 않고 Git Bash 5.2.37에서 실행했습니다. 입력은 모두 임시 폴더와 표시 파일입니다. 출력 JSON의 문맥, 종료 코드, 설정 파일 존재 안내를 비교했습니다.

조건	관찰
공백이 있는 .uproject 파일명, 프로젝트 루트	프로젝트명 출력, 종료 0
같은 프로젝트의 Source 하위 폴더	상위 프로젝트 발견, 종료 0
.mcp.json이 있는 프로젝트의 Content 폴더	설정 파일 존재 안내, 종료 0
GenerateProjectFiles.bat가 있는 엔진의 깊은 모듈 폴더	엔진 소스 트리로 분류, 종료 0
UE 표시가 전혀 없는 폴더	6,000ms 제한 초과
Engine이라는 폴더만 있고 UE 표시가 없는 곳	6,000ms 제한 초과

추적 실행과 최소 대조를 더했습니다. /*.uproject 확장은 49ms에 끝났고 //*.uproject 확장은 3,500ms 제한을 넘었습니다. 루트에서 끝의 /를 제거하도록 메모리 속 복사본만 바꿔 실행하니, 원래 멈췄던 두 조건은 각각 370ms와 400ms에 출력 없이 정상 종료했습니다.

이는 이 PC에서 루트 glob 표기가 지연과 관련 있다는 재현 근거입니다. Windows 전반의 원인이나 네트워크 동작까지 증명한 것은 아닙니다. 원본 저장소에 수정하거나 이슈를 등록하지도 않았습니다. 훅 설정의 제한은 5초이므로 이 환경에서는 프로젝트 밖 시작을 주의해서 볼 필요가 있습니다. 훅 원본, 훅 등록

자동화에 붙일 때는 결과를 다시 읽는 단계가 필요합니다

새 도구를 만드는 스킬은 기존 도구와의 중복 확인, 명확한 데이터 타입, 오류 처리, 테스트를 요구합니다. 동기 도구의 정상 반환과 비동기 결과의 성공·오류 처리도 구분합니다. 작업 지침을 만드는 스킬은 프로젝트 지식과 도구 자체를 나눕니다. 도구 작성 지침, Agent Skill 작성 지침

이를 QA에 대입한다면 제안은 다음 순서입니다. 현재 상태 읽기 → 작은 행동 → 도구의 완료 결과 확인 → 바뀐 상태 재조회. 서버가 판정하는 기능이라면 서버 측 결과 증거도 추가해야 합니다. 이것은 적용 제안이며 이번에 완성한 QA 기능이 아닙니다.

설치 가능성과 실제 효용은 아직 남아 있습니다

에디터 실행, MCP 왕복 호출, Blueprint 컴파일, 에셋 저장, 프록시 복구를 시험하지 않았습니다. 호환 엔진 버전의 범위와 각 클라이언트의 실제 지원도 확인하지 않았습니다. 에셋을 수정하는 작업에는 복구 가능한 상태가 필요합니다. Python 스크립트 실행처럼 권한이 넓은 경로도 있으므로 작은 실험 범위부터 확인할 계획입니다.

현재 판정은 연결·조회 파일럿 후보입니다. 이번에 얻은 것은 설치 완료나 QA 개선 완료가 아니라, 무엇을 먼저 연결하고 무엇으로 성공을 확인해야 하는지에 대한 구체적인 순서입니다.