Amazon DOP-C02: 코드형 인프라 및 구성 관리 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

개요

AWS의 코드형 인프라(IaC) 및 구성 관리는 인프라와 애플리케이션의 반복 가능하고, 감사 가능하며, 통제된 프로비저닝 및 구성을 제공합니다. CloudFormation과 AWS Cloud Development Kit(CDK)는 리소스를 선언적으로 설명하거나, CloudFormation으로 합성되는 코드를 통해 설명합니다. AWS OpsWorks 및 AWS Systems Manager와 같은 구성 계층은 EC2 및 하이브리드 플릿 전반의 인스턴스에서 원하는 상태를 강제하고 보고합니다. 보안 암호, 파라미터, 이미지 베이킹은 수명 주기를 완성하여 대규모의 불변하고 안전한 배포를 가능하게 합니다.

CloudFormation 스택, 변경 제어 및 거버넌스

CloudFormation 스택은 배포의 단위입니다. 영향 반경을 최소화하기 위해 수명 주기 경계와 소유권을 중심으로 스택을 설계하십시오. 파라미터는 드물게 사용하고, 매핑 또는 SSM 조회를 사용하는 의견이 반영된(opinionated) 기본값을 선호하십시오. 강한 결합을 피하기 위해 Outputs와 Fn::ImportValue를 통해 안정적이고 공유된 값만 내보내고 가져오십시오.

중첩 스택은 재사용 가능한 구성 요소를 캡슐화하고 상위 템플릿을 작게 유지합니다. 상위 스택은 하위 스택에 파라미터를 전달하고 그 출력을 사용할 수 있어 모듈식 아키텍처(예: 애플리케이션 스택이 사용하는 공유 네트워크 중첩 스택)를 가능하게 합니다. 중첩 스택은 단일 책임(VPC, 데이터 계층, 앱 계층)에 집중하고 독립적으로 버전을 관리합니다.

StackSets는 단일 템플릿을 여러 계정과 리전에 걸쳐 배포합니다. AWS Organizations와 함께 서비스 관리형 권한 모델을 사용하여 OU에 자동 배포하고 새 계정을 자동으로 포함시키십시오. 롤아웃을 제어하기 위해 작업 기본 설정(최대 동시 계정/리전, 실패 허용 범위)을 구성하십시오. 계정 또는 리전별 파라미터 재정의를 통해 표준 템플릿을 로컬 제약 조건에 맞게 조정할 수 있습니다. StackSet 및 스택 인스턴스 드리프트를 모니터링하여 대역 외(out-of-band) 변경을 탐지하십시오.

변경 세트는 안전하고 사람이 검토할 수 있는 업데이트를 제공합니다. 항상 CreateChangeSet를 실행하고 ExecuteChangeSet를 실행하기 전에 리소스별 영향, 교체, 잠재적 데이터 손실을 검사하십시오. 단계별 승인을 위해 변경 세트를 자동화된 파이프라인에 통합하십시오.

드리프트 탐지는 스택 리소스가 템플릿과 일치하는지 검증합니다. 중요한 스택 및 StackSets에 대해 정기적으로 드리프트 탐지를 실행하십시오. 모든 리소스 유형에 대해 모든 속성이 평가되는 것은 아니라는 점을 이해해야 합니다(지원되지 않는 속성은 ‘확인되지 않음’으로 보고됨). 드리프트를 인시던트로 취급하고, 조사하고, 컨텍스트를 파악한 후 스택 업데이트를 통해 수정하거나 드리프트를 코드로 만들고 다시 적용하여 수정하십시오.

스택 정책은 업데이트 중 중요한 리소스를 보호하는 JSON 문서입니다. 대체 불가능한 리소스(예: 프로덕션 데이터베이스, Route 53 영역)에 대한 업데이트를 거부하고, StackPolicyDuringUpdateBody를 사용하여 특정 변경을 위한 정밀한 경로를 일시적으로 열어준 다음, 더 엄격한 정책을 복원하십시오. 가드레일을 위해 종료 방지 및 DeletionPolicy(Retain/Snapshot)와 결합하여 사용하십시오. 외부 상태를 가진 리소스(S3 버킷)의 경우, 삭제 동작을 계획하십시오. 버킷을 삭제하기 전에 비워야 하는 경우, 스택 삭제 시 객체를 제거하는 사용자 지정 리소스를 구현하십시오.

AWS CDK 및 CloudFormation 확장성

AWS CDK는 익숙한 언어(TypeScript, Python, Java, .NET, Go)로 인프라를 모델링합니다. Construct는 CDK의 기본 구성 요소입니다:

