GitHub Actions — 개념, CI/CD 파이프라인 및 자동화

저자: IT Sectr 게시일: 2026-04-13 읽는 시간: 8 분

GitHub Actions는 GitHub에 내장된 CI/CD 및 자동화 플랫폼으로, 리포지토리에서 직접 모바일 애플리케이션의 빌드, 테스트 및 배포를 실행할 수 있습니다. GitHub, 2024에 따르면, 이 플랫폼은 마켓플레이스에서 15,000개 이상의 기성 액션을 제공하며, 린팅부터 앱 스토어 출시까지 개발의 모든 단계를 포괄합니다.

핵심 사항

  • GitHub Actions — 개발 워크플로 자동화를 위한 GitHub의 내장 CI/CD 플랫폼
  • Workflow — .github/workflows 디렉토리의 YAML 파일에 설명된 자동화된 프로세스
  • Runner — 모바일 앱 빌드를 포함한 워크플로 작업을 실행하는 가상 머신
  • Marketplace는 Android SDK, Xcode, Firebase 및 기타 도구용 기성 액션 제공
  • Matrix strategy는 다양한 OS 및 도구 버전에서 병렬 빌드 실행

GitHub Actions란?

GitHub Actions는 GitHub에 내장된 워크플로 자동화 플랫폼으로, 2019년에 출시되었습니다. 리포지토리에 직접 저장된 YAML 파일에서 CI/CD 파이프라인을 정의할 수 있습니다. 각 워크플로는 푸시, 풀 리퀘스트, 태그 생성 또는 일정에 따라 트리거됩니다. Jenkins나 TeamCity와 달리 CI 서버 호스팅을 위한 별도의 인프라가 필요하지 않습니다.

모바일 개발 맥락에서 GitHub Actions는 APK 및 IPA 빌드, 에뮬레이터에서 단위 테스트 및 UI 테스트 실행, 린터를 통한 코드 검사, 서명, Google Play 및 App Store에 출시를 자동화합니다. 플랫폼은 무료 시간을 제공하며, 공개 리포지토리의 경우와 비공개 리포지토리의 경우 요금제에 따라 제공됩니다. 오픈 소스 모바일 프로젝트의 경우 비용 없이 완전한 CI/CD 솔루션입니다.

GitHub Actions 아키텍처: Workflows, Jobs 및 Steps

GitHub Actions 아키텍처는 4개 레벨로 구성됩니다. Workflow는 자동화를 정의하는 루트 YAML 파일입니다. Workflow는 Job으로 구성되며, 각 Job은 별도의 Runner에서 실행됩니다. Job 내에서는 Steps(순차 명령 또는 외부 액션)가 실행됩니다. Events는 트리거(push, pull_request, schedule, workflow_dispatch)를 정의합니다. GitHub 인터페이스의 Actions 탭을 통해 워크플로를 수동으로 트리거할 수도 있습니다.

GitHub는 OS가 사전 설치된 호스티드 러너(Ubuntu, macOS, Windows)를 제공합니다. iOS 빌드에는 macOS 러너가 필수이며, Android에는 Linux 또는 macOS가 필요합니다. 셀프 호스티드 러너를 사용하면 사용자 지정 환경의 자체 서버에서 작업을 실행할 수 있어 특수 하드웨어 요구 사항이 있는 대규모 프로젝트에 유용합니다. GitHub는 작업 실행 대기열 구성을 위한 셀프 호스티드 러너 그룹도 지원합니다.

워크플로 파일 구조

기본 워크플로 파일에는 name, on(트리거), jobs 섹션이 포함됩니다. 각 작업은 runs-on(러너 유형), strategy(매트릭스), steps(작업 목록)을 지정합니다. Steps는 셸 명령 또는 마켓플레이스의 기성 액션이며, owner/repo@version 구문을 통해 연결됩니다.

GitHub Actions에서 모바일 애플리케이션 빌드

Android 빌드의 경우 워크플로에는 일반적으로 리포지토리 체크아웃, JDK 설치, Gradle 캐시 구성, assembleRelease 실행 단계가 포함됩니다. iOS의 경우 macOS 러너가 필요하며, xcode-select를 통한 Xcode 설치, 프로비저닝 프로파일 해결 및 xcodebuild 실행이 필요합니다. iOS 빌드의 복잡성은 코드 서명과 인증서 관리에 있습니다. Apple별 설정에는 apple-actions/import-codesign-certs를 통한 프로비저닝 프로파일 관리가 포함됩니다.

Matrix strategy를 사용하면 여러 버전에서 동시에 빌드를 실행할 수 있습니다. 예: iOS 버전(15.0, 16.0, 17.0) 및 Xcode(14, 15)의 매트릭스. 이로 인해 검증이 가속화되어 다양한 OS 버전과의 애플리케이션 호환성을 확인할 수 있지만, 러너 시간 소비가 증가합니다. CI 예산이 제한된 프로젝트의 경우 매트릭스를 주요 구성으로만 제한할 수 있습니다.

Android 환경 설정

