CI/CD Pipeline — 정의, 자동화 단계 및 도구

CI/CD Pipeline이란

CI/CD Pipeline은 리포지토리에 변경 사항을 커밋하는 순간부터 프로덕션에 배포할 때까지 코드가 거치는 공식화되고 자동화된 프로세스 집합입니다. 이 용어는 Continuous Integration(지속적 통합)과 Continuous Delivery(지속적 전달)라는 두 가지 방식을 결합하여 소프트웨어 전달 파이프라인을 형성합니다.

CI/CD의 역사

Continuous Integration의 개념은 1991년 Grady Booch가 설명했고 2000년대에 Martin Fowler가 대중화했습니다. Continuous Delivery라는 용어는 Jez Humble과 David Farley의 저서 “Continuous Delivery”(2010) 이후 확립되었습니다. 현대의 CI/CD Pipeline은 2015년 이후 클라우드 CI 서버와 앱 스토어 자동화의 등장으로 모바일 개발의 사실상 표준이 되었습니다.

모바일 개발에 CI/CD Pipeline이 필요한 이유

모바일 애플리케이션은 빌드 및 게시에 특정 요구 사항이 있습니다: 인증서 서명, 여러 구성(debug, release, staging), ProGuard/R8 난독화, 여러 빌드 유형(APK, AAB, IPA), 앱 스토어와의 통합. 이러한 단계를 수동으로 실행하면 몇 시간이 걸리고 오류가 발생하기 쉽습니다 — CI/CD Pipeline이 일상 작업을 자동화합니다.

모바일 앱을 위한 CI/CD Pipeline 단계

Android 또는 iOS 앱을 위한 표준 CI/CD Pipeline은 7가지 주요 단계로 구성됩니다. 일부 단계는 병렬로 실행되고 다른 단계는 순차적으로 실행됩니다. 정확한 단계 구성은 기술 스택과 팀 성숙도에 따라 다르지만 핵심은 동일합니다.

1. 체크아웃 및 종속성 설치

파이프라인은 리포지토리 복제와 종속성 설치로 시작됩니다: Android의 경우 Gradle/Maven, iOS의 경우 CocoaPods 또는 SPM. 실행 간 종속성 캐싱은 설치 시간을 3~5분에서 몇 초로 줄입니다 — 모든 최신 CI 서비스가 이 최적화를 지원합니다.

2. 정적 분석 및 린팅

빌드 전에 코드는 린터(Android용 ktlint, detekt, iOS용 SwiftLint)와 정적 분석기(Android Lint, SonarQube)로 검사됩니다. 린팅은 테스트 실행 전에 잠재적 버그, 코드 스타일 위반, 사용되지 않는 API를 감지합니다 — fail-fast 원칙이 팀 시간을 절약합니다.

3. 프로젝트 빌드

빌드 단계에서는 전체 프로젝트가 컴파일되고 아티팩트가 생성됩니다: Android의 경우 APK와 AAB, iOS의 경우 IPA. Android는 Gradle 태스크(assembleDebug, bundleRelease)를 사용하고 iOS는 xcodebuild 또는 xcrun을 사용합니다. 빌드는 CI 서버의 격리된 환경에서 실행되어 재현성을 보장합니다.

# GitHub Actions에서 Android용 CI/CD Pipeline 예시
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. 자동화된 테스트

빌드 후에 단위 테스트, 통합 테스트, UI 테스트가 실행됩니다. 단위 테스트에는 JUnit과 MockK, Android UI에는 Espresso와 Compose Test, iOS에는 XCTest와 XCUITest가 사용됩니다. 결과는 보고서에 게시되며 중요한 테스트가 실패하면 파이프라인이 차단됩니다.

5. 서명 및 난독화

릴리스 빌드의 경우 디지털 인증서 서명(Android의 APK Signer, iOS의 codesign)과 코드 난독화가 수행됩니다. Android용 ProGuard 또는 R8은 APK 크기를 15~30% 줄입니다. 서명 키는 CI 서버의 시크릿에 저장되며 — 리포지토리에 커밋되지 않습니다.

