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

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

게임 개발에서는 소스 코드와 함께 텍스처, 3D 메시, 씬 데이터, 오디오 같은 바이너리 에셋을 관리해야 하는 경우가 많다. 프로젝트에 따라 파일 크기와 협업 방식이 달라 버전 관리 도구도 워크플로에 맞춰 선택해야 한다.

에셋 종류와 협업 방식이 다른 만큼 VCS마다 장단점이 있고, 팀은 작업 흐름과 운영 요구를 함께 비교해야 한다.

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

    Git --> G1["분산 아키텍처 및 강력한 브랜치"]
    Git --> G2["대용량 파일에 Git LFS와 선택적 체크아웃 설정 필요"]

    P4 --> P1["중앙 집중식 파일 잠금 및 대규모 에셋 제어"]
    P4 --> P2["상용 라이선스와 서버 운영 조건 검토"]

    Lore --> L1["오픈소스 중앙 집중식 및 Rust 엔진"]
    Lore --> L2["콘텐츠 주소화, 머클 트리, 조각 단위 저장"]

Git & Git LFS: Git은 분산 버전 관리 시스템이며, Git LFS는 대용량 파일 내용을 별도 저장소에 두고 Git에는 포인터를 기록한다. 전체 이력과 작업 트리의 크기는 저장소 구성과 사용 방식에 따라 달라지므로, 대규모 프로젝트에서는 Git LFS와 선택적 체크아웃을 함께 검토해야 한다.
Perforce (Helix Core): Helix Core는 중앙 서버 기반 버전 관리 시스템으로, 워크스페이스 뷰와 파일 잠금 기능을 제공한다. 라이선스와 운영 비용은 배포 및 계약 조건에 따라 달라지므로 팀 규모와 호스팅 방식을 포함해 직접 비교해야 한다.

이런 선택지를 비교할 때 함께 살펴볼 수 있는 도구가 에픽게임즈의 오픈소스 버전 관리 시스템 Lore다.

Lore의 탄생 배경과 정체성

Lore는 에픽게임즈가 관리하는 오픈소스 버전 관리 시스템이다. 에픽게임즈 문서에 따르면 Lore는 이전에 Unreal Revision Control (URC)로 불렸으며 UEFN에 내장되어 있다. 다만 현재 공개 오픈소스 도구는 UEFN이 사용하는 압축 형식과 호환되지 않아 UEFN 프로젝트에 연결할 수 없다. 공개 문서는 사용자·프로젝트·저장 용량의 구체적인 규모를 제시하지 않으므로 여기서는 성능이나 운영 규모를 단정하지 않는다.

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

공개된 Lore는 중앙 집중식 저장소, 콘텐츠 주소화, 머클 트리, 조각 단위 저장을 조합한다. 이를 Git이나 Perforce의 대체 표준으로 단정하기보다는 현재 공개된 기능과 아직 진행 중인 로드맵을 나누어 살펴보는 편이 정확하다.

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

중앙 집중식 구조는 다음과 같은 운영 특성을 가진다. 이것을 Lore 팀이 선택한 동기의 공식 설명으로 단정하지 않고, 분산형 VCS와 비교할 때 고려할 점으로 읽어야 한다.

작업 복사본의 범위 선택: Lore는 sparse 작업 복사본을 지원하므로 필요한 범위만 선택해 가져올 수 있다. 공개 문서상 현재는 범위를 미리 선택하는 방식이며, 파일을 열 때 자동으로 가져오는 가상 파일 시스템(VFS)은 로드맵의 진행 중 항목이다.
접근 제어 경계: Lore의 설계는 하위 저장소(partition) 단위 접근 제어를 지원한다. 다만 디렉터리 접근을 업무 흐름에서 직접 구성하는 기능은 현재 공개 문서에서 데이터 모델과 별도로 작업 중인 항목으로 설명한다.
바이너리 충돌 관리: Lore에는 기본 잠금 기능이 있지만 현재 잠금은 협업자에게 알리는 용도이며 서버가 동시 수정을 강제 차단하지 않는다. 확장 가능한 잠금 강제는 로드맵에 있다.

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

