Day 5 - Week 8 종합 복습: CI/CD 파이프라인을 머릿속에서 끝까지 돌려보기

이번 주를 시작할 때만 해도 "Code* 시리즈가 다섯 개나 있다"는 게 부담이었을 텐데, 한 주를 지나고 보면 다섯 서비스가 사실은 한 흐름의 다섯 단계라는 게 보인다. CodeCommit이 코드를 받고, CodeBuild가 빌드하고, CodeDeploy가 배포하고, CodePipeline이 그 전체를 이어 붙이고, Elastic Beanstalk가 모든 걸 한 번에 추상화한다. 이 흐름을 머릿속에서 막힘없이 그릴 수 있으면 DVA-C02의 CI/CD 영역은 사실상 끝난다.

이번 글은 단순 요약이 아니다. 각 서비스를 다시 한 번 깊이 비교하고, 이번 주에 헷갈리기 쉬운 함정들을 일렬로 정리하고, 실전 시험 유형의 시나리오 문제 12개로 점검한다. 마지막 점검은 "정답을 맞히는 것"이 아니라 "왜 다른 보기는 틀렸는지를 설명할 수 있는가"의 자체 채점이다.

5개 서비스의 본질을 한 줄로

다섯 서비스가 각각 어떤 문제를 풀려고 만들어졌는지를 한 줄로 정리하면 다음과 같다.

💡 관련 이론: 이 다섯 서비스의 분리는 "Single Responsibility Principle"의 시스템 레벨 적용이다. 한 서비스가 모든 걸 하는 monolith를 만드는 대신, 각 서비스가 하나의 책임만 갖고 잘 정의된 인터페이스(IAM, S3 artifact, EventBridge)로 연결되도록 설계했다. 그래서 어느 한 서비스만 별도로 쓰는 것도 가능하다(예: CodeBuild만 쓰고 다른 CI는 Jenkins, 배포는 GitHub Actions). "Code* 시리즈는 반드시 함께 써야 한다"는 보기는 오답이다.

헷갈리기 쉬운 비교 25쌍

이번 주 학습 중 혼동하기 쉬운 개념 쌍을 모두 정리한다. 시험 직전 마지막 점검용.

이번 주의 함정 20가지

시험에서 구분해야 하는 미세한 함정을 정리한다. 하나하나가 단독 문항이 될 수 있다.

1. CodeCommit은 2024년 7월부터 신규 가입 불가 — 그러나 기존 고객은 계속 사용, 시험엔 여전히 출제.
2. HTTPS Git Credentials는 IAM 콘솔 로그인 비밀번호와 별개 — 별도 발급 필요.
3. Credential Helper는 매 git operation마다 SigV4로 새 password 생성 — EC2 인스턴스 프로파일 자동 인증.
4. CodeBuild는 매 빌드마다 fresh container — startup 10-30s, LOCAL 캐시는 호스트 재사용 시만 동작.
5. CodeBuild 환경변수 variables는 평문 — 비밀은 parameter-store(SecureString) 또는 secrets-manager.
6. CodeBuild에서 Docker 빌드 시 privileged: true 필수 — DinD 패턴.
7. CodeBuild VPC 모드는 ENI 프로비저닝으로 startup +30s — 인터넷 outbound 사라짐, 각종 endpoint 필요.
8. buildspec.yml의 post_build는 build 실패 시에도 실행 — CODEBUILD_BUILD_SUCCEEDING 변수로 분기.
9. buildspec.yml의 exported-variables가 후속 stage로 전달 — CodePipeline에서 #{BuildVariables.X}.
10. CodeDeploy EC2 배포는 Agent 필수 — Lambda/ECS는 Agent 없음.
11. ECS는 CodeDeploy로 Blue/Green만 가능 — In-Place는 ECS service의 자체 rolling.
12. EC2 ApplicationStop은 이전 revision의 스크립트가 실행 — 새 스크립트는 다음 배포 때.
13. AllAtOnce 배포는 1개 인스턴스만 성공해도 deployment success — 서비스 가용성은 별개.
14. Lambda Canary와 Linear의 결정적 차이는 "한 번에 100%로 vs 균등 증가".
15. Lambda BeforeAllowTraffic/AfterAllowTraffic 훅은 PutLifecycleEventHookExecutionStatus 호출 필수 — 안 하면 1시간 timeout.
16. CodePipeline V2의 트리거 필터는 CodeStar Source Connection만 지원 — CodeCommit은 EventBridge rule로.
17. CodePipeline artifact bucket은 파이프라인과 같은 리전 필수 — Cross-Region 시 각 리전에 별도.
18. Manual Approval은 7일 응답 없으면 자동 거부.
19. Beanstalk 환경 안에 RDS를 만들면 환경 삭제 시 함께 삭제 — production은 외부에.
20. Beanstalk Worker는 ALB가 없고 SQS Daemon이 HTTP로 변환 — application은 일반 HTTP 서버.

