Blog,미분류

AIOps(Artificial Intelligence for IT Operations, 인공지능을 활용한 IT 운영)는 2016년 가트너(Gartner)가 제창한 개념입니다. 인공지능을 서비스 운영에 활용하는 대처를 묶어 부르는 말이고, 대량 데이터와 기계 학습, 고급 분석으로 모니터링·자동화·서비스 데스크를 강화하는 것이 목표입니다.

AIOps가 운영 조직에 주는 통찰력은 크게 세 가지로 정리됩니다.

• 이상 탐지 — 평소와 다른 징후를 자동으로 포착합니다.
• 근본 원인 분석 — 쏟아지는 알람 속에서 진짜 원인을 지목합니다.
• 장애 예측 — 위험 신호를 미리 경고해 사전 대응을 가능하게 합니다.

쏟아지는 알람에서 이상 징후와 원인을 찾아 장애를 미리 막는 것, 이것이 AIOps가 겨냥한 자리입니다.

자동화가 끝나지 않은 자리 — 토일(Toil)

서비스 운영에는 여전히 사람이 직접 처리하는 반복적이고 번거로운 작업이 남아 있습니다. 사이트 신뢰성 공학(SRE, Site Reliability Engineering)에서는 이런 작업을 토일(Toil)이라고 부릅니다. 수작업으로 반복되며 자동화가 가능한 업무를 뜻하고, 세 가지 특징이 있습니다.

• 그때그때 급히 처리하고 끝나는 일입니다.
• 해도 남는 것이 없습니다. 개선으로 쌓이지 않습니다.
• 서비스가 커지면 일도 그만큼 늘어납니다.

복잡한 맥락이 만드는 인지부하

인지부하(Cognitive Load)는 한 번에 너무 많은 정보를 처리하거나 복잡한 작업을 할 때 사람이 느끼는 뇌의 부담을 말합니다. 연도가 지날수록 개발·운영 담당자가 다뤄야 하는 도구와 책임 범위가 함께 늘어나면서 이 부담이 급격히 커졌습니다.

여기가 갈림길입니다. 기존 자동화가 손을 대신했다면, LLM의 언어 이해는 판단과 해석까지 기계가 분담하게 합니다. 복잡하고 방대한 운영 작업의 인지 부담 자체를 자동화 대상으로 끌어들이는 것입니다.

발표 자료는 도입 논의 이전에 이미 현장에서 쓰이고 있는 영역을 여섯 가지로 정리합니다.

시스템 안정성을 유지하고 이상 징후가 생겼을 때 빠르게 대응하는 것은 IT 운영팀의 핵심 과제입니다. 그런데 감당해야 할 규모가 최근 몇 년 사이 네 갈래로 늘었습니다.

• 클라우드 네이티브 아키텍처 — 다양한 클라우드 서비스와 API로 연결 지점이 폭증했습니다.
• 마이크로서비스(MSA) — 수십·수백 개 서비스가 유기적으로 연결되며 운영 복잡성이 가중됐습니다.
• 쿠버네티스(Kubernetes) — 컨테이너 오케스트레이션으로 확장성은 확보했지만 운영 난이도가 올라갔습니다.
• 방대한 데이터 — 로그·메트릭·이벤트가 폭증했고, 수집과 보관만으로는 가치가 나오지 않습니다.

AIOps가 데이터 분석 자동화에 초점을 맞췄다면, AIOPS는 운영자의 의도와 시스템의 맥락을 결합합니다. 복잡해진 환경에서 안정성 확보와 대응 속도 향상을 동시에 노리는, 운영 경험 자체를 지능화하는 접근입니다.

AIOPS는 기존 AIOps에 LLM의 언어 이해와 생성 능력을 결합해, IT 운영 데이터를 맥락적으로 분석하고 문제 해결까지 지원하는 차세대 운영 체계입니다. LLM, AIOps, IT 데이터 세 겹이 겹치는 자리에서 세 가지 성질이 나옵니다.

• 맥락 이해 — 수치로만 보지 않고 사람의 언어로 설명하며 의미를 해석합니다. 로그 메시지, 장애 보고서, 운영 문서를 자유롭게 읽습니다.
• 자연어 소통 — 대화형 인터페이스로 복잡한 쿼리 없이 질문만으로 원하는 분석 결과를 확인합니다.
• 인과관계 추론 — 방대한 학습 데이터를 기반으로 원인과 결과의 연결고리를 도출해 문제 해결 시간을 줄입니다.

