깃허브 액션

워크플로우는 깃허브 액션에서 자동화 작업을 정의하는 가장 상위의 구성 단위이다. 각 워크플로우는 저장소의 .github/workflows 디렉토리 내에 별도의 YAML 파일로 작성된다. 하나의 저장소에는 여러 개의 워크플로우 파일을 배치할 수 있으며, 각 파일은 서로 다른 자동화 작업을 독립적으로 관리한다.

워크플로우 파일은 실행을 트리거할 이벤트, 실행 환경을 구성하는 러너, 그리고 실제 작업 단위인 잡과 스텝을 정의한다. 예를 들어, 코드가 메인 브랜치에 푸시될 때마다 테스트와 빌드를 수행하거나, 매일 정해진 시간에 데이터베이스를 백업하는 정기 작업을 설정할 수 있다. 이렇게 워크플로우를 통해 CI/CD 파이프라인을 구축하거나 다양한 유지보수 작업을 자동화한다.

워크플로우의 실행은 정의된 이벤트에 의해 자동으로 시작되지만, workflow_dispatch 이벤트를 설정하면 깃허브의 웹 인터페이스나 API를 통해 수동으로 실행을 시작할 수도 있다. 이는 특정 조건에서만 테스트하거나 긴급 배포를 진행할 때 유용하다. 모든 실행 기록과 결과는 저장소의 'Actions' 탭에서 확인할 수 있으며, 각 워크플로우 실행은 고유한 로그와 상태를 제공한다.

깃허브 액션에서 잡은 하나의 워크플로우를 구성하는 핵심 실행 단위이다. 하나의 워크플로우는 하나 이상의 잡으로 구성되며, 각 잡은 기본적으로 독립적인 가상 머신 또는 컨테이너 환경인 러너 위에서 실행된다. 이는 각 잡이 서로 격리된 환경에서 병렬로 실행될 수 있음을 의미하며, 매트릭스 전략을 사용하면 단일 잡 정의를 기반으로 여러 아키텍처나 운영체제에 대한 빌드와 테스트를 동시에 수행할 수 있다.

각 잡은 순차적으로 실행되는 여러 스텝으로 나뉜다. 스텝은 셸 명령어를 실행하거나, 재사용 가능한 코드 모듈인 액션을 호출하는 등의 작업을 수행하는 최소 실행 단위이다. 잡 내의 스텝들은 동일한 러너 환경을 공유하기 때문에, 한 스텝에서 생성된 파일이나 설정된 환경 변수를 후속 스텝에서 사용할 수 있다. 예를 들어, 첫 번째 스텝에서 코드를 빌드하고, 두 번째 스텝에서 빌드 결과물로 테스트를 실행한 뒤, 마지막 스텝에서 배포를 진행하는 흐름을 구성할 수 있다.

잡 간의 관계는 needs 키워드를 통해 정의할 수 있다. 이를 통해 특정 잡의 실행이 다른 잡의 성공적인 완료에 의존하도록 설정할 수 있어, 복잡한 CI/CD 파이프라인의 순서를 제어하는 데 유용하다. 모든 잡과 스텝의 실행 로그는 깃허브 인터페이스에서 실시간으로 확인할 수 있으며, 이를 통해 디버깅과 모니터링이 용이하다.

러너는 깃허브 액션 워크플로우의 잡이 실행되는 가상 머신 또는 물리적 환경이다. 각 잡은 하나의 러너 위에서 순차적으로 실행되며, 러너는 워크플로우 정의 파일에서 지정할 수 있다. 깃허브는 Ubuntu, Windows, macOS 운영체제를 탑재한 호스팅된 러너를 기본적으로 제공하며, 사용자가 직접 관리하는 셀프 호스팅 러너를 구성하여 특정 하드웨어나 소프트웨어가 필요한 환경에서도 워크플로우를 실행할 수 있다.

