CI/CD

CI/CD란?

CI/CD(지속적 통합/지속적 전달 또는 배포)는 자동화를 통해 지원되는 소프트웨어 개발 전략입니다. 짧은 주기로 제공되고 신뢰할 수 있는 업데이트는 지속적인 코드 배포를 통해 릴리스 주기를 단축합니다.

CI/CD 설명

CI/CD는 여러 DevOps 단계를 다루는 포괄적인 용어입니다. CI(지속적 통합)는 하루에 여러 번 코드 변경 사항을 저장소에 통합하는 전략입니다. CD는 다음과 같이 2가지 의미가 있습니다. 지속적 전달은 코드 통합을 자동화하고, 지속적 배포는 최종 빌드를 최종 사용자에게 자동으로 릴리스합니다. CI/CD는 잦은 테스트를 통해 코드 오류와 결함을 줄여주므로 모든 DevOps 워크플로에서 필수입니다.

CI(지속적 통합)란 무엇인가요?

CI(지속적 통합)는 배포마다 깔끔한 고품질 코드를 제공하면서 개발을 가속화하는 자동 소프트웨어 개발 프로세스입니다. CI는 개발자가 하루에 여러 번 해당 코드 단위를 중앙 공유 저장소에 자주 체크인(커밋)하도록 요구합니다.

CI는 개발자가 공유 코드 저장소에 코드를 체크인할 때의 DevOps 베스트 프랙티스이자 DevOps 수명 주기의 단계입니다. 자동 빌드 툴은 체크인이나 브랜치를 검증하여 오류가 없고 프로덕션에 바로 적용될 준비가 되었는지 확인합니다. 주요 이점은 일반적으로 문제를 조기에 발견하여 더 큰 문제로 확대되는 것을 방지한다는 점입니다.

CI를 채택하면 오랜 시간이 걸리고 빈도가 덜한 대규모 업데이트보다 잦은 주기로 사소한 변경 사항의 하위 집합을 통합합니다. 테스트, 병합, 공유 저장소에 대한 변경 사항을 체크인하는 워크플로를 자동화하면 팀원이 더 깔끔한 코드를 빠르게 제공할 수 있습니다. 더 깔끔한 코드란 검증 가속화, 고품질 릴리스, 확장하기 쉬운 더 효율적인 개발 파이프라인을 의미합니다.

CI의 작동 방식

CI는 개발 단계에서 시작하여 테스트 환경에서 완료되는 간단하고 원활한 프로세스입니다. 이를 통해 모든 개발자가 협력하고, 해당 코드를 트래킹할 수 있습니다. 각 개발자는 공유 코드 저장소(다른 명칭: 메인라인 저장소)에 작은 증분으로 코드를 ‘커밋’합니다. 코드 저장소는 버전 관리 시스템인 Unity VCS, Perforce, Git에서 유지됩니다. 저장소의 메인 브랜치(또는 선택한 경우 자식 브랜치)에 적용된 모든 커밋은 코드를 가져와 빌드를 생성하는 빌드 관리 시스템에 연결된 자동화 빌드 프로세스를 트리거할 수 있습니다. 코드가 빌드 시스템에 병합되면 개발자는 해당 코드 빌드에 대한 전체 액세스 권한을 확보합니다. 여기에서 개발자는 해당 코드가 올바르게 컴파일되었는지, 수정해야 할 오류가 있는지 확인할 수 있습니다. 빌드 시스템은 다양한 테스트 프레임워크를 지원하도록 설정할 수 있습니다.

코드가 승인되고 빌드 주기가 성공하면 빌드의 품질과 후속 릴리스를 검증하기 위해 자동화된 테스트 환경이 트리거됩니다. 테스트와 빌드 프로세스가 매우 빠르므로 코드 커밋의 결과를 신속하게 커뮤니케이션할 수 있어 개발자가 남아 있는 오류를 적시에 수정할 수 있습니다. 이 전체 프로세스를 통해 코드베이스가 정상으로 유지되고 모든 관련자가 효율적으로 계속 작업할 수 있습니다.

