클라우드 기반 CI/CD 플랫폼을 선택하는 방법

빠른 소프트웨어 개발과 잦은 프로덕션 빌드 배포가 목표라면 테스트 및 제공 프로세스의 적어도 일부라도 자동화해야 한다. 이상적으로 이는 프로젝트를 위한 CI/CD 파이프라인, 고객이 소프트웨어를 접하기 전에 오류를 포착하기 위한 테스트 모음, 그리고 파이프라인의 각 단계를 구현하는 스크립트를 구현한다는 것을 의미한다.

ⓒ Getty Images Bank

지속적 통합(CI)은 소프트웨어 빌드와 패키징, 테스트를 일관된 방식으로 자동화하기 위한 방법론이다. CI는 개발팀이 소스 코드 버전 제어에 체크인하는 변경 사항이 빌드의 작동을 중단시키거나 소프트웨어에 버그를 유입시키지 않는다는 어느 정도의 확신을 얻는 데 도움이 된다. CI의 종점은 일반적으로 소프트웨어 리포지토리의 주 분기에 대한 체크인이다.

지속적 제공(CD)은 테스트된 소프트웨어를 인프라 환경에 전달하는 과정을 자동화한다. 물론 프로덕션에 바로 던져 넣어 고객이 불평하는지 여부를 살피는 것을 의미하지는 않는다. 일반적으로 조직은 먼저 개발 환경으로 빌드를 푸시한다. 개발자 스스로 새 빌드를 살펴보고 릴리스하면 다음은 보통 테스트 환경으로 넘어간다. 테스트 환경에서는 더 폭넓은 사용자 그룹에 의해 사용되고(전담 내부 테스터들로 구성될 수도 있고, 베타 테스트나 내부 시험(dog-fooding)에 등록한 사용자 그룹인 경우도 있음) 면밀하게 모니터링된다. 아무 문제가 없으면 마지막으로 테스터들이 새 버전을 승인하고 프로덕션 환경으로 보낸다.

CD의 각 단계에는 이전 빌드로 신속하게 되돌리고 개발자가 새 빌드에서 해결해야 할 버그 보고서 티켓을 생성하는 옵션이 있다. 목표는 프로덕션으로 많은 수의 빌드를 푸시하는 것이 아니라 퇴행 없이 지속적으로 소프트웨어를 개선 및 향상하는 것이다. 이 방식을 지칭하는 또 다른 용어가 “데브옵스”다.

클라우드에 CI/CD를 호스팅하는 이유

자체 데이터센터에 CI/CD 플랫폼을 호스팅하는 방법은 특히 방화벽 안에 애플리케이션과 데이터를 호스팅할 것을 의무화하는 기업에서 사용 가능한 옵션이다. 이 경우의 단점은 인프라를 유지보수할 전담팀이 필요하며 서버에 대한 어느 정도의 설비 투자가 발생한다는 점이다.

클라우드에 호스팅할 수 있다면 일반적으로는 그 방법이 더 낫다. 클라우드에 호스팅하는 비용은 크지 않고, 운영비는 제공되는 서비스(온보딩, 인프라 유지보수, 보안 유지보수, 지원, CI/CD 소프트웨어 유지보수)로 상쇄된다. CI/CD 소프트웨어를 클라우드에 호스팅하고 소스 코드 리포지토리도 클라우드에 호스팅된다면, 파이프라인에서 소스 코드 리포지토리와의 상호작용이 더 쉽고 빨라진다. 개발자 및 테스터가 지리적으로 분산되어 있는 경우, 리포지토리를 클라우드에 호스팅하면 방화벽 뒤의 원격 서버에 호스팅하는 경우에 비해 개발자에게 더 원활한 환경을 제공할 수 있다.

CI/CD를 온프레미스와 클라우드 서버의 하이브리드에 배포하는 것도 가능하다. 여러 최신 CI/CD가 쿠버네티스 클러스터의 컨테이너에서 실행되며, 온프레미스와 클라우드에서도 마찬가지로 원활하게 실행된다. 하이브리드 배포 시나리오에서는 개발자 자신의 물리적인 위치와 개발 인프라에 있는 다른 서버의 네트워크 위치 등 각 구성요소를 가장 적합한 곳에 배치할 수 있다.

CI/CD와 리포지토리의 통합

