Git은 게임을 다루지 못해서... 에픽게임즈가 'Lore'를 만들었다

BBetter Stack
컴퓨터/소프트웨어창업/스타트업게임/e스포츠

스크립트

00:00:00에픽게임즈는 Git에 질려버린 나머지 자체 버전 관리 시스템을 만들었습니다.
00:00:05이들은 Rust로 시스템을 구축하고 무료로 공개했죠. 이름은 Lore입니다. 그렇습니다,
00:00:10포트나이트를 만든 회사가 Git의 대안을 만든 거죠. 물론 Git도 여전히 훌륭하지만,
00:00:15분명 Git은 코드를 위해 만들어졌습니다. 대부분 텍스트 파일이나 작은 파일이 많고,
00:00:21변경 사항도 보통 몇 줄 단위인 경우에 적합하죠. 게임은 그와는 정반대입니다. 그렇다면
00:00:26Lore는 Git과 어떻게 다르고, 어떻게 사용할 수 있을까요? 한번 알아보죠.
00:00:35요즘에는 방대한 텍스처, 오디오 파일, 비디오, 3D 모델 등
00:00:41수백 메가바이트나 수 기가바이트에 달하는 온갖 바이너리 자산이 쓰입니다. 이런 파일들이
00:00:47수정되기 시작하면 아주 복잡해집니다. 저장소는 커지고, 클론 속도는 느려지며,
00:00:53기록은 거대해지죠. 결국 누군가는 Git LFS를 써야 하지 않냐고 말합니다. Git LFS가 도움은 되지만,
00:01:01이런 종류의 데이터를 위해 설계되지 않은 시스템에 덧붙인 임시방편 같은 느낌을 줍니다.
00:01:06할당량과 대역폭 제한 문제, 기록에 남아있는 오래된 자산들도 골칫거리죠. 그래서
00:01:12많은 스튜디오가 Perforce를 사용합니다. 솔직히 Perforce는 제 기능을 하죠. 많은 게임
00:01:18스튜디오가 사용하는 이유가 있지만, 비싸기도 합니다. 복잡해질 수도 있고요. 설정 규모가 커지면
00:01:24누군가는 항상 이걸 유지 보수하는 전담 인력이 되어야 합니다. Lore는 바로 이런 점을
00:01:29해결하려고 설계되었습니다. 워크플로우를 빠르게 해주는 코딩 도구에 관심이 있다면 구독해 주세요.
00:01:35영상은 계속 올라옵니다. 자, 이제 Lore에 대해 말만 하기보다,
00:01:39멋진 기술이니 직접 실행해서 작동 방식을 보여드리겠습니다. 데모는 설치 명령어
00:01:44하나와 데모 플래그로 시작하며, 여기서 바로 실행해 보겠습니다. 이게 전부입니다. 잠시 후,
00:01:51Lore 서버가 로컬에서 실행됩니다. 클라우드 계정이나 키, 인증서 설정도 필요 없습니다. 여기 포트에서
00:01:57실행 중이죠. 서버가 살아있는지 확인하기 위해 헬스 체크 엔드포인트를 호출해보겠습니다.
00:02:03터미널에서 실행해보죠. 됐습니다. 잘 작동하고 있네요.
00:02:08수동으로 연결해야 할 백그라운드 서비스도, 생성해야 할 인증 토큰도 없습니다.
00:02:14설정 마법사도 없죠. 그냥 실행하면 됩니다. 이제 저장소를 하나 만들어보겠습니다. 폴더를 생성하고,
00:02:22저장소를 만듭니다. 이제 커다란 바이너리 파일을 생성하고 커밋해 보겠습니다.
00:02:27이건 테스트용 파일이지만, 좀 더 큰 파일을 만들어보죠. DD 명령어로
00:02:32데이터 복제를 해보겠습니다. 100메가바이트짜리 파일을 하나의 거대한 객체로 다루는 대신,
00:02:40Lore는 작은 단위(청크)로 쪼갭니다. 청크들은 해시 처리되고 Zstandard로 압축되어
00:02:47콘텐츠 주소 지정 머클 트리(Merkle Tree)에 저장됩니다. 파일의 대부분이 그대로라면
00:02:52Lore는 전체 파일을 다시 저장할 필요가 없습니다. 이미 가진 청크를 재사용하고 변경된 부분만 저장하죠.
00:02:58이것이 거대한 바이너리 자산에 훨씬 적합한 방식입니다. 커밋이 끝나면
00:03:04디스크에 생성된 로컬 상태를 확인할 수 있습니다. 여기에 설정과 메타데이터가 담긴 Lore 디렉토리가 생겼죠.
00:03:10자, 이제 브랜치를 만들어보겠습니다. 'Lore branch create'를 실행해 브랜치 이름을 짓습니다.
00:03:17Git과 거의 비슷하게 작동하죠. 브랜치를 전환하고 작은 변경을 해보겠습니다.
00:03:24간단한 텍스트 파일을 만들고 브랜치에 커밋하겠습니다. 수정하고, 스테이징하고,
00:03:31커밋합니다. 이 과정도 Git과 대략 비슷합니다. 이제 다시 전환해보겠습니다.
00:03:37거의 즉각적이네요. 중요한 점은 이 모든 과정에서 서버 통신이 필요 없었다는 겁니다.
00:03:44스테이징, 커밋, 브랜칭, 전환, 차이 비교까지 모두 로컬에서 이루어집니다. 그래서
00:03:50Lore는 중앙 서버가 있지만, 일상적인 작업은 매우 빠르고 오프라인에서도 계속 일할 수 있습니다.
00:03:56전체적으로 아주 가벼운 느낌을 줍니다. 이제 궁금한 점은,
00:04:02데이터가 어디로 가느냐 하는 것입니다. 이 데모에서는 모든 것이 임시적이라 서버를 끄면
00:04:08데이터가 사라집니다. 데모 모드를 사용 중이기 때문이죠. 실제 환경에서는 설정 파일과
00:04:15지속성 저장소와 함께 Lore 서버를 실행하게 됩니다. CLI 명령어나 로컬 워크플로우는
00:04:21완전히 동일합니다. 그냥 임시 폴더를 버리는 대신 실제 디렉토리나 객체 저장소를
00:04:27서버에 지정하는 것뿐입니다. Git은 프로젝트 스냅샷의 기록을 제공합니다. 내부적으로는
00:04:34영리한 최적화를 많이 하지만, Lore는 처음부터 청크 단위 저장과 중복 제거를 기반으로 설계되었습니다.
00:04:40그래서 거대한 자산이 많은 프로젝트에서 파일의 새로운 버전을 매번 완전히 새로운
00:04:47거대 객체로 취급할 필요가 없죠. Lore는 파일을 필요할 때만 가져오는(하이드레이션) 기능도 있어
00:04:53엄청난 양의 데이터를 포함한 저장소에서도 첫날부터 모든 자산을 다운로드할 필요가 없습니다.
00:04:59실제 작업 중인 프로젝트 부분에 필요한 파일만 받아오면 됩니다.
00:05:03Lore 출시 당시 좀 헷갈렸던 부분이 이게 중앙 집중형인지
00:05:08분산형인지였는데요. 중앙 집중형입니다. 하나의 기록 서버가 존재하지만 대부분의 작업은
00:05:15로컬에서 이루어집니다. 따라서 실제로는 Perforce와 Git 사이 어딘가에 위치합니다. 중앙 통제와
00:05:22권한 관리는 중앙에서 하되, 로컬 작업은 빠르고 서버 상태에 매초 의존하지 않아도 되죠.
00:05:28좋은 차이점들도 있습니다. Lore는 MIT 라이선스이고, 프로토콜이 오픈 소스이며,
00:05:34여러 언어용 SDK가 있어 스크립트 작성이나 도구 구축이 훨씬 쉽습니다.
00:05:39이제 현실적인 이야기를 좀 해보죠. 내일 당장 실무의 Perforce 환경을 Lore로
00:05:45바꾸지는 않을 겁니다. 아직 1.0 이전 버전이니까요. 에픽게임즈는 첫 안정 버전 전까지 API가
00:05:52변경될 수 있다고 했고 프로젝트는 분명 계속 발전 중입니다. 아직 Git과의
00:05:58상호 운용성도 없고, 기존 Git 저장소를 Lore로 지정해서 전체 기록을 가져올 수도 없습니다.
00:06:03자체 호스팅 방식이죠. 계정을 만들고 리포를 올리면 끝나는 호스팅 서비스는 없습니다.
00:06:09그리고 여기저기서 보이는 데스크톱 앱은 오픈 소스 릴리즈에 포함되어 있지 않습니다.
00:06:15핵심 라이브러리, 서버, CLI, SDK만 제공됩니다. GUI는 포함되지 않습니다.
00:06:22그리고 성능이죠. 성능은 어떤가요? 에픽은 Lore가 다른 시스템처럼 느려지지 않으면서
00:06:28거대한 저장소를 처리할 수 있다고 합니다. 에픽은 분명 매우 큰 프로젝트를 다뤄본
00:06:33경험이 있죠. 하지만 현재 이런 주장들은 에픽 측에서 나오는 이야기입니다. 신뢰할 만한
00:06:39독립적인 벤치마크는 아직 없어요. 따라서 성능은 유망해 보이지만 제대로
00:06:45테스트를 시작하기 전까지는 실제 성능을 알기 어렵습니다. 사용해야 할까요? 재미로 써보기엔
00:06:50괜찮습니다. 게임을 만들고 있나요? 거대한 프로젝트를 하고 있나요? 새로운 프로젝트라면 고려해볼 만합니다.
00:06:56대형 바이너리 자산 버전 관리가 어디로 향하고 있는지 궁금하다면 시도해 볼 가치가 있습니다.
00:07:01중요하지 않은 프로젝트에서 테스트해 보고, 가지고 놀면서 성능과 작업 흐름을 확인해보세요.
00:07:07여기서 더 큰 요점은 Lore가 당장 Git이나 Perforce를 대체할 수 있느냐가 아닙니다.
00:07:14프로젝트들이 거대한 양의 바이너리 데이터를 포함해서 출시되기 시작하면서, 기존 버전 관리는
00:07:19더 이상 풀린 문제가 아니게 되었습니다. Git은 텍스트와 작은 파일에서는 승리했죠. Lore는 그 이후의 문제를 해결하려 합니다.
00:07:27성공 여부를 떠나, 정말 흥미로운 방향입니다. 이런 코딩 팁과
00:07:32정보가 유익했다면 Betterstack 채널을 구독해주세요. 다음 영상에서 뵙겠습니다.

