CI/CD 기초 개념 소개

지속적 통합·제공·배포의 차이를 구분하고 React 앱의 변경 검증과 배포를 자동화하는 파이프라인을 이해합니다.

지속적인 개발과 배포 과정에서 개발 효율성을 극대화하고 안정성을 높이는 데 필수적인 개념이 바로 CI/CD(Continuous Integration / Continuous Delivery/Deployment)입니다.

이번 11장 배포와 다음 단계의 세 번째 절에서는 CI/CD의 기초 개념을 소개하고, 왜 개발 워크플로우에 CI/CD를 통합해야 하는지 설명하겠습니다.

CI / CONTINUOUS DELIVERY / DEPLOYMENT

검증 후, 수동 승인과 자동 배포를 구분한다

CI는 변경을 자주 통합하고 빌드·테스트로 피드백한다. 검증을 통과한 릴리스를 준비한 뒤 수동 승인으로 운영에 내보내면 지속적 제공, 자동으로 내보내면 지속적 배포다.

1. 입력 기록commit · lockfile

2. 검사 · 테스트실패 시 뒤 단계 중지

3. production builddist 아티팩트 생성

4. preview 검증대표 URL · 기능

5. 릴리스 방식 선택수동 승인 / 자동 정책

6. 운영 + 관찰오류 · 핵심 행동 확인

단계와 의존성을 구성해야 실패가 배포를 차단한다

CI / FEEDBACK

검증 실패는 수정으로 되돌린다

commit·lockfile로 입력을 기록하고 정적 검사·테스트·빌드의 기준과 순서를 구성한다. 실패 소유자와 재실행 방법을 기록하며, 필요한 앞 단계가 실패하면 뒤 배포가 진행되지 않도록 의존성을 둔다.

ARTIFACT / VERIFY

검증한 결과물을 보존한다

정적 앱의 dist 파일을 아티팩트로 저장한다. 선택한 preview·스테이징에서 대표 URL, 자산, 오류 상태와 접근성을 확인한다. 같은 아티팩트의 승격은 이 그림의 설계 예시다.

CONTINUOUS DELIVERY

준비는 자동화, 운영 배포는 승인

검증된 릴리스를 운영에 내보낼 수 있는 상태로 준비한다. 최종 배포는 사람이 승인하거나 수동으로 시작한다.

CONTINUOUS DEPLOYMENT

기준을 통과하면 운영에 자동 반영

구성한 검사와 정책을 통과하면 별도 수동 승인 없이 운영으로 배포한다. 저장소 연결 자체가 테스트 기준이나 배포 차단 조건을 모두 만들어 주는 것은 아니다.

OBSERVE / ROLLBACK

운영 결과와 복구 대상을 기록한다

release ID·digest와 오류·핵심 사용자 행동을 기록한다. 이전 정상 아티팩트로 돌아갈 정책을 구성하고 확인한다. digest 기록·원자적 전환·자동 롤백은 각 도구에서 직접 구성할 절차다.

이 흐름은 파이프라인 설계 예시다. Netlify·Vercel의 Git 연동이나 GitHub Actions 사용만으로 검사 의존성, 승인, 동일 바이트 승격과 관찰·롤백이 모두 구현됐다고 보지 않는다.

빌드와 로컬 프리뷰가 무엇을 확인하는지 먼저 연결하세요. CI/CD는 React 전용 API가 아니라 저장소의 변경, 검사, 산출물, 릴리스 조건을 잇는 방식입니다. 아래 순서는 설계 예시이며, 테스트 종류에 따라 빌드 전 검사를 하거나 빌드 산출물을 만든 뒤 검사할 수 있습니다.

React에서 CI/CD란 무엇인가?

CI/CD는 변경의 통합·검사와 릴리스 준비·배포를 반복 가능한 흐름으로 연결합니다. CI만 도입하거나 승인과 같은 수동 판단을 남길 수도 있으므로 모든 단계가 자동이어야 하는 것은 아닙니다.

크게 CI(Continuous Integration)와 CD(Continuous Delivery/Deployment) 두 가지 개념으로 나눌 수 있습니다.

CI (지속적 통합)

