2026-08-21

모던 GitHub Actions CI Flow: 프롤로그 CI 개요

Overview

이 글에서는 GitHub Actions를 통해 CI를 진행할 때의 모던한 CI Flow를 설명한다.

Jenkins에서는 보통 Job 또는 Pipeline을 만들고, SCM 변경을 감지한 뒤 Agent에서 빌드와 테스트를 실행한다. GitHub Actions에서는 이 흐름을 저장소 안의 Workflow YAML로 정의하고, 정의된 Workflow는 Event에 의해 Runner 내부에서 실행된다. 본문에서는 Github Actions의 용어와 개념을 설명한다.

GitHub Actions의 핵심 개념

시리즈 구성

본문은 전체 CI Flow를 설명하는 1편이다. 여기서 정리한 흐름을 실제 Workflow YAML로 옮기는 방법은 2편에서 설명한다.

1편 (본문) 모던 GitHub Actions CI Flow
- Event별로 CI를 어떤 식으로 사용하는지 이해한다.
2편 GitHub Actions Workflow 작성하기
- 그 흐름을 Workflow YAML로 어떻게 작성하는지 이해한다.

사전지식

GitHub Actions 용어

용어	의미
Workflow	하나의 자동화 흐름을 정의한 YAML 파일
Event	Workflow를 실행시키는 트리거 (저장소 활동 or 수동·예약 요청)
Job	같은 Runner에서 실행되는 Step들의 묶음
Runner	Job을 실행하는 실행 환경
Step	셸 명령을 실행하거나 Action을 호출하는 작업 단위
Action	Workflow에서 재사용할 수 있는 자동화 단위

Workflow는 저장소의 .github/workflows 디렉터리에 위치한다. 하나의 Workflow에는 하나 이상의 Job이 있고, Job은 여러 Step을 순서대로 실행한다. GitHub Workflows 문서

Jenkins 개념과 비교

Jenkins	GitHub Actions	차이점
Job 또는 Pipeline	Workflow	GitHub Actions Workflow는 저장소에 YAML 관리
Trigger 또는 SCM Polling/Webhook	Event	`on` 키에 실행 조건 선언
Agent	Runner	GitHub 호스팅 Runner 또는 자체 호스팅 Runner를 선택
Stage	Job 또는 Step	병렬 실행과 의존 관계를 Job 단위로 표현할 수 있다.

이 표는 이해를 위한 비교이며, 두 시스템의 설정 단위가 완전히 같은 것은 아니다.

CI Flow

이벤트별 CI 방식을 설명한다.

PR Flow

예를 들어 feature 브랜치에서 develop 브랜치로 PR을 생성한다고 하자. feature는 변경을 제공하는 source 또는 head branch이고, develop은 변경을 반영하는 target 또는 base branch다.

PR CI는 GitHub가 source와 target을 Merge한 테스트 결과를 Runner에서 검증하는 흐름이다. 충돌이 없는 경우 GitHub는 테스트용 Merge ref를 제공하고, Runner는 이를 기준으로 Build와 Test를 실행한다. 실제 target 브랜치는 이 과정에서 변경되지 않는다. Pull Request Event 문서

sequenceDiagram
    participant C as Client
    participant G as GitHub
    participant R as Runner

    Note over C,R: PR Event
    C->>G: commit push 및 Pull Request 생성 또는 갱신
    G->>R: Workflow 실행
    R<<->>G: fetch merge ref
    R->>R: Build, Unit Test, Integration Test
    R-->>G: CI 결과 전달

    alt CI 실패
        C->>C: 코드 수정
        C->>G: 새 commit push
        Note over G,R: synchronize Event로 CI 재실행
    else CI 성공
        C->>G: Review 및 Merge
    end

특징

Build, Test, Lint, 분석을 주로 수행
CI 실패 시 Re-run failed jobs로 재실행하거나 코드를 수정해 새 commit을 Push한다. 새 commit에는 synchronize가 발생한다.

Draft PR 의미

PR 상태 중 1을 의미

Draft PR은 아직 정식 Review와 Merge 준비가 끝난 변경임을 표시하는 상태다. Draft는 Merge할 수 없고, Code Owners에 대한 자동 Review 요청도 발생하지 않는다. 준비가 끝나면 Ready for review로 전환한다. Pull Request 상태 변경

PR 상태전이

stateDiagram-v2
    state "Draft" as PR_DRAFT
    state "Ready" as PR_READY
    state "Merged" as PR_MERGED
    state "Closed" as PR_CLOSED

    [*] --> PR_DRAFT: 초안 생성

    PR_DRAFT --> PR_READY: 리뷰 요청
    PR_READY --> PR_DRAFT: 초안 전환

    PR_DRAFT --> PR_CLOSED: 병합 없이 종료
    PR_READY --> PR_CLOSED: 병합 없이 종료
    PR_READY --> PR_MERGED: 병합

    PR_CLOSED --> PR_DRAFT: 초안으로 재개
    PR_CLOSED --> PR_READY: 리뷰 상태로 재개

    PR_MERGED --> [*]

Push Flow

PR을 통해 source의 내용이 target에 병합되면 push 이벤트를 통해 CI를 발동시킬 수 있다. 대개 대상은 develop이며, feature 내용이 PR승인되었을때 개발계에 자동배포를 위한 용도로 사용된다.

sequenceDiagram
    participant C as Client
    participant G as GitHub
    participant R as Runner

    Note over C,R: Push Event
    G->>R: 기본 브랜치 반영 후 Workflow 실행
    R<<->>G: fetch develop
    R->>R: Build 및 Test 실행
    R->>R: Artifact 또는 Image 생성
    R->>G: Artifact 또는 Image Push
    R-->>G: CI 결과 전달

특징

Build 후 개발계 자동배포 (Production X)

Workflow Dispatch Flow

workflow_dispatch는 GitHub UI나 API를 통해 사용자가 Workflow를 수동으로 트리거하는 Event다.

sequenceDiagram
    participant C as Client
    participant G as GitHub
    participant R as Runner

    Note over C,R: workflow_dispatch Event
    C->>G: Workflow와 입력값, 대상 Ref 선택
    G->>R: Workflow 실행
    R<<->>G: fetch 대상 Ref
    R->>R: 수동 작업 실행
    R-->>G: 실행 결과 전달
    G-->>C: 결과 표시

특징

특정 릴리즈를 생성하거나 Production을 수동으로 배포하거나, 실패한 운영 작업을 재처리하는 데 사용한다.

CI Flow를 Workflow YAML로 작성하는 방법은 GitHub Actions Workflow 작성하기에서 다룬다.

Conclusion

모던한 GitHub Actions CI Flow는 Pull Request 변경을 Event로 받아 Runner에서 일관된 환경을 준비하고, Build와 Test를 실행한 뒤 Check 결과를 Review와 Merge 판단에 제공한다.