지속적 통합/지속적 전달(CI/CD)이란 무엇인가요?

CI/CD 파이프라인의 핵심 특징은 코드 품질을 보장하는 데 도움이 되는 자동화를 활용한다는 점입니다. 소프트웨어 변경 사항이 파이프라인을 거치는 동안 자동화된 테스트가 종속성과 기타 문제를 조기에 식별하고, 코드 변경 사항을 여러 환경으로 전달하며, 애플리케이션을 프로덕션 환경에 배포합니다.

여기서 자동화는 품질 관리를 수행하며, 성능부터 애플리케이션 프로그래밍 인터페이스(API) 사용 현황과 보안에 이르기까지 전반을 평가합니다. 이 과정을 통해 모든 팀원이 수행한 변경 사항이 의도한 대로 완전하게 통합되고 적용되도록 지원합니다.

CI/CD 파이프라인의 여러 단계를 자동화할 수 있기 때문에 개발 팀은 품질을 높이고, 더 빠르게 작업하며, DevOps의 다양한 성과 지표를 개선할 수 있습니다.

CI/CD 파이프라인은 애자일 DevOps 워크플로를 의미하며, CI/CD는 지속적 통합과 지속적 전달을 함께 수행하는 개발 방식을 뜻합니다.

CI/CD는 여러 사람이 수행한 작업을 하나의 일관된 제품으로 더 빠르고 정확하게 통합할 수 있는 방법을 제공합니다. DevOps 환경에서 CI/CD는 애플리케이션의 코딩, 테스트 및 배포 프로세스를 간소화합니다. 이 접근 방식은 팀에 작업을 저장할 단일 리포지토리와 코드를 통합하고 테스트하여 일관되게 작동하도록 지원하는 자동화 툴을 제공합니다.

CI/CD 파이프라인을 사용하면 DevOps 팀은 코드를 작성하고, 통합하고, 테스트를 실행하며, 릴리스를 제공하고, 소프트웨어 변경 사항을 실시간으로 협업하여 배포할 수 있습니다. 초기 테스트부터 최종 배포까지 소프트웨어 릴리스 과정을 자동화할 수 있다는 점은 CI/CD 파이프라인의 대표적인 장점이며, 이 밖에도 다음과 같은 이점이 있습니다.

• 배포 시간 단축: 자동화된 테스트는 개발 프로세스의 효율성을 높여 소프트웨어 제공에 걸리는 시간을 단축합니다. 또한 지속적 배포와 자동화된 프로비저닝을 통해 개발자가 클라우드 애플리케이션에 적용한 변경 사항을 작성 후 몇 분 안에 운영 환경에 반영할 수 있습니다.

• 비용 절감: 자동화를 통해 개발, 테스트 및 운영 환경 배포가 빨라지므로 개발에 소요되는 시간이 줄어듭니다. 그 결과 기존의 소프트웨어 개발 방식보다 비용을 절감할 수 있습니다.

• 지속적인 피드백 루프: CI/CD 파이프라인은 빌드, 테스트, 배포가 반복되는 지속적인 사이클로 이루어집니다. 피드백 루프를 통해 개발자는 테스트가 완료될 때마다 신속하게 대응하여 코드를 지속적으로 개선할 수 있습니다.

• 조기 오류 탐지: 지속적 통합에서는 빌드되는 모든 코드 버전에 대해 테스트를 자동으로 수행하여 통합 과정에서 발생하는 문제를 조기에 찾아냅니다. 이러한 문제는 파이프라인에서 더 이른 단계에 발견될수록 더 쉽게 해결할 수 있습니다.

• 가동 중단 시간 감소 및 안정성 향상: 배포 실패, 버그 또는 성능 문제가 발생하면 자동 롤백과 같은 기능을 통해 소프트웨어 시스템이나 애플리케이션을 이전의 안정적인 상태로 되돌릴 수 있습니다. 이를 통해 가동 중단 시간을 최소화하고 서비스 안정성을 높일 수 있습니다.

