게임 개발 대용량 에셋 버전 관리 서비스 선택 기준

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

프로그래머가 수정한 스크립트는 쉽게 병합되는데, 아티스트가 올린 수백 MB짜리 PSD와 FBX는 내려받는 데만 한참 걸립니다. 같은 씬 파일을 두 사람이 편집했다가 한쪽 작업이 사라지거나, 저장소 용량이 갑자기 늘어 추가 비용을 마주치는 일도 흔합니다.

이 문제는 단순히 서버가 느려서 생기지 않습니다. 게임 개발 버전 관리에서 코드와 대용량 바이너리 에셋은 저장 방식, 충돌 처리, 권한 관리 요구가 서로 다르기 때문입니다. GitHub와 Git LFS, Perforce P4, Unity Version Control, Diversion을 비교하면 팀 규모보다 먼저 살펴야 할 기준이 무엇인지 분명해집니다.

게임 에셋이 많을수록 선택 기준이 달라진다

코드 저장소의 익숙함만으로 결정하기 어려운 이유

일반 소프트웨어 프로젝트에서는 텍스트 기반 소스 코드가 중심입니다. 변경된 줄만 확인하고 브랜치를 병합하기 쉬우므로 Git의 분산형 작업 방식이 잘 맞습니다. 반면 게임 프로젝트에는 텍스처, 오디오, 영상, 애니메이션, 라이트 베이크 데이터처럼 내부 내용을 줄 단위로 병합하기 어려운 파일이 대량으로 들어갑니다.

예를 들어 레벨 디자이너 두 명이 동일한 바이너리 맵을 동시에 수정하면 자동 병합을 기대하기 어렵습니다. 이때 필요한 기능은 화려한 커밋 그래프보다 파일 잠금, 부분 동기화, 변경 파일 미리보기입니다. 외주 아티스트에게 특정 폴더만 보여줘야 한다면 파일 단위 권한도 중요해집니다.

게임 프로젝트의 제작 흐름은 프로그래머만으로 완성되지 않습니다. 직군 간 역할을 구분할 때는 게임 기획자의 업무 범위처럼 기획·아트·개발이 어떤 산출물을 주고받는지도 함께 봐야 합니다. 기획자가 스프레드시트와 데이터 파일을 자주 갱신하고 아티스트가 원본 에셋을 직접 제출한다면, 명령줄 사용을 전제로 한 도구는 교육 비용을 키울 수 있습니다.

• 저장소 구성: 소스 코드와 원본 아트 파일을 한 저장소에 둘지, 제작용 저장소와 빌드용 저장소를 나눌지 결정합니다.
• 파일 잠금: 씬, 프리팹, PSD, Blender 파일처럼 병합하기 어려운 확장자에 독점 잠금을 적용할 수 있는지 확인합니다.
• 부분 작업 공간: 전체 프로젝트를 복제하지 않고 담당 폴더만 내려받을 수 있어야 원격 작업자의 대기 시간이 줄어듭니다.
• 복구 방식: 실수로 삭제한 파일뿐 아니라 폴더 이동, 이름 변경, 대규모 임포트 이전 상태도 쉽게 되돌릴 수 있어야 합니다.
• 비용 단위: 사용자 수, 저장 용량, 다운로드 트래픽 중 무엇을 기준으로 과금하는지 구분합니다.

실무 팁: 도입 시험에서는 작은 샘플 저장소를 쓰지 마세요. 실제 프로젝트와 비슷한 크기의 텍스처 묶음, 씬 파일, 소스 코드를 넣고 첫 동기화와 일일 변경분 동기화 시간을 각각 측정해야 합니다.

기능과 비용 구조를 한눈에 보는 서비스 비교

아래 비교는 2026년 8월에 공개된 공식 안내를 기준으로 정리한 실무 관점의 요약입니다. 가격과 무료 제공량은 지역, 세금, 계약 조건에 따라 달라질 수 있으므로 실제 도입 전에는 각 서비스의 결제 화면과 견적서를 다시 확인해야 합니다.

표에서 가장 싼 항목을 고르는 것만으로는 충분하지 않습니다. 한 달 저장 비용이 낮더라도 모든 구성원이 매일 전체 저장소를 동기화한다면 전송량과 대기 시간이 커집니다. 반대로 사용자당 요금이 있더라도 잠금 충돌과 재작업을 줄인다면 총비용은 오히려 내려갈 수 있습니다.

서비스별 강점은 작업 흐름에서 드러난다

GitHub와 Perforce가 갈리는 지점

GitHub와 Git LFS 조합은 프로그래머에게 가장 익숙한 선택입니다. 이슈, 풀 리퀘스트, 코드 리뷰, CI 서비스와 자연스럽게 이어지고 오픈소스 라이브러리 관리도 편합니다. LFS 포인터 파일을 사용하면 거대한 바이너리가 일반 Git 이력을 직접 부풀리는 문제도 완화할 수 있습니다.

