새벽 2시, 결제가 안 된다는 알림이 울립니다. 담당자는 노트북을 열고 대시보드, 로그, 트레이스를 차례로 뒤집니다. 원인을 찾는 데 40분, 고치는 데 10분. 그 50분 동안 빠져나간 매출과 고객 신뢰는 다시 돌아오지 않습니다.

서비스가 커질수록 이런 밤은 늘어납니다. 그런데 운영팀은 서비스만큼 빨리 늘지 않습니다. 리더가 고를 수 있는 길은 보통 두 가지입니다. 사람을 더 뽑거나, 일하는 방식을 바꾸거나. 최근 LLM 기반 AIOps가 자주 거론되는 건 두 번째 길에 대한 꽤 구체적인 답을 내놓고 있기 때문입니다.

이 글은 클라우드네이티브TV의 발표 「LLM AIOps ① 개념과 기능」을 보며, 운영을 책임지는 리더 입장에서 짚어볼 만한 부분을 정리한 것입니다.

운영팀이 지치는 진짜 이유는 '손'이 아니라 '머리'

구글의 SRE(사이트 신뢰성 엔지니어링)에서는 반복적이고, 손으로 해야 하고, 서비스가 커질수록 같이 늘어나는 일을 '토일(Toil)'이라고 부릅니다. 지난 10년 동안 운영 자동화는 대부분 이 토일을 줄이는 데 집중했습니다. 배포 자동화, 오토스케일링, 알림 자동화가 그 결과물입니다.

그런데 손이 덜 바빠졌는데도 운영팀은 여전히 지쳐 있습니다. 발표자는 그 이유를 '인지부하'에서 찾습니다. 마이크로서비스, 쿠버네티스, 멀티 클라우드로 시스템 계층이 늘어나면서, 장애 하나를 이해하기 위해 알아야 할 범위가 너무 넓어졌다는 겁니다. 이제 자동화가 덜어줘야 할 건 손이 아니라 머리, 즉 판단의 부담이라는 주장입니다.

기존 AIOps와 무엇이 다른가

AIOps라는 말 자체는 새롭지 않습니다. 가트너가 2016년에 처음 제시한 개념이고, 많은 모니터링 도구가 이미 이상 탐지 기능을 갖고 있습니다. 문제는 대부분 "이상이 있다"까지만 알려준다는 점입니다. 왜 그런지, 무엇을 해야 하는지는 여전히 사람이 찾아야 합니다.

LLM 기반 AIOps는 여기에 언어 이해 능력을 더합니다. 운영자가 사람에게 묻듯 질문하면, AI가 로그(오류·이벤트), 트레이스(서비스 호출·지연), 메트릭(CPU·메모리·트래픽)을 한꺼번에 보고 원인을 지목한 뒤 조치까지 제안합니다.

발표에 나온 예시가 이해를 돕습니다. "어젯밤 10시부터 쇼핑몰이 느려진 원인이 뭐야?"라고 물으면, 마케팅 이벤트로 사용자가 평소의 5배 몰렸고, 그 여파로 DB의 특정 테이블에서 잠금 경합이 생겼다는 답과 함께 문제가 된 SQL이 나옵니다. "어제 주문 실패 원인"을 물으면 실패 1,570건 중 95%가 재고 부족 처리 과정에서 나왔고, 특정 상품의 재고 연동 구간이 의심된다는 식으로 범위를 좁혀줍니다.

실제로 바뀌는 업무 세 가지

첫째, 보고. 장애가 끝나면 늘 남는 일이 경위서입니다. "대표님 보고용으로 정리해줘"라고 하면 AI가 원인, 영향 범위, 조치 내역을 보고서 형태로 만들어줍니다. 장애 대응보다 보고서 작성이 더 오래 걸리던 경험이 있다면 체감이 클 부분입니다.

둘째, 예측. "3시간 뒤 메모리가 임계치를 넘을 확률 85%", "5일 뒤 DB 서버 CPU가 90%를 넘을 가능성이 높고, 현재 32GB 메모리로는 부족하다" 같은 알림을 받게 됩니다. 장애가 난 뒤에 움직이던 팀이, 장애가 나기 전에 증설을 결정하는 팀으로 바뀌는 지점입니다.

셋째, 반복 작업. 스레드 덤프 분석 스크립트를 짜거나, 로그를 정리하는 예약 작업을 만드는 일을 AI가 대신 작성합니다. 발표에서는 이런 작업을 관리자가 승인한 뒤 실행하는 방식으로 설명합니다. AI가 마음대로 시스템을 건드리는 구조가 아니라는 점은 리더 입장에서 중요한 대목입니다.

숫자는 어떻게 읽어야 할까

발표에서 제시한 기대 효과는 장애 해결 시간(MTTR) 30~50% 단축입니다. 관리자 한 명이 맡을 수 있는 시스템 규모가 2배 이상 늘 수 있다는 설명도 나옵니다.

다만 이 숫자는 어디까지나 기대 효과입니다. 로그와 지표가 얼마나 잘 쌓여 있는지, 시스템 구성이 얼마나 정리돼 있는지에 따라 결과는 크게 달라집니다. 데이터가 흩어져 있는 조직이라면 AI보다 데이터 정리가 먼저입니다.

오히려 숫자보다 눈여겨볼 효과는 '지식이 쌓이는 방식'입니다. 많은 팀에서 장애 대응 노하우는 특정 고참의 머릿속에 있습니다. 그 사람이 휴가를 가거나 회사를 떠나면 대응 품질이 같이 떨어집니다. AI가 장애 이력과 대응 과정을 학습하고 다음 장애에 활용하는 구조라면, 노하우가 사람이 아니라 시스템에 남습니다. 작은 팀일수록 이 차이가 큽니다.

도입을 검토한다면 먼저 물어볼 네 가지

1. 로그·트레이스·메트릭이 한 곳에서 보이는가. AI가 묶어서 볼 데이터가 없으면 아무것도 묶을 수 없습니다.
2. AI가 제안한 조치를 누가 승인하는가. 자동화 범위와 승인 절차를 먼저 정해야 사고가 나지 않습니다.
3. 반복되는 장애 목록이 있는가. 자주 반복되는 장애가 자동화의 첫 번째 후보입니다.
4. 보안과 권한은 어떻게 관리하는가. AI가 시스템에 접근하는 만큼, 비정상 접근이나 정책 위반을 감시하는 장치가 함께 있어야 합니다.

운영자는 보병에서 지휘관으로

발표자는 이 변화를 "보병에서 지휘관으로"라는 말로 정리합니다. 로그를 한 줄씩 읽던 사람이, AI가 정리한 상황을 보고 무엇을 먼저 할지 정하는 사람이 된다는 뜻입니다.

결국 리더가 던져야 할 질문은 "AI가 운영자를 대체하는가"가 아니라 "우리 운영자의 시간을 어디에 쓰게 할 것인가"일지도 모릅니다. 장애를 쫓는 데 쓰던 시간을, 장애가 나지 않는 구조를 만드는 데 쓸 수 있다면 그것만으로도 충분히 검토해 볼 만한 변화입니다.

이 글은 아래 발표와 원문을 바탕으로 정리했습니다. 기능별 상세 설명과 데모는 원문과 영상에서 볼 수 있습니다.

원문: AIOps 기능 활용 — 운영자가 장애 원인을 빠르게 찾는 기준
영상: LLM AIOps ① 개념과 기능 (36분)
채널: 클라우드네이티브TV 구독하기