Notice
Recent Posts
Recent Comments
Link
«   2026/06   »
일 월 화 수 목 금 토
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
Tags more
Archives
Today
Total
관리 메뉴

근묵자흑

AIOps 스터디 5주차 - RCA 본문

AIOps

AIOps 스터디 5주차 - RCA

Luuuuu 2026. 5. 9. 20:32

4주차에서는 "이 incident의 영향 범위는 어디까지인가"를 service graph로 답했습니다.
5주차는 그 범위 안에서 "그래서 무엇이 원인인가"를 다룹니다.
다만 이 답은 데이터만으로는 닫혀 풀리지 않는다는 점을 함께 짚어두려 합니다.

 

1. 무엇이 다른가?

 

4주차의 service graph는 "어디까지 이 사건이 퍼졌는가"를 다뤘습니다. 5주차의 RCA는 그 범위 안에서 "왜 이렇게 되었는가"를 묻습니다. 한 단계 더 들어간 질문이지만, 그 한 단계 사이에서 데이터만으로 답이 닫히던 단계와 닫히지 않는 단계가 갈라집니다.

flowchart LR
    A["Detection<br/>비정상인가?"] -->|대부분 닫힘| B["Correlation/Scoping<br/>어디까지 영향인가?"]
    B -->|토폴로지 있으면 닫힘| C["RCA<br/>왜 그렇게 되었나?"]
    C -.->|닫히지 않음<br/>인과·암묵지 의존| D[?]

    style A fill:#e8f5e9,stroke:#2e7d32
    style B fill:#e8f5e9,stroke:#2e7d32
    style C fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style D fill:#ffebee,stroke:#c62828,stroke-dasharray: 5 5

여기서 "닫힌다"는 표현은 입력 데이터 안에서 정답이 결정된다는 뜻입니다. Detection은 시계열 패턴만 보고 임계치 위반 여부를 판정할 수 있으니 닫힙니다. Correlation도 service graph가 주어져 있으면 시간·위치 근접성만으로 묶을 수 있어 닫힙니다. 그러나 RCA는 입력 시계열 자체가 답을 결정하지 않습니다. 같은 신호도 토폴로지가 어떻게 그려져 있느냐, 운영자가 과거에 비슷한 사건을 본 적이 있느냐에 따라 다른 결론으로 갑니다.

이 어려움이 어디에서 오는지 구체적인 예로 보겠습니다. 다음은 K8s 환경에서 흔한 인과 사슬입니다.

flowchart LR
    A[새 버전 배포] --> B[ConfigMap 변경]
    B --> C[DB pool maxSize 축소]
    C --> D[connection 고갈]
    D --> E[query 대기 누적]
    E --> F[API latency 급증]

    style A fill:#fce4ec,stroke:#880e4f
    style F fill:#ffebee,stroke:#c62828,stroke-width:2px

운영자가 보는 증상(symptom)은 맨 오른쪽의 latency 급증이고, 진짜 원인(root cause)은 맨 왼쪽의 배포로 인한 ConfigMap 변경입니다. 그 사이를 잇는 다섯 단계의 화살표는 데이터에는 직접 보이지 않습니다. 이 사슬을 채우려면 토폴로지(어느 서비스가 어느 DB를 쓰는지), 운영 컨텍스트(이 ConfigMap이 어떤 Pod에 마운트되는지), 과거 incident의 암묵지(지난 분기에도 비슷한 일이 있었다)가 함께 있어야 합니다.

1.1 RCA의 출력은 단일 답이 아니라 후보 리스트입니다

RCA를 처음 다루는 운영자가 흔히 빠지는 함정 중 하나는 "한 줄짜리 답"을 기대하는 것입니다. 다음 두 가지 출력 형태를 비교해 보면 차이가 분명해집니다.

기대하는 형태는 이런 모습입니다.

RCA: 원인 = payment-db
RCA: 원인 = payment-db CPU 100%

학술 논문이나 실제 시스템에서의 RCA 출력은 다음에 가깝습니다.

RCA top-3 probable cause:
  1. payment-db        (confidence 0.62)
  2. payment-app       (confidence 0.21)
  3. payment-cache     (confidence 0.09)

+ 결정적 단서 후보:
  - ConfigMap diff (db.pool.max 50 → 5)
  - deploy event @ 11:42
  - db.wait p99 상승

이 출력에는 두 가지 정보가 들어 있습니다. 하나는 probable cause 후보 리스트로, 보통 top-k 형태입니다. 다른 하나는 모델이 그 후보를 얼마나 강하게 의심하는지를 나타내는 confidence score입니다.

이 confidence는 일기예보의 강수확률과 같은 형태로 읽으면 정확합니다. "70% 비"가 "내가 70% 확신한다"는 뜻이 아니라 "비슷한 상황에서 70%는 비가 왔다"는 뜻인 것처럼, RCA의 confidence 0.62도 "62% 확실히 원인"이 아니라 "비슷한 패턴에서 62%는 이 노드가 원인이었다"에 가깝습니다.

 

