Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자

CI/CD에서 한 단계 더 나아간 '지속적 배포 자동화' 준비하는 5가지 방법

Isaac Sacolick  | InfoWorld 2022.06.23
많은 기업이 소프트웨어 개발 워크플로우의 효율성을 높이기 위해 지속적 통합/지속적 제공(Continuous integration/Continuous Delivery, CI/CD) 파이프라인을 앞다퉈 구축했다. 그런데 여기서 더 나아가서 CI/CD 파이프라인을 사용해서 지속적으로 프로덕션에 변경 사항을 반영하는 지속적 배포(Continuous Deployment)를 자동화한 기업은 극소수다. 여기에는 그럴 만한 이유가 있다.
 
사실 매일 또는 매시간 프로덕션으로 코드를 프로덕션으로 푸시한다고 생각하면 오싹한 느낌이 든다. 실제로 몇 년 전에 지속적 배포의 단점에 대한 기사를 쓴 적도 있다. “책임감 있는 데브옵스 팀이 배포 빈도를 높여야 할 때”라는 기사에서는 배포 빈도가 높을수록 좋다는 전제가 과연 옳은 전제인지를 질문했다.
 
ⓒ Getty Images Bank

그러나 지난 몇 년 사이 많은 변화가 있었고, 이제 고품질의 안정적인 배포를 자동화하기 위한 기술과 방식, 툴을 채택하는 데브옵스 팀은 점점 늘어나고 있다. 지속적 제공과 지속적 배포 간의 차이점을 설명하고, 데브옵스 팀이 CI/CD 파이프라인의 지속적 배포를 자동화하기 전에 해야 할 5가지를 살펴본다.
 

지속적 제공 vs. 지속적 배포

캡제미니(Capgemini)의 애자일 및 데브옵스 리더인 쿨버 라이나는 지속적 제공과 지속적 배포의 차이점에 대해 “지속적 제공은 프로덕션에 이르기까지 소프트웨어 릴리즈의 종단 간 자동화 흐름이고, 지속적 배포는 지속적 통합 이후 이 흐름에서 사전에 테스트된 프로세스를 통해 프로덕션으로 소프트웨어 패키지를 푸시하는 자동화된 프로세스”라고 설명했다.
 
프로덕션 배포 자동화는 그 결과가 비즈니스, 고객, 최종 사용자에게 영향을 미치는 만큼 위험도 크다. 그래서 데브옵스 팀이 배포를 자동화하기로 결정하는 경우 배포 프로세스에는 지속적 테스트와 철저한 오류 처리가 포함되어야 한다. 그렇지 않으면 배포로 인해 프로덕션에서 성능 문제, 불안정한 시스템, 보안 틈새 및 결함이 발생할 수 있다.
 
SPR의 소프트웨어 엔지니어링 디렉터 마이크 사코텔리는 “지속적 제공 모델을 운영하는 조직과 지속적 배포 모델을 운영하는 조직의 가장 큰 차이점은 빌드 및 배포 프로세스의 성숙도와 정교함 수준”이라고 말했다.
 
데브옵스 팀은 다음 체크리스트를 사용해서 지속적 배포를 위한 CI/CD 파이프라인 업그레이드를 준비할 수 있다.
 

1. 비즈니스 이점 평가

지속적 배포는 많은 애플리케이션에 적용할 수 있으며 엄격한 규제를 받는 업계도 마찬가지다. 빌드카이트(Buildkite)의 공동 창업자, 공동 CEO인 팀 루카스는 “지속적 배포는 프로젝트 단위로 도입이 기능하며 조직은 최대한 이 모델로 많은 프로젝트를 옮긴다는 목표를 수립한다. 금융 업계와 규제 대상 업계에서도 대부분의 프로젝트에서 지속적 배포 모델을 도입할 수 있다. 자율주행차 기업에서도 지속적 배포를 사용한다”라고 말했다.
 
데브옵스 팀은 많은 프로젝트에서 지속적 배포를 구현할 수 있는데, 관건은 어느 부분에서 확고한 비즈니스 케이스와 중대한 기술적 이점을 제공하느냐다. 기능과 수정을 빈번하게 배포하는 프로젝트, 현대화된 아키텍처로 자동화가 간소화되는 프로젝트가 지속적 배포로 전환하기에 가장 적합하다.
 

2. 개발 팀 준비

루카스는 지속적 배포 모델로 전환하기 전에 소프트웨어 개발 프로세스에 포함해야 하는 전제 조건에 대해 “지속적 배포는 진정한 민첩성이며 코드 변경에서 프로덕션에 이르는 가장 빠른 길이다. 이를 위해서는 주 분기를 항상 전달 가능한 상태로 유지하고 테스트를 자동화하며, 신뢰할 수 있는 고품질의 툴을 확보해야 한다”라고 말했다.
 
지속적 배포를 자동화하려는 개발자가 확인해야 하는 개발 관련 사항은 다음과 같다.
 
  • 변경이 새로운 결함을 유발하지 않는지 확인하는 코드 커버리지가 충분한 지속적 테스트
  • 보안, 성능 및 기타 코드 품질 문제를 테스트하는 정적/동적 코드 분석 툴
  • API 보안을 위한 모범 사례를 포함한 시프트-레프트(shift-left) 보안 실천
  • 애플리케이션과 마이크로서비스에 대한 관찰 가능성 표준
  • 사용자 일부에 대해 새로운 기능을 켜고 끄거나 제어하기 위한 기능 플래깅
 
