STUDY NOTE · 개념 정리
CI/CD 개념 정리: CI, Continuous Delivery, Continuous Deployment와 배포 전략
etc
CI는 코드 변경을 자주 합치고 그때마다 자동으로 빌드·테스트해 문제를 빨리 찾는 것이고, CD는 검증된 코드를 언제든(또는 자동으로) 배포할 수 있게 만드는 것이다. 핵심은 사람이 손으로 하던 반복 작업을 같은 방식으로, 자동으로 수행하게 하는 것이다.
1. 왜 필요한가
자동화가 없으면 이런 일이 생긴다.
- 각자 브랜치에서 오래 작업하다 한꺼번에 합치면 충돌과 버그가 몰려 나온다 (merge hell).
- "내 PC에서는 되는데" — 빌드 환경이 사람마다 달라 결과가 다르다.
- 배포 절차가 문서나 특정 사람의 기억에 의존해 실수가 생긴다.
- 배포가 무섭고 번거로우니 드물게 하고, 드물게 하니 한 번에 바뀌는 게 많아 더 위험해진다.
2. 용어 정리
| 구분 | CI | Continuous Delivery | Continuous Deployment |
| 뜻 | 지속적 통합 | 지속적 제공 | 지속적 배포 |
| 자동화 범위 | 빌드 + 테스트 | 빌드 + 테스트 + 배포 가능한 산출물 준비 | 운영 배포까지 전부 |
| 운영 배포 | 해당 없음 | 사람이 승인 후 (버튼) | 테스트 통과 시 자동 |
| 전제 조건 | 자동화된 테스트 | CI + 배포 자동화 | 매우 신뢰할 수 있는 테스트와 모니터링 |
CD는 문맥에 따라 Delivery와 Deployment 중 하나를 뜻한다. 둘의 차이는 운영 배포에 사람의 승인이 있느냐다.
3. 파이프라인 단계
| 단계 | 하는 일 | 실패하면 |
| 트리거 | PR 생성, main 머지, 태그, 수동 실행, 스케줄 | - |
| 체크아웃·의존성 설치 | 코드와 라이브러리 준비 (캐시 활용) | 중단 |
| 정적 분석 | lint, 포맷, 타입 체크 | 중단 |
| 테스트 | 유닛 → 통합 | 중단 |
| 빌드 | 산출물 생성 (jar, 정적 파일, 도커 이미지) | 중단 |
| 배포 | dev → stage → prod | 중단 또는 롤백 |
| 검증·알림 | 헬스 체크, 메신저 알림 | 롤백 |
빠르고 싼 검사를 앞에 둔다. lint에서 걸릴 문제를 10분짜리 통합 테스트 뒤에서 알게 되면 시간 낭비다.
4. 대표 도구
| 도구 | 특징 |
| GitHub Actions | 저장소에 YAML 파일로 정의, GitHub 이벤트와 바로 연동 |
| Jenkins | 직접 설치·운영, 플러그인이 많고 자유도가 높음 |
| GitLab CI | GitLab에 내장, .gitlab-ci.yml로 정의 |
| ArgoCD | 쿠버네티스용 GitOps 배포 도구 (Git 상태를 클러스터에 동기화) |
5. 배포 전략
| 전략 | 방식 | 장점 | 단점 |
| 재생성 (Recreate) | 기존 버전을 모두 내리고 새 버전을 올림 | 단순 | 다운타임 발생 |
| 롤링 (Rolling) | 인스턴스를 하나씩 순차 교체 | 추가 자원 적음, 무중단 | 배포 중 두 버전이 공존, 롤백이 느림 |
| 블루-그린 (Blue-Green) | 새 환경을 통째로 띄운 뒤 트래픽을 한 번에 전환 | 즉시 전환·즉시 롤백 | 자원이 두 배 필요 |
| 카나리 (Canary) | 일부 트래픽(예: 5%)만 새 버전으로 보내며 점진 확대 | 위험을 작게 검증 | 라우팅·모니터링 구성이 복잡 |
롤링과 카나리는 배포 중 구 버전과 새 버전이 동시에 요청을 받는다. 그래서 API나 DB 스키마 변경은 두 버전이 모두 동작하도록 하위 호환을 유지하며 단계적으로 배포한다(예: 컬럼 추가 → 코드 배포 → 옛 컬럼 삭제).
6. 좋은 파이프라인의 조건
| 조건 | 의미 | 방법 |
| 빠름 | 10분 넘으면 아무도 기다리지 않음 | 의존성 캐시, 병렬 실행 |
| 재현 가능 | 같은 커밋이면 같은 결과 | lock 파일 기준 설치(npm ci), 런타임 버전 고정 |
| 명확한 실패 | 문제가 있으면 멈춤 | 경고로 넘어가지 않기, 외부 데이터 조회 실패 시 빌드 실패 |
| 추적 가능 | 무엇이 배포됐는지 앎 | 이미지 태그를 latest가 아닌 커밋 SHA·버전으로 |
| 쉬운 롤백 | 이전 버전으로 바로 복구 | 이전 산출물 보관, 배포와 같은 방식으로 되돌리기 |
| 비밀 관리 | 키가 코드에 노출되지 않음 | CI 플랫폼의 Secrets 사용 |
7. 실제로 어떻게 적용되나
- PR마다 CI: PR을 올리면 lint, 테스트, 빌드가 자동으로 돌고, 실패하면 머지를 막는다(브랜치 보호 규칙). "합치기 전에 문제 발견"이라는 CI의 정의 그대로다.
- PR 미리보기 배포: 정적 사이트는 PR마다 임시 URL로 배포해 리뷰어가 실제 화면을 보고 승인할 수 있다. 이 사이트도 Firebase Hosting의 미리보기 채널을 쓴다.
- Continuous Delivery 형태의 운영 배포: dev 서버는 main 머지 시 자동 배포하고, 운영은 수동 실행 버튼(workflow_dispatch)이나 승인 단계를 거친다.
- 쿠버네티스 롤링 업데이트: 이미지 태그를 바꾸면 파드가 하나씩 교체된다. 새 파드가 아직 기동 중인데 트래픽을 받지 않도록 readiness probe를 설정해야 무중단이 된다.
8. 면접 질문으로 정리
- Q. CI와 CD의 차이는? CI는 변경 사항을 자주 통합하고 자동 빌드·테스트로 문제를 조기에 발견하는 것이고, CD는 통합된 코드를 배포 가능한 상태로 유지하거나(Delivery) 운영까지 자동으로 배포하는 것(Deployment)이다.
- Q. Continuous Delivery와 Continuous Deployment의 차이는? 운영 배포에 사람의 승인이 필요하면 Delivery, 테스트를 통과하면 승인 없이 자동 배포되면 Deployment다.
- Q. 블루-그린과 카나리 배포의 차이는? 블루-그린은 새 환경을 모두 준비한 뒤 트래픽을 한 번에 전환하고, 카나리는 일부 트래픽부터 새 버전으로 보내며 점진적으로 늘린다.
- Q. 롤링 배포 시 주의할 점은? 배포 중 두 버전이 동시에 동작하므로 API와 DB 변경의 하위 호환을 유지해야 하고, 준비되지 않은 인스턴스가 트래픽을 받지 않도록 헬스 체크를 설정해야 한다.