DVA-C02 특화 주제: 5가지 깊이 포인트

1. Lambda Firecracker와 CodeBuild Lambda compute

CodeBuild BUILD_LAMBDA compute type(2023년 말 출시)은 내부적으로 Firecracker microVM 위에서 빌드 컨테이너를 띄운다. Firecracker는 AWS가 2018년 오픈소스화한 KVM 기반 microVM 모니터로, 100ms 이내 부팅과 5MB 메모리 풋프린트를 자랑한다. Lambda와 Fargate가 내부적으로 사용하는 격리 기술이고, "초경량 VM과 컨테이너의 중간"을 노린 설계.

🔍 더 깊이: Firecracker가 일반 Docker 컨테이너와 다른 점은 하드웨어 가상화(KVM) 레벨 격리다. Docker는 리눅스 namespace + cgroup으로 격리하므로 커널을 공유하지만, Firecracker는 각 VM이 자기 커널을 갖는다. 그래서 multi-tenant 환경(여러 고객의 코드를 같은 호스트에서 실행)에서 보안 boundary가 훨씬 강하다. Lambda가 처음부터 다른 고객 함수 코드를 같은 호스트에서 돌리면서도 안전했던 비결이 여기 있다.

2. DynamoDB 파티션과 hot partition (간접적으로 시험)

CodeBuild가 결과를 DynamoDB에 저장하는 패턴, 또는 Lambda + DynamoDB의 흔한 조합에서 hot partition 문제가 시험에 나온다. DynamoDB는 partition key의 hash 값으로 데이터를 분산하는데, 모든 쓰기가 한 partition key로 몰리면 그 파티션만 throttle된다. 해결책은 ① write sharding (suffix 추가) ② Adaptive Capacity 활성화(default) ③ partition key 설계 재검토.

3. API Gateway와 SigV4

API Gateway에 IAM 인증을 설정하면 클라이언트가 모든 요청을 SigV4로 서명해야 한다. CodeBuild에서 API Gateway 호출 시 자동으로 SigV4 서명 가능(boto3/aws-sdk가 처리). "Lambda → API Gateway 호출 시 IAM 인증" 시나리오가 있다.

4. SQS at-least-once와 Beanstalk Worker

Beanstalk Worker 환경의 SQS Daemon은 SQS의 at-least-once delivery를 그대로 application에 노출한다. 즉 같은 메시지가 두 번 처리될 수 있고, application은 idempotency를 보장해야 한다. message ID나 deduplication ID를 DynamoDB에 기록해 중복 처리 방지하는 패턴이 표준.

5. X-Ray sampling과 CI/CD 파이프라인

빌드 중인 application에 X-Ray instrumentation을 추가하면 production에서 trace가 수집되는데, 모든 요청을 sampling하면 비용 폭증. X-Ray의 기본 sampling rule은 "처음 1초당 1개 요청 + 추가 5% sampling"이다. 시험에서 "X-Ray 비용 절감"이 나오면 sampling rule 조정이 답.

CI/CD 전체 흐름 한 번에 그리기

이번 주의 모든 서비스가 함께 동작하는 production-grade CI/CD를 한 번에 그리면 다음과 같다.

[개발자] git push origin feature/new-api
              │
              ▼
[CodeCommit (또는 GitHub via Code Connection)]
              │
              │ EventBridge 즉시 트리거
              ▼
[CodePipeline V2 "myapp-pipeline"]
   │
   ├── Stage 1: Source
   │     Action: CodeCommit Source (output: SourceOutput)
   │
   ├── Stage 2: Validate (병렬 실행, runOrder=1)
   │     Action A: CodeBuild "lint" (input: SourceOutput)
   │     Action B: CodeBuild "security-scan" (Snyk, Bandit)
   │     Action C: CodeBuild "unit-test" (output: TestReport)
   │
   ├── Stage 3: Build
   │     Action: CodeBuild "build"
   │             - install: nodejs 20, docker
   │             - pre_build: ECR login, IMAGE_TAG export
   │             - build: docker build & push to ECR
   │             - post_build: imagedefinitions.json
   │             (output: BuildOutput with imagedefinitions.json)
   │
   ├── Stage 4: Deploy-Staging
   │     Action: ECS CodeDeploy Blue/Green
   │             - 새 task definition으로 Green tasks 배포
   │             - ALB Test Listener로 smoke test
   │             - Production Listener swap
   │             - 5분 후 Blue tasks 종료
   │
   ├── Stage 5: Integration Test
   │     Action: CodeBuild "integration-test"
   │             - staging endpoint에 대해 Postman/Pytest
   │
   ├── Stage 6: Manual Approval
   │     Action: Manual Approval
   │             - SNS notification → Slack via Chatbot
   │             - 7일 timeout
   │
   └── Stage 7: Deploy-Production
         Action: ECS CodeDeploy Blue/Green
                 - Lambda hook BeforeAllowTraffic: contract test
                 - 10% canary 10분 → 100% (LambdaCanary10Percent10Minutes 패턴)
                 - CloudWatch Alarm 위반 시 자동 롤백

