RCA 품질을 감으로 판단하지 않기: Evidence Quality와 회귀 게이트

신호가 검출됐다고 바로 원인이라고 말할 수는 없다

초기 Rule Engine은 disk.root_usage_percent=96과 같은 값을 임계값과 비교해 disk_usage_critical 신호를 만들었다. 규칙은 결정론적이어서 같은 입력에는 같은 결과를 낸다. 하지만 운영 환경에서 더 어려운 문제는 입력 자체의 상태였다.

• Evidence가 2시간 전에 수집된 값일 수 있다.
• 필요한 Collector 일부가 권한 문제로 실패할 수 있다.
• Agent는 살아 있지만 특정 로그 경로만 읽지 못할 수 있다.
• 필드 이름이나 타입이 Agent 버전에 따라 달라질 수 있다.
• 정상 경계값을 장애로 오판할 수 있다.

이 상태에서 신호 개수만 보고 confidence를 높이면 “수집하지 못한 것”을 “문제가 없는 것”으로 오해할 수 있다. 그래서 Signal Detection과 별도로 Evidence Quality를 계산했다.

Collector 계약부터 고정하기

Node Agent의 14개 Collector와 Backend 분석기 사이에 collector-evidence/v1 계약을 만들었다. 각 필드의 타입, alias, 단위와 필수 여부를 정의한다.

알려진 alias는 canonical 필드로 복사하지만, 잘못된 타입을 임의로 숫자로 추정하지는 않는다. 등록되지 않은 Collector도 입력에서 삭제하지 않고 상태를 unknown으로 기록한다.

Agent raw output
  → schema version 확인
  → alias 정규화
  → 타입 검증
  → 원본 유지
  → detector 입력 생성

계약이 틀렸다고 Report 전체를 버리지는 않는다. 대신 invalid_collector_count, unknown_collector_count와 Collector별 상태를 Report Evidence에 남긴다. 운영자는 원본 값과 Agent 버전을 함께 확인할 수 있다.

Evidence Quality에 포함한 항목

품질 평가는 다음 세 영역을 본다.

1. Freshness: 수집 시각과 현재 시각의 차이
2. Collector status: 예상 Collector의 누락·실패·degraded 여부
3. Agent health: 수집 Agent가 정상 heartbeat 상태인지

결과는 complete, partial, stale, insufficient 같은 상태와 점수로 정리한다. Evidence가 오래됐거나 일부 Collector가 실패하면 confidence penalty를 적용하되, 기존 Rule signal을 삭제하지는 않는다.

오래된 Evidence에서 디스크 신호가 검출됐다는 사실과 지금도 디스크 장애가 지속된다는 판단은 다르기 때문이다.

Report Quality Gate

Evidence Quality, Rule signal 수, 높은 confidence 신호 수와 최상위 원인 후보 점수를 조합해 Report Quality Gate를 만들었다.

이 Gate는 자동화 권한이 아니다. pass라고 해서 조치를 실행할 수 있는 것은 아니며, Policy Engine은 별도로 모든 Action을 분류한다.

limited 상태에서는 LLM이 기존 confidence를 올리지 못하게 하고, 먼저 stale 또는 failed Collector를 다시 수집하도록 안내한다. insufficient 상태는 과감하게 “모른다”라고 표현한다.

회귀 테스트를 수치로 만들기

Rule을 추가할 때 특정 장애 하나만 통과하도록 테스트하면 정상 환경의 false positive가 늘어날 수 있다. 그래서 golden scenario에 precision, recall과 Top-K 기준을 붙였다.

Micro precision >= 0.90
Micro recall >= 0.95
Top-1 expected signal hit >= 0.90
Top-3 expected signal hit >= 0.95

여기에 실제 Agent E2E 구조를 비식별화한 production-like corpus를 분리했다. 정상 containerd와 CRI-O, 임계값 바로 아래 값, disk·DNS·etcd 복합 장애, journal 접근 실패와 file fallback처럼 운영에서 흔한 변형을 포함했다.

Gate가 실패하면 임계값을 낮춰 통과시키지 않는다. 어떤 case에서 false positive 또는 false negative가 생겼는지 artifact로 확인하고 Detector나 fixture의 기대값을 다시 검토한다.

이 구조를 선택한 이유

RCA 플랫폼의 가장 위험한 실패는 보고서를 만들지 못하는 것이 아니라, 불완전한 근거를 완전한 결론처럼 보여주는 것이다. 그래서 정확도 숫자 하나보다 다음을 함께 표현하도록 했다.

• 수집 계약이 맞는가
• 데이터가 최신인가
• 필요한 Collector가 모두 동작했는가
• Rule 결과가 회귀 기준을 통과했는가
• 결론을 어느 수준까지 신뢰할 수 있는가

운영 도구에서 unknown과 limited는 실패한 UX가 아니다. 잘못된 확신을 줄이는 중요한 상태다.

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