CI/CD란 무엇인가? 비전공자도 이해하는 CI/CD 개념 정리

한 줄 요약

CI/CD는 코드 변경을 자동으로 합치고(CI), 자동으로 테스트·배포 준비까지 끝내는(CD) 소프트웨어 개발 방식이에요. CI/CD는 지속적 통합(Continuous Integration)과 지속적 전달/배포(Continuous Delivery/Deployment)를 뜻하며, 소프트웨어 개발 주기를 빠르고 안정적으로 만드는 것을 목표로 합니다.

---

1. 핵심 개념 설명

CI (Continuous Integration, 지속적 통합)

CI는 개발자들이 자신의 코드 변경 사항을 중앙 저장소에 자주 병합하고, 병합될 때마다 자동으로 빌드와 테스트가 실행되는 개발 방식입니다. 목표는 버그를 더 빨리 찾아내고, 소프트웨어 품질을 높이고, 새 업데이트를 검증하고 릴리스하는 데 걸리는 시간을 줄이는 것입니다.

빌드(build): 사람이 쓴 소스 코드를 컴퓨터가 실제로 실행할 수 있는 형태로 변환하는 과정이에요.

저장소(repository): 소스 코드를 버전별로 보관하는 공간이에요. Git이 대표적입니다.

 

코드를 자주 커밋할수록 오류를 더 이른 시점에 발견할 수 있고, 문제의 원인을 찾을 때 확인해야 할 코드의 양도 줄어듭니다.

CD ①: Continuous Delivery (지속적 전달)

지속적 전달에서는 모든 코드 변경이 빌드·테스트를 거쳐 운영 환경이 아닌 테스트·스테이징 환경까지 자동으로 올라갑니다. 운영 환경에 최종 반영할지는 사람이 결정합니다.

CD ②: Continuous Deployment (지속적 배포)

지속적 배포는 사람의 승인 절차 없이 운영 환경 반영까지 자동으로 진행된다는 점에서 지속적 전달과 구분됩니다. 즉 지속적 전달은 운영 환경 자동 배포 직전에서 멈추고, 지속적 배포는 변경 사항을 운영 환경까지 자동으로 내보냅니다.

왜 중요한가

DORA는 소프트웨어 전달 성능을 측정하는 지표 체계를 연구해 왔고, 현재는 기존 4개 지표에서 5개 지표 모델로 발전한 형태를 사용합니다. 여기서 배포 빈도와 변경 리드 타임은 속도를, 변경 실패율과 서비스 복구 시간은 안정성을 나타냅니다. 2015년 이후 연구에서는 속도와 안정성이 서로 희생 관계에 있다는 통념이 성립하지 않으며, 성과가 높은 조직은 두 가지를 동시에 달성한다는 결과가 확인되었습니다.

CI/CD는 이 지표들을 개선하기 위한 기술적 실천 방법에 해당해요.

---

2. 쉽게 이해하는 설명

CI/CD를 음식점 주방 에 비유해 볼게요.

상황	비유
CI 없음	요리사 5명이 각자 재료를 따로 손질해 두었다가, 영업 직전에 한꺼번에 합칩니다. 맛이 안 맞으면 원인을 찾기 어려워요.
CI 적용	재료를 손질할 때마다 바로 합쳐 보고 간을 봅니다. 문제가 생기면 방금 넣은 재료가 원인입니다.
Continuous Delivery	접시에 담아 서빙 직전 상태까지 준비해 두고, 내보낼지는 매니저가 결정합니다.
Continuous Deployment	완성되면 매니저 확인 없이 바로 손님 테이블로 나갑니다.

CI가 없으면 개발자들이 며칠에서 몇 주 동안 따로 작업한 뒤 한 번에 병합하게 되고, 충돌과 원인 추적이 어려운 버그가 쌓이는 상황이 발생합니다.

핵심은 "자동화"가 아니라 "자주, 작게 합치는 것"이에요. 자동화는 그것을 가능하게 만드는 수단입니다.

---

3. CI/CD 파이프라인의 기본 흐름

CI/CD는 수동 단계를 파이프라인으로 대체해 빌드·테스트·배포를 자동으로 수행하는 작업 흐름으로 설명할 수 있습니다.

코드 작성 → 커밋/푸시 → 자동 빌드 → 자동 테스트 → 아티팩트 생성 → 배포

파이프라인(pipeline): 위 단계들을 순서대로 자동 실행하도록 정의해 둔 흐름이에요.

아티팩트(artifact): 빌드 과정에서 만들어지는 결과물로, 컴파일된 코드나 라이브러리, 컨테이너 이미지 등이 여기에 해당하며 버전이 매겨져 보관됩니다.

지속적 전달은 CI를 전제로 하는 확장 개념이며, CI가 제대로 자리 잡지 않은 상태에서 도입하는 것은 권장되지 않습니다.

---

4. 핵심 정리

• CI 는 코드 변경을 중앙 저장소에 자주 병합하고, 그때마다 자동으로 빌드·테스트하는 방식이에요.
• Continuous Delivery 는 배포 가능한 상태까지 자동화하되, 운영 반영은 사람이 승인해요.
• Continuous Deployment 는 승인 단계 없이 운영 반영까지 자동으로 진행돼요.
• CI/CD의 목적은 배포 자동화 그 자체가 아니라, 오류를 이른 시점에 발견하고 릴리스 위험을 줄이는 것 이에요.
• CD를 도입하려면 CI가 먼저 안정적으로 동작해야 해요.

---

5. 추가 정보

CI/CD 도구 예시

CI 관리와 구축을 돕는 도구로 Jenkins, CircleCI, Bitbucket Pipelines, Bamboo, TeamCity 등이 사용됩니다. GitHub에서는 GitHub Actions를 이용해 저장소 안에서 직접 CI 워크플로를 구성할 수 있습니다.

도입 시 주의사항

• 테스트가 부실하면 CI/CD는 오히려 위험해요. 자동으로 통과된 코드가 자동으로 배포되기 때문이에요.
• Continuous Deployment는 모든 조직에 적합한 방식이 아니에요. 규제 산업이나 승인 절차가 필요한 서비스에서는 Continuous Delivery 단계까지만 적용하는 경우가 많습니다.
• 조직별 도입 성공률이나 구체적인 비용 절감 수치는 공식 문서 기준으로 명확히 확인되지 않음 으로 표기해요.

참고 출처

• AWS — What is Continuous Integration / Continuous Delivery
• GitLab — What is CI/CD
• Red Hat — What is CI/CD
• GitHub Docs — Continuous integration
• DORA (dora.dev) — Software delivery performance metrics
• Google Cloud Blog — Four Keys metrics