Lore의 공개 설계 문서는 게임과 미디어의 대용량 바이너리 작업을 고려한 저장 구조를 설명한다. 주요 특징은 다음과 같다.

flowchart TD
    Client["Lore CLI / API"] -->|저장소 작업 및 기본 잠금 상태| Server["Lore 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 (BLAKE3 address)"]
        C2["Chunk B (BLAKE3 address)"]
        C3["Chunk C (BLAKE3 address)"]
    end

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

1. Rust로 작성된 공개 구현

공식 문서는 공개된 정식 구현을 Rust 라이브러리, 서버, CLI로 설명한다. 언어만으로 처리량이나 지연 시간, 동시 사용자 규모를 보장할 수는 없으므로 실제 프로젝트에서는 저장소 규모와 네트워크 조건을 반영해 부하 테스트해야 한다.

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

Lore는 콘텐츠 주소화 저장소(CAS)를 사용한다. 공식 시스템 설계 문서는 콘텐츠 주소 함수로 BLAKE3를 사용한다고 명시한다. 이는 데이터 식별과 무결성 확인에 쓰이는 해시이지 암호화가 아니다.

조각 단위 저장과 재사용: 공식 설계는 큰 파일을 조각으로 나누어 중복되는 내용을 재사용하도록 설명한다. 전송량이나 성능 향상 폭은 실제 파일과 배포 구성에 따라 다르다.
해시 기반 검증: 콘텐츠 해시는 저장된 데이터의 식별과 검증에 사용된다. 백업, 저장 매체의 장애 대응, 전송 안정성까지 해시만으로 보장되는 것은 아니다.

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"]

리비전은 머클 트리와 부모 리비전 해시를 포함하는 구조로 표현된다. 비교 속도는 저장소와 작업에 따라 달라지므로 공개된 성능 수치 없이 “초고속”을 보장한다고 말할 수 없다.
과거 리비전을 참조할 수 있지만, 같은 소스 상태만으로 빌드가 재현되는 것은 아니다. 빌드 도구·의존성·환경도 별도로 고정해야 한다.

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

Lore는 필요한 파일 범위를 선택하는 sparse 작업 복사본을 지원한다. 다만 공개 로드맵은 현재 작업 범위를 복제 전에 선택해야 하며, 파일을 열 때 자동으로 가져오는 가상 파일 시스템은 아직 진행 중인 기능으로 설명한다.

선택한 범위의 파일을 작업 복사본으로 가져오는 방식과 파일 단위 지연 가져오기를 혼동하지 않아야 한다. 초기 동기화 시간 단축 폭을 보여 주는 공개 벤치마크는 확인되지 않았다.

Git vs Perforce vs Lore 비교 분석

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

비교 항목	Git (+ Git LFS)	Perforce Helix Core	Epic Games Lore
저장소 아키텍처	분산형 (Distributed)	중앙 집중식 (Centralized)	중앙 집중식 (Centralized)
라이선스 모델	Git은 GPLv2 계열(일부 구성 요소는 호환 라이선스), Git LFS는 MIT	P4(구 Helix Core)는 최대 5명·20개 워크스페이스까지 무료이며 그 이상은 현재 요금·배포 조건을 확인	오픈소스 (MIT)
대용량 바이너리	Git LFS 별도 구성 가능	대용량 파일 워크플로 지원	콘텐츠 주소화·조각 저장을 설계 목표로 제공
부분 작업 복사본	Sparse checkout 제공	클라이언트 워크스페이스 뷰 제공	현재 범위를 지정하는 sparse 복사본 지원; VFS는 로드맵
파일 잠금	Git LFS Lock API	파일 잠금 기능	현재 알림용 기본 잠금; 강제 잠금은 로드맵
부분 권한 제어	기본 Git 저장소는 복제된 저장소 경계	보호 경로와 권한 설정	partition 설계 지원; 워크플로 통합은 진행 중
편집기 통합	다양한 외부 도구	P4V 등 외부 도구	CLI와 API 제공; Unreal Editor 플러그인은 로드맵