이 차이를 무시하면 자동화 단계에서 문제가 생깁니다. 운영자가 top-1을 자동으로 incident root cause 라벨로 박는 순간, 잘못된 학습 신호가 모델에 다시 들어가 누적됩니다. 다음 절에서 다룰 cold-start 문제와 이 자동 라벨링이 결합되면 모델은 한 번 빠진 오답에서 빠져나오기 어려워집니다.

1.2 ML 기반 RCA의 구조적 한계 다섯 가지

위 출력 형태를 출발점으로 두면 ML 기반 RCA의 다섯 가지 구조적 제약이 보입니다.

  • 첫째는 확률적 본성(probabilistic nature) 입니다. 모델이 내놓는 것은 결정적 답이 아니라 후보 리스트이므로, 운영자가 마지막 단계에서 검증해야 합니다. 같은 입력을 같은 모델에 넣어도 토폴로지가 살짝 바뀌거나 random seed가 다르면 후보 순위가 바뀝니다. 이는 버그가 아니라 설계상의 출력 형태입니다. 자동화의 천장이 여기에서 한 번 형성됩니다. 실무적으로는 top-1만 보고 incident를 종결하지 않고 top-3까지 결정적 단서와 교차 검증하는 운영 습관이 필요합니다.
  • 둘째는 cold-start 문제 입니다. 신규 장애 유형은 학습 데이터에 없으므로 모델이 사실상 처음 보는 패턴을 다뤄야 합니다. 학습 데이터가 부재하면 confidence 자체가 의미를 잃고, top-k 후보는 "그냥 자주 보던 노드"로 채워집니다. LLM 기반 접근이 이 문제를 해결한다는 인상을 주지만, 좀 더 정확하게는 "라벨 부족 문제를 context 부족 문제로 옮긴" 것에 가깝습니다. LLM이 잘 동작하려면 runbook, integration, dependency graph 같은 운영 컨텍스트가 필요하며, 이 컨텍스트도 누군가 미리 정리해 두어야 합니다.
  • 셋째는 암묵지 의존(tribal knowledge dependency) 입니다. "이 서비스는 매주 화요일 새벽에 트래픽이 튄다", "이 alert는 사실 누구도 신경 쓰지 않는다" 같은 지식은 문서에도 모델에도 없고 운영자의 머릿속에만 있습니다. 새벽 호출에 응답한 선임 SRE가 "아, 또 그 캐시야. 어제 인덱스 마이그레이션 풀 때 캐시 워밍이 안 끝나서 그래"라고 정확히 진단하는 경우가 자주 있습니다. 그 지식은 어디에도 학습 데이터로 들어가 있지 않습니다. 모델의 top-k 옆에 운영자가 "맞았다 / 틀렸다 / 진짜 원인은 이것이다"를 기록하는 feedback loop가 없으면, RCA 모델은 영원히 처음 그 자리에 머무릅니다.
  • 넷째는 라벨링 병목(labeling bottleneck) 입니다. "이 사건의 진짜 원인은 X였다"는 정답 라벨을 만드는 데 incident 하나당 사람 시간이 들어갑니다. 더 까다로운 점은 라벨에 편향이 끼어든다는 것입니다. 라벨된 case는 대개 해결된 incident이고, 미해결이거나 오진된 case는 라벨이 달리지 않습니다. 모델은 결과적으로 "쉬운 incident"만 학습하게 됩니다. 또한 사후 라벨링은 "그때 알았다면 이게 원인이었다"는 식으로 정리되어, 실시간 시점에는 보이지 않았던 신호까지 정답에 반영되어 들어갑니다.
  • 다섯째는 토폴로지 부정확성(topology inaccuracy) 입니다. 4주차에서 stale topology가 correlation을 어긋나게 한다고 다뤘습니다. 5주차에서는 그 해악이 더 커집니다. correlation 단계에서는 묶음이 약간 어긋나도 운영자가 수동으로 합치면 됩니다. 그러나 RCA 단계에서는 후보 노드 자체가 틀리면 운영자가 잘못된 노드를 30분 동안 조사하게 되고, 이 시간이 그대로 골든 타임의 손실로 이어집니다. 4주차의 SDG 정확도가 correlation의 천장이었다면, 5주차에서는 RCA의 천장이 됩니다. 그리고 그 천장은 더 낮아집니다.

보강 출처: A Survey of AIOps in the Era of LLMs (arXiv:2507.12472, 2025) — 2020-2024년 183편을 분석하며, "context availability가 모델 지능보다 RCA 성능을 더 결정한다"는 결론을 제시.

 

2. 두 갈래 접근 — 가정의 차이가 곧 한계의 차이입니다

이 절의 비교 축은 "각 알고리즘이 무엇을 가정하는가"입니다. 정확도 절대 비교가 아니라, 어떤 가정이 어떤 환경에서 깨지는지를 보는 자리입니다.

 

