Git LFS 및 Perforce 저장소를 Epic Lore로 이전할 때 검토할 사항
Epic Lore의 현재 범위를 고려해 Git LFS 및 Perforce 저장소의 이전 가능성, 무결성 검증, 자체 변환 도구와 전환 절차를 검토합니다.
핵심 요약
Epic Lore는 0.x 단계의 오픈 소스 VCS이며, 공식 문서에서 Git LFS 또는 Perforce 저장소를 변환하는 범용 importer를 제공한다고 안내하지 않습니다. 따라서 아래 내용은 마이그레이션 도구의 설계 체크리스트이지, 그대로 실행할 수 있는 Lore 이전 명령이나 검증된 무중단 전환 절차가 아닙니다.
실제 이전을 추진한다면 1) 무결성·메타데이터 조사, 2) 별도로 구현하고 검증한 변환 도구로 데이터 이전, 3) CI/CD와 락 정책을 시험 환경에서 검증하는 단계로 계획할 수 있습니다. 듀얼 싱크가 데이터 충돌 없이 운영된다고 가정하지 말고 쓰기 주체, 동기화 방향, 복구 지점을 명시해야 합니다.
게임 개발 파이프라인에서 왜 VCS 마이그레이션을 고민하는가?
게임 개발 프로젝트가 고도화될수록 3D 모델, 4K/8K 텍스처, 사운드 뱅크, 프리팹과 같은 바이너리 에셋의 비중이 기하급수적으로 증가합니다.
전통적인 소스 코드 중심의 Git 환경에서는 LFS(Large File Storage) 확장 기능을 사용하더라도 클론/체크아웃 속도 저하와 복잡한 포인터 누락 문제가 발생하기 쉽습니다. 반면 Perforce(Helix Core)는 바이너리 처리와 배타적 잠금(Exclusive Checkout)에 강점이 있지만 브랜치 관리 비용이 높고 분산 오프라인 작업이 어렵습니다.
Lore는 중앙 서버 구조, 바이너리 중심 청크 저장, 희소·온디맨드 워킹 트리와 브랜치를 제공하는 버전 관리 시스템입니다. 다만 현재 파일 락은 협업 상태를 알리는 기본 기능이며 강제 편집 차단은 지원하지 않습니다. 이전 후 빌드 속도나 운영 안정성이 향상되는지는 저장소와 워크플로를 사용해 직접 측정해야 합니다.
| 비교 항목 | Git + Git LFS | Perforce (Helix Core) | Lore |
|---|---|---|---|
| 바이너리 처리 방식 | 메타데이터 포인터 치환 | 서버 중앙 저장 및 스트리밍 | 콘텐츠 기반 청크 분할 스트리밍 |
| 브랜치 오버헤드 | 로컬 브랜치 | Streams 기반 운영 | 가벼운 분기 기능; 대규모 성능은 직접 측정 |
| 파일 잠금 (Locking) | 호스팅에 따라 LFS Lock 지원 | 서버 중심 배타적 체크아웃 | 기본 락 제공; 현재 강제 편집 차단 아님 |
| CI/CD 체크아웃 속도 | 설정과 저장소에 따라 다름 | 프록시 등 구성에 따라 다름 | 실제 빌드 에이전트에서 비교 측정 필요 |
| 인프라 유지보수 | 호스팅 구성에 따라 다름 | 서버 구성에 따라 다름 | 자체 호스팅 구조·스토리지 운영 필요 |
마이그레이션 파이프라인 아키텍처
개념적으로 변환 도구는 커밋/체인지리스트 이력, 브랜치 구조, LFS 포인터와 실제 객체, 락 정책을 조사하고 대상 Lore 저장소와 비교해야 합니다. 이것은 제품에 포함된 “Lore Migration Pipeline” 기능이 아니며, 원본을 보존한 독립 도구와 검증 절차가 필요합니다.
flowchart LR
subgraph Source [기존 저장소]
GL[Git LFS Repository] --> |LFS Pointer & Commit Tree| IE[Inspection Engine]
P4[Perforce Helix Depot] --> |Changelist & Typemap| IE
end
subgraph Transform [변환 파이프라인]
IE --> |무결성 검사| VAL[Validation & Hash Check]
VAL --> |청크 분할 및 역직렬화| CONV[Lore Migration Pipeline]
end
subgraph Target [Lore 시스템]
CONV --> LMeta[(Lore Metadata DB)]
CONV --> LBlob[(Lore Object Storage)]
CONV --> LLock[Live Lock Registry]
end
Git LFS 저장소를 Lore로 변환하는 4단계 절차
Git LFS 프로젝트를 Lore로 이전할 때는 포인터 파일만 존재하고 실제 바이너리 오브젝트가 누락되는 ‘LFS 미러 불일치’ 현상을 사전에 방지해야 합니다.
1단계: LFS 무결성 검증 및 히스토리 정리
먼저 원격 저장소의 모든 LFS 오브젝트가 로컬에 완전하게 캐시되어 있는지 확인하고 누락된 객체를 일괄 다운로드합니다.
# 모든 원격 브랜치 및 태그의 LFS 오브젝트 완전 동기화
git fetch --all --tags
git lfs fetch --all
# LFS 포인터와 실제 바이너리 무결성 검증
git lfs fsck2단계: LFS 추적 규칙(.gitattributes) 분석
.gitattributes에 정의된 필터 설정을 추출하여 Lore의 에셋 정책 정의 파일(lore.attributes)로 변환합니다.
# .gitattributes 예시
*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text lockable
*.psd filter=lfs diff=lfs merge=lfs -text lockable# Pseudocode only: not a Lore CLI command; implement with a supported client API.
read_git_commits_and_branches(source_repository)
resolve_and_verify_all_lfs_objects(source_repository)
write_revisions_using_supported_lore_api(target_repository)
compare_file_hashes_and_revision_inventory(source_repository, target_repository)Perforce(P4) 저장소를 Lore로 변환하는 4단계 절차
Perforce 저장소 이전 시에는 typemap에 설정된 +l(배타적 잠금), +k(키워드 확장 방지) 등의 속성을 Lore 메타데이터 규칙으로 정확히 매핑하는 것이 핵심입니다.
1단계: Depot 경로 및 Changelist 범위 설정
마이그레이션 대상 Stream 또는 Depot 경로를 확인하고 이전할 Changelist 범위를 확정합니다.
# P4 변경 이력 및 Typemap 확인
p4 typemap -o > p4_typemap.txt
p4 changes -m 500 //depot/main/GameProject/...2단계: Typemap 규칙을 Lore 에셋 정책으로 매핑
P4 속성을 Lore가 인식할 수 있는 규칙으로 정의합니다. 예를 들어 P4의 binary+l 속성은 Lore의 lock=exclusive 정책으로 치환됩니다.
# lore.rules 매핑 정의
//depot/.../*.uasset -> asset_type=binary, lock=exclusive
//depot/.../*.umap -> asset_type=binary, lock=exclusive
//depot/.../*.cpp -> asset_type=text, merge=auto# Pseudocode only: not a Lore CLI command; implement with a supported client API.
read_perforce_changes_and_depot_files(source_depot)
map_metadata_and_lock_policy()
write_revisions_using_supported_lore_api(target_repository)
compare_file_hashes_and_revision_inventory(source_depot, target_repository)4단계: 사용자 권한 및 락 레지스트리 동기화
현재 열려 있는 P4 파일 상태는 참고용으로 추출할 수 있습니다. Lore 락의 범위와 현재 락이 강제 차단 기능이 아니라는 한계를 고려해 상태를 자동 이관한다고 가정하지 말고, 전환 시점에 편집 충돌을 방지하는 별도 운영 절차를 둡니다.
# 활성 P4 락 추출 후 Lore 락 엔진에 반영
p4 opened -a //depot/main/GameProject/... > opened_locks.txt
# No documented Lore command imports this lock list; review it manually.
CI/CD 빌드 파이프라인 및 라이브 운영 전환 전략
형상관리 시스템 전환 시 빌드 머신들의 체크아웃 스크립트와 캐시 구조를 갱신하지 않으면 라이브 패치 배포가 지연될 수 있습니다.
Jenkins / GitHub Actions 스크립트 갱신
기존 Git LFS의 smudge 단계나 Perforce p4 sync를 바꾸기 전에 설치 버전에서 지원하는 Lore CLI/API로 동기화 흐름을 직접 구성하고 검증합니다. 아래는 실제 GitHub Action이나 Lore CLI 구문이 아니라 작업 단계를 나타내는 예시입니다.
# Workflow concept only; no verified setup action or Lore command is implied.
steps:
- name: Prepare workspace with the installed, documented Lore client
run: ./scripts/prepare-lore-workspace.sh "$REVISION"듀얼 싱크(Dual-Sync) 기반 롤백 플랜
전환 당일 발생할 수 있는 클라이언트 이슈에 대비하여 최소 2주간 듀얼 싱크 브리지를 운영합니다.
- 개발자 커밋 주체 전환: 메인 개발팀의 커밋 권한을 Lore로 일괄 이전합니다.
- 자동 단방향 미러링: Lore의 새로운 커밋 및 에셋 변경 사항을 기존 Git/P4 저장소로 자동 동기화하는 미러 봇을 가동합니다.
- 비상 롤백 절차: 심각한 장애 발생 시 미러 봇을 중단하고 Git/P4의 쓰기 권한을 즉시 복구합니다.
자주 묻는 질문 (FAQ)
Q1. 마이그레이션 도중 이전 작업이 실패하면 기존 저장소 데이터가 훼손되나요?
원본을 읽기 전용으로 두고 별도 도구를 사용하면 원본 변경 위험을 낮출 수 있지만, 공식 Lore importer와 재개 옵션은 확인되지 않았습니다. 변환 도구는 실패 후 재실행, 체크포인트, 부분 결과 검증을 설계·테스트하고 원본 백업을 유지해야 합니다.
Q2. 수십만 개의 커밋과 체인지리스트 히스토리가 빠짐없이 보존되나요?
메타데이터와 병합 토폴로지의 보존 여부는 변환기와 두 제품의 데이터 모델에 달려 있습니다. 작성자, 시각, 메시지, 브랜치 및 병합 관계의 매핑을 정의하고 샘플 변환으로 확인하세요. 이 문서에서 언급한 --prune-unreachable은 Lore 공식 옵션으로 확인되지 않았습니다.
Q3. 전환 후 CI/CD 빌드 머신의 체크아웃 시간은 얼마나 단축되나요?
체크아웃 속도 향상률을 일반화할 공식 수치는 없습니다. 대상 프로젝트의 전체 checkout과 증분 sync를 동일한 기기·네트워크·캐시 조건에서 반복 측정해 전환 여부를 판단하세요.