Lore 실무 워크플로 및 CLI 개념

아래는 Epic의 공개 CLI 빠른 시작 문서에 나온 명령을 간추린 예다. sparse 범위 설정과 잠금 옵션은 CLI 버전과 설정에 따라 달라질 수 있으므로 최신 명령 참조를 확인한다.

# 로컬 Lore 서버에 저장소 만들기
lore repository create lore://127.0.0.1:41337/my-project

# 파일 추가 후 스테이징 및 커밋
lore stage Content/Characters/Hero/Hero_Mesh.uasset
lore commit "Update hero mesh"

# 서버와 동기화하고 브랜치 작업
lore push
lore branch create character-work
lore branch switch character-work
lore sync

flowchart LR
    A["lore repository create"] --> B["lore stage"]
    B --> C["lore commit"]
    C --> D["lore push"]
    D --> E["branch create and switch"]
    E --> F["edit, stage, commit"]
    F --> G["merge and sync"]

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

Lore는 pre-1.0 단계로, API와 프로토콜이 바뀔 수 있다. 실무 도입 전에는 공식 FAQ와 로드맵에서 현재 지원 범위와 미완성 기능을 확인해야 한다.

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

Lore는 현재 pre-stable 0.x 단계다. 공식 FAQ는 팀 배포를 위한 인증 및 저장소 백엔드 구성을 설명하지만 LDAP/SSO 통합, 관리자 대시보드, 엔터프라이즈 백업 도구의 상태를 여기서 단정하지 않는다. 배포 전 필요한 항목을 공식 서버 설정 문서와 이슈에서 확인해야 한다.

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

UEFN에 내장된 Lore와 공개 Lore 도구는 현재 압축 형식 차이로 호환되지 않는다. Unreal Editor 플러그인은 공개 로드맵상 진행 중인 항목이며, Unity 등 타 엔진은 CLI 또는 공개 API를 이용한 통합을 별도로 검토해야 한다.

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

CI/CD 연결은 공개 CLI 또는 API를 사용하는 방식으로 설계할 수 있다. 이 문서에서 특정 Lore 전용 빌드 팜 에이전트의 공식 제공 여부는 확인하지 않았으므로 도입 전에 현재 SDK와 API를 확인한다.

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

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

소규모 또는 코드 중심 프로젝트: 기존 팀 숙련도와 호스팅·백업 요구에 따라 Git 계열 도구를 평가한다.
대용량 바이너리 프로젝트: Lore, Perforce Helix Core, Git LFS 등 후보를 실제 저장소 표본으로 시험하고 잠금, 복구, 권한, 클라이언트 통합을 확인한다.
Lore 평가: pre-1.0 상태와 현재 UEFN 호환성 한계를 감안해, 프로덕션 전 파일럿에서 필요한 워크플로와 운영 요구를 검증한다.

마치며

에픽게임즈의 Lore는 게임과 미디어 프로젝트의 코드 및 대용량 바이너리 작업을 겨냥한 오픈소스 중앙 집중식 VCS다. 공개 설계는 콘텐츠 주소화와 조각 단위 저장, Merkle 트리, sparse 작업 복사본을 포함한다.

온디맨드 파일 시스템과 편집기 통합 등 일부 기능은 공개 로드맵에 남아 있으며, 성능 향상 폭을 보여 주는 독립 벤치마크는 이 글에서 제시하지 않는다. 관심 있는 팀은 공식 빠른 시작 문서로 기능을 확인하고 자신의 저장소에서 파일럿 테스트를 수행해야 한다.