AIOps 스터디 5주차 - RCA 평가지표 정리

1. 먼저 큰 그림 — RCA 평가가 어떻게 이뤄지는가

발표에서 BARO 0.80, CIRCA 0.46, OpenRCA 11.34% 같은 숫자들이 등장합니다. 이 숫자들이 어디서 오는지를 먼저 잡고 가시면 그 뒤의 모든 해석이 쉬워집니다.

벤치마크의 평가 방식은 다음 흐름입니다.

flowchart LR
    A[정답이 있는<br/>사건 데이터셋] --> B[알고리즘이<br/>top-5 후보 출력]
    B --> C{정답이<br/>몇 번째에<br/>있는가?}
    C --> D[1건 채점 완료]
    D --> E[735건 전체에<br/>같은 작업 반복]
    E --> F[평균 점수]

    style A fill:#e3f2fd,stroke:#1565c0
    style F fill:#fff3e0,stroke:#e65100,stroke-width:2px

여기서 중요한 점은 벤치마크에는 정답이 있다 는 사실입니다. 사람이 일부러 fault를 주입했기 때문입니다. 예를 들어 "Train Ticket 시스템에서 payment-db Pod에 11시 42분에 메모리 부하를 주입했다"는 사실을 채점자가 알고 있습니다. 그러면 정답은 payment-db입니다.

알고리즘은 그 시점의 시계열 데이터만 입력으로 받고, "내가 의심하는 원인 후보 다섯 개는 이렇다"라고 top-5 리스트를 출력합니다. 채점자는 그 리스트에서 정답이 몇 번째에 있는지를 봅니다.

이 작업을 735개 사건 전체에 대해 반복합니다. 평균을 내면 그 알고리즘의 점수가 됩니다.

---

2. 평가 지표 네 가지를 시험 점수로 비유하면

발표에 나온 평가 지표 네 가지를 일상 비유로 풀어 보겠습니다. 객관식 시험을 치는 학생을 상상하시면 됩니다.

AC@1 은 가장 엄격한 채점입니다. "내가 가장 확신하는 정답"이 진짜 정답일 때만 맞은 것으로 칩니다. 시험으로 치면 한 문제에 답을 한 개만 적을 수 있는 상황입니다.

AC@3 은 좀 너그러운 채점입니다. "후보 세 개 중에 정답이 들어 있으면" 맞은 것으로 칩니다. 시험으로 치면 한 문제에 답을 세 개까지 적을 수 있고, 그중에 진짜 답이 있으면 점수를 받는 상황입니다.

AC@5 는 그보다 더 너그럽습니다. 후보 다섯 개 중에 정답이 있으면 점수를 받습니다.

Avg@5 는 AC@1부터 AC@5까지의 평균입니다. AC@1처럼 짜지도, AC@5처럼 후하지도 않은 중간 점수입니다.

MAR 만 좀 다릅니다. 이것은 "정답이 평균적으로 몇 번째에 있었나" 입니다. 다른 지표들과 달리 숫자가 작을수록 좋습니다. MAR이 1이면 항상 1번째에서 정답을 찾았다는 뜻이고, MAR이 5이면 평균적으로 5번째에서야 정답을 찾았다는 뜻입니다.

flowchart TB
    Q[한 사건<br/>정답: payment-db]

    Q --> R1["1번째: payment-db ✓"]
    Q --> R2["2번째: payment-app"]
    Q --> R3["3번째: payment-cache"]
    Q --> R4["4번째: order-svc"]
    Q --> R5["5번째: auth-svc"]

    R1 -.->|"AC@1, AC@3, AC@5<br/>모두 hit"| H[정답을 1번째에 잡음<br/>가장 좋은 케이스]

    style R1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
    style H fill:#fff3e0,stroke:#e65100

위 그림은 정답이 1번째에 있는 가장 좋은 케이스입니다. 이 사건은 AC@1, AC@3, AC@5 모두에서 hit이 됩니다.

