1. CI/CD 개요

소프트웨어 개발은 단순히 코드를 작성하는 것으로 끝나지 않는다.

개발이 완료된 애플리케이션은 빌드(Build), 테스트(Test), 배포(Deploy)를 거쳐 실제 사용자에게 제공된다.

과거에는 이러한 작업을 사람이 직접 수행했지만, 서비스 규모가 커지고 배포 주기가 짧아지면서 자동화의 필요성이 커졌고, 이를 해결하기 위해 등장한 개념이 CI/CD이다.

이번 글에서는 CI/CD의 개념부터 실무에서 어떻게 활용되는지, 그리고 DevOps와 DevSecOps와는 어떤 관계가 있는지 알아보겠다.

왜 CI/CD가 등장했을까?

과거에는 개발자가 코드를 완성하면 운영 담당자가 직접 서버에 접속하여 파일을 복사하고 서비스를 재시작하는 방식으로 배포를 진행했다. 이러한 수동 배포는 시간이 오래 걸리고 사람의 실수로 인한 장애가 발생하기 쉬웠다. 또한 배포 횟수가 많아질수록 운영 부담도 함께 증가했다.

CI/CD란?

CI/CD는 소프트웨어의 빌드, 테스트, 배포 과정을 자동화하여 더 빠르고 안정적으로 서비스를 제공하기 위한 개발 방식이다.

개발자가 코드를 저장소에 반영하면 미리 정의된 파이프라인이 실행되어 반복적인 작업을 자동으로 수행한다.

많은 사람들이 CI/CD를 하나의 기술이나 도구라고 생각하지만, 실제로는 자동화된 개발 및 배포 프로세스 를 의미하며 GitHub Actions, Jenkins와 같은 도구는 이를 구현하기 위한 수단이다.

CI/CD 전체 흐름

일반적인 CI/CD 파이프라인은 아래와 같은 순서로 동작한다.

Developer
      │
 Git Push
      │
     CI
(Build / Test)
      │
 Artifact
      │
     CD
(Deploy)
      │
 Production

개발자가 코드를 저장소에 Push하면 CI 과정에서 코드가 검증되고, 문제가 없다면 CD 과정을 통해 운영 환경까지 자동으로 배포된다.

CI/CD 파이프라인은 어떻게 동작할까?

앞에서 개발자가 코드를 Push하면 CI가 실행된다고 설명했는데, 그렇다면 어떤 작업을 수행해야 하는지는 누가 결정하는 것일까?
정답은 파이프라인 정의 파일(Pipeline as Code) 이다.

CI/CD는 미리 정해진 순서대로 동작하는 것이 아니라, 개발자가 작성한 파이프라인 정의 파일을 읽어 그 내용대로 Build, Test, Deploy 등을 수행한다. 즉, CI/CD 프로세스도 코드처럼 관리(Code as Configuration)할 수 있다.

예를 들어 Python 프로젝트라면 pytest를 실행하도록 작성할 수 있고,

Java 프로젝트라면 Gradle Build와 JUnit Test를 수행하도록 작성할 수 있다.

즉, 프로젝트의 언어와 목적에 따라 CI/CD 과정은 얼마든지 달라질 수 있다.

왜 대부분 YAML 파일을 사용할까?

