iOS 앱 개발에서 버전과 빌드의 이해하기

 

iOS 앱을 개발하고 지속적으로 업데이트하다 보면 반드시 마주치게 되는 개념이 '버전'과 '빌드'입니다. 이 두 가지는 앱의 릴리스 관리에 핵심적인 요소이지만, 많은 개발자들이 그 차이점과 효과적인 관리 방법에 대해 혼란을 겪곤 합니다. 

버전(Version)과 빌드(Build) 이해하기

버전(Version)이란?

버전은 사용자에게 보이는 앱의 '공개 식별자'입니다. 보통 세 개의 숫자로 구성된 형식(예: 1.2.3)을 사용하며, 이를 'Semantic Versioning'(의미론적 버저닝)이라고 부릅니다. iOS 앱에서 버전은 CFBundleShortVersionString 키로 Info.plist 파일에 저장됩니다.

버전 번호의 각 부분은 다음과 같은 의미를 가집니다:

• Major(주 버전): 첫 번째 숫자로, 호환되지 않는 API 변경이 있을 때 증가
• Minor(부 버전): 두 번째 숫자로, 기능 추가와 같은 하위 호환성을 유지하는 변경 시 증가
• Patch(패치 버전): 세 번째 숫자로, 버그 수정과 같은 작은 변경 시 증가

버전은 App Store에서 사용자에게 표시되며, 사용자는 이를 통해 앱의 업데이트 여부를 인식합니다.

빌드(Build)란?

빌드 번호는 개발자를 위한 '내부 식별자'입니다. 같은 버전 내에서도 여러 빌드가 존재할 수 있습니다. 빌드 번호는 Info.plist 파일에 CFBundleVersion 키로 저장됩니다.

빌드 번호는 주로 개발 과정에서 사용되며, 테스트와 디버깅 목적으로 활용됩니다. 사용자는 일반적으로 빌드 번호를 보지 못하지만, 앱 설정이나 '정보' 화면에서 표시할 수도 있습니다.

버전과 빌드의 관계

버전과 빌드의 관계를 이해하기 위한 좋은 비유는 책의 '판'과 '인쇄'의 관계입니다.

• 버전(Version) = 책의 판(Edition): 1판, 2판 등 내용의 중요한 변화를 나타냅니다.
• 빌드(Build) = 책의 인쇄(Printing): 같은 판이라도 여러 번 인쇄될 수 있으며, 작은 오타 수정 등이 포함될 수 있습니다.

효과적인 버저닝 전략

시맨틱 버저닝(Semantic Versioning)

시맨틱 버저닝은 현재 가장 널리 사용되는 버저닝 방법론입니다. 기본 형식은 MAJOR.MINOR.PATCH입니다:

1.2.3
↑ ↑ ↑
│ │ └── 패치 버전: 버그 수정
│ └──── 부 버전: 새로운 기능 (하위 호환성 유지)
└────── 주 버전: 호환되지 않는 변경

이 방식을 따르면 앱의 변경 사항의 중요도를 버전 번호를 통해 명확히 전달할 수 있습니다.

빌드 번호 관리 전략

빌드 번호 관리에는 여러 접근 방식이 있습니다:

1. 단순 증가: 새 빌드마다 1씩 증가 (1, 2, 3, ...)
2. 날짜 기반: 날짜와 시간을 활용 (예: YYMMDDhhmm - 2304151023)
3. 버전 연계: 버전과 빌드를 연계 (예: 버전 1.2.3의 첫 번째 빌드는 1.2.3.1)
4. 자동화 도구 활용: CI/CD 도구에서 제공하는 빌드 번호 자동 생성 (예: Jenkins, Fastlane 등)

실제 버저닝 예시

다음은 앱 개발 과정에서 버전과 빌드가 어떻게 변화하는지 보여주는 예시입니다.

상황 버전(Version) 빌드(Build) 설명

최초 릴리스	1.0.0	1	앱의 첫 출시
버그 수정	1.0.1	2	작은 버그 수정
추가 버그 수정	1.0.2	3	또 다른 버그 수정
새 기능 추가	1.1.0	4	새로운 기능 추가
중요 업데이트	2.0.0	5	호환되지 않는 큰 변경

Xcode에서 버전과 빌드 설정하기

Xcode에서 버전과 빌드 번호를 설정하는 방법은 매우 간단합니다.

1. 프로젝트 네비게이터에서 프로젝트를 선택합니다.
2. 'General' 탭을 선택합니다.
3. 'Identity' 섹션에서 'Version'과 'Build' 필드를 찾을 수 있습니다.

또한 Info.plist 파일에서 직접 다음 키를 수정할 수도 있습니다.

• 버전: CFBundleShortVersionString
• 빌드: CFBundleVersion

자동화된 버저닝 관리

앱 개발이 진행됨에 따라 버전과 빌드 번호를 수동으로 관리하는 것은 번거롭고 오류가 발생하기 쉽습니다. 다음은 이를 자동화하는 몇 가지 방법입니다.

1. 스크립트를 통한 자동화

Xcode의 Build Phase에서 스크립트를 추가하여 빌드 번호를 자동으로 증가시킬 수 있습니다.

# 빌드 번호 자동 증가 스크립트
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

2. Fastlane 활용

Fastlane은 iOS 앱 배포를 자동화하는 도구로, 버전 및 빌드 관리 기능이 포함되어 있습니다.

# Fastfile 예시
lane :increment_build do
  increment_build_number
end

lane :increment_version do |options|
  increment_version_number(
    bump_type: options[:type] # "patch", "minor", "major" 중 하나
  )
end

3. Git 태그와 연동

Git 태그를 버전 관리에 활용하는 방법도 있습니다.

# Git 태그 기반 버전 생성 스크립트
GIT_TAG=$(git describe --tags --abbrev=0)
VERSION=${GIT_TAG#v}
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $VERSION" "${PROJECT_DIR}/${INFOPLIST_FILE}"

App Store 배포 시 고려사항

버전 증가 규칙

App Store에 새 버전을 제출할 때는 다음 규칙을 반드시 준수해야 합니다.

1. 각 새 빌드는 이전보다 큰 빌드 번호를 가져야 합니다.
2. 각 새 버전은 이전보다 큰 버전 번호를 가져야 합니다.

즉, App Store에 이미 버전 1.2.3, 빌드 5를 제출했다면, 다음 제출은 최소한 버전 1.2.3, 빌드 6 또는 버전 1.2.4, 빌드 1이어야 합니다.

테스트플라이트와 App Store 배포

테스트플라이트와 App Store 배포 시 버전과 빌드 번호의 관계를 이해하는 것이 중요합니다.

• 테스트플라이트: 같은 버전 번호에 대해 여러 빌드를 테스트할 수 있습니다.
• App Store: 한 버전 번호에 대해 하나의 빌드만 출시할 수 있습니다.