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

목차

전체 아키텍처 개요

Git 저장소를 사용하지 않고도 AWS 서비스만으로 CI/CD 파이프라인을 구성할 수 있습니다. 이번 구성에서는 Amazon S3 버킷을 코드 패키지 저장소로 사용하고, AWS CodeDeploy를 통해 해당 패키지를 EC2 인스턴스에 배포합니다. CodeDeploy 에이전트가 설치된 EC2 인스턴스는 S3에 올라온 새로운 버전의 애플리케이션(zip 파일)을 감지하여 가져오고, 지정된 배포 그룹에 속한 인스턴스들에 자동으로 배포를 수행합니다. 이 과정에서 AWS CodePipeline이 소스(S3)와 배포(CodeDeploy) 단계를 오케스트레이션 하여 코드 변경 시 자동으로 배포까지 이어지도록 합니다.

 

[Developer]
     │
     ▼
[S3 Bucket]
     │
     ▼
[CodeDeploy (CodePipeline)]
     │
     ▼
[EC2 Instance (WEB)]

 ※ 현재 구축 아키텍처: S3 버킷에 애플리케이션 zip을 업로드하면 CodeDeploy가 EC2 인스턴스에 배포한다.

 

위 다이어그램과 같이, S3 버킷은 어플리케이션 패키지(압축 파일)의 소스 저장소 역할을 합니다. CodeDeploy는 배포 서비스로서 S3에 새 버전이 올라오면 EC2에 배포 작업을 수행합니다. EC2 인스턴스에는 CodeDeploy Agent가 설치되어 있으며, 배포를 원활히 받기 위한 IAM 역할이 연결되어 있습니다 (S3 읽기 및 CodeDeploy와 연동 권한). 이 IAM 역할에는 AmazonEC2RoleforAWSCodeDeploy 및 AmazonSSMManagedInstanceCore와 같은 관리형 정책을 포함하여 EC2가 CodeDeploy 및 S3와 상호작용할 수 있도록 권한을 부여해야 합니다. 또한 CodeDeploy 자체에도 배포 작업을 수행하기 위한 서비스 역할(예: AWSCodeDeployRole 정책이 연결된 IAM 역할)을 생성하여 할당합니다.

 

※ 이전글

2025.07.17 - [IT 트렌드/알아두면 좋은 IT 상식] - VSCode Java Spring 프로젝트: Maven 스프링 부트 예제 설정부터 디버깅까지

VSCode Java Spring 프로젝트: Maven 스프링 부트 예제 설정부터 디버깅까지

2025.07.23 - [IT 트렌드/알아두면 좋은 IT 상식] - Java Spring Boot로 Maven 빌드 및 배포하기: 초보자도 겁내지 마세요!

Java Spring Boot로 Maven 빌드 및 배포하기: 초보자도 겁내지 마세요!

 

 

왜 Git을 생략하는가? 스타트업 환경에서는 초기에는 코드 저장소나 별도 CI 서버 세팅이 미흡할 수 있습니다. 이때 AWS S3와 CodeDeploy를 활용하면 간단히 Zip 파일 업로드만으로 배포 자동화를 구현할 수 있습니다. 즉, 개발 머신이나 빌드 서버에서 패키징 한 산출물을 S3에 올리기만 하면 CodeDeploy가 이를 EC2에 반영합니다. AWS CodePipeline을 사용하면 S3 버킷의 변경을 트리거로 잡아 배포까지 연계할 수 있어, Git 저장소 없이도 엔드투엔드 자동 배포 파이프라인이 완성됩니다.

단계별 구성 절차

이제 S3를 소스로 하고 CodeDeploy로 EC2에 배포하는 파이프라인을 단계별로 구축해보겠습니다. 주요 단계는 S3 버킷 준비, EC2 인스턴스 설정, CodeDeploy 에이전트 설치, CodeDeploy 애플리케이션 및 배포 그룹 생성, 마지막으로 CodePipeline으로 전체 흐름을 연결하는 것입니다.

참조 URL : https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/pipelines-connections.html

