UE5 대규모 레벨(UMAP) 협업과 바이너리 에셋 충돌 방지: OFPA와 Lore 기반 비파괴적 브랜칭 전략

핵심 요약

문제: 언리얼 엔진의 .umap 및 .uasset은 직렬화된 바이너리 파일이므로 Git이나 SVN 같은 텍스트 기반 소스 컨트롤에서 라인 단위 병합(3-way Merge)이 불가능하여 덮어쓰기 데이터 유실이 발생합니다.
엔진 레벨 해결책: World Partition의 OFPA(One File Per Actor)로 거대 맵을 개별 액터 단위 파일(__ExternalActors__)로 분할하고 Data Layers로 아트·라이팅·기획 요소를 논리적으로 격리합니다.
VCS 레벨 해결책: 에픽게임즈의 차세대 버전 관리 시스템 Lore(구 URC)의 콘텐츠 주소 지정 스토리지(Merkle Tree), 스파스 하이드레이션(Sparse Hydration), 네이티브 파일 락킹(Exclusive Locking)을 도입해 대용량 바이너리 환경에서도 무손실 비파괴 브랜칭을 달성할 수 있습니다.

UE5 레벨 파일(UMAP)과 바이너리 에셋은 왜 머지(Merge)가 불가능할까?

언리얼 엔진 5(UE5) 프로젝트에서 레벨 디자이너, 테크니컬 아티스트, 조명 담당자가 동시에 하나의 레벨을 편집할 때 가장 자주 마주치는 병목은 소스 컨트롤 충돌입니다.

C++ 소스 코드나 텍스트 설정 파일(JSON, YAML)은 라인 단위의 변경 사항을 추적하여 자동으로 브랜치를 병합할 수 있지만 .umap과 .uasset 파일은 패키지 헤더, 임포트/익스포트 맵, 직렬화된 UObject 페이로드가 압축된 바이너리 스트림(Binary Stream) 구조를 가집니다. 단 1바이트의 트랜스폼(Transform) 값만 수정되어도 파일 전체의 오프셋과 체크섬이 달라지므로 외부 머지 툴이 의미론적 차이를 해석할 수 없습니다.

하나의 모놀리식 .umap에 $N$ 명의 작업자가 동시에 변경 사항을 커밋할 때 발생하는 충돌 확률은 각 작업자의 동시 수정 확률을 $p_k$ 라 할 때 다음과 같은 독립 사건의 누적 확률 모델로 표현할 수 있습니다.

P_{\text{conflict}} = 1 - \prod_{k=1}^{N} (1 - p_k)

팀 규모 $N$ 이 커질수록 충돌 확률은 1에 수렴하며 결과적으로 누군가의 작업물이 덮어씌워지거나 롤백되는 파괴적 손실을 낳습니다. 이를 해결하기 위해서는 엔진 내부의 파일 구조 분할과 VCS 차원의 바이너리 브랜칭 전략이 결합되어야 합니다.

엔진 내부 아키텍처 최적화: OFPA와 Data Layer를 통한 충돌 격리

1. World Partition과 OFPA(One File Per Actor)

UE5의 World Partition 시스템은 기존의 레벨 스트리밍(Level Streaming) 구조를 대체하며 핵심 기능으로 OFPA(One File Per Actor)를 제공합니다.

동작 방식: 레벨(.umap) 저장 시 모든 액터를 단일 맵 파일에 패킹하지 않고 프로젝트의 Content/__ExternalActors__/ 디렉터리에 액터 GUID 기반의 독립된 .uasset 파일로 분할 저장합니다.
효과: 레벨 디자이너가 맵 전체를 체크아웃(Check-out)할 필요 없이 자신이 이동하거나 수정한 액터 파일만 선택적으로 체크아웃할 수 있어 동시 작업 충돌을 획기적으로 낮춥니다.

2. Data Layer를 활용한 도메인별 작업 격리

테크니컬 아티스트와 환경 아티스트의 작업 간섭을 최소화하기 위해 Data Layers를 계층화해야 합니다.

DL_Art_Environment: 스태틱 메시, 모듈러 프랍, 지형 장식
DL_Lighting_Atmosphere: 라이트 소스, 지오메트릭 볼륨, 스카이라이트, 포스트 프로세스 볼륨
DL_VFX_Audio: 나이아가라 시스템, 앰비언트 사운드 큐
DL_Gameplay_Logic: 트리거 볼륨, 스폰 포인트, AI 네비게이션 메시