GitHub Actions는 JDK 설치용 setup-java 액션과 Gradle 캐싱용 caching을 제공합니다. Android SDK는 Ubuntu 러너에 사전 설치되어 있습니다. 사용자 지정 API 수준의 경우 별도 단계에서 sdkmanager를 사용합니다. Android와 iOS 빌드는 서로 다른 러너와 빌드 도구를 사용하므로 별도의 워크플로를 만드는 것이 좋습니다.

GitHub Marketplace 및 기성 액션

GitHub Marketplace에는 커뮤니티와 공식 개발자가 만든 15,000개 이상의 액션이 있습니다. 모바일 개발의 주요 카테고리에는 코드 서명(apple-actions/import-codesign-certs), 테스트(react-native-community/action), 배포(google-github-actions/release-google-play), 알림(slackapi/slack-github-action)이 포함됩니다. Firebase App Distribution, TestFlight 업로드 및 Fastlane용 액션도 사용할 수 있습니다. 각 액션에는 특정 러너 OS와의 호환성 레이블이 있습니다.

각 액션에는 버전, 설명, README 및 라이선스가 있습니다. 액션을 선택할 때는 공급업체(Google, Apple, Microsoft)의 공식 액션과 Verified Badge로 검증된 액션을 우선시해야 합니다. 고정 메이저 버전(actions/checkout@v4)을 지정하는 것이 중요하며, @main을 지정하여 예기치 않은 변경을 방지합니다. 필요한 액션이 Marketplace에 없는 경우 사용자 지정 액션을 만들 수 있습니다(리포지토리 내 Docker 액션 또는 JavaScript 액션, 또는 Marketplace에 게시).

모바일 CI/CD용 인기 액션

  • actions/checkout — 리포지토리를 러너에 복제
  • actions/setup-java — Android 빌드용 JDK 설치
  • gradle/actions/setup-gradle — Gradle 구성 및 캐싱
  • apple-actions/import-codesign-certs — iOS용 인증서 가져오기
  • google-github-actions/submit-release — Google Play Console에 게시

iOS 프로젝트용 워크플로 예시

iOS 애플리케이션을 개발할 때는 시뮬레이터와 기기에서 올바른 작동을 설정하는 것이 중요합니다. macOS-14 러너는 ARM 아키텍처에서 Intel 빌드를 실행하기 위한 Rosetta 2가 포함된 환경을 제공합니다. 워크플로에는 여러 빌드 스킴(풀 리퀘스트용 Debug 및 태그용 Release)을 포함할 수 있습니다. GitHub Actions는 테스트 결과 표시를 위한 xcparse/sonarqube 액션을 통한 xcresult 파싱을 지원합니다. 빌드 상태 알림을 보내기 위해 Slack 또는 Telegram 액션을 추가할 수 있습니다.

iOS의 코드 서명에는 인증서 및 프로비저닝 프로파일 가져오기가 필요합니다. Apple-actions는 P12 인증서 가져오기 및 프로비저닝 프로파일 설치를 위한 단계를 제공합니다. 인증서는 GitHub Actions 시크릿으로 저장되며 빌드 단계에서만 해독됩니다. 서명 자동화에는 Fastlane match가 사용되며, 워크플로에서 별도 단계로 호출할 수 있습니다.

Swift로 작성된 iOS 앱의 워크플로를 살펴보겠습니다. 프로젝트를 빌드하고, 테스트를 실행하고, 아카이브 빌드를 생성합니다. 이 워크플로는 macOS-14 러너, Xcode 15.4 및 인증서 관리용 액션을 사용합니다.

yaml
name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

GitHub Actions에서 종속성 캐싱

캐싱은 워크플로 실행 간에 종속성을 유지하여 빌드 시간을 줄입니다. GitHub는 actions/cache를 통한 내장 캐싱을 제공합니다. Gradle의 경우 ~/.gradle, CocoaPods의 경우 Pods/, SPM의 경우 .build/가 캐시됩니다. 캐시 키에는 종속성 목록 파일의 해시가 포함되며, 종속성이 변경되면 캐시가 자동으로 무효화됩니다.

캐시 복원 전략(restore-keys)에 특별한 주의를 기울여야 합니다. 정확한 키를 찾을 수 없는 경우 GitHub Actions는 restore-keys로 부분 일치를 시도합니다. 이것은 하나의 종속성만 변경될 때 유용하며, 캐시가 부분적으로 사용 가능한 상태로 유지됩니다. Gradle의 경우 프로젝트의 여러 모듈 간에 빌드 결과를 캐시하는 Gradle Build Cache를 활성화하는 것이 추가로 권장됩니다.

Gradle 캐싱 예시

yaml
- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

캐시 효율성(Android 프로젝트): 캐시 없는 첫 번째 빌드 — 8–12분, 캐시 있는 후속 빌드 — 2–4분. CocoaPods를 사용하는 iOS의 경우도 유사한 절감 효과가 있습니다. 최적의 캐시 관리를 위해 actions/cache를 Gradle의 setup-gradle 액션과 결합하는 것이 좋습니다. React Native의 npm 종속성의 경우 package-lock.json 해싱과 함께 actions/cache가 사용됩니다. 적절한 캐시 구성으로 빌드 시간을 최대 70%까지 줄일 수 있습니다.