앞서 “CI의 종점은 일반적으로 소프트웨어 리포지토리의 주 분기에 대한 완성된 체크인”이라고 강조했듯이, 리포지토리는 CI와 CD에 필수적이다. 소프트웨어 리포지토리는 체크인과 테스트 프로세스의 종점이기도 하지만 CI 및 CD 스크립트와 구성 파일을 저장하는 용도로도 많이 사용된다. 물론 많은 CI/CD 플랫폼이 스크립트 및 기타 파일을 내부적으로 저장할 수 있지만 일반적으로는 툴 외부의 버전 제어에 두는 편이 더 낫다.

거의 모든 CI/CD 툴이 깃(Git)과 상호적용이 가능하다. 일부는 깃허브(GitHub), 깃허브 엔터프라이즈, 깃랩(GitLab) 또는 비트버킷(Bitbucket)과 직접 통합된다. 서브버전(Subversion) 및 머큐리얼(Mercurial)를 지원하는 툴도 소수 있다.

CI/CD 툴이 현재의 프로그래밍 언어와 툴을 지원해야 함

각 프로그래밍 언어 또는 언어 그룹(JVM 언어, LLVM 컴파일 언어, 닷넷 언어 등)에는 보통 자체 빌드 툴과 테스트 툴이 있다. CI/CD 툴이 유용성을 가지려면 해당 프로젝트에 속하는 모든 언어를 지원해야 한다. 그렇지 않은 경우 툴을 위해 하나 또는 그 이상의 플러그인을 만들어야 할 수 있다.

도커 이미지는 분산 모듈형 및 마이크로서비스 소프트웨어 배포에서 점점 더 중요해지고 있다. 소스 코드, 바이너리, 전제 조건으로부터 이미지를 생성하고 특정 환경에 이미지를 배포하는 등 도커 이미지를 어떻게 처리해야 하는지를 CI/CD 툴이 알면 도움이 된다. 마찬가지로 이 기능이 없으면 플러그인 또는 스크립트를 직접 작성해서 필요한 도커 기능을 구현해야 할 수 있다. CI/CD 툴이 쿠버네티스와 현재 환경에서 사용 중인 기타 컨테이너 오케스트레이션 시스템을 지원하는 편이 좋다.

현재 고려 중인 CI/CD와 툴을 개발자가 이해하는가?

CI 및 CD의 원칙은 명확하지만 세부 사항은 그렇지 않다. CI/CD 툴은 다양하고, 저마다 지원과 문서화 수준도 다르다. 젠킨스(Jenkins)에 관해서는 여러 권의 책이 있는데, 젠킨스가 가장 오래된 툴임을 감안하면 당연한 일이다. 다른 제품의 경우 선택 과정에서 문서와 지원 포럼, 유료 지원 옵션을 잘 살펴봐야 한다.

프로젝트마다 다른 CI/CD 툴 선택 가능

이 가이드의 주제는 CI/CD 플랫폼 선택이지만, 한 가지 플랫폼이 모든 소프트웨어 개발 프로젝트에 최적일 것이라고 기대해서는 안 된다. 대부분 기업은 여러 프로그래밍 언어와 환경을 사용하는데, 모든 CI/CD 플랫폼이 사용 중인 모든 언어와 환경을 지원하지는 않는다.
하나의 플랫폼으로 타협하기보다는 각 프로젝트를 위한 최선의 CI/CD 플랫폼을 찾는 것을 주저하지 말아야 한다. 각 플랫폼을 위해 작성하는 스크립트는 이식이 안 될 수도 있지만, CI와 CD의 전반적인 원칙은 여러 플랫폼에서 공통적으로 적용된다. 새로운 각 플랫폼에 수반되는 부가적인 온보딩 시간으로 인해 데브옵스 팀의 시간이 일부 소비될 수 있지만, 대부분의 경우 CI/CD 툴을 구석구석 맞춤 설정하는 데 필요한 비용보다는 낮다.

미래의 CI/CD 마이그레이션을 위한 계획

같은 맥락에서, 특정 CI/CD 플랫폼이 프로젝트의 요구사항을 영구적으로 충족할 것이라고 전제해서는 안 된다. 위험을 분산시켜야 할 필요가 있다. 예를 들어 스크립트를 CI/CD 툴이 아닌 리포지토리에 저장해야 한다.

