고된 작업에서 신뢰로: Azure SRE 에이전트가 클라우드 운영을 재정의하는 방법

Azure 환경이 확장됨에 따라 인프라 팀은 익숙한 난관에 직면합니다: 대규모에서 안정적으로 운영하는 것. 이제 서비스 중단은 단일 VM이나 잘못 구성된 서비스로 인해 발생하는 것이 아니라, 컴퓨팅, 네트워킹, 스토리지 및 플랫폼 서비스 전반에 걸친 복잡한 종속성에서 비롯됩니다.

Azure SRE 에이전트는 AI 지원 진단 및 해결 기능을 Azure 운영에 직접 통합하여 인프라 및 SRE 팀이 이러한 난관에 대처할 수 있도록 설계되었습니다.

이 게시물은 다음 사항에 초점을 맞춥니다:

• Azure SRE 에이전트가 가장 유용한 인프라 중심 시나리오
• 인프라 팀이 Azure 포털에서 에이전트에 액세스하는 방법
• 온보딩 전 필요한 선행 조건

Azure SRE 에이전트는 현재 미리 보기로 제공됩니다. 기능, 역량 및 지역별 가용성은 일반 공급 전에 변경될 수 있습니다. 이 게시물은 작성 시점의 제품 동작을 반영합니다.

Azure SRE 에이전트란 무엇인가 (인프라 관점)

Azure SRE 에이전트는 Azure에 통합된 AI 기반 안정성 비서입니다. 이 에이전트는 Azure Monitor, Log Analytics 및 서비스 API에서 원격 측정 데이터를 지속적으로 관찰하여 엔지니어가 운영 환경의 문제를 진단, 조사 및 해결하도록 돕습니다.

인프라 관점에서 에이전트는 다음을 이해합니다:

• Azure 리소스 토폴로지 및 종속성
• Azure 서비스 전반의 일반적인 장애 패턴
• Azure CLI 및 REST API를 사용한 안전한 운영 작업

이 에이전트는 작업을 권장하거나 적절한 보호 장치 및 승인을 통해 문제 해결 단계를 실행할 수 있습니다.

이 에이전트는 다음을 포함한 여러 자동화 메커니즘을 통해 작동합니다:

• 내장된 Azure 지식: 최적화된 운영 패턴을 갖춘 Azure 서비스에 대한 사전 구성된 이해
• 사용자 지정 런북: 모든 Azure 서비스에 대한 Azure CLI 명령 및 REST API 호출 실행
• 하위 에이전트 확장성: VM, 데이터베이스 또는 네트워킹 구성 요소와 같은 특정 서비스를 위한 전문 에이전트 구축
• 외부 통합: 모니터링, 인시던트 관리 및 소스 제어 시스템에 연결

Azure SRE 에이전트가 가장 도움이 되는 인프라 시나리오

1. 인시던트 조사 및 운영 중단

인시던트 발생 시, 인프라 엔지니어는 일반적으로 경고, 메트릭, 로그 및 대시보드를 오가며 확인합니다. Azure SRE 에이전트는 원격 측정 데이터를 자동으로 상호 연관시키고 문제를 자연어로 요약하여 이를 간소화합니다.

일반적인 인프라 문제:

• 응답하지 않는 가상 머신
• App Service 또는 Container App 오류
• 네트워크 연결 또는 NSG 구성 오류
• 스토리지 제한 또는 용량 고갈

엔지니어는 수동으로 로그를 쿼리하는 대신, 에이전트에게 어떤 문제가 왜 발생했는지 묻고 합리적인 답변을 받을 수 있습니다.

2. 로그 및 메트릭 기반 근본 원인 분석

Azure SRE 에이전트는 Azure Monitor 및 Log Analytics 데이터를 직접 소비합니다. 이를 통해 엔지니어가 일반적인 시나리오에 대해 수동으로 KQL을 작성할 필요 없이 상황 인지 RCA를 수행할 수 있습니다.

예시 질문:

"지난 배포 이후 App Service가 HTTP 500 오류를 반환하기 시작한 이유는 무엇인가요?"

에이전트는 배포 활동, 구성 변경 사항 및 원격 측정 데이터를 상호 연관시켜 가장 가능성 높은 근본 원인을 식별합니다.

3. 인프라 문제에 대한 안전하고 제어된 문제 해결

인프라 팀에게 중요한 가치는 제어된 자동화입니다.

Azure SRE 에이전트는 다음을 지원합니다:

• 검토 모드 – 작업이 제안되며 명시적인 승인이 필요합니다.
• 자율 모드 – 사전 승인된 하위 에이전트가 작업을 자동으로 실행합니다.

이는 다음과 같은 반복적인 인프라 작업에 유용합니다:

• 비정상 서비스 다시 시작
• 컴퓨팅 리소스 확장
• 실패한 배포 롤백
• 알려진 구성 드리프트 수정

