Cert Notes/ 출퇴근 학습 노트
로드맵
KOEN
CLF-C02 · FoundationalCloud Practitioner - Foundational
DVA-C02 · AssociateDeveloper - Associate
SAA-C03 · AssociateSolutions Architect - Associate
SOA-C02 · AssociateCloudOps Engineer - Associate
SAP-C02 · ProfessionalSolutions Architect - Professional
DOP-C02 · ProfessionalDevOps Engineer - Professional
  • Week 1
    • 1.DevOps라는 운영 모델: CALMS의 다섯 축과 DORA가 측정해 보여준 진실
    • 2.Well-Architected Framework: DevOps의 6개 렌즈로 다시 읽기
    • 3.AWS DevOps 도구 지도: Code* 시리즈와 그 너머의 진짜 그림
    • 4.멀티 계정 전략: Organizations, Control Tower, IAM Identity Center의 진짜 그림
    • 5.Week 1 종합: DevOps 사고 프레임을 시나리오로 굳히기
  • Week 2
    • 1.CodeCommit 심화: Git 호스팅을 IAM으로 통합하면 무엇이 달라지는가
    • 2.GitHub Actions ↔ AWS OIDC: 정적 키를 영구히 없애는 페더레이션
    • 3.CodeArtifact와 공급망 보안: 의존성이 공격 표면이 되는 시대의 패키지 관리
    • 4.DevSecOps의 Shift Left: 코드 서명·CodeGuru·Inspector로 만드는 자동 보안 게이트
    • 5.Week 2 종합: 소스 제어부터 코드 서명까지, DevSecOps 사고 프레임을 시나리오로 굳히기
  • Week 3
    • 1.buildspec.yml의 진짜 의미: 파이프라인 명세가 코드가 되는 순간
    • 2.빌드 속도의 물리학: 캐시·병렬·컴퓨트의 트레이드오프
    • 3.시크릿 관리의 설계 원칙: Secrets Manager vs Parameter Store를 가르는 기준
    • 4.VPC CodeBuild, Custom Image, ARM/Graviton: 빌드 환경의 경계 확장
    • 5.Week 3 복습: CodeBuild 통합 시나리오와 실전 판단력
  • Week 4
    • 1.In-place vs Blue/Green, AppSpec: 배포 전략의 물리학
    • 2.EC2/On-Prem 배포 + Auto Scaling 통합: 인스턴스 생애주기와 배포의 교차점
    • 3.Lambda 배포: Linear/Canary/AllAtOnce와 Alias의 수학
    • 4.ECS Blue/Green + CodeDeploy 트래픽 시프트: 두 Target Group의 논리
    • 5.Week 4 복습: CodeDeploy 배포 전략의 통합 시나리오
  • Week 5
    • 1.CodePipeline 구조: Stage, Action, Artifact가 만들어진 이유
    • 2.멀티 계정 파이프라인: Cross-Account IAM이 필요한 이유
    • 3.Action Providers: Lambda, Step Functions, Manual Approval이 파이프라인을 확장하는 방식
    • 4.동적 파이프라인: V2 변수 시스템, 트리거 필터, Execution Mode의 설계
    • 5.Week 5 복습: CodePipeline 통합 시나리오
  • Week 6
    • 1.ECR: 컨테이너 이미지 레지스트리가 해결하는 문제들
    • 2.ECS 자동 배포: Task Definition 갱신에서 Auto Scaling까지
    • 3.EKS CI/CD: GitOps가 탄생한 이유, 그리고 ArgoCD와 Flux가 Kubernetes를 바꾼 방식
    • 4.App Runner와 ECS Copilot: 컨테이너 운영 추상화의 스펙트럼
    • 5.Week 6 복습 + 시나리오 문제 12개
  • Week 7
    • 1.AWS SAM: CloudFormation이 서버리스에게 던진 사과
    • 2.Serverless Framework와 CDK: SAM이 아닌 길을 고른 사람들
    • 3.Lambda Version과 Alias: 불변 스냅샷 위에 얹은 가변 포인터
    • 4.Step Functions: 워크플로를 코드가 아닌 상태 머신으로
    • 5.Week 7 복습: 서버리스 CI/CD의 모든 조각을 한 그림에
  • Week 8
    • 1.CloudFormation 고급: Nested·Cross-Stack과 모듈화의 깊은 이야기
    • 2.StackSets: 수천 계정에 IaC를 뿌리는 거버넌스의 깊은 이야기
    • 3.Custom Resource·Hooks·Change Set: CloudFormation의 확장과 검증 메커니즘
    • 4.CDK·CDK Pipelines·Terraform: 모던 IaC 도구의 깊은 비교와 자기 진화하는 파이프라인
    • 5.Week 8 통합 시나리오: IaC 도구가 한 인시던트 안에서 만나는 자리
  • Week 9
    • 1.Systems Manager: Run Command·Session Manager·Patch Manager의 깊은 이야기
    • 2.State Manager·Inventory·Compliance: 원하는 상태라는 추상화
    • 3.AppConfig: 코드 배포 없이 동작을 바꾸는 기술
    • 4.Parameter Store와 Secrets Manager: 시크릿 회전의 깊은 이야기
    • 5.Week 9 종합: 운영 자동화를 하나의 그림으로
  • Week 10
    • 1.CloudWatch Metrics: 시계열·차원·알람 평가 모델의 깊은 이야기
    • 2.CloudWatch Logs: 그룹·스트림·구독·Insights의 깊은 이야기
    • 3.Container Insights·Lambda Insights·EMF: 워크로드별 관찰성의 깊은 이야기
    • 4.Synthetics·RUM·Evidently: 사용자 경험을 측정하는 세 가지 시선
    • 5.Week 10 종합: 관찰성 스택을 인시던트로 엮다
  • Week 11
    • 1.X-Ray: 분산 추적의 인과 그래프와 Trace 모델의 깊은 이야기
    • 2.X-Ray 샘플링: Reservoir 알고리즘과 운영 규모의 추적 경제학
    • 3.ADOT: OpenTelemetry가 끝낸 추적 도구 전쟁의 깊은 이야기
    • 4.OpenSearch · AMP · AMG: 역인덱스와 시계열 DB의 두 세계
    • 5.Week 11 종합: 옵저버빌리티 추적·텔레메트리의 실전 의사결정
  • Week 12
    • 1.EventBridge: 이벤트 버스의 라우팅 모델과 비동기 자동화의 신경계
    • 2.SSM Automation: 운영 절차를 코드로, 사람을 워크플로 안으로
    • 3.Auto-Healing: 자동 복구의 제어 이론과 폭주를 막는 안전 공학
    • 4.ChatOps와 Incident Manager: 자동화가 끝나고 사람 조직이 시작되는 경계
    • 5.Week 12 통합 복습: 인시던트 자동화의 전체 신경계를 하나로 잇기
  • Week 13
    • 1.Multi-AZ High Availability: The Distributed Principles Behind Replication Consistency, Quorum, and Failover
    • 2.Multi-Region Resilience: Distributed Principles of DNS Routing, Global Replication, and Encryption Boundaries
    • 3.Four DR Strategies: Tradeoffs of RTO, RPO, Cost and Their Economics
    • 4.Resilience Verification: Chaos Engineering via Resilience Hub and FIS
    • 5.Week 13 종합 복습: 고가용성·멀티 리전·DR·복원력 검증을 하나로 꿰다
  • Week 14
    • 1.GuardDuty와 자동 격리: 위협 탐지의 신호 처리·통계·자동 대응 원리
    • 2.Security Hub: 보안 데이터 정규화·집계·자동 수정의 SIEM 원리
    • 3.AWS Config: 상태 기록·드리프트·자동 수정의 폐루프 제어 원리
    • 4.Audit Manager·Macie·Inspector: 증거 자동화·데이터 분류·취약점 스캔의 원리
    • 5.Week 14 종합 복습: 보안 자동화 스택의 큰 그림과 실전 시나리오
  • Week 15
    • 1.멀티 계정 엔터프라이즈 CI/CD: 50+ 계정을 떠받치는 거버넌스·플랫폼 엔지니어링의 원리
    • 2.하이브리드 CI/CD: 온프레미스와 AWS를 하나의 배포 모델로 묶는 원리
    • 3.대규모 ECS/EKS 운영: 100+ 마이크로서비스를 떠받치는 스케줄링·GitOps·비용의 원리
    • 4.서버리스 대규모 인시던트 자동 대응: 사람 없이 복구하는 자동화의 원리와 안전장치
    • 5.Week 15 종합: 케이스를 가로지르는 단서 독해와 트레이드오프 판단의 기술
  • Week 16
    • 1.도메인 1·2 통합 복습: SDLC 자동화와 IaC를 한 줄기로 꿰는 원리
    • 2.도메인 3·4 통합 복습: 복원력의 수학과 관찰성의 이론
    • 3.도메인 5·6 통합 복습: 통제 이론으로 보는 인시던트 자동화와 보안
    • 4.전체 모의고사: 실전 75문항 페이스로 6개 도메인 종합 점검
    • 5.D-Day 마무리: 시험장 전략과 마지막 시나리오 통합 점검
