장애 대응의 첫 30분
장애 알림이 오면 처음 30분은 대개 비슷하게 흘러갑니다.
대시보드를 엽니다. 어느 지표가 튀었는지 봅니다. 로그를 검색합니다. 최근 배포가 있었는지 확인합니다. 그리고 슬랙에 "확인 중입니다"라고 씁니다.
이 과정은 판단보다 수집에 가깝습니다. 여러 도구를 오가며 단서를 모으는 일이죠. AWS DevOps Agent가 겨냥한 곳이 바로 여기입니다. AWS는 이 에이전트를 "항상 켜져 있는 자율 온콜 엔지니어"라고 소개했습니다.
Agent Space: 무엇을 볼 수 있는가
글에서 먼저 이해해야 할 개념은 Agent Space입니다. 에이전트가 일하면서 접근할 수 있는 범위를 정하는 단위입니다.
애플리케이션 하나에 하나를 만들 수도 있고, 여러 서비스를 맡은 온콜 팀 단위로 만들 수도 있습니다. Agent Space를 만들면 에이전트가 계정 안팎의 리소스를 들여다볼 IAM 역할도 함께 생깁니다.
에이전트는 이 범위 안에서 애플리케이션 토폴로지를 그립니다. 구성 요소와 그 사이의 호출 관계를 지도로 만드는 거죠. 토폴로지 탭에는 볼 수 있는 모든 것이 아니라, 에이전트가 중요하다고 판단한 리소스만 보입니다.
어떤 도구와 엮이나
연동 목록이 꽤 깁니다.
| 영역 | 연동 대상 |
|---|---|
| 관측 | CloudWatch, Datadog, Dynatrace, New Relic, Splunk |
| 배포 | GitHub Actions, GitLab CI/CD, GitHub 코드 변경 |
| 추적 | AWS X-Ray |
| 장애 관리 | ServiceNow 기본 지원, PagerDuty는 웹훅 |
| 소통 | Slack |
| 확장 | 직접 붙이는 MCP 서버(Grafana, Prometheus 등) |
AWS 바깥 관측 도구를 처음부터 넣었다는 점이 눈에 띕니다. 실제 운영 환경은 대부분 여러 도구가 섞여 있으니까요.
조사는 어떻게 시작되나
두 가지 방법이 있습니다. 웹 앱에서 "최근 경보", "CPU 급증", "오류율 급증" 같은 시작점을 골라 직접 시작하거나, 장애 관리 시스템의 알림이 자동으로 조사를 시작하게 할 수 있습니다.
글의 데모가 구체적입니다. 에이전트가 CloudWatch 지표와 로그를 엮고, 최근 코드 변경을 훑은 뒤 원인을 찾아냅니다. 원인은 의도적으로 오류를 던지는 Lambda 함수를 누군가 수동으로 호출한 것이었습니다.
조사 중에 채팅으로 추가 질문을 하거나 방향을 틀 수 있다는 점도 중요합니다. 에이전트가 엉뚱한 곳을 파고 있으면 사람이 바로잡을 수 있습니다.
고치는 것까지 맡기나
여기서 선이 그어집니다. 에이전트는 완화 방안을 제안합니다. 직접 고치지는 않습니다.
장애가 진행 중일 때는 즉시 쓸 수 있는 완화 계획을 내놓습니다. 지나간 장애들을 분석해서는 관측, 인프라, 배포 파이프라인의 장기 개선점을 권합니다. 다중 가용 영역 배포나 모니터링 공백 같은 항목입니다.
솔직한 문장도 하나 있었습니다. 글쓴이는 단순한 데모 환경에서는 쓸 만한 권고가 나오지 않았다고 적었습니다. 장기 권고는 장애 이력이 쌓여야 의미가 생긴다는 뜻으로 읽힙니다.
맡길 수 있는 것과 없는 것
발표 내용을 기준으로 나눠 보면 이렇습니다.
- 맡길 만한 것: 단서 수집, 지표·로그·배포 이력의 시간 맞추기, 이해관계자에게 진행 상황 알리기
- 사람이 해야 할 것: 완화 조치의 실행 결정, 고객 영향 판단, 원인 분석 결과의 검증
새벽 3시에 깬 온콜 엔지니어가 노트북을 열었을 때, 이미 "최근 배포 이후 이 함수의 오류율이 올랐다"는 요약이 기다리고 있다면 첫 30분이 10분으로 줄 수 있습니다. 그 정도만 돼도 충분히 가치가 있습니다.
그 뒤의 소식
발표 당시에는 us-east-1에서 프리뷰로 시작했고, 다른 리전과 여러 계정의 애플리케이션도 감시할 수 있었습니다. 프리뷰 동안은 무료였지만 월간 에이전트 작업 시간에 한도가 있었습니다.
같은 글의 갱신 문구에 따르면 2026년 3월 31일 정식 출시됐고, 신규 고객에게 2개월 무료 체험을 줍니다. 써 보려면 Agent Space를 작게, 서비스 하나 단위로 시작하는 편이 권한 범위를 관리하기에 안전해 보입니다.