CI의 규칙과 원칙

- 단일 중앙 코드 저장소 유지

다양한 팀의 여러 개발자가 코드를 개별 저장소나 별도의 시스템에 임시로 저장하는 것은 최소화해야 합니다.

- 메인라인 저장소에 코드를 자주 커밋/체크인

개발자가 코드를 빌드하거나 테스트하지 않고 오래 보유할수록 중앙 저장소에 저장된 코드와 일치하지 않을 가능성이 높아집니다.

- 별도의 빌드와 테스트 서버 유지

팀에서는 빌드 목적으로만 전용 시스템을 유지해야 합니다. 이렇게 하면 빌드 프로세스를 가속화하고 다른 개발자의 워크플로에 미치는 영향을 최소화할 수 있습니다.

- 필수로 빌드와 테스트 자동화

중앙 소스 코드 저장소에 커밋된 모든 코드는 CI 툴을 사용하여 자동으로 빌드하고 테스트되어야 합니다.

- 프로덕션과 유사한 테스트 환경 사용

테스트 환경은 최종 프로덕션 환경을 시뮬레이션한 것이어야 합니다. 이를 통해 테스트 환경의 사용 가능성을 확보하고 배포 전반에서 기대치를 일관성 있게 유지합니다.

- 품질 보증 팀에 빌드에 대한 액세스 권한 부여

QA 팀이 빌드에 액세스할 수 있으면 프로덕션 요구 사항을 충족하지 못하는 경우를 조기에 감지할 수 있어 나중에 코드 빌드를 다시 작업해야 하는 위험을 줄입니다.

지속적 전달과 지속적 배포 비교

지속적 전달과 지속적 배포는 새 코드를 신속하고 효율적으로 프로덕션에 배포하는 데 사용되는 전략입니다. 지속적 전달은 CI를 따릅니다. 최종 제품이 고객에게 릴리스되기 전 개발 파이프라인의 체크포인트 단계로 생각할 수 있습니다. 코드 변경 사항 검증이 완료되면 코드는 자동으로 중앙 저장소에 전달됩니다.

지속적 배포는 DevOps 수명 주기에서 CI를 따르지만 두 프로세스는 연결되어 있습니다. CI는 자동화를 통해 빌드에 코드를 통합하고, CD는 해당 프로세스를 완료합니다. DevOps 자동화는 업데이트의 품질을 평가합니다. 오류가 없는 것으로 확인되면 자동으로 프로덕션에 배포됩니다.

지속적 전달이란 무엇인가요?

지속적 전달은 소프트웨어에 대한 코드 변경의 빌드, 테스트, 전달을 의미합니다. 이 프로세스에서 코드는 자동 단위 테스트, 통합 테스트, 시스템 테스트 등의 다양한 테스트 환경을 통과한 후 프로덕션으로 푸시됩니다. 지속적 전달은 QA 팀이 코드를 검토하고, 버그를 수정하며, 빌드가 항상 배포 가능하고 릴리스 준비가 되도록 자동화된 테스트를 실행하는 프로덕션과 유사한 스테이징 환경에서 발생합니다.

지속적 전달의 목표는 여러 체인지 세트를 충분히 작게 유지하여 주요 빌드에 대한 업데이트가 최종 제품의 ‘프로덕션 준비’ 상태에 영향을 미치지 않도록 하는 데 있습니다. 최종 제품에 사소한 오류가 있을 수 있지만, 사용자 경험에 영향을 미칠 만큼 심각한 것은 아닙니다.

이 전략은 안정적인 코드만이 우선적으로 전달 단계에 도달하도록 하므로 지속적 전달을 채택하면 개발자는 내부적으로 테스트하는 데 소요되는 시간을 줄일 수 있습니다. 버그 탐지를 더 간단한 프로세스로 활용 가능하여 문제 해결 시간이 단축됩니다.

지속적 배포란 무엇인가요?

