AWS Elastic Beanstalk를 활용한 Spring Boot 자동 배포: CodePipeline 연동 가이드

목차

 AWS Elastic Beanstalk, Spring Boot 자동 배포, CodePipeline 연동 – 이 세 가지 키워드로 대표되는 이번 가이드에서는 Spring Boot 애플리케이션을 AWS 클라우드에 자동 배포하는 방법을 단계별로 알아봅니다.

 GitHub 소스 변경을 AWS CodePipeline과 연동하여 코드 빌드(AWS CodeBuild) 및 AWS Elastic Beanstalk로의 배포까지 CI/CD 파이프라인을 구축하는 과정을 다뤄볼 것입니다. 또한 데이터베이스로 AWS RDS를 연동할 때 환경 변수 설정 방법, IAM 권한 구성, 배포 실패 시 트러블슈팅 팁 등 실무 경험에 기반한 노하우도 함께 공유합니다. 초급~중급 개발자를 위한 실용적인 기술 가이드로, Spring Boot 애플리케이션의 클라우드 배포 전략을 이해하고 직접 구성해 보세요.

 

※ 이전글

2025.07.29 - [IT 트렌드/알아두면 좋은 IT 상식] - Git 없이 S3로 구축하는 AWS DevOps 배포 파이프라인

Git 없이 S3로 구축하는 AWS DevOps 배포 파이프라인

2025.07.31 - [IT 트렌드/알아두면 좋은 IT 상식] - AWS CodePipeline에서 GitHub 연동 – 실무 후기 및 CI/CD 구축 가이드

AWS CodePipeline에서 GitHub 연동 – 실무 후기 및 CI/CD 구축 가이드

 

AWS Elastic Beanstalk 개요 및 장단점

AWS Elastic Beanstalk는 애플리케이션 배포를 간소화해 주는 AWS의 PaaS(platform as a service) 서비스입니다. 복잡한 서버 인프라를 일일이 구성하지 않고도 코드를 업로드하면, Elastic Beanstalk가 알아서 EC2 인스턴스, 로드 밸런서, 오토스케일링 그룹 등 필요한 인프라 자원들을 자동으로 프로비저닝 하고 애플리케이션을 배포해 줍니다. 마치 Heroku와 유사하게 개발자는 코드에 집중하고, 환경 구성과 운영은 Beanstalk이 도와주는 셈이죠.

• 주요 장점: Elastic Beanstalk의 가장 큰 장점은 배포와 운영의 간편함입니다. 개발자는 애플리케이션 배포 패키지만 준비하면, 서버 설정이나 OS 관리 없이도 손쉽게 배포할 수 있습니다. Beanstalk이 EC2, 로드밸런서, Auto Scaling 등을 자동으로 구성해 주므로 인프라 관리 부담이 크게 줄어듭니다. 또한 AWS의 다른 서비스와도 긴밀하게 연계되어 RDS, S3, CloudWatch 등과 통합된 환경을 제공합니다. 필요에 따라 자동 스케일링으로 트래픽 변화에 대응할 수 있고, 버전 관리 및 롤백 기능을 통해 배포 이력을 관리하며, 새로운 플랫폼 업데이트도 자동 적용 옵션이 있어 최신 환경을 유지하기 수월합니다. 무엇보다 Elastic Beanstalk 자체는 별도의 비용이 들지 않고, 사용자는 EC2 인스턴스 등의 자원 비용만 부담하면 되므로 (프리 티어 내에서는 추가 비용 없이 시작 가능) 진입장벽이 낮습니다.
• 주요 단점: 편리함의 이면에는 제한된 유연성과 벤더 종속성의 단점도 있습니다. Beanstalk는 미리 제공되는 환경설정에 맞춰 동작하기 때문에, 세부적으로 인프라나 미들웨어를 커스터마이징해야 하는 시나리오에서는 제약이 있습니다. 애플리케이션이 Beanstalk의 제약에 맞도록 구조를 바꿔야 할 수도 있고, 로컬에서 임의로 수정한 서버 설정은 새 배포 시 초기화되는 등 세밀한 제어가 어렵습니다. 또한 AWS 환경에 종속되기 때문에 벤더 lock-in 우려도 있으며, 추후 다른 플랫폼으로 이식하기가 까다로울 수 있습니다. 배포 과정이 단순화되어 있는 만큼 문제 발생 시 트러블슈팅이 복잡할 수 있고, 배포 속도가 느리다는 의견도 있습니다. 마지막으로 Elastic Beanstalk 서비스 자체는 무료지만 하위 자원의 비용(EC2, RDS 등)은 지속 발생하므로, 필요 이상으로 큰 리소스를 사용하지 않도록 비용 관리에 신경 써야 합니다.

요약: Elastic Beanstalk는 Spring Boot와 같은 애플리케이션을 손쉽게 클라우드에 올릴 수 있는 매니지드 배포 서비스입니다. 배포 자동화와 인프라 관리 간소화라는 큰 이점이 있지만, 세밀한 설정의 제약과 AWS 종속이라는 단점도 있으므로 요구사항에 맞게 활용하는 것이 중요합니다.

