100GB+ 대용량 게임 프로젝트 VCS 벤치마크: Git LFS vs Perforce vs Lore 성능 및 구조 비교

핵심 요약

Git LFS: 코드 중심 소규모 팀에 익숙하지만 포인터 치환 오버헤드와 분산 저장소 구조로 인해 100GB+ 프로젝트에서 클론 및 브랜치 전환 속도가 급격히 저하됩니다.
Perforce (Helix Core): 성숙한 중앙집중형 아키텍처, 강력한 배타적 잠금(Locking), 안정적인 대용량 전송을 제공하지만 고가의 라이선스 비용과 인프라 유지보수 부담이 큽니다.
Lore: Epic Games가 UEFN 백엔드를 기반으로 공개한 오픈소스 중앙집중형 VCS로, Merkle 트리 기반 청크(Chunk) 스토리지와 온디맨드 하이드레이션(On-Demand Hydration)을 통해 Perforce급 성능을 무료(MIT 라이선스)로 제공합니다.

4K 텍스처, 고밀도 메시(Nanite), 오디오 뱅크 등 에셋 크기가 기가바이트 단위를 넘어서는 현대 게임 엔진(Unreal Engine 5, Unity 6) 환경에서 버전 관리 시스템(VCS)은 클라이언트 개발 생산성을 좌우하는 핵심 파이프라인입니다.

본 글에서는 100GB 규모의 실제 게임 프로젝트 환경에서 Git LFS, Perforce(Helix Core) 그리고 에픽게임즈가 오픈소스로 공개한 차세대 게임용 VCS Lore를 동일한 조건에서 벤치마크하고 내부 아키텍처 차이를 분석합니다.

100GB+ 에셋 환경에서 VCS 아키텍처 차이는 왜 중요한가?

게임 클라이언트 프로젝트는 수만 개의 텍스트 코드 파일과 수십 기가바이트의 대용량 비정형 바이너리(.uasset, .fbx, .psd, .bank)가 공존합니다. 일반적인 소프트웨어 공학에 최적화된 분산 VCS와 게임 전용 중앙집중형 VCS는 바이너리 저장 및 전송 메커니즘에서 근본적인 차이를 보입니다.

flowchart LR
    subgraph GitLFS["Git LFS"]
        G1["Git 커밋"] --> G2["SHA-256 포인터 텍스트"]
        G2 --> G3["LFS 서버에서 전체 파일 다운로드"]
    end

    subgraph Perforce["Perforce Helix Core"]
        P1["Depot 중앙 서버"] --> P2["Revision 메타데이터"]
        P2 --> P3["작업공간(Have Table) 직접 동기화"]
    end

    subgraph Lore["Epic Games Lore"]
        L1["중앙 Merkle Store"] --> L2["Content-Addressed 청크 트랜스퍼"]
        L2 --> L3["온디맨드 가상 하이드레이션"]
    end

Git LFS: Git 객체 트리에는 해시 포인터만 남기고 실제 바이너리는 별도 LFS 스토리지에 저장합니다. 그러나 브랜치 전환 시 스머지(Smudge)/클린(Clean) 필터 프로세스가 파일마다 프로세스를 호출하여 파일 수가 많아질수록 I/O 병목이 심화됩니다.
Perforce (Helix Core): 서버가 각 클라이언트의 동기화 상태(Have Table)를 직접 추적합니다. 로컬 인덱싱 오버헤드가 없으며 중앙 서버에서 클라이언트로 다이렉트 스트리밍 전송을 수행합니다.
Lore: 중앙집중형 모델을 채택하면서도 Merkle 트리 기반의 콘텐츠 주소 지정(Content-Addressed) 청크 스토리지를 사용합니다. 파일 전체가 아닌 수정된 블록 단위로 중복을 제거하고 필요한 파일만 지연 로딩(Sparse Hydration)합니다.

벤치마크 환경 및 측정 기준

공정한 성능 측정을 위해 동일한 하드웨어 사양과 네트워크 대역폭 제한 환경에서 테스트를 구성했습니다.

테스트 환경 사양

프로젝트 구성: Unreal Engine 5.4 기반 C++ 코드 + 105.4GB 바이너리 에셋 (총 파일 수: 24,180개)
클라이언트 머신: AMD Ryzen 9 7950X, 64GB DDR5, PCIe 4.0 NVMe SSD (7,000MB/s), Windows 11
네트워크 환경: 1Gbps 대칭형 전용망 (실측 대역폭: 약 110MB/s)
서버 환경: AWS EC2 c6i.2xlarge (Ubuntu 22.04, EBS gp3 3,000 IOPS)