1단계: S3 버킷 생성 및 Versioning 설정

우선 코드 패키지를 저장할 S3 버킷을 생성합니다. 버킷을 만든 후에는 버전 관리(Versioning)를 활성화해야 합니다. CodePipeline에서 S3를 소스로 사용할 경우 버전 관리가 활성화된 버킷만 트리거로 활용할 수 있기 때문입니다. S3 콘솔에서 버킷을 생성한 뒤, Properties(속성) 탭의 버전 관리 섹션에서 Enable 옵션을 선택하고 저장합니다. 버전 관리가 켜지면 동일한 경로에 업로드되는 파일들의 과거 버전도 유지되므로, CodeDeploy 배포 시 특정 버전의 zip을 가리킬 수 있고 변경 감지도 정확하게 이루어집니다.

S3 bucket - upload file

 

이 버킷에 애플리케이션 배포 파일(예: SampleApp_linux.zip)을 업로드하면 준비 완료입니다. 초기에 테스트를 위해 간단한 웹 애플리케이션 파일들을 zip으로 묶어 올려두세요. (예: index.html과 CodeDeploy 설정파일 appspec.yml 포함) – Sample 애플리케이션 구조에 대한 예시는 AWS에서 제공하는 샘플을 참고할 수 있습니다.

파일 첨부 : SampleApp_linux.zip (https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/samples/SampleApp_Linux.zip)

SampleApp_Linux.zip

0.01MB

 

 

참고: S3 버킷 권한은 기본적으로 버킷 소유자에게만 허용됩니다. CodePipeline이 해당 버킷의 객체를 읽을 수 있도록 권한이 필요한 경우, 버킷 정책이나 IAM 역할을 통해 CodePipeline 서비스에 읽기 권한을 부여해야 합니다.
다만 기본 설정으로 진행하면 문제없이 연동됩니다.

2단계: EC2 인스턴스 생성 및 IAM 역할 매핑

배포 대상이 될 EC2 인스턴스를 생성합니다. 운영체제는 Amazon Linux 2 또는 Ubuntu 등 CodeDeploy 에이전트를 설치할 수 있는 환경을 선택합니다 (예시에서는 Amazon Linux 2 사용). 보안 그룹을 설정하여 SSH(22번 포트) 접근 및 웹 애플리케이션 확인을 위한 HTTP(80번 포트)를 허용합니다.

생성 시 중요한 것은 EC2에 IAM 역할(Instance Profile)을 연결하는 것입니다. 이 역할에는 S3 버킷에서 애플리케이션 패키지를 가져올 권한과 CodeDeploy와 통신할 권한이 필요합니다. AWS에서 미리 제공하는 AmazonEC2RoleforAWSCodeDeploy 정책과 AmazonS3ReadOnlyAccess 정책을 EC2 IAM 역할에 첨부하면 편리합니다. 또한 CodeDeploy 에이전트가 최신 버전으로 자동 유지되도록 AmazonSSMManagedInstanceCore 정책도 포함하면 좋습니다.

IAM 콘솔에서 역할 생성 시 신뢰 정책을 EC2로 하고 위의 관리형 정책들을 첨부한 뒤, 해당 역할을 EC2 생성 시에 지정하면 됩니다. (예: 역할 이름 EC2CodeDeployRole)

= IAM Role Name : EC2InstanceRole

= trust 는 EC2 로 진행

IAM Role Create

= 생성 시 셋팅값

IAM Policy & Trust

 

마지막으로 EC2에 태그를 하나 추가해 둡니다. CodeDeploy 배포 그룹에서 대상 EC2를 식별할 때 이 태그(Key=Name 혹은 특정 태그 키)로 인스턴스를 선택할 예정입니다. 예를 들어 태그 Key를 Name, Value를 MyCodePipelineDemo로 지정하면, 이후 CodeDeploy 배포 그룹 설정에서 동일한 키-값으로 대상 지정이 가능합니다.

3단계: EC2에 CodeDeploy Agent 설치

