[CI/CD] 지속적 통합 / 지속적 배포

CI/CD 란?

1. CI (Continuous Integration) / 지속적 통합

CI(Continuous Integration, 지속적 통합)는 개발 과정에서 코드 변경 사항을 자주 통합하고, 그때마다 빌드와 테스트를 자동으로 수행하여 문제를 빠르게 발견하는 개발 방식이다.

1) 필요한 이유

여러 개발자가 동시에 작업할 경우, 각자의 코드가 로컬 환경에서는 정상적으로 작동하더라도 공유 브랜치에 통합되는 과정에서 빌드 오류, 테스트 실패, 기능 간 비호환 문제 등이 발생할 수 있다.

CI는 이러한 문제를 조기에 발견하고, 공용 코드의 품질을 일정하게 유지하기 위해 사용된다.

2) CI의 핵심

코드의 변경 사항을 자주 통합하고, 통합 과정에서 빌드와 테스트를 자동으로 수행한다.

문제가 발생했을 때 이를 빠르게 감지하고 수정할 수 있도록 하여 공용 브랜치의 안정성을 높인다.

 

CI는 단순히 컴파일만 확인하는 과정이 아니라, 빌드, 테스트, 정적 분석, 코드 스타일 검사 등을 함께 수행하여 변경 사항이 전체 시스템에 문제를 일으키지 않는지 검증하는 과정이다.

 

CI가 제대로 작동하려면 신뢰할 수 있는 자동화된 테스트 코드(Unit Test, Integration Test 등)가 뒷받침되어야 한다.

3) CI의 동작 흐름

CI는 보통 개발자가 기능 브랜치에서 작업한 뒤 코드를 push 하거나 Pull Request를 생성하는 시점에 실행된다.

이때 CI 도구는 미리 정의된 환경에서 소스 코드를 가져와 빌드, 테스트, 정적 분석 등을 자동으로 수행한다.

 

검증이 모두 성공하면 해당 변경 사항은 공유 브랜치와 통합할 준비가 된 것으로 볼 수 있다. 반대로 빌드 오류나 테스트 실패가 발생하면, 개발자는 CI가 제공하는 로그와 결과를 통해 문제를 확인하고 수정할 수 있다.

 

이러한 과정을 반복함으로써, CI는 코드 변경 사항이 누적될 때 발생할 수 있는 문제를 조기에 발견하고 공용 브랜치의 안정성을 유지하도록 돕는다.

 

이처럼 CI를 통해 안전하게 검증되고, 병합(Merge)된 코드를, 실제 서비스 환경이나 테스트 환경으로 전달하고 배포하는 과정이 바로 CD(Continuous Delivery/Deployment)다.

---

2. CD (Continuous Delivery / Continuous Deployment) / 지속적 서비스 제공, 지속적 배포

앞서 언급했던, CI(Continous Integration)과 다르게 CD는 보통 Continuous Delivery와 Continuous Deployment를 함께 가리키는 표현으로 사용된다.
두 개념은 모두 CI 이후의 배포 과정을 다룬다는 공통점이 있지만, 실제 운영 환경까지 자동으로 반영하는지 여부에서 차이가 있다.  

1) Delivery와 Deployment의 차이

Continuous Delivery는 검증된 결과물을 언제든 배포할 수 있는 상태로 유지하는 것을 의미한다.

이 경우 배포 준비 과정은 자동화되어 있지만, 실제 운영 반영은 사람의 승인이나 수동 실행을 통해 이루어질 수 있다.

 

Continuous Deployment는 검증이 끝난 결과물을 실제 운영 환경까지 자동으로 반영하는 것을 의미한다.

즉, 테스트와 검증이 통과되면 사람의 개입 없이 운영 배포까지 자동으로 진행된다.

 

※ 실제 서비스에서는 자동 배포를 제한하는 경우가 있다. 예를 들어, 게임 서비스에서는 이벤트 시작 시점이나 점검 일정에 맞춰 배포해야 하는 경우가 많기 때문에, 배포 준비까지는 자동화하더라도 실제 배포는 수동으로 진행하는 경우가 있다. 이처럼 기술적으로는 배포가 가능하더라도 운영 시점에 대한 판단이 필요하다면, Continuous Deployment보다는 Continuous Delivery에 가까운 방식으로 운영될 수 있다.

 

2) CD의 핵심

CI를 통해 검증된 결과물을 배포 가능한 상태로 유지하거나, 필요 시 실제 운영 환경까지 일관된 방식으로 반영할 수 있도록 자동화하는 데 있다. 

이를 통해 배포 과정에서 발생할 수 있는 수작업 실수와 반복 작업을 줄이고, 더 안정적이고 예측 가능한 배포를 가능하게 한다.

CD는 검증된 결과물이 동일한 절차를 통해 스테이징 또는 운영 환경으로 전달되도록 만드는 과정에 가깝다.

또한 실제 서비스에서는 운영 일정, 승인 절차, 이벤트 시점 등의 이유로 자동 배포를 제한할 수 있으므로, CD는 배포 전 과정을 모두 자동화하는 것이라기보다 배포를 신뢰성 있게 이어갈 수 있는 흐름을 만드는 것에 더 가깝다.

3) CD의 동작 흐름

 

CD는 CI를 통해 검증된 결과물을 배포 단계로 이어주는 과정이다. 일반적으로 빌드와 테스트가 완료되면 배포 가능한 결과물이 생성되고, 이후 스테이징 환경이나 운영 환경에 반영된다. 이때 실제 운영 반영 전에 사람의 승인이나 일정 조정이 필요하다면 Continuous Delivery에 가깝고, 별도의 개입 없이 자동으로 운영 환경까지 배포된다면 Continuous Deployment에 가깝다.

---

3. 정리

CI는 코드 변경 사항을 자주 통합하는 과정에서 빌드와 테스트를 자동으로 수행하여 문제를 조기에 발견하는 데 초점이 있다. 반면 CD는 이렇게 검증된 결과물을 실제 배포 단계까지 안정적으로 이어주는 과정에 가깝다.

CD는 Continuous Delivery와 Continuous Deployment로 나뉘며, 두 개념의 핵심 차이는 실제 운영 환경까지 자동으로 반영하는지 여부에 있다. 실제 서비스에서는 운영 일정, 점검 시간, 이벤트 시점, 외부 승인 절차 등의 이유로 완전한 자동 배포를 적용하지 않는 경우도 많기 때문에, 상황에 따라 Continuous Delivery 방식이 더 현실적일 수 있다. 

결국 CI/CD는 단순히 자동화 도구를 사용하는 것을 의미하는 것이 아니라, 코드 변경부터 검증, 배포에 이르는 과정을 더 일관되고 안정적으로 관리하기 위한 개발 방식이라고 볼 수 있다.

 

사실 지금까지 CI/CD에 대해 깊게 생각해 볼 기회는 많지 않았다. 이전 직장에서는 Jenkins를 이용해 배포를 진행했지만, 당시에는 배포 자동화의 전체 흐름이나 PR 단계에서 어떤 검증이 수행되었는지까지는 충분히 이해하지 못했던 것 같다. 앞으로는 작은 프로젝트를 통해 테스트 코드 작성, 빌드 자동화, 간단한 배포 자동화까지 직접 구성해 보면서 CI/CD 흐름을 더 익혀보고 싶다.

 

---

4. 출처

Red Hat, CI/CD(지속적 통합/지속적 배포)란?, https://www.redhat.com/ko/topics/devops/what-is-ci-cd , 접속일 2026.03.30