적절한 경우 서버리스 CI/CD를 우선 고려

일반적으로 배포 비용을 보면 클라우드 서버 인스턴스 배포에 비해 클라우드 컨테이너 배포가 더 저렴하고, 컨테이너 배포에 비해 서버리스 클라우드 배포가 더 저렴하다. 아쉬운 부분은 이 기사를 작성하는 현재 서버리스 실행이 가능한 CI/CD 플랫폼이 극소수라는 점이다.

서버리스는 프로세스를 실행하는 컨테이너가 필요에 따라, 일반적으로 이벤트에 반응하여 인스턴스화된다는 것을 의미한다. CI/CD의 경우 트리거 이벤트는 보통 특정 리포지토리 분기에 대한 코드 체크인이다. 이후 리포지토리 웹훅이 서버리스 프로세스를 시작한다. 프로세스가 완료되면 리소스가 회수된다.

서버리스 실행이 가능한 소수의 CI/CD 플랫폼 중 하나는 오픈소스 서버리스 프레임워크(Serverless Framework)의 강화된 버전인 서버리스 프레임워크 프로(Serverless Framework Pro)에 속한 서버리스 CI/CD(Serverless CI/CD)다. 서버리스 CI/CD는 서버리스 앱 배포에 최적화됐으며, 현재는 AWS에서만 실행된다. 이 플랫폼을 사용하려면 해당 애플리케이션을 충분히 지원하는지 여부를 확인해야 한다.

현재 클라우드 자산은 어디에 있는가?

클라우드 기반 CI/CD 구성(또는 모든 클라우드 애플리케이션도 마찬가지)을 최적화하려는 경우, 모든 자산이 서로 “인접”한 것이 유리하다. 여기서 “인접”이란 지리적 위치와 네트워크 위치를 모두 나타낸다.

예를 들어 데이터베이스가 호주에 있고 애플리케이션이 북미에 있다면, 애플리케이션이 데이터를 읽고 쓸 때마다 긴 지연이 발생하게 된다. 애플리케이션과 데이터베이스가 같은 가용성 영역(AZ) 내에 있다면 둘 사이의 지연은 최소화된다. 같은 지역의 다른 영역에 있는 경우 지연은 높아지지만 지역 자체가 다른 경우만큼 크지는 않다.

마찬가지로, 데이터베이스가 미국 버지니아주의 구글 클라우드 플랫폼에 위치하고 애플리케이션이 같은 지역의 마이크로소프트 애저에 있는 경우, 두 가지가 같은 AZ의 같은 클라우드 서비스 업체에 있는 경우에 비해 지연이 크다. 이런 특성은 리포지토리(기본적으로 데이터베이스), CI/CD 소프트웨어, 실제 애플리케이션, 그리고 개발자 및 테스터에게도 똑같이 적용된다. 모두가 “인접”해 있으면 좋다. 다만 이 환경에서 지연이 미치는 영향은 예를 들어 실시간 인터랙티브 게임만큼 크지는 않다.

개발자는 안정적으로, 인지할 정도의 대기 시간 없이 코드 커밋을 마스터 리포지토리에 푸시할 수 있다면 대체로 만족한다. 마찬가지로 사용자와 테스터 역시 애플리케이션에 충분히 “인접”해 있어서 응답 시간이 1초 미만이라면 만족할 것이다. CI/CD 소프트웨어의 경우 핵심은 배포 지점에 대한 안정적인 연결이다. 시간 초과 또는 패킷 누락을 일으키지만 않는다면 약간의 지연은 용인할 수 있다.

커밋 전에 개념 증명 실시

CI/CD는 완전히 구현된 이후에는 인프라의 핵심적인 부분이 된다. 이 점을 염두에 두고 일을 진행해야 한다.

CI/CD 파이프라인을 구축하기 전에 철저한 개념 증명을 수행하는 것이 중요하다. CD 단계를 시작하기 전에 CI 부분을 운용하면서 철저히 살펴야 한다. CI/CD 파이프라인을 프로덕션 인스턴스에 연결하기 전에 테스트 모음과 롤백 기능을 확인하고, 자동화가 충분히 견고하다는 확신이 들 때까지 인력의 개입을 중단해서는 안된다. editor@itworld.co.kr

Martin Heller editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지