[CI/CD 시리즈 02] 1분 만에 끝내는 실전 배포: Docker Compose와 GitHub Actions 연동

CI/CD Automation Series 02

빌드부터 서버 반영까지,
Docker Compose 실전 배포 자동화

 

안녕하세요, code-resting입니다. 지난 1편에서 GitHub Actions를 통해 Docker 이미지를 생성하고 저장소에 푸시하는 것까지 성공했습니다. 이제 마지막 단계입니다. 서버가 이 이미지를 가져와서 기존 버전을 내리고, 새 버전을 올리는 과정을 자동화해 보겠습니다.

1. 왜 Docker Compose인가?

단일 docker run 명령어도 가능하지만, 애플리케이션 외에 DB, Redis 등을 묶어서 관리하고 환경 변수를 체계적으로 관리하기 위해 Docker Compose를 사용하는 것이 실무의 정석입니다.

# docker-compose.yml (서버 위치)
services:
  app:
    image: ${{ secrets.DOCKER_USER }}/my-app:latest
    ports:
      - "8080:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=prod
    restart: always

2. 원격 서버 접속 및 배포 명령 (SSH)

GitHub Actions에서 서버로 직접 명령을 내리기 위해 appleboy/ssh-action을 활용합니다. 이 과정에서 서버의 IP, SSH Key 정보가 필요합니다.

# deploy.yml 하단에 추가
- name: Deploy to Server
  uses: appleboy/ssh-action@master
  with:
    host: ${{ secrets.SERVER_HOST }}
    username: ${{ secrets.SERVER_USER }}
    key: ${{ secrets.SSH_PRIVATE_KEY }}
    script: |
      docker pull ${{ secrets.DOCKER_USER }}/my-app:latest
      docker-compose up -d
      docker image prune -f # 사용하지 않는 이전 이미지 정리

3. 배포 성능 최적화: Layer Caching

매번 모든 라이브러리를 다시 빌드하면 시간이 오래 걸립니다. Dockerfile의 순서를 최적화하여 변경된 소스 코드만 빌드되도록 설정하면 배포 시간을 30초 이내로 단축할 수 있습니다.

💡 Tip: Gradle의 dependencies를 소스 코드보다 먼저 복사(COPY)하도록 Dockerfile을 구성하세요. 라이브러리가 변하지 않았다면 캐시된 레이어를 사용하여 빌드 속도가 비약적으로 향상됩니다.

💡 마치며

이로써 코드 푸시 한 번으로 [빌드 -> 이미지화 -> 저장소 푸시 -> 서버 배포 -> 컨테이너 갱신]에 이르는 전체 자동화 파이프라인이 완성되었습니다. 이제 개발자는 인프라 고민 없이 오직 좋은 코드를 작성하는 데만 집중할 수 있습니다. 2026년 백엔드 개발자라면 반드시 갖춰야 할 '무기' 하나를 장착하신 셈입니다!

© 2026 code-resting. All rights reserved.