LLM을 진단 보조로 제한한 RCA 파이프라인 설계

LLM을 붙이기 전에 역할부터 제한했다

LLM을 붙이기 전에 Rule-based 결과를 먼저 만들기로 했다. Provider 응답이 늦거나 실패해도 RCA가 멈추지 않아야 했고, 원인 후보의 근거를 다시 확인할 수 있어야 했다.

분석 순서는 다음과 같이 유지했다.

Evidence 전처리
  → Rule-based signal
  → 원인 후보와 정책 분류 Action
  → 선택적 LLM 설명 보강
  → Report 조립

Rule-based Analyzer가 기준 결과를 만들고, LLM은 설명 보강과 추가 확인 항목 제안을 맡도록 했다.

Raw log를 직접 보내지 않은 이유

Agent 원본에는 긴 로그, 노드 식별자, 주소, 민감한 경로가 포함될 수 있었다. Provider에 보낼 정보와 크기를 먼저 제한했다.

Backend에서 다음 전처리를 수행하도록 했다.

• 불필요한 필드와 크기 제한
• 민감정보 redaction
• Collector 상태와 Evidence Quality 요약
• Rule-based derived signal 생성
• 허용된 Evidence ID catalog 생성
• 이미 Policy Engine을 통과한 권장 조치 포함

LLM에는 preprocessed_evidence.payload만 전달했다. Supporting evidence는 입력에 포함된 Evidence ID를 참조하게 했다.

{
  "cause": "Filesystem capacity is critically high",
  "confidence": "medium",
  "supporting_evidence_ids": ["ev-0123456789abcdef"]
}

없는 ID를 참조하거나 Evidence 없이 제시한 원인 후보는 거부하도록 했다.

응답을 신뢰하지 않는 입력으로 다루기

Provider의 JSON 응답은 Report에 넣기 전에 다음 항목을 검증했다.

• 허용된 네 개의 최상위 필드인지
• candidate와 action item이 object인지
• Evidence ID가 실제 catalog에 있는지
• confidence 값이 low, medium, high 중 하나인지
• Action key 형식과 개수·문자열 길이가 제한 안에 있는지
• 실행 가능한 plan을 만들지 않았는지

자유 형식 Evidence는 근거로 채택하지 않았다. 알 수 없는 Action key는 manual_investigation으로 낮췄다. LLM의 모든 Action에는 automation_allowed=false, executable=false를 저장하고 Policy Engine을 다시 통과시켰다.

Provider 실패를 RCA 실패로 만들지 않기

LLM timeout, 인증 오류, schema validation 실패가 나더라도 Rule-based Report는 생성하도록 했다.

LLM disabled  → skipped
Provider 오류 → failed
정상 응답     → completed

연속 실패가 기준을 넘으면 circuit breaker로 호출을 줄였다. Report에는 Provider, model, latency, token usage, 예상 비용을 남기고 API key와 인증 오류 원문은 redaction했다.

Console Settings에서는 설정 상태와 필요한 환경 변수만 보여줬다. API key를 화면에서 입력받거나 DB에 저장하지 않고, Secret·환경 변수·외부 Secret Manager로 주입한 뒤 재시작하도록 했다.

실제 Provider 검증도 호출 예산을 둔다

실제 Provider의 응답과 rate limit을 확인할 staging smoke도 만들었다. 호출 전에 횟수와 비용 상한을 계산하도록 했다.

무료 tier나 제한된 환경에는 다음 조건을 함께 적용했다.

application max attempts = 1
Spring AI internal retry = 1
connectivity test 생략
provider call budget = 1

최악의 호출 수가 예산을 넘으면 호출 전에 중단했다. burn-in에서도 같은 시간 구간에 성공 표본이 있으면 다음 호출을 기다리도록 했다.

왜 Rule-based를 기준으로 남겼나

LLM 응답은 같은 입력에서도 달라질 수 있다. 어떤 필드와 임계값에서 신호가 나왔는지 다시 확인할 수 있도록 Rule-based 결과를 기준으로 남겼다.

각 단계의 역할은 다음과 같다.

• Rule Engine: 신호와 기준 근거 생성
• LLM: 보조 설명과 추가 확인 항목
• Policy Engine: Action의 실행 경계 분류
• 운영자: 실제 변경 승인과 수행

LLM의 입력, 출력 검증, 호출 예산, 실행 권한을 분리해 관리하도록 구성했다.

프로젝트 저장소: Kubernetes Cluster Infra RCA Platform