8.1 CI/CD와 전달

개요와 동기

지속적 통합과 지속적 전달(CI/CD)은 코드를 쓰는 일과 그것을 안전하게 사용자 앞에 두는 일 사이의 결합 조직입니다. 지속적 통합은 모든 변경이 공유 메인라인에 자주 병합된 뒤 자동으로 빌드되고 테스트된다는 뜻으로, 통합 문제가 긴 릴리스 주기의 끝이 아니라 몇 분 안에 드러납니다. 지속적 전달은 파이프라인을 통과한 모든 변경이 배포 가능한 상태로 유지된다는 뜻으로, 프로덕션 릴리스가 엔지니어링의 난리가 아니라 비즈니스 결정이 됩니다. 지속적 배포는 한 걸음 더 나아가 통과한 모든 변경을 사람의 관문 없이 자동으로 릴리스합니다.

큰 팀에게 이 구별은 대단히 중요합니다. 수백 명의 엔지니어가 겹치는 시스템에 커밋할 때 수동 통합과 수동 테스트의 비용은 비선형적으로 커집니다. 공유되고 자동화된 파이프라인은 많은 기여자에게 빠르고 믿을 만한 피드백을 주고 한 팀의 변경이 다른 팀의 것을 조용히 깨뜨리지 않게 하는 유일한 실용적 방법입니다. 파이프라인은 소프트웨어가 건강한지에 대한 단일 진실 원천이 되며, 어떤 문서나 선의로도 규모에서 보장할 수 없는 일관성을 시행합니다.

기업과 정부 맥락은 감사 가능성과 변경 통제라는 차원을 하나 더합니다. 규제 기관, 보안 담당자, 감사자는 변경이 리뷰, 테스트, 승인되었다는 증거와, 프로덕션에서 돌아가는 산출물이 빌드되고 검증된 바로 그것이라는 증거를 필요로 합니다. 잘 설계된 CI/CD 파이프라인은 이런 컴플라이언스 의무를 서류 작업의 부담에서 일반적인 엔지니어링 워크플로의 자동적인 부산물로 바꿉니다. 잘 하면 전달이 동시에 더 빠르고 더 안전해지며, 이것이 리더십에게 가장 중요한 성과입니다.

함께 보기: 8.4장(플랫폼 엔지니어링과 개발자 경험), 8.5장(테스트 및 프로세스 자동화), 점진적 전달(상태 지표를 자동으로 모니터링하며 변경을 점진적으로 릴리스하는 것)이 가능하게 하는 기능 플래그(재배포 없이 기능을 사용자에게 노출하는 런타임 스위치)와 실험 실천에 대한 7.4장(제품 분석과 실험).

핵심 원칙

작은 변경을 자주 통합하십시오. 오래 사는 브랜치는 지속적 통합의 적입니다.
산출물을 한 번 빌드하고 동일한 산출물을 모든 환경에 승격하십시오.
파이프라인을 권위 있는 관문으로 삼으십시오. 초록이면 변경은 출하 가능하고, 빨강이면 고쳐질 때까지 작업이 멈춥니다.
개발자가 몰입을 유지하고 맥락이 신선할 때 결함이 잡히도록 빠른 피드백을 끈질기게 최적화하십시오.
테스트, 보안 스캔, 프로비저닝, 배포를 포함해 반복되는 모든 것을 자동화하십시오.
파이프라인 정의를 클릭하는 콘솔 구성이 아니라 리뷰를 받는 버전 관리되는 코드로 다루십시오.
어떤 배포든 빨리 되돌릴 수 있도록 안전하고 되돌릴 수 있는 릴리스를 설계하십시오.
기능 플래그로 배포(코드 설치)와 릴리스(사용자에게 노출)를 분리하십시오.

권장 사항

파이프라인을 일련의 품질 관문으로 설계한다

