에픽게임즈의 오픈소스 VCS 'Lore' 아키텍처 분석: Git과 Perforce 사이의 대안

게임 개발 버전 관리(VCS)의 영원한 딜레마

현대 게임 개발 파이프라인은 소프트웨어 엔지니어링과 대규모 디지털 아트 프로덕션이 결합된 복합적인 환경이다. 수백만 줄의 C++ 및 셰이더 코드뿐만 아니라 기가바이트 단위의 고해상도 텍스처, 3D 메시, 씬(Level/Map) 데이터, 비압축 오디오가 단일 프로젝트 내에서 유기적으로 맞물려 작동한다.

이러한 특성 때문에 게임 스튜디오는 오랜 기간 버전 관리 시스템(VCS)을 선택할 때 극단적인 타협을 강요받아 왔다.

flowchart TD
    VCS["게임 개발 VCS 아키텍처 비교"] --> Git["Git 및 Git LFS"]
    VCS --> P4["Perforce Helix Core"]
    VCS --> Lore["Epic Games Lore"]

    Git --> G1["분산 아키텍처 및 강력한 브랜치"]
    Git --> G2["대용량 바이너리 처리 한계 및 전체 복제 오버헤드"]

    P4 --> P1["중앙 집중식 파일 잠금 및 대규모 에셋 제어"]
    P4 --> P2["고가의 상용 라이선스 및 온프레미스 운영 부담"]

    Lore --> L1["오픈소스 중앙 집중식 및 Rust 엔진"]
    Lore --> L2["CAS 및 머클 트리 기반 바이너리 스트리밍"]

Git & Git LFS: 소프트웨어 개발의 표준이자 분산 버전 관리의 대표주자이지만 모든 클라이언트가 전체 커밋 히스토리를 로컬에 보유해야 하는 분산 모델 특성상 테라바이트 단위의 게임 에셋을 감당하기 어렵다. Git LFS(Large File Storage) 포인터 방식으로 완화하더라도 브랜치 전환 지연, 대역폭 낭비, 복잡한 메타데이터 동기화 문제가 지속된다.
Perforce (Helix Core): 중앙 집중식 파일 잠금(Locking)과 부분 체크아웃(Sparse Checkout)으로 AAA 게임 업계의 사실상 표준이 되었지만 사용자당 부과되는 막대한 라이선스 비용, 온프레미스 서버 운영의 높은 유지보수 난이도, 폐쇄적인 생태계로 인해 인디 및 중소규모 스튜디오에게 큰 진입장벽이다.

이러한 양극단 사이에서 에픽게임즈(Epic Games)가 공식 오픈소스로 공개한 차세대 버전 관리 시스템이 바로 Lore다.

Lore의 탄생 배경과 정체성

Lore는 단순한 연구용 프로젝트나 프로토타입이 아니다. 에픽게임즈 내부에서 Unreal Revision Control (URC)이라는 이름으로 개발되어 수백만 크리에이터가 수천만 개의 섬(Island) 프로젝트와 페타바이트 단위 에셋을 실시간으로 협업하는 포트나이트 언리얼 에디터(UEFN, Unreal Editor for Fortnite)의 백엔드 저장소로 장기간 실전 검증을 거쳤다.

flowchart TD
    URC["Unreal Revision Control (URC) in UEFN"] -->|오픈소스 아키텍처 전환| Lore["Epic Games 'Lore' VCS (Written in Rust)"]

에픽게임즈는 2026년 이 코어 엔진을 오픈소스로 공개하며 Git의 현대적인 데이터 무결성 모델과 Perforce의 게임 최적화 중앙 집중식 워크플로를 결합한 새로운 표준을 제시했다.

왜 ‘중앙 집중식(Centralized)‘을 선택했는가?

Git이 대세가 된 시대에 Lore가 중앙 집중식 아키텍처를 채택한 이유는 게임 개발의 현실적인 제약조건 때문이다.

