[Cloud Computing] CI/CD
CI/CD
코드가 커밋되는 순간부터 사용자에게 도달하기까지. CI·CD의 정확한 정의부터 Rolling·Blue-Green·Canary 배포, 그리고 AWS Code 시리즈·Jenkins·GitHub Actions·ArgoCD 실전 활용까지.
| Category | Level | Reads | Status |
|---|---|---|---|
| Cloud Computing · DevOps | 중급 | 약 20분 | VERIFIED |
CI (Continuous Integration)란?
CI는 여러 개발자가 작성한 코드를 자주, 자동으로 통합·검증하는 방식이다.
옛날 방식은 몇 주씩 각자 따로 개발하다가 한 번에 코드를 합쳤다. 이러면 충돌(merge conflict)이 산더미처럼 쌓이고, 어디서 문제가 생겼는지도 알기 어렵다. CI는 이걸 반대로 뒤집는다 — 커밋할 때마다(하루에도 여러 번) 즉시 통합하고, 자동으로 빌드하고, 자동으로 테스트를 돌린다. 문제가 생기면 몇 주 뒤가 아니라 몇 분 안에 알 수 있다.
개발자가 코드를 원격 저장소에 올리면 파이프라인이 자동으로 트리거된다.
코드를 실행 가능한 형태(바이너리, 도커 이미지 등)로 컴파일·패키징한다.
단위 테스트, 통합 테스트 등을 자동 실행해서 코드가 여전히 정상 동작하는지 검증한다.
검증을 통과한 결과물을 저장소(레지스트리 등)에 저장해서, 다음 단계(CD)가 바로 가져다 쓸 수 있게 한다.
CD란? — Delivery와 Deployment는 다르다
CD는 두 가지 다른 의미로 쓰여서 헷갈리기 쉽다. 둘 다 CI가 끝난 뒤 이어지는 단계지만, "사람의 승인이 끼는가"가 결정적인 차이다.
배포 직전까지 자동으로 준비는 해두지만, 실제 프로덕션 반영은 사람이 버튼을 눌러야 실행된다. "언제든 배포할 수 있는 상태"를 항상 유지하는 것이 핵심이다.
테스트를 통과하면 사람 개입 없이 곧바로 프로덕션까지 자동 배포된다. 배포 속도는 가장 빠르지만, 그만큼 테스트 신뢰도가 뒷받침돼야 한다.
배포 전략 ① Rolling (롤링 배포)
기존 서버(인스턴스/Pod)를 한 번에 조금씩 새 버전으로 교체해나가는 방식이다. Kubernetes Deployment의 기본 배포 방식이기도 하다.
- 추가 서버 자원이 거의 필요 없음(기존 자원 재활용)
- 중단 없이(무중단) 배포 가능
- 구현이 비교적 단순함
- 배포 도중 신·구 버전이 동시에 떠 있어 호환성 이슈 가능
- 문제 발생 시 롤백도 다시 "롤링"으로 되돌려야 해서 느림
- 즉각적인 트래픽 전환이 아니라 완전 롤백까지 시간이 걸림
배포 전략 ② Blue/Green
Rolling과 다르게, 완전히 똑같은 환경 두 벌을 준비한다. 지금 트래픽을 받고 있는 환경을 Blue, 새 버전을 미리 다 띄워놓은 대기 환경을 Green이라 부른다. 준비가 끝나면 라우터(로드밸런서)가 트래픽을 Blue에서 Green으로 한 번에 전환한다.
- 전환이 즉각적이고, 롤백도 스위치만 되돌리면 되므로 매우 빠름
- 신·구 버전이 트래픽 레벨에서 동시에 섞이지 않아 안전함
- Green 환경에서 배포 전 최종 검증(스모크 테스트)이 가능
- 환경을 통째로 두 벌 운영해야 해서 인프라 비용이 두 배에 가까움
- DB 스키마 변경처럼 두 버전이 공유하는 자원이 있으면 설계가 까다로움
- 전환 순간 모든 사용자가 한 번에 새 버전을 겪음(문제 있으면 영향 범위가 큼)
배포 전략 ③ Canary (카나리 배포)
이름은 탄광 속 카나리아 새에서 왔다 — 위험을 가장 먼저 감지하는 존재. 새 버전에 아주 적은 비율의 트래픽만 흘려보내고, 문제가 없으면 그 비율을 점점 늘려가는 방식이다.
- 문제가 있어도 극히 일부 사용자에게만 영향
- 실제 프로덕션 트래픽으로 검증 가능(테스트 환경의 한계 보완)
- A/B 테스트처럼 지표 기반 의사결정과 결합하기 좋음
- 전체 전환까지 시간이 오래 걸림(신중한 만큼 느림)
- 트래픽을 비율대로 나누는 정교한 라우팅·모니터링 인프라가 필요
- 일부 사용자만 새 버전을 겪는 동안 일관성 문제가 생길 수 있음
배포 전략 비교 — 언제 무엇을 쓸까
| 구분 | Rolling | Blue/Green | Canary |
|---|---|---|---|
| 인프라 비용 | 낮음 | 높음(환경 2배) | 중간 |
| 롤백 속도 | 느림 | 매우 빠름 | 빠름(비율만 0으로) |
| 위험 노출 범위 | 중간 | 전환 순간 전체 | 매우 작게 시작 |
| 구현 복잡도 | 낮음 | 중간 | 높음(정교한 라우팅 필요) |
| 적합한 상황 | 일반적인 서비스, 비용 민감 | 즉각 롤백이 중요한 서비스 | 사용자 영향 최소화가 최우선인 대규모 서비스 |
CI 도구들 — 뭐가 있나
CI를 실행해주는 도구는 생각보다 다양하다. 대부분 "코드 저장소에 변화가 생기면 자동으로 빌드·테스트를 실행"하는 역할은 같고, 어디서 어떻게 실행하느냐가 다르다.
| 도구 | 특징 |
|---|---|
| Jenkins | 가장 오래되고 널리 쓰이는 오픈소스. 플러그인으로 거의 모든 걸 확장 가능하지만 직접 서버를 운영해야 함 |
| GitHub Actions | GitHub 저장소에 내장된 CI/CD. 워크플로우를 YAML로 정의, 별도 서버 설치 불필요 |
| GitLab CI/CD | GitLab에 내장. 저장소·CI·CD·이슈 관리를 하나의 플랫폼에서 처리 |
| CircleCI | 클라우드 기반 CI 전문 서비스. 빠른 실행 속도와 캐싱 최적화로 유명 |
| Travis CI | 오픈소스 프로젝트에서 초창기 인기를 끌었던 클라우드 CI 서비스 |
| AWS CodeBuild | AWS의 완전관리형 빌드 서비스. 서버 없이 컨테이너에서 빌드·테스트 실행 |
| TeamCity / Bamboo | JetBrains(TeamCity), Atlassian(Bamboo)의 기업용 CI 서버, 대규모 조직에서 사용 |
AWS Code 시리즈
AWS는 CI/CD 파이프라인의 각 단계를 서비스별로 나눠서 제공한다. 이름이 비슷해서 헷갈리기 쉬운데, 역할은 명확히 나뉜다.
Git 기반 소스 저장소(요즘은 GitHub 등 외부 저장소를 그대로 쓰는 경우도 많음).
소스를 빌드하고 테스트를 실행하는 완전관리형 서비스. 서버를 직접 띄울 필요가 없다.
빌드된 결과물을 EC2, ECS, Lambda 등에 실제로 배포한다. Rolling·Blue/Green 배포를 옵션으로 지원한다.
위 세 단계를 하나의 파이프라인으로 연결·자동화하는 오케스트레이션 서비스.
- 서버 관리 없이 완전관리형으로 운영 부담이 적음
- IAM, VPC 등 다른 AWS 서비스와 통합이 매끄러움
- CodeDeploy가 Blue/Green 배포를 기본 지원
- AWS 생태계에 종속됨
- Jenkins·GitHub Actions 대비 커뮤니티 플러그인·확장성이 상대적으로 적음
- 복잡한 파이프라인 구성 시 여러 서비스를 함께 이해해야 해서 학습 곡선이 있음
Jenkins
가장 오래되고 여전히 가장 널리 쓰이는 오픈소스 자동화 서버다. Jenkinsfile이라는 파이프라인 정의 파일에 빌드·테스트·배포 전체 흐름을 코드로 적어둔다(Pipeline as Code).
- 수천 개의 플러그인으로 거의 모든 도구·서비스와 연동 가능
- 온프레미스든 클라우드든 어디에나 설치 가능
- 오랜 기간 검증된 안정성과 방대한 커뮤니티 자료
- 서버를 직접 설치·운영·업데이트해야 함
- 플러그인 의존성이 쌓이면 관리가 복잡해짐
- UI가 상대적으로 오래된 느낌, 초기 설정에 손이 많이 감
GitHub Actions
GitHub 저장소에 내장된 CI/CD 도구다. .github/workflows/*.yml 파일 하나로 "언제(트리거) 무엇을(job) 할지"를 정의한다. 별도 서버 설치 없이 GitHub가 제공하는 실행 환경(Runner)에서 곧바로 돌아간다.
Push/PR 이벤트 발생
→ GitHub가 workflow YAML을 읽음
→ Runner(가상 머신)에서 job 실행
→ 빌드 · 테스트 · (필요시) 배포까지 한 파일로 정의
- GitHub와 완벽 통합, 별도 서버·계정 설정 불필요
- Marketplace의 방대한 재사용 가능한 Action으로 빠른 구성
- 오픈소스 프로젝트는 무료로 넉넉하게 사용 가능
- GitHub 생태계 밖에서는(다른 저장소) 그대로 못 씀
- 대규모 조직에서는 실행 시간·동시성 비용이 늘어날 수 있음
- 복잡한 파이프라인은 YAML이 금방 길어지고 관리가 번거로워짐
ArgoCD와 GitOps
ArgoCD는 지금까지의 도구들과 접근 방식 자체가 다르다. Jenkins·GitHub Actions가 "파이프라인이 능동적으로 서버에 접속해서 배포 명령을 내리는" 방식이라면, ArgoCD는 GitOps라는 철학을 따른다.
Git 저장소에 적힌 내용을 "있어야 할 상태(Desired State)"의 유일한 근거로 삼는 방식. 배포는 "명령을 실행"하는 게 아니라 "Git을 원하는 상태로 고치는 것"이 된다.
ArgoCD는 Kubernetes 클러스터 안에서 계속 돌면서, Git에 적힌 상태와 클러스터의 실제 상태(Actual State)를 끊임없이 비교한다. 다르면(Drift) 자동으로 클러스터를 Git에 맞게 맞춘다(Sync).
- Git이 유일한 진실 공급원(Single Source of Truth) — 배포 이력이 곧 Git 커밋 이력
- 클러스터가 수동으로 바뀌어도(Drift) 자동으로 원상 복구
- 롤백이 "이전 커밋으로 되돌리기"만큼 간단함
- Argo Rollouts와 결합해 Blue/Green·Canary를 선언적으로 관리
- Kubernetes 환경 전제 — 그 밖에서는 쓰기 어려움
- GitOps 개념 자체의 학습 곡선이 있음
- CI(빌드·테스트)는 별도 도구가 필요 — ArgoCD는 CD 전용
그 외에도 이런 도구들이 있다
| 도구 | 특징 |
|---|---|
| Spinnaker | Netflix가 만든 멀티 클라우드 CD 플랫폼. Canary 분석 기능이 강력함 |
| Flux | ArgoCD와 같은 GitOps 진영의 경쟁 도구. CNCF 프로젝트로 더 가벼운 구조가 특징 |
| Tekton | Kubernetes 네이티브로 설계된 CI/CD 파이프라인 프레임워크 |
| Harness | AI 기반 배포 검증·비용 최적화를 내세우는 상용 CD 플랫폼 |
| AWS CodeDeploy(단독) | CodePipeline 없이 배포 단계만 따로 쓸 수도 있음(다른 CI와 조합) |
실무에서 자주 쓰는 조합
보통 CI 도구 하나와 CD 도구 하나를 조합해서 쓴다. 대표적인 조합은 이렇다.
GitHub Actions가 빌드·테스트 후 이미지를 만들고 Git 매니페스트를 갱신하면, ArgoCD가 그 변화를 감지해 Kubernetes에 반영한다. 최근 가장 인기 있는 GitOps 조합.
Jenkins가 빌드·테스트를 맡고, 실제 EC2/ECS 배포는 AWS CodeDeploy에 위임하는 전통적인 조합.
CodeCommit/GitHub → CodeBuild → CodeDeploy까지 전부 AWS 서비스로 통일해서 관리 지점을 하나로 줄인다.
GitLab 하나로 코드 저장, CI, 심지어 배포(Auto DevOps)까지 처리하는 올인원 조합.
왜 CI/CD를 도입하는가
- 버그를 몇 주가 아니라 몇 분 안에 발견
- 배포가 두렵지 않은 일상적인 작업이 됨(자주, 작게 배포)
- 사람의 실수(수동 배포 절차 누락 등)를 자동화로 제거
- 배포 이력·롤백이 명확하게 추적 가능
- 테스트 코드가 부실하면 CI가 "빠르게 잘못된 것을 통과시키는" 도구가 될 수 있음
- 초기 파이프라인 구축·유지에 시간 투자가 필요함
- 배포 전략(Blue/Green 등)까지 도입하려면 인프라·비용 설계가 함께 필요함