Day 5 - Week 12 통합 복습: 인시던트 자동화의 전체 신경계를 하나로 잇기

한 주 동안 우리는 자동화 도메인을 부위별로 해부했다. EventBridge라는 신경계, SSM Automation이라는 절차의 코드화, Auto-healing이라는 반사 신경, ChatOps와 Incident Manager라는 사람 조직과의 접점. 오늘은 이 부위들을 다시 하나의 살아 있는 유기체로 조립한다. 실전에서 인시던트는 이 컴포넌트들을 따로 쓰지 않는다 — 하나의 탐지가 자동 복구를 부르고, 복구가 실패하면 사람을 호출하고, 사람이 ChatOps로 협응하고, 끝나면 포스트모템으로 학습이 순환된다. 이 전체 흐름을 머릿속에 단일 그림으로 그릴 수 있어야 DOP 시험의 복합 시나리오를 풀 수 있다.

Week 12 핵심을 하나의 흐름으로

                    [탐지 Sense]
   CloudWatch Alarm · GuardDuty · EC2 StatusCheck · Synthetics
                          │
                          ▼
              [라우팅 — EventBridge Day 1]
       Event Pattern 매칭 (결정 트리, 부분 일치, 배열=OR)
                          │
        ┌─────────────────┼──────────────────┬───────────────┐
        ▼                 ▼                  ▼               ▼
   [단순 자동복구]    [표준 절차]        [복잡 복구]      [Critical]
   Lambda Day 3     SSM Automation     Step Functions   Incident Mgr
   (격리·재시작)     Runbook Day 2      (Saga, Day 3)    Day 4 (ICS)
   Cooldown·Bounded  aws:approve 게이트                  Escalation
   ·Idempotent                                          Timeline·PIR
        │                 │                  │               │
        └─────────────────┴──────────────────┴───────────────┘
                          ▼
              [알림 Notify — Day 4]
   CodeStar Notifications → Chatbot(Slack) · PagerDuty(API Destination)
                          │
                          ▼
              [학습 Learn]  비난 없는 포스트모템 · Game Day(FIS)
                          │
                          ▼ (피드백 루프: 새 패턴을 자동 대응에 추가)

이 그림의 다섯 단계 — 탐지 → 라우팅 → 대응 → 알림 → 학습 — 가 Week 12 전체의 골격이다. 각 단계의 핵심을 다시 짚는다.

1. EventBridge(Day 1) — 자동화의 신경계. EAI/EIP의 메시지 버스·Content-Based Router를 구현해 발신자가 수신자를 모르게 결합도를 끊는다. Event Pattern 매칭은 순차 비교가 아니라 결정 트리(quamina/Rete 계열)로 컴파일되어 규칙 수에 무관하게 빠르고, 부분 일치·배열=OR 의미론을 가진다. Pipes(파이프-필터, 폴링 글루 제거), Scheduler(수백만 스케줄·Flexible Time Window 지터로 thundering herd 방지), Archive/Replay(이벤트 소싱 재처리), at-least-once 전달이라 컨슈머는 멱등해야 한다.

2. SSM Automation(Day 2) — 운영 절차를 코드로. Runbook(aws:executeAwsApi·aws:invokeLambdaFunction·aws:approve)으로 절차를 선언하고, aws:approve로 사람 게이트를 워크플로에 끼운다.

3. Auto-healing(Day 3) — 제어 이론의 폐쇄 루프(MAPE-K). MTTR↓가 MTBF↑보다 비용 효율적. 재시작·교체·격리·스케일·페일오버·회로차단 패턴. 플랫폼 내장(ASG ELB health check, StatusCheckFailed_System→ec2:recover) 우선. 안전망 3대 기둥(Idempotent·Cooldown·Bounded Action)이 blast radius 폭주를 막고(2017 S3 사고의 교훈), Circuit Breaker가 연쇄 장애를 끊으며, FIS Game Day로 검증한다.

4. ChatOps & Incident Manager(Day 4) — 사람 조직과의 접점. Chatbot(SNS-Slack 다리, IAM Role∩Guardrail), CodeStar Notifications(파이프라인 알림 표준), Incident Manager(ICS 사건 지휘 체계의 코드화: Response Plan·Escalation·Timeline·PIR), API Destination(외부 SaaS 통합).

5. 학습 — 비난 없는 포스트모템(스위스 치즈 모델·Just Culture)으로 데이터를 학습으로 전환해 피드백 루프를 닫는다.

