---
term: 'CI/CD (지속적 통합과 지속적 전달)'
seoTitle: 'CI/CD란? 지속적 통합과 지속적 전달·배포의 개념'
headline: 'CI/CD(지속적 통합과 지속적 전달)란?'
slug: ci-cd
category: cloud-architecture
shortDefinition: 'CI/CD는 코드의 빌드, 테스트, 릴리스를 자동화하여 모든 변경이 커밋에서 프로덕션까지 작은 단계로 이동하게 하는 관행입니다.'
relatedTerms:
  - no-ops-development
  - containerization
  - kubernetes
  - backend-boilerplate-code
  - cloud-code-serverless-functions
contrastsWith:
  - no-ops-development
faq:
  - question: 'CI/CD는 무엇의 약자입니까?'
    answer: 'Continuous Integration과 Continuous Delivery, 즉 지속적 통합과 지속적 전달의 약자입니다. 여기에는 모든 실무자가 알아야 할 모호함이 내장되어 있습니다. "CD"는 지속적 배포(continuous deployment)를 뜻하기도 합니다. 전달은 프로덕션 앞에 사람의 승인을 남겨 두고, 배포는 그 승인을 없앱니다. 누군가 "우리는 CI/CD를 합니다"라고 말하면, 어느 CD를 뜻하는지 되묻는 것이 언제나 유용합니다.'
  - question: '지속적 통합이란 무엇입니까?'
    answer: '작은 변경을 공유 메인라인에 자주 병합하는 관행입니다. 표준 정의로는 최소 하루에 한 번이며, 병합할 때마다 자동화된 빌드와 테스트가 실행됩니다. 핵심은 빠른 피드백입니다. 통합 문제가 몇 주 뒤 릴리스 직전의 혼란 속에서가 아니라 생긴 지 몇 분 안에 드러납니다.'
  - question: '지속적 전달과 지속적 배포의 차이는 무엇입니까?'
    answer: '수동 승인 단계 하나입니다. 지속적 전달에서는 모든 변경이 자동으로 빌드되고 테스트되어 언제든 릴리스 가능한 상태로 유지되지만, 프로덕션을 실제로 언제 갱신할지는 사람이 결정합니다. 지속적 배포에는 관문이 없습니다. 파이프라인을 통과한 모든 변경이 자동으로 프로덕션에 반영되며, 실패한 테스트만이 그것을 멈춥니다.'
  - question: 'CI/CD 파이프라인이란 무엇입니까?'
    answer: '변경이 커밋에서 프로덕션까지 거쳐 가는 자동화된 워크플로입니다. 소스 트리거, 빌드, 자동화된 테스트, 스테이징 환경으로의 전달, 배포로 이어집니다. 각 단계를 통과해야 다음 단계가 실행되므로 파이프라인은 모든 변경이 같은 방식으로 통과해야 하는 품질 관문 역할을 합니다. 예외도, 영웅적인 수동 배포도 없습니다.'
  - question: 'DORA 지표란 무엇입니까?'
    answer: 'DORA 연구 프로그램에서 나온, 전달 성과를 측정하는 업계 표준 방식입니다. 배포 빈도, 변경 리드 타임, 변경 실패율, 실패한 배포의 복구 시간, 그리고 가장 최근에 추가된 배포 재작업률입니다. 연구의 대표적인 결론은 속도와 안정성이 트레이드오프가 아니라는 것입니다. 최상위 팀은 둘 다 높은 점수를 받습니다.'
  - question: 'CI/CD는 DevOps와 같은 것입니까?'
    answer: '아닙니다. DevOps는 개발과 운영을 통합하는 더 넓은 문화이고, CI/CD는 그 자동화의 중추입니다. 문화 없이 CI/CD 도구만 도입할 수도 있고(기대보다 도움이 덜 됩니다), 자동화 없이 문화만 설파할 수도 있습니다(약속보다 바뀌는 것이 적습니다). 두 관행은 서로를 강화하지만 서로 다른 것을 가리킵니다.'
  - question: 'CI/CD 파이프라인에서는 어떤 테스트가 실행됩니까?'
    answer: '속도에 따라 계층을 나눕니다. 단위 테스트와 정적 분석은 빠르기 때문에 커밋마다 실행하고, 통합 테스트는 실제 의존성을 대상으로 구성 요소를 검증하며, 엔드투엔드 테스트, 성능 테스트, 보안 스캔은 느리기 때문에 후반 단계나 예약 실행에서 돌립니다. 설계 원칙은 이렇습니다. 피드백이 빠를수록 앞 단계에 둡니다.'
  - question: '작은 팀에도 CI/CD가 필요합니까?'
    answer: '배관보다 관행이 더 필요합니다. 두 명짜리 팀이라도 모든 변경에 대한 자동화된 테스트와 명령 하나로 끝나는 배포의 이점을 누리며, 이것이 실질적인 CI/CD입니다. 작은 팀이 피해야 할 것은 무거운 파이프라인 인프라를 직접 운영하는 일입니다. 호스팅된 러너나 배포 기능이 내장된 플랫폼을 쓰면 이 관행이 설정 수준으로 줄어듭니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Continuous Integration — Martin Fowler (updated 2024)'
    url: 'https://martinfowler.com/articles/continuousIntegration.html'
  - name: 'Continuous Delivery — Martin Fowler'
    url: 'https://martinfowler.com/bliki/ContinuousDelivery.html'
  - name: 'DORA metrics guide (dora.dev)'
    url: 'https://dora.dev/guides/dora-metrics-four-keys/'
  - name: 'CI/CD (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/CI/CD'
