GitHub Actions로 반복 작업 자동화하기: 초보자 가이드
매일 반복되는 빌드, 테스트, 배포 작업에 피로감을 느끼고 계신가요? 개발자라면 한 번쯤 “이 귀찮은 작업을 알아서 해주는 도구는 없을까?” 고민해 보셨을 겁니다. 바로 이때 필요한 도구가 GitHub Actions입니다. 이 글에서는 GitHub Actions 자동화 초보를 위해 핵심 개념부터 첫 워크플로우 작성법까지 알기 쉽게 정리해 드립니다.
GitHub Actions란 무엇인가요?
GitHub Actions는 GitHub 저장소(Repository) 내에서 소프트웨어 개발 워크플로우를 자동화할 수 있도록 지원하는 도구입니다. 코드를 푸시(Push)하거나 풀 리퀘스트(Pull Request)를 보낼 때 자동으로 테스트를 실행하고, 빌드하며, 서버에 배포하는 등의 작업을 수행할 수 있습니다. 별도의 외부 CI/CD 도구를 연동하지 않고 GitHub 환경 내에서 바로 사용할 수 있어 접근성이 매우 높습니다.
GitHub Actions의 핵심 개념 3가지
GitHub Actions를 시작하기 전에 반드시 알아야 할 3가지 핵심 요소가 있습니다.
- 워크플로우 (Workflow): 자동화 프로세스를 정의한 전체 스크립트입니다.
.github/workflows/디렉터리에 YAML(.yml또는.yaml) 파일 형식으로 저장됩니다. - 이벤트 (Event): 워크플로우를 실행시키는 조건(트리거)입니다. 예를 들어
push,pull_request등이 대표적인 이벤트입니다. - 러너 (Runner)와 잡 (Job): 워크플로우가 실행되는 가상 머신 환경(Runner)과 그 안에서 실행되는 세부 단계들의 집합(Job)입니다. GitHub에서 제공하는 기본 가상 서버(Ubuntu, Windows 등)를 사용할 수 있습니다.
초보자를 위한 첫 번째 워크플로우 만들기
직접 워크플로우를 작성해 보면서 개념을 익혀보겠습니다. 저장소 루트에 .github/workflows/hello-world.yml 파일을 만들고 아래 코드를 입력해 보세요.
name: GitHub Actions Beginner Guide
# 언제 실행할지 정의 (main 브랜치에 push가 발생했을 때)
on:
push:
branches: [ "main" ]
# 실행할 작업 정의
jobs:
say-hello:
runs-on: ubuntu-latest
steps:
- name: Checkout repository code
uses: actions/checkout@v4
- name: Run a one-line script
run: echo "Hello, GitHub Actions!"
이 파일은 main 브랜치에 코드가 푸시되면 자동으로 실행됩니다. 가상 머신(Ubuntu)을 실행하고, 코드를 불러온 뒤, 터미널에 “Hello, GitHub Actions!“를 출력하는 아주 간단한 자동화 스크립트입니다. 파일 추가 후 GitHub의 Actions 탭에서 실행 결과를 바로 확인할 수 있습니다.
처음 접할 때 자주 막히는 지점
YAML 문법에 익숙하지 않은 상태로 시작하면 아래 지점에서 흔히 막힙니다.
- 들여쓰기 오류: YAML은 들여쓰기(공백 칸수)로 구조를 구분하는 문법이라, 탭(Tab)과 스페이스(Space)가 섞이거나 칸수가 한 칸만 어긋나도 워크플로우 전체가 실행되지 않을 수 있습니다. 에디터에서 YAML 문법 강조 기능을 켜두면 오류를 미리 발견하기 쉽습니다.
uses와run의 차이를 헷갈리는 것:uses는 다른 사람이 미리 만들어 둔 재사용 가능한 액션(예:actions/checkout@v4)을 가져다 쓰는 것이고,run은 셸 명령어를 직접 실행하는 것입니다. 이 둘의 역할을 구분하지 못하면 존재하지 않는 명령어를uses에 넣는 실수가 잦습니다.- 권한(Permissions) 부족으로 인한 실패: 워크플로우가 저장소에 파일을 커밋하거나 PR을 생성하는 등 쓰기 작업을 시도할 때, 기본 권한으로는 거부되는 경우가 있습니다. 워크플로우 파일 상단에
permissions: contents: write처럼 필요한 권한을 명시해야 합니다. - 로그를 읽지 않고 재시도만 반복하는 것: 실패한 워크플로우는
Actions탭에서 각 스텝별 로그를 펼쳐 보면 정확히 어느 줄에서 실패했는지 나옵니다. 무작정 다시 실행하기보다 로그를 먼저 읽는 습관이 디버깅 시간을 크게 줄여줍니다.
다음 단계로 확장하는 순서
처음부터 복잡한 배포 파이프라인을 만들려고 하면 실패 지점을 찾기 어렵습니다. 아래 순서로 난이도를 점진적으로 높이는 것을 권장합니다.
- echo 출력처럼 부작용이 없는 스크립트로 워크플로우 문법 자체에 익숙해지기
- 코드 검사(Lint)나 테스트 실행처럼 실패해도 시스템에 영향이 없는 작업 자동화하기
- 실제 빌드·배포처럼 실패 시 영향이 있는 작업은, 위 단계들이 안정적으로 동작하는 것을 확인한 뒤 도입하기
GitHub Actions 자동화 초보를 위한 핵심 내용을 정리하면, 워크플로우는 .github/workflows/에 YAML로 작성하고, push나 pull_request 같은 이벤트를 트리거로 실행되며, 실패 시 로그를 확인하는 습관이 가장 중요한 디버깅 기술입니다. 처음에는 간단한 출력(Echo)이나 코드 검사(Linting)로 시작해, 안정적으로 동작하는 것을 확인한 뒤 자동 테스트와 배포 단계로 점진적으로 확장해 나가면 번거로운 반복 작업에서 벗어날 수 있습니다.