핵심 요약

Lore는 Git의 텍스트 중심 설계와 Perforce의 높은 비용 문제를 해결하기 위해 대용량 바이너리 자산을 청크 단위로 효율적으로 관리하도록 설계된 오픈 소스 중앙 집중형 버전 관리 시스템이다.

하이라이트

  • 에픽게임즈는 텍스트 기반인 Git의 한계를 극복하기 위해 Rust로 구축한 버전 관리 시스템 Lore를 공개했다.

  • Lore는 파일을 거대한 객체로 저장하지 않고 청크 단위로 쪼개어 해시 처리 및 Zstandard 압축을 수행하며 중복을 제거한다.

  • 중앙 집중형 서버를 두면서도 스테이징, 커밋, 브랜칭, 차이 비교 등 일상적인 작업을 오프라인 상태에서 로컬로 처리한다.

  • 필요한 파일만 선택적으로 다운로드하는 하이드레이션 기능을 통해 거대한 저장소에서도 초기 데이터 전송량을 줄인다.

  • 현재 1.0 이전 버전으로 API 변경 가능성이 있고 GUI가 포함되어 있지 않으며 Git과의 상호 운용성을 지원하지 않는다.

타임라인

기존 버전 관리 시스템의 한계와 Lore의 등장

  • Git은 텍스트 파일과 소규모 변경 사항에 최적화되어 있어 대용량 바이너리 자산이 많은 게임 프로젝트에는 적합하지 않다.
  • Git LFS는 임시방편에 불과하며 Perforce는 기능은 우수하나 비용이 많이 들고 전담 유지 보수 인력이 필요하다.

