State of Unreal 2026에서 눈에 띈 소식은 Unreal Engine 6나 UE 5.8만이 아니었습니다. Epic Games는 2026년 6월 17일 행사 정리 글에서 Lore라는 오픈소스 버전관리 시스템을 함께 공개했습니다.
겉으로는 “또 하나의 버전관리 툴”처럼 보일 수 있지만, 게임 개발 현장에서 보면 이 소식은 꽤 현실적인 의미가 있습니다. 코드만 관리하는 팀이 아니라, 레벨 파일, 캐릭터 에셋, 애니메이션, 텍스처, VFX 소스, 대용량 바이너리 파일을 같이 다루는 팀에게는 버전관리 자체가 제작 속도와 스트레스에 직접 연결되기 때문입니다.

1. Lore는 코드와 바이너리 에셋을 같이 보는 버전관리 시스템입니다
Epic이 소개한 Lore의 핵심은 “소스코드용” 또는 “바이너리 에셋용”으로 한쪽에 치우친 시스템이 아니라는 점입니다. 공식 Lore 페이지도 게임과 엔터테인먼트처럼 코드와 대용량 바이너리 에셋이 섞인 프로젝트를 주요 대상으로 설명합니다.
게임 개발에서는 이 차이가 큽니다. Git은 코드 협업에는 익숙하지만, 대형 텍스처, DCC 소스, 레벨 데이터, 바이너리 에셋을 다룰 때는 Git LFS나 별도 규칙을 조심스럽게 붙여야 합니다. 반대로 Perforce 계열 워크플로우는 게임 업계에서 오래 쓰였지만, 작은 팀이나 개인 개발자에게는 운영 부담이 크게 느껴질 수 있습니다.
Lore가 당장 모든 팀의 표준이 된다는 뜻은 아닙니다. 다만 Epic이 “게임 제작에서 버전관리는 코드 문제가 아니라 제작 파이프라인 문제”라고 공개적으로 다시 짚은 것만으로도 의미가 있습니다.
2. 아티스트와 개발자가 같은 흐름 안에서 움직일 수 있느냐가 핵심입니다
VFX, 테크니컬 아트, 환경 아트 작업에서는 한 파일이 작게 보이지 않습니다. Niagara 시스템 하나를 고쳐도 머티리얼, 텍스처, 블루프린트, 레벨 배치, 시퀀서 컷까지 이어질 수 있습니다. 디자이너가 밸런스를 조정하는 동안 아티스트가 같은 맵 에셋을 수정하고, 프로그래머가 관련 시스템을 바꾸는 상황도 흔합니다.
그래서 버전관리는 단순히 “백업이 된다”의 문제가 아닙니다.
- 누가 어떤 에셋을 건드리고 있는지 알 수 있는가
- 대용량 파일 수정이 팀 전체 동기화 시간을 잡아먹지 않는가
- 브랜치를 만들어 실험하고 다시 돌아오는 일이 부담스럽지 않은가
- 깨진 에셋이나 잘못된 수정이 들어왔을 때 원인을 추적할 수 있는가
이 네 가지가 제작 속도를 크게 좌우합니다. Lore가 내세우는 chunked storage, on-demand hydration, lightweight branches 같은 방향은 결국 “필요한 데이터만 빠르게 가져오고, 큰 에셋도 덜 낭비하면서, 팀 단위 실험을 쉽게 만들자”는 쪽에 가깝습니다.