SCS-C03 · SpecialtySecurity - Specialty
MLA-C01 · AssociateMachine Learning Engineer - Associate
AIF-C01 · FoundationalAI Practitioner - Foundational
DEA-C01 · AssociateData Engineer - Associate
MLS-C01 · SpecialtyMachine Learning - Specialty
합격 후기
← DOP-C02/Week 1/Day 5
DOP-C02· ProWeek 1 · Day 5읽기 약 25분

Day 5 - Week 1 종합: DevOps 사고 프레임을 시나리오로 굳히기

Week 1은 추상의 주간이었다. CALMS의 다섯 축, DORA의 네 메트릭, Well-Architected의 여섯 기둥, AWS DevOps 도구 지도, 그리고 멀티 계정 거버넌스. 따로 두면 각자 하나의 거대한 책이지만, DOP-C02 시나리오 안에서는 항상 두세 개가 한 묶음으로 등장한다. "분기 1회 배포 → 일 1회"로 가속하는 일에는 Automation 도구만 깔아서 풀리지 않고, blast radius·계정 분리·서명 검증·롤백 자동화·관찰성까지 한 번에 끌려 올라온다.

오늘은 그 묶음 풀이를 12개의 시나리오로 굳힌다. 각 문제는 Day 1-4의 두세 가지 개념을 엮어 만들었고, 시험장에서 정확히 같은 형태의 문제를 만난다고 가정하고 풀이를 적었다. 결국 Week 1이 가르치고 싶은 것은 "DevOps는 코드를 빠르고 안전하게 흘려보내는 시스템이고, AWS의 도구·계정 구조·메트릭은 그 시스템을 코드로 옮기기 위한 부품"이라는 한 문장이다.