다른 클라우드의 동등 서비스 매핑

정리

CI/CD의 핵심은 "사람이 매번 수동으로 하던 release 절차를, 한 번 정의해두면 그 다음부터는 자동으로 흘러간다"는 한 가지 약속이다. 그 약속의 구체적 구현이 이번 주의 5개 서비스이고, 각 서비스는 자기 자리에서 한 가지 역할만 잘 한다.

DVA-C02 시험 직전 점검 포인트: ① 5개 서비스의 역할 1줄 매핑 ② CodeDeploy 배포 전략별 trade-off ③ Lambda 배포 9가지 사전 정의 구성 ④ Beanstalk 6가지 배포 전략 ⑤ CodePipeline V2 신기능. 이 5가지를 자기 언어로 30초 안에 설명할 수 있어야 한다.

다음 주에는 데이터 보안, IAM, KMS, Secrets Manager — DVA-C02의 또 다른 핵심 축인 보안 영역을 본다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 핀테크 회사가 모든 코드 변경에 대해 ① 보안 스캔(Snyk) ② 단위 테스트 ③ lint를 병렬로 실행하고, 세 가지 모두 통과해야 다음 단계로 진행하려 한다. CodePipeline 구성으로 옳은 것은?

• A세 작업을 각각 별도 stage에 배치하고 각 stage 사이에 자동 전환을 설정
• B한 stage에 세 액션을 두고 runOrder를 1, 2, 3으로 지정해 의존 순서를 명시
• C한 stage에 세 액션을 모두 runOrder=1로 지정
• D세 작업을 각각 별도 파이프라인으로 분리하고 EventBridge로 완료를 집계해 게이트 구성

문제 2

한 e-commerce 회사가 Lambda 기반 결제 처리 함수를 배포하려 한다. 새 버전이 잘못되면 결제 실패로 직결되므로, 처음 10분 동안 10%만 트래픽을 받은 후 자동 검증을 통해 점진적으로 100%로 가야 한다. 또한 CloudWatch Alarm ErrorRate > 1%가 발생하면 자동 롤백돼야 한다. 가장 적합한 구성은?

• ALambdaCanary10Percent10Minutes + Auto Rollback (DEPLOYMENT_STOP_ON_ALARM)
• BLambdaLinear10PercentEvery1Minute + Auto Rollback (DEPLOYMENT_FAILURE)
• CLambdaAllAtOnce + 사후 모니터링
• DLambdaCanary10Percent5Minutes + Manual Approval

문제 3

ECS Fargate 기반 마이크로서비스를 CodeDeploy로 Blue/Green 배포하려 한다. 다음 중 필수 사전 조건이 아닌 것은?

• AECS service의 deploymentController.type을 CODE_DEPLOY로 설정
• BALB Target Group 2개 (Production + Test)와 두 개의 listener(Production listener + Test listener) 구성
• Cappspec.json(또는 appspec.yaml)에 TaskDefinition과 LoadBalancerInfo, ContainerName/ContainerPort 명시
• DFargate task definition의 컨테이너에 CodeDeploy Agent sidecar를 추가하고 lifecycle hook 스크립트 마운트

문제 4

CodeBuild가 사설 서브넷의 Aurora 클러스터에 접속해 DB 마이그레이션을 실행해야 한다. 현재 빌드는 default 환경(AWS managed VPC)에서 실행 중이고 Aurora 접속이 안 된다. 가장 적합한 해결은?

• AAurora 클러스터를 public으로 변경
• BCodeBuild 프로젝트를 사용자 VPC 모드로 전환하고 적절한 subnet + security group 지정, ECR/S3/Secrets Manager용 VPC Endpoint 구성
• CCodeBuild가 호출하는 Lambda 함수를 통해 우회 접속
• DDB 마이그레이션을 EC2 bastion에서 수동 실행

문제 5

Beanstalk 환경에 새 버전을 배포하면서 다운타임 없이 가장 빠르게 롤백이 가능하고, production 인스턴스 용량이 절대 감소해서는 안 되며, 추가 비용 일시 2배를 허용한다. 가장 적합한 배포 전략은?