💡 관련 이론: Week 12 전체는 사실 하나의 거대한 MAPE-K 루프(IBM Autonomic Computing)다 — Monitor(CloudWatch/GuardDuty) → Analyze(EventBridge 패턴 매칭) → Plan(어느 대응 경로로 보낼지) → Execute(Lambda/SSM/Step Functions/Incident Manager), 그리고 이 넷이 공유하는 Knowledge(런북·포스트모템·스키마 레지스트리). 개별 서비스를 외우는 대신 이 루프의 어느 단계에 무엇이 들어가는지로 이해하면, 처음 보는 시나리오도 "이건 Analyze 단계의 라우팅 문제군 → EventBridge"처럼 분해된다. 그리고 학습 단계가 Knowledge를 갱신해 다음 루프를 개선하는 것이 자율 시스템의 정수다.

컴포넌트 선택의 결정 트리

시험은 "이 상황에 어떤 서비스인가"를 묻는다. 헷갈리는 경계를 정리한다.

이 표의 밑바닥에는 일관된 원리가 흐른다 — "가능한 한 높은 추상화, 가능한 한 관리형(managed)". 같은 일을 Lambda로도 할 수 있지만, AWS가 관리형으로 제공하는 것(Pipes·Scheduler·ec2:recover·CodeStar Notifications·API Destination)이 있으면 그것을 쓴다. 이유는 셋이다. (1) 검증된 안전망 — 관리형 서비스는 AWS가 재시도·멱등성·레이트 리밋을 이미 검증했다. (2) 글루 코드 제거 — 직접 짜면 폴링·배치·에러·인증 갱신 같은 배관을 손으로 관리해야 한다. (3) 운영 부담 이전 — 패치·확장·가용성을 AWS가 진다. DOP 시험의 정답은 거의 항상 "운영 부담이 가장 적은 관리형 옵션"으로 수렴하며, "Lambda로 다 짠다"는 보통 오답 함정이다(되긴 하지만 운영 우수성 기둥에 반함).

통합 시나리오의 안티패턴

마지막으로, 이 컴포넌트들을 잘못 조립하는 흔한 안티패턴을 짚는다. 시험은 종종 "무엇이 잘못됐나"를 묻는다.

⚠️ 함정: 통합 자동화의 3대 안티패턴. (1) 멱등성 누락 — EventBridge·CloudWatch가 at-least-once라 중복 전달되는데 컨슈머가 멱등하지 않으면 이중 격리·이중 청구가 터진다. "이벤트가 가끔 두 번 처리됨"의 답은 거의 항상 컨슈머 멱등성 부재다. (2) 무한 자동 복구 — 개방 루프(결과 미확인)로 "재시작→실패→재시작"을 반복하거나, Cooldown·Bounded Action 없이 폭주한다(2017 S3). (3) 비가역 동작 자동화 — 격리(가역)는 자동이 맞지만 종료·삭제(비가역)를 사람 게이트 없이 자동화하면 오탐 시 데이터·증거를 영구 소실한다. 이 셋을 막는 것이 멱등성·안전망 3기둥·aws:approve 게이트다.

정리

Week 12는 "자동화"라는 한 단어 아래 다섯 층 — 탐지·라우팅·대응·알림·학습 — 을 쌓았다. 핵심 통찰은 이것들이 따로가 아니라 하나의 닫힌 피드백 루프(MAPE-K)라는 점이고, 각 층에서 AWS는 "가장 관리형인 옵션"을 정답으로 제시하며, 모든 자동화의 안전은 멱등성·blast radius 제한·비가역 동작 게이트라는 세 원칙 위에 선다는 것이다. 아래 시나리오 12개로 이 통합 그림을 점검한다.

📝 연습 문제

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

문제 1

GuardDuty가 Critical 위협(침해된 EC2가 C2 서버와 통신)을 탐지했다. 해당 인스턴스를 자동 격리하고 포렌식 스냅샷을 뜬 뒤, 종료는 운영자 승인을 받아 실행하는 흐름을 구성하려 한다. 가장 적합한 것은?

• ALambda 하나가 탐지·격리·스냅샷·종료를 모두 즉시 자동 실행해 사람 개입 없이 MTTR을 최소화
• BEventBridge가 GuardDuty Finding(severity 기준)을 패턴 매칭 → SSM Automation Runbook(aws:executeAwsApi로 격리·스냅샷, aws:approve로 종료 게이트)
• CCloudTrail 로그를 매분 폴링하는 Lambda가 C2 통신 흔적을 찾아 격리·스냅샷·종료를 실행
• DGuardDuty 알림을 SNS 이메일로만 전송하고 격리·스냅샷·종료를 전부 운영자가 수동 처리

문제 2