flowchart TB
    Q[한 사건<br/>정답: payment-db]

    Q --> R1["1번째: payment-app"]
    Q --> R2["2번째: payment-cache"]
    Q --> R3["3번째: order-svc"]
    Q --> R4["4번째: payment-db ✓"]
    Q --> R5["5번째: auth-svc"]

    R4 -.->|"AC@5는 hit<br/>AC@3 miss<br/>AC@1 miss"| H[정답을 4번째에 잡음<br/>top-3까진 놓침]

    style R4 fill:#fff9c4,stroke:#f57f17,stroke-width:2px
    style H fill:#fff3e0,stroke:#e65100

위 그림은 정답이 4번째에 있는 케이스입니다. 이 사건은 AC@5에서는 hit이지만 AC@3과 AC@1에서는 miss입니다.

---

3. 0.80이라는 숫자를 어떻게 읽어야 하나

발표에서 "BARO Avg@5 = 0.80"이라는 표현이 나왔습니다. 이 0.80을 직관적으로 읽으려면 다음과 같이 보시면 됩니다.

Avg@5 = 0.80 → "100건 중 평균적으로 80% 수준의 적중률"

flowchart LR
    A[100건의 사건] --> B[알고리즘 실행]
    B --> C["AC@1 적중<br/>예: 60건"]
    B --> D["AC@3 적중<br/>예: 75건"]
    B --> E["AC@5 적중<br/>예: 95건"]

    C --> F["평균 = 0.80<br/>(중간 단계 평균 포함)"]
    D --> F
    E --> F

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

직관을 좀 더 단순하게 잡으시면, 숫자가 1에 가까울수록 잘 맞춘다, 0에 가까울수록 못 맞춘다 정도로 보시면 됩니다.

발표에 나온 수치들을 이 잣대로 다시 읽어 보겠습니다.

알고리즘	Avg@5	직관적 해석
BARO	0.80	잘 맞추는 편
TraceRCA	0.77	잘 맞추는 편
PDiagnose	0.67	보통
CIRCA	0.46	절반 정도만 맞춤
RCD	0.13	거의 못 맞춤

여기서 RCD의 0.13이라는 숫자가 인상적입니다. 이 데이터셋에서는 사실상 무작위에 가깝게 못 맞춘다 는 뜻입니다. 그런데 같은 RCD가 다른 데이터셋에서는 0.54까지 나옵니다. 이게 왜 중요한지는 다음 절에서 다룹니다.

---

4. 같은 알고리즘이 데이터셋마다 다른 점수를 받는 이유

BARO를 예로 들어 더 깊이 들어가 보겠습니다. BARO는 RCAEval에서 fault type별로 다른 점수를 받습니다. Train Ticket의 RE2 데이터셋에서 다음과 같습니다.

flowchart TB
    BARO["BARO 알고리즘"]

    BARO --> CPU["CPU fault<br/>Avg@5 = 0.72<br/>72점 정도"]
    BARO --> MEM["MEM fault<br/>Avg@5 = 0.99<br/>거의 만점"]
    BARO --> DISK["DISK fault<br/>Avg@5 = 1.0<br/>만점"]
    BARO --> SOCKET["SOCKET fault<br/>Avg@5 = 0.83<br/>잘 맞춤"]
    BARO --> DELAY["DELAY fault<br/>Avg@5 = 0.63<br/>약함"]
    BARO --> LOSS["LOSS fault<br/>Avg@5 = 0.64<br/>약함"]

    style DISK fill:#c8e6c9,stroke:#2e7d32
    style MEM fill:#c8e6c9,stroke:#2e7d32
    style DELAY fill:#ffe0b2,stroke:#e65100
    style LOSS fill:#ffe0b2,stroke:#e65100

이 차이가 왜 생길까요. 직관적으로 풀어 보면 다음과 같습니다.

디스크 fault 가 일어나면 시계열에 매우 분명한 변화가 나타납니다. 디스크가 가득 차거나 I/O가 막히는 순간, 영향 받은 서비스의 메트릭이 평소와 완전히 다른 양상으로 갑자기 바뀝니다. 이런 명확한 변화 는 BARO 같은 알고리즘이 잘 잡습니다. 그래서 Avg@5가 1.0에 가깝습니다.

