[Unreal/Blueprint] 영화 VFX 업체가 방대한 오픈월드 생존 RPG 게임을 개발할 수 있었던 방법 (언리얼 페스트 서울 2025, 블루프린트, 최적화)

개요

블루프린트에 대한 이해도를 높일 수 있는 사례라 도움이 될 것 같아 요약하였다.

성능과 관리 측면에서 실제 게임 출시에 어떤 영향을 주는지 알 수 있다.

 

내용

1. 영상 정보

• 영상 제목: [언리얼 페스트 서울 2025] Day2 영화 VFX 업체가 방대한 오픈월드 생존 RPG 게임을 개발할 수 있었던 방법
• 채널명: Unreal Engine KR
• 영상 링크: https://youtu.be/CKdMdBOZ7-c

 

2. 핵심 요약 (Conclusion)

• VFX 스튜디오의 게임 개발 전향: 영화/OTT VFX 외주 제작 방식에서 벗어나 자사 IP 자산을 확보하기 위해 언리얼 엔진 기반 게임 개발로 전환한 배경 및 팀 확장 과정
• 블루프린트(BP) 중심 개발 시스템 구축: 95% 이상을 블루프린트로 구현하면서 아티스트 주도의 제작 워크플로우, 사내 BP 연수 프로그램, 퍼포스(P4V) 연동 형상 관리 체계 확립
• 블루프린트 성능 오해와 실측 데이터: BP Tick, Timer, Timeline, Cast, Interface에 대한 기술적 오해 검증 및 실제 오픈월드 씬 내 BP 틱 타임(2.55ms) 실측 결과 공유
• 순환 종속성(Circular Dependency) 문제 해결: BP 간 직접 참조로 인한 패키징 오류(Stack Overflow) 및 크래시 문제를 인터페이스 도입 및 전용 모니터링 플러그인 개조로 해결
• 월드 파티션 및 HLOD 디버깅 노하우: 128m 스트리밍 그리드 설정, HLOD 로그 확인 및 축 가로지름 현상 해결을 위한 '정렬된 그리드 레벨(Grid-Aligned Levels)' 옵션 제어
• 데이터 레이어(Data Layer)를 통한 로딩 절감: 6~7만 개 에셋이 몰린 대형 레벨의 로딩 시간을 데이터 레이어 계층 구조화(지역/배경/로직) 및 하이드 처리를 통해 50% 단축
• 레벨 인스턴스, BPP, PCG 및 스크립터블 툴 최적화: BPP(Blueprint Packed) 및 PCG 조합을 통한 드로우콜/GPU 타임 개선, UE 5.3 PCG 문자열 파싱 기술, 스크립터블 툴 기반 레벨 디자이너용 자체 커스텀 컨트롤러 제작

 

3. 타임라인별 상세 정리

1. 서론 및 영화 VFX 업체에서 게임 개발사로의 전환 (00:00:00 ~ 00:04:16)

• 발표자 및 회사의 배경 (00:00:00): 폴리모프 스튜디오의 한지수 클라이언트 개발 리드와 이수아 테크니컬 아티스트(TA)가 발표를 진행합니다. [00:16]
• VFX 제작 경력과 회의감 (00:00:42): <스위트홈>, <기생수>, <좀비딸> 등 대형 흥행작의 VFX 3D 에셋을 외주 제작했으나, 저작권 이슈로 인해 공식 자리에서 포트폴리오나 수익조차 공개할 수 없는 구조적 한계에 부딪혔습니다. [01:12]
• 게임 개발을 선택한 이유 (00:01:33): 영화/OTT는 대규모 인맥과 막대한 자본이 필수적인 반면, 게임은 직접 감독이자 연출자가 되어 이야기를 만들고 고유한 IP 자산을 온전히 축적할 수 있다는 점에서 매력을 느껴 전향했습니다. [01:45]
• 초기 난관과 인재 유치 (00:01:53): 3D 에셋 제작에는 숙달되어 있었으나, 이를 실제 조작 가능한 게임 로직으로 구동하는 것은 별개의 문제였습니다. 이에 유튜브를 통해 개발 과정을 투명하게 공개하는 방식을 취했고, 이에 공감한 개발 인재들이 모여 3명의 아티스트로 시작한 팀이 20명 규모의 개발사로 성장했습니다. [02:27]

 

