UE6 소스 코드 공개, UE5.8과 UE6의 신규 모듈 21개를 비교

2026년 8월은 너무나도 더운 날씨가 계속됩니다. 날씨도 그렇지만 몇 개월동안 마음이 불편한 일들이 있어 생각을 정리하기에도 벅찬 시간을 보냈네요. 

이러나 저러나 그래도 언리얼엔진 6과 Verse 는 저의 큰 관심사 중 하나인터라... 지하철에서 또 읽을 거리를 남기고자 합니다. 내용파악은 사람이 + 글 정리는 AI로 작성했습니다.

---

UE5에서 UE6로 넘어가는 일도 본질적으로는 한 번의 이사입니다. 하지만 많은 사람이 기대하는 “매끄러운 업그레이드, 그대로인 콘센트 위치”와 달리, Epic은 분명히 밝혔습니다. UE5에서 UE6로의 마이그레이션은 과거 UE4에서 UE5로 넘어갈 때보다 더 어려울 것입니다.

Epic은 새집에 방 두 개만 덧붙인 게 아닙니다. 하나는 Verse 언어, 다른 하나는 Scene Graph(씬 그래프) 엔티티 프레임워크라는 이름의 새로운 내력 구조를 설계했습니다. 당분간은 낡은 가구도 계속 쓸 수 있지만, Epic은 이미 예고했습니다. 새 프레임워크가 “충분히 성숙”하면 Blueprint와 Actor 체계는 단계적으로 지원 중단(deprecate)되고, 변환 도구가 제공될 것입니다.

UE6 소스 코드는 이미 GitHub의 ue6-main 브랜치에 공개됐습니다. 저는 하루 밤낮을 들여 UE5.8과 UE6의 플러그인 디렉터리를 비교했고, UE5.8에는 없고 UE6에 새로 들어온 모듈 21개를 찾아냈습니다. 이 글에서는 트레일러도, 공식 편집 영상도 보지 않겠습니다. 오직 코드를 보고 Epic 공식 로드맵 《The Road to UE 6》와 대조하면서, 많은 사람이 잘못 답하고 있는 질문에 답해 보겠습니다. 여러분의 UE5 프로젝트는 지금부터 UE6 업그레이드를 준비해야 할까요? 그렇다면 어떻게 넘어가야 할까요?

먼저 공식 입장부터 분명히 하겠습니다（이것이 뒤의 모든 판단을 결정합니다）

소스 코드를 뜯어보기 전에, 이 글의 전제가 되는 Epic 공식 사실 네 가지부터 확인하겠습니다. 많은 미디어가 이 내용을 거꾸로 설명하고 있습니다.

① UE6 = UE5와 UEFN을 하나의 통합 엔진으로 합친 것입니다.

Epic EVP Marcus Wassmer는 《The Road to UE 6》에서 이렇게 썼습니다. UE4는 누구나 엔진을 사용할 수 있게 했고, UE5는 세계를 구축하는 방식을 새롭게 정의했으며, UE6는 “세계를 배포하고 운영하는 방법”에 관한 것입니다. 즉 UE5（고사양 싱글 플레이·대작）와 Unreal Editor for Fortnite（UEFN, 새 프로그래밍 모델의 실전 시험장）를 하나로 합칩니다.

② Early Access는 2027년 말, 정식 버전은 그로부터 12~18개월 뒤（대략 2029년 중반）입니다.

다시 말해 UE6를 정식으로 사용할 수 있는 시점은 빨라도 2029년입니다. 내년의 일이 아니라 “장기전”을 전제로 한 결정입니다.

③ UE5.8은 계획된 UE5의 마지막 메이저 버전입니다.

Epic은 5.8 이후 UE5에 새로운 기능을 담은 메이저 버전을 내지 않고, 버그 수정과 유지보수만 진행한다고 확인했습니다. 따라서 2027년 말 이전에 출시해야 한다면 UE5.8이 종착역입니다. 새로운 엔진 기능 없이 장기간 유지해야 할 준비가 필요합니다.

④ Blueprint와 Actor는 “단계적으로 지원 중단”되지만, Epic은 마이그레이션 도구 제공을 약속했습니다.