• 팀 협업 및 시스템 통합 향상: 팀원 모두가 코드를 수정하고, 피드백을 반영하며, 발생하는 문제에 신속하게 대응할 수 있습니다.

CI/CD 파이프라인은 서로 연결된 다음 세 가지 방법론으로 구성됩니다.

• 지속적 통합
• 지속적 전달
• 지속적 배포

CI/CD 프로세스는 지속적 통합(CI)부터 시작됩니다. 이 단계에서는 개발자가 버전 관리 시스템(VCS)에서 관리하는 중앙 리포지토리에 코드를 커밋합니다. CI를 사용하면 개발자는 독립적으로 작업하면서 자신만의 코드 '브랜치'를 만들어 작은 변경 사항을 구현할 수 있습니다.

개발자는 작업하는 동안 일반적으로 Git과 같은 버전 관리 툴을 사용해 소스 코드의 스냅샷을 저장할 수 있습니다. 이후 개발자는 새로운 기능 개발을 계속 진행할 수 있으며, 문제가 발생하면 Git을 사용해 코드베이스를 이전 상태로 신속하게 되돌릴 수 있습니다.

그런 다음 각 개발자의 작업은 스크립트를 사용해 코드 변경 사항을 빌드하고 테스트하는 자동화 시스템으로 전달됩니다. 자동화된 빌드 단계가 끝나면 CI 서버는 소스 코드 변경 사항을 공유 소스 코드 리포지토리의 메인 브랜치, 즉 '트렁크'에 병합합니다.

CI/CD 개발 프로세스를 사용하면 개발자가 각자 코드를 작성한 뒤 한 달에 한 번씩 메인 브랜치에 병합하는 방식 대신 코드 변경 사항을 더 자주 제출할 수 있습니다. 이를 통해 버그 수정에 많은 시간이 소요되거나 버전 관리가 제대로 이루어지지 않는 문제를 줄일 수 있습니다. 이러한 지속적 테스트를 통해 버그를 더 빠르게 수정하고 기능이 정상적으로 작동하는지 확인할 수 있으며, 궁극적으로 협업과 소프트웨어 품질을 모두 향상할 수 있습니다.

파이프라인의 다음 단계는 지속적 전달(CD)입니다. 이 단계에서는 지속적 통합 과정에서 검증된 코드 변경 사항을 GitHub와 같은 특정 환경이나 코드 리포지토리에 배포합니다. 운영 팀은 여기에서 해당 변경 사항을 운영 중인 프로덕션 환경에 배포할 수 있습니다.

소프트웨어와 API를 테스트하고 오류를 자동화된 프로세스를 통해 해결합니다. CD 프로세스의 마지막 단계에서는 DevOps 팀이 최신 빌드에 대한 알림을 받은 후 이를 수동으로 배포 단계에 전달합니다.

지속적 전달 단계의 목표는 최소한의 노력으로 새로운 코드를 배포하면서도 필요한 수준의 사람의 검토와 통제를 유지하는 것입니다.

CI/CD에서 CD는 지속적 배포를 의미하기도 합니다. 지속적 배포는 코드 무결성을 확인하기 위해 실제 환경을 모사한 환경에서 수행하는 통합 테스트 등 사전에 정의된 일련의 테스트를 통과하면 코드 변경 사항을 최종 사용자에게 자동으로 릴리스합니다.

지속적 전달과 지속적 배포는 모두 CI보다 이후 단계의 파이프라인을 자동화하는 방식이며, 두 용어는 혼용되는 경우가 많습니다.

지속적 전달과 지속적 배포의 차이는 소프트웨어 또는 앱 릴리스에 사용되는 자동화 수준에 있습니다. 지속적 전달에서는 코드가 자동으로 프로덕션과 유사한 환경으로 이동해 추가 테스트 및 품질 보증(위험 평가, 소스 코드 취약점 식별 등)을 받습니다. 성공적인 테스트 이후에는 프로덕션으로 이동하기 위해 인간의 개입이 필요합니다.