• ARolling
• BRolling with Additional Batch
• CImmutable
• DAll at once

문제 6

정답 4개 선택

한 SaaS 회사가 Source 계정에서 CodePipeline을 운영하고, Prod 계정의 ECS service에 배포하려 한다. 다음 중 필요한 구성을 모두 고르면?

• ASource 계정 pipeline 서비스 역할에 Prod 계정 cross-account role에 대한 sts:AssumeRole 권한
• BProd 계정에 Source 계정을 신뢰하는 CrossAccountDeployRole 생성
• CArtifact S3 bucket의 KMS CMK Key Policy에 양쪽 계정 permission
• DArtifact S3 bucket policy에 Prod 계정 read 권한
• EProd 계정 ECS service에 Agent 설치

정답 확인

문제 7

Beanstalk Worker 환경에서 SQS 메시지가 간헐적으로 두 번 처리되는 현상을 발견했다. 원인과 해결은?

• ASQS는 at-least-once delivery이므로 정상 동작이며, application에서 idempotency를 구현해야 한다
• BBeanstalk의 SQS Daemon 버그이므로 AWS Support에 문의
• CAuto Scaling Group이 너무 많이 띄워졌으므로 인스턴스 수 줄이기
• DSQS visibility timeout을 0으로 설정

문제 8

CodePipeline 파이프라인이 production 배포에 실패할 때마다 JIRA에 자동으로 incident ticket을 생성하고 싶다. 가장 적합한 구성은?

• ACodeStar Notifications → AWS Chatbot → Slack에서 사람이 JIRA 등록
• BEventBridge rule (FAILED 상태 감지) → Lambda → JIRA REST API 호출
• CCloudWatch Logs Insight에서 5분마다 실패 로그 조회 후 JIRA 등록
• DCodePipeline 콘솔에서 JIRA 통합 옵션 활성화

문제 9

CodeBuild에서 빌드 도중 동적으로 결정된 IMAGE_TAG 값을 다음 stage의 CodeDeploy 액션에 전달하려 한다. 적합한 메커니즘은?

• Abuildspec.yml의 env.exported-variables에 IMAGE_TAG 명시 → CodePipeline에서 #{BuildVariables.IMAGE_TAG} 참조
• Bbuildspec.yml의 env.variables에 정적 정의
• CDynamoDB에 저장하고 다음 stage에서 조회
• DS3에 텍스트 파일로 저장하고 다음 stage에서 다운로드

문제 10

CodeDeploy로 EC2에 In-Place 배포 중인 fleet(100대)에 CloudWatch Alarm ErrorRate > 5%가 발생했다. 자동 롤백이 동작하려면 어떤 설정 조합이 필요한가?

• ADeploymentGroup의 AlarmConfiguration에 알람 등록 + AutoRollbackConfiguration.Events에 DEPLOYMENT_STOP_ON_ALARM 포함
• BCloudWatch Alarm action에 직접 CodeDeploy stop API 등록
• CLambda 함수를 만들어 알람 시 수동 stop 호출
• DASG의 health check type을 ELB로 변경

문제 11

한 회사가 Beanstalk 환경에서 production DB로 외부 RDS를 사용 중이다. 환경 변수로 DB endpoint와 비밀번호를 주입하고 있는데, 비밀번호를 30일마다 자동 회전하면서 application도 자동으로 새 비밀번호를 받게 하려 한다. 가장 적합한 구성은?

• A.ebextensions의 option_settings에 비밀번호를 평문으로 저장하고 주기적으로 수동 업데이트
• BAWS Secrets Manager에 DB 자격증명 저장 + 자동 회전 활성화, .ebextensions에서 SSM Parameter Store reference로 endpoint만 주입하고 application 코드에서 Secrets Manager API로 비밀번호 fetch
• CS3 bucket에 비밀번호 파일을 저장하고 인스턴스가 주기적으로 다운로드
• DEC2 user data에 비밀번호 하드코딩

문제 12

CodeBuild로 빌드 중인 Java application의 단위 테스트 결과(JUnit XML)를 CodeBuild 콘솔에서 시각화해 보고 싶다. 필요한 buildspec.yml 설정은?

• Aartifacts.files에 XML 파일을 추가하고 artifacts.name으로 S3 산출물 경로를 지정
• Breports 섹션에 file-format을 JUNITXML로 지정하고 파일 경로 명시
• Ccache.paths에 XML 경로를 추가하고 cache.type을 LOCAL_CUSTOM_CACHE로 설정
• Denv.exported-variables에 JUNIT_XML을 추가하고 후속 stage에서 #{BuildVariables.JUNIT_XML}로 참조