모바일 개발에서 Build Pipeline — 본질, 단계 및 구성

Build Pipeline이란

Build Pipeline은 코드가 변경될 때마다 자동으로 실행되는 공식화된 일련의 단계입니다. 각 단계는 컴파일 가능성, 테스트 정확성, 취약점 부재, 코드 스타일 준수 등 특정 품질 측면을 확인합니다. 어떤 단계라도 실패하면 파이프라인이 중지됩니다.

파이프라인 개념은 생산 라인에서 유래했습니다 — 공장에서 각 스테이션이 제품에 가치를 추가하는 것과 같습니다. 개발에서 각 단계는 코드가 릴리스 준비가 되었다는 확신을 추가합니다. 최신 파이프라인은 코드로 정의되며(Pipeline as Code) 프로젝트와 함께 Git 리포지토리에 저장됩니다.

Continuous Delivery Foundation, 2025에 따르면, 성숙한 build-pipeline은 커밋에서 릴리스까지의 시간을 주에서 분으로 단축합니다. 이는 완전한 자동화와 독립적인 단계의 병렬 실행을 통해 달성됩니다.

Pipeline as Code

웹 인터페이스를 통해 구성하는 대신, 최신 파이프라인은 YAML 또는 Groovy 파일로 설명됩니다. Jenkinsfile, `.gitlab-ci.yml`, `.github/workflows/build.yml`은 Pipeline as Code의 예입니다. 장점: 버전 관리, 코드 리뷰, 재현성.

선언형(Declarative) vs 스크립트형(Scripted) Pipeline

Jenkins에는 두 가지 구문이 있습니다. 선언형 — 더 간단하며 명확한 stages/steps 구조를 가집니다. 스크립트형 — 더 유연하며 Groovy를 기반으로 합니다. 대부분의 프로젝트에서는 가독성과 예측 가능성이 높은 선언형 접근 방식이 권장됩니다.

일반적인 파이프라인 단계

모바일 애플리케이션의 일반적인 build-pipeline에는 여러 주요 단계가 포함됩니다. 각 단계는 기능을 수행하고 잠재적인 문제를 초기 단계에서 필터링합니다.

체크아웃 및 종속성 설치

파이프라인은 리포지토리를 클론하는 것으로 시작됩니다. 그런 다음 종속성이 설치됩니다: Gradle/Maven 패키지, CocoaPods, SPM(Swift Package Manager), npm 패키지. 이 단계에서 캐싱을 사용하면 후속 빌드가 50-70% 빨라집니다.

린팅 및 정적 분석

컴파일 전에 코드 품질 도구가 실행됩니다: Kotlin용 Detekt 또는 ktlint, Swift용 SwiftLint, JavaScript용 ESLint. 이들은 코드 스타일 준수를 확인하고 코드 분석 수준에서 잠재적인 버그를 찾습니다.

컴파일 및 단위 테스트

코드는 바이너리 형식으로 컴파일되고 단위 테스트는 병렬로 실행됩니다. Android의 경우 `./gradlew testDebugUnitTest`, iOS의 경우 `xcodebuild test -scheme App -destination 'platform=iOS Simulator'`입니다. 테스트 실패는 즉시 파이프라인을 중지합니다.

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

통합 및 UI 테스트

컴파일이 성공하면 애플리케이션 실행이 필요한 테스트가 수행됩니다: Android용 Espresso, iOS용 XCTest/XCUITest, React Native용 Detox. 이 단계에서 아티팩트는 팜 서비스(Firebase Test Lab, BrowserStack, Sauce Labs)를 통해 시뮬레이터나 실제 기기에 배포됩니다.

파이프라인 구성

파이프라인의 올바른 구성은 전체 CI/CD 프로세스의 효율성을 결정합니다. 구성에는 트리거 선택, 병렬 및 순차 단계 정의, 매개변수화 및 외부 서비스와의 통합이 포함됩니다.

파이프라인 트리거

주요 트리거: 리포지토리에 푸시, 풀 리퀘스트(특히 자동 검사가 있는 코드 리뷰), Git 태그 생성(릴리스 빌드용), 일정(나이틀리 빌드). 풀 리퀘스트 트리거는 코드 병합 전에 문제를 식별할 수 있어 팀 작업에 가장 실용적입니다.

병렬 및 순차 단계

독립적인 단계(린팅, 다른 OS 버전에서 테스트)는 속도 향상을 위해 병렬로 실행되어야 합니다. 종속 단계는 순차적으로 실행됩니다. 최신 CI 시스템은 병렬 작업을 자동으로 관리하여 사용 가능한 에이전트에 분배합니다.

