CI/CD(2) - CI/CD 도구와 GitHub Actions

안녕하세요. 좋은 오후입니다. 오늘은 날씨가 종일 흐리네요. 내일 비가와서 그런가봅니다...날씨가 흐려서 힘도 같이 빠지지만 내일 불닭 냉면 + 돈까스를 먹는다는걸 생각하면서 오늘 하루도 열심히 살아보고자 합니다. 그럼 CI/CD 학습 시작하겠습니다.

---

CI/CD 도구를 학습하는 이유

지난 시간에는 CI/CD가 무엇인지 그리고 빌드, 테슽, 배포 자동화하는 이유에 대해 학습했습니다. 이번 시간에는 CI/CD를 실제로 구성할 때 사용하는 도구들을 알아보려 합니다. CI/CD를 구현하는 도구에는 GitHub Actions, Jenkins, GitLab CI/CD, CircleCI 등이 있습니다.

 

그 중 GitHub Actions는 GitHub 저장소와 바로 연결해 사용할 수 있어 GitHub로 프로젝트를 관리하는 개인 프로젝트나 팀 프로젝트에서 접근하기 좋은 도구입니다. 따라서 이번 글에서는 GitHub Actions를 중심으로 살펴보고, 다른 CI/CD 도구들은 간략히 비교해보겠습니다.

 

CI/CD 도구에는 무엇이 있을까?

CI/CD 도구마다 설정 방식과 운영 방식은 다르지만 핵심 목적은 같습니다. 코드 변경 이후 빌드, 테스트, 배포 과정을 자동화하여 반복 작업을 줄이고, 검증된 코드가 안정적으로 반영되도록 돕는 것입니다.

도구	특징
GitHub Actions	GitHub 저장소와 바로 연결되는 자동화 도구
Jenkins	별도 서버에 설치해 사용하는 오픈소스 CI/CD 도구
GitLab CI/CD	GitLab 저장소와 통합된 CI/CD 도구
CircleCI	클라우드 기반 CI/CD 자동화 도구

 

GitHub Actions

GitHub Actions는 GitHub에서 제공하는 자동화 도구입니다. 코드를 push하거나 pull request를 생성했을 때, 미리 정의한 작업을 자동으로 실행할 수 있습니다. 이를 통해 프로젝트 빌드, 테스트, 실행, Docker 이미지 생성, 서버 배포 같은 작업을 자동화할 수 있습니다.

 

즉, GitHub Actions는 GitHub 저장소에서 발생하는 이벤트를 기준으로 정해진 작업을 자동 실행하는 CI/CD 도구입니다.

 

GitHub Actions의 핵심 개념

GitHub Actions는 Workflow 파일을 기준으로 동작합니다. Workflow 안에는 어떤 이벤트에서 실행할지, 어떤 작업을 수행할지, 어떤 환경에서 실행할지를 정의합니다.

개념	의미
Workflow	자동화 작업을 정의한 파일
Event	Workflow를 실행시키는 조건
Job	하나의 실행 작업 단위
Step	Jop 안에서 실행되는 개별 단계
Action	재사용 가능한 작업 단위
Runner	Workflow가 실행되는 환경

 

Workflow

Workflow는 GitHub Actions에서 자동화 작업을 정의한 파일입니다. 보통 프로젝트 루트 경로 아래에 ".github/workflows" 폴더를 만들고, 그 안에 '.yml' 또는 '.yaml' 파일로 작성합니다.

 

예시 경로 : .github/workflows/deploy.yml

 

Workflow 의 기본 구성 요소

아래의 예시는 main 브랜치에 push가 발생했을 때 실행되는 간단한 CI Workflow입니다.

actions/checkout은 Github 저장소의 코드를 가져오는 역할을 하고, actions/setup-java는 Java 실행 환경을 준비하는 역할을 합니다. 마지막으로 ./gradlew build 명령어를 통해 Spring Boot 프로젝트를 빌드합니다.