구분	기존 서브레벨(Sub-Level) 방식	World Partition + OFPA + Data Layer
파일 단위	서브레벨 단위 모놀리식 `.umap`	개별 액터 단위 `.uasset` 분할
체크아웃 단위	서브레벨 전체 (동시 편집 불가)	특정 액터만 단독 락(Lock)
런타임 로딩	수동 스트리밍 볼륨 및 블루프린트 로드	그리드 기반 셀 자동 스트리밍 + Data Layer 토글
협업 효율	충돌 빈번, 명시적 레벨 분할 필요	수십 명의 아티스트가 동일 맵 실시간 동시 작업

UE5 World Partition OFPA 액터 분할 및 Data Layer 계층 구조

차세대 버전 관리 시스템 Lore란 무엇이며 어떻게 동작하는가?

OFPA를 적용하더라도 대용량 텍스처, 나이아가라 캐시, 3D 셰이더 에셋과 같은 고용량 바이너리 파일들을 Git LFS나 Perforce에서 브랜칭하고 동기화하는 작업은 여전히 막대한 디스크 공간과 네트워크 대역폭을 소모합니다.

Lore(구 Unreal Revision Control / URC)는 에픽게임즈가 포트나이트(UEFN) 대규모 라이브 개발을 위해 구축하고 오픈소스화한 게임 개발 특화 버전 관리 시스템입니다. 전통적인 Git이나 Perforce의 구조적 한계를 극복하도록 설계되었습니다.

Lore의 3대 핵심 아키텍처

콘텐츠 주소 지정 스토리지 (Content-Addressed Merkle Tree):
모든 파일과 디렉터리 상태를 SHA-256 기반 머클 트리로 관리하여 동일한 바이너리 블록의 중복을 원천 차단합니다. 수 기가바이트의 맵 브랜칭 시에도 변경된 액터 노드만 새로 생성되므로 스냅샷 생성 속도가 거의 즉각적(Zero-Copy)입니다.
스파스 하이드레이션 (Sparse Hydration / On-Demand Sync):
수백 기가바이트에 달하는 전체 저장소를 로컬에 전부 다운로드받지 않고 가상 파일 시스템 메타데이터만 먼저 가져온 뒤 아티스트가 뷰포트에서 열람하거나 빌드에 필요한 에셋만 온디맨드로 스트리밍 다운로드합니다.
네이티브 독점 잠금 (Exclusive File Locking):
중앙 집중식 코디네이터를 통해 특정 액터(.uasset)를 수정 중인 사용자를 실시간 감지하여 다른 작업자의 쓰기 접근을 엔진 에디터 상에서 시각적으로 차단합니다.

flowchart TD
    subgraph Central_Lore_Server["Lore 중앙 저장소 (Content-Addressed Storage)"]
        Root["Root Commit (Merkle Root)"]
        T_Actors["Tree: __ExternalActors__"]
        T_Art["Tree: Art/Textures"]
        BlobA["Blob: Actor_Light_01.uasset"]
        BlobB["Blob: Actor_Terrain_02.uasset"]
        BlobTex["Blob: T_Rock_4K_BC.uasset"]
        
        Root --> T_Actors
        Root --> T_Art
        T_Actors --> BlobA
        T_Actors --> BlobB
        T_Art --> BlobTex
    end

    subgraph Local_Artist_Workspace["아티스트 워크스페이스 (Sparse Hydration)"]
        Hydrated["로컬 로드된 액터 (Lock 획득: Actor_Light_01)"]
        VirtualStub["가상 스텁 (필요 시 다운로드: T_Rock_4K)"]
    end

    BlobA -.->|"스냅샷 로드 & 독점 잠금"| Hydrated
    BlobTex -.->|"온디맨드 하이드레이션"| VirtualStub

위 구조를 통해 아티스트는 전체 프로젝트를 클론할 필요 없이 필요한 레벨 구역과 라이팅 에셋만 로드하여 작업할 수 있으며 다른 작업자가 잠근 에셋은 실시간으로 편집이 제한되어 비파괴적인 작업 흐름이 보장됩니다.

Lore의 Content-Addressed 머클 트리 스냅샷 및 스파스 하이드레이션 파이프라인

Step-by-Step: Lore와 UE5를 연동한 비파괴적 브랜칭 파이프라인 구축하기

1단계: World Partition 및 OFPA 활성화

기존 프로젝트 레벨을 OFPA 구조로 전환합니다.

언리얼 에디터 메뉴에서 도구(Tools) -> 월드 파티션(World Partition) -> 레벨 변환(Convert Level)을 실행합니다.
프로젝트 세팅의 프로젝트 -> 소스 컨트롤에서 OFPA 사용(Enable One File Per Actor)이 활성화되어 있는지 확인합니다.
레벨 저장 시 Content/__ExternalActors__/ 경로에 개별 액터 파일들이 생성되는지 확인합니다.

