DevOps

CI/CD 파이프라인에 대해서 설명해주세요

커밋 한 번으로 빌드·테스트·배포가 자동으로 이루어지는 CI/CD 파이프라인의 동작 원리, 주요 단계, 배포 전략을 인터랙티브 시각화로 이해합니다.

2026년 3월 15일 · 약 14분 읽기

Q. "CI/CD 파이프라인이 무엇인지 설명하고, 무중단 배포 전략에 대해서도 말씀해주세요."

예상 꼬리질문

답변 가이드

"CI/CD는 코드 변경사항을 자동으로 빌드·테스트·배포하는 파이프라인입니다. CI(지속적 통합)는 커밋마다 자동으로 빌드와 테스트를 실행해 통합 오류를 조기에 발견하는 관행입니다."

"CD는 Continuous Delivery(스테이징까지 자동, 프로덕션은 수동 승인)와 Continuous Deployment(완전 자동화) 두 가지로 나뉩니다. 파이프라인은 Source → Build → Test → Security → Staging → Production 단계로 구성되며, 앞 단계 실패 시 파이프라인이 중단됩니다."

"무중단 배포 전략으로 Blue-Green(즉각 전환), Canary(점진적 트래픽 이동), Rolling(순차 교체)이 있으며, 각각 비용·리스크·속도 트레이드오프가 다릅니다."

코드를 작성하고 "이제 배포해야지"라고 마음먹는 순간, 그 뒤에는 얼마나 많은 작업이 기다리고 있을까요? 빌드, 테스트, 도커 이미지 빌드, 서버 업로드, 재시작… 이 과정을 매번 손으로 반복한다면 실수가 생기고, 속도는 팀의 발목을 잡습니다.

CI/CD 파이프라인은 이 모든 과정을 자동화합니다. 개발자가 코드를 커밋하는 순간부터 서비스에 반영되기까지의 전 과정을 파이프라인이 대신 처리하며, 사람의 실수를 줄이고 배포 속도를 극적으로 높입니다.

1. CI와 CD — 같은 듯 다른 두 개념

꼬리질문: "CI와 CD는 각각 무엇이고, Continuous Delivery와 Continuous Deployment의 차이는 뭔가요?"

CI와 CD는 자주 함께 언급되지만, 각각 해결하는 문제가 다릅니다. CI(Continuous Integration, 지속적 통합)는 여러 개발자가 작성한 코드를 자주 통합하면서 생기는 충돌과 오류를 조기에 발견하는 관행입니다. 커밋마다 자동으로 빌드와 테스트가 실행되고, 10분 이내 결과가 개발자에게 전달됩니다.

CD는 두 가지 의미를 가집니다. Continuous Delivery(지속적 전달)는 CI를 통과한 코드를 스테이징까지 자동 배포하되 프로덕션은 수동 승인을 거칩니다. Continuous Deployment(지속적 배포)는 수동 개입 없이 모든 단계를 자동화합니다.

CI와 CD의 개념 차이를 다이어그램으로 확인해 보세요.

파이프라인 커버 범위

Source
→
Build
→
Test
→
Staging
→
Prod

개발자가 코드를 공유 저장소에 자주 병합할 때마다 자동으로 빌드·테스트를 실행합니다.

특징

  • •커밋마다 자동 빌드/테스트
  • •10분 이내 피드백
  • •통합 충돌 조기 발견

적합 환경

모든 팀

배포 주기

자동 배포 없음

2. 파이프라인의 6단계

꼬리질문: "CI/CD 파이프라인은 어떤 단계로 구성되나요?"

CI/CD 파이프라인은 코드 변경이 감지되는 순간부터 서비스 반영까지 여러 단계를 순서대로 통과합니다. 앞 단계가 실패하면 파이프라인이 즉시 중단되고 개발자에게 알림이 발송됩니다. 이 구조 덕분에 결함이 있는 코드는 절대 프로덕션에 도달하지 못합니다.

각 단계는 독립적으로 실행되며, 병렬 실행이 가능한 단계는 동시에 처리해 전체 실행 시간을 줄입니다. 일반적인 목표는 CI 전체(빌드+테스트)를 10분 이내에 완료하는 것입니다.

각 단계를 실행하며 파이프라인의 흐름을 직접 체험해 보세요.

Inject Failure:
Source
→
Build
→
Test
→
Security
→
Staging
→
Production

각 단계 카드를 클릭하면 세부 정보를 볼 수 있습니다

3. GitHub Actions로 보는 파이프라인 코드

꼬리질문: "GitHub Actions로 파이프라인을 어떻게 구성하나요?"