테라바이트급 에셋의 로컬 복제 방지: 아트 디자이너나 기획자에게 수백 GB 이상의 전체 프로젝트 이력을 내려받게 하는 것은 비효율적이다. 중앙 서버가 원본을 유지하고 클라이언트는 필요한 작업본만 동기화해야 한다.
엄격한 접근 제어 및 보안(NDA/외주 협업): 분산 VCS에서는 저장소를 복제하면 전체 히스토리가 노출된다. 반면 중앙 집중식 시스템에서는 디렉터리 및 브랜치 단위로 세분화된 접근 권한(Subtree Access Control)을 강제할 수 있어 외주 파트너와의 협업에 필수적이다.
바이너리 충돌 방지(배타적 잠금): 코드는 병합(Merge)이 가능하지만 3D 모델이나 텍스처 같은 바이너리는 3-way 병합이 불가능하다. 중앙 서버가 실시간 잠금 상태를 관리해야 동시 수정 사고를 원천 차단할 수 있다.

Lore의 핵심 기술 아키텍처 분석

Lore는 현대적인 분산 시스템 기법과 게임 엔진의 I/O 특성을 깊이 이해하고 설계된 시스템이다. 주요 아키텍처 특징은 다음과 같다.

flowchart TD
    Client["Lore Client / Editor Plugin"] -->|청크 단위 동기화 및 잠금| Server["Lore Central Server"]
    
    subgraph StorageEngine["Lore Storage Engine"]
        CAS["Content-Addressed Storage"]
        MT["Merkle Tree Hierarchy"]
        RC["Immutable Revision Chain"]
    end

    Server --> CAS
    Server --> MT
    Server --> RC

    subgraph DataLayout["Data Chunking and Deduplication"]
        C1["Chunk A (SHA-256)"]
        C2["Chunk B (SHA-256)"]
        C3["Chunk C (SHA-256)"]
    end

    CAS --> C1
    CAS --> C2
    CAS --> C3

1. Rust 기반의 고성능 코어 엔진

Lore의 서버 및 클라이언트 코어는 Rust로 작성되었다.

무비용 추상화와 메모리 안정성: 가비지 컬렉션(GC) 일시 중단 없이 테라바이트급 I/O 스트림을 안전하고 빠르게 처리한다.
초동시성 I/O 처리: 비동기 런타임(Tokio 기반)을 활용하여 수백 명의 클라이언트가 동시에 기가바이트급 에셋을 업로드/다운로드하더라도 병목을 최소화한다.

2. 내용 주소화 저장소 (Content-Addressed Storage, CAS)

Lore는 모든 파일과 디렉터리를 내용의 암호화 해시(Content Hash)를 식별자로 사용하는 CAS 구조로 관리한다.

블록/청크 단위 중복 제거(Deduplication): 대형 바이너리 파일이 일부만 수정되었을 때 전체 파일을 다시 전송하는 대신 변경된 청크만 전송하고 저장한다.
데이터 무결성 자동 보증: 네트워크 전송 중 손상된 패킷이나 디스크 배드섹터로 인한 에셋 오염을 해시 검증을 통해 즉각 감지한다.

3. 머클 트리(Merkle Tree) 기반의 불변 리비전 체인

Git과 마찬가지로 Lore는 특정 시점의 전체 프로젝트 상태를 머클 트리(Merkle Tree)로 표현한다.

flowchart TD
    Root["Root Commit Merkle Hash"] --> SrcTree["Source Code Tree"]
    Root --> AssetTree["Game Assets Tree"]

    SrcTree --> C1["Player.cpp"]
    SrcTree --> C2["AI.cpp"]

    AssetTree --> A1["Hero.uasset"]
    AssetTree --> A2["Level.umap"]

파일 하나가 변경되면 상위 노드의 해시만 재계산되므로 수십만 개의 파일이 존재하는 대형 프로젝트에서도 초고속 상태 비교(Diff)가 가능하다.
이전 리비전은 불변(Immutable) 상태로 보존되어 특정 시점으로의 안전한 롤백과 일관된 빌드 재현성을 보장한다.