가장 중요하면서도 가장 자주 오해되는 대목입니다. Epic의 원문은 UE6의 새 프레임워크（Scene Graph + Verse）가 “충분히 성숙”하면 Blueprint와 Actor 체계를 지원 중단하고, 기존 프레임워크를 새 프레임워크로 변환하는 도구를 제공하겠다는 것입니다. 따라서 정확한 표현은 “Actor는 영원히 사라지지 않습니다”가 아니라, “단기적으로는 유지되지만 장기적으로는 퇴장하며, 전환 기간과 도구가 제공됩니다”입니다.

먼저 코드를 살펴보겠습니다: UE6에는 대체 무엇이 추가됐을까요?

두 엔진의 Engine/Plugins/ 디렉터리를 diff하면, UE6에 추가된 세 가지 큰 방향이 보입니다.

1. Verse 언어 패키지 전체（플러그인 3개, UE5.8에는 전혀 없습니다）

Engine/Plugins/Verse/              ← Verse 엔진 통합 계층（여러 하위 모듈）
Engine/Plugins/VerseInterface/     ← Verse와 엔진 사이의 C++ 인터페이스 계층
Engine/Plugins/VerseVM/            ← Verse 가상 머신（바이트코드 + 디버거）

VerseInterface는 Verse 시스템 전체의 “콘센트”입니다. 외부에 노출하는 공개 헤더는 매우 적습니다.

// VerseInterface/Public/IVerseInterfaceModule.h
// VerseInterface/Public/SolarisDebugMessage.h

인터페이스 계층은 의도적으로 얇게 만들어졌습니다. Verse 런타임과 엔진이 극도로 좁은 인터페이스를 통해 결합한다는 뜻입니다. Epic이 언어 런타임을 엔진 본체에서 의도적으로 분리한 것입니다. 단기적으로는 Verse가 존재한다는 이유만으로 기존 C++ 코드를 억지로 고칠 필요가 없습니다.

흔한 오해 하나는 바로잡아야 합니다. Verse는 “C++의 대체재”도 아니고 “C++로 컴파일되는 언어”도 아닙니다. Verse는 Epic이 대규모 멀티플레이와 동시성을 위해 자체 개발한 새로운 함수형 논리 언어입니다（Epic 내부의 전신 코드명은 ULang입니다）. VerseVM이라는 바이트코드 가상 머신에서 실행되며, Blueprint VM과는 독립적인 실행 파이프라인을 사용하므로 둘은 함께 존재할 수 있습니다.

Verse 소스 → 컴파일러 프런트엔드 → VerseVM 바이트코드 → VerseVM 실행
（Blueprint VM과 서로 독립적이며 간섭하지 않음）

2. Scene Graph 엔티티 프레임워크 / EntityFramework（하위 모듈 21개, UE5.8에는 전혀 없습니다）

UE6에서 가장 무겁고, 동시에 가장 과소평가된 방향입니다. 소스 파일만 약 638개입니다. 주의할 점은 이것이 “선택적으로 쓰는 소수 취향의 최적화 플러그인”이 아니라는 것입니다. Epic이 공식적으로 지목한, Verse로 처음부터 구축하는 차세대 게임 프레임워크 Scene Graph의 엔진 측 구현입니다. Scene Graph는 이미 UEFN에서 수년간 실전에 투입됐고, Actor/Component 체계의 차세대 후계자로 자리매김했습니다.

EntityFramework/Source/
├── Entity/                  ← 핵심: entity 클래스, component 클래스, SceneGraph API
├── Component/               ← 내장 컴포넌트 라이브러리（Mesh/Light/Physics/Sound/Particle）
├── EntityLevel/             ← 레벨의 Entity 관리, SceneGraph 설정
├── EntitySimulation/        ← 시뮬레이션 런타임
├── ActorEntity/             ← 🔑 Actor ↔ Entity 브리지 계층（마이그레이션기의 핵심）
├── EntityEditor/            ← 에디터 통합
├── EntitySequencer/         ← Sequencer 통합
├── EntitySkeletalAnimation/ ← 스켈레탈 애니메이션 통합
├── EntityStreaming/         ← 스트리밍 로딩
├── EntityLandscape/         ← 랜드스케이프 통합
├── EntityModifiers/         ← 모디파이어 시스템（Mass 통합 포함）
├── EntityRegistry/          ← 레지스트리
├── EntityPrefabEditor/      ← Prefab 에디터
├── Execution/               ← 실행 엔진
├── RigidPhysicsCore/        ← 리지드바디 물리 코어
├── AgentGroup/              ← Agent 그룹화
├── TedsVerseEntityFields/   ← Verse와 Entity의 타입 매핑
└── TedsVersePathRegistry/   ← Verse 경로 등록

