CI와 CD
한 줄 정의
CI는 변경된 코드를 자주 통합하고 자동 검증하는 활동이고, CD는 검증된 변경을 반복 가능하게 배포하는 활동이다.
실무에서 왜 문제 되는가
- CI가 약하면 깨진 코드가 늦게 발견된다.
- CD가 약하면 배포 절차가 사람마다 달라지고 복구가 느려진다.
- 테스트 없이 배포 자동화만 있으면 장애도 빠르게 배포된다.
- 배포 성공과 서비스 정상 동작을 혼동하면 운영 문제가 늦게 발견된다.
실무 판단 기준
| 단계 | 핵심 질문 |
|---|---|
| CI | 이 변경이 빌드되고 테스트를 통과하는가? |
| CD | 같은 절차로 안전하게 배포하고 되돌릴 수 있는가? |
| 배포 후 검증 | 지표와 로그가 정상인가? |
| 승인 | 어떤 변경은 수동 승인이나 점검이 필요한가? |
자주 나는 실수
- CI/CD를 단순히 도구 이름으로 이해한다.
- 테스트가 불안정한 상태에서 자동 배포를 켠다.
- 배포 후 지표 확인을 pipeline 밖의 수동 작업으로만 둔다.
- 롤백 절차가 없는 상태에서 배포 속도만 높인다.
확인 방법
- pull request마다 build/test가 실행되는지 확인한다.
- main branch 기준 배포 artifact가 재현 가능한지 확인한다.
- 배포 실패와 배포 후 오류율 증가를 구분해 감지하는지 확인한다.
핵심 요약
CI는 변경을 빠르게 통합하고 검증하는 과정이다.
CD는 검증된 변경을 반복 가능하게 배포하는 과정이다.
자동화는 테스트, 설정, 권한, 롤백 기준과 함께 설계해야 한다.
배포 성공은 pipeline 성공이 아니라 서비스 지표 정상까지 포함해야 한다.
빠른 배포보다 되돌릴 수 있는 배포가 운영 안정성에 중요하다.
꼬리 질문
- CI와 CD는 무엇이 다른가?
- 배포 자동화 전에 무엇이 준비되어야 하는가?
- 배포 성공을 어떤 기준으로 판단할 것인가?