[AWS] AWS에 프로젝트 배포하기 (1) - EC2 생성, 초기 설정, 배포 준비

📌 핵심 요약

• EC2 단일 인스턴스 — 컨테이너 없이 Spring Boot + MySQL + Nginx를 한 서버에 구성
• t4g.small (ARM) 추천 — Java 21 + MySQL 동시 운영 시 메모리 여유, x86 대비 약 20% 저렴
• 월 $10~12 수준 — 하루 12시간 운영 기준, 추후에 Lambda + EventBridge로 서버 자동 시작/정지 설정
• init_server.sh로 초기 설정 자동화 — 계정 생성·디렉토리 구성·systemd 서비스 등록까지 스크립트 한 번 실행으로 완료

 

목차

1 개요 및 아키텍처

이 글은 Spring Boot 프로젝트를 AWS EC2에 직접 배포하는 전 과정을 기록한 글입니다. 

Docker나 별도 PaaS 없이 EC2 단일 인스턴스에 Spring Boot + MySQL + Nginx를 구성하는 방식으로, 소규모 프로젝트나 개인 서비스에 적합한 구성입니다.

서비스 운영 시간은 하루 12시간으로 설정하고, EC2를 시작/정지하는 방식으로 비용을 절감할 예정입니다.

기술 스택

구분	기술	버전
애플리케이션	Spring Boot / Java	4.0.2 / 21
데이터베이스	MySQL	8.0
웹 서버	Nginx (리버스 프록시)	1.24
OS	Ubuntu LTS (ARM)	24.04
인프라	AWS EC2, Elastic IP, Lambda, EventBridge	—

서버 구성도

사용자가 브라우저로 접속하면 요청이 Elastic IP(고정 IP) → Nginx → Spring Boot 순서로 전달됩니다.

Nginx는 외부 요청을 받아 내부에서 실행 중인 Spring Boot 애플리케이션으로 넘겨주는 중간 관문(리버스 프록시) 역할을 합니다. MySQL은 같은 서버 안에서 동작하므로 외부에서는 직접 접근할 수 없습니다.

 

Architecture

인터넷 → Elastic IP → EC2 (Ubuntu)
                              ├── Nginx (포트 80)
                              │     └── 리버스 프록시 → Spring Boot (포트 8080)
                              └── MySQL (127.0.0.1:3306)

2 인스턴스 선택 기준 및 비용

EC2 인스턴스는 AWS에서 빌려 쓰는 가상 서버입니다. 인스턴스 유형에 따라 CPU·메모리 성능이 달라지고, 그에 맞게 비용도 달라집니다.

운영 시간이 하루 12시간 이하라면 EC2를 시작/정지하는 방식이 비용 면에서 가장 효율적입니다.

RDS를 별도로 두지 않고 EC2 안에 MySQL을 함께 운영하면 인스턴스 정지만으로 모든 비용을 절감할 수 있습니다.

ℹ️

t4g.small (ARM) 을 추천하는 이유

Java + MySQL을 동시에 운영하면 t3.micro(1GB RAM)는 메모리 부족이 발생할 수 있습니다. t4g.small은 2GB RAM을 제공하며, ARM 아키텍처(모바일·저전력 설계 방식) 덕분에 x86 대비 약 20% 저렴하고 Java 21을 완전히 지원합니다.

월 예상 비용 (12시간/일 기준)

EBS(Elastic Block Store)는 EC2에 연결되는 가상 하드디스크입니다.

EC2를 정지해도 EBS에 저장된 데이터는 유지됩니다.

Elastic IP는 고정 IP 주소로, EC2가 정지 중일 때도 IP를 점유하고 있으면 소액의 요금이 부과됩니다.

항목	사양	월 비용
EC2	t4g.small (ARM, 2GB RAM)	약 $6.6
EBS	20GB gp3	약 $1.6
Elastic IP	정지 중 과금 ($0.005/시간)	약 $1.8
합계	—	약 $10~12

