Azure SRE Agent 소개¶
Azure SRE Agent의 기능, 구성 요소와 운영 흐름을 설명합니다.
Azure SRE Agent는 Azure 운영 환경에서 발생한 인시던트를 자동으로 조사하고, 관련 근거를 바탕으로 근본 원인과 조치 방안을 제안하는 AI 기반 운영 도우미입니다.
이 문서에서는 Azure SRE Agent가 인시던트를 조사하는 방식과 실제 활용 예시를 소개합니다. 제품에서 제공하는 표준 기능과 이번 실증에서 확인한 내용을 구분해 설명합니다.
Azure SRE Agent를 사용하면 무엇이 달라지나요?¶
운영자는 경고가 발생하면 여러 도구를 오가며 원인을 찾아야 합니다. Azure SRE Agent는 이 과정을 하나의 조사 흐름으로 연결합니다.
| 기존 장애 대응 | Azure SRE Agent를 활용한 대응 |
|---|---|
| 담당자가 경고를 확인한 뒤 조사를 시작합니다. | 대응 계획에 따라 에이전트가 자동으로 조사를 시작합니다. |
| 모니터링 화면, 로그, 변경 이력, 소스 코드를 각각 확인합니다. | 에이전트가 필요한 자료를 선택해 함께 분석합니다. |
| 담당자가 여러 가능성을 머릿속에서 비교합니다. | 에이전트가 가설을 세우고 근거를 통해 확인하거나 제외합니다. |
| 조사 결과를 티켓과 메일로 다시 작성합니다. | 같은 조사 결과를 GitHub Issue, Outlook, Microsoft Teams 등에 전달할 수 있습니다. |
| 해결 경험이 담당자 개인에게 남습니다. | 근본 원인과 해결 과정을 지식으로 축적할 수 있습니다. |
Azure SRE Agent는 단순히 오류 로그를 나열하지 않습니다. 어떤 서비스가 영향을 받았는지 확인하고, 원격 분석 데이터와 변경 이력, 소스 코드를 함께 살펴본 뒤 근본 원인과 다음 조치를 설명합니다.
인시던트가 발생하면 어떻게 조사하나요?¶
출처: 인시던트 대응 자동화
Azure SRE Agent는 다음 순서로 인시던트를 조사합니다.
- 경고를 받습니다.
Azure Monitor, PagerDuty 또는 ServiceNow에서 조사 요청을 받습니다. 이번 실증에서 사용한 별도 연결 방식은 뒤에서 설명합니다.
- 조사 범위를 확인합니다.
영향을 받은 서비스, 발생 시각, 고객 영향을 먼저 정리합니다.
- 관련 근거를 수집합니다.
Application Insights, Log Analytics, Azure Resource Graph, Azure Activity Log, 배포 이력, 소스 코드를 확인합니다.
- 가설을 세우고 검증합니다.
가능한 원인을 여러 개 세운 뒤 수집한 근거와 맞지 않는 원인을 제외합니다.
- 근본 원인과 조치 방안을 제안합니다.
확인한 근거, 현재 상태, 최소 범위의 완화 조치를 함께 설명합니다.
- 사람이 검토하고 승인합니다.
검토 모드에서는 변경 작업을 실행하기 전에 담당자의 승인을 받습니다.
- 조사 결과를 공유합니다.
ServiceNow, PagerDuty, GitHub, Outlook, Microsoft Teams 등 기존 운영 도구로 결과를 전달할 수 있습니다.
근본 원인은 어떻게 찾나요?¶
출처: 근본 원인 분석
어떤 정보를 조사할 수 있나요?¶
Azure SRE Agent는 관리 ID와 Azure RBAC 권한을 사용해 Azure 리소스를 조사합니다.
| 분류 | 확인할 수 있는 정보 |
|---|---|
| 애플리케이션 상태 | Application Insights 요청, 예외, 종속성 호출 |
| 로그 | Log Analytics 작업 영역의 로그 |
| 인프라 상태 | Azure Monitor 메트릭, 리소스 구성, Resource Graph |
| 변경 이력 | Azure Activity Log, 배포 이력, Container Apps 수정 버전 |
| 소스와 문서 | GitHub, Azure DevOps, 운영 절차서, 기술 문서 |
| 과거 경험 | 유사한 인시던트, 이전의 근본 원인과 해결 방법 |
Azure 내부 원격 분석 데이터는 기본 도구만으로도 조회할 수 있습니다. 외부 시스템이나 특정 데이터 원본을 지속해서 사용해야 하는 경우에는 커넥터를 추가합니다.
과거 경험과 운영 문서는 어떻게 활용하나요?¶
출처: 메모리와 지식 관리
출처: 메모리와 지식 관리
조사가 끝난 뒤 무엇을 학습하나요?¶
출처: 메모리와 지식 관리
어떤 시스템과 연결할 수 있나요?¶
인시던트 관리¶
- Azure Monitor 경고
- PagerDuty
- ServiceNow
소스와 작업 관리¶
- GitHub 저장소, Issue, Pull Request
- Azure DevOps 저장소와 Work Item
- Jira와 같은 관리형 커넥터(미리 보기) 또는 MCP 기반 티켓 시스템
관리형 커넥터로 연결할 수 있는 대표적인 서비스는 다음과 같습니다.
출처: 관리형 커넥터(미리 보기)
알림과 협업¶
- Outlook 메일
- Microsoft Teams 채널
- Slack 채널
출처: 조치 실행하기
외부 관찰 도구¶
- Grafana
- Datadog
- Dynatrace
- New Relic
- Splunk
- MCP를 지원하는 사용자 지정 도구
커넥터에서는 사용할 작업만 선택할 수 있습니다. 메일 수신자나 Jira 프로젝트 키처럼 에이전트가 임의로 바꾸면 안 되는 값은 고정할 수 있습니다.
권한과 승인 절차는 어떻게 제어하나요?¶
출처: 에이전트 추론과 실행
요청이 복잡하면 이 과정을 여러 차례 반복하며 판단을 다듬습니다. 각 단계에 걸리는 시간은 상황과 작업 범위에 따라 달라지므로 고정된 처리 시간을 보장하지는 않습니다.
Azure SRE Agent는 실행 수준에 따라 권한을 제어합니다.
| 모드 | 동작 |
|---|---|
| 읽기 전용 모드 | 자료를 조회하고 분석하지만 변경 작업은 실행하지 않습니다. |
| 검토 모드(Review mode) | 조치 방안을 제안하고 담당자의 승인을 기다립니다. |
| 자율 모드 | 허용된 작업을 별도 승인 없이 실행합니다. |
공식 기능인 검토 모드(Review)와 자율 모드(Autonomous)의 차이는 다음 그림에서도 확인할 수 있습니다.
출처: 실행 모드
처음 도입할 때는 검토 모드로 시작하는 것을 권장합니다. 조사 결과와 도구 선택이 실제 운영 절차에 맞는지 충분히 확인한 뒤 자동화 범위를 넓히는 편이 안전합니다.
커넥터를 설정할 때도 최소 권한 원칙을 적용해야 합니다.
- 읽기 작업과 쓰기 작업을 구분합니다.
- 필요한 작업만 에이전트에 노출합니다.
- 메일 수신자와 프로젝트 키처럼 중요한 값은 고정합니다.
- 삭제나 변경 작업은 승인을 받도록 설정합니다.
- 자율 모드에서는 일부 승인 절차가 생략될 수 있으므로 별도의 최소 권한 연결을 사용합니다.
관리 ID 권한이 부족할 때 담당자 승인으로 넘어가는 세부 과정은 다음 그림과 같습니다.
출처: 권한
팀에 맞게 어떻게 확장하나요?¶
출처: 스킬
기본 에이전트만으로 부족한 영역은 두 가지 방법으로 보완합니다.
| 구분 | 사용 방식 | 적합한 용도 |
|---|---|---|
| 스킬 | 관련 상황에서 에이전트가 자동으로 불러옵니다. | 팀 공통 문제 해결 절차와 실행 도구 |
| 사용자 지정 에이전트 | 담당자가 필요할 때 직접 호출합니다. | 데이터베이스, 보안처럼 특정 영역 전문 조사 |
스킬에는 절차를 담은 문서와 함께 Azure CLI, Kusto 쿼리, Python 스크립트 같은 도구를 연결할 수 있습니다. 따라서 방법을 설명하는 데서 그치지 않고 필요한 조회를 직접 수행합니다. 한 대화에서 동시에 활성화되는 스킬은 최대 5개이며, 이 수를 넘으면 오래된 스킬부터 해제되었다가 필요할 때 다시 불러옵니다.
사용자 지정 에이전트는 각자 도구와 커넥터, 사용할 스킬을 따로 지정합니다. 조사 과정에서 다른 전문 에이전트로 작업을 넘기도록 구성할 수도 있어, 인시던트 분류와 상세 조사, 결과 전달을 단계별로 나눌 수 있습니다.
출처: 사용자 지정 에이전트
인시던트를 담당자에게 어떻게 배분하나요?¶
대응 계획은 들어온 인시던트를 조건에 따라 적절한 사용자 지정 에이전트로 전달합니다. 다음 조건을 조합할 수 있습니다.
- 심각도 또는 우선순위(여러 값 동시 선택 가능)
- 영향을 받은 서비스
- 인시던트 유형
- 제목에 포함된 키워드
대응 계획마다 실행 수준을 따로 지정할 수 있어, 중요한 장애는 자동 조치를 허용하고 낮은 심각도는 검토 모드로 운영하는 방식이 가능합니다. 계획은 삭제하지 않고 사용 중지할 수 있으므로 정기 점검 기간에도 설정을 유지할 수 있습니다.
인시던트 플랫폼을 처음 연결하면 빠른 시작 대응 계획이 자동으로 만들어집니다. 사용자 정의 대응 계획을 만든 뒤에는 이 계획을 삭제해야 인시던트가 잘못 전달되거나 두 번 처리되지 않습니다.
출처: 인시던트 플랫폼
제품에서 기본으로 지원하는 방식¶
제품의 표준 Azure Monitor 연계는 Azure Monitor 인시던트 플랫폼 → 대응 계획 → Azure SRE Agent 순서로 동작합니다. 이 방식에서는 Logic App과 같은 중간 연결이 필요하지 않습니다.
Azure SRE Agent는 다음 기능을 제품에서 기본으로 지원합니다.
- Azure Monitor, PagerDuty, ServiceNow를 통한 인시던트 수신
- 조건에 맞는 인시던트를 담당 에이전트로 전달하는 대응 계획
- Application Insights와 Log Analytics 조사
- GitHub와 Azure DevOps 소스 연결
- ServiceNow와 PagerDuty 상태 갱신
- Outlook과 Microsoft Teams 알림 커넥터
- 읽기 전용, 검토, 자율 실행 모드
자세한 제품 기능은 다음 자료에서 확인할 수 있습니다.
이번 실증에서 사용한 방식¶
이번 실증에서는 대응 계획을 공개 API로 자동 구성하는 데 제약이 있어 Azure SRE Agent의 HTTP Trigger를 사용했습니다.
이 연결은 실증 자동화를 위해 사용한 방식이며, 표준 Azure Monitor 연계에 필요한 필수 구성은 아닙니다.
이번 실증에서 실제로 확인한 기능은 다음과 같습니다.
- Azure Monitor 경고에서 Azure SRE Agent 조사 시작
- Application Insights와 Azure Activity Log 분석
- Container Apps 설정과 배포 이력 확인
- GitHub 저장소 검색
- 근본 원인과 조치 방안 작성
- 검토 모드에서 변경 작업을 실행하지 않는 안전 제어
- 실제 GitHub Issue 생성
- Outlook에서 열 수 있는 메일 초안 생성
다음 기능은 이번 실증에서 실제 연결하지 않았습니다.
- ServiceNow
- PagerDuty
- Outlook OAuth 커넥터
- Microsoft Teams 커넥터
- Azure Monitor 기본 대응 계획
실제 활용 예시: 주문 API에서 HTTP 500 발생¶
배포 설정 오류로 주문 API가 HTTP 500을 반환하는 상황을 만들고, Azure SRE Agent가 어떤 근거를 확인하는지 검증했습니다.
상황¶
- 서비스:
ca-sre-event-lab-vnet - 영향:
GET /api/orders요청 120건 실패 - 탐지: Azure Monitor 경고
- 실행 수준: 검토 모드
에이전트에게 기대한 조사¶
- 영향을 받은 서비스와 API를 정확히 찾아야 합니다.
- 장애가 시작된 시각을 확인해야 합니다.
- 외부 종속성 문제와 애플리케이션 문제를 구분해야 합니다.
- 장애 직전에 변경된 배포 설정을 찾아야 합니다.
- 서비스가 정상으로 돌아왔는지 확인해야 합니다.
- 추가로 필요한 조치를 제안해야 합니다.
실제 확인 결과¶
- Azure Monitor 경고가 발생한 뒤 2초 안에 조사 대화가 생성됐습니다.
- Application Insights에서 실패한 요청 120건을 확인했습니다.
- Container Apps 수정 버전
0000010에서FAILURE_MODE=http500설정을 확인했습니다. - 정상 설정을 사용한 후속 수정 버전으로 트래픽이 이동한 사실을 확인했습니다.
- 에이전트는 검토 모드에서 Azure 리소스를 직접 변경하지 않았습니다.
조사 결과를 티켓으로 전달하기¶
Azure SRE Agent가 정리한 근본 원인과 조치 방안을 작업 항목으로 전달할 수 있습니다. 이번 실증에서는 같은 조사 결과로 실제 GitHub Issue를 만들었습니다.
Issue에는 다음 내용을 포함했습니다.
- 고객 영향
- 탐지 시각과 조사 시작 시각
- 근본 원인
- 확인한 근거
- 현재 복구 상태
- 후속 권장 사항
- Azure SRE Agent 조사 식별자
실제 운영 환경에서는 ServiceNow, PagerDuty, Azure DevOps Work Item, Jira 등으로 같은 형식을 전달할 수 있습니다.
조사 결과를 메일로 공유하기¶
이번 실증에서는 외부 수신자에게 메일을 보내지 않았습니다. 대신 Azure SRE Agent의 조사 결과로 Outlook에서 열 수 있는 메일 초안과 화면 미리보기를 만들었습니다.
실제 운영에서는 Outlook 커넥터의 메일 보내기 작업을 사용할 수 있습니다.
- 받는 사람은 담당자 또는 배포 목록으로 고정합니다.
- 제목과 본문은 에이전트가 조사 결과를 바탕으로 작성하도록 설정할 수 있습니다.
- 검토 모드에서는 담당자가 내용을 확인한 뒤 전송합니다.
- 자율 모드에는 중요한 수신자나 작업을 별도의 최소 권한 연결로 분리합니다.
다른 장애에도 같은 조사 방식을 적용할 수 있나요?¶
이번 실증에서는 세 가지 유형을 확인했습니다.
| 상황 | Azure SRE Agent가 확인한 내용 | 결과 |
|---|---|---|
| 주문 API HTTP 500 | 실패한 요청, 수정 버전, 설정 변경 | 설정 오류를 근본 원인으로 확인했습니다. |
| 주문 API 지연 | 성공한 요청의 응답 시간, 외부 종속성, 지연 설정 | ORDER_DELAY_MS=4000을 확인했습니다. |
| Blob 권한 오류 | 역할 삭제 이력, Blob 403, API 503 | 역할 삭제를 근본 원인으로 확인했습니다. 복구 확인 대상은 한 차례 잘못 선택해 한계로 기록했습니다. |
상세 수치, 시간 순서, 평가 기준은 실제 동작 검증 결과에서 확인할 수 있습니다.
Dynamic Thresholds와 함께 사용할 수 있나요?¶
이번 실증은 같은 날 결과를 확인하기 위해 고정 임계값을 사용했습니다. 실제 운영에서는 Dynamic Thresholds를 함께 사용해 평소와 다른 패턴을 찾을 수 있습니다.
- 최소 3일과 30개 표본이 있어야 경고가 발생합니다.
- 최근 10일의 데이터를 기준으로 허용 범위를 계산합니다.
- 주간 패턴을 학습하려면 최소 3주가 필요합니다.
- 로그 검색 경고에서는 1분 단위 평가를 지원하지 않습니다.
처음에는 기존 고정 임계값을 유지하고, Dynamic Thresholds를 별도의 관찰용 경고로 추가하는 방식을 권장합니다. 충분한 학습 기간을 거친 뒤 오탐과 누락을 비교해 실제 대응 흐름에 연결합니다.
자세한 내용은 Dynamic Thresholds 연계 가이드를 참고하세요.
도입 전에 확인해야 할 사전 조건¶
Azure SRE Agent를 만들기 전에 다음 조건을 먼저 확인하세요.
- 구독이 Azure SRE Agent 사용 대상으로 등록되어 있어야 합니다. 등록되지 않으면 에이전트를 만들 때 리전 목록이 비어 있습니다.
- 에이전트를 만드는 담당자에게 구독 Contributor 권한이 필요합니다. 리소스 공급자를 등록하고 리소스를 만들기 위한 권한입니다.
- 역할 할당을 직접 만들려면 Owner 또는 User Access Administrator 권한이 추가로 필요합니다.
- 사내 네트워크에서 에이전트 포털 도메인을 차단하지 않아야 합니다. 보안 프록시 환경에서는 사전에 허용 목록을 확인하세요.
에이전트가 조사에 사용하는 권한은 담당자의 권한과 다릅니다. 에이전트의 관리 ID는 기본적으로 읽기 권한만 가지며, 변경 작업을 하려면 필요한 범위에 권한을 따로 부여해야 합니다.
에이전트는 한 리전에 배포합니다. Korea Central을 포함해 여러 리전을 지원하지만, 만든 뒤에는 리전은 변경할 수 없습니다. 다른 리전에서 운영하려면 해당 리전에 별도 에이전트를 만듭니다. 에이전트가 배포된 리전과 무관하게 다른 리전의 리소스를 조사할 수 있습니다.
AI 모델 공급자도 함께 확인하세요. 조사 대화와 요약 결과는 에이전트를 배포한 리전에 저장되지만, 모델 추론은 공급자에 따라 다른 국가에서 처리될 수 있습니다. 지역별 기본 공급자가 다르므로, 데이터 처리 위치에 대한 요건이 있는 조직은 도입 검토 단계에서 현재 설정된 공급자와 처리 범위를 확인하세요.
비용은 어떻게 발생하나요?¶
Azure SRE Agent는 Azure Agent Unit(AAU)을 기준으로 과금합니다. 비용은 두 가지로 나뉩니다.
| 구분 | 발생 방식 |
|---|---|
| 상시 비용 | 에이전트를 만든 시점부터 삭제할 때까지 시간 단위로 발생합니다. |
| 활성 비용 | 조사, 채팅, 예약 작업처럼 모델을 사용하는 작업에서 토큰 사용량에 따라 발생합니다. |
비용을 관리할 때는 다음을 기억하세요.
- 에이전트를 중지해도 상시 비용은 계속 발생합니다. 완전히 멈추려면 삭제해야 합니다.
- 월별 AAU 한도를 설정할 수 있습니다. 이 한도는 활성 비용에만 적용되며, 한도에 도달하면 다음 달까지 조사와 채팅을 사용할 수 없습니다. 상시 비용은 한도와 무관하게 계속 발생합니다.
- 사용하는 모델에 따라 단가가 크게 달라집니다.
- 스레드 유형별 사용량을 확인하고 내보낼 수 있어 팀별 비용 배분에 활용할 수 있습니다.
- Azure Monitor 로그 조회처럼 연결된 서비스의 비용은 별도로 발생합니다.
보안과 데이터는 어떻게 보호되나요?¶
Azure SRE Agent는 조사 도구를 격리된 샌드박스에서 실행하고, 자격 증명을 대화 맥락에 남기지 않습니다.
- 도구 실행 환경은 에이전트별로 분리되며, 호출마다 새 프로세스를 사용합니다.
- 자격 증명은 호출 시점에 짧은 수명 토큰으로 발급하고 재사용하지 않습니다.
- 조회한 원시 로그는 별도로 저장하지 않고, 조사 대화와 요약된 결과만 보존합니다.
- 관리 ID 권한이 부족하면 담당자 승인 후 사용자 자격 증명으로 실행하며, 이후 자격 증명을 캐시하지 않습니다.
- Azure CLI 기반 작업에는 안전 장치가 있어 삭제 계열 명령과 키 자격 증명 모음 접근은 차단됩니다.
- 읽기 전용으로 잠근 리소스는 변경하지 않습니다.
Log Analytics 작업 영역이나 AKS를 비공개 네트워크로만 노출한 환경이라면 에이전트의 네트워크 모드를 VNet 통합으로 설정해 프라이빗 엔드포인트에 접근할 수 있습니다. 이 기능은 현재 미리 보기입니다. 공개 엔드포인트만 사용하는 환경에서는 별도 VNet 구성 없이도 조사할 수 있습니다. 자세한 구성 방법은 아래 '비공개 네트워크에는 어떻게 연결하나요?' 절에서 설명합니다.
비공개 네트워크에는 어떻게 연결하나요?¶
출처: 네트워크 통합
Azure SRE Agent가 비공개 네트워크에 있는 리소스에 접근하려면 VNet 통합(VNet integration)을 사용합니다. 이 기능의 공식 명칭은 VNet 통합이며, 흔히 쓰이는 표현인 'VNet 삽입(VNet injection)'은 공식 용어가 아니므로 안내나 문서에서 혼용하지 않는 것이 좋습니다. VNet 통합은 현재 미리 보기 상태입니다.
네트워크 제어가 왜 필요한가요?¶
기본값인 Unrestricted 모드에서는 에이전트가 인터넷의 모든 엔드포인트에 연결할 수 있습니다. 개발과 테스트 환경에서는 문제가 되지 않지만, 운영 환경에서는 다음 두 가지 위험이 남습니다.
- 데이터 유출(data exfiltration): 민감한 내부 데이터를 다루는 에이전트가 인터넷으로 자유롭게 나갈 수 있으면 조직 밖으로 데이터가 빠져나가는 경로가 생깁니다.
- 프롬프트 인젝션(prompt injection): 공개 인터넷의 악의적인 내용은 에이전트의 판단을 조작하도록 만들어질 수 있으며, 외부 콘텐츠를 가져오는 에이전트는 그 응답을 통한 공격에 노출됩니다.
VNet 통합을 적용하면 에이전트의 아웃바운드 호출이 조직의 네트워크 인프라를 지나갑니다. 그 결과 네트워크 로그에 기록되어 감사와 모니터링에 활용할 수 있고, 계층 4와 계층 7 방화벽 검사, 사용자 지정 DNS 구성, 기존 송신 규칙이 그대로 적용됩니다. 에이전트는 같은 네트워크의 다른 워크로드와 동일한 규칙 아래에서 동작합니다.
세 가지 네트워크 제어 모드¶
| 모드 | 설명 | 이런 경우에 적합합니다 |
|---|---|---|
| Unrestricted(기본값) | 아웃바운드 트래픽 제한이 없습니다. | 개발, 테스트, 민감하지 않은 워크로드 |
| Limited | 허용 목록에 등록한 호스트로만 아웃바운드 연결을 제한합니다. | 전체 VNet 구성 없이 특정 대상만 제어하고 싶을 때 |
| Azure VNet | 플랫폼 트래픽을 제외한 아웃바운드 트래픽을 사용자의 VNet으로 라우팅합니다. | 감사 추적과 송신 제어가 필요한 운영 환경 |
사전 준비 사항¶
- 에이전트와 같은 리전에 있는 전용 서브넷이 필요합니다.
- 서브넷 크기는 /28 이상이어야 하며, 여러 에이전트를 함께 운영하거나 트래픽이 몰릴 때를 대비하려면 /26까지 넉넉하게 확보하는 것을 권장합니다.
- 서브넷은 Microsoft.App/environments에 위임(delegate)되어 있어야 합니다.
- 서브넷을 연결할 담당자에게는 대상 서브넷에 대한 Network Contributor 역할(또는
Microsoft.Network/virtualNetworks/subnets/join/action권한을 포함하는 동급 역할)이 필요합니다. - 에이전트 리소스에는 SRE Agent Administrator 역할이 필요합니다.
- 서브넷은 다른 서비스와 공유할 수 없으며 에이전트 전용으로 사용해야 합니다.
트래픽 경로는 대상마다 다릅니다¶
| 트래픽 대상 | 실제 경로 | 설정 가능 여부 |
|---|---|---|
| Azure 리소스(Log Analytics, Application Insights, AKS, 데이터베이스, Key Vault 등) | 사용자의 VNet | 기본적으로 VNet을 통과합니다. |
| 온프레미스 시스템(ExpressRoute 또는 VPN으로 연결) | 사용자의 VNet | 네트워크 경로가 허용하면 접근할 수 있습니다. |
| 플랫폼 서비스(오케스트레이션, 모델 엔드포인트, 원격 분석) | Azure SRE Agent 인프라 네트워크 | 변경할 수 없으며 항상 관리형 인프라를 거칩니다. |
| 패키지 레지스트리(PyPI, npm, NuGet, apt 등) | 토글을 켜면 인프라 네트워크, 끄면 VNet의 FQDN 방화벽 규칙 | 레지스트리별로 개별 설정할 수 있습니다. |
| 코드 저장소(GitHub, GitHub Enterprise, Azure DevOps) | 토글을 켜면 인프라 네트워크, 끄면 VNet의 FQDN 방화벽 규칙 | 공급자별로 개별 설정할 수 있습니다. |
| 원격 MCP 서버 | 토글을 켜면 인프라 네트워크, 끄면 VNet의 FQDN 방화벽 규칙 | 단일 토글로 설정합니다. |
| 추가 호스트 목록에 등록한 호스트 | 인프라 네트워크 | 호스트 이름이나 *.example.com 같은 와일드카드 패턴을 직접 입력해 관리합니다. 구성한 패키지와 커넥터는 각자 사용하는 호스트를 자동으로 허용하므로, 목록에는 레지스트리와 코드 저장소 밖의 대상만 등록하면 됩니다. |
| 커넥터 트래픽(관리형 커넥터 포함) | 공개 인터넷 | 변경할 수 없습니다. 미리 보기 기간에는 VNet을 거치지 않고 공개 인터넷 경로로 전송됩니다. |
| 프라이빗 엔드포인트를 통한 인바운드 연결 | 지원하지 않음 | 이번 미리 보기에서는 아웃바운드 방향만 제어합니다. |
설정 절차¶
- 에이전트 포털에서 설정 > 작업 영역 구성 > 네트워킹 탭을 엽니다.
- 네트워크 제어 모드로 Azure VNet을 선택합니다.
- 서브넷 찾아보기에서 구독, 리소스 그룹, 가상 네트워크, 서브넷을 순서대로 선택하고 연결합니다.
- 연결하면 Use VNet's private DNS 옵션이 자동으로 켜집니다. 이 옵션을 사용하면 에이전트가 프라이빗 엔드포인트 호스트 이름을 확인할 수 있습니다.
- 프라이빗 엔드포인트 확인이 정상적으로 동작하려면 VNet에 관련 Azure Private DNS 영역을 연결해야 합니다. Log Analytics에는
privatelink.ods.opinsights.azure.com, Key Vault에는privatelink.vaultcore.azure.net영역을 연결하세요. DNS를 구성하지 않으면 에이전트가 공개 엔드포인트로 돌아가거나 연결에 실패할 수 있습니다. - 인프라 네트워크 토글에서 원격 MCP 서버, 패키지 레지스트리, 코드 저장소, 추가 호스트 중 공개 인터넷 경로를 허용할 항목을 선택합니다.
- 저장한 뒤 공개 접근을 차단한 프라이빗 엔드포인트 리소스(예: 공개 접근을 비활성화한 Log Analytics 작업 영역)를 조사하도록 요청해 실제로 VNet 경로로 연결되는지 확인하세요.
VNet을 연결한 뒤에 구성을 바꿀 때는 다음 순서를 지켜야 합니다.
- 송신 모드를 바꾸려면 먼저 VNet 연결을 해제해야 합니다. VNet이 연결되어 있는 동안에는 Unrestricted와 Limited 모드 카드가 비활성화되어 선택할 수 없습니다.
- 서브넷을 바꿀 때도 VNet 연결을 해제한 뒤 새 서브넷으로 다시 연결해야 합니다.
인프라 네트워크 토글은 과도기 수단입니다¶
GitHub는 Azure 서비스가 아니어서 서비스 태그를 제공하지 않고, PyPI와 npm, NuGet, 컨테이너 레지스트리처럼 널리 쓰이는 공개 서비스도 전 세계에 걸친 IP 대역이 자주 바뀝니다. 계층 4 IP 기반 방화벽만으로는 이런 대상의 주소 목록을 최신 상태로 유지하기 어렵고, 목록이 오래되면 에이전트가 필요한 서비스에 도달하지 못합니다. 인프라 네트워크 토글은 이런 대상에 플랫폼 송신 경로로 도달하도록 열어 주는 설정입니다.
다만 이 토글은 호스트 이름이나 FQDN을 인식하는 송신 필터링을 대신하지 않습니다. FQDN 규칙을 지원하는 Azure Firewall Premium이나 TLS 검사를 지원하는 네트워크 가상 어플라이언스로 옮겨 가는 동안 한시적으로 사용하는 과도기 수단으로 다루고, 네트워크 팀이 방화벽 규칙을 갱신하면 열어 둔 범위를 다시 좁히세요.
패키지 레지스트리 대신 미리 설치를 사용할 수 있습니다¶
에이전트가 조사 중에 실행하는 스크립트가 특정 패키지를 필요로 한다면, 패키지 레지스트리 토글을 켜서 인프라 네트워크로 우회하는 대신 샌드박스 기본 이미지에 필요한 패키지를 미리 설치할 수 있습니다. 이렇게 하면 실행할 때마다 패키지가 준비된 상태로 제공되므로 공개 레지스트리로 나가는 경로를 열지 않아도 됩니다.
설정 방법은 다음과 같습니다.
- 에이전트 포털에서 설정 > 작업 영역 구성을 열고 Packages 탭을 선택합니다.
- 패키지 이름을 입력하고 패키지 관리자로
pip또는NuGet을 선택한 뒤 필요하면 버전을 지정합니다. - 패키지 추가를 선택합니다.
NuGet 항목에는 dotnet-ef처럼 .NET CLI 도구만 등록할 수 있으며, 라이브러리 패키지는 전역으로 설치할 수 없습니다.
방화벽에서 허용해야 하는 도메인¶
에이전트 포털과 조사 기능을 사용하려면 사내 방화벽과 프록시에서 다음 도메인을 HTTP와 WebSocket 트래픽 모두에 대해 허용해야 합니다.
| 도메인 | 용도 |
|---|---|
*.azuresre.ai |
에이전트 포털과 API, 실시간 대화(WebSocket) |
sre.azure.com |
에이전트 관리 포털 |
portal.azure.com |
Azure Portal(모니터, 로그, 관리 ID 확인) |
api.applicationinsights.io |
Application Insights 쿼리 API |
api.loganalytics.io, api.loganalytics.azure.com |
Log Analytics 쿼리 API |
*.ods.opinsights.azure.com |
Log Analytics 작업 영역 데이터 수집 |
management.azure.com |
Azure Resource Manager API |
login.microsoftonline.com, *.login.microsoft.com |
Microsoft Entra ID 인증 |
Zscaler를 비롯한 일부 사내 프록시는 *.azuresre.ai를 기본적으로 차단합니다. 포털이 열리지 않거나 대화 화면이 응답하지 않는다면 이 도메인을 허용 목록에 추가하고, 프록시가 WebSocket 연결을 막고 있지 않은지 확인하세요. 브라우저 확장 프로그램의 영향을 배제하려면 시크릿 창에서도 확인해 보세요.
네트워크가 호출을 차단하면 어떻게 되나요?¶
NSG 규칙에 막히거나 경로가 없어 아웃바운드 요청이 거부되면, 에이전트는 같은 서브넷의 다른 워크로드가 받는 것과 똑같은 네트워크 오류를 받습니다. 이때 에이전트는 실패한 사실을 조사 결과에 그대로 남기고(예: Log Analytics 작업 영역에 연결하지 못하고 시간이 초과됐다는 메시지) 접근할 수 있는 도구와 데이터로 조사를 이어 갑니다. 꼭 필요한 데이터 원본에 접근하지 못하면 조사 결과가 완전하지 않다는 사실도 함께 알려 줍니다.
알아두어야 할 제한 사항과 거버넌스¶
- VNet 통합은 아웃바운드 트래픽만 제어하며, 프라이빗 엔드포인트를 통한 인바운드 연결은 이번 미리 보기에서 지원하지 않습니다.
- Azure Policy를 적용해 인프라 네트워크 토글 자체를 제한하거나 비활성화할 수 있어 담당자가 임의로 VNet 밖으로 트래픽을 우회하지 못하도록 통제할 수 있습니다.
- 네트워크 제어 설정을 변경할 수 있는 권한은 SRE Agent Administrator 역할을 가진 사용자로 제한됩니다. 관리 ID, 사용자 위임 자격 증명, Azure RBAC 권한과 함께 네트워크 구성을 묶어서 거버넌스를 설계하세요.
- Key Vault 방화벽 허용은 VNet 통합과 별개의 절차입니다. 인증서 기반 커넥터가 Key Vault에 접근해야 한다면 에이전트 포털의 설정 화면에서 아웃바운드 IP 주소를 확인한 뒤 Key Vault 방화벽의 허용 목록에 각 IP 주소를 개별적으로 추가해야 합니다.
자세한 절차는 다음 자료를 참고하세요.
인시던트 대응 외에 무엇을 자동화할 수 있나요?¶
예약 작업¶
일정에 따라 에이전트가 스스로 점검을 수행하도록 예약할 수 있습니다. 작업 내용은 자연어로 작성하며, 실행할 때마다 조사 대화와 요약 결과가 남습니다. 매일 서비스 상태 점검, 비용 이상 탐지, 보안 구성 점검, 배포 후 확인처럼 경고가 발생하기 전에 문제를 찾는 용도로 사용합니다.
심층 조사¶
영향 범위가 크거나 원인이 여러 개일 수 있는 상황에서는 심층 조사를 사용할 수 있습니다. 가설을 여러 개 세우고 검증 과정을 단계별로 보여주며, 제외한 가설도 함께 정리합니다. 일반 조사보다 토큰 사용량이 많으므로 중요한 인시던트에 선택적으로 사용하는 편이 좋습니다.
팀 지식 온보딩¶
에이전트에 팀 구조, 서비스 아키텍처, 문제 해결 절차를 미리 학습시킬 수 있습니다. 대화형 온보딩을 진행하거나 운영 문서를 업로드하면 이후 조사에서 해당 내용을 근거로 활용합니다.
Agent Hooks¶
Agent Hooks를 사용하면 에이전트가 결과를 반환하기 직전이나 도구 실행 직후에 자체 검증을 추가할 수 있습니다. 위험한 명령을 차단하거나, 결론에 근거가 충분한지 확인해 다시 조사하도록 만들 수 있습니다. 실행 수준이 무엇을 할 수 있는지를 정한다면, Agent Hooks는 어떻게 수행해야 하는지를 정합니다.
도구 용량 관리¶
하나의 에이전트가 사용할 수 있는 도구는 기본 도구와 MCP 도구를 합쳐 최대 80개입니다. 외부 관찰 도구와 사내 시스템을 폭넓게 연결할 계획이라면 도구 수를 미리 설계하세요.
에이전트가 한 일을 어떻게 감사하나요?¶
에이전트의 활동은 조직이 소유한 Application Insights의 customEvents 테이블에 기록됩니다. 모델 호출, 도구 실행, Azure CLI 명령, 승인 결정, 인시던트 처리 결과를 각각 확인할 수 있어 KQL로 조회하고 보고서로 활용할 수 있습니다.
또한 인시던트 지표 화면에서 처리한 인시던트 수, 에이전트가 완화한 비율, 담당자가 처리한 비율, 절감한 시간, 근본 원인 분포를 확인할 수 있습니다. 도입 효과를 정량적으로 설명해야 할 때 활용하기 좋습니다.
이 지표는 왼쪽 사이드바의 Operations Hub 개요 탭에서 한 화면으로 확인할 수 있습니다.
출처: Operations Hub
도입 전에 무엇을 확인해야 하나요?¶
조사 범위¶
- 필요한 구독과 리소스 그룹만 연결하세요.
- Application Insights와 Log Analytics에 필요한 데이터가 들어오는지 확인하세요.
- 실제 배포에 사용한 소스 분기와 운영 절차서를 연결하세요.
인시던트 전달¶
- Azure Monitor, PagerDuty, ServiceNow 중 사용할 인시던트 플랫폼을 정하세요.
- 심각도, 서비스, 제목 기준으로 대응 계획을 만드세요.
- 사용자 정의 대응 계획을 만들었다면 빠른 시작 대응 계획을 삭제하세요.
- 처음에는 검토 모드로 시작하세요.
권한과 안전¶
- 읽기 권한부터 시작하세요.
- 변경 작업은 필요한 리소스 범위에만 허용하세요.
- 삭제와 변경 작업은 승인을 받도록 설정하세요.
- 커넥터에는 필요한 작업만 노출하세요.
- 메일 수신자와 프로젝트 키처럼 중요한 값은 고정하세요.
조사 품질¶
- 영향을 받은 서비스와 발생 시각이 정확한지 확인하세요.
- 결론에 근거가 포함되어 있는지 확인하세요.
- 확인하지 못한 내용과 불확실성을 표시하는지 확인하세요.
- 조치 방안이 최소 범위이며 되돌릴 수 있는지 확인하세요.
- 올바른 서비스와 API에서 복구를 확인하는지 확인하세요.
알아두어야 할 제한 사항¶
- AI가 잘못된 결론이나 적절하지 않은 조치 방안을 제시할 수 있습니다.
- 연결한 소스가 실제 배포 분기와 다르면 코드 변경을 정확히 찾지 못할 수 있습니다.
- 여러 서비스가 같은 원격 분석 이름을 사용하면 서로 다른 데이터를 혼동할 수 있습니다.
- 외부 커넥터는 연결을 설정한 사용자의 권한으로 동작할 수 있습니다.
- 자율 모드에서는 일부 승인 절차가 생략될 수 있습니다.
- 지역과 테넌트에 따라 사용할 수 있는 기능이 다를 수 있습니다.
따라서 충분한 근거, 최소 권한, 검토 모드 우선 적용, 실제 복구 확인을 운영 원칙으로 삼는 것이 좋습니다.
참고 자료¶
제품 개요와 조사 방식¶
- Azure SRE Agent 개요
- 인시던트 대응 설정
- 인시던트 대응 계획
- 인시던트 플랫폼
- 근본 원인 분석
- Azure 관찰 가능성으로 진단하기
- 조치 실행하기
- 실행 모드
- 심층 조사
- 팀 온보딩
- 사용자 지정 에이전트
- 스킬
도입과 운영¶
보안과 확장¶
- 보안 개요
- 권한
- 네트워크 통합
- 네트워크 제어 구성
- 네트워크 요구 사항
- Key Vault 방화벽 허용 목록 구성
- 데이터 보존과 개인 정보
- Agent Hooks
- 커넥터
- 관리형 커넥터(미리 보기)
- MCP 커넥터