파이프라인을 싸고 빠른 것에서 비싸고 철저한 것으로 진행하는 단계로 구조화하십시오. 컴파일과 단위 테스트가 먼저, 그다음 통합 테스트, 보안 및 라이선스 스캔, 마지막으로 스테이징과 프로덕션 배포입니다. 각 단계는 변경이 통과해야 하는 관문입니다. 가장 빠르고 실패할 가능성이 큰 검사가 먼저 돌도록 관문의 순서를 정해, 개발자에게 가능한 가장 짧은 시간에 피드백을 주십시오. 할 수 있는 곳에서는 커밋 단계 피드백 루프를 10분 아래로 유지하십시오. 그 이상에서는 개발자가 맥락 전환을 하고 생산성이 떨어집니다.

한 번 빌드하고 어디서나 승격한다

빌드 단계에서 단일 불변 산출물을 만들고 정확히 그 산출물을 테스트, 스테이징, 프로덕션으로 승격하십시오. 환경마다 다시 빌드하지 마십시오. 재빌드는 차이를 조용히 들일 수 있기 때문입니다. 환경마다 달라지는 구성은 별도 빌드에 구워 넣지 말고 배포 시점에 주입하십시오. 이 실천이 프로덕션의 바이너리가 모든 관문을 통과한 바로 그것임을 감사자에게 확실하게 말할 수 있게 해 줍니다.

파이프라인을 정책의 시행 지점으로 삼는다

필수 검사(코드 리뷰 승인, 테스트 커버리지 임계값, 보안 스캔 결과, 서명된 커밋)를 파이프라인과 브랜치 보호 규칙에 직접 코드화하십시오. 위키에 사는 수동 정책은 마감 압박 아래서 으레 우회됩니다. 파이프라인에 코드화된 정책은 모든 변경에 균일하게 자동으로 적용됩니다.

메인라인을 항상 릴리스 가능하게 유지한다

모든 작업을 오래 사는 브랜치가 거의 없거나 전혀 없는 하나의 공유 브랜치에 통합하는 트렁크 기반 개발을 쓰거나, 수명이 짧은 기능 브랜치를 쓰고, 미완성 작업을 오래 사는 브랜치가 아니라 기능 플래그로 숨기십시오. 이는 병합 충돌을 작게 유지하고 메인라인을 항상 배포 가능한 상태로 유지하며, 이것이 진정한 지속적 전달의 전제 조건입니다.

배포 전략을 의도적으로 고른다

배포 전략을 서비스의 위험과 피해 범위에 맞추십시오.

롤링 배포는 인스턴스를 점진적으로 교체하며 무상태 서비스의 합리적인 기본값입니다.
블루-그린은 두 개의 동일한 환경을 유지하고 트래픽을 한꺼번에 전환해 즉각적인 롤백 경로를 줍니다.
카나리 릴리스는 트래픽의 작은 비율을 새 버전으로 보내고, 상태 지표를 지켜보고, 신호가 좋을 때만 확대합니다.
기능 플래그는 릴리스를 배포와 분리해, 재배포 없이 특정 사용자나 코호트에 기능을 켜게 합니다.

자동 롤백이 있는 점진적 전달을 채택한다

점진적 전달은 카나리 릴리스를 오류율, 지연, 포화 같은 지표의 자동 분석과 결합합니다. 객관적인 상태 기준을 미리 정의한 뒤, 시스템이 그 신호에 근거해 자동으로 승격하거나 롤백하게 하십시오. 자동 롤백은 작은 사고를 큰 사고로 바꾸는 사람의 주저함을 없앱니다.

규제 환경을 위한 릴리스 관리와 변경 통제를 제공한다

규제 환경에서는 가볍지만 실제인 변경 관리 기록을 유지하십시오. 누가 각 변경을 승인했는지, 어떤 테스트가 돌았는지, 어떤 산출물이 배포되었는지 자동으로 포착하십시오. 정말로 위험이 큰 변경에는 변경 자문 프로세스를 쓰되 그런 경우에만 남겨 두십시오. 모든 일상적 변경을 주간 위원회에 보내면 자동화의 가치가 파괴됩니다. 대신 의식 없이 파이프라인을 흐르는 표준적이고 사전 승인된 변경 유형을 목표로 하십시오.

장단점

