기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# CI/CD 이해
지속적 통합 및 지속적 전송(CI/CD)은 소프트웨어 릴리스 수명 주기를 자동화하는 프로세스입니다. 경우에 따라 CI/CD의 *D*는 *배포*를 의미할 수도 있습니다. *지속적 전송*과 *지속적 배포*의 차이는 프로덕션 환경에 대한 변경 사항을 릴리스할 때 나타납니다. 지속적 전송에서는 변경 사항을 프로덕션으로 승격하기 전에 수동 승인이 필요합니다. 지속적 배포에서는 전체 파이프라인을 통해 중단 없는 흐름을 제공하며 명시적 승인이 필요하지 않습니다. 이 전략은 일반적인 CI/CD 개념을 설명하므로 제공된 권장 사항 및 정보는 지속적 전송 및 지속적 배포 접근 방식 모두에 적용됩니다.
CI/CD는 기존에 커밋에서 프로덕션으로 새 코드를 가져오는 데 필요한 수동 프로세스의 대부분 또는 전부를 자동화합니다. CI/CD 파이프라인에는 소스, 빌드, 테스트, 스테이징 및 프로덕션 단계가 포함됩니다. 각 단계에서 CI/CD 파이프라인은 코드를 배포하거나 테스트하는 데 필요한 모든 인프라를 프로비저닝합니다. 개발 팀은 CI/CD 파이프라인을 통해 코드를 변경하여 자동으로 테스트하고 배포로 푸시할 수 있습니다.
고의로 또는 무의식적으로 완전한 CI/CD에서 벗어나는 몇 가지 경우를 논의하기 전에 기본 CI/CD 프로세스부터 검토합니다. 다음 다이어그램에서는 각 단계의 CI/CD 단계 및 활동을 보여줍니다.
![\[CI/CD 프로세스의 5단계와 각 프로세스의 활동 및 환경.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## 지속적 통합에 대한 정보
지속적 통합은 GitHub의 Git 리포지토리와 같은 코드 리포지토리에서 수행됩니다. 단일 기본 브랜치를 코드베이스의 신뢰할 수 있는 소스로 처리하고 기능 개발을 위한 수명이 짧은 브랜치를 생성합니다. 상위 환경에 기능을 배포할 준비가 되면 기능 브랜치를 기본 브랜치에 통합합니다. 기능 브랜치는 상위 환경에 직접 배포되지 않습니다. 자세한 내용은 이 안내서의 [트렁크 기반 접근 방식](fully-cicd-process-differences.md#trunk-based-approach) 섹션을 참조하세요.
*지속적 통합 프로세스*
1. 개발자는 기본 브랜치에서 새 브랜치를 생성합니다.
1. 개발자는 변경을 수행하고 로컬에서 이를 빌드하고 테스트합니다.
1. 변경 사항이 준비되면 개발자는 기본 브랜치를 대상으로 하는 [풀 요청](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)(GitHub 설명서)을 생성합니다.
1. 코드가 검토됩니다.
1. 코드가 승인되면 기본 브랜치에 병합됩니다.
## 지속적 전송에 대한 정보
지속적 전송은 개발 환경 및 프로덕션 환경과 같은 격리된 환경에서 수행됩니다. 각 환경에서 수행되는 작업은 다를 수 있습니다. 진행하기 전에 파이프라인 자체를 업데이트하는 데 첫 번째 단계 중 하나가 사용되는 경우도 있습니다. 배포의 최종 결과는 각 환경이 최신 변경 사항으로 업데이트되는 것입니다. 빌드 및 테스트를 위한 개발 환경의 수도 다르지만 최소 2개를 사용하는 것이 좋습니다. 파이프라인에서 각 환경은 중요도에 따라 순서대로 업데이트되며 가장 중요한 환경인 프로덕션 환경이 마지막입니다.
*지속적 전송 프로세스*
파이프라인의 지속적 전송 부분은 소스 리포지토리의 기본 브랜치에서 코드를 가져와 빌드 단계로 전달하여 시작됩니다. 리포지토리의 코드형 인프라(IaC) 문서에는 각 단계에서 수행되는 작업이 요약되어 있습니다. IaC 문서를 반드시 사용해야 하는 것은 아니지만 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 또는 [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)와 같은 IaC 서비스 또는 도구를 사용하는 것이 좋습니다. 가장 일반적인 단계는 다음과 같습니다.
1. 유닛 테스트
1. 코드 빌드
1. 리소스 프로비저닝
1. 통합 테스트
파이프라인의 어느 단계에서든 오류가 발생하거나 테스트가 실패하면 현재 단계가 이전 상태로 롤백되고 파이프라인이 종료됩니다. 후속 변경 사항은 코드 리포지토리에서 시작하고 완전한 CI/CD 프로세스를 거쳐야 합니다.
# CI/CD 파이프라인 테스트
배포 파이프라인에서 일반적으로 참조되는 두 가지 유형의 자동 테스트는 *유닛 테스트*와 *통합 테스트*입니다. 그러나 코드베이스와 개발 환경에서 실행할 수 있는 다양한 유형의 테스트가 있습니다. [AWS 배포 파이프라인 참조 아키텍처](https://pipelines.devops.aws.dev/application-pipeline/)에서는 다음과 같은 유형의 테스트를 정의합니다.
+ **유닛 테스트** - 이러한 테스트는 애플리케이션 코드를 빌드하고 실행하여 예상대로 실행되고 있는지 확인합니다. 코드베이스에 사용되는 모든 외부 종속성을 시뮬레이션합니다. 유닛 테스트 도구의 예로, [JUnit](https://junit.org/), [Jest](https://jestjs.io/), [pytest](https://pytest.org/)가 있습니다.
+ **통합 테스트** - 이러한 테스트는 프로비저닝된 테스트 환경을 테스트하여 애플리케이션이 기술 요구 사항을 충족하는지 확인합니다. 통합 테스트 도구의 예로, [Cucumber](https://cucumber.io/), [vRest NG](https://vrest.io/), [integ-tests](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html)(AWS CDK용)가 있습니다.
+ **승인 테스트** - 이러한 테스트는 프로비저닝된 테스트 환경을 테스트하여 애플리케이션이 사용자 요구 사항을 충족하는지 확인합니다. 승인 테스트 도구의 예로, [Cypress](https://cypress.io/) 및 [Selenium](https://selenium.dev/)이 있습니다.
+ **가상 테스트** - 이러한 테스트는 백그라운드에서 지속적으로 실행되어 트래픽을 생성하고 시스템이 정상인지 확인합니다. 가상 테스트 도구의 예로, [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 및 [Dynatrace Synthetic Monitoring](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/)이 있습니다.
+ **성능 테스트** - 이러한 테스트는 프로덕션 용량을 시뮬레이션합니다. 애플리케이션이 성능 요구 사항을 충족하는지 확인하고 지표를 과거 성능과 비교합니다. 성능 테스트 도구의 예로, [Apache JMeter](https://jmeter.apache.org/), [Locust](https://locust.io/), [Gatling](https://gatling.io/)이 있습니다.
+ **복원력 테스트** - *카오스 테스트*라고도 하는 이러한 테스트는 위험 영역을 식별하기 위해 환경에 장애를 주입합니다. 그리고 장애가 주입되는 기간을 장애가 없는 기간과 비교합니다. 복원력 테스트 도구의 예로, [AWS Fault Injection Service](https://aws.amazon.com/fis/) 및 [Gremlin](https://www.gremlin.com/)이 있습니다.
+ **정적 애플리케이션 보안 테스트(SAST)** - 이러한 테스트는 [SQL 인젝션](https://owasp.org/www-community/attacks/SQL_Injection) 또는 [크로스 사이트 스크립팅(XSS)](https://owasp.org/www-community/attacks/xss/)과 같은 보안 위반에 대한 코드를 분석합니다. SAST 도구의 예로, [Amazon CodeGuru](https://aws.amazon.com/codeguru/), [SonarQube](https://www.sonarqube.org/), [Checkmarx](https://checkmarx.com/)가 있습니다.
+ **동적 애플리케이션 보안 테스트(DAST)** - 이러한 테스트를 *침투 테스트* 또는 *펜 테스트*라고도 합니다. 프로비저닝된 테스트 환경에서 SQL 인젝션 또는 XSS와 같은 취약성을 식별합니다. DAST 도구의 예로, [ZAP(Zed Attack Proxy)](https://www.zaproxy.org/) 및 [HCL AppScan](https://www.hcltechsw.com/appscan)이 있습니다. 자세한 내용은 [Penetration Testing](https://aws.amazon.com/security/penetration-testing/)을 참조하세요.
모든 완전한 CI/CD 파이프라인이 이러한 테스트를 모두 실행하는 것은 아닙니다. 그러나 최소한 파이프라인은 코드베이스에서 유닛 테스트 및 SAST 테스트를 실행하고 테스트 환경에서 통합 및 승인 테스트를 실행해야 합니다.
# CI/CD 파이프라인에 대한 지표
[AWS 배포 파이프라인 참조 아키텍처](https://pipelines.devops.aws.dev/application-pipeline/)에 따라 최소한 CI/CD 파이프라인에 대한 다음 4가지 지표를 추적해야 합니다.
+ **리드 타임** - 단일 커밋이 프로덕션에 들어가는 데 걸리는 평균 시간. 사용 사례에 따라 리드 타임을 1시간에서 1일 사이로 지정하는 것이 좋습니다.
+ **배포 빈도** - 지정된 기간 내 프로덕션 배포 수. 사용 사례에 따라 매일 여러 번에서 매주 두 번 사이로 배포 빈도를 지정하는 것이 좋습니다.
+ **평균 장애 간격(MTBF)** - 성공한 파이프라인의 시작과 실패한 파이프라인의 시작 사이의 평균 시간. 가능한 한 높은 MTBF를 목표로 지정하는 것이 좋습니다. 자세한 내용은 [Increasing MTBF](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html)를 참조하세요.
+ **평균 복구 시간(MTTR)** - 실패한 파이프라인의 시작과 다음에 성공한 파이프라인의 시작 사이의 평균 시간. 가능한 한 낮은 MTTR을 목표로 지정하는 것이 좋습니다. 자세한 내용은 [Reducing MTTR](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)을 참조하세요.
이러한 지표는 팀이 완전한 CI/CD가 되기 위한 진행 상황을 추적하는 데 도움이 됩니다. 팀은 조직의 이해관계자와 최적의 목표가 무엇인지 공개적으로 논의해야 합니다. 상황과 요구 사항은 조직마다, 심지어 팀마다 크게 다릅니다.
빠르고 급격한 변경은 일반적으로 문제를 일으킬 위험을 높인다는 점을 명심하는 것이 매우 중요합니다. 소규모의 점진적 개선을 진행하도록 목표를 설정합니다. 완전한 CI/CD 파이프라인의 일반적인 최적의 리드 타임은 3시간 미만입니다. 리드 타임 5.2일로 시작하는 팀은 몇 주에 한 번씩 하루를 줄이는 것을 목표로 해야 합니다. 이 팀이 하루 이하의 리드 타임에 도달한 후에는 팀 및 조직 이해관계자가 필요하다고 간주하는 경우에만 몇 개월 동안 그곳에 머물고 더 적극적인 리드 타임으로 이동할 수 있습니다.