게임 버전 관리, Git LFS와 Perforce 사이의 선택

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

프로그래머가 만든 브랜치는 잘 합쳐지는데 아티스트가 수정한 2GB짜리 텍스처 때문에 저장소가 멈춘다면, 문제는 팀원의 숙련도가 아니라 도구의 전제에 있습니다. 게임 버전 관리는 소스 코드뿐 아니라 PSD, FBX, WAV, 영상처럼 병합하기 어려운 바이너리 에셋까지 감당해야 하므로 일반적인 웹 개발 저장소와 선택 기준이 다릅니다.

특히 Git LFS와 Perforce P4, Unity Version Control, SVN은 모두 파일 이력을 보존하지만 잠금 방식, 브랜치 비용, 서버 운영 부담에서 뚜렷한 차이를 보입니다. 여러분의 프로젝트가 5명짜리 인디 게임인지, 외주 아티스트가 드나드는 30명 규모 제작인지에 따라 가장 좋은 답도 달라집니다.

코드보다 에셋이 커지는 순간 선택 기준이 달라집니다

저장 용량보다 먼저 볼 것은 변경 형태입니다

게임 프로젝트에서 중요한 수치는 저장소의 현재 크기만이 아닙니다. 1GB짜리 캐릭터 원본 파일을 매주 통째로 갱신한다면 작은 수정도 새로운 1GB 버전으로 쌓일 수 있습니다. Git LFS 역시 대용량 파일 자체 대신 포인터를 Git에 기록하지만, 수정된 바이너리 객체는 별도로 다시 저장됩니다. 따라서 에셋의 크기와 변경 빈도를 함께 측정해야 실제 비용을 예측할 수 있습니다.

또 하나의 기준은 동시에 같은 파일을 만지는 사람의 수입니다. C++이나 셰이더 텍스트는 충돌 후 병합할 수 있지만, 언리얼 레벨이나 포토샵 문서는 자동 병합이 사실상 어렵습니다. 이런 파일이 많은 팀에서는 빠른 브랜치보다 독점 잠금과 잠금 상태의 가시성이 작업 손실을 줄여 줍니다.

• 코드 비중이 높고 브랜치가 잦음: Git LFS가 기존 Git 워크플로와 자연스럽게 연결됩니다.
• 바이너리 에셋이 크고 동시 편집이 잦음: Perforce P4의 중앙 집중형 잠금이 유리합니다.
• Unity 편집기 중심의 혼합 직군: Unity Version Control의 GUI와 부분 작업공간을 검토할 만합니다.
• 단순한 중앙 저장소를 직접 운영: SVN이 낮은 개념적 복잡성을 제공합니다.

도구를 고르기 전에 최근 30일간 변경된 상위 20개 파일의 크기, 수정 횟수, 수정 직군을 표로 뽑아 보세요. 이 데이터가 제품 소개 문구보다 정확한 선택 기준이 됩니다.

Git LFS와 Perforce를 포함한 네 가지 도구의 차이

팀이 매일 체감하는 항목으로 나란히 보기

다음 표는 기능의 개수보다 실제 제작 과정에서 자주 부딪히는 문제를 기준으로 구성했습니다. Git LFS는 분산형 Git에 대용량 객체 저장을 더하는 방식이고, Perforce P4는 중앙 서버와 작업공간을 중심으로 움직입니다. Unity Version Control은 Plastic SCM에서 이어진 브랜치·GUI 경험이 강하며, SVN은 전통적인 중앙 집중형 모델로 이해하기 쉽습니다.

어느 제품이 절대적으로 우수한 것은 아닙니다. 개발자가 명령줄과 리베이스에 익숙해도 아티스트가 매일 잠금 충돌을 겪는다면 팀 전체 생산성은 낮아집니다. 반대로 소규모 코드 중심 팀이 복잡한 서버를 도입하면 관리 업무만 늘어날 수 있습니다.

• 아티스트에게는 체크아웃, 잠금 해제, 이전 버전 복구를 직접 시험하게 합니다.
• 프로그래머에게는 브랜치 생성과 빌드 서버 동기화 시간을 측정하게 합니다.
• 관리자에게는 백업 복원과 계정 회수 절차를 검증하게 합니다.

기술 선택은 제작 계획과 떨어져 있지 않습니다. 역할별 책임을 정의할 때는 게임 기획자의 업무 범위처럼 직군 간 산출물 흐름도 함께 살펴보면 누가 어떤 파일을 잠그고 승인할지 정하기 쉬워집니다.

코드 중심 팀이라면 Git LFS가 빠르게 안착합니다

익숙한 Git 생태계를 유지하는 선택

