CI/CD 기초와 핵심 개념

CI/CD의 개념을 이해하고, 대표적인 도구들의 특징을 비교해보자.

---

1. 이번 섹션 내용

챕터 2는 CI/CD를 중심으로, AWS 클라우드 서비스와 연계한 자동화 배포 파이프라인 구축을 목표로 한다.

학습 로드맵은 다음과 같다.

챕터	주제
2-1	오리엔테이션 (전체 흐름 파악)
2-2	CI/CD 개념과 도구 소개
2-3	Amazon ECS 이해
2-4	실습 개요
2-5 ~ 2-9	GitLab, AWS 보안그룹/ECR/ECS/IAM 설정
2-10	GitLab CI 파일 작성 및 푸시
2-11	결과 확인
2-12	추가 정보 (GitHub Actions)

⚠️ AWS 비용 주의
실습 후에는 반드시 사용한 AWS 서비스(ECS, ECR, EC2 등)를 중지해야 한다. 방치하면 예상치 못한 비용이 청구될 수 있다.

---

2. CI/CD란 무엇인가

처음 이 개념을 접했을 때, "왜 이게 필요하지?"라는 의문이 먼저 들었다. 코드를 작성하고 수동으로 빌드하고 서버에 올리면 되는 거 아닌가 싶었다.

그런데 팀 단위로 개발이 진행되고, 하루에도 수십 번씩 코드가 바뀌는 상황을 상상해보면 이야기가 달라진다. 그 모든 변경사항을 일일이 수작업으로 테스트하고 배포하는 건 현실적으로 불가능하다. 그래서 나온 개념이 CI/CD이다.

---

2.1 CI (Continuous Integration) — 지속적 통합

CI란, 개발자가 작성한 코드를 자주, 자동으로 통합하고 테스트하는 프로세스이다.

코드 변경이 발생할 때마다 빌드와 테스트가 자동으로 실행되어, 문제를 조기에 발견할 수 있다.

예를 들어, A 개발자와 B 개발자가 동시에 코드를 수정했을 때, 두 코드를 합쳤을 때 충돌이 생기진 않는지 자동으로 검증해주는 것이 CI의 핵심 역할이다.

개발자 코드 Push
        ↓
  자동 빌드 실행
        ↓
  자동 테스트 실행
        ↓
  결과 피드백 (성공 / 실패)

---

2.2 CD (Continuous Delivery / Continuous Deployment) — 지속적 배포

CD는 CI를 통과한 코드를 자동으로 배포하는 프로세스이다.

여기서 CD에는 두 가지 개념이 혼용된다.

용어	의미
Continuous Delivery (지속적 전달)	스테이징(staging, 실제 서비스와 유사한 테스트 환경) 환경까지 자동 배포. 프로덕션 배포는 수동 승인 필요
Continuous Deployment (지속적 배포)	승인 없이 프로덕션까지 완전 자동 배포

두 단어가 같은 약자(CD)를 쓰기 때문에 처음엔 헷갈릴 수 있다. 맥락에 따라 어느 쪽을 의미하는지 파악하는 것이 중요하다. 대부분의 팀은 Continuous Delivery 방식을 채택하여, 프로덕션 배포 직전에 사람이 한 번 검토하는 단계를 둔다.

---

2.3 전체 파이프라인 흐름

파이프라인(Pipeline)이란 각 단계가 순서대로 연결된 자동화 프로세스를 말한다. 마치 공장의 컨베이어 벨트처럼, 이전 단계가 성공해야 다음 단계로 넘어간다.

코드 Push (Git)
      ↓
   [CI 단계]
   빌드 (Build)
      ↓
   테스트 (Test)
      ↓
   코드 분석 (Code Analysis)
      ↓
   [CD 단계]
   스테이징 배포 (Staging Deploy)
      ↓
   (승인 or 자동)
      ↓
   프로덕션 배포 (Production Deploy)

---

3. CI/CD를 도입하면 무엇이 좋아지나