지속적 통합(Continuous Integration)은 개발자들이 각자 작업한 코드를 메인 코드 저장소(예: main 브랜치)에 자주 그리고 지속적으로 통합하는 개발 방법론입니다.

CI의 핵심 목표

충돌 최소화: 여러 개발자가 동시에 작업하면서 발생하는 코드 충돌(merge conflict)을 조기에 발견하고 해결하여 통합 비용을 줄입니다.
버그 조기 발견: 통합된 코드에 대한 자동화된 테스트(단위 테스트, 통합 테스트 등)를 실행하여 문제를 빠르게 감지합니다.
일관된 검사: 빌드 및 테스트 과정을 자동화해 정한 조건을 반복 확인합니다. 테스트하지 않은 모든 동작의 품질을 보증하는 것은 아닙니다.

CI 파이프라인의 일반적인 단계

코드 커밋: 개발자가 자신의 로컬에서 작업한 코드를 원격 Git 저장소(예: GitHub, GitLab)에 푸시합니다.

자동화된 빌드: 푸시된 코드가 저장소에 통합되면(예: Pull Request 병합 또는 직접 푸시), CI 서버(Jenkins, GitHub Actions, GitLab CI 등)가 자동으로 프로젝트를 빌드합니다. (우리의 React 앱의 npm run build 과정과 유사)

자동화된 테스트: 빌드가 성공하면, 미리 작성된 단위 테스트, 통합 테스트 등을 실행하여 새로운 코드가 기존 기능에 영향을 주지 않는지 확인합니다.

피드백: 빌드 또는 테스트가 실패하면, 개발자에게 즉시 알림을 보내 문제를 수정하도록 유도합니다.

왜 CI가 중요한가?

CI는 버그는 일찍 발견할수록 고치기 쉽다는 원칙에 기반합니다.

코드가 작게 자주 통합되고 테스트되면, 문제가 발생했을 때 그 원인을 찾고 해결하는 데 드는 시간과 노력을 크게 줄일 수 있습니다.

CD (지속적 제공/배포)

지속적 제공(Continuous Delivery, CD)은 CI 단계를 통과한 코드를 자동으로 릴리스 가능한 상태로 준비하는 것을 목표로 합니다.

즉, 언제든지 버튼 클릭 한 번으로 프로덕션 환경에 배포할 수 있는 상태를 만드는 것입니다.

지속적 배포(Continuous Deployment, CD)는 지속적 제공에서 한 걸음 더 나아가, CI 및 테스트 단계를 모두 통과한 코드를 수동적인 개입 없이 자동으로 프로덕션 환경에 배포하는 것을 의미합니다.

CD의 핵심 목표

빠른 배포 주기: 새로운 기능이나 버그 수정이 사용자에게 도달하는 시간을 단축합니다.
수동 작업 제거: 배포 과정을 자동화하여 인적 오류를 줄이고 시간을 절약합니다.
릴리스 위험 감소: 배포 전 검증을 통해 확인한 범위의 회귀 위험을 줄입니다.

CD 파이프라인의 일반적인 단계 (CI 이후)

아티팩트 생성: 빌드된 결과물(이 장의 Vite SPA는 dist 폴더의 정적 파일)을 아티팩트로 저장합니다.

자동화된 배포 테스트 (선택 사항): 스테이징(Staging) 환경이나 테스트 환경에 자동으로 배포하여 최종적인 End-to-End 테스트를 수행할 수 있습니다.

릴리스 승인 (Continuous Delivery): 프로덕션 환경 배포 전에 수동적인 승인 단계가 필요합니다.

자동 배포 (Continuous Deployment): 승인 단계를 거치거나 (지속적 제공의 경우), 모든 테스트를 통과하면 자동으로 프로덕션 환경에 배포됩니다. (Netlify의 자동 배포 기능이 여기에 해당)

지속적 제공 vs 지속적 배포

도입 그림은 검증한 아티팩트를 그대로 승격하는 설계 예시입니다. digest 기록, 승인, 배포 후 관찰과 원자적 롤백은 각 CI·호스팅 환경에서 구성해야 하며 Git 연동만으로 모두 생기는 기능은 아닙니다.

