지속적 전달 이해

지속적 전달(CD)은 소프트웨어를 프로덕션에 릴리스하기 위한 준비 단계를 자동화하여 지속적 통합(CI)을 기반으로 구축합니다.

코드 변경 사항을 지정된 브랜치에 병합할 때마다 지속적 통합 프로세스가 자동화된 유닛 테스트를 포함한 일련의 검사를 수행하고 빌드를 생성합니다. 지속적 전달은 각 빌드를 일련의 테스트 및 스테이징 환경으로 자동 배포하고 자동화된 테스트를 추가로 실행하여 이 프로세스를 확장합니다.

이러한 테스트에는 통합 테스트, UI 테스트 및 성능 테스트(로드, 소크, 스트레스 테스트 등)와 엔드투엔드 테스트가 포함됩니다. 업계에 따라 지속적 전달을 활용하여 보안 테스트, 접근성 테스트 및 수동 사용자 수용 테스트 및 실험적 테스트를 실행할 수도 있습니다. 빌드가 각 단계를 성공적으로 통과하면 프로덕션으로 릴리스될 준비가 된 것으로 간주됩니다.

지속적 통합과 마찬가지로 효율적인 지속적 전달은 최대한 많은 프로세스를 자동화합니다. 여기에는 단계별로 피드백을 제공하고, 빌드가 단계를 통과하지 못하면 팀이 빠르게 문제를 해결할 수 있도록 경고하는 것이 포함됩니다.

지속적 전달과 지속적 배포는 모두 빌드를 자동으로 환경에 배포하고 자동화된 테스트를 실행합니다. 그 결과 두 용어는 혼용해서 사용할 때가 많지만, 지속적 전달과 지속적 배포를 구분하는 것이 유용할 수 있습니다.

지속적 배포의 경우 코드 변경이 각 테스트 단계를 통과할 때마다 자동으로 프로덕션에 배포됩니다. 반면에 지속적 전달은 최종 단계인 프로덕션으로 소프트웨어를 릴리스할 때 수동 단계를 거쳐야 합니다.

소프트웨어 개발 팀이라면 지속적 배포가 이상적인 목표처럼 들릴 수 있지만, 상당수의 팀이 지속적 전달을 시행하는 데는 여러 이유가 있습니다.

지속적 전달과 지속적 배포에 대해 자세히 알아보기

CI/CD 프로세스의 최종 단계는 코드 변경 사항을 프로덕션으로 배포하는 것입니다. 지속적 전달의 경우 릴리스 프로세스 자체는 자동화되어 있지만 릴리스로 배포할지 여부는 수동으로 결정해야 합니다.

일부 팀에서는 지속적 배포로 넘어가기 전의 징검다리 단계로 지속적 전달을 시행합니다. 프로덕션으로 최종 배포하는 것을 수동으로 실행하면 자동화된 테스트와 검사의 신뢰도를 쌓는 동안 안전을 확보할 수 있습니다. 이 경우 몇 달 정도 지속적 전달을 시행한 다음에 성공적인 모든 코드 변경 사항을 자동으로 프로덕션에 배포하는 단계로 넘어가면 좋습니다.

그러나 하루에 여러 번 또는 한 시간에도 여러 번 소프트웨어 업데이트를 배포하는 방식이 항상 좋지는 않습니다. 모바일 앱, API, 임베디드 소프트웨어 또는 데스크톱 제품처럼 버전이 있는 소프트웨어의 경우, 변경 사항을 그룹화하여 대규모 릴리스로 만드는 것이 합리적일 때가 많습니다. 설치된 제품을 사용하는 사람들이 몇 시간마다 앱을 업데이트하기를 바라지도 않을 것이고, 새로운 API 버전으로 업그레이드하면 고객에게 큰 영향을 줄 수도 있습니다. 지속적 전달과 지속적 배포 중에서 선택할 때는 비즈니스와 사용자에게 맞는 결정을 내려야 합니다.

정확한 빌드 단계, 환경 및 테스트는 제품이나 조직에 따라 달라지지만, 다음의 일반적인 원칙은 지속적 전달 프로세스를 만드는 데 도움이 될 것입니다.