Spring Boot 애플리케이션 배포 환경 설정 (Elastic Beanstalk)

이제 Spring Boot 애플리케이션을 Elastic Beanstalk에 배포하기 위한 환경을 설정해 보겠습니다. 먼저 Spring Boot 애플리케이션의 패키징부터 준비해야 합니다. 일반적으로 Spring Boot는 실행 가능한 JAR로 패키징 하며, 이는 자체적으로 임베디드 서버(Tomcat 등)를 포함하므로 WAR 파일보다 간편합니다. Maven이나 Gradle로 프로젝트를 빌드하여 *.jar 파일을 생성해 둡니다 (예: mvn clean package -DskipTests). 이 JAR 파일이 곧 Elastic Beanstalk에 업로드될 배포 아티팩트입니다.
- Environment tier : Web server environment
- Application information : MySpringBootAppEB
- Environment information : MySpringBootAppEB-env
- Platform : Managed platform (Java + Correto 21 + Platform 4.6.1)
- Application code : Sample application (나중에 덮어 쓰일 예정)
- Presets : Single instance (free tier eligible) (테스트 목적이기 때문에)

Elastic Beqanstalk - 구성화면

이어서 AWS Management Console에서 Elastic Beanstalk 환경(Environment)을 생성합니다. 새 애플리케이션을 생성하고 환경 타입은 "웹 서버 환경"으로 선택합니다. 플랫폼은 "Java"를 선택하고, Java 버전은 애플리케이션에 맞는 Corretto(OpenJDK) 런타임을 고릅니다 (예: Corretto 17 on Amazon Linux 2 등). 플랫폼을 Java로 지정하면 Spring Boot JAR 파일을 직접 실행하는 환경이 구성됩니다. (만약 Spring Boot를 WAR로 배포한다면 Tomcat 플랫폼을 선택해 WAR를 배포할 수도 있지만, 여기서는 JAR 배포를 가정합니다.) 애플리케이션 코드는 일단 "Sample Application(샘플 애플리케이션)"으로 설정하고 진행합니다. 이후 CodePipeline을 통해 실제 빌드 산출물이 배포되면서 이 샘플 코드는 덮어씌워질 예정입니다.

 

환경 구성 단계: 환경 생성 마법사에서 EC2 인스턴스 유형, 키 페어, 용량(Capacity) 등을 설정합니다. 테스트 용도로는 프리 티어(Free Tier)에 해당하는 작은 인스턴스(t2.micro 등)와 단일 인스턴스 환경을 선택하면 충분합니다. 서비스 역할(Service role)과 EC2 인스턴스 프로파일(Instance profile)은 기본값을 사용하면 됩니다. Elastic Beanstalk 초기 세팅 시, aws-elasticbeanstalk-service-role이라는 서비스 IAM 역할과 aws-elasticbeanstalk-ec2-role이라는 EC2용 IAM 역할을 생성하라는 옵션이 있는데, 둘 다 기본 값을 선택하면 AWS에서 관리형 권한이 부여된 역할이 자동으로 설정됩니다. (이들은 Elastic Beanstalk 환경이 내부적으로 AWS 자원을 만들고 관리하는 데 필요한 권한을 갖습니다.)

 

※ aws-elasticbeanstalk- service-role

IAM Role - aws-elasticbeanstalk- service-role

 

※ aws-elasticbeanstalk- service-role

IAM Role - aws-elasticbeanstalk- service-role

 

Elastic Beanstalk - Configuration

 

네트워킹은 기본 VPC와 서브넷을 사용하거나 필요에 따라 구성하며, RDS 등 데이터베이스를 함께 생성할 계획이라면 같은 VPC에 두어야 추후 통신이 가능합니다. 모든 설정을 마치고 환경 생성을 시작하면, Elastic Beanstalk가 해당 구성대로 EC2 인스턴스 등을 프로비저닝 하고 애플리케이션을 배포합니다. 수 분 정도 소요된 뒤 환경 상태(Health)가 OK로 표시되면 준비 완료입니다.

포트 설정 주의: Amazon Linux 2 기반의 Elastic Beanstalk Java 플랫폼은 내부에 Nginx 프록시를 두고 포트 5000으로 트래픽을 라우팅 합니다. 따라서 기본적으로 Spring Boot 앱은 포트 5000에서 동작해야 Elastic Beanstalk의 헬스 체크를 통과합니다. Spring Boot의 기본 포트(8080)를 그대로 사용하면 502 Bad Gateway 오류가 발생할 수 있으므로, 서버 포트를 5000으로 변경해야 합니다. 방법으로는 애플리케이션의 application.properties에 server.port=5000을 설정하거나, Elastic Beanstalk 환경 변수로 SERVER_PORT=5000을 지정할 수 있습니다. 이렇게 하면 Spring Boot 애플리케이션이 포트 5000에서 구동되어 정상적으로 요청을 받을 수 있습니다.

Elastic Beanstalk Java 플랫폼

CodePipeline 연동으로 CI/CD 파이프라인 구축