지속적 제공: 배포 준비가 되었지만, 최종 배포는 수동 트리거(버튼 클릭)를 통해 이루어집니다. 비즈니스적 판단이나 추가적인 수동 검증이 필요한 경우에 유용합니다.
지속적 배포: 모든 과정이 자동화되어, 코드가 Git에 푸시되면 자동으로 빌드, 테스트, 배포까지 이루어집니다. 가장 빠르고 효율적이지만, 테스트 자동화에 대한 높은 신뢰가 필요합니다.

왜 React 앱 개발에 CI/CD가 필요한가?

React 개발에서 CI/CD를 도입하면 다음과 같은 이점을 얻을 수 있습니다.

빠른 피드백 루프: 코드 변경 사항이 빌드되고 테스트되며 배포까지 자동화되므로, 문제가 발생했을 때 개발팀이 빠르게 인지하고 수정할 수 있습니다.

릴리스 위험 감소: 자동화된 테스트를 통해 주요 기능의 동작을 반복 확인하고, 배포 전에 회귀 가능성을 줄입니다.

개발 생산성 증대: 수동으로 빌드하고 배포하는 데 드는 시간과 노력을 절약하여 개발자가 핵심 기능 개발에 집중할 수 있게 합니다.

팀 협업 강화: 모든 개발자가 동일한 통합 및 배포 프로세스를 따르므로, 코드 통합이 더 원활해지고 협업 오류가 줄어듭니다.

일관성 유지: 빌드 및 배포 환경이 표준화되고 자동화되므로, 환경 차이로 인한 문제가 발생할 가능성이 줄어듭니다.

잦은 배포 가능: 작은 단위로 자주 배포함으로써, 문제가 발생하더라도 빠르게 롤백하거나 수정할 수 있습니다.

앞 절에서 Netlify를 통한 Git 연동 자동 배포를 경험하셨을 것입니다.

이는 사실상 가장 기본적인 형태의 CI/CD를 경험한 것입니다.

여러분이 코드를 Git에 푸시하면 Netlify가 자동으로 빌드(npm run build)하고 배포하는 과정이 바로 지속적 배포(Continuous Deployment)의 한 예시입니다.

CI/CD 도구 (React 개발 관점)

CI/CD를 구현하기 위한 다양한 도구들이 있습니다.

Netlify / Vercel: Git 연동 빌드·배포 기능을 사용할 수 있습니다. 자신의 테스트·승인·보안 검사를 배포 전에 연결했는지는 실제 설정으로 확인합니다.
GitHub Actions: GitHub에서 제공하는 CI/CD 플랫폼입니다. .github/workflows 디렉터리에 YAML 파일을 작성하여 빌드, 테스트, 배포 등 원하는 자동화 워크플로우를 정의할 수 있습니다. React 앱의 단위 테스트 실행, 번들링, Netlify/Vercel 자동 배포 트리거 등에 활용될 수 있습니다.
GitLab CI/CD: GitLab 저장소와 통합된 CI/CD 플랫폼입니다. .gitlab-ci.yml 파일을 통해 워크플로우를 정의합니다.
Jenkins: 오래된 CI/CD 서버 중 하나입니다. 자체 서버를 구축해야 하지만, 매우 유연하고 다양한 플러그인을 지원합니다.
CircleCI, Travis CI, Bitbucket Pipelines: 다른 인기 있는 클라우드 기반 CI/CD 서비스들입니다.

React 개발자가 CI/CD를 시작하는 가장 쉬운 방법

테스트 코드 작성: Jest, React Testing Library 등을 사용하여 충분한 단위/통합 테스트 코드를 작성합니다.

npm test 스크립트 활용: package.json의 test 스크립트가 모든 테스트를 실행하도록 설정합니다.

Netlify/Vercel 연동: Git 저장소에 코드를 푸시할 때마다 자동으로 빌드/배포되도록 설정합니다.

GitHub Actions 연동 (선택): GitHub Actions를 사용하여 코드가 푸시될 때마다 npm install -> npm test -> npm run build를 자동화하고, 성공하면 Netlify/Vercel 배포를 트리거하는 워크플로우를 구성할 수 있습니다.

CI/CD를 실제로 설계할 때는 각 단계가 통과했을 때와 실패했을 때의 피드백 흐름을 분명히 두어야 합니다.

통과 조건을 먼저 적는 연습