파이프라인은 결국 YAML 파일 하나입니다. GitHub Actions는 현재 가장 널리 쓰이는 CI/CD 도구로, .github/workflows/ 디렉토리에 워크플로 파일을 추가하는 것만으로 파이프라인을 구성할 수 있습니다.

각 job이 파이프라인의 스테이지에 해당하고, needs 키워드로 의존 관계를 선언합니다. environment: production 설정이 수동 승인 게이트를 구현합니다.

실제 워크플로 코드를 살펴보며 각 설정의 의미를 확인해 보세요.

name: CI/CD Pipeline
 
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
 
jobs:
  build-and-test:
    runs- ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-versi '21'
      - name: Build & Test
        run: ./gradlew build
 
  deploy-staging:
     build-and-test
     github.ref == 'refs/heads/develop'
    runs- ubuntu-latest
    steps:
      - name: Deploy to Staging
        run: kubectl set image deployment/app \
               app=myapp:${{ github.sha }}
 
  deploy-producti
     deploy-staging
     github.ref == 'refs/heads/main'
     production
    runs- ubuntu-latest
    steps:
      - name: Deploy to Production
        run: kubectl apply -f k8s/production/

노란색 키워드를 클릭하면 설명을 볼 수 있습니다

키워드를 클릭하면

설명이 표시됩니다

4. 무중단 배포 전략 — Blue-Green, Canary, Rolling

꼬리질문: "Blue-Green, Canary, Rolling 배포 전략의 차이를 설명해주세요"

서비스를 중단하지 않고 새 버전을 배포하는 것은 CI/CD의 핵심 요구사항입니다. 세 가지 주요 전략은 각각 다른 방식으로 이 문제를 해결하며, 속도·비용·리스크 간 트레이드오프가 다릅니다.

Blue-Green은 동일한 환경 두 벌을 유지하며 트래픽을 한 번에 전환합니다. Canary는 신버전을 일부 트래픽에만 먼저 노출해 검증합니다. Rolling은 기존 인스턴스를 하나씩 순차 교체합니다.

각 전략의 동작 방식과 트레이드오프를 직접 비교해 보세요.

동일한 환경 두 벌을 유지하며 로드밸런서가 트래픽을 한 번에 전환합니다.

Blue 환경Active
v1.0
v1.0
v1.0
v1.0
Green 환경
—
—
—
—
트래픽:
Blue 100%
Green 0%

장점

  • + 즉각적인 롤백 가능
  • + 제로 다운타임

단점

  • − 인프라 비용 2배
  • − 긴 전환 준비 시간

인프라 비용

높음

5. DevOps 성과 측정 — DORA 4대 메트릭

꼬리질문: "DevOps 성과를 어떻게 측정하나요?"

파이프라인을 구축했다면 그 효과를 어떻게 측정할까요? Google이 수천 개 팀을 분석해 도출한 DORA(DevOps Research and Assessment) 메트릭은 DevOps 성과를 측정하는 업계 표준입니다.

흥미로운 점은 4가지 지표가 모두 상관관계가 있다는 것입니다. 배포를 자주 할수록 변경 크기가 작아지고, 변경 실패율이 낮아지며, 장애 복구도 빨라집니다. CI/CD 자동화는 이 선순환을 만드는 핵심 도구입니다.

우리 팀의 DORA 메트릭 수준을 직접 확인해 보세요.

Deployment Frequency

배포 빈도

하루 여러 번

완전 자동화 파이프라인, 소규모 변경 단위

Lead Time for Changes

변경 리드 타임

1시간 미만

커밋 직후 자동 배포, 테스트 병렬화

Change Failure Rate

변경 실패율

0 ~ 15%

자동화 테스트 + Feature Flag 적극 활용

Time to Restore

복구 시간

1시간 미만

자동 롤백, 즉각 알림, 빠른 핫픽스 파이프라인

엘리트 팀 달성!

4가지 메트릭 모두 엘리트 수준 — 하루 여러 번 배포하고 1시간 이내 복구합니다

각 메트릭의 성과 레벨을 클릭해 수치와 특성을 비교해보세요

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 CI/CD 질문은 준비 완료입니다.

  • - CI: 커밋마다 자동 빌드·테스트로 통합 오류를 조기 발견
  • - CD: Delivery(수동 승인 포함)와 Deployment(완전 자동화)로 나뉨
  • - 파이프라인: Source → Build → Test → Security → Staging → Production, 앞 단계 실패 시 중단
  • - 배포 전략: Blue-Green(즉각 전환), Canary(점진적), Rolling(순차 교체) — 비용·리스크·속도 트레이드오프
  • - DORA 메트릭: 배포 빈도, 변경 리드 타임, 변경 실패율, 복구 시간 4대 지표

참고 자료

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.

0 / 1000