Amazon SAP-C02: 배포, 자동화 및 DevOps — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Infrastructure as Code 및 환경 관리

IaC(Infrastructure as Code)를 환경의 단일 진실 공급원(single source of truth)으로 취급하고, 네트워크, IAM, 애플리케이션 토폴로지를 재사용 가능하고 버전 관리되는 아티팩트에 내장하십시오. 엄격하고 선언적인 제어와 깊은 AWS 통합을 위해서는 CloudFormation을 선택하고, 상위 수준의 구성(construct)과 언어 네이티브 추상화가 개발자 생산성을 향상시킬 때는 AWS Cloud Development Kit(CDK)를 사용하십시오. 항상 CI가 CDK를 템플릿으로 합성(synthesize)하고 아티팩트를 암호화되고 버전 관리되는 S3 버킷에 저장하도록 강제하십시오. 일관된 교차 계정, 교차 리전 스택 인스턴스화를 위해 CloudFormation StackSets를 사용하고, 드리프트가 구성 엔트로피를 나타낼 때 Systems Manager를 통한 자동 복구와 결합된 드리프트 탐지(drift detection)를 활성화하십시오. EC2 Image Builder 또는 Packer로 골든 이미지를 만들고(bake) 자동화된 파이프라인을 통해 계정 및 리전에 AMI를 게시하십시오. 이는 불변(immutable) 배포를 지원하고 시작 후 구성 드리프트를 줄여줍니다. 데이터 손실을 유발할 수 있는 의도치 않은 리소스 교체를 피하기 위해 CloudFormation 변경 세트(change sets), 종료 보호(termination protection), 업데이트 정책을 신중하게 사용하십시오. 일반적인 함정으로는 템플릿에 보안 암호를 포함하는 것, 드리프트 탐지를 깨뜨리는 안일한 수동 변경에 의존하는 것, 또는 지나치게 광범위한 CloudFormation 실행 역할을 부여하는 것 등이 있습니다. 실행 역할은 최소 권한으로 제한하고 감사 가능성을 위해 CloudTrail 및 Config 기록을 보존하십시오. 장단점은 명확합니다. CDK는 개발을 가속화하지만 동기화되지 않은 런타임 스택을 피하기 위해 잘 통제된 CI/CD가 필요합니다. 순수 CloudFormation은 더 경직되어 있지만 즉시 감사가 가능합니다.

CI/CD 파이프라인 및 배포 전략

빌드, 테스트, 배포 단계를 분리하고 롤백 결정을 자동화하는 파이프라인을 설계하십시오. AWS CodePipeline, CodeBuild, CodeDeploy는 소스에서 프로덕션까지의 흐름을 위한 완전 관리형 경로를 제공하며, 타사 시스템(GitHub Actions, Jenkins, GitLab)은 아티팩트 스토리지(S3), 컨테이너 레지스트리(ECR), 배포 후크(deployment hooks)를 위해 AWS 서비스와 통합됩니다. 런타임 전략의 경우, 상태 저장(stateful) 또는 세션 기반(sessionful) 서비스에는 현재 위치(in-place) 구성 드리프트를 제거하기 위해 불변(immutable) 또는 블루/그린 배포를 선호하고, 점진적인 위험 감소를 위해 트래픽 전환(traffic shifting)을 사용하는 카나리(canary) 배포를 사용하십시오. Lambda의 경우, 자동 롤백을 위해 CloudWatch 경보 또는 CodeDeploy와 함께 별칭(alias) 및 가중치 기반 트래픽 전환을 사용하십시오. ECS/EKS의 경우, 정상적인 종료(graceful shutdown)를 보장하기 위해 배포 컨트롤러(CodeDeploy, AWS App Mesh 또는 네이티브 Kubernetes 전략)를 ALB 대상 그룹 드레이닝(draining) 및 수명 주기 후크(lifecycle hooks)와 결합하십시오. 데이터베이스 스키마 변경에 주의하십시오. 하위 호환성을 갖는 마이그레이션을 설계하고, 기능 플래그(AWS AppConfig) 또는 다크 론치(dark launch)를 사용하여 코드 롤아웃을 스키마 진화와 분리(decouple)하십시오. 비용 대 속도 고려 사항이 중요합니다. 카나리 배포는 롤아웃 속도를 늦추지만 장애 영향 반경(blast radius)을 최소화하는 반면, 병렬 블루/그린 배포는 전환 기간 동안 인프라 비용을 두 배로 증가시킵니다. 장애 발생 시 수동 개입을 피하기 위해 항상 배포 정책, 상태 확인, 자동 롤백을 파이프라인에 내장하십시오.