• Fail-fast — 병렬 브랜치에서 오류 발생 시 즉시 실패하도록 구성
• Matrix build — 여러 구성(API Level, Xcode 버전)에서 하나의 빌드 실행
• 조건부 단계 — 일부 단계는 특정 브랜치에서만 실행(예: main에서만 배포)

Build Pipeline 최적화

긴 파이프라인은 개발 주기를 늦추고 팀의 동기를 저하시킵니다. 빌드 시간 최적화는 build pipeline을 다루는 DevOps 엔지니어의 주요 작업 중 하나입니다.

종속성 캐싱

Gradle Build Cache는 이전 컴파일 결과를 저장합니다. 모듈의 소스 코드가 변경되지 않으면 다시 컴파일되지 않습니다. Swift와 Kotlin의 증분 컴파일도 유사하게 작동합니다. 캐시 크기는 기가바이트에 달할 수 있지만 시간 절약은 30%에서 70% 사이입니다.

테스트 병렬 실행

단위 테스트는 여러 에이전트에서 동시에 실행할 수 있으며 테스트 클래스를 분산시킵니다. Sharding은 테스트를 그룹(shard)으로 나누는 기술입니다. GitHub Actions는 `strategy.matrix`, Jenkins는 Parallel Test Executor, Gradle은 `--parallel --max-workers`를 지원합니다.

파이프라인 계층 최소화

각 추가 단계는 시간을 추가합니다. 정기적으로 파이프라인을 분석하세요: 어떤 단계를 통합할 수 있습니까? 예를 들어, 린팅은 컴파일 전이 아닌 병렬로 실행할 수 있습니다. 통합 테스트는 모든 커밋이 아닌 풀 리퀘스트에 대해서만 실행합니다.

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Build Pipeline 보안

Build pipeline은 소프트웨어 공급망의 중요한 요소이며, 그 보안을 무시할 수 없습니다. 파이프라인 손상은 릴리스 아티팩트에 악성 코드가 삽입되어 애플리케이션의 모든 사용자에게 영향을 미칠 수 있습니다.

파이프라인에 대한 공급망 공격

알려진 공격: SolarWinds(2020), Codecov(2021), 3CX(2023) — 모두 CI/CD 파이프라인의 취약점을 악용했습니다. 공통 벡터 — 공격자가 빌드 서버의 자격 증명에 접근하여 빌드 단계에서 코드를 수정합니다. 결과 — 합법적인 인증서로 서명된 악성 릴리스.

자격 증명 보호

절대 저장하지 마십시오 서명 키, API 토큰 및 비밀번호를 리포지토리나 CI 시스템 환경 변수에 일반 텍스트로. CI 시스템 시크릿(GitHub Secrets, GitLab CI Variables), HashiCorp Vault, AWS Secrets Manager를 사용하세요. 시크릿에 대한 접근을 최소화하세요 — 각 파이프라인은 특정 단계에 필요한 키만 받아야 합니다.

파이프라인 아티팩트 검증

파이프라인에서 나오는 모든 아티팩트는 암호학적으로 서명되어야 하며 증명(attestation) — 출처 증명(provenance)을 포함해야 합니다. 도구: SLSA 프레임워크, in-toto attestation, 컨테이너 서명용 cosign. 서명 검증은 모든 환경에 배포하기 전에 수행되어야 합니다.

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

파이프라인 모니터링 및 디버깅

Build pipeline은 지속적인 모니터링이 필요한 복잡한 시스템입니다. 메트릭 없이는 파이프라인이 느려졌는지, 어떤 단계가 병목 지점이 되었는지 확인하는 것이 불가능합니다.

파이프라인 메트릭

추적 항목: 총 파이프라인 기간, 각 단계의 시간, 빌드 실패율, 대기열 시간. 대규모 팀(20명 이상의 개발자)의 경우 Grafana 또는 Datadog에서 주/월별 집계 통계가 포함된 대시보드를 설정하는 것이 좋습니다.

장애 알림

모든 파이프라인 장애에는 대응이 필요합니다. 메신저(Slack, Telegram, Discord)에 오류 로그 링크와 커밋 작성자 이름이 포함된 알림을 설정하세요. 심각한 장애의 경우 — 에스컬레이션이 포함된 PagerDuty 또는 Opsgenie.

로컬 파이프라인 디버깅

Act(GitHub Actions용) 또는 Jenkins Pipeline Unit Test와 같은 도구를 사용하면 커밋 없이 파이프라인을 로컬에서 실행할 수 있습니다. 이는 특히 새 단계를 추가하거나 구성을 변경할 때 파이프라인 개발 및 디버깅을 가속화합니다.