[프로젝트 관리] 게임 개발 시의 버전 관리 규칙

게임 개발 버전 관리 규칙

 

프로젝트 좀보이드의 버전 표기

게임을 개발하다 보면, 혹은 플레이하다보면 버전 표기를 한 번쯤은 본 적이 있을 것이다.
오늘은 이 버전 표기가 어떤 규칙을 갖고 있는지 확인해보도록 하겠다.

버전이란?

게임을 빌드하거나 릴리즈할 때, 히스토리를 기록하고 관리하기 위해 사용한다.

예를 들어 버전은 특정 부분에서 버그가 났을 때 어떤 버전의 어떤 수정점 때문에 발생한 것인지 추적할 수 있게 해주고,
밸런스 패치를 하기 전과 후의 로그를 비교하거나 할 때 기준점이 되어 주기도 한다.

버전 표기 규칙

팀이나 프로젝트마다 사용하는 버전 표기 규칙은 다를 수 있지만,
오늘은 보편적으로 사용되는 규칙에 대해서 알아볼 것이다.

바로 Semantic Versioning (유의적 버전) 이라는 방법이다.
원본 문서는 다음 링크를 참고하라.

- Semantic Verisioning: https://semver.org/

Semantic Versioning 2.0.0

 

---

 

버전 관리 기본 규칙

 

일반적으로 우리는 1.0.0과 같은 형식으로 버전을 작성하며, . 을 기준으로 다음과 같이 파트를 구분할 수 있다.

메이저(major)

기존 버전과 호환되지 않게 API가 바뀌면, 메이저(주, 主) 버전을 올린다.

 

쉽게 말해 크게 바뀌었을 때를 말한다.
좀보이드로 예를 들어 설명하면 41 빌드에서 사용할 수 있던 모드를 42 빌드에서 사용할 수 없게 되는 것과 비슷하다.

메이저 버전이 바뀌면 마이너, 패치 버전은 0으로 초기화된다.

보통 유저에게 처음 공식적으로 릴리즈된 버전을 1로 잡으며,
개발 과정에서 빌드하는 경우 메이저 버전을 0으로 사용한다.

 

---

마이너(minor)

기존 버전과 호환되면서 새로운 기능을 추가할 때, 마이너(부, 部) 버전을 올린다.

새로운 기능이 추가되었을 때를 말한다.
예를 들어, 원래 있던 요리 시스템에 새로운 레시피가 추가된다거나 하는 경우가 있을 것이다.

버전은 소수점 개념이 아니기 때문에 1.0, 1.1, ... 1.9 다음에 1.10 과 같은 방식으로도 진행이 가능하다.
버전은 항상 1씩만 올라가야 한다는 점도 당연하지만 중요하다.

개발 과정의 빌드는 메이저 버전이 0으로 고정되어 있기 때문에, 마이너 버전을 메이저 버전처럼 사용하기도 한다.
예를 들어 빌드를 할 때마다 0.1, 0.2, ... 가 되는 식이다.

---

패치(patch)

기존 버전과 호환되면서 버그를 수정한 것이라면, 패치(수, 修) 버전을 올린다.

 

핫픽스 버전이라고도 부른다.
말 그대로 이미 있는 기능이 정상적으로 작동하지 않을 때, 오류를 수정한 버전을 말한다.
이미 있는 시스템의 폴리싱과 같은 자잘한 일감도 패치에 태우기도 한다.

---

Pre-Release (정식 배포 전) 규칙

위의 메이저.마이너.패치 형식 뒤에 -를 붙여 정식 배포 전 버전이나 빌드 메타데이터를 위한 라벨을 붙일 수도 있다.
예를 들면 다음과 같다.

• 1.0.0-alpha ▶ 1.0.0-beta ▶ 1.0.0 (릴리즈)
  • alpha: 개발 내부 테스트 버전
  • beta: 사용자 대상의 테스트 버전

alpha나 beta 뒤에도 . 으로 추가적인 버전을 붙여 관리할 수도 있다.
이 뒤쪽 규칙은 정말 팀바팀이긴 하다. 간소화해서 사용하거나 아예 사용하지 않는 경우도 있다.

• 1.0.0-alpha.1 ▶1.0.0-alpha.2 ▶ 1.0.0-beta.1 ▶ 1.0.0
• 1.0.0-1 ▶ 1.0.0-2 ▶ ... (이런 식으로 alpha, beta 표기 없이 추가 버전만 기록하는 것도 가능하다.)