쉬운 설명
예전에는 개발자가 코드를 짠 다음 수동으로 빌드하고, 따로 테스트를 돌리고, 누군가 배포 버튼을 누르는 게 일반적이었습니다. 사람이 하다 보니 잊고 빠뜨리거나 실수해서 운영에 문제가 자주 생겼습니다. CI/CD는 이 모든 단계를 코드를 푸시하는 순간 자동으로 돌게 만들어, 사람 손이 닿지 않아도 신뢰할 수 있게 합니다.
CI(지속적 통합)는 'commit 할 때마다 빌드와 테스트를 자동으로 돌리는' 부분입니다. 깨진 코드가 다른 사람 작업과 합쳐지기 전에 잡히고, 모든 PR이 같은 기준으로 검사됩니다. 빠르게 자주 통합하면 큰 충돌이 모이지 않고, 변경이 작아 디버깅도 쉬워집니다.
CD(지속적 배포·지속적 전달)는 그 위에서 '테스트가 통과한 변경을 자동으로 서버에 올리는' 부분입니다. 전체 자동 배포(continuous deployment)와 사람이 마지막 한 번 승인하는 전달(continuous delivery)로 갈라집니다. 어느 쪽이든 핵심은 '배포 자체가 두렵지 않은 정상적인 일'이 되는 것입니다.
장점이 큰 만큼 함부로 켜면 위험합니다. 그래서 보통 안전장치를 함께 둡니다. ① 단계별 배포(스테이징 → 일부 사용자 → 전체), ② 카나리·블루-그린 배포(트래픽의 일부만 새 버전으로), ③ 자동 롤백(모니터링 지표가 이상하면 즉시 이전 버전으로), ④ 기능 플래그(코드를 배포해 두고 사용자에겐 숨김). 이 도구들이 함께 작동해야 진짜 안전한 빠른 배포가 됩니다.
대표 도구: GitHub Actions·GitLab CI·CircleCI·Jenkins·BuildKite. 클라우드 사업자도 자체 CI/CD를 제공(AWS CodePipeline·GCP Cloud Build). 작은 팀은 GitHub Actions가 무료·간단해서 첫 선택지가 되고, 회사 규모가 커지면 자체 인프라나 매니지드 솔루션으로 옮겨갑니다.
비유로 보면
CI/CD는 공장의 컨베이어 벨트와 같습니다. 한 부품(코드)이 들어오면 검사·조립·도색·포장을 거쳐 출하까지 자동으로 흐릅니다. 사람은 라인을 설계하고 알람을 듣는 일을 하지, 부품을 손에 들고 한 단계씩 옮기지 않습니다.
어디에서 만나나
거의 모든 현대 소프트웨어 개발의 표준. 작은 사이드 프로젝트부터 대규모 기업 시스템까지, GitHub과 같은 코드 호스팅에 PR을 올리는 순간 자동 빌드·테스트·배포가 따라오는 흐름이 기본이 됐습니다. 데이터·머신러닝에서도 'CI for data', 'MLOps' 같은 형태로 같은 발상이 확장되고 있습니다.
작은 예시
오픈소스 프로젝트에 PR을 올리면 1~2분 안에 자동으로 빌드·테스트가 돌고, 결과가 PR에 초록·빨강으로 표시됩니다. 메인 브랜치에 머지되면 그 즉시 스테이징 서버에 배포됩니다. 사람은 코드를 리뷰만 하고, 나머지는 CI/CD가 합니다.
자주 하는 오해
한 줄 정리
CI/CD의 진짜 가치는 '배포 자체를 두렵지 않은 일로 만드는 것'입니다. 작고 자주, 자동으로 — 이 세 가지가 갖춰지면 사고는 줄고 속도는 올라갑니다.