전환기에서 가장 중요한 것은 ActorEntity/입니다. Actor 모델과 Entity 모델 사이의 브리지를 정의합니다.

// ActorEntity/Public/ActorEntityBridge.h
// ActorEntity/Public/ActorEntitySubsystem.h
// ActorEntity/Public/ActorEntityComponent.h

// 브리지 구현（Private/Bridges/）:
StaticMeshComponentBridge.h    ← StaticMeshComponent → MeshEntityComponent
PhysicsComponentBridge.h       ← PhysicsBody → PhysicsEntityComponent
SoundComponentBridge.h         ← AudioComponent → SoundComponent
TransformComponentBridge.h     ← SceneComponent → Transform
ParticleSystemComponentBridge.h
LandscapeComponentBridge.h
PossessableComponentBridge.h
TagComponentBridge.h

올바른 해석은 다음과 같습니다. Bridge는 “Actor가 영구히 공존한다”는 증거가 아니라 “마이그레이션 기간의 호환 계층”이라는 증거입니다. Epic은 흔히 쓰는 ActorComponent마다 Entity로 번역하는 변환기를 작성해 두었습니다. 전환기에는 기존 코드도 계속 돌아가게 하려는 것입니다. 하지만 브리지 계층의 존재는 오히려 Entity/Scene Graph가 목표 상태이고, Actor는 번역되고 단계적으로 교체되는 쪽이라는 사실을 보여 줍니다. “결국 Actor를 지원 중단한다”는 공식 입장과도 정확히 맞아떨어집니다.

3. Mass Gameplay 유지（약 293개 파일, UE5.8에서 이어집니다）

Engine/Plugins/Runtime/MassGameplay/        ← 그대로 존재, 여러 하위 모듈
Engine/Plugins/Experimental/MassCharacters/
Engine/Plugins/Experimental/MassIrisReplication/

Mass Entity는 제거되지 않았습니다. 역할은 이렇게 이해하시면 됩니다. Mass는 “대규모 데이터 지향 엔티티”（수천·수만 개의 agent）를 처리하고, Scene Graph/EntityFramework는 “모든 엔티티”를 위한 범용 프레임워크입니다. EntityModifiers를 통해 Mass도 통합합니다. 둘은 서로 대체하는 관계가 아니라 상호 보완하고 통합되는 관계입니다.

엔진 업그레이드 자체: 기반은 안정적이지만 “매끄럽다”는 말에 속지 마세요

좋은 소식도 분명히 있습니다. UE6의 .uproject 형식, .uasset 직렬화, C++ 리플렉션 매크로（UCLASS/UPROPERTY/UFUNCTION 등） 같은 기반 인프라는 UE5.8과 매우 비슷합니다. 핵심 헤더를 표본 조사해도 확인됩니다.

// UE6 Engine/Source/Runtime/Core/Public/CoreMinimal.h
// UE5.8과 거의 같은 include 구조와 매크로 정의

// UE6 Engine/Source/Runtime/Engine/Classes/GameFramework/Actor.h
// EA 단계에서도 Actor 클래스가 남아 있고, 핵심 가상 함수도 제거되지 않음

다만 “기반 인프라가 호환된다”는 말은 “업그레이드 위험이 0입니다”라는 뜻이 아닙니다. Epic은 UE5→UE6 마이그레이션이 UE4→UE5보다 어렵다고 분명히 밝혔습니다. 원인은 위에서 살펴본 두 개의 새로운 내력 구조——Verse와 Scene Graph입니다. 둘은 Epic이 밀고 있는 새 프로그래밍 패러다임을 뜻하며, 기존 Blueprint/Actor 패러다임은 결국 지원 중단됩니다. 그러므로 더 정확한 결론은 다음과 같습니다.

• 단기（EA 단계）: 엔진 업그레이드는 가능하고, 기존 프로젝트도 높은 확률로 실행됩니다. 마이그레이션 비용은 비교적 통제할 수 있습니다.
• 장기（정식 버전 이후）: Blueprint/Actor가 단계적으로 지원 중단되면서 “개조하지 않는” 프로젝트는 갈수록 수세에 몰립니다. 진짜 비용은 “업그레이드” 버튼을 누르는 데 있는 게 아니라 패러다임을 옮기는 데 있습니다.

