CD가 뭔가요? 지속적 전달과 배포의 개념부터 파이프라인 구성까지

소프트웨어 개발 현장에서 CI/CD라는 표현은 이제 일상 용어에 가깝다. 그런데 앞의 CI(지속적 통합)에 비해 뒤의 CD가 정확히 무엇을 가리키는지는 의외로 모호하게 이해되는 경우가 많다. CD는 하나의 단어이면서도 실제로는 두 가지 서로 다른 개념을 함께 품고 있고, 파이프라인의 어느 지점에서 자동화의 경계를 긋느냐에 따라 그 의미가 달라진다. 이 글은 CD의 정의와 원리, 파이프라인 단계 구성, 대표적인 배포 전략과 도구 생태계, 그리고 도입 시 반드시 짚어야 할 고려사항까지 하나의 흐름으로 정리한다.

 

 

 

 

 

 

 

 

▍ CD의 위치: CI 다음에 오는 자동화 단계

 

CD를 이해하려면 먼저 CI/CD 파이프라인 전체 구조 안에서 CD가 어느 자리에 놓이는지를 파악해야 한다. CI(Continuous Integration)는 여러 개발자가 작성한 코드를 공용 저장소에 자주 병합하고, 병합할 때마다 자동으로 빌드와 테스트를 수행해 통합 과정에서 발생하는 충돌과 오류를 조기에 잡아내는 활동이다. CI가 코드의 '검증'에 초점을 둔다면, CD는 그렇게 검증된 결과물을 실제 사용자에게 '전달'하는 뒤쪽 단계를 담당한다.

 

두 활동은 분리된 별개의 작업이 아니라 하나의 연속된 흐름으로 연결된다. 코드가 저장소에 커밋되면 빌드와 단위 테스트가 자동으로 돌아가고, 이 관문을 통과한 산출물은 실행 가능한 배포 아티팩트로 패키징되어 다음 단계로 넘어간다. 이때부터가 CD의 영역이다. 다시 말해 CD는 CI라는 튼튼한 토대 위에서만 제대로 작동한다. 자동 테스트가 부실하면 그 위에 아무리 정교한 배포 자동화를 얹어도 신뢰할 수 없는 결과가 나오기 때문이다.

 

 

 

▍ 같은 약자, 다른 의미: 지속적 전달과 지속적 배포

 

CD가 혼란을 주는 가장 큰 이유는 이 두 글자가 두 개의 개념을 동시에 지칭하기 때문이다. 하나는 Continuous Delivery(지속적 전달)이고, 다른 하나는 Continuous Deployment(지속적 배포)다. 두 개념은 파이프라인의 거의 모든 단계를 공유하지만, 마지막 순간에 결정적인 차이를 드러낸다. 그 차이는 한 문장으로 요약된다. 운영 환경으로 코드를 내보내는 마지막 결정을 사람이 내리는가, 아니면 시스템이 자동으로 내리는가.

 

 

 

▍ 지속적 전달(Continuous Delivery)

 

지속적 전달은 모든 코드 변경이 자동화된 빌드와 테스트를 거쳐 '언제든 배포 가능한 상태'로 준비되도록 만드는 관행이다. 코드는 빌드, 단위 테스트, 통합 테스트, 시스템 테스트, 스테이징 환경 검증까지 파이프라인 전 과정을 자동으로 통과한다. 다만 마지막 운영 배포만은 사람의 판단을 요구한다. 릴리스 관리자나 개발 리드가 검증된 산출물을 확인한 뒤 언제 내보낼지 결정하는 방식이다.

 

이 수동 관문(manual gate)은 통제 수단이라는 점에서 의미가 크다. 배포 시점을 마케팅 일정이나 규제 요건, 데이터베이스 마이그레이션 같은 외부 조건과 맞춰야 하는 상황에서, 사람이 최종 승인 버튼을 쥐고 있으면 일정을 조율할 여지가 생긴다. 금융이나 의료처럼 규제와 감사 추적이 중요한 분야에서 지속적 전달이 선호되는 이유가 여기에 있다.

 

 

 

 

 

 