측정 항목

초기 클론 및 체크아웃(Fresh Clone/Sync): 최초 저장소 설정 후 전체 워크스페이스를 작업 가능한 상태로 만드는 데 걸린 시간
브랜치 전환(Branch Switching): 5GB 분량의 에셋 수정 및 신규 추가가 포함된 브랜치 간 전환 시간
1GB 대용량 파일 수정 후 제출(Commit & Push / Submit): 단일 1GB 텍스처 아틀라스 수정 후 서버 반영 시간
로컬 디스크 점유 용량: 작업 완료 후 로컬 저장소 총 사용량

100GB 게임 프로젝트 VCS별 클론 및 브랜치 전환 소요 시간 벤치마크 그래프

벤치마크 결과 비교 분석

동일한 105.4GB 데이터셋에 대한 측정 결과는 다음과 같습니다.

비교 항목	Git + Git LFS (2.13 / 3.5)	Perforce Helix Core (2024.1)	Epic Games Lore (0.8.x)	비고
초기 클론/동기화 (전체)	34분 12초	17분 48초	16분 52초	네트워크 대역폭 한계 도달
온디맨드 부분 동기화	지원 불가 (전체 LFS 다운로드)	2분 10초 (Client View 설정)	42초 (Virtual Hydration)	작업 디렉터리만 즉시 로드
브랜치 전환 (5GB 변경)	4분 38초	1분 12초	58초	Lore 청크 캐시 재사용
1GB 파일 커밋 및 제출	48초 (Hashing + LFS Push)	22초 (Direct Submit)	25초 (Chunk Deduplication)	Perforce 직렬화 전송 우세
로컬 디스크 사용량	212.8GB (Git DB + LFS Cache + Workdir)	105.4GB (순수 워크스페이스)	114.2GB (CAS 청크 스토어)	Git의 로컬 캐시 중복 이슈
배타적 잠금(Locking)	Git LFS Lock (수동, 충돌 위험 존재)	전용 엔진 통합 Lock (완전 제어)	전용 File Lock 지원 (발전 중)	아티스트 협업 필수 기능
라이선스 및 비용	오픈소스 (호스팅 비용 별도)	5인 초과 시 유료 (인당 연 $500+)	MIT 오픈소스 (무료)	엔터프라이즈 도입 비용

동기화 지연 시간( $T_{\text{sync}}$ )은 이론적으로 다음과 같은 모델을 따릅니다:

T_{\text{sync}} = \sum_{i=1}^{N} \frac{\text{ChunkSize}_i}{\text{Bandwidth}} + T_{\text{index}} + T_{\text{filter\_process}}

Git LFS는 파일 수( $N$ )가 증가할수록 포인터 검증 및 필터 프로세스 기동 비용인 $T_{\text{filter\_process}}$ 가 기하급수적으로 증가하는 반면, Perforce와 Lore는 중앙 색인 테이블을 통해 이를 $O(1)$ 또는 Merkle 트리 깊이 수준으로 제어합니다.

대용량 바이너리 프로젝트에서 Git LFS는 왜 한계에 부딪히는가?

Git LFS가 대용량 프로젝트에서 성능 저하를 겪는 이유는 Git의 고유 설계 철학인 ‘분산 모델’과 LFS의 ‘애드온(Add-on)’ 방식 결합 때문입니다.

이중 스토리지 점유 오버헤드:
Git LFS는 다운로드한 바이너리를 .git/lfs/objects에 캐싱하고 이를 작업 디렉터리에 복사(또는 하드링크)합니다. 100GB 프로젝트를 클론하면 로컬 디스크 공간이 최대 200GB 이상 소모됩니다.
스머지/클린 필터의 단일 스레드 병목:
Git 체크아웃 과정에서 수만 개의 LFS 포인터 파일을 바이너리로 교체할 때 파이프 프로세스가 지속적으로 호출되어 CPU 및 파일 I/O 대기열이 급증합니다.
느슨한 파일 잠금 메커니즘:
바이너리 에셋은 텍스트처럼 3-way 머지가 불가능하므로 선점형 잠금이 필수적입니다. Git LFS의 git lfs lock은 중앙 서버와의 실시간 상태 동기화가 느려 휴먼 에러로 인한 에셋 덮어쓰기 위험이 있습니다.