cta:
  title: '파이프라인 배관 없는 배포'
  text: 'Back4app은 CI/CD의 전달 쪽 절반을 크게 줄여 줍니다. Cloud Code 함수는 CLI 명령 하나로, 또는 Git 저장소에서 곧바로 배포되며, 데이터베이스, 인증, API는 이미 라이브 상태입니다. 테스트는 그대로 두고, 러너 서버군 운영은 건너뛰면 됩니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-11-02'
translationKey: ci-cd
---

**CI/CD는 코드의 빌드, 테스트, 릴리스를 자동화하여 모든 변경이 커밋에서 프로덕션까지 작은 단계로 이동하게 하는 관행입니다.** 이 이름에는 두 가지 생각이 압축되어 있습니다. 지속적 통합(끊임없이 병합하고 검증하는 것)과 지속적 전달(모든 변경을 릴리스 가능한 상태로 유지하는 것)입니다. 여기에 유명한 모호함이 하나 더해집니다. 두 번째 "D"는 지속적 *배포*를 뜻하기도 하며, 이 경우 커밋과 프로덕션 사이를 가로막는 것은 실패한 테스트뿐입니다.

## 핵심 요약

| 질문 | 답변 |
| --- | --- |
| 정의 | "릴리스 날"을 끊임없이 일어나는 평범한 일로 바꾸는 자동화 |
| CI | 작은 변경을 매일 병합. 병합할 때마다 자동으로 빌드하고 테스트 |
| 두 가지 CD | 전달은 프로덕션 앞에 사람의 승인을 남기고, 배포는 그것을 없앰 |
| 효과가 있는 이유 | 작은 변경은 작게 실패함. 빠른 피드백이 버그를 생긴 지 몇 분 만에 잡음 |
| 측정 방법 | 다섯 가지 DORA 지표. 속도와 안정성은 함께 올라감 |

## 파이프라인의 실제 모습

이 관행 전체가 설정 파일 하나에 들어갑니다. "CI/CD 설명" 페이지마다 묘사하지만 거의 아무도 보여 주지 않는 바로 그 결과물입니다:

```yaml
# pipeline.yml — "배포의 날"을 대체하는 자동화
on: push to main

jobs:
  build:
    steps:
      - checkout
      - run: npm ci && npm run build
  test:
    needs: build
    steps:
      - run: npm test            # 단위 + 통합 테스트, 모든 커밋마다
      - run: npm run lint        # 정적 분석
  deploy:
    needs: test
    approval: manual             # 이 줄을 지우면 → 지속적 배포
    steps:
      - run: npm run deploy
```