현대 게임 개발은 수 기가바이트에 달하는 텍스처, 오디오, 3D 모델 등 바이너리 데이터를 포함한다. Git은 이러한 데이터를 다룰 때 저장소가 비대해지고 클론 속도가 저하되는 문제를 겪는다. 에픽게임즈는 이러한 게임 개발 환경의 고질적인 문제를 해결하고자 자체 버전 관리 도구인 Lore를 구축했다.

Lore의 기술적 작동 방식

  • Lore는 대용량 파일을 작은 청크 단위로 분할하여 머클 트리 구조로 저장하고 변경된 청크만 기록한다.
  • 서버 통신 없이 로컬 환경에서 스테이징, 커밋, 브랜칭 등의 작업을 즉각적으로 수행할 수 있다.

설치 후 별도의 설정 없이 바로 서버를 실행할 수 있으며, 100메가바이트 이상의 거대한 파일도 전체를 다시 저장할 필요가 없다. 파일의 대부분이 동일하면 기존 청크를 재사용하여 저장 효율을 극대화한다. 또한 중앙 서버가 존재함에도 브랜칭이나 차이 비교 등 대부분의 작업을 오프라인에서 빠르게 처리 가능하다.

운영 모델 및 향후 과제

  • Lore는 중앙 집중형 서버를 통해 권한을 통제하면서 로컬 작업의 속도를 보장하는 하이브리드 성격을 띤다.
  • 프로젝트 초기 단계로 API가 변동될 수 있고 상호 운용성이나 GUI 같은 편의 기능은 아직 부족하다.

데이터를 필요할 때만 가져오는 하이드레이션 기능으로 대규모 프로젝트의 효율성을 높였다. 다만 현재는 코어 라이브러리와 CLI 위주로 구성되어 있어 실무에 바로 적용하기보다는 개인 프로젝트에서의 테스트가 권장된다. 텍스트 위주의 기존 버전 관리 도구가 해결하지 못했던 대용량 바이너리 관리 문제를 정면으로 다루고 있다.

커뮤니티 글

모든 글 보기