참고 : https://devstory.tistory.com/81

2.1 Graph-based RCA — 대표적으로 MicroRCA (NOMS 2020)

Graph-based 접근은 service dependency graph(SDG)가 이미 주어져 있다 는 것에서 출발합니다. 노드는 서비스, 엣지는 호출이나 의존 관계입니다. 알고리즘은 이 그래프 위에서 anomaly가 어떻게 전파되었는지를 따라가며 가장 그럴듯한 원인 노드에 점수를 부여합니다.

flowchart TB
    A["1️⃣ Attributed Graph 구성<br/>노드 = 서비스, 엣지 = 호출 관계<br/>속성 = response time, CPU, 메모리"]
    A --> B["2️⃣ Anomalous Subgraph 추출<br/>임계치를 벗어난 노드와<br/>그 인접 엣지만 분리"]
    B --> C["3️⃣ Personalized PageRank<br/>이상 노드에서 출발하여<br/>점수가 가장 높은 노드를 원인으로"]

    style A fill:#e3f2fd,stroke:#1565c0
    style B fill:#e3f2fd,stroke:#1565c0
    style C fill:#bbdefb,stroke:#1565c0,stroke-width:2px

데이터 입력은 서비스 간 응답 시간과 컨테이너·호스트 리소스 메트릭 정도이고, 추가 instrumentation은 거의 필요하지 않습니다. 강점은 결과의 해석 가능성입니다. "왜 이 노드인가"를 그래프 위 경로로 설명할 수 있습니다. 약점은 SDG가 정확하지 않을 때 점수 전파가 엉뚱한 방향으로 흘러가는 점, 그리고 cache miss로 갑자기 활성화되는 경로 같은 동적 의존성을 잘 못 잡는 점입니다.

2.2 Causal Discovery RCA — 대표적으로 AERCA (ICLR 2025 Oral)

Causal Discovery 접근은 SDG가 없어도 multivariate time series에서 인과 구조를 발견 한다는 발상에서 출발합니다. AERCA는 여기에 autoencoder 구조와 Granger causality를 결합합니다.

flowchart LR
    subgraph Train [학습 단계 - 정상 시계열]
        T1[Encoder] --> T2["Exogenous variable<br/>분포 학습"]
        T2 --> T3[Decoder<br/>Granger 기반 재구성]
    end

    subgraph Infer [추론 단계 - 이상 시계열]
        I1[Encoder] --> I2["Exogenous 출력이<br/>정상 분포에서 벗어남?"]
        I2 -->|크게 벗어난 변수| I3[Root Cause 후보]
    end

    Train -.->|학습된 정상 분포| Infer

    style T2 fill:#e8f5e9,stroke:#2e7d32
    style I3 fill:#fff3e0,stroke:#e65100,stroke-width:2px

이론적으로는 anomaly를 exogenous variable에 가해진 intervention 으로 정의하는 Pearl 식 SCM 위에 Granger causality를 얹은 형태입니다. 강점은 새로운 토폴로지나 미관측 의존성에 대한 robustness, 그리고 인과 그래프 자체를 자동으로 발견할 수 있다는 점입니다. 약점은 stationarity 가정과 충분한 표본 수 요구입니다. 그래프를 먼저 학습하고 그 위에서 다시 RCA를 하는 구조라 두 단계 모두에서 오차가 누적될 수 있습니다. 저자 본인도 논문에서 "이 가정이 깨지면 잘못된 결론이 나올 수 있다"고 명시합니다.

2.3 그 외 진영

위 두 갈래 외에도 RCA에는 여러 흐름이 있습니다. 전체 지형을 한눈에 보면 다음과 같습니다.

