재현 가능한 멀티-AZ (multi-AZ) 탄력성 워크스루: 서비스를 시뮬레이션된 존(zone)들에 분산시키고, 부하가 걸린 상태에서 하나를 종료한 뒤 드롭된 요청을 측정합니다 — 또한 실제 프로덕션 환경에서만 나타나는 부분들도 다룹니다.

원래 AWS Builder Center에 게시되었습니다:

AWS Builder Center

여러분의 여정을 이해하는 빌더(builders)들과 연결하세요. 솔루션을 공유하고, AWS 제품 개발에 영향을 미치며, 성장을 가속화하는 유용한 콘텐츠에 접근하세요. 여러분의 커뮤니티가 여기서 시작됩니다.

favicon builder.aws.com

Repo:

GitHub logo PradeepKandepaneni / golden-path-resilience

golden-path-resilience

서비스가 전체 가용 영역(availability zone)의 손실로부터 살아남도록 만드세요 — 그리고 부하가 걸린 상태에서 한 존을 종료하고 얼마나 많은 요청이 드롭되는지 계산하는 데모를 통해, 무료 인프라에서 이를 증명하세요. 스포일러: 결과는 0이어야 합니다.

이것은 golden-path의 후속작입니다. 동일한 작은 서비스이지만, 이제 흥미로운 부분은 **토폴로지 (topology)**입니다: 하나의 존이 사라지더라도 서비스를 함께 끌고 가지 않도록 어떻게 분산되어 있는가 하는 점입니다.

로컬 멀티 노드 kind 클러스터와 GitHub의 무료 러너(runners)를 사용하는 CI에서 엔드 투 엔드(end-to-end)로 실행됩니다. 총 비용: $0.

이것이 증명하는 것

세 개의 워커 노드(worker nodes)가 세 개의 시뮬레이션된 존(az-a, az-b, az-c)으로 라벨링됩니다. 6개의 레플리카(replicas)가 존당 2개씩 분산됩니다. 그 다음 scripts/az-outage-demo.sh를 실행합니다:

1. 서비스에 지속적인 요청 스트림을 시작하고,
2. 한 존의 노드를 코돈(cordon) 및 드레인(drain) 합니다 (해당 AZ가 불능 상태가 되는 것을 대신함),
3. 쫓겨난 포드(pods)가 살아남은 존들로 재스케줄링되는 것을 관찰하며,
4. 얼마나 많은지 집계합니다...

GitHub에서 보기

서두에 밝히는 주장

자율성(Autonomy)은 더 이상 역량의 문제가 아닙니다. 당신의 에이전트(agent)는 이미 사고를 조사하고 조치를 취할 수 있습니다. Amazon Bedrock AgentCore를 기반으로 구축된 AWS DevOps Agent는 2026년 3월 31일에 정식 출시(GA)되었으며, 사람이 각 단계를 직접 수행하지 않아도 텔레메트리(telemetry), 코드, 배포 데이터를 상관 분석하여 문제를 분류(triage)합니다. 이제 흥미로운 질문은 다른 곳으로 옮겨갔습니다.

현재의 제약 조건은 의사결정 경계(decision boundary)입니다. 즉, 에이전트가 감독 없이 실행할 수 있는 작업은 무엇인지, 어떤 작업을 에이전트가 에스컬레이션(escalate)해야 하는지, 그리고 변경 관리 정책(change-management policy), 예산 상한선, 그리고 새벽 2시의 장애 상황에서도 유지될 수 있도록 그 경계선을 어떻게 인코딩할 것인가의 문제입니다. 거의 모든

단독으로 행동하는 것의 예상 비용은 대략 P(에이전트가 틀릴 확률) × (잘못된 행동의 폭발 반경 (blast radius))입니다. 에스컬레이션 (Escalating) 역시 비용이 발생하며, 그 비용은 0이 아닙니다. 즉, 인간의 대응 지연 시간, 온콜 (on-call) 노고, 그리고 — 사람들이 자주 잊는 부분인데 — 에스컬레이션이 발생하기 전 조사를 위해 이미 소비된 에이전트의 시간과 토큰 (tokens)이 포함됩니다. AI SRE 에이전트는 챗봇보다 훨씬 더 많은 모델 호출 (model calls)을 수행하는데, 이는 단 하나의 장애가 계획 수립, 도구 선택 (tool selection), 증거 수집, 가설 수정, 그리고 보고를 트리거하기 때문입니다. 이러한 작업에는 비용 측정기가 돌아가고 있습니다.