L1 Construct(CfnXxx)는 CloudFormation 사양에서 생성되며 리소스와 일대일로 매핑됩니다.
L2 Construct는 높은 수준의 의도와 합리적인 기본값(예: ApplicationLoadBalancedFargateService)을 추가합니다.
L3 ‘패턴’은 여러 L2를 조합하여 즉시 사용 가능한 아키텍처를 만듭니다.

CDK 앱은 하나 이상의 스택을 포함합니다. cdk synth 중에 앱은 컨텍스트 조회(예: VPC ID)를 확인하고, 에셋을 렌더링하며, CloudFormation 템플릿을 생성합니다. 배포하기 전에 cdk bootstrap은 환경의 에셋 버킷과 역할을 생성합니다. cdk diff를 사용하여 변경 사항을 미리 보고, cdk deploy를 사용하여 템플릿과 에셋을 제출합니다. CDK는 내부적으로 변경 세트를 사용하며 보안에 민감한 변경(IAM 또는 리소스 교체)을 표시하고 확인합니다. Aspects를 통해 스택과 리소스에 태그를 지정하여 조직 전체의 태그 정책을 강제하십시오. L2 추상화가 부족한 경우, 이스케이프 해치(node.defaultChild)를 사용하거나 L1 Construct로 전환합니다.

CloudFormation 사용자 지정 리소스는 API를 통해 접근 가능한 모든 것으로 IaC를 확장합니다. Lambda 기반 사용자 지정 리소스는 RequestId, PhysicalResourceId, 속성과 함께 Create, Update, Delete 이벤트를 수신합니다. 함수는 다음을 수행해야 합니다:

멱등성을 가지며 타임아웃 시간 내에 미리 서명된 ResponseURL로 성공/실패를 반환해야 합니다.
안정적인 PhysicalResourceId를 설정하여 업데이트를 추적하고 Delete 시 정리를 수행해야 합니다.
최종적 일관성을 가지는 다운스트림 서비스를 위해 재시도 및 안정화 대기를 처리해야 합니다.

Lambda에 최소 권한 IAM 실행 역할을 사용하고, API 호출에 지수 백오프를 포함하며, RequestId를 통한 로그 상관 관계를 설정하십시오. 크거나 오래 실행되는 작업의 경우, 실행 토큰을 기다리는 사용자 지정 리소스와 함께 Step Functions를 사용하는 것을 고려하십시오. 해당하는 경우, 재사용 가능하고 버전이 관리되는 공급자를 위해 CloudFormation 레지스트리를 사용하는 것이 좋습니다.

Infrastructure as Code의 보안 암호 및 파라미터

템플릿이나 코드에 보안 암호를 하드코딩하지 마십시오. 배포 시점에 동적 참조를 사용하여 민감한 값을 확인하십시오:

Secrets Manager: {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}
SecureString Parameter Store: {{resolve:ssm-secure:parameter-name:version}}

동적 참조를 사용하면 보안 암호가 스택 템플릿이나 이벤트에 저장되는 것을 방지할 수 있습니다. CloudFormation이 평문으로 기록하는 Outputs나 리소스 속성에는 보안 암호를 넣지 마십시오. CloudFormation 실행 역할에 참조된 값을 복호화하거나 검색할 수 있는 권한을 부여하고, 액세스가 필요한 주체(principal)로 KMS CMK의 범위를 지정하십시오.

Parameter Store는 보안 암호가 아닌 구성(기능 플래그, AMI ID, 엔드포인트 등)에 이상적입니다. 버전 관리되는 SSM 파라미터를 사용하여 여러 환경에 걸쳐 안전한 롤백과 원자적(atomic) 승격을 구현하십시오. CDK에서는 ssm.StringParameter.fromStringParameterName 또는 보안 값을 위한 fromSecureStringParameterAttributes를 사용하여 값을 가져오고, 파라미터 읽기를 사용자 데이터나 애플리케이션 부트스트랩에 연결하십시오.

Secrets Manager는 수명 주기 제어, 교체, 감사 등을 위해 설계되었습니다. 지원되는 엔진(RDS, Aurora) 또는 사용자 지정 Lambda와 교체 기능을 통합하십시오. 오래된 정보의 확산을 피하기 위해 AMI에 내장(baking)하는 대신 런타임에 보안 암호를 참조하십시오. 컨테이너화되거나 서버리스인 워크로드의 경우, Secrets Manager 참조를 기반으로 하는 환경 변수를 통해 보안 암호를 주입하거나 ECS/TaskDefinition 보안 암호를 통해 마운트하십시오. 짧은 TTL의 연결 풀과 재시도를 사용하여 다운타임을 최소화하며 교체하십시오.

구성 관리와 불변(Immutable) 인프라