지속적 배포에서는 자동화 범위가 더욱 넓어집니다. 코드가 테스트를 통과하면 사람의 승인 없이 프로덕션 환경으로 자동 배포됩니다.

조직이 CI/CD 파이프라인을 어떻게 적용하고 지속적 전달과 지속적 배포 중 어떤 방식을 선택할지는 비즈니스 요구 사항에 따라 달라집니다. 지속적 배포는 전자상거래 사이트나 서비스형 소프트웨어(SaaS) 플랫폼을 개발하는 것처럼 개발 주기가 빠른 DevOps 팀에 가장 적합합니다.

지속적 배포를 사용하면 팀이 신규 또는 업데이트된 소프트웨어를 가능한 한 자주, 그리고 신속하게 릴리스할 수 있으므로 소프트웨어 릴리스 프로세스를 효율적으로 지원합니다. 변경 사항이 공개 환경에 자동으로 배포되므로 이러한 유형의 지속적 배포 파이프라인은 일반적으로 검증된 개발 프로세스를 갖춘 DevOps 팀에서만 사용됩니다.

의료 애플리케이션을 개발하는 팀처럼 워크플로에서 업데이트를 자주 릴리스할 필요가 없는 경우에는 일반적으로 지속적 전달이 더 적합한 선택입니다. 지속적 전달은 속도는 다소 느리지만 최종 사용자에게 기능이 정상적으로 제공되도록 추가적인 검토 단계를 제공합니다.

지속적 전달과 지속적 배포의 차이를 자세히 알아보려면 다음 영상을 확인해 보세요.

머신 러닝 파이프라인은 머신 러닝 모델의 구축, 학습, 평가 및 배포 과정을 자동화하고, 표준화하며, 간소화하도록 설계된 일련의 상호 연결된 데이터 처리 및 모델링 단계입니다.

머신 러닝 파이프라인은 머신 러닝(ML) 시스템의 개발과 운영에 필수적인 구성 요소입니다. 또한 빅데이터와 인공 지능(AI)의 성장에 따라 그 중요성이 더욱 커지고 있습니다.

Kings Research에 따르면 전 세계 머신 러닝 시장 규모는 2023년 260억 6천만 달러로 평가되었으며, 2024년 354억 4천만 달러에서 2031년 3,288억 9천만 달러로 성장해 예측 기간 동안 연평균 성장률(CAGR) 37.47%를 기록할 것으로 전망됩니다.¹

머신 러닝 파이프라인은 DevOps 방식과 통합되어 머신 러닝 모델에 대한 CI/CD를 구현합니다. 이러한 통합을 머신 러닝 운영(MLOps)이라고 하며, 데이터 사이언스 팀이 ML 오케스트레이션 관리의 복잡성을 효과적으로 관리할 수 있도록 지원합니다.

소스 코드 작성부터 프로덕션 배포까지, 다음 단계는 CI/CD 파이프라인의 개발 수명 주기와 워크플로를 구성합니다.

• 구축
• 테스트
• 제공
• 배포

이 단계는 지속적 통합 프로세스의 일부로, 코드를 작성하고 컴파일하는 작업을 포함합니다. 팀은 소스 코드를 기반으로 협업하여 개발을 진행하고 새로운 코드를 통합하면서 발생하는 문제나 충돌을 신속하게 식별합니다.

이 단계에서는 팀이 코드를 테스트합니다. 자동화된 테스트는 지속적 전달과 지속적 배포 모두에서 수행됩니다. 이러한 테스트 환경에는 통합 테스트, 단위 테스트 및 회귀 테스트가 포함될 수 있습니다.