Rocket League는 UE6로 이전하는 첫 번째 플래그십 프로젝트 중 하나로 확인됐고, Epic의 Fortnite도 같은 체계 위에서 발전하고 있습니다. 이는 마이그레이션 경로가 실제로 존재한다는 뜻이지만, 동시에 공짜로 매끄럽게 넘어가는 일이 아니라 공학 자원을 투입해 걸어가야 할 길이라는 뜻이기도 합니다.

Verse 언어: 사용할지는 프로젝트의 로직 계층이 얼마나 무거운지에 달려 있습니다

VerseInterface와 Entity 소스를 보면 Verse와 엔진의 상호작용 모델은 꽤 명확합니다. Verse component에는 완전한 생명주기가 있습니다.

// Entity/Public/Component.h — Verse component 생명주기
// 1. OnInitialized       ← 컴포넌트 생성 완료
// 2. OnAddedToScene      ← 씬에 추가
// 3. OnBeginSimulation   ← 시뮬레이션 시작
// 4. OnEndSimulation     ← 시뮬레이션 종료
// 5. OnRemovingFromScene ← 씬에서 제거
// 6. OnUninitializing    ← 파괴

이 생명주기는 ActorComponent의 BeginPlay → Tick → EndPlay와 뚜렷하게 대응합니다. Verse component는 대략 “Verse로 작성되어 Scene Graph 위에서 실행되는 ActorComponent”라고 이해하시면 됩니다.

프로젝트 세 종류, 전략도 세 가지입니다

새 프로젝트（2027년 말 EA 이후 시작）：Verse + Scene Graph를 바로 사용하세요.

기존 부담이 없습니다. Verse는 설계 단계부터 대규모 멀티플레이와 동시성을 겨냥했습니다——이는 본질적으로 단일 스레드·단일 프레임 실행 모델인 Blueprint 노드 그래프가 자연스럽게 해내기 어려운 일입니다. Epic은 Verse와 Scene Graph를 UE6 프로그래밍의 기반으로 삼고 있습니다. 새 프로젝트가 공식 주류를 따르면 장기 유지비가 가장 낮습니다.

기존 프로젝트, 로직 계층이 가벼움：적절한 시점에 단계적으로 이전하세요.

로직이 주로 글루 코드（C++ 호출, UI 이벤트 처리, 간단한 상태 전환）라면 Verse 이전 작업량은 비교적 통제할 수 있습니다. 다만 솔직히 말씀드려야 합니다. 현재 독립 엔진 사용자가 접할 수 있는 Verse 공개 자료는 여전히 UEFN 중심이며, 완전한 데스크톱 도구 체인은 EA가 되어야 성숙할 것입니다. 너무 일찍 올인하는 것은 적절하지 않습니다.

기존 프로젝트, Blueprint/C++ 로직이 많음：우선 안정적으로 유지하고 마이그레이션 도구에 주목하세요.

출시된 프로젝트에는 Blueprint 클래스가 수백 개일 수 있어 수작업 재작성은 비현실적입니다. 다행히 Epic은 “기존 프레임워크 → 새 프레임워크” 변환 도구 제공을 공식적으로 약속했습니다. 소스 코드에도 근거가 있습니다.

TedsVerseEntityFields/   ← Verse 타입 ↔ Entity 필드 매핑
TedsVersePathRegistry/   ← Verse 경로 등록

두 모듈은 Epic이 설계 단계부터 기존 타입 시스템을 Verse/Entity 타입 시스템으로 매핑하는 문제를 고려했다는 뜻입니다. Blueprint 노드 그래프는 본질적으로 구조화된 강타입 로직 그래프이므로 프로그램으로 분석하고 변환하기에 잘 맞습니다.

다만 판단에는 절제가 필요합니다. Epic이 GenAI 도구 체인（MCP, Claude/Codex 통합）에 크게 투자하는 방향을 보면 “AI 보조 BP/Actor → Verse/Scene Graph 마이그레이션”은 기술적으로 합리적인 추측입니다. 아마 원클릭 변환보다는 “도구 생성 + 사람의 검토” 형태의 반자동 흐름에 가까울 것입니다. 하지만 이 부분은 확인된 사실이 아니라 합리적인 추측으로만 받아들여야 합니다.현재 Epic이 약속한 것은 “변환 도구 제공”이지 “AI 원클릭 마이그레이션”이 아닙니다. 의사 결정은 공식적으로 확인된 약속을 기준으로 해야 합니다.