flowchart TB
    R[RCA 알고리즘 진영]

    R --> G[Graph 기반]
    R --> C[Causal Discovery]
    R --> S[통계 기반]
    R --> M[Multi-source]
    R --> L[LLM-agentic]

    G --> G1[MicroRCA<br/>NOMS'20]
    C --> C1[AERCA<br/>ICLR'25 Oral]
    C --> C2[CIRCA, RCD]
    C --> C3[CRFD<br/>TOSEM'26<br/>counterfactual]
    S --> S1[BARO<br/>FSE'24 Best Artifact]
    M --> M1[Eadro ICSE'23]
    M --> M2[Nezha FSE'23]
    M --> M3[TORAI FSE'26]
    L --> L1[HolmesGPT]
    L --> L2[K8sGPT]

    style S1 fill:#fff9c4,stroke:#f57f17,stroke-width:2px
    style M3 fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px

통계 기반 BARO (FSE 2024 Best Artifact Award)는 인과 그래프도 SDG도 사용하지 않습니다. Multivariate Bayesian Online Change Point Detection으로 변화점을 찾고, RobustScorer라는 비모수 가설 검정으로 원인 변수를 판정합니다. 단순함이 무기인 접근입니다.

Multi-source 계열 (Eadro, Nezha, TORAI)은 metric, log, trace를 한 모델 안에서 함께 사용합니다. 특히 TORAI (FSE 2026 Research Track, BARO 저자 그룹의 후속작)는 "모든 서비스에 trace가 있다"는 비현실적 가정을 깨는 데 초점을 둡니다. 컴파일된 software나 미지원 서비스가 service call graph에 빠져 있을 때 telemetry만으로 원인을 찍는 4단계(anomaly severity → clustering → causal analysis → hypothesis testing) 구조이며, 2026년 4월에 RCAEval에 baseline으로 통합되었습니다.

Counterfactual / 인과 후속작 도 활발합니다. Robust Root Cause Diagnosis using In-Distribution Interventions (arXiv:2505.00930, 2025)는 SCM의 abduction 단계가 분포 외(OOD) 상황에서 취약함을 처음 분석했고, DynaCausal (arXiv:2510.22613, 2025-10)은 autoscaling 같은 동적 토폴로지 변화에 대응하는 방향을 제시합니다. CRFD (ACM TOSEM 2026-02, DOI 10.1145/3796706)는 counterfactual reasoning을 multi-source observability에 적용했습니다.

LLM-agentic 계열 인 HolmesGPT와 K8sGPT는 LLM이 toolkit을 호출하면서 hypothesis-investigate loop를 도는 형태입니다. 자세한 동향은 §6에서 다룹니다.

LLM의 RCA 능력 자체를 평가하려는 두 벤치마크가 2025년에 나왔습니다.

OpenRCA (Microsoft, ICLR 2025)는 335개 failure에 대해 약 68 GB의 telemetry를 함께 제공하며, LLM이 이 데이터 위에서 root cause를 식별하는지를 측정합니다. Claude 3.5 + RCA-agent의 best 성능이 11.34%(balanced sampling 시 3.88%)였습니다. 이 벤치마크가 측정하는 것은 "대용량 텔레메트리 위에서의 failure localization 능력"이라는 좁은 정의입니다.

ITBench (IBM + UIUC)는 94개 운영 시나리오를 SRE, CISO, FinOps 세 페르소나로 나눠 평가합니다. SoTA 모델이 SRE 시나리오 13.8%, CISO 25.2%, FinOps 0%를 해결했습니다. 측정 단위는 "도구 호출까지 포함한 운영 task 해결률"이라 RCA보다 넓은 범위입니다.

두 벤치마크는 서로 다른 능력을 측정하므로 수치를 직접 비교할 수 없습니다. 둘 다 한 자리수에서 10%대라는 정성적 사실 정도가 "현 시점에서 LLM 단독 RCA는 production-ready와 거리가 있다"는 명제의 약한 증거 정도입니다. Traversal blog(2025)의 비판처럼 OpenRCA가 system structure를 직접 검증하지 않는 점을 감안하면, 11.34%라는 숫자는 "RCA 불능"보다는 "탐색과 구조 추론을 한꺼번에 요구하는 평가에서의 한계"로 읽는 편이 정확합니다.

3. 벤치마크가 드러내는 격차 — RCAEval (FSE 2026)

RCAEval은 마이크로서비스 RCA 알고리즘을 같은 인터페이스에서 비교할 수 있게 만든 벤치마크입니다. 이 절은 동일 데이터셋의 단일 서브셋에서의 baseline 순위를 다룹니다. 다른 데이터셋이나 fault type에서는 순위가 달라진다는 점을 미리 일러둡니다.

벤치마크의 데이터셋 구조는 다음과 같습니다.

flowchart TB
    R[RCAEval]
    R --> RE1[RE1 - 375 cases<br/>metric only<br/>5 fault type]
    R --> RE2[RE2 - 270 cases<br/>multi-source<br/>6 fault type]
    R --> RE3[RE3 - 90 cases<br/>code-level fault<br/>multi-source]

    RE1 --> S1[Online Boutique]
    RE1 --> S2[Sock Shop]
    RE1 --> S3[Train Ticket]
    RE2 --> S4[Online Boutique]
    RE2 --> S5[Sock Shop]
    RE2 --> S6[Train Ticket]
    RE3 --> S7[Online Boutique]
    RE3 --> S8[Sock Shop]
    RE3 --> S9[Train Ticket]

    style RE2 fill:#e1f5fe,stroke:#0277bd,stroke-width:2px

총 9개 데이터셋, 735개 failure case, 11개 fault type, 15개 baseline(2026년 4월 TORAI 추가 후 16개)이 들어 있습니다. 평가지표는 AC@1, AC@3, Avg@5, MAR(Mean Average Rank)입니다.

Train Ticket 시스템의 RE2 데이터셋에서 Avg@5 기준 결과를 단일 서브셋 예시로 가져오면 다음과 같습니다.

알고리즘 분류 Avg@5
BARO 통계, 그래프 없음 0.80
TraceRCA trace-only 0.77
PDiagnose multi-source 0.67
CIRCA causal 0.46
RCD causal 0.13

같은 RCD가 다른 데이터셋에서는 best 0.54까지 나오는 것을 보면, 알고리즘의 절대적 우열보다는 데이터셋과의 궁합이 더 큰 변수임을 알 수 있습니다.

이 결과에서 흥미로운 부분은 가장 단순한 BARO가 causal 계열보다 잘 나온다는 점입니다. 가장 그럴듯한 해석은 다음과 같습니다.

BARO가 causal보다 본질적으로 우월해서가 아니라, 현재의 마이크로서비스 RCA 데이터가 "강한 변화점은 많고 안정적 인과 구조를 배우기에는 나쁜" 체계라서 그렇습니다.

 

벤치마크의 fault injection이 신호 강도가 강한 형태이고, 마이크로서비스 환경 자체가 비정상성·짧은 지속·차원 폭증·autoscaling을 동반하는 점이 모두 causal discovery의 가정을 약화시키는 방향으로 작용합니다.

다만 BARO도 만능은 아닙니다. 같은 RCAEval에서 BARO는 DELAY/LOSS 같은 network fault에서 Avg@5가 0.46/0.54로 떨어집니다. 반면 resource fault(DISK)는 1.0에 가깝게 잡습니다. fault type별 강약이 분명하다는 점을 함께 적어 두는 편이 공정합니다.

4. K8s 시나리오 워킹 — "배포 → DB pool 오류 → latency"

이제 구체적인 시나리오에서 위 개념들이 어떻게 작동하는지를 보겠습니다.

증상은 API latency p99의 급증입니다. 가설은 새 버전 배포 시 hikari pool maxSize가 잘못 줄어들면서 connection이 고갈되고, DB query 대기가 누적되어 upstream에서 latency가 쌓이는 형태입니다.

이 사건의 시간축을 그려 보면 다음과 같습니다.

sequenceDiagram
    participant CI as CI/CD
    participant K as Kubernetes
    participant App as API Pod
    participant DB as Database

    CI->>K: 11:42 새 버전 배포
    K->>App: ConfigMap 갱신, Pod 재시작
    Note over App: pool maxSize 50→5 축소
    App->>App: 트래픽 처리 시작
    App->>DB: query 요청 (정상)
    Note over App: 11:43 connection 점유 누적
    App--xApp: pool acquire timeout
    App->>App: pending borrowers 증가
    Note over App: latency p99 ↑
    Note over DB: DB 메트릭은 정상

여기서 주목할 부분은 마지막 Note입니다. DB 서버 자체는 멀쩡하다는 점이 RCA에서 결정적입니다. DB 메트릭부터 보면 RCA가 엉뚱한 방향으로 갑니다.

4.1 풀이의 다섯 단계 골격

증상에서 원인까지 도달하는 운영자의 작업을 다섯 단계로 정리하면 다음과 같습니다. 이 골격을 먼저 잡아 두면 §4의 나머지 절들이 어디에 해당하는지가 분명해집니다.

flowchart LR
    A[1. 증상 확인<br/>latency P99 alert] 
    --> B[2. 영향 범위 묶기<br/>4주차 결과 재사용]
    B --> C[3. 후보 노드 ranking<br/>MicroRCA / AERCA류]
    C --> D[4. 결정적 단서 식별<br/>변경 시점 × 내용 × 직접 증거]
    D --> E[5. 검증·롤백<br/>rollout undo / shadow traffic]

    style D fill:#fff3e0,stroke:#e65100,stroke-width:2px

1단계와 2단계는 4주차까지 다룬 detection과 correlation이 이미 해결합니다. 3단계의 후보 ranking은 §2에서 본 MicroRCA, AERCA, BARO 같은 알고리즘이 자동으로 만들어 줍니다. 알고리즘이 끝나는 자리는 여기까지입니다.

5주차의 본질이 가장 진하게 드러나는 자리는 4단계의 결정적 단서 식별입니다. 알고리즘이 내놓은 후보 ranking 위에서 "정말로 이것이 원인인가"를 가르는 작업이고, 데이터 안에서 자동으로 닫히지 않는 단계입니다. §4의 나머지 절들은 이 4단계를 어떻게 진행해야 하는지를 다룹니다.

4.2 결정적 단서는 단일 신호가 아니라 시간순 결합입니다

이 시나리오에서 진짜 원인을 가리키는 것은 단 하나의 결정적 신호가 아닙니다. 다음 세 신호의 시간순 결합입니다.

변경 시점은 Deployment rollout 이벤트로, 11:42에 새 버전 배포가 일어났다는 사실을 알려 줍니다. 변경 내용은 ConfigMap diff로, db.pool.max가 50에서 5로 줄어들었다는 사실을 알려 줍니다. 직접 증거는 11:43부터 관측되는 pool 포화 신호로, in_use가 max와 같고 db.wait p99가 상승했다는 사실을 알려 줍니다.

 

이 셋이 따로 떨어져 있을 때를 생각해 보면 결합이 왜 필요한지가 분명해집니다. 변경 시점만 있으면 "뭔가 바뀌었다"는 사실은 알지만 무엇이 바뀌었는지는 모릅니다. 변경 내용만 있으면 "이 값이 바뀌었다"는 사실은 알지만 사고 시점에 그 변경이 실제로 적용되었는지를 모릅니다(이 부분은 §4.4에서 따로 다룹니다). 직접 증거만 있으면 pool이 고갈된 사실은 알지만 왜 고갈됐는지를 모릅니다.

세 신호가 같은 시간축 위에서 동시에 일치할 때, 운영자는 비로소 root cause를 충분히 압축할 수 있습니다.

flowchart LR
    T1["변경 시점<br/>deploy event<br/>11:42"]
    T2["변경 내용<br/>ConfigMap diff<br/>pool.max 50→5"]
    T3["직접 증거<br/>pool 포화·db.wait↑<br/>11:43~"]

    T1 --> M[원인 합치점]
    T2 --> M
    T3 --> M
    M --> R[Root Cause 압축]

    style M fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style R fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

알고리즘이 내놓는 후보 ranking 위에 이 세 신호의 합치점을 얹는 것이 §4.1의 4단계의 실체입니다.

4.3 신호별 평가표 — 결정적 단서로서의 가능성

수많은 신호 중 어느 것을 먼저 봐야 하는지를 "결정적 단서로서의 가능성"이라는 축으로 정리하면 다음과 같습니다.

신호 정보량 한계 결정적 단서 가능성
latency P99 metric 증상의 시작 시점·영향 노드 무엇이 원인인지 불명 낮음 (증상에 해당)
App log "pool exhausted" 직접적 원인 어휘 노이즈에 묻힐 수 있음 중-높음
K8s event: deployment rolled 변경 발생 시점 어떤 변경인지 불명 높음 (시점 매칭용)
ConfigMap diff: db.pool.max 변경의 의미 자체 즉시 적용 여부 별도 확인 결정적
trace span: db.wait p99 ↑ latency가 DB 대기에서 발생함을 입증 trace coverage 의존 높음
metric: connections.in_use vs max pool 포화 상태 직접 관측 노출 안 되어 있을 수 있음 결정적 (직접 증거)
OOMKilled / CrashLoopBackOff 컨테이너 죽음 pool 고갈에서는 발생 안 함 부수 (가설 배제용)

 

여기서 두 가지를 짚어 두려 합니다.

 

첫째, latency 자체는 결정적 단서가 아닙니다. 운영자가 처음 보는 신호는 항상 latency나 error spike이지만, 이 신호들은 증상에 해당하므로 원인을 가리지 못합니다. 운영 RCA가 무너지는 가장 흔한 경로는 "처음 본 신호가 가장 강하게 보이니까 그것을 원인으로 단정"하는 것입니다.

 

둘째, OOMKilled나 CrashLoopBackOff는 이 시나리오에서는 발생하지 않습니다. pool 고갈은 컨테이너가 죽지 않고 hang하는 형태이므로 이런 이벤트가 없습니다. 이 부재 자체가 인프라 장애 가설을 빠르게 배제하는 부수 신호로 작동합니다. RCA에서는 신호의 부재 도 단서가 됩니다.

4.4 ConfigMap 변경의 적용 시점 — eventual consistency 가드레일

운영 RCA에서 자주 빠지는 함정 하나를 짚어 두려 합니다. "ConfigMap을 11:42에 변경했고 alert가 11:45에 떴으니 ConfigMap이 원인이다"라는 추론은 항상 맞지 않습니다. ConfigMap은 즉시 적용되지 않기 때문입니다. 적용 시점은 주입 방식에 따라 다음과 같이 달라집니다.

주입 방식 갱신 시점
Volume mount kubelet sync 주기 의존(기본 약 1분), 컨테이너 재시작 불필요
subPath mount 갱신되지 않음. 컨테이너 재시작 필요
env from configMapKeyRef 컨테이너 재시작 전까지 미반영
Helm/ArgoCD가 함께 배포 rollout이 트리거되어 새 Pod에서만 새 값

따라서 "ConfigMap diff가 존재한다"는 사실과 "그 변경이 사고 시점에 실제로 Pod에 적용되었다"는 사실은 별개로 검증해야 합니다. RCA 엔진이 이 차이를 모르면 시간만 맞으면 ConfigMap을 원인으로 단정하는 오류를 내고, 운영자는 잘못된 방향으로 끌려갑니다.

실무에서는 Pod 재시작 시점, Pod의 spec/annotations에 보이는 ConfigMap resourceVersion, kubelet sync log 같은 보조 신호를 함께 봐야 적용 여부를 확인할 수 있습니다. 토론 시나리오의 경우에는 11:42 deploy event가 Pod rollout을 동반했으므로 새 Pod부터 새 pool size가 적용된 것으로 추적할 수 있습니다.

Secret도 같은 추적 경로가 필요합니다. 다만 Secret은 값 자체가 노출되지 않으므로 resourceVersion, annotation, sealed-secret 해시 같은 메타데이터 diff 로 변경을 감지합니다. DB password rotation으로 connection이 일제히 재인증되면서 pool이 초기화되는 패턴은 같은 시나리오의 자매 케이스로, ConfigMap diff와 동일한 "변경 시점 × 변경 내용" 결합 방식으로 풀립니다.

4.5 SDG만으로는 부족합니다 — 세 의존성 그래프

운영 환경에서 RCA를 할 때 자주 잊히는 사실은, 서비스 의존성만 가지고는 config misconfig 같은 원인을 짚을 수 없다는 점입니다. 최소한 세 종류의 그래프가 함께 있어야 합니다.

flowchart TB
    subgraph G1 [① 서비스 의존성 - 4주차 SDG]
        I1[Ingress] --> A1[API]
        A1 --> D1[(DB)]
    end

    subgraph G2 [② 변경 의존성]
        Dep[Deployment] --> RS[ReplicaSet]
        RS --> Pod[Pod]
        Pod --> CM[ConfigMap]
        Pod --> Sec[Secret]
        Pod --> Env[env vars]
    end

    subgraph G3 [③ 관측 의존성]
        AS[API trace span] -.->|parent-child| DS[DB client span]
    end

    style G2 fill:#fff3e0,stroke:#e65100

4주차에서 다룬 SDG는 첫 번째 그래프에 해당합니다. RCA 단계에서는 그 위에 "무엇이 무엇의 설정을 결정하는가"라는 두 번째 그래프가 얹혀야 pool misconfig 같은 원인을 짚을 수 있습니다. 세 번째 그래프인 관측 의존성은 trace의 parent-child 관계로 두 서비스의 시간을 정렬해 주는 보조 역할을 합니다.

세 층 중 어느 한 층이 빠지면 무엇을 잃는지를 정리하면 다음과 같습니다.

빠진 층 잃는 단서
서비스 의존성만 보면 변경의 시점·내용을 놓침
변경 의존성만 보면 변경이 어느 노드에 영향을 가는지 불명
관측 의존성만 보면 누가 무엇을 바꿨는지 모름

§4.2의 세 신호 결합이 작동하려면 결국 세 층의 그래프가 모두 RCA 엔진의 입력으로 들어와야 합니다. 한 층이라도 빠지면 결정적 단서 중 하나가 사라지고, 알고리즘은 후보 ranking에서 멈추게 됩니다.

4.6 어떤 RCA 접근이 어울리는가

Graph 기반(MicroRCA류)은 SDG 위에서 anomalous subgraph의 sink를 "API → DB"로 좁히는 데까지는 잘 갑니다. 다만 거기서 한 단계 더 들어간 "pool 설정"이라는 원인까지 짚으려면 변경 의존성 그래프가 따로 필요합니다.

Causal discovery(AERCA류)는 pool wait_count가 latency를 Granger-cause한다는 사실을 발견할 잠재력은 있습니다. 다만 deploy 순간의 pool 변경이 단일 step intervention이라, 학습용 정상 데이터에 이 인과가 존재하지 않을 수 있습니다. 평소에 일어나지 않던 일이기 때문입니다.

 

LLM-agentic(HolmesGPT)은 사람의 진단 흐름과 가장 닮았습니다. "latency 알람을 받고 → kubectl로 deployment 변경을 확인하고 → ConfigMap diff를 보고 → pool metric을 조회하고 → log를 검색"하는 체인이 자연스럽습니다. 다만 toolkit, runbook, integration이 없으면 이 체인이 시작되지 않습니다. OpenRCA의 11.34%, ITBench SRE의 13.8%가 이 한계를 정량적으로 보여줍니다.

5. 분석 대상 오픈소스 — 스터디 후보

선정 기준은 (a) 활성 유지, (b) 코드 분량 적당, (c) 이론과 코드의 매핑이 또렷, (d) K8s나 관측 가능 데이터에 직접 연결, 네 가지로 잡았습니다.

  프로젝트 핵심 가치 License 메타
  RCAEval 벤치마크 + 16 baselines를 한 코드베이스에서 비교 MIT 105★, 32 releases, FSE'26
  BARO FSE'24 Best Artifact. 단일 알고리즘이라 통계 RCA의 실체를 짧은 코드로 볼 수 있음 MIT v0.2.2 (2025-06)
  HolmesGPT LLM-agentic의 정점. CNCF Sandbox(2025-10-08 승인). Robusta.dev 원작, Microsoft 공동 기여 Apache 2.0 2.4k★, v0.28.0
  AERCA ICLR'25 Oral. Granger causal discovery + autoencoder MIT 86★, PyTorch
  Nezha Multi-modal RCA의 짧은 구현 MIT 70★
  MicroRCA Personalized PageRank의 원형 (현재 비활성) 미상 NOMS'20
  PyRCA Salesforce의 metric-only 라이브러리 BSD-3 활발
  K8sGPT K8s 리소스 상태 해석. CNCF Sandbox(2023-12-19) Apache 2.0 CLI/Operator
  OpenRCA LLM RCA 평가 벤치마크 + RCA-agent MIT ICLR'25
  ITBench SRE/CISO/FinOps agent benchmark — arXiv'25

 

RCAEval과 BARO를 함께 보는 조합을 권합니다. 벤치마크의 "정답지"와 1위 알고리즘을 같이 따라가면, 이론에서 코드로, 코드에서 성능 수치까지 한 번에 trace할 수 있습니다.

 

여유가 있다면 옵션으로 HolmesGPT를 추가할 수 있습니다. 다만 HolmesGPT는 RCA 코어보다 agent, integration, ops engineering 쪽 비중이 커서 토론 초점이 흐려질 위험은 있습니다.

6. 산업계 동향 — 2025 후반부터 2026 초반까지의 agentic AIOps

상용 vendor들도 같은 시기에 agentic AIOps 방향으로 빠르게 움직이고 있습니다. 다만 여기서 중요한 점은 vendor의 주장 과 외부에서 검증 가능한 공개된 사실, 그리고 알 수 없는 부분 을 분리하는 일입니다. vendor 자체 보고 수치를 그대로 인용하면 비판적 평가가 어렵습니다.

flowchart LR
    subgraph OSS [오픈소스]
        H[HolmesGPT<br/>CNCF Sandbox]
        K[K8sGPT<br/>CNCF Sandbox]
    end

    subgraph Vendor [상용 Vendor]
        D[Datadog<br/>Bits AI SRE]
        P[PagerDuty<br/>SRE Agent]
        Dy[Dynatrace<br/>Davis CoPilot]
        N[New Relic<br/>AI MCP Server]
    end

    subgraph Cloud [클라우드 통합]
        MS[Microsoft<br/>Azure SRE Agent]
    end

    Vendor -.->|MCP 통합| Cloud
    OSS -.->|toolset 제공| Vendor

    style OSS fill:#e8f5e9,stroke:#2e7d32
    style Vendor fill:#fff3e0,stroke:#e65100
    style Cloud fill:#e3f2fd,stroke:#1565c0

각 제품을 주장, 공개된 사실, 알 수 없는 것 셋으로 나눠 정리하면 다음과 같습니다.

제품 주장 공개된 사실 알 수 없는 것
HolmesGPT "agentic loop로 hypothesis-investigate" OSS Apache 2.0, CNCF Sandbox 2025-10-08, Robusta·Microsoft 공동, 22개 toolset 통합 실제 production 배포 규모, agent loop 평균 깊이
Datadog Bits AI SRE "MTTR 70-95% 단축"(개별 사례), "deep research agent" 2025-12-02 GA, 베타 2,000+ environment, "tens of thousands of investigations" baseline 비교 방식, 독립 검증된 효과, agent loop 깊이
PagerDuty SRE Agent "early adopter 50% faster" Fall 25 GA, SRE/Scribe/Shift suite 구성 50% 측정 방법, 모집단, 통계적 유의성
Dynatrace Davis CoPilot "natural language RCA + remediation" 2024-10 출시, Chat 2025-02 GA, Problems app 통합 기존 Davis(symbolic) 대비 추가 기여도
New Relic AI MCP Server "Azure/AWS agent 통합으로 cross-vendor" 2025-11-04 발표, MCP server 공개 RCA loop가 실제로 MCP를 통해 도는지, 지연·비용
Microsoft Azure SRE Agent "Foundry로 통합 SRE 에이전트" Build 2025 발표 GA 시점, 단독 사용 가능 여부

공개 자료의 한계를 한 줄로 요약하면, vendor agentic AIOps는 모두 "agent를 지향한다"는 표현이 정확합니다. 외부에서 검증 가능한 것은 데모와 보도자료 수준이며, 운영 환경의 비용·권한·안전성 제약 때문에 실제 동작은 완전한 hypothesis loop라기보다 retrieval + bounded tool use + summarization에 가까울 가능성이 큽니다. 

출처

벤치마크

알고리즘

LLM-agentic / 산업

검증 도구

책 / 서베이

'AIOps' 카테고리의 다른 글

AIOps 스터디 6주차 — coroot의 데이터 흐름과 RCA 책임 분담  (0) 2026.05.16
AIOps 스터디 5주차 - RCA 평가지표 정리  (1) 2026.05.10
AIOps 스터디 4주차 — Correlation  (0) 2026.04.25
AIOps 스터디 3주차 — 전통 Anomaly Detection의 기본기와 Forecasting Foundation Model의 등장  (0) 2026.04.18
AIOps 스터디 2주차 - What is AIOps  (1) 2026.04.11
'AIOps' Related Articles more