Amazon DVA-C02: 배포 및 CI/CD (CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, 컨테이너) — 학습 가이드

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Developer Associate DVA-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

CodePipeline 및 CodeBuild를 사용한 CI/CD 기본 사항: 패턴, API 및 일반적인 함정

파이프라인을 소스, 빌드, 테스트, 승인, 배포, 배포 후 검증과 같은 명확한 단계로 설계합니다. CodePipeline은 이러한 단계를 조율합니다. 최소한의 범위로 지정된 권한을 부여하는 파이프라인 역할을 사용하고, 서드파티 통합을 위해 작업 역할을 구성합니다. CodeCommit 웹훅 또는 프로그래밍 방식의 실행을 위해 StartPipelineExecution(AWS SDK: codepipeline.startPipelineExecution)을 통해 파이프라인을 트리거합니다. 빌드의 경우, 단계(install, pre_build, build, post_build)를 정의하는 buildspec.yml을 사용하는 CodeBuild 프로젝트를 선호합니다. 애드혹 또는 배치 빌드가 필요할 때는 StartBuild 또는 StartBuildBatch로 빌드를 직접 호출합니다. 이미지 빌드의 경우, pre_build 단계에서 aws ecr get-login-password를 docker login으로 파이프하여 사용한 다음, ECR로 docker build/push하고 이미지 다이제스트를 캡처하여 불변의 아티팩트 참조를 생성합니다. “latest"와 같은 유동적인 태그 사용을 피하고, 대신 이미지 다이제스트를 참조하는 태스크 정의나 매니페스트 파일을 생성하여 배포가 결정적이 되도록 합니다. 일반적인 함정을 주의해야 합니다: 장기 실행 스크립트에서 ECR 인증 토큰 만료, ECR에 푸시하거나 AWS API를 호출하기 위한 CodeBuild IAM 정책의 부적절함, ARN 하드코딩. 빌드 아티팩트에 비밀을 포함시키는 대신, 빌드를 구성하여 아티팩트를 S3 또는 파이프라인 아티팩트 저장소에 업로드하고, 환경 변수와 Parameter Store/Secrets Manager를 사용하여 민감한 런타임 전용 값을 관리합니다.

배포 전략: CodeDeploy, Lambda 별칭 및 Elastic Beanstalk 구성 선택

리스크 허용 범위와 롤백 요구 사항에 맞는 배포 모델을 선택합니다. Lambda의 경우, 버전과 별칭을 사용합니다. 버전을 게시(lambda.publishVersion)하고, Lambda 애플리케이션 및 배포 그룹을 참조하는 배포(codedeploy.createDeployment)를 생성하여 CodeDeploy를 통해 트래픽 전환 규칙으로 별칭을 업데이트합니다. 정확한 카나리 또는 선형 전환을 위해 CodeDeployDefault.LambdaCanary10Percent5Minutes와 같은 CodeDeploy 내장 구성 또는 사용자 지정 트래픽 라우팅을 사용합니다. EC2 및 온프레미스 앱의 경우, CodeDeploy는 트래픽 전 검증을 위한 수명 주기 훅과 상태 확인 실패 시 자동 롤백 기능을 갖춘 블루/그린 배포를 지원합니다. Elastic Beanstalk는 여러 정책을 제공합니다: All at Once(빠르지만 위험), Rolling, Rolling with Additional Batch(더 안전), Immutable(가장 안전). 이러한 정책은 eb deploy 또는 DeploymentPolicy와 OptionSettings를 지정하는 update-environment API로 변경할 수 있습니다. 개발자가 흔히 빠지는 함정으로는 자동 트래픽 전환을 막는 애플리케이션 상태 확인(ALB 대상 그룹 상태, EB 상태 보고) 구성 누락, CodeDeploy가 Lambda를 호출하거나 ECS를 업데이트하기에 불충분한 IAM 권한 등이 있습니다. 데이터베이스 기반 릴리스의 경우, 코드와 스키마가 동일한 트랜잭션에 결합되는 것을 피하기 위해 하위 호환 가능한 스키마 변경과 배포 전 기능 토글을 고려합니다.

컨테이너 파이프라인, ECR, ECS/Fargate 및 EKS: 빌드, 배포 및 불변 참조

견고한 컨테이너 파이프라인은 CodeBuild에서 이미지를 빌드하고, ECR로 푸시하며, ECS, Fargate 또는 EKS로의 배포를 트리거합니다. CodeBuild에서 aws ecr get-login-password | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com을 실행한 다음, docker build -t repo:tag ., docker push를 실행하고, docker inspect --format='{{index .RepoDigests 0}}' image를 통해 이미지 다이제스트를 캡처합니다. ECS/Fargate의 경우, containerDefinitions에 이미지 다이제스트를 포함하여 새 태스크 정의를 등록(ecs.registerTaskDefinition)한 다음, 서비스를 업데이트(ecs.updateService)하여 새 태스크 정의를 사용하거나 forceNewDeployment를 설정하여 교체를 트리거합니다. ALB 수준에서 트래픽을 전환하는 ECS 블루/그린 배포에는 CodeDeploy를 사용합니다. EKS의 경우, Kubernetes 매니페스트를 업데이트하여 이미지 다이제스트를 참조하고 kubectl set image를 적용하거나 선언적 GitOps 도구를 사용합니다. CodeBuild는 aws eks update-kubeconfig 및 kubectl 명령을 실행할 수 있습니다. 일반적인 함정으로는 오래된 배포를 유발하는 가변 태그 사용, ECS가 새 이미지를 배포하지 못하게 하는 태스크 정의 버전업 실패, Fargate 태스크의 CPU/메모리 또는 ENI 제한 부족, CodeBuild에 푸시된 이미지를 읽을 수 있는 ecr:BatchGetImage 권한 부여 누락 등이 있습니다.