Scene Graph / Entity Framework: Actor는 단기적으로 공존하지만 장기적으로는 자리를 내줍니다

UE6에서 가장 오해받기 쉬운 부분입니다. 한쪽 극단은 “Actor가 당장 죽습니다”, 다른 극단은 “Actor는 영원히 죽지 않습니다”인데둘 다 정확하지 않습니다.

소스 코드와 공식 입장을 합쳐 보면 진실은 “단계별 전환”입니다.

ActorEntity 브리지 계층: 마이그레이션기의 호환 보장

// ActorEntity/Public/ActorEntityBridge.h      ← Actor → Entity 변환 규칙 정의
// ActorEntity/Public/ActorEntitySubsystem.h   ← Actor / Entity 매핑 관계 관리
// ActorEntity/Private/Bridges/StaticMeshComponentBridge.h
//   ← StaticMeshComponent → MeshEntityComponent 구체 변환 로직

EA와 그 이후 일정 기간 Epic은 Actor를 제거하지 않습니다. Bridge가 엔진 내부에서 투명하게 변환하므로, 전환기에는 AActor / UActorComponent 코드 대부분을 고치지 않아도 됩니다. 이것은 “연착륙”이지 “영구적인 이중 노선”이 아닙니다.

Entity 모델은 어떻게 생겼을까요?

// Entity/Public/Entity.h
class entity : public UBaseEntity
{
    // 컴포넌트 추가
    virtual void AddComponents(TArray<TNonNullPtr<component>> const& NewComponents);

    // 타입으로 컴포넌트 조회
    component* GetComponentByType(const TSubclassOf<component> ComponentType) const;

    // 모든 컴포넌트 순회
    template<typename VisitorType>
    static void ForEachComponent(NotNullEntityType&& Entity, VisitorType&& Functor, ...);

    // 모든 컴포넌트 조회
    TArray<TNonNullPtr<component>> GetComponents() const;
};

Unity의 GameObject.GetComponent<T>()를 써 보셨다면 익숙한 API일 것입니다. 다만 UE6의 Entity는 Unity GameObject보다 더 저수준입니다——SceneGraph, 네트워크 리플리케이션, 스트리밍 로딩과 직접 연결되며 상위 래퍼가 아니라 엔진의 일급 시민입니다.

SceneGraph: 단순한 렌더링 트리가 아니라 엔티티 시스템 전체의 골격입니다

// EntityLevel/Public/SceneGraph/SceneGraphSettings.h
//   ← SceneGraph가 관리하는 도메인 제어

// Entity/Public/SceneGraphNetAPI.h
//   ← SceneGraph 네트워크 리플리케이션 API, 부모·자식 관계의 복제 순서 보장:
//   Entity → SubObjectA → ComponentZ → SubObjectB → SubObjectC

이름이 같은 두 개념을 구분해야 합니다. 전통 그래픽스의 scene graph는 렌더링 씬 트리입니다. 반면 UE6의 Scene Graph는 완전한 게임 오브젝트 구성 프레임워크입니다——엔티티의 공간 관계, 부모·자식 계층, 네트워크 복제 순서를 관리하며 Verse 프로그래밍 모델을 실행하는 기반입니다. Actor의 AttachToActor는 새 모델에서 Scene Graph의 부모·자식 관계에 대응합니다.

기존 프로젝트에 미치는 영향（단계별）

프로젝트 유형 EA	단기 영향 정식 버전	장기 영향
전통적인 싱글/멀티플레이 게임	낮음. Actor가 계속 동작하고 Bridge가 자동 변환	Scene Graph 이전을 계획해야 하며 Actor는 결국 지원 중단
대규모 엔티티 시뮬레이션（RTS/배틀로얄/오픈월드）	긍정적. Entity + Mass가 순수 Actor보다 훨씬 효율적	큰 혜택. 새 패러다임 자체가 이를 위해 만들어짐
Fortnite식 게임 간 에셋 호환을 원함	필요. Entity/Verse가 이식 가능한 에셋의 기반	필수이며 공식 개방형 표준 노선과 연동
Actor / Blueprint 이벤트 그래프에 크게 의존	단기에는 호환 계층으로 그대로 유지 가능	반드시 이전. 도구와 비용을 일찍 평가할수록 주도권 확보

