1. CI/CD는 왜 필요할까?

개발자가 코드를 작성했다고 해서 바로 사용자에게 서비스를 제공할 수 있는 것은 아니다.

일반적으로 다음과 같은 과정이 필요하다.

코드 작성
 ↓
빌드
 ↓
테스트
 ↓
배포 파일 생성
 ↓
서버 배포

이 과정을 사람이 매번 직접 수행하면

- 테스트 누락

- 잘못된 버전 배포

- 배포 과정 실수

- 개발자마다 다른 배포 방식

같은 문제가 발생할 수 있다.

또 여러 개발자가 하나의 프로젝트를 개발하면 각자의 코드를 합쳤을 때 문제가 없는지도 계속 확인해야 한다.

Developer A ─┐
             ├→ 코드 통합
Developer B ─┤
             │
Developer C ─┘

→ 빌드가 되는가?
→ 테스트가 성공하는가?
→ 서로 충돌하지 않는가?

따라서 코드의 통합, 빌드, 테스트, 배포 과정을 자동화할 필요가 있다.

이것이 CI/CD의 핵심이다.

2. CI란?

CI는 Continuous Integration, 즉 지속적 통합을 의미한다.

여러 개발자가 작성한 코드 변경사항을 공유 저장소에 자주 통합하고, 변경이 발생할 때마다 자동으로 빌드와 테스트를 수행하는 방식이다.

Developer
   ↓
Git Push / Pull Request
   ↓
Repository
   ↓
Build
   ↓
Test
   ↓
성공 / 실패 Feedback

CI의 목적은 단순히 코드를 Git에 합치는 것이 아니다.

변경된 코드가

정상적으로 빌드되는가?

테스트를 통과하는가?

기존 코드와 합쳐도 문제가 없는가?

를 자동으로 검증하고 문제를 빠르게 발견하는 것이 핵심이다.

Source
  ↓
Build
  ↓
Test
  ↓
Analyze
  ↓
Artifact

3. CD란?

CI를 통해 코드가 정상적으로 동작한다는 것을 확인했다면 다음 단계는 배포이다.

CD는 두 가지 의미로 사용된다.

Continuous Delivery
Continuous Deployment

Build
 ↓
Test
 ↓
Artifact
 ↓
배포 준비 완료
 ↓
사람의 승인
 ↓
Production 배포

Build
 ↓
Test
 ↓
Artifact
 ↓
Deploy
 ↓
Production

Continuous Delivery
→ 배포 가능한 상태까지 자동화
→ 운영 배포는 사람의 승인

Continuous Deployment
→ 운영 환경 배포까지 자동화

4. CI/CD 전체 흐름

CI와 CD를 연결하면 다음과 같은 Pipeline을 만들 수 있다.

Developer
   ↓
Git Push / PR
   ↓
──────── CI ────────
   ↓
Build
   ↓
Test
   ↓
Artifact
   ↓
──────── CD ────────
   ↓
Deploy
   ↓
Production
   ↓
User

Docker를 사용하는 환경이라면

Source Code
    ↓
Build / Test
    ↓
Docker Image 생성
    ↓
Container Registry Push
    ↓
Server에 배포

같은 형태가 될 수 있다.

즉

CI는 변경된 코드를 지속적으로 검증하는 과정이고, CD는 검증된 결과물을 사용자에게 전달하는 과정이다.

5. CI/CD는 무엇으로 구현할까?

CI/CD는 하나의 기술 이름이 아니라 개발 및 배포 과정을 자동화하는 방식이다.

이를 구현하기 위해 다양한 도구를 사용할 수 있다.

GitHub Actions
Jenkins
GitLab CI/CD
ArgoCD 등

예를 들어 GitHub Actions를 사용하면 GitHub에서 Push나 Pull Request가 발생했을 때

Pull Request
     ↓
GitHub Actions
     ↓
Build
     ↓
Test
     ↓
성공 / 실패 확인

처럼 자동으로 CI Pipeline을 실행할 수 있다.

또 필요하다면 Docker Image를 만들거나 서버에 배포하는 CD 과정까지 자동화할 수도 있다.

즉 중요한 것은 특정 도구의 이름보다

어떤 이벤트가 Pipeline을 실행하는가?

어떤 Build와 Test를 수행하는가?

검증된 결과물을 어떻게 배포하는가?

를 이해하는 것이다.

6. 배포 전략은 왜 필요할까?

CD를 구축했다고 해서 기존 서버를 바로 종료하고 새 버전을 실행하면 되는 것은 아니다.

v1 종료
   ↓
서비스 중단
   ↓
v2 실행

이렇게 배포하면 서비스가 중단될 수 있고, 새로운 버전에 문제가 있다면 모든 사용자에게 영향을 줄 수도 있다.

따라서 서비스를 유지하면서 안전하게 새로운 버전을 배포하기 위한 배포 전략이 필요하다.

대표적으로

Rolling Update
Blue-Green
Canary

가 있다.

7. Rolling Update

Rolling Update는 기존 서버를 한 번에 모두 교체하지 않고 점진적으로 새로운 버전으로 변경하는 방식이다.

v1  v1  v1  v1

        ↓

v2  v1  v1  v1

        ↓

v2  v2  v1  v1

        ↓

v2  v2  v2  v2

별도의 환경을 하나 더 구성하지 않아도 되기 때문에 리소스를 효율적으로 사용할 수 있다.

다만 배포 중에는

v1 + v2

가 동시에 실행될 수 있으므로 두 버전 사이의 호환성을 고려해야 한다.

8. Blue-Green Deployment

Blue-Green은 기존 환경과 새로운 환경 두 개를 준비한 뒤 트래픽을 전환하는 방식이다.

Blue
v1
현재 운영

      ↓ 트래픽 전환

Green
v2
새 버전

새로운 Green 환경에 먼저 배포하고 문제가 없는지 확인한 뒤 트래픽을 전환한다.

문제가 발생하면 다시 Blue 환경으로 빠르게 돌릴 수 있어 Rollback이 쉽다.

반면 두 환경을 동시에 유지해야 하기 때문에 추가적인 인프라 비용이 필요할 수 있다.

9. Canary Deployment

Canary는 새로운 버전을 일부 사용자에게 먼저 배포하는 방식이다.

v1 → 95%

v2 → 5%

문제가 없는지 확인하면서

5%
 ↓
20%
 ↓
50%
 ↓
100%

처럼 새 버전의 트래픽을 점차 증가시킨다.

따라서 문제가 발생하더라도 처음에는 일부 사용자만 영향을 받기 때문에 배포 위험을 줄일 수 있다.

다만 트래픽 분배와 지속적인 모니터링이 필요해 운영이 복잡해질 수 있다.

10. 배포 전략 비교

간단하게 구분하면

서버를 하나씩 바꾼다
→ Rolling Update

새 환경을 준비하고 한 번에 전환한다
→ Blue-Green

일부 사용자에게 먼저 적용한다
→ Canary

11. 핵심 정리

전체 흐름은 다음과 같다.

코드 변경
   ↓
CI
   ↓
Build / Test
   ↓
Artifact
   ↓
CD
   ↓
Deploy
   ↓
Production

결국 CI/CD의 핵심은

개발자가 작성한 코드를 지속적으로 자동 검증하고, 검증된 결과물을 반복 가능하고 안전하게 사용자에게 전달하는 것

이라고 이해할 수 있다.