대부분의 CI/CD 도구는 파이프라인을 YAML(YAML Ain't Markup Language) 형식으로 작성한다.

YAML은 사람이 읽기 쉽고 계층 구조를 표현하기 편하기 때문에 복잡한 자동화 작업을 정의하기에 적합하다. 또한 Git으로 함께 버전 관리할 수 있어 파이프라인 변경 이력까지 코드와 동일하게 관리할 수 있다는 장점이 있다.

예를 들어 GitHub Actions에서는 다음과 같이 Workflow를 작성한다.

name: CI

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - run: pip install -r requirements.txt

      - run: pytest

이 파일에는 언제 실행할지(Event), 어떤 환경에서 실행할지(Runner), 어떤 작업을 수행할지(Steps)가 모두 정의되어 있다.

즉, 위와 같이 작성하면 GitHub에 코드를 Push했을 때 Ubuntu 환경이 생성되고, 저장소를 가져온 뒤 Python 의존성을 설치하고 pytest를 실행하여 프로젝트가 정상적으로 동작하는지 자동으로 검증한다.

파이프라인 파일은 어디에 있을까?

파이프라인 정의 파일은 일반적으로 프로젝트 저장소 내부에 함께 존재한다.

예를 들어 GitHub Actions는 아래와 같은 구조를 사용한다.

my-project/

├── app.py
├── Dockerfile
├── requirements.txt
└── .github/
    └── workflows/
        ├── ci.yml
        └── deploy.yml

개발자가 코드를 Push하면 GitHub는 .github/workflows/ 폴더를 자동으로 확인한 뒤, 해당 Workflow 파일을 읽어 정의된 작업을 순서대로 실행한다.

즉, 별도의 설정 없이도 저장소 안에 있는 파이프라인 파일을 기반으로 자동화가 이루어진다.

파일 이름도 정해져 있을까?

파일 이름 규칙은 사용하는 CI/CD 도구마다 다르다.

GitHub Actions는 .github/workflows/ 폴더만 고정되어 있으며, 파일 이름은 ci.yml, deploy.yml, backend.yml 등 자유롭게 지정할 수 있다.

반면 GitLab CI는 프로젝트 최상위에 .gitlab-ci.yml 이라는 이름을 사용해야 하며, Jenkins는 Jenkinsfile 이라는 고정된 파일명을 사용한다.

도구	파일 위치	파일명
GitHub Actions	.github/workflows/	자유 (*.yml, *.yaml)
GitLab CI/CD	프로젝트 루트	.gitlab-ci.yml
Jenkins	프로젝트 루트	Jenkinsfile

즉, CI/CD 도구는 약속된 위치의 파이프라인 정의 파일을 자동으로 찾아 실행하며, 개발자는 그 파일만 수정하여 Build, Test, Deploy 과정을 자유롭게 변경할 수 있다.

2. CI (Continuous Integration)

CI란?

CI(Continuous Integration)는 여러 개발자가 작성한 코드를 하나의 저장소에 지속적으로 통합하고 자동으로 검증하는 과정이다. 코드를 자주 병합하고 즉시 빌드와 테스트를 수행하여 오류를 빠르게 발견하는 것이 목적이다.

왜 CI가 필요할까?

개발자가 각자 오랫동안 코드를 수정한 뒤 한 번에 병합하면 충돌이 발생하거나 예상하지 못한 오류가 생길 가능성이 높다. CI는 작은 단위로 자주 통합하고 자동 검증을 수행하여 이러한 문제를 미리 발견하고 수정할 수 있도록 도와준다.

CI의 핵심 원칙

CI는 단순히 자동 빌드만 수행하는 것이 아니라 몇 가지 핵심 원칙을 기반으로 한다.

• 작은 단위로 자주 Commit
• 코드 변경 사항을 지속적으로 Merge
• 자동 Build 수행
• 자동 Test 수행
• 빠른 피드백 제공

이러한 원칙을 통해 코드 품질을 유지하면서 안정적으로 개발을 진행할 수 있다.

CI 과정

일반적인 CI 과정은 다음과 같다.

Git Push
    │
Build
    │
Unit Test
    │
Lint
    │
Dependency Check
    │
Artifact 생성

빌드와 테스트를 통해 코드의 정상 동작 여부를 확인하고, 문제가 없다면 배포 가능한 결과물(Artifact)을 생성한다.

대표 CI 도구

대표적인 CI 도구는 다음과 같다.

• GitHub Actions
• Jenkins
• GitLab CI/CD

각 도구는 실행 방식에는 차이가 있지만 모두 코드 변경을 감지하여 빌드와 테스트를 자동으로 수행하는 역할을 한다.

3. CD (Continuous Delivery / Continuous Deployment)

CD란?

CD는 CI를 통해 검증된 결과물을 실제 운영 환경에 배포하는 과정이다. CD는 Continuous Delivery와 Continuous Deployment라는 두 가지 의미로 사용되므로 이를 구분해서 이해하는 것이 중요하다.

Continuous Delivery

Continuous Delivery는 빌드와 테스트를 모두 자동으로 수행하지만 실제 운영 환경 배포는 운영자의 승인을 받은 후 진행하는 방식이다. 기업 환경에서는 안정성을 위해 이 방식을 가장 많이 사용한다.

Build
   │
Test
   │
Artifact
   │
승인
   │
Deploy

Continuous Deployment

Continuous Deployment는 별도의 승인 과정 없이 테스트가 모두 통과하면 운영 환경까지 자동으로 배포하는 방식이다. 빠른 배포가 중요한 SaaS 서비스나 스타트업에서 많이 활용된다.

Build
   │
Test
   │
Artifact
   │
Deploy

두 방식의 차이

Continuous Delivery	Continuous Deployment
운영자 승인 후 배포	승인 없이 자동 배포
안정성 중심	속도 중심
기업 환경에서 많이 사용	SaaS 환경에서 많이 사용

대표 CD 도구

대표적인 CD 도구는 다음과 같다.

• Argo CD
• Flux CD
• GitHub Actions
• Jenkins

이러한 도구들은 검증이 완료된 애플리케이션을 운영 환경에 자동으로 배포하는 역할을 수행한다.

4. 실무 CI/CD Pipeline

전체 파이프라인

실무에서는 단순히 빌드와 배포만 수행하지 않는다. 보안 검사, 컨테이너 생성, 인프라 구성, 모니터링까지 하나의 파이프라인으로 자동화하는 경우가 많다.

GitHub Actions

GitHub Actions는 GitHub에서 제공하는 CI/CD 자동화 서비스이다. 특정 이벤트(Push, Pull Request 등)가 발생하면 미리 작성한 Workflow를 실행하여 빌드, 테스트, 배포를 자동으로 수행할 수 있다.

Docker

Docker는 애플리케이션과 실행 환경을 하나의 이미지로 만들어 어디서나 동일한 환경에서 실행할 수 있도록 해준다. CI에서는 이미지를 생성하고, CD에서는 생성된 이미지를 배포하는 데 활용된다.

Registry

생성된 Docker 이미지는 Registry에 저장된다. 대표적으로 Docker Hub, Amazon ECR, Harbor 등이 있으며, 운영 서버는 Registry에서 이미지를 가져와 실행한다.

Terraform

Terraform은 Infrastructure as Code(IaC) 도구로, 서버와 네트워크 같은 인프라를 코드로 관리할 수 있다. CI/CD와 연계하면 애플리케이션뿐 아니라 인프라 생성과 변경도 자동화할 수 있다.

Kubernetes

Kubernetes는 컨테이너를 관리하는 오케스트레이션 플랫폼이다. 새로운 버전의 애플리케이션을 Rolling Update 방식으로 배포하고 장애가 발생한 컨테이너를 자동으로 복구하는 기능을 제공한다.

Monitoring & Rollback

배포가 끝났다고 모든 과정이 종료되는 것은 아니다. Prometheus, Grafana와 같은 모니터링 도구를 통해 서비스 상태를 지속적으로 확인하고, 문제가 발생하면 이전 버전으로 Rollback하여 빠르게 서비스를 복구한다.

5. DevOps와 DevSecOps

DevOps란?

DevOps는 Development(개발)와 Operations(운영)를 결합한 개념으로, 개발부터 운영까지의 과정을 협업과 자동화를 통해 효율적으로 관리하는 개발 문화이자 운영 방식이다.

CI/CD는 DevOps를 구현하기 위한 핵심 요소 중 하나이며, IaC, 모니터링, 로깅 등과 함께 활용된다.

DevOps
 ├── CI/CD
 ├── IaC
 ├── Monitoring
 ├── Logging
 └── Automation

즉, CI/CD는 DevOps를 구성하는 여러 요소 중 하나이며, DevOps는 그보다 더 넓은 개념이다.

DevSecOps란?

DevSecOps는 DevOps에 Security(보안)를 통합한 개념이다. 기존에는 배포 이후 보안을 점검했다면, DevSecOps는 개발부터 배포까지의 전 과정에 보안 검사를 포함하여 취약점을 조기에 발견하고 수정하는 것을 목표로 한다.

예를 들어 코드 품질 검사(SAST), 오픈소스 의존성 검사, Secret 검사, 컨테이너 이미지 검사 등을 CI/CD 파이프라인에 포함하여 보다 안전한 소프트웨어를 제공한다.

마무리

CI는 코드를 지속적으로 통합하고 자동으로 검증하는 과정이며, CD는 검증된 결과물을 운영 환경에 안전하게 배포하는 과정이다. 이러한 자동화 체계를 통해 더 빠르고 안정적인 소프트웨어 제공이 가능하며, 최근에는 DevOps와 DevSecOps 문화와 결합하여 개발부터 운영, 보안까지 하나의 파이프라인으로 관리하는 것이 일반적인 방식이 되고 있다.