Continuous Integration (CI) — 정의, 원칙 및 자동화 설정

Continuous Integration이란

Continuous Integration (CI)는 여러 기여자의 코드를 단일 코드베이스로 통합하는 프로세스를 자동화하는 개발 방법론입니다. 이 용어는 2000년대 초반 Martin Fowler가 “통합 지옥”을 방지하기 위한 일련의 방식으로 도입했습니다. 통합 지옥은 개발자들이 수주 동안 격리되어 작업하고, 변경 사항을 병합할 때 수많은 충돌이 발생하여 수동 해결에 며칠이 걸리는 상황을 말합니다.

CI가 해결하는 문제

CI가 없으면 개발자가 기능을 완료하고 변경 사항을 main 브랜치에 병합하려고 할 때 동료들이 동일한 파일을 수정했음을 발견합니다. 충돌 해결에 몇 시간이 걸리고 종종 작동 중인 코드가 손상됩니다. CI는 하루에 여러 번 통합을 강제하여 이 문제를 해결합니다. 통합이 빈번할수록 충돌이 줄어들고 해결이 쉬워집니다. 실제 경험에 따르면 매일 통합하면 충돌 해결에 몇 분이 걸리지만, 주간 통합하면 몇 시간이 걸립니다.

CI의 경제적 효과

IBM Systems Sciences Institute에 따르면 코딩 단계에서 버그를 수정하는 비용은 25달러, 테스트 단계에서는 100달러, 프로덕션 단계에서는 2,500달러입니다. CI는 결함 감지를 가능한 한 왼쪽으로 이동(shift left)시켜 수정이 거의 무료인 커밋 단계에서 오류를 발견합니다. CI를 사용하는 팀은 디버깅에 평균 15%의 시간을 소비하는 반면, CI가 없는 팀은 35%를 소비합니다.

Continuous Integration의 기본 원칙

Martin Fowler는 기술 스택에 관계없이 관련성을 유지하는 CI의 주요 방식을 정의했습니다. 이러한 원칙을 따르면 CI가 관료적 부담이 아닌 가치를 제공합니다. 모바일 개발은 추가 요구 사항을 부과하지만 핵심은 변하지 않습니다.

단일 리포지토리

모든 프로젝트 코드는 통합된 버전 관리 시스템(Git)을 갖춘 단일 리포지토리에 저장됩니다. 단일 진실 공급원은 기능이 포크에서 개발되어 수주 동안 메인 코드베이스와 동기화되지 않는 상황을 제거합니다. 모바일 프로젝트에서는 Android, iOS 및 백엔드 부분이 하나의 리포지토리(모노레포) 또는 공유 버전 관리 체계를 가진 별도의 리포지토리에 있을 수 있습니다.

자동 빌드

프로젝트 빌드는 단일 명령으로 실행 가능해야 합니다. Android의 경우 ./gradlew assembleDebug, iOS의 경우 xcodebuild 또는 fastlane build입니다. 빌드 스크립트는 재현 가능성을 검증합니다. CI 서버의 빌드는 개발자 머신과 동일한 결과를 생성해야 합니다. 환경 차이는 컨테이너화 또는 IaC(Infrastructure as Code)를 통해 제거됩니다.

자동 테스트

빌드 후 모든 수준의 테스트(유닛, 통합, UI)가 실행됩니다. 테스트가 실패하면 커밋이 무효로 간주됩니다. 녹색 상태 유지는 팀의 공동 책임입니다. 모바일 프로젝트에서는 빠른 테스트(커밋당 5분 이내 실행)를 느린 테스트(실제 기기에서 UI 테스트, 덜 자주 실행)와 분리하는 경우가 많습니다.

// CI 친화적 보고서가 포함된 유닛 테스트 예제
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast 및 투명성

CI 결과는 전체 팀에 공개됩니다. 누구의 커밋이 빌드를 망가뜨렸는지 모두 확인할 수 있습니다. 투명성은 책임 문화를 조성합니다. 개발자는 푸시 전에 변경 사항을 확인하고 순서에 관계없이 손상된 빌드를 수정합니다. CI 서버는 빌드 상태가 변경될 때 Slack 또는 Telegram으로 알림을 보냅니다.

CI 시스템의 구성 요소

완전한 CI 시스템은 서로 상호 작용하는 여러 구성 요소로 구성됩니다. 각 구성 요소는 트리거부터 보고까지 파이프라인의 일부를 담당합니다. CI 아키텍처를 이해하면 문제 진단과 성능 최적화에 도움이 됩니다.

CI 서버

빌드 대기열, 리소스 할당, 결과 게시를 관리하는 중앙 구성 요소입니다. CI 서버는 클라우드 기반(GitHub Actions, GitLab CI, CircleCI) 또는 자체 호스팅(Jenkins, TeamCity)될 수 있습니다. 서버는 웹훅 또는 폴링을 통해 리포지토리 변경을 모니터링하고 푸시 또는 풀 리퀘스트마다 파이프라인을 트리거합니다.

러너와 에이전트

러너는 빌드 작업을 실행하는 가상 또는 물리적 머신입니다. 클라우드 CI에서는 러너가 공급자에 의해 제공되며 사용 시간에 따라 요금이 부과됩니다. 자체 호스팅 러너는 자체 인프라에 설치되며 유지 관리가 필요합니다. iOS 빌드에는 macOS 러너가, Android 빌드에는 Linux 또는 Windows가 필요합니다.

아티팩트와 캐시

