Close

지속적 배포 (Continuous Delivery)

지속적 제공(CD)이란 자동화를 이용해 소프트웨어를 짧은 기간 반복하여 릴리스하는 것을 의미합니다.

지속적 제공이란 무엇입니까?


지속적 제공은 팀이 소스 코드 리포지토리에서 프로덕션에 이르기까지 양질의 제품을 자주, 그리고 예측 가능한 방식으로 자동화하여 릴리스하는 방식입니다.

일부 조직에서는 아래 다이어그램과 같이 한 팀에서 다음 팀으로 제품을 전달하여 수동으로 릴리스합니다. 보통 개발자는 이 스펙트럼의 왼쪽 끝에 있고 운영 담당자는 제품을 받는 쪽에 있습니다. 그러면 제품을 전달할 때마다 지연이 발생하여 팀과 고객의 불만족으로 이어집니다. 제품은 지루하고 오류가 발생하기 쉬운 프로세스를 거치게 되고, 결국 수익 창출이 지연되게 됩니다.

그림 1: 고객에게 제품을 수동으로 릴리스
수동 릴리스 단계: 개발, QA, 도구, 인프라, 플랫폼, 릴리스, InfoSec

이제 아래의 지속적 제공 파이프라인을 확인해 보세요. 개발자가 노트북에서 코드를 작성하고 Bitbucket과 같은 소스 코드 리포지토리에 변경 사항을 커밋하는 방법이 나와 있습니다. 코드란 테스트 대상 시스템, 테스트, 그리고 시스템 배포 및 유지 관리에 사용되는 인프라를 의미합니다. Bitbucket Pipelines는 테스트 단계에서부터 스테이징, 프로덕션 단계에 이르기까지 제품을 제공하고, 고객이 새로운 기능을 사용할 수 있도록 지원합니다.

그림 2: 자동 릴리스를 통한 지속적 제공 파이프라인
지속적 제공 파이프라인 단계: 개발자, 노트북, Bitbucket, Bitbucket Pipelines, 고객

지속적 제공은 어떻게 작동합니까?


지속적 제공 파이프라인의 프로덕션 단계 직전에 수동 게이트가 있는 경우가 있습니다. 수동 게이트에는 사용자의 개입이 필요합니다. 그리고 조직에는 파이프라인에 수동 게이트가 필요한 시나리오가 있을 수 있습니다. 수동 게이트에는 의문스러운 것도 있고 합리적인 것도 있습니다. 합리적인 경우라면 비즈니스 팀이 최종 순간에 릴리스 결정을 내릴 수 있습니다. 엔지니어링 팀은 매 스프린트가 끝날 때마다 제품의 제공 가능한 버전을 준비해 두고, 비즈니스 팀은 모든 고객이나 전체 사용자, 아니면 특정 지역에 사는 사용자에게 제품을 릴리스하는 최종 결정을 내립니다.

파이프라인을 거치는 제품의 아키텍처는 지속적 제공 파이프라인의 구조를 결정하는 핵심 요소입니다. 고도로 결합된 제품 아키텍처는 복잡한 그래픽 파이프라인 패턴을 생성하여 프로덕션에 도달하기 전에 다양한 파이프라인이 뒤엉킬 수 있습니다.

제품 아키텍처는 파이프라인의 여러 단계와 각 단계에서 만들어지는 아티팩트에도 영향을 미칩니다. 파이프라인은 먼저 배포 가능하고 테스트 가능한 제품 중 가장 작은 단위인 컴포넌트를 빌드합니다. 예를 들어, 파이프라인으로 빌드한 라이브러리를 컴포넌트라고 부를 수 있습니다. 이러한 과정이 컴포넌트 단계입니다.

느슨하게 결합된 컴포넌트는 배포 가능하고 실행 가능한 가장 작은 단위인 하위 시스템을 구성합니다. 예를 들어, 서버는 하위 시스템입니다. 컨테이너에서 실행되는 마이크로서비스도 하위 시스템의 한 예입니다. 이러한 과정이 하위 시스템 단계입니다. 컴포넌트와는 다르게 하위 시스템은 만들어서 테스트할 수 있습니다.