이제 지속적 통합/배포(CI/CD)를 실현하기 위해 AWS CodePipeline을 구성해 보겠습니다. CodePipeline은 소스 코드의 변경을 감지하여 자동으로 빌드 및 배포 과정을 실행해 주는 AWS 서비스입니다. 우리가 만들 파이프라인은 다음과 같은 3단계로 구성됩니다:

1. Source (소스 단계): GitHub 저장소의 지정된 브랜치에 코드 변경이 푸시되면 CodePipeline이 이를 감지합니다. GitHub 연동을 위해 AWS 콘솔에서 CodePipeline 설정 시 GitHub 연결(AWS CodeStar Connections)을 구성해야 합니다. 또는 AWS CodeCommit을 소스로 사용할 수도 있습니다. 여기서는 예시로 GitHub의 main 브랜치를 모니터링한다고 가정하겠습니다.
2. Build (빌드 단계): 소스 변경 감지 후 AWS CodeBuild가 트리거 됩니다. CodeBuild는 앞서 준비한 Spring Boot 프로젝트를 빌드하여 JAR 파일을 생성하는 역할을 합니다. CodeBuild 프로젝트를 생성하고, 빌드 사양(buildspec) 파일을 설정해야 합니다. 예를 들어 프로젝트 루트에 buildspec.yml 파일을 만들어 아래와 같이 명시할 수 있습니다:
   
   

