WallyLog
others

CI/CD의 필요성 (AWS Lightsail로 직접 배포하며 느낀)

예전에 AWS Lightsail을 이용하여 개인 웹사이트를 운영한 적이 있습니다.

당시에는 CI/CD를 적용하지 않았기 때문에, 코드를 수정할 때마다 직접 서버에 접속하여 배포를 진행했습니다.

배포 과정은 다음과 같았습니다.

GitHub에 Push
↓
AWS 서버 접속(SSH)
↓
git pull
↓
npm install
↓
npm run build
↓
Nginx가 바라보는 build 파일 갱신
↓
서비스 배포

이 방식은 동작에는 문제가 없었지만 몇 가지 아쉬운 점이 있었습니다.

  • 테스트 과정이 없었다.

  • Lint 검사도 하지 않았다.

  • 코드 수정이 발생할 때마다 AWS 서버에 직접 접속해야 했다.

  • 배포 과정이 모두 수작업이라 실수가 발생할 가능성이 있었다.

특히 하루에 여러 번 수정이 발생하는 경우에는 위 과정을 계속 반복해야 했습니다.

그래서 "GitHub에 Push 한 번으로 테스트부터 배포까지 자동으로 수행할 수 없을까?"라는 생각을 하게 되었고, CI/CD에 대해 정리해 보았습니다.

CI/CD 적용 후 전체 흐름

개발자가 코드 작성
↓
git push
=========================
CI 시작
=========================
GitHub Actions 실행
↓
GitHub가 새로운 가상 머신(Runner)을 생성
↓
Node 설치
↓
npm install
↓
Lint 검사 (ESLint 등)
↓
테스트 실행 (Jest, Vitest 등)
↓
테스트 성공 시에만
↓
npm run build
↓
build/ 또는 dist/ 생성
=========================
CD 시작
=========================
AWS에 접속
↓
AWS 배포
(자동 배포 또는 수동 승인 후 배포)
↓
build 파일 업로드
↓
Nginx Reload
↓
서비스 반영

CI에서는 코드가 정상적으로 동작하는지 확인합니다.

  • 의존성 설치(npm install)

  • Lint 검사

  • 테스트

  • Build

이 중 하나라도 실패하면 Build와 배포는 진행되지 않습니다.

즉, 문제가 있는 코드가 운영 서버까지 배포되는 것을 방지할 수 있습니다.

CD에서는 CI를 통과한 결과물을 실제 AWS 서버에 배포합니다.

배포 방식은 프로젝트에 따라 다르며,

  • 운영 서버까지 자동 배포(Continuous Deployment)

  • 승인 후 배포(Continuous Delivery)

두 가지 모두 가능합니다.

예를 들어 실제 현업에서는 다음과 같이 운영하는 경우가 많습니다.

  • Staging 환경 → 자동 배포

  • Production 환경 → 승인 후 수동 배포

현업에서 많이 사용하는 흐름

실제 회사에서는 바로 main 브랜치에 Push하는 경우보다 Pull Request(PR)를 통한 코드 리뷰를 거치는 경우가 많습니다.

개발자가 코드 작성
↓
feature/login 브랜치 생성
↓
기능 개발
↓
GitHub에 Push
↓
Pull Request 생성
↓
====================
CI 실행
====================
Node 설치
↓
npm install
↓
Lint 검사
↓
테스트
↓
Build
↓
CI 성공
↓
PR 대기
(코드 리뷰)
↓
팀장 또는 리뷰어 승인(Approve)
↓
main 브랜치 Merge
(이 시점에 CD 실행)
↓
====================
CD 실행
====================
AWS 배포
(자동 또는 승인 후 수동 배포)

CI는 코드의 품질을 자동으로 검증하는 역할을 하고,

CD는 검증이 완료된 코드를 실제 운영 환경에 배포하는 역할을 합니다.

예전에는 제가 직접 AWS 서버에 접속하여 git pull, npm run build, Nginx 재시작 등을 수행했지만, CI/CD를 적용하면 이러한 반복 작업을 GitHub Push 한 번으로 자동화할 수 있습니다.

배포 속도뿐 아니라 코드 품질과 안정성까지 함께 향상시킬 수 있다는 점이 CI/CD의 가장 큰 장점이라고 생각합니다.

GitHub Actions 예제

아래는 예시로 작성한 가장 기본적인 GitHub Actions YAML예제입니다.

name: React CI/CD

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # 소스 다운로드
      - name: Checkout
        uses: actions/checkout@v4

      # Node 설치
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22

      # 의존성 설치
      - name: Install dependencies
        run: npm ci

      # ESLint
      - name: Run Lint
        run: npm run lint

      # 테스트
      - name: Run Test
        run: npm test -- --watch=false

      # Build
      - name: Build
        run: npm run build

      # 이후 단계
      # AWS EC2 업로드
      # 또는 S3 Sync
      # 또는 CodeDeploy

이 YAML은 CI까지만 구현한 예제입니다.

여기에 마지막으로 AWS 배포 스텝을 추가하면 CD까지 완성됩니다.

예를 들어:

  • EC2 + SSH 배포

  • S3 + CloudFront 배포

  • AWS CodeDeploy

  • Docker + ECS

등 원하는 배포 방식에 맞는 스텝을 추가합니다

모든 게시글 보기