다만 LFS는 설치만 하면 끝나는 기능이 아닙니다. 저장소에 바이너리를 먼저 커밋한 뒤 추적 규칙을 추가하면 과거 이력에는 큰 파일이 그대로 남을 수 있습니다. 팀을 열기 전에 .gitattributes에 PSD, FBX, WAV, EXR 같은 확장자를 지정하고 파일 잠금 정책과 과거 이력 정리 방법을 문서화해야 합니다. 공식 계산기에 공개된 추가 사용 단가는 저장 공간과 외부 전송량이 별도로 산정되므로, 빌드 머신이 에셋을 반복해서 내려받는 구조도 점검할 필요가 있습니다.

Perforce P4는 수백 GB에서 수 TB에 이르는 저장소, 많은 바이너리 파일, 세분된 접근 권한을 다루는 데 강합니다. 사용자는 전체 저장소가 아니라 필요한 디포 경로만 작업 공간에 매핑할 수 있고, 병합 불가능한 파일을 체크아웃 단계에서 잠그는 흐름도 명확합니다. 거대한 게임 제작 조직에서 오랫동안 선택되어 온 이유가 여기에 있습니다.

대신 무료 소프트웨어라는 인상만 보고 시작하면 운영 부담을 놓치기 쉽습니다. 자체 호스팅은 소규모 사용자에게 무료 범위가 있지만 서버, 백업, 장애 복구, 저장 장치 증설을 팀이 책임져야 합니다. 관리형 P4 Cloud는 공식 표시 기준 사용자당 월 39달러이며 64GiB 저장 공간이 포함되지만, 팀원이 늘면 좌석 비용도 함께 증가합니다. 누가 서버를 관리하고 복구 훈련을 할 것인지까지 비용표에 넣어야 공정한 비교가 됩니다.

1. 코드 리뷰와 자동화가 핵심이고 바이너리가 일부라면 GitHub와 Git LFS부터 시험합니다.
2. 원본 아트가 크고 동일 파일의 동시 편집을 막아야 한다면 Perforce의 잠금과 스트림을 검토합니다.
3. CI가 같은 에셋을 자주 받는다면 캐시 서버를 두거나 다운로드 경로를 재설계합니다.
4. 외주 인력이 있다면 저장소 전체가 아닌 담당 경로만 열 수 있는지 권한 테스트를 진행합니다.

도구 성능은 최고 사양 PC 한 대가 아니라 가장 느린 원격 작업자의 첫 동기화 시간으로 평가하는 편이 안전합니다. 해외 행사와 업계 제작 사례를 찾을 때 활용되는 GDC의 배경과 성격도 참고하면 대규모 개발사의 발표 맥락을 이해하는 데 도움이 됩니다.

Unity Version Control과 Diversion의 낮은 진입 장벽

Unity Version Control은 과거 Plastic SCM으로 알려진 제품이며, 개발자용 브랜치 작업과 아티스트용 Gluon 인터페이스를 함께 제공합니다. 아티스트는 복잡한 Git 명령을 외우지 않고 필요한 파일만 선택해 내려받고 잠글 수 있습니다. 이름에 Unity가 들어가지만 다른 엔진 프로젝트에도 사용할 수 있다는 점도 알아둘 만합니다.

공식 안내상 2026년 3월부터 퍼블릭 클라우드 좌석 요금이 제거되고 조직당 월 25GB 저장 공간과 100GB 송신량이 무료 구간으로 제시됐습니다. 이 변화는 구성원이 많지만 저장소가 비교적 작은 팀에 유리합니다. 그러나 버전 관리 저장소와 빌드 산출물이 클라우드 할당량을 공유할 수 있으므로, 빌드 자동화까지 사용할 때는 청구 항목을 분리해 관찰해야 합니다.

Diversion은 설치와 동기화 절차가 단순해 비개발 직군의 첫 진입이 편한 편입니다. 변경 사항을 백그라운드에서 추적하고 클라우드에 공유하는 흐름이라 소규모 분산 팀이 서버를 직접 관리하지 않아도 됩니다. 짧은 프로토타입이나 학생 팀처럼 저장소 관리자를 따로 둘 수 없는 환경에서 매력적입니다.

반면 새 서비스의 편의성만 보고 핵심 프로젝트를 바로 이전해서는 곤란합니다. 사용 중인 게임 엔진 플러그인, 빌드 서버 인증, 훅 스크립트, IDE 연동, 장기 보관 정책을 먼저 확인해야 합니다. 특히 배포 파이프라인이 Git 커밋 해시나 Perforce 체인지리스트 번호를 릴리스 식별자로 사용한다면 기존 자동화 수정 비용이 커질 수 있습니다.

• Unity 중심 팀: 씬과 프리팹을 자주 다루는 기획자·아티스트가 많다면 Unity Version Control의 GUI와 잠금 흐름이 편합니다.
• 프로토타입 팀: 서버 관리 없이 즉시 공유하고 싶다면 Diversion의 온보딩 시간을 비교해 볼 만합니다.
• 멀티 엔진 스튜디오: 제품명보다 Unreal, 자체 엔진, DCC 도구와의 실제 연동 결과를 우선합니다.
• 장기 라이브 서비스: 데이터 내보내기, 계정 종료 후 보존 기간, 감사 로그 보관 여부를 계약 전에 확인합니다.