▍ 지속적 배포(Continuous Deployment)

 

지속적 배포는 지속적 전달에서 마지막 수동 관문마저 제거한 형태다. 모든 자동 검증을 통과한 변경은 사람의 개입 없이 곧바로 운영 환경까지 자동으로 밀려 올라간다. 개발자가 작성한 코드가 몇 분 안에 실제 사용자에게 도달할 수 있다는 뜻이다. 이 방식은 피드백 순환을 가장 빠르게 만든다는 강점이 있지만, 그만큼 자동 테스트의 품질과 운영 모니터링 체계에 절대적으로 의존한다.

 

지속적 배포 환경에서는 변경이 즉시 반영되므로, 문제를 몇 초 안에 감지하고 자동으로 되돌리거나 담당자에게 알리는 체계가 필수다. 이 때문에 기능 플래그(feature flag)가 자주 함께 쓰인다. 코드는 운영 환경에 배포하되, 새 기능의 노출 여부는 플래그로 따로 제어함으로써 '배포'와 '릴리스'를 분리하는 것이다. 이 조합을 활용하면 자동 배포의 속도를 유지하면서도 기능 공개 시점은 사람이 통제할 수 있다.

 

정리하면 지속적 전달과 지속적 배포는 본질적으로 같은 자동화 세트를 공유하되, 자동화의 선을 어디에 긋느냐에서만 갈린다. 다음 표는 두 개념의 핵심 차이를 한눈에 비교한 것이다.

 

 

 

 

대부분의 소규모 팀이나 기존 사용자를 보유한 서비스는 지속적 전달부터 시작하는 편이 현실적이라는 관점이 일반적이다. 자동 테스트 커버리지가 충분히 무르익고 운영 감시 체계가 갖춰진 뒤에야 수동 관문을 떼어내 지속적 배포로 넘어가는 단계적 접근이 안전하다.

 

 

 

▍ CD 파이프라인의 단계별 구성

 

CD 파이프라인은 여러 단계가 순차적으로 연결된 구조로 이루어진다. 각 단계는 코드에 대한 확신을 조금씩 높여 나가는 관문 역할을 한다. 앞 단계를 통과하지 못하면 흐름이 멈추고 결과가 보고되며, 문제를 고쳐 다시 커밋하면 처음부터 다시 시작한다. 일반적인 구성은 다음과 같은 순서를 따른다.

 

소스 관리: 개발자가 버전 관리 시스템에 코드 변경을 커밋하면 파이프라인이 트리거된다.

 

빌드: 소스 코드를 컴파일하고 의존성을 설치해 실행 가능한 산출물, 즉 배포 아티팩트를 생성한다.

 

테스트: 단위 테스트로 시작해 통합 테스트, 시스템 테스트, 성능·보안 테스트까지 자동으로 실행한다.

 

스테이징 배포: 검증된 코드를 운영과 유사한 사전 환경에 올려 추가 검증을 수행한다.

 

운영 배포: 지속적 전달에서는 사람의 승인 후, 지속적 배포에서는 자동으로 실제 운영 환경에 반영한다.

 

모니터링: 배포 이후 오류율, 응답 지연, 자원 사용량 등을 관찰해 이상 징후를 감지한다.

 

여기서 눈여겨볼 부분은 배포 아티팩트의 개념이다. 빌드 단계에서 한 번 만들어진 산출물이 스테이징과 운영을 거치는 동안 재컴파일 없이 그대로 승격(promotion)되는 것이 원칙이다. 매 환경마다 다시 빌드하면 환경별로 미묘하게 다른 결과가 나올 위험이 커지기 때문이다. 동일한 아티팩트가 여러 환경을 통과하도록 만드는 것이 재현성을 보장하는 핵심 설계 원칙이다.

 

 

 

 

 

 

▍ 배포 전략: 위험을 관리하는 방법들

 

