1. 무엇을 배포하나요¶

리소스	용도
SRE Agent	Managed Identity · Knowledge Base · Custom Agent 를 갖춘 AI 에이전트
Grubify 앱	샘플 음식 주문 앱 (API + Frontend, Azure Container Apps)
Log Analytics + App Insights	로그 저장 및 모니터링
Azure Monitor 경고	HTTP 5xx 경고 → 에이전트 조사 자동 트리거
Container Registry (ACR)	Grubify 컨테이너 이미지 빌드/저장
Managed Identity	에이전트가 Azure 를 조작할 때 쓰는 ID (권한은 아래 표 참고)

권한 구조 — 조사와 조치의 경계¶

에이전트가 무엇을 할 수 있는지는 서로 다른 두 가지가 결정합니다. 이 둘을 하나로 보면 오해가 생깁니다.

	어디서 보나	무엇을 뜻하나
① Agent permissions level	포털 Settings ▸ Basics	에이전트를 만들 때 고르는 권한 프로필 — Reader(기본값) / Privileged
② 관리 ID 의 Azure RBAC	관리 ID 의 역할 할당	Azure 가 실제로 허용·거부하는 경계. ARM 은 이것만 보고 판정합니다

포털에서 에이전트를 만들면 ①을 고르는 순간 ②가 그에 맞게 채워지므로 보통 둘이 일치합니다. 이 Lab 은 일치하지 않습니다 — 의도적으로 그렇게 구성했습니다.

이 Lab 의 실제 구성¶

항목	값
Agent permissions level	Reader — 기본값 그대로 (`actionConfiguration.accessLevel: Low`)
Agent mode	Autonomous
관리 ID 의 역할	Reader · Monitoring Reader · Log Analytics Reader · Monitoring Contributor · Container Apps Contributor

infra/modules/subscription-rbac.bicep 이 위 5개 역할을 구독 범위로, 권한 수준과 무관하게 항상 부여합니다. 마지막 Container Apps Contributor 가 쓰기 역할입니다.

제품 기본값과 이 Lab 의 차이¶

무인 완화가 가능했던 것은 제품이 원래 그렇게 동작해서가 아니라, 이 Lab 이 기본값 두 개를 바꿨기 때문입니다.

항목	제품 기본값	이 Lab	무엇이 달라지나
Agent mode	Review — 조치 전 사람 승인	Autonomous	승인 대기 없이 실행
관리 ID 의 쓰기 역할	없음 (Reader 선택 시)	`Container Apps Contributor`	ARM 쓰기 요청이 통과

둘 중 하나만 빠져도 무인 완화는 일어나지 않습니다. 기본 상태의 SRE Agent 는 조사를 마친 뒤 사람의 승인을 기다립니다.

그래서 포털에 Reader 로 표시되어도 에이전트는 컨테이너를 재시작하고 메모리를 확장할 수 있습니다. ARM 은 권한 수준 표시가 아니라 요청 주체가 그 작업에 대한 역할을 갖고 있는지만 판정하기 때문입니다. 실제로 그렇게 동작한 기록은 6.3 — 조치를 실행한 주체에서 활동 로그로 확인할 수 있습니다.

이 Lab 에서 가장 중요한 보안 관점의 교훈이 여기 있습니다 — 포털의 권한 수준 표시만 보고 "이 에이전트는 읽기 전용이겠거니" 판단하면 안 되고, 관리 ID 에 실제로 붙어 있는 역할 할당을 함께 확인해야 합니다.

단계별로 — 무엇이 권한을 필요로 하나¶

인시던트 처리 단계	필요한 역할	이 Lab
경고 수신 · Acknowledge	`Monitoring Contributor`	✅
Knowledge Base(런북·아키텍처) 검색	없음	✅
메트릭 · KQL 로그 질의	`Monitoring Reader` · `Log Analytics Reader`	✅
리비전 · 배포 이력 · 리소스 구성 조회	`Reader`	✅
소스 코드에서 `파일:라인` 근본 원인 특정	없음 (GitHub 연동 필요)	연동 시
차트 생성 · 인시던트 리포트 작성 · Team Memory 저장	없음	✅
Azure Monitor 경고 종료(Close)	`Monitoring Contributor`	✅
컨테이너 재시작 · 스케일 · 설정 변경	`Container Apps Contributor`	✅

조사에 해당하는 항목에는 쓰기 역할이 하나도 필요하지 않습니다. 쓰기 역할이 없으면 마지막 줄만 막히고, 그때 에이전트는 조사를 끝낸 뒤 Approve action(OBO) 승인 요청을 띄우고 대기합니다. 승인하면 승인한 사람의 자격 증명으로 실행되며, 자격 증명은 저장되지 않고 작업 후 다시 관리 ID 로 돌아갑니다. 승인은 SRE Agent Administrator 역할을 가진 직장/학교 계정만 가능합니다.

즉 쓰기 역할 없이 운영하면 "진단은 완전 자동, 실행은 사람이 버튼 한 번" 모델이 되고, 쓰기 역할을 부여하면 이 Lab 처럼 "진단부터 완화까지 무인" 모델이 됩니다.

쓰기 권한 없이 운영하려면 (선택)¶

OBO 승인 흐름을 확인하고 싶거나 쓰기 권한을 부여할 수 없는 환경이라면 Container Apps Contributor 만 제거하면 됩니다.

# 배포 후 해당 역할만 회수 → Reader 상당으로 전환
PRINCIPAL_ID=$(az identity show -g rg-sre-lab \
  --name "$(az identity list -g rg-sre-lab --query '[0].name' -o tsv)" \
  --query principalId -o tsv)

az role assignment delete --assignee "$PRINCIPAL_ID" \
  --role "Container Apps Contributor" \
  --scope "/subscriptions/$(az account show --query id -o tsv)"

이 상태로 break-app.sh 를 실행하면 에이전트가 조사를 마친 뒤 완화 단계에서 승인 프롬프트를 띄우고 대기합니다.

🔐 운영 환경 권장: 구독 범위 부여를 피하고 대상 리소스 그룹 범위로만 필요한 역할을 주세요. 또한 신규 Response Plan 은 Review 모드로 시작해 동작을 검증한 뒤 Autonomous 로 전환하는 것이 안전합니다. 전체 권한 모델(계층 · 실행 모드 매트릭스 · OBO)은 SRE_Agent.md — 권한 모델 참고.

SRE Agent 구성 요소¶

구성 요소	내용
Knowledge Base	HTTP 오류 런북, 앱 아키텍처 문서, 인시던트 리포트 템플릿, 이슈 분류 기준
incident-handler	로그 · KQL · 런북 기반 조사 (도구 19종)
code-analyzer	위 기능 + 소스 코드 검색, GitHub 이슈 생성 (GitHub 연동 시)
issue-triager	고객 이슈 분류 · 라벨 · 코멘트 (GitHub 연동 시)
Response Plan	`grubify-http-errors` — Sev0~Sev4 경고를 `incident-handler` 로 Autonomous 라우팅
Scheduled Task	12시간마다 이슈 트리아지 (GitHub 연동 시)
Global Tools	DevOps + Python plotting 활성화