버전 관리 시스템(VCS)은 팀이 프로젝트의 소스 코드를 백업하고 아카이빙하도록 지원합니다. 이를 통해 저장소를 쉽게 검토하고 편집할 수 있으며 빌드가 손상되는 오류 발생 시 이전 버전을 복원할 수 있습니다.

버전 관리는 소스 코드 및 에셋에 대한 업데이트를 트래킹하고 관리하는 체계적인 프로세스입니다. 버전 관리 시스템은 효율적인 워크플로의 바탕이 되며, 프로그래머와 아티스트, 기타 팀원을 위한 SSOT(single source of truth) 역할을 하는 동시에 모두가 공유 코드 베이스에 독립적으로 기여할 수 있도록 지원합니다. 개발 중에 치명적인 오류가 발생하는 경우 코드 업데이트를 '실행 취소'할 수 있도록 지원하여 안전망 역할도 합니다.

팀의 규모, 지역 분포와 같은 요인은 게임 개발자가 어떤 버전 관리 시스템을 선택하고 구현할지에 대한 결정에 영향을 미칩니다. 개인 개발자는 로컬 솔루션만을 사용해도 충분히 작업을 진행할 수 있지만 대규모 팀은 시간대와 지역에 구애받지 않고 협업을 진행할 수 있도록 더 견고하고 확장성이 뛰어난 버전 관리 시스템을 모색해야 합니다.

버전 관리에서는 브랜치 생성 기능도 지원합니다. 브랜치는 VCS 내에서 관리되는 코드의 단일 사본입니다. 개발자와 나머지 팀원은 브랜치를 만들어서 별도의 스트림에서 상호 독립적으로 작업할 수 있습니다. 버전 관리를 활용하면 개발자가 협업을 진행하고 공유 코드베이스와 동기화할 수 있습니다.

버전 관리 시스템은 DevOps의 핵심으로, 프로젝트의 소스 코드에 대해 팀이 협업하고 빠르게 반복 작업할 수 있도록 지원합니다.

버전 관리를 사용하면 항상 백업이 존재하게 됩니다. 개별 프로젝트 업데이트는 메인 소스 코드로 병합되기 전에 '커밋'이라고 하는 단일 그룹에 주기적으로 수집됩니다. 버전 관리 소프트웨어는 각 프로젝트 파일의 모든 수정 사항을 트래킹하는 데 필수적입니다. 실수나 회귀가 발생하면 사용자는 해당 파일의 이전 버전으로 거의 즉시 돌아갈 수 있습니다. 버전 관리는 모든 변경 사항, 변경한 사람, 각 변경의 모든 반복 작업(iteration)에 대한 로그를 제공합니다. 버전 관리 시스템을 갖추면 모든 이해 관계자와 팀원이 다수의 파일에서 동시에 끊김 없이 작업할 수 있습니다. 버전 관리 시스템은 모든 코드 편집 및 변경 사항을 하나의 중앙화된 저장소로 병합하도록 지원합니다.

프로젝트 전체 이력에 액세스하고 실수를 되돌릴 수 있는 버전 관리 시스템을 사용하면 버그 트래킹 과정을 간소화하고 이전에 삭제한 기능을 손쉽게 복원할 수 있습니다.

버전 제어 시스템에서 새 저장소를 생성하면 기본 분기가 열립니다. 이를 메인 브랜치 또는 트렁크 마스터라고 합니다. 트렁크 마스터를 통해 메인 코드 베이스가 파이프라인으로 들어가고 그런 다음, 컴파일되어 최종 사용자에게 배포됩니다.

브랜치란 무엇일까요? 브랜칭은 마스터 브랜치로부터 코드가 갈라지는 프로세스입니다. 이를 통해 개발자는 메인 코드에 커밋하지 않고 코드를 개인적으로 변경할 수 있습니다. 브랜치를 사용하면 개발자는 단일 서버에 전체 파일 이력을 보관할 필요가 없습니다. 그 대신 코드에서 변경된 사항의 전체 이력을 시간순으로 보관할 수 있습니다. 버전 관리 시스템을 활용하면 이러한 별개의 브랜치를 다시 메인 브랜치에 병합할 수 있습니다. 개발자가 자신의 작업 브렌치를 메인 브랜치에 병합할 준비가 되지 않았다면 변경 사항을 개별 브랜치로 커밋하고 원할 때 메인 브랜치에 병합하면 됩니다.

