AWS Resilience Hub의 세 가지 변화: 의존성 AI 인사이트를 SRE 운영에 연결하는 법

복원력(resilience)은 장애가 발생하지 않는 상태가 아닙니다. 장애가 발생해도 핵심 기능을 유지하고, 영향 범위를 줄이며, 정해 둔 시간 안에 회복하는 능력입니다. 그런데 분산 애플리케이션이 호출하는 서비스와 외부 API가 늘어날수록 “우리 시스템의 의존성이 무엇인지”부터 정확히 알기 어려워집니다.

AWS는 2026년 9월 18일 AWS Resilience Hub에 세 가지 기능을 추가했다고 발표했습니다.

Amazon EKS 네임스페이스의 레이블을 서비스 입력 범위로 사용
발견된 의존성에서 패턴을 요약하는 생성형 AI 기반 Dependency insights
AWS Organizations를 통한 복원력 정책 공유

이번 발표는 단순한 콘솔 기능 추가보다 복원력의 기준을 개별 애플리케이션에서 조직 전체의 정책과 의존성 데이터로 확장하려는 변화로 볼 수 있습니다. 다만 AI가 만들어 주는 요약을 곧바로 복구 설계로 바꾸는 것은 위험합니다. 데이터 수집 범위, IAM 권한, 발견 기간, 비용과 검증 절차를 함께 설계해야 합니다.

이 글은 AWS의 2026년 9월 18일 발표, Resilience Hub 개발자 문서와 가격 문서, AWS Well-Architected Reliability 지침, NIST 사이버 복원력 지침을 교차 확인해 작성했습니다. 기능·리전·가격은 변경될 수 있으므로 실제 도입 전에 계정의 최신 문서를 확인해야 합니다.

1. 무엇이 추가됐나

세 기능은 서로 다른 문제를 해결하지만 하나의 운영 흐름으로 연결됩니다.

기능	해결하려는 문제	실무에서 얻는 것
EKS 레이블 입력	클러스터 전체를 분석 범위로 넣으면 서비스 경계가 흐려짐	네임스페이스·레이블 규칙에 맞는 자원만 평가
Dependency insights	수백 개 의존성 목록을 사람이 모두 읽기 어려움	교차 리전·신규·서드파티·불균등 사용 패턴 요약
Organizations 정책 공유	계정마다 RTO·RPO 기준이 달라짐	중앙 정책을 여러 계정의 서비스에 재사용하고 채택 현황 확인

AWS가 말하는 차세대 Resilience Hub는 리소스 탐색, 의존성 발견, 장애 모드 분석, 복원력 테스트와 조직 단위 보고를 하나의 서비스 모델로 묶습니다. 이번 업데이트는 그 모델에서 “무엇을 분석할지”, “무엇을 먼저 볼지”, “어떤 기준으로 평가할지”를 각각 정교하게 만든 셈입니다.

2. EKS 레이블이 중요한 이유

EKS 클러스터는 여러 팀의 네임스페이스와 워크로드가 공존하는 경우가 많습니다. 플랫폼 팀이 클러스터 단위로 복원력을 평가하면, 한 서비스의 장애 모드에 다른 팀의 리소스가 섞여 결과가 부풀려질 수 있습니다.

이번 기능은 네임스페이스 안의 Kubernetes 레이블을 Resilience Hub의 서비스 입력으로 사용할 수 있게 합니다. 예를 들어 다음과 같은 규칙을 운영할 수 있습니다.

app.kubernetes.io/part-of: checkout
resilience.example.com/tier: critical
team.example.com/owner: commerce

이렇게 하면 checkout 서비스의 평가에는 해당 레이블을 가진 Deployment, Service, PodDisruptionBudget 등 관련 자원만 포함하도록 범위를 설계할 수 있습니다. 레이블은 단순 검색용 문자열이 아니라 서비스 소유권과 복구 목표를 연결하는 인벤토리 키가 됩니다.