4. 바이너리 퍼스트 가상 파일 시스템 & 스파스 체크아웃

Lore는 대규모 오픈월드 맵이나 캐릭터 에셋 라이브러리 전체를 로컬에 다운로드하지 않고도 작업할 수 있도록 가상화된 스파스 체크아웃(Sparse Checkout)을 기본 지원한다.

클라이언트는 디렉터리 메타데이터만 빠르게 동기화한 뒤 언리얼 엔진이나 DCC 툴에서 실제로 여는 파일만 온디맨드(On-demand)로 스트리밍 받아 로컬 캐시에 저장한다.
이를 통해 신규 입사자나 외주 작업자의 초기 저장소 동기화(Initial Sync) 시간을 수 시간에서 수 분 단위로 단축시킨다.

Git vs Perforce vs Lore 비교 분석

세 시스템의 기술적 특성과 워크플로 차이를 표로 정리하면 다음과 같다.

비교 항목	Git (+ Git LFS)	Perforce Helix Core	Epic Games Lore
저장소 아키텍처	분산형 (Distributed)	중앙 집중식 (Centralized)	중앙 집중식 (Centralized)
라이선스 모델	오픈소스 (GPL/MIT)	상용 독점 (고가 라이선스)	오픈소스 (Permissive)
주요 구현 언어	C, Shell, Rust(일부 툴)	C++	Rust
대용량 바이너리 지원	포인터 분리 (LFS 필수, 비효율)	네이티브 지원 (탁월)	네이티브 CAS & 청크 스트리밍
스파스 체크아웃	지원하나 설정 복잡, 느림	워크스페이스 뷰 기반 네이티브	메타데이터 기반 온디맨드 스트리밍
파일 배타적 잠금	LFS Lock 지원 (수동적)	강력한 중앙 서버 강제 잠금	중앙 서버 기반 잠금 지원
부분 권한 제어 (보안)	미지원 (전체 복제)	디렉터리/파일별 정밀 권한	중앙 서버 기반 하위 트리 제어
생태계 및 UI 도구	GitHub, GitLab, 수많은 GUI	P4V, 대형 스튜디오 파이프라인	언리얼 엔진 통합 및 CLI (확장 중)

Lore 실무 워크플로 및 CLI 개념

Lore는 명령줄 인터페이스(CLI) 및 엔진 플러그인을 통해 직관적인 워크플로를 제공한다.

# 1. 중앙 Lore 서버에서 특정 프로젝트 워크스페이스 초기화 (스파스 모드)
lore clone https://lore.studio-internal.com/projects/ProjectTitan --sparse

# 2. 작업할 특정 캐릭터 에셋 폴더만 온디맨드 동기화
lore sync Content/Characters/Hero/

# 3. 바이너리 에셋 수정 전 배타적 잠금(Lock) 획득
lore lock Content/Characters/Hero/Hero_Mesh.uasset -m "Skinning rework by Alex"

# 4. 파일 수정 후 상태 확인 및 커밋 (CAS 청크 업로드)
lore status
lore commit -m "Update hero skeleton and LOD meshes" Content/Characters/Hero/

# 5. 작업 완료 후 잠금 해제
lore unlock Content/Characters/Hero/Hero_Mesh.uasset

flowchart TD
    Step1["1. lore clone --sparse<br/>(프로젝트 워크스페이스 메타데이터 초기화)"] --> Step2["2. lore sync [에셋경로]<br/>(작업 대상 에셋 폴더 온디맨드 동기화)"]
    Step2 --> Step3["3. lore lock [에셋파일]<br/>(바이너리 파일 배타적 수정 잠금 획득)"]
    Step3 --> Step4["4. 로컬 에셋 수정 및 저장<br/>(DCC 툴 및 언리얼 에디터 작업)"]
    Step4 --> Step5["5. lore commit -m [커밋메시지]<br/>(CAS 청크 업로드 및 변경 사항 커밋)"]
    Step5 --> Step6["6. lore unlock [에셋파일]<br/>(작업 완료 후 잠금 해제 및 팀 공유)"]