CD에서 '어떻게 배포하는가'는 '무엇을 배포하는가' 못지않게 중요하다. 새 버전을 운영 환경에 반영하는 방식에 따라 장애 발생 시의 파급 범위와 복구 속도가 크게 달라지기 때문이다. 실무에서 널리 쓰이는 대표적인 배포 전략은 다음과 같다.

 

 

 

▍ 롤링 업데이트

 

롤링 업데이트는 기존 인스턴스를 조금씩 새 버전으로 교체해 나가는 방식이다. 전체를 한꺼번에 바꾸지 않으므로 서비스 중단 없이 점진적으로 전환할 수 있다는 장점이 있다. 구성이 단순해 개발 환경이나 빠른 반복이 필요한 상황에 적합하지만, 배포 도중에는 구버전과 신버전이 함께 돌아가는 구간이 생기므로 두 버전이 공존할 때 문제가 없도록 설계해야 한다.

 

 

 

▍ 블루-그린 배포

 

블루-그린 배포는 현재 운영 중인 환경(블루)과 새 버전을 올린 환경(그린)을 나란히 두 벌 운영하는 방식이다. 그린 환경에서 충분히 검증한 뒤 트래픽을 한 번에 그린으로 전환하며, 문제가 생기면 즉시 블루로 되돌릴 수 있다. 순간적인 롤백이 가능하다는 점에서 보안 패치나 대규모 기능 릴리스처럼 위험도가 높은 변경에 적합하다. 다만 두 환경을 동시에 유지해야 하므로 배포 기간 동안 자원이 두 배로 필요하다는 부담이 있다.

 

 

 

▍ 카나리 배포

 

카나리 배포는 새 버전에 트래픽을 한꺼번에 몰지 않고 소량부터 점진적으로 흘려보내는 방식이다. 예를 들어 처음에는 전체 트래픽의 일부만 새 버전으로 보내 오류율과 응답 지연 같은 지표를 관찰하고, 이상이 없으면 비율을 단계적으로 늘려 결국 전량을 전환한다. 문제를 초기에 좁은 범위에서 잡아낼 수 있어 안전성을 극대화하는 전략으로 평가된다. 다만 정교한 트래픽 분할과 지표 기반 자동 판단 체계가 뒷받침되어야 제 기능을 발휘한다.

 

 

 

 

세 전략은 우열의 문제라기보다 상황에 맞는 선택의 문제다. 다음 표는 각 전략의 특성을 요약한 것이다.

 

 

 

 

 

 

▍ CD를 실현하는 도구 생태계

 

CD 파이프라인은 특정 하나의 도구로 완성되지 않고, 여러 도구가 각자의 역할을 맡아 연결되는 형태로 구축된다. 저장소 관리, 빌드·테스트 자동화, 배포 오케스트레이션, 모니터링이 서로 다른 계층에서 협력한다. 대표적인 도구들의 성격은 다음과 같이 정리할 수 있다.

 

Jenkins: 오래되고 널리 쓰이는 오픈소스 자동화 서버로, 풍부한 플러그인 덕에 거의 모든 환경에 대응한다. 대신 초기 설정과 유지 관리에 손이 많이 간다.

 

GitHub Actions: 저장소와 바로 연동되어 별도 서버 없이 파이프라인을 시작할 수 있다. 워크플로를 설정 파일로 정의하며 소규모 팀에서 도입 비용이 낮다.

 

GitLab CI/CD: 저장소 관리와 파이프라인을 한 플랫폼에서 처리할 수 있어 통합 운영이 편리하다.

 

클라우드 제공 도구: 특정 클라우드 위에서 서비스를 운영한다면 해당 클라우드의 배포 서비스를 쓰는 편이 통합 측면에서 유리하다.

 

