¶ 7권 — CI/CD 파이프라인 구성하기
이 책은 GitHub Actions를 중심 사례로, "커밋 → 빌드 → 테스트 → 배포"를 사람이 매번 수동 반복하지 않도록 자동화하는 체계를 다룬다. Martin Fowler가 정리한 지속적 통합의 핵심 관행이 이 책 전체의 이론적 뼈대다.
- 단일 저장소
- 완전 자동화된 빌드
- 빌드에 포함된 테스트
- 매일의 메인라인 커밋
- 짧은 빌드 시간(10분 이내 지향)
¶ CI와 CD의 구분
CI(지속적 통합)는 코드가 통합될 때마다 자동으로 빌드·테스트해 문제를 최대한 빨리 발견하는 것이다. CD는 검증을 통과한 결과물을 실제 환경까지 내보내는 것이다.
| 구분 | 방식 |
|---|---|
| Delivery | 배포 가능 상태까지만 자동화, 배포 버튼은 사람이 누름 |
| Deployment | 배포 버튼까지 자동화 |
작은 팀은 "커밋이 들어오면 무엇이 자동으로 일어나야 안심할 수 있는가"를 기준으로 범위를 정하는 편이 실용적이다.
¶ 파이프라인 기본 단계: 빌드 - 테스트 - 배포
GitHub Actions의 워크플로는 세 요소로 구성된다.
- 이벤트(트리거)
- 잡(job)
- 스텝/액션
빌드 단계는 모든 PR·브랜치 push에 대해 실행하며 실패 시 병합을 막는 필수 체크로 지정해야 한다.
테스트 단계는 존재하는 테스트 코드를 예외 없이 CI에 연결하는 것이 원칙이다. 단위 테스트는 매 커밋마다, 무거운 E2E는 병합 직전이나 야간 스케줄로 분리해 속도와 균형을 맞춘다.
배포 단계는 GitHub의 environment 기능으로 수동 승인·브랜치 제한·지연 시간 같은 배포 보호 규칙을 걸 수 있다. 프로덕션 배포에는 최소한 "누가 승인했는가"가 남는 절차가 필요하다.
¶ 배포 전략 — 블루/그린과 카나리
| 전략 | 방식 | 특징 |
|---|---|---|
| 블루/그린 배포 | 동일한 두 프로덕션 환경 중 한쪽이 트래픽을 처리하는 동안 다른 쪽에 새 버전을 배포·검증한 뒤 라우터에서 트래픽을 한 번에 전환 | 빠른 롤백 가능, 두 배 인프라와 DB 스키마 호환성 설계 필요 |
| 카나리 릴리스 | 신버전에 처음에는 트래픽을 보내지 않다가 일부 사용자군부터 점진적으로 확대 | 에러율·응답시간 같은 지표를 보며 확대 여부와 자동 롤백 조건을 미리 정해야 효과 있음 |
초기 단계에서는 완전한 두 전략 대신 롤링 배포나 기능 플래그와 결합한 점진적 노출로 절충한다. "배포 직후 5~10분간 핵심 지표를 관찰하고 이상 시 되돌린다"는 최소 기준선은 팀 규모와 무관하게 가져야 한다.
¶ 롤백 전략
배포는 자동화했는데 롤백은 수동 처리하는 팀이 많다. 점검할 네 기준은 다음과 같다.
- 되돌릴 대상이 코드뿐 아니라 DB 마이그레이션·환경 변수·인프라 설정까지 명확한가
- 롤백도 파이프라인의 일부로 마련되어 있는가
- 신버전·구버전 공존 구간의 DB 스키마 변경이 하위 호환적인가
- 헬스체크 실패·에러율 급증 같은 자동 롤백 조건이 정의되어 있는가
CI/CD의 완성도는 성공 시나리오가 아니라 실패 시나리오에서 드러난다.
¶ 속도 최적화
파이프라인이 느려지면 개발자들은 결국 로컬 확인만으로 파이프라인을 우회하기 시작한다. 대표적 개선책은 다음과 같다.
- 의존성 캐싱(lock 파일 해시를 캐시 키에 포함)
- 잡 병렬화·매트릭스 빌드
- 불필요한 실행 줄이기(문서만 변경된 커밋은 경로 필터로 건너뛰기)
¶ 옵션: 다중 환경 파이프라인 분기와 배포 알림
팀이 커지면 dev-staging-production 환경마다 다른 시크릿·보호 규칙을 적용하는 분기가 필요해진다. 하지만 처음부터 복잡하게 설계하지 말고 "지금 스테이징이 실제로 필요한가"부터 점검해야 한다.
배포 상태를 Slack으로 자동 알리는 것은 적은 비용으로 불안을 없애는 방법이다. 배포 성공 이벤트를 Jira 이슈 자동 전환과 연계하면 "배포됐으니 이슈를 닫아야지"를 사람이 기억할 필요가 없어진다.
¶ 핵심 메시지 — 배포 빈도와 안정성은 상충하지 않는다
"자주 배포하면 사고도 잦아지지 않을까"라는 직관과 달리, 배포를 작고 자주 하는 조직일수록 장애 대응이 빠르고 안정성이 높다는 것이 업계 패턴이다. 한 번에 담기는 변경이 작을수록 문제 발생 시 원인 후보가 좁혀지기 때문이다.
¶ 참고할 만한 사례
| 구분 | 사례 |
|---|---|
| 국내 | 우아한형제들 라이더스팀이 반복된 수동 배포 실수를 계기로 Jenkins 기반 CI/CD를 도입한 사례 |
| 해외 | Netflix의 Spinnaker 기반 자동화된 카나리 분석과 Etsy의 하루 수십 차례 배포 문화 |
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.