따라서 경계선은 세 가지 수치에 의해 정의되며, 이 세 가지 모두를 구체적으로 추론할 수 있습니다:

1. 행동의 가역성 (Reversibility) 및 폭발 반경 (blast radius): 크래시 루프 (crash-looping)에 빠진 포드 (pod)를 재시작하는 것은 범위가 제한적이며 가역적입니다. 상한선 내에서 Karpenter 노드 그룹을 스케일링 (scaling)하는 것도 가역적입니다. 하지만 프로덕션 데이터베이스를 수정하거나, 볼륨 (volume)을 삭제하거나, 스키마 (schema)를 롤링 (rolling)하는 것은 가역적이지 않습니다.
2. 에이전트의 신뢰도 (Confidence) — 모델의 자기 보고가 아닌, 증거의 완전성 (evidence completeness)으로 정의됩니다. 특정 파일, 라인, 로그 기록, 그리고 명확한 전후 상관관계에 의해 뒷받침되는 가설은 신뢰도가 높습니다. "모델이 87%라고 말했다"는 증거가 아닙니다. 에이전트는 환각 (hallucinate)을 일으키며, 자신 있게 틀린 근본 원인 분석 (root-cause analysis)은 위험한 실패 모드입니다.
3. 조사에 드는 경제적 무게: 조사 기반의 과금 방식은 노이즈가 많은 알람 (alerts)에 페널티를 부여합니다. 에이전트가 오탐 (false positive)을 조사하는 것 역시 여전히 비용을 발생시키기 때문입니다. 따라서 알람의 품질은 에이전트 지출에 직접적인 입력값이 되며, 이는 SLO 위생 (hygiene)을 FinOps와 결합시킵니다.

이하의 모든 내용은 단지 이 세 가지 수치를 운영 가능한 형태로 만든 것입니다.

프레임워크: 자가 치유 스위치가 아닌, 폭발 반경 라우터 (blast-radius router)

단순한 On/Off 방식의 "자율성 (autonomy)" 토글을 배포하지 마십시오. 대신 위에서 언급한 세 가지 수치를 매개변수로 하여, 각 후보 행동을 네 가지 처분 중 하나로 분류하는 라우터를 배포하십시오.

높은 신뢰도 (구체적인 증거, 명확한 전후 상관관계):

가역적(Reversible) + 제한된 폭발 반경 (contained blast radius) → 자동 실행 (Auto-execute) 후, 변경 불가능한 감사 기록 (immutable audit record)을 남기고 방지 항목 (prevention item)을 생성합니다.
비가역적(Irreversible) 또는 넓은 폭발 반경 (wide blast radius) → 미리보기 후 실행 (Execute-with-preview): 에이전트가 정확한 변경 사항을 제안하고, 실행 전 사람이 승인합니다.

낮은 신뢰도 (Low confidence) (희박하거나 상충하는 증거):

가역적(Reversible) + 제한된 폭발 반경 (contained blast radius) → 예산 한도 (budget cap) 내에서 자동 조사 (Auto-investigate)를 수행합니다. 증거를 수집하고 신뢰도가 임계값 (threshold)을 넘을 경우에만 조치를 취하며, 그렇지 않으면 에스컬레이션 (escalate)합니다.
비가역적(Irreversible) 또는 넓은 폭발 반경 (wide blast radius) → 즉시 에스컬레이션 (Escalate)합니다. 조치를 취하지 마십시오. 증거를 첨부하고 사람에게 페이지 (page)를 보냅니다.

다음 두 가지 설계 규칙은 이 라우터(router)를 단순한 장식이 아닌 안전한 장치로 만듭니다:

1. 신뢰도는 제안이 아니라 게이트 (gate)입니다. 임계값 (threshold) 미만일 경우, 폭발 반경 (blast radius)에 관계없이 처분 (disposition)은 절대 자동 실행 (auto-execute)될 수 없습니다. 임계값은 느낌 (vibe)이 아니라, 측정된 교정 (calibration)을 통해 조정하는 정책 값 (policy value)입니다.

2. 라우터의 상한선 (ceilings)은 에이전트 내부의 로직이 아니라, 에이전트 하단의 인프라 (infrastructure)에서 강제됩니다. 이것이 전체 설계에서 가장 중요한 단일 아키텍처 결정이며, 다음 섹션에서 그 이유를 설명하겠습니다.

심층 메커니즘: 에이전트 하단에서 강제되는 코드로서의 가드레일 (guardrails as code)