2. 프로젝트 소개: <이프 선셋 (If Sunset)> (00:04:17 ~ 00:04:52)

• 게임 개요 및 핵심 루프 (00:04:17): 언리얼 엔진 5.3 기반의 오픈월드 심리스 생존 RPG로, 낮에는 섬을 탐험하며 기지를 구축하고 밤에는 몰려오는 몬스터에 맞서 싸우는 구조입니다. [04:22]
• 기술 스펙 및 현황 (00:04:27): 에픽 온라인 서비스(EOS) 기반 최대 4인 멀티플레이를 지원하며, 게임 로직의 95% 이상을 블루프린트(BP)로 구현했습니다. 현재 얼리 억세스 상태이며 내년 정식 출시를 목표로 하고 있습니다. [04:35]

 

3. 블루프린트 중심의 개발 워크플로우 및 조직 운용 (00:04:53 ~ 00:07:43)

• C++ 대신 블루프린트를 채택한 이유 (00:04:53): 프로그래머 중심의 개발 구조에서 벗어나, 아티스트가 주체적으로 인게임 콘텐츠를 구현하고 테스트할 수 있는 환경을 구축하기 위해 BP 중심 파이프라인을 고집했습니다. [05:03]
• 사내 BP 연수 프로그램 (00:05:22): 사내 4.5일제(금요일 오후)를 활용하여 아티스트 대상 블루프린트 교육을 진행했습니다. 이를 통해 R&D 속도가 급증했으며, 실제 일부 아티스트는 C++ 및 전문 프로그래머로 전향하는 성과를 거두었습니다. [05:31]
• GUI 기반 퍼포스(P4V) 형상 관리 연동 (00:06:20): 개발 경험이 없는 아티스트를 위해 커맨드라인 툴 대신 P4V를 언리얼 에디터 내부와 연동했습니다. 에디터 상에서 직관적으로 에셋을 체크아웃하고 서밋할 수 있도록 시스템을 단순화했습니다. [06:31]
• 성능 감소 대가와 아티스트 생산성의 교환 (00:06:51): BP가 C++ 대비 느린 것은 사실이나, 성능 감쇄 폭을 기술적으로 제어할 수 있다면 아티스트 주도의 빠른 콘텐츠 생산 속도가 주는 이점이 훨씬 크다고 판단했습니다. [07:22]

 

4. 블루프린트 성능 오해 분석 및 실측 프로파일링 (00:07:44 ~ 00:10:08)

• BP Tick vs C++ Tick (00:07:44): BP Tick은 C++ Tick에 비해 연결된 노드 수만큼 추가적인 버추얼 머신 오버헤드가 누적되므로 실제로 무겁습니다. [07:55]
• Tick 대신 Timer 사용 논란 (00:08:05): 타이머가 Tick보다 가볍다는 오해가 있으나, 타이머는 델리게이트 함수를 찾을 때 문자열(함수 이름) 검색 과정을 거치므로 틱보다 오버헤드가 더 클 수 있습니다. [08:15]
• Tick 대신 Timeline 사용 논란 (00:08:26): 타임라인 내부 틱이 C++로 구동되어 가볍다고 생각하기 쉬우나, 타임라인 컴포넌트 수량이 많아지면 일반 BP Tick보다 훨씬 중량이 커질 수 있습니다. [08:37]
• BP Cast 노드의 실제 비용 (00:08:49): Cast 기능 자체가 무거운 것이 아니라, 캐스팅 대상 BP가 참조(Reference)하고 있는 모든 에셋들이 메모리에 한 번에 로드되는 현상 때문입니다. 이로 인해 에셋을 열 때 2~3분씩 로딩이 걸리는 병목이 발생합니다. [08:59]
• Cast 대안으로서의 Interface (00:09:20): 인터페이스는 다중 상속 및 결합도(Decoupling) 완화를 위한 도구일 뿐, 단순 Cast 대체용으로 사용하는 것은 잘못된 접근입니다. [09:28]
• 오픈월드 실측 BP 데이터 (00:09:39): 인게임 내 로드된 BP 액터 4,061개 기준, BP 수행 시간(BP Time)은 약 2.55ms 수준입니다 (스폰 수량에 따라 1~3ms 변동). 적절한 최적화를 거친다면 대형 오픈월드에서도 BP 중심 구조를 충분히 감내 및 운용할 수 있음을 증명했습니다. [09:52]

 

