세션 개요
게임의 경쟁 상대가 게임이 아니게 된 다음, 엔진은 무엇을 해야 하는가
시장 진단 → 에픽의 대응(열린 생태계) → 그 대응을 떠받치는 기술(UE6) 순서로 이어지는 키노트입니다.
이 키노트는 기능 소개가 아니라 하나의 논증입니다. 전제는 “게임은 이제 게임하고만 경쟁하지 않는다”이고, 결론은 “그래서 답은 닫힌 플랫폼이 아니라 열린 생태계다”이며, UE6는 그 결론을 실행 가능하게 만드는 기술 계획으로 제시됩니다. 세 단계가 하나로 이어져 있어서, 중간의 어느 한 단계만 떼어 보면 왜 엔진 로드맵에 포트나이트가 등장하는지 이해되지 않습니다.
진단 — 대형 게임이 소셜 플랫폼이 됐다
유저의 시간과 돈이 한 공간에 묶이면서, 신작이 진입할 수 있는 틈이 좁아졌다는 문제 제기.
처방 — 개발자↔플랫폼이 아니라 개발자↔플레이어
에셋·콘텐츠·경제를 게임 경계 너머로 옮길 수 있게 열어, 각 게임이 서로의 유입 경로가 되게 하자는 구상.
실행 — UE5와 UEFN을 UE6 하나로 합친다
Verse 기반 프로그래밍 모델, 개방 표준 기반 상호운용, MCP 기반 제작 파이프라인 세 축.
이 글이 원문 노트에 더한 것
발표는 결론을 빠르게 던지고 지나갑니다. 이 글에서는 각 결론마다 그 주장이 성립하려면 독자가 먼저 알아야 하는 것을 “기초 다지기” 블록으로, 발표 표현을 그대로 믿으면 오해가 생기는 지점을 “짚어둘 점” 블록으로 따로 뽑았습니다. 수치와 일정은 가능한 한 에픽이 직접 공개한 문서와 대조했고, 대조되지 않은 것은 각주로 표시했습니다.
세 줄 요약
- 게임의 경쟁 상대는 더 이상 게임만이 아닙니다. 다른 엔터테인먼트 형식과 소셜 플랫폼 전부가 같은 시간을 놓고 경쟁하며, 예전의 제작 공식만으로는 답이 되지 않는다는 것이 발표의 출발점입니다.
- 에픽의 대응은 열린 생태계입니다. “개발자 ↔ 플랫폼”이 아니라 “개발자 ↔ 플레이어”가 주도적으로 만들어가는 구조를 지향한다고 정리했습니다.
- 그 구조를 가능하게 하는 기술 기반이 UE6에 담깁니다. 에픽뿐 아니라 대형 IP 보유사와 유명 개발사들이 이 개념에 참여 중이며, 한국 개발사들의 참여도 함께 요청했습니다.
1부
시장 진단 — 위기와 기회가 공존하는 격변기
발표가 든 세 가지 불안과, 그 불안의 공통 원인으로 지목한 한 가지 변화.
발표는 개발자들이 느끼는 불안을 세 갈래로 나눴습니다. 셋 다 체감의 언어로 제시됐고, 공식 통계가 함께 붙지는 않았습니다.[1]
감(感)의 상실
20~30년간 게임을 만들어온 세대에게는 “내가 좋아하는 걸 만들면 게이머도 좋아한다”는 공식이 통했지만, 지금은 젊은 게이머의 취향을 지표로 공부는 해도 체감하지 못한다는 진단입니다.
트렌드 가속
변화의 템포가 갈수록 빨라져, 기획 당시의 전제가 출시 시점에 남아 있지 않습니다.
비용 ↑ / 성공률 ↓
개발 비용은 계속 오르는데 신작의 성공 확률은 전 세계적으로 낮아지고 있다는, 이 발표에서 가장 자주 반복된 문장입니다.
원인 — 대형 게임의 소셜 플랫폼화
에픽의 진단은 한 문장으로 압축됩니다. 대형 게임들이 소셜 플랫폼으로 진화하면서 파이를 계속 늘려가고 있고, 그 결과 신작이 진입할 수 있는 시장이 급격히 좁아지고 있다는 것입니다.
기초 다지기
“소셜 플랫폼화”가 정확히 무엇을 뜻하는가
여기서 말하는 소셜 플랫폼화는 게임에 채팅이 붙는다는 뜻이 아닙니다. 세 가지 성질이 동시에 생긴 상태를 가리킵니다. 첫째, 친구 관계가 게임 안에 산다는 것. 로그인 이유가 “이 게임이 재밌어서”에서 “여기 친구가 있어서”로 바뀝니다. 둘째, 구매한 것이 계정에 쌓인다는 것. 코스메틱·배틀패스·진척도가 누적될수록 이탈 비용이 커집니다. 셋째, 콘텐츠 공급이 개발사 한 곳에서 나오지 않는다는 것. 안에서 다른 사람이 만든 것을 계속 소비할 수 있으면 콘텐츠 고갈로 인한 자연 이탈이 사라집니다.
이 세 가지가 겹치면 게임은 “클리어하고 떠나는 상품”이 아니라 떠날 이유가 계속 줄어드는 거주지가 됩니다. 신작이 마주하는 벽이 “우리 게임이 저 게임보다 재미있는가”가 아니라 “유저가 저기 쌓아둔 관계와 구매를 버리고 올 만한가”로 바뀌는 것이 문제의 핵심입니다.
차세대 게이머의 소비 방식
- 게임을 “게임”으로만 즐기지 않습니다. 큰 놀이터 같은 공간에서 내가 관심 있는 것만 골라 즐기면서도, 친구들과 계속 소통하며 그 세계에 남아 있는 경향이 강해졌다는 설명입니다.
- 비유하자면 영상은 어떤 플랫폼, 쇼핑은 어떤 플랫폼, SNS는 어떤 플랫폼 — 이렇게 나눠 쓰는 것과 거의 같은 구조라는 것입니다.
- 한정된 리소스(내 시간, 내 돈)를 두고 “어떤 게 더 편리하고, 더 재미있고, 결과적으로 더 가치 있는가”를 계산해 옮겨 다닙니다.
결론적 영향 — UA 코스트와 경쟁 상대의 재정의
이전의 경쟁 구도
같은 장르, 같은 플랫폼
- 경쟁 상대 = 비슷한 시기에 나오는 같은 장르 게임
- 유저 획득 = 출시 시점 마케팅으로 한 번에 확보
- 이탈한 유저는 다음 신작에서 다시 만날 수 있음
발표가 말한 지금의 구도
시간을 놓고 벌이는 경쟁
- 경쟁 상대 = 숏폼, 스트리밍, SNS 등 다른 엔터테인먼트 전부
- 유저 획득 = 이미 다른 곳에 정착한 유저를 끌어내야 함
- 한 번 떠난 유저를 다시 불러들이는 UA 코스트가 과거보다 훨씬 높아짐[2]
같은 “재미”를 두고 겨루던 싸움이 “가처분 시간”을 두고 겨루는 싸움으로 바뀌었다는 것이 1부의 결론입니다.
기초 다지기
UA 코스트가 왜 이 논증의 핵심 고리인가
UA(User Acquisition) 코스트는 유저 한 명을 우리 게임에 들이는 데 드는 평균 비용입니다. 광고비 총액을 신규 설치 수로 나눈 값이라고 보면 됩니다. 이 수치가 중요한 이유는, 게임의 손익이 사실상 “유저 한 명이 평생 쓰는 돈(LTV)이 UA 코스트보다 큰가”라는 한 줄 부등식으로 결정되기 때문입니다.
앞서 말한 소셜 플랫폼화는 이 부등식의 양쪽을 동시에 불리하게 만듭니다. 경쟁 입찰에 참여하는 광고주가 늘어 UA 코스트는 오르고, 유저가 기존 플랫폼에 지출을 이미 묶어두고 있어 신작에서의 LTV는 떨어집니다. 그래서 발표가 “유통 채널을 다시 짜라”로 넘어가는 것입니다 — 광고로 유저를 사 오는 대신, 유저가 이미 모여 있는 곳 안에 콘텐츠를 놓는 것이 2부와 3부의 제안입니다.
2부
에픽의 대응 — 열린 생태계(Open Ecosystem)
같은 문제를 로블록스와 포트나이트가 정반대 방향으로 풀고 있다는 것이 발표의 대비 구도입니다.
1부의 진단을 받아들이면 선택지는 둘입니다. 우리도 닫힌 플랫폼이 된다, 혹은 플랫폼의 경계를 열어 서로의 유입 경로가 된다. 발표는 후자를 택했다고 선언하며, 그 대비를 로블록스와 포트나이트의 방향 차이로 설명했습니다.
포트나이트
발표가 제시한 전환 중인 쪽
- 방향성: 초기엔 닫힌 구조 → 열린 시스템으로 전환 중
- 통제를 점진적으로 개방
- 구매한 값어치를 게임 경계 너머로 옮기는 것을 목표로 함
발표 스스로도 포트나이트가 “아직 닫힌 생태계”임을 인정합니다. 대비는 현재 상태가 아니라 이동 방향에 대한 것입니다.
핵심 개념 — 에셋 상호운용
열린 생태계라는 추상어에 발표가 붙인 구체적인 정의는 하나입니다. 내가 구매한 옷(코스메틱)을 어디서든 활용할 수 있는 구조.
- 포트나이트는 다수의 게임·IP와 콜라보해 에셋을 확보하고, 그 에셋을 모든 포트나이트 모드(+ 유즈맵)에서 활용 가능하도록 설계하고 있습니다.
- 예를 들어 콜라보로 받은 캐릭터 에셋을 UGC 맵을 포함한 전 영역에서 사용할 수 있게 하는 방향입니다.
더 깊이
에픽이 코스메틱을 첫 번째 증명 대상으로 고른 이유
UE6 로드맵 글은 이 선택의 근거를 명시합니다. 포트나이트 코스메틱 시스템을 개방된 UE6 모듈로 옮기는 것이 상호운용의 첫 실증 대상이고, 그 결과로 개발사는 플레이어가 이미 보유한 포트나이트 아웃핏을 자기 게임에서 쓰게 하거나, 반대로 자기 게임의 아웃핏을 포트나이트 안에서 동작하게 만들 수 있게 하겠다는 것입니다.
왜 하필 옷인가. 에픽의 설명은 두 가지입니다. 하나는 충분히 복잡해서 의미 있는 존재 증명이 된다는 것 — 코스메틱은 소유권, 권리 관계, 렌더링, 애니메이션 리타기팅이 전부 얽힌 시스템입니다. 다른 하나는 플레이어에게 즉시 이득이 된다는 것입니다. 그래서 이 작업의 목표는 “포트나이트 옷을 다른 데서 입기”가 아니라, 로직과 기능을 가진 스마트 에셋이 게임 경계를 넘는 공용 경제의 첫 단추로 제시됩니다.
짚어둘 점
“상호운용”은 파일 포맷 이야기가 아닙니다
에셋을 옮긴다는 말을 들으면 보통 메시와 텍스처를 내보내는 장면을 떠올리게 됩니다. 그건 이미 glTF나 USD로 되는 일입니다. 여기서 어려운 부분은 모양이 아니라 나머지 전부입니다 — 이 플레이어가 그 아이템을 정말 보유하고 있는지 확인하는 권리 검증, 다른 게임의 스켈레톤에 붙일 때의 리타기팅, 게임마다 다른 성능 예산, 그리고 IP 보유사가 허용한 사용 범위입니다.
에픽의 계획도 정확히 그 지점을 겨냥합니다. 기존 표준(glTF, USD)이 충분한 곳에서는 그것을 엔진의 1급 포맷으로 채택하고, 표준이 없는 영역에서는 언리얼 자체 시스템을 Verse API와 에셋 규약, 문서를 갖춘 공개 명세로 개방하겠다는 것입니다. 즉 상호운용의 실체는 파일 포맷이 아니라 공개 명세로 쓰인 규약이고, 그래서 이 작업이 엔진 로드맵의 한 축이 되는 것입니다.
개발자 지원 스택
| 영역 | 제공 | 무엇을 대신 해주는가 |
|---|---|---|
| 개발 | 언리얼 엔진, Fab (에셋 마켓) | 제작 도구와 에셋 조달 |
| 운영 | EOS (Epic Online Services) | 로그인·친구·매치메이킹·업적 등 온라인 백엔드 |
| 배포 | 에픽게임즈 스토어, 포트나이트 | 유통 채널과 노출 지면 |
세 층이 각각 개발·운영·배포를 덮도록 배치돼 있다는 것이 이 표의 요지입니다.
발표를 들으며 남은 의문
방향성 자체는 에픽게임즈 스토어와 포트나이트를 묶어 하나의 플랫폼에서 모든 것이 해결되는 체계를 만들려는 의도로도 읽힙니다. “열린 생태계”라는 표현과 별개로, 실질적으로는 에픽 진영 안에서 자족적인 구조를 지향하는 측면이 있어 보입니다. 이 긴장은 이 글 뒤쪽의 남은 질문 절에서 다시 다룹니다.
3부
콘텐츠 배포 두 갈래 — 스토어와 포트나이트 안쪽
에픽이 제시한 배포 경로는 ① 에픽게임즈 스토어, ② 포트나이트 안으로의 배포 두 가지입니다.
발표가 그린 유통 경로
같은 게임의 두 번째 경로
에픽게임즈 스토어 — 새 런처
새 런처가 공개됐습니다. 훨씬 빠릿하고, 가볍고, 편하며, 디자인도 개선됐고 기능도 계속 추가되는 중이라는 소개였습니다. 전 세계 게이머에게 배포할 때 개발자에게 가장 유리한 조건을 제공하는 플랫폼이라는 점을 함께 강조했습니다.[4]
사진 · 자료
다시 만든 에픽게임즈 스토어 런처
기초 다지기
“개발자에게 가장 유리한 조건”의 실제 내용
발표는 조건을 열거하지 않고 넘어갔지만, 에픽이 공개한 배포 페이지에는 숫자가 명시돼 있습니다. 제품별·연도별 첫 100만 달러 순매출까지는 수익 배분이 100%/0%이고, 그 이상부터 표준인 88%/12%가 적용됩니다. 100만 달러 기준선은 매년 1월 1일에 제품별로 초기화됩니다. 언리얼 엔진으로 만든 게임이 에픽 결제 시스템을 통해 스토어에서 판매될 경우 엔진 로열티가 면제된다는 조항도 함께 걸려 있습니다.
별도로 Epic First Run이라는 독점 프로그램이 있어, 참여하면 첫 6개월간 금액과 무관하게 순매출 100%를 가져갑니다. 이 조건들이 경쟁 스토어보다 유리한지는 비교 판단이지만, 조건의 내용 자체는 공개돼 있어 확인 가능합니다.
포트나이트 — 디스커버(Discover) 전면 개편
UGC 게임을 만들었을 때 노출되는 화면이 대폭 바뀝니다. 개편의 항목은 넷입니다.
영상 미리보기
정지 이미지 썸네일만이 아니라 미리보기 영상이 지면 전반에 들어갑니다.
OTT식 개인화 UI
개별 타일이 개인화되어 표시되는, 스트리밍 서비스에서 익숙한 형태입니다.
소셜 지표 노출
실제로 몇 명이 어떻게 얼마나 즐기고 있는지가 타일 위에 함께 표시됩니다.
유행 콘텐츠
지금 무엇이 돌고 있는지를 지면에서 바로 확인할 수 있게 됩니다.
사진 · 자료
개편된 포트나이트 디스커버
가장 큰 변화
기존에는 포트나이트를 플레이하다 나왔을 때 보이던 화면이 디스커버였지만, 앞으로는 포트나이트에 접속하면 처음 만나는 기본 화면이 디스커버가 됩니다. 에픽도 공식 정리에서 “디스커버가 로비를 대체해 플레이어가 포트나이트를 켰을 때 가장 먼저 보는 화면이 된다”고 같은 내용을 적었습니다. UEFN으로 UGC 콘텐츠를 만들면 노출 기회 자체가 구조적으로 늘어난다는 뜻입니다.
짚어둘 점
노출 총량이 늘어난다고 내 몫이 늘어나지는 않습니다
첫 화면이 디스커버가 되면 지면의 총 임프레션은 늘어날 가능성이 큽니다. 그런데 그 지면이 개인화 추천으로 채워진다는 것이 같은 문장의 나머지 절반입니다. 개인화된 지면에서는 모두에게 같은 목록이 보이지 않으므로, 늘어난 노출은 균등하게 배분되지 않고 추천 엔진이 판단한 적합도에 따라 배분됩니다.
그래서 이 변화의 실질적 의미는 “노출이 늘었다”가 아니라 “노출이 알고리즘 변수의 함수가 됐다”입니다. 유튜브 알고리즘을 타는 것과 같은 구조가 되므로, 포트나이트 내 검색·추천 엔진에 잘 노출되는 것(디스커버러빌리티)이 새로운 핵심 역량이 됩니다. 에픽이 공개한 수치도 이 방향을 가리킵니다 — 최근 디스커버 변경 이후 새로 게시된 섬이 플레이어 100명과 임프레션 1만 회에 도달하는 비율이 이전의 거의 두 배가 됐다는 것입니다.
4부
UEFN — 개발자 입장에서의 실익과 한계
“포트나이트 안으로 배포한다”가 실제로 무엇을 아껴주는지에 대한 정리입니다.
발표가 UEFN을 설명하는 방식은 기능 나열이 아니라 비용 제거 목록입니다. 무엇을 안 해도 되는지를 먼저 말하고, 그 대가로 무엇을 포기하는지를 마지막에 붙입니다.
인프라 부담 제로
서버 확장이나 인프라 설정이 전혀 필요 없습니다. 자신의 플랫폼 안에 등록만 해두면 접속 가능하며, 클라이언트에만 집중하면 됩니다.
원 빌드, 전 플랫폼
한 번 빌드하면 PC / 모바일 / 콘솔 어디서든 바로 사용할 수 있습니다.
MAU 확보가 쉽다
하나의 포트나이트 게임 안에서 운영되기 때문입니다. 발표에서는 7명이 만든 게임이 450만 MAU를 확보한 사례가 언급됐습니다.
적합한 케이스
수익을 내면서도 자체 에셋 없이 비교적 간단하게 만들고 싶다면 포트나이트 에디터가 좋은 선택지라는 정리였습니다.
발표가 밝힌 한계
포트나이트 에디터는 아직 닫힌 생태계입니다. 점점 개방하려 노력 중이라는 단서가 붙었지만, 현재 상태는 닫혀 있다는 것을 발표 스스로 인정했습니다. 7인 팀 450만 MAU 사례의 구체적 수치는 이 문서 기준으로 에픽의 공식 자료에서 확인되지 않았습니다.[5]
기초 다지기
“인프라 부담 제로”가 실제로 지우는 비용의 목록
멀티플레이 게임을 직접 서비스하면 클라이언트 코드 바깥에 최소한 이만큼이 따라옵니다 — 전용 서버 이미지 빌드와 배포 파이프라인, 리전별 서버 프로비저닝, 동접에 따른 오토스케일링, 매치메이킹 큐, 계정·인증, 친구 관계, 세션 관리, 안티치트, 로그 수집과 장애 대응, 그리고 이 전부에 붙는 24시간 운영 인력입니다.
UEFN의 제안은 이 목록 전체를 포트나이트가 이미 운영 중인 인프라에 얹는 것입니다. 그래서 “클라이언트에만 집중하면 된다”는 말은 과장이 아니라 책임 경계선의 위치를 바꾸는 것에 대한 서술입니다. 대신 그 경계선 바깥은 전부 플랫폼의 규칙을 따르게 되고, 그 대가가 위에서 말한 “아직 닫힌 생태계”입니다.
이터레이션 시간 — UEFN이 UE6에 먼저 기여하는 부분
에픽이 공개한 정리에 따르면 UEFN 출시 이후 개발자에게 지급된 누적 금액은 10억 달러를 넘었고, 같은 해에 이터레이션 시간을 평균 40% 단축했습니다. 아래 슬라이드의 수치는 이 개선을 실제 프로젝트 기준으로 측정한 범위입니다.
사진 · 자료
변경 사항 반영 시간 40~70% 단축
UEFN 쪽에서 검증된 파이프라인 개선이 그대로 UE6로 수렴한다는 것이 이 절과 다음 절을 잇는 고리입니다.
5부
언리얼 엔진 6 — 정체성과 일정
“UE6 = UE5 + UEFN”이라는 한 줄이 무엇을 합치겠다는 뜻인지 풀어봅니다.
UE6의 최종 목표는 UE5 + UEFN입니다. UE5와 포트나이트(UEFN)의 좋은 점만 추출해 합치는 방향이며, 여기에 열린 생태계 개념이 결합됩니다.
사진 · 자료
UE6를 한 장으로 설명한 등식
현재 UEFN에는 이미 UE6 시스템이 도입되어 있습니다. 이 문장이 발표에서 가장 실무적으로 중요한 대목입니다 — UE6의 새 개념을 미리 만져보고 싶다면 기다릴 필요 없이 지금 UEFN을 열면 된다는 뜻이기 때문입니다.
기초 다지기
에픽이 공식화한 UE6의 세 축
발표의 “좋은 점만 합친다”는 표현은 압축이 심합니다. 에픽이 공개한 UE6 로드맵 글은 같은 내용을 세 개의 이니셔티브로 명시합니다.
- 프로그래밍 모델을 Verse로 옮긴다. Verse는 C++를 트랜잭션화하며, 개발 접근성을 높이는 동시에 수천 명이 함께 기여하는 지속적·대규모 라이브 경험을 만들 수 있게 하는 것이 목적입니다.
- 콘텐츠·코드·경제를 게임과 생태계, 엔진 사이에서 이식 가능하고 상호운용 가능하게 만든다. 수단은 개방 표준입니다.
- 제작 파이프라인 기능을 생산성 배수로 만든다. 여기에 Claude, Gemini 등과 연동되는 MCP가 포함됩니다.
발표에서 “열린 생태계”라고 부른 것이 2번, “AI 대응”이라고 부른 것이 3번, 그리고 뒤에 나올 씬 그래프·Verse·트랜잭션 이야기가 전부 1번입니다. 세 축을 알고 나면 나머지 항목들이 어디에 속하는지 바로 정리됩니다.
로드맵과 라이선스
도해
UE5에서 UE6까지의 시간 축
UE5
UEFN
UE6
시간 →
짚어둘 점
“Actor와 Blueprint는 어떻게 되는가”에 대한 공식 답
UE6가 새 게임플레이 프레임워크로 간다는 말을 들으면 기존 프로젝트가 끊긴다고 읽기 쉽습니다. 에픽의 공식 서술은 반대입니다. 전환 철학은 “기존 프로젝트를 데려가는 것이지 단절을 강제하는 것이 아니다”이고, 그 보장을 위해 Actor와 Blueprint는 UE6 초기 버전에 그대로 포함됩니다. 새 프레임워크가 충분히 성숙한 뒤에야 deprecate되며, 그때는 프로젝트를 옮기는 변환 도구가 제공된다고 명시돼 있습니다.
또 하나 실무적으로 유용한 사실 — UE6 개발 스트림은 이미 공개돼 있습니다. 다만 에픽은 이 스트림이 알파가 아니며 방향을 투명하게 보여주기 위한 것이라고 못박았고, Verse 언어 구현 역시 공개는 됐지만 현시점에서 일반 채택을 의도한 것이 아니라고 했습니다.
6부
UE6 내부 — 렌더링, 씬 그래프, Verse, Lore, 트랜잭션
발표가 빠르게 훑고 지나간 다섯 항목을, 각각 무엇을 바꾸는 변화인지 기준으로 다시 정리했습니다.
성능 / 렌더링
- 셰이더 컴파일러 개선 — 중복 코드 컴파일을 방지하고 변경점만 재컴파일하는 방향입니다. 발표에서는 컴파일 시간 기준 약 68% 개선이라는 수치가 제시됐습니다.[8]
- 전면 Mesh 기반화 — 더 높은 품질을 더 낮은 비용으로 구현할 수 있도록 바꾼다는 설명이었습니다.[9]
- 애니메이션 — 단순히 사람이 등장하는 영상만으로 애니메이션을 구현하기 쉬워진다는 언급이 있었습니다.
기초 다지기
셰이더 컴파일이 왜 이 규모의 개선 대상이 되는가
머티리얼 하나는 GPU에서 실행될 코드 한 벌이 아닙니다. 같은 머티리얼이라도 어떤 정점 팩토리에 붙는지(스태틱 메시 / 스켈레탈 메시 / Nanite / 인스턴싱), 어떤 패스에서 그려지는지(뎁스, 베이스, 섀도우, 벨로시티), 어떤 플랫폼과 품질 설정인지에 따라 조합이 갈리고, 그 조합 하나하나가 별도의 셰이더 퍼뮤테이션으로 컴파일됩니다. 프로젝트가 커지면 이 조합 수가 수십만 단위로 불어나고, 그래서 셰이더 컴파일이 대형 팀에서 체감상 가장 긴 대기 시간이 됩니다.
개선의 방향이 “중복 제거”인 것도 이 구조 때문입니다. 서로 다른 퍼뮤테이션이 결국 같은 코드로 귀결되는 경우가 많으므로, 중복을 걸러내면 실제로 컴파일해야 할 항목 자체가 줄어듭니다. 에픽의 공식 정리도 같은 설명을 하되 결과를 다른 단위로 적었습니다 — 셰이더 컴파일 최적화와 중복 제거 개선으로 포트나이트의 셰이더 개수를 68% 줄였다는 것입니다.
아키텍처 — 씬 그래프(Scene Graph)
- 언리얼의 모든 객체를 중앙에서 관리하는 씬 그래프가 새로 생깁니다.
- Actor → Entity로의 전환이 함께 언급됐습니다.[10]
- 목표는 개발자가 API를 따라 오브젝트를 쉽게 만들고 쉽게 공유할 수 있게 하는 것입니다.
- 다만 기존 구조와 매우 유사한 형태로 보인다는 것이 현장에서의 인상이었습니다.
도해
Actor 계층에서 Entity + Component로
Actor — 상속으로 기능을 얻는다
Pawn을 상속하고 Character를 상속하는 식으로 계층을 타고 내려가며 기능이 붙습니다. 계층 중간을 다른 프로젝트로 옮기기 어렵습니다.
Entity — 그 자체로는 비어 있다
씬 그래프의 엔티티는 식별자와 트랜스폼에 가깝고, 기능은 붙는 컴포넌트가 결정합니다.
Component — 데이터와 동작을 붙였다 뗀다
UEFN 문서 기준으로 컴포넌트는 Verse로 직접 정의할 수 있으며, 애니메이션·아이템·어빌리티 같은 코어 엔진 시스템이 Verse에서 다룰 수 있는 컴포넌트로 내려오고 있습니다.
Prefab — 조립한 결과를 통째로 재사용한다
엔티티와 컴포넌트의 조합을 프리팹으로 묶어 프로젝트 간에 재사용하는 것이 문서가 설명하는 사용 방식입니다.
더 깊이
“기존 구조와 비슷해 보인다”는 인상이 맞기도 하고 틀리기도 한 이유
언리얼에는 원래도 UActorComponent가 있었으니 엔티티-컴포넌트 구성이 새로울 것 없어 보이는 것은 당연합니다. 차이는 무엇이 1급 시민인가에 있습니다. 기존 구조에서 컴포넌트는 Actor에 붙는 부속이고, 게임플레이의 뼈대는 여전히 Actor 상속 계층이 쥐고 있습니다. 씬 그래프에서는 그 관계가 뒤집혀, 엔티티가 컨테이너가 되고 기능은 전부 컴포넌트 쪽에 있습니다.
그리고 이 차이가 실질적으로 중요해지는 이유는 앞의 2부와 연결됩니다. 상호운용을 하려면 옮길 수 있는 최소 단위가 있어야 하는데, 상속 계층은 그 단위가 되지 못합니다. 컴포넌트는 됩니다. 씬 그래프는 렌더링 개선이 아니라 “이식 가능한 게임플레이 단위”를 만들기 위한 구조 변경으로 읽는 것이 맞습니다.
언어 — Verse와 C++의 역할 분담
앞으로도 Verse를 씁니다.
- 게임 콘텐츠는 Verse, 엔진은 C++로 개발 영역을 분리할 예정입니다.
- Verse는 최대한 쉽게 만드는 것이 목표라고 했습니다.
기초 다지기
Verse가 “C++를 트랜잭션화한다”는 말의 뜻
에픽의 공식 설명에서 Verse의 핵심은 문법이 아니라 소프트웨어 트랜잭셔널 메모리 모델입니다. Verse의 모든 함수는 원자적 트랜잭션의 일부로 실행되며, 필요하면 롤백하고 다시 실행할 수 있습니다. 그리고 이 트랜잭션 의미론은 Verse에서 호출되는 C++ 코드에까지 확장됩니다 — 현재는 Verse가 단일 스레드에서 돌고, 커스텀 LLVM 컴파일러로 빌드된 C++ 코드를 호출하면서 그 C++를 자동으로 트랜잭션화하는 방식입니다.
이 설계가 왜 필요한지는 데이터베이스를 떠올리면 이해가 빠릅니다. 트랜잭션이 있으면 “중간까지만 적용된 상태”가 존재하지 않습니다. 수천 명이 동시에 기여하는 지속형 월드에서 가장 다루기 어려운 것이 바로 그 중간 상태이고, Verse는 그 문제를 언어 런타임 차원에서 없애겠다는 접근입니다.
버전 관리 — Lore
- 자체 버전 관리 시스템 Lore가 소개됐습니다.[11]
- 트리 구조로 표현해 변경점만 파악·저장합니다.
- 상위 변경점만 따로 빌드하는 것에 대한 부담이 크게 줄어들 것으로 기대됩니다.
사진 · 자료
Lore — 차세대 버전 관리 시스템
기초 다지기
게임 프로젝트에서 Git이 잘 안 되는 이유, 그리고 Lore의 답
Git은 텍스트 diff를 전제로 최적화돼 있습니다. 2GB짜리 씬 파일에서 한 군데를 고치면 Git은 그 파일을 통째로 새 오브젝트로 저장하고, 클론할 때는 전체 히스토리를 내려받습니다. 반대로 Perforce 계열은 대용량 바이너리에 강하지만 코드 워크플로가 무겁습니다. 게임 프로젝트는 그 둘이 한 저장소에 섞여 있는 거의 유일한 분야입니다.
Lore 문서가 설명하는 해법은 세 가지입니다. 첫째, 모든 데이터를 구분 없는 바이트 스트림으로 취급합니다 — 텍스트든 바이너리든 같은 프리미티브를 통과합니다. 둘째, 임계값을 넘는 파일은 콘텐츠 정의 청크로 쪼갭니다. 그래서 수 기가바이트 파일 안의 한 군데를 고치면 바뀐 청크만 다시 올라가고, 임의의 바이트 구간을 파일 전체를 실체화하지 않고 읽을 수 있습니다. 셋째, 클라이언트는 실제로 쓰는 데이터만 보유하고 나머지는 원격에서 지연 페치합니다. 발표의 “변경점만 파악·저장”은 이 설계를 한 줄로 줄인 표현입니다.
트랜잭션 구조 — 롤백과 마이그레이션
- 원자적 트랜잭션(Atomic Transaction) 구조를 활용해 실패 시 롤백이 매우 쉬운 구조가 됩니다.
- 분산 트랜잭션 시스템을 통해 서버에 있는 객체의 롤백과 마이그레이션이 훨씬 쉬워집니다.
도해
객체가 다른 서버에 있을 때 UE6가 하려는 일
단일 서버처럼 코드를 쓴다
네트워킹 코드를 곳곳에 심을 필요 없이 평범한 Verse 코드로 작성합니다.
필요한 객체가 이 서버에 없다
클러스터의 다른 서버가 그 객체를 들고 있는 상황입니다.
런타임이 현재 트랜잭션을 롤백한다
중간 상태가 남지 않으므로 되돌리는 데 특별한 정리 코드가 필요 없습니다.
객체를 적절한 서버로 마이그레이션한다
객체 이동 자체를 런타임이 수행합니다.
트랜잭션을 다시 실행한다
이번에는 객체가 있는 상태에서 같은 코드가 그대로 성공합니다.
더 깊이
세이브 데이터가 전역 맵 하나가 되는 이유
이 구조에서 파생되는 결과 중 실무적으로 가장 큰 것은 저장입니다. Verse 런타임이 프로그램의 전역 상태를 자동으로 동기화하고 저장하며, 그 상태를 같은 게임·생태계의 모든 실행 인스턴스가 공유할 수 있습니다. 그래서 에픽의 설명대로라면 플레이어 세이브를 만드는 일이 “플레이어 → 저장 상태”라는 전역 맵을 하나 정의하는 것으로 끝납니다 — 데이터베이스를 세우고 게임과 백엔드 서비스 사이에 스키마를 맞추는 작업이 사라집니다.
UEFN에서 이미 쓰이는 weak_map 영속성 기능이 이 방식의 초기 단계이며, 앞으로의 범용 방식과 전방 호환된다고 명시돼 있습니다. UEFN을 지금 만지는 것이 UE6 준비가 되는 구체적인 예입니다.
7부
AI와 MCP — 모델을 만들지 않고 연결한다
에픽이 택한 위치는 모델 제공자가 아니라, 모델이 엔진을 조작할 수 있게 하는 인터페이스 제공자입니다.
자체 AI 모델은 만들지 않습니다.
직접 모델을 만드는 것은 비용이 크므로, 대신 MCP를 적극 지원해 편하게 엔진과 연동해 개발할 수 있도록 하는 방향으로 해결한다는 설명이었습니다.[12] UEFN에 공식 MCP를 추가했다는 언급도 함께 나왔습니다.[13]
기초 다지기
MCP가 무엇이고, 왜 엔진이 이걸 붙이는가
MCP(Model Context Protocol)는 모델이 외부 도구를 호출할 수 있게 하는 공개 규약입니다. 애플리케이션이 “내가 제공하는 도구는 이런 것들이고 각각의 입력은 이런 형태다”를 선언하면, 그 규약을 이해하는 모델이 도구를 골라 호출하고 결과를 받아 다음 판단에 씁니다.
엔진 입장에서 이 방식의 이점은 모델을 고르지 않아도 된다는 것입니다. 엔진은 도구 표면만 잘 정의해 두면 되고, 어떤 모델을 붙일지는 사용자가 정합니다. 에픽의 공식 설명도 같은 논리입니다 — 인터페이스가 열려 있고 모델 선택도 열려 있어서 Claude든 Gemini든 각자에게 맞는 것을 쓰면 된다는 것입니다. 발표의 “엔진 API를 최대한 제거해 Agent가 알아서 동작하게 한다”도 이 맥락에서 읽어야 합니다 — API를 없애자는 뜻이 아니라, 사람이 외우고 조합해야 하던 표면을 에이전트가 다룰 수 있는 형태로 줄이자는 뜻입니다.
언리얼 MCP의 차별점과 시연된 기능
다른 MCP와 달리 환경 인식·공간 인식이 매우 뛰어나도록 설계되었다는 것이 발표의 주장이었습니다.[14] 프레임워크를 계속 개발 중이며, 공식 Unreal MCP를 코딩 에이전트와 연계해 사용하는 것을 예시로 시연했습니다.
| 시연 기능 | 내용 | 왜 인상적이었는가 |
|---|---|---|
| 에셋 배치 | 임의로 생성해 배치하는 것이 아니라, 내 에셋 라이브러리에서 알맞은 것을 찾아 배치합니다. | 생성이 아니라 검색이라서, 팀이 이미 승인한 에셋만 쓰인다는 점 |
| PCG 연동 | 절차적 생성으로 도시를 만들 때도 잘 활용됐습니다. | 레벨 배치에 명확한 이점이 있고, 3D 레벨 창작 난이도가 크게 낮아 보였다는 점 |
| UMG | 프롬프트 입력만으로 UI를 편하게 생성합니다. | 반복적인 위젯 배치처럼 창작이 아닌 작업이 먼저 걷힌다는 점 |
짚어둘 점
“검색해서 배치한다”가 비용 구조를 결정합니다
에셋을 생성하는 대신 기존 라이브러리에서 찾아 배치하는 설계는 결과물 품질 면에서는 분명한 장점입니다. 팀이 만든 에셋만 쓰이므로 스타일이 무너지지 않습니다. 동시에 이 설계는 비용 구조도 함께 결정합니다 — 모델이 무엇을 고를지 판단하려면 후보 에셋의 목록과 설명이 컨텍스트에 들어와야 하기 때문입니다.
그래서 발표가 남긴 실무 조언이 의미를 갖습니다. 에셋 검색·배치 방식의 특성상 토큰 사용량이 상당할 것으로 예상되며, 그렇다면 파일 네이밍 컨벤션이라도 잘 잡아두는 것이 중요해집니다. 이름만 보고 후보를 좁힐 수 있으면 모델이 훑어야 할 범위가 줄고, 그것이 그대로 비용과 정확도로 돌아옵니다.
현재 성숙도
발표는 전부 실험 단계임을 분명히 했습니다. 앞으로 발전할 여지가 크다는 뜻이기도 하지만, 지금 파이프라인을 여기에 걸어두는 것은 이르다는 뜻이기도 합니다. 에픽의 공식 릴리스 노트에서도 UE 5.8의 MCP 플러그인은 실험적(Experimental) 상태로 표기돼 있습니다.
8부
남은 질문 — 발표만으로는 닫히지 않는 것들
답을 지어내지 않고, 질문의 형태와 지금 확인 가능한 근거만 정리했습니다.
- 에셋 제작 부담. 콜라보 에셋을 전 영역에서 활용하는 구조가 되면, 나중에 전용 에셋을 판매·구매하기 위해 높은 퀄리티를 요구하게 되는 것처럼 보입니다. 유저가 에셋을 만드는 것에 대한 부담감은 없는지가 현장에서 남은 첫 번째 의문이었습니다.
- “UE5 + 오픈 에코시스템”의 실체. 오픈 에코시스템이 정확히 무엇을 지칭하는지 발표 안에서는 정의가 모호했습니다. 이 글에서는 에픽이 공개한 로드맵 문서를 근거로 개방 표준 채택 + 자체 시스템의 공개 명세화로 좁혀 읽었지만, 그것이 발표가 의도한 범위와 같은지는 확정할 수 없습니다.
- 분산 트랜잭션 구조. 서버 객체의 롤백·마이그레이션 구조가 사실상 블록체인과 유사한 구조인지에 대한 의문이 남았습니다.
- 열린 생태계 vs 자족 구조. 표방하는 개방성과, 실제로는 에픽 플랫폼 안에서 모든 것이 해결되는 구조 사이의 간극입니다.
짚어둘 점
3번 질문에 대해 지금 말할 수 있는 것
에픽이 공개한 UE6 설명에는 블록체인이나 분산 원장에 대한 언급이 없습니다. 서술된 것은 분산 소프트웨어 트랜잭셔널 메모리이며, 목적은 합의나 신뢰 없는 검증이 아니라 단일 서버처럼 작성한 코드를 여러 서버에 자동 분산하는 것입니다.
겹쳐 보이는 이유는 두 시스템이 “원자성”과 “롤백”이라는 같은 어휘를 쓰기 때문입니다. 하지만 블록체인의 트랜잭션은 서로를 믿지 못하는 참여자들 사이의 합의 문제를 풀고, UE6의 트랜잭션은 한 운영 주체가 관리하는 클러스터 안의 동시성 문제를 풉니다. 전제가 다르므로 결과 구조도 다릅니다. 현재 공개된 자료 범위에서는 “유사한 구조”라고 보기 어렵다는 것이 이 글의 판단입니다.
짚어둘 점
4번 질문 — 개방성 주장을 검증할 수 있는 지점
“열린 생태계”가 수사인지 아닌지는 선언이 아니라 산출물로 판별됩니다. 지금 시점에서 확인 가능한 산출물은 셋입니다. Lore가 실제로 MIT 라이선스 오픈소스로 공개돼 있다는 것, UE6 개발 스트림이 공개돼 있다는 것, 그리고 상호운용의 수단으로 자체 규격이 아니라 glTF나 USD 같은 기존 개방 표준을 1급 포맷으로 채택하겠다고 문서에 적어둔 것입니다.
반대로 아직 확인되지 않은 것도 분명합니다. 포트나이트 코스메틱의 개방 모듈이 실제로 어떤 조건에서 외부 게임에 열리는지, 상호운용이 에픽 생태계 안쪽에서만 성립하는 것인지 밖으로도 나가는 것인지는 아직 문서로 특정되지 않았습니다. 이 질문은 UE6 얼리 액세스 시점에 다시 물어야 하는 종류의 것입니다.
정리
개발자 관점에서 가져갈 것
배포 전략을 다시 짜야 합니다
스팀 단일 배포를 전제로 하던 상황이 아니라, EGS와 포트나이트/UEFN을 노출 채널로 함께 고려할 수 있는 상황이 됐습니다. 특히 UEFN은 인프라 비용 없이 MAU를 확보할 수 있는 통로이고, EGS는 제품별 첫 100만 달러까지 수익 배분 100%라는 조건이 문서로 공개돼 있습니다.
디스커버러빌리티가 개발력만큼 중요해집니다
포트나이트 디스커버가 기본 화면이 되고 모든 행에 개인화가 붙는 순간, 노출 최적화가 별도의 역량이 됩니다. 썸네일과 미리보기 영상, 소셜 지표가 곧 클릭률을 결정하는 변수가 되기 때문입니다.
AI 워크플로가 엔진 로드맵의 1급 시민이 됐습니다
MCP 기반 제작 파이프라인은 에픽이 공식화한 UE6 세 축 중 하나입니다. MCP 연동을 전제로 한 작업 습관 — 네이밍 컨벤션, 에셋 정리 — 이 실제 생산성 차이를 만들 가능성이 높습니다. 검색 기반 배치라서 정리 상태가 곧 비용이기 때문입니다.
Verse는 피하기 어렵습니다
UE6의 새 게임플레이 프로그래밍 모델은 Verse를 중심으로 설계되고(기존 Actor·Blueprint는 초기 버전에 남습니다), 이 전환이 UE6의 첫 번째 이니셔티브로 명시돼 있습니다. UEFN을 진지하게 볼 거라면 학습이 불가피합니다.
지금 UEFN을 만지는 것이 UE6 준비가 됩니다
씬 그래프, Lore, weak_map 영속성은 이미 UEFN에 들어와 있고 앞으로의 범용 방식과 전방 호환된다고 문서에 적혀 있습니다. 2027년 말 얼리 액세스를 기다릴 이유가 없다는 뜻입니다.
기존 프로젝트가 끊기지는 않습니다
Actor와 Blueprint는 UE6 초기 버전에 포함되며, 새 프레임워크가 성숙한 뒤 변환 도구와 함께 단계적으로 정리됩니다. 지금 UE5로 만드는 것을 멈출 이유는 발표 어디에도 없었습니다.
참고 자료
이 문서의 사실 확인에 사용한 자료
본문의 수치·일정·기능명은 아래 자료와 대조했습니다.
에픽게임즈 공식
공식 뉴스 · 2026-06-17
State of Unreal 2026: Top news from the showUE6 세 이니셔티브, 2027년 말 얼리 액세스 목표, Lore 오픈소스 공개, UEFN 개발자 누적 지급액 10억 달러 돌파, 이터레이션 시간 평균 40% 단축, 디스커버 개편(영상·개인화·소셜 지표·로비 대체), 포트나이트 셰이더 개수 68% 감소, EGS 6,000개 게임/3,000개 파트너와 2025년 서드파티 지출 4억 달러. 이 문서에 실린 이미지 5장의 출처이기도 합니다.
공식 블로그 · 2026-06-22
The road to Unreal Engine 6UE5와 UEFN을 2년에 걸쳐 하나로 통합한다는 계획, Verse의 소프트웨어 트랜잭셔널 메모리와 C++ 자동 트랜잭션화, 분산 트랜잭션과 객체 마이그레이션 절차, 포트나이트 코스메틱을 개방 모듈로 옮기는 상호운용 첫 실증, glTF·USD 1급 채택과 공개 명세화, Actor·Blueprint의 UE6 초기 유지와 변환 도구, 얼리 액세스 이후 12~18개월 내 정식 릴리스.
공식 문서
Scene Graph in Unreal Editor for Fortnite엔티티·컴포넌트 구성, Verse로 직접 정의하는 커스텀 컴포넌트, 프리팹을 통한 프로젝트 간 재사용. 발표의 “Actor → Entity” 서술을 대조한 자료입니다.
공식 문서 / 저장소
Lore Developer Documentation · EpicGames/lore모든 데이터를 바이트 스트림으로 취급하는 설계, FastCDC 기반 콘텐츠 정의 청킹과 부분 재업로드, 지연 페치, MIT 라이선스. FAQ에 “Lore는 이전에 Unreal Revision Control이라 불리던 UEFN 내장 버전 관리 시스템”이라고 명시돼 있습니다.
공식 페이지
Epic Games Store — Revenue Share제품별·연도별 첫 100만 달러 순매출까지 100%/0%, 이후 88%/12%. 2025년 6월 1일부터 적용되며 매년 1월 1일에 기준선이 초기화됩니다. Epic First Run은 첫 6개월간 금액 무관 100%.
공식 문서
Epic First Run | Epic Online Services Developer독점 프로그램의 조건과 종료 이후 수익 배분 처리 방식. 위 수익 배분 조건의 세부 사례가 정리돼 있습니다.
세션·행사 관련
현장 보도 (수치 대조용)
아래 기사들에는 이 문서가 공식 자료로 확정하지 못한 수치가 일부 포함돼 있습니다. 1차 자료가 아니므로 인용 시에는 위의 에픽 공식 문서를 우선 근거로 삼는 편이 안전합니다.
인벤
차세대 게임 엔진 ‘언리얼 엔진6’, “개발 생태계의 전환 가져올 것”키노트를 시간 순으로 정리. UEFN 서드파티 누적 지급액 10억 달러 돌파, 7인 팀 게임의 MAU 450만·최고 동접 110만 등 이 문서의 수치와 대조 가능한 항목이 있습니다.
PNN
“게임 개발 방식 전환 필요”… UE6 핵심은 ‘에코시스템’UE6 얼리 액세스 목표가 2027년 말이라는 점과 코딩 에이전트 연동 확대가 명시돼 있습니다. 전자는 에픽 공식 블로그로도 확인됩니다.
부록
각주
본문에서 표시한 항목에 대해, 무엇이 공식 자료로 확인되고 무엇이 확인되지 않았는지 정리했습니다.
각주
- 시장 진단의 세 갈래 — “감의 상실”, “트렌드 가속”, “개발 비용 상승과 성공률 하락”은 발표에서 제시된 진단입니다. 개발 비용 추이나 신작 성공률에 대한 수치가 함께 제시되지는 않았고, 에픽이 공개한 자료에서도 이를 뒷받침하는 통계는 확인되지 않았습니다. 업계 전반에서 널리 공유되는 인식이지만, 이 문서는 발표의 주장으로 표기합니다. ↩
- UA 코스트 상승 — 신규 유저 획득 비용이 과거보다 훨씬 높아졌다는 서술은 발표 내용입니다. 구체적인 수치나 출처는 발표에서 제시되지 않았고, 에픽 공식 자료에서도 확인되지 않았습니다. ↩
- 로블록스를 “닫힌 생태계”로 분류한 것 — 발표의 평가입니다. 로블록스가 개발·콘텐츠·구매를 플랫폼이 통제한다는 서술은 경쟁 플랫폼에 대한 에픽 측 관점이며, 이 문서는 이를 사실 판정 없이 발표의 대비 구도로만 옮겼습니다. ↩
- “개발자에게 가장 유리한 조건” — 조건의 내용은 확인됩니다. 에픽 공식 배포 페이지 기준으로 제품별·연도별 첫 100만 달러 순매출까지 100%/0%, 이후 88%/12%이며, 에픽 결제 시스템을 통한 스토어 판매에는 언리얼 엔진 로열티가 면제됩니다. 다만 이 조건이 모든 경쟁 스토어 대비 “가장 유리”한지는 비교 판단이며, 그 우열을 확정하는 공식 근거는 없습니다. ↩
- 7명이 만든 게임의 MAU 450만 — 발표에서 언급된 사례입니다. 이 문서 작성 시점 기준으로 에픽 공식 자료에서 해당 수치는 확인되지 않았습니다. 현장 보도에는 MAU 450만, 최고 동시 접속 110만이라는 수치가 함께 실려 있으나 1차 자료는 아닙니다. 반면 UEFN 출시 이후 개발자 누적 지급액이 10억 달러를 넘었다는 사실은 에픽 공식 정리에서 확인됩니다. ↩
- UE5 라이선스 보유사의 UE6 전환 비용 — 추가 비용이 전혀 없다는 서술은 발표 내용입니다. 에픽이 공개한 UE6 로드맵 문서에는 라이선스·요금 조건에 대한 언급이 없어, 이 문서 기준으로는 확인되지 않았습니다. 확인되는 것은 전환 기술 측면의 약속뿐입니다 — 기존 프로젝트를 데려가는 것이 원칙이고, Actor와 Blueprint가 UE6 초기 버전에 포함되며, 이후 변환 도구가 제공된다는 것입니다. ↩
- 5.9의 주요 과제 — 5.9에서 AI 워크플로 고도화와 렌더링 고도화가 주요 과제라는 서술은 발표 내용입니다. 에픽 공식 정리의 표현은 다릅니다 — 5.8이 UE5의 마지막 계획된 메이저 릴리스이며, 필요할 경우 5.9를 낼 선택지를 남겨둔 상태라고 되어 있습니다. 즉 5.9의 존재 자체가 확정이 아니므로, 그 릴리스의 과제 목록도 공식 자료로는 확인되지 않습니다. ↩
- 셰이더 관련 “약 68%” — 발표에서는 컴파일 시간 기준 약 68% 개선으로 전달됐습니다. 에픽 공식 정리의 문장은 단위가 다릅니다 — 셰이더 컴파일 최적화와 중복 제거 개선으로 포트나이트의 셰이더 개수를 68% 줄였다는 서술입니다. 개수 감소와 시간 단축은 같은 값이 아니므로, 이 문서는 68%라는 숫자를 발표 표현 그대로 두되 공식 서술의 단위를 본문에 함께 적었습니다. ↩
- “전면 Mesh 기반화”와 영상 기반 애니메이션 — 두 항목 모두 발표에서 짧게 언급됐습니다. “전면 Mesh 기반화”에 대응하는 공식 기능명은 특정하지 못했습니다. UE 5.8의 실험적 기능인 Mesh Terrain(하이트필드 제약 없이 3D 지형을 저작하는 새 시스템)이 방향상 가까워 보이지만, 발표가 가리킨 것과 동일한 항목이라는 근거는 없습니다. 영상만으로 애니메이션을 구현한다는 서술도 특정 기능명으로 확인되지 않았습니다. ↩
- Actor → Entity — 씬 그래프가 엔티티와 컴포넌트로 구성된다는 것은 UEFN 공식 문서로 확인됩니다. 확인되지 않는 것은 전환의 범위와 시점입니다. 에픽 공식 문서는 Actor와 Blueprint가 UE6 초기 버전에 포함되고 새 프레임워크가 충분히 성숙한 뒤에야 deprecate된다고 명시하므로, “Actor가 Entity로 대체된다”는 표현은 최종 방향에 대한 서술로 읽어야 하며 UE6 출시 시점의 상태를 뜻하지 않습니다. ↩
- Lore “도입 예정” — 발표에서는 앞으로 도입할 시스템으로 소개됐습니다. 에픽 공식 자료 기준의 현재 상태는 다릅니다 — Lore는 이미 공개돼 MIT 라이선스로 무료 사용이 가능하고, UEFN에서 그동안 Unreal Revision Control이라는 이름으로 쓰이던 바로 그 시스템이며, 에픽 내부도 UE6 출시 시점까지 Lore로 완전 전환하는 것을 목표로 하고 있습니다. 다만 공개된 오픈소스 툴링과 UEFN 구현이 아직 압축 포맷 차이로 직접 통신하지 못하는 상태라는 점도 함께 문서화돼 있습니다. ↩
- “자체 AI 모델은 만들지 않는다” — 이 표현 그대로의 선언은 에픽 공식 자료에서 확인되지 않았습니다. 확인되는 것은 방향입니다 — 엔진 기능을 MCP로 폭넓게 노출해 개발자가 원하는 모델을 골라 쓰게 하겠다는 것이고, 공식 문서에 이름이 오른 것도 Claude, Gemini, Codex 같은 외부 모델입니다. 동시에 에픽은 선택적 턴키 솔루션으로 Epic Developer Assistant(EDA)를 개선 중이라고 밝히고 있어, “모델을 전혀 다루지 않는다”로 읽는 것은 과합니다. ↩
- “UEFN에 공식 MCP를 추가했다” — 이 문서 기준으로 공식 확인되는 것은 UE 5.8에 실험적(Experimental) MCP 플러그인이 도입됐다는 사실입니다. UEFN 쪽에 별도의 공식 MCP가 추가됐다는 서술은 에픽 공식 자료에서 확인하지 못했습니다. UE6에서 UE5와 UEFN이 하나로 합쳐지는 계획을 감안하면 같은 작업의 다른 표현일 가능성이 있으나, 이 문서에서는 단정하지 않습니다. ↩
- 언리얼 MCP의 환경 인식·공간 인식 우수성 — 다른 MCP 대비 공간 인식이 뛰어나게 설계됐다는 것은 발표의 주장입니다. 비교 대상이나 평가 기준이 제시되지 않았고, 이를 뒷받침하는 공식 자료도 확인되지 않았습니다. 시연으로 보인 동작(에셋 라이브러리 검색 후 배치, PCG 연동, 프롬프트 기반 UMG 생성) 자체는 발표에서 실제로 확인된 내용입니다. ↩