⚠️

EC2 중지 vs 종료 혼동 주의

중지(Stop)는 서버를 일시 정지하는 것으로 나중에 다시 시작할 수 있습니다. 반면 종료(Terminate)는 서버를 완전히 삭제하므로 복구가 불가능합니다. AWS 콘솔에서 버튼을 누르기 전 반드시 어떤 동작인지 확인하세요.

3 STEP 0~1 : EC2 생성 및 SSH 접속

STEP 0 — EC2 인스턴스 생성

AWS 콘솔 → EC2 → 인스턴스 시작 메뉴에서 아래 설정값을 참고해 인스턴스를 생성합니다.

각 항목이 무엇을 의미하는지 함께 확인하세요.

항목	설정값	설명
AMI	Ubuntu Server 24.04 LTS (64비트 ARM)	서버에 설치할 운영체제 이미지. Ubuntu 24.04 LTS는 장기 지원 버전으로 안정적입니다.
인스턴스 유형	t4g.small	서버의 CPU·메모리 사양. Java + MySQL 동시 운영에 적합한 최소 사양입니다.
키 페어	새로 생성 후 .pem 파일 저장	서버 접속에 사용하는 개인 키 파일입니다. 생성 후 반드시 안전한 곳에 보관하세요.
스토리지	20GB gp3	서버의 가상 하드디스크 용량입니다. gp3는 성능 대비 비용이 효율적인 타입입니다.
보안 그룹 인바운드	22(SSH/내 IP), 80(HTTP), 443(HTTPS)	외부에서 서버로 들어올 수 있는 포트를 지정하는 방화벽 규칙입니다. SSH는 내 IP만 허용해 보안을 강화합니다.

생성 후 Elastic IP(고정 IP 주소)를 할당하여 인스턴스에 연결합니다.

EC2는 기본적으로 재시작할 때마다 IP가 바뀝니다. 서비스를 껐다 켤 때마다 주소가 바뀐다면 운영이 어렵기 때문에 Elastic IP로 IP를 고정합니다. (서버를 24시간 내내 켜두는 무중단 운영이라면 설정하지 않아도 됩니다)

STEP 1 — SSH 접속

배포 첫 단계로 Windows 환경에서 생성한 EC2 서버에 접속하고 작업을 진행할 수 있도록 접근하는 설정을 진행할 겁니다. 

pem 파일은 AWS EC2 서버에 접속할 때 비밀번호 대신 사용하는 개인 키 파일입니다.

분실하거나 유출되면 서버에 무단 접근이 가능하므로 반드시 안전하게 보관해야 합니다.

 

WSL(Windows Subsystem for Linux)은 Windows에서 Linux 명령어를 그대로 실행할 수 있는 환경입니다.

필자는 Ubuntu를 사용했습니다. AWS 서버(Ubuntu)와 동일한 Linux 환경이기 때문에 SSH 접속 작업에 용이합니다.

 

pem 파일을 활용해 EC2 서버에 접속을 시도하는 과정에서 필요한 과정이 한 가지 있습니다. 

SSH는 보안상 이유로 다른 사람이 읽을 수 있는 키 파일로는 접속을 거부하기 때문에, chmod 400으로 소유자만 읽을 수 있도록 권한을 제한해야 합니다.

하지만 pem 파일을 Windows 경로(/mnt/c/)에 그대로 두면 chmod 권한 명령이 제대로 적용되지 않기 때문에 pem 파일을 WSL 내부 경로(~/.ssh/)로 복사한 뒤 권한을 제한해야 합니다. 

즉 [pem 파일 위치를 WSL 내부 경로로 이동 -> 소유자만 읽을 수 있도록 권한을 제한] 작업을 진행해야 합니다.

그 후 SSH 접속을 시도해보면 됩니다.

 

Bash — WSL