자신의 한계를 스스로 감시하는 에이전트는 단일 장애점 (single point of failure)이 됩니다. 근본 원인 (root cause)을 환각 (hallucinate)할 수 있는 바로 그 LLM이 조치 허용 여부를 결정하게 되기 때문입니다. 에이전트가 논리적으로 우회할 수 없는 곳에 엄격한 제한 (hard limits)을 두어야 합니다.

IAM의 범위를 제한하여 폭발 반경 (blast radius)을 물리적으로 경계 지으십시오. 에이전트의 실행 역할 (execution role)은 포드 (pod)를 재시작하거나, 노드 (node)를 코든 (cordon) 하거나, 특정 배포 (deployment)의 롤백 (rollback)을 트리거할 수 있어야 하지만, 영구 볼륨 (persistent volumes)을 삭제하거나, 프로덕션 데이터베이스 (production database)를 변경하거나, IAM을 건드릴 수 있는 경로는 없어야 합니다. 만약 라우터가 잘못 분류하더라도, 권한 경계 (permission boundary)가 최후의 보루 (backstop) 역할을 합니다.

예산과 규모의 상한선(ceiling)을 산문(prose)이 아닌 Terraform 또는 정책(policy)에 인코딩하십시오. Karpenter 프로비저너(provisioner)에는 엄격한 노드 상한선을 설정합니다. 비용 가드레일(cost guardrail)은 사고당 및 일일 에이전트 사용 시간(agent-minutes)을 제한합니다. 이를 통해 방지할 수 있는 실패는 실재합니다. 잘못 설정된 AI 에이전트는 일반적인 프로비저닝 상황에서 몇 달에 걸쳐 쌓일 비용을 단 몇 시간 만에 발생시킬 수 있으며, 실제로 약 5억 달러에 달하는 AI 설정 오류 사고가 공개적으로 보고된 사례가 있습니다. 상한선은 제한된 실험과 무제한적인 부채 사이의 차이를 결정합니다.

변경 동결(change-freeze) 기간을 정책으로 인코딩하십시오. 승인된 변경 기간 외에 스케일링(scaling)하거나 패치(patching)를 수행하는 에이전트는, 해당 작업 자체가 올바랐더라도 거버넌스 위반(governance violation)을 일으킨 것입니다. 이는 2026년 거버넌스 격차(governance-gap) 데이터에서 명시된 위험 중 하나인 '변경 관리 정책과 충돌하는 자율적 행동'이며, 에이전트가 준수하는 거부 기간(deny window)을 설정함으로써 아주 쉽게 방지할 수 있습니다.

불변의 감사 추적(immutable audit trail)을 유지하십시오. 모든 자동 실행된 작업은 에이전트가 나중에 수정할 수 없는 감사 기록을 작성해야 합니다. AWS DevOps Agent가 바로 이 이유로 불변의 조사 타임라인(investigation timelines)을 생성하는 것입니다. 만약 자체적인 복구 계층(remediation layer)을 구축하고 있다면, 이 속성을 복제하십시오. 감사 가능성(Auditability)은 나중에 희망이 아닌 증거를 바탕으로 자율성을 확대할 수 있게 해주는 핵심 요소입니다.

심각도가 낮거나 이미 알려진 노이즈성 경고는 자동 조사(auto-investigation) 대상에서 제외하십시오. 이것이 비용 위생(cost-hygiene) 메커니즘입니다. 먼저 중복을 제거(deduplicate)하고, 빈번하게 발생하는 경고(flappers)를 억제(suppress)한 다음, 품질 기준을 통과하는 신호에 대해서만 에이전트 사용 시간(agent-minutes)을 할당하십시오. 그런 다음 노이즈 메트릭(noise metrics)을 SLO(서비스 수준 목표)를 강화하는 데 다시 피드백하여, 신뢰성과 비용 사이의 루프를 완성하십시오.

실패 모드 (이 부분이 독자들이 실제로 필요로 하는 부분입니다)

누구나 성공적인 경로(happy path)는 보여줄 수 있습니다. 신뢰성은 실패 모드(failure modes)에서 나오며, 언급할 가치가 있는 네 가지 모드가 있습니다.

1. 근본 원인을 은폐하는 자동 해결 (Auto-resolution). 가장 유혹적인 실패 유형입니다. 알람은 다시 OK 상태로 돌아오고 그래프는 깨끗해 보이지만, 근본적인 결함은 그대로 남아 있어 재발하게 됩니다. 이는 가설이 아닙니다. AWS 자체의 AgentCore 관측성(observability) 워크스루를 보면, 트리거가 된 취약점은 여전히 살아있는 상태에서 약 1분 만에 스스로 해결된 사고 사례가 나타납니다. 완화 방법: 모든 자동 해결(auto-resolve)은 반드시 방지 백로그(prevention-backlog) 항목을 생성해야 합니다. 복구(Recovery)는 해결(Resolution)이 아닙니다.