• CI로 시작하세요. 대부분의 경우 지속적 전달을 실행하기 전에 지속적 통합을 구현하는 것이 합리적입니다. CI는 주로 개발 팀에 영향을 주기 때문에 외부 이해관계자가 포함되기 전에 빌드, 테스트 및 배포 프로세스의 자동화에 익숙해질 기회를 제공합니다.
• 빠른 피드백을 위한 자체적인 CD 프로세스를 설계하세요. 문제를 조기에 발견하면 개발 프로세스의 효율성이 올라갑니다. 다양한 플랫폼을 대상으로 하는 빌드에서 자동화된 UI 테스트와 같은 단계는 병렬로 실행할 수 있습니다. 마찬가지로, 오래 실행되거나 리소스를 많이 사용하는 성능 테스트는 빌드가 이전 단계를 성공적으로 통과할 때까지 지연될 수 있습니다.
• 이해관계자와 소통하세요. CI/CD의 배경 철학인 DevOps는 개발 팀이 팀 간의 벽을 허물고 전체적인 소프트웨어 개발 프로세스를 고려하는 것을 권장합니다. CD 파이프라인을 설계할 때 운영, 보안은 물론 마케팅과 지원을 포함하여 현재 릴리스 프로세스에 참여하는 모든 관계자를 포함시키세요.
• 테스트를 자동화하세요. 자동화된 테스트는 소프트웨어가 의도대로 동작하는지 안정적으로 빠르게 검증할 방법을 제공하므로 지속적 전달에 필수적입니다. 자동화된 테스트가 없다면 영향력이 가장 큰 영역을 우선시하여 테스트 커버리지를 점진적으로 늘리세요.
• 동일한 빌드 아티팩트를 다시 사용하세요. 일관성을 유지하려면 CI 단계에서 같은 빌드 아티팩트를 각 사전 프로덕션 환경과 프로덕션 환경에 배포하세요.
• 테스트 환경을 자동으로 새로 고치세요. 테스트 환경은 CI/CD 프로세스에서 새로운 빌드가 있을 때마다 새로 고치는 것이 좋습니다. 컨테이너와 코드형 인프라 접근 방식을 사용하면 필요에 따라 환경을 내리거나 새로운 환경을 가동하기가 쉬워집니다.
• 이해관계자의 요구 사항을 고려하세요. 위에 기술된 원칙이 적용되지 않는 예외 환경은 지원, 영업 또는 마케팅 팀에서 새로운 기능에 적응하기 위해 사용하는 스테이징 환경입니다. 이러한 팀은 진행 중인 작업이 중단되는 것을 피하기 위해 요청에 따라 환경이 업데이트되는 것을 선호할 수 있습니다.
• DevSecOps를 채택하세요. 정보 보안 또는 사이버 보안 팀은 보안 감사를 실행하는 데 소요되는 시간과 감사 이후의 긴 보고서로 인해 빈번한 릴리스를 방해한다고 여겨지는 경우가 많습니다. DevSecOps 방식을 채택하고 보안 요구 사항을 처음부터 파이프라인에 적용하세요.
• 수동 테스트 요구 사항을 고려하세요. 비즈니스에 따라 예기치 않은 실패 모드를 식별하기 위해 일부 실험적 수동 테스트를 포함하세요. 모든 코드 변경 사항에 수동 테스트를 요구하지 말고 선택적 단계 또는 주 단위나 월 단위로 실행되는 대체 파이프라인을 고려해 보세요.
• 릴리스를 자동화하세요. 지속적 전달에서 프로덕션으로 릴리스하는 결정은 수동으로 이루어져도 릴리스 자체는 자동화되어야 합니다. 명령어 하나만으로 정상 빌드를 프로덕션에 배포할 수 있어야 합니다.

지속적 전달을 통해 소프트웨어를 더 빠르게 릴리스하고 더 빈번하게 하면서도 프로덕션까지 전달되는 버그의 수를 줄일 수 있습니다. 이를 달성하기 위한 핵심은 항상 변경 사항을 지속적으로 테스트하고 문제가 발견되는 즉시 해결하여 언제든 코드가 릴리스될 수 있도록 하는 것입니다.

여기에 더해서 지속적인 전달에는 여러 가지 장점이 있습니다.

• 릴리스를 빈번하게 하면 시장 출시 시간이 단축되고, 새로운 기능, 수정 및 개선 사항이 사용자에게 더 빠르게 전달됩니다.
• 지속적인 테스트 프로세스로 작업물에 대한 피드백을 빠르게 받을 수 있습니다. 최근의 변경 사항에서 취약점이 발생하여 특정 상황에서 앱이 멈추거나 API 호출이 실패한다면, 전통적인 릴리스 테스트 프로세스를 활용할 때보다 훨씬 더 빨리 해당 문제를 식별할 수 있습니다.
• 문제를 조기에 발견하면 개발 프로세스의 효율성을 개선할 수 있습니다. 개발자가 변경 사항을 아직 기억하고 있을 뿐만 아니라 불량한 코드를 기반으로 다른 코드 변경 사항이 추가될 위험도 줄어듭니다.
• 반복적인 빌드, 테스트, 릴리스 작업을 자동화하면 이러한 작업이 일관되게 실행되고 실수가 발생할 위험이 감소하는 동시에 팀원이 가치를 더하는 일에 더 집중할 수 있습니다.
• 자동화된 테스트에 투자하면 소프트웨어를 더욱 엄격하게 테스트할 수 있습니다. 여기에는 여러 플랫폼에서 일관되게 테스트하고, 접근성 요구 사항을 만족하는지 확인하거나 제품이나 서비스의 성능 베이스라인을 측정하는 것이 포함될 수 있습니다.
• 환경 새로고침과 빌드 배포를 자동화하면 온프레미스 서버든 클라우드에 호스팅된 빌드 팜이든 상관없이 인프라를 더욱 효율적으로 사용할 수 있습니다.
• 스테이징 사이트로의 배포를 자동화하면 개발 팀이나 운영 팀에서 추가적인 수작업을 하지 않아도 제품, 마케팅 및 지원 팀이 새로운 기능을 미리 확인할 수 있습니다.
• 지속적 전달은 릴리스 프로세스를 강화하고 반복 가능하게 만들며, 정확한 릴리스 시점을 결정할 권한을 사용자에게 부여합니다. CD 프로세스가 자리를 잡으면 작은 개선 사항을 주, 일 또는 시간 단위로 전달할 수 있습니다.