접근	장점	단점	가장 적합한 곳
지속적 전달 (수동 릴리스 관문)	비즈니스가 시점을 통제. 규제된 릴리스 기간에 강함	메인라인을 출하 가능하게 유지하는 규율 필요	변경 기간이 있는 기업
지속적 배포 (완전 자동)	가장 빠른 피드백. 가장 작은 배치	성숙한 테스트와 관측 가능성 요구	신뢰가 높고 빈도가 높은 팀
블루-그린	즉각 롤백. 단순한 멘탈 모델	전환 중 환경 비용이 두 배	빠른 되돌림이 필요한 핵심 서비스
카나리 + 점진적 전달	피해 범위 제한. 데이터 기반	만들기 복잡. 좋은 지표 필요	대규모 사용자 대면 시스템
기능 플래그	배포를 릴리스와 분리	정리하지 않으면 플래그 부채	미완성 작업을 안전하게 출하하는 팀

중심 트레이드오프는 속도 대 통제이지만, 흔히 거짓 선택입니다. 성숙한 자동화는 둘 다 줍니다. 릴리스가 더 작아서 더 빠르고, 각각이 검증되고 되돌릴 수 있어서 더 안전합니다. 진짜 비용은 테스트 커버리지, 관측 가능성, 파이프라인 엔지니어링에 대한 선행 투자와 이를 건강하게 유지하는 지속적 규율입니다. 그 투자를 아끼는 조직은 안전 없이 속도를 얻으며, 이는 느린 수동 프로세스보다 나쁩니다.

팀과 논의할 질문

커밋 단계 피드백 시간의 목표는 무엇이며, 스위트가 10분을 넘어 커지면 무엇을 잘라 냅니까? 느린 커밋 단계는 지속적 통합을 조용히 죽입니다. 개발자가 초록을 기다리기를 멈추고 변경을 묶기 시작하기 때문입니다. 숫자를 지금 정하고(이 장은 10분 미만을 주장합니다) 그것을 유지할 메커니즘을 정하십시오. 병렬 워커, 엄격한 테스트 피라미드, 느린 통합 검사를 이후 단계로 옮기는 것입니다. 기업 규모에서 이것은 플랫폼 결정입니다. 수백 명의 엔지니어가 같은 파이프라인을 공유하고 추가되는 모든 분이 모든 커밋에 걸쳐 곱해지기 때문입니다. 회의에 실제 데이터를 가져오십시오. 현재 파이프라인 소요 시간의 p50과 p95, 가장 느린 테스트 열 개, 사람들이 기다리는 대신 다시 실행하는 빈도입니다. 목표를 진술하고 숫자로 방어할 수 없다면, 파이프라인은 CI 의상을 입은 배치 프로세스로 표류하고 있는 것입니다.
각 서비스는 어떤 배포 전략을 쓰며, 그 선택에는 누가 책임집니까? 롤링, 블루-그린, 카나리는 서로 바꿔 쓸 수 없습니다. 비용, 롤백 속도, 복잡성을 다르게 맞바꾸며, 올바른 선택은 서비스의 피해 범위에 달려 있습니다. 블루-그린은 전환 중 두 배의 환경이라는 대가로 즉각 롤백을 사며, 결제 시스템에는 값하지만 내부 대시보드에는 낭비입니다. 카나리는 노출을 제한하지만 좋은 상태 지표와 더 많은 파이프라인 엔지니어링을 요구합니다. 크거나 규제된 영역에서 이를 각 팀의 습관에 맡기면 사고 중에 드러나는 비일관성이 생기므로, 서비스 등급별 기본값에 합의하고 결정을 기록하십시오. 서비스 카탈로그를 가져와 각 서비스에 그 전략, 롤백 경로, 그 판단을 소유한 사람을 표시하십시오.
프로덕션의 산출물이 모든 관문을 통과한 바로 그것임을 어떻게 증명합니까? 한 번 빌드하고 동일한 산출물을 승격하는 것이 감사 가능성의 전부이며, 누군가 환경마다 다시 빌드하거나 실행 중인 상자를 패치하는 순간 깨집니다. 기업과 정부 환경에서 감사자는 실행 중인 바이너리를 그 커밋, 리뷰, 승인까지 추적해 달라고 요청할 것이고, 그 답이 일주일이 아니라 몇 초 걸리기를 원합니다. 어떻게 시행할지 정하십시오. 불변 산출물, 서명된 이미지, 배포 시점의 서명 검증, 별도 빌드에 구워 넣지 않고 배포 시점에 주입하는 구성입니다. 현재의 간극을 테이블에 가져오십시오. 재빌드하는 모든 단계, 모든 수동 핫픽스 경로, 구성이 산출물을 갈라놓는 모든 곳입니다. 답이 컴플라이언스 증거가 파이프라인의 부산물인지 감사 전마다의 수동적 허둥지둥인지를 정합니다.
메인라인이 빨강이 되면 실제로 무엇이 멈추며, 불안정한 테스트는 어떻게 다룹니까? 파이프라인은 빨간 빌드가 작업을 실제로 멈출 때만 권위 있는 관문이지만, 많은 조직이 깨진 메인라인과 간헐적 실패의 적체를 조용히 용인하며, 이는 개발자가 초록이 될 때까지 다시 실행하고 실패 위에 출하하도록 훈련시킵니다. 큰 팀에서 이 부패는 누적됩니다. 한 팀이 무시한 불안정성이 모두가 관문을 우회하는 핑계가 되고, 파이프라인에 대한 신뢰는 다시 쌓는 것보다 지키는 것이 훨씬 싸기 때문입니다. 경쟁하는 끌림을 저울질하십시오. 엄격한 라인 정지 규칙은 품질을 지키지만 나쁜 커밋 하나로 수백 명의 엔지니어를 막을 수 있고, 관대한 정책은 처리량을 지키지만 관문을 침식합니다. 논의에 증거를 가져오십시오. 현재 메인라인이 빨강이었던 시간, 격리되었거나 불안정한 테스트의 수, 재실행률, 실패하는 검사 위로 변경이 병합되는 빈도입니다. 기업과 정부 환경에서는 누가 불안정성 분류를 소유하고 누가 병합을 동결할 권한이 있는지 이름을 정하십시오. 아무도 시행할 책임이 없는 관문은 감사자가 으레 무시되어 왔음을 발견할 관문이기 때문입니다.
기능 플래그의 수명 주기는 무엇이며, 폐기할 책임은 누구에게 있습니까? 플래그는 배포와 릴리스를 분리하고 미완성 작업을 숨기게 해 주지만, 모든 플래그는 저절로 정리되지 않는 코드의 분기이며, 관리되지 않은 플래그는 아무도 감히 건드리지 못하는 조건부 복잡성으로 쌓입니다. 큰 영역에서 이 부채는 위험합니다. 낡은 플래그가 보안 수정을 조용히 가로막거나 테스트되지 않은 코드 경로를 프로덕션으로 뒤집을 수 있고, 그것을 만든 사람은 이미 떠났기 때문입니다. 긴장의 균형을 잡으십시오. 플래그는 안전하고 점진적인 전달을 사 주었으므로 목표는 더 적은 플래그가 아니라 소유자, 만료 기대, 낡은 것을 드러내는 도구가 있는 규율 있는 수명 주기입니다. 회의에 현재 목록을 가져오십시오. 라이브 플래그가 몇 개인지, 가장 오래된 것이 얼마나 되었는지, 소유자가 없는 것은 무엇인지, 오래 사는 플래그가 지금 다른 곳에 속하는 영구 구성으로 기능하는지입니다. 규제 환경에서는 누가 프로덕션에서 플래그를 바꿀 수 있고 그 변경이 배포와 같은 엄밀함으로 기록되는지를 더하십시오. 파이프라인이 돌지 않아도 플래그 전환은 릴리스이기 때문입니다.
사람 관문이 있는 지속적 전달과 완전한 지속적 배포 사이의 경계는 어디이며, 롤백 임계값은 누가 정합니까? 지속적 전달은 사람이 릴리스 시점을 통제하게 하여 법정 변경 기간과 피해 범위가 큰 시스템에 맞고, 지속적 배포는 통과한 모든 변경을 자동으로 출하하며 안전하려면 성숙한 테스트, 관측 가능성, 자동 롤백을 요구합니다. 크거나 규제된 조직에서 답은 균일한 경우가 드뭅니다. 마케팅 사이트는 지속적으로 배포하고 결제 핵심은 문서화된 사람 관문을 유지할 수 있으며, 서비스 등급별로 그 선을 그으면 불필요한 마찰과 무모한 자동화를 모두 막습니다. 경쟁하는 고려는 속도와 배치 크기 대 통제와 감사 가능성, 그리고 자동 롤백이 요구하는 상태 지표의 엔지니어링 비용입니다. 증거를 가져오십시오. 서비스별 변경 실패율, 평균 복구 시간, 현재 릴리스 주기, 사람 없이 승격하거나 롤백할 때 신뢰할 객관적 신호(오류율, 지연, 포화)입니다. 정부와 기업 환경에서는 각 등급을 누가 롤백 임계값을 소유하고 누가 관문이 있는 릴리스에서 완전 자동화로의 이동을 승인하는지에 묶어, 결정이 표류하는 대신 의도적이게 하십시오.