자동화는 맹목적으로가 아니라 보호 장치를 갖춘 자동화가 적용됩니다.

4. 인프라 보호 장치 및 운영 위생

인시던트 외에도 Azure SRE 에이전트는 인프라 상태를 지속적으로 평가하고 운영 위험을 강조할 수 있습니다.

예시는 다음과 같습니다:

• 안전하지 않은 네트워크 노출 감지
• 지원되지 않는 SKU 또는 구성 플래그 지정
• 운영 안티 패턴 식별

이는 인프라 팀이 사후 대응적인 문제 해결에서 사전 예방적 안정성 관리로 전환하는 데 도움이 됩니다.

5. 하위 에이전트를 사용한 인프라 자동화 확장

인프라 팀은 네트워킹, 데이터베이스 또는 스토리지와 같은 특정 도메인에 맞춰진 하위 에이전트를 사용하여 Azure SRE 에이전트를 확장할 수 있습니다.

하위 에이전트 빌더를 사용하여 팀은 다음을 수행할 수 있습니다:

• 사용자 지정 런북 첨부
• 외부 관찰 가능성 도구 통합
• 경고 또는 일정에 따라 작업 트리거

이를 통해 자문 지원에서 고급 자동화에 이르는 점진적인 채택이 가능합니다.

Azure SRE 에이전트 시작하기

다음 섹션에서는 엔터프라이즈 Azure 환경에서 Azure SRE 에이전트를 온보딩하는 데 필요한 선행 조건, 연결 고려 사항 및 지원되는 통합에 대해 설명합니다.

선행 조건 및 소유권 모델

Azure SRE 에이전트는 인프라, 플랫폼, 보안 및 네트워크 팀 전반에 걸쳐 플랫폼 수준의 선행 조건을 도입합니다. 인프라 팀이 주요 사용자이지만, 성공적인 온보딩을 위해서는 교차 팀 간의 조율이 필요합니다.

아래 섹션에서는 명확성을 위해 소유권을 명시적으로 태그합니다.

1. 구독 및 지역

소유자: 플랫폼 / 구독 관리자

• 평가 또는 PoC를 위한 전용 Azure 구독 또는 리소스 그룹 권장
• 미리 보기 기간 동안, 에이전트 제어 평면은 사용 가능한 위치(스웨덴 중부, 오스트레일리아 동부, 미국 동부 2)에 생성되어야 하며, 모니터링되는 워크로드는 모든 Azure 지역에 있을 수 있습니다.
• 구독은 미리 보기 액세스를 위해 허용 목록에 추가되어야 할 수 있습니다.

인프라 팀은 일반적으로 이러한 설정을 요청하고, 플랫폼 팀이 이를 구현합니다.

2. ID 및 액세스 (필수)

소유자: 플랫폼 + 보안 소비자: 인프라 / SRE

• 관리 ID(시나리오에 따라 시스템 할당 또는 사용자 할당)를 생성할 수 있는 기능
• 온보딩 중 향상된 RBAC 권한 필요:
  • 구독 범위에서 Microsoft.Authorization/roleAssignments/write
  • 소유자, 사용자 액세스 관리자 또는 RBAC 관리자와 같은 역할
• 온보딩 후, SRE 에이전트 ID에는 최소 권한 RBAC가 부여되어야 합니다:
  • 조사 시나리오에 대한 읽기 전용 액세스
  • 문제 해결이 승인된 경우에만 범위가 지정된 쓰기 액세스

인프라 팀이 ID를 사용하고, 보안 및 플랫폼 팀이 액세스를 관리합니다.

3. 리소스 공급자 등록

소유자: 플랫폼

• 필수 Azure 리소스 공급자가 구독에 등록되어야 합니다.
• 에이전트 런타임 및 종속 서비스에서 사용되는 공급자 포함

일반적으로 일회성 플랫폼 작업입니다.

4. 모니터링 및 원격 측정 기준선 (필수 종속성)

소유자: 인프라 / 플랫폼 (공동)

• 대상 워크로드에 대해 Azure Monitor 활성화
• 진단 설정이 로그 및 메트릭을 다음으로 보내도록 구성:
  • Log Analytics
  • Application Insights (해당하는 경우)
• 에이전트 생성 중 지원 리소스가 배포될 수 있습니다:
  • Log Analytics 작업 영역
  • Application Insights
  • 스마트 감지기 경고 규칙

인프라 팀은 이 원격 측정 데이터에 의존하며, 플랫폼 팀은 종종 공유 기반을 제공합니다.

5. 네트워크 및 연결

소유자: 네트워크 / 보안

• 다음으로의 아웃바운드 HTTPS 연결 필요:
  • Azure 관리 엔드포인트 (ARM, Monitor 등)
  • 통합이 활성화된 경우 외부 시스템 (예: ServiceNow 또는 MCP 서버)
