HolmesGPT & CNCF 도구로 쿠버네티스 알림 자동 진단하기

15분 걸리던 알림 분석을 단 2분으로! 에스티씨랩의 SRE 팀이 LLM 기반의 쿠버네티스 알림 자동화 파이프라인을 구축하며 얻은 노하우를 공유합니다. AI 조사 품질을 결정짓는 핵심 키, '런북(Runbook)'의 힘을 알아보세요.

Daniel(원재인)

Apr 27, 2026

Contents

우리가 AI 조사 파이프라인을 구축한 이유 HolmesGPT: LLM 스스로 조사 방향을 결정한다 Robusta와 연동하기 모든 것을 바꾼 런북(Runbook)모델 도입 과정 실제로 중요한 것

아래 글은 에스티씨랩의 SRE Team, Grace & Ihyeok Song 두 멤버가 AI 파이프라인을 구축하며 배운 점을 작성한 것으로, CNCF(Cloud Native Computing Foundation) 블로그 콘텐츠 공모전에서 채택되어 포스팅되었습니다.
Auto-daignosing Kubernetes alerts with HolmesGPT and CNCF Tools
Posted on April 21, 2026 by Grace Park and Ihyeok Song, DevOps Engineer, STCLab SRE Team

우리가 AI 조사 파이프라인을 구축한 이유

에스티씨랩은 다수의 EKS 클러스터 환경에서 ‘가상 대기실 솔루션, 넷퍼넬(NetFUNNEL)’과 ‘봇 매크로 관리 솔루션, 봇매니저(BotManager)’를 SaaS 플랫폼으로 서비스하고 있습니다.

OpenTelemetry를 통해 Mimir, Loki, Tempo로 데이터를 보내는 완전한 옵저버빌리티(Observability) 스택을 갖추고 있으며, 오픈소스 Robusta를 사용해 프로메테우스(Prometheus) 알림에 에러 로그, 그라파나(Grafana) 링크, 담당 팀 멘션 등을 풍부하게 추가하여 슬랙으로 전송하고 있습니다.

문제는 데이터가 아니라 그 다음이었습니다. 알림이 오면 매번 파드(Pod)를 확인하고, 프로메테우스 쿼리를 확인하고, Loki 로그를 살펴보고, 트레이스 데이터를 가져와 상관관계를 파악하는 똑같은 작업을 반복해야만 했습니다. 이 작업은 매번 15분에서 20분 정도 소요되었습니다. 저희는 이 과정을 자동화하고, 그 결과를 동일한 슬랙 스레드에서 바로 확인하기를 원했습니다.

HolmesGPT: LLM 스스로 조사 방향을 결정한다

HolmesGPT(CNCF 샌드박스 프로젝트)를 선택한 이유는 ReAct(Reasoning and Acting) 패턴의 작동 방식 때문입니다. LLM이 알림을 읽고, 도구를 선택하고, 결과를 확인한 다음 무엇을 조사할지 스스로 결정할 수 있습니다.

예를 들어, 파드가 재시작되면 종료 코드(Exit code)부터 확인하고, VPC 피어링을 통해 클러스터 간 Loki 로그를 가져온 뒤, 프로메테우스에서 CPU 상태를 살펴볼 수 있습니다. 정해진 스크립트를 따르는 것이 아니라, 모델이 실제로 발견한 내용에 따라 조사 경로가 유동적으로 달라집니다.

이는 저희 환경에서 특히 중요했습니다.네임스페이스마다 환경이 다르기 때문입니다. 중앙 집중식 로그, 분산 추적 등 모든 것이 갖춰진 네임스페이스가 있는 반면, 멀티 테넌트 워크로드처럼 아무것도 없는 경우도 있습니다. 이런 네임스페이스에서는 kubectl과 프로메테우스만 사용할 수 있습니다.

저희는 이러한 환경의 차이를 마크다운(Markdown) 형태의 런북(Runbook)에 기록하고, 각각 메타데이터 헤더를 추가했습니다.

## Meta
scope: namespace=<target> only
tools: kubectl, prometheus, loki, tempo
caution: some containers excluded from log collection → use kubectl logs

Holmes는 조사 초반에 fetchh_runbook을 호출합니다. 이 메타데이터를 통해 어떤 도구를 사용할 수 있고, 어떤 도구를 건너뛰어야 하는지 파악합니다.

Robusta와 연동하기

약 200줄의 파이썬(Python) 코드로 작성한 커스텀 플레이북은 HolmesGPT가 자체적으로 커버하지 못하는 영역을 처리합니다.

Robusta는 Holmes가 조사를 마치기 전에 슬랙에 알림을 전달하기 때문에, 플레이북은 나중에 올바른 스레드를 찾아 결과를 답글(Reply)로 달아주어야 합니다. 롤아웃(Rollout) 중에 프로메테우스가 파드마다 알림을 하나씩 발송하면, 플레이북이 워크로드 단위로 핑거프린팅(Fingerprinting)을 수행해 30분 동안 중복 알림을 억제합니다. 또한, Robusta가 네이스페이스별로 다른 슬랙 채널에 라우팅하기 때문에, 플레이북이 해당 매핑 정보를 그대로 복제해 어느 채널에 메시지를 게시할지 결정합니다.

모든 것을 바꾼 런북(Runbook)

처음에는 어떤 모델을 선택할지에만 집중했습니다. 하지만 실제로 조사 품질을 결정지은 것은 바로 ‘런북’이었습니다.

런북이 없으면 모델은 그저 추측만 할 뿐입니다. 사이트카가 없는 네임스페이스에서 Istio 메트릭을 확인하거나, 아무것도 수집되지 Loki에 쿼리를 날리기도 합니다. 결국 무한 루프에 빠져 예산을 소진한 뒤, “더 많은 정보가 필요합니다”라는 허무한 답변만 내놓게 됩니다.