쿠버네티스 환경이 널리 퍼지면서 CD의 무게 중심도 조금씩 이동하고 있다. 최근에는 Git 저장소를 시스템의 유일한 기준 상태(single source of truth)로 삼는 GitOps 방식이 주목받는다. 이 방식에서는 원하는 상태를 Git에 선언적으로 기술해 두면, 에이전트가 실제 운영 상태를 지속적으로 비교하고 조정한다. 누군가 클러스터를 직접 수정하더라도 Git에 정의된 상태로 자동 복원되며, 롤백은 대개 이전 커밋으로 되돌리는 방식으로 처리된다. 여기에 점진적 배포 전략을 얹으면 앞서 살펴본 블루-그린이나 카나리를 지표 분석 기반으로 자동화할 수 있다. 이러한 흐름은 배포를 코드로 관리한다는 점에서 감사 추적과 재현성 측면에서도 이점을 제공한다.

 

 

 

▍ 도입 전에 짚어야 할 고려사항

 

CD는 많은 이점을 약속하지만, 처음부터 완벽하게 구축하려는 시도는 오히려 자동화에 대한 불신을 낳기 쉽다. 실무에서 흔히 권장되는 접근은 단계적 확장이다. 먼저 빌드와 테스트 자동화를 안정적으로 정착시키고, 그 위에 스테이징 배포를 붙이며, 마지막으로 운영 배포 자동화로 나아가는 순서다. 이 과정에서 몇 가지 요소는 특히 중요하게 다뤄야 한다.

 

첫째, 테스트 문화가 자동화보다 먼저다. 자동으로 돌릴 테스트가 부실하면 파이프라인이 통과시킨 결과를 신뢰할 근거가 사라진다. 특히 지속적 배포로 넘어가려면 사용자에게 손해를 끼칠 수 있는 핵심 경로가 테스트로 충분히 덮여 있어야 하고, 테스트가 개발자가 건너뛰고 싶어질 만큼 느리지 않아야 한다.

 

둘째, 재현성을 보장하는 환경 관리다. 로컬에서는 되는데 운영에서는 안 되는 상황의 상당수는 런타임 버전 차이, 의존성 설치 방식의 불일치, 환경 변수 가정에서 비롯된다. 버전을 명시적으로 고정하고, 잠금 파일 기준으로 깨끗하게 설치하는 습관이 이런 균열을 줄여 준다.

 

셋째, 비밀값 관리와 보안이다. API 키나 데이터베이스 비밀번호가 파이프라인 설정 파일에 그대로 노출되지 않도록 시크릿 관리 기능을 반드시 활용해야 한다. 자동화 초반에 권한을 넓게 열어 두고 빠른 동작만 우선하는 습관은 이후 운영 위험으로 남는 경우가 많으므로, 최소 권한 원칙을 처음부터 적용하는 편이 안전하다.

 

넷째, 배포와 짝을 이루는 모니터링과 롤백 체계다. 특히 지속적 배포에서는 문제를 빠르게 감지하고 되돌리는 능력이 자동화 자체만큼이나 중요하다. 되돌릴 수 없는 자동화는 속도만 빠른 위험으로 바뀔 수 있다.

 

 

 

 

 

 

▍ 결론: CD는 도구가 아니라 신뢰의 구조다

 

CD는 결국 검증된 코드를 사용자에게 얼마나 안전하고 반복 가능하게 전달하느냐의 문제로 귀결된다. 지속적 전달과 지속적 배포는 자동화의 경계선을 어디에 긋느냐로 갈릴 뿐, 튼튼한 테스트와 재현 가능한 환경, 관찰 가능한 운영이라는 토대를 공유한다. 그 토대가 약하면 어떤 배포 전략이나 도구를 얹어도 신뢰할 수 있는 파이프라인이 되기 어렵다.

 

따라서 CD 도입의 출발점은 화려한 배포 도구를 고르는 일이 아니라, 팀이 감당할 수 있는 범위에서 자동화의 신뢰 수준을 한 단계씩 끌어올리는 일이다. 작은 프로젝트라면 빌드와 테스트 자동화부터 시작해 점차 배포 단계로 확장해 보는 접근이 가장 견고하다. CD를 단순한 기술 편의 기능이 아니라, 개발과 운영이 함께 쌓아 가는 신뢰의 구조로 바라볼 때 그 진짜 가치가 드러난다.