같은 사건을 두고 답변이 어떻게 달라지는지 보면 차이가 분명합니다.

지표를 통보하는 데서 멈추느냐, 원인을 지목하고 조치를 제안하느냐. 도입 검토에서 실제로 갈리는 지점이 여기입니다.

기능 1. 질문 한 줄로 끝나는 원인 분석

복잡한 쿼리나 명령어를 외울 필요가 없습니다. 옆자리 선임에게 묻듯 자연어로 질문하면 됩니다.

운영자 — 어젯밤 10시부터 갑자기 느려진 온라인 쇼핑몰의 원인이 뭐야?

AIOPS — 해당 시간대에 특정 마케팅 이벤트로 평소 대비 5배의 사용자가 몰렸으며, 이로 인해 데이터베이스의 특정 테이블에 Lock 경합이 발생한 것이 주된 원인입니다. 관련 SQL 쿼리는 다음과 같습니다.

같은 방식으로 "이번 주 WAS 성능 동향을 CEO 보고 형식으로 요약해 줘"라고 하면 보고서가 즉시 나오고, "스레드 덤프를 떠서 분석하는 스크립트를 만들어 줘"라고 하면 실행 가능한 코드가 나옵니다.

기능 2. 흩어진 세 갈래 데이터를 하나의 원인으로

전통적인 AIOps 도구는 서로 다른 데이터 소스 사이의 상관관계를 찾기 어려웠습니다. LLM은 로그(오류·이벤트·트레이스), 트레이스(서비스 호출·지연), 메트릭(CPU·메모리·트래픽)을 함께 읽어 근본 원인을 도출합니다.

"어제 발생한 주문 실패 관련 에러 로그를 요약해 줘"라는 요청에 이렇게 답합니다. 총 1,570건의 주문 실패 중 95%가 재고 부족 예외처리 관련 로그이며, 특정 상품의 재고 시스템 연동 지연으로 추정된다는 식입니다. 지표를 스스로 해석하므로 오탐(False Positive)이 줄고 실제 문제에 집중할 수 있습니다.

기능 3. 시작점 파악부터 재발 차단까지

원인 분석이 네 단계로 자동 진행됩니다.

1. 데이터 소스 수집 — 활동 로그, 이벤트 데이터, 인시던트 추적 등 여러 출처의 데이터를 자동 수집합니다.
2. 문제의 시작점 파악 — 인시던트의 시작점을 정확히 짚고 시간순으로 문제의 전개를 추적합니다.
3. 맥락 기반의 권고안 — 의도와 맥락을 고려한 해결 방안을 제안하고 적절한 담당자에게 자동 전달합니다.
4. 재발성 문제 자동화 — 식별된 재발성 문제를 자동화된 워크플로로 해결하거나 담당자에게 넘깁니다.

기능 4. 트래픽이 오기 전에 끝내는 용량 계획

예측 모델이 서비스 KPI를 만족하도록 스레드 풀 크기 같은 파라미터를 제안합니다. WAS 확장이나 캐시 조정까지 자동화해 관리 부담을 줄입니다. 데이터 결합, 패턴 분석, 자동 최적화, KPI 달성의 네 단계로 돕니다.

금요일 신규 기능 배포를 앞둔 상황을 예로 들면 이렇습니다. 변경될 코드의 특성과 기존 성능 데이터를 비교 분석한 뒤, 신규 기능에 포함된 복잡한 쿼리로 평균 응답 시간이 약 15% 증가할 수 있으니 사전에 SQL 튜닝을 검토하라고 알립니다.

기능 5. 말로 시키면 스크립트가 나오는 운영

자연어 요청에서 시작해 LLM 처리, 스크립트 생성, 작업 실행까지 이어집니다. "다음 주부터 WAS 로그를 아카이브하는 크론 잡을 만들어 줘"라고 요청하면 적절한 OS 스크립트가 작성되고, 관리자는 승인만 하면 됩니다.

#!/bin/bash
# WAS 로그 아카이브 스크립트
LOG_DIR=/var/log/was
ARCHIVE_DIR=/archive/was_logs
find $LOG_DIR -type f -name "*.log" -mtime +7 \
  -exec tar -czvf $ARCHIVE_DIR/.tar.gz  \;
