AWS에 스프링 부트를 배포하는 네 가지 방법

AWS에 스프링 부트(Spring Boot) 애플리케이션을 배포하는 방식은 EC2에 직접 접속해 JAR 파일을 실행하는 수동 배포부터, 셸 스크립트 자동화, AWS CodeDeploy 같은 관리형 배포 서비스, 그리고 컨테이너 기반 배포까지 단계적으로 발전해 왔다. 각 방식은 자동화 수준과 무중단 배포 가능 여부, 운영 부담에서 차이가 나며, 팀 규모와 트래픽 특성에 맞는 방식을 선택하는 것이 중요하다. 면접에서는 특정 명령어보다 각 방식의 원리와 한계를 이해하고 있는지를 확인한다.

배포 과정의 큰 그림

스프링 부트 배포의 본질은 세 단계로 요약된다. 먼저 소스 코드를 빌드해 실행 가능한 JAR(Java Archive)라는 산출물을 만들고, 그 산출물을 서버로 옮긴 뒤, 기존 프로세스를 새 버전으로 교체한다. 스프링 부트는 내장 톰캣(Tomcat)을 포함한 실행 가능 JAR를 만들어 주기 때문에 별도의 웹 애플리케이션 서버를 설치할 필요 없이 java -jar 한 줄로 서비스를 띄울 수 있다. 어떤 배포 방식을 쓰든 이 세 단계는 동일하며, 차이는 누가 어떤 도구로 이 과정을 수행하느냐에 있다.

EC2 수동 배포와 그 한계

가장 원초적인 방식은 EC2(Elastic Compute Cloud) 인스턴스에 SSH(Secure Shell)로 접속해서 직접 배포하는 것이다. 서버에서 git pull로 코드를 받아 빌드하거나, 로컬에서 빌드한 JAR를 scp로 전송한 뒤 기존 프로세스를 종료하고 새 프로세스를 실행한다.

ssh -i mykey.pem ec2-user@서버주소
kill -15 $(pgrep -f myapp.jar)
nohup java -jar myapp.jar > app.log 2>&1 &

여기서 nohup은 SSH 세션이 끊겨도 프로세스가 살아 있게 하고, 2>&1은 표준 에러를 표준 출력과 같은 로그 파일로 합친다. 이 방식은 원리를 이해하기에는 좋지만 사람이 매번 같은 명령을 반복해야 하므로 실수가 생기기 쉽고, 프로세스를 죽이고 새로 띄우는 사이에 서비스가 중단되는 다운타임(downtime)이 반드시 발생한다.

배포 스크립트로 자동화하기

수동 배포의 반복 작업을 셸 스크립트 하나로 묶으면 배포가 명령 한 번으로 줄어든다. 전형적인 배포 스크립트는 저장소 갱신, 빌드, 기존 프로세스 종료, 새 프로세스 실행, 상태 확인 순서로 구성된다.

#!/bin/bash
REPO_DIR=/home/ec2-user/app
cd $REPO_DIR
git pull origin main
./gradlew clean bootJar

PID=$(pgrep -f myapp.jar)
if [ -n "$PID" ]; then
  kill -15 $PID
  sleep 5
fi

nohup java -jar build/libs/myapp.jar > app.log 2>&1 &
curl -s http://localhost:8080/actuator/health

여기서 kill -15는 강제 종료(SIGKILL)가 아니라 정상 종료(SIGTERM) 신호를 보내, 처리 중인 요청을 마무리할 기회를 준다. 마지막의 헬스 체크(health check)는 새 프로세스가 정상 기동했는지 확인하는 안전장치다. 스크립트 방식은 배포 절차를 코드로 고정한다는 점에서 큰 진전이지만, 여전히 서버 한 대 기준이고 배포 순간의 다운타임 문제는 해결하지 못한다.