2단계: Lore 프로젝트 초기화 및 잠금 규칙 설정

Lore CLI 또는 플러그인을 사용하여 리포지토리를 초기화하고 바이너리 잠금 규칙을 정의합니다.

# Lore 리포지토리 초기화
lore init --server https://lore.internal-studio.com/project-rpg

# 바이너리 에셋 및 레벨 액터 확장자 잠금 정책 등록
lore config locks.patterns "Content/**/*.uasset" "Content/**/*.umap"

# 가상 파일 시스템 스파스 하이드레이션 활성화
lore config storage.sparse-hydration true

3단계: 일상 작업 및 비파괴 브랜칭 워크플로

아티스트가 새로운 조명 기법이나 셰이더 실험을 안전하게 진행하는 표준 순서입니다.

스냅샷 브랜치 생성: 메인라인에 영향을 주지 않는 경량 스냅샷 브랜치를 생성합니다.
```
lore branch create feat/art-volumetric-lighting
lore checkout feat/art-volumetric-lighting
```
에셋 독점 잠금 및 수정: 에디터 내에서 DL_Lighting_Atmosphere에 속한 라이트 액터들을 수정하면 Lore가 백그라운드에서 중앙 서버에 락(Lock)을 요청합니다.
변경 사항 커밋 및 메인라인 리베이스: 변경된 액터 블록만 Merkle Tree에 기록되므로 즉시 커밋 후 충돌 없이 메인 스트림으로 승격(Promote)합니다.
```
lore commit -m "Apply new volumetric fog and local directional lights"
lore push origin feat/art-volumetric-lighting
```

자주 묻는 질문 (FAQ)

Q1. 이미 Perforce(P4)를 사용 중인 스튜디오에서도 Lore 도입의 실익이 있을까요?

Perforce의 스트림(Streams)과 익스클루시브 체크아웃은 성숙한 솔루션이지만 브랜치 전환 시 작업 공간 전체의 파일을 물리적으로 교체하므로 디스크 I/O 병목과 스토리지 낭비가 큽니다. Lore는 Merkle Tree 기반의 가상 파일 포인터 스왑을 사용하므로 수백 기가바이트의 브랜치 전환이 수초 내에 완료되며 스파스 하이드레이션을 통해 아티스트 로컬 드라이브 용량을 최대 70% 이상 절감할 수 있습니다.

Q2. Git LFS의 `git lfs lock`과 Lore의 잠금 메커니즘은 어떻게 다른가요?

Git LFS의 락킹은 별도의 원격 서버 API 호출을 통해 수동 또는 반자동으로 이루어지며 브랜치가 갈라졌을 때 락의 소유권이 전역적으로 명확하지 않은 분산 환경의 구조적 모순이 존재합니다. 반면 Lore는 중앙 코디네이터가 실시간 세션을 유지하며 언리얼 엔진 에디터 뷰포트와 직접 양방향 통신하여 액터 선택 즉시 락을 획득하고 해제합니다.

Q3. OFPA 활성화 시 수만 개의 액터 파일로 인해 OS 디스크 I/O나 패키징 빌드 속도가 느려지지 않나요?

언리얼 엔진의 쿠킹(Cooking) 및 패키징 파이프라인은 빌드 시점에 OFPA 액터들을 다시 최적화된 런타임 맵 블록으로 패킹하므로 최종 게임 런타임 성능에는 부정적인 영향이 전혀 없습니다. 다만 로컬 소스 컨트롤 동기화 시 수많은 소형 파일로 인한 오버헤드는 Lore와 같은 Content-Addressed 청크 전송 최적화 툴을 사용할 때 효율적으로 상쇄됩니다.

결론: 테크니컬 아티스트를 위한 협업 체크리스트

대규모 UE5 프로젝트에서 바이너리 에셋 충돌로 인한 작업 손실을 막기 위해서는 엔진 기능과 전용 VCS 도구가 유기적으로 맞물려야 합니다.

World Partition + OFPA 적용: 신규 레벨 생성 시 필수 활성화하여 단일 .umap 의존도 제거
Data Layer 규칙 표준화: 아트, 라이팅, 사운드, 기획 레이어를 분리하여 커밋 경계 격리
Lore 기반 스파스 동기화 구축: 불필요한 전체 에셋 다운로드를 지양하고 필요한 액터만 온디맨드 하이드레이션
실시간 에디터 락킹 체계화: .uasset 수정 전 에디터 내 잠금 상태를 확인하는 비파괴적 작업 문화 확립