게임 개발에서의 버전 관리: Git, Git LFS, Perforce 비교
게임 프로젝트는 소스 코드뿐 아니라 대형 에셋과 엔진 설정도 함께 관리해야 한다. Git, Git LFS, Perforce의 차이와 팀 규모·에셋 성격에 따른 선택 기준을 정리한다.
게임 개발의 버전 관리는 왜 까다로운가
게임 프로젝트에는 텍스트 기반 소스 코드와 함께 텍스처, 사운드, 3D 모델, 애니메이션, 영상처럼 용량이 크고 병합하기 어려운 바이너리 파일이 섞여 있다. 여기에 Unity나 Unreal Engine이 생성하는 설정 파일과 빌드 산출물까지 더해지면 일반적인 웹 프로젝트와는 다른 관리 전략이 필요하다.
핵심은 도구 자체의 우열보다 팀이 다루는 파일의 성격이다. 코드 중심 프로젝트는 분산 작업과 브랜치 전략이 중요하고 아트 에셋 중심 프로젝트는 충돌 방지와 대용량 전송이 더 중요해진다.
세 도구의 역할을 먼저 구분하기
Git은 전체 이력을 각 개발자의 로컬 저장소에 복제하는 분산 버전 관리 시스템이다. Git LFS는 Git을 대체하는 도구가 아니라 대형 파일의 실제 내용을 별도 저장소에 두고 Git에는 작은 포인터 파일을 기록하는 확장 기능이다. Perforce Helix Core는 중앙 서버를 기반으로 대규모 바이너리 자산과 파일 잠금 작업을 지원하는 버전 관리 시스템이다.
flowchart TD
A[프로젝트의 주된 협업 문제] --> B{대형 바이너리 에셋이 많은가?}
B -->|아니오| C[Git 중심으로 시작]
B -->|예| D{여러 사람이 같은 에셋을 자주 수정하는가?}
D -->|가끔| E[Git + Git LFS 검토]
D -->|자주| F{파일 잠금과 중앙 관리가 중요한가?}
F -->|예| G[Perforce 검토]
F -->|아니오| E이 흐름은 절대적인 결정 규칙이 아니다. 예를 들어 인디 팀도 고해상도 영상 원본을 자주 다루면 Perforce가 편할 수 있고 규모가 큰 팀도 코드 저장소는 Git으로 운영할 수 있다.
Git: 코드와 텍스트 파일 협업에 강하다
Git의 가장 큰 장점은 브랜치와 병합을 중심으로 한 유연한 협업이다. 코드, 셰이더, JSON·YAML 기반 설정, 문서처럼 줄 단위 비교가 가능한 파일에서는 변경 내용을 검토하고 병합하기 좋다. GitHub, GitLab 같은 호스팅 서비스와 자동 빌드 도구도 풍부하다.
반면 대형 바이너리 파일을 일반 Git 객체로 계속 커밋하면 저장소 전체 이력이 빠르게 커진다. 바이너리는 줄 단위 병합이 거의 불가능하므로 같은 파일을 두 사람이 수정했을 때 한쪽 작업을 선택해야 하는 상황도 흔하다. 이미 커밋한 대형 파일을 지워도 과거 이력에는 남기 때문에 단순 삭제만으로 저장소 용량이 줄지 않는 점도 주의해야 한다.
게임 프로젝트에서 Git을 사용할 때는 엔진별 .gitignore를 먼저 준비하고 중간 산출물과 캐시를 추적 대상에서 제외하는 것이 기본이다. Unity의 Library, Unreal Engine의 Binaries, Intermediate, DerivedDataCache 같은 생성 폴더는 보통 저장소에 넣지 않는다. 다만 팀의 엔진 버전과 필요한 설정 파일은 재현 가능한 작업 환경을 위해 명확히 관리해야 한다.
Git LFS: Git의 대용량 파일 부담을 덜어 준다
Git LFS는 PSD, FBX, WAV, PNG, MP4 같은 대형 파일을 LFS 저장소에 보관하고 일반 Git 이력에는 해당 파일을 가리키는 포인터를 기록한다. 일반 Git 객체가 비대해지는 문제를 줄이는 데 유용하다.
다음은 대표적인 초기 설정 예시다. 파일을 처음 추가하기 전에 추적 규칙을 설정해야 한다.
git lfs install
git lfs track "*.psd"
git lfs track "*.fbx"
git lfs track "*.wav"
git add .gitattributes
git add Assets/Characters/hero.fbx
git commit -m "Add character asset through LFS".gitattributes는 팀원 모두가 공유해야 한다. 이 파일이 빠지면 누군가는 같은 확장자를 일반 Git 파일로 커밋할 수 있다. 또한 저장소를 받은 뒤 LFS 클라이언트가 설치되어 있지 않으면 실제 에셋 대신 포인터 파일만 보게 된다.
Git LFS에도 한계는 있다. 파일의 이전 버전이 LFS 저장소에 계속 쌓이므로 저장 공간과 전송량 정책을 확인해야 한다. 제공 서비스마다 저장 용량, 대역폭, 과금 방식이 다르다. 무엇보다 LFS가 바이너리 병합 문제를 해결해 주지는 않는다. 같은 FBX나 PSD를 동시에 수정하는 일을 줄이려면 담당 구분, 파일 분할, 잠금 규칙이 필요하다.
Git LFS는 파일 잠금 기능을 제공할 수 있다. 다만 실제로 효과를 보려면 호스팅 서비스와 클라이언트 설정이 이를 지원하는지 확인하고 아티스트가 수정 전 잠금과 수정 후 해제를 일관되게 수행해야 한다.
Perforce: 대형 에셋과 잠금 중심 작업에 적합하다
Perforce는 중앙 서버의 파일을 워크스페이스로 받아 작업하는 방식이다. 특히 대용량 바이너리 파일을 다루고 하나의 파일을 한 번에 한 사람만 수정하도록 강제하는 워크플로에 잘 맞는다. 아트, 레벨, 시네마틱처럼 충돌 비용이 높은 파일이 많은 팀에서 자주 검토하는 이유다.
Perforce에서는 파일을 수정하기 전에 체크아웃하거나 잠금 상태로 만들고 다른 사용자는 해당 파일이 작업 중임을 확인한다. 병합이 불가능한 파일을 나중에 충돌로 발견하는 대신 작업 시작 단계에서 충돌 가능성을 줄이는 접근이다.
다만 서버 운영과 권한 관리, 워크스페이스 설정에 대한 이해가 필요하다. 오프라인에서 자유롭게 이력을 다루는 Git의 경험과도 다르다. 규모가 작고 코드 비중이 높은 팀이라면 운영 부담이 장점보다 크게 느껴질 수 있다.
실무 선택 기준
| 상황 | 우선 검토할 선택 | 이유 |
|---|---|---|
| 코드와 텍스트 설정이 대부분인 소규모 팀 | Git | 브랜치, 코드 리뷰, CI 연동이 간단하다. |
| 코드와 대형 에셋이 함께 있는 인디 팀 | Git + Git LFS | 기존 Git 워크플로를 유지하면서 대형 파일을 분리할 수 있다. |
| 고용량 원본 에셋과 바이너리 협업이 많은 팀 | Perforce | 중앙 관리와 파일 잠금으로 충돌 비용을 낮추기 쉽다. |
| 코드와 에셋의 작업 방식이 크게 다른 팀 | 혼합 운영 | 코드는 Git, 대형 에셋은 Perforce처럼 역할을 나눌 수 있다. |
혼합 운영을 선택한다면 두 저장소 사이의 의존성을 문서화해야 한다. 예를 들어 특정 게임 데이터 형식이나 생성 도구의 버전이 어느 저장소에서 관리되는지 빌드 서버가 어떤 리비전을 조합하는지 정하지 않으면 재현 가능한 빌드가 어려워진다.
도입 전에 정할 운영 규칙
도구를 고르기 전에 다음 규칙을 합의해 두는 편이 중요하다.
- 어떤 폴더와 확장자를 버전 관리할지 정한다.
- 병합 불가능한 파일의 담당자와 잠금 절차를 정한다.
- 엔진 버전, 플러그인 버전, 패키지 잠금 파일을 어떻게 고정할지 정한다.
- 빌드 산출물과 원본 에셋의 보관 위치를 구분한다.
- 저장소 백업, 접근 권한, 퇴사자 계정 회수 절차를 마련한다.
Git은 코드 중심 협업의 기본 선택지이고 Git LFS는 그 위에서 대형 파일 문제를 완화하는 수단이다. Perforce는 바이너리 에셋의 규모와 동시 편집 비용이 커질수록 더 설득력 있는 선택지가 된다. 처음부터 완벽한 도구를 찾기보다 현재 프로젝트에서 가장 자주 발생하는 충돌과 대기 시간을 줄이는 방향으로 운영 방식을 설계하는 것이 좋다.
