운영 현장에서 가장 비싼 시간은 “지금 왜 느려졌는지 모르는 15분”입니다. 대시보드는 넘치지만, 실제로 원인을 짚고 조치로 연결되는 데는 늘 사람이 붙어야 했습니다. 이 영상은 거대 언어 모델(LLM) 기반 AIOps가 그 간극을 어떻게 메우는지, 4개 섹션의 실제 데모로 보여줍니다.
이번 글은 「운영자 없이 장애를 잡는다? — LLM AIOps ① 개념과 기능」에 이어지는 두 번째 편(실전 데모) 요약입니다. 영상은 32분이지만, 핵심은 네 가지 — 외부 API 에러 장애 분석 · T-Map 장애 패턴 자동 지목 · APM 연계 지연 트랜잭션 원인 분석 · 느린 쿼리 자동 진단입니다.
왜 지금 ‘LLM AIOps’인가 — 대시보드는 늘었는데 답은 늦는 이유
운영자는 WAS 로그·APM 메트릭·DB 성능·외부 API 응답까지 매번 창을 바꿔가며 확인해야 했습니다. 그래서 장애 발생부터 원인 특정, 조치 결정까지 흔히 수십 분이 걸립니다.
LLM AIOps는 이 흐름을 뒤집습니다. 운영자가 자연어로 묻고, AI가 APM 데이터를 직접 조회해 원인을 짚고 실측으로 증명합니다. OPENMARU APM × CogentAI 조합이 그 역할을 합니다.
영상에서 보는 네 가지 섹션 — 한눈에
- SECTION 01 — 장애 시나리오 데모 : 외부 서비스 지연 / 외부 API HTTP 500 / DB 커넥션 풀 고갈 세 가지 사례를 질문 몇 번으로 해결
- SECTION 02 — T-Map 장애 패턴 감지 : 히트맵 ‘모양’만 보고 16종 장애 패턴을 자동 분류
- SECTION 03 — APM 연계 AIOps 활용 : 지연 트랜잭션 원인 분석 + 사용자 활동 추적 + 보고서 자동 생성
- SECTION 04 — 느린 쿼리 진단과 개선 : 임계치에 안 걸리는 느린 쿼리까지 자동으로 잡고, 실행 계획과 인덱스 추천으로 개선 방안까지 제시
SECTION 01 — 외부 API 에러에 따른 장애, 자연어 한 번으로 원인 특정
외부 API가 HTTP 500을 반환하면서 애플리케이션 에러율이 60~65%까지 치솟고 Apdex가 급락한 상황입니다. 운영자는 평소처럼 WAS 로그를 뒤지는 대신 “에러율이 올라가는데 원인을 분석해줘”라고 묻기만 했습니다.
AI는 CogentAI 창에서 에러 발생 위치(UserTestController.errorTest), 호출 체인, 외부 API URL까지 짚고, “WAS 자체 자원 문제가 아닌 외부 API 장애(HTTP 500)”라고 원인을 확정합니다. 정상 범위로 확인된 지표(TPS·평균 응답시간·Heap 사용률)와 이상 지표(에러율·Apdex)를 함께 보여줘, 운영자가 바로 조치 방향을 잡을 수 있습니다.
SECTION 02 — T-Map 장애 패턴을 시스템이 ‘먼저’ 지목
운영 중에는 수천~수만 건의 트랜잭션이 쏟아집니다. 어떤 유형으로 잘못되는지 표로 찾기는 느리고 놓치기도 쉽습니다. 특히 쿼리 타임아웃은 징후가 여러 트랜잭션에 흩어져 직관적으로 보이지 않습니다.
T-Map은 시간 × 응답시간 평면에 트랜잭션을 히트맵으로 뿌려두고, 모양만 보고도 16종 장애 패턴을 자동 분류합니다. 세로줄·느린 응답·파도치기·단계적 성능 저하·연쇄 장애 등 패턴별로 유형 판정을 자동화하고, DB 지연·타임아웃 특유의 패턴은 바로 느린 SQL·외부 호출까지 진단 체인을 자동 연결합니다. “트랜잭션의 문제 패턴을 시스템이 먼저 짚어 준다”가 핵심입니다.
SECTION 03 — APM 연계 지연 트랜잭션 원인 분석과 실측 검증
운영자가 “[homepage] 애플리케이션에 문제는 없는지 현재 상황을 분석해줘”라고 묻자, AI가 /api/orders/statistics 트랜잭션이 6초 이상 지연되는 사실과 그 원인을 특정했습니다 — 느린 SQL과 JDBC 커넥션 풀 고갈.
여기까지가 ‘AI 분석을 실측으로 검증하는 3단계’입니다. 원인 분석(JDBC 실행 시간이 전체 지연의 6,651ms임을 지목) → 개선 방안(인덱스 추가·서브쿼리 JOIN 전환·커넥션 풀 15~20 확장) → 실측 검증(트랜잭션 추적에서 Duration 6,714ms 중 SQL Time 6,711ms 확인). AI가 지목한 쿼리가 실제 호출됨을 콜 트리로 증명합니다.
영상에는 이어서 접속 사용자 활동 추적(20초 기다린 사용자의 요청 흐름 역추적)과 보고서 자동 생성(PDF · HWPX · DOCX)이 나옵니다. 분석에서 보고까지 하나의 흐름입니다.
SECTION 04 — 느린 쿼리, 찾는 데서 끝나지 않고 ‘고치는 법’까지
개별 쿼리는 임계치 미만(8~18ms)이라 슬로우 감지에 안 잡히지만 N+1 · 대량 Fetch로 전체가 느려지는 경우, 원인을 찾아도 실행 계획 해석과 인덱스 설계는 DBA 영역이라 개발자가 매번 묻는 병목이 생깁니다.
OPENMARU APM은 트랜잭션을 여는 즉시 느린 SQL Top N(100ms 초과 정렬·비율)을 상단에 표시하고 N+1·대량 Fetch를 포착합니다. 그리고 버튼 클릭 한 번으로 AI에 쿼리를 전달해 실행 계획 해석 + 인덱스 추천(Oracle·PostgreSQL·MySQL·MSSQL 지원)까지 받습니다. 주석과 메타데이터를 그대로 AI에 전달해 쿼리의 의도까지 함께 읽히므로 분석 정확도가 높아집니다. “느린 쿼리를 찾는 것에서 끝나지 않고, 쿼리 플랜을 AI가 분석합니다.”
OPENMARU APM × CogentAI — 이렇게 조합됩니다
이 네 가지 데모의 공통점은, 모두 OPENMARU APM이 수집·보관한 운영 데이터를 AI가 직접 조회한다는 점입니다. 데이터가 외부로 나가지 않고, 운영자는 자연어로 묻기만 하면 됩니다. 그 결과:
- MTTR(평균 복구 시간) 단축 — 알람에서 원인 특정까지의 대응 시간이 10분의 1 수준
- DBA 의존도 감소 — 개발자가 혼자 실행 계획과 인덱스 설계까지
- 장애 보고 자동화 — 분석 → PDF·HWPX·DOCX 보고서까지 하나의 흐름
- 보안 안전 — sLLM + MCP + APM 구조로 데이터가 조직 밖으로 나가지 않음
참고 리소스
- AI가 장애 원인까지 짚는다 — LLM AIOps ② 실전 데모 (클라우드네이티브TV)
- 운영자 없이 장애를 잡는다? — LLM AIOps ① 개념과 기능 (클라우드네이티브TV)
- OPENMARU APM 제품 페이지
- 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모
문의 — AIOps 도입이 궁금하다면
OPENMARU APM × CogentAI 조합을 자사 운영 환경에 어떻게 적용할지, 무료 기술 상담에서 바로 짚어드립니다. 사내 보안 요건과 레거시(WebLogic·JBoss)까지 포함한 도입 범위도 함께 설계합니다.