따라서 전체 시스템을 전체적으로 릴리스해야 하는 경우에는 느슨하게 연결된 하위 시스템을 이용해 시스템을 어셈블하도록 파이프라인을 학습시킬 수 있습니다. 이러한 과정이 시스템 단계입니다.

하위 시스템을 하나의 시스템으로 어셈블하는 구성은 권장하지 않습니다. 그림 3에 나와 있는 그림을 살펴보세요.

그림 3: 하나의 시스템으로 어셈블된 하위 시스템
하위 시스템 다이어그램

모두 선택하지 않으면 모두 포기하는(all-or-none) 접근 방식은 가장 빠른 하위 시스템이 가장 느린 하위 시스템의 속도를 따르도록 만듭니다. “쇠사슬의 강도는 가장 약한 고리에 달려 있다”는 이러한 아키텍처 패턴에 사로잡혀 있는 팀에 경고할 때 사용하는 말이죠.

검증이 끝나면 어셈블된 시스템은 추가 수정 없이 마지막 단계인 프로덕션으로 승격됩니다.

프로덕션 단계는 물리적이기보다는 논리적인 단계이며, 큰 문제를 여러 개의 작은 하위 문제로 나누기 위해 만들어졌습니다. 아키텍처와 요구 사항에 따라 단계가 더 많거나 적을 수도 있습니다.

품질이 높지 않고 속도만 빠르다면 고객에게 쓸모가 없습니다. 지속적 테스트는 자동화된 테스트를 소프트웨어 제공 파이프라인에 통합하고 파이프라인에서 이루어지는 모든 변경 사항을 검증하는 기술입니다. 파이프라인의 각 단계에서 테스트가 실행되어 해당 단계에서 생성된 아티팩트를 검증합니다. 단위 테스트와 정적 코드 분석은 파이프라인의 컴포넌트 단계에서 컴포넌트를 검증합니다. 기능, 성능, 보안 테스트는 하위 시스템 단계에서 하위 시스템을 검증합니다. 통합, 성능, 보안 테스트는 시스템 단계에서 시스템을 검증합니다. 마지막으로 스모크 테스트는 프로덕션 단계에서 제품을 검증합니다.

코드 검토 일러스트레이션

자동화된 테스트는 파이프라인과 통합됩니다

진흑 덩어리(Big Ball of Mud) 패턴의 모놀리식 제품 아키텍처는 “테스트 덩어리(Big Ball of Tests)”로 전락할 수 있습니다. 인증을 위한 고도로 통합된 환경 없이도 독립적으로 배포 가능한 아티팩트가 파이프라인을 통과할 수 있도록 마이크로서비스에 투자하는 것이 좋습니다. 또한 독립적으로 배포할 수 있는 아티팩트를 사용하면 업무 속도가 더 빠른 팀이 느린 팀 때문에 지연되지 않습니다.

지속적 제공의 가치


소프트웨어 제공 파이프라인은 그 자체로도 하나의 제품이며, 비즈니스의 최우선 과제여야 합니다. 그렇지 않으면 수익을 창출하는 제품을 파이프라인에 통과시켜서는 안 됩니다. 지속적 제공은 세 가지 방식으로 가치를 더합니다. 바로, 소프트웨어 개발 팀의 속도, 생산성, 지속 가능성을 개선하는 것이죠.

로켓 일러스트레이션

속도

속도란 무분별한 속도가 아닌 책임감 있는 속도를 말합니다. 파이프라인은 고객에게 고품질 제품을 제공하기 위한 것입니다. 팀에 규칙이 없으면 파이프라인은 잘못된 코드를 프로덕션에 더 빠르게 보내는 결과만 유발할 수 있습니다! 자동화된 소프트웨어 제공 파이프라인은 조직이 시장 변화에 더 효과적으로 대응하도록 도와줍니다.

코드 파이프라인 일러스트레이션

생산성

프로덕션에 적용되는 모든 변경 사항에 대해 변경 요청을 제출하는 것과 같이 지루한 작업을 수동으로 하지 않고 파이프라인으로 수행할 수 있으면 생산성이 급상승합니다. 그러면 스크럼 팀이 물류에 에너지를 낭비하는 대신 세상을 놀라게 할 제품에 집중할 수 있게 됩니다. 그리고 팀원의 만족도와 업무 몰입도는 물론, 팀에 더 오래 머물고자 하는 의향이 높아질 수 있습니다.