한 문장으로 정리하면, Scene Graph/Entity Framework는 EA 단계에서는 “증분 선택지”지만, 정식 버전 이후에는 “공식 주류이자 최종 상태”입니다. UE5에 Mass가 추가됐던 일과 완전히 같지는 않습니다——Mass는 보완재였지만 Scene Graph는 Epic이 Actor의 후계자로 명시한 체계입니다. 이를 단순한 “선택 사항”으로만 보면 2028년 이후 수세에 몰릴 수 있습니다.

MCP + GenAI: 업그레이드하면 바로 쓸 수 있는 “공짜 점심”입니다

이 부분의 판단은 유효하지만 버전은 정확히 짚겠습니다.

• UE5.8에는 이미 Claude, Gemini 같은 모델을 UE 프로젝트에 직접 연결하는 실험적(Experimental) MCP 플러그인이 내장돼 있습니다. 일부 AI 기능은 5.8에서도 미리 체험할 수 있습니다.
• UE6에서는 GenAI 도구 체인을 더 깊이 통합하고 프로덕션 수준의 워크플로로 발전시키며, “사용자 자체 모델”(bring your own model)도 지원합니다. 이 모델들은 Epic 내부와 UEFN에서 실전 검증을 거쳤습니다.

Epic의 로드맵은 아주 직설적입니다. LLM, 생성 모델, Claude·Codex 같은 도구가 “콘텐츠를 더 빠르게 구축하도록 돕는 일”에서 핵심 역할을 맡게 됩니다. State of Unreal 2026 현장 데모에서는 채팅창으로 가상 아파트에 가구를 추가하고, 도시 씬의 조명 시간을 조정하며, 정지 사진 한 장을 조명 참고 자료로 사용하는 모습도 보여 줬습니다.

이 기능들의 가장 큰 가치는 프로젝트 핵심 아키텍처 코드를 대부분 고칠 필요가 없다는 것입니다. 엔진만 올리면（일부는 5.8에서도） AI 도구를 바로 쓸 수 있습니다. 확실히 가장 빨리 이익을 볼 수 있는 영역입니다.

의사 결정 매트릭스: 네 가지 프로젝트에는 네 가지 답이 있습니다

프로젝트 유형	권장안	시점	핵심 고려 사항
새 프로젝트（2027년 말 이후 시작）	✅ UE6 직접 사용	UE6 EA 공개 후	기존 부담 없음, Verse + Scene Graph 공식 주류 추종
기존 프로젝트, 가벼운 로직, 2028년 이후 출시	✅ 공개 후 업그레이드 평가	UE6 정식 버전	기반 호환, 로직 계층 단계적 이전
기존 프로젝트, BP/Actor 다수, 2028년 이후 출시	⚠️ 마이그레이션 도구를 기다림	변환 도구가 명확해진 뒤	패러다임 이전 비용이 크므로 공식 도구를 기다림
기존 프로젝트, 2027년 말 이전 출시	❌ 기다리지 말고 UE5.8 사용	UE5.8 안정 버전	5.8은 UE5 막차, 장기 유지보수 준비

참고로 UE6 Early Access는 2027년 말이고 정식 버전은 2029년 중반으로 예상됩니다. 2028년 중반 이전에 반드시 출시해야 하는 프로젝트는 본질적으로 UE5.8을 기준으로 결정해야 합니다.

지금 할 수 있는 네 가지입니다

UE6를 정식으로 쓰기까지 적어도 2~3년은 남았습니다. 불안해할 필요는 없지만 미리 포석은 둘 수 있습니다.

1. 코드 측면：모듈성을 유지하세요. 미래에 수동으로 이전하든 AI 도움을 받든, 함수를 작게 나누고 인터페이스를 명확히 하며 로직과 표현을 분리한 코드는 더 다루기 쉽습니다. 그 자체로도 좋은 엔지니어링 습관이므로 헛되지 않습니다.

2. 지식 측면：지금 UEFN의 Scene Graph + Verse를 직접 써 보세요. 현재 UE6의 새 패러다임을 실제로 체험할 유일한 방법입니다. Scene Graph와 Verse는 UEFN에서 이미 쓸 수 있습니다. UE6 EA가 나온 뒤 처음 배우는 것보다 미리 손에 익혀 두는 편이 훨씬 여유롭습니다.

3. 도구 측면：UE5.8에서 MCP 플러그인을 시험해 보세요. Claude/Gemini를 기존 프로젝트에 연결해 AI 보조가 팀 워크플로에서 실제로 얼마나 이득인지 평가하세요. 이 부분은 지금 당장 실행할 수 있습니다.