5. 순환 종속성(Circular Dependency) 해결 및 세이브 시스템 (00:10:09 ~ 00:13:35)

• 순환 종속성 발생 원인 (00:10:09): 헤더 파일이 없는 BP 특성상, Actor A가 Actor B 변수를 가지고 Actor B가 Actor A 변수를 가지는 식의 상호 직접 참조가 무분별하게 일어납니다. [10:21]
• 프로젝트 대형화에 따른 장애 (00:10:35): 프로젝트 규모가 커지면 패키징 빌드 시 스택 오버플로우(Stack Overflow) 에러로 빌드가 실패하거나, 에셋 오픈 시 에디터가 크래시되는 치명적 문제가 발생했습니다. [10:45]
• 순환 깊이(Depth) 분석 및 해결책 (00:11:05): 참조 고리(A→B→C→...→A)의 깊이가 일정 기준을 초과하면 에러가 발생함을 규명했습니다. 이에 직접 참조 노드를 BP Interface로 리팩터링하여 참조 고리를 끊었습니다. [11:23]
• Circular Dependency Plugin 커스텀 (00:11:36): 에셋 간 순환 종속성 뎁스를 시각적으로 모니터링할 수 있는 외부 플러그인을 구매 후 사내에 맞게 개조하여, BP 참조 깊이를 지속적으로 관리하고 재발을 방지했습니다. [11:46]
• 월드 파티션 이벤트 연동 세이브 매니저 (00:12:03): 월드 파티션의 그리드가 로드될 때 호출되는 BP의 BeginPlay에서 세이브 매니저로부터 데이터를 불러오고, 언로드될 때 호출되는 EndPlay에서 현재 데이터를 세이브 매니저에 저장하는 방식으로 배치된 모든 BP의 데이터를 실시간 관리합니다. [12:55]

 

6. 배경 제작, 월드 파티션, HLOD 세팅 및 디버깅 (00:13:36 ~ 00:17:37)

• 배경 다듬기 병목과 해양 콘텐츠의 과제 (00:13:36): 정글/사막 구역 디테일 작업에만 1년 가까이 소요되어, 더 넓은 해양 구역을 단기간에 구축하기 위해 언리얼 오픈월드 핵심 기능들을 적극 채택했습니다. [14:23]
• 월드 파티션 스트리밍 설정 (00:15:14): 플레이어 기준 스트리밍 소스 범위를 128m로 지정하고, 그 외의 원거리 영역은 간소화된 HLOD가 보이도록 세팅했습니다. [15:24]
• HLOD 디버깅 팁 (00:15:40):
  • 프로젝트 Saved/Logs 폴더 내 로그 데이터를 분석하면 그리드 정보, HLOD 컨테이너 스트리밍 정보, Always Loaded 상태의 액터 목록을 정확히 파악할 수 있습니다 (PIE 모드와 Cooked 빌드의 로그 차이 유의). [15:53]
  • 정렬되지 않은 자연 지형 에셋이 좌표축을 가로지를 때 HLOD가 정상 생성되지 않는 현상이 발생합니다. 이때 월드 옵션의 '정렬된 그리드 레벨 (Grid-Aligned Levels)' 옵션을 비활성화(Off)하면 문제를 해결할 수 있습니다. [16:38]
  • wp.RuntimeHash2D.Debug 콘솔 커맨드를 활용해 텔레포트 시 로드(녹색 128m 영역) 및 언로드(적색 HLOD 영역) 구역을 시각적으로 디버깅할 수 있습니다. [17:23]

 

7. 데이터 레이어(Data Layer)를 통한 프로젝트 최적화 (00:17:38 ~ 00:19:37)