의사 결정 일러스트레이션

지속 가능성

지속 가능성은 기술뿐만 아니라 모든 비즈니스의 핵심입니다. “소프트웨어가 세상을 먹어 치우고 있다”는 말은 더 이상 사실이 아닙니다. 소프트웨어는 이미 세상을 집어삼켰으니까요! 결국 의료, 금융, 소매, 기타 영역을 막론하고 모든 회사가 기술을 통해 다른 기업과의 차별화를 이루고 경쟁에서 앞서나가고 있습니다. 자동화는 오류가 발생하기 쉽고 반복적인 수작업을 줄이거나 없애는 데 도움을 줍니다. 그리고 기업이 고객의 요구 사항에 맞게 더 빠르고 효과적으로 혁신할 수 있도록 지원합니다.

지속적 제공은 누가, 언제 해야 합니까?


지속적 제공을 채택할 적기는 언제일까요? 바로 어제였습니다.
팀에는 우선 순위가 지정된 단일 백로그가 필요합니다.

  1. 지속적 제공이 백그라운드로 밀려나는 대신 받아들여졌습니다
  2. 사용자 스토리의 허용 기준에는 수동 방식 대신 자동화된 소프트웨어 제공 방식이 명시되어 있습니다
  3. 스프린트 완료 정의(Definition of Done, DoD)는 팀이 제품을 수동으로 제공하는 스프린트를 마칠 수 없게 만듭니다

지속적 제공은 옳은 방식이지만, 때로는 혁신에 불을 붙여야 할 때도 있습니다. 결국 올바르게 설계되면 지속적 제공 파이프라인은 제값을 해냅니다.

그렇다면 누가 참여합니까?

어떤 조직은 지속적 제공 파이프라인을 설계하고 구현한 경험이 없는 직원에게 일을 맡겨 여러 복잡한 요소가 존재한다는 사실을 힘들게 깨닫곤 합니다. 지속적 제공 작업에 하급 직원을 배정하면 지속적 제공의 우선 순위가 낮다는 잘못된 신호를 팀에 보내게 됩니다. 따라서 기술과 비즈니스에 대한 심층적인 이해를 갖춘 선임 아키텍트를 배정하는 것이 좋습니다.

지속적 제공을 넘어서


CE(Continuous Everything) 여정 중 어느 단계에 있든지(통합, 테스트, 제공, 배포, 분석 등) 핵심은 체크리스트나 목적지가 아니라 지속적인 개선입니다.

지속적 제공 파이프라인이 구축되면 언젠가는 경영진, 엔지니어링, 제품 관리, 거버넌스, 위험, 컴플라이언스, InfoSec, 운영, 법률 팀 등 조직의 모두가 알림을 받게 됩니다. 파이프라인은 사일로를 없애고 벽을 무너뜨립니다. 어떤 식으로든 우리 모두는 이 변화에 참여하고 있습니다. 그리고 모두가 지속적으로 하는 것이 뉴 노멀(new normal)입니다!

CI/CD 시작하기

CI/CD를 적용하려면 개발, 배포 및 테스트를 자동화하는 도구를 사용하면 됩니다. 특정 도구는 통합을 제공하고 다른 도구는 개발 및 배포를 제공하며 또다른 도구는 테스트를 제공합니다.

Atlassian은 CI/CD를 포함한 엔드투엔드 DevOps 프로세스를 제공하는 Open DevOps 솔루션을 제공합니다. 팀은 Bitbucket에 내장된 통합 CI/CD 서비스인 Bitbucket Pipelines를 비롯한 수많은 CI/CD 도구를 사용할 수 있습니다. 리포지토리의 구성 파일을 기반으로 코드를 자동으로 구축, 테스트 및 배포할 수 있습니다. Open DevOps는 Harness, GitLab, JFrog, Codefresh 및 CircleCI를 포함한 다른 CI/CD 도구와도 통합됩니다.

Open DevOps 통합에 대해 더 자세히 살펴보겠습니다. DevOps CI/CD 자습서를 확인해 보세요.

지속적 배포 일러스트레이션