# pem 파일을 WSL 내부로 복사
cp /mnt/c/keys/[저장한 이름.pem] ~/.ssh/[저장한 이름.pem]
chmod 400 ~/.ssh/[저장한 이름.pem]

# SSH 접속
ssh -i "~/.ssh/[저장한 이름.pem]" ubuntu@[Elastic IP]

💡

Windows 계정명이 한글일 때

scp 경로에 한글이 포함되면 WSL에서 경로 인식 문제가 발생할 수 있습니다. 경로를 따옴표로 감싸서 사용하세요: "/mnt/c/Users/한글명/..."

4 STEP 2~4 : Java · MySQL · 디렉터리 설정

STEP 2 — Java 21 설치

서버에서 Spring Boot 애플리케이션을 실행하려면 서버에 Java(JDK)가 설치되어 있어야 합니다.

apt는 Ubuntu에서 소프트웨어를 설치하는 기본 패키지 관리자입니다.

apt update로 최신 패키지 목록을 받아온 뒤 JDK 21을 설치합니다.

 

Bash — EC2 서버

sudo apt update
sudo apt install -y openjdk-21-jdk
java -version

STEP 3 — MySQL 설치 및 DB 설정

MySQL을 설치하고, 애플리케이션 전용 데이터베이스와 계정을 별도로 생성합니다.

root 계정을 직접 사용하지 않고 전용 계정을 만드는 이유는, 권한을 최소화해 보안 사고 발생 시 피해 범위를 줄이기 위해서입니다.

 

Bash — EC2 서버

sudo apt install -y mysql-server
sudo mysql

MySQL에 접속되면 아래 명령을 순서대로 실행합니다.

utf8mb4는 한글과 이모지까지 저장할 수 있는 문자셋으로, 한국어 서비스라면 반드시 설정하는 것이 좋습니다.

 

SQL — MySQL 접속 후

CREATE DATABASE [DB명] CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER '[DB계정]'@'localhost' IDENTIFIED BY '비밀번호';
GRANT ALL PRIVILEGES ON [DB명].* TO '[DB계정]'@'localhost';
FLUSH PRIVILEGES;
EXIT;

STEP 4 — 업로드 디렉터리 생성

Spring Boot 애플리케이션에서 파일을 업로드할 때 저장할 경로를 서버에 미리 만들어 두어야 합니다.(파일업로드 기능이 있다면)

이 경로는 프로젝트 내의 파일업로드 경로와 반드시 일치해야 합니다. (필자는 /var/project/uploads/ministry로 설정했습니다.)

chown 명령으로 해당 폴더의 소유자를 ubuntu 계정으로 변경해야 애플리케이션이 파일을 정상적으로 저장할 수 있습니다.

 

Bash — EC2 서버

sudo mkdir -p /var/project/uploads/ministry
sudo chown -R ubuntu:ubuntu /var/project/uploads

5 STEP 5 : 서버 초기 설정 파일 준비

이 단계에서는 서버에 전송할 초기 설정 파일 2개를 로컬 프로젝트의 deploy/ 폴더 안에 준비할 겁니다.

프로젝트 내에 deploy 폴더를 만들고 해당 파일 2개를 생성하시면 됩니다. (폴더위치 및 폴더명을 바꾸셔도 상관없습니다.)

이 파일들이 무엇인지, 왜 필요한 지부터 짚고 넘어가겠습니다.

이 파일들이 왜 필요한가요?

EC2 서버는 처음 생성되면 완전히 빈 상태입니다.

Spring Boot 앱이 실행되려면 아래와 같은 환경을 직접 손으로 하나씩 구성해야 합니다.

 

수동으로 할 경우 — 명령어가 20줄 이상

sudo useradd -r -m -s /sbin/nologin [서비스명]
sudo mkdir -p /opt/[프로젝트명]
sudo chown [서비스명]:[서비스명] /opt/[프로젝트명]
sudo chmod 750 /opt/[프로젝트명]
sudo mkdir -p /var/[프로젝트명]/uploads
sudo chown -R [서비스명]:[서비스명] /var/[프로젝트명]
sudo mkdir -p /var/log/[프로젝트명]
... (이하 생략)