분야별 관점

스타트업. 첫날부터 관리형 CI/CD에 기대십시오. 호스팅 러너, 하나의 파이프라인, 하나의 불변 이미지, 병합 시 스테이징으로의 자동 배포입니다. 나중에 유지해야 하는 파이프라인 인프라를 만들지 마십시오. 기능 플래그는 두세 명의 엔지니어가 반쯤 끝난 작업을 안전하게 병합하고 하루에 여러 번 출하하게 하며, 원클릭 프로덕션 배포와 빠른 플래그 끄기가 규모가 더 요구할 때까지 필요한 변경 통제의 전부입니다.

소기업. 전담 플랫폼이나 릴리스 엔지니어가 없으니 소스 호스트가 주는 파이프라인(내장 Actions나 그에 상당하는 것)과 그 기본 배포 전략을 맞춤 무엇보다 선호하십시오. 구매 대 구축의 선택을 정직하게 구성하십시오. 관리형 파이프라인과 내장 롤백이 있는 호스팅 플랫폼은 맞춤 구성이 먹는 엔지니어 시간보다 비용이 적습니다. 핵심, 곧 한 번 빌드, 같은 산출물 승격, 쉬운 되돌림을 유지하고, 물량이 정당화할 때까지 점진적 전달 기계는 건너뛰십시오.

대기업. 핵심 문제는 많은 팀에 걸친 일관성입니다. 리뷰, 스캔, 서명된 불변 산출물, 등급별 배포 전략을 시행하는 공유 파이프라인 템플릿을 표준화해 품질이 팀마다 달라지지 않게 하십시오. 파이프라인 정의를 리뷰된 코드로 다루고, 변경 통제 증거를 자동으로 포착하고, 기능 플래그와 롤백 임계값을 각 팀의 사적 습관이 아니라 거버넌스가 적용되는 자산으로 관리하십시오. 보답은 더 빠른 전달과, 분기마다의 허둥지둥 대신 부산물로 만들어지는 감사 증거입니다.

정부. 조달 규칙, 법정 변경 기간, 공적 책임이 파이프라인을 형성합니다. 중대한 시스템에는 완전 자동화보다 문서화된 사람 릴리스 관문이 있는 지속적 전달을 선호하고, 일상 작업을 사전 승인된 표준 변경으로 분류하고, 시민이 좁은 연간 기간 동안 의존하는 서비스에는 즉각적인 롤백 경로(블루-그린이나 자동화된 카나리)를 유지하십시오. 투명성과 감사 의무가 수동 서류 작업이 아니라 일반적인 워크플로로 충족되도록, 파이프라인이 누가 각 변경을 승인했는지, 어떤 테스트가 돌았는지, 어떤 산출물이 배포되었는지 기록하게 하십시오.

사례

스타트업. 네 명의 SaaS 스타트업이 단위 테스트를 돌리고, 하나의 Docker 이미지를 빌드하고, main에 병합할 때마다 그 같은 이미지를 스테이징에 자동 배포하는 하나의 GitHub Actions 파이프라인을 연결합니다. 프로덕션 배포는 클릭 한 번이며, 창업자들은 몇 주 동안 브랜치를 살려 두는 대신 반쯤 끝난 작업을 플래그 뒤에 병합할 수 있도록 기능 플래그에 기댑니다. 나쁜 릴리스가 새어 나가면 몇 초 만에 플래그를 끄고 침착하게 고치며, 이것이 전담 운영 인력 없이도 아주 작은 팀이 하루에 여러 번 출하하게 해 줍니다.