러너의 환경은 워크플로우 파일 내 runs-on 키워드로 정의된다. 이를 통해 특정 운영체제나 러너 레이블을 지정할 수 있다. 예를 들어, 크로스 컴파일이 필요한 경우, 서로 다른 CPU 아키텍처(예: x86과 ARM)를 가진 러너를 정의하고, 각 잡을 알맞은 러너에 배치하여 병렬로 빌드 작업을 수행할 수 있다.

셀프 호스팅 러너는 사용자의 인프라에 설치하여 운영한다. 이를 통해 데이터 프라이버시 요구사항을 충족하거나, 특정 의존성 라이브러리가 설치된 환경, 또는 GPU와 같은 특수 하드웨어가 필요한 머신러닝 학습 작업 등을 실행하는 데 유용하다. 호스팅된 러너는 관리 부담이 없지만, 셀프 호스팅 러너는 사용자가 러너 머신의 유지보수와 보안을 직접 책임져야 한다.

깃허브 액션에서 잡을 구성하는 기본 실행 단위이다. 하나의 잡은 여러 개의 스텝으로 나뉘며, 각 스텝은 셸 스크립트를 실행하거나 미리 정의된 액션을 재사용하는 등 개별적인 작업을 수행한다. 스텝은 잡 내에서 정의된 순서대로 반드시 순차적으로 실행되며, 같은 러너 환경을 공유한다. 이는 이전 스텝에서 생성된 파일이나 설정된 환경 변수를 후속 스텝에서 바로 사용할 수 있음을 의미한다.

스텝을 정의하는 주요 방법은 두 가지이다. 하나는 run: 키워드를 사용해 직접 셸 명령어나 스크립트를 실행하는 것이고, 다른 하나는 uses: 키워드를 사용해 깃허브 마켓플레이스에 공개된 재사용 가능한 액션 또는 동일 저장소의 액션을 호출하는 것이다. 예를 들어, 코드를 체크아웃하는 actions/checkout 액션을 사용하거나, Node.js 환경을 설정하는 actions/setup-node 액션을 사용하는 것이 일반적이다.

스텝 간에는 데이터를 주고받을 수 있다. uses:로 호출한 액션에는 with: 키워드를 통해 입력 매개변수를 전달할 수 있다. 또한, 액션의 출력 결과는 steps.<step_id>.outputs.<key> 형태의 표현식을 통해 다른 스텝에서 참조하거나 워크플로우의 조건문에서 사용할 수 있다. 이러한 설계 덕분에 빌드, 테스트, 배포와 같은 연속적인 작업 흐름을 명시적인 종속성 정의 없이도 자연스럽게 구성할 수 있다.

모든 스텝의 실행이 완료되면 해당 잡은 종료된다. 만약 중간 스텝에서 실패가 발생하면, 기본적으로 해당 잡의 후속 스텝 실행이 중단되고 잡 전체가 실패한 상태로 처리된다. 필요에 따라 continue-on-error와 같은 옵션을 설정하여 특정 스텝의 실패가 잡 전체의 실패로 이어지지 않도록 제어할 수도 있다.

액션은 깃허브 액션에서 재사용 가능한 자동화 작업의 기본 구성 요소이다. 자주 사용되는 특정 작업(예: 코드 체크아웃, Docker 이미지 빌드, npm 패키지 배포 등)을 미리 정의하고 패키징한 것으로, 워크플로우 내의 스텝에서 uses: 문법을 통해 쉽게 불러와 실행할 수 있다. 이를 통해 사용자는 반복적인 작업을 직접 스크립트로 작성할 필요 없이, 검증된 액션을 조합하여 빠르고 안정적인 자동화 파이프라인을 구축할 수 있다.