순서를 틀리거나 한 줄이라도 빠뜨리면 서비스가 실행되지 않습니다.

이 번거로운 과정을 해결하기 위해 init_server.sh와 project.service 파일을 미리 작성해두고, 서버에 전송 후 스크립트 하나만 실행해 모든 설정을 자동화합니다.

ℹ️

두 파일이 같은 폴더에 있어야 하는 이유

init_server.sh 내부에서 .service 파일을 자기 자신이 있는 폴더에서 찾아 systemd에 등록할겁니다. 두 파일이 같은 위치에 없으면 서비스 등록 단계가 실패하기 때문에 반드시 deploy/ 폴더 안에 함께 두어야 합니다.

① init_server.sh — 서버 초기 설정 자동화 스크립트

init_server.sh는 서버를 처음 세팅할 때 딱 한 번만 실행하는 스크립트입니다.

스크립트 상단의 변수 블록에서 프로젝트에 맞는 값을 지정하면, 이후 모든 설정이 그 값을 기준으로 자동으로 처리됩니다.

 

Shell — deploy/init_server.sh (상단 변수 블록만 수정하면 됩니다)

#!/usr/bin/env bash
# ============================================================
# Spring Boot 서버 최초 초기 설정 스크립트 (템플릿)
#
# 사용법:
#   1. 아래 [설정 변수] 섹션을 프로젝트에 맞게 수정
#   2. 서버에서 실행: sudo bash init_server.sh
#
# 이 스크립트는 서버를 처음 세팅할 때 딱 한 번만 실행합니다.
# 이후 배포는 deploy.sh 를 사용합니다.
#!/usr/bin/env bash
# ============================================================
# Spring Boot 서버 최초 초기 설정 스크립트 (템플릿)
#
# 사용법:
#   1. 아래 [설정 변수] 섹션을 프로젝트에 맞게 수정
#   2. 서버에서 실행: sudo bash init_server.sh
#
# 이 스크립트는 서버를 처음 세팅할 때 딱 한 번만 실행합니다.
# 이후 배포는 deploy-wsl.sh 를 사용합니다.
# ============================================================

set -euo pipefail

info()  { echo -e "\033[34m[INFO]\033[0m  $*"; }
ok()    { echo -e "\033[32m[OK]\033[0m    $*"; }

# ============================================================
# ★ 설정 변수 — 이 부분만 프로젝트에 맞게 수정하세요
# ============================================================
PROJECT_NAME="my-project"               # 서비스명 (계정명·디렉토리명에 사용됩니다)
APP_DIR="/opt/${PROJECT_NAME}"          # 앱 실행 디렉토리 (JAR 파일 위치)
UPLOAD_DIR="/var/${PROJECT_NAME}/uploads"  # 파일 업로드 저장 경로
LOG_DIR="/var/log/${PROJECT_NAME}"      # 로그 디렉토리
ENV_DIR="/etc/${PROJECT_NAME}"          # 환경변수 파일 디렉토리
SERVICE_FILE="${PROJECT_NAME}.service"  # systemd 서비스 파일명
# ============================================================

# 필자 변수 예시
#PROJECT_NAME="project"
#APP_DIR="/opt/project"
#UPLOAD_DIR="/var/project/uploads/ministry"
#LOG_DIR="/var/log/project"
#ENV_DIR="/etc/project"
#SERVICE_FILE="project.service"
# ============================================================


# ============================================================
# STEP 1. 전용 실행 계정 생성
# ============================================================
# -r : 시스템 계정으로 생성 (일반 로그인 불가)
# -s /sbin/nologin : SSH 직접 로그인 차단 (보안 강화)
info "STEP 1 — 전용 계정(${PROJECT_NAME}) 생성"
if id "${PROJECT_NAME}" &>/dev/null; then
    echo "  이미 존재함, 건너뜀"
