260323 CI/CD 파이프라인 종합 리서치 🚀

260323 CI/CD 파이프라인 종합 리서치 🚀

📌 목차

1. CI/CD 소개
2. 필요성
3. 장단점
4. 내 프로젝트에 적용
5. 간단 예제
6. 실용 예제
7. CI/CD 클라우드 플랫폼 추천

1. CI/CD 소개 🎯

CI/CD란?

CI/CD는 Continuous Integration(지속적 통합) 과 Continuous Delivery/Deployment(지속적 전달/배포) 의 약자로, 소프트웨어 개발 라이프사이클을 자동화하는 핵심 DevOps 관행입니다.

CI/CD 파이프라인 흐름

flowchart LR
    A[👨‍💻 코드 작성] --> B[📤 Git Push]
    B --> C[🔨 자동 빌드]
    C --> D[🧪 자동 테스트]
    D --> E{✅ 통과?}
    E -->|Yes| F[📦 아티팩트 생성]
    E -->|No| G[❌ 알림 & 수정]
    F --> H[🚀 스테이징 배포]
    H --> I[🏭 프로덕션 배포]
    G --> A

2026년 CI/CD 트렌드

• 🔒 Shift-Left Security: 보안 검사를 파이프라인 초기 단계에 통합
• 🤖 AI 기반 테스트: AI가 테스트 케이스 자동 생성 및 최적화
• 📊 Observability-Driven: 모니터링·로깅·트레이싱을 파이프라인에 내장
• 🏗️ Infrastructure as Code (IaC): Terraform, CDK 등으로 인프라를 코드로 관리
• ⚡ 병렬 테스트 실행: 15분 이내 전체 테스트 완료 목표

📖 참고: CI/CD Pipeline Explained: Stages, Tools & Examples (2026)

DevOps Engineering in 2026: Top CI/CD Tools

2. 필요성 💡

왜 CI/CD가 필요한가?

mindmap
  root((CI/CD 필요성))
    속도
      빠른 릴리즈 주기
      시장 선점
      주간/일간/시간 단위 배포
    품질
      자동화된 테스트
      조기 버그 발견
      코드 리뷰 강제
    협업
      팀 간 충돌 최소화
      작은 단위 통합
      투명한 프로세스
    비용
      수동 작업 제거
      다운타임 감소
      롤백 자동화

CI/CD 없이 개발할 때의 문제점 😰

도입 효과 수치 📊

• 배포 시간: 수시간 → 수분 (최대 95% 단축)
• 배포 빈도: 월 1회 → 일 수회 (10x~100x 증가)
• 버그 발견 시간: 수일 → 수분 (조기 탐지)
• 롤백 시간: 수시간 → 수분 (자동 롤백)