장점	설명
빠른 피드백	코드 Push 즉시 빌드/테스트 결과를 확인할 수 있다
자동화된 프로세스	수동 배포 작업이 줄어들고 인적 오류(Human Error)가 감소한다
일관된 배포	개발/테스트/스테이징/프로덕션 모든 환경에서 동일한 프로세스로 배포된다
높은 코드 품질	잠재적 버그를 조기에 발견하고 수정할 수 있다
개발 속도 향상	자동화된 파이프라인 덕분에 새 기능을 더 빠르게 사용자에게 전달할 수 있다

DORA(DevOps Research and Assessment) 보고서에 따르면, CI/CD를 성숙하게 운영하는 조직은 그렇지 않은 조직 대비 코드 배포 빈도가 약 200배 높고, 장애 복구 시간이 약 24배 짧다고 한다.

---

4. 대표적인 CI/CD 도구 비교

현 시점(2026년 기준)에서 가장 많이 사용되는 도구 세 가지를 살펴보겠다.

4.1 GitHub Actions

GitHub 저장소에 내장된 CI/CD 도구로, YAML 파일로 워크플로우(Workflow, 자동화 작업 흐름)를 정의한다.

주요 특징

• GitHub 저장소와 완벽하게 통합되어 있어 별도 설정이 거의 불필요하다
• 이벤트 기반 트리거 (Push, PR, 스케줄 등)를 지원한다
• Marketplace에 15,000개 이상의 재사용 가능한 Action이 등록되어 있다
• 무료 플랜 기준 월 1,500분의 실행 시간을 제공한다 (2026년 기준, 이전 2,000분에서 축소)

언제 쓰면 좋은가

코드가 이미 GitHub에 있고, 복잡한 인프라 없이 빠르게 CI/CD를 시작하고 싶은 팀에 최적이다. 오픈소스 프로젝트의 68%가 GitHub Actions를 사용하고 있을 만큼 현재 가장 빠르게 성장하고 있는 도구이다.

# .github/workflows/deploy.yml 예시
name: Deploy Pipeline  # 워크플로우 이름

on:
  push:
    branches: [main]  # main 브랜치에 Push될 때 실행

jobs:
  build-and-test:
    runs-on: ubuntu-latest  # 실행 환경 (GitHub가 제공하는 가상 머신)
    steps:
      - uses: actions/checkout@v4       # 저장소 코드를 가져오는 Action
      - name: Build
        run: ./gradlew build            # Gradle 빌드 실행
      - name: Test
        run: ./gradlew test             # 테스트 실행

---

4.2 Jenkins

오픈소스 CI/CD 도구의 원조로, 1,800개 이상의 플러그인(Plugin, 기능 확장 모듈)으로 거의 모든 환경에 대응 가능하다.

주요 특징

• 온프레미스(On-premises, 자체 서버에 직접 설치하여 운영) 또는 클라우드 모두 지원
• 플러그인 생태계가 방대하여 커스터마이징이 자유롭다
• 대규모 분산 빌드, 복잡한 멀티 환경 파이프라인에 강하다
• 오래된 레거시 환경과의 연동이 용이하다

2026년 현황

Jenkins는 시장 점유율이 점차 줄고 있지만(-8% YoY), Fortune 500 기업의 80%가 아직도 Jenkins를 핵심 CI/CD 도구로 사용하고 있다. 특히 규정 준수(Compliance)가 엄격하거나, 외부 인터넷이 차단된 환경(Air-gapped)에서는 Jenkins가 사실상 유일한 선택지이다.

참고 : 많은 팀이 기존 Jenkins 파이프라인을 유지하면서 신규 프로젝트를 점진적으로 GitHub Actions로 전환하고 있다. 이 전환 과정이 몇 달에서 몇 년씩 걸리기도 하니, Jenkins를 배워두는 것은 여전히 가치 있다.

// Jenkinsfile 예시 (Declarative Pipeline 문법)
pipeline {
    agent any  // 사용 가능한 어떤 에이전트(실행 노드)에서든 실행

    stages {
        stage('Build') {       // 빌드 단계
            steps {
                sh './gradlew build'  // shell 명령어 실행
            }
        }
        stage('Test') {        // 테스트 단계
            steps {
                sh './gradlew test'
            }
        }
        stage('Deploy') {      // 배포 단계
            steps {
                sh 'docker build -t myapp .'
                sh 'docker push myregistry/myapp'
            }
        }
    }
}

