Week 7은 "어떻게 안전하게 배포할 것인가"를 다섯 면에서 봤다. Beanstalk이라는 PaaS의 트레이드오프, CodeDeploy의 코드만 배포라는 좁은 책임, EC2 Image Builder가 강제하는 immutable infrastructure, OpsWorks → SSM으로 옮겨가는 패러다임 전환, 그리고 Launch Template + Mixed Instances Policy의 비용·가용성 균형. 다섯 글이 모두 다른 도구를 다뤘지만 공통 질문은 하나다 — "이 워크로드에 어떤 trade-off가 맞는가".
이 글에서는 그 다섯 글의 핵심 결정 축을 다시 모으고, SOA-C02 시험이 실제로 어떤 시나리오로 출제하는지 12개의 문제로 풀어본다. 표 암기가 아니라 "왜 A가 정답이고 B는 함정인가"를 결정하는 감각이 목표다. 시험 전날 한 번 더 훑어보면 답이 자연스럽게 떠오르는 정리가 되도록 구성했다.
이 5개 축으로 시나리오를 분해하면 정답이 거의 자동으로 좁혀진다. 예를 들어 "다운타임 0초 + 비용 최소 + 기존 EC2 인프라"라는 시나리오는 CodeDeploy + Blue/Green인지 Beanstalk + Rolling with batch인지 헷갈리지만, "기존 인프라"라는 단서가 CodeDeploy를 가리킨다.
💡 관련 이론: 이 결정 축 접근은 Architecture Decision Record(ADR)의 표준 양식과 정확히 같다. Michael Nygard가 2011년 제안한 ADR 템플릿은 Context → Decision → Consequences 구조인데, 각 결정에 대한 trade-off를 명시한다. 시험 시나리오를 ADR처럼 분해하는 습관이 클라우드 아키텍트의 핵심 사고 패턴이다.
실무에서는 셋을 조합해 쓴다. CloudFormation으로 VPC·ALB·ASG 기반 인프라를 만들고, CodeDeploy로 그 위에 코드를 배포하고, Beanstalk은 "인프라까지 묶고 싶은" 작은 워크로드에만 쓴다. Image Builder는 ASG가 사용할 AMI를 만든다.
핵심 함정 — "Blue/Green = 즉시 100% 전환"이 아니다. CNAME 전환은 즉시지만 DNS TTL 동안 일부 사용자는 구 환경에 머문다. Beanstalk 기본 CNAME TTL이 60초지만 일부 ISP/사내 DNS가 더 길게 캐싱하므로 실제 100% 전환까지 5-30분 걸릴 수 있다.
[Image Builder Pipeline] (매월 cron)
↓
새 AMI 생성
↓ (EventBridge)
[Lambda] → SSM Parameter 업데이트
/golden-ami/al2/latest = ami-XXXX
↓
[Launch Template]
ImageId: '{{resolve:ssm:/golden-ami/al2/latest}}'
↓
[Auto Scaling Group]
다음 Instance Refresh 또는 scale-out 시 새 AMI 사용
이 패턴의 우아함은 참조의 간접화다. Launch Template이 AMI ID를 직접 가리키지 않고 SSM Parameter를 거쳐 가리키면, AMI가 바뀔 때마다 Launch Template 새 버전을 만들 필요가 없다. SSM Parameter만 업데이트하면 다음 인스턴스 생성 시 자동으로 새 AMI가 사용된다.
💡 관련 이론: Proton은 Spotify의 Backstage가 정의한 "Internal Developer Platform(IDP)" 카테고리의 AWS 네이티브 구현이다. CNCF Platform Working Group의 reference architecture와 거의 동일 — Platform Engineer가 golden path를 제공하고, Developer는 그 path 안에서 자가 서비스로 일한다.
운영 환경에서 다운타임 없이, 용량을 유지하면서, 추가 비용을 최소화하려 한다. 가장 적합한 Beanstalk 배포 정책은?
문제 2
새 Lambda 버전을 10% 트래픽으로 5분간 검증 후 100%로 전환하려 한다. 운영팀이 자동 검증/롤백까지 원한다면?
문제 3
AppSpec.yml의 hook 중 새 버전 파일이 destination 디렉터리에 복사된 직후, 권한 설정·심볼릭 링크 생성·환경별 config 파일 치환을 수행할 단계는?
문제 4
회사가 매월 새 Golden AMI를 빌드해 신규 ASG 인스턴스가 별도 작업 없이 자동 사용하길 원한다. AWS 권장 표준 패턴은?
문제 5
Beanstalk 환경 종료 시 내장 RDS도 함께 삭제되어 데이터 손실이 발생했다. 동일 사고를 방지하려면?
문제 6
Auto Scaling Group에서 On-demand 2대 최소 보장 + 그 위로는 30% On-demand + 70% Spot으로 비용 절감을 자동화하려 한다. 또 Spot 회수율을 최소화하고 싶다.
문제 7
CodeDeploy 배포 중 CloudWatch HighErrorRate Alarm이 발생하면 자동으로 이전 버전으로 롤백되도록 구성하려 한다. 어떻게 설정하는가?
문제 8
Spot 인스턴스가 회수되기 2분 전 graceful shutdown(ALB Target Group deregister, 진행 중 요청 완료, 로그 백업)을 자동화하려 한다. 가장 표준적인 패턴은?
문제 9
OpsWorks Stacks가 2024.5.26 EOL이다. 기존 Chef cookbook 자산을 AWS에서 계속 활용하면서 추가 인프라 운영 부담을 줄이려면?
문제 10
회사가 사내 Platform Engineering 팀을 만들어 개발자에게 Git push만으로 표준 Fargate Service + ALB + RDS + CodePipeline이 자동 프로비저닝되는 IDP를 구축하려 한다. 가장 적합한 AWS 네이티브 도구는?
문제 11
기존 ASG에 새 Launch Template 버전(새 Golden AMI 참조)을 적용했다. 운영 중인 모든 인스턴스를 안전하게 점진 교체하면서, 중간에 CloudWatch Alarm이 울리면 자동 롤백되도록 하려 한다.
문제 12
ASG의 scale-out 시 콜드 스타트(AMI fetch + cloud-init + 앱 시작)가 3-5분 걸려 트래픽 spike에 늦게 대응한다. 비용을 크게 늘리지 않으면서 부팅 시간을 30-60초로 단축하려면? 또 평일 09:00 같은 일정한 패턴이 있다면 추가로 적용할 정책은?
Week 7은 표면적으로 다섯 가지 다른 도구(Beanstalk, CodeDeploy, Image Builder, OpsWorks/SSM, Launch Template/ASG)를 다뤘지만, 핵심 질문은 다섯 개 결정 축으로 수렴했다. 다운타임 허용도, 임시 용량 비용, 롤백 속도, 인프라 소유 모델, 변경 단위 — 시험 시나리오는 이 다섯 축 위에서 trade-off를 묻는다. 도구 이름과 hook 순서를 외우는 것보다 "이 시나리오에서 어떤 축이 결정적인가"를 빠르게 판단하는 감각이 시험과 실무 모두에서 강력하다.
다음 주(Week 8)는 네트워킹 운영으로 옮겨간다. VPC 트러블슈팅, Flow Logs, VPC Endpoints, Transit Gateway까지 — CloudOps 시험 도메인의 18%를 차지하는 핵심 영역이다. 배포 자동화가 "어떻게 안전하게 코드를 올리나"였다면, 네트워킹은 "어떻게 안전하게 트래픽을 흐르게 하나"의 영역이다.