GitHub, GitLab 또는 기존 CI 파이프라인을 이미 사용한다면 Git LFS의 가장 큰 장점은 새로운 버전 관리 개념을 최소화한다는 점입니다. 파일 확장자를 추적 대상으로 지정하고 속성 파일을 커밋하면, 이후 사용자는 평소처럼 clone, pull, push를 수행할 수 있습니다. 코드 리뷰와 이슈 연결, 브랜치 보호 규칙도 그대로 유지됩니다.

다만 Git LFS는 거대한 바이너리 저장소를 마법처럼 작은 저장소로 바꾸는 기능이 아닙니다. 500MB 파일에서 1바이트를 수정해 다시 푸시해도 새로운 500MB 객체가 저장되며, CI와 신규 팀원의 반복 다운로드는 전송량을 늘립니다. 2026년 9월 기준 GitHub Free와 Pro에는 LFS 저장 공간과 월간 다운로드 대역폭이 각각 10GiB 포함되고, Team과 Enterprise Cloud는 각각 250GiB가 포함됩니다. 초과분은 공식 계산기 기준 저장 공간 GiB당 월 0.07달러, 외부 전송 GiB당 0.0875달러로 계산되므로 계정 화면에서 최신 청구 조건을 다시 확인해야 합니다.

1. .psd, .fbx, .wav, 패키지 파일처럼 병합할 수 없는 확장자부터 추적합니다.
2. 이미 Git 이력에 들어간 대형 파일은 단순 삭제가 아니라 이력 마이그레이션 영향을 검토합니다.
3. 파일 잠금을 적용할 확장자와 긴급 잠금 해제 권한을 문서화합니다.
4. CI가 매 실행마다 전체 LFS 객체를 받지 않도록 캐시와 선택적 다운로드를 설정합니다.

Git LFS는 프로그래머 2~6명과 아티스트 1~2명이 일하는 프로젝트, 저장소가 수십 GB 이내이며 코드 브랜치가 자주 갈라지는 상황에 특히 편합니다. 반면 매일 수백 GB의 에셋을 동기화하거나 하나의 월드 파일을 여러 디자이너가 건드린다면 Git의 편리함보다 전송량과 잠금 규율이 더 큰 문제가 될 수 있습니다.

에셋 제작이 중심이면 Perforce와 Unity 방식이 앞섭니다

Perforce P4는 규모를, Unity Version Control은 접근성을 봅니다

Perforce P4는 대형 게임 스튜디오에서 자주 선택되는 중앙 집중형 버전 관리 시스템입니다. 사용자는 필요한 파일과 리비전을 작업공간으로 동기화하고, 병합이 어려운 에셋은 편집 전에 독점 체크아웃할 수 있습니다. 누가 레벨 파일을 사용 중인지 명확히 보이기 때문에 아티스트 두 명이 하루 동안 만든 결과 중 하나를 버리는 사고를 예방하기 좋습니다.

무료 자체 호스팅 P4는 현재 최대 5명과 20개 작업공간 범위에서 사용할 수 있으며, 자체 호스팅이므로 저장 용량은 준비한 서버 디스크에 좌우됩니다. 관리형 P4 Cloud는 100명 미만 팀을 대상으로 사용자당 월 39달러, 64GiB 포함 조건을 제시합니다. 자체 호스팅은 라이선스 비용을 줄여도 서버 패치, SSL 인증서, 백업, 복원 시험과 장애 대응 시간을 별도로 잡아야 합니다.

Unity Version Control은 개발자에게는 브랜치와 병합 기능을, 비개발 직군에게는 비교적 친숙한 데스크톱 인터페이스를 제공하는 중간 지점입니다. Unity 프로젝트에만 제한되는 것은 아니지만 Unity Editor 연동의 이점이 크며, 클라우드 요금제의 저장 한도는 구독 종류에 따라 달라집니다. 공식 Unity Cloud 문서에는 Personal 조직당 10GB, Pro 좌석당 50GB, Enterprise 좌석당 120GB가 안내되어 있으므로 실제 계약 화면과 지역별 조건을 대조하는 편이 안전합니다.

• Perforce P4 추천: 언리얼 프로젝트, 수백 GB 이상의 원본 에셋, 전담 빌드·인프라 담당자가 있는 팀
• Unity Version Control 추천: Unity Editor 사용 비중이 높고 아티스트가 Git 명령에 부담을 느끼는 팀
• 도입 보류: 서버를 관리할 사람이 없는데 자체 호스팅만 전제로 비용을 계산한 경우
• 필수 검증: 50GB 초기 동기화, 2GB 파일 수정, 잠금 충돌, 삭제 파일 복구를 실제 회선에서 시험

아티스트가 도구 사용법을 외우게 만드는 대신, 편집기에서 잠긴 파일이 즉시 보이게 만드세요. 좋은 파이프라인은 교육 자료보다 실수를 예방하는 신호가 먼저 나타납니다.

팀 규모와 제작 단계에 따라 추천 조합이 바뀝니다

하나의 순위 대신 실패 비용으로 판단하기