4. 아키텍처 측면：싱글 스레드 병목을 식별하세요. 성능 병목이 대량의 Actor Tick 같은 싱글 스레드 게임 로직에서 온다면, UE6의 Verse 동시성 + Scene Graph 데이터 지향 모델이 Verse 언어 자체보다 더 직접적으로 문제를 해결할 수 있습니다. 미리 병목 지점을 정리해 두세요.

부록: 실무에 적용 가능한 “마이그레이션 비용 자가 진단 프레임워크”입니다

“업그레이드해야 하나요?”라는 질문은 너무 추상적입니다. 공학적으로는 수치화할 수 있습니다. 아래의 간단한 자가 진단으로 감각적인 판단을 대화 가능한 숫자로 바꿔 보겠습니다.

1단계：로직 에셋을 조사합니다. 다음 네 숫자를 세어 보세요.

• Blueprint 클래스 수（특히 순수 데이터가 아니라 복잡한 이벤트 그래프를 포함한 BP）
• C++ 모듈 수와 그중 Actor/Component 생명주기에 직접 의존하는 비율
• 서드파티 플러그인 수와 각 공급사의 UE6 호환 약속 여부
• “핫 패스” 로직: 매 프레임 Tick하는 오브젝트 규모（백? 천? 만?）

2단계：에셋 유형별 마이그레이션 난이도를 매깁니다.

에셋 유형	이전 난이도	설명
순수 데이터 BP / DataAsset	낮음	대부분 설정이므로 일괄 변환 또는 유지 가능
글루형 BP（C++ 호출, UI 처리）	중하	구조가 단순해 도구 기반 이전에 적합
복잡한 이벤트 그래프 BP（분기·시퀀스 다수）	중상	로직 밀도가 높아 변환 결과를 사람이 검토해야 함
Actor 생명주기에 깊게 의존하는 C++	높음	Entity/Component + Verse 모델로 재작성 필요
서드파티 비공개 소스 플러그인	통제 불가	공급사의 업데이트 여부에 달렸으므로 사전 확인 필요

3단계：“전환 가능 기간”을 계산합니다. “정식 버전 시점（약 2029년 중반）− 프로젝트의 다음 메이저 버전 일정”으로 여유 기간을 추산하세요. 기간이 길수록 AI 마이그레이션 도구가 성숙한 뒤 움직일 수 있습니다. 짧을수록 지금부터 새 프로젝트에서 연습하고 팀에 Verse/Scene Graph 경험을 쌓아야 합니다.

부록: Verse, Blueprint, C++는 대체 어떻게 역할을 나눌까요?

UE6 이후에는 “세 가지 로직 작성 방식의 공존（전환기）→ 두 가지 중심（최종 상태）” 구도가 나타날 것입니다. 미리 역할을 정리하면 불필요한 불안과 잘못된 투자를 피할 수 있습니다.

항목	C++	Blueprint	Verse
위치	저수준/성능/엔진 확장	시각적 로직（결국 지원 중단）	게임 로직의 일급 시민
동시성 모델	수동 멀티스레딩, 높은 진입 장벽	싱글 스레드 노드 그래프	네이티브 동시성, 대규모 멀티플레이 지향
UE6에서의 미래	유지, 여전히 저수준 기반	단계적 지원 중단, 변환 도구 제공	Epic 주력, Scene Graph와 결합
적합한 사용자	엔진/시스템 프로그래머	디자이너, 빠른 프로토타이핑	게임 로직 프로그래머, 새 프로젝트
AI 친화도	중간	낮음（그래프 구조는 학습이 어려움）	높음（텍스트, 강타입）

주목할 신호가 하나 있습니다. Blueprint는 그래프 구조라 대규모 언어 모델이 효율적으로 학습하고 생성하기 어렵습니다. 반면 Verse는 텍스트 기반의 강타입 언어라 AI 보조 프로그래밍에 자연스럽게 맞습니다. 이는 Epic이 “UE6에서 AI가 핵심 역할을 맡게 합니다”라는 방향과 매우 일관됩니다——어떤 의미에서는 Blueprint를 지원 중단하고 Verse를 주력으로 삼는 일 자체가 AI 시대의 개발 흐름을 준비하는 것일 수 있습니다. 이는 합리적인 추측이며, Epic의 장기 의도를 판단할 때 참고하시기 바랍니다.

