Lore와 게임 에셋 캐시: 현재 지원 범위와 별도 분산 캐시 설계

먼저 구분할 점

Lore는 대용량 바이너리와 코드를 함께 관리하도록 설계된 중앙집중형 버전 관리 시스템입니다. 콘텐츠 주소 지정, 조각화, 중복 제거, 공유 저장소를 지원하지만, 공식 문서에는 이 글에서 다루던 Tracker·Seed·개발자 간 P2P 캐시 에이전트가 없습니다. 따라서 이를 Lore의 기본 기능이나 바로 배포할 수 있는 구성으로 안내하면 안 됩니다.

Lore 서버는 클라이언트가 push, clone, conflict resolution을 수행하는 중앙 저장소입니다. 기본 서버는 QUIC/gRPC에 41337 포트(UDP/TCP), HTTP에 41339 포트를 사용합니다. 무구성 실행은 임시 저장소와 재시작 때 바뀌는 자체 서명 인증서를 사용하므로 데모 전용입니다. 영구 환경에서는 공식 배포 가이드에 따라 loreserver와 설정 디렉터리의 local.toml을 구성해야 합니다.

공식 문서에 나온 빠른 데모

다음 설치 명령은 Lore 공식 Quickstart가 안내하는 데모 모드입니다. 운영 서버를 구축하거나 데이터를 보존하는 절차가 아닙니다.

curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash -s -- --demo

서버가 실행 중일 때 새 터미널에서 상태를 확인할 수 있습니다.

curl -i http://127.0.0.1:41339/health_check

공식 Quickstart와 서버 배포 가이드는 첫 Lore 저장소 만들기와 로컬 Lore 서버 배포를 참고하세요. 설정은 서버 바이너리의 기능 및 빌드에 따라 달라집니다. 특히 AWS 같은 플러그인 백엔드는 기본 공개 loreserver에 포함되지 않으므로, 단순히 S3 환경변수나 TOML을 추가하는 것만으로 사용할 수 없습니다.

팀 캐시를 따로 설계할 때

원격 팀의 빌드 파생 데이터나 반복 다운로드를 줄이려면 Unreal Derived Data Cache(DDC), Unity Accelerator, CDN 또는 사내 프록시 캐시처럼 해당 엔진이 공식 지원하는 캐시를 별도로 검토하세요. 이들 캐시의 저장 정책과 Lore 저장소를 한 서비스처럼 묶지 말고, 각각의 캐시 적중률·데이터 무결성·만료 동작을 측정해야 합니다.

P2P 전송 계층을 자체 개발하려면 다음을 먼저 정해야 합니다.

1. 캐시 대상이 Lore 저장소 조각인지, 엔진의 파생 데이터인지, 별도의 빌드 산출물인지 명확히 구분합니다.
2. 원본 서버가 반환한 콘텐츠 해시를 검증하고, 권한 확인 뒤에만 피어에서 데이터를 받도록 설계합니다.
3. 피어 탐색, 인증, TLS, 캐시 퇴거, 불량 피어 차단, 오프라인 복구를 독립적으로 구현하고 부하 테스트합니다.
4. 실제 팀 규모와 네트워크 조건에서 원본 다운로드 대비 효과를 측정합니다. 이 글에는 검증된 성능 수치가 없으므로 특정 절감률이나 가속 배수를 약속하지 않습니다.

이 구성은 Lore 기능이 아니라 별도 제품 또는 내부 도구의 설계 과제입니다. Lore의 공식 로드맵에는 대규모 저장소 워크플로, VFS, 확장 가능한 서버 토폴로지 등이 진행 항목으로 소개되지만, 구체적인 상태는 공식 로드맵과 릴리스 문서를 확인해야 합니다.

운영 전 확인 사항

Lore는 현재 1.0 이전 단계입니다. 배포 시점의 CLI·서버 버전과 공식 문서를 기준으로 설치·저장소·인증·백업 절차를 검증하고, 중요한 데이터를 임시 데모 서버에 보관하지 마세요. 기존 팀이 Perforce나 Git LFS에서 이전할 때는 전체 이력, 락 정책, 에디터 통합, 백업 복구를 작은 시험 저장소에서 먼저 평가한 뒤 전환 여부를 결정하는 편이 안전합니다.