26S15c

QK·2026년 9월 15일

대규모 K8s 데이터 레이크하우스 환경에서 1) 운영지식 기반화(Knowledge Base)와 2) 이벤트 발생 시 컨텍스트 정제(로그 축약/메트릭 선별) $\to$ 원인 분석 $\to$ 승인 후 실행(HITL)으로 이어지는 에이전트 시스템을 밑바닥부터 구축하는 실무 4단계 로드맵입니다.

Step 1. 운영지식(Knowledge Base) 자산화 및 하이브리드 파이프라인 구축

단순히 Markdown 문서를 무작정 쪼개 넣으면 모델이 명령어의 맥락이나 에러 코드의 인과관계를 놓치기 쉽습니다.

문서 구조화 및 메타데이터 주입:
SOP, 벤더 공식 문서, 과거 장애 보고서(Post-mortem) 상단에 구조화된 헤더(Frontmatter)를 강제합니다.

---
component: minio-aistor # 또는 cilium, iceberg, trino 등
severity_trigger: High
related_metrics: [minio_node_drive_total_duration_microseconds, kube_pod_status_phase]
error_patterns: ["slow down", "context deadline exceeded", "connection reset"]
---

SRE 특화 청킹(Chunking) 규칙:
텍스트 길이 기준 단순 분할 금지: 마크다운 2~3단계 헤더(##, ###) 단위로 끊되, 코드 블록(bash ... )과 주의사항(Callout) 블록은 한 청크 내에 완전히 보존합니다.

B300 GPU 1번을 활용한 하이브리드 인덱싱:
Dense & Sparse 벡터 생성: BGE-M3 모델로 Dense 임베딩과 Sparse 토큰 가중치(SPLADE 계열)를 동시 추출하여 사내 Milvus 또는 Qdrant에 적재합니다. (키워드/에러 코드는 Sparse가, 장애 정황 설명은 Dense가 커버)
Cross-Encoder Reranker 구성: 실시간 서빙을 위해 TEI(Text Embeddings Inference) 컨테이너로 bge-reranker-v2-m3를 GPU 1번에 상시 띄웁니다.

Step 2. 대용량 로그 및 Prometheus(Thanos) 메트릭 다이어트 (컨텍스트 정제)

초거대 컨텍스트 윈도우를 가진 LLM이라도 노이즈가 섞인 수십만 라인의 로그와 무분별한 메트릭 덤프를 그대로 받으면 환각(Hallucination)을 일으키고 TTFT 지연이 심해집니다.

로그 축약(Log Compaction) 2단계 필터링:
1차 룰 기반 축약 (Drain / Fluentbit 파이프라인):
동일한 에러 템플릿(예: 연결 재시도 로그 5,000건)이 반복될 경우 정규표현식 기반 로그 파서(Drain3 등)로 [Repeated 5,420 times] connection timed out to storage-node-04:9000 형태로 단일 라인 압축합니다.
2차 에러 윈도우 슬라이싱:
알람 발화 시각 기준 [-10분 ~ +5분] 구간 중 ERROR, FATAL, WARN, panic, backoff 레벨만 남기고 INFO/DEBUG는 전량 드롭합니다.

Thanos/Prometheus 메트릭 선별 (2-Hop 쿼리 전략):
Hop 1 (정적 코어 메트릭 팩 수집):
알람이 뜬 컴포넌트(Label 기준)에 미리 매핑된 기본 메트릭 세트(CPU/Mem Throttle, Pod Restart Count, Disk I/O Latency, 네트워크 패킷 드롭 등 5~7개)만 1차로 뽑아옵니다.
Hop 2 (경량 Router Agent의 동적 PromQL 생성):
GPU 0번(14B 모델)에 1차 수집된 에러 로그 요약과 Prometheus 메트릭 카탈로그(스키마 명세)를 전달합니다. Router Agent가 "이 에러는 디스크 쓰기 병목이 의심되니 드라이브별 레이턴시와 대기 I/O 큐 메트릭을 추가 조회하라"는 정밀 PromQL 1~2개를 생성하여 Thanos API를 2차 질의합니다.

지표 압축 (Vectorizing & Summarization):
15분간의 초 단위 원시 시계열을 수치 배열 그대로 넘기지 않고, 파이썬 전처리 모듈을 거쳐 통계량(min, max, avg, p99, 추세: 급상승) 요약 테이블로 변환하여 LLM에 주입합니다.

Step 3. LangGraph 기반 인시던트 오케스트레이션 상태 머신 설계

단순 선형 체인이 아니라 조건부 분기(Conditional Edge)와 상태 추적이 가능한 그래프를 구현합니다.

핵심 State 정의 (AgentState):
alert_info: Alertmanager 페이로드
compacted_logs: 압축된 핵심 에러 스택
metrics_summary: Thanos에서 선별한 이상 지표 요약
retrieved_sops: Reranking을 통과한 상위 3개 SOP
rca_hypothesis: 추론된 원인 가설 및 검증 결과
mitigation_plan: 실행 계획 및 커맨드

노드(Node) 및 흐름 배치:

TriageNode (GPU 0): 알람 파싱 및 1차 로그/메트릭 쿼리 생성
ContextFetchNode (Worker): K8s API / Loki / Thanos 조회 및 텍스트 압축
RetrieveSOPNode (GPU 1): 하이브리드 검색 및 Cross-Encoder 리랭킹
AnalyzeRCANode (GPU 2~7, DeepSeek-R1 FP8): CoT(사고 연쇄) 기반 원인-결과 인과분석
GeneratePlanNode (GPU 0 or 2~7): SOP 기반 실행 스크립트 작성
SafetyAuditNode (Worker + LLM): 파괴적 명령어 검증 (kubectl drain, delete ns 차단)
HumanApprovalNode (LangGraph interrupt() 호출): 사람 승인 대기

Step 4. MITP (Human-In-The-Loop) 승인 및 실행 체계 구축

자동 실행으로 인한 2차 장애를 원천 방지하기 위해 승인 인터페이스와 격리된 실행 환경을 만듭니다.

인터랙티브 리포트 전송:
사내 메신저(Slack/Teams 웹훅) 또는 전용 웹 콘솔로 카드 형태의 리포트를 발행합니다.
원인 추론 요약: "스토리지 노드 #03의 드라이브 I/O 지연으로 인한 MinIO 타임아웃 (신뢰도 94%)"
근거 자료: 매칭된 사내 SOP 섹션 및 벤더 이슈 링크
제안 조치: mc admin heal ... 또는 대상 Pod 롤링 재시작 스크립트 (Diff 형태 제공)

실행 런타임 보안:
관리자가 콘솔에서 [승인(Approve)]을 누르면, LangGraph 워크플로우가 재개(resume)되면서 RBAC이 극도로 제한된 일회성 K8s Job을 트리거하여 스크립트를 수행하고 결과를 알림으로 회신합니다.

구현 우선순위 (권장 착수 순서)

Phase 1 (1~2주차 - 수작업 자동화):

장애 났을 때 사람이 직접 수집하던 로그/메트릭 패턴을 파이썬 스크립트(fetch_incident_context.py)로 만들어 "알람 발화 시 10초 만에 압축 요약 텍스트를 만들어내는 파이프라인"부터 완성합니다.

Phase 2 (3~4주차 - 지식 베이스 구축):

사내 SOP 및 주요 벤더 문서를 Markdown화하고, BGE-M3 + Reranker 기반 하이브리드 검색 인덱스를 구성해 검색 정확도를 테스트합니다.

Phase 3 (5주차~ - LangGraph 결합 & B300 노드 서빙):

B300에 추론 모델(DeepSeek-R1 / Qwen 14B)을 올리고 LangGraph 노드들과 결합하여, 인시던트 발생 시 슬랙으로 승인 요청 카드까지 뽑아내는 End-to-End PoC를 완성합니다.

engineer

이전 포스트

26S15b

다음 포스트