액션은 크게 세 가지 유형으로 나뉜다. 첫째는 JavaScript 액션으로, Node.js 런타임에서 실행되며 깃허브의 공식 actions/toolkit 라이브러리를 활용해 API와 상호작용하는 데 주로 사용된다. 둘째는 Docker 컨테이너 액션으로, 특정 런타임 환경이나 도구가 필요한 작업을 격리된 상태에서 실행할 때 적합하다. 셋째는 복합 액션으로, 하나의 액션 정의 파일 내에서 여러 런 명령어와 액션을 조합하여 더 복잡한 작업을 정의할 수 있다.

액션은 YAML 형식의 메타데이터 파일(action.yml 또는 action.yaml)을 통해 정의되며, 여기서 이름, 설명, 입력 매개변수, 출력값, 실행 방식을 명시한다. 워크플로우의 스텝에서는 with: 키워드를 사용해 이러한 입력값을 전달하고, 실행 결과는 steps.<step_id>.outputs 형태로 후속 스텝에서 참조할 수 있다. 이렇게 표준화된 인터페이스를 제공함으로써 액션 간의 데이터 흐름과 연계 실행이 용이해진다.

수많은 커뮤니티 및 기업이 개발한 액션은 깃허브 마켓플레이스에서 공개되어 있으며, 코드 체크아웃(actions/checkout), 캐싱(actions/cache), Docker 빌드(docker/build-push-action) 등 다양한 분야에서 폭넓게 활용된다. 사용자는 이러한 공개 액션을 활용하거나, 조직 내부의 특정 요구사항에 맞춰 자체 액션을 개발하여 비공개 저장소에 배포하고 재사용할 수 있다.

푸시 이벤트는 깃허브 액션에서 가장 일반적으로 사용되는 트리거이다. 저장소에 커밋이 푸시될 때 자동으로 워크플로우를 실행하도록 설정할 수 있다. 이는 지속적 통합 파이프라인의 핵심 요소로, 개발자가 코드를 리모트 리포지토리에 푸시할 때마다 자동으로 빌드와 테스트를 수행하여 품질을 보장한다.

워크플로우의 on 키워드 아래에 push:를 명시하여 푸시 이벤트를 리스닝할 수 있다. 특정 브랜치나 태그에 대한 푸시만 감지하도록 필터를 적용하는 것이 일반적이다. 예를 들어, main 브랜치에 대한 푸시나 v* 패턴의 시맨틱 버저닝 태그가 푸시될 때만 작업이 실행되도록 구성할 수 있다. 이를 통해 개발 브랜치의 통합 테스트와 프로덕션 배포를 위한 릴리스 빌드를 구분하여 관리할 수 있다.

푸시 이벤트를 통해 실행된 워크플로우는 기본적으로 해당 푸시의 커밋 해시와 브랜치 정보를 컨텍스트로 가져간다. actions/checkout 액션을 사용하면 러너에 해당 시점의 저장소 코드를 체크아웃하여 실제 코드베이스에 대한 작업을 수행할 수 있다. 이는 단위 테스트 실행, 정적 분석 도구 수행, 도커 이미지 빌드 등 다양한 자동화 작업의 기초가 된다.

깃허브 액션의 워크플로우는 저장소에서 발생하는 다양한 이벤트에 의해 자동으로 트리거될 수 있다. 그중 스케줄 이벤트는 크론 표현식을 사용하여 특정 시간이나 주기적으로 워크플로우를 실행하도록 설정하는 기능이다. 이는 푸시 이벤트나 풀 리퀘스트와 같은 코드 변경 관련 이벤트와 달리, 시간 기반으로 자동화된 작업을 수행해야 할 때 유용하게 활용된다.

워크플로우의 YAML 파일에서 on: 키 아래 schedule:을 정의하여 사용한다. 크론 표현식은 UTC 시간 기준으로 실행 시각을 지정하며, 분, 시, 일, 월, 요일의 다섯 필드로 구성된다. 예를 들어, 매일 UTC 시간으로 자정(0시 0분)에 실행하려면 cron: '0 0 * * *'과 같이 설정한다. 이를 통해 정기적인 빌드 테스트, 데이터 백업, 정적 사이트 재생성, 의존성 업데이트 확인 등의 반복 작업을 자동화할 수 있다.