• 메인 레벨 로딩 속도 문제 (00:17:38): 정글/사막 구역에만 6만~7만 개의 에셋이 단일 월드에 배치되어, 메인 레벨을 열 때마다 매번 10분 가까운 로딩 대기 시간이 발생하는 생산성 저하가 있었습니다. [17:58]
• 데이터 레이어 계층 구조 설계 (00:18:17):
  • 최상위 데이터 레이어: 지역별 구분
  • 하위 데이터 레이어: 배경용 에셋 레이어 / 로직용 에셋 레이어로 세분화 분리. [18:32]
• 작업 효율성 향상 및 측정 결과 (00:18:49): 작업자가 본인 담당 구역 외의 데이터 레이어를 비활성화(Hide)한 채 작업할 수 있게 되었으며, 미공개/이벤트 에셋 제어도 용이해졌습니다. 언리얼 인사이트(Unreal Insights) 측정 결과 메인 레벨 로딩 시간이 절반 가까이 감소했습니다. [19:24]

 

8. 레벨 인스턴스, BPP, PCG 구축 노하우 (00:19:38 ~ 00:24:43)

• 에셋 단일화 및 BPP 패킹 (00:19:38): 스태틱 메시를 개별 배치하는 대신 소규모 에셋군을 레벨 인스턴스(Level Instance)로 묶은 뒤 BPP (Blueprint Packed) 형태로 패킹하여 모듈화했습니다. [19:50]
• 성능 측정 결과 (00:21:09): 개별 스태틱 메시 배치 방식 대비 Draw Call과 Primitive 수량이 획기적으로 감소했으며, GPU 타임 역시 크게 개선되었습니다. [21:19]
• PCG(Procedural Content Generation) 활용과 프레임 드랍 방지 (00:21:44):
  • 스플라인(Spline) 경로를 따라 해양 에셋을 절차적으로 배치하는 'Level to PCG' 세팅을 활용했습니다. [22:06]
  • PCG 에셋이 누적됨에 따라 실시간 자동 업데이트로 인한 1프레임 프레임 드랍(Stuttering)이 발생했습니다. 이를 해결하기 위해 버튼 호출(Manual Triggering) 방식을 구축하여 아티스트가 명시적으로 요청할 때만 PCG가 업데이트되도록 개조했습니다. [22:27]
• UE 5.3 PCG 데이터 파싱 워크플로우 (00:22:44): UE 5.3 버전의 PCG 내부 구조체 배열(Array Struct) 미지원 한계를 극복하기 위해 PCG Blueprint Element를 작성했습니다. 커스텀 데이터를 텍스트/문자열(String) 형태로 어트리뷰트에 넘긴 후 이를 파싱(Parsing)하여 매쉬 에셋 주소를 동적 할당하는 방식을 구현했습니다. [22:54]

 

9. 스크립터블 툴(Scriptable Tools) 및 최종 결론 (00:24:44 ~ 00:27:32)

• ISM 개별 수정 한계 극복 (00:24:44): PCG로 자동 생성된 ISM(Instanced Static Mesh)은 개별 변형이 불가능한 단점이 있습니다. 이를 보완하기 위해 언리얼의 스크립터블 툴(Scriptable Tools)을 사용해 자체 에디터 툴을 제작했습니다. [24:58]
• 에디터 컨트롤러 구축 (00:25:05): 아웃라이너(Outliner)에서 수많은 액터를 일일이 검색할 필요 없이, 외부 인터페이스 툴을 통해 복잡한 환경 에셋 및 PCG 액터 제어를 한곳에서 수행하도록 구축하여 해양 콘텐츠 제작 효율을 대폭 향상시켰습니다. [25:21]
• 요약 및 시사점 (00:25:35): VFX 전문 인력 중심의 소규모 팀이 월드 파티션, 데이터 레이어, 레벨 인스턴스, PCG, 스크립터블 툴, 그리고 체계적인 BP 파이프라인 최적화를 집약함으로써 방대한 규모의 오픈월드 생존 RPG를 효율적으로 개발해낼 수 있었습니다. [27:10]