기업. 한 글로벌 은행이 수십 개의 팀별 Jenkins 작업을 모든 제품 팀이 물려받는 표준화된 파이프라인 템플릿으로 통합합니다. 템플릿은 정적 분석, 의존성 스캔, 서명된 불변 산출물을 시행하고, 오류율과 지연 임계값에 맞춘 자동 롤백이 있는 카나리로 배포합니다. 같은 산출물이 테스트에서 프로덕션으로 승격되고 모든 관문이 기록되므로, 은행의 감사자는 어떤 프로덕션 바이너리든 그 커밋, 리뷰, 승인까지 몇 초 만에 추적할 수 있어, 분기마다의 수동 증거 수집 작업을 대체합니다.

정부. 신고 시스템을 현대화하는 한 국세청이 신고 시즌의 법정 변경 기간을 존중할 수 있도록 명시적 사람 릴리스 관문이 있는 지속적 전달을 채택합니다. 일상적 변경은 스테이징으로 자동 흐르는 표준 사전 승인 변경으로 분류됩니다. 프로덕션 릴리스는 파이프라인이 기록하는 하나의 문서화된 승인을 요구합니다. 블루-그린 배포는 결함이 프로덕션에 닿을 경우 기관에 즉각적인 롤백 경로를 주며, 수백만 시민이 좁은 연간 기간 동안 서비스에 의존할 때 결정적입니다.

비즈니스 사례: 동기, ROI, TCO

CI/CD 투자의 수익은 변경의 리드 타임 단축, 더 낮은 변경 실패율, 사고 발생 시 더 빠른 복구로 나타납니다. 연구가 전달 성과와 조직 성과 모두에 일관되게 연결하는 지표들입니다. 더 빠르고 더 작은 릴리스는 규모에서 엔지니어링 역량을 소모하는 조율 오버헤드를 줄이고, 자동화된 검증은 프로덕션 결함을 불 끄는 비싸고 사기를 꺾는 일을 줄입니다.

총소유비용은 도입 비용을 도입하지 않는 비용에 견주어 저울질합니다. 도입 비용에는 파이프라인의 구축과 유지, 테스트 커버리지의 확대, 관측 가능성과 플랫폼 인력에 대한 투자가 포함됩니다. 도입하지 않는 비용은 더 크지만 덜 보입니다. 느린 수동 릴리스, 통합의 고통, 평판을 해치는 프로덕션 사고, 규제 환경에서는 실패한 감사와 시정입니다. 리더십에게 논거는 위험 감소와 역량의 관점으로 구성하는 것이 가장 좋습니다. 자동화는 희소한 시니어 엔지니어의 시간을 반복적인 릴리스 고역에서 제품 작업으로 바꾸는 동시에 장애를 더 드물고 짧게 만듭니다.

안티패턴과 함정

스노플레이크 파이프라인. 모든 팀이 고유한 파이프라인을 손으로 만들어 개선과 수정을 공유할 수 없고 품질이 크게 갈립니다.
환경마다 재빌드. 단계마다 재빌드하면 “한 번 빌드” 보장이 깨지고 미묘한 차이가 프로덕션에 닿습니다.
무시되는 빨간 빌드. 지속적으로 깨진 메인라인을 용인하면 파이프라인에 대한 신뢰가 파괴되고 실패 위에 출하하는 것이 정상화됩니다.
방치된 불안정한 테스트. 간헐적 실패는 개발자가 초록이 될 때까지 다시 실행하도록 훈련시켜 관문의 목적을 무너뜨립니다.
수동 승인 연극. 모든 것을 도장 찍는 변경 자문 위원회는 안전을 더하지 않고 지연만 더합니다.
플래그 부채. 제거되지 않는 기능 플래그는 유지할 수 없는 조건부 복잡성으로 쌓입니다.
배포가 곧 릴리스. 둘을 결합하면 모든 사용자 대면 변경이 위험한 재배포를 요구합니다.

성숙도 모델

