AI가 온콜을 돕게 하려면 먼저 경계를 설계해야 한다

10분 읽기·2026.06.20·출처 6개·00

오늘의 질문

AI SRE 에이전트가 로그와 인프라를 읽어도 되는 범위, 실행해도 되는 행동, 사람이 승인해야 하는 지점은 어디까지일까?

infra-dev.md

SURVIVE.exe

AI가 온콜을 돕게 하려면 먼저 경계를 설계해야 한다

카테고리: infra_dev
예상 읽기 시간: 10분
오늘의 질문: AI SRE 에이전트가 로그와 인프라를 읽어도 되는 범위, 실행해도 되는 행동, 사람이 승인해야 하는 지점은 어디까지일까?
핵심 출처:
- AWS DevOps Agent is now generally available - 2026-03-31, 확인일 2026-06-20
- Production-Ready Autonomous Incident Resolution with AWS DevOps Agent (GA) and Datadog MCP Server - 2026년 게시, 확인일 2026-06-20
- What are DevOps Agent Spaces? - 현행 문서, 확인일 2026-06-20
- Limiting Agent Access in an AWS Account - 현행 문서, 확인일 2026-06-20
- Datadog MCP Server - 현행 문서, 확인일 2026-06-20

1. 왜 지금 봐야 하나

운영 자동화의 분위기가 바뀌고 있다. 예전의 자동화는 “알람이 오면 특정 스크립트를 실행한다”에 가까웠다. 지금의 흐름은 더 넓다. AI 에이전트가 알람을 읽고, 로그·메트릭·트레이스를 뒤지고, 최근 배포와 설정 변경을 연결하고, 원인 후보와 완화 계획을 제안한다.

AWS는 2026년 3월 AWS DevOps Agent 일반 제공(GA)을 공지하면서, 이 도구가 AWS뿐 아니라 multicloud와 on-prem 환경까지 incident triage, investigation, prevention을 돕는 운영 동료 역할을 한다고 설명했다. 이어 AWS DevOps & Developer Productivity Blog는 Datadog MCP Server와의 통합을 통해 Datadog의 로그, 메트릭, 트레이스, 최근 배포 이벤트를 AWS DevOps Agent 조사 흐름에 연결할 수 있다고 소개했다. Datadog 쪽 문서도 MCP Server가 Cursor, Codex, Claude Code, 자체 AI agent 같은 MCP 지원 클라이언트에 Datadog 관측 데이터를 구조적으로 제공한다고 설명한다.

이 글의 목적은 “AI가 장애를 해결해준다”는 기대를 키우는 것이 아니다. 오늘 가져갈 핵심은 반대에 가깝다.

AI 온콜 자동화는 모델 성능보다 먼저 접근 경계, 권한 경계, 감사 경계, 승인 경계를 설계해야 운영 기능이 된다.

AI가 운영 데이터를 더 잘 읽게 만들수록, 잘못 읽었을 때의 피해 범위도 커진다. 그래서 incident response에 AI를 붙일 때는 “무엇을 할 수 있나”보다 “어디까지 못 하게 할 것인가”를 먼저 정해야 한다.

2. 핵심 개념

오늘의 핵심 개념은 운영 에이전트의 blast radius다.

운영 에이전트는 일반 챗봇과 다르다. 코드베이스 문서만 읽는 것이 아니라 실제 운영 환경의 로그, 메트릭, 알람, 배포 기록, 인프라 설정, 때로는 티켓과 채팅 기록까지 연결한다. 이때 blast radius는 에이전트가 잘못된 결론을 내리거나 과도한 도구 호출을 했을 때 영향을 줄 수 있는 범위다.

AWS DevOps Agent 문서는 이 범위를 Agent Space라는 단위로 나눈다. Agent Space는 에이전트가 접근할 수 있는 도구와 인프라를 정의하는 논리적 컨테이너다. 각 Agent Space는 AWS 계정 접근, 외부 도구 통합, 사용자 권한, 조사 데이터와 채팅 기록을 독립적으로 가진다. 문서는 production과 non-production 환경을 분리하거나, 팀·서비스·컴플라이언스 요구에 따라 여러 Agent Space를 만들라고 권장한다.

