APM 기반 AIOps 장애 분석 데모 — 알람에서 원인과 조치까지

운영자가 자연어로 “지금 장애 원인 분석해줘”라고 묻고, APM(Application Performance Management — 애플리케이션 성능 관리)이 쌓아 둔 지표와 로그를 LLM이 읽어 원인과 조치를 되돌려주는 과정을 데모 화면 그대로 정리했습니다. 「LLM 기반 AIOps로 IT 운영 다시 설계하기」 2편에서 다룬 내용으로, 장애 시나리오 세 가지부터 T-Map 패턴 감지, 느린…

2026년 08월 06일

데모 영상 — 33분, 네 구간 전체 화면

아래 영상이 이 글에서 짚는 네 구간을 실제 운영 화면으로 담은 2편 전체입니다. 맨 앞 4분은 하이라이트라, 시간이 넉넉하지 않으시면 그 구간만 보셔도 흐름은 잡힙니다.

자료 다운로드 📄

이 글과 함께 제공되는 발표 자료를 아래 버튼에서 내려받으실 수 있습니다.

자료 다운로드

알람은 울렸는데, 원인은 여전히 사람이 찾습니다

장애가 나면 모니터링 도구는 임계치를 넘었다는 사실만 알려줍니다. 그다음부터가 사람의 몫입니다. 어느 트랜잭션이 문제인지, 외부 연동 API가 느린 건지 데이터베이스가 막힌 건지, 지표 화면과 로그를 오가며 직접 좁혀 들어가야 합니다.

여기서 시간이 갈립니다. 지표는 정상 범위인데 에러율만 튀는 상황, 개별 쿼리는 임계치에 안 걸리는데 전체 응답이 느려지는 상황처럼 표면 증상과 근본 원인이 어긋나면 숙련된 운영자도 한참을 헤맵니다. APM 기반 AIOps는 알람과 조치 사이의 이 빈칸을 메웁니다.

장애 시나리오 세 가지를 같은 흐름으로

데모는 성격이 다른 장애 세 건을 같은 질문 흐름으로 처리합니다. 운영자는 매번 자연어로 묻고, AI는 TPS·응답시간·오류율·Apdex를 먼저 훑은 뒤 이상 구간을 좁혀 들어갑니다.

외부 서비스 지연 — 응답시간 50ms에서 2,800ms로

첫 사례는 WAS 자체는 멀쩡한데 응답만 느려진 상황입니다. “지금 발생한 장애 원인을 분석해줘”라는 질문 하나로 AI는 특정 구간의 응답시간이 50ms에서 2,800ms까지 뛰고 Apdex가 떨어진 것을 짚습니다. 이어 “어느 트랜잭션이 문제인지 지정해줘”라고 물으면 /slowTest1 트랜잭션의 외부 HTTP 호출이 20초를 쓰고 있고 내부 WAS 처리는 정상이라는 답이 돌아옵니다.

마지막 질문은 “지금 어떤 조치를 취해야 해?”입니다. 외부 시스템 상태 점검, WAS의 외부 호출 타임아웃 설정 검토, 외부 연동 로그와 성능 지표 추가 모니터링까지 실행 항목으로 정리됩니다. 질문 네 번으로 탐지에서 조치까지 끝나는 셈입니다.

외부 API 에러 — 에러율 60~65%, Apdex 35~45

두 번째 사례는 지표 대부분이 정상인데 에러율만 치솟은 경우입니다. WAS 인스턴스의 에러율이 60~65%까지 오르고 Apdex는 35~45로 떨어졌는데, TPS·평균 응답시간·Heap 사용률은 정상 범위였습니다. 자원 문제가 아니라는 뜻입니다.

AI는 APM 지표를 모으고 외부 API 호출 상태를 점검한 뒤 에러 유형 통계를 분석해, /errorTest 트랜잭션이 호출하는 외부 API의 HTTP 500 오류로 원인을 특정합니다. 운영자에게는 원인 설명과 함께 외부 API 점검, 에러 핸들링 로직 강화, 네트워크 상태 추가 점검이 권고로 따라붙습니다. 단순 알람만 받던 자리에 원인과 대응 초안이 함께 오면서 대응 시간이 기존의 10분의 1 수준으로 줄었습니다.

DB 지연 — 500ms에서 2,300ms, 커넥션 획득 24초

세 번째는 데이터베이스 쪽입니다. JDBC 요청 중 sleep(5) 함수가 포함된 쿼리가 실행되면서 평균 응답시간이 500ms에서 2,300ms로 약 4.6배 뛰었고, HikariCP 커넥션 풀에서 커넥션을 얻는 데 24초 넘게 걸렸습니다. 커넥션 풀 고갈과 DB 연결 지연이 함께 확인된 상황입니다.

질문은 세 번입니다. “현재 발생하는 지연현상 분석해줘”로 병목 구간을 찾고, “DB 쿼리 때문에 장애가 발생했는지 확인해줘”로 JDBC 지연과 커넥션 풀 상태를 추적해 문제 쿼리를 집어내고, “지금 바로 조치할 방법을 알려줘”로 즉시 조치(불필요한 쿼리 제거, 커넥션 풀 파라미터 점검)와 개선 방안(풀 모니터링 강화, 자동 알림 설정, 쿼리 최적화)을 나눠 받습니다.

표를 훑지 않고 모양으로 진단하는 T-Map

운영 중에는 수천에서 수만 건의 트랜잭션이 쏟아집니다. 무엇이 어떤 유형으로 잘못되는지를 표에서 찾는 방식은 느리고 놓치기 쉽습니다. 특히 쿼리 타임아웃은 징후가 여러 트랜잭션에 흩어져 표로는 잘 보이지 않습니다.