스케줄 이벤트는 깃허브가 관리하는 러너에서 실행되며, 다른 이벤트와 마찬가지로 워크플로우 내에서 정의된 잡과 스텝을 순차적으로 수행한다. 다만, 예정된 실행 시간에 깃허브의 러너 가용성에 따라 실제 실행이 약간 지연될 수 있다는 점은 고려해야 한다. 또한, 퍼블릭 리포지토리와 프라이빗 리포지토리 모두에서 사용 가능하지만, 프라이빗 리포지토리의 경우 깃허브 요금제에 따른 월간 무료 실행 시간 제한이 적용된다.

이 기능은 CI/CD 파이프라인에서 야간 통합 테스트를 실행하거나, 주간 리포트를 생성하는 등 개발 주기와 직접적으로 연관되지 않은 정기 배치 작업을 설정하는 데 적합하다. workflow_dispatch 이벤트와 결합하여 수동 실행 옵션도 함께 제공하는 경우가 많다.

워크플로우를 자동 이벤트가 아닌 사용자가 직접 시작할 수 있도록 하는 기능이다. 이를 위해서는 워크플로우 정의 파일(.yml)의 on 섹션에 workflow_dispatch 이벤트를 추가해야 한다. 이렇게 설정하면 GitHub 저장소의 액션 탭에서 해당 워크플로우를 선택하고 'Run workflow' 버튼을 눌러 수동 실행할 수 있는 인터페이스가 제공된다.

수동 실행 시 사용자는 입력 매개변수를 제공할 수 있다. 워크플로우 파일에서 inputs을 정의해 미리 텍스트, 선택 옵션, 불리언 값 등을 설정하면, 실행 버튼을 누르기 전에 해당 값을 입력하거나 선택하는 필드가 웹 인터페이스에 나타난다. 이렇게 전달된 값은 워크플로우 내 잡과 스텝에서 ${{ github.event.inputs.이름 }} 형태로 참조하여 활용할 수 있다.

이 기능은 CI/CD 파이프라인의 특정 단계를 수동으로 트리거하거나, 배포 작업을 승인 후 실행하는 등 자동화된 흐름에 유연성을 더하는 데 유용하다. 또한 정기 작업을 위한 크론 스케줄 이벤트와 함께 사용되어, 예정된 시간 외에 필요 시 즉시 작업을 수행하는 용도로도 자주 쓰인다.

깃허브 액션의 가장 대표적인 활용 사례는 CI/CD 파이프라인을 구축하는 것이다. 소프트웨어 개발에서 코드 변경 사항을 지속적으로 통합(CI)하고, 검증된 결과물을 자동으로 배포(CD)하는 과정을 자동화하는 데 적합하다. 저장소에 코드가 푸시되거나 풀 리퀘스트가 생성되는 등의 이벤트를 트리거로 설정하여, 빌드, 테스트, 배포 작업을 자동으로 실행할 수 있다.

이를 위해 사용자는 저장소의 .github/workflows 디렉토리에 YAML 형식의 워크플로우 파일을 작성한다. 일반적인 CI/CD 워크플로우는 actions/checkout 액션으로 코드를 체크아웃한 후, 특정 프로그래밍 언어 환경(예: Node.js, Python, Java)을 설정하고, 의존성을 설치한 뒤, 테스트 스크립트를 실행하는 스텝으로 구성된다. 모든 잡이 성공적으로 완료되면, 배포를 담당하는 다음 잡이 실행되어 결과물을 스테이징 서버나 프로덕션 환경, 혹은 패키지 레지스트리에 자동으로 퍼블리시할 수 있다.