지속적 전달 프로세스를 구현하는 데에는 몇 가지 해결 과제가 따릅니다.

• 팀 간의 협업: 조직 내에서 운영, 인프라 및 보안 팀과 같은 다양한 부서와 협력해야 할 가능성이 높습니다. 단기적으로는 팀 간의 경계를 허무는 게 어렵겠지만 이를 통해 장기적으로 협업과 효율성이 개선됩니다.
• 시간 투자: 빌드, 테스트, 릴리스 프로세스를 자동화하려면 시간이 걸립니다. 그러나 반복적인 접근 방법을 취하고 시간을 들여 프로세스를 만들어 나가면 관리가 용이해집니다. 결함률, 빌드 타임과 같은 메트릭 수집과 이를 수동 절차와 비교하는 방식은 이해관계자에게 투자수익률을 증명할 때 효과적입니다.
• 확장의 어려움: 지속적 전달 프로세스를 확장하면서 다수의 빌드와 테스트를 병렬로 실행하고 싶을 수 있습니다. 이 단계에서 가용한 서버의 수가 제약 요소가 될 수 있습니다. 파이프라인 성능의 최적화를 수행한 후 필요에 따라 빌드 팜을 확장할 수 있도록 클라우드 호스팅 인프라로 이전을 고려해 보세요.

지속적 전달 프로세스를 만드는 일은 막연해 보일 수도 있지만 제대로 만든다면 소프트웨어 릴리스 속도는 극적으로 높이고 버그는 최소화할 수 있습니다.

지속적 전달을 효율적으로 구현하려면 DevOps 사고방식을 채택하는 것이 중요합니다. DevOps 관점에서 소프트웨어 개발 프로세스는 한 방향으로 이동하며 요구 사항, 코드 및 보고서가 한 팀에서 다른 팀으로 전달되는 컨베이어 벨트가 아닙니다. DevOps는 짧고 반복적인 주기로 협업과 신속한 피드백을 지원합니다.

'완료의 정의'를 바꾸는 것이 이 사고방식을 채택하는 데 도움이 됩니다. 코드가 테스트를 위해 제출될 때 작업이 완료되는 것이 아니라 새로운 기능이나 코드 변경 사항이 프로덕션으로 릴리스되었을 때만 완료가 된 것입니다. 수정할 때 승인을 위해 변경 보드를 거쳐야 하는 긴 보고서를 사용하는 것보다 파이프라인의 어느 단계에서든 문제가 발견되면 해당 피드백을 즉시 전달하고 협력하는 편이 문제를 더 빠르게 해결할 수 있습니다. 이것이 지속적 전달의 핵심입니다.

지속적 전달을 시작하는 데 도움이 되는 팁을 더 알아보려면 CI/CD 모범 사례 가이드를 참조하세요.

지속적인 전달을 사용하면 소프트웨어를 보다 간편하고 빠르게 릴리스할 수 있어 프로덕션으로의 배포 빈도를 높일 수 있습니다. 대규모 분기별 릴리스나 연간 릴리스 대신 소규모 업데이트가 자주 제공됩니다. 따라서 사용자는 신규 기능과 버그 수정을 더 빠르게 받아볼 수 있으며 개발자는 소프트웨어의 사용 방식을 확인하고 그에 따라 계획을 조정할 수 있습니다.

릴리스 프로세스의 마지막 단계를 계속 제어하고 싶어 하는 조직이 있는 반면, CI/CD 파이프라인의 논리적 귀결은 지속적 배포라는 방식을 사용하는 프로덕션 릴리스의 자동화라고 생각하는 조직도 있습니다. 여기에 관해서는 CI/CD 가이드의 다음 섹션에서 자세히 알아볼 수 있습니다.

TeamCity는 CI/CD 플랫폼으로서 다양한 빌드 도구, 테스트 프레임워크, 컨테이너 및 클라우드 인프라 공급자를 광범위하게 지원합니다. 빌드 시스템을 온프레미스, 클라우드에 호스팅하거나 혼합해서 사용하고자 하는 경우에도 TeamCity는 빌드 작업을 조율하여 효율을 극대화합니다.

TeamCity의 파이프라인 로직은 맞춤 설정할 수 있습니다. 즉, 플랫폼별 테스트와 같은 프로세스를 언제 병렬로 실행할지, 다음 단계로 넘어가기 전에 언제 성공적인 완료를 요구할지 선택할 수 있습니다. 알림도 구성할 수 있어 어디서 작업하든 필요한 정보를 받을 수 있으므로 불필요하게 방해 받을 일이 없습니다. 마지막으로 상세한 결과 덕분에 프로덕션까지 이르는 경로를 명확하게 파악할 수 있습니다.