name: CI

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source code
        uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Build with Gradle
        run: ./gradlew build

 

Spring Boot 프로젝트에서의 GitHub Actions 흐름

Spring Boot 프로젝트에서 GitHub Actions를 사용한다면 대략 다음과 같은 흐름으로 CI/CD를 구성할 수 있습니다.

 

Jenkins, GitLab CI/CD, CircleCI는 무엇이 다를까?

개인 프로젝트난 GitHub를 중심으로 관리하는 프로젝트라면 GitHub Actions가 시작하기 쉽습니다. 반면 회사 내부 인프라와 여러 도구를 세밀하게 연결해야 한다면 Jenkins처럼 자유도가 높은 도구가 사용될 수 있습니다. 

구분	GitHub Actions	Jenkins	GitLab CI/CD	CircleCI
특징	GitHub와 직접 연동	자유도 높은 오픈소스 도구	GitLab과 통합	클라우드 기반 자동화
장점	설정이 비교적 간단함	플러그인이 풍부함	GitLab 사용 시 편리함	빠른 설정과 실행
단점	GitHub 의존성이 있음	서버 운영이 필요함	GitLab 환경에 적합	외부 서비스 의존
적합한 경우	GitHub 기반 프로젝트	복잡한 사내 인프라	GitLab 기반 프로젝트	빠른 클라우드 CI/CD 구성

즉, 어떤 도구가 무조건 좋다기보다 프로젝트 환경, 저장소 플랫폼, 배포 방식, 운영 규모에 따라 적절한 도구를 선택하는 것이 중요합니다.

 

Docker와 CI/CD의 관계

Docker는 애플리케이션 실행 환경을 이미지로 만들 수 있는 도구입니다.

CI/CD에서 Docker를 함께 사용하면 GitHub Actions에서 Docker 이미지를 빌드하고, Docker Hub난 컨테이너 레지스트리에 이미지를 올린 뒤 서버에서 해당 이미지를 내려받아 실행하는 흐름을 만들 수 있습니다.

즉, Docker가 실행 환경을 일관되게 만들기 위한 도구라면 CI/CD는 빌드, 테스트, 배포 과정을 자동화하는 흐름입니다. 두 개를 함께 사용하면 배포 과정에서 환경 차이로 인한 문제를 줄일 수 있습니다.

 

실제 배포 자동화 시 주의할 점

CI/CD를 적용하면 배포 과정이 편리해지지만 무조건 자동화한다고 좋은 것은 아닙니다. 특히 운영 서버에 직접 반영되는 자동 배포는 주의가 필요합니다.

 

1. 환경 변수와 비밀키는 GitHub Secrets로 관리해야 합니다.
2. 서버 접속 정보는 코드에 직접 작성하지 않아야 합니다.
3. 테스트가 실패하면 배포가 진행되지 않도록 해야 합니다.
4. 배포 실패 시 이전 상태로 되돌릴 방법을 고려해야 합니다.
5. main 브랜치에 바로 배포하지 않고 브랜치 전략을 함께 고려해야 합니다.
6. 무중단 배포가 아니라면 재시작 과정에서 잠깐의 중단이 발생할 수 있습니다.

즉, CI/CD는 배포를 빠르게 만드는 도구이지만 잘못 설정하면 잘못된 코드도 빠르게 배포될 수 있습니다. 따라서 자동화보다 중요한 것은 안전하게 검증된 코드만 배포되도록 흐름을 설계하는 것입니다.

---

현재 진행 중인 프로젝트 역시 CI/CD를 넣을까 고민 중이였는데 구조적으로 더 많은 고민이 필요할 것 같네요. 확실히 공부한 것들이 오류로 나타나고 앞으로의 진행방향을 결정하는데 도움이 되어서 재밌는 것 같아요.

다음 시간에는 개발 설계 원칙에 대해 얘기해봅시다. 수고하셨습니다.