[Cloud] - CI/CD란? (with. AWS Cloud 특강)

오늘의 강의는 AWS에서의 CI/CD 개념 이해와 실습 적용을 목표로 진행되었다.

단순히 “자동 배포”를 경험하는 것이 아니라, 소프트웨어가 코드 변경부터 사용자에게 전달되기까지의 전체 흐름을 이해하는 데 초점이 맞춰졌다.

 

강의는 크게 두 부분으로 구성되었다.

• 이론: CI/CD 개념, 파이프라인 구조, AWS에서의 CI/CD 서비스 이해
• 실습: GitLab CI/CD 파이프라인을 구성하고, S3 기반 정적 웹사이트 배포

 

Part1 : CI/CD란 무엇인가?

1-1. CI/CD의 등장 배경

전통적인 소프트웨어 배포 방식에서는

• 코드 변경 → 수동 빌드 → 수동 테스트 → 수동 배포
  과정이 반복되며 배포 속도가 느리고, 휴먼 에러가 잦았다.

특히 마이크로서비스 환경에서는

• 서비스 개수가 많아질수록
• 각 서비스마다 빌드·테스트·배포를 반복해야 하므로
  자동화 없이는 운영이 사실상 불가능해진다.

이 문제를 해결하기 위해 등장한 개념이 CI/CD다.

1-2. CI/CD의 개념 정리

CI (Continuous Integration, 지속적 통합)

• 개발자가 코드를 자주(main branch에) 병합
• 코드 변경 시마다 자동으로:
  • 빌드
  • 단위 테스트
• 문제를 초기에 발견하는 것이 핵심
• 목표 = “코드를 자주 합치고, 바로 검증하자”

 

CD (Continuous Delivery / Deployment, 지속적인 배포)

• Continuous Delivery
  • 테스트를 통과한 결과물을 언제든 배포 가능한 상태로 유지
  • 실제 배포는 수동 승인
• Continuous Deployment
  • 테스트 통과 시 자동으로 운영 환경까지 배포
• 목표 = “검증된 코드를 빠르고 안정적으로 사용자에게 전달”

 

1-3. CI/CD 파이프라인 구조

 

• Source : Git 저장소에 코드 변경 사항 커밋
• Build : 소스 코드 컴파일 / 패키징
• Test : 단위 테스트 / 통합 테스트
• Release : 배포 가능한 아티팩트 생성
• Deploy : 운영 또는 스테이징 환경에 배포
• Monitor : 배포 이후 모니터링 및 피드백

 

1-4. 무중단 배포 전략 3가지

//TODO 진행 예정

 

 

 

Part2 : 실습, GitLab CI/CD + S3 배포

실습은 “AWS 클라우드에서 GitLab CI/CD를 활용한 DevOps 실습” 중 S3 정적 웹사이트 배포를 목표로 했다.

 

2-1. 실습 전체 흐름

실습에서 구성한 흐름은 다음과 같다.

1. GitLab Repository에 코드 push
2. GitLab CI 파이프라인 트리거
3. GitLab Runner가 빌드 수행
4. 빌드 결과물을 AWS S3에 업로드
5. S3 정적 웹사이트 호스팅을 통해 서비스 제공

2-2. 환경 구성

(1) GitLab 설치

• AWS Marketplace를 활용하여 Self-managed GitLab 환경 구성
• 설치할 EC2 Instance에 Secction Manger로 CLI에 접속해 설치를 진행.

# root 사용자로 변경
$ sudo su
# 쉘 스크립트 다운
$ wget https://ws-assets-prod-iad-r-pdx-f3b3f9f1a7d6a3d0.s3.us-west-2.amazonaws.com/bc2ef89d-92fa-46f3-9d84-2f5b1547f122/install_gitlab.sh
 # 쉘스크립트 실행
$ sh install_gitlab.sh

(2) Repository Import

