DOP-C02의 D2 도메인인 Configuration Management and IaC는 시험 비중 17%를 차지합니다. 단순히 CloudFormation 문법을 아는 수준이 아니라, 실제로 수백 개 계정에 걸쳐 인프라를 일관되게 배포하고, 수천 대 서버를 자동으로 패치하며, 드리프트가 발생했을 때 어떻게 복구하는지를 판단하는 능력을 평가합니다. 이 포스트에서는 실제 DOP-C02 시험에 자주 출제되는 시나리오를 중심으로 핵심 개념을 정리합니다.
CloudFormation 고급 패턴
AutoScalingRollingUpdate — 무중단 인스턴스 교체
새로운 AMI를 배포할 때 Auto Scaling Group의 인스턴스를 교체해야 한다면, 가장 안전한 방법은 CloudFormation의 UpdatePolicy 속성을 활용하는 것입니다.
핵심 파라미터 정리:
| 파라미터 | 역할 | |----------|------| | MaxBatchSize | 한 번에 교체할 최대 인스턴스 수 | | MinInstancesInService | 교체 중 유지할 최소 정상 인스턴스 수 | | WaitOnResourceSignals | cfn-signal 수신 후 다음 배치 진행 | | PauseTime | 각 배치 간 대기 시간 |
AutoScalingReplacingUpdate는 기존 ASG를 완전히 새 ASG로 교체하는 방식으로, 교체 중 두 ASG가 동시에 존재해 비용이 2배가 됩니다. 점진적 교체가 필요하다면 반드시 AutoScalingRollingUpdate를 선택해야 합니다.
스택 간 의존성 관리 — Cross-Stack Export/Import vs Nested Stack
멀티티어 아키텍처에서 VPC, 보안 그룹, 애플리케이션 레이어를 어떻게 분리해서 관리할지는 DOP-C02에서 반복적으로 나오는 주제입니다.
Cross-Stack Export/Import 패턴: 네트워크 스택, 보안 스택, 앱 스택을 각각 독립된 CloudFormation 스택으로 운영 네트워크 스택의 Outputs 섹션에 Export Name 지정 → 앱 스택에서 Fn::ImportValue로 참조 각 스택을 독립적으로 배포할 수 있어 변경 주기가 다른 레이어에 적합
Nested Stack 패턴: 부모 스택이 자식 스택을 리소스로 선언하는 구조 부모 스택 업데이트 시 모든 중첩 스택이 함께 재배포됨 리소스 재사용성은 높지만, 독립적인 배포 주기 요구사항에는 부적합
Export를 다른 스택이 참조하는 동안에는 Export 이름 변경이나 스택 삭제가 불가능하다는 강결합 제약을 항상 기억하세요.
!Cross-Stack Export/Import vs Nested Stacks
CloudFormation 데이터 보호 정책
RDS나 EBS 볼륨이 포함된 스택을 업데이트하거나 삭제할 때 데이터 손실을 방지하려면 두 가지 정책을 함께 설정해야 합니다.
| 정책 | 트리거 시점 | 동작 | |------|------------|------| | DeletionPolicy: Snapshot | 스택 삭제 시 | 자동 스냅샷 생성 후 리소스 삭제 | | UpdateReplacePolicy: Snapshot | 스택 업데이트로 리소스 교체 시 | 교체 전 스냅샷 생성 |
DeletionPolicy만 설정하면 스택 업데이트로 인한 리소스 교체 시 데이터가 손실됩니다. 두 정책을 함께 적용해야 양쪽 시나리오를 모두 커버합니다.
UPDATE_ROLLBACK_FAILED 상태 복구
스택 업데이트 실패 후 롤백이 진행되다가 UPDATE_ROLLBACK_FAILED 상태에서 멈추는 경우, 주된 원인은 CloudFormation 외부에서 리소스가 이미 변경되어 원래 상태로 되돌릴 수 없게 된 것입니다.
공식 해결 방법: ContinueUpdateRollback API의 ResourcesToSkip 파라미터를 사용해 문제가 된 리소스를 건너뛰면 나머지 롤백이 완료됩니다. 건너뛴 리소스는 드리프트 상태로 표시되므로 이후 Drift Detection을 통해 별도로 수정해야 합니다.
CloudFormation Custom Resource — 기본 지원 외 작업 자동화
비어 있지 않은 S3 버킷 삭제, 외부 API 호출, Active Directory Connector 생성 등 CloudFormation 기본 리소스가 지원하지 않는 작업은 Custom Resource + Lambda로 처리합니다.
Custom Resource의 필수 동작 원리: CloudFormation이 Lambda를 호출할 때 이벤트 객체에 ResponseURL(미리 서명된 S3 URL) 포함 Lambda 함수는 작업 완료 후 반드시 cfn-response로 SUCCESS 또는 FAILED 전송 cfn-response 누락 시 CloudFormation이 최대 1시간 대기 후 타임아웃으로 실패 처리
cfn-response 전송 코드가 try/except의 except 블록에 누락되는 경우가 흔한 실수입니다. Lambda 함수 실행은 성공했지만 스택이 타임아웃으로 실패하는 증상의 원인은 대부분 이것입니다.
AWS CDK와 CDK Pipelines
CDK의 역할과 CloudFormation과의 관계
AWS CDK는 TypeScript, Python, Java, C등 일반 프로그래밍 언어로 인프라를 정의하고, cdk synth 명령으로 CloudFormation 템플릿을 생성합니다. CDK가 생성한 스택도 결국 CloudFormation으로 배포되므로, CloudFormation의 드리프트 감지, 변경 세트, 롤백 기능을 그대로 활용합니다.
CDK의 핵심 장점: 조건문, 반복문, 함수를 사용해 복잡한 인프라 패턴을 간결하게 표현 L2/L3 Construct를 통한 모범 사례 내장 IDE의 타입 검사와 자동 완성 지원
CDK Pipelines — 파이프라인 자체를 코드로
CDK Pipelines는 CodePipeline을 CDK 코드로 정의하는 L3 Construct입니다. 파이프라인 자체가 CloudFormation 스택으로 관리되므로, 콘솔에서 수동으로 파이프라인을 변경해도 CloudFormation이 드리프트를 감지하여 원래 상태로 복원합니다.
파이프라인 자체를 IaC로 관리하면 드리프트 방지, 언제든 동일한 파이프라인 재프로비저닝, 배포 실패 시 자동 롤백이 모두 보장됩니다.
Service Catalog + CodePipeline 자동 동기화
플랫폼 팀이 승인된 CloudFormation 템플릿을 각 사업부에 제공할 때, 템플릿 변경 시마다 수동으로 Service Catalog를 갱신하면 누락과 지연이 발생합니다. CodePipeline에는 Service Catalog 배포 액션이 기본 내장되어 있어, CodeCommit에 커밋이 생기면 파이프라인이 자동으로 Service Catalog 제품 버전을 업데이트합니다.
AWS Organizations 기반 멀티 계정 거버넌스
Organizations 핵심 구성 요소
수십 또는 수백 개의 AWS 계정을 운영하는 기업은 Organizations와 Control Tower를 조합해 거버넌스를 구현합니다.
| 구성 요소 | 역할 | |-----------|------| | Management Account | 조직 루트, 전체 SCP 정책 적용 | | Organizational Unit (OU) | 계정 그룹화, OU 단위 SCP 적용 | | Service Control Policy (SCP) | IAM 권한의 최대 경계 설정 (허용 목록/거부 목록) | | Control Tower | 랜딩 존 자동화, 계정 프로비저닝, 가드레일 |
SCP는 IAM 정책을 대체하지 않습니다. SCP와 IAM 정책 둘 다 허용해야 실제로 작업이 가능합니다. SCP는 최대 권한 경계를 설정할 뿐입니다.
CloudFormation StackSets — 멀티 계정/리전 배포
StackSets를 사용하면 하나의 CloudFormation 템플릿을 여러 계정과 리전에 동시에 배포할 수 있습니다.
SERVICE_MANAGED 모드에서 auto-deployment를 활성화하면 새 계정이 OU에 추가될 때 자동으로 스택이 배포됩니다. 이것이 DOP-C02에서 자주 나오는 "계정 자동 온보딩" 패턴입니다.
배포 병렬성 제어: MaxConcurrentPercentage: 동시에 배포할 계정 비율 FailureTolerancePercentage: 실패 허용 계정 비율
GuardDuty 및 Config Organizations 통합
보안 거버넌스 측면에서 DOP-C02는 Organizations와의 서비스 통합 패턴을 자주 묻습니다.
GuardDuty Organizations 통합: Management Account 또는 위임된 관리자 계정에서 GuardDuty를 활성화하면 모든 멤버 계정의 위협 탐지 결과가 중앙에 집계됩니다. auto-enable 설정 시 새 계정 추가 시 자동으로 GuardDuty가 활성화됩니다.
AWS Config Organizations 규칙: Organizations 수준에서 Config Conformance Pack을 배포하면 모든 계정에 동일한 규정 준수 규칙이 적용됩니다. Aggregator를 통해 전체 계정의 규정 준수 현황을 단일 콘솔에서 조회합니다.
크로스 계정 IAM 역할 패턴
중앙 CI/CD 계정에서 개발, 스테이징, 프로덕션 계정에 배포할 때는 크로스 계정 역할 위임을 사용합니다.
각 대상 계정에 CrossAccountDeployRole 생성, 신뢰 정책에 CI/CD 계정 ID 지정 CI/CD 계정의 CodePipeline/CodeBuild가 STS AssumeRole로 대상 계정의 역할 획득 획득한 임시 자격 증명으로 CloudFormation 배포 실행
이 패턴은 장기 자격 증명 없이 최소 권한으로 멀티 계정 배포를 구현하는 DOP-C02의 핵심 패턴입니다.
AWS Systems Manager 대규모 자동화
Patch Manager — 환경별 패치 기준 자동화
수백 대의 EC2 인스턴스를 운영할 때 환경별로 다른 패치 기준을 자동으로 적용하는 패턴이 DOP-C02에 자주 등장합니다.
핵심 구성 요소 흐름:
환경별 분리 패턴:
| 환경 | Patch Baseline | Patch Group 태그 | |------|---------------|-----------------| | 프로덕션 | SECURITY 분류만 | Patch Group: prod | | 스테이징 | SECURITY (사전 검증) | Patch Group: staging | | 개발 | 전체 (ALL) | Patch Group: dev |