version: 0.2
phases:
  install:
    runtime-versions:
      java: corretto21    # Java 런타임 (Corretto 17 사용 예시)
  build:
    commands:
      - ./mvnw clean package -DskipTests   # Maven으로 JAR 빌드 (테스트 생략)
      - ls target/*.jar && echo "Build success"
artifacts:
  files:
    - target/*.jar

 

1. 위 내용은 Maven Wrapper(./mvnw)를 이용해 패키징을 수행한 후, target 디렉터리의 JAR 파일을 아티팩트로 지정하는 예시입니다. CodeBuild가 빌드를 마치면 결과물(JAR)이 파이프라인을 통해 배포 단계로 전달됩니다. (프로젝트 구조나 필요에 따라 빌드 명령을 조정하세요. Gradle 사용 시 ./gradlew build 등으로 변경합니다.)
2. Deploy (배포 단계): 파이프라인의 마지막 단계에서는 AWS Elastic Beanstalk로 배포가 이루어집니다. CodePipeline 설정 시 Deploy 단계를 추가하고, 배포 제공자(Provider)로 "AWS Elastic Beanstalk"를 선택합니다. 여기서 대상 애플리케이션 이름과 환경 이름을 지정하면, CodePipeline이 해당 EB 환경에 새로운 애플리케이션 버전을 생성 및 배포해 줍니다. 구체적으로는 CodePipeline이 앞 단계의 JAR 아티팩트를 S3에 업로드하고, Elastic Beanstalk에 새 버전으로 등록한 뒤 환경을 업데이트하는 식입니다. 이때 CodePipeline의 역할(Role)이 Elastic Beanstalk에 배포할 수 있는 권한을 가지고 있어야 합니다 (아래 IAM 설정 참고). 배포 단계까지 모두 설정하고 파이프라인을 생성하면, 전체 흐름은 다음과 같습니다:
3. 배포 파이프라인 흐름: 개발자가 GitHub의 메인 브랜치에 코드를 푸시 → CodePipeline이 변경을 감지하여 실행 → CodeBuild에서 애플리케이션을 빌드하여 JAR 생성 → 배포 단계에서 Elastic Beanstalk 환경으로 JAR 자동 배포 → 몇 분 내에 새로운 버전의 Spring Boot 애플리케이션이 구동됨.

 CodePipeline 실행 예시: 모든 구성이 완료되었다면 실제로 변경을 커밋(push)하여 파이프라인을 동작시켜 볼 수 있습니다. 새로운 커밋이 발생하면 파이프라인 실행이 시작되고, 콘솔의 CodePipeline 화면에서 Source → Build → Deploy 단계를 거쳐 성공 (Succeeded) 상태가 되는 것을 확인할 수 있습니다. Elastic Beanstalk 콘솔로 가서 해당 환경의 이벤트 로그를 보면 새로운 애플리케이션 버전이 배포되었음을 알 수 있습니다.

Code Pipeline - Flow

 또한 배포한 애플리케이션의 URL (예: http://<환경이름>.<region>.elasticbeanstalk.com)에 접속해 정상 동작 여부를 테스트합니다. 데이터베이스 연동까지 했다면 간단한 API 호출이나 페이지 접속을 통해 DB CRUD 동작도 확인해 보세요. 배포 파이프라인을 한 번 구축해 두면, 이후에는 코드 수정 → Git 푸시만으로 Spring Boot 애플리케이션이 자동 배포되는 편리함을 얻을 수 있습니다.

git add .
git commit -m 'EB Deploy'
git push origin main

 

 

RDS 연동을 위한 환경 변수 설정

실제 웹 애플리케이션에서는 데이터베이스 연동이 필수적이므로, AWS RDS(Relational Database Service)와 Spring Boot 애플리케이션을 연결하는 방법을 알아보겠습니다. Elastic Beanstalk는 환경 변수(Environment Properties)를 활용하여 애플리케이션에 구성 값을 주입할 수 있습니다. 데이터베이스 연결 정보(예: DB URL, 사용자, 비밀번호)를 코드에 하드코딩하는 대신, EB의 환경 변수로 설정해 두고 애플리케이션에서 이를 참조하도록 하는 것이 안전하고 편리합니다.

 

1) RDS 인스턴스 설정: RDS 데이터베이스는 EB 환경과 통합해서 생성하거나, 외부에 별도로 생성할 수 있습니다. EB 환경 생성 시 Database 옵션을 통해 RDS 인스턴스를 함께 만들었다면, 해당 환경에 자동으로 DB가 연결됩니다. 이 경우 Elastic Beanstalk가 DB 호스트이름, 포트, 사용자명, 비밀번호, DB 이름 등을 환경 변수로 자동 설정해 줍니다. 예를 들어 RDS_HOSTNAME, RDS_PORT, RDS_USERNAME, RDS_PASSWORD, RDS_DB_NAME 등의 변수가 환경에 추가되고, 여기에 RDS 접속 정보가 담깁니다. 이는 EB가 애플리케이션에 DB 접속 정보를 전달하는 방식으로, 애플리케이션이 이러한 환경 변수를 읽어 DB에 연결하면 됩니다.

Spring Boot는 다음과 같은 우선순위로 설정을 로드합니다 (높은 순서대로): 

1. 환경 변수 (가장 높은 우선순위)
2. 명령줄 인수

3. JAR 파일 외부의 application.properties
4. JAR 파일 내부의 application.properties

 

만약 이미 별도로 생성한 RDS 인스턴스가 있고 EB 환경에 수동으로 연동해야 한다면, EB 콘솔의 Configuration -> Software(소프트웨어) 설정에서 Environment properties(환경 속성) 항목을 편집하여 직접 변수를 추가하면 됩니다. 예를 들어 Spring Boot의 데이터소스 프로퍼티에 맞게 아래와 같은 변수들을 설정할 수 있습니다:

• SPRING_DATASOURCE_URL: jdbc:postgresql://<RDS_ENDPOINT>:5432/<RDS_DB_NAME>
• SPRING_DATASOURCE_USERNAME : <DB_계정명>
• SPRING_DATASOURCE_PASSWORD : <DB_비밀번호>

Elastic Beanstalk - Environment properties

위와 같이 환경 변수를 등록해 두면, Spring Boot는 실행 시 해당 값을 읽어 자동으로 데이터소스에 적용합니다. (Spring Boot 2.x 이상에서는 SPRING_DATASOURCE_URL 등 환경 변수 이름을 스프링 설정으로 자동 매핑해 주므로 application.properties에 별도 설정 없이도 동작합니다. 필요시 명시적으로 spring.datasource.url=${SPRING_DATASOURCE_URL} 형태로 속성을 연결할 수 있습니다.)

2) 애플리케이션 설정: 애플리케이션 쪽에서는 위 환경 변수들을 활용하도록 구성하면 됩니다. 보통 application.properties 또는 application.yml에서 DB 연결 설정을 할 때, 값을 직접 쓰는 대신 환경 변수 참조를 사용합니다. 예를 들어 properties 파일에서:

spring.datasource.url=${SPRING_DATASOURCE_URL}
spring.datasource.username=${SPRING_DATASOURCE_USERNAME}
spring.datasource.password=${SPRING_DATASOURCE_PASSWORD}
spring.jpa.hibernate.ddl-auto=update
# spring.jpa.database-platform=org.hibernate.dialect.MySQL8Dialect
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

 

이런 식으로 해두면, EB에서 설정한 환경 변수 값들이 자동 주입되어 DB 연결이 이루어집니다. (Hibernate Dialect 등 추가 설정은 사용하는 DB 종류에 맞게 지정합니다.) 중요: 데이터베이스 비밀번호와 같은 민감 정보는 절대 코드나 깃 저장소에 노출되지 않도록 하고, 반드시 환경 변수나 AWS Secrets Manager 등을 사용해 관리해야 합니다. Elastic Beanstalk 환경 변수는 콘솔에서도 암호화되어 표시되므로 기본적인 보안은 확보해 줍니다.

Codepipeline - Add Stage

- 작업 이름(Action name): Deploy (원하는 이름)
- 작업 공급자(Action provider): AWS Elastic Beanstalk을 선택합니다.
- 리전(Region): Elastic Beanstalk 환경을 생성한 리전과 동일하게 설정합니다.
- 입력 아티팩트(Input artifacts): BuildArtifact를 선택합니다. (이 이름은 여러분의 Build 단 계에서 생성되는 아티팩트의 이름이어야 합니다. 보통 BuildArtifact 또는 MyBuildOutput과 같 은 기본값입니다. Build 단계의 출력 아티팩트(Output artifacts) 이름을 확인하세요.)
- 애플리케이션 이름(Application name): 1단계에서 사용한 Elastic Beanstalk 애플리케이션 이름을 선택합니다. (예: MySpringBootAppEB)
- 환경 이름(Environment name): 1단계에서 사용한 Elastic Beanstalk 환경 이름을 선택합니 다. (예: my-spring-boot-app-env)

 

3) VPC 및 보안: EB 환경의 EC2 인스턴스와 RDS가 동일한 VPC 및 서브넷 내에 있어야 통신이 가능합니다. EB 환경 생성 시 VPC와 서브넷을 RDS와 일치시키고, RDS의 보안 그룹에서 EB 인스턴스의 보안 그룹 혹은 IP에 대한 접근을 허용해야 합니다. 만약 EB 환경과 RDS가 통신 불가한 상태이면 애플리케이션이 DB에 연결하지 못해 오류가 발생하므로, 네트워크 구성을 꼭 확인하세요.

IAM Role 설정 및 권한 구성

CI/CD 파이프라인과 Elastic Beanstalk를 연동할 때는 AWS 리소스 간 권한 부여가 올바르게 되어야 합니다. IAM Role(역할) 설정의 핵심 포인트는 각 서비스가 다른 서비스를 호출할 수 있는 권한을 갖는 것입니다. 이번 시나리오에서 등장하는 주요 IAM 역할과 권한 요구사항은 다음과 같습니다:

• CodePipeline 서비스 역할: CodePipeline 자체의 실행을 담당하는 IAM 역할로, 파이프라인 생성 시 지정됩니다. 이 역할은 파이프라인이 CodeBuild를 호출하고 배포 작업(Elastic Beanstalk)을 수행할 수 있도록 권한이 필요합니다. 일반적으로 AWSCodePipelineFullAccess 정책이나, 최소한 CodePipeline이 사용하는 CodeBuild 실행 및 EB 배포 관련 권한을 부여해야 합니다. 예를 들어 Elastic Beanstalk에 배포하려면 elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment 등의 권한이 필요합니다. 실제로 권한이 없을 경우 CodePipeline 배포 단계에서 “Provided role does not have the elasticbeanstalk:CreateApplicationVersion permission” 오류가 발생합니다. 이런 오류가 나면 해당 IAM 역할에 AWSElasticBeanstalkFullAccess 정책 등을 연결하여 권한을 추가하면 해결됩니다.
• CodeBuild 서비스 역할: CodeBuild 프로젝트 생성 시 새 IAM 역할을 만들거나 기존 역할을 사용할 수 있습니다. 이 역할은 CodeBuild가 소스 코드를 가져오고 빌드하며 S3 등에 아티팩트를 업로드하는 데 필요한 권한을 가집니다. 예를 들어 S3 버킷 읽기/쓰기 권한, ECR(컨테이너 이미지 빌드 시), 또는 기타 필요 자원 접근 권한 등을 포함합니다. Spring Boot 빌드만 하는 경우 기본 AWSCodeBuildAmazonS3ReadOnlyAccess, AWSCodeBuildDeveloperAccess 등의 정책으로 충분하지만, 추가로 GitHub 연동을 위한 OIDC 권한은 AWS가 연결 시 자동 처리합니다. 빌드 과정에서 혹시 다른 AWS 자원(DB 접근 등)이 필요하면 해당 권한도 이 역할에 부여해야 합니다.
• Elastic Beanstalk EC2 역할(인스턴스 프로파일): 이는 EB 환경을 구성할 때 EC2 인스턴스에 자동으로 연결되는 IAM 역할입니다. 기본값인 aws-elasticbeanstalk-ec2-role에는 EC2에서 애플리케이션이 동작하는 데 필요한 권한들이 포함됩니다. 예를 들어 소스 번들을 다운로드하기 위한 S3 읽기 권한, 로그를 업로드하는 CloudWatch Logs 권한 등이 있습니다. 기본 역할을 사용했다면 이러한 권한은 이미 설정되어 있지만, 필요에 따라 추가 리소스 접근(예: 애플리케이션이 S3나 SQS 등을 사용해야 하는 경우)이 있다면 해당 IAM 역할에 정책을 추가해야 합니다.
• Elastic Beanstalk 서비스 역할: EB 환경 생성 시 함께 구성된 aws-elasticbeanstalk-service-role은 Elastic Beanstalk 서비스가 환경을 관리하면서 AWS 리소스에 접근할 수 있게 해주는 역할입니다. 여기에 필요한 권한은 EB 설정 시 자동으로 부여되므로 보통 신경 쓸 필요는 없습니다. 다만, EB 환경에 AWS X-Ray나 CloudWatch 알람 등을 사용하는 설정을 켜면 추가 권한이 요구될 수 있습니다.

정리하면: CodePipeline 역할에는 CodeBuild 실행 및 EB 배포 권한, CodeBuild 역할에는 빌드 및 아티팩트 업로드 권한, EB EC2 역할에는 애플리케이션 구동에 필요한 자원 접근 권한을 갖도록 해야 합니다. AWS 콘솔 Wizard를 통해 설정하면 대부분 자동으로 구성되지만, 배포 실패 시 IAM 권한 문제를 로그로 확인하고 누락된 권한을 추가로 할당하는 디버깅이 필요할 수 있습니다. 보안상 최소 권한의 원칙을 따르는 것이 좋으나, 초기 설정 단계에서는 편의를 위해 Administrator 권한을 부여하고 나중에 필요 권한만 남기는 방식도 종종 활용됩니다.

배포 실패 사례 및 트러블슈팅 팁

실제로 AWS 기반 자동 배포 파이프라인을 처음 구축하면, 한두 번의 시행착오를 겪을 수 있습니다. 흔히 발생하는 배포 실패 시나리오와 원인, 그리고 대응 방법을 몇 가지 짚어보겠습니다:

• Case 1: CodePipeline 배포 단계 실패 (권한 오류) – CodePipeline의 Deploy 단계에서 Elastic Beanstalk 업데이트에 실패하면서 Access Denied 오류가 발생하는 경우가 있습니다. 앞서 언급했듯 elasticbeanstalk:CreateApplicationVersion 등의 권한 부족으로 인한 문제입니다. 대응: CodePipeline의 서비스 역할에 AWSElasticBeanstalkFullAccess 또는 해당 액션에 대한 권한을 가진 정책을 연결하고, 파이프라인을 재시도합니다. 권한 수정 후에는 파이프라인을 재실행(re-run)하거나 커밋을 다시 트리거하여 정상 동작을 확인합니다.
• Case 2: CodeBuild 빌드 실패 – CodeBuild 단계에서 Maven/Gradle 빌드가 실패하거나, 빌드는 성공했지만 아티팩트가 생성되지 않았다는 오류가 날 수 있습니다. 원인: buildspec.yml 설정 오류, 빌드 명령어 오류, 또는 CodeBuild 환경 세팅 문제 등이 있습니다. 대응: CodeBuild의 빌드 로그를 확인하여 실패 원인을 파악합니다. Maven 리포지토리 다운로드 문제라면 인터넷 접근(VPC 설정)을 점검하거나 캐시를 활용할 수 있고, 빌드 명령어 오타나 경로 문제는 buildspec을 수정해야 합니다. 또한 buildspec의 artifacts 경로가 실제 생성된 JAR 이름과 일치하는지 확인하세요. 예를 들어 출력 파일명이 app.jar인데 target/*.jar로 잡았다면 인식 못할 수 있습니다. 경로를 정확히 지정하거나 wildcard를 올바로 사용합니다. 빌드 시간 초과로 실패한다면 CodeBuild 프로젝트의 타임아웃 설정을 늘려야 합니다.
• Case 3: Elastic Beanstalk 배포 후 애플리케이션 오류 – 파이프라인은 성공했지만 정작 EB 환경에서 애플리케이션이 제대로 구동되지 않아 상태가 Severe로 바뀌거나 HTTP 502/504 에러가 나는 경우입니다. 원인: 애플리케이션 실행 실패 또는 헬스 체크 실패입니다. 일반적인 원인은 포트 미스매치(앞서 언급한 5000 vs 8080 문제), 환경 변수 미설정, 잘못된 DB 설정으로 인한 애플리케이션 예외 등입니다. 대응: Elastic Beanstalk 로그를 확인해 보는 것이 첫걸음입니다. EB 콘솔의 Logs 메뉴에서 애플리케이션 로그를 가져와 보세요. 예를 들어 로그에 org.hibernate.HibernateException: Unable to determine Dialect와 같은 에러가 있다면, DB 연결이 안 되어 Hibernate가 Dialect를 추론하지 못한 상황일 수 있습니다 (혹은 Dialect 미설정). 이 경우 DB 환경 변수 설정, 시큐리티 그룹 등을 재검토하고 애플리케이션 설정에서 Dialect를 지정하는 등 문제를 해결해야 합니다. 포트 문제라면 SERVER_PORT 설정 유무를 점검하세요. 수정 후 새로운 버전을 배포하거나 환경을 업데이트하면 됩니다.
• Case 4: 기타 EB 환경 이슈 – 가끔 EB 환경 자체의 제약으로 배포가 실패하는 경우도 있습니다. 예를 들어 아티팩트 크기가 500MB를 넘으면 배포 제한에 걸린다든지, 플랫폼 버그로 인해 특정 설정이 적용 안 된다든지 하는 상황입니다. 대응: 이러한 경우는 비교적 드물지만, AWS Elastic Beanstalk FAQ나 AWS Forum(re:Post)에서 유사 사례를 찾아보는 것이 도움 됩니다. 필요한 경우 EB 플랫폼 업데이트를 하거나, 아티팩트를 슬림화(JAR 경량화)하는 방안을 고려합니다.
• Case 5: 성능 및 자동 확장 문제 – 배포는 성공했지만 한 인스턴스로 감당 못 할 만큼 트래픽이 증가하는 경우에는 성능 문제가 생길 수 있습니다. 대응: Elastic Beanstalk Auto Scaling 설정을 통해 인스턴스 수를 자동 조정하거나, 인스턴스 타입을 업그레이드하는 등의 조치를 취해야 합니다. 이러한 튜닝은 운영 단계에서 모니터링을 통해 지속적으로 개선해야 합니다.

트러블슈팅 팁: 문제 상황이 발생하면 어느 단계에서 오류가 났는지에 따라 접근해야 합니다. CodePipeline 콘솔에서 각 단계의 상태와 에러 메시지를 먼저 확인하고, CodeBuild 문제는 Build 로그로, Beanstalk 문제는 EB 환경 이벤트 및 로그로 파고들어 갑니다. AWS 각 서비스의 CloudWatch 로그나 모니터링 지표를 활용하면 원인 분석에 도움이 됩니다. 그리고 IAM 권한 오류처럼 자주 실수하는 부분은 앞서 설정을 다시 한번 점검해 보세요. 초기에는 시행착오가 있지만 한번 설정이 완료되고 나면 이후 배포는 자동화되어 개발 효율이 크게 향상될 것입니다.

Spring Boot 애플리케이션을 CodePipeline으로 빌드/배포하여 Elastic Beanstalk에 배포한 후 웹 애플리케이션이 정상 구동된 모습 (예시 화면). 파이프라인 설정이 올바르게 이루어지면 코드 푸시 후 애플리케이션이 자동으로 업데이트되어 서비스됩니다.

마무리 및 다음 단계 (Call to Action)

지금까지 AWS Elastic Beanstalk를 활용한 Spring Boot 자동 배포 방법을 살펴보았습니다. 요약하면, CodePipeline 연동을 통해 코드 변경부터 자동 빌드 및 Elastic Beanstalk 배포까지 일련의 CI/CD 파이프라인을 구축하여, Spring Boot 애플리케이션을 신속하고 반복적으로 배포할 수 있습니다. AWS Elastic Beanstalk의 간편함 덕분에 복잡한 서버 관리 없이도 애플리케이션 운영에 집중할 수 있고, 자동화된 파이프라인으로 개발 생산성을 크게 높일 수 있습니다.

이제 여러분의 프로젝트에 이번 가이드 내용을 적용해 보세요. 작은 테스트 프로젝트를 만들어 CodePipeline과 Elastic Beanstalk 환경을 실제로 구성해 보는 것을 권장합니다. 직접 경험해 보면 설정 과정의 감각을 익히고, 나아가 회사나 개인 프로젝트의 배포 파이프라인을 개선하는 데 큰 도움이 될 것입니다. 클라우드 인프라와 CI/CD에 익숙해질수록 더 빠르고 안정적인 소프트웨어 제공이 가능해집니다.

마지막으로, 이 글이 AWS 기반 Spring Boot 배포에 대한 궁금증을 해소하고 도움이 되었다면 주변에 공유해 주시기 바랍니다. 댓글로 여러분의 경험이나 추가 질문을 남겨주시면 답변드리거나 토론해 보겠습니다. 지금 바로 AWS에서 Spring Boot 자동 배포 파이프라인을 구축하여 클라우드 배포의 편리함을 직접 체험해 보세요! Happy Deployments! 🚀

FAQ: AWS Elastic Beanstalk와 Spring Boot 자동 배포

Q1. AWS Elastic Beanstalk를 쓰는 것과 EC2에 직접 배포하는 것의 차이는 무엇인가요?
A. Elastic Beanstalk는 인프라 관리 작업을 자동화해 주는 관리형 서비스이고, EC2 직접 배포는 사용자가 모든 서버 설정을 수동으로 관리하는 방식입니다. Beanstalk를 사용하면 코드만 업로드하면 되도록 배포/스케일링/모니터링이 자동화되어 개발 생산성이 높아집니다. 반면 EC2 수동 배포는 설정의 유연성과 세밀한 제어가 가능하지만, 초기 세팅과 유지보수에 더 많은 시간이 듭니다. 또한 Beanstalk 환경은 AWS에 최적화되어 있어 RDS, S3 등과 원활한 통합이 장점입니다. 다만 Beanstalk는 커스텀 설정의 제약이 있고 AWS 종속이 발생한다는 점에서, 요구사항에 따라 EC2 직접 관리와 비교해 장단점을 고려해야 합니다.

Q2. AWS CodePipeline 대신 GitHub Actions 등 다른 CI/CD 도구를 사용해도 되나요?
A. 물론입니다. GitHub Actions, Jenkins, GitLab CI 등 다양한 CI/CD 툴로도 AWS에 배포 파이프라인을 구축할 수 있습니다. 다만 CodePipeline은 AWS 서비스들과의 연동이 매끄럽게 통합되어 있다는 강점이 있습니다. 예를 들어 CodePipeline을 쓰면 별도 자격증명 관리 없이 AWS IAM 역할 기반으로 CodeBuild, Beanstalk 등을 바로 사용할 수 있고, GUI로 배포 단계를 구성하기 편리합니다. GitHub Actions을 사용할 경우 AWS에 배포하려면 AWS 자격증명(Access Key 등) 설정이나 AWS CLI 스크립트 작성이 필요하지만, 오픈 소스 액션들도 많아 유연성은 높습니다. 조직의 기술 스택과 선호도에 따라 선택하면 되며, 소규모 프로젝트나 AWS 전용 환경이라면 CodePipeline이 간단하고, 멀티클라우드 또는 오픈 소스 CI/CD를 선호한다면 GitHub Actions 등을 고려할 수 있습니다.

Q3. Elastic Beanstalk 환경에서 Spring Boot 애플리케이션의 서버 포트는 어떻게 설정하나요?
A. Amazon Linux 2 기반 Elastic Beanstalk의 Java 플랫폼에서는 기본적으로 포트 5000을 리스닝하도록 설정되어 있습니다 (Nginx가 5000번 포트로 프록시). 따라서 Spring Boot 애플리케이션도 포트 5000에서 동작해야 정상적인 통신이 이뤄집니다. 설정 방법으로는 Spring Boot의 설정 파일에 server.port=5000을 추가하거나, EB 환경 변수에 SERVER_PORT 값을 5000으로 넣어주는 방법이 있습니다. 이렇게 하면 애플리케이션이 5000번 포트로 기동하며, Elastic Beanstalk의 헬스 체크와 로드 밸런서 라우팅이 정상 동작합니다. (만약 5000으로 설정하지 않으면 502 Bad Gateway 오류를 만나게 되니 유의해야 합니다.)

Q4. 데이터베이스 접속 정보(RDS Endpoint, 비밀번호 등)와 같은 민감한 설정은 어떻게 관리하나요?
A. 환경 변수 활용이 기본 방법입니다. Elastic Beanstalk 콘솔의 Configuration -> Software -> Environment properties에 DB연결 정보를 설정해 두면 애플리케이션에서 이를 읽어 사용할 수 있습니다. 예를 들어 SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME, SPRING_DATASOURCE_PASSWORD와 같은 변수에 RDS 접속값을 넣고, Spring Boot에서 해당 값을 받아 사용하면 됩니다. 이러한 환경 변수는 EB 콘솔에 암호화되어 표시되고, 코드에는 노출되지 않으므로 어느 정도 안전합니다. 추가로 AWS Systems Manager Parameter Store나 AWS Secrets Manager를 이용해 암호를 저장하고, 애플리케이션이 시크릿을 조회하도록 구성하면 보안 수준을 높일 수 있습니다. 하지만 초급 단계에서는 EB 환경 변수만으로도 충분하며, 나중에 보안을 강화해야 할 때 시크릿 관리 서비스를 도입하면 됩니다.

Q5. Elastic Beanstalk 사용 자체에는 비용이 발생하지 않는다고 했는데, 그렇다면 어떤 비용을 고려해야 하나요?
A. Elastic Beanstalk 서비스는 별도의 이용료가 없고 무료입니다. 다만 EB를 사용하면서 생성되는 모든 AWS 자원에는 비용이 부과됩니다. 예를 들어 EC2 인스턴스 시간당 비용, RDS 인스턴스 비용, 로드밸런서 비용, 사용한 S3 스토리지 비용 등이 해당됩니다. 따라서 프리 티어 한도 내의 작은 인스턴스로 시작하면 초반 비용은 거의 없겠지만, 트래픽 증가로 **대형 인스턴스나 다중 인스턴스(오토스케일링)**를 사용하게 되면 비용이 증가합니다. 또한 RDS를 함께 사용한다면 RDS 비용도 별도로 청구됩니다. 요약하면, EB 자체 요금은 없지만 EB가 생성한 AWS 인프라 자원의 비용을 모니터링하고 최적화해야 합니다. 필요 이상으로 돌아가는 리소스는 없는지, 자동 종료 설정(예: 미사용시 환경 종료) 등을 통해 비용 관리에 유의하세요.

Q6. 배포 자동화 이후에 추가로 고려할 만한 개선 사항이나 다음 단계는 무엇인가요?
A. 기본적인 자동 배포 파이프라인을 구축했다면, 이후에는 고가용성과 운영 개선을 고민할 수 있습니다. 예를 들어 Elastic Beanstalk 환경을 멀티 AZ로 구성하여 장애에 대비하거나, 오토스케일링 규칙을 튜닝하여 트래픽 급증 시 원활하게 대처합니다. Blue/Green 배포나 Canary 배포 등 배포 전략을 적용해 무중단 배포에 가까워지도록 할 수도 있습니다. 또한 CI 단계에서 테스트 자동화를 추가하여 품질 검사까지 파이프라인에 포함하면 더 안전한 배포가 가능합니다. 모니터링 측면에서는 CloudWatch 대시보드나 X-Ray 등을 연계해 애플리케이션 성능과 오류를 추적하는 것도 좋습니다. 마지막으로, 인프라 구성을 코드로 관리하기 위해 AWS CDK/CloudFormation으로 Beanstalk 환경과 CodePipeline을 관리하거나, Docker 컨테이너로의 전환(ECS, EKS, AWS App Runner 등 대안 서비스) 등을 고려해볼 수도 있습니다. 단계적으로 적용하면서 가장 적합한 환경을 찾아가보세요.

 

배포 성공 화면