깃허브 액션은 깃허브 생태계와의 긴밀한 통합 덕분에 CI/CD를 간편하게 구성할 수 있다. 깃허브 마켓플레이스에는 수많은 커뮤니티 및 공식 액션이 등록되어 있어, 도커 이미지 빌드, 클라우드 서비스(AWS, 구글 클라우드, 애저) 배포, 슬랙 알림 전송 등 복잡한 작업도 미리 만들어진 액션을 조합하여 쉽게 구현할 수 있다. 또한, 워크플로우 실행 내역과 로그가 깃허브 인터페이스 상에 통합되어 있어 모니터링과 디버깅이 용이하다.

깃허브 액션은 크로스 컴파일 작업을 자동화하는 데 매우 효과적인 도구이다. 크로스 컴파일은 특정 CPU 아키텍처나 운영 체제를 대상으로 소프트웨어를 빌드하는 과정을 의미하며, 깃허브 액션의 매트릭스 기능을 활용하면 단일 워크플로우 정의로 여러 다른 환경에 대한 빌드를 병렬로 실행할 수 있다. 이를 통해 개발자는 리눅스, 윈도우, macOS와 같은 다양한 운영 체제와 x86, ARM 같은 서로 다른 아키텍처에 대한 바이너리를 한 번에 생성할 수 있다.

구체적으로, 워크플로우 YAML 파일 내 strategy.matrix 구문을 사용하여 빌드할 대상 운영 체제와 아키텍처의 조합을 정의한다. 이렇게 설정하면 깃허브 액션이 각 조합에 대해 별도의 잡을 생성하고, 각 잡은 지정된 환경(러너)에서 실행된다. 예를 들어, 하나의 소스 코드 저장소에서 리눅스용 x86_64 바이너리, macOS용 ARM64 바이너리, 윈도우용 바이너리를 동시에 빌드하는 것이 가능해진다.

이러한 자동화는 특히 오픈 소스 프로젝트나 다중 플랫폼을 지원하는 라이브러리 및 애플리케이션 개발에 유용하다. 개발자는 코드를 푸시하거나 풀 리퀘스트를 생성할 때마다, 사전에 정의된 모든 대상 플랫폼에 대해 빌드가 자동으로 수행되고 테스트될 수 있도록 설정할 수 있다. 결과적으로 지속적 통합 파이프라인의 일부로 크로스 플랫폼 호환성을 지속적으로 검증하고, 최종 릴리즈 시 사용자에게 다양한 플랫폼용 패키지를 손쉽게 제공할 수 있게 한다.

정기 작업은 깃허브 액션의 워크플로우가 특정 시간이나 일정에 따라 자동으로 실행되도록 설정하는 기능이다. 이를 통해 매일, 매주 또는 특정 간격으로 반복되어야 하는 업무를 자동화할 수 있다. 대표적인 활용 예로는 정기적인 데이터 백업, 주기적인 종속성 업데이트 확인, 정기 보고서 생성, 또는 일정 시간마다 시스템 상태를 점검하는 모니터링 작업 등이 있다.

이러한 정기 작업은 워크플로우 정의 파일에서 on: schedule: 구문을 사용하여 설정한다. 실행 시점은 크론 표현식으로 지정하며, 이는 유닉스 계열 시스템의 작업 스케줄러인 크론과 동일한 문법을 사용한다. 예를 들어, 매일 한국 시간으로 오전 6시에 작업을 실행하려면 cron: '0 21 * * *'과 같이 설정할 수 있다. 이 표현식은 UTC 기준으로 동작하므로 지역 시간대에 맞춰 계산해야 한다.

정기 작업은 CI/CD 파이프라인의 일부가 아니더라도 개발 및 운영 프로세스를 지원하는 데 유용하게 쓰인다. 예를 들어, 저장소의 보안 취약점을 정기적으로 스캔하거나, 사용량 통계를 수집하거나, 외부 API에서 데이터를 주기적으로 가져와 갱신하는 등의 작업에 적용할 수 있다. 이는 개발자가 직접 실행을 기억하거나 트리거할 필요 없이, 시스템이 일관적으로 유지보수 작업을 수행하도록 보장한다.