Continuous Delivery (CD): 정의 및 Continuous Deployment와의 차이점

Continuous Delivery란

Continuous Delivery (CD)는 Continuous Integration의 확장으로, 릴리스 준비의 모든 단계(릴리스 빌드 생성, 인증서 서명, 난독화, 앱 스토어 메타데이터 검증, 스테이징 배포)에 자동화를 추가합니다. 이 용어는 Jez Humble과 David Farley가 “Continuous Delivery”(2010)라는 책에서 소개했으며, 팀이 릴리스를 예측 가능하고 저위험으로 만들 수 있는 방식을 공식화했습니다.

소프트웨어 전달의 진화

CD 도입 전에는 릴리스가 이벤트였습니다. 팀이 방에 모여 20개 항목의 체크리스트를 실행하고, 수동으로 스크립트를 실행하며, 아무것도 망가지지 않기를 바랐습니다. Continuous Delivery는 릴리스를 이벤트에서 프로세스로 전환합니다. 코드의 작은 변경을 몇 분 만에 사용자에게 제공할 수 있으며, 몇 주가 아니라요. Amazon, Netflix, Etsy가 2010년대에 처음 CD를 도입했으며, 오늘날에는 제품 팀의 표준입니다.

CD의 비즈니스 가치

빠른 기능 제공은 경쟁 우위입니다. 경쟁사가 며칠 만에 새 기능을 릴리스하는데 당신이 몇 달이 걸린다면, 시장은 경쟁사를 선택합니다. DORA 메트릭은 다음을 보여줍니다: 엘리트 팀(CD 사용)의 배포 리드 타임은 1시간 미만, 낮은 팀(CD 미사용)은 1주에서 1개월입니다. CD는 또한 위험을 근본적으로 줄입니다. 작은 변경은 대규모 분기별 릴리스보다 문제를 일으키기 어렵습니다.

CD vs CI vs Continuous Deployment

CI, CD 및 Continuous Deployment라는 용어는 종종 혼동되지만, 이들 사이에는 명확한 경계가 있습니다. 차이점을 이해하면 파이프라인을 올바르게 설계하고 팀의 성숙도와 비즈니스 요구 사항에 맞는 자동화 수준을 선택하는 데 도움이 됩니다.

Continuous Integration

CI는 CD가 구축되는 기초입니다. CI는 모든 커밋이 빌드와 테스트를 통과하도록 보장합니다. CI 없이는 CD가 불가능합니다. 코드가 검증되지 않으면 릴리스할 수 없습니다. CI는 정확성을 검증하고, CD는 비즈니스 사용 준비 상태를 검증합니다.

Continuous Delivery

CD는 CI에 릴리스 빌드 생성, 메타데이터 검증, 서명, 스테이징 또는 베타 테스트용 앱 스토어 배포 단계를 추가합니다. 핵심 차이점은 프로덕션 릴리스 결정을 사람(관리자, 제품 소유자)이 내린다는 것입니다. CD는 릴리스를 “한 번의 클릭”으로 간단하고 안전하게 만듭니다.

Continuous Deployment

Continuous Deployment는 완전한 자동화입니다. CD 파이프라인의 모든 단계를 통과하는 모든 변경 사항이 수동 승인 없이 자동으로 프로덕션에 전송됩니다. Continuous Deployment는 SaaS 제품 및 웹 서비스에 적용 가능하지만, 앱 스토어 정책(App Store Review, Google Play Review는 수동 제출 필요)으로 인해 모바일 개발에서는 거의 사용되지 않습니다.

모바일 애플리케이션을 위한 Continuous Delivery

모바일 애플리케이션을 위한 CD는 웹 및 백엔드 파이프라인과 구분되는 특징이 있습니다. 모바일 릴리스는 앱 스토어(App Store Review, Google Play Review)를 통과하므로 시간 및 프로세스 장벽이 추가됩니다. CD는 검토 제출 전에 자동화할 수 있는 모든 것을 자동화하여 첫 번째 시도에서 검증을 통과할 가능성을 극대화합니다.

Google Play 게시 준비

Android CD 파이프라인에는 다음이 포함됩니다: AAB(Android App Bundle) 빌드, 릴리스 키 서명, R8/ProGuard를 통한 난독화, APK 크기 및 multidex 클래스 확인, 릴리스 노트 생성. Gradle product flavors(free/paid, dev/staging/prod)를 사용하면 하나의 파이프라인에서 여러 구성을 관리할 수 있습니다.

App Store 게시 준비

iOS CD에는 Fastlane match를 통한 인증서 서명, 아이콘 규정 준수 확인(App Store 요구 사항 — 1024×1024 px), 메타데이터(이름, 설명, 키워드) 검증, 비공개 API 부재 확인이 필요합니다. 기술 검증은 altool --validate-app를 통해 App Store Connect에 업로드하지 않고 수행되므로 빠른 피드백을 제공합니다.

# Fastfile — iOS 및 Android를 위한 완전한 CD 파이프라인
platform :ios do
  desc "iOS CD — 릴리스 준비 및 TestFlight 업로드"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — AAB 빌드 및 Google Play Console 업로드"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight는 스크린샷을 수집하고, match를 통해 인증서를 얻고, IPA를 빌드하여 TestFlight에 업로드합니다. Android용 deliver_to_internal 레인은 Gradle을 통해 Release AAB를 빌드하고 Google Play Console의 내부 트랙에 업로드합니다. 두 파이프라인 모두 테스트 통과 후 CI에서 실행됩니다.

