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

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

RCA 플랫폼에 LLM을 추가할 때 가장 먼저 정한 원칙은 “LLM이 원인을 결정하지 않는다”였다. Linux와 Kubernetes 장애는 그럴듯한 설명보다 재현 가능한 근거가 중요하다. Provider 응답이 느리거나 실패해도 기본 RCA가 멈춰서는 안 된다.

전체 순서는 다음처럼 유지했다.

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

Rule-based Analyzer가 기준 결과를 먼저 만든다. LLM은 이 결과를 읽기 쉽게 설명하고, 추가 확인 항목을 제안하는 보조 단계다.

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

Node Agent가 수집한 원본에는 긴 로그, 노드 식별자, 주소와 민감한 경로가 포함될 수 있다. 원본 전체를 Provider에 전달하면 비용과 보안 경계가 함께 커진다.

Backend는 LLM 호출 전에 다음 작업을 수행한다.

• 불필요한 필드와 크기 제한
• 민감정보 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도 외부 입력이다. Backend는 Report에 반영하기 전에 다음을 검증한다.

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

자유 형식 Evidence는 Report 근거로 사용하지 않는다. 알 수 없는 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한다.

Web Console의 Settings에서는 현재 설정 상태와 필요한 환경 변수만 보여준다. API key 값을 화면에서 입력받거나 DB에 저장하지 않는다. Secret, 환경 변수 또는 외부 Secret Manager를 통해 주입한 뒤 Pod나 프로세스를 재시작한다.

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

단위 테스트만으로는 실제 Provider의 응답 형식과 rate limit을 확인할 수 없다. Staging smoke를 만들되 호출 횟수와 비용 상한을 먼저 계산하도록 했다.

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

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

최악의 호출 수가 예산을 넘으면 Provider를 호출하기 전에 실패한다. 여러 실행을 모으는 burn-in도 같은 시간 구간에 이미 성공 표본이 있으면 다음 호출을 기다린다.

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

LLM은 새로운 장애 표현을 설명하는 데 유용하지만 같은 입력에 항상 같은 판단을 보장하지 않는다. 반면 운영자는 “어떤 필드가 어떤 임계값을 넘어서 이 신호가 만들어졌는가”를 다시 확인해야 한다.

그래서 역할을 다음처럼 나눴다.

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

AI를 사용하지 않는 것이 안전한 것이 아니라, 어디까지 맡길지 명시하는 것이 안전하다는 점을 배웠다.

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