근묵자흑

What is AIOps 본문

AIOps

What is AIOps

Luuuuu 2026. 4. 11. 19:30

1. 이 글이 다루는 것

첫 스터디의 주제는 AIOps의 정의, 그리고 Observability·SRE·DevOps와의 관계, 마지막으로 telemetry 기반 이해입니다.

이 주제를 정리하다 보면 자연스럽게 한 가지 질문에 부딪히게 됩니다. 우리가 교과서적으로 세운 정의가 2025년 말 시점에도 유효한지, 아니면 LLM과 agentic AI의 등장으로 이미 낡은 것이 되었는지 하는 질문입니다. 이 글은 Hands-on AIOps(Apress, 2022)와 Observability Engineering(O'Reilly, 2022) 두 책을 뼈대로 삼되, 2023년부터 2025년 말까지 발표된 주요 논문과 벤치마크를 교차 참조해 그 질문에 답해 보는 형태로 구성했습니다.

2. 정의의 출발점: Gartner에서 학계로

AIOps라는 용어는 2017년 Gartner의 리서치 노트에서 "big data와 machine learning을 결합해 IT 운영 기능을 강화하는 플랫폼"으로 처음 공식화되었습니다. 이 산업계 정의를 학술적으로 좁혀준 것이 Notaro, Cardoso, Gerndt가 2021년 ACM Transactions on Intelligent Systems and Technology에 발표한 "A Survey of AIOps Methods for Failure Management" 서베이였습니다. 이 서베이는 AIOps의 failure management 기능을 다섯 개의 카테고리로 분해하는데, 시간 축 위에 나란히 놓으면 다음과 같은 형태가 됩니다.

flowchart LR
    A[Failure<br/>Prevention<br/>설계·품질] --> B[Online Failure<br/>Prediction<br/>장애 조짐 포착]
    B --> C[Failure<br/>Detection<br/>이상 탐지]
    C --> D[Root Cause<br/>Analysis<br/>원인 가설]
    D --> E[Remediation<br/>권고·조치]
    style A fill:#e8f4ff
    style B fill:#e8f4ff
    style C fill:#fff4e0
    style D fill:#ffe8e8
    style E fill:#e8ffe8

이 분해가 중요한 이유는 "AIOps는 결국 이상 탐지 아닌가"라는 흔한 오해를 정면으로 반박하기 때문입니다. 이상 탐지는 다섯 카테고리 중 하나일 뿐이며, 그 앞뒤로 예방·예측·인과 분석·조치가 이어진다는 시각을 이 서베이가 분명히 해주었습니다. 이 학술적 정의에 현실감을 더해준 논문이 2019년 ICSE Companion에 실린 Microsoft Dang, Lin, Huang의 technical briefing "AIOps: Real-World Challenges and Research Innovations"입니다. Azure 운영 경험을 바탕으로 noisy label, concept drift, interpretability 같은 제약을 일찍이 지적한 점이 지금도 인용 가치가 있으며, 스터디의 북극성인 "지금 현실적으로 가능한 것과 실험적인 것의 경계"를 세우는 데 좋은 출발점이 됩니다.

3. 두 책이 보여주는 서로 다른 각도

우리가 뼈대로 삼은 두 권의 책은 같은 풍경을 다른 각도에서 봅니다. 이를 그림으로 나란히 놓으면 다음과 같습니다.

flowchart TB
    subgraph HOA["Hands-on AIOps (운영 관점)"]
        H1[분절된 모니터링 도구]
        H2[통합 플랫폼 계층]
        H3[확률론적 출력]
        H1 --> H2 --> H3
    end
    subgraph OE["Observability Engineering (능력 관점)"]
        O1[Logs·Metrics·Traces]
        O2[Introspection 수준]
        O3[내부 상태 추론 능력]
        O1 --> O2 --> O3
    end
    HOA -. 공통 결론 .-> X[AIOps 출력 품질은<br/>Observability 품질을<br/>넘어설 수 없다]
    OE -. 공통 결론 .-> X
    style X fill:#ffe8e8

Hands-on AIOps는 AIOps를 운영 관점에서 바라보며, SRE·DevOps와 대립되는 것이 아니라 그것들을 지탱하는 기반으로 위치시킵니다. 특히 AIOps의 출력이 결정론적이 아니라 확률론적이라는 점을 강조하는 대목이 중요합니다. 이 성격은 SRE의 error budget 개념과 자연스럽게 맞물립니다. 오류를 0으로 만드는 것이 아니라 허용 가능한 범위 안에서 관리한다는 SRE의 전제가 있어야, 확률론적 출력을 다루는 심리적·조직적 여유가 생기기 때문입니다.

Observability Engineering은 같은 풍경을 관측 능력의 관점에서 바라봅니다. 이 책은 observability를 시스템의 내부 상태를 외부에서 추론할 수 있도록 하는 introspection 수준으로 정의하면서, 그것을 logs·metrics·traces라는 특정 시그널의 조합으로 환원하지 말라고 경고합니다. 시그널의 종류보다 추론 능력이 본질이라는 관점은, AIOps를 observability의 경쟁자가 아니라 그 위에 얹히는 층으로 이해하는 데 중요한 단서를 줍니다. 두 책을 나란히 읽으면 한 가지 결론이 도출되는데, AIOps의 출력 품질은 observability의 품질을 절대 넘어설 수 없다는 명제입니다.

4. AIOps의 정의를 세 겹으로 풀어보기

위의 관점들을 종합하면 AIOps는 세 겹으로 나누어 이해할 때 가장 명확해집니다.

flowchart LR
    subgraph L1["① 입력"]
        I1[Logs]
        I2[Metrics]
        I3[Traces]
        I4[Events]
        I5[CMDB/Topology]
    end
    subgraph L2["② 출력"]
        O1[이상 탐지]
        O2[중복 제거]
        O3[RCA 가설]
        O4[권고 조치]
        O5[제한적 자동화]
    end
    subgraph L3["③ 소비 주체"]
        C1[SRE]
        C2[DevOps]
    end
    L1 --> L2 --> L3

첫 번째 겹은 입력이고, logs·metrics·traces·events, 그리고 CMDB나 토폴로지 같은 구성 정보가 모두 여기에 해당합니다. 두 번째 겹은 출력이고, 이상 탐지 결과·알림의 중복 제거·근본 원인 가설·권고 조치·되돌리기 쉬운 범위에서의 자동 조치가 포함됩니다. 세 번째 겹은 소비 주체인데, 최종적으로는 SRE와 DevOps 팀의 사람이 의사결정을 내린다는 점이 핵심입니다. 이 세 번째 겹 때문에 우리는 AIOps를 "자동화 시스템"이 아니라 "의사결정 보조 계층"이라고 부릅니다.

5. Observability·SRE·DevOps와의 관계

이 세 개념은 자주 섞여 쓰이지만 각자 다른 질문에 답합니다. Observability는 "시스템 내부 상태를 외부에서 얼마나 추론할 수 있는가"에 답하는 능력의 개념이고, SRE는 "신뢰성을 어떻게 공학적으로 관리할 것인가"에 답하는 공학 실천이며, DevOps는 "개발과 운영 사이의 벽을 어떻게 허물 것인가"에 답하는 문화와 협업 방식입니다. AIOps는 이 셋과 같은 층위에 있는 것이 아니라 이들 위에 얹히는 네 번째 층입니다.

flowchart TB
    TEL[Telemetry<br/>logs·metrics·traces·events] --> OBS[Observability<br/>내부 상태 추론 능력]
    OBS --> SRE[SRE<br/>SLI/SLO/Error Budget]
    OBS --> AIOPS[AIOps<br/>의사결정 보조 계층]
    AIOPS --> SRE
    SRE --> DO[DevOps<br/>개발·운영 협업]
    AIOPS --> DO
    style TEL fill:#e8f4ff
    style OBS fill:#fff4e0
    style AIOPS fill:#ffe8e8
    style SRE fill:#e8ffe8
    style DO fill:#f0e8ff

이 그림에서 화살표가 단방향이라는 점이 중요합니다. AIOps가 telemetry를 만들어 주지 않고, SRE 원칙이 없다고 해서 observability가 저절로 생기지도 않습니다. 순서를 거꾸로 세우면 모델은 불완전한 입력 위에서 자신 있게 틀린 답을 내놓기 시작합니다.

6. 파이프라인으로서의 AIOps 컴포넌트

Notaro 서베이의 다섯 카테고리를 실무 흐름으로 재배열하면, 각 단계가 요구하는 능력과 출력의 성격이 서로 다르다는 점이 더 분명히 드러납니다.

flowchart LR
    FP[Failure Prevention<br/>품질 공학] --> OFP[Online Failure<br/>Prediction<br/>조짐 포착]
    OFP --> FD[Failure Detection<br/>이상 신호]
    FD --> RCA[Root Cause Analysis<br/>원인 가설]
    RCA --> RM[Remediation<br/>권고·조치]
    RM -. 피드백 .-> FP

    FD -.횡단.- CORR[Correlation &<br/>Deduplication]
    CORR -.횡단.- RCA
    style FP fill:#e8f4ff
    style OFP fill:#e8f4ff
    style FD fill:#fff4e0
    style RCA fill:#ffe8e8
    style RM fill:#e8ffe8
    style CORR fill:#f0f0f0

첫 단계인 failure prevention은 설계와 테스트 단계에서 결함의 유입을 줄이는 활동으로, 엄밀히 말하면 AIOps 이전의 품질 공학 영역과 겹칩니다.

 

두 번째 단계인 online failure prediction은 실제 장애가 일어나기 전에 telemetry의 패턴으로 그 조짐을 미리 포착하는 단계인데, 이 단계의 출력이 의미를 가지려면 거짓 양성에 드는 비용이 해당 장애가 실제로 발생했을 때의 비용보다 훨씬 낮아야 한다는 조건이 붙습니다.

 

세 번째 단계인 failure detection은 현재 시점에 "평소와 다른 일"이 벌어지고 있음을 신호로 만드는데, 그 신호는 곧바로 "문제"를 의미하지 않고 단지 "통계적으로 드문 일"이 발생했다는 사실에 가깝습니다.

 

네 번째 단계인 root cause analysis는 감지된 이상의 원인에 대한 가설을 만듭니다. 답이 아니라 가설이라는 점을 잊지 말아야 하며, 이 가설의 질은 앞에 놓인 세 단계의 품질에 결정적으로 좌우됩니다.

 

다섯 번째 단계인 remediation은 권고 조치와 제한적 자동 조치를 포함하는데, 현재 현실적으로 자동화 가능한 조치는 되돌리기 쉬운 것들(서비스 재시작, 스케일 아웃, 캐시 flush)에 한정됩니다. 실제 파이프라인에서는 이들 사이에 상관관계 분석과 알림 중복 제거가 횡단적으로 작동하며, 이 부분은 CMDB나 토폴로지 정보의 품질에 크게 좌우됩니다.

 

이 다섯 단계를 관통하는 원칙 하나는 앞 단계의 품질이 낮으면 뒷 단계가 그것을 절대 만회하지 못한다는 것입니다.

7. Telemetry의 현실적 한계

OpenTelemetry가 사실상의 표준이 되면서 수집의 파편화는 완화되었지만, 그 아래에는 여전히 구조적 문제가 남아 있습니다. 아래 그림은 네 가지 대표적 함정을 한눈에 정리한 것입니다.

flowchart TB
    T[Telemetry 품질 리스크]
    T --> S[Sampling<br/>trace 대표성 왜곡]
    T --> C[Cardinality<br/>저장소 한계·누락]
    T --> K[Clock Skew<br/>선후 관계 오해석]
    T --> M[Missing Data<br/>'없음'을 '정상'으로 오해]
    S --> X[RCA 인과 추론 실패]
    C --> X
    K --> X
    M --> X
    style T fill:#fff4e0
    style X fill:#ffe8e8

Sampling은 trace의 대표성을 좌우하여 특정 이상을 보이지 않게 만들 수 있고, metric의 label cardinality는 저장소 비용과 쿼리 성능을 결정하며 한계에 도달하면 조용히 데이터가 누락됩니다. Clock skew는 분산 시스템에서 사건의 선후 관계를 왜곡해 RCA의 인과 추론을 어긋나게 하고, missing data는 "데이터가 없는 구간"을 "이상 없음"으로 오해하게 만들어 가장 치명적인 실패를 유발합니다.

8. 2025년 벤치마크가 드러낸 현실

여기까지가 교과서적 정리라면, 이제부터는 최근 1~2년간의 벤치마크 결과를 통해 "그래서 AIOps는 지금 어디까지 왔는가"를 확인할 차례입니다. 여러 벤치마크의 공통 결론은 아래 그림으로 요약할 수 있습니다.

flowchart LR
    DET[Detection<br/>✓ 잘함] --> LOC[Localization<br/>△ 조건부]
    LOC --> RCA[RCA<br/>✗ 가설 수준]
    RCA --> MIT[Mitigation<br/>✗ 위험]
    style DET fill:#e8ffe8
    style LOC fill:#fff4e0
    style RCA fill:#ffe8e8
    style MIT fill:#ffcccc

Microsoft Research의 AIOpsLab(arXiv:2501.06706)은 현재 가장 포괄적인 평가 프레임워크로, microservice 환경을 Kubernetes 위에 배포하고 장애를 주입한 뒤 agent에게 Detection, Localization, Root Cause Diagnosis, Mitigation 네 가지 태스크를 수행하게 합니다. GPT-4 기반 ReAct agent는 Detection은 비교적 잘 해내지만 RCA와 Mitigation으로 갈수록 정확도가 급락합니다. 모델이 "무엇이 잘못되었는지"는 자주 맞히지만 "왜 잘못되었는지"와 "어떻게 고칠지"에서는 급격히 흔들린다는 뜻입니다.

CUHK 선전·Microsoft·Tsinghua가 공동으로 ICLR 2025에서 발표한 OpenRCA는 더 냉정한 결과를 보여줍니다. 335개 장애와 68GB의 telemetry를 담았는데, 인시던트 하나에 1,263개의 KPI가 연관되는 것이 현실입니다.

flowchart LR
    A[1,263개 KPI<br/>실제 운영 규모] -- "95% 감축<br/>(oracle sampling)" --> B[53개 golden KPI]
    B --> C[Claude 3.5 + RCA-agent<br/>해결률 11.34%]
    style A fill:#ffe8e8
    style B fill:#fff4e0
    style C fill:#ffcccc

1,263개에서 53개로 줄여주어야만 의미 있는 수치가 나왔고, 그럼에도 Claude 3.5가 해결한 장애 비율은 11.34%에 그쳤다는 이 결과는 앞에서 말한 "앞 단계의 품질이 뒷 단계를 결정한다"는 원칙에 한 층을 더합니다. 품질뿐 아니라 양의 문제도 있다는 것입니다.

2025년 12월 공개된 NIKA(arXiv:2512.16381)는 GPT-5, GPT-5-mini, GPT-OSS:20B를 네트워크 트러블슈팅에 적용했는데, 결론은 짧고 명확합니다. 큰 모델일수록 이상 탐지는 더 잘하지만 fault localization과 root cause 식별에서는 여전히 고전한다는 것입니다. 모델이 GPT-4에서 GPT-5로 진화하는 동안 경계는 조금씩 움직였지만 경계 자체가 사라지지는 않았습니다. 한편 ICCS 2025의 AIOps for Reliability 논문은 통제된 few-shot 설정에서 GPT-4 0.66, Gemini 0.74, Mistral 0.60의 분류 정확도를 보고했는데, 동시에 모델마다 틀리는 방식이 달랐다는 관찰이 더 중요합니다. GPT-4는 프롬프트 제약 덕에 보안 시나리오를 회피한 반면, Gemini와 Mistral은 존재하지 않는 네트워크 위협을 가설로 만들어내는 경향을 보였습니다.

9. RCA 연구의 궤적

연구 공동체는 이 한계를 정면으로 우회하려는 시도를 빠르게 진행해 왔습니다. 그 궤적을 타임라인으로 정리하면 다음과 같습니다.

flowchart LR
    A[2023<br/>Ahmed et al.<br/>ICSE: 리포트 → LLM] --> B[2024<br/>RCACopilot<br/>EuroSys: Handler]
    B --> C[2024<br/>ReAct for RCA<br/>arXiv: 도구 사용]
    C --> D[2024<br/>RCAgent<br/>Flink 프로덕션]
    D --> E[2025<br/>Flow-of-Action<br/>WWW: SOP 제약]
    E --> F[2025<br/>Triangle·MULAN·STRATUS<br/>Multi-agent]
    style A fill:#e8f4ff
    style B fill:#fff4e0
    style C fill:#fff4e0
    style D fill:#ffe8e8
    style E fill:#e8ffe8
    style F fill:#f0e8ff

2023년 Ahmed 등의 ICSE 논문은 인시던트 리포트를 GPT에게 그대로 주고 근본 원인을 생성하게 했지만, LLM이 동적 정보에 접근할 수 없다는 한계가 드러났습니다. Microsoft의 RCACopilot(EuroSys 2024)이 이 한계를 handler 기반 파이프라인으로 우회했는데, 운영팀이 미리 정의해 둔 진단 스크립트를 LLM이 호출하고 그 결과를 요약·분류하게 하는 구조였습니다. Microsoft 내부 email 서비스의 653개 실제 인시던트에 4년 넘게 운영되며 0.766의 RCA 정확도를 보고했지만, handler를 사람이 일일이 만들어야 한다는 trade-off가 남았습니다.

2024년 Roy 등의 "Exploring LLM-based Agents for Root Cause Analysis"(arXiv:2403.04123)는 ReAct 프레임워크를 RCA에 적용하면서 RCA의 성격을 "LLM의 지식 검색"에서 "LLM의 도구 사용 지능"으로 전환시켰습니다. Alibaba의 RCAgent(arXiv:2310.16340)는 이 접근을 Apache Flink 프로덕션에 배치하며 context length, action validity, privacy라는 세 가지 실전 제약을 공식 문서화했고, 이후 모든 실전 RCA 시스템의 체크리스트가 되었습니다.

2025년 WWW Companion의 Flow-of-Action(arXiv:2502.08224)은 방향 자체를 뒤집었습니다. ReAct의 자유도가 hallucination의 원인이라면, 자유도를 제한하자는 철학으로 SRE의 표준 운영 절차(SOP)를 구조화해 agent의 도구 호출 순서를 강제했습니다.

flowchart LR
    R["ReAct<br/>35.50%"] --> F["Flow-of-Action<br/>64.01%"]
    style R fill:#ffe8e8
    style F fill:#e8ffe8

ReAct가 35.50%에 머무른 반면 Flow-of-Action이 64.01%를 기록했다는 사실은 모델을 더 크게 만드는 것이 아니라, 모델이 움직일 수 있는 공간을 영리하게 제약하는 것이 효과적이라는 교훈을 압축적으로 보여줍니다. 마지막으로 2024년 후반부터는 multi-agent 구조가 떠올랐습니다. WWW 2024의 MULAN은 metric과 로그를 서로 다른 모달리티로 다루고, Microsoft의 Triangle(ASE 2025)은 Analyzer·Decider·Team Manager의 3-agent 역할 분화를 제시했으며, IBM Research의 STRATUS(NeurIPS 2025, arXiv:2506.02009)는 이 접근을 cloud reliability engineering 전반으로 확장하며 Transactional No-Regression이라는 안전 규약을 형식화하고 AIOpsLab·ITBench 위에서 기존 SOTA 대비 최소 1.5배의 장애 완화 성공률을 보고했습니다.

10. 네 가지 진화 축

이 계보를 관통하는 네 가지 축을 그림으로 정리하면 최신 연구의 방향이 선명해집니다.

flowchart LR
    subgraph Axis["RCA 연구의 네 가지 진화 축"]
        direction TB
        A1[자유] -->|제약| A2[SOP 기반]
        B1[내재 지식] -->|외재화| B2[외부 저장소]
        C1[단일 모달] -->|확장| C2[다중 모달]
        D1[단일 Agent] -->|분화| D2[Multi-agent]
    end

첫째, 자유에서 제약으로: 초기 접근은 LLM에게 최대한의 자유를 주었지만, Flow-of-Action은 반대로 자유를 거두어들이는 선택을 했고 두 배에 가까운 정확도 향상으로 이어졌습니다.

둘째, 지식 내재화에서 외재화로: LLM의 사전 학습 지식에 의존하던 방식에서, handler·도구·SOP 같은 외부 저장소에 조직 지식을 명시적으로 두는 방향으로 움직였습니다.

셋째, 단일 모달에서 다중 모달로: 텍스트 리포트만 다루던 연구가 metric·log·trace를 함께 입력받는 쪽으로 이동했으며 MULAN이 대표 사례입니다.

넷째, 단일 agent에서 역할 분화된 multi-agent로: context length라는 엔지니어링 제약에서 출발했지만 지금은 "전문성의 분리"와 "안전성 검증의 국지화"로 정당화되고 있습니다.

11. Kubernetes 생태계에서의 위치

Kubernetes 환경에서는 OpenTelemetry Collector가 telemetry 계층을, Prometheus·Loki·Tempo가 observability 저장소를, Grafana가 쿼리와 시각화를 맡는 구성이 표준에 가깝습니다.

flowchart TB
    subgraph K8S["Kubernetes Cluster"]
        APP[Applications & Pods]
        APP --> OTEL[OpenTelemetry Collector]
        OTEL --> PROM[Prometheus]
        OTEL --> LOKI[Loki]
        OTEL --> TEMPO[Tempo]
        PROM --> GRAF[Grafana]
        LOKI --> GRAF
        TEMPO --> GRAF
        PROM --> AM[Alertmanager<br/>inhibition·grouping]
    end
    GRAF --> AI[LLM-based 진단<br/>K8sGPT / HolmesGPT / Robusta]
    AM --> AI
    style OTEL fill:#e8f4ff
    style GRAF fill:#fff4e0
    style AI fill:#ffe8e8

AIOps 계층은 이 위에 얹히는 별도 시스템일 수도 있지만, Alertmanager의 inhibition 규칙이나 Grafana의 알림 그룹핑처럼 이미 매우 단순한 형태의 correlation과 deduplication이 내장되어 있는 경우도 많습니다. 이 "단순한 형태"가 앞서 설명한 파이프라인 중간 단계의 초기 구현이라는 점을 인식하면, AIOps가 멀리 있는 미래 기술이 아니라 이미 일부가 우리 주변에 녹아들어 있는 연속체임을 자연스럽게 받아들이게 됩니다. 최근에는 K8sGPT, HolmesGPT, Robusta 같은 오픈소스 프로젝트가 LLM 기반 진단을 Kubernetes에 직접 연결하려는 시도를 보여주고 있으며, 이들은 대체로 Flow-of-Action의 철학과 유사한 "제약된 도구 호출" 방식을 채택하고 있습니다.

12. 정리하자면

두 책의 이론, 2021년 서베이의 분류, 그리고 2023~2025년 벤치마크와 방법론 연구를 종합하면 한 가지 결론이 분명해집니다. "AIOps는 observability 위의 운영 의사결정 보조 계층"이라는 정의에서 '보조'라는 단어는 2025년 말의 벤치마크 데이터에 의해 오히려 더 강하게 뒷받침됩니다. AgentOps와 self-healing cloud라는 비전은 분명히 존재하지만, 그 비전을 평가하기 위해 만들어진 벤치마크들이 반복해서 확인해 주는 것은 "아직은 보조"라는 현실이며, 숙련된 사람보다 단일 LLM이 일관되게 앞서는 영역은 아직 detection 계열에 한정되어 있습니다.

 

더 실무적으로 말하면, 현재 LLM 기반 AIOps의 배치 지점은 파이프라인의 어느 단계에 놓느냐에 따라 성공과 실패가 갈립니다. Detection 단계에 배치하면 실용적이고, localization에 배치하면 조건부로 유용하며, RCA에 배치하면 가설 생성기로만 유효하고, mitigation에 자율적으로 배치하면 위험합니다. 이 계층화된 배치 전략이 우리 스터디가 이후 실습에서 검증해야 할 가설이 됩니다.

참고 자료

단행본 — Sabharwal & Bhardwaj (2022), Hands-on AIOps, Apress. / Majors, Fong-Jones & Miranda (2022), Observability Engineering, O'Reilly.

기초 문헌 — Gartner (2017), Market Guide for AIOps Platforms. / Notaro, Cardoso & Gerndt (2021), A Survey of AIOps Methods for Failure Management, ACM TIST 12(6), Article 81, https://doi.org/10.1145/3483424. / Dang, Lin & Huang (2019), AIOps: Real-World Challenges and Research Innovations, ICSE 2019 Companion.

벤치마크 — Chen et al. (2025), AIOpsLab, arXiv:2501.06706. / Xu et al. (2025), OpenRCA, ICLR 2025 (CUHK Shenzhen · Microsoft · Tsinghua). / Wang et al. (2025), NIKA, arXiv:2512.16381.

RCA 방법론 — Ahmed et al. (2023), ICSE 2023. / Chen et al. (2024), RCACopilot, EuroSys 2024. / Roy et al. (2024), arXiv:2403.04123. / Wang et al. (2023), RCAgent, arXiv:2310.16340. / Pei et al. (2025), Flow-of-Action, WWW 2025 Companion, arXiv:2502.08224.

Multi-agent 시스템 — Zheng et al. (2024), MULAN, WWW 2024. / Yu et al. (2025), Triangle, ASE 2025 (Microsoft Research). / Chen et al. (2025), STRATUS, NeurIPS 2025, arXiv:2506.02009 (IBM Research · U. Illinois).

리소스 — awesome-LLM-AIOps: https://github.com/Jun-jie-Huang/awesome-LLM-AIOps