Vite 앱을 만들었다는 이유만으로 npm test가 설정되지는 않습니다. package.json에 실제 test 스크립트와 테스트 파일이 있는지 먼저 봅니다. 테스트가 없는 프로젝트는 테스트가 통과했다고 기록하지 않습니다. 단위 검사, 빌드, 프리뷰 확인 각각 무엇을 검사하고 실패하면 어느 단계가 멈춰야 하는지 적습니다.

예시

아래 표는 배포 서비스를 호출하는 코드가 아니라 한 릴리스의 의존 조건입니다. 검사를 모두 생략하고도 Git 연동 배포가 따로 실행되면 표의 조건이 구현된 것이 아닙니다.

단계	입력과 통과 조건	실패 뒤의 동작
검사	선택한 commit의 코드와 테스트, 검사 성공	그 릴리스를 만들거나 승격하는 후속 단계를 차단
빌드	같은 commit에서 산출물 생성, 빌드 성공	배포할 새 산출물 없음으로 기록
프리뷰 검증	그 산출물의 주소·기능·자산 확인	승인·운영 승격을 차단
릴리스	검증한 산출물과 필요한 승인	같은 산출물을 운영에 전달하고 이후 응답 관찰

GitHub Actions의 jobs.needs 규칙은 성공한 선행 job을 기다리는 의존 관계를 설명합니다. 실패·건너뜀 뒤에도 실행하는 조건을 따로 사용하면 후속 단계가 실행될 수 있으므로, 항상 실행할 진단·정리 작업과 성공할 때만 실행할 배포를 구별합니다. 이 절은 실제 workflow 파일이나 원격 job을 실행한 결과를 제시하지 않습니다.

실패·승인·산출물을 독립적으로 구별하기

① 단위 검사가 실패했지만 호스트의 Git 연동 빌드는 성공해 사이트가 바뀌었습니다. 이것이 “검사 성공 뒤 배포”인가요? ② 검사와 프리뷰가 통과했고 담당자가 승인 버튼을 누르면 검증한 산출물을 배포합니다. 지속적 제공과 지속적 배포 중 어느 쪽인가요? ③ A 산출물을 프리뷰에서 검증한 뒤 운영에서는 다시 빌드해 B 산출물을 배포했습니다. 같은 commit이라는 사실만으로 A와 B의 바이트가 같다고 결론 낼 수 있나요?

의존 관계·수동 결정·동일 산출물의 풀이

①은 검사 실패가 호스트 배포를 막지 못한 구성입니다. 별도로 성공한 호스트 빌드가 검사 실패를 지우지는 않습니다. 검사 통과와 배포를 실제 의존 조건으로 연결해야 표의 정책이 됩니다.

②는 운영 배포에 수동 결정이 남으므로 지속적 제공의 예입니다. 준비와 배포 명령 자체를 자동화해도 최종 승인에 사람이 필요한 경계는 같습니다. ③은 환경 값·의존성·빌드 입력이나 재현성 때문에 바이트가 다를 수 있습니다. 같은 commit은 소스 식별 근거이며 동일 산출물의 증거는 아닙니다. 검증한 파일 묶음을 승격하거나 digest와 실제 배포 대상의 일치를 따로 확인합니다.

CI/CD 도입 요약과 다음 실습 포인트

CI/CD는 소프트웨어 개발의 현대적인 필수 요소이며, 특히 빠르고 지속적인 업데이트가 중요한 웹 애플리케이션 개발에서 그 가치를 발휘합니다.

CI(지속적 통합): 코드 변경 사항을 자주 통합하고 자동 빌드 및 테스트를 통해 버그를 조기에 발견합니다.
CD(지속적 제공/배포): CI를 통과한 코드를 릴리스 가능한 상태로 준비하거나, 자동으로 프로덕션에 배포합니다.
React 앱은 정적 호스팅 서비스의 Git 연동 자동 배포 기능(Netlify, Vercel 등)을 통해 쉽게 CI/CD를 시작할 수 있습니다.

이것으로 11장 배포와 다음 단계의 핵심 개념인 빌드, 배포, 그리고 CI/CD에 대한 설명을 마쳤습니다.

이 지식은 작성한 코드를 사용자에게 전달하는 배포 단계로 연결됩니다.