부록: UE6에 관한 흔한 오해 7가지（하나씩 바로잡겠습니다）

오해①：“UE6 업그레이드는 5.9처럼 매끄럽고 위험이 없습니다.” 바로잡기: Epic은 UE5→UE6가 UE4→UE5보다 어렵다고 공식적으로 밝혔습니다. 기반 호환은 사실이지만, Verse/Scene Graph 패러다임 이전에는 실제 비용이 듭니다.

오해②：“Actor는 영원히 제거되지 않습니다.” 바로잡기: Epic의 약속은 “프레임워크가 성숙하면 Actor/Blueprint를 단계적으로 지원 중단하고 변환 도구를 제공합니다”라는 것입니다. 연착륙이지 영구적인 이중 노선이 아닙니다.

오해③：“Verse는 새로운 C++이고 C++로 컴파일됩니다.” 바로잡기: Verse는 Epic이 만든 동시성 함수형 언어이며 VerseVM 바이트코드 가상 머신에서 실행됩니다. C++ 및 Blueprint VM과 독립된 체계입니다.

오해④：“Entity Framework는 선택적 최적화 플러그인일 뿐입니다.” 바로잡기: Scene Graph의 엔진 구현이며 Epic이 차세대 게임 프레임워크이자 Actor의 후계자로 삼은 체계입니다. 소수 취향의 선택지가 아닙니다.

오해⑤：“AI가 Blueprint를 Verse로 한 번에 바꿔 줍니다.” 바로잡기: Epic은 “변환 도구”를 약속했지만 “AI 원클릭 이전”은 아직 업계의 추측입니다. 현실적으로는 “도구 생성 + 사람의 검토”가 더 가능성이 높습니다.

오해⑥：“지금 출시 프로젝트를 UE6로 올려야 합니다.” 바로잡기: UE6 EA는 2027년 말, 정식 버전은 약 2029년 중반입니다. 2028년 중반 이전 출시 프로젝트는 UE5.8을 기준으로 결정해야 합니다.

오해⑦：“UE5는 계속 업데이트됩니다.” 바로잡기: UE5.8이 계획된 마지막 메이저 버전이며, 이후에는 버그 수정만 이뤄집니다. 새 엔진 기능은 UE6에 들어갑니다.

맺음말

UE6는 UE5를 무너뜨리고 다시 짓는 엔진이 아닙니다. 소스 코드를 보면 오히려 한 번의 “통합”에 가깝습니다——UE5와 UEFN의 기반을 통합하고, Actor와 Entity의 추상 계층을 통합한 뒤 최종적으로 Scene Graph로 대체하며, 인간 개발과 AI 개발의 도구 체인을 통합합니다. Epic은 전부 갈아엎을 생각이 없습니다. 자사의 Fortnite도 같은 체계 위에서 실행됩니다.

하지만 “통합”이 “무통”을 뜻하지는 않습니다. Epic 자신도 마이그레이션은 더 어렵고 기존 패러다임은 지원 중단될 것이라고 말했습니다. 그러므로 게임 개발자가 UE6에 대해 답해야 할 진짜 질문은 흑백논리식 “업그레이드할 것인가요?”가 아니라, 층위를 나눈 세 가지입니다.

• 어떤 새 기능이 지금 당장, 낮은 비용으로 도움을 줄 수 있을까요? —— MCP + GenAI 도구 체인입니다. 일부는 UE5.8에서도 쓸 수 있습니다.
• 피할 수 없어서 미리 계획해야 하는 장기 마이그레이션은 무엇일까요? —— Verse + Scene Graph입니다. UEFN에서 일찍 연습할수록 주도권을 얻습니다.
• 현재 프로젝트는 어느 전환 가능 기간에 놓여 있을까요? —— 위의 자가 진단 프레임워크로 계산한 뒤, “우선 안정적으로 유지할지” 아니면 “훈련을 시작할지” 결정하시면 됩니다.

UE6 소스 코드는 GitHub의 ue6-main 브랜치에 공개돼 있고, Epic 공식 로드맵 《The Road to UE 6》는 unrealengine.com에서 볼 수 있습니다. 앞으로도 UE6의 기술 세부 사항을 계속 추적하겠습니다. Verse와 Scene Graph의 데스크톱 도구 체인이 공개되는 즉시 깊이 있게 분석하겠습니다. 팔로우해 두시면 놓치지 않습니다.