3. 소규모 팀은 지금 당장 갈아타기보다 관찰하고 실험하는 쪽이 맞습니다
중요한 주의점도 있습니다. Lore는 현재 pre-1.0 단계입니다. 공식 FAQ에서도 API와 프로토콜이 1.0 전까지 바뀔 수 있다는 점을 밝히고 있습니다. 즉, 상용 프로젝트의 중심 버전관리 시스템을 당장 전부 교체하라는 신호로 받아들이기에는 이릅니다.
현실적인 접근은 이렇습니다.
- 기존 Git, Perforce, Plastic SCM, Unity Version Control 워크플로우는 유지합니다.
- 테스트용 프로젝트나 툴 제작용 샘플에서 Lore의 구조를 살펴봅니다.
- 대용량 바이너리 에셋, 브랜치 실험, sparse workspace, API 연동 같은 관점에서 기존 툴과 비교합니다.
- 팀 내 아티스트가 실제로 이해하고 쓸 수 있는 UX가 나오는지 봅니다.
개인적으로는 “오픈소스라서 좋다”보다 “게임 제작에서 버전관리를 다시 제품 수준의 문제로 보고 있다”는 점이 더 중요해 보입니다. 작은 팀도 나중에는 에셋 수가 폭발하고, 그때부터 버전관리 규칙을 고치려면 비용이 큽니다.
4. VFX와 기술 아트 입장에서는 포트폴리오 관리에도 연결됩니다
VFX 아티스트나 테크니컬 아티스트에게도 버전관리는 꽤 현실적인 포트폴리오 주제입니다. 좋은 이펙트 하나를 만들 때도 최종 영상만 남기는 것보다, 어떤 버전에서 쉐이더가 바뀌었고, 어떤 버전에서 파티클 수를 줄였고, 어떤 버전에서 GPU 비용을 줄였는지 남겨두면 훨씬 강한 제작 기록이 됩니다.
특히 Material, Shader, Niagara 작업은 “최종 결과”와 “최적화 과정”이 함께 설득력을 만듭니다. Lore 같은 시스템이 아니더라도, 앞으로는 포트폴리오 작업에서도 이런 습관을 들이는 편이 좋습니다.
- 실험 브랜치와 최종 브랜치를 나눕니다.
- 중요한 셰이더 변경은 짧은 메모와 스크린샷을 같이 남깁니다.
- 성능 개선 전후의 수치와 뷰포트 캡처를 보관합니다.
- 팀 작업이라면 에셋 잠금, 리뷰, 롤백 규칙을 문서화합니다.
이건 취업 포트폴리오에도 도움이 되고, 나중에 블로그나 유튜브 교육 콘텐츠로 풀어내기에도 좋습니다. 단순히 “멋진 결과물”이 아니라 “제작 판단을 어떻게 쌓았는지”를 보여줄 수 있기 때문입니다.

5. 이번 소식은 UE6보다 조용하지만, 제작 현장에는 꽤 실용적입니다
게이머 입장에서는 버전관리 시스템이 직접 보이지 않습니다. 하지만 개발팀 입장에서는 이런 기반 툴이 게임 품질에 영향을 줍니다. 빌드가 자주 깨지지 않고, 에셋 충돌이 줄고, 실험을 빨리 해볼 수 있으면 결국 더 안정적인 콘텐츠와 더 빠른 업데이트로 이어질 수 있습니다.
Epic이 Lore를 공개한 건 UE6의 미래 비전과도 연결됩니다. 더 큰 팀, 더 많은 기여자, 더 복잡한 에셋, 더 다양한 플랫폼을 다루려면 엔진 기능만 좋아서는 부족합니다. 콘텐츠가 만들어지고, 저장되고, 검토되고, 배포되는 파이프라인 전체가 같이 좋아져야 합니다.
다음에 확인할 지점
Lore는 아직 “내일부터 모든 팀이 바꿔야 하는 툴”은 아닙니다. 하지만 게임 개발자, 아티스트, 디자이너, 테크니컬 아티스트가 함께 일하는 방식을 다시 생각하게 만드는 신호로는 충분히 의미가 있습니다.
VFX Diary 관점에서 보면 이번 소식의 포인트는 명확합니다. 툴 자체보다 중요한 것은 대용량 에셋과 반복 실험을 어떻게 관리할지입니다. Niagara, Material, Shader, 레벨 아트, 캐릭터 애니메이션이 복잡해질수록 “버전관리도 제작 기술”이라는 감각이 더 중요해질 것 같습니다.
참고 출처
- Epic Games, “State of Unreal 2026: Top news from the show”, 2026년 6월 17일: https://www.unrealengine.com/news/state-of-unreal-2026-top-news-from-the-show
- Lore 공식 사이트: https://lore.org/
- EpicGames/lore GitHub 저장소: https://github.com/EpicGames/lore
- Lore FAQ: https://epicgames.github.io/lore/faq/
- Lore 시스템 디자인 문서: https://epicgames.github.io/lore/explanation/system-design/