이 문제를 해결한 건 더 좋은 모델이 아니었습니다. 모델에게 무엇을 하지 말아야 할지를 알려주는 것이었습니다. 런북에 예외 규칙(“이 네임스페이스에는 Loki, Tempo, Istio 없음. kubectl과 PromQL만 사용”)을 추가하자, 조사마다 낭비되는 도구 호출 횟수가 16회에서 2회로 급감했습니다.

이를 명확히 확인하기 위해 통제된 비교 실험도 진행했습니다. 동일한 ClickHouse 핸드쉐이크(Handshake) 알림을 네 가지 방식으로 테스트했습니다. 런북이 있을 때 Holmes는 3~4번의 도구 호출만으로 알려진 에러 패턴을 파악했고, 나머지 예산으로 검증을 진행했습니다. 반면 런북이 없을때는 프록시 스케일링, 스키마 불일치, 포트 설정 오류 등 완전히 엉뚱한 세 가지 가설을 쫓느라 20번 이상의 스텝을 소진하고 나서야 결론에 도달했습니다.

모델도 같았고, 알림도 같았습니다. 런북이 정답을 알려준 게 아닙니다. 검색 공간을 충분히 좁혀줬기 때문에 단지 12번의 스텝 예산으로도 충분했던 것입니다.

현재 에스티씨랩은 네임스페이스와 알림 유형별로 세분화된 7개의 런북을 관리하고 있습니다. 조사 결과가 틀렸을 때 가장 먼저 던지는 질문은 “더 좋은 모델이 필요한가?”가 아니라 “런북이 이 케이스를 커버하고 있는가?” 입니다.

동일한 알림, 동일한 모델. 왼쪽: 런북 가이드 적용 / 오른쪽: 런북 미적용 결과 비교 이미지

모델 도입 과정

저희는 셀프 호스팅과 매니지드 호스팅 환경을 넘나들며 총 7개의 모델을 테스트했습니다.

처음에는 KubeAI(CNCF)로 관리되는 스팟 GPU에서 셀프 호스팅을 시도했습니다. 7B 모델은 유효한 도구 호출을 만들어내지 못했습니다. 9B 모델의 추론(Thinking) 모드는 ReAct 루프와 충돌히 빈 응답만 반환했습니다. 14B 모델은 가능성이 있어 보였지만, 스팟 인스턴스 회수(eviction)로 인해 실행이 자주 끊겼고, Karpenter가 노드를 프로비저닝하는 데 발생하는 콜드 스타트(Cold start)가 5~8분이나 소요되었습니다.

이후 VPC 엔드포인트를 통한 매니지드 API를 테스트했습니다. 클러스터 데이터가 자사 인프라 내에서 머무르게 하는 방식입니다. 여기서도 대부분의 모델이 제대로 동작하지 않았고, 여러 모델이 HolmesGPT의 프롬프트 캐싱 마커(prompt caching markets)를 처리하지 못해 문제를 일으켰습니다.

한국어 출력, 슬랙 포맷팅, 런북 조회, 클러스터 간 로그 상관관계 분석 등 저희가 필요로 하는 모든 조건에 부합하는 모델 패밀리는 단 하나였습니다. 파드 ID 인증 관련 3줄짜리 업스트림 수정(PR #1850, 머지 완료)도 기여했습니다.

현재는 스테이징 환경에서는 셀프 호스팅을, 프로덕션 환경에서는 매니지드 API를 사용하는 하이브리드 구성을 운영하고 있습니다. 이 둘 사이의 전환은 YAML 블록 하나만 수정하면 될 정도로 간단합니다.

modelList:
  primary:
    model: "provider/model-name"    # 프로바이더 및 모델 ID 교체
    api_base: "https://endpoint"    # 매니지드 API 또는 셀프 호스팅 엔드포인트
    temperature: 0

조사 1건당 비용은 약 0.04$로, 월 평균 약 12$ 수준입니다. 백엔드가 바뀌어도 파이프라인, 플레이북, 런북은 전혀 수정할 필요가 없습니다.

실제로 중요한 것

몇 가지 수치를 요약해 공유합니다.

워크로드 단위의 중복 제거를 통해 하루 약 40건의 raw 알림을 약 12건의 고유한 조사 건으로 줄였습니다. 엔지니어들이 수동으로 15~20분씩 트리아지(Triage)를 하는 대신, 스레드에 요약된 내용을 2분 이내에 읽고 상황을 파악합니다. 전체 조사의 약 40%는 자동으로 해결됩니다. OOMKilled, ImagePullBackOff 등 Holmes가 런북과 매칭해 근본 원인을 바로 파악하는 알려진 패턴들입니다.

위와 같은 파이프라인 구축을 시작하려는 팀들에게 전하고 싶은 팁이 있습니다.

모델보다 런북이 먼저입니다.
같은 모델, 동일한 알림에 대해 런북이 있을 때는 5점 만점에 4.6점, 없을 때는 3.6점을 기록했습니다. 런북에 작성한 예외 규칙이 그 어떤 모델 교체보다 더 큰 성능 향상을 가져왔습니다.
글루 코드(Glue code)는 실제 작업입니다.
200줄의 플레이북이 타이밍 동기화, 중복 제거, 라우팅, 스레드 매칭을 처리합니다. HolmesGPT는 추론을 담당합니다. 이 둘 모두가 필요합니다.
모델 교체를 염두에 두고 설계하세요.
지금까지 백엔드를 세 번 교체하는 동안, 파이프라인은 전혀 건드리지 않았습니다. 플레이북은 안정적인 코어(Core)로 두고, 모델은 언제든 교체 가능한 부분입니다.

개발 스토리