네트워크 지연(DELAY) 은 다릅니다. 패킷이 늦게 도착하는 정도의 변화는 시계열에서 미묘하게 나타납니다. 평소 변동성과 잘 구분되지 않습니다. 그래서 BARO도 약합니다. Avg@5가 0.63 수준입니다.

이 사실에서 발표의 중요한 메시지가 따라옵니다. 우리 시스템에서 자주 일어나는 fault가 어떤 type이냐에 따라 알고리즘 선택이 달라져야 합니다. "BARO가 1위"라는 단정이 위험한 이유가 여기에 있습니다. 이 데이터셋에 BARO가 잘 맞는다 가 더 정확한 표현입니다.

---

5. Confidence score 0.62는 무슨 뜻인가

이제 알고리즘이 후보를 출력할 때 함께 나오는 confidence score를 풀어 보겠습니다.

발표에서 다음과 같은 출력 예시를 보여드렸습니다.

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

여기서 0.62, 0.21, 0.09를 어떻게 읽어야 할까요.

가장 흔한 오해는 "0.62 = 62% 확실히 원인이다"라는 해석입니다. 이건 정확하지 않습니다.

정확한 해석은 일기예보의 강수확률과 같습니다.

flowchart TB
    subgraph Weather [일기예보 강수확률 70%]
        W1[기상청이 70% 확신한다 ❌]
        W2["과거 비슷한 기압 패턴 100번 중<br/>70번은 비가 왔다 ✅"]
    end

    subgraph RCA [RCA confidence 0.62]
        R1[이 노드가 62% 확실히 원인 ❌]
        R2["과거 비슷한 데이터 패턴 100번 중<br/>62번은 이 노드가 진짜 원인이었다 ✅"]
    end

    style W1 fill:#ffebee,stroke:#c62828
    style W2 fill:#c8e6c9,stroke:#2e7d32
    style R1 fill:#ffebee,stroke:#c62828
    style R2 fill:#c8e6c9,stroke:#2e7d32

같은 잣대로 후보 리스트의 다른 점수도 읽어 보면 다음과 같습니다.

• payment-db (0.62) → 비슷한 패턴 100번 중 62번은 payment-db가 원인이었다
• payment-app (0.21) → 비슷한 패턴 100번 중 21번은 payment-app이 원인이었다
• payment-cache (0.09) → 비슷한 패턴 100번 중 9번은 payment-cache가 원인이었다

세 후보의 합이 0.92이고, 나머지 0.08은 그 외 후보들에 흩어져 있습니다.

이 해석에서 한 가지 결론이 나옵니다. top-1만 보고 자동으로 종결하면 안 됩니다. 0.62는 꽤 높은 점수처럼 보이지만, 거꾸로 보면 38%는 틀린다는 뜻이기도 합니다. 운영자가 마지막 검증을 해야 하는 이유가 이 숫자 자체에 들어 있습니다.

---

6. BARO가 하는 일 — change point detection 직관

BARO는 통계 기반 RCA의 대표적 방법입니다. 통계 용어를 풀어 보면 다음과 같습니다.

BARO의 정식 이름은 Multivariate Bayesian Online Change Point Detection 입니다. 길지만 풀어 쓰면 어렵지 않습니다.

Change point detection 은 시계열에서 "갑자기 변하는 시점을 찾는 일"입니다.

flowchart LR
    A[시간] --> B[메트릭 값]

    B --> P1["📊 평소<br/>값이 평탄하게<br/>왔다 갔다"]
    P1 --> CP["⚡ Change Point<br/>갑자기 다른 양상으로<br/>변하는 시점"]
    CP --> P2["📊 변화 후<br/>이전과 다른 패턴"]

    style CP fill:#ffe4b5,stroke:#d2691e,stroke-width:3px

평소에는 값이 평탄하게 변동합니다. 그러다가 어느 순간 갑자기 양상이 달라지는 시점이 있습니다. 이 시점이 change point입니다. fault가 주입되면 이런 변화가 나타납니다.