마지막 단계가 실행되고 몇 분 뒤면 모든 클라이언트가 이미 새 백엔드 버전을 호출하고 있습니다. 이것이 요점의 전부입니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Seconds after `b4a deploy`, every client is calling the new version
const version = await Parse.Cloud.run('version');
console.log(`API version: ${version}`); // no pipeline YAML, no runners
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
  if case .success(let version) = result {
    print("API version: \(version)") // fresh from the deploy
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("version", hashMapOf()) { version, e ->
  if (e == null) Log.d("API", "version: $version") // fresh from the deploy
}
```

## CI vs. 지속적 전달 vs. 지속적 배포

| 기준 | 지속적 통합 | 지속적 전달 | 지속적 배포 |
| --- | --- | --- | --- |
| 범위 | 병합 + 빌드 + 테스트 | …+ 항상 릴리스 가능한 아티팩트 | …+ 자동 릴리스 |
| 트리거 | 메인라인에 대한 모든 커밋 | 통과한 모든 빌드 | 통과한 모든 빌드 |
| 사람의 관문 | 없음(테스트가 관문) | **있음 – 릴리스 승인** | **없음** |
| 프로덕션 갱신 시점 | 누군가 릴리스할 때 | 누군가 클릭할 때 | 지속적으로 |
| 적합한 대상 | 모두 | 규제 대상 릴리스, 마케팅 일정에 맞춘 출시 | 웹 백엔드, SaaS, 신뢰도 높은 테스트 스위트 |

```mermaid
flowchart LR
  accTitle: CI/CD 파이프라인
  accDescr: 커밋이 자동화된 빌드와 테스트 단계를 트리거합니다. 통과한 변경은 스테이징에 도달한 뒤, 지속적 전달에서는 수동 승인 관문을, 지속적 배포에서는 관문 없이 프로덕션으로 넘어갑니다.
  A[커밋] --> B[빌드] --> C[자동화된 테스트] --> D[스테이징]
  D --> E{수동 승인?}
  E -- "예 – 지속적 전달" --> F[프로덕션]
  E -- "관문 없음 – 지속적 배포" --> F
```

계보는 한 문장으로 짚어 둘 만합니다. [Martin Fowler의 표준 글](https://martinfowler.com/articles/continuousIntegration.html)이 2000년에 CI를 정의했고, 2010년에 나온 책 *Continuous Delivery*가 이를 릴리스 프로세스로 확장했으며, DevOps가 이 둘을 자동화의 중추로 삼았습니다. Fowler가 짚은 날카로운 지적 하나는 지금도 유효합니다. 오래 유지되는 피처 브랜치를 대상으로 빌드 서버를 돌리는 것은 "반쪽 통합(semi-integration)"일 뿐이며, 진짜 CI는 메인라인이 모든 사람의 작업을 최소 하루에 한 번 통합하는 것을 뜻합니다.

## 단계별로 본 파이프라인

- **소스.** 커밋이나 병합이 모든 것을 트리거합니다. 수동 빌드는 절대 없습니다. 트리거되지 않는다면 CI가 아닙니다.
- **빌드.** 컴파일하고, 의존성을 해결하고, 이후 모든 단계가 재사용하는 아티팩트(번들, 컨테이너 이미지)를 만듭니다. 한 번 빌드하고 모든 곳으로 승격합니다.
- **테스트.** 빠른 검사부터 합니다. 단위 테스트와 린팅은 커밋마다, 실제 의존성을 대상으로 한 통합 테스트는 그다음, 엔드투엔드 테스트, 성능 테스트, 보안 스캔은 후반 단계나 예약 실행에서 합니다. 단계의 순서는 피드백 속도가 결정합니다.
- **전달.** 아티팩트가 프로덕션과 유사한 스테이징 환경에 도착합니다. 지속적 전달에서는 여기서 릴리스 가능한 상태로 사람의 승인을 기다립니다.
- **배포.** 프로덕션입니다. 성숙한 파이프라인은 일부 트래픽에만 먼저 내보내는 카나리 배포나 병렬 블루-그린 환경으로 점진적으로 배포하므로, 잘못된 변경은 장애가 아니라 범위가 제한된 롤백으로 끝납니다.

## 측정하기: DORA 지표

"우리는 전달을 잘하고 있는가?"라는 질문에는 표준 답이 있습니다. [DORA 연구 프로그램의 다섯 가지 지표](https://dora.dev/guides/dora-metrics-four-keys/)입니다. 배포 빈도, 변경 리드 타임, 변경 실패율, 실패한 배포의 복구 시간, 배포 재작업률입니다. 이 연구에서 가장 많이 인용되는 결론은 고전적인 속도 vs. 안정성 트레이드오프가 거짓이라는 것입니다. 가장 자주 배포하는 팀이 가장 적게 망가뜨립니다. 작고 잦은 변경은 하나하나의 위험이 낮고 진단이 빠르기 때문입니다. 파이프라인 작업이 다섯 지표 중 어느 것도 움직이지 못한다면, 그것은 진전이 아니라 배관 공사입니다.

## 일반적인 사용 사례

- **웹과 API 백엔드** – 완전한 지속적 배포의 본고장입니다. 변경량이 많고, 롤백이 즉각적이며, 설치 단계가 없습니다.
- **모바일 앱** – CI에 지속적 *전달*을 더합니다. 파이프라인이 모든 변경을 빌드하고 테스트하고 스테이징하지만, 스토어 심사가 있어 마지막 출시는 본질적으로 관문을 거칩니다.
- **배포 담당자 한 명을 넘어 성장하는 팀** – 파이프라인이 "릴리스하는 법을 아는" 단 한 사람을 누구나 실행할 수 있는 프로세스로 대체합니다.
- **규제 환경** – 승인 관문이 기능이 됩니다. 관문 직전까지는 완전히 자동화하고, 관문에서는 감사 가능한 사람의 결정을 남깁니다.
- **오픈소스 프로젝트** – 모든 풀 리퀘스트를 자동으로 빌드하고 테스트하는 것은 CI가 프로젝트의 정문 역할을 하는 것입니다.

## 프로덕션에 관문을 둬야 할까? 결정 매트릭스

| 지속적 배포를 선택할 때… | 전달 관문을 유지할 때… |
| --- | --- |
| 테스트 스위트를 프로덕션을 맡길 만큼 신뢰함 | 테스트 커버리지가 아직 그만한 신뢰를 쌓는 중임 |
| 롤백이 명령 하나 | 롤백이 하나의 프로젝트 |
| 사용자가 눈에 띄지 않는 지속적 업데이트를 기대함 | 릴리스를 마케팅이나 계약 일정에 맞춤 |
| 제품이 웹 백엔드나 SaaS | 제품이 앱 스토어 심사를 거쳐 출시됨 |
| 장애가 피처 플래그 뒤에서 우아하게 저하됨 | 잘못된 릴리스가 규제상의 결과를 낳음 |

솔직한 순서는 이렇습니다. 전달을 실천하며 배포할 자격을 얻는 것입니다. 관문 직전까지 모든 것을 자동화하고, 실패율을 지켜본 뒤, 관문이 더 이상 아무 역할도 하지 않을 때 없애면 됩니다.

## 한계와 트레이드오프

- **파이프라인은 직접 소유하는 코드입니다.** 러너, YAML, 캐시, 시크릿 모두 유지 보수가 필요하며, 팀이 어느 규모를 넘으면 파이프라인이 자체 온콜을 둔 하나의 제품이 됩니다.
- **불안정한(flaky) 테스트는 모든 것을 오염시킵니다.** 무작위로 실패하는 테스트 스위트는 사람들이 "재시도"를 누르도록 길들이고, 지속적 배포를 단계만 늘어난 수동 배포로 조용히 되돌립니다.
- **문화는 부산물이 아니라 전제 조건입니다.** 작은 병합, 메인라인 개발, 실패한 빌드의 즉시 수정은 습관입니다. 파이프라인을 산다고 설치되지 않습니다.
- **관측 가능성 없는 속도는 도박입니다.** 끊임없는 배포는 장애를 빠르게 볼 수 있을 때만 안전합니다. 모니터링과 알림은 부가 기능이 아니라 관행의 일부입니다.
- **마지막 구간은 제각각입니다.** 데이터베이스, 마이그레이션, 상태가 있는 서비스는 "그냥 다시 배포"에 저항합니다. 파이프라인에는 어떤 YAML도 대신 써 주지 않는 전략(확장-축소 마이그레이션, 피처 플래그)이 필요합니다.

## Back4app에서의 CI/CD

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. CI/CD에 미치는 효과는 전달 쪽의 덜어 내기입니다. Cloud Code는 CLI 명령 하나로, 또는 Git 저장소에서 곧바로 배포되고, 데이터베이스, 인증, API로 이루어진 표준 백엔드는 빌드하거나 릴리스할 것이 없으므로 파이프라인에 아예 등장하지 않습니다. 남는 것은 지켜야 할 절반입니다. 커밋마다 실행되는 테스트가, 이제 한 줄짜리가 된 배포 단계 앞에 서 있습니다.