SQS 큐의 메시지를 폴링해 이벤트 패턴으로 1차 필터링하고, 부족한 정보를 외부 API로 보강한 뒤 DynamoDB에 저장하는 흐름을 글루 코드 없이 구성하려 한다. 가장 적합한 것은?

• ALambda를 직접 작성해 SQS 롱폴링·이벤트 필터·외부 API 보강·DynamoDB 저장을 한 함수에서 처리
• BEventBridge Pipes (Source: SQS → Filter → Enrichment → Target: DynamoDB)
• CEventBridge Rule로 SQS를 직접 이벤트 소스로 지정하고 Input Transformer로 보강 후 DynamoDB 타겟
• DSNS 팬아웃으로 메시지를 여러 구독자에 분배한 뒤 각자 필터·보강해 DynamoDB에 저장

문제 3

자동 복구 Lambda가 같은 알람의 중복 전달로 한 인스턴스를 두 번 격리하고, 짧은 간격으로 반복 트리거되어 자원을 소진하며, 한 번에 너무 많은 인스턴스를 건드린다. 폭주를 막는 안전망 조합은?

• ALambda 타임아웃과 메모리를 늘려 격리 동작이 중간에 끊기지 않게 완주를 보장한다
• BIdempotent(DynamoDB ConditionExpression) + Cooldown(lastActionTime, T초 내 재처리 금지) + Bounded Action(트리거당 최대 N개 상한)
• CEventBridge RetryPolicy를 0으로 설정해 재시도에 의한 중복 트리거를 원천 차단한다
• DCloudWatch Alarm 평가 주기를 늘려 중복·연속 트리거 빈도 자체를 낮춘다

문제 4

매일 새벽 3시 정각에 5만 개의 사용자별 백업 작업이 동시에 실행되며 다운스트림이 부하로 무너진다. 또한 이런 사용자별 스케줄이 수십만 개라 CloudWatch cron 규칙 수 한계에 부딪힌다. 올바른 해법은?

• Acron 시각을 02:59로 당겨 다운스트림이 한가한 시간대로 옮겨 부하 충돌을 회피한다
• BEventBridge Scheduler — 수백만 스케줄 지원 + Flexible Time Window로 실행을 윈도우에 분산(지터 주입, thundering herd 방지)
• CLambda 예약 동시성 한도를 크게 늘려 5만 개 동시 실행을 모두 수용하도록 확장한다
• D작업을 수동으로 10개 그룹으로 나눠 각각 다른 cron 시각에 배치해 부하를 시간 분산

문제 5

Critical 인시던트에서 on-call 1차 담당자가 30분 내 응답하지 않으면 자동으로 2차 그룹을, 그래도 무응답이면 매니저를 호출하고, 전 과정을 타임라인에 자동 기록하려 한다. AWS 네이티브 솔루션은?

• ASNS 토픽에 on-call 전원을 구독시켜 동시에 알림하고 먼저 응답한 사람이 처리하게 한다
• BAWS Incident Manager — Escalation Plan(N분 무응답 시 다음 단계) + Engagement(SMS/Voice/Email) + Timeline(자동 기록) + PIR
• CLambda가 30분마다 응답 여부를 폴링하며 무응답이면 다음 단계 그룹에 순차 SMS를 발송
• DCloudWatch Alarm을 단계별로 여러 개 만들어 시차를 두고 1차·2차·매니저에 알림

문제 6

Slack에서 운영자가 Chatbot으로 진단 명령은 자유롭게 실행하되, 실수로라도 prod EC2 종료·RDS 삭제는 절대 못 하게 하려 한다. IAM Role은 운영 편의상 넓게 유지하고 싶다. 올바른 구성은?

• AChatbot이 맡는 IAM Role을 read-only 권한으로만 제한해 어떤 변경·삭제도 못 하게 막는다
• BChatbot 채널 Guardrail Policy에 명시적 Deny(ec2:TerminateInstances, rds:Delete*) — IAM Role과 무관하게 봉쇄
• CSlack 채널을 비공개·초대제로 전환해 권한 있는 운영자만 위험 명령을 칠 수 있게 한다
• DChatbot의 명령 실행(run command) 기능을 끄고 조회·알림 수신 용도로만 사용한다

문제 7

EC2 인스턴스가 하부 호스트 하드웨어 장애로 응답하지 않는다. 같은 IP·ENI·EBS를 유지하며 건강한 하드웨어로 자동 복구하려 한다. 올바른 구성은?

• AASG에 넣고 health-check-type을 EC2로 설정
• BStatusCheckFailed_System 메트릭 알람 + ec2:recover 알람 액션
• CStatusCheckFailed_Instance 알람 + Lambda로 종료 후 재생성
• DRoute 53 헬스체크로 페일오버

문제 8

"RDS 페일오버 → 완료 대기 → 캐시 무효화 → 헬스 확인 → 실패 시 사람 에스컬레이션, 성공 시 Slack 보고 + 티켓"처럼 분기·대기·재시도·보상이 얽힌 복구를 구성하려 한다. 가장 적합한 것은?

• A단일 Lambda에 if-else 분기와 sleep 대기로 페일오버·무효화·헬스확인·에스컬레이션을 모두 구현
• BStep Functions State Machine — 각 단계 Retry/Catch, 상태 보존, Saga 보상
• C각 단계를 EventBridge Rule로 만들어 한 단계 완료 이벤트가 다음 Rule을 트리거하는 체인으로 연결
• Dcron으로 매분 폴링하는 Lambda가 현재 복구 단계를 확인해 다음 동작을 결정하며 진행

문제 9

CodePipeline 실패를 Slack 채널에 가장 단순하고 표준적으로 알리려 한다. 가장 적합한 것은?

• A파이프라인 실패 이벤트마다 Lambda를 트리거해 Slack Incoming Webhook을 직접 호출
• BCodeStar Notifications 규칙 → AWS Chatbot(Slack 채널) 타겟
• CCodePipeline의 CloudWatch Logs를 폴링하는 cron Lambda가 실패 로그를 찾아 Slack에 게시
• D파이프라인에 수동 승인 단계를 추가해 실패 시 승인자에게 Slack 알림이 가도록 구성

문제 10

운영팀이 자동 복구 로직을 만들었으나, 진짜 장애가 처음 발생했을 때 버그로 작동하지 않았다(2017 S3 사고의 재시작 경로처럼). 이런 "녹슨 자동화"를 평시에 발견하는 표준 접근은?

• A자동화 코드를 더 작성해 발생 가능한 모든 장애 경우의 수를 사전에 빠짐없이 커버한다
• BAWS FIS로 정기적으로 장애를 주입하고 Game Day로 자동 복구·알림·런북을 통째로 리허설(카오스 엔지니어링)
• C프로덕션에서 신뢰할 수 없는 자동 복구를 끄고 검증된 사람 중심 수동 대응만 운영한다
• D자동화 실패를 사후에 추적할 수 있도록 관련 로그의 보존 기간을 길게 늘린다

문제 11

EventBridge로 처리하는 결제 이벤트가 가끔 두 번 처리되어 이중 청구가 발생한다. 근본 원인과 해법은?

• AEventBridge가 이벤트를 중복 전달하는 것은 버그이므로 AWS 지원팀에 문의해 수정을 요청한다
• BEventBridge 전달은 at-least-once라 중복이 정상 — 컨슈머에 멱등성 로직(이벤트 ID 기반 중복 차단: DynamoDB conditional write, Lambda Powertools Idempotency)을 추가
• CEventBridge 타겟의 RetryPolicy를 0으로 설정해 재시도로 인한 중복 전달을 원천 제거한다
• D결제 컨슈머의 DLQ를 제거해 실패 이벤트가 재유입·재처리되지 않도록 경로를 단순화한다

문제 12

EventBridge에서 외부 SaaS(PagerDuty)로 인증을 포함해 인시던트를 안전하게 전송하되, 인증 갱신·레이트 리밋·재시도·시크릿 관리를 직접 코딩하지 않으려 한다. 가장 적합한 것은?

• ALambda가 PagerDuty REST API를 직접 호출하고 API Key를 환경 변수에 저장해 인증을 처리
• BEventBridge API Destination + Connection(인증을 Secrets Manager로 관리, 레이트 리밋, EventBridge 재시도·DLQ 활용)
• CSNS Email 구독으로 PagerDuty의 이메일 통합 주소에 인시던트 알림을 전송
• DS3에 이벤트를 쓰고 PagerDuty가 버킷을 주기적으로 폴링해 인시던트를 생성하게 한다

🔜 Week 13 예고

복원력 - DR, Multi-Region

Week 12가 "한 리전 안에서 장애를 감지·복구·협응"하는 신경계였다면, Week 13은 그 신경계가 리전 전체를 잃었을 때를 다룬다 — RTO/RPO의 수학, Backup·Pilot Light·Warm Standby·Multi-Site Active/Active의 비용-복구시간 트레이드오프, Route 53 페일오버, 그리고 리전 간 데이터 복제의 일관성 문제. Week 12의 자동 복구가 "노드 단위"였다면 Week 13은 "리전 단위"의 복구다.