적절한 브랜칭 전략은 코드 충돌 및 빌드 손상을 피하는 데 중요합니다. 효율적인 버전 관리 시스템이 있다면 팀에서 쉽게 메인 브랜치와 동기화하고 충돌할 수 있는 코드를 고칠 수 있습니다. 코드가 메인 통합 브랜치에 커밋된 다음에도 그렇습니다.

분산형 버전 관리 시스템을 사용하면 메인 서버에 연결하지 않고도 체크인, 브랜치, 병합을 할 수 있습니다. 각 기여자는 클라우드에 저장된, 복제된 저장소에서 작업합니다. 주된 장점은 팀원이 네트워크이나 VPN의 속도 저하에 대한 걱정 없이 별도로 신속하게 작업할 수 있다는 점입니다. 오프라인에서도 프로젝트에 대한 작업을 진행할 수 있지만, 업데이트를 내보내거나 가져오려면 인터넷 연결이 필요합니다.

분산형 버전 관리 시스템을 사용할 때는 대기 시간이 길어질 수 이으며, 특히 변경 이력이 많은 대규모 프로젝트에서 전체 프로젝트 이력을 다운로드해야 하는 경우라면 그럴 가능성이 더 높습니다. 이러한 파일이 빠른 속도로 여유 공간을 차지할 수 있으므로 대규모 바이너리 파일을 사용하는 스튜디오에서는 스토리지 사용을 주의 깊게 모니터링해야 합니다.

유연성을 높이고 잠재적으로 생산성을 끌어올리고자 하는 스튜디오라면 분산형 버전 관리를 고려하는 것이 좋습니다.

중앙 집중형 버전 관리 시스템은 체크인/푸시 워크플로를 사용하여 메인 서버에 연결됩니다. 소스 코드의 변경 사항 또는 업데이트는 새 버전으로 저장소에 자동 저장됩니다. 중앙 집중형 버전 관리 시스템은 강력한 브랜치 및 병합 기능을 제공하며 저장소를 여러 시스템으로 복제할 필요가 없습니다. 이러한 측면에서 보면 더욱 안전합니다.

중앙 집중형 버전 관리 시스템에는 네트워크 연결이 필요합니다. 팀이 하나의 서버에 저장된 단일 프로젝트 버전에 종속되므로 서비스 중단이 발생하면 속도가 크게 저하될 수 있습니다. 중앙 집중형 버전 관리의 또 다른 단점은 확장성이 떨어질 수 있다는 것입니다. 프로젝트에 기여하는 개발자가 많을수록 안정적인 환경에서 변경 사항을 내보낼 기회가 줄어들며 이로 인해 병합 충돌과 같은 문제가 발생할 수 있습니다.

설정과 사용이 쉬운 버전 관리 시스템에 관심이 있다면 중앙 집중형 워크플로를 고려해 보는 것도 좋습니다.

로컬 버전 관리 시스템은 가장 간단한 버전 관리 형태이며 팀 단위보다는 1인 개발자가 주로 사용합니다. 로컬 버전 관리의 경우 모든 프로젝트 데이터가 단일 컴퓨터에 저장되며 프로젝트 파일에 대한 변경 사항은 패치로 저장됩니다. 각 패치에는 이전 패치 이후에 구현된 업데이트만 포함됩니다. 프로젝트의 특정 버전에 문제가 발생하는 경우 문제를 진단하려면 전체 패치 컬렉션을 검사하여 적기에 특정 시점의 프로젝트 파일 상태를 짜 맞춰야 합니다.

모든 데이터가 컴퓨터 하나에 연결되어 있으므로 로컬 버전 관리 시스템은 분산형 및 중앙 집중형보다 본질적으로 유연성이 낮습니다. 팀원 간의 협업이 쉽지 않으며, 만약 데이터베이스가 손상되어 손실된 정보를 복원하지 못하면 곤란한 상황에 처할 수 있습니다.

일반적으로는 로컬 버전 관리로 시작해도 무방하지만, 규모가 커지기 시작하면(한 명에서 단 두 명으로 팀이 커진 경우에도) 분산형 또는 중앙 집중형 방식을 사용하는 것이 좋습니다.