else
    useradd -r -m -s /sbin/nologin "${PROJECT_NAME}"
    ok "계정 생성 완료"
fi

# ============================================================
# STEP 2. 필수 디렉토리 생성 및 권한 설정
# ============================================================
info "STEP 2 — 디렉토리 생성"

# 앱 실행 디렉토리 (JAR 파일이 위치할 경로)
mkdir -p "${APP_DIR}"
chown "${PROJECT_NAME}:${PROJECT_NAME}" "${APP_DIR}"
chmod 750 "${APP_DIR}"

# 파일 업로드 디렉토리
mkdir -p "${UPLOAD_DIR}"
chown -R "${PROJECT_NAME}:${PROJECT_NAME}" "/var/${PROJECT_NAME}"
chmod -R 755 "/var/${PROJECT_NAME}"

# 로그 디렉토리
mkdir -p "${LOG_DIR}"
chown "${PROJECT_NAME}:${PROJECT_NAME}" "${LOG_DIR}"
chmod 750 "${LOG_DIR}"

ok "디렉토리 생성 완료"

# ============================================================
# STEP 3. 환경변수 파일 초기화
# ============================================================
# 민감 정보(DB 비밀번호, API 키 등)를 소스코드와 분리해 관리합니다.
# chmod 600 으로 소유자만 읽을 수 있도록 보호합니다.
info "STEP 3 — 환경변수 파일 생성"
mkdir -p "${ENV_DIR}"

if [[ -f "${ENV_DIR}/env" ]]; then
    echo "  이미 존재함, 건너뜀 (기존 값 유지)"
else
    cat > "${ENV_DIR}/env" << 'EOF'
# 이 파일에 프로젝트에서 사용하는 환경변수를 입력하세요.
# 스크립트 실행 후 아래 명령으로 직접 편집합니다:
#   sudo nano /etc/[프로젝트명]/env
EOF
    chown "${PROJECT_NAME}:${PROJECT_NAME}" "${ENV_DIR}/env"
    chmod 600 "${ENV_DIR}/env"
    ok "환경변수 파일 생성: ${ENV_DIR}/env"
    echo ""
    echo "  !! 반드시 아래 파일을 열어 실제 값을 입력하세요 !!"
    echo "  sudo nano ${ENV_DIR}/env"
    echo ""
fi

# ============================================================
# STEP 4. systemd 서비스 등록
# ============================================================
# systemd 에 등록하면 서버 재부팅 시 자동으로 앱이 실행됩니다.
# 이 스크립트와 같은 폴더에 .service 파일이 있어야 합니다.
info "STEP 4 — systemd 서비스 등록"

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

if [[ -f "${SCRIPT_DIR}/${SERVICE_FILE}" ]]; then
    cp "${SCRIPT_DIR}/${SERVICE_FILE}" /etc/systemd/system/
    systemctl daemon-reload
    systemctl enable "${PROJECT_NAME}"  # 서버 재부팅 시 자동 시작 등록
    ok "서비스 등록 완료 (아직 시작하지 않음)"
else
    echo "  ${SERVICE_FILE} 파일을 찾을 수 없습니다."
    echo "  수동으로 /etc/systemd/system/ 에 복사 후 아래 명령을 실행하세요:"
    echo "  sudo systemctl daemon-reload && sudo systemctl enable ${PROJECT_NAME}"
fi

# ============================================================
# STEP 5. sudo 권한 설정
# ============================================================
# 전용 계정이 서비스 시작·정지·로그 조회만 할 수 있도록 권한을 제한합니다.
# 전체 sudo 권한을 주지 않아 보안 사고 발생 시 피해 범위를 최소화합니다.
info "STEP 5 — sudo 권한 설정"
SUDOERS_FILE="/etc/sudoers.d/${PROJECT_NAME}"

