GitHub Actions로 워크플로 만들기: 트리거, 잡, 스텝

개념

워크플로 파일의 위치와 형식

GitHub Actions의 워크플로는 저장소의 .github/workflows/ 폴더 안에 YAML 파일로 저장된다. 모듈 8(레슨 6)에서 YAML 형식의 문서 구조를 다뤘던 것처럼, 여기서도 들여쓰기로 구조를 표현하는 같은 형식이 쓰인다.

트리거(Trigger) — 언제 실행되는가

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

이 설정은 "main 브랜치로의 PR이 열리거나, main에 직접 푸시될 때 이 워크플로를 실행하라"는 뜻이다. 모듈 9(레슨 7)에서 배운 PR 개념이 여기서 실제로 워크플로를 촉발하는 조건이 된다.

잡(Job)과 스텝(Step)

워크플로는 하나 이상의 잡으로 구성되고, 각 잡은 순서대로 실행되는 스텝들로 이뤄진다.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4
 
      - name: 의존성 설치
        run: npm install
 
      - name: 단위 테스트 실행
        run: npm run test:unit
 
      - name: API 테스트 실행
        run: npm run test:api

각 스텝은 미리 만들어진 재사용 가능한 동작(uses:, 레슨 1에서 배운 "코드 체크아웃" 같은 흔한 작업)이거나, 직접 실행할 명령어(run:)다. 이 구조는 모듈 1(레슨 1)에서 배운 테스트 절차처럼, 순서대로 하나씩 실행되고 각 단계의 성공 여부가 다음 단계로 이어진다는 점에서 비슷하다.

여러 잡을 병렬로 실행하기

jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps: [...]
 
  api-test:
    runs-on: ubuntu-latest
    steps: [...]

unit-test와 api-test처럼 서로 의존하지 않는 잡은 동시에 병렬로 실행되어, 전체 파이프라인 시간을 줄인다 — 모듈 13(레슨 8)에서 배운 크로스 브라우저 병렬 실행과 같은 원리다.

실패 시 어떻게 되는가

한 스텝이 실패하면(예: npm run test:unit이 실패 종료 코드를 반환하면), 기본적으로 그 잡의 나머지 스텝은 건너뛰고 실패로 표시된다. GitHub은 이 결과를 PR 화면에 체크 표시(✓/✗)로 보여줘, 병합 버튼 자체를 막을 수 있다(레슨 4의 품질 게이트와 연결된다).

워크플로를 읽는 연습이 왜 중요한가

QA가 GitHub Actions 문법을 직접 짤 줄 몰라도, .github/workflows/ 폴더의 YAML 파일을 열어 **"이 파이프라인이 정확히 무엇을, 어떤 순서로, 어떤 조건에서 실행하는지"**를 읽을 수 있으면 큰 도움이 된다. "이 PR이 왜 자동으로 검증이 안 됐지?"라는 의문이 들 때, 트리거 조건을 직접 확인해서 원인을 스스로 파악할 수 있다.

실무에서 왜 필요한가

"CI가 빨간불(실패)인데 왜 그런지 모르겠다"는 상황에서, 워크플로 파일을 열어 어느 스텝에서 실패했는지 직접 확인할 수 있는 QA는 개발자에게 묻지 않고도 1차 진단을 할 수 있다. 또한 새로운 자동화 테스트 스위트를 추가할 때, "이걸 어느 잡에, 어떤 트리거 조건으로 넣어야 할지" 판단하는 데도 이 구조 이해가 필요하다.

실습 과제

과제 1 — 워크플로 읽기 (10분)

다음 YAML을 보고, 이 워크플로가 언제 실행되는지, 몇 개의 스텝으로 구성되는지, 어느 스텝이 실패하면 이후 스텝이 진행 안 되는지 설명한다.

on:
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run lint
      - run: npm run test:unit
      - run: npm run build

과제 2 — 병렬화 설계하기 (10분)

과제 1의 워크플로에서, lint와 test:unit이 서로 의존하지 않는 독립적인 검사라고 하자. 이 둘을 병렬로 실행하도록 잡을 나눈다면 어떻게 구조를 바꿀지 설명한다.

자가 체크리스트

워크플로 파일이 저장되는 위치와 기본 형식(YAML)을 안다
트리거(on), 잡(jobs), 스텝(steps)의 관계를 설명할 수 있다
스텝이 실패했을 때 파이프라인이 어떻게 반응하는지 설명할 수 있다
워크플로 YAML 파일을 읽고 실행 조건과 순서를 파악할 수 있다

흔한 실수

워크플로 문법을 완벽히 암기하려 한다. QA에게 더 중요한 건 직접 짜는 능력보다 이미 있는 워크플로를 읽고 이해하는 능력이다.
모든 스텝을 순서대로만 실행하고 병렬화를 고려하지 않는다. 독립적인 검사는 병렬로 돌려 전체 시간을 단축할 수 있다.
트리거 조건을 확인하지 않고 "왜 CI가 안 돌았지?"라고만 궁금해한다. on: 섹션을 보면 실행 조건을 바로 확인할 수 있다.

참고 자료

GitHub Actions 공식 문서 — Workflow syntax — 워크플로 YAML 문법의 공식 레퍼런스
GitHub Actions 공식 문서 — Triggering a workflow — 트리거 조건의 공식 가이드