빌드 후 CI 시스템은 아티팩트(APK, IPA, 테스트 보고서)를 스토리지에 저장합니다. 이들은 다운로드 및 배포에 사용할 수 있습니다. 실행 간 의존성 캐싱(Gradle 캐시, CocoaPods 캐시)은 후속 빌드를 3~5배 가속화합니다.

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

모바일 개발에는 웹 또는 백엔드 프로젝트와 다른 CI에 대한 특별한 요구 사항이 있습니다. 긴 빌드 시간(Android 3~15분, iOS 5~20분), 여러 아티팩트 유형(APK, AAB, IPA), 서명 및 난독화의 필요성 — 이 모든 것은 CI 파이프라인의 맞춤형 구성이 필요합니다.

Android CI 파이프라인

Android의 일반적인 CI에는 다음이 포함됩니다. 린팅(ktlint, detekt) 및 정적 분석, JUnit 및 MockK를 사용한 유닛 테스트, 디버그 및 릴리스 APK/AAB 빌드, CI 내 에뮬레이터에서 계측 테스트, 아티팩트 게시. Gradle 캐시는 반복 빌드를 가속화합니다. 캐시가 없으면 각 빌드가 의존성을 처음부터 다운로드하여 3~5분을 낭비합니다.

iOS CI 파이프라인

iOS CI는 Swift/Objective-C 코드를 컴파일하기 위해 macOS 러너가 필요합니다. 파이프라인에는 CocoaPods 또는 SPM 의존성 설치, 스타일 검사를 위한 SwiftLint, XCTest를 사용한 유닛 테스트, IPA 빌드, Fastlane match를 통한 코드 서명, TestFlight 업로드가 포함됩니다. 데이터 센터의 Mac mini 또는 Mac에서 자체 호스팅 러너는 클라우드 macOS 러너의 대안입니다.

크로스 플랫폼 프로젝트(Flutter, React Native)

Flutter와 React Native는 두 플랫폼 모두에 대해 네이티브 빌드로 컴파일됩니다. CI는 두 개의 러너를 지원해야 합니다. Android 빌드용 Linux와 iOS 빌드용 macOS입니다. 최적의 전략은 분할 파이프라인입니다. Linux 러너에서 Android 빌드, macOS 러너에서 iOS 빌드를 수행한 후 두 아티팩트를 단일 릴리스로 결합합니다.

CI 도구 비교

CI 도구 선택은 팀 규모, 필요한 성능, 예산, 기술 스택에 따라 달라집니다. 다음은 모바일 개발에 중점을 둔 인기 솔루션의 비교입니다. 자체 호스팅 솔루션은 제어를 제공하지만 관리가 필요하고, 클라우드 솔루션은 편의성을 제공하지만 구성을 제한합니다.

GitHub Actions

공개 리포지토리에 무료(월 2000분). GitHub Actions는 Android(gradle/actions) 및 iOS(apple-actions)용 기성 액션의 생태계를 제공합니다. 단점은 macOS 러너가 유료 요금제에서만 사용 가능하다는 점입니다. 오픈 소스 및 이미 GitHub를 사용하는 소규모 팀에 이상적입니다.

Jenkins

자체 호스팅 오픈 소스 CI 서버입니다. Jenkins는 Groovy Pipeline을 통해 구성되며 수백 개의 플러그인을 지원하고 모든 하드웨어에서 실행됩니다. 설치 및 유지 관리에 DevOps 엔지니어가 필요합니다. 인프라 제어가 중요한 엔터프라이즈 부문에서 인기가 있습니다.

GitLab CI

개방형 러너 아키텍처를 갖춘 GitLab에 내장된 CI/CD입니다. GitLab CI는 무료 요금제에서 자체 러너(macOS 포함)를 사용할 수 있습니다. YAML 구성은 GitHub Actions보다 강력하지만 학습이 더 어렵습니다. GitLab을 단일 DevOps 플랫폼으로 사용하는 팀에 적합합니다.

CircleCI

속도에 중점을 둔 클라우드 CI입니다. CircleCI는 Docker, macOS, Android 이미지를 지원하며 의존성을 자동으로 캐시합니다. 가격은 크레딧 기반으로 소규모 팀에는 GitHub Actions보다 비싸지만 최적화된 러너로 더 빠릅니다. 속도 요구 사항이 있는 프로덕션 프로젝트에 권장됩니다.

CI 설정 예제

GitHub Actions를 사용하여 Android 프로젝트의 CI 설정을 살펴보겠습니다. 파이프라인은 main 브랜치에 대한 푸시 및 풀 리퀘스트마다 정적 분석, 빌드, 테스트를 수행합니다. 최소 구성은 15분이 소요되며 외부 서비스가 필요하지 않습니다.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

파이프라인은 두 개의 병렬 작업으로 구성됩니다. lint(정적 분석 수행)와 unit-tests(lint에 의존 — 린팅이 실패하면 테스트가 실행되지 않음). unit-tests 작업은 테스트 보고서를 아티팩트로 업로드합니다. 팀은 파일을 로컬로 다운로드하지 않고 GitHub Actions UI에서 검토할 수 있습니다.

CI 전 로컬 검사

사소한 오류로 인한 CI 실패를 방지하려면 Git에서 pre-push hook 또는 동일한 검사를 로컬로 실행하는 Gradle 작업을 설정하세요. 예: ./gradlew ktlintCheck detekt testDebugUnitTest. 로컬 검사에 3분 이상 걸리는 경우 빠른 검사(린터)와 느린 검사(테스트)로 분할하여 빠른 검사는 각 커밋 전에, 느린 검사는 푸시 전에만 실행하세요.