EC2 인스턴스에 접속(SSH)하여 CodeDeploy 에이전트를 설치합니다. CodeDeploy 에이전트는 배포 시 EC2에서 실행되어 S3로부터 파일을 받고 앱을 설치하는 역할을 합니다. Ruby 기반으로 동작하기 때문에 설치 전에 Ruby가 필요합니다. Amazon Linux 2 기준 설치 방법은 다음과 같습니다:

# 시스템 업데이트 및 Ruby, Wget 설치
sudo yum update -y
sudo yum install -y ruby wget

# CodeDeploy 에이전트 설치 스크립트 다운로드 (리전 URL 확인 필요)
REGION=ap-northeast-2  # 서울 리전 예시
wget "https://aws-codedeploy-${REGION}.s3.${REGION}.amazonaws.com/latest/install"

# 설치 스크립트 실행
chmod +x ./install
sudo ./install auto

# CodeDeploy 에이전트 실행 상태 확인
sudo service codedeploy-agent status

 

위 명령들을 실행하면 CodeDeploy 에이전트가 EC2에 설치됩니다. status 명령 결과 “The AWS CodeDeploy agent is running”이라고 나오면 성공입니다. 만약 에이전트가 실행 중이지 않다면 sudo service codedeploy-agent start로 수동 시작하고, sudo systemctl enable codedeploy-agent로 부팅 시 자동 시작을 활성화합니다.

Tip: CodeDeploy 에이전트 설치는 AWS Systems Manager(SSM)을 통해 자동화할 수도 있습니다. 이번 글에서는 수동 설치 방법을 다루지만, 실제 프로덕션 환경에서는 초기 설정 시 사용자 데이터(User Data) 스크립트나 SSM을 활용해 EC2 생성과 동시에 에이전트를 설치해 두는 것을 권장합니다.

 

4단계: CodeDeploy 애플리케이션 및 배포 그룹 설정

CodeDeploy에서 애플리케이션은 배포하려는 코드의 이름 형태의 식별자입니다.

 

이제 AWS Management Console에서 CodeDeploy 서비스를 설정합니다. CodeDeploy 콘솔에서 먼저 애플리케이션(Application)을 생성합니다. 애플리케이션 이름은 배포할 대상 어플리케이션 식별자이며 임의로 지정하면 됩니다 (예: MyDemoApplication). 플랫폼은 "EC2/온프레미스"를 선택합니다.

 

CodeDeploy Role 

Code Deploy Policy

 

Application 생성

MyDemoApplication 생성

 

 

다음으로 해당 애플리케이션에 배포 그룹(Deployment Group)을 생성해야 합니다. 배포 그룹에서는 어떤 EC2 인스턴스들에, 어떤 방식으로 배포할지 정의합니다. 배포 그룹 생성 시 다음 사항을 설정합니다:

Deployment Group 생성

• 배포 그룹 이름: 예시로 MyDemoDeploymentGroup 등으로 지정
• 서비스 역할: 앞서 생성한 CodeDeploy용 IAM 역할 (예: CodeDeployRole)을 선택합니다. 이 역할에는 AWSCodeDeployRole 정책이 첨부되어 있어야 합니다.
• 배포 유형: "In-place" (기존 EC2에 배포) 선택.
• 대상 환경 구성: "Amazon EC2 인스턴스"를 선택하고, 태그 기반으로 대상 지정합니다. 여기서 Key 및 Value를 앞서 EC2에 달았던 태그 (Name=MyCodePipelineDemo 등)로 입력하면 해당 인스턴스를 배포 대상으로 인식합니다.
• 배포 설정: 기본값인 CodeDeployDefault.OneAtATime 사용 – 하나의 인스턴스씩 순차 배포. (필요에 따라 반영 없이 즉시 배포하는 AllAtOnce 등 선택 가능)
• 로드 밸런서: 현재 구성에서는 사용하지 않으므로 비활성화 (체크 해제).
  
  

Key Base Deploy