그러나 레이블이 있다고 해서 복원력이 자동으로 확보되는 것은 아닙니다.

레이블 누락은 평가 범위 누락으로 이어질 수 있습니다.
팀마다 키와 값의 의미가 다르면 조직 보고가 왜곡됩니다.
레이블 변경이 배포 파이프라인에서 검증되지 않으면 서비스 경계가 조용히 바뀝니다.
Kubernetes 리소스와 AWS 리소스의 소유 관계가 레이블만으로 완전히 설명되지 않을 수 있습니다.

따라서 플랫폼 팀은 레이블을 정책으로 관리해야 합니다. 필수 키, 허용 값, 소유 팀, 변경 검토자를 정의하고 CI에서 누락을 차단하는 편이 좋습니다. 복원력 도구를 도입하면서 태깅 체계부터 정리하는 이유가 여기에 있습니다.

3. Dependency insights는 무엇을 분석하나

Resilience Hub의 dependency discovery는 DNS 질의 로그를 분석해 애플리케이션이 실제로 호출하는 AWS 서비스, VPC 내부 엔드포인트, 제3자 엔드포인트와 교차 리전 대상을 찾습니다. 문서에 따르면 각 의존성에 대해 이름·종류·위치·중요도·질의 빈도·처음 관찰된 시점·최근 관찰된 시점을 확인할 수 있습니다.

Dependency insights는 이 목록을 사람이 처음부터 끝까지 읽지 않도록 다음 패턴을 요약합니다.

교차 리전 의존성: 호출자와 다른 리전에 있는 엔드포인트
신규 의존성: 최근 7일에 처음 나타난 대상
제3자 의존성: AWS 밖에 있는 LaunchDarkly, Stripe, Datadog 같은 서비스
불균등 사용: 요일·시간대에 따라 호출량이 크게 달라지는 대상
AWS 서비스 의존성: S3, DynamoDB, SQS 등 AWS 엔드포인트

이 기능은 의존성 발견을 “목록 만들기”에서 “검토 우선순위 정하기”로 바꿉니다. 예를 들어 신규 결제 API가 일주일 전부터 호출되기 시작했다면, 그 API가 장애 시 대체 경로를 갖는지와 계약 변경 알림을 받는지 먼저 확인할 수 있습니다. 다른 리전의 데이터베이스를 반복 호출한다면 지연시간과 리전 장애의 영향 범위를 설계 검토 대상으로 올릴 수 있습니다.

4. 35일 데이터와 24시간 재생성 제한

AI 요약이라는 표현만 보면 실시간 감시처럼 느껴지지만, Dependency insights는 그런 도구가 아닙니다.

AWS 문서는 차세대 Resilience Hub가 최대 35일의 발견된 의존성 데이터를 분석한다고 설명합니다. 의존성 데이터는 시간 단위로 요약되며, 같은 서비스의 인사이트는 24시간에 한 번 재생성할 수 있습니다. 따라서 방금 배포한 변경이 즉시 요약에 반영된다고 기대하면 안 됩니다.

이 특성은 다음과 같은 운영 판단을 요구합니다.

배포 직후 검증과 주기적 분석을 분리한다.
배포 직후의 계약 검증은 테스트와 트레이싱으로 처리하고, Dependency insights는 일·주간 단위의 구조 변화 점검에 사용합니다.
발견 데이터가 충분히 쌓인 뒤 해석한다.
첫 실행은 의존성 목록을 만드는 단계입니다. 발견 기간이 짧으면 계절성·배치 작업·장애 시 호출 경로를 충분히 설명하지 못합니다.
생성 실패를 데이터 부족과 구분한다.
AWS CLI 문서에는 INSUFFICIENT_DATA, LLM_GENERATION_FAILED, INTERNAL_ERROR 같은 실패 코드가 제시되어 있습니다. “인사이트 없음”을 “위험 없음”으로 해석해서는 안 됩니다.