1단계: 시작. 빌드와 배포가 대체로 수동적이고, 즉흥적이며, 반응적입니다. 통합이 늦게 일어나고, 릴리스는 드물고 스트레스가 많으며, 롤백은 옛 버전을 손으로 재배포하는 것을 뜻하고, 파이프라인 관문에 대한 공유된 개념이 없습니다.

2단계: 발전. 자동화된 빌드와 단위 테스트가 커밋마다 돌지만 실천은 팀마다 다릅니다. 배포는 스크립트화되었지만 여전히 수동으로 촉발되고 감독되며, 일부 환경은 일관되고, 산출물은 단계마다 다시 빌드될 수 있습니다. 파이프라인이 있는 곳에서는 흔히 공유할 수 없는 스노플레이크입니다.

3단계: 표준화. 문서화된 표준화된 파이프라인 템플릿이 팀 전반에 시행됩니다. 단일 불변 산출물을 모든 환경으로 승격하고, 자동화된 품질 및 보안 관문을 적용하고, 리뷰 승인과 스캔 결과 같은 필수 검사를 코드화하고, 변경 기록을 자동으로 포착합니다. 카나리나 블루-그린 같은 배포 전략은 서비스 등급별로 의도적으로 고릅니다.

4단계: 관리. 전달이 기준선에 대해 측정되고 통제됩니다. 조직은 변경의 리드 타임, 배포 빈도, 변경 실패율, 평균 복구 시간과 함께 파이프라인 p50 및 p95 소요 시간, 불안정한 테스트와 재실행률, 기능 플래그의 나이를 추적합니다. 롤백 임계값은 관찰된 오류율, 지연, 포화 데이터로 정해지고, 관문은 습관이 아니라 증거로 시행되며, 각 지표에는 목표에서 벗어날 때 행동하는 소유자가 있습니다.

5단계: 오케스트레이션. 전달이 지속적으로 개선되고 조직 전체에 통합됩니다. 자동화된 지표 기반 롤백이 있는 점진적 전달이 규범이고, 릴리스는 잘 다스려지는 플래그를 통해 배포와 분리되며, 컴플라이언스 증거는 부산물로 자동 생산됩니다. 파이프라인은 영역이 바뀜에 따라 적응하고, 전달 지표는 비즈니스 및 위험 계획에 공급되어 투자가 가장 지렛대 효과가 큰 개선으로 흐릅니다.

논의를 위한 아이디어

가장 핵심적인 시스템에서 사람 관문이 있는 지속적 전달과 완전한 지속적 배포 사이의 올바른 경계는 어디입니까?
의무적인 변경 관리 프로세스를 도장 찍기 연극으로 만들지 않고 의미 있게 유지하려면 어떻게 합니까?
어떤 객관적 상태 지표가 자동 롤백을 다스려야 하며, 그 임계값은 누가 소유합니까?
플랫폼 팀은 표준화된 파이프라인 템플릿과 특이한 요건을 가진 팀의 정당한 필요 사이의 균형을 어떻게 맞춰야 합니까?
부채가 되기 전에 기능 플래그를 폐기하는 정책과 도구는 무엇입니까?
더 빠른 전달이 단지 더 많이 출하하는 것이 아니라 비즈니스 성과를 실제로 개선하는지 어떻게 측정합니까?

핵심 요점

CI, CD, 지속적 배포는 구별됩니다. 위험 허용도와 성숙도에 맞는 자동화 수준을 고르십시오.
산출물을 한 번 빌드하고 동일한 산출물을 모든 환경에 승격하십시오.
파이프라인을 빠른 피드백에 최적화된 순서 있는 품질 관문으로 설계하고 권위 있는 출하 결정으로 다루십시오.
배포 전략을 의도적으로 고르고, 피해 범위를 제한하도록 자동 롤백이 있는 점진적 전달을 채택하십시오.
기능 플래그로 릴리스를 배포와 분리하고 플래그 부채를 관리하십시오.
규제 환경에서는 변경 통제 증거를 수동 서류 작업이 아니라 자동으로 포착하십시오.

참고 문헌과 더 읽을거리

Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, “Feature Toggles (Feature Flags)” (essay).
ITIL (Information Technology Infrastructure Library), change management guidance.