설정을 마치고 배포 그룹을 생성하면, CodeDeploy 측 준비는 완료됩니다. CodeDeploy 애플리케이션과 배포 그룹이 생성되었지만 아직 실제 배포를 실행하지는 않은 상태입니다. 이제 남은 것은 S3 버킷의 변경을 감지하여 CodeDeploy 배포를 트리거하는 파이프라인을 구성하는 일입니다.

Code Deploy Application 생성 확인

 

5단계: CodePipeline 생성 및 S3–CodeDeploy 연동

AWS CodePipeline을 사용하여 S3를 소스(Stage 1)로, CodeDeploy를 배포(Stage 2)로 연결하는 파이프라인을 생성합니다.

Code Pipeline 생성

AWS CodePipeline 콘솔에서 Create Pipeline을 통해 파이프라인을 생성하고 단계별로 아래와 같이 설정합니다:

1. 파이프라인 생성: 파이프라인 이름을 입력하고, 새 서비스 역할을 생성하거나 기존 역할을 지정합니다 (기본값대로 진행하면 자동으로 CodePipeline용 역할이 생성됨). 이때 파이프라인의 Artifact 저장용 S3 버킷도 자동 생성하거나 커스텀으로 지정할 수 있습니다.
2. 소스 단계 추가: Source provider로 "Amazon S3"를 선택하고, Bucket 이름에 앞서 만든 버킷을 지정합니다. S3 object key에는 배포 패키지 경로를 입력합니다 (예: app.zip). 버킷이 버전 관리 활성화되어 있다면 CodePipeline이 해당 객체의 변경사항을 감지할 수 있습니다. Change detection 옵션은 기본 CloudWatch Events 또는 CodePipeline 폴링을 선택할 수 있는데, 여기서는 기본값(CloudWatch 이벤트)을 사용합니다.
   ( CodePipeline 소스 단계 설정 화면 – S3 버킷과 객체 키를 지정하고 변경 감지를 활성화한다. )
3. 빌드 단계 건너뛰기: 이번 파이프라인에는 코드 빌드 과정이 없으므로 Build stage는 Skip 합니다. (경고 창이 뜨면 확인).
4. 배포 단계 추가: Deploy provider로 "AWS CodeDeploy"를 선택합니다. Region 및 애플리케이션 이름, 배포 그룹을 앞서 설정한 값으로 지정합니다 (예: MyDemoApplication / MyDemoDeploymentGroup). 설정을 완료하면 다음을 눌러 파이프라인 생성을 마칩니다.

S3 Object key

파이프라인이 생성되면 CodePipeline이 자동으로 한 사이클을 실행하며, S3 버킷에 있는 zip 파일을 가져와 CodeDeploy로 EC2에 배포를 시도합니다. 최초 실행에서 성공 (Succeeded) 상태가 뜨면 구성이 제대로 된 것입니다. 만약 실패한다면, 오류 메시지를 확인해야 합니다. 예를 들어 “The source artifact bucket ... is not versioned”와 같은 오류는 S3 버킷에 버전 관리가 활성화되지 않아 발생한 것으로, 이 경우 버전 관리를 다시 확인해야 합니다. 또한 “No AWS CodeDeploy agent running” 등의 메시지가 나오면 EC2에 CodeDeploy 에이전트가 설치/실행되지 않은 상태이므로 3단계의 에이전트 설치를 재확인해야 합니다.

배포가 성공하면, CodeDeploy 콘솔이나 EC2 인스턴스에서 애플리케이션이 배포된 것을 확인할 수 있습니다. 예를 들어, EC2의 웹 서버 루트 경로(/var/www/html 등)에 업로드한 index.html이 배포되어, 해당 EC2의 퍼블릭 주소로 접속하면 웹 페이지가 보일 것입니다. CodeDeploy 배포 단계에서 설정한 AppSpec 파일(appspec.yml)에 따라 서비스 재시작이나 파일 복사 등이 수행되었다면 그 결과까지 반영됩니다. (AppSpec 파일은 CodeDeploy 배포의 단계별 동작을 정의하는 YAML 파일로, 파일 복사 경로와 후행 스크립트 등을 지정합니다.)

Deploy Stage

