배경
Grafana에서 에러가 터지면 로그를 직접 읽고, 원인을 찾으려고 GitLab에서 소스코드를 하나하나 추적해야 했습니다.
해결 방법
Grafana Alert → Lambda → AI 분류 → GitLab 소스 조회 → Slack 알림까지 이어지는 자동화 파이프라인을 만들었습니다.
아키텍처
Grafana Alert(Webhook) → Phase 1: Error Scan → Phase 2: Deep Analysis → Slack 알림까지 4단계로 구성됩니다.
실전 시나리오: Alert 17건 처리
Webhook 수신부터 Slack 발송까지 4단계로 17건의 alert를 자동 처리합니다.
Phase 1: Error Scan
Loki 쿼리로 ERROR 로그를 수집하고, 사전 필터링과 클래스 병합으로 노이즈를 제거합니다.
Phase 2: Deep Analysis
Pod Context 조회 → GitLab Source 조회 → AI 개별 심층 분석을 병렬로 수행합니다.
AI Agent 설계
Error Classifier, Deep Analyzer, Source Lookup 3개 에이전트가 각각의 역할을 수행합니다.
고민과 해결
AI 할루시네이션, 분석 품질 저하, 동일 클래스 중복, JSON 파싱 불안정 등 4가지 문제를 해결했습니다.
Slack 연동
분석 결과를 Slack Block Kit 서식으로 CRITICAL/WARNING 심각도와 함께 발송합니다.
효과
| 지표 | Before | After |
|---|---|---|
| 에러 대응 방안 | 수동적으로 파악 | 알람 기반으로 자동 판단 |
| 무시 가능 에러 확인 | 하나하나 로그 열어서 판단 | AI 자동 분류 |
| 소스코드 확인 | 소스코드에서 파일명, 위치 검색 | GitLab API로 자동 조회 |
| 새벽 대응 | 노트북 켜서 로그 조회 | Slack으로 수신, 폰으로 판단만 |
눈여겨볼 점
- Two-Pass 구조가 영리합니다. Phase 1에서 17건의 alert를 중요/무시로 먼저 분류하고, Phase 2에서 중요한 것만 심층 분석합니다. AI 비용과 분석 품질을 동시에 잡는 구조입니다.
- 실전에서 부딪힌 문제들을 하나씩 풀어간 과정이 값집니다. "로그에서 직접 판단하라"는 프롬프트 전환으로 할루시네이션을 잡고, 에러 1건=AI 1호출 원칙으로 분석 퇴화를 막았습니다. JSON 파싱 불안정은 stop_sequences + fallback으로 대응했습니다.
- GitLab 소스 조회에는 AI를 쓰지 않습니다. 에러 위치(CartService.java:362)에서 파일명과 라인을 추출해 GitLab API로 ±15줄 스니펫을 가져오는 방식이라, 비용은 줄이면서 분석 컨텍스트는 풍부하게 확보했습니다.