기준: DOP-C02 시험 가이드오류 제보
이번 주를 한 문장으로 정리하면 "서버리스 워크로드의 CI/CD는 IaC 도구 선택부터 배포 전략, 워크플로 오케스트레이션까지 한 묶음으로 봐야 한다"이다. 어제까지 본 SAM(Day 1), Serverless Framework·CDK(Day 2), Lambda Version·Alias·CodeDeploy Canary(Day 3), Step Functions(Day 4)는 모두 같은 그림의 다른 면이다. 시험에 나오는 시나리오 문제는 거의 항상 두세 개 도구를 결합한 형태로 출제되므로, 각 도구가 어디서 빛나고 어디서 약한지를 정확히 매칭하는 능력이 합격을 가른다.
오늘은 이번 주 다섯 가지 핵심 축을 다시 정리하고, 실제 시험 패턴과 유사한 시나리오 12문항으로 종합 점검한다. 단순 사실 암기를 넘어 "이 시나리오의 어느 키워드가 어느 답을 호출하는지"의 매핑을 외워두는 게 목표다.
| 시나리오 키워드 | 적합한 도구 | 이유 |
|---|---|---|
| "Lambda + API Gateway + Dynamo만, YAML" | SAM | CFN Macro로 서버리스 6종 최적화, 학습 곡선 낮음 |
| "Lambda 200개, 멀티 stage, 풍부한 플러그인" | Serverless Framework | Node 플러그인 생태계 (단 v4 라이선스 검토) |
| "Lambda + EKS + RDS + OpenSearch + TS 팀" | CDK | 모든 AWS 리소스 L2 추상화 + grant 메서드 + L3 사내 라이브러리 |
| "멀티 클라우드 (AWS+GCP+Azure)" | Terraform | Provider 모델로 클라우드 무관 |
| "CFN 거버넌스(StackSets, Drift) 그대로 + 서버리스 단순화" | SAM | CFN의 모든 기능 호환 |
| "사내 9000 스택 + 표준 패턴 라이브러리 필요" | CDK | L3 Construct로 재사용 가능 추상화 |
핵심 명제: Version은 불변 스냅샷, Alias는 가변 포인터. Git commit/branch, Docker image digest/tag와 같은 발상.
publish-version → V7 (불변, 영구히 변하지 않음)
update-alias --function-version 7 → live가 V7 가리킴
| 기능 | 동작 |
|---|---|
$LATEST | 가변 working copy, weighted routing 불가, PC 불가 |
| Version 숫자 | 불변, 자원 정책과 PC만 변경 가능 |
| Alias weighted | primary + 1 additional만 (최대 2-way) |
| API Gateway 통합 | ${stageVariables.alias} + add-permission --qualifier <alias> |
| CodeDeploy Canary | AutoPublishAlias + DeploymentPreference 한 줄 |
| 기법 | 적용 런타임 | 비용 | 효과 |
|---|---|---|---|
| Provisioned Concurrency | 모든 런타임 | 활성 시간 과금 | Cold start 0 (PC 용량 내) |
| SnapStart | Java 11/17/21, Python 3.12+, .NET 8+ (zip만) | Java 무료, Py/.NET 유료 | Init 시간 90% 단축 |
| Reserved Concurrency | 모든 | 무료 | 동시 한도 (cold start와 무관) |
| ARM 아키텍처 | 호환 런타임 | 20% 저렴 | Init 10~20% 빠름 |
| 항목 | Standard | Express |
|---|---|---|
| 시간 | 1년 | 5분 |
| 보장 | Exactly-once | At-least-once |
| 동기 호출 | 불가 | 가능 (StartSyncExecution) |
| TaskToken | ✅ | ❌ |
| 가격 | 상태 전이당 | 호출 + 실행 시간 |
| 사용 | 배포 워크플로, 사람 승인 | API 백엔드, IoT, ETL |
┌─ Source (Git) ──→ CodePipeline ──→ CodeBuild (sam build) ──→ CFN Deploy ──┐
│ ↓
│ Lambda 새 Version V7 게시
│ ↓
│ CodeDeploy: Alias 'live' weighted (V6:90, V7:10)
│ ↓
│ 5분 대기 + CloudWatch Alarm 모니터
│ ↓
│ ┌─ Alarm OK → V7:100
│ └─ Alarm → V6:100 (롤백)
│
└─ 복잡한 흐름 → Step Functions로 위임
├─ AWS SDK Service Integration (Lambda 없이 직접 호출)
├─ TaskToken (사람 승인, 외부 시스템)
└─ Distributed Map (대용량 병렬)
| A | B | 가르는 키워드 |
|---|---|---|
| SAM | CDK | YAML 서버리스 특화 vs 코드 범용·모든 AWS |
| SAM | Serverless Framework | AWS 네이티브·OSS vs 멀티 클라우드·v4 상업 |
| Standard SFn | Express SFn | 1년·exactly-once vs 5분·at-least-once |
| Provisioned Concurrency | Reserved Concurrency | 워밍업·유료 vs 한도·무료 |
| Lambda zip | Container Image | 250MB·Layer 가능 vs 10GB·Layer 불가·SnapStart 불가 |
$LATEST | Version 숫자 | 가변·PC 불가 vs 불변·PC 가능 |
| Alias weighted | Version 100% | Canary 두 단계 vs All-at-once |
| Inline Map | Distributed Map | 40 동시·부모 history 영향 vs 1만 동시·child execution |
.sync integration | .waitForTaskToken | 자동 완료 대기 vs 외부 콜백 대기 |
| sam deploy | sam sync | CFN 표준 경로 vs 개발 가속·drift 위험 |
이 표의 모든 비교는 트레이드오프 모델의 전형이다. CAP 정리(2000년 Eric Brewer), PACELC(2010년 Daniel Abadi), Conway의 법칙(1968) 같은 시스템 디자인 원칙이 IaC와 워크플로 도구에도 동일하게 적용된다. 예를 들어 Standard SFn의 exactly-once는 가용성/성능을 일부 희생한 일관성 보장이고, Express의 at-least-once는 반대의 트레이드. 시험 시나리오는 거의 항상 "어느 trade가 더 중요한가"를 묻는다.
🎯 시나리오: 이번 주 도구 5개의 결합으로 다음 그림을 그리는 문제가 시험에 나올 수 있다 — "CDK로 Lambda+DynamoDB+API Gateway 합성 → CodePipeline Source/Build → SAM Canary로 배포 → 30분 모니터링 → Step Functions로 멀티 리전 순차 배포 + 사람 승인". 이 흐름의 각 단계에서 어느 서비스가 책임지는지 묻는 문제가 출제될 수 있다.
2023년 AWS Summit Seoul에서 한 핀테크 회사가 발표한 사례 — Lambda 1500개를 CDK + SAM 혼합으로 운영. 단순 서버리스(API+Lambda+Dynamo)는 SAM, 복잡 인프라(Lambda+EKS+OpenSearch+Step Functions)는 CDK, 배포 워크플로는 CodePipeline + Step Functions로 분리. 각 도구의 강점을 정확히 매칭한 결과 배포 시간 70% 단축. 시험에서 "여러 도구를 어떻게 조합?"의 답은 "각 도구의 강점에 맞춰 분리" — 한 도구로 모든 걸 하려는 건 안티패턴.
⚠️ 함정 1:
add-permission --qualifier를 빠뜨려 API Gateway가 Alias 호출 시 403. Function ARN 권한은$LATEST만 허용.
⚠️ 함정 2: SnapStart로 모든 호출에서 같은 UUID/random 생성.
org.crac.Resource의afterRestoreHook에서 재초기화 필수.
함정 3: SAM Policy Template은 광범위(GSI/LSI 포함). PCI/HIPAA에선
Statement직접 작성으로 정확한 ARN 제한.
함정 4:
sam sync --watch는 CFN 우회 → drift 발생. 프로덕션에서 다음 정규 deploy가 변경 덮어씀.
함정 5: PC는
$LATEST에 설정 불가, Alias/Version에만. Canary 중 두 Version 모두 PC라 비용 2배 일시 상승.
함정 6: Container Image Lambda는 Layer 불가, SnapStart 불가. 모든 의존성을 Dockerfile에 포함.
함정 7: Alias weighted routing은 primary + 1 additional만. 3-way는 ALB target group이나 Route 53 weighted 필요.
함정 8: Step Functions Express는 TaskToken 미지원. 사람 승인 워크플로는 반드시 Standard.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
한 SaaS 팀이 Lambda 200개를 Serverless Framework v3로 운영 중인데, v4 상업 라이선스 적용으로 연간 비용이 부담된다. 가장 합리적인 마이그레이션 경로는?
문제 2
Java Spring Boot Lambda(메모리 1GB, 패키지 80MB, init 8초)의 P99 latency를 1초 미만으로 만들고 싶다. 비용도 최소화. 가장 효과적인 조합은?
문제 3
S3 데이터 레이크에서 매일 5000만 JSON 객체(평균 50KB)를 변환·집계해야 한다. 1% 실패 허용, 운영 부담 최소화. 가장 적합한 패턴은?
문제 4
API Gateway REST API가 Lambda Alias live를 가리키는데, 코드 변경마다 API 재배포가 발생해 운영이 번거롭다. 가장 깔끔한 구성은?
문제 5
한 팀이 sam local invoke로 모든 통합 테스트를 통과한 후 production에 배포했다. Lambda가 즉시 throttle되고 API Gateway가 30초 timeout으로 5xx를 반환. 가장 가능성 높은 원인은?
문제 6
Lambda zip 패키지에 ML 모델(2.5GB)을 포함해야 한다. zip 한도 초과. 가장 적합한 패키징 방식은?
문제 7
CodePipeline에서 us-east-1 → eu-west-1 → ap-northeast-2 순차 배포 중 EUW1 단계에서 알람 발동 시 USE1과 EUW1을 역순 롤백해야 한다. 가장 적합한 구성은?
문제 8
프로덕션 배포 시 보안팀 → DevOps 팀 → 자동 배포 3단계 승인, 각 단계 7일 안에 응답 없으면 자동 취소, 통보는 Slack interactive message. 가장 적합한 워크플로 엔진과 패턴은?
문제 9
한 팀이 sam sync --watch를 production 환경에 사용 중. 며칠 후 다음 정규 sam deploy가 hotswap 변경을 모두 덮어썼다. 가장 정확한 원인 설명은?
문제 10
한 회사가 1500개 Lambda 함수를 CDK로 관리 중. 각 팀이 비슷한 함수 패턴(Lambda + DynamoDB + API Gateway + IAM grant + X-Ray + Powertools)을 반복 작성하고 있다. 운영 표준화와 재사용성을 어떻게 확보?
문제 11
CDK Pipelines에 selfMutation: true를 켜고 production 운영 중. 어느 날 잘못된 파이프라인 정의를 push해 self-mutation이 깨진 파이프라인을 deploy. 다음 실행이 깨진 파이프라인으로 시작되어 정상 복구 불가. 가장 적절한 예방·복구 전략은?
문제 12
한 결제 회사가 결제 처리 워크플로를 다음과 같이 설계한다 — 검증(50ms) → 인증(100ms) → 차지(150ms) → 기록(50ms). API Gateway 동기 응답 필요, 초당 500회 호출. 가장 적합한 워크플로 엔진과 호출 패턴은?
이번 주에 익힌 다섯 가지 축의 핵심을 마지막으로 다시 정리한다.
IaC 도구 선택은 워크로드 성격과 팀 언어가 결정한다. AWS-only 서버리스는 SAM, 다양한 AWS 자원은 CDK, 멀티 클라우드는 Terraform. Serverless Framework는 v4 라이선스 검토 필수.
Lambda Version은 불변 스냅샷, Alias는 가변 포인터. Git commit/branch와 같은 발상. Weighted routing은 primary + 1 additional만 가능 — CodeDeploy Canary가 "한 번에 한 단계"인 구조적 이유.
Cold Start 완화의 두 표준 — Provisioned Concurrency(워밍업·유료) vs SnapStart(Java/Python/.NET zip만·init 시간 90% 단축). Reserved Concurrency는 한도 설정이지 cold start와 무관.
Step Functions는 호출 빈도×실행 시간으로 Standard/Express 선택. AWS SDK Service Integration으로 200+ 서비스 Lambda 없이 호출. TaskToken으로 사람·외부 시스템 통합. Distributed Map으로 1만 동시 자식 워크플로.
통합 흐름은 CodePipeline + CodeBuild + CFN/SAM Deploy + CodeDeploy Canary + Step Functions의 결합. 각 서비스의 강점에 맞춰 분리하는 게 표준 패턴. 한 도구로 모든 걸 하려는 건 안티패턴.
IaC 심화 - CloudFormation/CDK/Terraform 깊이
이번 주가 "어떤 도구를 쓸 것인가"였다면, 다음 주는 "그 도구를 어떻게 깊이 운영할 것인가"가 주제다. StackSets로 100개 계정에 정책을 일괄 적용하고, Drift Detection으로 수동 변경을 잡고, Custom Resource로 CFN이 모르는 자원을 통합하는 — 엔터프라이즈 IaC의 본격적 영역이 펼쳐진다.