CI/CD
Continuous Integration / Continuous Delivery
코드 변경을 자동으로 빌드, 테스트, 배포하는 실천. GitHub Actions, Jenkins, CircleCI 사용.
Continuous Integration / Continuous Delivery
코드 변경을 자동으로 빌드, 테스트, 배포하는 실천. GitHub Actions, Jenkins, CircleCI 사용.
CI/CD(Continuous Integration / Continuous Delivery)는 코드 변경을 자동으로 빌드, 테스트, 배포하는 소프트웨어 개발 실천법입니다. CI는 개발자들이 코드를 자주 통합하고 자동 테스트로 문제를 조기 발견하며, CD는 테스트된 코드를 자동으로 배포 가능한 상태로 만듭니다.
CI(Continuous Integration)에서는 개발자가 코드를 푸시할 때마다 자동으로 빌드와 테스트가 실행됩니다. 작은 변경을 자주 통합하면 병합 충돌을 줄이고, 버그를 빨리 발견하여 수정 비용을 낮출 수 있습니다.
CD는 Continuous Delivery와 Continuous Deployment 두 가지로 해석됩니다. Delivery는 배포 준비까지 자동화하고 실제 배포는 수동 승인, Deployment는 프로덕션 배포까지 완전 자동화합니다. 조직의 리스크 허용도에 따라 선택합니다.
GitHub Actions, Jenkins, GitLab CI, CircleCI 등 다양한 도구가 있습니다. 파이프라인은 일반적으로 빌드 → 유닛테스트 → 통합테스트 → 보안스캔 → 아티팩트 게시 → 배포 단계로 구성됩니다.
# .github/workflows/ci-cd.yml
name: CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm run test:coverage
- uses: codecov/codecov-action@v4
build-and-push:
needs: test
if: github.event_name == 'push'
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v3
- uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v5
with:
push: true
tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
cache-from: type=gha
cache-to: type=gha,mode=max
deploy:
needs: build-and-push
runs-on: ubuntu-latest
environment: production
steps:
- run: |
echo "Deploying version ${{ github.sha }} to production"
# kubectl set image 또는 ArgoCD sync 등
시니어: "배포가 주 1회에서 일 10회로 늘었는데 장애가 오히려 줄었어요. CI/CD 파이프라인 덕분에 작은 변경을 자주 배포하니까 문제 범위가 좁아졌거든요."
주니어: "테스트 커버리지가 낮으면 CD 하기 어렵지 않나요?"
시니어: "맞아요, 그래서 커버리지 threshold 설정하고, 점진적으로 높여가고 있어요. 테스트 없는 CD는 위험합니다."
면접관: "CI/CD 파이프라인에서 테스트가 실패하면 어떻게 하나요?"
지원자: "파이프라인이 실패하면 PR 머지가 블록됩니다. 테스트 실패 원인을 분석하고 수정하거나, flaky test라면 격리하여 별도 조사합니다. main 브랜치는 항상 green 상태를 유지하는 것이 원칙입니다."
리뷰어: "시크릿을 환경변수로 직접 넣지 말고 GitHub Secrets나 Vault에서 가져오도록 해주세요."
개발자: "네, secrets context 사용하고 OIDC로 AWS 인증도 적용하겠습니다."
원인: 운영 DB에서 수동으로 rm -rf 실행 후, 백업이 정상 작동하지 않는 것을 발견
영향: 6시간 분량의 프로젝트 데이터 영구 손실, GitLab.com 18시간 다운
해결: 유일하게 살아남은 스테이징 DB 스냅샷에서 복구
교훈: CI/CD 파이프라인에 백업 검증 테스트 단계 추가, Chaos Engineering 도입
원인: 8대 서버 중 1대에 구버전 코드가 배포됨 (수동 배포, 자동화 부재)
영향: 45분 동안 비정상 주식 거래로 $440M 손실, 회사 파산 위기
해결: 수동 개입으로 서버 중단
교훈: 자동화된 CI/CD 파이프라인의 중요성, Blue-Green 배포로 롤백 가능성 확보
Q1. CI(Continuous Integration)의 핵심 목적은?
Q2. Continuous Delivery와 Continuous Deployment의 차이점은?
Q3. CI/CD 파이프라인에서 Flaky Test가 문제인 이유는?
이 페이지에 오류가 있거나 추가하고 싶은 내용이 있다면 알려주세요!