Sorry Architecture

Continuous Delivery

Quill. 2019. 6. 6. 23:51

지속적 전달(Continuous Delivery)은 짧은 주기로 소프트웨어를 개발하고, 언제든지 안정적으로 배포할 수 있도록 하는 소프트웨어 공학(Software Engineering)이다. 모든 변경사항은 언제라도 운영가능한 상태(Production-ready)가 되도록 만드는 것이다.[각주:1]

작은 규모의 소프트웨어를 짧은 시간동안 개발해서 즉각적으로 사용자에게 전달하겠다는 도전은 도달하기 쉽지 않은 목표이지만, 이를 통해서 사용자(소비자, 고객)의 만족을 높일 수 있으므로 매우 중요하다. 그래서 지속적 전달이라는 용어가 정립되기 전에도 같은 목표(애자일 철학)을 이루기 위한 여러 시도가 있었다. 바로, 지속적 통합이다. 지속적 통합을 통해서도 사용자의 피드백을 지속적으로 반영하고 개선하는 노력을 하였고, 주로 개발에 중심을 두었다. 따라서, 인프라스트럭처(Infrastructure)를 비롯한 실제 사용자가 느끼는 부분에 관련된 운영 문제들은 여전히 병목지점이 되거나 기존의 방식을 따르는 경우가 많았다. 운영환경까지 신경쓰던 개발팀은 지속적 통합만으로도 충분히 소비자 만족을 줄 수 있었지만, 체계회된 방식이나 이론은 생기는 중이었다. 그리도 대부분의 경우, 개발은 애자일하게 잘 하더라도 실제 소비자의 손에 닿기에는 여전히 여러 장애물이 있었다.

 

지속적 전달은 이러한 문제를 해결하려던 여러 노력들을 정리한 개념이다. 간단하게 말하면, 지속적 통합을 소비자가 피부로 느끼는 운영환경에까지 확산한 것이 지속적 전달이라고 볼 수 있다. 따라서 지속적 전달을 위해서는 개발, 운영, 검증이 협력하여 유기적으로 움직여야 하며, 또한 각 단계들이 자동화, 규격화 됨으로써 탄탄하지만 민첩하게 기능해야 한다. 또한 이 모든 과정이 지속적이고 점진적이어야 한다. 따라서, 결과적으로 지속적 전달은 애자일과 데브옵스(DevOps)의 개념을 구체적으로 표현한 형태라고 볼 수 있다. 지속적 통합에서는 빠르고 안정적인 배포를 위해 다음의 내용들을 이야기하고 있다.
 
1/ 지속적 통합[각주:2]: 일단 지속적 통합을 먼저 잘 해야 한다. 지속적 전달은 지속적 통합에서부터 시작한다.

2/ 파이프라인(Pipeline)[각주:3]: 파이프라인이란 일련의 여러 작업절차가 순서에 맞추어 이어진 것을 표현하는 것이며, 지속적 전달에서 절차의 자동화를 표현할 때 사용하는 대표적인 단어다. 지속적 전달에서는 개발과 운영이 함께 서비스(Service Software)제공하는 절차들을 자동화여 파이프라인을 구성하도록 강조하고 있는데 그 이유는 자동화를 통한 생산성 향상을 얻기 위함이다. 여기서 말하는 제공이란 제품의 생산과 검수 그리고 유통과 판매에 이르는 모든과정을 포함한다. 일반적인 공산품을 생산하는 것과 크게 다르지 않다. 설계와 조립, 그리고 검수와 출하, 유통, 사후보증 등의 절차를 우리는 익히 알고 있다. 그리고 그 과정 전반을 회사에서 관리하며 우리는 그 회사로부터 물품을 구입한다.

 

마찬가지로 서비스도 우리가 소비하는 특정 소비재로 볼 수 있기 때문에 공장 자동화처럼 서비스개발 및 운영환경을 개선해 볼 수 있다. 이 것이 파이프라인이며 지속적 전달에서 제일 중요한 개념이다. 그러나 여기서 주의할 점이 한 가지 있다. 많은 부분이 자동화 되었기 때문에 사소한 변경이라도 즉각 소비자에게 영향을 미칠 수 있다. 그러므로 검수 단계를 꼼꼼하게 만들어서 사소한 결함이라도 소비자가 받는 제품에 들어가지 않도록 노력해야 한다. 검사(Test)를 통과하지 못하면 전체 파이프라인을 중지하고 소비자에게 해당 제품이 전달되지 못하도록 해야 하는 것이다.[각주:4] 동시에 개발자에게 결함이 있음을 알려주어야 한다. 그리고 시장에서 발견된 결함이 있다면 그 내용을 자동화된 검수(Automated Test)에 계속 누적시켜서 차후에는 테스트 케이스(Test Case)를 통해 자동으로 걸러지도록 해야 한다. 이렇게 검증을 꼼꼼하게 처리하는 것이 소비자에게 서비스의 신뢰를 줄 수 있는 가장 확실한 방법이며, 같은 맥락에서 지속적 통합이 매우 중요하다.[각주:5]

3/ 불변의 결과물(Immutable Package): 고객에게 전달할 제품을 함부로 건드리지 않도록 만드는 것과 같다. 우리가 제품을 구매했을 때, 만약 문제가 생겼다면 우리는 판매자가 새로운 동일 제품으로 교환해 주기를 바란다. 에어컨을 샀는데 사자마자 고장났다면 당연히 교환 또는 환불을 해 주는 것이 상식이다. 제조사가 에어컨을 뜯어서 원인을 분석해 보자고 한다면 너그러이 받아주는 소비자는 별로 없을 것이다. 서비스도 소비자 입장에서는 크게 다르지 않다. 서비스 제공 중인 서버(Server)에 문제가 생겼을 때, 그 안에 접속해서 원인을 분석하겠다고하는 것은 위의 사례와 비슷하다. 그래서 공산품(제품) 생산 및 유통 방식처럼 서버를 이미지(Machine Image)[각주:6] 단위로 관리하고, 문제가 생겼을 때 새로운 이미지를 만들어서 제공하는 것이 필요하다. 이렇게 하면 고객의 입장에서 지속적으로 서비스를 받을 수 있어서 좋다. 그리고 제조사 입장에서도 공장자동화에 적용한 방식을 서비스 개발 및 운용에 적용하여 비효율 요소를 제거할 수 있게 된다.

 

  1. 저자인 Jez Humble이 워크샵 초반에 한 장으로 표현한 핵심요약이다 [본문으로]
  2. Continuous Integration [본문으로]
  3. CI/CD Pipeline [본문으로]
  4. Jez의 워크샵 내용 중 80%는 테스트를 강조하는 것이었다. [본문으로]
  5. 지속적 전달을 하고 싶다면 먼저 지속적 통합부터 '제대로' 시작해야 한다. [본문으로]
  6. 또는, Container Image, Package, Artifact [본문으로]
저작자표시 비영리 변경금지