2. 노이즈 알람으로 인한 비용 함정. 조사 기반 과금(Investigation-based billing) 방식에서는 에이전트가 오탐(false positives)을 처리하는 것이 소리 없는 예산 누출을 의미합니다. 완화 방법: 알람 품질에 따라 조사를 제한하고, 미터기(meter)가 작동하기 전에 공격적으로 중복을 제거(dedupe)하십시오. 이제 알람 위생(alert hygiene)은 예산 항목의 일부입니다.

3. 변경 관리(Change-management) 충돌. 동결 기간(freeze) 동안 기술적으로 올바른 스케일 업(scale-up)을 수행하는 것도 그 자체로 하나의 사고입니다. 완화 방법: 동결 기간을 문서가 아닌 강제된 정책으로 시행하십시오.

4. 신뢰도 오보정 (Confidence miscalibration). 에이전트가 확신을 가지고 틀리는 경우입니다. 완화 방법: 자동 실행(auto-execute)의 전제 조건으로 구체적인 증거 아티팩트(evidence artifacts) — 특정 파일, 라인, 로그 기록 — 를 요구하고, 모델이 스스로 보고하는 신뢰도는 신뢰할 수 없는 입력값으로 취급하십시오.

지표(metrics)에 관한 참고 사항 — 누군가를 인용하기 전에 반드시 읽으십시오

시장은 검증 불가능한 수치들로 포화되어 있습니다. 90% 이상의 알람 노이즈 감소, 엔터프라이즈 배포 전반에 걸친 40~60%의 MTTR(평균 복구 시간) 개선 등의 주장을 보게 될 것이며, 한 벤더는 94%의 근본 원인 정확도와 최대 75%의 MTTR 개선을 광고하고 있습니다. 이것들은 제3자 및 벤더가 보고한 수치입니다. 이를 인용할 때는 반드시 그 출처를 밝히거나 아예 인용하지 마십시오. 절대로 이를 귀하 자신의 결과인 것처럼 제시해서는 안 됩니다.

귀하가 자신의 이름을 걸 수 있는 유일한 수치는 명시된 기준점(baseline), 명시된 방법(method), 그리고 명시된 시간 범위(time window)와 함께 귀하가 직접 측정한 수치뿐입니다. 시니어 리뷰어 — 또는 시니어 면접관 — 는 이 세 가지를 모두 물어볼 것이며, 빌려온 수치는 첫 번째 후속 질문에서 무너집니다. 이것이 이 글의 나머지 부분이 제가 주장하는 벤치마크가 아니라, 귀하가 직접 수행하는 실험실(lab)인 이유입니다.

이를 재현해 보세요: autonomy-boundary-lab

위의 모든 내용은 저렴한 비용으로 구축 가능합니다. 이 리포지토리(repo)의 이름이 일반적인 "골든 패스 (golden path)" 데모와 차별화되도록 의도적으로 명명된 이유는, 이 프로젝트의 기여점이 플랫폼이 아닌 정책 계층 (policy layer)이기 때문입니다.

귀하가 구축하게 될 것:

• 정의된 장애 발생 시 CloudWatch 알람이 발생하도록 계측된 kind 클러스터 상의 작은 서비스 (또는 DevOps 에이전트 통합을 엔드 투 엔드(end-to-end)로 구현하고 싶다면 단일 노드 EKS).
• 재현 가능한 결함 주입 (fault-injection) 스크립트 — 크래시 루프 (crash loop), 잘못된 배포, 의존성 타임아웃 등을 통해 동일한 사고를 반복할 수 있게 하며, 로그가 연출된 것이 아닌 실제 상황이 되도록 합니다.
• 작은 정책 구성 요소로서의 폭발 반경 (blast-radius) 라우터: 알람과 에이전트의 증거를 읽고, 조치를 네 가지 처분 중 하나로 분류하며, 신뢰 게이트 (confidence gate)를 강제합니다.
• 코드로서의 가드레일 (guardrails): 범위가 제한된 IAM 역할 (role), Karpenter 노드 상한선, 에이전트 분당 예산 캡 (budget cap), 그리고 변경 동결 거부 창 (change-freeze deny window)을 모두 Terraform으로 구현합니다.
• 이 실험실(lab)이 실제로 생성한 결과물 (이번 실행 결과)