GitHub Actions CI/CD 자동화
GitHub Actions를 활용해 CI/CD 파이프라인을 구축하고 자동화 배포를 구현합니다. 워크플로우 문법, 액션 활용, 실전 배포 시나리오까지 모든 것을 다룹니다.
학습 항목
본 콘텐츠의 이미지 및 내용은 AI로 생성되었습니다.
이미지 로딩 중...
GitHub Actions 소개와 CI/CD 개념 완벽 가이드
GitHub Actions를 처음 접하는 초급 개발자를 위한 CI/CD 입문서입니다. 복잡해 보이는 자동화 파이프라인의 개념부터 실제 워크플로우 작성까지, 마치 소설을 읽듯 쉽게 이해할 수 있도록 구성했습니다.
목차
1. CI/CD란 무엇인가
김개발 씨는 입사 첫 날, 선배에게 충격적인 이야기를 들었습니다. "여기서는 코드 푸시하면 알아서 테스트되고, 알아서 배포돼요." 마법 같은 이야기에 김개발 씨는 고개를 갸웃거렸습니다.
도대체 어떻게 그런 일이 가능한 걸까요?
CI/CD는 Continuous Integration(지속적 통합)과 Continuous Delivery/Deployment(지속적 전달/배포)의 약자입니다. 쉽게 말해 코드를 작성하고 병합하고 배포하는 모든 과정을 자동화하는 것입니다.
마치 공장의 컨베이어 벨트처럼, 한 번 설정해두면 반복 작업을 기계가 대신 처리해줍니다.
다음 코드를 살펴봅시다.
# CI/CD 파이프라인의 기본 흐름 (의사 코드)
# 1단계: 개발자가 코드를 푸시합니다
git push origin feature/login
# 2단계: CI가 자동으로 시작됩니다
# - 코드 빌드
# - 테스트 실행
# - 코드 품질 검사
# 3단계: 모든 검사 통과 시 CD가 실행됩니다
# - 스테이징 환경에 배포
# - 프로덕션 환경에 배포
# 이 모든 과정이 자동으로 진행됩니다
김개발 씨는 이전 회사에서 배포할 때마다 진땀을 뺐습니다. 새벽 2시, 사용자가 적은 시간대에 서버에 접속해서 수동으로 파일을 올리고, 테스트하고, 문제가 생기면 롤백하고.
한 번 배포하는 데 두세 시간은 기본이었습니다. 그런데 새 회사에서는 분위기가 완전히 달랐습니다.
코드를 푸시하면 몇 분 뒤에 "배포 완료" 알림이 오고, 그게 끝이었습니다. 마치 마법 같았습니다.
박시니어 씨가 설명을 시작했습니다. "이게 바로 CI/CD예요.
우리가 반복적으로 하던 일들을 컴퓨터가 대신 해주는 거죠." CI, 즉 지속적 통합이란 무엇일까요? 비유하자면 여러 요리사가 함께 요리할 때, 각자 만든 소스를 큰 냄비에 계속 합치면서 맛을 보는 것과 같습니다.
혼자 너무 오래 따로 요리하면 나중에 합쳤을 때 맛이 이상해질 수 있으니까요. 개발에서도 마찬가지입니다.
여러 개발자가 작업한 코드를 자주 합치고, 합칠 때마다 자동으로 테스트해서 문제가 없는지 확인합니다. CD는 두 가지 의미를 가집니다.
Continuous Delivery는 배포 준비까지 자동화하는 것이고, Continuous Deployment는 실제 배포까지 완전 자동화하는 것입니다. 전자는 최종 배포 버튼만 사람이 누르고, 후자는 그마저도 자동입니다.
CI/CD가 없던 시절에는 어떤 일이 벌어졌을까요? 개발자들은 일주일, 길게는 한 달 동안 각자 작업한 뒤에야 코드를 합쳤습니다.
그러면 충돌이 수십 개씩 발생했고, 이를 해결하느라 또 며칠이 걸렸습니다. 배포는 더 끔찍했습니다.
테스트를 수동으로 돌리고, 서버에 파일을 직접 올리고, 문제가 생기면 야근은 기본이었습니다. CI/CD를 도입하면 이 모든 고통에서 해방됩니다.
코드를 푸시하는 순간 자동으로 빌드가 되고, 테스트가 돌아가고, 문제가 있으면 즉시 알림이 옵니다. 배포도 버튼 하나, 혹은 완전 자동으로 이루어집니다.
가장 큰 장점은 빠른 피드백입니다. 내가 작성한 코드에 문제가 있으면 몇 분 안에 알 수 있습니다.
일주일 뒤에 "저번 주에 넣은 코드가 문제예요"라는 말을 듣는 것보다 훨씬 낫습니다. 또한 일관성이 보장됩니다.
사람이 수동으로 하면 실수할 수 있지만, 자동화된 파이프라인은 항상 같은 방식으로 동작합니다. "내 컴퓨터에서는 되는데요?"라는 변명이 사라집니다.
김개발 씨의 눈이 반짝였습니다. "그래서 여기서는 배포가 그렇게 편한 거였군요!" 박시니어 씨가 웃으며 말했습니다.
"맞아요. 이제 우리는 배포를 두려워하지 않아요.
하루에 열 번이고 스무 번이고 배포할 수 있죠."
실전 팁
💡 - CI/CD의 핵심은 자동화와 빠른 피드백입니다. 수동 작업을 최소화하세요.
- 처음에는 CI만 도입하고, 익숙해지면 CD까지 확장하는 것이 좋습니다.
2. GitHub Actions 탄생 배경
김개발 씨가 물었습니다. "CI/CD 도구가 많다던데, 왜 하필 GitHub Actions을 쓰는 거예요?" 박시니어 씨가 화면을 가리키며 대답했습니다.
"GitHub에서 코드 관리하잖아요. 같은 곳에서 CI/CD까지 되면 얼마나 편하겠어요."
GitHub Actions는 2019년 GitHub에서 출시한 CI/CD 플랫폼입니다. GitHub 저장소와 완벽하게 통합되어, 코드를 푸시하거나 PR을 생성하는 등의 이벤트에 반응하여 자동으로 워크플로우를 실행합니다.
별도의 서버 설정 없이 YAML 파일 하나로 CI/CD 파이프라인을 구축할 수 있습니다.
다음 코드를 살펴봅시다.
# .github/workflows/hello.yml
# GitHub Actions의 기본 구조를 보여주는 예제입니다
name: Hello World # 워크플로우 이름
on: push # 트리거: 코드가 푸시되면 실행
jobs:
say-hello: # 작업 이름
runs-on: ubuntu-latest # 실행 환경
steps:
- name: Print greeting # 단계 이름
run: echo "Hello, GitHub Actions!"
- name: Show current date
run: date
2019년 이전, GitHub을 사용하는 개발자들은 불편함을 감수해야 했습니다. 코드는 GitHub에 있는데, CI/CD는 Jenkins나 Travis CI 같은 외부 서비스를 따로 연동해야 했습니다.
마치 집에서 요리하는데 냉장고가 이웃집에 있는 것과 같았습니다. GitHub도 이 문제를 알고 있었습니다.
개발자들이 코드 관리부터 배포까지 한 곳에서 할 수 있다면 얼마나 편할까요? 그래서 탄생한 것이 바로 GitHub Actions입니다.
GitHub Actions의 가장 큰 장점은 통합입니다. 별도의 서비스에 가입하거나, 복잡한 연동 설정을 할 필요가 없습니다.
GitHub 저장소 안에 .github/workflows 폴더를 만들고 YAML 파일을 넣으면 끝입니다. 마치 집 안에 냉장고를 들여놓은 것처럼 모든 것이 한 곳에 있습니다.
또 다른 장점은 이벤트 기반 트리거입니다. 코드 푸시, PR 생성, 이슈 등록, 심지어 특정 시간에 스케줄링까지.
GitHub에서 일어나는 거의 모든 이벤트에 반응하여 워크플로우를 실행할 수 있습니다. 박시니어 씨가 화면을 보여주며 말했습니다.
"보세요, 저장소의 Actions 탭만 클릭하면 모든 워크플로우 실행 기록을 볼 수 있어요. 어떤 커밋에서 실패했는지, 왜 실패했는지 한눈에 파악할 수 있죠." GitHub Actions가 인기를 끈 또 다른 이유는 마켓플레이스입니다.
다른 개발자들이 만들어놓은 수천 개의 액션을 가져다 쓸 수 있습니다. Node.js 설치, Docker 빌드, AWS 배포 등 흔히 필요한 작업들은 이미 누군가 만들어놓았습니다.
예를 들어 Node.js 프로젝트를 빌드하려면 직접 설치 스크립트를 작성할 필요 없이 actions/setup-node라는 공식 액션을 사용하면 됩니다. 한 줄이면 Node.js 환경이 준비됩니다.
물론 GitHub Actions 이전에도 좋은 CI/CD 도구들이 많았습니다. 하지만 GitHub이 전 세계 개발자들의 사실상 표준 코드 저장소가 되면서, 같은 플랫폼에서 모든 것을 처리할 수 있다는 점이 결정적인 장점이 되었습니다.
김개발 씨가 고개를 끄덕였습니다. "아, 그래서 요즘 오픈소스 프로젝트들을 보면 거의 다 GitHub Actions를 쓰는 거군요." 박시니어 씨가 덧붙였습니다.
"맞아요. 특히 오픈소스에는 무료로 제공되니까 더욱 인기죠."
실전 팁
💡 - GitHub Actions는 GitHub 저장소가 있다면 바로 사용할 수 있습니다. 별도 가입이 필요 없습니다.
- 마켓플레이스에서 필요한 액션을 먼저 검색해보세요. 직접 만들 필요가 없을 수 있습니다.
3. 다른 CI/CD 도구와 비교
김개발 씨가 궁금해졌습니다. "선배, 그런데 Jenkins나 CircleCI 같은 것도 있잖아요.
GitHub Actions이 항상 최선인가요?" 좋은 질문이었습니다. 모든 도구에는 장단점이 있으니까요.
CI/CD 도구는 크게 설치형(Jenkins, GitLab CI)과 클라우드형(GitHub Actions, CircleCI, Travis CI)으로 나뉩니다. 각각의 도구는 서로 다른 장단점을 가지고 있어, 프로젝트의 특성과 팀의 상황에 따라 적합한 도구가 달라집니다.
다음 코드를 살펴봅시다.
# 주요 CI/CD 도구 비교 (개념적 정리)
# Jenkins
# - 장점: 무한한 커스터마이징, 플러그인 생태계
# - 단점: 직접 서버 관리 필요, 설정 복잡
# - 적합: 대기업, 복잡한 파이프라인
# GitHub Actions
# - 장점: GitHub 통합, 쉬운 설정, 무료 제공
# - 단점: GitHub 종속, 복잡한 작업은 한계
# - 적합: GitHub 사용 프로젝트, 오픈소스
# GitLab CI
# - 장점: GitLab과 완벽 통합, Auto DevOps
# - 단점: GitLab 종속
# - 적합: GitLab 사용 프로젝트
# CircleCI
# - 장점: 빠른 빌드, 좋은 캐싱
# - 단점: 가격, 학습 곡선
# - 적합: 성능이 중요한 프로젝트
박시니어 씨가 화이트보드에 도구들을 정리하기 시작했습니다. "각 도구의 특징을 알아두면 나중에 프로젝트에 맞는 도구를 선택할 때 도움이 될 거예요." 먼저 Jenkins입니다.
CI/CD 도구의 할아버지 격으로, 2011년부터 사용되어온 검증된 도구입니다. 가장 큰 장점은 무한한 커스터마이징입니다.
플러그인이 수천 개 있어서 상상하는 거의 모든 것을 할 수 있습니다. 하지만 단점도 명확합니다.
직접 서버를 설치하고 관리해야 합니다. 설정도 복잡해서 제대로 다루려면 Jenkins 전문가가 필요할 정도입니다.
GitLab CI는 GitLab을 사용하는 팀에게 최적의 선택입니다. GitLab 저장소와 완벽하게 통합되어 있고, Auto DevOps 기능으로 설정 없이도 기본적인 CI/CD가 동작합니다.
하지만 GitLab을 사용하지 않는다면 매력이 반감됩니다. CircleCI는 성능에 특화된 도구입니다.
빌드 속도가 빠르고, 캐싱 기능이 뛰어납니다. 큰 프로젝트에서 빌드 시간이 중요하다면 좋은 선택입니다.
다만 무료 티어가 제한적이고 가격이 비싼 편입니다. 그렇다면 GitHub Actions는 어떨까요?
가장 큰 장점은 역시 GitHub과의 완벽한 통합입니다. 이미 GitHub을 사용하고 있다면 별도의 설정 없이 바로 시작할 수 있습니다.
YAML 문법도 직관적이어서 처음 배우는 사람도 쉽게 익힐 수 있습니다. 물론 단점도 있습니다.
GitHub에 종속된다는 점입니다. 나중에 GitLab이나 Bitbucket으로 이전하면 워크플로우를 다시 작성해야 합니다.
또한 아주 복잡한 파이프라인을 구축하기에는 Jenkins만큼 유연하지 않습니다. 김개발 씨가 정리했습니다.
"그러니까 상황에 따라 다르다는 거네요?" 박시니어 씨가 고개를 끄덕였습니다. "맞아요.
우리 팀은 GitHub을 쓰고, 파이프라인도 복잡하지 않으니까 GitHub Actions이 딱 맞는 거예요. 하지만 대기업에서 복잡한 배포 파이프라인을 관리한다면 Jenkins가 나을 수도 있죠." 결론적으로, GitHub을 사용하는 대부분의 프로젝트에서 GitHub Actions는 최적의 선택입니다.
설정이 쉽고, 무료로 충분한 사용량을 제공하며, 커뮤니티도 활발합니다.
실전 팁
💡 - 팀이 이미 사용하는 플랫폼과의 통합을 가장 먼저 고려하세요.
- 처음 CI/CD를 배운다면 GitHub Actions로 시작하는 것이 가장 쉽습니다.
4. GitHub Actions 무료 사용량
"그런데 선배, 이거 돈 내야 하는 거 아니에요?" 김개발 씨의 현실적인 질문에 박시니어 씨가 웃었습니다. "공개 저장소는 완전 무료고, 비공개 저장소도 꽤 넉넉한 무료 사용량이 있어요."
GitHub Actions는 공개 저장소에서 완전 무료입니다. 비공개 저장소의 경우 월 2,000분의 무료 사용량이 제공됩니다.
스토리지는 500MB까지 무료입니다. 이 정도면 개인 프로젝트나 소규모 팀에서는 충분히 무료로 사용할 수 있습니다.
다음 코드를 살펴봅시다.
# GitHub Actions 무료 사용량 정리 (2024년 기준)
# 공개 저장소 (Public Repository)
# - 실행 시간: 무제한 무료
# - 스토리지: 무제한 무료
# - 동시 실행: 20개 작업
# 비공개 저장소 (Private Repository) - Free 플랜
# - 실행 시간: 월 2,000분
# - 스토리지: 500MB
# - 동시 실행: 20개 작업
# 운영체제별 분당 소비량
# - Linux: 1분 = 1분 소비
# - Windows: 1분 = 2분 소비
# - macOS: 1분 = 10분 소비
# 예시: Linux에서 10분 빌드 = 10분 소비
# macOS에서 10분 빌드 = 100분 소비
김개발 씨에게 가장 반가운 소식이었습니다. 개인 사이드 프로젝트를 공개 저장소로 관리하고 있었는데, CI/CD를 무료로 사용할 수 있다니요!
박시니어 씨가 상세히 설명했습니다. "공개 저장소는 실행 시간이 무제한 무료예요.
오픈소스 프로젝트라면 마음껏 사용해도 됩니다." 비공개 저장소의 경우는 조금 다릅니다. GitHub Free 플랜 기준으로 월 2,000분이 무료로 제공됩니다.
스토리지는 500MB까지입니다. 이 정도면 개인 프로젝트나 소규모 스타트업에서는 충분합니다.
하지만 주의할 점이 있습니다. 운영체제에 따라 분당 소비량이 다릅니다.
Linux에서 1분 실행하면 1분이 차감됩니다. 하지만 Windows는 2배, macOS는 무려 10배입니다.
그러니까 macOS에서 10분짜리 빌드를 돌리면 100분이 차감되는 것입니다. 왜 이런 차이가 날까요?
클라우드에서 Linux 서버를 운영하는 비용에 비해 macOS를 운영하는 비용이 훨씬 비싸기 때문입니다. 애플의 라이선스 정책 때문이기도 합니다.
따라서 가능하면 Linux 러너를 사용하는 것이 좋습니다. 대부분의 웹 프로젝트는 Linux에서 빌드하고 테스트해도 문제없습니다.
iOS 앱을 빌드하는 등 반드시 macOS가 필요한 경우에만 macOS 러너를 사용하세요. 김개발 씨가 계산해봤습니다.
"Linux로 10분짜리 빌드를 하루에 10번 돌리면 월 3,000분 정도네요. 살짝 초과하겠군요." 박시니어 씨가 팁을 알려줬습니다.
"그래서 캐싱이 중요해요. 의존성을 캐싱하면 빌드 시간을 절반 이하로 줄일 수 있거든요." 또한 self-hosted runner라는 옵션도 있습니다.
자신의 서버에서 워크플로우를 실행하는 것입니다. 이렇게 하면 GitHub Actions의 무료 사용량을 전혀 소비하지 않습니다.
다만 서버를 직접 관리해야 하는 부담이 있습니다. 정리하자면, 오픈소스 프로젝트라면 걱정 없이 마음껏 사용하면 됩니다.
비공개 프로젝트라도 효율적으로 사용하면 무료 사용량 안에서 충분히 운영할 수 있습니다.
실전 팁
💡 - Linux 러너를 기본으로 사용하고, macOS는 꼭 필요할 때만 사용하세요.
- 캐싱을 적극 활용하여 빌드 시간을 단축하면 무료 사용량을 효율적으로 쓸 수 있습니다.
- 사용량 현황은 Settings > Billing에서 확인할 수 있습니다.
5. 핵심 용어 정리
박시니어 씨가 말했습니다. "이제 본격적으로 배우기 전에 용어부터 정리하고 가죠.
Workflow, Job, Step, Action... 처음엔 헷갈리거든요." 김개발 씨가 펜을 꺼내 들었습니다.
용어가 확실해야 나중에 문서를 읽을 때 막힘이 없으니까요.
GitHub Actions의 핵심 용어는 Workflow, Job, Step, Action, Runner 다섯 가지입니다. Workflow는 전체 자동화 프로세스이고, 그 안에 여러 Job이 있습니다.
각 Job은 여러 Step으로 구성되며, Step에서 Action을 실행합니다. 이 모든 것은 Runner라는 실행 환경에서 돌아갑니다.
다음 코드를 살펴봅시다.
# GitHub Actions 용어 계층 구조
# Workflow (.yml 파일)
# └── Job (작업)
# └── Step (단계)
# └── Action (재사용 가능한 명령 묶음)
#
# Runner: 위 모든 것을 실행하는 서버
name: Build and Test # Workflow 이름
on: push # Trigger: 언제 실행할지
jobs:
build: # Job 이름
runs-on: ubuntu-latest # Runner 지정
steps: # Step 목록
- uses: actions/checkout@v4 # Action 사용
- name: Run tests
run: npm test # 직접 명령 실행
박시니어 씨가 화이트보드에 계층 구조를 그렸습니다. "이 다섯 가지만 확실히 이해하면 GitHub Actions의 절반은 마스터한 거예요." 먼저 Workflow입니다.
가장 큰 단위로, 하나의 자동화 프로세스 전체를 의미합니다. .github/workflows 폴더에 있는 YAML 파일 하나가 하나의 Workflow입니다.
예를 들어 "테스트 및 배포 자동화"가 하나의 Workflow가 됩니다. 다음은 Job입니다.
Workflow 안에는 여러 개의 Job이 있을 수 있습니다. 각 Job은 독립적인 실행 단위입니다.
비유하자면 Workflow가 공장이라면, Job은 각각의 생산 라인입니다. 기본적으로 Job들은 병렬로 실행됩니다.
하지만 needs 키워드로 순서를 지정할 수도 있습니다. 그 안에 Step이 있습니다.
Job은 여러 개의 Step으로 구성됩니다. Step은 순차적으로 하나씩 실행되는 단계입니다.
코드를 체크아웃하고, 의존성을 설치하고, 테스트를 실행하는 것이 각각 하나의 Step이 됩니다. Step에서 실행하는 것이 Action입니다.
Action은 재사용 가능한 명령 묶음입니다. 마켓플레이스에서 다른 사람이 만든 Action을 가져다 쓸 수도 있고, 직접 만들 수도 있습니다.
actions/checkout은 저장소 코드를 가져오는 공식 Action이고, actions/setup-node는 Node.js 환경을 설정하는 Action입니다. 마지막으로 Runner입니다.
이 모든 것이 실제로 실행되는 환경입니다. GitHub에서 제공하는 GitHub-hosted runner를 사용하면 Ubuntu, Windows, macOS 환경에서 실행할 수 있습니다.
또는 self-hosted runner를 설정해서 자신의 서버에서 실행할 수도 있습니다. 김개발 씨가 정리했습니다.
"그러니까 Workflow 파일을 만들고, 그 안에 Job들을 정의하고, 각 Job에 Step들을 나열하고, Step에서 Action이나 명령어를 실행하는 거네요." 박시니어 씨가 엄지를 들었습니다. "완벽해요!" 한 가지 더 알아둘 용어가 있습니다.
Event 또는 Trigger입니다. Workflow가 언제 실행될지를 정의합니다.
on: push라고 쓰면 코드가 푸시될 때 실행되고, on: pull_request라고 쓰면 PR이 생성될 때 실행됩니다. 이 용어들이 익숙해지면 GitHub Actions 문서를 읽을 때 훨씬 수월해집니다.
처음에는 헷갈려도 직접 워크플로우를 몇 개 만들어보면 자연스럽게 체득됩니다.
실전 팁
💡 - Job은 병렬 실행이 기본이고, Step은 순차 실행입니다. 이 차이를 기억하세요.
- Action은 마켓플레이스에서 검색해서 사용하면 시간을 크게 절약할 수 있습니다.
6. 첫 번째 워크플로우 체험
이론은 충분합니다. 이제 직접 해볼 차례입니다.
박시니어 씨가 말했습니다. "백문이 불여일견이에요.
가장 간단한 워크플로우를 만들어보죠." 김개발 씨가 키보드에 손을 올렸습니다.
GitHub Actions 워크플로우는 저장소의 .github/workflows 폴더에 YAML 파일로 작성합니다. 가장 간단한 워크플로우는 코드가 푸시될 때 테스트를 실행하는 것입니다.
파일을 만들고 푸시하면 바로 Actions 탭에서 실행 결과를 확인할 수 있습니다.
다음 코드를 살펴봅시다.
# .github/workflows/ci.yml
# Node.js 프로젝트를 위한 기본 CI 워크플로우
name: CI # 워크플로우 이름 (Actions 탭에 표시됨)
on:
push:
branches: [main] # main 브랜치에 푸시될 때
pull_request:
branches: [main] # main 브랜치로의 PR이 생성될 때
jobs:
test:
runs-on: ubuntu-latest # Ubuntu 최신 버전에서 실행
steps:
- name: Checkout code
uses: actions/checkout@v4 # 저장소 코드 가져오기
- name: Setup Node.js
uses: actions/setup-node@v4 # Node.js 설치
with:
node-version: '20'
- name: Install dependencies
run: npm ci # 의존성 설치
- name: Run tests
run: npm test # 테스트 실행
김개발 씨가 드디어 첫 번째 워크플로우를 만들 시간입니다. 박시니어 씨가 옆에서 가이드합니다.
"먼저 저장소에 .github/workflows 폴더를 만들어요. 이 폴더 안에 있는 YAML 파일들이 워크플로우가 됩니다." 폴더를 만들고 ci.yml 파일을 생성합니다.
파일 이름은 자유롭게 지을 수 있지만, 목적을 알 수 있게 짓는 것이 좋습니다. 파일의 첫 줄에 name을 지정합니다.
이 이름이 GitHub Actions 탭에 표시됩니다. 팀원들이 보기 좋게 의미 있는 이름을 붙입니다.
다음은 on 섹션입니다. 언제 이 워크플로우가 실행될지 정의합니다.
push와 pull_request를 모두 지정했으니, 코드를 푸시하거나 PR을 만들 때 모두 실행됩니다. branches로 특정 브랜치만 지정할 수도 있습니다.
jobs 섹션에서 실제 작업을 정의합니다. 여기서는 test라는 이름의 Job 하나를 만들었습니다.
runs-on: ubuntu-latest는 GitHub에서 제공하는 최신 Ubuntu 환경에서 실행하겠다는 뜻입니다. steps에는 순서대로 실행할 단계들을 나열합니다.
첫 번째로 actions/checkout@v4를 사용해 저장소 코드를 가져옵니다. 이 단계가 없으면 러너에 코드가 없어서 아무것도 할 수 없습니다.
두 번째로 actions/setup-node@v4로 Node.js를 설치합니다. with 아래에 node-version을 지정해서 원하는 버전을 설치할 수 있습니다.
세 번째로 npm ci를 실행해 의존성을 설치합니다. npm install 대신 npm ci를 쓰는 이유는 CI 환경에 최적화되어 있어 더 빠르고 안정적이기 때문입니다.
마지막으로 npm test를 실행해 테스트를 돌립니다. 여기서 테스트가 실패하면 워크플로우 전체가 실패로 표시됩니다.
김개발 씨가 파일을 저장하고 푸시했습니다. GitHub 저장소의 Actions 탭을 열자 방금 만든 워크플로우가 실행되고 있었습니다.
각 Step이 순서대로 실행되면서 초록색 체크 표시가 하나씩 나타났습니다. "와, 진짜 자동으로 되네요!" 김개발 씨의 눈이 반짝였습니다.
몇 분 뒤 모든 Step이 완료되고 워크플로우가 성공으로 표시되었습니다. 박시니어 씨가 말했습니다.
"이제 이 저장소에 코드를 푸시할 때마다 자동으로 테스트가 돌아갈 거예요. 테스트가 실패하면 바로 알림을 받을 수 있죠." 이것이 CI/CD의 시작입니다.
이 간단한 워크플로우만으로도 코드 품질을 지키는 데 큰 도움이 됩니다. 여기서 더 발전시켜 빌드, 린트, 배포까지 추가할 수 있습니다.
실전 팁
💡 - 워크플로우 파일을 수정하면 반드시 main 브랜치에 머지해야 변경사항이 적용됩니다.
- Actions 탭에서 실행 로그를 자세히 볼 수 있으니, 실패했을 때 로그를 확인하세요.
- 처음에는 간단하게 시작하고 점점 기능을 추가해나가는 것이 좋습니다.
이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!