사코텔리는 “지속적 배포는 고품질 코드에 대한 이해도가 성숙한 개발 팀을 기반으로 실행되어야 성공할 수 있다. 코드가 품질이 낮거나 테스트되지 않을 경우 불안정한 시스템으로 이어지고 버그와 취약점이 프로덕션으로 빠르게 유입된다”라고 덧붙였다.
 

3. 운영 팀 준비

CI/CD 파이프라인이 실행되어 새 코드를 프로덕션으로 배포한다. 그렇다면 데브옵스 팀은 할 일을 다 했고 모두 다음 릴리즈로 넘어갈 수 있다는 것을 의미할까?
 
아직은 아니다. 빌드가 깨지지 않도록 하고 코드 테스트를 자동화하고 프로덕션에서 활성화되는 코드를 제어하기 위해 많은 노력을 기울이지만, 배포로 인해 프로덕션 문제가 발생할 위험은 여전히 존재한다. 비즈니스 서비스, 애플리케이션, 시스템 모니터링은 데브옵스 내에서 운영 영역의 책임이며, 지속적 배포를 지원하기 위한 이들의 역량은 배포 자동화를 실현하기 훨씬 전부터 시작된다. 권장 사함은 다음과 같다.
 
  • 코드형 인프라와 컨테이너를 사용해서 배포, 테스트, 프로덕션 및 기타 환경 간에 일관적인 인프라 구성을 보장한다.
  • 애플리케이션과 마이크로서비스에서 생성되는 관찰 가능성 데이터를 로드해 분석할 수 있는 애플리케이션 및 시스템 수준 모니터링 툴을 채택한다.
  • 애플리케이션에서 마이크로서비스, 데이터스토어에 이르기까지 전체 스택에 걸쳐 모니터링, 알림, 관찰 가능성 데이터를 통합하고 여러 이벤트를 관리 가능한 인시던트로 연계하는 AI옵스 플랫폼을 선택한다.
  • 카나리 릴리즈를 설정해서 새 배포로의 트래픽과 컷오버를 제어하고 컷오버 전략이 더 어려워질 위험을 낮춘다.
  • 매우 동적인 애플리케이션 환경의 위험을 낮추는 API 게이트웨이, 웹 애플리케이션 방화벽, 컨테이너 보안, 위협 모니터링, 민감한 데이터 모니터링을 포함한 일련의 보안 툴을 갖춘다.
 

4. 여러 팀과 툴에서 ITSM과 워크플로우 통합하기

 
이렇게 다양한 배포 및 운영 역량을 갖추더라도 아직 끝난 것이 아니다. 예를 들어 데브옵스 팀이 코드를 커밋하고 지속적 배포가 변경 사항을 프로덕션으로 전달하고 애플리케이션 성능 모니터링 툴이 실행 중이라고 가정하자. 문제가 발생할 경우 데브옵스 팀이 사고를 분류하고 근본 원인을 조사하고 신속하게 문제를 해결할 수 있도록 사고 알림이 얼마나 빠르게 적절한 팀원에게 전달될까?
 
루카스는 지속적 배포로 전환할 때의 첫 번째 위험이 “부실한 테스트”라고 말했다. 루카스는 그 외의 위험으로 안정적이지 않은 CI/CD 툴, 잘못된 프로덕션 모니터링 및 비상 사태 대기 관행, 그리고 엔지니어링과 IT 사이 진정한 파트너십의 부재를 꼽았다.
 
모니터링, AI옵스, IT 서비스 관리(ITSM), 애자일, 커뮤니케이션 툴 간의 워크플로우와 통합이 없으면 데브옵스 팀이 문제에 대응하고 해결하는 속도가 배포 속도보다 뒤처질 수 있다. 이 간극이 알력을 일으키고, 개발과 운영 사이의 파트너십을 악화시킨다. 최선은 데브옵스 팀이 지속적 배포에서 발생하는 모든 문제를 상시 파악할 수 있도록 IT 툴과 워크플로우를 통합하는 것이다.
 

5. 위험 기반 의사 결정 게이트 및 KPI 정의

코파도(Copado)의 제품 마케팅 담당 디렉터 크리스틴 바스켓은 지속적 배포에 필요한 필수 요소에 대해 “무모한 자동화는 시스템에 악영향을 미칠 수 있지만 적절한 자동화는 조직이 데브옵스의 진정한 이점을 얻을 때 필요한 유연성과 일관성을 달성하는 데 도움이 된다. 개발자가 자동으로 코드를 통합할 수 있게 되면 협업이 개선된다. 또한 테스트 자동화와 품질 게이트에 투자하는 조직은 위험을 낮추면서 더 빠르게 혁신할 수 있다”라고 말했다.
 
바스켓은 테스트 자동화 외에 다른 위험 평가로 범위가 확장되는 품질 게이트를 구현해야 한다고 말했다. 빌드가 지속적 배포를 트리거하면 품질 게이트는 어느 배포가 프로덕션으로 갈 수 있고 어느 배포에 규정 준수 검토나 경영진 서명이 필요한지를 결정하는 비즈니스 규칙을 적용한다.
 
지속적 배포를 지원하는 그 외의 권장 사항에는 데브옵스 핵심 성과 지표(KPI) 개발, 피드백 루프 공식화, 커뮤니케이션 전략 개발 등이 포함된다.
 
지속적 배포는 많은 비즈니스 및 기술적 혜택을 제공한다. 하지만 자동화를 사용해 배포 빈도를 높이기 전에 앞서 강조한 권장 사항과 툴을 갖출 것을 조언한다.
editor@itworld.co.kr 
 Tags CI/CD 지속적배포 지속적제공 지속적통합 위험기반의사결정 데브옵스 ITSM 워크플로우 코드테스트 자동화
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.