📖 참고: [12 Benefits of CI/CD

JetBrains](https://www.jetbrains.com/teamcity/ci-cd-guide/benefits-of-ci-cd/)

[Best Practices for Awesome CI/CD

Harness](https://www.harness.io/blog/best-practices-for-awesome-ci-cd)

3. 장단점 ⚖️

✅ 장점

❌ 단점

📖 참고: [Pros and Cons of CI/CD

BairesDev](https://www.bairesdev.com/blog/pros-and-cons-of-ci-cd-pipelines/)

[Benefits and Challenges of CI/CD

TechTarget](https://www.techtarget.com/searchsoftwarequality/tip/The-pros-and-cons-of-CI-CD-pipelines)

4. 내 프로젝트에 적용 🏠

프로젝트 기술 스택

┌─────────────────────────────────────────────────────────┐
│                    🌐 Frontend                          │
│   Next.js + TypeScript + Tailwind CSS                   │
│   → AWS Lambda (Docker 컨테이너)                         │
├─────────────────────────────────────────────────────────┤
│                    ⚙️ Backend                            │
│   Python FastAPI                                        │
│   → AWS Lambda (Docker 컨테이너)                         │
├─────────────────────────────────────────────────────────┤
│                    🗄️ Database                           │
│   Google Firestore (NoSQL)                              │
└─────────────────────────────────────────────────────────┘

프로젝트 맞춤 CI/CD 아키텍처

flowchart TB
    subgraph DEV["👨‍💻 개발 환경"]
        A[Git Push to GitHub]
    end

    subgraph CI["🔨 CI - GitHub Actions"]
        B[Checkout Code]
        C[Install Dependencies]
        D[Lint & Type Check]
        E[Unit Tests]
        F[Build Docker Images]
    end

    subgraph CD_FRONT["🎨 CD - Frontend"]
        G[Build Next.js]
        H[Docker Image → ECR]
        I[Deploy to Lambda]
    end

    subgraph CD_BACK["⚙️ CD - Backend"]
        J[Build FastAPI]
        K[Docker Image → ECR]
        L[Deploy to Lambda]
    end

    subgraph INFRA["☁️ AWS Infrastructure"]
        M[API Gateway]
        N[Lambda - Frontend]
        O[Lambda - Backend]
        P[Firestore]
    end

    A --> B --> C --> D --> E --> F
    F --> G --> H --> I --> N
    F --> J --> K --> L --> O
    N --> M
    O --> M
    O --> P

각 컴포넌트별 CI/CD 전략

🎨 Frontend (Next.js + TypeScript + Tailwind CSS)

⚙️ Backend (Python FastAPI)

🗄️ Firestore 연동 고려사항

• CI 환경에서 Firestore Emulator 사용하여 테스트
• 프로덕션 Firestore 접근에는 GitHub Secrets에 서비스 계정 키 저장
• 환경별(dev/staging/prod) Firestore 프로젝트 분리 권장

📖 참고: Deploy FastAPI on AWS Lambda with Docker

Next.js Deployment on AWS Lambda

5. 간단 예제 📝

5-1. 가장 기본적인 CI 워크플로우 (GitHub Actions)

main 브랜치에 PR이 올라오면 자동으로 테스트를 실행하는 예제

# .github/workflows/ci.yml
name: CI Pipeline

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run tests
        run: pytest

5-2. 가장 기본적인 CD 워크플로우

main에 merge되면 자동으로 EC2에 배포하는 예제

# .github/workflows/cd.yml
name: CD Pipeline

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy via SSH
        uses: appleboy/ssh-action@master
        with:
          host: $
          username: $
          key: $
          script: |
            cd /home/ubuntu/my-app
            git pull origin main
            docker-compose down
            docker-compose up -d --build

5-3. 워크플로우 파일 구조

my-project/
├── .github/
│   └── workflows/
│       ├── ci.yml          ← PR 시 자동 테스트
│       └── cd.yml          ← merge 시 자동 배포
├── Dockerfile
├── docker-compose.yml
├── requirements.txt
└── app/
    └── main.py

📖 참고: How to Build Your First CI/CD Pipeline in 2026

CI/CD Pipelines Explained: A Practical Guide

6. 실용 예제 🔥

내 프로젝트 (Next.js + FastAPI + Lambda) 전체 CI/CD 구성

6-1. FastAPI Backend - Dockerfile

# backend/Dockerfile
FROM public.ecr.aws/lambda/python:3.12

# 의존성 설치
COPY requirements.txt ${LAMBDA_TASK_ROOT}
RUN pip install -r requirements.txt

# 앱 코드 복사
COPY ./app ${LAMBDA_TASK_ROOT}/app

# Mangum 핸들러 지정 (FastAPI → Lambda 어댑터)
CMD ["app.main.handler"]

6-2. FastAPI main.py (Lambda 호환)

# app/main.py
from fastapi import FastAPI
from mangum import Mangum

app = FastAPI(title="My API")

@app.get("/health")
async def health_check():
    return {"status": "healthy"}

@app.get("/api/stocks")
async def get_stocks():
    # Firestore에서 주식 데이터 조회
    ...

# Lambda 핸들러 (Mangum이 API Gateway ↔ FastAPI 변환)
handler = Mangum(app, lifespan="off")

6-3. Next.js Frontend - Dockerfile

# frontend/Dockerfile
FROM public.ecr.aws/lambda/nodejs:20 AS builder

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM public.ecr.aws/lambda/nodejs:20
COPY --from=builder /app/.next/standalone ${LAMBDA_TASK_ROOT}
COPY --from=builder /app/.next/static ${LAMBDA_TASK_ROOT}/.next/static
COPY --from=builder /app/public ${LAMBDA_TASK_ROOT}/public

CMD ["server.handler"]

6-4. 통합 CI/CD 워크플로우 (GitHub Actions)

# .github/workflows/deploy.yml
name: 🚀 Build & Deploy Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  AWS_REGION: ap-northeast-2
  ECR_REGISTRY: $.dkr.ecr.ap-northeast-2.amazonaws.com

jobs:
  # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  # 🧪 CI: 테스트 & 검증
  # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ci-backend:
    name: 🐍 Backend CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          cd backend
          pip install -r requirements.txt
          pip install pytest ruff mypy

      - name: Lint (Ruff)
        run: cd backend && ruff check .

      - name: Type Check (mypy)
        run: cd backend && mypy app/

      - name: Run Tests
        run: cd backend && pytest --tb=short -q
        env:
          FIRESTORE_EMULATOR_HOST: localhost:8080

  ci-frontend:
    name: 🎨 Frontend CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
          cache-dependency-path: frontend/package-lock.json

      - name: Install dependencies
        run: cd frontend && npm ci

      - name: Lint (ESLint)
        run: cd frontend && npm run lint

      - name: Type Check (TypeScript)
        run: cd frontend && npx tsc --noEmit

      - name: Run Tests
        run: cd frontend && npm test -- --ci

      - name: Build
        run: cd frontend && npm run build

  # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  # 🚀 CD: Docker 빌드 & Lambda 배포
  # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  cd-backend:
    name: 🐍 Backend Deploy
    needs: [ci-backend]
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $

      - name: Login to ECR
        id: ecr-login
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build & Push Docker Image
        run: |
          IMAGE_TAG="$/backend:$"
          docker build -t $IMAGE_TAG ./backend
          docker push $IMAGE_TAG

      - name: Update Lambda Function
        run: |
          aws lambda update-function-code \
            --function-name my-backend-api \
            --image-uri "$/backend:$"

      - name: Wait for Lambda Update
        run: |
          aws lambda wait function-updated \
            --function-name my-backend-api

  cd-frontend:
    name: 🎨 Frontend Deploy
    needs: [ci-frontend]
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $

      - name: Login to ECR
        id: ecr-login
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build & Push Docker Image
        run: |
          IMAGE_TAG="$/frontend:$"
          docker build -t $IMAGE_TAG ./frontend
          docker push $IMAGE_TAG

      - name: Update Lambda Function
        run: |
          aws lambda update-function-code \
            --function-name my-frontend-app \
            --image-uri "$/frontend:$"

6-5. 필요한 GitHub Secrets 설정

6-6. 배포 파이프라인 시퀀스 다이어그램

sequenceDiagram
    actor Dev as 👨‍💻 개발자
    participant GH as GitHub
    participant GA as GitHub Actions
    participant ECR as AWS ECR
    participant Lambda as AWS Lambda
    participant GW as API Gateway
    participant FS as Firestore

    Dev->>GH: git push (main)
    GH->>GA: Webhook 트리거

    par Backend CI/CD
        GA->>GA: Python lint + test
        GA->>ECR: Docker image push (backend)
        ECR->>Lambda: 이미지 업데이트 (backend)
    and Frontend CI/CD
        GA->>GA: TypeScript check + build
        GA->>ECR: Docker image push (frontend)
        ECR->>Lambda: 이미지 업데이트 (frontend)
    end

    Lambda->>GW: 서비스 Ready
    GW->>Dev: 배포 완료! 🎉
    Lambda->>FS: 데이터 읽기/쓰기

📖 참고: FastAPI + Docker + AWS Lambda (2025)

AWS Lambda FastAPI CI/CD Pipeline

FastAPI CI/CD: GitHub Actions, Docker & AWS EC2

7. CI/CD 클라우드 플랫폼 추천 ☁️

7-1. 플랫폼 비교 총정리

pie title 2026 CI/CD 시장 점유율 (마인드쉐어)
    "GitHub Actions" : 35
    "Jenkins" : 25
    "GitLab CI" : 15
    "AWS CodePipeline" : 10
    "CircleCI" : 8
    "기타" : 7

7-2. AWS 내에서의 추천 💎

🏆 Option A: GitHub Actions + AWS (⭐ 가장 추천)

GitHub Actions → ECR → Lambda

왜 추천?

• 설정이 가장 간편 (YAML 파일 하나로 끝)
• GitHub 무료 플랜으로 소규모 프로젝트 충분
• AWS 서비스 연동 액션이 마켓플레이스에 풍부
• 현재 프로젝트(GitHub 기반)에 가장 자연스러운 선택

비용: 무료 ~ $4/월 (소규모 기준)

🥈 Option B: AWS CodePipeline + CodeBuild

CodePipeline → CodeBuild → ECR → Lambda

장점:

• AWS 네이티브로 IAM 역할 기반 보안 우수
• CloudWatch와 연동으로 모니터링 편리
• 2026년 GitHub App 통합으로 설정 간소화

단점:

• 초기 설정이 GitHub Actions보다 복잡
• CodeBuild 빌드 환경 커스텀에 시간 소요

비용: ~$1/파이프라인/월 + CodeBuild $0.005/분

🥉 Option C: Jenkins on EC2 (자체 호스팅)

Jenkins (EC2) → ECR → Lambda

장점:

• 완전한 커스텀 제어
• 플러그인 생태계 (1,800개+)
• 복잡한 빌드 로직 구현 가능

단점:

• EC2 인스턴스 직접 관리 (패치, 백업, 스케일링)
• Jenkins 자체 보안 관리 부담
• 1인/소규모 팀에는 오버스펙

비용: t3.medium ~$30/월 + EBS 비용

7-3. EC2로 직접 CI/CD 구축하기 🖥️

방법 1: EC2에 Jenkins 설치

# EC2 인스턴스에 Jenkins 설치 (Amazon Linux 2023)
sudo dnf update -y
sudo dnf install java-17-amazon-corretto -y

# Jenkins 저장소 추가 및 설치
sudo wget -O /etc/yum.repos.d/jenkins.repo \
  https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo dnf install jenkins -y

# Jenkins 시작
sudo systemctl start jenkins
sudo systemctl enable jenkins

# 방화벽 설정
sudo ufw allow 8080

방법 2: EC2에 GitHub Actions Self-Hosted Runner 설치

GitHub Actions의 편리함 + EC2의 성능을 결합하는 하이브리드 방식 ⭐

# EC2 인스턴스에서 실행
# 1. Runner 다운로드
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64-2.321.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.321.0/actions-runner-linux-x64-2.321.0.tar.gz
tar xzf ./actions-runner-linux-x64-2.321.0.tar.gz

# 2. Runner 등록
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO \
  --token YOUR_TOKEN

# 3. 서비스로 실행
sudo ./svc.sh install
sudo ./svc.sh start

워크플로우에서 Self-Hosted Runner 사용:

jobs:
  build:
    runs-on: self-hosted  # ← GitHub 호스팅 대신 EC2 사용
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t my-app .
      - run: docker push ...

Self-Hosted Runner 장점 🚀

EC2 직접 구축 추천 여부 판단 기준

flowchart TD
    A{팀 규모?} -->|1~3명| B{빌드 빈도?}
    A -->|4명+| C[Self-Hosted Runner 고려]
    B -->|하루 수회| D[✅ GitHub Actions 무료로 충분]
    B -->|하루 수십회| E{비용 민감?}
    E -->|Yes| F[✅ Self-Hosted Runner]
    E -->|No| D
    C --> G{VPC 내부 접근 필요?}
    G -->|Yes| F
    G -->|No| H{빌드 시간 중요?}
    H -->|Yes| F
    H -->|No| D

7-4. 🎯 내 프로젝트 최종 추천

💡 결론: 현재 프로젝트 규모(Next.js + FastAPI + Lambda)에서는 GitHub Actions가 최적입니다. 프로젝트가 성장하면 Self-Hosted Runner로 전환하면 됩니다.

📖 참고: GitHub Actions vs AWS CodePipeline (2025)

AWS CodePipeline vs Jenkins vs GitHub Actions (2026)

Self-Hosted Runners: 6x Faster Builds

CI/CD with GitHub Actions Self-Hosted Runner

📎 전체 참고 자료

프롬프트

주제 : CI/CD

- 소개
- 필요성
- 장단점
- 내 프로젝트
  - next.js, typescript, tailwind.css
  - aws lambda 에 docker 배포
  - python fastapi backend
  - firestore 사용
- 간단 예제
- 실용 예제
- CI/CD 구축하는 실무 클라우드 플랫폼 추천
  - in aws
  - ec2로 직접하는 방식?