한 페이지 컴팩트 — Week 1 핵심

CALMS 5축 진단표 (가장 약한 축이 곧 다음 우선순위)

축진단 질문약하면 나타나는 증상1순위 AWS 도구
Culture사고 시 누가 비난받나?사고 은폐, 동일 사고 반복Blameless COE, Incident Manager, Chatbot
Automation수동 단계가 몇 개 남았나?빈도 정체, MTTR 폭증, 휴먼 에러CodePipeline + CodeBuild + CodeDeploy + SSM Automation
LeanPR 머지까지 며칠?WIP 누적, lead time 폭주Trunk-based dev, AppConfig feature flag
Measurement변경의 효과를 어떻게 아나?"느낌" 기반 결정, KPI 게이밍CloudWatch Metrics + EMF + DORA dashboard
Sharing한 팀의 깨달음이 흐르나?같은 실수가 다른 팀에서 재발Service Catalog, Proton, Wiki

DORA 4 metrics → 처방 매핑

지표약함의 신호1차 처방 (AWS)
Deployment Frequency ↓분기 1회, 월 1회CodePipeline 자동화 + 작은 배치 + AppConfig flag
Lead Time ↑commit→prod 2주+Manual Approval 제거 + CodeBuild 캐시 + monorepo 분할
Change Failure Rate ↑30%+ 사고율Canary + CloudWatch alarm 자동 롤백 + pre-deploy hook
MTTR ↑사고 후 며칠EventBridge → SSM Runbook + Incident Manager