• 사용자 지정 MCP 엔드포인트는 원격이며 HTTPS를 통해 접근 가능해야 합니다 (로컬 엔드포인트는 지원되지 않음).
• IP 허용 목록 시나리오는 명시적으로 유효성을 검사해야 합니다. 고정 이그레스 IP는 보장되지 않습니다.

조직이 엄격한 네트워크 제어를 시행하는 경우에만 필요합니다.

6. 커넥터별 선행 조건 (조건부)

소유자: 보안 + 플랫폼 소비자: 인프라 / SRE

• Microsoft Teams / Outlook 커넥터
  • Microsoft 365 API에 대한 OAuth 동의
  • 커넥터 인증을 위한 사용자 할당 관리 ID 필요
• 사용자 지정 MCP 커넥터
  • MCP 기본 URL
  • 인증 자료 (API 키, 토큰 또는 OAuth)
  • 커넥터 구성 및 관리를 위한 RBAC 권한

통합이 활성화된 경우에만 적용됩니다.

7. 자동화 준비 상태

소유자: 인프라 / SRE + 보안

• 권장 사항 전용 대 자동화된 문제 해결에 대한 명확한 결정
• 정의된 승인 모델:
  • 사람 개입
  • 잘 이해되는 작업에 대한 범위가 지정된 자율성
• 에이전트 ID에는 자동화가 명시적으로 승인된 경우에만 쓰기 권한이 부여됩니다.

인프라 팀이 운영 의도를 정의하고, 보안 팀이 경계를 검증합니다.

8. 거버넌스 및 데이터 처리

소유자: 보안 / 거버넌스

• 프롬프트, 응답 및 분석 데이터가 에이전트가 위치한 지역에 저장된다는 점에 대한 수락
• 다음과 같은 조직 정책과의 조율:
  • 로깅 및 보존
  • 감사 가능성
  • 책임 있는 AI 사용 및 승인

이는 거버넌스 선행 조건이며, 인프라 작업이 아닙니다.

Azure SRE 에이전트는 Azure Resource Manager, Azure Monitor, Log Analytics 및 관리 ID 위에 계층화된 관리형 제어 평면으로 작동합니다. 결과적으로, ID, 원격 측정 및 거버넌스 기반이 구축되어야만 인프라 팀이 에이전트의 이점을 충분히 활용할 수 있습니다.

지원되는 통합

Azure SRE 에이전트는 다음 방식으로 운영 에코시스템과 통합됩니다:

• 모니터링 및 관찰 가능성:
  • Azure Monitor (메트릭, 로그, 경고, 통합 문서)
  • Application Insights
  • Log Analytics
  • Grafana
• 인시던트 관리:
  • Azure Monitor 경고
  • PagerDuty
  • ServiceNow
• 소스 제어 및 CI/CD:
  • GitHub (리포지토리, 이슈)
  • Azure DevOps (리포지토리, 작업 항목)
• 데이터 소스:
  • Azure 데이터 탐색기 (Kusto) 클러스터
  • 모델 컨텍스트 프로토콜 (MCP) 서버

연결 매트릭스

1. Azure 제어 평면 연결

• 모든 Azure 제어 평면 통신은 에이전트에서 아웃바운드 전용입니다.
• 고객 VNet에 대한 인바운드 연결은 필요하지 않습니다.

2. 인시던트 관리 통합

• 타사 플랫폼에는 명시적인 커넥터 구성이 필요합니다.
• 페이로드는 인시던트 메타데이터 및 진단 컨텍스트로 제한됩니다.

3. 협업 및 알림 채널

• Office 365 커넥터에는 사용자 할당 관리 ID만 지원됩니다.
• 에이전트에 사서함 수준 권한이 저장되지 않습니다.

4. 외부 및 사용자 지정 통합

• 엔드포인트는 명시적으로 구성 및 승인되어야 합니다.
• 비밀은 영구적으로 저장되지 않으며, 자격 증명은 런타임에 안전하게 주입됩니다.

5. 방화벽 및 네트워크 고려 사항

• 방화벽 허용 목록에 * .azuresre.ai * 를 추가하세요. 일부 네트워킹 프로필은 기본적으로 이 도메인에 대한 액세스를 차단할 수 있습니다.
• 아웃바운드 HTTPS (443)를 다음으로 허용:
  • Azure 제어 평면 엔드포인트
  • • .azuresre.ai * (SRE 에이전트 서비스)
  • 구성된 타사 엔드포인트 (ServiceNow, PagerDuty, MCP 서버)
• 인바운드 방화벽 규칙 또는 프라이빗 엔드포인트 노출은 필요하지 않습니다.
• 허용 목록에 추가될 경우 프라이빗 VNet 및 제한된 아웃바운드 모델과 호환됩니다.

