CI/CD에 대해서 알아보자

728x90

CI/CD란?

CI/CD는 Continuous Integration(지속적 통합)과 Continuous Delivery/Deployment(지속적 제공/배포)의 약자입니다. 코드는 마치 공장의 컨베이어 벨트처럼, 개발에서 테스트를 거쳐 배포까지 매끄럽게 흘러가는 자동화된 프로세스입니다.

CI/CD는 기존에 수동으로 처리했던 작업을 자동화하여 다운타임을 최소화하고 코드 릴리스 주기를 단축합니다. 또한 코드의 업데이트와 변경 사항을 더 빠르게 통합할 수 있어, 사용자 피드백을 더 자주 효과적으로 반영함으로써 사용자 만족도를 향상시킬 수 있습니다.

예를 들어, 전통적인 개발 방식에서는 한 달에 한 번 배포가 일반적이었으나, CI/CD를 통해 하루에도 여러 번(심지어 시간 단위로) 업데이트가 가능해집니다. 실제 많은 기업들은 일일 배포(Daily Deployment)를 실현하고, Amazon과 같은 회사는 평균 11.7초마다 새 코드를 프로덕션에 배포하기도 합니다.

CI/CD의 구성요소

CI (Continuous Integration) - 지속적 통합

CI는 Continuous Integration의 약자로, 빌드-테스트-머지 작업을 자동화하는 프로세스입니다.

CI 이전에는 개발자들이 특정한 날(보통 1달 주기로)에 빌드-테스트-머지 작업을 한꺼번에 수행했습니다. 이러한 방식은 여러 개발자가 동시에 작업할 때 문제가 발생합니다.

여러 사람이 같은 코드베이스에서 오랜 기간 독립적으로 작업하면 충돌되는 코드들이 다수 발생하게 됩니다. 이는 병합 과정에서 큰 어려움을 초래합니다.

결과적으로 새로운 기능을 개발하는 데 걸리는 시간보다 충돌된 코드들을 수정하는 데 더 많은 시간이 소요될 수 있습니다. 이는 개발 효율성과 생산성을 크게 저하시킵니다.

이러한 문제를 해결하기 위한 더 좋은 방법은 가능한 한 작업을 작은 단위로 나누고, 주기적으로 자주 통합해 나가는 것입니다. 작은 변경사항을 자주 통합함으로써 충돌을 조기에 발견하고 해결할 수 있습니다.

여기서 자동화를 도입하면 어떻게 될까요? 자동화는 이 과정을 훨씬 효율적으로 만듭니다.

개발자가 GitHub에 코드만 올리면 나머지 작업인 테스트와 빌드는 프로그램이 자동으로 처리해준다면, 개발자는 코드 작성에만 집중할 수 있습니다. 자동화된 테스트는 즉시 피드백을 제공하므로 문제를 빠르게 발견하고 수정할 수 있습니다.

이러한 CI 방식은 반복되는 귀찮은 작업을 줄이고, 코드 품질을 향상시키며, 개발 프로세스 전반의 효율성을 높이는 훨씬 편리하고 효과적인 방법입니다.

CD(Continuous Delivery/Deployment) - 지속적 제공/배포

CI를 통해 개발자들이 코드 변경사항을 자주 통합하게 되면서 개발 과정이 크게 개선되었습니다. 하지만 여전히 한 가지 문제가 남아있었습니다. "통합된 코드를 어떻게 효율적으로 배포할 것인가?"

전통적인 방식에서는 개발팀이 코드를 통합한 후, 배포팀이 수동으로 배포 작업을 진행했습니다. 이 과정은 보통 복잡한 절차와 여러 승인 단계를 거쳐야 했기 때문에 배포 주기가 몇 주 또는 몇 달에 한 번으로 제한되었습니다.

이런 상황에서 CD(Continuous Delivery - 지속적 제공)가 등장했습니다. CD는 CI의 자연스러운 확장으로, 통합된 코드를 언제든지 배포 가능한 상태로 유지하는 것을 목표로 합니다.

지속적 제공(Continuous Delivery)은 모든 코드 변경사항이 테스트를 거쳐 배포 준비가 완료된 상태로 유지되지만, 실제 프로덕션 환경으로의 배포는 수동으로 승인하는 방식입니다. 이는 마치 주방에서 요리가 완성되어 서빙할 준비가 되었지만, 매니저의 최종 확인 후에 손님에게 제공되는 것과 같습니다.

반면 지속적 배포(Continuous Deployment)는 한 단계 더 나아가, 코드 변경사항이 모든 테스트를 통과하면 사람의 개입 없이 자동으로 프로덕션 환경에 배포됩니다. 이는 요리가 완성되자마자 자동 시스템에 의해 즉시 손님에게 서빙되는 것과 유사합니다. 두 방식의 핵심 차이는 프로덕션 배포 단계에서 수동 승인 과정이 있는지 여부입니다.

예를 들어, 개발자가 새로운 기능을 개발하고 코드를 저장소에 푸시하면 CI 시스템이 이 코드를 자동으로 빌드하고 테스트합니다. 지속적 제공 환경에서는 모든 테스트를 통과한 코드가 스테이징 환경에 배포되고, 실제 프로덕션 배포는 책임자의 승인 후에 이루어집니다. 반면 지속적 배포 환경에서는 테스트를 통과한 코드가 추가 승인 절차 없이 곧바로 프로덕션 환경에 자동 배포됩니다.

이러한 CD 접근 방식은 배포 프로세스를 크게 간소화하고, 사용자에게 새로운 기능과 버그 수정을 더 빠르게 제공합니다. 작은 단위의 변경사항을 자주 배포함으로써 대규모 변경으로 인한 위험을 최소화하고, 문제 발생 시 빠르게 롤백할 수 있는 장점이 있습니다.

결국 CI/CD의 완전한 구현은 소프트웨어 개발의 전체 생명주기를 자동화하여, 개발자가 코드 작성에만 집중할 수 있게 하고, 사용자에게는 더 빠르고 안정적인 서비스를 제공할 수 있게 합니다.

지속적 제공(Continuous Delivery)과 지속적 배포(Continuous Deployment)의 차이

지속적 제공(Continuous Delivery)과 지속적 배포(Continuous Deployment)는 모두 CD로 약칭되지만 중요한 차이점이 있습니다. 지속적 제공은 코드 변경사항이 테스트를 통과한 후 배포 준비는 완료되지만, 실제 프로덕션 환경에 배포하기 전에 사람의 수동 승인이 필요합니다. 반면 지속적 배포는 코드 변경이 모든 테스트를 통과하면 자동으로 프로덕션 환경에 배포되는 방식으로, 사람의 개입이 필요하지 않습니다.

실제 개발 환경에서 두 접근 방식을 비교해보면 다음과 같습니다:

지속적 제공(Continuous Delivery) 워크플로우: Code → Build → Test → Staging까지 자동으로 진행된 후, 프로덕션 환경으로의 Deploy 과정은 수동으로 진행합니다.
지속적 배포(Continuous Deployment) 워크플로우: Code → Build → Test → Staging → Deploy 과정 전체가 자동화되어 있어, 코드 변경이 자동으로 프로덕션까지 배포됩니다.

따라서 최종 배포 단계의 자동화 여부가 두 접근 방식의 핵심적인 차이점이라고 이해할 수 있습니다.