배포가 두려운 팀은 배포를 미루고, 미룬 배포는 한 번에 거대한 변경을 몰아 더 위험해집니다. CI/CD의 진짜 가치는 속도가 아니라 ‘작은 변경을 자주, 안전하게’ 내보낼 수 있게 만드는 데 있습니다. 이 글은 빈 저장소에서 시작해 신뢰할 수 있는 파이프라인을 세우는 과정을 다룹니다.
운영 문제: 수동 배포의 비용
수동 배포는 단지 느린 게 아닙니다. 사람이 명령을 외워 치는 과정은 재현 불가능하고, 금요일 오후의 실수 한 번이 주말 장애로 번집니다. 자동화의 첫 목표는 ‘누가 눌러도 똑같은 결과’를 보장하는 것입니다.
아키텍처: CI와 CD의 분리
CI(지속적 통합)는 코드가 합쳐질 때마다 빌드와 테스트로 품질을 검증하는 단계이고, CD(지속적 배포)는 검증된 산출물을 환경에 안전하게 내보내는 단계입니다. 둘을 명확히 분리해야 ‘CI는 빠르게, CD는 신중하게’라는 서로 다른 리듬을 줄 수 있습니다.
구현: 파이프라인 정의 예시
stages:
- lint-and-test # 단위 테스트 + 정적 분석
- build-image # 컨테이너 이미지 빌드 + 취약점 스캔
- deploy-staging # 스테이징 자동 배포
- smoke-test # 핵심 경로 통합 검증
- deploy-prod # 카나리 10% -> 50% -> 100%핵심은 각 단계가 게이트 역할을 한다는 점입니다. 테스트가 깨지면 이미지는 빌드되지 않고, 스모크 테스트가 실패하면 운영 배포는 자동으로 중단됩니다. 사람의 판단이 아니라 파이프라인이 안전을 강제합니다.
모니터링과 배포 안전장치
- 배포 빈도와 변경 실패율(DORA 핵심 지표)
- MTTR(평균 복구 시간)과 자동 롤백 발동 횟수
- 카나리 단계별 에러율·지연 비교
카나리 배포는 새 버전을 일부 트래픽에만 노출해 에러율이 기준치를 넘으면 즉시 롤백합니다. 이 한 가지 장치만으로도 잘못된 배포의 영향 범위를 전체 사용자에서 10% 이하로 가둘 수 있습니다.
정리
좋은 파이프라인은 배포를 ‘이벤트’에서 ‘일상’으로 바꿉니다. 테스트 게이트로 품질을, 카나리와 자동 롤백으로 안전을 확보하면, 팀은 두려움 없이 하루에도 여러 번 배포하며 빠르게 학습할 수 있습니다.





