Spring Boot + AWS EC2 배포 흐름 완전 이해하기
배포를 처음 경험하면
GitHub, Jenkins, EC2, DB, 환경변수, properties 분리 등
용어와 구성들이 헷갈리기 마련이다.
이 글에서는 Spring Boot 프로젝트를 실제로 배포할 때 사용하는 흐름과 각 기술의 역할, 그리고 설정 파일 관리 방식까지 한 번에 정리한다.
1. 전체 아키텍처 흐름
배포 환경은 보통 아래 흐름으로 움직인다.
이미지 출처 : https://velog.io/@yb_engineer/Server-EC2-Docker-Deploy-with-Jenkins
[로컬 개발] → [Github push] → [Jenkins CI/CD] → [EC2 서버 배포 & 실행] → [사용자가 접속]
각 구성요소는 이런 역할을 한다:
구성 요소 역할 GitHub 소스 코드 저장소 Jenkins GitHub 코드를 자동 빌드 → JAR 생성 → EC2 서버에 자동 배포 EC2 서버 실제 Spring Boot 애플리케이션(JAR)이 실행되는 서버 Oracle DB (EC2 내부 또는 RDS) 애플리케이션이 연결하는 데이터베이스 설정 파일(properties, 환경변수) DB URL, 계정 정보, JWT key 등 외부 설정
2. EC2에 뭐가 올라가는가?
EC2 서버에는 다음이 올라간다:
✔ 1) Spring Boot JAR 파일
- Jenkins가 빌드해서 서버로 보내는 파일.
- 이 파일이 실제 웹 서비스 역할을 한다.
✔ 2) Oracle DB
-
직접 EC2에서 Oracle을 설치해서 쓸 수도 있고
-
AWS RDS(Oracle)를 따로 둘 수도 있다.
-
DB는 애플리케이션과는 별개의 서버/프로세스다.
✔ 3) 설정 파일(properties)
-
DB_URL, DB_USERNAME, JWT_SECRET 같은 민감한 정보는
configure.properties 같은 외부 파일에 따로 보관한다. -
EC2 서버 파일 시스템에 저장된다.
참고 : RDS 아키텍처
이미지 출처 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Welcome.html
3. 설정 파일을 분리하는 이유 (보안 + 유지보수)
“어차피 설정 파일과 JAR이 같은 서버에 있는데 분리하는 의미가 있나?”
이유 1) GitHub에 비밀번호가 올라가면 절대 안 됨
-
코드와 설정을 같이 두면 DB 비밀번호, JWT secret 등이 GitHub에 그대로 올라가게 된다 → 치명적 보안 문제.
-
따라서 properties는 GitHub에 두지 않고 서버 파일 시스템에만 둔다.
이유 2) 배포될 때마다 값 변경이 가능함
-
JAR은 매번 바뀌지만 DB URL, 비밀번호, JWT secret은 자주 바뀌지 않는다.
-
만약 설정이 하드코딩되어 있으면 설정 하나 바꾸려고 전체 애플리케이션을 다시 빌드해야 함.
-
외부 파일로 분리하면 설정만 수정하면 된다.
이유 3) 서버마다 설정을 다르게 적용 가능
로컬: oracle://localhost:1521/xe
개발 서버: oracle://dev-server:1521/ORCL
운영 서버: oracle://prod-server:1521/ORCL
- JAR은 동일해도 서버 환경만 다르면 설정을 다르게 줄 수 있다.
4. application.properties + configure.properties 구조
Spring Boot는 이런 형태로 properties를 불러오도록 할 수 있다:
✔ 로컬에서는
c:/springBootWorkspace/.../configure.properties✔ EC2 서버에서는
/usr/local/project/properties/configure.properties경로를 찾아 로드한다.
→ 이렇게 경로만 다르게 해서 같은 코드로 여러 환경에서 실행 가능.
application.properties 예시
configure.properties 예시 (EC2 서버에 위치)
5. DB URL의 localhost 문제
배포 시 localhost는 절대 기본값이 아님.
EC2 서버에서 Oracle이 같은 EC2 안에 설치된 경우에만 localhost 사용 가능.
✔ 상황 1) DB가 EC2 내부
- DB가 서버 내부에 있으면 localhost OK
✔ 상황 2) DB가 RDS(별도 서버)
-
이때는 localhost 쓰면 안 됨
-
RDS 엔드포인트를 써야 함
jdbc:oracle:thin:@my-rds.xxxxxx.ap-northeast-2.rds.amazonaws.com:1521/ORCL
6. 배포 자동화 전체 흐름 요약
- 개발자가 GitHub에 push
- Jenkins가 GitHub webhook으로 자동 감지
- Jenkins:
- 코드를 pull
- Gradle build → JAR 생성
- EC2 서버로 JAR 파일 복사
- 실행 중이던 Spring Boot 종료 후 다시 실행
- EC2 서버에서 JAR이 실행되며 웹 서비스가 동작
- DB와 설정 파일은 서버 파일 시스템에서 불러옴
배포 구성
JAR = 애플리케이션
EC2 = 실행되는 공간
DB = 별도의 데이터 저장소
properties = 민감한 설정
Jenkins = 빌드 & 배포 자동화
GitHub = 코드 저장소
🔹오늘의 나는 무엇을 잘했는지 (성취)
처음에는 배포 개념이 너무 복잡했지만, Jenkins–EC2–GitHub 관계를 흐름대로 정리하면서 전체 구조를 이해할 수 있었다.
🔹어떤 문제를 겪었고, 어떻게 해결할지 (개선)
EC2 안에 뭐가 들어가는지, properties는 왜 분리하는지 헷갈렸는데
그 구분을 단계별로 묶어서 정리하니 훨씬 명확해졌다.
내일은 배포 자료를 보면서 실제 EC2 경로에 파일을 배치하는 실습을 해볼 예정이다.
🔹오늘 배운 것 (학습)
배포는 단순히 JAR 파일 올리는 게 아니라
GitHub → Jenkins → EC2 → Spring Boot 실행까지
각 도구가 맡은 역할이 명확히 있다는 걸 배웠다.
🔹좋았던 점 & 아쉬웠던 점 (피드백)
배포 개념이 하나로 연결되어 이해되니 훨씬 부담이 줄었다.
하지만 아직 Jenkins 파이프라인 스크립트는 익숙하지 않아 추가 학습이 필요하다.
🔹나만의 팁 or 복습 방법
배포 과정을 그림으로 먼저 그리고,
각 단계를 “누가 → 무엇을 → 어디로 보내는가” 형태로 정리하면 훨씬 이해가 빨라진다.
