클라우드 나침반

AIOps는 모니터링 엔지니어의 일을 없애지 않는다. 오히려 더 많은 판단을 요구한다. "AI가 알아서 고쳐 주는 시스템"을 기대했다가 오탐(False Positive) 폭탄을 맞은 팀이 적지 않다. 기본 지표와 로그가 부실한 상태에서 AIOps를 얹으면 잘못된 판단이 더 빠르게 확산될 뿐이다. 이 글은 AIOps를 어떤 맥락에서 받아들여야 하는지, 운영자 관점에서 정리한다.요약AIOps는 모니터링을 없애는 기술이 아니라, 모니터링과 Observability 데이터를 해석하고 운영 흐름으로 연결하는 계층에 가깝습니다. 장애 징후를 더 빨리 묶고, 원인 후보를 좁히고, 반복 대응을 자동화하는 데는 도움이 되지만 기본적인 지표, 로그, 트레이스, 알림 기준이 부실하면 오히려 잘못된 판단을 빠르게 확산시킬 수..

요약Agentic AI를 운영 환경에 붙일 때 가장 먼저 준비해야 할 것은 모델 선택이 아니라 관측 가능성, 즉 Observability 기준이다. Agent는 단순히 답변을 생성하는 것을 넘어 도구를 호출하고, 외부 시스템을 조회하고, 여러 단계의 판단을 거쳐 결과를 만든다.그래서 운영자는 "정답이 나왔는가"만 볼 수 없다. 어떤 사용자 요청에서 시작됐고, 어떤 Agent 버전이 동작했고, 어떤 도구를 어떤 권한으로 호출했으며, 실패했을 때 어느 단계가 원인이었는지를 추적할 수 있어야 한다.이 글을 읽으면 좋은 사람클라우드 운영, DevOps, SRE, 플랫폼 엔지니어링, LLMOps 업무에서 Agentic AI 도입을 검토하는 분들을 위한 글이다.특히 AWS Bedrock Agent, Bedrock ..

알람 이후의 탐색, 판단, 승인 흐름을 AI Agent로 줄이는 방법"장애 대응 자동화의 목표는 사람을 없애는 것이 아니라, 사람이 판단해야 할 순간까지 더 빨리 도착하게 만드는 것이다." 1. 장애 대응에서 가장 오래 걸리는 일1.1 알람은 빠르지만 판단은 느리다운영 환경에서 알람은 이미 충분히 빠르다. CloudWatch Alarm, Prometheus Alertmanager, Datadog, Slack 알림까지 붙어 있으면 문제 발생 자체는 금방 알 수 있다.그런데 실제 장애 대응에서 시간이 오래 걸리는 부분은 알람 수신이 아니다. 알람 이후에 "무엇을 먼저 봐야 하는가"를 판단하는 과정이다.1.1.1 운영자가 동시에 확인하는 정보예를 들어 API 지연 시간이 갑자기 증가하면 운영자는 보통 다음 정..