Bayesian 은 이 변화 시점을 찾는 방법론 입니다. 매 시점마다 "여기서 변화가 일어났을 가능성이 얼마인가"를 확률로 계산해 갑니다. 그 확률이 갑자기 튀는 시점을 change point로 봅니다.

Multivariate 는 시계열을 여러 개 동시에 본다는 뜻입니다. 한 변수만 보면 노이즈와 헷갈릴 수 있는데, 여러 변수를 함께 보면 진짜 변화 시점이 더 또렷해집니다.

flowchart TB
    subgraph Single [한 변수만 볼 때]
        S1["CPU 메트릭<br/>변화? 노이즈?"]
        S1 -.->|애매| SR[판단 불확실]
    end

    subgraph Multi [여러 변수 함께 볼 때]
        M1[CPU 메트릭]
        M2[메모리 메트릭]
        M3[Network I/O]
        M1 --> MR[셋이 동시에 변하면<br/>진짜 변화 시점]
        M2 --> MR
        M3 --> MR
    end

    style SR fill:#ffebee,stroke:#c62828
    style MR fill:#c8e6c9,stroke:#2e7d32

여기까지가 BARO의 첫 단계입니다. 변화 시점을 찾으면, 두 번째 단계에서 RobustScorer 라는 방법으로 어느 변수가 가장 강하게 변했는지를 판정합니다. 이게 root cause 후보입니다.

RobustScorer의 핵심은 "비모수 가설 검정"이라는 통계 방법입니다. 어렵게 들리는데, 직관은 단순합니다. 분포에 대한 가정 없이 변수들을 비교 한다는 뜻입니다. "이 변수가 평소와 가장 많이 달라졌다"를 판정하는 안정적인 방법 정도로 이해하시면 됩니다.

---

7. AERCA가 하는 일 — Granger causality 직관

이번에는 causal discovery 쪽 알고리즘인 AERCA를 풀어 보겠습니다. AERCA의 핵심 개념은 Granger causality 입니다. 이름이 어렵지만 아이디어는 다음 한 줄로 정리됩니다.

"A가 변하면 시간 차를 두고 B가 자주 변한다 → A가 B의 원인일 가능성"

flowchart LR
    T0["시점 0<br/>A 변화 발생"] -->|"몇 분 후"| T1["시점 1<br/>B에 변화 나타남"]

    T0 -.->|"이런 패턴이<br/>여러 번 반복되면"| C["A가 B의<br/>원인일 가능성"]
    T1 -.->|"여러 번 반복"| C

    style T0 fill:#e3f2fd,stroke:#1565c0
    style T1 fill:#fff3e0,stroke:#e65100
    style C fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

예를 들어 "배포 이벤트가 발생하고 5분 후에 latency가 상승한다"는 패턴이 자주 관찰되면, 배포가 latency의 원인일 가능성이 있다고 봅니다.

좀 더 엄밀하게 말씀드리면, "B의 미래 값을 예측할 때 A의 과거 정보를 추가하면 예측이 좋아지는가"를 검정합니다. 좋아지면 A가 B를 Granger-cause한다고 표현합니다.

여기서 중요한 주의점이 하나 있습니다. Granger causality는 통계적 선행성이지 진짜 원인의 보장이 아닙니다.

flowchart TB
    C["진짜 원인 C<br/>(우리가 못 보는 변수)"]
    C --> A[변수 A]
    C --> B[변수 B]

    A -.->|"A가 시간상 먼저 움직이면<br/>Granger는 A→B로 본다"| B

    note["하지만 진짜 원인은 C<br/>A와 B는 모두 C의 결과"]
    style C fill:#ffe4b5,stroke:#d2691e,stroke-width:2px
    style note fill:#ffebee,stroke:#c62828

위 그림이 가장 흔한 함정입니다. A와 B가 모두 또 다른 원인 C에서 나왔다면, A가 B를 일으킨 것처럼 보일 수 있습니다. 진짜 원인은 C인데 우리는 C를 관찰하지 못하니 A↔B만 보입니다. Granger는 이 차이를 자동으로 가르지 못합니다.