35일 창은 장기 감사 로그가 아닙니다. 규제 감사나 사고 포렌식에 필요한 원본 DNS·VPC·애플리케이션 로그는 별도 보존 정책으로 관리해야 합니다.

5. AI 인사이트를 설계 판단으로 바꾸는 질문

AI가 “교차 리전 의존성이 위험하다”고 요약해도 곧바로 리전을 옮길 수는 없습니다. 다음 질문을 순서대로 확인해야 합니다.

이 의존성이 정말 하드(hard) 의존성인가

결제 승인, 인증, 재고 차감처럼 없으면 요청을 완료할 수 없는 기능은 하드 의존성일 수 있습니다. 반면 추천, 분석 로그, 알림처럼 잠시 실패해도 핵심 업무를 계속할 수 있는 기능은 소프트(soft) 의존성으로 바꿀 수 있습니다.

장애 시 어떤 열화가 허용되는가

캐시된 값을 보여 줄지, 일부 기능만 비활성화할지, 요청을 큐에 저장할지 결정해야 합니다. 이 결정에는 비즈니스 담당자의 허용 범위가 필요합니다.

호출량의 불균등은 버그인가 업무 패턴인가

주중 오전에만 호출량이 늘어난다면 배치 작업일 수 있습니다. 불균등 사용을 무조건 이상으로 고치기보다, 해당 시간대의 용량·스로틀링·재시도 정책이 적절한지 검증해야 합니다.

제3자 서비스의 계약과 복구 책임은 누구에게 있는가

외부 API의 SLA, 요금, 인증서 만료, 데이터 지역, rate limit을 확인합니다. 외부 서비스가 복구 목표를 보장하지 않는다면 내부 시스템의 RTO를 그 서비스에 그대로 의존하게 해서는 안 됩니다.

AI 인사이트의 역할은 결론을 대신 내리는 것이 아니라, 운영자가 질문해야 할 대상을 먼저 좁히는 것입니다.

6. Organizations 정책 공유의 의미

여러 AWS 계정을 운영하는 조직에서는 팀마다 복원력 정책을 다르게 정의하기 쉽습니다. 한 팀은 RTO 15분, 다른 팀은 4시간을 목표로 삼고 같은 결제 서비스를 평가할 수도 있습니다.

Resilience Hub의 정책 공유는 중앙 팀이 정책을 만들고 AWS Organizations의 멤버 계정 서비스에 적용할 수 있게 합니다. 중앙에서 같은 정책을 재사용하면 다음을 표준화할 수 있습니다.

중요도별 RTO·RPO 기준
평가할 리소스와 장애 유형
정책을 적용한 서비스의 채택 현황
정책 변경과 서비스 사용 이력

하지만 중앙 정책은 자율성을 없애는 도구가 아닙니다. 조직 정책을 그대로 적용하면 연구·개발 환경의 비용과 복구 목표가 과도해질 수 있습니다. 권장하는 방식은 “전체 계정에 하나의 정책”이 아니라, 결제·회원·내부 분석 등 업무 등급별 정책을 만들고 예외를 명시하는 것입니다.

정책 공유 뒤에는 다음 지표를 운영하면 좋습니다.

지표	질문
적용률	대상 계정·서비스 중 몇 곳이 정책을 사용 중인가?
준수율	RTO·RPO 기준을 만족하는 구성요소는 몇 개인가?
예외율	어떤 팀이 왜 기준을 충족하지 못하는가?
평균 개선 시간	발견 후 수정·재평가까지 얼마나 걸리는가?
테스트 성공률	권고 조치가 실제 장애 실험에서 효과가 있었는가?

정책을 배포한 사실보다, 각 서비스의 복구 목표가 실제 테스트로 확인됐는지가 중요합니다.

7. 권한과 데이터 경계

Resilience Hub는 AWS 자원의 구성과 의존성을 읽어야 합니다. AWS 문서의 IAM 참고 자료는 차세대 평가 실행 역할에 읽기 권한을 부여하고, EKS를 포함할 때 IAM 역할과 Kubernetes RBAC를 별도로 설정하도록 안내합니다.

