[Spring Boot] "귀찮은 빌드 작업, 이제 그만!" GitHub Actions로 CI/CD 자동화 입문

 
혹시 아직도 배포할 때마다 이런 과정을 반복하고 계신가요?

1. 로컬에서 ./gradlew build 실행 (한참 기다림)
2. FTP나 SCP로 서버에 jar 파일 전송
3. 서버 접속해서 기존 프로세스 죽이고(kill), 다시 실행(java -jar)

이 과정은 귀찮기도 하지만, 사람이 하기 때문에 반드시 실수가 발생합니다. 오늘은 이 과정을 로봇에게 맡기는 CI(Continuous Integration, 지속적 통합)를 GitHub Actions로 구현해 보겠습니다.

---

1. CI/CD가 도대체 뭔가요?

• CI (Continuous Integration): "지속적 통합"
• 개발자가 코드를 합칠(Merge) 때마다, 자동으로 빌드하고 테스트해서 "이 코드 문제없어!"라고 검증하는 과정입니다.

• CD (Continuous Deployment): "지속적 배포"
• 검증된 코드를 실제 사용자나 테스트 서버에 자동으로 배포(실행)하는 과정입니다.

오늘은 이 중에서 가장 기본이 되는 "GitHub에 올리면 자동으로 빌드 & 테스트하기(CI)"를 해보겠습니다.

---

2. 왜 GitHub Actions인가요?

예전에는 젠킨스(Jenkins)라는 별도의 서버를 구축해야 했습니다. (관리하기 정말 힘들었죠.)
하지만 GitHub Actions는 우리가 코드를 올리는 GitHub 저장소에 내장되어 있습니다.

• 장점:
• 서버 설치 필요 없음 (GitHub가 빌려줌)
• 공개 저장소(Public Repo)는 공짜!
• 설정이 매우 간편함 (yaml 파일 하나면 끝)

---

3. 실전! 자동 빌드 스크립트 만들기

GitHub Actions에게 일을 시키려면 "워크플로우(Workflow)"라는 작업 지시서를 작성해야 합니다.

① 폴더 만들기

프로젝트 최상단에 다음 경로로 폴더를 만듭니다. (이름 틀리면 안 됩니다!)
.github/workflows

② 파일 만들기 ()

위 폴더 안에 gradle.yml 파일을 만들고 아래 내용을 복사해 넣으세요.

# 워크플로우 이름 (GitHub Actions 탭에 표시됨)
name: Spring Boot CI

# 언제 실행할 것인가? (Trigger)
on:
  push:
    branches: [ "main" ] # main 브랜치에 push 될 때마다 실행!
  pull_request:
    branches: [ "main" ] # PR이 들어올 때도 실행!

# 할 일 목록 (Jobs)
jobs:
  build:
    # 실행 환경 (리눅스 우분투 최신 버전 빌려줘!)
    runs-on: ubuntu-latest

    # 실행 단계 (Steps)
    steps:
    # 1. 내 코드 내려받기 (Checkout)
    - uses: actions/checkout@v3

    # 2. 자바 설치하기 (JDK 17)
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'

    # 3. Gradle 권한 부여 (가끔 권한 문제 생길 수 있음)
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew

    # 4. 빌드 및 테스트 실행 (가장 중요!)
    - name: Build with Gradle
      run: ./gradlew clean build

---

4. 결과 확인하기

이제 이 파일을 git add, commit, push 해보세요.
그리고 GitHub 저장소 페이지의 상단 [Actions] 탭을 클릭해 보세요.

1. 방금 올린 커밋 메시지와 함께 노란색 불(진행 중)이 들어옵니다.
2. 클릭해서 들어가면 build 작업이 실시간으로 로그를 찍으며 돌아가는 게 보입니다.
3. 잠시 후 초록색 체크 표시(Success)가 뜨면 성공! 🎉

만약 빨간 불(Fail)이 떴다면?
로그를 확인해 보세요. 십중팔구 테스트 코드에서 실패했거나, gradlew 권한 문제입니다. 로컬에서는 되는데 여기서 안 된다면, 환경 차이 때문일 확률이 높습니다.

---

5. 이걸 하면 뭐가 좋나요?

이제 팀원 중 누군가가 실수로 컴파일 에러가 나는 코드를 올리거나, 기존 기능을 망가뜨리는 코드(테스트 실패)를 올리면, GitHub가 즉시 빨간색 경고를 띄워줍니다.
"어? 김 대리님, 빌드 깨졌는데요?"
배포하기 전에 문제를 미리 알 수 있는 강력한 안전장치가 생긴 것이죠.

---

마치며

오늘의 결론입니다.

1. CI/CD는 개발자의 수동 작업을 자동화하는 필수 과정이다.
2. GitHub Actions는 별도 서버 없이 무료로 쓸 수 있는 최고의 도구다.
3. .github/workflows/gradle.yml 파일 하나만 추가하면 자동 빌드 시스템 완성!

이제 빌드와 테스트는 자동화되었습니다. 다음 단계는 무엇일까요?
바로 "빌드된 파일을 실제 서버(AWS EC2 등)로 보내서 실행까지 시키는 CD(배포 자동화)"입니다.
다음 포스팅에서는 AWS EC2 서버를 만들고, GitHub Actions에서 만든 Jar 파일을 거기로 쏘는 방법에 대해 알아보겠습니다. (진짜 배포가 시작됩니다!)