두 번째 경계는 IAM과 permission guardrail이다. AWS 문서에 따르면 DevOps Agent는 incident investigation과 preventative evaluation 중 AWS 리소스를 discover/describe하기 위해 IAM role을 사용한다. 중요한 문장은 이것이다. 애플리케이션 topology 화면이 에이전트가 접근 가능한 모든 것을 보여주는 것은 아니며, 실제 제한은 IAM policy로 해야 한다. 또한 DevOps Agent는 assume-role 시 session policy 형태의 guardrail을 적용하고, 유효 권한은 “사용자가 붙인 IAM role policy”와 “AWS DevOps Agent guardrail”의 교집합이 된다. 즉 role에 더 큰 권한을 붙여도 guardrail 밖의 destructive action은 사용할 수 없도록 설계되어 있다.

세 번째 경계는 관측 데이터 MCP 경계다. Datadog MCP Server는 AI agent가 Datadog의 APM, logs, metrics, monitors, dashboards, security signals 등에 구조적으로 접근하게 해준다. 동시에 문서는 fair-use limit, Audit Trail, MCP tool usage metric, OAuth 기반 인증, site별 지원 제한, usage data retention 같은 운영 조건도 함께 제시한다. MCP는 “AI가 편하게 부르는 API”가 아니라 감사와 제한을 붙여야 하는 운영 인터페이스다.

3. 최신 이슈와 연결

AWS의 GA 공지와 블로그에서 눈에 띄는 변화는 incident response가 세 단계로 확장된다는 점이다.

탐지 후 조사: CloudWatch, Datadog 같은 신호를 보고 어떤 리소스와 배포 변경이 관련 있는지 찾는다.
완화 계획 제안: rollback, capacity 조정, retry/circuit breaker 추가 같은 구체적 action plan을 만든다.
재발 방지 추천: 반복 장애 패턴을 보고 장기 개선 작업을 추천한다.

여기서 작은 팀이 조심해야 할 것은 “추천”과 “실행”을 섞는 순간이다. 예를 들어 에이전트가 “최근 배포가 원인일 가능성이 높으니 rollback하라”고 말하는 것은 조사 결과다. 그런데 에이전트가 배포 시스템에 직접 rollback 명령을 내리거나, IAM·네트워크·DB 설정을 바꿀 수 있다면 위험 등급이 달라진다.

Datadog MCP Server 문서도 비슷한 신호를 준다. MCP Server는 Audit Trail에 tool call을 남기고, 'datadog.mcp.session.starts', 'datadog.mcp.tool.usage' 같은 metric을 제공한다. toolset을 제한할 수도 있다. 이것은 AI 도구 연결의 핵심 운영 포인트다. AI가 어떤 정보를 읽었고, 어떤 tool을 호출했고, 누가 어떤 client에서 사용했는지 나중에 설명할 수 있어야 incident response 도구로 받아들일 수 있다.

최신 흐름을 한 문장으로 줄이면 이렇다.

AI incident response의 경쟁력은 “더 똑똑한 답변”이 아니라 “운영 데이터에 안전하게 접근하고, 행동을 통제하고, 감사 가능한 흔적을 남기는 방식”에서 나온다.

4. 개발자 관점 해석

개발자와 작은 팀은 이 흐름을 도입할 때 세 가지 착각을 피해야 한다.

첫째, read-only면 항상 안전하다는 착각이다. 읽기 권한만 있어도 민감한 로그, 고객 식별자, 내부 URL, secret-like string, 배포 토큰 흔적이 노출될 수 있다. Datadog MCP Server 문서는 원격 MCP 사용 과정에서 user prompt 같은 context leading to MCP tool usage가 수집될 수 있고 120일 보관된다고 설명한다. 따라서 운영 로그에 PII나 secret이 섞여 있다면 AI 연결 이전에 로그 위생부터 봐야 한다.

