CI/CD란? 개발한 코드를 자동으로 테스트하고 서버에 배포하는 과정 쉽게 이해하기

코드를 고쳤다면 사용자가 보는 서버에 반영해야 합니다. 작은 사이트는 직접 파일을 복사해도 되지만, 파일이 빠지거나 미검증 코드가 올라가고 서버마다 버전이 어긋나면 장애로 이어집니다. CI/CD는 변경한 코드를 자동으로 검사·테스트하고, 실제 서버에 안전하고 반복 가능한 방식으로 배포하기 위한 개발·배포 자동화입니다.

CI · CD · Pipeline

CI(Continuous Integration)는 코드 변경을 자주 합치고 문법·스타일·단위 테스트·빌드 등을 자동 검사하는 과정입니다. Git Push나 Pull Request를 신호로 돌릴 수 있고, 테스트 실패 시 배포를 막을 수 있습니다. CD는 문맥에 따라 Continuous Delivery(배포 준비까지 자동, 최종 반영은 사람 승인) 또는 Continuous Deployment(검사 통과 시 운영까지 자동)입니다. 금융처럼 승인 단계가 필요한 곳과 빠른 웹서비스는 선택이 달라집니다.

Pipeline은 Push → 검사 → 테스트 → 빌드 → 배포처럼 단계를 순서대로 통과하는 자동 흐름입니다. 중간 실패 시 뒤 단계는 실행하지 않아 깨진 빌드가 서버로 가는 일을 줄입니다. 빌드는 개발용 코드를 배포용으로 묶는 작업이고, 단순 HTML은 없어도 React·TypeScript 등에는 흔합니다.

배포 전략 · Staging · Artifact

로드밸런서 뒤 서버마다 버전이 다르면 요청마다 동작이 달라질 수 있습니다. 무중단을 위해 Rolling(순차 교체), Blue-Green(두 환경 전환·빠른 롤백), Canary(소수 사용자에게 먼저)를 쓸 수 있습니다. CI/CD만으로 무중단이 되는 것은 아니고, 이런 전략을 파이프라인에 넣는 것입니다.

Development → Staging(리허설) → Production(공연장)으로 나누고, 같은 Artifact(빌드 결과물·Docker 이미지)를 여러 환경에 쓰는 편이 검증 의미가 큽니다. 배포 성공 ≠ 서비스 정상일 수 있어 Smoke Test(메인·로그인·health 등 최소 확인)와 배포 후 모니터링·에러 트래킹을 같이 봅니다. 오토스케일로 새 서버가 떠도 같은 Artifact면 버전을 맞추기 쉽습니다.

Secret · 권한 · DB 마이그레이션

API 키·DB 비밀번호는 코드·Git에 넣지 말고 CI/CD Secret으로 관리합니다. 배포 계정은 최소 권한만 줍니다. DB Migration은 코드 롤백만으로 데이터가 되돌아오지 않을 수 있어 백업·복구 절차까지 검토해야 합니다.

자동 테스트 통과 ≠ 버그 없음입니다. 사람 코드 리뷰와 실제 사용자 환경은 여전히 필요합니다. 배포 실패와 서비스 장애도 다릅니다 — 새 배포가 실패해도 기존 v1이 계속 돌도록 설계할 수 있습니다. 회사소개 HTML 몇 장이면 필수는 아니지만, 수정이 잦거나 여러 서버·자동 테스트가 있으면 가치가 큽니다. SEO 기술은 아니고, 잘못된 배포로 500·깨진 JS를 줄이는 운영 도구에 가깝습니다. 실패 원인은 CI 로그로 확인합니다.

자주 묻는 질문

CI/CD란?

코드를 자동 검사·테스트하고 배포 가능 상태로 만들거나 실제 서버까지 배포하는 자동화 방식입니다.

Delivery와 Deployment 차이는?

Delivery는 운영 반영 전 사람 승인을 둘 수 있고, Deployment는 검사 통과 시 운영까지 자동 배포할 수 있습니다.

무중단 배포가 자동인가?

아닙니다. Rolling·Blue-Green·Canary 같은 전략을 함께 구성해야 합니다.

작은 홈페이지에도 필요하나?

필수는 아니지만 배포가 잦거나 실수를 줄이고 싶으면 1인 개발에도 유용할 수 있습니다.

정리

코드 작성 → 검사 → 테스트 → 빌드 → 배포 → 모니터링이 기본 흐름입니다. 새 버전에 문제가 생기면 「계속 서비스할지, 이전 정상 버전으로 되돌릴지」를 결정합니다. 이처럼 배포한 새 버전을 이전 정상 상태로 되돌리는 작업을 롤백(Rollback)이라고 합니다.