CD 파이프라인 구성 요소

CD 파이프라인은 순차적 단계로 구성되며, 각 단계는 릴리스가 사용자에게 준비되었다는 신뢰를 더합니다. 단계는 기술적(빌드, 서명)과 제품적(메타데이터, 스크린샷, 설명 검증)으로 나뉩니다. 어떤 단계를 건너뛰면 앱 스토어에서 릴리스가 거부될 위험이 높아집니다.

버전 관리

CD의 중요한 구성 요소는 자동 버전 관리입니다. 버전 증가(Android의 versionCode 및 versionName, iOS의 CFBundleVersion 및 CFBundleShortVersionString)는 Git 태그 또는 스토어의 이전 버전을 기반으로 수행됩니다. Fastlane increment_version_number 및 Gradle 명령(versionCode auto-increment)이 이 단계를 자동화합니다.

스토어 메타데이터

Google Play Console 및 App Store Connect에는 다음이 필요합니다: 앱 설명, 키워드, 카테고리, 평점, 개인정보 처리방침 링크. CD에는 메타데이터의 존재와 정확성 확인이 포함됩니다. Fastlane deliver 및 supply는 빌드와 함께 설명, 스크린샷, 아이콘 업로드를 자동화합니다.

게이트 검사

검토를 위해 제출하기 전에 파이프라인은 게이트 검사를 수행합니다: 빌드 크기 검사(APK > 200MB는 Google Play에서 거부), 모든 로컬라이제이션 존재, 릴리스 빌드의 디버그 기호 부재, 크래시 로그 디코딩을 위한 ProGuard 매핑 파일 검사. 검사 중 하나라도 실패하면 파이프라인이 릴리스를 차단합니다.

CD를 위한 자동화된 테스팅

CD에 대한 신뢰 수준은 자동화된 테스트의 품질에 정비례합니다. 테스트가 회귀를 잡지 못하면 릴리스가 프로덕션을 망가뜨릴 수 있고 팀은 CD에 대한 신뢰를 잃습니다. 모바일 CD에는 플랫폼 특성에 맞게 조정된 3계층 테스트 피라미드가 필요합니다.

단위 테스트

단위 테스트는 비즈니스 로직을 격리하여 검증합니다. 중요한 모듈(인증, 결제, 네트워킹)의 코드 커버리지는 최소 70%여야 합니다. CI는 푸시할 때마다 단위 테스트를 실행하며, 실패하면 수정될 때까지 CD 파이프라인이 차단됩니다.

통합 테스트

컴포넌트 상호 작용을 검증합니다: 실제 API(또는 모의 서버)를 사용한 네트워크 계층, 데이터베이스, 파일 시스템. Android용 Room DAO 테스트, iOS용 Core Data 테스트는 통합 테스트의 예입니다. 단위 테스트보다 느리며(1~5분) 모든 커밋의 CI가 아닌 CD 단계에서 실행됩니다.

UI 및 스크린샷 테스트

스크린샷 테스트(스냅샷 테스트)는 앱 화면을 참조 이미지와 비교합니다. 코드 변경이 UI를 변경한 경우 테스트가 실패하고 개발자가 변경이 예상되는지 확인합니다. Android는 Roborazzi 및 Paparazzi를 지원하고, iOS는 Point-Free의 SnapshotTesting을 지원합니다. 스크린샷 테스트는 CD 파이프라인의 일부로 릴리스 전에 실행됩니다.

Continuous Delivery 모범 사례

Continuous Delivery를 구현하려면 도구뿐만 아니라 팀 문화의 변화도 필요합니다. 아래의 관행은 Google, Spotify, Uber의 모바일 팀의 수년간 경험을 기반으로 하며 모든 규모의 프로젝트에 적용됩니다.

Feature Flags

새 기능의 코드는 프로덕션에 제공되지만 플래그 뒤에 숨겨집니다. Feature flags를 사용하면 기능이 사용자에게 공개되기 전에 코드를 배포하고 문제 발생 시 즉시 비활성화할 수 있습니다. 라이브러리: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags는 모바일 프로젝트에서 CD의 필수 요구 사항입니다.

스테이징 환경

프로덕션에 제공하기 전에 빌드는 스테이징에 배포됩니다. 이는 프로덕션과 동일하지만 테스트 데이터를 사용하는 환경입니다. QA 엔지니어는 TestFlight 또는 Internal Testing 트랙을 통해 설치된 스테이징 빌드에서 기능을 검증합니다. 스테이징을 통과하면 빌드는 스토어 검토 제출 승인을 받습니다.

릴리스 노트 및 체인지로그

CD는 커밋 메시지를 기반으로 릴리스 노트를 자동 생성합니다. Conventional Commits(feat:, fix:, chore:) 및 시맨틱 버저닝 형식의 Git 태그를 사용하면 변경 내역을 구문 분석할 수 있습니다. Fastlane changelog_from_git_commits는 마지막 두 태그 간의 변경 사항을 수집하여 앱 스토어용으로 형식화합니다.

릴리스 후 모니터링

CD는 게시로 끝나지 않습니다. 릴리스 후 모니터링이 시작됩니다: 크래시율, Android의 ANR율, 시작 시간, 결제 실패율. 메트릭이 정상 한계를 초과하면 CD 파이프라인이 자동으로 릴리스를 롤백하거나 팀에 알려야 합니다. 도구: Firebase Crashlytics, Sentry, New Relic.

// CD를 위한 Firebase Remote Config를 사용한 Feature Flag 예제
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// 코드에서 사용
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}