지속적 배포의 목표는 빌드가 안정적일 때 중앙 저장소에서 프로덕션으로 코드 변경 사항을 지속적으로 배포하는 데 있습니다. 운영 팀은 컴파일된 코드를 배포하고 다양한 환경(개발/테스트, 스테이징, 프로덕션)에 소프트웨어를 설치합니다. 각 변경 사항은 애플리케이션의 작동하는 버전을 프로덕션으로 푸시하는 자동화된 파이프라인을 통과합니다. 배포는 다양한 형태로 나타날 수 있습니다. 다크 릴리스는 사용자에게 표시되지 않는 배포이며, 기능 전환이나 스위치는 특정 체인지 세트의 하위 집합을 사용자 그룹에 배포하여 테스트하고 피드백을 얻는 데 사용할 수 있습니다.

지속적 배포는 개발자와 고객에게 많은 이점을 제공합니다. 지속적 배포 솔루션을 사용하는 개발자는 더 이상 수동 빌드 배포에 대해 걱정할 필요가 없으며, 더 많은 기술 기반 작업에 집중할 수 있습니다. 자동화는 피드백 루프를 단축시켜 고객의 의견에 따라 제품을 더 빠르게 업데이트할 수 있게 합니다. 코드는 지속적 배포를 통해 품질을 확보하고 제품의 실시간 모니터링을 지원하는 시뮬레이션 환경에서 실행되고 유지됩니다. 지속적 배포의 주요 목표는 최신 버전의 코드를 일관성 있게 릴리스하고 이러한 변경 사항을 최종 사용자에게 자동으로 배포하는 데 있습니다.

CI/CD와 DevOps의 관계

모든 소프트웨어 개발은 사전 프로덕션(계획 단계)으로 시작하여 프로덕션(코딩과 에셋 생성) 순으로 진행됩니다. DevOps는 이러한 프로세스를 더 효율적으로 만들기 위한 하나의 문화이자 프로세스입니다. CI/CD는 DevOps 수명 주기 내의 단계로, 최종 제품의 지속적이고 반복적인 개선을 확보하기 위해 시간 경과에 따라 작지만 안정적인 코드 업데이트의 구현을 의무화합니다.

정기적이고 빈번한 소프트웨어 릴리스는 코드 변경 사항의 통합, 전달, 배포를 지원하는 특정 툴과 제품을 사용하여 달성할 수 있으며, 이를 CI/CD 파이프라인이라고 합니다.

CI/CD 파이프라인은 DevOps 수명 주기가 구현되도록 하는 툴과 자동화에 연결된 일련의 구체적인 단계입니다. CI/CD는 DevOps 문화의 필수적인 부분이지만, DevOps는 소프트웨어 개발 수명 주기 전반에서 협업, 팀 구조, 관측성, 버전 관리 등 훨씬 더 많은 사항을 포함합니다.

DevOps의 구현은 조직마다 크게 다르지만, 본질적으로 DevOps는 CI/CD 없이 구현을 달성할 수 없습니다. CI/CD 파이프라인은 DevOps 문화와 소규모의 빈번한 릴리스 프로세스에 본질적으로 연결되어 있습니다.

CI/CD의 이점

- 신속한 반복 작업

DevOps 수명 주기의 일환으로 CI/CD 전략을 도입하면 코드베이스에 대한 변경 사항을 검증하고 배포하는 수동 작업을 자동화하여 개발이 가속화됩니다.

- 깔끔한 코드

하루 동안 수많은 사소한 변경 사항을 체크인하면 소스 코드에 빌드에 영향을 미치는 오류가 발생할 위험이 크게 줄어듭니다.

- 버그 수정 가속화

CI/CD를 통해 더 사소한 여러 체인지 세트를 보다 자주 병합하면 더 수월하게 코드 오류를 식별하고 큰 문제로 번지기 전에 수정할 수 있습니다.

- 피드백 루프 단축

CI/CD를 사용하면 피드백 루프를 단축할 수 있습니다. 이는 핵심 DevOps 원칙으로, 더 사소하고 반복적인 변경 사항이 통합, 테스트, 배포하기 더 쉽기 때문입니다.