6. 전달 및 배포

파이프라인의 최종 단계는 아티팩트 게시입니다: Google Play Console 내부 테스트에 APK 업로드, TestFlight에 IPA 전송, Firebase Distribution에 게시. Continuous Delivery는 이 단계에 수동 승인이 필요함을 의미하며, Continuous Deployment는 자동으로 실행됩니다.

7. 알림 및 보고서

파이프라인이 완료되면 팀은 결과 알림을 받습니다: 성공/실패, 실행 시간, 아티팩트 링크. Slack, Telegram 또는 이메일 — 알림 채널은 팀 필요에 따라 선택됩니다. 단계가 실패하면 알림에 특정 오류 로그 링크가 포함됩니다.

CI와 CD의 차이

CI와 CD라는 용어는 종종 단일 개념 CI/CD로 사용되지만, 둘 사이에는 근본적인 차이가 있습니다. CI(Continuous Integration)는 각 코드 통합 시 품질 검사를 담당하고, CD(Continuous Delivery)는 코드의 릴리스 준비 상태를 보장합니다. 파이프라인을 설계할 때 이 차이를 이해하는 것이 중요합니다.

Continuous Integration — 품질 검사

CI는 모든 push 또는 pull request에서 실행되며 빌드, 정적 분석, 테스트를 포함합니다. CI의 목표는 수정 비용이 최소일 때 가능한 한 빨리 문제를 감지하는 것입니다. CI가 실패하면 — 코드가 메인 브랜치에 들어가지 않습니다. 모바일 프로젝트의 평균 CI 실행 시간은 5~15분입니다.

Continuous Delivery — 릴리스 준비

CD는 CI에 릴리스 준비 단계를 추가합니다: 서명, 난독화, 릴리스 노트 작성, 라이선스 확인, 테스터를 위한 스토리지에 게시. CD는 보장합니다 메인 브랜치의 모든 커밋이 한 번의 클릭으로 프로덕션에 배포될 수 있지만, 릴리스 자체는 수동 승인이 필요합니다.

CI/CD Pipeline 구축 도구

모바일 개발을 위한 CI/CD 도구 생태계에는 클라우드 서비스, 자체 호스팅 솔루션, 전문 플랫폼이 포함됩니다. 도구 선택은 팀 규모, 예산, 보안 요구 사항에 따라 달라집니다. 아래는 가장 인기 있는 옵션입니다.

GitHub Actions

GitHub에 내장된 CI/CD로, 공개 리포지토리에 대해 월 2000분의 무료 한도가 있습니다. GitHub Actions는 기성 액션의 거대한 생태계(마켓플레이스), YAML을 통한 쉬운 설정, GitHub 리포지토리와의 완벽한 통합 덕분에 인기가 있습니다. 제한 사항 — 무료 요금제에서 iOS 빌드용 Windows 러너를 지원하지 않습니다.

GitLab CI/CD

강력한 YAML 구성기를 갖춘 자체 호스팅 및 클라우드 솔루션. GitLab CI는 병렬 작업, 캐싱, 아티팩트, 환경을 지원합니다. 자체 인프라에 배포할 수 있고 데이터를 완전히 제어할 수 있어 엔터프라이즈 부문에서 인기가 있습니다.

Jenkins

클래식 오픈 소스 CI 서버. Jenkins는 플러그인(1800개 이상)을 통해 구성되며, Groovy 형식의 Declarative Pipeline을 지원하고 Windows, macOS, Linux 등 모든 환경에서 실행됩니다. 전담 관리가 필요하지만 최대 구성 유연성을 제공합니다.

CircleCI

속도와 단순성에 초점을 맞춘 클라우드 CI 서비스. CircleCI는 종속성을 자동으로 캐시하고, 격리된 빌드를 위한 Docker 이미지를 지원하며, iOS 빌드를 위해 macOS와 통합됩니다. 가격은 크레딧 기반 — 성능을 중시하는 팀에 적합합니다.