W-AF 6 Pillar → 시나리오 키워드

Pillar시나리오 키워드DevOps 관점
Operational Excellence"자동화", "관찰성", "런북"CALMS의 A + M
Security"최소 권한", "shift-left", "감사"DevSecOps
Reliability"RTO/RPO", "Multi-AZ/Region", "self-healing"자동 롤백 + chaos
Performance"지연 시간", "처리량"Profiler, 인스턴스 타입
Cost"낭비", "예산", "Spot"Right-sizing, autoscale
Sustainability"탄소", "재생 에너지"리전 선택, ARM/Graviton

멀티 계정 표준 구조

  • OU: Security / Infrastructure / Workloads(Prod/Non-Prod) / Sandbox
  • 3대 표준 계정: Management(billing+SCP), Log Archive(불변), Audit(SecurityHub/GuardDuty 집계)
  • SCP: deny-only guardrail (permission grant 아님). root에도 적용. NotAction으로 글로벌 서비스 제외 필수.
  • Cross-account: STS AssumeRole + ExternalId / Resource policy / RAM
  • CI/CD: Shared Services(Hub) → 환경 계정(Spoke) AssumeRole 배포

Week 1 시나리오 풀이 4단계 흐름

시험장에서는 다음 4단계를 의식적으로 거쳐야 한다.

  1. W-AF Pillar 분류: "이 시나리오가 어느 Pillar를 묻는가" (Reliability? Cost? Security?)
  2. CALMS/DORA 진단: 어느 축이 약하고 어느 메트릭이 깨졌는가
  3. AWS 도구 후보 추리기: 도메인별 도구 지도에서 3-4개 후보
  4. trade-off로 단일 정답 선택: 우선순위·blast radius·비용·운영 부담

🎯 시나리오: "Slack 알림이 너무 많아 무시당한다"는 보고가 올라온다. 무엇이 문제인가? 도구가 아니라 Measurement 정의가 잘못된 상태다. SLO/SLI 없이 모든 메트릭을 alert로 만든 결과 alert fatigue가 생긴 것. 정답은 도구 추가가 아니라 SLO 정의 + Composite Alarm으로 노이즈 축소 + Error Budget 기반 분류다. CALMS의 M 축이 양적으로는 충족됐지만 질적으로 무너진 사례.


📝 종합 시나리오 12개

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 대형 핀테크가 "분기 1회 배포 → 주 1회 배포"로 가속을 추진한다. 현재 상태: 단일 AWS 계정에서 dev/staging/prod를 VPC로만 분리, CodePipeline 없이 사람이 콘솔에서 직접 배포, 사고 발생 시 평균 8시간 복구 소요. CALMS 진단 + 우선순위 처방으로 가장 적합한 것은?

문제 2

한 회사가 us-east-1과 eu-west-1에 동일 워크로드를 배포한다. 사용자는 글로벌이고 GDPR 준수가 필수. 단일 계정에서 운영 중이라 사고 시 blast radius 우려가 크다. Organizations 도입 후 가장 적합한 OU 구조는?

문제 3

한 회사가 SaaS 모니터링 도구 Datadog를 도입한다. Datadog가 우리 AWS 계정의 메트릭에 접근해야 한다. 보안 + 자동화 관점에서 가장 적합한 설정은?