자동화, 구성 규정 준수 및 관측 가능성

운영 우수성(Operational excellence)은 자동화된 복구, 일관된 구성, 전체적인 관측 가능성(observability)에 달려 있습니다. AWS Systems Manager는 구성을 위한 Parameter Store, 런북을 위한 Automation 문서, 기준선 유지를 위한 Patch Manager, 배스천 없는(bastionless) 문제 해결을 위한 Session Manager를 제공합니다. 분리된(decoupled) 자동화를 위해 EventBridge를 중앙 이벤트 버스로 사용하십시오. CloudTrail, Config 또는 애플리케이션 이벤트를 Lambda나 Step Functions로 라우팅하여 오케스트레이션된 복구를 수행하십시오. AWS Config 규칙과 Config Aggregator로 가드레일을 적용하여 여러 계정을 감사하고, 규정을 준수하지 않는 리소스에 대해 Systems Manager 또는 EventBridge를 통해 자동화된 복구 플레이북을 구현하십시오. 관측 가능성을 위해 CloudWatch 지표와 로그로 서비스를 계측(instrument)하고, 분산 추적을 위해 X-Ray 또는 AWS Distro for OpenTelemetry를 활성화하며, CloudWatch Logs 구독 또는 Kinesis Firehose를 사용하여 중앙 집중식 S3 데이터 레이크 및 분석 스택으로 로그를 중앙 집중화하십시오. 일반적인 함정으로는 비용을 급증시키는 무제한 로그 보존, 지표 비용을 폭증시키는 고유성(high-cardinality)이 높은 사용자 지정 지표, 추적을 쓸모없게 만드는 상관관계 ID(correlation ID) 누락, 비프로덕션 환경에서 복구 런북을 테스트하지 않는 것 등이 있습니다. 장단점은 원격 측정(telemetry) 세분성과 수집 및 저장 비용 사이에서 결정됩니다. 추적 샘플링과 짧은 보존 기간은 비용을 절감하지만 드물게 발생하는 치명적인 장애를 가릴 수 있습니다. 운영 오버헤드를 관리 가능한 수준으로 유지하기 위해 실행 가능한 신호(actionable signal)에 초점을 맞춘 경보와 대시보드를 설계하십시오.

성능, 상태 저장 서비스, 보안 및 리전 간 고려 사항