둘째, 하나의 에이전트가 모든 환경을 보면 효율적이라는 착각이다. 운영자는 production, staging, sandbox를 다르게 다뤄야 한다. Agent Space 문서가 environment isolation과 service boundary를 강조하는 이유가 여기에 있다. “같은 질문을 어디에 던졌는지”가 결과의 위험도를 바꾼다. staging 장애 조사에는 넓은 실험 권한을 줄 수 있지만 production 조사에는 읽기 중심, 승인 중심으로 좁혀야 한다.

셋째, 도구 호출 로그가 있으면 감사가 끝났다는 착각이다. 감사 로그는 사후 증거일 뿐이다. 실제로 필요한 것은 사전 정책이다. 예를 들어 “P0 incident에서는 에이전트가 recent deployment, error logs, trace latency, alarm history를 읽을 수 있다. 하지만 rollback, feature flag 변경, DB failover, queue purge는 사람 승인 없이는 실행하지 않는다” 같은 규칙이 있어야 한다.

인프라 개발자에게 이 주제는 AI가 아니라 운영 설계 문제다. 에이전트를 붙이는 순간, 기존의 관측성·권한·사고 대응 프로세스가 더 선명해져야 한다.

5. 내 프로젝트에 적용할 체크포인트

작은 팀이 당장 점검할 체크리스트는 다음과 같다.

Agent Space 또는 equivalent boundary를 정의했는가? production, staging, demo, 고객별 환경을 같은 AI 작업 공간에 섞지 않는다.
읽기 권한의 범위를 문서화했는가? CloudWatch/Datadog/GitHub/Jira/Slack 중 어떤 데이터를 읽을 수 있는지 적는다.
write action을 기본 차단했는가? rollback, scale-out, secret rotation, DB promotion, queue purge, firewall 변경은 승인 단계로 둔다.
toolset을 최소화했는가? Datadog MCP Server를 쓴다면 모든 toolset을 켜기보다 incident 조사에 필요한 logs, apm, metrics, monitors부터 시작한다.
감사 로그를 보는 대시보드가 있는가? MCP tool call 수, 사용자별 사용량, 실패율, 비정상 burst를 확인한다.
민감정보 로그 정책이 있는가? AI에 연결하기 전에 로그 redaction, token masking, PII field 차단을 점검한다.
사람 승인 기준이 명확한가? 에이전트가 “제안”할 수 있는 것과 “실행”할 수 있는 것을 runbook에 분리한다.
비용과 rate limit을 봤는가? Datadog MCP Server의 fair-use limit처럼 AI 조사 도구도 무제한이 아니다. 장애 중 tool call 폭주가 생길 수 있다.

6. 오늘 10분 액션

오늘은 새 도구를 붙이기보다 종이에 경계를 그려보자.

최근 장애 하나를 고른다.
사람이 조사할 때 열었던 화면을 나열한다. 예: logs, metrics, traces, deploy history, feature flags, DB dashboard, Slack thread.
각 화면 옆에 'AI 읽기 허용', 'AI 요약 허용', 'AI 실행 금지', '사람 승인 후 실행' 중 하나를 적는다.
production과 staging에서 규칙이 달라지는 항목을 표시한다.
마지막으로 “이 에이전트가 잘못 판단했을 때 최악의 피해는 무엇인가?”를 한 문장으로 쓴다.

이 10분 액션의 결과물이 바로 AI 온콜 도입의 첫 번째 정책 초안이다. 도구 연결은 그다음이다.

7. 더 볼 자료

중복 회피 메모

로컬 'content/generated'와 Supabase 최근 'infra_dev' 글을 확인했다. 최근 글은 EventBridge event bus logging, Lambda durable functions, GitHub Actions 제어면 장애, Cloudflare Queues backlog/DLQ, PostgreSQL 관측 지표, Docker 보안, GKE standby buffer, OpenTelemetry Collector 운영, Cloud Run worker backpressure, OIDC 기반 secret 축소를 다뤘다. 이번 글은 큐·재시도·CI 장애·일반 관측 파이프라인을 반복하지 않고, AWS DevOps Agent GA와 Datadog MCP Server를 계기로 AI incident response 에이전트의 접근 경계, 권한 guardrail, MCP 감사 로그, 사람 승인 정책을 설계하는 관점에 집중한다.

오늘 10분 액션+5%