배포 전 검증, 롤백, 관측성: 테스트, 후크, 운영상의 안전장치

자동화된 단위, 통합, 스모크 테스트를 파이프라인 단계에 통합합니다. CodeBuild를 사용하여 테스트를 실행하고, AWS X-Ray 또는 CloudWatch Logs를 추적 및 구조화된 로그에 사용합니다. SDK에서 PutAnnotation으로 X-Ray 추적에 주석을 달아 다운스트림 쿼리가 사용자 또는 요청 속성으로 필터링할 수 있도록 합니다. 배포 전 단계에서는 CodePipeline의 수동 승인 작업이나 자동화된 검증 단계를 사용합니다. CodeBuild를 통해 배포된 엔드포인트를 실행하는 Canary 검사를 수행하거나, CloudWatch Synthetics 카나리를 호출하여 스크립트 기반 검증을 실행합니다. CodeDeploy 수명 주기 후크(BeforeAllowTraffic, AfterAllowTraffic)를 사용하여 상태 확인 및 등록/등록 취소 로직을 실행합니다. 자동 롤백 트리거를 구현합니다. 0이 아닌 배포 상태 또는 실패한 경보(배포 그룹에 연결된 CloudWatch 경보) 발생 시 롤백하도록 CodeDeploy를 구성하고, Lambda의 경우 트래픽 이동 기능이 있는 별칭을 사용하여 이전 버전을 가리키도록 별칭을 업데이트함으로써 신속한 롤백을 활성화합니다. 개발자가 빠지기 쉬운 함정으로는 시간 초과 불일치(Lambda 시간 초과가 SQS 가시성 시간 초과보다 짧음), ECS/CodeDeploy에 대한 AppSpec 후크를 올바르게 설정하는 것을 잊는 것, 런타임 동작을 검증하지 않고 배포 API 호출 성공에만 의존하는 것 등이 있습니다. 배포에 지표와 경보를 설정하고, 추적성을 위해 아티팩트에 불변 식별자를 사용합니다.

실제 문제: 사용 사례 시나리오

시나리오: ExampleRetail은 dev/test/prod 계정에 걸쳐 AWS에서 마이크로서비스 기반 스토어프런트를 운영합니다. 소스 관리에 CodeCommit, CI에 CodePipeline/CodeBuild, 이미지에 ECR, ALB 뒤의 서비스에 ECS/Fargate, 비동기 워커에 Lambda를 사용합니다.

과제: 개발자는 실패 시 롤백되는 자동화된 배포 전 검증과 카나리 트래픽 이동 기능을 갖춘 안전하고 자동화된 파이프라인을 추가하여 새로운 결제 서비스 컨테이너를 배포해야 합니다.

권장 접근 방식:

1. Docker 이미지를 빌드하고, 단위 테스트를 실행하고, ECR에 로그인(aws ecr get-login-password | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com)하고, 이미지를 푸시한 다음, 이미지 다이제스트를 포함하는 JSON 아티팩트를 내보내는 CodeBuild 프로젝트를 생성합니다.
2. CodePipeline에서, 이미지 다이제스트를 참조하는 ecs.registerTaskDefinition을 통해 새로운 ECS 작업 정의를 등록하는 배포 단계를 추가합니다. 그런 다음, 새로운 작업 정의와 카나리용으로 설정된 deploymentConfig(예: CodeDeployDefault.ECSCanary10Percent5Minutes)를 바인딩하는 AppSpec을 사용하여 codedeploy.createDeployment를 호출함으로써 CodeDeploy ECS 배포를 생성합니다.
3. 중요한 결제 엔드포인트를 호출하고 응답을 검증하는 배포 후 테스트로 CodeBuild 기반 검증 작업 또는 CloudWatch Synthetics 카나리를 추가합니다. 파이프라인이 성공적인 검증을 기다리도록 만듭니다.
4. 임계값을 초과하면 자동으로 중단하고 롤백하도록 CodeDeploy 롤백 옵션과 배포 그룹에 연결된 CloudWatch 경보(예: 5xx 오류율 또는 지연 시간)를 구성합니다.

근거: 불변 이미지를 빌드하고, 명시적인 이미지 다이제스트로 작업 정의를 등록하고, CodeDeploy의 트래픽 이동 기능과 자동화된 검증을 사용하면 안전한 카나리 릴리스와 빠르고 자동화된 롤백을 제공하는 동시에 배포의 재현성과 관측성을 보장할 수 있습니다.

← CloudFormation 및 코드형 인프라 (SAM · 모든 도메인 · 보안 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →