From 4b12c0e5acfe0eab244bc7e6e3846a2e7a76e16a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Thu, 22 Oct 2026 04:08:35 +0000
Subject: [PATCH 1/7] docs-site: remove ADR references from the intro deck
 index

Split from #192 to stay under the AI review input limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .../presentation/awsops-intro/index.html      | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/docs-site/static/presentation/awsops-intro/index.html b/docs-site/static/presentation/awsops-intro/index.html
index c9518e3c8..5b3edc81c 100644
--- a/docs-site/static/presentation/awsops-intro/index.html
+++ b/docs-site/static/presentation/awsops-intro/index.html
@@ -188,7 +188,7 @@ <h3>보고서 작성 부담</h3>
 <div style="display:grid;grid-template-columns:1fr 1fr;gap:1rem;">
   <div style="background:var(--yellow-bg);border:1px solid var(--orange);border-radius:8px;padding:1.25rem;">
     <div style="color:var(--orange);font-weight:bold;font-size:1.125rem;margin-bottom:.5rem;">Bedrock AgentCore</div>
-    <div style="color:var(--text-secondary);line-height:1.6;">Claude Opus 4.8 / Sonnet 5 / Haiku 4.5<br>AgentCore Runtime + 섹션 에이전트<br>ADR-003 하이브리드 라우팅</div>
+    <div style="color:var(--text-secondary);line-height:1.6;">Claude Opus 4.8 / Sonnet 5 / Haiku 4.5<br>AgentCore Runtime + 섹션 에이전트<br>하이브리드 라우팅</div>
   </div>
   <div style="display:grid;grid-template-rows:1fr 1fr;gap:.75rem;">
     <div style="background:var(--yellow-bg);border:1px solid var(--orange);border-radius:8px;padding:.75rem;text-align:center;">
@@ -255,7 +255,7 @@ <h3>보고서 작성 부담</h3>
   <div class="slide-header" data-remarp-id="s6-header"><h2>AWSops — By the Numbers</h2></div>
   <div class="slide-body" data-remarp-id="s6-body">
     <p><!-- Slide 5: By the Numbers --></p>
-<table><thead><tr><th>항목</th><th>내용</th><th>설명</th></tr></thead><tbody><tr><td><strong>Infra</strong></td><td>Terraform MSA</td><td>비공개 엣지 — CloudFront VPC Origin → 내부 ALB → Fargate</td></tr><tr><td><strong>Compute</strong></td><td>ECS Fargate</td><td>web thin-BFF + OOM-safe 비동기 워커 티어 (arm64)</td></tr><tr><td><strong>Data</strong></td><td>Aurora Serverless v2</td><td>PostgreSQL 17 영속 상태 + 41종 인벤토리 sync</td></tr><tr><td><strong>AI Tools</strong></td><td>9 게이트웨이 설계 (160+ 도구) · 30개 슬라이스 전부 LIVE</td><td>AgentCore 섹션 에이전트 (모두 read-only; 9개 게이트웨이 전부 READY MCP 타깃)</td></tr><tr><td><strong>AI Routing</strong></td><td>ADR-003 하이브리드</td><td>regex fast-path + Haiku 분류기, 게이트 96.9%</td></tr><tr><td><strong>Diagnosis</strong></td><td>light·mid 9 / deep 16 섹션</td><td>Well-Architected 매핑, DOCX/PDF 내보내기</td></tr><tr><td><strong>UX</strong></td><td>3-테마 + 모바일 + 4개 언어</td><td>반응형 대시보드 + Cmd-K + 한/영/中/日 i18n</td></tr></tbody></table>
+<table><thead><tr><th>항목</th><th>내용</th><th>설명</th></tr></thead><tbody><tr><td><strong>Infra</strong></td><td>Terraform MSA</td><td>비공개 엣지 — CloudFront VPC Origin → 내부 ALB → Fargate</td></tr><tr><td><strong>Compute</strong></td><td>ECS Fargate</td><td>web thin-BFF + OOM-safe 비동기 워커 티어 (arm64)</td></tr><tr><td><strong>Data</strong></td><td>Aurora Serverless v2</td><td>PostgreSQL 17 영속 상태 + 41종 인벤토리 sync</td></tr><tr><td><strong>AI Tools</strong></td><td>9 게이트웨이 설계 (160+ 도구) · 30개 슬라이스 전부 LIVE</td><td>AgentCore 섹션 에이전트 (모두 read-only; 9개 게이트웨이 전부 READY MCP 타깃)</td></tr><tr><td><strong>AI Routing</strong></td><td>하이브리드</td><td>regex fast-path + Haiku 분류기, 게이트 96.9%</td></tr><tr><td><strong>Diagnosis</strong></td><td>light·mid 9 / deep 16 섹션</td><td>Well-Architected 매핑, DOCX/PDF 내보내기</td></tr><tr><td><strong>UX</strong></td><td>3-테마 + 모바일 + 4개 언어</td><td>반응형 대시보드 + Cmd-K + 한/영/中/日 i18n</td></tr></tbody></table>
   </div>
 </div>
 
@@ -296,7 +296,7 @@ <h3>For FinOps / Management</h3>
   <div style="background: var(--green-bg); border: 1px solid var(--green); border-radius: 12px; padding: 1.5rem; text-align: center;">
     <div style="font-size: 3rem; margin-bottom: .75rem;">🔒</div>
     <div style="color: var(--green); font-weight: bold; font-size: 1.125rem; margin-bottom: .5rem;">Read-Only Posture</div>
-    <div style="color: var(--text-muted); font-size: .875rem;">AWS 리소스 변경·자율 실행 동결<br>ADR-005 (FROZEN) / ADR-007 — 설계상 안전</div>
+    <div style="color: var(--text-muted); font-size: .875rem;">AWS 리소스 변경·자율 실행 동결<br>설계상 안전</div>
   </div>
   <div style="background: var(--accent-subtle); border: 1px solid var(--accent); border-radius: 12px; padding: 1.5rem; text-align: center;">
     <div style="font-size: 3rem; margin-bottom: .75rem;">📊</div>
@@ -311,7 +311,7 @@ <h3>For FinOps / Management</h3>
   <div class="slide-header" data-remarp-id="s10-header"><h2>Key Takeaways — 5가지 목표, 하나의 대시보드</h2></div>
   <div class="slide-body" data-remarp-id="s10-body">
     <p><!-- Slide 8: Block 1 Key Takeaways --></p>
-<ul><li><strong>① 가시성</strong> → Overview·Topology·Monitoring + NFM·Direct Connect까지 통합된 Network 6종 메뉴</li><li><strong>② FinOps</strong> → 읽기 전용 비용 분석 + Rightsizing 인사이트 + OpenCost 패널</li><li><strong>③ Well-Architected</strong> → 종합진단 리포트 자동 생성 (light·mid/deep, DOCX/PDF)</li><li><strong>④ 보안성</strong> → Security Findings + CIS Compliance 벤치마크, 둘 다 읽기 전용</li><li><strong>⑤ 장애 대응 AI</strong> → AI Assistant/Diagnosis가 메트릭·로그·트레이스·NFM 경로를 자연어로 교차 분석</li><li><strong>핵심 차별점</strong> → In-account Bedrock AI + 읽기 전용 태세 (ADR-005 FROZEN) + 4개 언어 UX</li></ul>
+<ul><li><strong>① 가시성</strong> → Overview·Topology·Monitoring + NFM·Direct Connect까지 통합된 Network 6종 메뉴</li><li><strong>② FinOps</strong> → 읽기 전용 비용 분석 + Rightsizing 인사이트 + OpenCost 패널</li><li><strong>③ Well-Architected</strong> → 종합진단 리포트 자동 생성 (light·mid/deep, DOCX/PDF)</li><li><strong>④ 보안성</strong> → Security Findings + CIS Compliance 벤치마크, 둘 다 읽기 전용</li><li><strong>⑤ 장애 대응 AI</strong> → AI Assistant/Diagnosis가 메트릭·로그·트레이스·NFM 경로를 자연어로 교차 분석</li><li><strong>핵심 차별점</strong> → In-account Bedrock AI + 읽기 전용 태세 + 4개 언어 UX</li></ul>
   </div>
 </div>
 
@@ -379,7 +379,7 @@ <h3>Foundation</h3>
 <p><strong>LIVE 오늘</strong>: workers · steampipe · agentcore · integrations · ai_cost_tracking · diagnosis_schedule · diagnosis_notify · eks_auto_register · hybrid_routing</p>
 </div><div class="col">
 <h3>Feature Flags (~17개, 전부 default-off = $0)</h3>
-<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>ADR-005 FROZEN</strong>, do-not-enable</li></ul>
+<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>FROZEN</strong>, do-not-enable</li></ul>
 </div>
 </div>
   </div>
@@ -394,7 +394,7 @@ <h3>Core Layers</h3>
 <table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>network.tf</code></td><td>VPC 신규/재사용</td></tr><tr><td><code>edge.tf</code></td><td>CloudFront + VPC Origin + ALB</td></tr><tr><td><code>auth.tf</code></td><td>Cognito + Lambda@Edge</td></tr><tr><td><code>data.tf</code></td><td>Aurora + schema</td></tr><tr><td><code>workload.tf</code></td><td>ECS web service</td></tr><tr><td><code>ecr.tf</code></td><td>dual-tier ECR</td></tr><tr><td><code>ai.tf</code></td><td>AgentCore + SSM</td></tr><tr><td><code>workers.tf</code></td><td>SQS + SFN + Lambda</td></tr></tbody></table>
 </div><div class="col">
 <h3>Gated Subsystems</h3>
-<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포 (ADR-015)</td></tr></tbody></table>
+<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포</td></tr></tbody></table>
 </div>
 </div>
   </div>
@@ -406,7 +406,7 @@ <h3>Gated Subsystems</h3>
     <div class="columns">
 <div class="col">
 <h3>Next.js 14 Standalone (arm64)</h3>
-<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트(ADR-009)</li></ul>
+<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트</li></ul>
 <h3>Routes</h3>
 <ul><li><code>/api/health</code> — 공개 헬스체크</li><li><code>/api/stream</code> — SSE 스트리밍</li><li><code>/api/db</code> — Aurora ping</li><li><code>/api/jobs</code> (+<code>/[id]</code>) — 비동기 작업</li></ul>
 </div><div class="col">
@@ -422,7 +422,7 @@ <h3>Routes</h3>
     <div class="columns">
 <div class="col">
 <h3>Aurora (PostgreSQL 17.9)</h3>
-<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>ADR-030 스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
+<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
 </div><div class="col">
 <h3>Steampipe = 인벤토리 sync ONLY</h3>
 <p><div style="background:rgba(0,255,136,0.08);border:1px solid rgba(0,255,136,0.3);border-radius:10px;padding:1rem;margin-top:0.5rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;margin-bottom:0.5rem;">warm Fargate → Aurora → /inventory/[type]</div><div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">flag-gated (<code style="color:#00ff88;">steampipe_enabled</code>)<br><b style="color:#00ff88;">41종</b> 리소스 타입 동기화<br>fan-out sync · registry-driven nav</div><div style="color:#ef4444;font-size:0.75rem;margin-top:0.625rem;border-top:1px solid rgba(239,68,68,0.3);padding-top:0.5rem;">NOT a live query engine — pg Pool / 라이브 조회 아님</div></div></p>
@@ -474,13 +474,13 @@ <h3>Steampipe = 인벤토리 sync ONLY</h3>
     <span style="background:rgba(168,85,247,0.18);color:#c4a0f7;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">ops</span>
     <span style="background:rgba(0,212,255,0.18);color:#7fd8ff;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">external-obs</span>
   </div>
-  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격, ADR-004) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 ADR-001/010에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
+  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 설계 원칙에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
 </div>
   </div>
 </div>
 
 <div class="slide" data-remarp-id="s8" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat — ADR-003</h2></div>
+  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat</h2></div>
   <div class="slide-body" data-remarp-id="s8-body">
     <div class="columns">
 <div class="col">
@@ -564,7 +564,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -604,7 +604,7 @@ <h3>Read-Only Query</h3>
 </div>
 
 <div class="slide" data-remarp-id="s14" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out (ADR-011)</h2></div>
+  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out</h2></div>
   <div class="slide-body" data-remarp-id="s14-body">
     <div class="columns">
 <div class="col">
@@ -612,7 +612,7 @@ <h3>Registry + Assume</h3>
 <ul><li>Aurora <strong>accounts</strong> 레지스트리 — 호스트 계정은 lazy seed</li><li>대상 계정 <code>AWSopsReadOnlyRole</code>을 host task role이 <strong>STS AssumeRole</strong></li><li><strong>ExternalId</strong> — 1st-party(trust policy가 task-role ARN 핀) = <strong>선택</strong>, 3rd-party/와일드카드 = <strong>필수</strong>(confused-deputy 방어)</li><li>글로벌 셀렉터: 단일 계정 스코프 / <code>__all__</code> = 전 계정 fan-out</li></ul>
 </div><div class="col">
 <h3>Safety</h3>
-<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
+<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
 </div>
 </div>
   </div>
@@ -625,7 +625,7 @@ <h3>Safety</h3>
 <div class="col">
 <h3>Cognito + Lambda@Edge</h3>
 <ul><li><strong>us-east-1</strong>, py3.12, viewer-request</li><li><strong>RS256 JWKS</strong> 서명 검증 (iss/aud/token_use)</li><li>OAuth <code>state</code> + <strong>PKCE public client</strong></li></ul>
-<h3>Login (ADR-002)</h3>
+<h3>Login</h3>
 <ul><li><strong>Primary</strong> = 자체 <code>/login</code> 폼</li><li>BFF <code>POST /api/auth/login</code> → 무서명 공개 <code>InitiateAuth(USER_PASSWORD_AUTH)</code> → <code>awsops_token</code> (id_token 12h)</li><li>Hosted UI PKCE = <strong>dark fallback</strong>, signout = 쿠키 삭제</li></ul>
 </div><div class="col">
 <p><div style="display:flex;flex-direction:column;gap:0.75rem;margin-top:0.5rem;"><div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;">🔒 Private Edge</div><div style="color:#8b95a5;font-size:0.8125rem;">공개 ALB 없음 — 진입점은 CloudFront 하나</div></div><div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00d4ff;font-weight:bold;font-size:0.9375rem;">🔑 ECS Secrets</div><div style="color:#8b95a5;font-size:0.8125rem;">execution role 권한 (task role 아님)</div></div><div style="background:rgba(168,85,247,0.1);border:1px solid rgba(168,85,247,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#a855f7;font-weight:bold;font-size:0.9375rem;">👤 Admin</div><div style="color:#8b95a5;font-size:0.8125rem;">SSM + Cognito group (fail-closed)</div></div></div></p>
@@ -670,16 +670,16 @@ <h3>Login (ADR-002)</h3>
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
+  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -693,7 +693,7 @@ <h3>Login (ADR-002)</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Key Takeaways — Architecture</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 19: Key Takeaways --></p>
-<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock</li></ul>
+<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>하이브리드 라우팅 + 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock</li></ul>
   </div>
 </div>
 
@@ -1124,7 +1124,7 @@ <h3>동작 흐름 (read-only)</h3>
 <h3>분석 결과 예시 (권장만)</h3>
 <ul><li>"<strong>payment</strong> Pod: CPU request 500m, 실사용 50m → <strong>90% 과할당</strong> (rightsizing 권장)"</li><li>"<strong>frontend</strong> Deployment: Memory limit 2Gi, 사용량 200Mi → <strong>다운사이징 권장</strong>"</li><li>"Node 3대 중 <strong>2대 활용률 15% 미만</strong> → 통합 검토"</li><li>"예상 월 절감 <strong>$1,200</strong> — 권장사항"</li></ul>
 <h3>Read-Only 원칙</h3>
-<blockquote><p>권장사항만 제시 · <strong>자동 적용 없음</strong> (mutating 설치 버튼은 <strong>ADR-005</strong>로 동결 — do-not-enable)</p></blockquote>
+<blockquote><p>권장사항만 제시 · <strong>자동 적용 없음</strong> (mutating 설치 버튼은 동결 — do-not-enable)</p></blockquote>
 </div>
 </div>
   </div>
@@ -1329,7 +1329,7 @@ <h3>스케줄 진단 (<code>diagnosis_schedule_enabled</code>)</h3>
 <ul><li><code>report_schedules</code> 테이블 — 주간 / 격주 / 월간 (<code>next_run_at</code> 기준)</li><li>hourly <strong><code>schedule_dispatcher</code></strong> — 스캔 후 <code>report</code> job enqueue</li><li>v1 <code>report-scheduler.ts</code> 패턴 승계</li></ul>
 </div><div class="col">
 <h3>알림 다이제스트 (병합·배포 완료)</h3>
-<ul><li><strong><code>diagnosis_digest.py</code></strong> — <code>notified_at IS NULL</code> 리포트를 ~15분 배치로 묶어 SNS 1건 발송 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 main 병합·라이브 배포됨; ADR-13이 승인한 건 스케줄 요약뿐이라 수동 실행분까지 묶는 현재 범위는 ADR 정리 대상)</li><li>완료 즉시 개별 발송(per-report) 방식 폐기 — 폭주 방지(하루 44건 → 1건)</li><li><strong>PII 스크러빙</strong> — Bedrock 호출 전 ARN·계정ID·이메일·IP·액세스키를 결정론적으로 마스킹 (현재 라이브)</li></ul>
+<ul><li><strong><code>diagnosis_digest.py</code></strong> — <code>notified_at IS NULL</code> 리포트를 ~15분 배치로 묶어 SNS 1건 발송 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 main 병합·라이브 배포됨)</li><li>완료 즉시 개별 발송(per-report) 방식 폐기 — 폭주 방지(하루 44건 → 1건)</li><li><strong>PII 스크러빙</strong> — Bedrock 호출 전 ARN·계정ID·이메일·IP·액세스키를 결정론적으로 마스킹 (현재 라이브)</li></ul>
 </div>
 </div>
   </div>
@@ -1404,7 +1404,7 @@ <h3>인증 & 온보딩</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Feature Tour: 멀티 계정 Security & Compliance</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 12: Feature Tour — Multi-Account Security & Compliance --></p>
-<p><strong>ADR-011</strong> — STS AssumeRole read-only fan-out (ExternalId: 1st-party 옵션 · 3rd-party 필수) · 계정별 보안/컴플라이언스 스코핑 · CVE Severity Distribution donut(ECR 스캔 집계).</p>
+<p><strong>멀티 계정</strong> — STS AssumeRole read-only fan-out (ExternalId: 1st-party 옵션 · 3rd-party 필수) · 계정별 보안/컴플라이언스 스코핑 · CVE Severity Distribution donut(ECR 스캔 집계).</p>
 <div class="columns">
   <div class="col">
     <h3>Security Findings Pipeline</h3>
@@ -1472,8 +1472,8 @@ <h3>AWSops가 제공하는 것</h3>
 <h3>핵심 차별점</h3>
 <ul><li><strong>in-account Bedrock</strong> (외부 AI SaaS API 없음)</li><li><strong>private edge</strong> (공개 ALB 없음, CloudFront VPC Origin)</li><li>OOM-safe 비동기 워커 티어</li></ul>
 </div><div class="col">
-<h3>Read-Only 자세 (ADR-005/007)</h3>
-<ul><li><strong>AWS-리소스 변경 + 자율 = 동결</strong> (ADR-005, do-not-enable)</li><li>외부 관측성 <strong>READ</strong> 허용</li><li>외부 기록 / 티켓 / 메시지 <strong>WRITE</strong> 는 거버넌스 하 허용
+<h3>Read-Only 자세</h3>
+<ul><li><strong>AWS-리소스 변경 + 자율 = 동결</strong> (do-not-enable)</li><li>외부 관측성 <strong>READ</strong> 허용</li><li>외부 기록 / 티켓 / 메시지 <strong>WRITE</strong> 는 거버넌스 하 허용
 <ul><li>SSRF · Secrets · DLP · human-gate · flag-OFF</li></ul></li><li>변경되는 것은 <strong>DATA</strong>, AWS 리소스가 아님</li></ul>
 <h3>시작하기</h3>
 <ol><li><code>make configure</code> → Terraform apply</li><li><code>make deploy</code></li><li>Cognito 사용자 추가 · <code>/login</code></li><li>어시스턴트에서 질문 시작</li></ol>
@@ -1506,43 +1506,43 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     2: "[1min] 총 65분 세션으로 3개 파트로 나누어 진행합니다.\n첫 번째로 왜 이런 도구가 필요한지, 두 번째로 어떻게 만들었는지, 세 번째로 실제로 어떻게 쓰는지를 보여드리겠습니다.",
     3: "⏸️ [3min] [요약]\n• 이 프로젝트를 시작할 때 세운 5가지 목표를 먼저 공유합니다.\n\n이 프로젝트를 시작할 때 5가지 목표를 세웠습니다.\n\n첫째, DevOps·SRE의 가시성 향상입니다. 콘솔을 오가지 않고 NFM 트래픽 분석, Direct Connect 상태, DNS·IP·VPC 엔드포인트·Network Firewall까지 한 화면에서 봅니다.\n\n\n둘째, FinOps로 비용을 최적화하는 것입니다. 읽기 전용 비용 분석과 rightsizing 인사이트, OpenCost 패널을 상시 확인합니다.\n\n셋째, Well-Architected 기준으로 아키텍처를 점검하는 것입니다. 종합진단 리포트가 6개 Pillar에 매핑되어 자동 생성됩니다.\n\n넷째, 보안성 향상입니다. Security Findings와 CIS Compliance 벤치마크를 상시 노출합니다.\n\n다섯째, 장애가 났을 때 AI가 트래픽과 원인을 분석하는 것입니다. NFM의 E2E hop path까지 포함해 자연어로 교차 분석합니다.\n\n\n이 5가지 목표가 앞으로 볼 모든 기능의 출발점입니다. 먼저 이걸 만들게 된 도전 과제부터 보겠습니다.",
     4: "❓ ⏸️ [3min] 클라우드 운영을 하다 보면 정말 많은 도전 과제에 직면합니다.\n\n첫 번째는 Console Hopping입니다. 하나의 이슈를 해결하려면 EC2 콘솔에서 시작해서 CloudWatch로 메트릭 보고, VPC에서 네트워크 확인하고, IAM에서 권한 체크하고... 평균 5-7개 콘솔을 돌아다녀야 합니다. 멀티 어카운트면 로그인만 해도 지칩니다.\n\n\n\n두 번째는 데이터 사일로입니다. CloudWatch 메트릭, Prometheus 메트릭, 로그, 트레이스가 각각 다른 시스템에 있어서 교차 분석이 어렵습니다. \"CPU가 높아졌는데 어떤 서비스 때문이지?\" 라는 질문에 답하려면 여러 도구를 동시에 봐야 합니다.\n\n세 번째, 네 번째도 마찬가지로 반복 작업과 보고서 부담이 큽니다.\n\n\n여러분도 이런 경험 있으시죠? 특히 FinOps 리포트를 매달 수동으로 만들어 본 경험이 있으신 분?\n\n\nAWSops는 이 4가지 문제를 동시에 해결합니다.",
-    5: "⏸️ [3min] AWSops는 3개 레이어로 구성됩니다.\n\n\nData Layer는 Aurora Serverless v2가 중심입니다. PostgreSQL 17 기반으로 worker 작업, chat 스레드, 진단 리포트 같은 영속 상태를 안전하게 저장합니다. 인벤토리는 flag로 켜는 Steampipe sync가 41종 리소스 타입을 Aurora로 동기화해 화면에 보여주는 보조 역할입니다. 라이브 조회 엔진이 아니라 인벤토리 캐시라는 점이 핵심입니다.\n\nAI Engine은 Bedrock입니다. Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)로 설계되어 160개 이상의 읽기 전용 도구를 갖췄고, 함대 배포가 완료되어 30개 슬라이스 전부, 9개 게이트웨이 전부 READY MCP 타깃을 보유하고 있습니다. 라우팅은 ADR-003 하이브리드 방식으로 빠르고 정확합니다.\n\nDashboard는 Next.js 14 thin-BFF입니다. Overview, AI Diagnosis, Assistant, Security, Compliance, Topology, Monitoring, Accounts, Integrations, Jobs, Customization까지 하나의 대시보드로 통합되어 있고, 화면에 보이는 스크린샷처럼 실제 라이브 v2 환경입니다. 무거운 작업은 비동기 워커 티어로 넘깁니다.\n\n\n구체적인 숫자를 보겠습니다.",
+    5: "⏸️ [3min] AWSops는 3개 레이어로 구성됩니다.\n\n\nData Layer는 Aurora Serverless v2가 중심입니다. PostgreSQL 17 기반으로 worker 작업, chat 스레드, 진단 리포트 같은 영속 상태를 안전하게 저장합니다. 인벤토리는 flag로 켜는 Steampipe sync가 41종 리소스 타입을 Aurora로 동기화해 화면에 보여주는 보조 역할입니다. 라이브 조회 엔진이 아니라 인벤토리 캐시라는 점이 핵심입니다.\n\nAI Engine은 Bedrock입니다. Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)로 설계되어 160개 이상의 읽기 전용 도구를 갖췄고, 함대 배포가 완료되어 30개 슬라이스 전부, 9개 게이트웨이 전부 READY MCP 타깃을 보유하고 있습니다. 라우팅은 하이브리드 방식으로 빠르고 정확합니다.\n\nDashboard는 Next.js 14 thin-BFF입니다. Overview, AI Diagnosis, Assistant, Security, Compliance, Topology, Monitoring, Accounts, Integrations, Jobs, Customization까지 하나의 대시보드로 통합되어 있고, 화면에 보이는 스크린샷처럼 실제 라이브 v2 환경입니다. 무거운 작업은 비동기 워커 티어로 넘깁니다.\n\n\n구체적인 숫자를 보겠습니다.",
     6: "[1min] [요약]\n• 슬라이드웨어 목업이 아니라 실제 라이브 v2 환경 캡처\n\n지금 보시는 건 mockup이 아니라 실제 운영 중인 v2 대시보드 화면입니다.\n\n\n숫자로 다시 정리해 보겠습니다.",
-    7: "[2min] 숫자보다 구조로 보면 더 명확합니다.\n\n인프라는 Terraform 기반 MSA입니다. 공개 ALB 없이 CloudFront VPC Origin이 내부 ALB를 거쳐 Fargate로 들어오는 비공개 엣지 구조입니다. 컴퓨트는 ECS Fargate로, 웹 thin-BFF와 OOM에 안전한 비동기 워커 티어가 분리되어 있습니다. 모두 arm64입니다.\n\n데이터는 Aurora Serverless v2, PostgreSQL 17로 영속 상태를 보관하고, 인벤토리는 41종 리소스 타입을 sync합니다.\n\nAI는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)에 160개 이상의 읽기 전용 도구가 설계되어 있고, 30개 슬라이스 전부 함대 배포되어 9개 게이트웨이 전부 READY 상태입니다. 라우팅은 ADR-003 하이브리드로 게이트 정확도 96.9%를 달성했습니다. 진단은 light·mid 티어가 9섹션(기본 8 + 의도-실제 드리프트 1), deep 티어가 16섹션이며 Well-Architected에 매핑되고 DOCX/PDF로 뽑을 수 있습니다. UX 쪽은 3-테마·모바일 대응에 더해 한국어/English/中文/日本語 4개 언어를 완전히 지원합니다 — 일본어는 최근 복원되어 전체 화면 번역 커버리지 점검까지 마쳤습니다.\n\n\n이게 어떤 가치를 만드는지 보겠습니다.",
+    7: "[2min] 숫자보다 구조로 보면 더 명확합니다.\n\n인프라는 Terraform 기반 MSA입니다. 공개 ALB 없이 CloudFront VPC Origin이 내부 ALB를 거쳐 Fargate로 들어오는 비공개 엣지 구조입니다. 컴퓨트는 ECS Fargate로, 웹 thin-BFF와 OOM에 안전한 비동기 워커 티어가 분리되어 있습니다. 모두 arm64입니다.\n\n데이터는 Aurora Serverless v2, PostgreSQL 17로 영속 상태를 보관하고, 인벤토리는 41종 리소스 타입을 sync합니다.\n\nAI는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)에 160개 이상의 읽기 전용 도구가 설계되어 있고, 30개 슬라이스 전부 함대 배포되어 9개 게이트웨이 전부 READY 상태입니다. 라우팅은 하이브리드로 게이트 정확도 96.9%를 달성했습니다. 진단은 light·mid 티어가 9섹션(기본 8 + 의도-실제 드리프트 1), deep 티어가 16섹션이며 Well-Architected에 매핑되고 DOCX/PDF로 뽑을 수 있습니다. UX 쪽은 3-테마·모바일 대응에 더해 한국어/English/中文/日本語 4개 언어를 완전히 지원합니다 — 일본어는 최근 복원되어 전체 화면 번역 커버리지 점검까지 마쳤습니다.\n\n\n이게 어떤 가치를 만드는지 보겠습니다.",
     8: "⏸️ [3min] 두 가지 관점에서 가치를 드립니다.\n\nDevOps나 SRE 분들에게는 콘솔 호핑 없이 한 화면에서 모든 리소스를 보고, AI에게 자연어로 질문하면 됩니다. \"이 EC2 인스턴스가 왜 느려?\"라고 물으면 CloudWatch 메트릭을 확인하고, 네트워크 경로를 분석하고, 관련 로그를 찾아줍니다. 모두 읽기 전용이고, 응답은 스트리밍으로 흐릅니다. Topology와 EKS 읽기 전용 뷰에 더해, NFM 트래픽 top-contributor와 E2E hop path, Direct Connect 피크 사용률·BGP 라우트, DNS·IP·VPC 엔드포인트·Network Firewall까지 네트워크 6종 메뉴가 같은 대시보드에 통합되어 있습니다. Prometheus·Loki·Tempo 같은 데이터소스 Explore도 함께 제공합니다.\n\n\n\nFinOps나 Management 분들에게는 읽기 전용 비용 분석과 rightsizing 인사이트를 드립니다. 중요한 건 권고만 제시하고 자동으로 바꾸지 않는다는 점입니다. 그리고 종합진단 리포트를 light·mid 티어 9섹션, deep 티어 16섹션으로 만들고, Well-Architected에 매핑해 DOCX와 PDF로 내보냅니다. 무거운 생성 작업은 비동기 워커가 처리하므로 수작업 2-3일이 사라집니다.\n\n\n가장 중요한 차별점을 보겠습니다.",
     9: "[1min] [요약]\n• Cmd-K로 어디서든 키보드 이동\n• 한/영/中/日 4개 언어, 최근 일본어 복원 + 전체 커버리지 점검\n\nCmd-K 커맨드 팔레트로 마우스 없이 전체 화면을 이동할 수 있고, 한국어·English·中文·日本語 4개 언어를 완전히 지원합니다. 일본어는 최근 복원되면서 전체 화면 번역 커버리지 점검도 함께 마쳤습니다.\n\n\n가장 중요한 차별점을 보겠습니다.",
-    10: "❓ [3min] AWSops의 차별점은 세 가지로 압축됩니다.\n\n첫째, In-Account Bedrock AI입니다. AI 추론을 고객 AWS 계정 안의 Bedrock에서 직접 호출합니다. OpenAI 같은 외부 AI SaaS API를 쓰지 않으므로 데이터가 계정 밖으로 나가지 않습니다. 금융, 공공, 의료처럼 데이터 주권이 중요한 환경에 적합합니다.\n\n둘째, 읽기 전용 운영 태세입니다. ADR-005 기준으로 AWS 리소스 변경과 자율 실행은 동결(FROZEN, 새 명시적 결정 전까지)되어 있습니다. AI가 진단하고 권고할 뿐 직접 바꾸지 않으므로, 설계 단계에서부터 안전합니다. \"read-only\"는 AWS 리소스에 한정된 정의이고, 외부 관측성 데이터소스의 읽기/쓰기는 ADR-007 거버넌스 하에 별도로 허용됩니다.\n\n셋째, AI 종합진단 리포트입니다. Well-Architected에 매핑된 light·mid 9섹션, deep 16섹션 리포트를 비동기 워커가 생성하고 DOCX와 PDF로 내보냅니다.\n\n\n외부 AI SaaS에 운영 데이터를 보내는 게 부담스러웠던 분 계시죠? AWSops는 그 경로 자체가 없습니다.\n\n\n이제 아키텍처를 자세히 살펴보겠습니다.",
+    10: "❓ [3min] AWSops의 차별점은 세 가지로 압축됩니다.\n\n첫째, In-Account Bedrock AI입니다. AI 추론을 고객 AWS 계정 안의 Bedrock에서 직접 호출합니다. OpenAI 같은 외부 AI SaaS API를 쓰지 않으므로 데이터가 계정 밖으로 나가지 않습니다. 금융, 공공, 의료처럼 데이터 주권이 중요한 환경에 적합합니다.\n\n둘째, 읽기 전용 운영 태세입니다. AWS 리소스 변경과 자율 실행은 동결(FROZEN)되어 있습니다. AI가 진단하고 권고할 뿐 직접 바꾸지 않으므로, 설계 단계에서부터 안전합니다. \"read-only\"는 AWS 리소스에 한정된 정의이고, 외부 관측성 데이터소스의 읽기/쓰기는 거버넌스 하에 별도로 허용됩니다.\n\n셋째, AI 종합진단 리포트입니다. Well-Architected에 매핑된 light·mid 9섹션, deep 16섹션 리포트를 비동기 워커가 생성하고 DOCX와 PDF로 내보냅니다.\n\n\n외부 AI SaaS에 운영 데이터를 보내는 게 부담스러웠던 분 계시죠? AWSops는 그 경로 자체가 없습니다.\n\n\n이제 아키텍처를 자세히 살펴보겠습니다.",
     11: "[2min] 첫 번째 파트를 정리하겠습니다.\n\nAWSops는 처음 세운 5가지 목표를 하나의 대시보드 안에서 동시에 해결합니다.\n가시성은 Overview·Topology·Monitoring에 NFM·Direct Connect를 포함한 네트워크 6종 메뉴까지 통합해서, FinOps는 읽기 전용 비용 분석과 Rightsizing으로, Well-Architected 점검은 자동 생성되는 종합진단 리포트로, 보안성은 Security Findings와 CIS Compliance로, 장애 대응은 AI가 메트릭·로그·트레이스·NFM 경로를 함께 교차 분석하는 것으로 풀었습니다.\n\n그리고 가장 중요한 것은, AI 추론을 고객 계정 안 Bedrock에서 돌리고, AWS 리소스 변경과 자율 실행은 동결한 읽기 전용 태세라는 점입니다. 설계상 안전합니다.\n\n\n5분 쉬고 아키텍처를 자세히 보겠습니다.",
     12: "[1min] 두 번째 파트, 아키텍처 딥다이브입니다.\nAWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다.\n핵심은 세 가지입니다. 첫째, Terraform 기반 MSA로 재구축했다는 점. 둘째, 공개 진입점이 없는 비공개 엣지 구조라는 점. 셋째, 읽기 전용 운영 태세 위에 모든 것이 설계되었다는 점입니다.\n\n전체 그림부터 보겠습니다.",
     13: "⏸️ [3min] 전체 구조는 4개 레이어의 비공개 엣지입니다.\n브라우저는 전용 도메인으로 들어오고, CloudFront가 TLS로 받습니다. 여기서 VPC Origin을 https-only 443으로 설정해 내부 ALB까지 TLS가 끊기지 않게 합니다. origin 도메인을 public FQDN으로 지정해 SNI가 맞아야 합니다.\n\n핵심은 공개 ALB가 없다는 점입니다. 내부 ALB의 보안 그룹은 CloudFront 관리형 SG에서 오는 443만 허용합니다. VPC CIDR만 열면 504가 납니다. ALB는 HTTP로 Fargate의 web 컨테이너 3000번 포트로 전달합니다.\n영속 상태는 Aurora에 두고, 라이브 AWS 조회는 AgentCore MCP 도구가, 무거운 작업은 비동기 워커가 처리합니다.\n\n이 인프라를 어떻게 코드로 관리하는지 보겠습니다.",
-    14: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 ADR-005 동결 상태이고, integrations_write는 off이지만 ADR-007 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
-    15: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 ADR-005로 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
-    16: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`, ADR-009)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
-    17: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 ADR-030 기반 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
+    14: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 동결 상태이고, integrations_write는 off이지만 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
+    15: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
+    16: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
+    17: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
     18: "⏸️ [2min] AI 엔진은 Bedrock AgentCore입니다.\n모델은 Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore Runtime이 Strands 기반 `agent/agent.py`를 실행합니다. Memory와 Code Interpreter도 함께 붙어 있습니다.\n\n설정의 source of truth는 SSM입니다. provision.py가 runtime ARN, interpreter ID, memory ID를 `/ops/awsops-v2/agentcore/` 경로에 기록하고, 웹 BFF가 런타임에 읽습니다. valueFrom 레이스를 피하려는 의도적 설계입니다.\n\n이 런타임이 어떤 도구를 들고 있는지 보겠습니다.",
-    19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
-    20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
+    19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. 2026년 6월 24일에 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
+    20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     21: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
-    22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
+    22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     23: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",
     24: "⏸️ [3min] 관측성 데이터는 읽기 전용 데이터소스 플랫폼으로 통합합니다.\nClickHouse, Prometheus, Loki, Tempo, Mimir 커넥터를 지원합니다. 각 커넥터는 Lambda로 구현되고, 스키마는 Aurora에 캐시합니다. 이 데이터를 챗에 주입하면 AI가 여러 데이터소스를 교차 조회할 수 있습니다. `/datasources` Explore 페이지에서는 자연어를 쿼리로 변환해 직접 탐색할 수도 있습니다. 모두 읽기 전용입니다.\n\n토폴로지는 리소스 간 관계를 그래프로 보여줍니다. flow 그래프와 infra 리소스 그래프 두 가지가 있고, CloudFront에서 로드밸런서, 타깃 그룹, DB로 이어지는 경로를 시각화합니다. `/topology/resource/[id]`로 들어가면 개별 리소스의 상세 패널을 볼 수 있습니다.\n\n컨테이너 운영자를 위한 EKS 통합을 보겠습니다.",
     25: "⏸️ [3min] EKS도 읽기 전용으로 통합되는데, 인증 경로가 3가지로 늘었습니다. 원래 경로는 configure.mjs 멀티선택으로 시작해서 eks.tf가 웹 task role에 Access Entry를 부여하고 AmazonEKSAdminViewPolicy를 클러스터 스코프로 붙이는 방식입니다. View가 아니라 AdminView인 이유는, View 정책엔 클러스터 스코프 리소스가 없어서 노드 목록 조회가 403이 나기 때문입니다. AdminView는 */*/get,list,watch라 시크릿까지 읽을 수 있지만, BFF가 노출하는 kind는 화이트리스트로 제한되어 있어서 시크릿·컨피그맵은 절대 통과하지 않습니다.\n\n여기에 sa-token과 assume-role 두 가지 경로가 Aurora의 eks_registrations.auth에 더해졌습니다. 클러스터별로 등록하면 되고 terraform 온보딩이 필요 없습니다. 그리고 지금 라이브인 auto-register 경로가 있는데, EventBridge가 CloudTrail의 AssociateAccessPolicy나 DeleteAccessEntry 이벤트를 잡아서 Lambda를 거쳐 eks_registrations에 자동으로 기록합니다. 버튼을 누를 필요가 없습니다.\n조회는 nodes, pods, deployments, services 같은 핵심 리소스를 BFF가 직접 처리합니다. 워커를 거치지 않습니다. 그리고 한 가지 더, ListClusters·DescribeCluster 같은 핵심 discovery 권한은 이제 게이트가 아니라 workload.tf에 상시로 붙어 있습니다. 그래서 온보딩 플래그가 꺼져 있어도 /api/eks, /api/overview, /api/cost는 항상 정상 동작합니다.\nEKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워크로드 뷰가 있습니다.\n\n계정을 하나 더 늘리면 어떻게 되는지, 멀티 계정 구조를 보겠습니다.",
-    26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
-    27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
+    26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
+    27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     28: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 \"영구 금지\"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 \"안전조건 충족 + 새로운 명시적 결정 전까지\" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
-    30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
+    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 별도의 명시적인 제품 결정이 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     31: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다.",
     32: "[1min] 마지막 파트입니다. 지금까지 왜 필요한지, 어떻게 만들었는지를 봤고, 이제 실제로 어떻게 쓰는지를 데모로 보여드리겠습니다.\nAI 어시스턴트, 비용/인벤토리/토폴로지 시나리오, 그리고 종합진단 리포트까지 순서대로 보겠습니다.\n\n한 가지 먼저 짚고 갈 점은, 오늘 보여드리는 모든 데모는 read-only라는 것입니다. 조회와 진단만 하고, AWS 리소스를 변경하지 않습니다.\n\n먼저 AI 어시스턴트 데모입니다.",
-    33: "⏸️ [2min] AI 어시스턴트의 동작 흐름을 보겠습니다. 자연어 질문 하나가 답변으로 이어지는 과정입니다.\n\n사용자가 \"EKS 비용 개선점 찾아줘\"라고 질문합니다. 첫 단계는 ADR-003 하이브리드 라우팅입니다. regex fast-path가 먼저 매칭을 시도하고, 애매하면 Haiku 분류기가 판단합니다. 프롬프트 캐싱으로 약 59% 히트율을 내고, 이 질문은 cost 섹션 게이트웨이로 라우팅됩니다.\n\n\n\n선택된 AgentCore 섹션 에이전트가 MCP 도구로 라이브 read-only AWS 조회를 수행합니다. Cost Explorer, EKS 메트릭 등 필요한 도구만 호출합니다. 그리고 in-account Bedrock이 결과를 분석합니다.\n\n\n같은 질문이 실제 화면에서 어떻게 보이는지 이어서 보겠습니다.",
+    33: "⏸️ [2min] AI 어시스턴트의 동작 흐름을 보겠습니다. 자연어 질문 하나가 답변으로 이어지는 과정입니다.\n\n사용자가 \"EKS 비용 개선점 찾아줘\"라고 질문합니다. 첫 단계는 하이브리드 라우팅입니다. regex fast-path가 먼저 매칭을 시도하고, 애매하면 Haiku 분류기가 판단합니다. 프롬프트 캐싱으로 약 59% 히트율을 내고, 이 질문은 cost 섹션 게이트웨이로 라우팅됩니다.\n\n\n\n선택된 AgentCore 섹션 에이전트가 MCP 도구로 라이브 read-only AWS 조회를 수행합니다. Cost Explorer, EKS 메트릭 등 필요한 도구만 호출합니다. 그리고 in-account Bedrock이 결과를 분석합니다.\n\n\n같은 질문이 실제 화면에서 어떻게 보이는지 이어서 보겠습니다.",
     34: "🎬 [1min] 응답은 SSE 스트리밍으로 실시간 전달되고, 어떤 라우트와 도구가 쓰였는지 UI에 함께 표시됩니다. 대화는 Aurora에 thread로 영속 저장되어, 사이드바에서 이어보기가 가능합니다. resizable drawer나 /assistant 전체 화면 어디서든 같은 thread를 씁니다.\n\n\n(데모) 어시스턴트에서 질문을 입력하고, 라우트 분류와 도구 호출, 그리고 스트리밍 답변을 보여줍니다.\n\n\n다음은 비용 분석 시나리오입니다.",
     35: "⏸️ [2min] 첫 번째 시나리오는 비용 분석과 rightsizing 인사이트입니다.\n\n\"비용 개선점 찾아줘\"라고 입력하면 cost 섹션 게이트웨이로 라우팅됩니다. cost 에이전트가 Cost Explorer와 Forecast를 read-only로 조회하고, Cost 대시보드가 서비스별 비용과 추이를 시각화합니다.\n\n\n\nEKS 워크로드는 read-only 메트릭으로 request 대비 실사용량을 비교합니다. 과할당된 파드와 다운사이징 후보, 통합 가능한 노드를 식별합니다. 결과는 구체적인 절감 추정치와 함께 제시됩니다.\n\n\n실제 Cost 대시보드 화면을 보겠습니다.",
-    36: "[1min] 여기서 중요한 점은, AWSops는 권장사항만 제시한다는 것입니다. 어떤 변경도 자동으로 적용하지 않습니다. 과거 설계에 있던 OpenCost mutating 설치 버튼은 **ADR-005**(AWS 리소스 변경·자율 조치 = FROZEN)로 동결됐습니다. 진단과 권고까지가 AWSops의 역할이고, 적용 결정과 실행은 운영자의 몫입니다.\n\n\n다음은 인벤토리와 유휴 리소스 점검입니다.",
+    36: "[1min] 여기서 중요한 점은, AWSops는 권장사항만 제시한다는 것입니다. 어떤 변경도 자동으로 적용하지 않습니다. 과거 설계에 있던 OpenCost mutating 설치 버튼은 AWS 리소스 변경·자율 조치 동결(FROZEN) 원칙에 따라 동결됐습니다. 진단과 권고까지가 AWSops의 역할이고, 적용 결정과 실행은 운영자의 몫입니다.\n\n\n다음은 인벤토리와 유휴 리소스 점검입니다.",
     37: "⏸️ [1min] 두 번째 시나리오는 인벤토리와 유휴 리소스 점검입니다.\n\nAWSops는 41가지 리소스 타입을 제네릭 `/inventory/[type]` 페이지로 제공합니다. 이 데이터는 flag-gated Steampipe sync가 warm Fargate에서 돌면서 Aurora로 적재한 것입니다. registry 기반으로 내비게이션이 자동 구성되고, 페이지마다 KPI, donut, 필터로 구성된 mini-dashboard가 붙습니다.\n\n\n\n여기서 분명히 할 점은, Steampipe는 인벤토리 sync 전용이라는 것입니다. 라이브 쿼리 엔진이 아닙니다. 실시간 조회와 분석은 AgentCore MCP 도구가 담당합니다. 인벤토리 화면에서 후보를 좁히고, 에이전트로 라이브 현황을 보강하는 방식입니다.\n\n\n실제 인벤토리 화면을 보겠습니다.",
     38: "[1min] 미연결 EBS, 미사용 Elastic IP, 오래된 스냅샷, 중지된 EC2, 참조 없는 Security Group 같은 후보를 read-only로 점검합니다. 변경은 하지 않고, 검토 대상만 정리합니다.\n\n\n세 번째 시나리오, 토폴로지입니다.",
     39: "⏸️ [2min] 세 번째 시나리오는 토폴로지와 의존성 시각화입니다.\n\nAWSops는 flow 그래프와 infra 리소스 그래프 두 가지를 제공합니다. CloudFront에서 시작해 Load Balancer, Target Group, Database로 이어지는 CF → LB → TG → DB 체인을 한눈에 보여줍니다.\n\n\n\n리소스 노드를 클릭하면 `/topology/resource/[id]` 상세 페이지로 이동합니다. 해당 리소스가 무엇에 연결되어 있고 무엇이 그것에 의존하는지를 추적할 수 있습니다. 최근에는 그래프 자체가 **계정별로 스코핑**되어, 멀티 계정 환경에서 계정 단위로 필터링해 볼 수 있습니다.\n\n\n실제 토폴로지 그래프 화면을 보겠습니다.",
     40: "[1min] 이것이 진단에 중요한 이유는 blast radius, 즉 영향 범위 분석 때문입니다. 어떤 리소스에 문제가 생겼을 때 그 영향이 어디까지 전파되는지, 어떤 의존 관계를 끊어야 하는지를 그래프로 따라갈 수 있습니다. VPC 상세 패널에서는 풀스크린 **VPC Resource Map**을 열 수 있는데, VPC → Subnet(AZ별) → Route Table → IGW/NAT/TGW까지 라우팅 구조를 한 화면에서 클릭으로 하이라이트하며 추적합니다. 과거의 자율 인시던트 수집 루프 대신, 사람이 그래프를 보며 의존 관계를 진단하는 read-only 방식입니다.\n\n\n이제 플래그십 기능인 종합진단 리포트를 보겠습니다.",
-    41: "⏸️ [2min] AI 종합진단 리포트는 AWSops의 플래그십 기능입니다. 전부 read-only로 동작합니다.\n\n리포트는 두 등급입니다. light·mid는 9개 섹션, deep는 16개 섹션이고 Well-Architected Framework에 매핑됩니다. deep 등급은 기본 Sonnet으로 동작하고, 필요하면 cost-gate를 거쳐 Opus를 선택할 수 있습니다.\n\n\n\n실행은 비동기 워커 티어에서 일어납니다. 웹은 thin-BFF라 무거운 작업을 직접 돌리지 않고 워커 큐에 넣는데, 진단 잡은 범용 `POST /api/jobs`가 아니라 소유권을 검사하는 전용 라우트 `/api/diagnosis`로 제출합니다(ADR-009, IDOR 방지 — 범용 라우트는 `noop` 계열만 허용). SQS, Step Functions, Lambda 또는 Fargate 워커가 받아서 섹션을 분석합니다. 진행 상황은 SSE로 실시간 표시됩니다. \"3/16 Security Posture 분석 중\" 같은 상태가 클라이언트에 흐릅니다.\n\n\n완성된 리포트 화면을 보겠습니다.",
+    41: "⏸️ [2min] AI 종합진단 리포트는 AWSops의 플래그십 기능입니다. 전부 read-only로 동작합니다.\n\n리포트는 두 등급입니다. light·mid는 9개 섹션, deep는 16개 섹션이고 Well-Architected Framework에 매핑됩니다. deep 등급은 기본 Sonnet으로 동작하고, 필요하면 cost-gate를 거쳐 Opus를 선택할 수 있습니다.\n\n\n\n실행은 비동기 워커 티어에서 일어납니다. 웹은 thin-BFF라 무거운 작업을 직접 돌리지 않고 워커 큐에 넣는데, 진단 잡은 범용 `POST /api/jobs`가 아니라 소유권을 검사하는 전용 라우트 `/api/diagnosis`로 제출합니다(IDOR 방지 — 범용 라우트는 `noop` 계열만 허용). SQS, Step Functions, Lambda 또는 Fargate 워커가 받아서 섹션을 분석합니다. 진행 상황은 SSE로 실시간 표시됩니다. \"3/16 Security Posture 분석 중\" 같은 상태가 클라이언트에 흐릅니다.\n\n\n완성된 리포트 화면을 보겠습니다.",
     42: "[1min] 완성된 리포트는 자동 제목과 태그가 붙고, 소프트 삭제를 지원합니다. 리포트 목록과 상세 화면에서 열람할 수 있습니다.\n\n\n이 리포트를 어떻게 내보내는지 보겠습니다.",
     43: "⏸️ [2min] 완성된 리포트는 워커가 직접 문서로 내보냅니다.\n\nDOCX는 python-docx로, PDF는 chromium과 playwright로 렌더링합니다. 한글이 깨지지 않도록 Noto CJK 폰트를 워커 이미지에 포함했습니다. 내보내기는 워커 티어에서 실행되고, 실패해도 본 리포트 생성과 격리되어 영향을 주지 않습니다. 과거의 브라우저 Print-to-PDF 방식을 대체한 것입니다.\n\n\n\n생성된 파일은 S3의 `diagnosis/{id}.docx`와 `.pdf` 경로에 저장되고, BFF 프록시 라우트로 다운로드합니다. 생성 일시는 KST로 표기됩니다.\n\n라이프사이클 측면에서는 자동 제목과 태그 제안, 제목 수정, 소프트 삭제를 지원합니다. 읽기 경로는 `deleted_at IS NULL`을 전제로 하고, 수정과 삭제는 owner 또는 admin만 가능한 fail-closed입니다. 제목과 태그는 React-escape로 렌더해 XSS 위험을 차단합니다.\n\n\n다음은 스케줄 진단과 알림 다이제스트입니다.",
     44: "⏸️ [2min] [요약]\n• 스케줄 진단은 `report_schedules` 테이블 + hourly `schedule_dispatcher`로 자동 실행\n• 알림은 개별 발송에서 ~15분 배치 다이제스트로 전환됨(폭주 방지, 이미 라이브)\n• Bedrock 호출 전 PII를 결정론적으로 스크러빙 — \"왜 안전한가\"의 핵심 근거\n\n리포트는 수동 실행뿐 아니라 스케줄로도 돌 수 있습니다. `report_schedules` 테이블에 사용자별로 주간, 격주, 월간 주기를 등록하면, hourly로 도는 `schedule_dispatcher`가 `next_run_at`을 스캔해서 리포트 job을 큐에 넣습니다. v1 `report-scheduler.ts`의 패턴을 그대로 승계했습니다.\n\n\n\n완료된 리포트의 알림 방식도 이미 개선됐습니다. 예전에는 리포트가 끝날 때마다 SNS 이메일을 즉시 발송해서 하루에 44건이 몰리면 이메일이 44통 날아가는 문제가 있었는데, `diagnosis_digest.py`가 ~15분 주기로 `notified_at IS NULL`인 리포트를 모아 SNS 한 건으로 묶어 보내도록 이미 main에 병합·배포되어 라이브에서 동작 중입니다.\n\n\n\n그리고 이 파이프라인 전체에서 중요한 보안 포인트가 하나 있습니다. Bedrock을 호출하기 전에 ARN, 계정 ID, 이메일, IP, 액세스 키 같은 정보를 결정론적으로 스크러빙합니다. 진단 데이터가 LLM에 들어가기 전에 이미 민감 정보가 지워진다는 뜻입니다.\n\n\n이제 Datasources 화면을 보겠습니다.",
@@ -1551,9 +1551,9 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     47: "[1min] [요약]\n• EKS는 nodes/pods/deployments/services 개별 페이지 + K9s 스타일 explorer(11탭) + container cost로 확장\n• 인증은 sa-token / assume-role / task-role(Access Entry) 3가지 모드\n• Access Entry 보유 클러스터는 즉시(LIVE) 조회 등록 가능\n\nEKS 화면도 read-only지만 이제 완전한 메뉴 패밀리입니다. fleet 전체의 nodes, pods, deployments, services를 각각의 페이지로 보고, K9s 스타일 explorer에서는 11개 리소스 종류를 탭으로 오갈 수 있습니다. container cost 뷰도 붙었습니다.\n\n\n실제 EKS 화면 두 장을 보겠습니다.",
     48: "[1min] 인증은 세 가지 모드를 지원합니다. 읽기 전용 ServiceAccount 토큰을 붙이는 sa-token, Access Entry가 있는 IAM Role을 assume하는 assume-role, 그리고 web task role 자체의 Access Entry를 쓰는 task-role입니다. task role은 **AmazonEKSAdminViewPolicy**(View가 아니라 AdminView — View는 클러스터 스코프 리소스가 없어 nodes 조회가 403남) 권한을 클러스터 스코프로 가지고, BFF의 kind allow-list가 secrets 등 민감 kind를 차단합니다. Access Entry가 이미 있는 클러스터는 별도 자격 증명 없이 LIVE로 즉시 등록할 수 있습니다.\n\n\n지금까지 안 다룬 두 가지를 더 보겠습니다. 서비스별 진단 계층과 멀티 계정 보안입니다.",
     49: "⏸️ [2min] [요약]\n• 11개 서비스 각각에 전용 진단 UI + 접이식 \"owner 가이드\" 설명이 붙음\n• 콘솔처럼 지표만 보여주는 게 아니라 \"왜\" 문제인지까지 설명하는 것이 차별점\n• 새 서비스 추가는 GuideSpec 데이터 하나만 늘리면 됨 (컴포넌트 재사용)\n\n여기서부터는 지금까지 데모에서 못 짚은 부분을 훑어보겠습니다. 먼저 서비스별 진단 계층입니다. RDS, DynamoDB, ElastiCache, MSK, OpenSearch, ALB/NLB, S3/EBS, EC2, Lambda까지 11개 서비스 각각에 전용 진단 화면이 있습니다.\n\n\n\n각 화면에는 접었다 펼 수 있는 \"owner 가이드\"가 붙어있어서, 이 지표가 왜 중요한지, 어떤 값이 정상이고 어떤 값이 위험한지를 설명합니다. 표면적으로는 그냥 콘솔처럼 보이지만, 실제로는 각 서비스마다 문제의 원인을 설명해주는 진단 가이드가 함께 붙어있다는 점이 차별점입니다. 지표 테이블은 range-picker로 기간을 바꾸고 정렬도 가능합니다.\n\n\n구현 관점에서도 재사용성이 좋습니다. 컴포넌트 하나가 `GuideSpec` 데이터를 받아 렌더링하기 때문에, 서비스를 하나 추가하는 건 새 컴포넌트가 아니라 데이터 하나를 추가하는 일입니다.\n\n\n다음은 멀티 계정 보안과 컴플라이언스입니다.",
-    50: "⏸️ [2min] [요약]\n• ADR-011 — 멀티 계정은 STS AssumeRole read-only fan-out, ExternalId는 1st-party 옵션·3rd-party 필수\n• Security 페이지에 CVE Severity Distribution donut(ECR 스캔 집계)이 추가됨\n• Compliance 벤치마크도 계정 단위로 스코핑되어 실행/이력 관리\n\n멀티 계정 지원은 ADR-011을 기준으로 합니다. 각 대상 계정에 STS AssumeRole로 read-only fan-out하고, ExternalId는 host ARN이 고정되는 1st-party 계정은 옵션, 신뢰 관계가 약한 3rd-party 계정은 필수입니다.\n\n\n\n이 화면의 왼쪽은 Security findings 파이프라인입니다. Public S3, Open SG, Unencrypted EBS, IAM MFA 같은 항목에 더해 ECR 스캔 결과를 집계한 CVE Severity Distribution donut이 추가됐습니다. 오른쪽은 Compliance 벤치마크 실행 흐름인데, Powerpipe 워커가 계정 단위로 스코핑되어 실행되고 이력이 `compliance_runs`/`compliance_results`에 쌓입니다.\n\n\n배포 방법을 보겠습니다.",
+    50: "⏸️ [2min] [요약]\n• 멀티 계정은 STS AssumeRole read-only fan-out, ExternalId는 1st-party 옵션·3rd-party 필수\n• Security 페이지에 CVE Severity Distribution donut(ECR 스캔 집계)이 추가됨\n• Compliance 벤치마크도 계정 단위로 스코핑되어 실행/이력 관리\n\n멀티 계정은 다음과 같이 지원합니다. 각 대상 계정에 STS AssumeRole로 read-only fan-out하고, ExternalId는 host ARN이 고정되는 1st-party 계정은 옵션, 신뢰 관계가 약한 3rd-party 계정은 필수입니다.\n\n\n\n이 화면의 왼쪽은 Security findings 파이프라인입니다. Public S3, Open SG, Unencrypted EBS, IAM MFA 같은 항목에 더해 ECR 스캔 결과를 집계한 CVE Severity Distribution donut이 추가됐습니다. 오른쪽은 Compliance 벤치마크 실행 흐름인데, Powerpipe 워커가 계정 단위로 스코핑되어 실행되고 이력이 `compliance_runs`/`compliance_results`에 쌓입니다.\n\n\n배포 방법을 보겠습니다.",
     51: "⏸️ [2min] 배포는 Terraform 기반이고, 네 단계로 정리됩니다.\n\n먼저 `make configure`로 대화형 TUI를 돌려 VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다.\n\n\n\n다음으로 Terraform을 init하고 plan을 tfplan으로 저장합니다. 공유 인프라에는 auto-approve를 쓰지 않고, 저장된 tfplan을 컨트롤러가 apply합니다. CloudFront나 Security Group처럼 오래 걸리는 apply는 서브에이전트 타임아웃 때문에 컨트롤러가 직접 실행합니다.\n\n세 번째로 `make deploy`는 먼저 ULID 마이그레이션을 돌리고, arm64 이미지를 빌드해 ECR에 푸시한 뒤 ECS 롤링 배포를 하고, 마지막으로 `/api/health` 스모크로 검증합니다.\n\n마지막으로 AgentCore와 워커는 flag-gated입니다. `make agentcore`, `make workers`로 활성화하며, 기본은 꺼져 있어 비용이 0입니다. 라이브 환경은 단일 계정 123456789012, 도메인 awsops-v2.example.com입니다.\n\n\n마무리하겠습니다.",
-    52: "⏸️ [2min] AWSops를 정리하면, read-only AWS 운영 대시보드에 AI 진단을 결합한 제품입니다.\n\n자연어로 물으면 AgentCore MCP 도구가 라이브 read-only 조회를 하고, 종합진단 리포트가 light·mid 9섹션과 deep 16섹션으로 Well-Architected 관점의 진단을 제공합니다. 인벤토리, 토폴로지, Datasources, EKS 화면이 이를 뒷받침합니다.\n\n\n\n차별점은 세 가지입니다. AI는 계정 안의 Bedrock으로 동작해 외부 AI SaaS API를 쓰지 않습니다. 엣지는 private edge라 공개 ALB가 없고 CloudFront VPC Origin으로만 들어옵니다. 무거운 작업은 OOM-safe 비동기 워커 티어가 처리합니다.\n\n\n\n가장 중요한 원칙은 read-only 자세입니다. ADR-007(keystone) 기준으로 read-only는 AWS **리소스**에 한정되고, AWS 리소스 변경과 자율 실행은 ADR-005로 동결(새 명시적 결정 전까지, 영구 아님)입니다. 다만 외부 관측성 데이터를 읽고, 외부 기록이나 티켓, 메시지를 쓰는 것은 SSRF 방어, Secrets 관리, DLP, human-gate, flag-OFF 같은 거버넌스 아래에서 허용됩니다. 변경되는 것은 데이터일 뿐, AWS 리소스가 아닙니다.\n\n시작은 간단합니다. configure하고 Terraform을 apply한 뒤 deploy하고, Cognito 사용자를 추가해 `/login`으로 들어오면 됩니다.\n\n\n마지막 슬라이드입니다.",
+    52: "⏸️ [2min] AWSops를 정리하면, read-only AWS 운영 대시보드에 AI 진단을 결합한 제품입니다.\n\n자연어로 물으면 AgentCore MCP 도구가 라이브 read-only 조회를 하고, 종합진단 리포트가 light·mid 9섹션과 deep 16섹션으로 Well-Architected 관점의 진단을 제공합니다. 인벤토리, 토폴로지, Datasources, EKS 화면이 이를 뒷받침합니다.\n\n\n\n차별점은 세 가지입니다. AI는 계정 안의 Bedrock으로 동작해 외부 AI SaaS API를 쓰지 않습니다. 엣지는 private edge라 공개 ALB가 없고 CloudFront VPC Origin으로만 들어옵니다. 무거운 작업은 OOM-safe 비동기 워커 티어가 처리합니다.\n\n\n\n가장 중요한 원칙은 read-only 자세입니다. read-only는 AWS **리소스**에 한정되고, AWS 리소스 변경과 자율 실행은 동결(새 명시적 결정 전까지, 영구 아님)입니다. 다만 외부 관측성 데이터를 읽고, 외부 기록이나 티켓, 메시지를 쓰는 것은 SSRF 방어, Secrets 관리, DLP, human-gate, flag-OFF 같은 거버넌스 아래에서 허용됩니다. 변경되는 것은 데이터일 뿐, AWS 리소스가 아닙니다.\n\n시작은 간단합니다. configure하고 Terraform을 apply한 뒤 deploy하고, Cognito 사용자를 추가해 `/login`으로 들어오면 됩니다.\n\n\n마지막 슬라이드입니다.",
     53: "[1min] 감사합니다. 질문이 있으시면 지금 받겠습니다.\n\n발표 후 추가 질문이 있으시면 언제든 연락 주세요. AWSops는 내부에서 계속 발전하고 있고, 새로운 기능이 지속적으로 추가되고 있습니다.\n\n\n오늘 보여드린 하이브리드 라우팅, thin-BFF + 비동기 워커, read-only 진단 자세는 여러분의 프로젝트에도 적용할 수 있는 범용 아키텍처 패턴입니다.\n\n감사합니다."
   };
   const deck = new SlideFramework({

From 0397c7d617131a6ec816ffd8aa376fc23602fb36 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Thu, 22 Oct 2026 04:08:35 +0000
Subject: [PATCH 2/7] docs-site: remove ADR references from the deck
 architecture section

Split from #192 to stay under the AI review input limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .../awsops-intro/02-architecture.html         | 50 ++++++++---------
 .../awsops-intro/02-architecture.md           | 56 +++++++++----------
 2 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.html b/docs-site/static/presentation/awsops-intro/02-architecture.html
index 31ca70759..76b3c3b75 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.html
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.html
@@ -80,7 +80,7 @@ <h3>Foundation</h3>
 <p><strong>LIVE 오늘</strong>: workers · steampipe · agentcore · integrations · ai_cost_tracking · diagnosis_schedule · diagnosis_notify · eks_auto_register · hybrid_routing</p>
 </div><div class="col">
 <h3>Feature Flags (~17개, 전부 default-off = $0)</h3>
-<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>ADR-005 FROZEN</strong>, do-not-enable</li></ul>
+<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>FROZEN</strong>, do-not-enable</li></ul>
 </div>
 </div>
   </div>
@@ -95,7 +95,7 @@ <h3>Core Layers</h3>
 <table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>network.tf</code></td><td>VPC 신규/재사용</td></tr><tr><td><code>edge.tf</code></td><td>CloudFront + VPC Origin + ALB</td></tr><tr><td><code>auth.tf</code></td><td>Cognito + Lambda@Edge</td></tr><tr><td><code>data.tf</code></td><td>Aurora + schema</td></tr><tr><td><code>workload.tf</code></td><td>ECS web service</td></tr><tr><td><code>ecr.tf</code></td><td>dual-tier ECR</td></tr><tr><td><code>ai.tf</code></td><td>AgentCore + SSM</td></tr><tr><td><code>workers.tf</code></td><td>SQS + SFN + Lambda</td></tr></tbody></table>
 </div><div class="col">
 <h3>Gated Subsystems</h3>
-<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포 (ADR-015)</td></tr></tbody></table>
+<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포</td></tr></tbody></table>
 </div>
 </div>
   </div>
@@ -107,7 +107,7 @@ <h3>Gated Subsystems</h3>
     <div class="columns">
 <div class="col">
 <h3>Next.js 14 Standalone (arm64)</h3>
-<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트(ADR-009)</li></ul>
+<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트</li></ul>
 <h3>Routes</h3>
 <ul><li><code>/api/health</code> — 공개 헬스체크</li><li><code>/api/stream</code> — SSE 스트리밍</li><li><code>/api/db</code> — Aurora ping</li><li><code>/api/jobs</code> (+<code>/[id]</code>) — 비동기 작업</li></ul>
 </div><div class="col">
@@ -123,7 +123,7 @@ <h3>Routes</h3>
     <div class="columns">
 <div class="col">
 <h3>Aurora (PostgreSQL 17.9)</h3>
-<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>ADR-030 스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
+<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
 </div><div class="col">
 <h3>Steampipe = 인벤토리 sync ONLY</h3>
 <p><div style="background:rgba(0,255,136,0.08);border:1px solid rgba(0,255,136,0.3);border-radius:10px;padding:1rem;margin-top:0.5rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;margin-bottom:0.5rem;">warm Fargate → Aurora → /inventory/[type]</div><div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">flag-gated (<code style="color:#00ff88;">steampipe_enabled</code>)<br><b style="color:#00ff88;">41종</b> 리소스 타입 동기화<br>fan-out sync · registry-driven nav</div><div style="color:#ef4444;font-size:0.75rem;margin-top:0.625rem;border-top:1px solid rgba(239,68,68,0.3);padding-top:0.5rem;">NOT a live query engine — pg Pool / 라이브 조회 아님</div></div></p>
@@ -175,13 +175,13 @@ <h3>Steampipe = 인벤토리 sync ONLY</h3>
     <span style="background:rgba(168,85,247,0.18);color:#c4a0f7;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">ops</span>
     <span style="background:rgba(0,212,255,0.18);color:#7fd8ff;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">external-obs</span>
   </div>
-  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격, ADR-004) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 ADR-001/010에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
+  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 설계 원칙에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
 </div>
   </div>
 </div>
 
 <div class="slide" data-remarp-id="s8" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat — ADR-003</h2></div>
+  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat</h2></div>
   <div class="slide-body" data-remarp-id="s8-body">
     <div class="columns">
 <div class="col">
@@ -265,7 +265,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -305,7 +305,7 @@ <h3>Read-Only Query</h3>
 </div>
 
 <div class="slide" data-remarp-id="s14" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out (ADR-011)</h2></div>
+  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out</h2></div>
   <div class="slide-body" data-remarp-id="s14-body">
     <div class="columns">
 <div class="col">
@@ -313,7 +313,7 @@ <h3>Registry + Assume</h3>
 <ul><li>Aurora <strong>accounts</strong> 레지스트리 — 호스트 계정은 lazy seed</li><li>대상 계정 <code>AWSopsReadOnlyRole</code>을 host task role이 <strong>STS AssumeRole</strong></li><li><strong>ExternalId</strong> — 1st-party(trust policy가 task-role ARN 핀) = <strong>선택</strong>, 3rd-party/와일드카드 = <strong>필수</strong>(confused-deputy 방어)</li><li>글로벌 셀렉터: 단일 계정 스코프 / <code>__all__</code> = 전 계정 fan-out</li></ul>
 </div><div class="col">
 <h3>Safety</h3>
-<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
+<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
 </div>
 </div>
   </div>
@@ -326,7 +326,7 @@ <h3>Safety</h3>
 <div class="col">
 <h3>Cognito + Lambda@Edge</h3>
 <ul><li><strong>us-east-1</strong>, py3.12, viewer-request</li><li><strong>RS256 JWKS</strong> 서명 검증 (iss/aud/token_use)</li><li>OAuth <code>state</code> + <strong>PKCE public client</strong></li></ul>
-<h3>Login (ADR-002)</h3>
+<h3>Login</h3>
 <ul><li><strong>Primary</strong> = 자체 <code>/login</code> 폼</li><li>BFF <code>POST /api/auth/login</code> → 무서명 공개 <code>InitiateAuth(USER_PASSWORD_AUTH)</code> → <code>awsops_token</code> (id_token 12h)</li><li>Hosted UI PKCE = <strong>dark fallback</strong>, signout = 쿠키 삭제</li></ul>
 </div><div class="col">
 <p><div style="display:flex;flex-direction:column;gap:0.75rem;margin-top:0.5rem;"><div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;">🔒 Private Edge</div><div style="color:#8b95a5;font-size:0.8125rem;">공개 ALB 없음 — 진입점은 CloudFront 하나</div></div><div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00d4ff;font-weight:bold;font-size:0.9375rem;">🔑 ECS Secrets</div><div style="color:#8b95a5;font-size:0.8125rem;">execution role 권한 (task role 아님)</div></div><div style="background:rgba(168,85,247,0.1);border:1px solid rgba(168,85,247,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#a855f7;font-weight:bold;font-size:0.9375rem;">👤 Admin</div><div style="color:#8b95a5;font-size:0.8125rem;">SSM + Cognito group (fail-closed)</div></div></div></p>
@@ -371,16 +371,16 @@ <h3>Login (ADR-002)</h3>
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
+  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -394,7 +394,7 @@ <h3>Login (ADR-002)</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Key Takeaways — Architecture</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 19: Key Takeaways --></p>
-<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock</li></ul>
+<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>하이브리드 라우팅 + 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock</li></ul>
   </div>
 </div>
 
@@ -420,23 +420,23 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
   const presenterNotes = {
     1: "[1min] 두 번째 파트, 아키텍처 딥다이브입니다.\nAWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다.\n핵심은 세 가지입니다. 첫째, Terraform 기반 MSA로 재구축했다는 점. 둘째, 공개 진입점이 없는 비공개 엣지 구조라는 점. 셋째, 읽기 전용 운영 태세 위에 모든 것이 설계되었다는 점입니다.\n\n전체 그림부터 보겠습니다.",
     2: "⏸️ [3min] 전체 구조는 4개 레이어의 비공개 엣지입니다.\n브라우저는 전용 도메인으로 들어오고, CloudFront가 TLS로 받습니다. 여기서 VPC Origin을 https-only 443으로 설정해 내부 ALB까지 TLS가 끊기지 않게 합니다. origin 도메인을 public FQDN으로 지정해 SNI가 맞아야 합니다.\n\n핵심은 공개 ALB가 없다는 점입니다. 내부 ALB의 보안 그룹은 CloudFront 관리형 SG에서 오는 443만 허용합니다. VPC CIDR만 열면 504가 납니다. ALB는 HTTP로 Fargate의 web 컨테이너 3000번 포트로 전달합니다.\n영속 상태는 Aurora에 두고, 라이브 AWS 조회는 AgentCore MCP 도구가, 무거운 작업은 비동기 워커가 처리합니다.\n\n이 인프라를 어떻게 코드로 관리하는지 보겠습니다.",
-    3: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 ADR-005 동결 상태이고, integrations_write는 off이지만 ADR-007 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
-    4: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 ADR-005로 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
-    5: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`, ADR-009)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
-    6: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 ADR-030 기반 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
+    3: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 동결 상태이고, integrations_write는 off이지만 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
+    4: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
+    5: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
+    6: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
     7: "⏸️ [2min] AI 엔진은 Bedrock AgentCore입니다.\n모델은 Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore Runtime이 Strands 기반 `agent/agent.py`를 실행합니다. Memory와 Code Interpreter도 함께 붙어 있습니다.\n\n설정의 source of truth는 SSM입니다. provision.py가 runtime ARN, interpreter ID, memory ID를 `/ops/awsops-v2/agentcore/` 경로에 기록하고, 웹 BFF가 런타임에 읽습니다. valueFrom 레이스를 피하려는 의도적 설계입니다.\n\n이 런타임이 어떤 도구를 들고 있는지 보겠습니다.",
-    8: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
-    9: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
+    8: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. 2026년 6월 24일에 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
+    9: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     10: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
-    11: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
+    11: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     12: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",
     13: "⏸️ [3min] 관측성 데이터는 읽기 전용 데이터소스 플랫폼으로 통합합니다.\nClickHouse, Prometheus, Loki, Tempo, Mimir 커넥터를 지원합니다. 각 커넥터는 Lambda로 구현되고, 스키마는 Aurora에 캐시합니다. 이 데이터를 챗에 주입하면 AI가 여러 데이터소스를 교차 조회할 수 있습니다. `/datasources` Explore 페이지에서는 자연어를 쿼리로 변환해 직접 탐색할 수도 있습니다. 모두 읽기 전용입니다.\n\n토폴로지는 리소스 간 관계를 그래프로 보여줍니다. flow 그래프와 infra 리소스 그래프 두 가지가 있고, CloudFront에서 로드밸런서, 타깃 그룹, DB로 이어지는 경로를 시각화합니다. `/topology/resource/[id]`로 들어가면 개별 리소스의 상세 패널을 볼 수 있습니다.\n\n컨테이너 운영자를 위한 EKS 통합을 보겠습니다.",
     14: "⏸️ [3min] EKS도 읽기 전용으로 통합되는데, 인증 경로가 3가지로 늘었습니다. 원래 경로는 configure.mjs 멀티선택으로 시작해서 eks.tf가 웹 task role에 Access Entry를 부여하고 AmazonEKSAdminViewPolicy를 클러스터 스코프로 붙이는 방식입니다. View가 아니라 AdminView인 이유는, View 정책엔 클러스터 스코프 리소스가 없어서 노드 목록 조회가 403이 나기 때문입니다. AdminView는 */*/get,list,watch라 시크릿까지 읽을 수 있지만, BFF가 노출하는 kind는 화이트리스트로 제한되어 있어서 시크릿·컨피그맵은 절대 통과하지 않습니다.\n\n여기에 sa-token과 assume-role 두 가지 경로가 Aurora의 eks_registrations.auth에 더해졌습니다. 클러스터별로 등록하면 되고 terraform 온보딩이 필요 없습니다. 그리고 지금 라이브인 auto-register 경로가 있는데, EventBridge가 CloudTrail의 AssociateAccessPolicy나 DeleteAccessEntry 이벤트를 잡아서 Lambda를 거쳐 eks_registrations에 자동으로 기록합니다. 버튼을 누를 필요가 없습니다.\n조회는 nodes, pods, deployments, services 같은 핵심 리소스를 BFF가 직접 처리합니다. 워커를 거치지 않습니다. 그리고 한 가지 더, ListClusters·DescribeCluster 같은 핵심 discovery 권한은 이제 게이트가 아니라 workload.tf에 상시로 붙어 있습니다. 그래서 온보딩 플래그가 꺼져 있어도 /api/eks, /api/overview, /api/cost는 항상 정상 동작합니다.\nEKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워크로드 뷰가 있습니다.\n\n계정을 하나 더 늘리면 어떻게 되는지, 멀티 계정 구조를 보겠습니다.",
-    15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
-    16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
+    15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
+    16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     17: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 \"영구 금지\"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 \"안전조건 충족 + 새로운 명시적 결정 전까지\" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
-    19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
+    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 별도의 명시적인 제품 결정이 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     20: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다."
   };
   const deck = new SlideFramework({
diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.md b/docs-site/static/presentation/awsops-intro/02-architecture.md
index 66cdcbc50..a952d0487 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.md
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.md
@@ -111,7 +111,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 - `hybrid_routing_enabled` · `diagnosis_schedule_enabled` · `diagnosis_notify_enabled`
 - `incident_lifecycle_enabled` · `k8sgpt_enabled` · `rca_writeback_enabled`
 - `eks_auto_register_enabled` · `ai_cost_tracking_enabled` · `multi_route_synthesis_enabled`
-- `remediation_enabled` — **ADR-005 FROZEN**, do-not-enable
+- `remediation_enabled` — **FROZEN**, do-not-enable
 
 :::
 
@@ -122,7 +122,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 {cue: pause}
 큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.
 {cue: pause}
-다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 ADR-005 동결 상태이고, integrations_write는 off이지만 ADR-007 거버넌스 아래 게이트 상태(동결은 아님)입니다.
+다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 동결 상태이고, integrations_write는 off이지만 거버넌스 아래 게이트 상태(동결은 아님)입니다.
 공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.
 {cue: transition}
 파일별로 어떻게 나뉘어 있는지 보겠습니다.
@@ -167,7 +167,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 | `k8sgpt.tf` | K8sGPT 예산/리소스 (`k8sgpt_enabled`) |
 | `writeback.tf` | RCA write-back (`rca_writeback_enabled`) |
 | `remediation.tf` | 리메디에이션 substrate (**FROZEN**) |
-| `secret-rotation.tf` | 자기치유 재배포 (ADR-015) |
+| `secret-rotation.tf` | 자기치유 재배포 |
 
 :::
 
@@ -176,7 +176,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 파일별 역할입니다.
 왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.
 {cue: pause}
-오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 ADR-005로 동결(do-not-enable) 상태입니다.
+오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 동결(do-not-enable) 상태입니다.
 {cue: transition}
 이제 컴퓨트와 웹 레이어입니다.
 :::
@@ -196,7 +196,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 
 - **루트 경로 서빙** — basePath 없음, fetch는 `/api/*`
 - **Thin-BFF 원칙** — 무겁고·길고·OOM 위험 작업은 직접 실행 금지
-- 무거운 작업은 워커 큐로 enqueue — 범용 **`POST /api/jobs`는 `noop` 계열만**, `report`/`compliance` 등 도메인 job은 소유권 검사하는 전용 라우트(ADR-009)
+- 무거운 작업은 워커 큐로 enqueue — 범용 **`POST /api/jobs`는 `noop` 계열만**, `report`/`compliance` 등 도메인 job은 소유권 검사하는 전용 라우트
 
 ### Routes
 
@@ -220,7 +220,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.
 전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.
 {cue: pause}
-가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`, ADR-009)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.
+가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.
 오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.
 {cue: transition}
 영속 상태를 담는 데이터 레이어로 갑니다.
@@ -241,7 +241,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 
 - **0.5–4 ACU**, KMS CMK, RDS-관리 master secret
 - 앱 접근 = **node-pg** (`web/lib/db.ts`)
-- ADR-030 스키마 (v9 baseline) + `worker_jobs` · chat threads · diagnosis
+- 스키마 (v9 baseline) + `worker_jobs` · chat threads · diagnosis
 - 새 테이블 = **ULID 마이그레이션** (`migrations/<ULID>_*.sql`)
 
 :::
@@ -259,7 +259,7 @@ AWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다
 :::notes
 {timing: 3min}
 영속 상태는 Aurora Serverless v2가 담당합니다.
-PostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 ADR-030 기반 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.
+PostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.
 {cue: pause}
 여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.
 {cue: transition}
@@ -333,14 +333,14 @@ AI 엔진은 Bedrock AgentCore입니다.
     <span style="background:rgba(168,85,247,0.18);color:#c4a0f7;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">ops</span>
     <span style="background:rgba(0,212,255,0.18);color:#7fd8ff;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">external-obs</span>
   </div>
-  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격, ADR-004) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 ADR-001/010에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
+  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 설계 원칙에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
 </div>
 :::
 
 :::notes
 {timing: 2min}
 도구는 9개 섹션 게이트웨이로 묶입니다.
-network, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 "9번째 게이트웨이가 아니다"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.
+network, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. 2026년 6월 24일에 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 "9번째 게이트웨이가 아니다"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.
 {cue: pause}
 전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.
 {cue: transition}
@@ -354,7 +354,7 @@ network, container, data, security, cost, monitoring, iac, ops, 그리고 extern
 @type: content
 @transition: slide
 
-# Hybrid Routing & Streaming Chat — ADR-003
+# Hybrid Routing & Streaming Chat
 
 ::: left
 
@@ -388,7 +388,7 @@ network, container, data, security, cost, monitoring, iac, ops, 그리고 extern
 
 :::notes
 {timing: 3min}
-9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.
+9개 게이트웨이 중 어디로 보낼지는 하이브리드 라우팅이 정합니다.
 파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.
 {cue: pause}
 게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.
@@ -484,7 +484,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 :::notes
 {timing: 2min}
 무거운 작업은 모두 비동기 워커 티어가 받습니다.
-흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.
+흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.
 {cue: pause}
 그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.
 워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.
@@ -506,7 +506,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 ### 잡 종류 (2026-06-18 이후 증가)
 
 - **schedule_dispatcher** — 시간별 EventBridge → `report_schedules` 스캔 → 진단 잡 enqueue (`diagnosis_schedule_enabled`, LIVE)
-- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)
+- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨)
 - **compliance** (Powerpipe) — CIS 벤치마크 Fargate 잡 (`steampipe_enabled`)
 
 :::
@@ -618,7 +618,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 @type: content
 @transition: slide
 
-# Multi-Account — STS AssumeRole Fan-Out (ADR-011)
+# Multi-Account — STS AssumeRole Fan-Out
 
 ::: left
 
@@ -636,7 +636,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 ### Safety
 
 - **host self-assume 가드** — target == host면 `get_role_arn()`이 `None` 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)
-- **read-only 한정** — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)
+- **read-only 한정** — 대상 계정 변경 작업 없음
 - `/accounts` admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)
 
 :::
@@ -648,7 +648,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 • ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수
 • host self-assume 가드로 "cross-account 차단" 오진을 방지
 
-AWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.
+AWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.
 {cue: pause}
 ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.
 전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.
@@ -675,7 +675,7 @@ ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AW
 - **RS256 JWKS** 서명 검증 (iss/aud/token_use)
 - OAuth `state` + **PKCE public client**
 
-### Login (ADR-002)
+### Login
 
 - **Primary** = 자체 `/login` 폼
 - BFF `POST /api/auth/login` → 무서명 공개 `InitiateAuth(USER_PASSWORD_AUTH)` → `awsops_token` (id_token 12h)
@@ -696,7 +696,7 @@ ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AW
 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.
 Lambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.
 {cue: pause}
-로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.
+로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.
 오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.
 {cue: transition}
 이걸 실제로 배포하는 흐름을 보겠습니다.
@@ -760,16 +760,16 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
+  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -781,10 +781,10 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
 :::notes
 {timing: 3min}
 이 아키텍처의 태세를 정확히 정의하겠습니다.
-AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 "영구 금지"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 "안전조건 충족 + 새로운 명시적 결정 전까지" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
+AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 별도의 명시적인 제품 결정이 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
 {cue: pause}
-딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.
-다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.
+딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.
+다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.
 그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.
 {cue: transition}
 전체를 한 장으로 정리하겠습니다.
@@ -802,16 +802,16 @@ AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니
 - **Terraform MSA on private edge** — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음
 - **Aurora 영속 상태** — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)
 - **AgentCore 섹션 에이전트** — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기
-- **ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정** — regex + Haiku 분류기 + caching, STS AssumeRole fan-out
+- **하이브리드 라우팅 + 멀티 계정** — regex + Haiku 분류기 + caching, STS AssumeRole fan-out
 - **OOM-safe 비동기 워커 티어** — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리
-- **읽기 전용 동결 태세** — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock
+- **읽기 전용 동결 태세** — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock
 
 :::notes
 {timing: 2min}
 아키텍처 파트를 한 장으로 정리합니다.
 첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.
 {cue: pause}
-셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.
+셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.
 {cue: transition}
 세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.
 :::

From 36de90e34a9ce0db4fd6a853f3c605f5e23138a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Thu, 22 Oct 2026 23:49:16 +0000
Subject: [PATCH 3/7] fix: address review feedback (iteration 1/5)

Keep the facts the ADR removal dropped: the diagnosis digest's approved
scope is the scheduled summary while the implementation also batches
manual runs, and lifting the AWS-mutation freeze needs a new decision
document, a multi-AI panel review and a dated owner approval.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 docs-site/static/presentation/awsops-intro/index.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs-site/static/presentation/awsops-intro/index.html b/docs-site/static/presentation/awsops-intro/index.html
index 5b3edc81c..b5a48e736 100644
--- a/docs-site/static/presentation/awsops-intro/index.html
+++ b/docs-site/static/presentation/awsops-intro/index.html
@@ -564,7 +564,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -1329,7 +1329,7 @@ <h3>스케줄 진단 (<code>diagnosis_schedule_enabled</code>)</h3>
 <ul><li><code>report_schedules</code> 테이블 — 주간 / 격주 / 월간 (<code>next_run_at</code> 기준)</li><li>hourly <strong><code>schedule_dispatcher</code></strong> — 스캔 후 <code>report</code> job enqueue</li><li>v1 <code>report-scheduler.ts</code> 패턴 승계</li></ul>
 </div><div class="col">
 <h3>알림 다이제스트 (병합·배포 완료)</h3>
-<ul><li><strong><code>diagnosis_digest.py</code></strong> — <code>notified_at IS NULL</code> 리포트를 ~15분 배치로 묶어 SNS 1건 발송 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 main 병합·라이브 배포됨)</li><li>완료 즉시 개별 발송(per-report) 방식 폐기 — 폭주 방지(하루 44건 → 1건)</li><li><strong>PII 스크러빙</strong> — Bedrock 호출 전 ARN·계정ID·이메일·IP·액세스키를 결정론적으로 마스킹 (현재 라이브)</li></ul>
+<ul><li><strong><code>diagnosis_digest.py</code></strong> — <code>notified_at IS NULL</code> 리포트를 ~15분 배치로 묶어 SNS 1건 발송 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 main 병합·라이브 배포됨; 승인된 범위는 스케줄 요약뿐이지만 현재 구현은 수동 실행분까지 묶음 — 후속 정리 대상)</li><li>완료 즉시 개별 발송(per-report) 방식 폐기 — 폭주 방지(하루 44건 → 1건)</li><li><strong>PII 스크러빙</strong> — Bedrock 호출 전 ARN·계정ID·이메일·IP·액세스키를 결정론적으로 마스킹 (현재 라이브)</li></ul>
 </div>
 </div>
   </div>
@@ -1530,7 +1530,7 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
     27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     28: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 별도의 명시적인 제품 결정이 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
     30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     31: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다.",
     32: "[1min] 마지막 파트입니다. 지금까지 왜 필요한지, 어떻게 만들었는지를 봤고, 이제 실제로 어떻게 쓰는지를 데모로 보여드리겠습니다.\nAI 어시스턴트, 비용/인벤토리/토폴로지 시나리오, 그리고 종합진단 리포트까지 순서대로 보겠습니다.\n\n한 가지 먼저 짚고 갈 점은, 오늘 보여드리는 모든 데모는 read-only라는 것입니다. 조회와 진단만 하고, AWS 리소스를 변경하지 않습니다.\n\n먼저 AI 어시스턴트 데모입니다.",

From e901e6d5160d3f10e58df3e6de1439552ddb50bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Thu, 22 Oct 2026 23:49:19 +0000
Subject: [PATCH 4/7] fix: address review feedback (iteration 1/5)

Keep the facts the ADR removal dropped: the diagnosis digest's approved
scope is the scheduled summary while the implementation also batches
manual runs, and lifting the AWS-mutation freeze needs a new decision
document, a multi-AI panel review and a dated owner approval.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .../static/presentation/awsops-intro/02-architecture.html     | 4 ++--
 docs-site/static/presentation/awsops-intro/02-architecture.md | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.html b/docs-site/static/presentation/awsops-intro/02-architecture.html
index 76b3c3b75..80242e815 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.html
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.html
@@ -265,7 +265,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -435,7 +435,7 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
     16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     17: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 별도의 명시적인 제품 결정이 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
     19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     20: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다."
   };
diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.md b/docs-site/static/presentation/awsops-intro/02-architecture.md
index a952d0487..f74dbd796 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.md
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.md
@@ -506,7 +506,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 ### 잡 종류 (2026-06-18 이후 증가)
 
 - **schedule_dispatcher** — 시간별 EventBridge → `report_schedules` 스캔 → 진단 잡 enqueue (`diagnosis_schedule_enabled`, LIVE)
-- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨)
+- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)
 - **compliance** (Powerpipe) — CIS 벤치마크 Fargate 잡 (`steampipe_enabled`)
 
 :::
@@ -781,7 +781,7 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
 :::notes
 {timing: 3min}
 이 아키텍처의 태세를 정확히 정의하겠습니다.
-AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 별도의 명시적인 제품 결정이 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
+AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
 {cue: pause}
 딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.
 다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.

From 684320a964357f6eb228d9e9b3c06d3ee851d944 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Sat, 24 Oct 2026 06:59:26 +0000
Subject: [PATCH 5/7] docs-site: leave the combined deck to its own PR

index.html is regenerated from the part sources in #195 after this
section and the other parts merge, so this review covers the
architecture source and its rendering together.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .../presentation/awsops-intro/index.html      | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/docs-site/static/presentation/awsops-intro/index.html b/docs-site/static/presentation/awsops-intro/index.html
index b5a48e736..c9518e3c8 100644
--- a/docs-site/static/presentation/awsops-intro/index.html
+++ b/docs-site/static/presentation/awsops-intro/index.html
@@ -188,7 +188,7 @@ <h3>보고서 작성 부담</h3>
 <div style="display:grid;grid-template-columns:1fr 1fr;gap:1rem;">
   <div style="background:var(--yellow-bg);border:1px solid var(--orange);border-radius:8px;padding:1.25rem;">
     <div style="color:var(--orange);font-weight:bold;font-size:1.125rem;margin-bottom:.5rem;">Bedrock AgentCore</div>
-    <div style="color:var(--text-secondary);line-height:1.6;">Claude Opus 4.8 / Sonnet 5 / Haiku 4.5<br>AgentCore Runtime + 섹션 에이전트<br>하이브리드 라우팅</div>
+    <div style="color:var(--text-secondary);line-height:1.6;">Claude Opus 4.8 / Sonnet 5 / Haiku 4.5<br>AgentCore Runtime + 섹션 에이전트<br>ADR-003 하이브리드 라우팅</div>
   </div>
   <div style="display:grid;grid-template-rows:1fr 1fr;gap:.75rem;">
     <div style="background:var(--yellow-bg);border:1px solid var(--orange);border-radius:8px;padding:.75rem;text-align:center;">
@@ -255,7 +255,7 @@ <h3>보고서 작성 부담</h3>
   <div class="slide-header" data-remarp-id="s6-header"><h2>AWSops — By the Numbers</h2></div>
   <div class="slide-body" data-remarp-id="s6-body">
     <p><!-- Slide 5: By the Numbers --></p>
-<table><thead><tr><th>항목</th><th>내용</th><th>설명</th></tr></thead><tbody><tr><td><strong>Infra</strong></td><td>Terraform MSA</td><td>비공개 엣지 — CloudFront VPC Origin → 내부 ALB → Fargate</td></tr><tr><td><strong>Compute</strong></td><td>ECS Fargate</td><td>web thin-BFF + OOM-safe 비동기 워커 티어 (arm64)</td></tr><tr><td><strong>Data</strong></td><td>Aurora Serverless v2</td><td>PostgreSQL 17 영속 상태 + 41종 인벤토리 sync</td></tr><tr><td><strong>AI Tools</strong></td><td>9 게이트웨이 설계 (160+ 도구) · 30개 슬라이스 전부 LIVE</td><td>AgentCore 섹션 에이전트 (모두 read-only; 9개 게이트웨이 전부 READY MCP 타깃)</td></tr><tr><td><strong>AI Routing</strong></td><td>하이브리드</td><td>regex fast-path + Haiku 분류기, 게이트 96.9%</td></tr><tr><td><strong>Diagnosis</strong></td><td>light·mid 9 / deep 16 섹션</td><td>Well-Architected 매핑, DOCX/PDF 내보내기</td></tr><tr><td><strong>UX</strong></td><td>3-테마 + 모바일 + 4개 언어</td><td>반응형 대시보드 + Cmd-K + 한/영/中/日 i18n</td></tr></tbody></table>
+<table><thead><tr><th>항목</th><th>내용</th><th>설명</th></tr></thead><tbody><tr><td><strong>Infra</strong></td><td>Terraform MSA</td><td>비공개 엣지 — CloudFront VPC Origin → 내부 ALB → Fargate</td></tr><tr><td><strong>Compute</strong></td><td>ECS Fargate</td><td>web thin-BFF + OOM-safe 비동기 워커 티어 (arm64)</td></tr><tr><td><strong>Data</strong></td><td>Aurora Serverless v2</td><td>PostgreSQL 17 영속 상태 + 41종 인벤토리 sync</td></tr><tr><td><strong>AI Tools</strong></td><td>9 게이트웨이 설계 (160+ 도구) · 30개 슬라이스 전부 LIVE</td><td>AgentCore 섹션 에이전트 (모두 read-only; 9개 게이트웨이 전부 READY MCP 타깃)</td></tr><tr><td><strong>AI Routing</strong></td><td>ADR-003 하이브리드</td><td>regex fast-path + Haiku 분류기, 게이트 96.9%</td></tr><tr><td><strong>Diagnosis</strong></td><td>light·mid 9 / deep 16 섹션</td><td>Well-Architected 매핑, DOCX/PDF 내보내기</td></tr><tr><td><strong>UX</strong></td><td>3-테마 + 모바일 + 4개 언어</td><td>반응형 대시보드 + Cmd-K + 한/영/中/日 i18n</td></tr></tbody></table>
   </div>
 </div>
 
@@ -296,7 +296,7 @@ <h3>For FinOps / Management</h3>
   <div style="background: var(--green-bg); border: 1px solid var(--green); border-radius: 12px; padding: 1.5rem; text-align: center;">
     <div style="font-size: 3rem; margin-bottom: .75rem;">🔒</div>
     <div style="color: var(--green); font-weight: bold; font-size: 1.125rem; margin-bottom: .5rem;">Read-Only Posture</div>
-    <div style="color: var(--text-muted); font-size: .875rem;">AWS 리소스 변경·자율 실행 동결<br>설계상 안전</div>
+    <div style="color: var(--text-muted); font-size: .875rem;">AWS 리소스 변경·자율 실행 동결<br>ADR-005 (FROZEN) / ADR-007 — 설계상 안전</div>
   </div>
   <div style="background: var(--accent-subtle); border: 1px solid var(--accent); border-radius: 12px; padding: 1.5rem; text-align: center;">
     <div style="font-size: 3rem; margin-bottom: .75rem;">📊</div>
@@ -311,7 +311,7 @@ <h3>For FinOps / Management</h3>
   <div class="slide-header" data-remarp-id="s10-header"><h2>Key Takeaways — 5가지 목표, 하나의 대시보드</h2></div>
   <div class="slide-body" data-remarp-id="s10-body">
     <p><!-- Slide 8: Block 1 Key Takeaways --></p>
-<ul><li><strong>① 가시성</strong> → Overview·Topology·Monitoring + NFM·Direct Connect까지 통합된 Network 6종 메뉴</li><li><strong>② FinOps</strong> → 읽기 전용 비용 분석 + Rightsizing 인사이트 + OpenCost 패널</li><li><strong>③ Well-Architected</strong> → 종합진단 리포트 자동 생성 (light·mid/deep, DOCX/PDF)</li><li><strong>④ 보안성</strong> → Security Findings + CIS Compliance 벤치마크, 둘 다 읽기 전용</li><li><strong>⑤ 장애 대응 AI</strong> → AI Assistant/Diagnosis가 메트릭·로그·트레이스·NFM 경로를 자연어로 교차 분석</li><li><strong>핵심 차별점</strong> → In-account Bedrock AI + 읽기 전용 태세 + 4개 언어 UX</li></ul>
+<ul><li><strong>① 가시성</strong> → Overview·Topology·Monitoring + NFM·Direct Connect까지 통합된 Network 6종 메뉴</li><li><strong>② FinOps</strong> → 읽기 전용 비용 분석 + Rightsizing 인사이트 + OpenCost 패널</li><li><strong>③ Well-Architected</strong> → 종합진단 리포트 자동 생성 (light·mid/deep, DOCX/PDF)</li><li><strong>④ 보안성</strong> → Security Findings + CIS Compliance 벤치마크, 둘 다 읽기 전용</li><li><strong>⑤ 장애 대응 AI</strong> → AI Assistant/Diagnosis가 메트릭·로그·트레이스·NFM 경로를 자연어로 교차 분석</li><li><strong>핵심 차별점</strong> → In-account Bedrock AI + 읽기 전용 태세 (ADR-005 FROZEN) + 4개 언어 UX</li></ul>
   </div>
 </div>
 
@@ -379,7 +379,7 @@ <h3>Foundation</h3>
 <p><strong>LIVE 오늘</strong>: workers · steampipe · agentcore · integrations · ai_cost_tracking · diagnosis_schedule · diagnosis_notify · eks_auto_register · hybrid_routing</p>
 </div><div class="col">
 <h3>Feature Flags (~17개, 전부 default-off = $0)</h3>
-<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>FROZEN</strong>, do-not-enable</li></ul>
+<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>ADR-005 FROZEN</strong>, do-not-enable</li></ul>
 </div>
 </div>
   </div>
@@ -394,7 +394,7 @@ <h3>Core Layers</h3>
 <table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>network.tf</code></td><td>VPC 신규/재사용</td></tr><tr><td><code>edge.tf</code></td><td>CloudFront + VPC Origin + ALB</td></tr><tr><td><code>auth.tf</code></td><td>Cognito + Lambda@Edge</td></tr><tr><td><code>data.tf</code></td><td>Aurora + schema</td></tr><tr><td><code>workload.tf</code></td><td>ECS web service</td></tr><tr><td><code>ecr.tf</code></td><td>dual-tier ECR</td></tr><tr><td><code>ai.tf</code></td><td>AgentCore + SSM</td></tr><tr><td><code>workers.tf</code></td><td>SQS + SFN + Lambda</td></tr></tbody></table>
 </div><div class="col">
 <h3>Gated Subsystems</h3>
-<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포</td></tr></tbody></table>
+<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포 (ADR-015)</td></tr></tbody></table>
 </div>
 </div>
   </div>
@@ -406,7 +406,7 @@ <h3>Gated Subsystems</h3>
     <div class="columns">
 <div class="col">
 <h3>Next.js 14 Standalone (arm64)</h3>
-<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트</li></ul>
+<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트(ADR-009)</li></ul>
 <h3>Routes</h3>
 <ul><li><code>/api/health</code> — 공개 헬스체크</li><li><code>/api/stream</code> — SSE 스트리밍</li><li><code>/api/db</code> — Aurora ping</li><li><code>/api/jobs</code> (+<code>/[id]</code>) — 비동기 작업</li></ul>
 </div><div class="col">
@@ -422,7 +422,7 @@ <h3>Routes</h3>
     <div class="columns">
 <div class="col">
 <h3>Aurora (PostgreSQL 17.9)</h3>
-<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
+<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>ADR-030 스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
 </div><div class="col">
 <h3>Steampipe = 인벤토리 sync ONLY</h3>
 <p><div style="background:rgba(0,255,136,0.08);border:1px solid rgba(0,255,136,0.3);border-radius:10px;padding:1rem;margin-top:0.5rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;margin-bottom:0.5rem;">warm Fargate → Aurora → /inventory/[type]</div><div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">flag-gated (<code style="color:#00ff88;">steampipe_enabled</code>)<br><b style="color:#00ff88;">41종</b> 리소스 타입 동기화<br>fan-out sync · registry-driven nav</div><div style="color:#ef4444;font-size:0.75rem;margin-top:0.625rem;border-top:1px solid rgba(239,68,68,0.3);padding-top:0.5rem;">NOT a live query engine — pg Pool / 라이브 조회 아님</div></div></p>
@@ -474,13 +474,13 @@ <h3>Steampipe = 인벤토리 sync ONLY</h3>
     <span style="background:rgba(168,85,247,0.18);color:#c4a0f7;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">ops</span>
     <span style="background:rgba(0,212,255,0.18);color:#7fd8ff;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">external-obs</span>
   </div>
-  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 설계 원칙에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
+  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격, ADR-004) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 ADR-001/010에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
 </div>
   </div>
 </div>
 
 <div class="slide" data-remarp-id="s8" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat</h2></div>
+  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat — ADR-003</h2></div>
   <div class="slide-body" data-remarp-id="s8-body">
     <div class="columns">
 <div class="col">
@@ -564,7 +564,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -604,7 +604,7 @@ <h3>Read-Only Query</h3>
 </div>
 
 <div class="slide" data-remarp-id="s14" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out</h2></div>
+  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out (ADR-011)</h2></div>
   <div class="slide-body" data-remarp-id="s14-body">
     <div class="columns">
 <div class="col">
@@ -612,7 +612,7 @@ <h3>Registry + Assume</h3>
 <ul><li>Aurora <strong>accounts</strong> 레지스트리 — 호스트 계정은 lazy seed</li><li>대상 계정 <code>AWSopsReadOnlyRole</code>을 host task role이 <strong>STS AssumeRole</strong></li><li><strong>ExternalId</strong> — 1st-party(trust policy가 task-role ARN 핀) = <strong>선택</strong>, 3rd-party/와일드카드 = <strong>필수</strong>(confused-deputy 방어)</li><li>글로벌 셀렉터: 단일 계정 스코프 / <code>__all__</code> = 전 계정 fan-out</li></ul>
 </div><div class="col">
 <h3>Safety</h3>
-<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
+<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
 </div>
 </div>
   </div>
@@ -625,7 +625,7 @@ <h3>Safety</h3>
 <div class="col">
 <h3>Cognito + Lambda@Edge</h3>
 <ul><li><strong>us-east-1</strong>, py3.12, viewer-request</li><li><strong>RS256 JWKS</strong> 서명 검증 (iss/aud/token_use)</li><li>OAuth <code>state</code> + <strong>PKCE public client</strong></li></ul>
-<h3>Login</h3>
+<h3>Login (ADR-002)</h3>
 <ul><li><strong>Primary</strong> = 자체 <code>/login</code> 폼</li><li>BFF <code>POST /api/auth/login</code> → 무서명 공개 <code>InitiateAuth(USER_PASSWORD_AUTH)</code> → <code>awsops_token</code> (id_token 12h)</li><li>Hosted UI PKCE = <strong>dark fallback</strong>, signout = 쿠키 삭제</li></ul>
 </div><div class="col">
 <p><div style="display:flex;flex-direction:column;gap:0.75rem;margin-top:0.5rem;"><div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;">🔒 Private Edge</div><div style="color:#8b95a5;font-size:0.8125rem;">공개 ALB 없음 — 진입점은 CloudFront 하나</div></div><div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00d4ff;font-weight:bold;font-size:0.9375rem;">🔑 ECS Secrets</div><div style="color:#8b95a5;font-size:0.8125rem;">execution role 권한 (task role 아님)</div></div><div style="background:rgba(168,85,247,0.1);border:1px solid rgba(168,85,247,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#a855f7;font-weight:bold;font-size:0.9375rem;">👤 Admin</div><div style="color:#8b95a5;font-size:0.8125rem;">SSM + Cognito group (fail-closed)</div></div></div></p>
@@ -670,16 +670,16 @@ <h3>Login</h3>
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
+  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -693,7 +693,7 @@ <h3>Login</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Key Takeaways — Architecture</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 19: Key Takeaways --></p>
-<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>하이브리드 라우팅 + 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock</li></ul>
+<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock</li></ul>
   </div>
 </div>
 
@@ -1124,7 +1124,7 @@ <h3>동작 흐름 (read-only)</h3>
 <h3>분석 결과 예시 (권장만)</h3>
 <ul><li>"<strong>payment</strong> Pod: CPU request 500m, 실사용 50m → <strong>90% 과할당</strong> (rightsizing 권장)"</li><li>"<strong>frontend</strong> Deployment: Memory limit 2Gi, 사용량 200Mi → <strong>다운사이징 권장</strong>"</li><li>"Node 3대 중 <strong>2대 활용률 15% 미만</strong> → 통합 검토"</li><li>"예상 월 절감 <strong>$1,200</strong> — 권장사항"</li></ul>
 <h3>Read-Only 원칙</h3>
-<blockquote><p>권장사항만 제시 · <strong>자동 적용 없음</strong> (mutating 설치 버튼은 동결 — do-not-enable)</p></blockquote>
+<blockquote><p>권장사항만 제시 · <strong>자동 적용 없음</strong> (mutating 설치 버튼은 <strong>ADR-005</strong>로 동결 — do-not-enable)</p></blockquote>
 </div>
 </div>
   </div>
@@ -1329,7 +1329,7 @@ <h3>스케줄 진단 (<code>diagnosis_schedule_enabled</code>)</h3>
 <ul><li><code>report_schedules</code> 테이블 — 주간 / 격주 / 월간 (<code>next_run_at</code> 기준)</li><li>hourly <strong><code>schedule_dispatcher</code></strong> — 스캔 후 <code>report</code> job enqueue</li><li>v1 <code>report-scheduler.ts</code> 패턴 승계</li></ul>
 </div><div class="col">
 <h3>알림 다이제스트 (병합·배포 완료)</h3>
-<ul><li><strong><code>diagnosis_digest.py</code></strong> — <code>notified_at IS NULL</code> 리포트를 ~15분 배치로 묶어 SNS 1건 발송 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 main 병합·라이브 배포됨; 승인된 범위는 스케줄 요약뿐이지만 현재 구현은 수동 실행분까지 묶음 — 후속 정리 대상)</li><li>완료 즉시 개별 발송(per-report) 방식 폐기 — 폭주 방지(하루 44건 → 1건)</li><li><strong>PII 스크러빙</strong> — Bedrock 호출 전 ARN·계정ID·이메일·IP·액세스키를 결정론적으로 마스킹 (현재 라이브)</li></ul>
+<ul><li><strong><code>diagnosis_digest.py</code></strong> — <code>notified_at IS NULL</code> 리포트를 ~15분 배치로 묶어 SNS 1건 발송 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 main 병합·라이브 배포됨; ADR-13이 승인한 건 스케줄 요약뿐이라 수동 실행분까지 묶는 현재 범위는 ADR 정리 대상)</li><li>완료 즉시 개별 발송(per-report) 방식 폐기 — 폭주 방지(하루 44건 → 1건)</li><li><strong>PII 스크러빙</strong> — Bedrock 호출 전 ARN·계정ID·이메일·IP·액세스키를 결정론적으로 마스킹 (현재 라이브)</li></ul>
 </div>
 </div>
   </div>
@@ -1404,7 +1404,7 @@ <h3>인증 & 온보딩</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Feature Tour: 멀티 계정 Security & Compliance</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 12: Feature Tour — Multi-Account Security & Compliance --></p>
-<p><strong>멀티 계정</strong> — STS AssumeRole read-only fan-out (ExternalId: 1st-party 옵션 · 3rd-party 필수) · 계정별 보안/컴플라이언스 스코핑 · CVE Severity Distribution donut(ECR 스캔 집계).</p>
+<p><strong>ADR-011</strong> — STS AssumeRole read-only fan-out (ExternalId: 1st-party 옵션 · 3rd-party 필수) · 계정별 보안/컴플라이언스 스코핑 · CVE Severity Distribution donut(ECR 스캔 집계).</p>
 <div class="columns">
   <div class="col">
     <h3>Security Findings Pipeline</h3>
@@ -1472,8 +1472,8 @@ <h3>AWSops가 제공하는 것</h3>
 <h3>핵심 차별점</h3>
 <ul><li><strong>in-account Bedrock</strong> (외부 AI SaaS API 없음)</li><li><strong>private edge</strong> (공개 ALB 없음, CloudFront VPC Origin)</li><li>OOM-safe 비동기 워커 티어</li></ul>
 </div><div class="col">
-<h3>Read-Only 자세</h3>
-<ul><li><strong>AWS-리소스 변경 + 자율 = 동결</strong> (do-not-enable)</li><li>외부 관측성 <strong>READ</strong> 허용</li><li>외부 기록 / 티켓 / 메시지 <strong>WRITE</strong> 는 거버넌스 하 허용
+<h3>Read-Only 자세 (ADR-005/007)</h3>
+<ul><li><strong>AWS-리소스 변경 + 자율 = 동결</strong> (ADR-005, do-not-enable)</li><li>외부 관측성 <strong>READ</strong> 허용</li><li>외부 기록 / 티켓 / 메시지 <strong>WRITE</strong> 는 거버넌스 하 허용
 <ul><li>SSRF · Secrets · DLP · human-gate · flag-OFF</li></ul></li><li>변경되는 것은 <strong>DATA</strong>, AWS 리소스가 아님</li></ul>
 <h3>시작하기</h3>
 <ol><li><code>make configure</code> → Terraform apply</li><li><code>make deploy</code></li><li>Cognito 사용자 추가 · <code>/login</code></li><li>어시스턴트에서 질문 시작</li></ol>
@@ -1506,43 +1506,43 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     2: "[1min] 총 65분 세션으로 3개 파트로 나누어 진행합니다.\n첫 번째로 왜 이런 도구가 필요한지, 두 번째로 어떻게 만들었는지, 세 번째로 실제로 어떻게 쓰는지를 보여드리겠습니다.",
     3: "⏸️ [3min] [요약]\n• 이 프로젝트를 시작할 때 세운 5가지 목표를 먼저 공유합니다.\n\n이 프로젝트를 시작할 때 5가지 목표를 세웠습니다.\n\n첫째, DevOps·SRE의 가시성 향상입니다. 콘솔을 오가지 않고 NFM 트래픽 분석, Direct Connect 상태, DNS·IP·VPC 엔드포인트·Network Firewall까지 한 화면에서 봅니다.\n\n\n둘째, FinOps로 비용을 최적화하는 것입니다. 읽기 전용 비용 분석과 rightsizing 인사이트, OpenCost 패널을 상시 확인합니다.\n\n셋째, Well-Architected 기준으로 아키텍처를 점검하는 것입니다. 종합진단 리포트가 6개 Pillar에 매핑되어 자동 생성됩니다.\n\n넷째, 보안성 향상입니다. Security Findings와 CIS Compliance 벤치마크를 상시 노출합니다.\n\n다섯째, 장애가 났을 때 AI가 트래픽과 원인을 분석하는 것입니다. NFM의 E2E hop path까지 포함해 자연어로 교차 분석합니다.\n\n\n이 5가지 목표가 앞으로 볼 모든 기능의 출발점입니다. 먼저 이걸 만들게 된 도전 과제부터 보겠습니다.",
     4: "❓ ⏸️ [3min] 클라우드 운영을 하다 보면 정말 많은 도전 과제에 직면합니다.\n\n첫 번째는 Console Hopping입니다. 하나의 이슈를 해결하려면 EC2 콘솔에서 시작해서 CloudWatch로 메트릭 보고, VPC에서 네트워크 확인하고, IAM에서 권한 체크하고... 평균 5-7개 콘솔을 돌아다녀야 합니다. 멀티 어카운트면 로그인만 해도 지칩니다.\n\n\n\n두 번째는 데이터 사일로입니다. CloudWatch 메트릭, Prometheus 메트릭, 로그, 트레이스가 각각 다른 시스템에 있어서 교차 분석이 어렵습니다. \"CPU가 높아졌는데 어떤 서비스 때문이지?\" 라는 질문에 답하려면 여러 도구를 동시에 봐야 합니다.\n\n세 번째, 네 번째도 마찬가지로 반복 작업과 보고서 부담이 큽니다.\n\n\n여러분도 이런 경험 있으시죠? 특히 FinOps 리포트를 매달 수동으로 만들어 본 경험이 있으신 분?\n\n\nAWSops는 이 4가지 문제를 동시에 해결합니다.",
-    5: "⏸️ [3min] AWSops는 3개 레이어로 구성됩니다.\n\n\nData Layer는 Aurora Serverless v2가 중심입니다. PostgreSQL 17 기반으로 worker 작업, chat 스레드, 진단 리포트 같은 영속 상태를 안전하게 저장합니다. 인벤토리는 flag로 켜는 Steampipe sync가 41종 리소스 타입을 Aurora로 동기화해 화면에 보여주는 보조 역할입니다. 라이브 조회 엔진이 아니라 인벤토리 캐시라는 점이 핵심입니다.\n\nAI Engine은 Bedrock입니다. Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)로 설계되어 160개 이상의 읽기 전용 도구를 갖췄고, 함대 배포가 완료되어 30개 슬라이스 전부, 9개 게이트웨이 전부 READY MCP 타깃을 보유하고 있습니다. 라우팅은 하이브리드 방식으로 빠르고 정확합니다.\n\nDashboard는 Next.js 14 thin-BFF입니다. Overview, AI Diagnosis, Assistant, Security, Compliance, Topology, Monitoring, Accounts, Integrations, Jobs, Customization까지 하나의 대시보드로 통합되어 있고, 화면에 보이는 스크린샷처럼 실제 라이브 v2 환경입니다. 무거운 작업은 비동기 워커 티어로 넘깁니다.\n\n\n구체적인 숫자를 보겠습니다.",
+    5: "⏸️ [3min] AWSops는 3개 레이어로 구성됩니다.\n\n\nData Layer는 Aurora Serverless v2가 중심입니다. PostgreSQL 17 기반으로 worker 작업, chat 스레드, 진단 리포트 같은 영속 상태를 안전하게 저장합니다. 인벤토리는 flag로 켜는 Steampipe sync가 41종 리소스 타입을 Aurora로 동기화해 화면에 보여주는 보조 역할입니다. 라이브 조회 엔진이 아니라 인벤토리 캐시라는 점이 핵심입니다.\n\nAI Engine은 Bedrock입니다. Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)로 설계되어 160개 이상의 읽기 전용 도구를 갖췄고, 함대 배포가 완료되어 30개 슬라이스 전부, 9개 게이트웨이 전부 READY MCP 타깃을 보유하고 있습니다. 라우팅은 ADR-003 하이브리드 방식으로 빠르고 정확합니다.\n\nDashboard는 Next.js 14 thin-BFF입니다. Overview, AI Diagnosis, Assistant, Security, Compliance, Topology, Monitoring, Accounts, Integrations, Jobs, Customization까지 하나의 대시보드로 통합되어 있고, 화면에 보이는 스크린샷처럼 실제 라이브 v2 환경입니다. 무거운 작업은 비동기 워커 티어로 넘깁니다.\n\n\n구체적인 숫자를 보겠습니다.",
     6: "[1min] [요약]\n• 슬라이드웨어 목업이 아니라 실제 라이브 v2 환경 캡처\n\n지금 보시는 건 mockup이 아니라 실제 운영 중인 v2 대시보드 화면입니다.\n\n\n숫자로 다시 정리해 보겠습니다.",
-    7: "[2min] 숫자보다 구조로 보면 더 명확합니다.\n\n인프라는 Terraform 기반 MSA입니다. 공개 ALB 없이 CloudFront VPC Origin이 내부 ALB를 거쳐 Fargate로 들어오는 비공개 엣지 구조입니다. 컴퓨트는 ECS Fargate로, 웹 thin-BFF와 OOM에 안전한 비동기 워커 티어가 분리되어 있습니다. 모두 arm64입니다.\n\n데이터는 Aurora Serverless v2, PostgreSQL 17로 영속 상태를 보관하고, 인벤토리는 41종 리소스 타입을 sync합니다.\n\nAI는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)에 160개 이상의 읽기 전용 도구가 설계되어 있고, 30개 슬라이스 전부 함대 배포되어 9개 게이트웨이 전부 READY 상태입니다. 라우팅은 하이브리드로 게이트 정확도 96.9%를 달성했습니다. 진단은 light·mid 티어가 9섹션(기본 8 + 의도-실제 드리프트 1), deep 티어가 16섹션이며 Well-Architected에 매핑되고 DOCX/PDF로 뽑을 수 있습니다. UX 쪽은 3-테마·모바일 대응에 더해 한국어/English/中文/日本語 4개 언어를 완전히 지원합니다 — 일본어는 최근 복원되어 전체 화면 번역 커버리지 점검까지 마쳤습니다.\n\n\n이게 어떤 가치를 만드는지 보겠습니다.",
+    7: "[2min] 숫자보다 구조로 보면 더 명확합니다.\n\n인프라는 Terraform 기반 MSA입니다. 공개 ALB 없이 CloudFront VPC Origin이 내부 ALB를 거쳐 Fargate로 들어오는 비공개 엣지 구조입니다. 컴퓨트는 ECS Fargate로, 웹 thin-BFF와 OOM에 안전한 비동기 워커 티어가 분리되어 있습니다. 모두 arm64입니다.\n\n데이터는 Aurora Serverless v2, PostgreSQL 17로 영속 상태를 보관하고, 인벤토리는 41종 리소스 타입을 sync합니다.\n\nAI는 9개 섹션 게이트웨이(8개 AWS 도메인 + external-obs)에 160개 이상의 읽기 전용 도구가 설계되어 있고, 30개 슬라이스 전부 함대 배포되어 9개 게이트웨이 전부 READY 상태입니다. 라우팅은 ADR-003 하이브리드로 게이트 정확도 96.9%를 달성했습니다. 진단은 light·mid 티어가 9섹션(기본 8 + 의도-실제 드리프트 1), deep 티어가 16섹션이며 Well-Architected에 매핑되고 DOCX/PDF로 뽑을 수 있습니다. UX 쪽은 3-테마·모바일 대응에 더해 한국어/English/中文/日本語 4개 언어를 완전히 지원합니다 — 일본어는 최근 복원되어 전체 화면 번역 커버리지 점검까지 마쳤습니다.\n\n\n이게 어떤 가치를 만드는지 보겠습니다.",
     8: "⏸️ [3min] 두 가지 관점에서 가치를 드립니다.\n\nDevOps나 SRE 분들에게는 콘솔 호핑 없이 한 화면에서 모든 리소스를 보고, AI에게 자연어로 질문하면 됩니다. \"이 EC2 인스턴스가 왜 느려?\"라고 물으면 CloudWatch 메트릭을 확인하고, 네트워크 경로를 분석하고, 관련 로그를 찾아줍니다. 모두 읽기 전용이고, 응답은 스트리밍으로 흐릅니다. Topology와 EKS 읽기 전용 뷰에 더해, NFM 트래픽 top-contributor와 E2E hop path, Direct Connect 피크 사용률·BGP 라우트, DNS·IP·VPC 엔드포인트·Network Firewall까지 네트워크 6종 메뉴가 같은 대시보드에 통합되어 있습니다. Prometheus·Loki·Tempo 같은 데이터소스 Explore도 함께 제공합니다.\n\n\n\nFinOps나 Management 분들에게는 읽기 전용 비용 분석과 rightsizing 인사이트를 드립니다. 중요한 건 권고만 제시하고 자동으로 바꾸지 않는다는 점입니다. 그리고 종합진단 리포트를 light·mid 티어 9섹션, deep 티어 16섹션으로 만들고, Well-Architected에 매핑해 DOCX와 PDF로 내보냅니다. 무거운 생성 작업은 비동기 워커가 처리하므로 수작업 2-3일이 사라집니다.\n\n\n가장 중요한 차별점을 보겠습니다.",
     9: "[1min] [요약]\n• Cmd-K로 어디서든 키보드 이동\n• 한/영/中/日 4개 언어, 최근 일본어 복원 + 전체 커버리지 점검\n\nCmd-K 커맨드 팔레트로 마우스 없이 전체 화면을 이동할 수 있고, 한국어·English·中文·日本語 4개 언어를 완전히 지원합니다. 일본어는 최근 복원되면서 전체 화면 번역 커버리지 점검도 함께 마쳤습니다.\n\n\n가장 중요한 차별점을 보겠습니다.",
-    10: "❓ [3min] AWSops의 차별점은 세 가지로 압축됩니다.\n\n첫째, In-Account Bedrock AI입니다. AI 추론을 고객 AWS 계정 안의 Bedrock에서 직접 호출합니다. OpenAI 같은 외부 AI SaaS API를 쓰지 않으므로 데이터가 계정 밖으로 나가지 않습니다. 금융, 공공, 의료처럼 데이터 주권이 중요한 환경에 적합합니다.\n\n둘째, 읽기 전용 운영 태세입니다. AWS 리소스 변경과 자율 실행은 동결(FROZEN)되어 있습니다. AI가 진단하고 권고할 뿐 직접 바꾸지 않으므로, 설계 단계에서부터 안전합니다. \"read-only\"는 AWS 리소스에 한정된 정의이고, 외부 관측성 데이터소스의 읽기/쓰기는 거버넌스 하에 별도로 허용됩니다.\n\n셋째, AI 종합진단 리포트입니다. Well-Architected에 매핑된 light·mid 9섹션, deep 16섹션 리포트를 비동기 워커가 생성하고 DOCX와 PDF로 내보냅니다.\n\n\n외부 AI SaaS에 운영 데이터를 보내는 게 부담스러웠던 분 계시죠? AWSops는 그 경로 자체가 없습니다.\n\n\n이제 아키텍처를 자세히 살펴보겠습니다.",
+    10: "❓ [3min] AWSops의 차별점은 세 가지로 압축됩니다.\n\n첫째, In-Account Bedrock AI입니다. AI 추론을 고객 AWS 계정 안의 Bedrock에서 직접 호출합니다. OpenAI 같은 외부 AI SaaS API를 쓰지 않으므로 데이터가 계정 밖으로 나가지 않습니다. 금융, 공공, 의료처럼 데이터 주권이 중요한 환경에 적합합니다.\n\n둘째, 읽기 전용 운영 태세입니다. ADR-005 기준으로 AWS 리소스 변경과 자율 실행은 동결(FROZEN, 새 명시적 결정 전까지)되어 있습니다. AI가 진단하고 권고할 뿐 직접 바꾸지 않으므로, 설계 단계에서부터 안전합니다. \"read-only\"는 AWS 리소스에 한정된 정의이고, 외부 관측성 데이터소스의 읽기/쓰기는 ADR-007 거버넌스 하에 별도로 허용됩니다.\n\n셋째, AI 종합진단 리포트입니다. Well-Architected에 매핑된 light·mid 9섹션, deep 16섹션 리포트를 비동기 워커가 생성하고 DOCX와 PDF로 내보냅니다.\n\n\n외부 AI SaaS에 운영 데이터를 보내는 게 부담스러웠던 분 계시죠? AWSops는 그 경로 자체가 없습니다.\n\n\n이제 아키텍처를 자세히 살펴보겠습니다.",
     11: "[2min] 첫 번째 파트를 정리하겠습니다.\n\nAWSops는 처음 세운 5가지 목표를 하나의 대시보드 안에서 동시에 해결합니다.\n가시성은 Overview·Topology·Monitoring에 NFM·Direct Connect를 포함한 네트워크 6종 메뉴까지 통합해서, FinOps는 읽기 전용 비용 분석과 Rightsizing으로, Well-Architected 점검은 자동 생성되는 종합진단 리포트로, 보안성은 Security Findings와 CIS Compliance로, 장애 대응은 AI가 메트릭·로그·트레이스·NFM 경로를 함께 교차 분석하는 것으로 풀었습니다.\n\n그리고 가장 중요한 것은, AI 추론을 고객 계정 안 Bedrock에서 돌리고, AWS 리소스 변경과 자율 실행은 동결한 읽기 전용 태세라는 점입니다. 설계상 안전합니다.\n\n\n5분 쉬고 아키텍처를 자세히 보겠습니다.",
     12: "[1min] 두 번째 파트, 아키텍처 딥다이브입니다.\nAWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다.\n핵심은 세 가지입니다. 첫째, Terraform 기반 MSA로 재구축했다는 점. 둘째, 공개 진입점이 없는 비공개 엣지 구조라는 점. 셋째, 읽기 전용 운영 태세 위에 모든 것이 설계되었다는 점입니다.\n\n전체 그림부터 보겠습니다.",
     13: "⏸️ [3min] 전체 구조는 4개 레이어의 비공개 엣지입니다.\n브라우저는 전용 도메인으로 들어오고, CloudFront가 TLS로 받습니다. 여기서 VPC Origin을 https-only 443으로 설정해 내부 ALB까지 TLS가 끊기지 않게 합니다. origin 도메인을 public FQDN으로 지정해 SNI가 맞아야 합니다.\n\n핵심은 공개 ALB가 없다는 점입니다. 내부 ALB의 보안 그룹은 CloudFront 관리형 SG에서 오는 443만 허용합니다. VPC CIDR만 열면 504가 납니다. ALB는 HTTP로 Fargate의 web 컨테이너 3000번 포트로 전달합니다.\n영속 상태는 Aurora에 두고, 라이브 AWS 조회는 AgentCore MCP 도구가, 무거운 작업은 비동기 워커가 처리합니다.\n\n이 인프라를 어떻게 코드로 관리하는지 보겠습니다.",
-    14: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 동결 상태이고, integrations_write는 off이지만 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
-    15: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
-    16: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
-    17: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
+    14: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 ADR-005 동결 상태이고, integrations_write는 off이지만 ADR-007 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
+    15: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 ADR-005로 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
+    16: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`, ADR-009)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
+    17: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 ADR-030 기반 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
     18: "⏸️ [2min] AI 엔진은 Bedrock AgentCore입니다.\n모델은 Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore Runtime이 Strands 기반 `agent/agent.py`를 실행합니다. Memory와 Code Interpreter도 함께 붙어 있습니다.\n\n설정의 source of truth는 SSM입니다. provision.py가 runtime ARN, interpreter ID, memory ID를 `/ops/awsops-v2/agentcore/` 경로에 기록하고, 웹 BFF가 런타임에 읽습니다. valueFrom 레이스를 피하려는 의도적 설계입니다.\n\n이 런타임이 어떤 도구를 들고 있는지 보겠습니다.",
-    19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. 2026년 6월 24일에 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
-    20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
+    19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
+    20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     21: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
-    22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
+    22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     23: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",
     24: "⏸️ [3min] 관측성 데이터는 읽기 전용 데이터소스 플랫폼으로 통합합니다.\nClickHouse, Prometheus, Loki, Tempo, Mimir 커넥터를 지원합니다. 각 커넥터는 Lambda로 구현되고, 스키마는 Aurora에 캐시합니다. 이 데이터를 챗에 주입하면 AI가 여러 데이터소스를 교차 조회할 수 있습니다. `/datasources` Explore 페이지에서는 자연어를 쿼리로 변환해 직접 탐색할 수도 있습니다. 모두 읽기 전용입니다.\n\n토폴로지는 리소스 간 관계를 그래프로 보여줍니다. flow 그래프와 infra 리소스 그래프 두 가지가 있고, CloudFront에서 로드밸런서, 타깃 그룹, DB로 이어지는 경로를 시각화합니다. `/topology/resource/[id]`로 들어가면 개별 리소스의 상세 패널을 볼 수 있습니다.\n\n컨테이너 운영자를 위한 EKS 통합을 보겠습니다.",
     25: "⏸️ [3min] EKS도 읽기 전용으로 통합되는데, 인증 경로가 3가지로 늘었습니다. 원래 경로는 configure.mjs 멀티선택으로 시작해서 eks.tf가 웹 task role에 Access Entry를 부여하고 AmazonEKSAdminViewPolicy를 클러스터 스코프로 붙이는 방식입니다. View가 아니라 AdminView인 이유는, View 정책엔 클러스터 스코프 리소스가 없어서 노드 목록 조회가 403이 나기 때문입니다. AdminView는 */*/get,list,watch라 시크릿까지 읽을 수 있지만, BFF가 노출하는 kind는 화이트리스트로 제한되어 있어서 시크릿·컨피그맵은 절대 통과하지 않습니다.\n\n여기에 sa-token과 assume-role 두 가지 경로가 Aurora의 eks_registrations.auth에 더해졌습니다. 클러스터별로 등록하면 되고 terraform 온보딩이 필요 없습니다. 그리고 지금 라이브인 auto-register 경로가 있는데, EventBridge가 CloudTrail의 AssociateAccessPolicy나 DeleteAccessEntry 이벤트를 잡아서 Lambda를 거쳐 eks_registrations에 자동으로 기록합니다. 버튼을 누를 필요가 없습니다.\n조회는 nodes, pods, deployments, services 같은 핵심 리소스를 BFF가 직접 처리합니다. 워커를 거치지 않습니다. 그리고 한 가지 더, ListClusters·DescribeCluster 같은 핵심 discovery 권한은 이제 게이트가 아니라 workload.tf에 상시로 붙어 있습니다. 그래서 온보딩 플래그가 꺼져 있어도 /api/eks, /api/overview, /api/cost는 항상 정상 동작합니다.\nEKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워크로드 뷰가 있습니다.\n\n계정을 하나 더 늘리면 어떻게 되는지, 멀티 계정 구조를 보겠습니다.",
-    26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
-    27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
+    26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
+    27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     28: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
-    30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
+    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 \"영구 금지\"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 \"안전조건 충족 + 새로운 명시적 결정 전까지\" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     31: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다.",
     32: "[1min] 마지막 파트입니다. 지금까지 왜 필요한지, 어떻게 만들었는지를 봤고, 이제 실제로 어떻게 쓰는지를 데모로 보여드리겠습니다.\nAI 어시스턴트, 비용/인벤토리/토폴로지 시나리오, 그리고 종합진단 리포트까지 순서대로 보겠습니다.\n\n한 가지 먼저 짚고 갈 점은, 오늘 보여드리는 모든 데모는 read-only라는 것입니다. 조회와 진단만 하고, AWS 리소스를 변경하지 않습니다.\n\n먼저 AI 어시스턴트 데모입니다.",
-    33: "⏸️ [2min] AI 어시스턴트의 동작 흐름을 보겠습니다. 자연어 질문 하나가 답변으로 이어지는 과정입니다.\n\n사용자가 \"EKS 비용 개선점 찾아줘\"라고 질문합니다. 첫 단계는 하이브리드 라우팅입니다. regex fast-path가 먼저 매칭을 시도하고, 애매하면 Haiku 분류기가 판단합니다. 프롬프트 캐싱으로 약 59% 히트율을 내고, 이 질문은 cost 섹션 게이트웨이로 라우팅됩니다.\n\n\n\n선택된 AgentCore 섹션 에이전트가 MCP 도구로 라이브 read-only AWS 조회를 수행합니다. Cost Explorer, EKS 메트릭 등 필요한 도구만 호출합니다. 그리고 in-account Bedrock이 결과를 분석합니다.\n\n\n같은 질문이 실제 화면에서 어떻게 보이는지 이어서 보겠습니다.",
+    33: "⏸️ [2min] AI 어시스턴트의 동작 흐름을 보겠습니다. 자연어 질문 하나가 답변으로 이어지는 과정입니다.\n\n사용자가 \"EKS 비용 개선점 찾아줘\"라고 질문합니다. 첫 단계는 ADR-003 하이브리드 라우팅입니다. regex fast-path가 먼저 매칭을 시도하고, 애매하면 Haiku 분류기가 판단합니다. 프롬프트 캐싱으로 약 59% 히트율을 내고, 이 질문은 cost 섹션 게이트웨이로 라우팅됩니다.\n\n\n\n선택된 AgentCore 섹션 에이전트가 MCP 도구로 라이브 read-only AWS 조회를 수행합니다. Cost Explorer, EKS 메트릭 등 필요한 도구만 호출합니다. 그리고 in-account Bedrock이 결과를 분석합니다.\n\n\n같은 질문이 실제 화면에서 어떻게 보이는지 이어서 보겠습니다.",
     34: "🎬 [1min] 응답은 SSE 스트리밍으로 실시간 전달되고, 어떤 라우트와 도구가 쓰였는지 UI에 함께 표시됩니다. 대화는 Aurora에 thread로 영속 저장되어, 사이드바에서 이어보기가 가능합니다. resizable drawer나 /assistant 전체 화면 어디서든 같은 thread를 씁니다.\n\n\n(데모) 어시스턴트에서 질문을 입력하고, 라우트 분류와 도구 호출, 그리고 스트리밍 답변을 보여줍니다.\n\n\n다음은 비용 분석 시나리오입니다.",
     35: "⏸️ [2min] 첫 번째 시나리오는 비용 분석과 rightsizing 인사이트입니다.\n\n\"비용 개선점 찾아줘\"라고 입력하면 cost 섹션 게이트웨이로 라우팅됩니다. cost 에이전트가 Cost Explorer와 Forecast를 read-only로 조회하고, Cost 대시보드가 서비스별 비용과 추이를 시각화합니다.\n\n\n\nEKS 워크로드는 read-only 메트릭으로 request 대비 실사용량을 비교합니다. 과할당된 파드와 다운사이징 후보, 통합 가능한 노드를 식별합니다. 결과는 구체적인 절감 추정치와 함께 제시됩니다.\n\n\n실제 Cost 대시보드 화면을 보겠습니다.",
-    36: "[1min] 여기서 중요한 점은, AWSops는 권장사항만 제시한다는 것입니다. 어떤 변경도 자동으로 적용하지 않습니다. 과거 설계에 있던 OpenCost mutating 설치 버튼은 AWS 리소스 변경·자율 조치 동결(FROZEN) 원칙에 따라 동결됐습니다. 진단과 권고까지가 AWSops의 역할이고, 적용 결정과 실행은 운영자의 몫입니다.\n\n\n다음은 인벤토리와 유휴 리소스 점검입니다.",
+    36: "[1min] 여기서 중요한 점은, AWSops는 권장사항만 제시한다는 것입니다. 어떤 변경도 자동으로 적용하지 않습니다. 과거 설계에 있던 OpenCost mutating 설치 버튼은 **ADR-005**(AWS 리소스 변경·자율 조치 = FROZEN)로 동결됐습니다. 진단과 권고까지가 AWSops의 역할이고, 적용 결정과 실행은 운영자의 몫입니다.\n\n\n다음은 인벤토리와 유휴 리소스 점검입니다.",
     37: "⏸️ [1min] 두 번째 시나리오는 인벤토리와 유휴 리소스 점검입니다.\n\nAWSops는 41가지 리소스 타입을 제네릭 `/inventory/[type]` 페이지로 제공합니다. 이 데이터는 flag-gated Steampipe sync가 warm Fargate에서 돌면서 Aurora로 적재한 것입니다. registry 기반으로 내비게이션이 자동 구성되고, 페이지마다 KPI, donut, 필터로 구성된 mini-dashboard가 붙습니다.\n\n\n\n여기서 분명히 할 점은, Steampipe는 인벤토리 sync 전용이라는 것입니다. 라이브 쿼리 엔진이 아닙니다. 실시간 조회와 분석은 AgentCore MCP 도구가 담당합니다. 인벤토리 화면에서 후보를 좁히고, 에이전트로 라이브 현황을 보강하는 방식입니다.\n\n\n실제 인벤토리 화면을 보겠습니다.",
     38: "[1min] 미연결 EBS, 미사용 Elastic IP, 오래된 스냅샷, 중지된 EC2, 참조 없는 Security Group 같은 후보를 read-only로 점검합니다. 변경은 하지 않고, 검토 대상만 정리합니다.\n\n\n세 번째 시나리오, 토폴로지입니다.",
     39: "⏸️ [2min] 세 번째 시나리오는 토폴로지와 의존성 시각화입니다.\n\nAWSops는 flow 그래프와 infra 리소스 그래프 두 가지를 제공합니다. CloudFront에서 시작해 Load Balancer, Target Group, Database로 이어지는 CF → LB → TG → DB 체인을 한눈에 보여줍니다.\n\n\n\n리소스 노드를 클릭하면 `/topology/resource/[id]` 상세 페이지로 이동합니다. 해당 리소스가 무엇에 연결되어 있고 무엇이 그것에 의존하는지를 추적할 수 있습니다. 최근에는 그래프 자체가 **계정별로 스코핑**되어, 멀티 계정 환경에서 계정 단위로 필터링해 볼 수 있습니다.\n\n\n실제 토폴로지 그래프 화면을 보겠습니다.",
     40: "[1min] 이것이 진단에 중요한 이유는 blast radius, 즉 영향 범위 분석 때문입니다. 어떤 리소스에 문제가 생겼을 때 그 영향이 어디까지 전파되는지, 어떤 의존 관계를 끊어야 하는지를 그래프로 따라갈 수 있습니다. VPC 상세 패널에서는 풀스크린 **VPC Resource Map**을 열 수 있는데, VPC → Subnet(AZ별) → Route Table → IGW/NAT/TGW까지 라우팅 구조를 한 화면에서 클릭으로 하이라이트하며 추적합니다. 과거의 자율 인시던트 수집 루프 대신, 사람이 그래프를 보며 의존 관계를 진단하는 read-only 방식입니다.\n\n\n이제 플래그십 기능인 종합진단 리포트를 보겠습니다.",
-    41: "⏸️ [2min] AI 종합진단 리포트는 AWSops의 플래그십 기능입니다. 전부 read-only로 동작합니다.\n\n리포트는 두 등급입니다. light·mid는 9개 섹션, deep는 16개 섹션이고 Well-Architected Framework에 매핑됩니다. deep 등급은 기본 Sonnet으로 동작하고, 필요하면 cost-gate를 거쳐 Opus를 선택할 수 있습니다.\n\n\n\n실행은 비동기 워커 티어에서 일어납니다. 웹은 thin-BFF라 무거운 작업을 직접 돌리지 않고 워커 큐에 넣는데, 진단 잡은 범용 `POST /api/jobs`가 아니라 소유권을 검사하는 전용 라우트 `/api/diagnosis`로 제출합니다(IDOR 방지 — 범용 라우트는 `noop` 계열만 허용). SQS, Step Functions, Lambda 또는 Fargate 워커가 받아서 섹션을 분석합니다. 진행 상황은 SSE로 실시간 표시됩니다. \"3/16 Security Posture 분석 중\" 같은 상태가 클라이언트에 흐릅니다.\n\n\n완성된 리포트 화면을 보겠습니다.",
+    41: "⏸️ [2min] AI 종합진단 리포트는 AWSops의 플래그십 기능입니다. 전부 read-only로 동작합니다.\n\n리포트는 두 등급입니다. light·mid는 9개 섹션, deep는 16개 섹션이고 Well-Architected Framework에 매핑됩니다. deep 등급은 기본 Sonnet으로 동작하고, 필요하면 cost-gate를 거쳐 Opus를 선택할 수 있습니다.\n\n\n\n실행은 비동기 워커 티어에서 일어납니다. 웹은 thin-BFF라 무거운 작업을 직접 돌리지 않고 워커 큐에 넣는데, 진단 잡은 범용 `POST /api/jobs`가 아니라 소유권을 검사하는 전용 라우트 `/api/diagnosis`로 제출합니다(ADR-009, IDOR 방지 — 범용 라우트는 `noop` 계열만 허용). SQS, Step Functions, Lambda 또는 Fargate 워커가 받아서 섹션을 분석합니다. 진행 상황은 SSE로 실시간 표시됩니다. \"3/16 Security Posture 분석 중\" 같은 상태가 클라이언트에 흐릅니다.\n\n\n완성된 리포트 화면을 보겠습니다.",
     42: "[1min] 완성된 리포트는 자동 제목과 태그가 붙고, 소프트 삭제를 지원합니다. 리포트 목록과 상세 화면에서 열람할 수 있습니다.\n\n\n이 리포트를 어떻게 내보내는지 보겠습니다.",
     43: "⏸️ [2min] 완성된 리포트는 워커가 직접 문서로 내보냅니다.\n\nDOCX는 python-docx로, PDF는 chromium과 playwright로 렌더링합니다. 한글이 깨지지 않도록 Noto CJK 폰트를 워커 이미지에 포함했습니다. 내보내기는 워커 티어에서 실행되고, 실패해도 본 리포트 생성과 격리되어 영향을 주지 않습니다. 과거의 브라우저 Print-to-PDF 방식을 대체한 것입니다.\n\n\n\n생성된 파일은 S3의 `diagnosis/{id}.docx`와 `.pdf` 경로에 저장되고, BFF 프록시 라우트로 다운로드합니다. 생성 일시는 KST로 표기됩니다.\n\n라이프사이클 측면에서는 자동 제목과 태그 제안, 제목 수정, 소프트 삭제를 지원합니다. 읽기 경로는 `deleted_at IS NULL`을 전제로 하고, 수정과 삭제는 owner 또는 admin만 가능한 fail-closed입니다. 제목과 태그는 React-escape로 렌더해 XSS 위험을 차단합니다.\n\n\n다음은 스케줄 진단과 알림 다이제스트입니다.",
     44: "⏸️ [2min] [요약]\n• 스케줄 진단은 `report_schedules` 테이블 + hourly `schedule_dispatcher`로 자동 실행\n• 알림은 개별 발송에서 ~15분 배치 다이제스트로 전환됨(폭주 방지, 이미 라이브)\n• Bedrock 호출 전 PII를 결정론적으로 스크러빙 — \"왜 안전한가\"의 핵심 근거\n\n리포트는 수동 실행뿐 아니라 스케줄로도 돌 수 있습니다. `report_schedules` 테이블에 사용자별로 주간, 격주, 월간 주기를 등록하면, hourly로 도는 `schedule_dispatcher`가 `next_run_at`을 스캔해서 리포트 job을 큐에 넣습니다. v1 `report-scheduler.ts`의 패턴을 그대로 승계했습니다.\n\n\n\n완료된 리포트의 알림 방식도 이미 개선됐습니다. 예전에는 리포트가 끝날 때마다 SNS 이메일을 즉시 발송해서 하루에 44건이 몰리면 이메일이 44통 날아가는 문제가 있었는데, `diagnosis_digest.py`가 ~15분 주기로 `notified_at IS NULL`인 리포트를 모아 SNS 한 건으로 묶어 보내도록 이미 main에 병합·배포되어 라이브에서 동작 중입니다.\n\n\n\n그리고 이 파이프라인 전체에서 중요한 보안 포인트가 하나 있습니다. Bedrock을 호출하기 전에 ARN, 계정 ID, 이메일, IP, 액세스 키 같은 정보를 결정론적으로 스크러빙합니다. 진단 데이터가 LLM에 들어가기 전에 이미 민감 정보가 지워진다는 뜻입니다.\n\n\n이제 Datasources 화면을 보겠습니다.",
@@ -1551,9 +1551,9 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     47: "[1min] [요약]\n• EKS는 nodes/pods/deployments/services 개별 페이지 + K9s 스타일 explorer(11탭) + container cost로 확장\n• 인증은 sa-token / assume-role / task-role(Access Entry) 3가지 모드\n• Access Entry 보유 클러스터는 즉시(LIVE) 조회 등록 가능\n\nEKS 화면도 read-only지만 이제 완전한 메뉴 패밀리입니다. fleet 전체의 nodes, pods, deployments, services를 각각의 페이지로 보고, K9s 스타일 explorer에서는 11개 리소스 종류를 탭으로 오갈 수 있습니다. container cost 뷰도 붙었습니다.\n\n\n실제 EKS 화면 두 장을 보겠습니다.",
     48: "[1min] 인증은 세 가지 모드를 지원합니다. 읽기 전용 ServiceAccount 토큰을 붙이는 sa-token, Access Entry가 있는 IAM Role을 assume하는 assume-role, 그리고 web task role 자체의 Access Entry를 쓰는 task-role입니다. task role은 **AmazonEKSAdminViewPolicy**(View가 아니라 AdminView — View는 클러스터 스코프 리소스가 없어 nodes 조회가 403남) 권한을 클러스터 스코프로 가지고, BFF의 kind allow-list가 secrets 등 민감 kind를 차단합니다. Access Entry가 이미 있는 클러스터는 별도 자격 증명 없이 LIVE로 즉시 등록할 수 있습니다.\n\n\n지금까지 안 다룬 두 가지를 더 보겠습니다. 서비스별 진단 계층과 멀티 계정 보안입니다.",
     49: "⏸️ [2min] [요약]\n• 11개 서비스 각각에 전용 진단 UI + 접이식 \"owner 가이드\" 설명이 붙음\n• 콘솔처럼 지표만 보여주는 게 아니라 \"왜\" 문제인지까지 설명하는 것이 차별점\n• 새 서비스 추가는 GuideSpec 데이터 하나만 늘리면 됨 (컴포넌트 재사용)\n\n여기서부터는 지금까지 데모에서 못 짚은 부분을 훑어보겠습니다. 먼저 서비스별 진단 계층입니다. RDS, DynamoDB, ElastiCache, MSK, OpenSearch, ALB/NLB, S3/EBS, EC2, Lambda까지 11개 서비스 각각에 전용 진단 화면이 있습니다.\n\n\n\n각 화면에는 접었다 펼 수 있는 \"owner 가이드\"가 붙어있어서, 이 지표가 왜 중요한지, 어떤 값이 정상이고 어떤 값이 위험한지를 설명합니다. 표면적으로는 그냥 콘솔처럼 보이지만, 실제로는 각 서비스마다 문제의 원인을 설명해주는 진단 가이드가 함께 붙어있다는 점이 차별점입니다. 지표 테이블은 range-picker로 기간을 바꾸고 정렬도 가능합니다.\n\n\n구현 관점에서도 재사용성이 좋습니다. 컴포넌트 하나가 `GuideSpec` 데이터를 받아 렌더링하기 때문에, 서비스를 하나 추가하는 건 새 컴포넌트가 아니라 데이터 하나를 추가하는 일입니다.\n\n\n다음은 멀티 계정 보안과 컴플라이언스입니다.",
-    50: "⏸️ [2min] [요약]\n• 멀티 계정은 STS AssumeRole read-only fan-out, ExternalId는 1st-party 옵션·3rd-party 필수\n• Security 페이지에 CVE Severity Distribution donut(ECR 스캔 집계)이 추가됨\n• Compliance 벤치마크도 계정 단위로 스코핑되어 실행/이력 관리\n\n멀티 계정은 다음과 같이 지원합니다. 각 대상 계정에 STS AssumeRole로 read-only fan-out하고, ExternalId는 host ARN이 고정되는 1st-party 계정은 옵션, 신뢰 관계가 약한 3rd-party 계정은 필수입니다.\n\n\n\n이 화면의 왼쪽은 Security findings 파이프라인입니다. Public S3, Open SG, Unencrypted EBS, IAM MFA 같은 항목에 더해 ECR 스캔 결과를 집계한 CVE Severity Distribution donut이 추가됐습니다. 오른쪽은 Compliance 벤치마크 실행 흐름인데, Powerpipe 워커가 계정 단위로 스코핑되어 실행되고 이력이 `compliance_runs`/`compliance_results`에 쌓입니다.\n\n\n배포 방법을 보겠습니다.",
+    50: "⏸️ [2min] [요약]\n• ADR-011 — 멀티 계정은 STS AssumeRole read-only fan-out, ExternalId는 1st-party 옵션·3rd-party 필수\n• Security 페이지에 CVE Severity Distribution donut(ECR 스캔 집계)이 추가됨\n• Compliance 벤치마크도 계정 단위로 스코핑되어 실행/이력 관리\n\n멀티 계정 지원은 ADR-011을 기준으로 합니다. 각 대상 계정에 STS AssumeRole로 read-only fan-out하고, ExternalId는 host ARN이 고정되는 1st-party 계정은 옵션, 신뢰 관계가 약한 3rd-party 계정은 필수입니다.\n\n\n\n이 화면의 왼쪽은 Security findings 파이프라인입니다. Public S3, Open SG, Unencrypted EBS, IAM MFA 같은 항목에 더해 ECR 스캔 결과를 집계한 CVE Severity Distribution donut이 추가됐습니다. 오른쪽은 Compliance 벤치마크 실행 흐름인데, Powerpipe 워커가 계정 단위로 스코핑되어 실행되고 이력이 `compliance_runs`/`compliance_results`에 쌓입니다.\n\n\n배포 방법을 보겠습니다.",
     51: "⏸️ [2min] 배포는 Terraform 기반이고, 네 단계로 정리됩니다.\n\n먼저 `make configure`로 대화형 TUI를 돌려 VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다.\n\n\n\n다음으로 Terraform을 init하고 plan을 tfplan으로 저장합니다. 공유 인프라에는 auto-approve를 쓰지 않고, 저장된 tfplan을 컨트롤러가 apply합니다. CloudFront나 Security Group처럼 오래 걸리는 apply는 서브에이전트 타임아웃 때문에 컨트롤러가 직접 실행합니다.\n\n세 번째로 `make deploy`는 먼저 ULID 마이그레이션을 돌리고, arm64 이미지를 빌드해 ECR에 푸시한 뒤 ECS 롤링 배포를 하고, 마지막으로 `/api/health` 스모크로 검증합니다.\n\n마지막으로 AgentCore와 워커는 flag-gated입니다. `make agentcore`, `make workers`로 활성화하며, 기본은 꺼져 있어 비용이 0입니다. 라이브 환경은 단일 계정 123456789012, 도메인 awsops-v2.example.com입니다.\n\n\n마무리하겠습니다.",
-    52: "⏸️ [2min] AWSops를 정리하면, read-only AWS 운영 대시보드에 AI 진단을 결합한 제품입니다.\n\n자연어로 물으면 AgentCore MCP 도구가 라이브 read-only 조회를 하고, 종합진단 리포트가 light·mid 9섹션과 deep 16섹션으로 Well-Architected 관점의 진단을 제공합니다. 인벤토리, 토폴로지, Datasources, EKS 화면이 이를 뒷받침합니다.\n\n\n\n차별점은 세 가지입니다. AI는 계정 안의 Bedrock으로 동작해 외부 AI SaaS API를 쓰지 않습니다. 엣지는 private edge라 공개 ALB가 없고 CloudFront VPC Origin으로만 들어옵니다. 무거운 작업은 OOM-safe 비동기 워커 티어가 처리합니다.\n\n\n\n가장 중요한 원칙은 read-only 자세입니다. read-only는 AWS **리소스**에 한정되고, AWS 리소스 변경과 자율 실행은 동결(새 명시적 결정 전까지, 영구 아님)입니다. 다만 외부 관측성 데이터를 읽고, 외부 기록이나 티켓, 메시지를 쓰는 것은 SSRF 방어, Secrets 관리, DLP, human-gate, flag-OFF 같은 거버넌스 아래에서 허용됩니다. 변경되는 것은 데이터일 뿐, AWS 리소스가 아닙니다.\n\n시작은 간단합니다. configure하고 Terraform을 apply한 뒤 deploy하고, Cognito 사용자를 추가해 `/login`으로 들어오면 됩니다.\n\n\n마지막 슬라이드입니다.",
+    52: "⏸️ [2min] AWSops를 정리하면, read-only AWS 운영 대시보드에 AI 진단을 결합한 제품입니다.\n\n자연어로 물으면 AgentCore MCP 도구가 라이브 read-only 조회를 하고, 종합진단 리포트가 light·mid 9섹션과 deep 16섹션으로 Well-Architected 관점의 진단을 제공합니다. 인벤토리, 토폴로지, Datasources, EKS 화면이 이를 뒷받침합니다.\n\n\n\n차별점은 세 가지입니다. AI는 계정 안의 Bedrock으로 동작해 외부 AI SaaS API를 쓰지 않습니다. 엣지는 private edge라 공개 ALB가 없고 CloudFront VPC Origin으로만 들어옵니다. 무거운 작업은 OOM-safe 비동기 워커 티어가 처리합니다.\n\n\n\n가장 중요한 원칙은 read-only 자세입니다. ADR-007(keystone) 기준으로 read-only는 AWS **리소스**에 한정되고, AWS 리소스 변경과 자율 실행은 ADR-005로 동결(새 명시적 결정 전까지, 영구 아님)입니다. 다만 외부 관측성 데이터를 읽고, 외부 기록이나 티켓, 메시지를 쓰는 것은 SSRF 방어, Secrets 관리, DLP, human-gate, flag-OFF 같은 거버넌스 아래에서 허용됩니다. 변경되는 것은 데이터일 뿐, AWS 리소스가 아닙니다.\n\n시작은 간단합니다. configure하고 Terraform을 apply한 뒤 deploy하고, Cognito 사용자를 추가해 `/login`으로 들어오면 됩니다.\n\n\n마지막 슬라이드입니다.",
     53: "[1min] 감사합니다. 질문이 있으시면 지금 받겠습니다.\n\n발표 후 추가 질문이 있으시면 언제든 연락 주세요. AWSops는 내부에서 계속 발전하고 있고, 새로운 기능이 지속적으로 추가되고 있습니다.\n\n\n오늘 보여드린 하이브리드 라우팅, thin-BFF + 비동기 워커, read-only 진단 자세는 여러분의 프로젝트에도 적용할 수 있는 범용 아키텍처 패턴입니다.\n\n감사합니다."
   };
   const deck = new SlideFramework({

From bc27b70761df9dc5648d65cc94f646cf18e73ee8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Sat, 24 Oct 2026 07:04:28 +0000
Subject: [PATCH 6/7] chore: request review after retargeting to dev

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

From b9890532e3319810a0f043a88a17fe4c68833f76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=98=A4=EC=A4=80=EC=84=9D=28Junseok=20Oh=29DevOps?=
 <52226147+Atom-oh@users.noreply.github.com>
Date: Sat, 24 Oct 2026 07:16:44 +0000
Subject: [PATCH 7/7] docs-site: limit this part to architecture slides 1-9 and
 their combined-deck lines

Slides 10-19 move to a sibling PR so each review stays under the input
limit; the combined index.html lines for slides 1-9 change here with
their source block and per-part rendering.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .../awsops-intro/02-architecture.html         | 26 +++++++--------
 .../awsops-intro/02-architecture.md           | 32 +++++++++----------
 .../presentation/awsops-intro/index.html      | 24 +++++++-------
 3 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.html b/docs-site/static/presentation/awsops-intro/02-architecture.html
index 80242e815..7e85e04ed 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.html
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.html
@@ -265,7 +265,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -305,7 +305,7 @@ <h3>Read-Only Query</h3>
 </div>
 
 <div class="slide" data-remarp-id="s14" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out</h2></div>
+  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out (ADR-011)</h2></div>
   <div class="slide-body" data-remarp-id="s14-body">
     <div class="columns">
 <div class="col">
@@ -313,7 +313,7 @@ <h3>Registry + Assume</h3>
 <ul><li>Aurora <strong>accounts</strong> 레지스트리 — 호스트 계정은 lazy seed</li><li>대상 계정 <code>AWSopsReadOnlyRole</code>을 host task role이 <strong>STS AssumeRole</strong></li><li><strong>ExternalId</strong> — 1st-party(trust policy가 task-role ARN 핀) = <strong>선택</strong>, 3rd-party/와일드카드 = <strong>필수</strong>(confused-deputy 방어)</li><li>글로벌 셀렉터: 단일 계정 스코프 / <code>__all__</code> = 전 계정 fan-out</li></ul>
 </div><div class="col">
 <h3>Safety</h3>
-<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
+<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
 </div>
 </div>
   </div>
@@ -326,7 +326,7 @@ <h3>Safety</h3>
 <div class="col">
 <h3>Cognito + Lambda@Edge</h3>
 <ul><li><strong>us-east-1</strong>, py3.12, viewer-request</li><li><strong>RS256 JWKS</strong> 서명 검증 (iss/aud/token_use)</li><li>OAuth <code>state</code> + <strong>PKCE public client</strong></li></ul>
-<h3>Login</h3>
+<h3>Login (ADR-002)</h3>
 <ul><li><strong>Primary</strong> = 자체 <code>/login</code> 폼</li><li>BFF <code>POST /api/auth/login</code> → 무서명 공개 <code>InitiateAuth(USER_PASSWORD_AUTH)</code> → <code>awsops_token</code> (id_token 12h)</li><li>Hosted UI PKCE = <strong>dark fallback</strong>, signout = 쿠키 삭제</li></ul>
 </div><div class="col">
 <p><div style="display:flex;flex-direction:column;gap:0.75rem;margin-top:0.5rem;"><div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;">🔒 Private Edge</div><div style="color:#8b95a5;font-size:0.8125rem;">공개 ALB 없음 — 진입점은 CloudFront 하나</div></div><div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00d4ff;font-weight:bold;font-size:0.9375rem;">🔑 ECS Secrets</div><div style="color:#8b95a5;font-size:0.8125rem;">execution role 권한 (task role 아님)</div></div><div style="background:rgba(168,85,247,0.1);border:1px solid rgba(168,85,247,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#a855f7;font-weight:bold;font-size:0.9375rem;">👤 Admin</div><div style="color:#8b95a5;font-size:0.8125rem;">SSM + Cognito group (fail-closed)</div></div></div></p>
@@ -371,16 +371,16 @@ <h3>Login</h3>
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
+  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -394,7 +394,7 @@ <h3>Login</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Key Takeaways — Architecture</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 19: Key Takeaways --></p>
-<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>하이브리드 라우팅 + 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock</li></ul>
+<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock</li></ul>
   </div>
 </div>
 
@@ -428,15 +428,15 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     8: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. 2026년 6월 24일에 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
     9: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     10: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
-    11: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
+    11: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     12: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",
     13: "⏸️ [3min] 관측성 데이터는 읽기 전용 데이터소스 플랫폼으로 통합합니다.\nClickHouse, Prometheus, Loki, Tempo, Mimir 커넥터를 지원합니다. 각 커넥터는 Lambda로 구현되고, 스키마는 Aurora에 캐시합니다. 이 데이터를 챗에 주입하면 AI가 여러 데이터소스를 교차 조회할 수 있습니다. `/datasources` Explore 페이지에서는 자연어를 쿼리로 변환해 직접 탐색할 수도 있습니다. 모두 읽기 전용입니다.\n\n토폴로지는 리소스 간 관계를 그래프로 보여줍니다. flow 그래프와 infra 리소스 그래프 두 가지가 있고, CloudFront에서 로드밸런서, 타깃 그룹, DB로 이어지는 경로를 시각화합니다. `/topology/resource/[id]`로 들어가면 개별 리소스의 상세 패널을 볼 수 있습니다.\n\n컨테이너 운영자를 위한 EKS 통합을 보겠습니다.",
     14: "⏸️ [3min] EKS도 읽기 전용으로 통합되는데, 인증 경로가 3가지로 늘었습니다. 원래 경로는 configure.mjs 멀티선택으로 시작해서 eks.tf가 웹 task role에 Access Entry를 부여하고 AmazonEKSAdminViewPolicy를 클러스터 스코프로 붙이는 방식입니다. View가 아니라 AdminView인 이유는, View 정책엔 클러스터 스코프 리소스가 없어서 노드 목록 조회가 403이 나기 때문입니다. AdminView는 */*/get,list,watch라 시크릿까지 읽을 수 있지만, BFF가 노출하는 kind는 화이트리스트로 제한되어 있어서 시크릿·컨피그맵은 절대 통과하지 않습니다.\n\n여기에 sa-token과 assume-role 두 가지 경로가 Aurora의 eks_registrations.auth에 더해졌습니다. 클러스터별로 등록하면 되고 terraform 온보딩이 필요 없습니다. 그리고 지금 라이브인 auto-register 경로가 있는데, EventBridge가 CloudTrail의 AssociateAccessPolicy나 DeleteAccessEntry 이벤트를 잡아서 Lambda를 거쳐 eks_registrations에 자동으로 기록합니다. 버튼을 누를 필요가 없습니다.\n조회는 nodes, pods, deployments, services 같은 핵심 리소스를 BFF가 직접 처리합니다. 워커를 거치지 않습니다. 그리고 한 가지 더, ListClusters·DescribeCluster 같은 핵심 discovery 권한은 이제 게이트가 아니라 workload.tf에 상시로 붙어 있습니다. 그래서 온보딩 플래그가 꺼져 있어도 /api/eks, /api/overview, /api/cost는 항상 정상 동작합니다.\nEKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워크로드 뷰가 있습니다.\n\n계정을 하나 더 늘리면 어떻게 되는지, 멀티 계정 구조를 보겠습니다.",
-    15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
-    16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
+    15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
+    16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     17: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
-    19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
+    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 \"영구 금지\"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 \"안전조건 충족 + 새로운 명시적 결정 전까지\" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     20: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다."
   };
   const deck = new SlideFramework({
diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.md b/docs-site/static/presentation/awsops-intro/02-architecture.md
index f74dbd796..536413112 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.md
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.md
@@ -484,7 +484,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 :::notes
 {timing: 2min}
 무거운 작업은 모두 비동기 워커 티어가 받습니다.
-흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.
+흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.
 {cue: pause}
 그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.
 워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.
@@ -506,7 +506,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 ### 잡 종류 (2026-06-18 이후 증가)
 
 - **schedule_dispatcher** — 시간별 EventBridge → `report_schedules` 스캔 → 진단 잡 enqueue (`diagnosis_schedule_enabled`, LIVE)
-- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)
+- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)
 - **compliance** (Powerpipe) — CIS 벤치마크 Fargate 잡 (`steampipe_enabled`)
 
 :::
@@ -618,7 +618,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 @type: content
 @transition: slide
 
-# Multi-Account — STS AssumeRole Fan-Out
+# Multi-Account — STS AssumeRole Fan-Out (ADR-011)
 
 ::: left
 
@@ -636,7 +636,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 ### Safety
 
 - **host self-assume 가드** — target == host면 `get_role_arn()`이 `None` 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)
-- **read-only 한정** — 대상 계정 변경 작업 없음
+- **read-only 한정** — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)
 - `/accounts` admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)
 
 :::
@@ -648,7 +648,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 • ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수
 • host self-assume 가드로 "cross-account 차단" 오진을 방지
 
-AWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.
+AWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.
 {cue: pause}
 ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.
 전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.
@@ -675,7 +675,7 @@ ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AW
 - **RS256 JWKS** 서명 검증 (iss/aud/token_use)
 - OAuth `state` + **PKCE public client**
 
-### Login
+### Login (ADR-002)
 
 - **Primary** = 자체 `/login` 폼
 - BFF `POST /api/auth/login` → 무서명 공개 `InitiateAuth(USER_PASSWORD_AUTH)` → `awsops_token` (id_token 12h)
@@ -696,7 +696,7 @@ ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AW
 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.
 Lambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.
 {cue: pause}
-로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.
+로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.
 오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.
 {cue: transition}
 이걸 실제로 배포하는 흐름을 보겠습니다.
@@ -760,16 +760,16 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
+  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -781,10 +781,10 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
 :::notes
 {timing: 3min}
 이 아키텍처의 태세를 정확히 정의하겠습니다.
-AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
+AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 "영구 금지"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 "안전조건 충족 + 새로운 명시적 결정 전까지" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
 {cue: pause}
-딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.
-다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.
+딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.
+다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.
 그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.
 {cue: transition}
 전체를 한 장으로 정리하겠습니다.
@@ -802,16 +802,16 @@ AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니
 - **Terraform MSA on private edge** — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음
 - **Aurora 영속 상태** — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)
 - **AgentCore 섹션 에이전트** — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기
-- **하이브리드 라우팅 + 멀티 계정** — regex + Haiku 분류기 + caching, STS AssumeRole fan-out
+- **ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정** — regex + Haiku 분류기 + caching, STS AssumeRole fan-out
 - **OOM-safe 비동기 워커 티어** — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리
-- **읽기 전용 동결 태세** — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock
+- **읽기 전용 동결 태세** — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock
 
 :::notes
 {timing: 2min}
 아키텍처 파트를 한 장으로 정리합니다.
 첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.
 {cue: pause}
-셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.
+셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.
 {cue: transition}
 세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.
 :::
diff --git a/docs-site/static/presentation/awsops-intro/index.html b/docs-site/static/presentation/awsops-intro/index.html
index c9518e3c8..3dd4a4c0d 100644
--- a/docs-site/static/presentation/awsops-intro/index.html
+++ b/docs-site/static/presentation/awsops-intro/index.html
@@ -379,7 +379,7 @@ <h3>Foundation</h3>
 <p><strong>LIVE 오늘</strong>: workers · steampipe · agentcore · integrations · ai_cost_tracking · diagnosis_schedule · diagnosis_notify · eks_auto_register · hybrid_routing</p>
 </div><div class="col">
 <h3>Feature Flags (~17개, 전부 default-off = $0)</h3>
-<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>ADR-005 FROZEN</strong>, do-not-enable</li></ul>
+<ul><li><code>agentcore_enabled</code> · <code>workers_enabled</code> · <code>steampipe_enabled</code></li><li><code>hybrid_routing_enabled</code> · <code>diagnosis_schedule_enabled</code> · <code>diagnosis_notify_enabled</code></li><li><code>incident_lifecycle_enabled</code> · <code>k8sgpt_enabled</code> · <code>rca_writeback_enabled</code></li><li><code>eks_auto_register_enabled</code> · <code>ai_cost_tracking_enabled</code> · <code>multi_route_synthesis_enabled</code></li><li><code>remediation_enabled</code> — <strong>FROZEN</strong>, do-not-enable</li></ul>
 </div>
 </div>
   </div>
@@ -394,7 +394,7 @@ <h3>Core Layers</h3>
 <table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>network.tf</code></td><td>VPC 신규/재사용</td></tr><tr><td><code>edge.tf</code></td><td>CloudFront + VPC Origin + ALB</td></tr><tr><td><code>auth.tf</code></td><td>Cognito + Lambda@Edge</td></tr><tr><td><code>data.tf</code></td><td>Aurora + schema</td></tr><tr><td><code>workload.tf</code></td><td>ECS web service</td></tr><tr><td><code>ecr.tf</code></td><td>dual-tier ECR</td></tr><tr><td><code>ai.tf</code></td><td>AgentCore + SSM</td></tr><tr><td><code>workers.tf</code></td><td>SQS + SFN + Lambda</td></tr></tbody></table>
 </div><div class="col">
 <h3>Gated Subsystems</h3>
-<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포 (ADR-015)</td></tr></tbody></table>
+<table><thead><tr><th>파일</th><th>역할</th></tr></thead><tbody><tr><td><code>eks.tf</code></td><td>Access Entry + AdminView</td></tr><tr><td><code>steampipe.tf</code></td><td>인벤토리 sync (<code>steampipe_enabled</code>)</td></tr><tr><td><code>notify.tf</code></td><td>진단 알림 SNS (<code>diagnosis_notify_enabled</code>)</td></tr><tr><td><code>incidents.tf</code></td><td>인시던트 webhook (<code>incident_lifecycle_enabled</code>)</td></tr><tr><td><code>k8sgpt.tf</code></td><td>K8sGPT 예산/리소스 (<code>k8sgpt_enabled</code>)</td></tr><tr><td><code>writeback.tf</code></td><td>RCA write-back (<code>rca_writeback_enabled</code>)</td></tr><tr><td><code>remediation.tf</code></td><td>리메디에이션 substrate (<strong>FROZEN</strong>)</td></tr><tr><td><code>secret-rotation.tf</code></td><td>자기치유 재배포</td></tr></tbody></table>
 </div>
 </div>
   </div>
@@ -406,7 +406,7 @@ <h3>Gated Subsystems</h3>
     <div class="columns">
 <div class="col">
 <h3>Next.js 14 Standalone (arm64)</h3>
-<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트(ADR-009)</li></ul>
+<ul><li><strong>루트 경로 서빙</strong> — basePath 없음, fetch는 <code>/api/*</code></li><li><strong>Thin-BFF 원칙</strong> — 무겁고·길고·OOM 위험 작업은 직접 실행 금지</li><li>무거운 작업은 워커 큐로 enqueue — 범용 <strong><code>POST /api/jobs</code>는 <code>noop</code> 계열만</strong>, <code>report</code>/<code>compliance</code> 등 도메인 job은 소유권 검사하는 전용 라우트</li></ul>
 <h3>Routes</h3>
 <ul><li><code>/api/health</code> — 공개 헬스체크</li><li><code>/api/stream</code> — SSE 스트리밍</li><li><code>/api/db</code> — Aurora ping</li><li><code>/api/jobs</code> (+<code>/[id]</code>) — 비동기 작업</li></ul>
 </div><div class="col">
@@ -422,7 +422,7 @@ <h3>Routes</h3>
     <div class="columns">
 <div class="col">
 <h3>Aurora (PostgreSQL 17.9)</h3>
-<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>ADR-030 스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
+<ul><li><strong>0.5–4 ACU</strong>, KMS CMK, RDS-관리 master secret</li><li>앱 접근 = <strong>node-pg</strong> (<code>web/lib/db.ts</code>)</li><li>스키마 (v9 baseline) + <code>worker_jobs</code> · chat threads · diagnosis</li><li>새 테이블 = <strong>ULID 마이그레이션</strong> (<code>migrations/<ULID>_*.sql</code>)</li></ul>
 </div><div class="col">
 <h3>Steampipe = 인벤토리 sync ONLY</h3>
 <p><div style="background:rgba(0,255,136,0.08);border:1px solid rgba(0,255,136,0.3);border-radius:10px;padding:1rem;margin-top:0.5rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;margin-bottom:0.5rem;">warm Fargate → Aurora → /inventory/[type]</div><div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">flag-gated (<code style="color:#00ff88;">steampipe_enabled</code>)<br><b style="color:#00ff88;">41종</b> 리소스 타입 동기화<br>fan-out sync · registry-driven nav</div><div style="color:#ef4444;font-size:0.75rem;margin-top:0.625rem;border-top:1px solid rgba(239,68,68,0.3);padding-top:0.5rem;">NOT a live query engine — pg Pool / 라이브 조회 아님</div></div></p>
@@ -474,13 +474,13 @@ <h3>Steampipe = 인벤토리 sync ONLY</h3>
     <span style="background:rgba(168,85,247,0.18);color:#c4a0f7;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">ops</span>
     <span style="background:rgba(0,212,255,0.18);color:#7fd8ff;border-radius:6px;padding:0.3125rem 0.75rem;font-size:0.8125rem;">external-obs</span>
   </div>
-  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격, ADR-004) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 ADR-001/010에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
+  <div style="color:#8b95a5;font-size:0.75rem;margin-top:0.625rem;">external-obs = <b style="color:#00d4ff;">9번째 게이트웨이</b>(2026-06-24 승격) — Prometheus·ClickHouse 커넥터 호스팅, 챗 키 <code style="color:#00d4ff;">observability</code>로 별칭. 30슬라이스 <b style="color:#00ff88;">전부 LIVE</b>(9개 게이트웨이 전부 READY MCP 타깃). 16개 챗 키는 전부 등록되어 있지만, 그중 aws-data + 콜렉터 6종(7개)은 <code>steampipeAvailable()</code>이 설계 원칙에 따라 항상 false를 반환해 하드 비활성 — 선택하면 fail-open으로 ops에 위임됨</div>
 </div>
   </div>
 </div>
 
 <div class="slide" data-remarp-id="s8" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat — ADR-003</h2></div>
+  <div class="slide-header" data-remarp-id="s8-header"><h2>Hybrid Routing & Streaming Chat</h2></div>
   <div class="slide-body" data-remarp-id="s8-body">
     <div class="columns">
 <div class="col">
@@ -1515,13 +1515,13 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     11: "[2min] 첫 번째 파트를 정리하겠습니다.\n\nAWSops는 처음 세운 5가지 목표를 하나의 대시보드 안에서 동시에 해결합니다.\n가시성은 Overview·Topology·Monitoring에 NFM·Direct Connect를 포함한 네트워크 6종 메뉴까지 통합해서, FinOps는 읽기 전용 비용 분석과 Rightsizing으로, Well-Architected 점검은 자동 생성되는 종합진단 리포트로, 보안성은 Security Findings와 CIS Compliance로, 장애 대응은 AI가 메트릭·로그·트레이스·NFM 경로를 함께 교차 분석하는 것으로 풀었습니다.\n\n그리고 가장 중요한 것은, AI 추론을 고객 계정 안 Bedrock에서 돌리고, AWS 리소스 변경과 자율 실행은 동결한 읽기 전용 태세라는 점입니다. 설계상 안전합니다.\n\n\n5분 쉬고 아키텍처를 자세히 보겠습니다.",
     12: "[1min] 두 번째 파트, 아키텍처 딥다이브입니다.\nAWSops가 어떻게 만들어졌는지 레이어별로 자세히 보겠습니다.\n핵심은 세 가지입니다. 첫째, Terraform 기반 MSA로 재구축했다는 점. 둘째, 공개 진입점이 없는 비공개 엣지 구조라는 점. 셋째, 읽기 전용 운영 태세 위에 모든 것이 설계되었다는 점입니다.\n\n전체 그림부터 보겠습니다.",
     13: "⏸️ [3min] 전체 구조는 4개 레이어의 비공개 엣지입니다.\n브라우저는 전용 도메인으로 들어오고, CloudFront가 TLS로 받습니다. 여기서 VPC Origin을 https-only 443으로 설정해 내부 ALB까지 TLS가 끊기지 않게 합니다. origin 도메인을 public FQDN으로 지정해 SNI가 맞아야 합니다.\n\n핵심은 공개 ALB가 없다는 점입니다. 내부 ALB의 보안 그룹은 CloudFront 관리형 SG에서 오는 443만 허용합니다. VPC CIDR만 열면 504가 납니다. ALB는 HTTP로 Fargate의 web 컨테이너 3000번 포트로 전달합니다.\n영속 상태는 Aurora에 두고, 라이브 AWS 조회는 AgentCore MCP 도구가, 무거운 작업은 비동기 워커가 처리합니다.\n\n이 인프라를 어떻게 코드로 관리하는지 보겠습니다.",
-    14: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 ADR-005 동결 상태이고, integrations_write는 off이지만 ADR-007 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
-    15: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 ADR-005로 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
-    16: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`, ADR-009)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
-    17: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 ADR-030 기반 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
+    14: "⏸️ ⏸️ [2min] 인프라는 전부 Terraform입니다.\n단일 루트 `terraform/foundation/` 아래 모든 리소스를 정의하고, 상태는 partial S3 backend로 관리합니다. `use_lockfile`을 써서 DynamoDB 락 테이블 없이도 동시성 안전을 확보했습니다. Terraform 1.15 이상, provider 6 계열, 이미지는 모두 arm64입니다.\n\n큰 모듈은 전부 feature flag로 게이트합니다. 지금은 약 17개까지 늘어났습니다 — agentcore, workers, steampipe, hybrid_routing뿐 아니라 diagnosis_schedule, diagnosis_notify, incident_lifecycle, k8sgpt, rca_writeback, eks_auto_register, ai_cost_tracking, multi_route_synthesis, 그리고 동결(do-not-enable) 상태인 remediation까지. 전부 기본값이 false라서 plan을 돌리면 No changes, 비용은 0입니다.\n\n다만 라이브 환경은 이미 여러 개를 켜 놓은 상태입니다. workers, steampipe, agentcore, integrations, ai_cost_tracking, diagnosis_schedule, diagnosis_notify, eks_auto_register, hybrid_routing가 terraform.tfvars에서 true입니다. remediation은 계속 off이자 동결 상태이고, integrations_write는 off이지만 거버넌스 아래 게이트 상태(동결은 아님)입니다.\n공유 인프라는 절대 auto-approve를 쓰지 않고, 저장된 tfplan을 apply하는 규율을 지킵니다. CloudFront나 SG 같은 긴 apply는 컨트롤러가 직접 실행합니다.\n\n파일별로 어떻게 나뉘어 있는지 보겠습니다.",
+    15: "⏸️ [1min] 파일별 역할입니다.\n왼쪽이 핵심 레이어입니다. 네트워크(`create_network`만 게이트), 엣지, 인증, 데이터, 워크로드, ECR은 항상 켜져 있는 core 레이어라 무조건 배포되고, AI와 워커만 각각 `agentcore_enabled`·`workers_enabled`로 게이트됩니다.\n\n오른쪽은 게이트로 묶인 서브시스템입니다. EKS(Access Entry는 상시, `onboard_eks_clusters` for_each로 클러스터별 대상만 선택)에 더해 steampipe, notify, incidents, k8sgpt, writeback, remediation, secret-rotation까지 각 서브시스템이 별도 파일과 flag로 분리되어 있습니다. remediation은 동결(do-not-enable) 상태입니다.\n\n이제 컴퓨트와 웹 레이어입니다.",
+    16: "⏸️ [3min] 웹 레이어는 Next.js 14 standalone 빌드이고 arm64입니다.\n전용 도메인을 쓰므로 basePath 없이 루트 경로에서 서빙하고, fetch는 그냥 `/api/*`를 호출합니다.\n\n가장 중요한 설계 원칙은 thin-BFF입니다. 무겁거나, 오래 걸리거나, OOM 위험이 있는 작업은 절대 인라인으로 돌리지 않습니다. 대신 워커 큐에 넣는데, 범용 `POST /api/jobs`는 `noop` 계열만 받고, 진단·컴플라이언스 같은 도메인 job은 소유권을 검사하는 전용 라우트(`/api/diagnosis`, `/api/compliance/run`)로 제출합니다. 라우트는 공개 헬스체크, SSE 스트림, Aurora ping, 비동기 작업 정도로 얇게 유지합니다.\n오른쪽은 실전에서 꼭 챙겨야 하는 두 가지입니다. 첫째, HOSTNAME을 0.0.0.0으로 런타임 env에 명시해야 합니다. 이미지 ENV만으로는 ECS가 ENI IP로 덮어써서 헬스체크가 UNHEALTHY가 됩니다. 둘째, 컨테이너와 타깃 그룹의 헬스 경로가 앱의 `/api/health`와 정확히 일치해야 circuit breaker 루프를 피합니다.\n\n영속 상태를 담는 데이터 레이어로 갑니다.",
+    17: "⏸️ [3min] 영속 상태는 Aurora Serverless v2가 담당합니다.\nPostgreSQL 17.9, 0.5에서 4 ACU로 오토스케일하고, KMS CMK로 암호화하며 master secret은 RDS가 관리합니다. 앱은 node-pg 공유 풀로 접근합니다. 스키마는 v9 baseline에 worker_jobs, chat 스레드, 진단 리포트 테이블이 더해진 형태이고, 새 테이블은 schema.sql에 덧붙이지 않고 ULID 마이그레이션 파일로 추가하는 규칙입니다.\n\n여기서 꼭 짚어야 할 점이 있습니다. Steampipe는 라이브 쿼리 엔진이 아닙니다. flag로 켜는 인벤토리 sync일 뿐입니다. warm Fargate가 41종 리소스 타입을 Aurora로 동기화하고, 이걸 generic `/inventory/[type]` 페이지가 보여줍니다. 라이브 AWS 조회는 어디까지나 AgentCore MCP 도구가 합니다. 예전의 임베디드 pg Pool 방식이 아니라는 점을 강조합니다.\n\n이제 핵심인 AI 엔진입니다.",
     18: "⏸️ [2min] AI 엔진은 Bedrock AgentCore입니다.\n모델은 Opus 4.8, Sonnet 5, Haiku 4.5를 상황에 맞게 쓰고, AgentCore Runtime이 Strands 기반 `agent/agent.py`를 실행합니다. Memory와 Code Interpreter도 함께 붙어 있습니다.\n\n설정의 source of truth는 SSM입니다. provision.py가 runtime ARN, interpreter ID, memory ID를 `/ops/awsops-v2/agentcore/` 경로에 기록하고, 웹 BFF가 런타임에 읽습니다. valueFrom 레이스를 피하려는 의도적 설계입니다.\n\n이 런타임이 어떤 도구를 들고 있는지 보겠습니다.",
-    19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
-    20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
+    19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. 2026년 6월 24일에 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
+    20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     21: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
     22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     23: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",