CodePipeline 파이프라인 실행 화면 – S3 소스 단계 성공 후 CodeDeploy 배포 단계가 진행 중인 모습. 

Simple S3 to EC2 Code Deploy

 

위 캡처는 파이프라인이 정상적으로 동작하는 예시입니다. Source 단계에서 S3 버킷의 변경을 감지하여 아티팩트를 가져오면 초록색으로 Succeeded 표시되고, 이어서 Deploy 단계에서 CodeDeploy가 EC2로 배포를 수행합니다. 배포 완료 후 EC2에 접속하거나 애플리케이션을 테스트하여 최종 결과를 검증할 수 있습니다.

 

Code Deploy 완료

 

※다음글

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

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

2025.08.01 - [IT 트렌드/알아두면 좋은 IT 상식] - AWS Elastic Beanstalk를 활용한 Spring Boot 자동 배포: CodePipeline 연동 가이드

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

 

향후 확장 방향

Git 연동 및 빌드 단계 추가

현재 구성은 빌드 과정을 생략하고 개발자가 수동으로 빌드한 산출물(zip)을 S3에 올리는 방식입니다. 향후에는 Git 플랫폼과 연계하여 코드 푸시부터 빌드, 테스트, 배포까지 자동화하는 방향으로 확장할 수 있습니다. 예를 들어, GitHub에 소스 코드를 푸시하면 CodePipeline이 이를 감지하여 CodeBuild로 Maven 빌드를 수행하고, 산출물을 S3에 저장한 뒤, CodeDeploy로 EC2에 배포하는 식입니다. 이러한 구성에서는 개발자가 직접 S3에 파일을 올릴 필요 없이 코드 커밋만으로 CI/CD 파이프라인이 동작하게 되어 더욱 효율적입니다.

 

확장된 CI/CD 흐름: Git 저장소 커밋 → CodeBuild 빌드/테스트 → S3 아티팩트 저장 → CodeDeploy 배포 (EC2).

위 그림은 GitHub 등 Git 리포지토리에 소스가 변경되면 CodePipeline이 소스 단계에서 해당 변경을 가져오고, 빌드 단계에서 CodeBuild가 애플리케이션을 패키징 한 후 산출물을 S3에 저장, 최종 배포 단계에서 CodeDeploy가 이를 EC2 인스턴스에 반영하는 엔드투엔드 파이프라인을 나타냅니다. 실제 구현을 위해서는 다음과 같은 추가 설정이 필요합니다:

• CodePipeline 소스 변경: S3 대신 GitHub을 소스로 연결. OAuth 토큰이나 Access Key를 통해 CodePipeline이 해당 리포지토리에 접근하도록 설정합니다.
• CodeBuild 프로젝트: 빌드 사양(예: buildspec.yml)에 따라 Maven 등 빌드 툴을 실행하고, 결과물(JAR/ZIP 등)을 S3에 출력하도록 정의합니다.
• CodeDeploy 연계: CodeBuild 출력 단계에서 생성된 아티팩트의 S3 경로를 CodeDeploy 배포 단계로 전달합니다 (CodePipeline가 자동 처리). CodeDeploy는 이전 구성과 동일하게 EC2에 배포를 수행합니다.

이처럼 확장된 파이프라인을 도입하면 테스트 자동화, 빌드 산출물 검증, 여러 환경으로의 배포(예: 스테이징/프로덕션)에 대한 관리가 수월해집니다. 초기 스타트업 단계에서는 다소 복잡해 보일 수 있으나, 애플리케이션이 성장하고 팀 협업이 늘어날수록 형상 관리와 CI/CD의 일원화가 큰 이점을 가져다줍니다.

ElastiCache 기반 세션 클러스터링 전략

확장이 진행되어 EC2 인스턴스를 여러 대 (예: 오토스케일링 그룹으로) 운영하게 될 경우, 세션 관리에 대한 고려가 필요합니다. 일반적으로 각 서버가 자체적으로 사용자 세션을 메모리에 저장하면, 배포 시 인스턴스 교체나 재시작으로 세션 정보가 유실되거나 로드 밸런싱 환경에서 세션 공유가 안 되는 문제가 발생할 수 있습니다. 이를 해결하기 위해 세션 스토리지의 외부화를 도입합니다.