Azure SRE 에이전트 액세스 방법

Azure SRE 에이전트는 Azure 포털에서 직접 또는 자체 SRE 포털을 통해 액세스할 수 있습니다.

아래에 몇 가지 스크린샷을 추가합니다:

관련 링크:

1. SRE 에이전트 사용 방법 확인, 여기.
2. 워크플로 자동화 방법 이해, 여기.
3. SRE 에이전트를 사용하여 Azure 환경 진단 수행, 여기.
4. 외부 시스템으로의 도달 범위를 확장하는 데 사용되는 커넥터에 대해 확인, 여기.
5. 첫 번째 조사를 설정하려면, 여기.
6. 가격 및 청구에 대해 알아보려면, 여기.
7. SRE 에이전트 권한 관리 방법 확인, 여기.
8. SRE 에이전트에서 MCP 커넥터를 설정하려면, 여기.
9. Azure SRE 에이전트의 하위 프로세서인 Anthropic

Azure SRE 에이전트가 인프라 팀에게 중요한 이유

대규모 Azure 자산을 관리하는 인프라 및 SRE 팀을 위해 Azure SRE 에이전트는 관찰 가능성, 인시던트 관리 및 배포 워크플로를 거버넌스가 적용된 의도 기반 운영 모델로 통합하는 단일 에이전트 기반 안정성 계층을 제공합니다.

• 평균 문제 해결 시간 (MTTR) 단축: Azure Monitor 및 Log Analytics와 기본적으로 통합되어, 에이전트가 수동 쿼리 작성이나 상관 관계 분석 없이도 심층적인 다중 신호 조사 및 근본 원인 분석을 수행합니다.
• 대시보드를 오가지 않는 빠른 조사: Azure SRE 에이전트는 단일 인터페이스에서 모니터링, 인시던트 및 배포 시스템 전반에 걸쳐 추론하여 도구 간의 컨텍스트 전환을 제거합니다.
• 심층 조사 및 근본 원인 분석: 로그, 메트릭, 구성 상태 및 최근 변경 사항에 걸쳐 다중 신호 상관 관계를 수행하여 표면적인 증상이 아닌 진정한 근본 원인을 식별하며, 명확하고 설명 가능한 결과를 제공합니다.
• 운영 부담 감소: 반복적인 진단 및 분류 작업은 에이전트가 처리하므로, 엔지니어는 더 높은 가치의 안정성 및 플랫폼 개선에 집중할 수 있습니다.
• 일관되고 감사 가능한 인시던트 대응: Azure Monitor, ServiceNow 및 PagerDuty 통합을 통해 조사는 ITSM 및 온콜 워크플로에 직접 포함되어 추적성, 일관성 및 거버넌스를 보장합니다.
• 예약된 작업 및 사전 예방적 점검: 예약된 워크플로를 사용하여 팀은 매일 또는 주기적인 상태 유효성 검사, 드리프트 검사 및 배포 후 확인을 실행할 수 있습니다. 이는 운영을 사후 대응적인 문제 해결에서 사전 예방적 안정성 관리로 전환합니다.
• 확장 가능한 하위 에이전트 및 기술: 인프라 팀은 도메인 전문 지식을 에이전트에 인코딩하여 신뢰성 지식을 재사용 가능하고 일관성 있게 만드는 기술, 하위 에이전트 및 워크플로를 생성할 수 있습니다.
• 배포 및 코드 인지: GitHub 및 Azure DevOps와의 통합을 통해 에이전트는 인프라 문제를 소스 코드, IaC 정의, 파이프라인 및 작업 항목과 연관시킬 수 있습니다. 이는 버그 생성, PR 권장 사항 또는 릴리스 수정과 같은 실행 가능한 후속 조치를 가능하게 합니다.
• 더 안전하고 통제된 자동화: 사람 개입 제어는 모든 권장 사항과 조치가 감사 가능하고, 검토 가능하며, 엔터프라이즈 거버넌스와 일치하도록 보장하여 안전을 손상시키지 않고 점진적인 자동화를 가능하게 합니다.
• 인프라 규모에서 더 나은 안정성: 팀을 수동 진단에서 의도 기반 에이전트 지원 운영으로 전환함으로써 Azure SRE 에이전트는 조직이 사후 대응적인 문제 해결에서 체계적이고 확장 가능한 안정성 엔지니어링으로 나아갈 수 있도록 돕습니다.

마무리 생각

Azure SRE 에이전트는 단순히 또 다른 문제 해결 도구가 아닙니다. 이는 에이전트 지원 인프라 운영으로의 전환을 의미합니다. AI 기반 추론을 Azure에 직접 내장함으로써 인프라 팀은 반복적인 조사에 덜 집중하고 복원력 있는 플랫폼을 구축하는 데 더 많은 노력을 기울일 수 있습니다.