AERCA는 이 한계를 줄이려고 약간 다른 접근을 합니다. 정상 시계열로 학습할 때 외생변수의 정상 분포 를 미리 학습합니다. 이상 시점에 그 외생변수가 정상 분포에서 크게 벗어나면 root cause로 판정합니다. 발표 슬라이드의 두 번째 다이어그램이 이 흐름을 보여줍니다.

---

8. LLM 벤치마크의 11.34%, 13.8% 의미

마지막으로 LLM RCA 벤치마크의 수치를 풀어 보겠습니다.

OpenRCA의 결과는 "Claude 3.5 + RCA-agent의 best 성능이 11.34%"였습니다. 이 11.34%를 어떻게 읽어야 할까요. 시험 점수와 같은 직관으로 보시면 됩니다.

flowchart LR
    Q["OpenRCA 시험<br/>335 문제"] --> A["Claude 3.5<br/>+ RCA-agent"]
    A --> R["38문제 정답<br/>(335 × 11.34%)"]
    R --> M["100문제 중<br/>약 11문제 정답"]

    style M fill:#ffe0b2,stroke:#e65100,stroke-width:2px

100문제 중 약 11문제만 맞췄다는 뜻입니다. 그것도 도구 호출과 시간을 충분히 준 최선의 조건 에서입니다.

ITBench도 비슷합니다. SRE 페르소나에서 13.8%였습니다. 100문제 중 약 14문제만 풀었다는 뜻입니다.

여기서 한 가지 짚어야 할 부분이 있습니다. 두 벤치마크의 11.34%와 13.8%를 직접 비교할 수는 없습니다.

flowchart TB
    Q1[OpenRCA 시험<br/>측정 능력: 텔레메트리 위 failure localization]
    Q2[ITBench 시험<br/>측정 능력: 도구 호출 포함 운영 task 해결]

    Q1 -.->|"다른 시험"| X[직접 비교 불가]
    Q2 -.->|"다른 채점 기준"| X

    Q1 --> S["둘 다 한 자리수<br/>~10%대라는<br/>정성적 사실만 비교 가능"]
    Q2 --> S

    style X fill:#ffebee,stroke:#c62828
    style S fill:#fff3e0,stroke:#e65100,stroke-width:2px

두 벤치마크가 측정하는 능력이 다릅니다. 시험지 자체가 다르고 채점 기준도 다릅니다. 그래서 11.34% vs 13.8%로 우열을 가릴 수는 없습니다.

다만 두 벤치마크가 독립적으로 비슷한 천장 을 보여준다는 점은 메시지가 됩니다. 현 시점에서 LLM 단독 RCA는 실 운영에 그대로 투입할 수준은 아니다 라는 정성적 사실 정도가 안전한 결론입니다.

---

9. 한 장 요약

오늘 보충 설명한 통계 수치들을 한 장으로 정리하면 다음과 같습니다.

수치	어떻게 읽나	주의
AC@1 = 0.60	100건 중 60건은 1순위에 정답	가장 엄격한 채점
AC@5 = 0.95	100건 중 95건은 5순위 안에 정답	가장 너그러운 채점
Avg@5 = 0.80	AC@1~AC@5의 평균 점수	직관: 0.8은 잘하는 편, 0.5는 절반, 0.1은 못 맞춤
MAR = 2.5	정답이 평균 2.5번째에 있음	작을수록 좋음
Confidence 0.62	비슷한 패턴 100번 중 62번이 진짜 원인이었다	"62% 확실"이 아님
BARO 0.99 (MEM), 0.63 (DELAY)	fault type별로 다른 강약	"1위 알고리즘" 단정 위험
OpenRCA 11.34%	100문제 중 약 11문제 정답	최선의 조건에서도 이 수준
ITBench 13.8%	다른 시험에서 100문제 중 약 14문제 정답	OpenRCA와 직접 비교 X