AWS에서는 ElastiCache (Redis 혹은 Memcached) 서비스를 활용하여 세션을 인메모리 데이터베이스에 저장하는 패턴을 추천합니다. 애플리케이션 서버들은 사용자 로그인 정보나 상태 정보를 로컬 메모리가 아니라 Redis와 같은 중앙 캐시 서버에 저장/조회하고, 모든 서버가 이를 공유함으로써 특정 서버가 내려가도 세션 일관성이 유지됩니다. 결과적으로 EC2 인스턴스들이 무상태(stateless)로 동작하게 되어 CodeDeploy로 배포 시 한 대씩 교체(롤링 업데이트)하더라도 사용자 세션이 유지되고 중단 없는 배포가 가능합니다. 또한 추후 서버 증설이나 축소 시에도 세션 복제 부담 없이 자유롭게 스케일링이 가능해집니다.

예시 시나리오: 현재 1대의 EC2로 동작하던 웹 서비스가 사용자 증가로 2대 이상의 EC2 인스턴스로 확장되고 로드 밸런서가 추가되었다고 가정해 봅시다. 이때 사용자 A의 세션이 EC2-1에 저장된 상태에서 배포나 장애로 EC2-1이 교체되면 세션이 사라지지만, ElastiCache를 세션 저장소로 쓰면 사용자 A의 세션이 Redis에 남아 있어 EC2-2 또는 신규 EC2에서도 이어서 동일한 세션을 사용할 수 있습니다. 이러한 구조를 세션 클러스터링 또는 세션 중앙관리라고 하며, 대규모 웹 시스템에서 흔히 쓰이는 패턴입니다.

 

정리하면, Git 연동 + CodeBuild 추가로 보다 자동화된 CI/CD 파이프라인을 구축하고, ElastiCache 도입으로 애플리케이션 서버를 Stateless 하게 만들어 세션 클러스터 환경을 구현하는 것이 향후 고려할 만한 발전 방향입니다. 이를 통해 스타트업도 초기에는 간소한 배포에서 출발하여, 점진적으로 엔터프라이즈 수준의 안정성과 확장성을 갖춘 DevOps 파이프라인으로 성장시킬 수 있을 것입니다.

결론

이번 글에서는 Git 없이 S3 버킷 업로드를 트리거로 활용한 AWS 기반 배포 자동화 파이프라인을 살펴보았습니다. DevOps 담당자나 스타트업 CTO 입장에서 최소한의 구성 요소만으로도 자동 배포를 시작할 수 있다는 점을 강조하였습니다. S3와 CodeDeploy, 그리고 CodePipeline의 연계를 통해 배포 속도와 빈도를 높일 수 있고, 점차 Github 연동과 빌드 자동화를 추가하며 CI/CD 수준을 향상시킬 수 있습니다.

AWS가 제공하는 매니지드 서비스 조합을 활용하면 인프라 관리 부담을 줄이면서도 신뢰성 있는 배포를 구현할 수 있습니다. 공식 문서와 모범 사례를 참고하여 권한 설정이나 버전 관리 등의 세부사항을 꼼꼼히 적용하는 것이 중요합니다. 작은 시작이라도 자동화된 배포 파이프라인을 갖추는 순간부터 개발팀은 빈번한 배포와 신속한 피드백 수집이 가능해지며, 이는 궁극적으로 서비스 품질과 사용자 만족도 향상으로 이어질 것입니다.

참고 자료: AWS CodePipeline 공식 가이드, AWS CodeDeploy 사용자 가이드, 및 AWS Well-Architected 자료 등. 또한 AWS 개발자 커뮤니티와 사례 연구를 통해 유사한 시나리오의 구축 경험을 살펴보는 것도 도움이 됩니다. 이번 구성으로 DevOps 여정의 첫 단추를 잘 끼웠기를 바라며, 향후 필요에 따라 점진적으로 고도화해 나가길 바랍니다.