AWS OpsWorks는 특정 방식(opinionated)을 제시하는 구성 관리 기능을 제공합니다. OpsWorks Stacks는 Chef 쿡북과 수명 주기 이벤트(Setup, Configure, Deploy, Undeploy, Shutdown)를 사용하여 애플리케이션 구성 및 배포를 오케스트레이션하고, 상태 확인을 통해 인스턴스를 중지/시작하거나 교체하는 자동 복구(auto-healing)를 지원합니다. 과거에 OpsWorks는 관리형 Chef Automate 및 Puppet Enterprise도 제공했지만, 오늘날 많은 팀은 에이전트 기반 오케스트레이션을 위해 Systems Manager를 표준으로 사용하거나 Ansible/Chef/Puppet 컨트롤 플레인을 직접 실행합니다. Ansible은 OpsWorks와 기본적으로 통합되지 않습니다. 대신 Systems Manager State Manager를 사용하여 플레이북을 실행하거나, SSM Session Manager 연결 및 EC2 동적 인벤토리와 함께 AWX/Ansible Automation Platform을 사용합니다.

AWS Systems Manager는 하이브리드 구성을 위한 현대적인 컨트롤 플레인입니다:

State Manager는 일정, 이벤트 또는 인스턴스 시작 시 SSM 문서(YAML/JSON)를 실행하는 연결(Association)을 통해 원하는 상태를 강제합니다.

undefined

및 사용자 지정 문서를 사용하여 구성을 수렴시킵니다. 연결을 파라미터화하고 태그로 대상을 지정하여 전체 플릿(fleet)에 대한 변경을 수행합니다.

구성 규정 준수는 연결 상태와 Patch Manager 결과를 보여줍니다. 패치 기준선을 사용하여 승인된 분류를 정의하고, 유지 관리 기간(Maintenance Window)에 연결하며, 인스턴스 태그, 패치 그룹 또는 리소스 그룹별로 규정 준수를 추적합니다. 하이브리드 활성화(Hybrid Activations)는 온프레미스 노드를 관리형 인스턴스로 온보딩하여 일관된 거버넌스를 적용합니다.
Inventory는 패키지, 파일, Windows 업데이트를 기록합니다. 리소스 데이터 동기화(Resource Data Sync)는 S3 및 Athena로 데이터를 내보내 엔터프라이즈 리포팅에 사용합니다. SSM 규정 준수를 AWS Config 규칙 및 자동 해결(Systems Manager Automation 실행서)과 결합하여 탐지에서 수정까지의 과정을 완료합니다.

불변 인프라는 드리프트(구성 편차)를 제거하고 롤백을 가속화합니다. EC2 Image Builder는 다음을 통해 이미지 파이프라인을 코드화합니다:

구성 요소(Component) (설치, 경화, 검증 단계)는 문서로 표현됩니다.
이미지 레시피(Image recipe)는 구성 요소와 기본 이미지를 조합합니다.
인프라 구성(Infrastructure configuration)은 서브넷, 보안 그룹, 인스턴스 프로필, 로깅을 정의합니다.
배포 구성(Distribution configuration)은 AMI를 여러 리전으로 복제하고 다른 계정과 공유합니다.

테스트 구성 요소를 추가하여 CIS 벤치마크, 에이전트 상태(SSM/CloudWatch), 애플리케이션 스모크 테스트를 검증합니다. 이미지 버전을 관리하고 시맨틱 태그로 레이블을 지정합니다. AMI ID를 Parameter Store(예: /app/frontend/ami)에 게시하고 Auto Scaling 시작 템플릿에서 참조합니다. 롤링 또는 블루/그린 전략으로 배포하고, 불변성을 유지하기 위해 인플레이스(in-place) 패치 대신 인스턴스를 교체합니다. 취약점 스캔(Amazon Inspector) 결과를 파이프라인 승격 게이트에 반영합니다. 이미지에 시크릿을 포함시키지(bake) 마십시오. 부팅 시 인스턴스 메타데이터 서비스 v2와 SSM/Secrets Manager 참조를 통해 검색합니다.

실제 문제 시나리오

Capital One은 고객 대면 플랫폼을 위해 멀티 어카운트, 멀티 리전 배포를 표준화하는 동시에 엄격한 거버넌스, 시크릿 관리, 구성 드리프트 제거를 시행해야 합니다. 환경은 AWS Organizations 내 수백 개의 계정에 걸쳐 있으며, 데이터베이스 액세스 및 OS 경화에 대한 엄격한 통제가 필요합니다.

AWS CDK로 인프라를 모델링하고 CloudFormation으로 합성(synthesize)

