게임 빌드 버전 관리 정책 제안

개요

• 게임 앱의 안정성, 품질, 일관성을 유지하기 위해 빌드 버전 관리 체계를 수립.

• 운영 및 업데이트 과정에서 개발, QA, 배포 간의 명확한 커뮤니케이션을 지원.

• 사용자 경험을 향상시키기 위해 버전별 기능 및 문제 추적을 용이하게 함.

본 버전 정책 제안 가이드는 런칭 전 릴리즈 버전 선점으로 인한 문제를 방지하기 위한 가이드 입니다.

iOS

1) Bundle Version (CFBundleShortVersionString)

• 마케팅 버전(사용자 표시)

• 예: 1.2.0, 0.0.1000 등

• 실제 사용자에게 보이는 버전이며, 일반적으로 Major.Minor.Patch 형태를 사용합니다.

2) buildNumber (CFBundleVersion)

• 빌드 식별자(내부 식별)

• 예: 42

• App Store Connect에 업로드할 때, 이전에 업로드한 빌드 번호보다 커야 합니다.

• iOS에서는 문자열 형태(1.0.0)도 가능하지만, Android와 통일성을 유지하기 위해 정수 형태를 사용하는 것을 권장합니다.

예시 규칙

• Dev: 0.0.1000

• QA: 0.100.1

• Release: 1.0.0

개발 편의를 위해 실제 유저에게 표시되는 버전과 개발용 버전(Dev/QA 버전)을 구분 지어 두면, 어느 빌드가 어디에 쓰였는지 빠르게 파악할 수 있습니다.

---

Android

1) Bundle Version (versionName)

• 마케팅 버전(사용자 표시)

• 예: 1.2.0, 0.100.1 등

• 실제 사용자에게 보이는 버전이며, 일반적으로 Major.Minor.Patch 형태를 사용합니다.

2) Bundle Version Code (versionCode)

• 빌드 식별자(내부 식별)

• 예: 42

• Google Play Console에 업로드할 때, 이전 버전 코드보다 커야 합니다.

• 정수(Integer)만 사용 가능하며, iOS와 달리 문자열 형태를 지원하지 않습니다.

예시 규칙

• Dev: 0.0.1000

• QA: 0.100.1

• Release: 1.0.0

마찬가지로 내부 테스트 및 QA 단계에서 versionName을 구분해두면, 빌드가 여러 개 올라가더라도 쉽게 식별할 수 있습니다.

---

공통 권장 사항

1. 빌드 번호 증가

   • TestFlight(iOS), Firebase App Distribution(Android) 등 베타 배포 툴을 사용할 경우, 빌드할 때마다 빌드 번호(또는 versionCode)를 +1씩 자동 증가시키는 것이 좋습니다.

   • 로컬에서 임시로 빌드하여 테스트하는 수준이라면 굳이 번호를 올릴 필요는 없습니다 (어차피 스토어/베타 채널에 업로드되지 않으므로)

2. 버전 체계 통일

   • iOS CFBundleVersion은 문자열 사용도 가능하지만, Android와 맞추어 정수 형태로 통일하는 편이 프로젝트 관리에 유리합니다.

3. 마케팅 버전 vs. 내부 버전

   • 사용자에게 표시할 버전(예: 1.0.0)과 개발/QA용 버전(예: 0.0.1000)을 적절히 구분하여, 빌드마다 “이게 어느 단계(Dev/QA/Release)의 버전인가?”를 명확히 알 수 있도록 하면 추적이 쉬워집니다.