수천만 개의 로그에서 장애 원인만 골라내는 법 — LLM 기반 AIOps와 로그 우선순위화

수천만 개의 로그에서 장애 원인만 골라내는 법 — LLM 기반 AIOps와 로그 우선순위화

AI 데이터센터와 GPU 클러스터에서는 엄청난 양의 로그가 발생합니다. 문제는 로그가 많을수록 장애 분석이 쉬워지는 것이 아니라 오히려 핵심 신호가 정상 메시지에 묻힌다는 점입니다.

로그가 너무 많다

GPU 드라이버, CUDA, Kubernetes, 스토리지, 네트워크, 데이터베이스 등 수많은 계층이 동시에 로그를 생성합니다. 대부분은 정상 상태를 알리는 정보성 메시지이고 실제 장애를 직접 설명하는 로그는 일부에 불과합니다.

LLM에 원시 로그를 넣을 수 없는 이유

수십 GB의 로그를 그대로 LLM에 넣으면 컨텍스트 한계를 넘고 추론 시간과 GPU 메모리 사용량이 급증합니다. 특히 폐쇄망이나 제한된 GPU 환경에서는 ‘더 큰 모델’을 쓰는 것보다 입력을 줄이는 기술이 더 중요합니다.

1단계: 의미 없는 로그 제거

Heartbeat, 정상적인 서비스 시작·종료, 반복 상태 확인처럼 장애 분석과 관련성이 낮은 로그를 제거합니다. 이것은 단순한 압축이 아니라 장애 분석 목적에 맞는 데이터 정제입니다.

2단계: 이벤트 단위로 통합

동일한 GPU Xid 오류가 500번 발생했다면 500개의 로그를 모두 전달할 필요는 없습니다. 발생 시간, 횟수, 영향을 받은 노드와 함께 하나의 이벤트로 요약하면 중복을 크게 줄일 수 있습니다.

3단계: 중요도를 계산한다

심각도, 발생 빈도, 영향 범위, 시간적 집중도 등을 이용해 이벤트 우선순위를 정합니다. 그 결과 중요한 이벤트만 LLM에 전달되어 토큰 사용량과 분석 시간이 크게 줄어듭니다. 특집 원고의 실험에서는 로그 변환으로 상당량을 제거하고 최종 LLM 입력 토큰을 원시 로그 대비 99% 이상 줄이면서 핵심 장애 이벤트는 유지하는 결과가 제시됩니다.

산업 장비에도 그대로 적용 가능

이 개념은 HPC에만 국한되지 않습니다. 모터 구동 시간, 실린더 동작, 비전 검사 결과, 통신 오류, 센서 상태를 이벤트로 통합하고 중요도를 부여하면 장비 이상 진단에도 활용할 수 있습니다. 즉, ‘모든 로그를 AI가 읽게 하는 것’보다 ‘AI가 읽어야 할 로그를 먼저 고르는 것’이 실용화의 핵심입니다.

참고 자료
한국정보과학회, 정보과학회지 2026년 9월호 「AI 시대의 HPC 인프라와 시스템 기술」 특집을 바탕으로 블로그용으로 재구성했습니다.

태그
#AIOps #로그분석 #LLM #장애진단 #GPU클러스터 #예지보전 #스마트팩토리 #산업용AI