find $LOG_DIR -type f -name "*.log.tar.gz" -mtime +30 -exec rm -f  \;

기능 6. 스스로 배우고 먼저 알리는 예방 정비

과거 데이터와 현재 상태를 분석해 잠재적 문제를 사전 감지하고 예방적 조치를 권고하는 자기 학습(self-learning) 기능입니다.

• 지능형 예측 분석 — 시계열 데이터와 로그 패턴을 학습해 미래의 장애를 예측합니다.
• 자동화된 예방 알림 — 주기적으로 시스템 상태를 분석하고 잠재적 위험을 감지하면 즉시 알립니다.
• 자기 학습 — 초기의 잘못된 예측도 실제 결과와 비교하며 지속적으로 최적화됩니다.
• 선제적 유지보수 — 예방적 조치를 자동 수행하거나 적합한 담당자에게 전달해 서비스 중단을 미리 막습니다.

기능 7. 로그 감시에서 규제 보고서까지

시스템 호출 로그와 사용자 세션을 분석해 보안 위협을 감지하고, 규제 요건에 맞는 보고서를 자동 생성합니다. 데이터 수집, 패턴 인식, 이상 탐지, 보고서 생성의 네 단계로 진행됩니다.

• 비정상 접근 감지 — 특정 시간대에 집중된 로그인 시도, 정상 범위를 벗어난 데이터 접근을 탐지합니다.
• 정책 위반 검출 — 권한 없는 파일 접근, DB 스키마 변경, 설정 파일 수정 등을 자동 감지하고 즉시 경고합니다.
• 감사 보고서 자동 생성 — 방대한 로그를 요약해 SOX, PCI DSS, GDPR 등 규제 요건에 맞는 보고서를 만듭니다.

전통적인 웹서버·WAS 관리자의 하루는 끊임없이 주시하는 모니터와 로그, 원인을 찾기 위해 밤을 새우는 장애 알람으로 채워집니다. 발표 자료는 그 한계를 다섯 가지로 정리합니다.

• 사후 대응 — 항상 문제 발생 이후에 대응하는 역할에 머무릅니다.
• 반복적 업무 — 같은 문제가 반복되면 매번 똑같은 절차를 다시 수행합니다.
• 데이터 해석 — 방대한 로그 속에서 단서를 찾으려고 수많은 명령어를 입력하고, 경험과 직관에 의존합니다.
• 인력 의존성 — 조직의 지식이 특정 인원에게 집중되어 교육이 어렵고 운영 공백 위험이 있습니다.
• 마이크로서비스 복잡성 — 서비스가 수십 개 이상의 컨테이너로 나뉘어 상태 추적과 확장이 큰 부담이 됩니다.

OPENMARU iAP는 OPENMARU APM에 모델 컨텍스트 프로토콜(MCP, Model Context Protocol)로 연결된 웹서버, WAS, OS를 지능적으로 모니터링하고 관리하는 플랫폼입니다. 앞에서 살펴본 기능들이 하나의 제품 위에서 어떻게 묶이는지 보여 주는 사례입니다.

• 지능형 대화 인터페이스 — 자연어 질문에 지표·로그·트랜잭션을 종합 분석해 명확한 원인과 근거를 제시합니다.
• 자동화된 문제 해결 — 여러 데이터 소스를 결합해 원인을 파악하고, 재발성 문제는 워크플로로 처리합니다.
• 지표와 로그 통합 분석 — APM 지표로 이상 징후를 스스로 해석하고 미래 장애를 예측합니다.
• 예방 정비·예측적 알림 — “3시간 뒤 메모리 사용량이 90%를 넘을 가능성이 높으니 미리 증설하라”는 형태로 조언합니다.

LLM이 시스템의 상태 데이터와 구성 정보를 이해하고 분석하는 흐름은 네 단계입니다.

1. 데이터 수집 — 메트릭·로그·트레이스 등 모든 운영 데이터를 실시간 수집합니다.
2. 컨텍스트 생성 — 시스템 구성 정보와 결합해 AI가 분석할 수 있는 맥락으로 가공합니다.
3. AI 분석 — AI 엔진이 컨텍스트를 분석해 이상 징후의 근본 원인을 진단합니다.
4. 자동화된 운영 — 해결 방안을 도출하고 실행 가능한 조치를 자동 수행합니다.