액세스 패턴, 지연 시간 요구 사항, 일관성 요구 사항에 따라 상태 저장 및 스토리지 서비스를 선택합니다. 인메모리 캐시는 밀리초 미만의 읽기 성능을 제공합니다. ElastiCache (Redis)는 순위표에 이상적인 정렬된 세트(ordered sets)를 지원하며, 복제, 영속성, 그리고 리전 간 읽기 로컬리티를 위한 Global Datastore를 제공합니다. DynamoDB는 대규모의 내구성 있는 스토리지에 탁월하며, 읽기 가속화를 위해 DAX와 함께 사용할 수 있습니다. 단, DAX는 캐시 가능한 항목 수준 액세스에 가장 적합하며 최종적 일관성(eventual consistency)이라는 트레이드오프가 있습니다. 파일 기반 레거시 앱의 경우, 리프트 앤 시프트(lift-and-shift) 호환성을 위해 Amazon FSx for NetApp ONTAP 또는 DataSync와 함께 Amazon EFS를 사용하는 것을 고려해 보세요. SMB/NFS 시맨틱이 필요하다면 FSx가 종종 가장 리스크가 적은 옵션입니다. 암호화와 복제에는 미묘한 함정이 있습니다. AWS KMS 키는 리전별로 생성되므로 리전 간 S3 복제를 위해서는 각 리전에서 관리해야 하며, 또는 다중 리전 키(multi‑Region keys)를 사용하여 액세스 패턴을 단순화할 수 있습니다. 키 정책과 계정 간 권한 부여에 주의해야 합니다. VPC 내의 Lambda는 ENI 생성으로 인해 콜드 스타트(cold-start)가 발생할 수 있습니다. 이는 VPC 엔드포인트, 더 작은 패키지 크기, 프로비저닝된 동시성(provisioned concurrency)을 사용하거나, VPC 외부에서 Lambda를 RDS Proxy와 함께 사용하여 완화할 수 있습니다. 비용과 복원력을 비교 평가해야 합니다. 글로벌 테이블과 리전 간 복제는 비용 증가를 대가로 RTO/RPO를 개선합니다. 프로비저닝된 동시성은 지연 시간을 줄이지만 기본 지출을 늘립니다. 아키텍처를 선택할 때는 데이터 내구성 요구 사항, DR 타임라인, 계정별 리소스 제한을 고려해야 합니다.

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

시나리오: SkyForge Games는 두 개 리전에 걸쳐 프로덕션 및 스테이징 계정을 포함하는 기존 AWS 환경을 운영하고 있습니다. 현재 순위표는 DynamoDB에 구현되어 있으며 CodePipeline을 통해 배포된 Lambda API로 서비스됩니다. 플레이어들은 잦은 기능 출시 중에도 마이크로초 단위의 읽기 지연 시간과 거의 없는 다운타임을 기대합니다.

과제: 내구성을 유지하면서 마이크로초 단위의 순위표 읽기 성능을 제공하고, 여러 계정과 리전에 걸쳐 롤백 가능한 신속한 배포를 지원하는 안전하고 자동화된 CI/CD 파이프라인을 구축해야 합니다.

권장 접근 방식:

기본 리전에 순위표 핫패스(hot-path)를 위해 ElastiCache for Redis 클러스터 모드를 활성화하여 프로비저닝하고, 여러 AZ에 걸쳐 복제본을 두며 Redis 영속성(AOF)을 활성화합니다. 보조 리전의 읽기 로컬리티를 위해 Global Datastore를 구성합니다.
DynamoDB를 신뢰할 수 있는 원천 데이터(source of truth)로 유지합니다. DynamoDB Streams + Lambda(또는 Kinesis Data Streams)를 사용하여 비동기적으로 Redis를 업데이트하고, 이를 통해 최종적 일관성과 복구를 위한 재현성(replayability)을 보장합니다.
템플릿을 합성하고, 아티팩트를 암호화된 S3/ECR에 빌드하며, CloudFormation StackSets를 통해 대상 계정/리전에 인프라를 배포하는 CDK 기반 파이프라인(CDK Pipelines 또는 Git으로 트리거되는 CodePipeline)을 구현합니다. 자동화된 스모크 테스트와 승인 단계를 포함합니다.
카나리/블루-그린 전략을 사용하여 애플리케이션 변경 사항을 배포합니다. 가중치가 적용된 Lambda 별칭 또는 ALB 대상 그룹 전환을 CloudWatch 경보 및 자동 롤백과 함께 사용합니다. CloudWatch, X-Ray, 그리고 합성 카나리 검사(synthetic canary checks)로 계측합니다.

근거: Redis를 사용하여 진정한 밀리초 미만의 읽기 성능을 확보하면서 DynamoDB의 내구성과 재현성을 유지합니다. CDK와 StackSets를 사용한 CI/CD는 일관성 있고 감사 가능한 다중 계정 배포를 제공하며, 트래픽 전환과 관측 가능성(observability)은 신속한 롤백이 가능한 안전한 반복적 릴리스를 가능하게 합니다.

← 비용 최적화 및 거버넌스 · 모든 도메인

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