T3. AI로 원인 분석하기 (CogentAI · SQL · 스레드 덤프 · 이벤트)
Diátaxis: Tutorial(따라하기) · 대상: 운영자 / 관리자 ← 목차로 · ← T2 대시보드로 발견·추적
T2에서 대시보드가 빨갛게 느려진 것을 발견했다면, 이 실습은 그 원인을 AI에게 분석시키는 네 가지 방법을 따라 합니다 — ① 시스템 전체를 CogentAI 진단으로, ② 느린 트랜잭션의 SQL을 AI 쿼리 진단으로, ③ 멈춘 지점을 스레드 덤프 → AI 분석으로, ④ 쌓인 이벤트를 그 자리에서 AI 분석으로. 약 9분입니다.
사전 조건 AI 기능은 관리자가 켜 두었을 때만(설정 ▸ Cogent AI) 버튼이 보입니다. 안 보이면 관리자에게 문의하세요. AI 기능 전반은 H14. AI로 차트·이벤트 분석 받기에 정리돼 있습니다.
1부. CogentAI 진단 — 시스템 전체를 한 번에
대시보드가 느린데 어디가 원인인지 막막할 때, 가장 빠른 첫걸음입니다. 화면 위쪽(헤더) 가운데의 CogentAI 진단 버튼이 선택한 앱 그룹 전체를 점검합니다.
1단계 — 진단할 그룹 고르기
먼저 컨텍스트 셀렉터에서 분석할 앱 그룹을 고릅니다(→ H1). AI 진단은 항상 지금 선택된 그룹 전체를 봅니다.
2단계 — AI 진단 버튼 누르기
- 헤더 우측의 AI 진단(CogentAI 아이콘 + 라벨)을 클릭합니다. (hover 시 "지금 시스템에 이상은 없는지 — AI 진단" 표시)
- CogentAI 위젯이 열리며 자동으로 그룹 전체 상태를 묻습니다 — "[그룹명] 애플리케이션 및 시스템에 문제는 없는지 현재 상황을 분석하여 알려줘."
결과 — AI가 그룹 전반(애플리케이션·시스템)을 점검해 위 화면처럼 데이터 회수 기간 → 애플리케이션 현황 → 성능 지표 분석 순의 구조화된 보고로 이상 징후와 다음에 볼 곳을 알려 줍니다. 위젯 하단 입력창으로 추가 질문도 이어갈 수 있습니다.
답변의 트랜잭션 링크를 눌러 바로 확인하기
지연·오류가 있으면 답변에 해당 트랜잭션으로 가는 링크가 함께 나옵니다. AI가 "느린 요청이 있습니다" 라고만 하지 않고 어느 요 청인지 짚어 줍니다.
링크를 누르면 화면을 벗어나지 않고 그 자리에서 트랜잭션 상세가 열립니다(새 탭으로 넘어가지 않습니다). 상세가 열릴 때 채팅창은 잠시 접히고, 닫으면 하던 대화로 돌아옵니다.
참고 상세에서 성능 분석 탭을 열면 문제 감지 카드로 바로 이어집니다 — AI의 추정을 실제 데이터로 확인하는 가장 짧은 경로입니다.
나의 대시보드에서 진단하기
나의 대시보드에서도 같은 진단을 받을 수 있고, 이때는 그 화면에 올려 둔 애플리케이션 그룹이 대상이 됩니다. 위젯을 특정 그룹으로 고정해 두었다면 그 그룹을 봅니다.
지연이 큰 트랜잭션을 자동으로 골라 함께 분석하므로, 어느 것을 볼지 먼저 정하지 않아도 됩니다.
참고 이 버튼은 지금 보고 있는 탭과 무관하게 항상 그룹 전체를 봅니다. 특정 차트만 좁혀 보고 싶으면 그 차트 카드의 AI 아이콘을, T-Map 패턴은 원의 AI 버튼을 쓰세요(→ T2 4단계).
3단계 — 답을 교차 확인하기
AI 답은 출발점입니다. 지목된 지표를 R2. 차트 레퍼런스·실제 차트로 확인해, 추정을 사실로 바꿉니다.
주의 AI는 추정을 제공합니다. 재시작·설정 변경처럼 돌이키기 어려운 조치는 사람이 근거를 확인한 뒤 결정하세요.
2부. 느린 SQL → AI로 쿼리 진단
T2·H6에서 느린 트랜잭션을 찾아 들어가면, 대개 그 안에 느린 SQL이 있습니다. 그 SQL의 실행계획을 사람이 읽기 전에, CogentAI에게 먼저 분석시켜 원인 가설과 인덱스 제안을 받습니다.
4단계 — 느린 SQL을 찾아 SQL 다이얼로그 열기
- 느린 트랜잭션의 상세로 들어갑니다(→ T2 4단계 · H6. 느린 트랜잭션 원인 찾기).
- **워터폴(Waterfall)**에서 DB 구간(span)의 [SQL] 버튼을 누르면 SQL 쿼리 다이얼로그가 열립니다.
- 다이얼로그에서 실제 실행된 쿼리(바인드 값이 채워진 형태)와 fetch·실행 통계를 확인합니다.
위 예시는 T-Map에서 드래그해 연 트랜잭션 조회에서 한 건을 고른 화면입니다. **호출 흐름(워터폴)**에 DB 호출(executeQuery)이 반복되고, 각 DB 구간 우측에 [SQL] 버튼이 보입니다 — 이 버튼이 SQL 쿼리 다이얼로그 입구입니다.
다이얼로그는 DB 연결 정보(드라이버·호스트·인스턴스·사용자), SQL 쿼리(바인드 변수
? 형태), 파라미터, 바인드 값이 채워진 매핑된 쿼리, FETCH(횟수·시간) 순으로
보여 줍니다. 각 블록의 복사 버튼으로 쿼리를 바로 가져갈 수 있습니다.
결과 — 분석할 SQL 한 건을 다이얼로그로 열었습니다.
5단계 — "AI 쿼리 진단" 누르기
- 다이얼로그 헤더(상태 배지 옆) 또는 **푸터([닫기] 왼쪽)**의 AI 쿼리 진단(CogentAI 아이콘) 버튼을 누릅니다.
- 그 SQL이 DB 종류와 함께 CogentAI로 전달되어 실행계획 분석 + 인덱스 추천을 받습니다.
- 다이얼로그는 닫히지 않고, 결과는 우하단 CogentAI 패널에 표시됩니다(“CogentAI 패널에서 결과를 확인하세요” 토스트).
결과 — 실행계획을 직접 해석하기 전에, AI가 **왜 느린지와 어떻게 고칠지(인덱스 등)**를 먼저 추려 줍니다.
AI 쿼리 진단 리포트 읽는 법
CogentAI 패널의 리포트는 다음 순서로 구성됩니다. 위에서부 터 읽으면 현상 → 원인 → 처방 순서가 됩니다.
1) 실행계획 — 시각화 차트와 표
패널 상단의 Query Execution Plan 시각화는 실행계획을 트리로 보여 줍니다. 비용(Cost)이 큰 노드는 색으로 강조되며, 노드에 마우스를 올리면 Cost·예상 행 수·Severity가 표시됩니다 — TABLE ACCESS FULL(풀스캔)이나 Severity가 Critical인 노드가 의심 지점입니다. 같은 내용이 Query Plan 표(Operation·Cost·E-Rows·E-Time)로도 제공되어 EXPLAIN 결과에 익숙하면 표로 바로 읽을 수 있습니다.
2) 테이블 구조(ERD)와 병목 지점
분석 대상 테이블들의 관계도(ERD) 와 함께, 쿼리가 무엇을 하는지(조인·집계·정렬)와 성능 병목 지점을 단계별 표로 짚어 줍니다 — 어느 스캔이 몇 번 반복되는지, 왜 인덱스를 못 타는지가 여기에 정리됩니다.
3) 최적화 방안 — 개선 SQL과 인덱스 제안
병목 분석에 이어 다시 쓴 SQL(서브쿼리를 CTE로 통합하는 등)과 권장 인덱스 목록, 적용 시 예상 개선 효과(예: "현재 3,086ms → 1/5 수준 단축 기대")를 제시합니다.
참고 무엇을 근거로? AI는 그 SQL의 **실행계획 + 테이블·인덱스 통계 + 이슈 감지(풀스캔·누락 인덱스)**를 보고 인덱스까지 제안합니다. 운영 영향? 콘솔의 AI 쿼리 진단은 EXPLAIN(추정 실행계획)과 통계 조회만 하고 쿼리를 실제로 실행하지 않아 운영 DB 부담이 거의 없습니다.
참고 SQL이 실패한 경우(에러 메시지 포함)도 그대로 분석을 요청할 수 있어, 오류 원인 진단에도 씁니다. 단, 테이블/뷰가 없는 오류(ORA-00942 등)는 분석이 무의미해 요청이 차단되고 안내 토스트가 뜹니다.
주의 AI의 제안(인덱스 생성 등)은 출발점입니다. 실제 적용 전에 DBMS 지표·실행계획을 R2.3 DBMS 차트와 DBA 검토로 교차 확인하세요.
3부. 스레드 덤프 → AI로 분석
"인스턴스는 살아 있는데 응답이 없다/느리다"(행·멈춤)면, 지금 스레드들이 무엇을 하다 멈췄는지 스레드 덤프로 보고, 그 덤프를 AI에게 분석시킵니다.
6단계 — 스레드 덤프 뜨기
- 좌측 메뉴 ▸ WAS ▸ 트러블슈팅으로 가서 스레드 덤프 분석 탭을 엽니다. 상단에서 진단할 인스턴스를 고릅니다. (같은 화면에 힙 오브젝트·오픈 파일·네트워크 상태·액티브 스레드 제어 탭도 함께 있습니다.)
- 스레드 덤프 목록에서 덤프를 하나 고릅니다(또는 새로 요청 버튼 클릭).
- 스레드 덤프 분석기에 스레드 목록과 상태(Runnable·Blocked·Waiting·Timed waiting 등)가 표시됩니다. 스레드를 고르면 우측 스레드 상세 분석에 상세 스택이 보입니다.
결과 — 지금 멈춰 있는 스레드와 그 스택을 확보했습니다.
참고 Blocked가 많으면 잠금 경합, Waiting이 많으면 스레드 풀 고갈을 의심합니다 (E3.2). 데드락·OOM 이벤트가 나면 덤프가 자동 수집되기도 합니다(R3).
7단계 — 덤프를 AI로 분석
- 스레드 덤프 목록 툴바의 CogentAI 분석 버튼을 누릅니다.
- AI가 덤프를 요약·분석해 공통 스택, 데드락 여부, 오래 걸리는 호출 대상을 짚어 줍니다.
결과 — 수백 개 스레드를 일일이 읽지 않고도, AI가 위 화면처럼 상태별 스레드 그룹과 관련 클래스·원인 후보를 표로 추려 줍니다. 멈춤의 공통 원인을 먼저 확인한 뒤 6단계의 분석기에서 해당 스레드 스택을 교차 확인하세요.
같은 방식으로 힙 오브젝트 분석(메모리 누수)도 받을 수 있습니다 → H7. 메모리 누수 점검 · H20. 에이전트 점검.
4부. 알림센터·이벤트 목록 → 이벤트 AI 분석
임계치 초과·상태 변화가 일어나면 시스템은 그 사건을 이벤트로 남깁니다. 어떤 이벤트가 막막할 때, 그 이벤트 1건을 AI에게 바로 분석시킬 수 있습니다.
8단계 — 알림센터·이벤트 목록 열기
- 알림센터 — 헤더 우측의 벨 아이콘으로 방금 발생한 심각·경고 알림을 빠르게 확인합니다. (심각 알림이 있으면 벨에 빨강 배지가 붙습니다.)
- 이벤트 목록 — 좌측 메뉴 ▸ 이벤트에서 전체 이벤트를 봅니다. 레벨(심각 · 경고 · 정보) · 발생시각 · 종류 · 대상 · 메시지로 정리되고, 상단 막대그래프로 시간대별 발생량을 봅니다.
- 이벤트 행을 클릭하면 우측에 상세 드로어가 열려 종류 · 대상(인스턴스/호스트) · 메시지와 무엇이 / 왜 / 영향 / 점검 설명이 함께 보입니다.
9단계 — 이벤트를 AI로 분석
- 이벤트 행 우측의 AI 아이콘, 또는 상세 드로어 헤더의 AI 진단 버튼을 누릅니다.
- 그 이벤트의 종류 · 레벨 · 대상 · 메시지(+ 데드락·OOM처럼 자동 수집된 스레드 덤프 · 진단 데이터)가 함께 CogentAI로 전달됩니다.
- AI가 그 이벤트의 원인 가설과 다음 점검 항목을 자연어로 보고합니다.
결과 — 막막한 이벤트도 그 자리에서 AI에게 "이건 왜 났고, 무엇부터 봐야 하나"를 물어볼 수 있습니다.
참고 데드락·OOM처럼 덤프가 자동 수집된 이벤트는 그 덤프까지 함께 분석돼 더 구체적인 답을 받습니다. 이벤트 종류별 의미·조사 포인트는 R3. 이벤트 종류 레퍼런스에 있습니다.
완료 — 이제 할 수 있는 것
- 헤더 AI 진단으로 선택 그룹 전체의 원인을 한 번에 분석시킨다
- 느린 트랜잭션의 SQL을 AI 쿼리 진단으로 실행계획·인덱스까지 분석시킨다
- 스레드 덤프를 떠서 멈춘 스레드를 확인하고, CogentAI로 그 덤프를 분석시킨다
- 알림센터·이벤트 목록에서 이벤트 1건을 AI 진단으로 분석시킨다
- AI 답을 차트·레퍼런스로 교차 확인해 조치를 결정한다
다음 단계
| 하고 싶은 것 | 가이드 |
|---|---|
| AI 버튼 종류(헤더·차트·트랜잭션·이벤트) 전체 | H14. AI로 차트·이벤트 분석 받기 |
| 메모리 누수(힙·GC·힙덤프) 진단 | H7. 메모리 누수 점검 |
| 에이전트 무응답·연결 점검 | H20. 에이전트 상태 점검 |
| 느린 트랜잭션 패턴 19종 | H6. 느린 트랜잭션 원인 찾기 |