VPC, ALB, Auto Scaling 그룹, Aurora를 위한 L2/L3 구조(construct)를 구현합니다. CI에서 cdk synth 및 cdk diff를 사용하여 템플릿과 변경 세트를 생성하고 검증합니다.
CDK를 사용하는 이유: 구조(construct)를 통한 강력한 구성 및 재사용, Aspects를 통한 프로그래밍 방식 정책으로 전사적 태깅 및 가드레일 구현, 감사 가능성을 위한 CloudFormation과의 네이티브 통합.

CloudFormation StackSets를 통해 기준 네트워크 및 가드레일 스택 배포

보안 및 샌드박스 OU를 대상으로 하는 서비스 관리형 StackSets를 생성하여 공유 VPC 엔드포인트, 표준 CloudWatch 경보, IAM 경계를 배포합니다. 장애 허용(failure tolerance) 및 동시성 제어(concurrency controls) 기능으로 새 계정에 대한 자동 배포를 활성화합니다.
StackSets를 사용하는 이유: 조직 규모의 일관된 배포, 새 계정 자동 포함, 내장된 드리프트 탐지 기능.

스택 정책 및 변경 세트로 중요 리소스 보호

Aurora 클러스터 및 Route 53 영역에 대한 업데이트를 거부하는 스택 정책을 적용합니다. 프로덕션 환경에서는 파이프라인에서 ExecuteChangeSet 전에 CreateChangeSet 및 수동 승인을 요구합니다.
스택 정책/변경 세트를 사용하는 이유: 최소 권한 변경을 강제하고, 고위험 변경 전에 수동 검토를 제공합니다.

Lambda 기반 사용자 지정 리소스로 IaC 확장

스택 삭제 시 애플리케이션 버킷을 비우는 Custom::S3BucketCleanup과, 생성 후 엔진 파라미터를 적용하는 Custom::AuroraParameterTuner를 구현합니다.
사용자 지정 리소스를 사용하는 이유: 선언적 프로비저닝의 기능적 격차를 해소하면서도 수명 주기를 스택에 연결된 상태로 유지합니다.

Secrets Manager와 Parameter Store로 시크릿 및 구성 중앙화

데이터베이스 자격 증명과 API 키는 교체 Lambda와 함께 Secrets Manager에 저장하고, AMI ID, 기능 플래그, 엔드포인트는 Parameter Store에 게시합니다. CloudFormation의 동적 참조와 CDK의 런타임 임포트를 통해 값을 참조합니다.
이 서비스들을 사용하는 이유: 관심사 분리—시크릿은 교체 및 감사 기능과 함께 관리하고, 파라미터는 시크릿이 아닌 구성 정보 및 손쉬운 승격을 위해 사용합니다.

Systems Manager State Manager를 통해 원하는 상태 및 규정 준수 강제

연결(association)을 생성하여 에이전트를 설치하고, OS 설정을 구성하며, 필요한 경우 Ansible 플레이북을 적용합니다. 유지 관리 기간(Maintenance Window)과 함께 Patch Manager를 사용하여 업무 외 시간에 패치를 적용하고, Resource Data Sync로 집계된 규정 준수 대시보드를 사용합니다.
State Manager를 사용하는 이유: EC2 및 온프레미스 전반에 걸친 에이전트 기반 수렴, 지속적인 규정 준수 보고, 대규모 수정 기능을 제공합니다.

EC2 Image Builder로 불변 인프라 채택

CIS 기준, SSM/Inspector 에이전트, 앱 런타임 종속성을 위한 구성 요소(component)를 사용하여 경화된 AMI를 빌드합니다. 테스트를 실행하고, AMI ID를 Parameter Store에 게시하며, Auto Scaling 시작 템플릿을 버전 관리된 파라미터에 연결합니다. 롤링 업데이트를 통해 배포하고, AMI 업데이트 시 인스턴스 새로 고침을 트리거합니다.
Image Builder를 사용하는 이유: 재현 가능하고 테스트 가능한 이미지로 드리프트를 제거하고, 빠른 롤백을 통해 평균 복구 시간(MTTR)을 단축합니다.

파이프라인 오케스트레이션 및 거버넌스

cdk synth/diff를 실행하고, 변경 세트를 생성하며, 승인을 위해 일시 중지한 다음 실행하는 다단계 파이프라인을 구현합니다. EventBridge를 사용하여 리포지토리 변경 시 StackSet 업데이트를 트리거합니다. 매일 밤 드리프트 탐지 스캔을 추가하고, 불일치 발생 시 OpsCenter 항목을 생성합니다.
이 접근 방식을 사용하는 이유: 감사 가능한 승격, 선제적 드리프트 탐지, 잘 정의된 서비스 책임을 통한 자동화된 수정을 갖춘 지속적인 배포(Continuous Delivery)를 구현합니다.

← CI · 모든 도메인 · 모니터링 →

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