- 더 나은 협업

CI/CD는 코드 커밋과 빌드 론칭을 위한 프로세스와 일정을 정의하여 작업의 명확성을 제공합니다. 팀원은 더 명확한 목표를 토대로 한층 더 민첩하게 작업할 수 있습니다.

- 고객에게 만족감 선사

CI/CD 덕분에 항상 릴리스 준비가 되어 있는 빌드로 고객은 서비스 중단을 덜 경험하고 자신의 피드백이 신속하게 반영되는 것을 경험할 수 있습니다.

애자일과 CI/CD의 차이

애자일 워크플로와 CI/CD는 관련이 있긴 하지만, 차이가 있습니다. 두 개념은 소프트웨어 개발 파이프라인의 완전히 다른 측면을 설명합니다. 애자일 개발은 소프트웨어 개발에서 워크플로, 회의 주기, 팀 구성을 관리하는 프로세스나 방법론을 의미합니다. 애자일 방법론은 고객의 요구 사항을 경청하고 이에 반응하며 개발 프로세스의 각 단계에 고객을 참여시켜 변경 사항을 적용하고 전달을 가속화합니다.

CI/CD는 소프트웨어를 릴리스하고 개선하는 데 병목 현상을 일으키는 인적 요소를 제거하기 위해 자동화에 의존합니다. CI와 CD 테스트 모두 파이프라인 전반에 걸쳐 자동화되며 결함을 수정하는 데 드는 비용과 시간을 최소화하기 위해 자주 수행됩니다.

지속적 배포를 사용하여 프로덕션에 배포하는 주기

CI/CD를 사용하는 경우 릴리스는 항상 자주 수행되어야 하며, 이를 통해 미래에 발생할 수 있는 문제를 방지하고 소프트웨어가 항상 릴리스 가능한 상태(일반적으로 하루에 여러 번 배포)를 유지할 수 있습니다. CI/CD 팀에서 흔히 하는 가정은 ‘지속적인’ 릴리스를 구현하는 것이지만, 항상 그런 것은 아닙니다. 릴리스 주기는 제품, 빌드는 물론 다음과 같이 고려해야 할 기타 요소에 따라 크게 달라질 수 있습니다.

1. 중요한 수정인가, 사소한 수정인가?

2. 빌드 간 회귀 수를 트래킹하고 있는가?

3. QA 팀이 구성되어 있는가?

4. 코드베이스에 단위 테스트가 포함되어 있는가?

5. 코드 중복이 있는가?

이 요소는 릴리스 전략과 파이프라인을 생각할 때 고려해야 할 몇 가지 측면의 예시일 뿐이며, 팀마다 크게 다릅니다. 제품마다 다른 접근 방식을 요구합니다.

지속적 배포의 가치

이 질문에 대한 정답은 하나로 정해져 있지 않습니다. 지속적 배포에 투자하기 전에 기업은 먼저 제품의 가장 큰 위험이 무엇인지 평가한 다음, 소프트웨어를 배포하는 방법에서의 절충안을 결정해야 합니다.

제품의 성공은 신속하게 반복하고, 고객의 피드백을 받고, 계속해서 변경 사항을 적용할 수 있는지에 달려 있습니다. 피드백 루프를 단축하고 매우 반응성이 뛰어난 비즈니스를 구축하는 것을 최우선 순위로 둔다면 지속적 배포는 매우 효과적이고 수익 창출에도 도움이 될 것입니다.

하지만 고객이 많지 않은 경우 배포를 증분적으로 구현할 때 이점의 가치는 덜하고 비용만 늘어날 수 있습니다. 배포를 선택하는 스테이징 환경은 궁극적으로 비즈니스 요구 사항, 워크플로, 예산에 따라 달라집니다.

지속적 배포는 설정에 있는 원래 코드에 대한 변경 사항을 지속적으로 적용하므로 설정이 중요합니다. 이는 시간 경과에 따라 발생할 수 있는 코드 오류와 함께 설정도 최신 상태로 유지되도록 합니다.