CI/CD는 애플리케이션의 빌드, 테스트, 배포 과정을 지속적으로 수행하고 자동화하는 개발 방식입니다. 일반적으로 코드 변경을 감지하면 빌드, 테스트, 패키징, 배포 등의 단계가 파이프라인을 통해 순서대로 실행됩니다.
**CI(Continuous Integration, 지속적 통합)**는 개발자들이 코드 변경 사항을 공유 저장소에 자주 통합하고, 변경할 때마다 자동으로 빌드와 테스트를 수행하는 방식입니다. 코드 충돌이나 결함을 빠르게 발견하고, 항상 통합 가능한 상태를 유지하는 것이 목적입니다.
CD는 두 가지 의미로 사용됩니다.
- Continuous Delivery, 지속적 제공: CI를 통과한 결과물을 언제든 운영 환경에 배포할 수 있는 상태로 자동 준비합니다. 운영 배포에는 승인이나 수동 실행 단계가 남아 있을 수 있습니다.
- Continuous Deployment, 지속적 배포: 테스트와 사전에 정의한 검증 조건을 통과한 변경 사항을 별도의 수동 승인 없이 운영 환경까지 자동 배포합니다.
대표적인 파이프라인은 코드 커밋 → 빌드 → 자동 테스트 → 결과물 생성 → 배포 순서로 구성됩니다. 중간 단계가 실패하면 파이프라인을 중단하고 개발자에게 빠르게 피드백합니다.
CI/CD를 적용하면 반복적인 작업과 수동 배포에서 발생하는 실수를 줄이고, 결함을 더 이른 시점에 발견할 수 있습니다. 또한 작은 변경을 자주 배포할 수 있어 한 번의 배포에 포함되는 변경 범위와 위험이 줄고, 배포 과정의 재현성과 속도가 향상됩니다.
CI/CD는 GitHub Actions, GitLab CI/CD, Jenkins 같은 특정 도구 자체를 의미하는 것이 아니라 개발 및 배포 방식이며, 이러한 도구들은 파이프라인을 구현하고 자동화하는 수단입니다.
Continuous Delivery와 Continuous Deployment의 차이는 무엇인가요?
Continuous Delivery는 검증된 결과물을 언제든 배포할 수 있는 상태까지 자동으로 준비하되 운영 반영에 수동 승인 단계가 있을 수 있습니다. Continuous Deployment는 검증 조건을 통과한 변경을 수동 승인 없이 운영 환경까지 자동으로 배포합니다.
CI 파이프라인의 테스트가 실패하면 어떻게 해야 하나요?
다음 단계로 진행하지 않고 파이프라인을 즉시 실패 처리하여 잘못된 결과물이 배포되지 않게 해야 합니다. 개발자에게 로그와 결과를 빠르게 전달하고, 실패 원인을 수정해 파이프라인이 다시 통과하도록 하는 것이 기본 원칙입니다.
CI/CD에서 안전하게 배포하기 위한 방법에는 무엇이 있나요?
배포 전 자동 테스트와 품질·보안 검사를 통과하게 하고, 운영 환경에는 Rolling, Blue-Green, Canary 같은 전략으로 변경을 점진적으로 노출할 수 있습니다. 배포 상태를 모니터링하고 문제가 발생하면 이전 버전으로 신속히 롤백할 수 있도록 결과물과 절차를 준비해야 합니다.