T-Map은 모든 트랜잭션을 시간과 응답시간 평면에 그린 히트맵입니다. 장애 유형마다 고유한 시각 패턴이 나타나기 때문에, 그 모양만으로 원인의 방향을 좁힐 수 있습니다. 세로줄, 느린 응답, 파도치기, 단계적 성능 저하, 연쇄 장애 등 16종 패턴을 자동으로 분류하고, DB 지연이나 타임아웃 특유의 패턴은 느린 SQL과 외부 호출 진단까지 자동으로 이어 줍니다. 표를 훑는 대신 시스템이 먼저 짚어 주는 방식입니다.

AI가 지목한 원인을 실측으로 검증합니다

AI 분석에서 늘 남는 질문은 “그 말이 맞는가”입니다. 데모는 이 지점을 원인 분석 → 개선 방안 → 실측 검증 세 단계로 나눠 보여 줍니다.

[homepage] 애플리케이션 상태를 물었을 때 AI는 /api/orders/statistics 트랜잭션이 6초 넘게 지연되고 있고, 원인이 느린 SQL과 JDBC 커넥션 풀 고갈이라고 답합니다. 근거로는 JDBC 실행 시간이 전체 지연의 대부분인 6,651ms를 차지한다는 점, 중첩 SELECT 풀스캔이 커넥션 풀 10개를 전량 점유했다는 점을 듭니다. 개선 방안은 인덱스 추가, 서브쿼리의 JOIN 전환, 커넥션 풀 15~20개 확장이고, 영역·조치·기대효과를 표로 묶어 3~5초 이하로 줄이는 목표까지 제시합니다.

검증은 사람이 합니다. 트랜잭션 추적 화면에서 Duration 6,714ms 가운데 SQL Time이 6,711ms임을 확인하고, 콜 트리로 AI가 지목한 쿼리가 실제로 호출됐음을 눈으로 확인합니다. 분석 결과와 실측이 맞물리는 것을 보고 나서야 조치로 넘어갑니다.

사용자 관점으로 다시 보기

“지금 접속한 사용자와 활동 내역을 보여줘”라고 하면 APM 세션·트랜잭션 데이터를 조회해 사용자가 어떤 화면과 API를 어떤 순서로 호출했는지 정리해 줍니다. 접속자 수를 나열하는 것과는 다릅니다.

세션 ID·로그인 시각·요청 경로가 타임라인으로 이어지고, 각 트랜잭션의 응답시간과 오류 구간이 함께 표시되어 어느 화면에서 느려졌는지가 바로 보입니다. 서버 지표만 보면 평균에 묻혀 사라지는 개별 사용자의 대기 시간이 여기서 드러납니다. 이상 호출 패턴을 잡아내거나 사용자 기준으로 장애를 재현할 때도 같은 데이터를 씁니다.

보고서까지 한 번에

“APM 성능 데이터를 정리해 보고서로 만들어줘”라고 하면 응답시간·처리량·에러율·자원 사용률을 자동으로 모으고, LLM이 이를 해석해 사람이 읽는 문서로 만듭니다. 임계치를 넘은 구간과 이상 징후를 짚고 성능 저하의 추정 원인을 서술한 뒤, GC 설정·메모리 사용 패턴·로그 레벨 같은 조치 사항을 덧붙입니다. 완성된 보고서는 PDF·HWPX·DOCX로 바로 내려받을 수 있어, 운영 보고나 경영 보고용 문서를 따로 편집할 일이 줄어듭니다.

느린 쿼리를 찾는 데서 끝내지 않습니다

느린 쿼리는 장애의 흔한 원인이지만 진단이 까다롭습니다. 개별 쿼리가 8~18ms 수준이면 일반적인 슬로우 쿼리 감지에는 걸리지 않는데, N+1이나 대량 Fetch로 전체 응답은 느려집니다. 원인을 찾아도 실행 계획 해석과 인덱스 설계는 DBA의 영역이라, 개발자가 매번 물어보는 또 다른 병목이 생깁니다.

데모에서는 트랜잭션을 여는 즉시 느린 SQL Top N(100ms 초과 기준 정렬과 비율)이 상단에 뜹니다. N+1과 대량 Fetch가 여기서 잡힙니다. 버튼 하나로 해당 쿼리를 AI에 전달하면 실행 계획 해석과 인덱스 추천이 스키마·통계 기준으로 돌아오고, Oracle·PostgreSQL·MySQL·MSSQL을 모두 다룹니다. 쿼리 원형을 주석과 메타데이터까지 그대로 전달하기 때문에 쿼리의 의도가 함께 읽혀 분석 정확도가 올라갑니다.

데모 네 구간이 남기는 것

구간	기존 방식	APM 기반 AIOps
장애 원인 파악	지표 화면과 로그를 오가며 수동 분석	자연어 질문 3~4회로 병목 트랜잭션 특정, 대응 시간 10분의 1
유형 진단	수천~수만 건 트랜잭션 표를 훑음	T-Map 모양 기반 16종 패턴 자동 분류
분석 신뢰	도구가 준 결론을 그대로 수용	트랜잭션 추적·콜 트리로 실측 검증(6,714ms 중 SQL 6,711ms)
느린 쿼리	임계치 미달이면 미탐지, 해석은 DBA 의존	Top N 자동 정렬 + 실행 계획 해석·인덱스 추천
보고서	수작업 집계와 문서 편집	PDF·HWPX·DOCX 자동 생성