문제 4

한 회사가 "배포 빈도는 일 5회로 Elite 수준인데 Change Failure Rate가 40%"라는 문제를 보고했다. 다음 조치 중 가장 효과적인 것은?

문제 5

한 글로벌 회사가 5개 리전에 배포하면서 모든 계정의 CloudTrail 로그를 중앙 집중 + 변조 방지로 관리하려 한다. 가장 적합한 아키텍처는?

문제 6

한 회사가 멀티 계정 환경에서 CI/CD를 구축한다. CodePipeline은 Shared Services 계정에 있고, 배포 대상은 Prod 계정. Prod 계정의 ECS 서비스로 배포해야 하며, KMS 키로 암호화된 artifact를 사용한다. 가장 정확한 권한 설정은?

문제 7

한 회사가 모든 계정에 "ap-northeast-2와 us-east-1 외 리전에서 EC2/RDS/S3 작업 금지"를 강제하려 한다. SCP를 작성할 때 반드시 주의해야 할 점은?

문제 8

한 회사가 EKS 클러스터를 Prod 계정에 운영하고, ArgoCD를 통해 GitOps 방식으로 배포한다. 단일 클러스터 시나리오에서 ArgoCD는 어디에 두는 게 가장 적합한가?

문제 9

한 회사가 "DORA 메트릭을 dashboard로 시각화하라"는 요구를 받았다. AWS 환경에서 가장 적합한 데이터 파이프라인은?

문제 10

한 회사가 Production 계정의 "특정 시간(주말, 새벽 0-6시)에 자동으로 read-only mode"를 강제하려 한다. 가장 적합한 메커니즘은?

문제 11

Werner Vogels의 "You Build It, You Run It" 원칙을 AWS 환경에서 가장 정확히 구현하는 조직 모델은?

문제 12

한 회사가 "한 팀이 sandbox 계정에서 비용을 한 달에 \$30,000 쓴 사고가 발생했다. 같은 일이 재발하지 않게 하라"는 요구를 받았다. 가장 효과적인 조치 조합은?

Week 1 마무리 — 다음 주로 가는 다리

오늘까지 본 다섯 가지 — DevOps 운영 모델, CALMS/DORA, W-AF, 도구 지도, 멀티 계정 — 는 DOP-C02 도메인 1~6 전부의 배경이 된다. 도메인 1(SDLC)을 다음 주부터 본격적으로 들어가는데, 그때 만나게 될 CodePipeline / CodeBuild / CodeDeploy 시나리오는 모두 다음 두 질문 위에서 풀린다.

  1. "이 변경을 얼마나 빠르고 안전하게 흘려보낼 것인가" (DORA)
  2. "사고가 나면 얼마나 좁은 범위에서 멈출 것인가" (blast radius + 멀티 계정)

이 두 질문을 잊지 않으면 다음 주 트렁크 기반 개발, OIDC 페더레이션, CodeArtifact, 코드 서명 같은 주제들이 "각각 따로 외워야 할 도구"가 아니라 "같은 사고 프레임의 다른 부품"으로 보이기 시작할 것이다.

이전멀티 계정 전략: Organizations, Control Tower, IAM Identity Center의 진짜 그림Week 1 · Day 4다음 CodeCommit 심화: Git 호스팅을 IAM으로 통합하면 무엇이 달라지는가Week 2 · Day 1

이 페이지

  • 한 페이지 컴팩트 — Week 1 핵심
  • CALMS 5축 진단표 (가장 약한 축이 곧 다음 우선순위)
  • DORA 4 metrics → 처방 매핑
  • W-AF 6 Pillar → 시나리오 키워드
  • 멀티 계정 표준 구조
  • Week 1 시나리오 풀이 4단계 흐름
  • 종합 시나리오 12개
  • Week 1 마무리 — 다음 주로 가는 다리