이 단계에서는 승인된 코드베이스가 프로덕션 환경으로 전달됩니다. 이 단계는 지속적 배포에서는 자동으로 수행되며, 지속적 전달에서는 개발자의 승인을 받은 후에만 자동으로 수행됩니다.

마지막으로 변경 사항을 배포하고 최종 제품을 프로덕션 환경에 적용합니다. 지속적 전달에서는 제품이나 코드가 리포지토리로 전달된 후 사람의 승인을 거쳐 프로덕션 환경에 배포됩니다. 지속적 배포에서는 이 단계가 자동으로 수행됩니다.

CI/CD 툴을 선택할 때는 소프트웨어 개발 프로세스를 최적화하고 자동화하는 데 중점을 두어야 합니다. 효율적인 CI/CD 파이프라인은 통합, 테스트 및 배포를 위해 오픈 소스 툴을 활용합니다. CI/CD 프로세스를 올바르게 구성하는 것 역시 소프트웨어 개발 파이프라인의 성공에 영향을 미칩니다.

가장 널리 사용되는 오픈 소스 CI/CD 툴은 Jenkins입니다. Jenkins는 Java로 개발된 자동화된 CI 서버로, CI/CD 단계와 보고를 자동화하는 데 사용됩니다. 그 밖의 오픈 소스 통합 툴로는 Travis CI와 CircleCI가 있습니다.

오픈 소스 툴뿐만 아니라 Google Cloud, IBM® Cloud, Microsoft Azure, Amazon Web Services(AWS)와 같은 주요 클라우드 서비스 제공업체도 클라우드 기반 CI/CD 툴체인, 파이프라인 및 툴 통합 기능을 제공합니다.

GitHub나 AWS CodeCommit과 같은 통합 개발 환경(IDE)은 개발자가 소프트웨어 패키지를 생성하고, 유지 관리하며, 추적할 수 있도록 지원합니다. 한편 GitLab과 같은 플랫폼은 다양한 툴을 포함한 통합 플랫폼 안에서 IDE를 함께 제공하는 것을 목표로 합니다.

클라우드 환경에서 작업하는 클라우드 네이티브 DevOps 팀은 애플리케이션을 패키징하고 배포하기 위해 Docker와 같은 컨테이너를 사용하며, Kubernetes와 같은 컨테이너 오케스트레이션 툴을 활용합니다. Kubernetes는 CI/CD 파이프라인만을 위한 툴은 아니지만, 많은 CI/CD 워크플로에서 활용됩니다.

CI/CD 보안은 CI/CD 파이프라인 전반에서 보안 및 규정 준수 조치를 구현하고 관리하는 데 필요한 방식, 프로세스 및 기술에 중점을 둡니다.

과거에는 개발 주기가 끝난 후 소프트웨어에 보안을 덧붙이는 방식이 일반적이었습니다. 클라우드 플랫폼, 마이크로서비스 및 컨테이너 기술의 발전은 기존 개발 방식의 병목 요인이 되었습니다.

개발자들이 애자일과 DevOps 방식을 도입하면서 릴리스 속도가 빨라졌고, 이에 보안이 이를 따라가지 못하는 경우가 발생했습니다. 이러한 배경에서 개발, 보안, 운영을 통합한 DevSecOps가 등장했습니다. DevSecOps는 지속적 통합(CI) 및 지속적 전달(CD) 파이프라인 전반에 보안 툴과 보안 방식을 자동으로 통합합니다.

DevSecOps의 주요 방식에는 시프트 레프트 테스트와 시프트 라이트 테스트가 포함됩니다. 시프트 레프트 테스트는 소프트웨어 개발 수명 주기(SDLC)의 더 이른 단계에서 보안 테스트와 기타 중요한 개발 방식을 통합하는 것을 의미합니다. 시프트 라이트 테스트는 개발 후반부, 일반적으로 프로덕션 환경에서 테스트를 수행하는 방식입니다. 이러한 방식은 SDLC 전반에 테스트 책임을 분산하여 서로를 보완합니다.