GitHub Actions는 워크플로, 작업 및 단계 수준에서 환경 변수를 지원합니다. 환경 변수는 재정의 가능하며, 단계 수준이 가장 높은 우선순위를 가집니다. 기밀 데이터에는 항상 시크릿을 사용하세요. 시크릿은 AES-256으로 암호화되며 로그에 표시되지 않습니다. 환경 보호 규칙(배포 전 필수 수동 승인)도 사용할 수 있습니다. 추가 보안을 위해 특정 사용자 또는 팀의 필수 승인을 구성할 수 있습니다.

GitHub Actions는 Reusable Workflows도 지원합니다. 이는 다른 워크플로에서 호출할 수 있는 재사용 가능한 파이프라인입니다. 이를 통해 중앙 집중식 빌드 워크플로를 만들고 조직의 모든 리포지토리에서 재사용할 수 있습니다. Reusable workflow는 한 줄로 호출되며 입력 매개변수와 시크릿을 받을 수 있습니다. 이는 대규모 팀에서 CI/CD 관행을 표준화하는 데 특히 유용합니다.

보안 및 모범 사례

모바일 프로젝트용 GitHub Actions를 구성할 때는 보안 원칙을 따르는 것이 중요합니다. OIDC(OpenID Connect)를 사용하면 장기 자격 증명을 제거하고 클라우드 제공업체용 임시 토큰을 얻을 수 있습니다. 스크립트에서 일반 텍스트 시크릿을 절대 사용하지 마세요. GitHub Actions는 로그에서 시크릿을 자동으로 마스킹합니다.

모바일 프로젝트의 경우 타사 포크의 워크플로 액세스를 제한하는 것이 중요합니다. pull_request_target 설정을 주의해서 사용하세요. 포크가 아닌 기본 브랜치의 코드를 실행합니다. iOS 앱 코드 서명의 경우 인증서를 암호화된 상태로 저장하고 gpg 또는 openssl을 통해 빌드 단계에서만 해독하는 것이 좋습니다.

자주 묻는 질문

GitHub Actions 비용은 얼마인가요?

공개 리포지토리의 경우 GitHub Actions는 무료이며 월 2000분 제한이 있습니다. 무료 요금제의 비공개 리포지토리의 경우 500분입니다. Team 및 Enterprise 요금제에는 각각 3000분 및 50000분이 포함됩니다.

iOS 빌드에는 어떤 러너가 필요합니까?

iOS 빌드에는 macOS 러너가 필요합니다(macos-13, macos-14 또는 macos-latest). iOS용 Xcode 및 코드 서명 도구는 macOS에서만 사용할 수 있습니다. Android 빌드는 Linux와 macOS 모두에서 실행할 수 있습니다.

GitHub Actions에 시크릿을 전달하려면 어떻게 해야 합니까?

시크릿은 리포지토리의 Settings → Secrets and variables → Actions에서 구성합니다. 워크플로에서는 ${{ secrets.MY_SECRET }} 구문으로 사용합니다. 시크릿은 암호화되어 로그에 표시되지 않으며 워크플로 실행 중에만 사용할 수 있습니다.

GitHub Actions를 로컬에서 실행할 수 있습니까?

네, 커뮤니티의 act 유틸리티를 통해 가능합니다. Docker 컨테이너에서 로컬로 워크플로를 실행합니다. 커밋 전 디버깅에 유용하지만 macOS별 단계(Xcode 빌드)는 지원되지 않습니다.

특정 경로로 워크플로 실행을 제한하려면 어떻게 해야 합니까?

on: push: paths: [“src/**”, “*.gradle”] 섹션에서 paths 필터를 사용합니다. 지정된 디렉토리에 변경 사항이 있을 때만 워크플로가 실행됩니다. 역필터 paths-ignore는 경로를 제외합니다.

요약

  • GitHub Actions — 모바일 애플리케이션의 빌드, 테스트, 배포를 자동화하는 GitHub의 내장 CI/CD 플랫폼
  • Workflow — 리포지토리의 .github/workflows에 저장된 jobs 및 steps가 포함된 YAML 파일
  • Runner — 작업 실행을 위한 Ubuntu, macOS 또는 Windows 가상 머신
  • Marketplace — 코드 서명, 배포, 테스트 및 알림을 위한 기성 액션 카탈로그
  • Matrix strategy는 다양한 OS 및 도구 버전에서 병렬 빌드 실행
  • 캐싱(actions/cache)은 적절한 구성으로 후속 빌드를 3–4배 가속화
  • iOS 빌드에는 macOS 러너와 apple-actions를 통한 코드 서명 설정 필요

턴키 방식의 모바일 애플리케이션을 개발해 드립니다

IT Sectr는 2017년부터 스타트업과 기업을 위한 iOS 및 Android 애플리케이션을 만듭니다. 저희가 상담해 드리고 최적의 솔루션을 제안하겠습니다.

프로젝트 논의

더 읽어보기