---

4.3 GitLab CI

GitLab 저장소에 통합된 CI/CD 도구로, .gitlab-ci.yml 파일 하나로 전체 파이프라인을 정의한다. 이번 강의에서 직접 실습할 도구이다.

주요 특징

• GitLab 내에서 코드 관리, 이슈 추적, CI/CD, 컨테이너 레지스트리까지 한 번에 처리 가능
• SAST(정적 코드 보안 분석), DAST(동적 보안 분석) 등 보안 스캔이 파이프라인에 내장
• 클라우드(GitLab.com) 또는 자체 서버(Self-hosted) 모두 지원
• Runner(파이프라인 실행 에이전트)를 직접 구성하여 사용할 수 있다

2026년 현황

GitLab CI는 엔터프라이즈(Enterprise, 대기업/중견기업 규모의 조직) 환경에서 전년 대비 34% 성장하고 있다. 보안 기능이 강화되고 올인원(All-in-One) 플랫폼으로서의 완성도가 높아지면서, DevSecOps(개발-보안-운영 통합) 환경을 구축하려는 팀에서 특히 선호된다.

# .gitlab-ci.yml 예시
stages:           # 파이프라인 단계 순서 정의
  - build
  - test
  - deploy

build-job:
  stage: build    # 위에서 정의한 build 단계에 속함
  image: gradle:8-jdk21  # 사용할 Docker 이미지
  script:
    - ./gradlew build    # 실행할 명령어

test-job:
  stage: test
  script:
    - ./gradlew test

deploy-job:
  stage: deploy
  script:
    - docker build -t $CI_REGISTRY_IMAGE .     # GitLab CI 내장 변수 사용
    - docker push $CI_REGISTRY_IMAGE
  only:
    - main  # main 브랜치일 때만 배포

---

5. 도구 선택 기준 정리

세 가지를 비교하고 나면 "그래서 뭘 써야 하나?"라는 질문이 남는다. 간단한 기준을 정리해보았다.

상황	추천 도구
코드가 GitHub에 있고, 빠르게 시작하고 싶다	GitHub Actions
복잡한 엔터프라이즈 환경, 레거시 시스템 연동 필요	Jenkins
코드 관리부터 배포까지 하나의 플랫폼으로 통합하고 싶다	GitLab CI
코드가 GitLab에 있다	GitLab CI (자연스러운 선택)
보안 요구사항이 엄격한 환경	Jenkins (온프레미스) 또는 GitLab CI

참고 : 실제로 많은 조직이 도구를 하나만 쓰지 않는다. 팀마다 Jenkins, GitHub Actions, GitLab CI를 혼용하는 경우도 흔하다. JetBrains의 2025 설문에 따르면, 기업의 32%가 두 가지 이상의 CI/CD 도구를 동시에 사용하고 있다.

---

6. 정리하며

이번 챕터는 본격적인 실습에 앞서 전체 흐름을 이해하는 오리엔테이션 성격이 강하다.

핵심을 한 줄로 요약하면 이렇다.

CI/CD는 코드 변경 → 빌드 → 테스트 → 배포까지의 과정을 자동화하여, 더 빠르고 안정적인 소프트웨어 배포를 가능하게 하는 방법론이다.

다음 챕터부터는 Amazon ECS, GitLab, AWS ECR/IAM 등을 활용한 실제 파이프라인 구축으로 넘어간다. 개념을 잘 잡아두면 이후 실습이 훨씬 수월하게 느껴질 것이다.

---

참고 자료

• DevOps Engineering in 2026: Top CI/CD Tools, Trends, and Best Practices — Refonte Learning
• Jenkins vs GitHub Actions vs GitLab CI – A Guide to CI/CD in 2026 — EITT Academy
• The State of CI/CD in 2025 — JetBrains TeamCity Blog
• Jenkins vs GitHub Actions vs GitLab CI (2026) — SquareOps
• CI/CD Decision Guide in 2026 — TechnologyMatch