Lore의 Merkle 기반 청크 스토리지와 Git LFS 포인터 구조 비교

Lore의 청크 기반 스토리지와 온디맨드 하이드레이션 원리

Lore는 에픽게임즈가 포트나이트 언리얼 에디터(UEFN)의 대규모 협업을 위해 내부적으로 구축했던 인프라를 오픈소스로 공개한 프로젝트입니다.

1. Merkle Tree 기반 청크 분할 (Chunked Storage)

Lore는 대용량 에셋을 가변 크기 청크(Chunk)로 분할하여 콘텐츠 주소 지정 저장소(CAS)에 저장합니다. 1GB 크기의 텍스처 파일에서 일부 밉맵이나 메타데이터만 변경되었을 경우, 변경된 수 메가바이트의 청크만 서버로 업로드됩니다.

2. 가상 파일 시스템(VFS) 기반 On-Demand Hydration

개발자나 아티스트가 프로젝트 전체를 동기화하지 않아도 디렉터리 메타데이터만 먼저 가져옵니다. 엔진 에디터가 특정 에셋에 접근하는 순간 백그라운드에서 해당 청크를 실시간 스트리밍하여 로컬 파일 시스템에 하이드레이션(Hydration)합니다.

# Lore CLI를 이용한 온디맨드 가상 작업공간 생성 예시
lore clone https://vcs.studio.internal/game-project ./ClientWorkspace --sparse

# 특정 맵 및 관련 에셋만 선택적 동기화
lore hydrate ./Content/Maps/Level_01/ --include-dependencies

팀 규모와 예산에 따른 최적의 VCS 선택 가이드 (Step-by-Step)

게임 개발 스튜디오의 규모, 파이프라인, 예산에 따라 적합한 VCS를 선택하는 3단계 가이드입니다.

1단계: 프로젝트 에셋 규모 및 예산 평가
- 프로젝트 전체 크기가 30GB 이하이고 프로그래머 중심의 팀이라면 기존 GitHub/GitLab 인프라를 활용할 수 있는 Git LFS가 가장 진입 장벽이 낮습니다.
- 프로젝트가 100GB 이상이며 Perforce 라이선스 예산(연간 수천만 원)이 확보된 경우 검증된 표준인 Perforce (Helix Core)를 선택합니다.
2단계: 인프라 자체 구축 역량 점검
- 비용을 절감하면서 Perforce 수준의 대용량 에셋 처리 성능이 필요하다면 자체 Linux 서버 또는 클라우드(AWS S3 기반 백엔드)에 Lore를 배포합니다.
3단계: 에디터 툴체인 및 아티스트 협업 환경 연동
- 언리얼 엔진의 Source Control 플러그인 연동 안정성이 최우선이라면 Perforce가 가장 유리하며 UEFN 파이프라인이나 차세대 오픈소스 스택을 구축하려는 팀은 Lore의 전용 플러그인을 도입합니다.

자주 묻는 질문 (FAQ)

Q1. Lore는 현재 프로덕션 환경에 바로 도입할 수 있는 상태인가요?

Lore는 UEFN에서 실제 서비스 검증을 거쳤으나 현재 독립 오픈소스 버전(0.8.x)은 pre-1.0 개발 단계입니다. 핵심 청크 스토리지와 동기화 엔진은 안정적이지만 GUI 클라이언트 생태계와 타사 DCC 툴 플러그인은 지속적으로 업데이트되고 있으므로 파일럿 프로젝트부터 단계적 도입을 권장합니다.

Q2. Git LFS 환경에서 속도를 개선할 수 있는 현실적인 설정은 무엇인가요?

.gitconfig에서 lfs.concurrenttransfers 값을 8~16으로 늘려 병렬 다운로드를 활성화하고 core.fscache = true, core.preloadindex = true를 설정합니다. 또한 git lfs clone 대신 최신 Git의 포괄적 필터를 지원하는 git clone을 사용해야 합니다.

Q3. Perforce에서 Lore로 마이그레이션할 때 히스토리 보존이 가능한가요?

Lore는 표준 인터페이스를 통해 변경 이력(Revision History)을 Merkle 트리 스냅샷 형태로 변환하는 마이그레이션 스크립트를 제공합니다. 코드 베이스의 메타데이터와 브랜치 그래프를 유지한 채 바이너리 청크 스토리지로 이전할 수 있습니다.