if [[ ! -f "$SUDOERS_FILE" ]]; then
    cat > "$SUDOERS_FILE" << EOF
# ${PROJECT_NAME} 계정이 서비스 제어 명령만 실행할 수 있도록 허용
${PROJECT_NAME} ALL=(ALL) NOPASSWD: /bin/systemctl start ${PROJECT_NAME}
${PROJECT_NAME} ALL=(ALL) NOPASSWD: /bin/systemctl stop ${PROJECT_NAME}
${PROJECT_NAME} ALL=(ALL) NOPASSWD: /bin/systemctl restart ${PROJECT_NAME}
${PROJECT_NAME} ALL=(ALL) NOPASSWD: /bin/journalctl -u ${PROJECT_NAME} *
EOF
    chmod 440 "$SUDOERS_FILE"
    ok "sudo 권한 설정 완료"
fi

# ============================================================
# 완료
# ============================================================
echo ""
echo "=============================================="
ok "서버 초기 설정 완료"
echo "=============================================="
echo ""
echo "다음 단계:"
echo "  1. 환경변수 파일에 실제 값 입력"
echo "     sudo nano ${ENV_DIR}/env"
echo ""
echo "  2. JAR 파일을 서버로 전송한 뒤 서비스 시작"
echo "     sudo systemctl start ${PROJECT_NAME}"
echo ""
echo "  3. 서비스 상태 확인"
echo "     sudo systemctl status ${PROJECT_NAME}"
echo "     sudo journalctl -u ${PROJECT_NAME} -f"

# ============================================================

변수를 설정하고 나면 스크립트가 아래 5단계를 순서대로 자동 실행합니다.

단계	하는 일	왜 필요한가
STEP 1	전용 실행 계정 생성	root 계정으로 앱을 실행하면 해킹 시 서버 전체가 위험합니다. 전용 계정은 서비스 제어 권한만 가져 피해 범위를 최소화합니다.
STEP 2	디렉토리 3개 생성 및 권한 설정	앱 실행 경로, 파일 업로드 경로, 로그 경로를 미리 만들고 전용 계정에 소유권을 부여합니다.
STEP 3	환경변수 파일 생성	DB 비밀번호·API 키 등 민감 정보를 소스코드 밖에서 관리합니다. chmod 600으로 소유자만 읽을 수 있게 보호됩니다.
STEP 4	systemd 서비스 등록	같은 폴더의 .service 파일을 systemd에 등록합니다. 서버 재부팅 시 앱이 자동으로 실행됩니다.
STEP 5	sudo 권한 최소화	전용 계정이 서비스 시작·정지·로그 조회만 할 수 있도록 권한을 제한합니다.

💡

이미 설정된 항목은 건너뜁니다

스크립트를 실수로 두 번 실행해도 괜찮습니다. 각 단계마다 이미 존재하는 항목은 자동으로 건너뛰도록 중복 체크가 되어 있어 기존 설정이 덮어씌워지지 않습니다.

② project.service — systemd 서비스 정의 파일

systemd는 Linux 서버에서 프로세스를 관리하는 시스템입니다.

JAR 파일을 서버에 올려놓는다고 해서 자동으로 실행되지 않습니다.

systemd에게 "이 앱을 어떻게, 어떤 조건으로 실행할 것인지"를 알려주는 설명서가 바로 .service 파일입니다.

이 파일을 systemd에 등록하면 이후 systemctl 명령으로 앱을 손쉽게 시작·정지·상태 확인할 수 있고, 서버가 재부팅될 때 앱도 자동으로 함께 실행됩니다.

 

INI — deploy/[프로젝트명].service

[Unit]
Description=[프로젝트 설명]
# MySQL이 먼저 뜬 뒤에 이 서비스를 시작한다 (부팅 순서만 보장)
After=network.target mysql.service
# (Requires로 묶으면 MySQL 재시작/자동 업데이트 시 이 서비스까지 동반 정지된다 — 주의)
Wants=mysql.service
# 5분 안에 5번 이상 재시작 실패하면 포기 (무한 재시작 루프 방지)
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
# ── 실행 계정 ──────────────────────────────────────────────
# init_server.sh STEP 1에서 생성한 전용 계정으로 실행한다
User=[서비스명]
Group=[서비스명]