최소 권한 관점에서는 다음을 분리해야 합니다.

AWS 자원 구성 조회 권한
EKS 리소스 읽기 권한
Organizations 정책 공유를 관리하는 권한
복원력 테스트를 실행하는 권한
결과와 로그를 보는 권한

특히 EKS 접근을 위해 클러스터 전체 관리자 권한을 주는 방식은 피해야 합니다. Resilience Hub 평가 역할에는 필요한 리소스의 get/list 중심 RBAC만 부여하고, 정책 공유와 테스트 실행은 별도의 운영 역할로 분리하는 것이 안전합니다.

Dependency discovery는 DNS 질의와 엔드포인트 정보를 다루므로 메타데이터도 보안 검토 대상입니다. 제3자 도메인명, 내부 서비스 이름, 리전 배치가 조직의 아키텍처를 드러낼 수 있습니다. 콘솔·API·로그에 접근할 수 있는 그룹을 최소화하고, 외부 티켓이나 채팅에 인사이트 원문을 복사할 때 내부 주소와 고객 식별자를 제거해야 합니다.

8. 비용과 적용 조건

AWS 가격 문서에 따르면 차세대 Resilience Hub는 서비스 수, 장애 모드 평가 횟수, 복원력 테스트, dependency discovery 활성화 여부에 따라 비용이 달라집니다. 예시로 서비스 생성 비용은 서비스당 월 15달러이며, 자동화된 Dependency Assessment는 서비스당 월 10달러의 선택형 추가 비용으로 안내됩니다. 평가·테스트 리소스 수와 실행 시간에 따라 추가 비용이 생길 수 있습니다.

따라서 처음부터 전 계정·전 서비스에 켜는 방식은 적절하지 않습니다.

고객 영향이 큰 서비스 하나를 선정합니다.
EKS 레이블과 서비스 소유자를 정리합니다.
Dependency discovery를 켜고 35일 창에서 실제 의존성을 관찰합니다.
인사이트를 장애 모드 분석과 운영 로그로 교차 검증합니다.
비용·개선 시간·테스트 결과를 확인한 뒤 정책 공유 범위를 넓힙니다.

비용을 줄이려고 discovery를 끄면 의존성 인사이트도 사용할 수 없습니다. 반대로 의존성은 많이 발견되는데 담당자와 복구 목표가 없다면, 분석 비용만 늘고 운영 개선은 일어나지 않습니다. 도입 전 “발견된 위험을 누가 언제 해결할 것인가”를 먼저 정해야 합니다.

9. AWS Well-Architected와의 연결

AWS Well-Architected Reliability 지침은 외부·내부 의존성을 식별하고, 부분 장애와 과부하를 고려하며, 실패를 테스트하라고 권고합니다. Resilience Hub는 이 원칙을 자동화된 탐색과 정책 평가로 연결하는 도구입니다.

그러나 도구가 다음 설계를 자동으로 만들어 주지는 않습니다.

타임아웃, 재시도, 지수 백오프와 jitter
서킷 브레이커와 bulkhead
큐 기반 비동기 처리
멱등성과 중복 요청 처리
다중 AZ·다중 리전 복제
실제 복구 절차와 의사결정권자

예를 들어 Dependency insights가 결제 API의 교차 리전 호출을 보여 줘도, 해결책은 리전을 옮기는 것일 수도 있고, 로컬 큐와 보상 트랜잭션을 도입하는 것일 수도 있습니다. 조직의 RTO·RPO, 데이터 주권, 비용, 운영 복잡도를 함께 비교해야 합니다.

10. 한계와 오해

발견되지 않은 의존성은 없는 의존성이 아니다

DNS 기반 discovery는 관찰된 질의를 바탕으로 합니다. 정적 설정, 캐시, 직접 IP 통신, 드물게 실행되는 장애 경로가 항상 같은 방식으로 잡힌다고 보장할 수 없습니다. 애플리케이션 트레이스·VPC Flow Logs·서비스 카탈로그와 함께 확인해야 합니다.

