CI/CD
"Build fast, Test always, Deploy continuous"
— 코드 품질 저하 없이 빠른 속도로 릴리스 사이클을 돌리는 데브옵스 운동의 정수.
사람 손으로 빌드하고 서버에 수동으로 압축파일을 올리던 원시 시대를 종식하고, '코드만 푸시하면 서버가 알아서 바뀐다'는 마법 같은 평화를 선사한 현대 개발의 수호신. 하지만 배포 파이프라인 빨간 불(Failed)을 마주하는 순간, 80단계의 빌드 로그 중에서 '어디서 터졌는지' 찾기 위해 돋보기를 들어야 하는 스트레스 유발기.(...)
1. 개요
CI/CD는 지속적 통합(Continuous Integration)과 지속적 제공/배포(Continuous Delivery/Deployment)를 결합한 소프트웨어 개발 생태계의 패러다임이다. 과거 개발자들이 코드를 취합한 뒤 밤샘 머지와 빌드 오류로 절규하던 '머지 지옥(Merge Hell)'을 예방하기 위해 탄생했다. 개발자가 코드를 Git에 올리기만 하면, 백엔드 로봇이 즉시 소스코드를 가져가 린트(Lint)를 돌리고, 단위 테스트를 하고, 배포용 빌드를 만든 다음, 최종 운영 서버에 릴리스하는 일련의 과정을 완전 자동화한다.(...)
2. CI(지속적 통합)와 CD(지속적 배포)의 칼 같은 역할 분담
CI와 CD는 파이프라인의 전반부와 후반부를 각각 책임지는 영혼의 동반자다.
2.1. CI (Continuous Integration: 지속적 통합)
- 핵심 목표: 여러 개발자가 작성한 코드가 충돌 없이 지속적으로 합쳐지고 빌드되는지 검증하는 것.
- 작업 흐름: 개발자가 GitHub에 Pull Request(PR)를 올리면, 자동으로 가상 환경에서 빌드를 시도하고 미리 짜여진 자동화 테스트들을 실행한다.
- 만약 이 단계에서 누군가 버그가 있는 코드를 짜서 테스트가 터지면, 파이프라인은 냉정하게 '빨간 불(Fail)'을 띄우며 머지를 불허한다. 덕분에 망가진 코드가 메인 코드베이스에 침투하는 대참사를 미연에 방지할 수 있다.1
2.2. CD (Continuous Delivery/Deployment: 지속적 배포)
- 핵심 목표: CI 단계를 무사히 통과한 검증된 코드를 실제 운영 환경에 사람 손을 대지 않고 배포하는 것.
- Continuous Delivery: 배포 준비 과정(빌드 및 스테이징 서버 배포)까지 자동화하되, 최종 프로덕션 서버 배포 버튼은 사람이 클릭하여 결정한다.
- Continuous Deployment: 테스트 통과 시 진짜 무지성으로 프로덕션 운영 서버까지 자동 배포가 완료되는 모델이다. 현대 테크 기업들은 이 방식으로 하루에도 수십, 수백 번씩 사용자 몰래 서비스를 업데이트한다.(...)
3. 파이프라인 구축의 3대 필수 구성 요소
든든한 CI/CD 환경을 구축하기 위해서는 다음 세 가지 요소의 기밀한 연동이 필수적이다.
3.1. 형상 관리 시스템 (VCS)
3.2. 빌드/테스트 자동화 스크립트
- 단순히 파이프라인 툴만 쓴다고 배포가 되지는 않는다. 파이프라인 내부에서 실행할
npm run test,gradlew build,docker build같은 로컬 빌드 명령어들이 잘 짜여 있어야 한다.
3.3. 오케스트레이터 및 러너 (Runner)
- Jenkins, GitHub Actions, GitLab CI 등 파이프라인의 파트별 실행 순서를 규정하고 실행해 주는 엔진이다. 이 엔진들은 전용 가상 머신(Runner)을 임시로 임대하여 스크립트를 한 줄씩 실행하며 성공 여부를 판가름한다.2
4. 관련 밈 및 드립
4.1. Update README.md (CI/CD 디버깅)
GitHub의 커밋 히스토리 창에서 'Update workflow', 'Fix cicd yaml', '제발 되어라 진짜', 'README.md 수정' 같은 눈물겨운 커밋이 30개 연속으로 이어지는 현상이다. 로컬 환경과 GitHub Actions 러너 가상 환경의 환경 변수나 OS 권한이 달라 빌드가 터질 때, 마땅히 로컬에서 디버깅할 방법이 없어 코드를 1줄 고치고 커밋하고, 또 터지면 1줄 고쳐서 푸시하는 행위를 밤새 반복하는 현대 개발자들의 대표적인 삽질 밈이다.(...)
5. 여담
- 빌드 깨뜨린 자의 벌금: 대형 IT 기업들의 개발 팀에서는 무책임하게 테스트가 터지는 코드를 머지해서 메인 파이프라인을 빨갛게 물들여 동료들의 배포 길을 막은 빌런(?)에게 커피를 쏘게 하거나 피자 벌금을 매기는 전통이 실존한다.
- Jenkins의 역사적 위상: 젠킨스는 현대 CI/CD의 조상 격인 오픈소스 도구다. 설치와 관리가 번거로워 요즘은 클라우드 기반 SaaS(GitHub Actions)에 자리를 많이 내줬지만, 여전히 보안이 삼엄한 대기업이나 금융권에서는 무조건 폐쇄망에 젠킨스 서버를 올려서 쓴다.
- 블루-그린 배포 (Blue-Green): 배포 도중 서비스가 끊기는 것을 막기 위해, 구버전 서버(Blue)를 켜둔 채 신버전 서버(Green)를 완전히 띄운 뒤 로드 밸런서의 경로를 한순간에 Green으로 돌리는 궁극의 무중단 배포 기법이다. 물론 데이터베이스 스키마가 바뀌는 경우 싱크를 맞추느라 엔지니어들의 영혼이 털려 나간다.