기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 완전한 CI/CD 프로세스의 차이
CI/CD 파이프라인은 개발자가 CI/CD 파이프라인의 CD 부분을 통해 빌드되고 테스트되는 기본 브랜치(또는 *트렁크*)에 작고 빈번한 업데이트를 병합하는 최신 *트렁크 기반 워크플로*를 사용합니다. 이 워크플로는 개발 및 릴리스 브랜치가 릴리스 일정으로 구분되는 *Gitflow 워크플로*를 대체합니다. 많은 조직에서 Gitflow는 여전히 버전 제어 및 배포로 널리 사용되는 방법입니다. 그러나 이제 레거시로 간주되므로 CI/CD 파이프라인에 통합하는 것이 어려울 수 있습니다.
많은 조직에서 Gitflow 워크플로에서 트렁크 기반 워크플로로의 전환이 완료되지 않았으며, 그 결과 도중에 어딘가에 멈춰 CI/CD로 완전히 마이그레이션되지 않은 상태입니다. 어쨌든 파이프라인은 과거와 현재 사이에 과도적 상태로 멈춰 있는 레거시 워크플로의 남은 특정 부분에 매달립니다. Git 워크플로의 차이를 검토한 다음 레거시 워크플로를 사용하는 것이 다음에 어떤 영향을 미칠 수 있는지 알아봅니다.
+ [환경 무결성](environment-integrity.md)
+ [출시](releases.md)
+ [보안](security.md)
최신 구성에서 레거시 Git 워크플로의 남은 부분을 더 쉽게 식별할 수 있도록 [Gitflow](#gitflow-approach)를 최신 [트렁크 기반](#trunk-based-approach) 접근 방식과 비교해 보겠습니다.
## Gitflow 접근 방식
이 이미지에서는 Gitflow 워크플로를 보여줍니다. Gitflow 접근 방식은 여러 브랜치를 사용하여 여러 가지 코드 버전을 동시에 추적합니다. 개발자가 여전히 코드의 현재 버전에서 작업하는 동안 향후 일정 기간 애플리케이션에 대한 업데이트 릴리스를 예약합니다. 트렁크 기반 리포지토리는 기능 플래그를 사용하여 이를 수행할 수 있지만 기본적으로 Gitflow에 내장되어 있습니다.
![\[기능, 개발, 릴리스 및 핫픽스 브랜치를 포함하는 Gitflow 워크플로\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
Gitflow 접근 방식의 결과 중 하나는 애플리케이션 환경이 일반적으로 동기화되지 않는다는 것입니다. 표준 Gitflow 구현에서 개발 환경은 코드의 현재 상태를 반영하는 반면, 사전 프로덕션 및 프로덕션 환경은 최신 릴리스의 코드베이스 상태에 고정되어 있습니다.
이 경우 릴리스되지 않은 기능을 노출하지 않고는 개발자가 작업하는 코드베이스를 프로덕션 환경에 병합할 수 없으므로 프로덕션 환경에 결함이 나타날 때 상황이 복잡해집니다. Gitflow는 핫픽스를 사용하여 이 상황을 처리합니다. 핫픽스 브랜치는 릴리스 브랜치에서 생성된 다음 상위 환경에 직접 배포됩니다. 그런 다음 핫픽스 브랜치는 코드를 최신 상태로 유지하기 위해 개발 브랜치에 병합됩니다.
## 트렁크 기반 접근 방식
다음 이미지에서는 트렁크 기반 워크플로를 보여줍니다. 개발자가 기능 브랜치에서 로컬로 기능을 빌드하고 테스트한 다음 해당 변경 사항을 기본 브랜치에 병합합니다. 이후 기본 브랜치는 개발, 프로덕션 이전 및 프로덕션 환경에 순차적으로 구축됩니다. 유닛 테스트 및 통합 테스트는 각 환경 사이에서 수행됩니다.
![\[기능 브랜치와 기본 브랜치가 있는 트렁크 기반 워크플로.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
이 워크플로를 사용하면 모든 환경이 동일한 코드베이스를 운영합니다. 릴리스되지 않은 기능을 노출하지 않고도 기본 브랜치에서 변경 사항을 구현할 수 있으므로 상위 환경에 대한 핫픽스 브랜치가 필요하지 않습니다. 기본 브랜치는 항상 안정적이고 결함이 없으며 릴리스할 준비가 된 것으로 간주됩니다. 이를 통해 CI/CD 파이프라인의 소스로 통합할 수 있습니다. 그러면 파이프라인의 모든 환경을 통해 코드베이스를 자동으로 테스트하고 배포할 수 있습니다.
# 트렁크 기반 접근 방식의 환경 무결성 이점
많은 개발자가 알고 있듯이 코드를 한 번 변경하면 때때로 [나비 효과](https://www.americanscientist.org/article/understanding-the-butterfly-effect)(American Scientist 기사)가 발생할 수 있습니다. 관련이 없는 것처럼 보이는 작은 편차가 예상치 못한 결과를 유발하는 체인 반응을 일으킵니다. 그러면 개발자는 근본 원인을 찾기 위해 철저히 조사해야 합니다.
과학자는 실험을 수행할 때 테스트 대상을 실험군 및 대조군과 같은 두 그룹으로 구분합니다. 실험에서 테스트되는 사물을 제외하고 실험군과 대조군을 완전히 동일하게 만들기 위한 것입니다. 대조군에서 발생하지 않는 일이 실험군에서 나타나면 테스트하는 요소가 유일한 원인일 수 있습니다.
배포의 변경 사항을 실험군으로 생각하고 각 환경을 별도의 제어군으로 간주합니다. 하위 환경에서 테스트한 결과는 제어가 상위 환경과 동일한 경우에만 신뢰할 수 있습니다. 환경 편차가 클수록 상위 환경에서 결함을 발견할 가능성이 커집니다. 즉, 코드 변경 사항이 프로덕션에서 실패할 경우 프로덕션에 도달하지 않도록 먼저 베타에서 실패하는 것이 좋습니다. 따라서 가장 하위의 테스트 환경에서 프로덕션 환경에 이르기까지 각 환경을 동기화된 상태로 유지하기 위해 모든 노력을 기울여야 합니다. 이를 *환경 무결성*이라고 합니다.
모든 완전한 CI/CD 프로세스의 목표는 문제를 최대한 빨리 발견하는 것입니다. 트렁크 기반 접근 방식을 사용하여 환경 무결성을 유지하면 핫픽스가 거의 필요하지 않습니다. 트렁크 기반 워크플로에서는 프로덕션 환경에 문제가 처음 나타나는 경우가 드뭅니다.
Gitflow 접근 방식에서는 핫픽스가 상위 환경에 직접 배포된 후 개발 브랜치에 추가됩니다. 그러면 향후 릴리스에 대한 수정 사항이 유지됩니다. 그러나 핫픽스는 애플리케이션의 현재 상태에서 직접 개발 및 테스트되었습니다. 핫픽스가 프로덕션 환경에서 완벽하게 작동하더라도 개발 브랜치의 최신 기능과 상호 작용할 때 문제가 발생할 가능성이 있습니다. 핫픽스에 대한 핫픽스를 배포하는 것은 일반적으로 바람직하지 않으므로 개발자는 핫픽스를 개발 환경에 개량하는 데 추가 시간을 소비하게 됩니다. 대부분의 경우 이로 인해 상당한 기술 부채가 발생하고 개발 환경의 전반적인 안정성이 저하될 수 있습니다.
환경에서 장애가 발생하면 모든 변경 사항이 롤백되어 환경이 이전 상태로 돌아갑니다. 코드베이스를 변경할 경우 첫 번째 단계에서 파이프라인을 다시 시작해야 합니다. 프로덕션 환경에서 문제가 발생하면 수정 사항도 전체 파이프라인을 거쳐야 합니다. 이 접근 방식을 사용하면 피할 수 있는 문제에 비해 하위 환경을 통과하는 데 걸리는 추가 시간은 일반적으로 무시할 수 있습니다. 하위 환경의 전체 목적은 실수가 프로덕션 환경에 도달하기 전에 포착하는 것이므로 Gitflow 접근 방식을 통해 이러한 환경을 우회하는 것은 비효율적이고 불필요한 위험입니다.
# 트렁크 기반 접근 방식의 릴리스 이점
종종 핫픽스가 필요한 이유 중 하나는 레거시 워크플로에서 개발자가 작업하는 애플리케이션의 상태에서 아직 프로덕션 환경에 있지 않은 릴리스되지 않은 여러 기능이 포함될 수 있다는 점 때문입입니다. 예약된 릴리스가 수행될 때만 프로덕션 환경과 개발 환경이 동기화된 후 다음 예약된 릴리스까지 즉시 다시 분기하기 시작합니다.
완전한 CI/CD 프로세스 내에서 예약된 릴리스를 보유할 수 있습니다. 기능 플래그를 사용하여 프로덕션으로 코드 릴리스를 지연할 수 있습니다. 그러나 완전한 CI/CD 프로세스에서는 예약된 릴리스를 불필요하게 만들어 유연성을 높일 수 있습니다. 결국 *지속적*이란 단위는 CI/CD의 키워드이며, 이는 변경 사항이 준비되면 릴리스됨을 의미합니다. 거의 항상 하위 테스트 환경과 동기화되지 않는 별도의 릴리스 환경을 유지하지 마세요.
파이프라인이 완전한 CI/CD가 아닌 경우 상위 환경과 하위 환경 간의 분산은 일반적으로 브랜치 수준에서 발생합니다. 개발자는 개발 브랜치에서 작업하고 예정된 릴리스가 필요한 경우에만 업데이트되는 별도의 릴리스 브랜치를 유지 관리합니다. 릴리스 브랜치와 개발 브랜치가 분산되면 다른 복잡성이 발생할 수 있습니다.
환경이 동기화되지 않는 것 외에도 개발자는 개발 브랜치에서 작업하고 프로덕션에서보다 훨씬 앞선 애플리케이션 상태에 익숙해지므로 문제가 발생할 때마다 프로덕션 상태로 다시 전환해야 합니다. 개발 브랜치의 상태는 프로덕션에 앞서 많은 기능을 포함할 수 있습니다. 개발자가 매일 해당 브랜치에서 작업하는 경우 프로덕션에 출시된 것과 출시되지 않은 것을 기억하기 어렵습니다. 이 경우 다른 버그를 수정하는 과정에서 새 버그가 발생할 위험이 커집니다. 그 결과는 몇 주, 몇 달 또는 몇 년 동안 타임라인을 연장하고 기능 릴리스를 지연시키는 끝없는 수정 주기가 이어질 수 있습니다.
# 트렁크 기반 접근 방식의 보안 이점
완전한 CI/CD 프로세스는 배포에 대해 완전 자동화된 단일 정보 소스 접근 방식을 제공합니다. 파이프라인에는 단일 진입점이 있습니다. 소프트웨어 업데이트는 처음에 파이프라인에 진입하고 한 환경에서 다음 환경으로 있는 그대로 전달됩니다. 파이프라인의 어느 단계에서든 문제가 발견되면 코드가 변경되어 동일한 프로세스를 거쳐 첫 번째 단계에서 시작해야 합니다. 파이프라인의 진입점을 줄이면 취약성이 파이프라인에 도입될 수 있는 여지도 줄어듭니다.
또한 진입점은 프로덕션 환경에서 가장 먼 지점이므로 취약성이 프로덕션 환경에 도달할 가능성을 크게 줄입니다. 완전한 CI/CD 파이프라인에서 수동 승인 프로세스를 구현하는 경우에도 변경 사항이 다음 환경으로 승격되는지에 대해 진행 또는 중지 의사 결정을 허용할 수 있습니다. 의사 결정권자가 변경 사항을 배포하는 사람과 반드시 같은 사람은 아닙니다. 이를 통해 코드 변경 사항 배포자와 해당 변경 사항 승인자의 책임이 분리됩니다. 또한 기술 지식 수준이 낮은 조직 리더가 승인자 역할을 더 쉽게 수행할 수 있습니다.
마지막으로 단일 진입점은 프로덕션 환경의 사용자 인터페이스(UI) 콘솔에 대한 쓰기 액세스를 소수의 사용자 또는 0명의 사용자로 제한하는 데 도움이 됩니다. 콘솔에서 수동으로 변경할 권한이 있는 사용자 수를 줄이면 보안 이벤트의 위험을 줄일 수 있습니다. 프로덕션 환경에서 콘솔을 수동으로 관리하는 기능은 CI/CD 자동 접근 방식보다 레거시 워크플로에서 훨씬 더 필요합니다. 이러한 수동 변경 사항은 추적, 검토 및 테스트하기 더 어렵습니다. 일반적으로 시간을 절약하기 위해 수행되지만 장기적으로 프로젝트에 상당한 기술 부채가 추가됩니다.
콘솔 보안 문제가 반드시 악의적인 행위자에 의해 발생하는 것은 아닙니다. 콘솔에서 발생하는 많은 문제는 우발적입니다. 우발적 보안 노출이 매우 일반적이며, 이로 인해 제로 트러스트 보안 모델이 부상했습니다. 이 모델은 부분적으로 내부 직원이라도 액세스 권한이 거의 없는 경우(*최소 권한*이라고도 함) 보안 사고가 발생할 가능성이 낮다고 가정합니다. 모든 프로세스를 자동화된 파이프라인으로 제한하여 프로덕션 환경의 무결성을 유지하면 콘솔 관련 보안 문제의 위험이 거의 사라집니다.