AI 요약은 설명 가능성을 보장하지 않는다

Dependency insights는 짧은 설명과 범주를 제공하지만, 최종 판단에 필요한 모든 원본 로그와 맥락을 대신하지 않습니다. 요약을 생성한 데이터 기간과 대상 서비스를 기록하고, 운영자가 근거를 다시 열어 볼 수 있게 해야 합니다.

정책 준수는 가용성의 증명이 아니다

RTO·RPO 기준을 만족하는 구성으로 보인다고 해서 실제 장애 시 복구된다는 뜻은 아닙니다. AWS Well-Architected 지침처럼 복구 절차를 실제로 실행하고, 결과를 측정해야 합니다.

중앙 정책은 지역·업무 차이를 지울 수 있다

Organizations 정책 공유는 표준화를 돕지만, 한국 리전의 데이터 규정이나 교육·연구용 서비스의 낮은 중요도를 고려하지 않으면 불필요한 비용과 예외가 커집니다. 정책 계층과 예외 승인 절차를 함께 설계해야 합니다.

11. 교육과 실무에서 얻는 데이터 엔지니어링 교훈

이번 기능은 Kubernetes·클라우드·데이터 엔지니어링 교육을 한 과제로 묶기 좋습니다.

실습 1: 레이블에서 서비스 카탈로그 만들기

작은 EKS 예제에 팀·서비스·중요도 레이블을 부여하고, 레이블 누락이 Resilience Hub 평가 범위에 어떤 차이를 만드는지 비교합니다. 인프라 메타데이터가 곧 운영 데이터라는 점을 배울 수 있습니다.

실습 2: 의존성 그래프와 장애 모드

의존성 목록을 하드·소프트 의존성으로 분류하고, 인증 API가 30분 중단되는 시나리오를 작성합니다. 캐시·큐·대체 응답을 적용한 뒤 RTO와 사용자 경험이 어떻게 달라지는지 측정합니다.

실습 3: AI 요약 검증

Dependency insights가 제시한 신규·교차 리전·제3자 의존성을 원본 로그와 대조합니다. AI가 맞힌 항목뿐 아니라 놓친 항목을 기록해 “요약 정확도”와 “운영 유용성”을 분리해 평가합니다.

학생에게 가장 중요한 질문은 “AI가 뭐라고 했는가?”가 아니라 “그 결과를 어떤 증거로 검증했는가?”입니다. 복원력은 대시보드의 점수가 아니라, 장애 중에도 업무를 지속시키는 설계와 훈련의 결과이기 때문입니다.

결론

AWS Resilience Hub의 2026년 9월 업데이트는 EKS 범위 지정, 의존성 AI 요약, Organizations 정책 공유를 통해 복원력 운영의 세 층을 연결합니다.

레이블은 어떤 서비스가 평가 대상인지 명확하게 만들고,
Dependency insights는 많은 의존성에서 검토 순서를 정하며,
정책 공유는 여러 계정에 같은 복구 기준을 적용하게 합니다.

도입의 핵심은 기능을 켜는 속도가 아닙니다. 35일 데이터와 24시간 재생성 제한을 이해하고, 최소 권한과 메타데이터 보호를 설계하며, AI 요약을 로그·트레이스·장애 실험으로 검증하는 것입니다. 그렇게 할 때 Resilience Hub는 “장애 가능성을 알려 주는 콘솔”을 넘어 복구 목표를 설계하고 시험하는 운영 루프가 됩니다.

참고 자료

AWS Resilience Hub의 리전·가격·지원 리소스와 생성형 AI 기능은 계속 변경될 수 있습니다. 실제 복원력 목표와 비용을 결정할 때는 AWS 콘솔, 계정별 가격 페이지, 최신 문서와 조직의 RTO·RPO 정책을 함께 확인하세요.