# ── 환경변수 ───────────────────────────────────────────────
# init_server.sh STEP 3에서 생성한 환경변수 파일을 읽는다
EnvironmentFile=/etc/[프로젝트명]/env

# ── 실행 명령 ──────────────────────────────────────────────
WorkingDirectory=/opt/[프로젝트명]
ExecStart=/usr/bin/java \
    -Xms256m \
    -Xmx512m \
    -jar /opt/[프로젝트명]/app.jar \
    --spring.profiles.active=prod

# ── 재시작 정책 ────────────────────────────────────────────
# 예외 종료(OOM 등) 시 10초 후 자동 재시작
Restart=on-failure
RestartSec=10

# ── 종료 ───────────────────────────────────────────────────
# Spring Boot graceful shutdown을 위해 30초 대기
TimeoutStopSec=30
# SIGTERM(143) 정상 종료를 "실패"로 보지 않는다 (stop/restart 시 failed 오표기 방지)
SuccessExitStatus=143

# ── 로그 ───────────────────────────────────────────────────
# journalctl -u [프로젝트명] -f 명령으로 실시간 로그 확인 가능
StandardOutput=journal
StandardError=journal
SyslogIdentifier=[프로젝트명]

[Install]
# 서버 부팅 완료 단계에 자동 시작되도록 등록
WantedBy=multi-user.target

설정 항목 중 중요한 것들을 정리하면 아래와 같습니다.

항목	역할
After / Wants	MySQL을 먼저 띄우려 시도한 뒤 앱을 시작합니다(부팅 순서 보장). 단, MySQL이 나중에 재시작·업데이트돼도 앱은 끌려 내려가지 않고 계속 동작합니다. (과거엔 Requires로 묶여 있어 MySQL이 멈추면 앱도 동반 정지되는 문제가 있었음)
EnvironmentFile	DB 비밀번호·API 키를 소스코드가 아닌 별도 파일에서 읽어옵니다.
Restart=on-failure	앱이 오류로 종료되면 10초 후 자동으로 재시작합니다. 단, systemctl stop이나 의존성에 의한 정지처럼 의도된 종료에는 작동하지 않습니다.
SuccessExitStatus=143	SIGTERM(정상 종료 신호)으로 내려간 경우를 "실패"로 보지 않게 합니다. stop/restart 시 failed로 잘못 표시되는 것을 막아줍니다.
-Xms256m / -Xmx512m	JVM이 사용할 메모리 최솟값·최댓값입니다. t4g.small(2GB) 기준에 맞게 설정한 값입니다.
WantedBy=multi-user.target	서버 재부팅 시 자동으로 이 서비스가 시작됩니다.

⚠️

Ubuntu에서 MySQL 서비스명 주의

mysqld.service는 CentOS/RHEL 기준입니다. Ubuntu에서는 mysql.service로 작성해야 합니다. OS에 맞는 이름을 사용하지 않으면 서비스 등록 시 오류가 발생합니다.

deploy 폴더 최종 구조

두 파일을 모두 작성하면 deploy/ 폴더 구조는 아래와 같습니다.

다음 단계에서 이 폴더 전체를 scp로 서버에 전송한 뒤 init_server.sh를 실행할 예정입니다.

프로젝트 내에 deploy 폴더

 

프로젝트 폴더 구조

프로젝트 루트/
└── deploy/
    ├── init_server.sh          ← 서버 최초 초기 설정 스크립트 (1회 실행)
    └── [프로젝트명].service    ← systemd 서비스 정의 파일

잘못된 내용이 있다면 지적부탁드립니다. 방문해주셔서 감사합니다.