[DevOps] GitHub Actions 첫걸음 — 푸시하면 자동으로 테스트 돌리기

지난 글에서 CI/CD가 뭔지 개념을 잡았다. "코드를 푸시하면 자동으로 테스트하고 배포한다"는 그거다. 오늘은 말로만 듣던 그걸 직접 만들어본다. 도구는 입문에 제일 만만한 GitHub Actions다.

목표는 소박하다. 코드를 push하면, GitHub이 알아서 테스트를 돌려주는 것. 이 첫 경험만 해보면 CI가 확 와닿는다.

---

GitHub Actions는 왜 쉬운가

GitHub Actions의 가장 큰 장점은 GitHub에 이미 내장돼 있다는 거다. 별도 서버도, 설치도, 회원가입도 필요 없다. 내 저장소 안 특정 위치에 설정 파일(YAML) 하나만 넣으면, GitHub이 그걸 읽고 자동으로 실행해준다.

그 위치가 정해져 있다. 저장소 루트에 이렇게 만든다.

내-저장소/
└── .github/
    └── workflows/
        └── ci.yml     ← 여기에 워크플로우를 적는다

.github/workflows/ 폴더 안에 있는 YAML 파일을 GitHub이 워크플로우로 인식한다. 파일 이름(ci.yml)은 자유다.

---

핵심 용어 3개만 알고 가자

YAML을 보기 전에 단어 세 개만 짚자. 이것만 알면 설정 파일이 술술 읽힌다.

• Workflow(워크플로우): 자동화 작업 전체. YAML 파일 하나가 워크플로우 하나다.
• Job(잡): 워크플로우 안의 작업 단위. "테스트하기", "배포하기" 같은 덩어리.
• Step(스텝): Job 안의 세부 단계. "코드 받기", "의존성 설치", "테스트 실행" 각각이 스텝이다.

관계는 이렇다. Workflow(전체) > Job(작업) > Step(단계).

---

첫 워크플로우 만들기

Node.js 프로젝트라고 하자. .github/workflows/ci.yml을 이렇게 작성한다.

name: CI

# 언제 실행할지
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

# 무엇을 할지
jobs:
  test:
    runs-on: ubuntu-latest      # 어떤 환경에서 돌릴지

    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4

      - name: Node 설치
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: 의존성 설치
        run: npm install

      - name: 테스트 실행
        run: npm test

이 파일을 push하는 순간부터, GitHub은 main에 push되거나 PR이 올라올 때마다 이 워크플로우를 자동으로 돌린다. 하나씩 뜯어보자.

---

한 줄씩 뜯어보기

on: — 언제 이 워크플로우를 실행할지 정하는 트리거다. 여기서는 main 브랜치에 push되거나, main으로 향하는 PR이 열릴 때 실행된다. 이게 "코드를 올릴 때마다 자동으로"를 만드는 부분이다.

jobs: — 실제로 할 작업들이다. 여기선 test라는 잡 하나다.

runs-on: ubuntu-latest — 이 작업을 어떤 컴퓨터에서 돌릴지다. GitHub이 우분투 가상 머신을 새로 하나 띄워서 거기서 실행해준다. 매번 깨끗한 환경이라 "내 컴퓨터에선 됐는데" 문제가 없다.

steps: — 실제 단계들이다. 위에서 아래로 순서대로 실행된다.

• uses: actions/checkout@v4 — 내 저장소 코드를 가상 머신으로 받아온다. 코드가 있어야 테스트를 하니 거의 항상 첫 스텝이다. uses는 남이 만든 액션을 가져다 쓰는 거다.
• uses: actions/setup-node@v4 — 그 환경에 Node 20을 설치한다.
• run: npm install — 여기서부터 run은 직접 명령어를 실행하는 거다. 터미널에 치듯이 의존성을 설치한다.
• run: npm test — 테스트를 돌린다. 여기서 하나라도 실패하면 워크플로우 전체가 실패로 표시된다.

정리하면 uses는 "가져다 쓰기", run은 "직접 명령 실행"이다.

---

결과는 어디서 보나

이 파일을 push하고 GitHub 저장소의 Actions 탭에 들어가면, 방금 돌아간(또는 돌고 있는) 워크플로우가 보인다. 초록 체크면 성공, 빨간 X면 실패다. 클릭하면 어느 스텝에서 왜 실패했는지 로그까지 다 볼 수 있다.

그리고 PR을 올리면, PR 화면 안에서 바로 "검사 통과/실패"가 표시된다. 팀원이 리뷰할 때 "얘 테스트는 통과했네" 하고 바로 확인할 수 있는 거다. 여기에 설정을 더하면 "테스트 통과 안 하면 merge 못 하게" 막을 수도 있다.

---

자주 쓰는 트리거 몇 개

on:에 뭘 넣느냐로 "언제 돌릴지"가 바뀐다. 자주 쓰는 것들이다.

설정	언제 실행
push	코드가 push될 때
pull_request	PR이 열리거나 업데이트될 때
schedule	정해진 시각마다 (cron)
workflow_dispatch	버튼으로 수동 실행

workflow_dispatch를 넣어두면 Actions 탭에서 손으로 "실행" 버튼을 눌러 돌려볼 수도 있어서, 테스트할 때 편하다.

---

정리

• GitHub Actions는 .github/workflows/ 안에 YAML 파일을 넣으면 바로 동작한다. 설치 필요 없다.
• 구조는 Workflow > Job > Step이다.
• on:으로 언제 돌릴지(push, PR 등)를 정한다.
• 스텝에서 uses는 남이 만든 액션 가져다 쓰기, run은 직접 명령 실행이다.
• 결과는 Actions 탭이나 PR 화면에서 초록/빨강으로 확인한다.

이제 코드를 push하면 자동으로 테스트가 돌아가는 CI를 손에 넣었다. 이것만 해도 "테스트 깜빡하고 배포하는" 실수가 사라진다. 다음 글에서는 여기서 한 발 더 나아가서, 테스트를 통과하면 Docker 이미지를 빌드하고 실제 서버에 배포까지 자동으로 이어지는 CD 파이프라인을 만들어보자. 앞에서 배운 Docker가 여기서 다시 등장한다.