정정지용
기술스택 목록
DevOps

GitHub Actions

프로젝트 6개에서 사용했습니다. 각 프로젝트에서 어떤 역할로 썼는지 아래에 정리했습니다.

이 기술은 무엇인가요?

코드 저장소 이벤트에 반응해 빌드·테스트·배포를 자동화하는 CI/CD 플랫폼

GitHub Actions는 GitHub 저장소에서 발생하는 push, pull request, 스케줄 등의 이벤트에 맞춰 정해진 작업을 자동으로 실행해 주는 CI/CD 도구다. 저장소마다 별도의 CI 서버를 구축하지 않고도, 저장소 안에 워크플로 파일만 두면 GitHub이 제공하는 실행 환경에서 테스트·빌드·배포 같은 반복 작업을 자동화할 수 있도록 만들어졌다. YAML로 파이프라인을 선언하고, 커뮤니티가 만든 재사용 가능한 단위(Action)를 조합해 쓸 수 있다는 점이 특징이다.

이럴 때 사용합니다

  • GitHub 저장소와 통합된 CI/CD를 별도 서버 구축 없이 바로 쓰고 싶을 때
  • 커밋·PR마다 린트, 테스트, 유효성 검증을 자동으로 반복 실행하고 싶을 때
  • 여러 프로젝트에 걸쳐 동일한 검증 규칙(포맷팅, 스키마 검증 등)을 표준화하고 싶을 때
  • 특정 도구 버전이 필요한 작업을 Docker 컨테이너 기반 실행 환경으로 고정하고 싶을 때

핵심 개념

Workflow
저장소의 .github/workflows 디렉터리에 YAML 파일로 정의하는 자동화 파이프라인 전체 단위다.
Event / Trigger
push, pull_request, schedule 등 워크플로를 실행시키는 계기가 되는 이벤트다.
Job
워크플로 안에서 하나의 실행 환경(runner)에서 수행되는 작업 단위이며, 여러 job은 기본적으로 병렬 실행된다.
Step / Action
job을 구성하는 개별 실행 단계이며, Action은 커뮤니티나 직접 만든 재사용 가능한 스텝 묶음이다.
Runner
실제로 job이 실행되는 서버(가상 머신 또는 컨테이너)로, GitHub이 호스팅하거나 직접 등록한 self-hosted runner를 쓸 수 있다.
container (job container)
job의 실행 환경을 특정 Docker 이미지로 고정해, 필요한 도구나 버전이 미리 갖춰진 격리된 환경에서 실행하도록 지정하는 설정이다.

PR마다 lint 검사를 실행하는 기본 워크플로

pull_request 이벤트가 발생하면 node:20 컨테이너 안에서 저장소를 체크아웃한 뒤 prettier 포맷 검사를 실행한다.

YAML
name: CI
on:
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    container: node:20
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx prettier --check .

처음 쓸 때 흔한 함정

  • workflow 파일 경로(.github/workflows)와 YAML 들여쓰기 오류로 실행 자체가 안 되는 경우가 많다
  • job은 기본적으로 병렬 실행되므로 순서가 필요하면 needs로 의존관계를 명시해야 한다
  • container 키워드 사용 시 이미지 크기와 다운로드 시간이 늘어나 실행 속도가 느려질 수 있다

위 개요는 기술 학습을 돕기 위해 자동 생성된 일반 설명입니다. 정확한 사양과 최신 정보는 공식 문서를 확인하세요.

프로젝트별 활용 방식

위 개념이 실제 프로젝트에서 어떻게 쓰였는지 보여줍니다.

함께 사용한 기술

위 프로젝트들에서 같이 쓰인 다른 기술입니다.

Docker4Next.js2Node.js2PostgreSQL2React2TypeScript2AlembicAlpine LinuxAWS S3AxiosCloudflare TunnelDocker Compose