1~3명의 초기 프로토타입 팀은 Git LFS로 시작하는 편이 대체로 효율적입니다. 코드와 문서, 작은 에셋을 한 저장소에서 다루기 쉽고 호스팅과 CI 선택지도 넓습니다. 다만 임시 빌드 파일, DerivedDataCache, Library 폴더를 제외하지 않으면 저장소가 빠르게 불어나므로 엔진별 ignore 설정을 첫 커밋에 포함해야 합니다.

4~5명의 아트 중심 인디 팀이라면 Git LFS와 무료 자체 호스팅 P4를 같은 데이터로 시험할 가치가 있습니다. P4의 무료 인원 범위는 매력적이지만 외주 계정, 자동화용 일반 사용자, 여러 PC의 작업공간 수가 한도에 영향을 주는지 살펴야 합니다. 팀이 6명 이상으로 늘 가능성이 높다면 무료 조건만 보고 들어가기보다 유료 전환 견적과 이전 비용까지 비교해야 합니다.

10명 이상의 제작에서는 저장소 도구만 결정하지 말고 릴리스 브랜치, 에셋 승인, 빌드 산출물 보관 정책을 함께 정해야 합니다. 국제 게임 개발 사례와 제작 흐름을 탐색할 때는 GDC의 성격과 역할도 참고할 수 있지만, 유명 스튜디오의 도구를 그대로 복제하기보다는 현재 팀의 병목을 기준으로 삼는 것이 중요합니다.

• 혼자 또는 3명 이하: Git LFS, 저장소 규칙을 단순하게 유지합니다.
• 5명 안팎의 아트 집중 팀: P4 무료 자체 호스팅과 Unity Version Control을 파일 잠금 중심으로 시험합니다.
• 원격 Unity 팀: Unity Version Control의 GUI, 클라우드 지연 시간, 좌석·저장 조건을 평가합니다.
• 중대형 언리얼 팀: Perforce P4, 스트림, 프록시, 백업 담당자를 포함해 설계합니다.
• 브랜치가 거의 없는 내부 도구: SVN도 충분하지만 향후 엔진·CI 연동 여부를 먼저 확인합니다.

2주와 100GB로 실제 운영비를 드러내세요

구독료 밖의 시간 비용까지 계산하는 시험법

최종 선택 전에는 같은 100GB 샘플 프로젝트를 후보 도구 두 개에 넣고 2주간 병행 시험하는 것이 좋습니다. 첫날에는 전체 동기화 시간을 재고, 셋째 날에는 2GB 바이너리 파일을 두 사람이 동시에 수정해 잠금 충돌을 확인합니다. 첫 주 말에는 빌드 서버가 깨끗한 작업공간을 만드는 시간을 측정하고, 둘째 주에는 파일 20개를 잘못 삭제한 상황에서 복구를 수행합니다.

비용표에는 구독료뿐 아니라 서버 관리와 대기 시간을 넣어야 합니다. 예를 들어 8명이 하루 평균 6분씩 동기화를 기다리면 한 달 20근무일 기준 960분, 즉 16시간이 사라집니다. 시간당 내부 비용을 4만원으로만 잡아도 월 64만원입니다. 자체 호스팅 관리에 매주 2시간이 들면 월 약 8시간이 추가되며, 백업 복원 시험을 분기당 4시간 배정하는 것도 현실적입니다.

1. 시험 데이터: 코드 5GB, 텍스처·모델·음원 95GB를 준비합니다.
2. 참여 인원: 프로그래머 2명, 아티스트 2명, 빌드 담당 1명 등 최소 5개 작업공간을 사용합니다.
3. 측정 항목: 최초 동기화, 일일 업데이트, 브랜치 전환, 파일 잠금, 복구 시간을 분 단위로 기록합니다.
4. 장애 시험: 서버 또는 네트워크를 30분 차단한 뒤 로컬 작업과 재연결 동작을 확인합니다.
5. 예산 상한: 월 구독·스토리지·전송료와 관리 인건비를 합쳐 프로젝트 월 인건비의 2% 이내인지 검토합니다.

숫자로 보면 선택이 선명해집니다. 코드 중심 3명 팀은 Git LFS 무료 10GiB를 넘는 초과 사용량과 CI 전송량부터 계산하고, 5명 에셋 팀은 P4 서버 디스크 1~2TB와 월 8시간 안팎의 관리 여력을 비교하면 됩니다. 10명 팀이 관리형 P4 Cloud를 택한다면 표시 가격만으로 월 390달러이며, 여기에 포함 용량 초과와 백업 정책을 확인해야 합니다. 2주 시험, 100GB 데이터, 5개 작업공간, 월 2% 예산 상한이라는 네 숫자를 고정하면 브랜드 선호가 아니라 실제 게임 프로그래밍 흐름에 맞는 도구를 고를 수 있습니다.