CI/CD Pipeline 설정 예제

GitHub Actions와 Fastlane을 사용한 iOS 앱용 완전한 CI/CD Pipeline을 살펴보겠습니다. Fastlane은 모바일 프로젝트를 위한 자동화 도구로, 복잡한 빌드, 서명, 게시 작업을 간단한 명령으로 추상화합니다.

# Fastfile — iOS CI/CD용 Fastlane 구성
default_platform(:ios)

platform :ios do
  desc "테스트 및 린트 실행"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "릴리스 빌드 및 TestFlight 업로드"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match는 인증서와 프로비저닝 프로필을 관리하고, build_app은 IPA를 빌드하며, pilot은 빌드를 TestFlight에 업로드합니다. fastlane release 명령은 모든 단계를 순차적으로 실행합니다: 인증서 획득, 빌드, 서명, 베타 테스터를 위한 App Store Connect에 업로드.

GitHub Actions를 사용한 iOS용 CI/CD Pipeline

Fastlane을 GitHub Actions와 통합하면 메인 브랜치에 대한 pull request 시 전체 파이프라인을 자동으로 실행할 수 있습니다. iOS 코드 컴파일을 위해서는 macOS의 자체 호스팅 러너가 필요합니다 — GitHub는 무료 요금제에서 macOS 러너를 제공하지 않습니다.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

CI/CD Pipeline 모범 사례

효과적인 CI/CD Pipeline을 구축하려면 도구 선택뿐만 아니라 입증된 사례를 따르는 것도 필요합니다. 적절한 조직화 없이는 파이프라인이 병목 현상이 되어 개발을 가속화하는 대신 느리게 만들 수 있습니다. 아래는 성숙한 모바일 팀의 경험을 바탕으로 한 주요 권장 사항입니다.

Fail Fast

가장 빠른 검사(린팅, 단위 테스트)가 먼저 실행됩니다. 실패하면 — 긴 UI 테스트나 릴리스 빌드 없이 파이프라인이 종료됩니다. Fail fast는 CI 시간을 절약하고 개발자 피드백을 가속화합니다. 첫 실패까지의 평균 시간은 2~3분을 초과하지 않아야 합니다.

종속성 캐싱

Gradle 캐시, CocoaPods 캐시, SPM 캐시는 실행 간에 복원되어야 합니다. GitHub Actions는 actions/cache를 통한 캐싱을 지원하고, GitLab CI는 cache 키워드를 통해 지원합니다. 캐싱이 없으면 각 빌드가 모든 종속성을 새로 다운로드하여 — 파이프라인 시간에 3~10분이 추가됩니다.

병렬 실행

독립적인 단계(Android와 iOS용 린터, 다른 모듈의 단위 테스트)는 병렬 작업으로 실행됩니다. 병렬화는 전체 파이프라인 시간을 20~30분에서 5~10분으로 줄입니다. 대부분의 CI 서비스는 병렬 작업을 별도로 청구합니다 — 요금제 선택 시 고려하세요.

환경 격리

각 파이프라인 실행은 깨끗한 환경에서 실행됩니다: Docker 컨테이너, 가상 머신 또는 임시 러너. 격리는 이전 빌드가 현재 빌드에 영향을 미치는 것을 방지합니다. 프로젝트 간 공유 러너 사용을 피하세요 — 교차 프로젝트 환경 오염은 비결정적 실패로 이어집니다.

시크릿 보안

API 키, 서명 인증서, 앱 스토어 액세스 토큰은 CI 서버의 암호화된 보관소에 저장됩니다. SECRET_ 접두사 없이 로그, 아티팩트 또는 환경 변수에 시크릿을 절대 포함하지 마세요. iOS 인증서 관리에는 Fastlane match와 같은 도구를 사용하세요.