정해진 규칙에 따른 자동화(Automation)를 넘어 AI가 스스로 상황을 판단한다는 점이 기존 자동화와 다릅니다.

지금까지 운영자는 장애를 직접 막고 원인을 찾는 보병에 가까웠습니다. 사후 대응에 시간의 대부분을 쓰고, 복잡한 로그와 지표를 사람이 해석하고, 같은 문제를 매번 다시 풀었습니다.

앞으로는 판단과 결정에 집중하는 지휘관 역할로 옮겨 갑니다. 문제가 커지기 전에 미리 조치하고, 자연어 질문으로 원인을 파악하고, 반복 보고와 스크립트는 기계가 수행합니다.

예측 분석이 어떻게 작동하는지는 이런 문장으로 확인할 수 있습니다. “3시간 뒤 특정 애플리케이션의 메모리 사용량이 임계치를 초과할 확률이 85%입니다. 원인은 최근 배포 버전의 메모리 누수로 추정됩니다.” 관리자는 장애가 나기 전에 선제 조치를 하고, 서비스는 멈추지 않습니다.

발표 자료는 도입 효과를 다섯 가지로 정리합니다.

• 운영 효율성의 극대화 — MTTR이 평균 30~50% 이상 단축되고, 반복 업무 자동화로 관리자 1인당 담당 규모가 2배 이상 증가합니다.
• 서비스 안정성 및 신뢰도 향상 — 장애를 사전에 예측·예방해 다운타임을 최소화하고, 고객 만족도 향상과 비즈니스 손실 방지로 이어집니다.
• 총소유비용(TCO) 절감 — 클라우드 자원과 서버 리소스의 최적 사용을 추천해 불필요한 비용과 야간·휴일 대응 인건비를 줄입니다.
• 전략적 의사결정 지원 — 시스템 증설이나 아키텍처 변경 같은 결정에서 데이터 기반 예측이 실패 위험을 줄입니다.
• 조직의 지식 자산화 — 소수 시니어 엔지니어의 머릿속에 있던 노하우가 시스템에 녹아들어 조직 전체의 지식 자산이 됩니다.

도입 전후를 다섯 가지 기준으로 비교하면 다음과 같습니다.

몇 가지 문제를 푸는 데서 그치지 않고 조직의 IT 운영 방식과 성과를 함께 바꾸는 계기가 된다는 것이 이 자료의 결론입니다. 도입을 검토한다면 지금 쓰는 모니터링이 알람 통보에서 멈추는지, 원인 설명까지 이어지는지부터 점검해야 합니다.

같은 내용을 나레이션과 함께 보시려면 아래 영상을 참고하십시오. 위에서 다룬 AIOps의 정의부터 일곱 가지 기능, 도입 전후 비교까지 순서대로 이어집니다.

다음 편에서 이어집니다

이 글은 LLM 기반 AIOPS를 다루는 3부작 가운데 1편 개념과 기능 편입니다. 2편은 APM 환경에서 실제 장애를 잡아 내는 데모, 3편은 운영 적용 시나리오를 다룹니다.

• 발표 자료 전문(22쪽)은 위 자료 다운로드 버튼에서 내려받으실 수 있습니다.
• 도입 검토나 데모 요청은 hello@msap.ai 로 보내 주시면 담당자가 연락드립니다.
• 제품과 플랫폼 구성은 MSAP.ai 홈페이지에서 확인하실 수 있습니다.

• 홈페이지: https://www.msap.ai/
• 이메일: hello@msap.ai
• 전화: 02-6953-5427

• MSAP.ai 홈페이지
• 공개 LLM 모델이 촉발 시킨 AIOPS 와 MLOPS
• Observability & APM — MSAP.ai 플랫폼
• AIOps란? 안정적인 IT 운영을 위한 특급 비법
• OPENMARU CogentAI — IT 운영자를 위한 지능형 AI 에이전트 플랫폼
• 지능형 애플리케이션 플랫폼, OPENMARU iAP 브로슈어
• 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모
• APM이란? 서버 모니터링으로 못 잡는 장애, 개념부터 도입까지
• APM으로 보는 클라우드 네이티브 운영
• Gartner — AIOps Platforms 용어 정의
• Google SRE Book — Eliminating Toil
• Model Context Protocol 공식 문서