• 실습용 웹 애플리케이션 Repository를 GitLab으로 Import
• GitLab에 접속해 Replository by URL import 활성화 하고 프로젝트를 예시 깃허브 프로젝트를 import해서 진행.
• CI/CD 파이프라인을 실습하기 위한 기본 코드 확보

(3) Runner 설치 및 등록

• GitLab Runner는 CI 작업을 실제로 실행하는 주체
• EC2 인스턴스에 Runner 설치
• GitLab 프로젝트에 Runner 등록

# GitLab 저장소를 추가합니다
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

# GitLab runner 패키지를 설치합니다
sudo apt-get install -y gitlab-runner

# Runner 서비스를 시작하고 부팅 시 자동 시작되도록 설정
sudo systemctl enable gitlab-runner
sudo systemctl start gitlab-runner

Runner 등록은 GitLab의 Setting의 CI/CD에서  project runner를 생성하고 아래의 명령어를 실행하면 된다.

gitlab-runner register --url http:/{ip주소} --token {}

 

2-3. S3 기반 정적 웹사이트 호스팅

실습에서는 서버 애플리케이션이 아닌 정적 웹사이트 배포를 진행했다.

(1) S3 버킷 준비

• AWS S3 서비스를 통해 버킷을 생성
• 정적 웹사이트 호스팅 옵션 활성화
  (버킷의 Properties의 "Static website hosting" 섹션 enable 설정 + Hosting type을 Host a static website 설정)
• 아래처럼 버킷 정책을 설정
• Public Access 설정 조정

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
        }
    ]
}

(2) EC2 인스턴스에 S3 배포 권한 할당하기 

• EC2 인스턴스에 S3 업로드 권한 부여를 위해 아래와 같이 IAM Policy 생성
• 생성한 IAM Policy를 EC2에 연결
• EC2 인스턴스에서 S3 접근 권한 확
• GitLab Runner가 S3에 접근 가능하도록 구성

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::{YOUR-BUCKET-NAME}",
                "arn:aws:s3:::{YOUR-BUCKET-NAME}/*"
            ]
        }
    ]
}

# EC2 인스턴스에서 S3 연결 확인
aws s3 ls s3://{YOUR-BUCKET-NAME}

 

2-4. GitLab CI/CD 파이프라인 구성

배포된 정적 웹 사이트 페이지

.gitlab-ci.yml 파일을 통해 다음을 정의했다.

• CI 단계(stage)
  • build
  • deploy
• 빌드 결과물 생성
• AWS CLI를 활용해 S3로 파일 업로드

코드 변경 후 push → 자동으로 파이프라인 실행 → S3에 최신 결과물 배포

위의 과정을 통해 “코드 변경시 자동 배포”되는 흐름을 직접 체험할 수 있었다.

image: node:latest

before_script:
  - source ~/.nvm/nvm.sh
  - nvm use node

stages:
  - build
  - deploy

cache:
  paths:
    - node_modules/

install_dependencies:
  stage: build
  script:
    - npm ci
  artifacts:
    paths:
      - node_modules/


deploy-job:      
  stage: deploy  
  environment: production
  script:
    - npm install -g gatsby-cli
    - gatsby build
    - aws s3 sync public s3://[YOUR-BUCKET-NAME] --delete

 

 

 

 

이번 CI/CD 특강은 단순한 도구 사용법을 넘어서,

• 왜 CI/CD가 필요한지
• 배포 자동화가 개발 문화에 어떤 영향을 주는지
• AWS 환경에서 이를 어떻게 구현하는지

를 한 흐름으로 이해할 수 있었다.

특히 인상 깊었던 점은:

• CI/CD는 “편의 기능”이 아니라 필수 인프라
• IAM 권한, 자동화, 파이프라인 설계가 보안과 직결
• S3 배포를 통한 작은 실습만으로도 DevOps의 핵심 흐름을 경험할 수 있다는 점이 가장 기억에 남는다.