GitHub Actions를 이용한 Spring Boot 자동 배포(CI/CD) 완벽 가이드: 이론부터 실무 최적화까지

1. 서론: 왜 현대 개발자에게 CI/CD는 필수인가?

과거의 배포 방식은 개발자가 로컬에서 빌드한 jar나 war 파일을 FTP로 서버에 업로드하고, 직접 터미널에 접속하여 프로세스를 재시작하는 수동적인 과정이었습니다. 하지만 서비스의 규모가 커지고 배포 주기가 짧아짐에 따라 이러한 방식은 휴먼 에러의 온상이 되었습니다.

**CI(Continuous Integration)**는 코드 변경 사항을 지속적으로 통합하고 검증하는 과정을 자동화하며, **CD(Continuous Deployment)**는 검증된 코드를 실제 운영 환경에 자동으로 반영하는 것을 의미합니다. 이번 포스트에서는 GitHub Actions를 활용해 이 과정을 어떻게 구축하고, 실무에서 고려해야 할 최적화 포인트는 무엇인지 심도 있게 다뤄보겠습니다.

2. CI/CD 파이프라인의 전체 아키텍처

우리가 구축할 파이프라인은 다음과 같은 흐름을 가집니다.

1. Push & Trigger: 개발자가 main 브랜치에 코드를 푸시하거나 Pull Request를 병합합니다.
2. Build & Test: GitHub이 제공하는 가상 환경(Runner)에서 JDK를 설정하고 Gradle을 이용해 테스트 및 빌드를 수행합니다.
3. Artifact Management: 빌드된 결과물(jar)을 안전하게 관리합니다. (필요 시 Docker Hub 등에 이미지로 업로드)
4. Deploy: SSH 프로토콜을 이용해 운영 서버에 접속하고, 기존 프로세스를 종료한 뒤 새 버전을 실행합니다.

3. GitHub Actions 워크플로우 상세 설정 (.github/workflows/deploy.yml)

단순한 배포를 넘어, 빌드 속도를 높이기 위한 캐싱 전략이 포함된 설정입니다.

name: Production CD Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'
          # Gradle 캐싱 활성화로 빌드 속도 향상
          cache: 'gradle'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle (Exclude Tests for speed if needed)
        run: ./gradlew clean build -x test

      - name: Deliver Artifact via SCP
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.SERVER_IP }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          source: "build/libs/*.jar"
          target: "/home/${{ secrets.SERVER_USER }}/deploy"
          strip_components: 2

      - name: Execute Remote Deployment Script
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.SERVER_IP }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: |
            echo "Stopping current application..."
            fuser -k 8080/tcp || true
            echo "Starting new application..."
            nohup java -jar ~/deploy/*.jar > ~/deploy/app.log 2>&1 &
            echo "Deployment successful!"

4. 실무에서의 핵심 고려 사항

4.1. 보안 관리 (GitHub Secrets)

절대로 application.yml에 담긴 DB 비밀번호나 API 키, 서버 접속 정보를 소스 코드에 포함해서는 안 됩니다. GitHub Actions는 Secrets 기능을 통해 암호화된 변수를 제공합니다. 특히 SSH Key를 등록할 때는 -----BEGIN RSA PRIVATE KEY-----부터 끝까지 정확히 복사해야 접속 오류를 방지할 수 있습니다.

4.2. 빌드 속도 최적화 (Caching)

매번 배포할 때마다 의존성 라이브러리를 다시 다운로드하는 것은 비효율적입니다. 위 설정에서 cache: 'gradle'을 사용한 것처럼, 캐싱 기능을 적극 활용하면 배포 시간을 수십 초에서 수 분까지 단축할 수 있습니다.

4.3. 무중단 배포 (Blue-Green / Rolling Update)

위의 스크립트는 서비스를 잠시 중단(Stop -> Start)하는 방식입니다. 실제 상용 서비스에서는 Nginx의 리버스 프록시 설정을 이용해 구버전과 신버전을 교체하는 Blue-Green 방식이나, 여러 대의 서버를 순차적으로 업데이트하는 Rolling Update를 고려해야 합니다.

5. 결론 및 향후 과제

GitHub Actions는 별도의 서버 구축 없이도 강력한 CI/CD 환경을 무료로 제공합니다. 이제 여러분은 단순 반복 작업에서 벗어나 더 가치 있는 코드 작성에 집중할 수 있습니다. 다음 단계로는 Docker 컨테이너 기반의 배포나 Kubernetes를 이용한 오케스트레이션으로 확장해 보시길 권장합니다.

• GitHub Actions
• Spring Boot
• Automation
• Deployment
• DevOps