Lore 도입 시 고려사항 및 현재 생태계 상태

Lore는 게임 개발 VCS의 고질적인 문제를 해결할 혁신적인 구조를 갖추고 있으나 실무 프로덕션 도입 전 다음 사항들을 면밀히 검토해야 한다.

1. Pre-1.0 개발 단계와 인프라 성숙도

Lore는 2026년 기준 빠르게 발전하고 있는 단계(Pre-1.0)에 있다. UEFN 백엔드로 기능적 검증은 끝났지만 일반적인 스튜디오 온프레미스/클라우드 자가 호스팅을 위한 관리자 대시보드, 유저 인증 시스템(LDAP/SSO 연동), 엔터프라이즈 백업 툴링은 커뮤니티 및 에픽의 로드맵을 따라 확장되는 중이다.

2. 언리얼 엔진 외 타 엔진(Unity, Godot) 호환성

UEFN 및 Unreal Engine 5 환경에서는 최상의 통합 경험을 제공하지만 Unity나 커스텀 자체 엔진 환경에서 사용하려면 CLI 래퍼 또는 자체 에디터 플러그인을 구성해야 할 수 있다.

3. CI/CD 자동화 및 빌드 파이프라인 구축

Git 기반의 GitHub Actions, GitLab CI나 Perforce 트리거 기반의 빌드 시스템과 마찬가지로 Lore 전용 빌드 팜 에이전트 연동 스크립트를 작성하여 자동화 파이프라인을 검증해야 한다.

스튜디오 환경별 최적의 VCS 선택 가이드

flowchart TD
    Start["VCS 선택 검토"] --> Q1{"프로젝트 성격이 순수 코드 또는 소형 2D 게임인가?"}
    Q1 -->|예| ChoiceGit["Git + GitHub"]
    Q1 -->|아니오| Q2{"수십 명 이상의 대형 스튜디오이며 기존 P4 파이프라인이 확고한가?"}
    Q2 -->|예| ChoiceP4["Perforce Helix Core"]
    Q2 -->|아니오| Q3{"대용량 3D 에셋을 다루며 라이선스 비용 없는 오픈소스 고성능 VCS를 원하는가?"}
    Q3 -->|예| ChoiceLore["Epic Games Lore"]
    Q3 -->|아니오| ChoiceGitLFS["Git + Git LFS"]

소규모 인디 & 코드 중심 프로젝트: 여전히 Git + GitHub/GitLab이 가장 빠르고 유지보수 비용이 적다.
언리얼 엔진 기반 중소·중견 스튜디오: 고가의 Perforce 라이선스가 부담스럽거나 Git LFS의 용량 한계에 부딪혔다면 Lore는 최상의 대안이다. 특히 UEFN 및 UE5 워크플로와의 궁합이 탁월하다.
글로벌 대형 AAA 스튜디오: 기존 인하우스 도구와 P4V 기반 레거시 파이프라인이 깊게 연동되어 있다면 Perforce를 유지하되 신규 프로젝트나 클라우드 기반 협업 팀을 중심으로 Lore의 파일럿 테스트를 진행하는 전략이 권장된다.

마치며

에픽게임즈의 ‘Lore’는 Git의 분산 모델이 가진 바이너리 한계와 Perforce의 독점적 고비용 구조 사이에서 오랫동안 정체되어 있던 게임 개발 VCS 시장에 등장한 가장 주목할 만한 혁신이다.

Rust 기반의 견고한 CAS 저장 엔진, 머클 트리 무결성, 온디맨드 스트리밍 기술은 대규모 3D 실시간 인터랙티브 콘텐츠 제작 파이프라인의 생산성을 크게 끌어올릴 것이다. 게임 개발 인프라를 현대화하고자 하는 테크니컬 디렉터와 빌드 엔지니어라면 Lore의 발전 방향을 주목할 필요가 있다.