큰 저장소가 항상 전용 서비스의 근거는 아니다

상황별 추천과 비용을 검증하는 시험 운영

서비스를 고르기 전에 대표 프로젝트 하나를 복제해 2주 정도 시험 운영하는 편이 좋습니다. 첫날에는 저장소 생성과 권한 설정을 확인하고, 이후에는 실제 직군별 작업을 재현합니다. 프로그래머는 브랜치 병합과 빌드를, 아티스트는 대용량 파일 잠금과 되돌리기를, 기획자는 데이터 파일 수정과 리뷰 요청을 수행합니다.

비용도 좌석 가격 하나로 계산하지 마세요. 월간 총비용은 서비스 이용료, 추가 저장 공간, 송신 트래픽, 서버 운영 시간, 교육 시간, 충돌로 인한 재작업을 합쳐야 합니다. 예산을 기능과 성과 단위로 연결하는 사고방식은 계획예산 제도의 개념에서도 참고할 수 있습니다. 게임 개발에서는 이를 ‘버전 관리 도입으로 줄일 재작업 시간’과 ‘안정적으로 보존할 에셋 규모’로 바꾸어 적용하면 됩니다.

상황별로 보면 선택은 비교적 선명합니다. 코드가 대부분인 2~5인 인디 팀이라면 GitHub와 Git LFS가 기존 개발 습관을 유지하기 쉽습니다. Unity를 사용하고 비개발 직군이 자주 저장소를 만진다면 Unity Version Control이 교육 부담을 줄여줍니다. 수십 명이 수 TB의 원본 아트를 공유하거나 엄격한 폴더 권한이 필요하다면 Perforce P4가 유력합니다. 짧은 제작 주기와 간편한 원격 협업이 우선이라면 Diversion을 시험 후보에 넣을 수 있습니다.

1. 첫 동기화: 신규 작업자가 전체 또는 담당 영역을 받는 데 걸리는 시간을 기록합니다.
2. 일일 갱신: 텍스처와 오디오가 대량 변경된 날의 다운로드 용량과 시간을 측정합니다.
3. 충돌 재현: 같은 씬이나 PSD를 두 계정에서 편집해 잠금 경고와 복구 절차를 확인합니다.
4. 장애 가정: 잘못 삭제한 폴더와 일주일 전 파일을 복원하고 담당자가 혼자 수행할 수 있는지 봅니다.
5. 비용 예측: 현재 저장량뿐 아니라 6개월 뒤 예상 용량, 신규 인원, 빌드 서버 트래픽을 입력합니다.
6. 이탈 시험: 저장소와 이력, 사용자 권한 기록을 표준적인 형태로 내보낼 수 있는지 검증합니다.

분리 저장소가 더 나은 경우도 있다

모든 파일을 하나의 거대한 시스템에 넣어야 협업이 좋아진다는 주장에는 반대 관점도 있습니다. 실제로는 소스 코드와 런타임에 필요한 최적화 에셋만 Git에 두고, 고해상도 원본과 제작 중간 파일은 Perforce 같은 별도 저장소에 두는 혼합 구성이 더 경제적일 수 있습니다. 코드 리뷰는 GitHub에서 유지하면서 아트팀은 잠금과 부분 동기화의 장점을 얻는 방식입니다.

물론 저장소를 나누면 버전 대응 관계가 흐려질 수 있습니다. 이를 막으려면 게임 빌드가 참조한 코드 커밋과 에셋 변경 번호를 함께 기록하고, 에셋 내보내기 과정을 자동화해야 합니다. 폴더를 사람이 복사하는 방식은 누락을 만들기 쉬우므로 빌드 스크립트가 정해진 버전을 가져오게 설계하는 편이 안전합니다.

반대로 프로젝트가 작고 바이너리 변경도 드물다면 전용 대규모 시스템은 과한 선택일 수 있습니다. 관리 도구가 하나 늘 때마다 계정, 백업, 권한, 교육 문서도 늘어납니다. 질문은 ‘어떤 제품이 가장 강력한가’가 아니라 우리 팀이 매주 겪는 충돌과 대기 시간을 어느 구조가 가장 적은 운영 부담으로 없애는가여야 합니다.

• 원본 에셋과 게임에 포함되는 가공 에셋의 소유 저장소를 문서에 명시합니다.
• 빌드 결과에 코드 커밋과 에셋 리비전 식별자를 함께 남깁니다.
• 혼합 구성에서는 계정 퇴사 처리와 외주 권한 회수를 두 시스템에서 동시에 수행합니다.
• 매월 저장 증가량과 다운로드 트래픽을 확인해 무료 구간 이탈 시점을 예측합니다.
• 도구를 바꾸기 전 충돌 건수, 복구 시간, 신규 인력 온보딩 시간을 기준값으로 남깁니다.