새벽 2시 13분입니다.

운영 환경(production)에서 결제 API가 갑자기 실패하기 시작합니다.

고객들은 트랜잭션을 완료할 수 없습니다. 곳곳에서 경고(Alerts)가 울리기 시작합니다. 대시보드는 빨간색으로 변합니다. Kubernetes 포드(pods)가 예기치 않게 재시작됩니다. 데이터베이스 연결(Database connections)이 타임아웃되기 시작합니다.

그리고 어딘가에서, 지칠 대로 지친 엔지니어가 Datadog을 열고 단 하나의 질문에 답하기 위해 수천 개의 로그를 스크롤하기 시작합니다:

“도대체 무엇이 고장 난 거지?”

현대적인 시스템은 엄청난 양의 텔레메트리(telemetry)를 생성합니다:

• 로그 (logs)
• 경고 (alerts)
• 트레이스 (traces)
• 메트릭 (metrics)
• 인프라 이벤트 (infrastructure events)

문제는 더 이상 모니터링의 부족이 아닙니다.

문제는 다음과 같습니다:

장애 발생 시 혼란스러운 상황을 충분히 빠르게 파악하는 것.

그 아이디어가 OpsMind AI의 시작점이 되었습니다. 이는 실제 DevOps 및 사이트 신뢰성 공학(Site Reliability Engineering, SRE) 워크플로에서 영감을 받은 AI 기반 장애 원인 분석(Incident Root Cause Analysis, RCA) 플랫폼입니다.

목표는 야심 차지만 단순했습니다:

관측성 로그(observability logs) 업로드 → 가능한 근본 원인 식별 → 복구 권장 사항 자동 생성.

핵심 문제

현대적인 분산 시스템(distributed systems)에서 단일 장애가 고립된 상태로 유지되는 경우는 드뭅니다.

데이터베이스 잠금(database lock)은 다음과 같은 현상을 유발할 수 있습니다:

• API 지연 시간 급증 (latency spikes)
• 게이트웨이 타임아웃 (gateway timeouts)
• 다운스트림 서비스 충돌 (downstream service crashes)
• Kubernetes 재시작 (Kubernetes restarts)

장애가 발생하면 엔지니어들은 서비스 간의 장애를 상관 분석(correlate)하기 위해 다음과 같은 도구들을 수동으로 오가며 작업합니다:

• Grafana 대시보드
• Datadog 경고
• New Relic 트레이스
• 원시 로그 스트림 (raw log streams)

이 과정은 다음과 같은 특징이 있습니다:

• 시간이 많이 소요됨
• 정신적으로 매우 소모적임
• 경험에 대한 의존도가 매우 높음

저는 멀티 에이전트 AI 시스템(multi-agent AI systems)이 이 과정을 도울 수 있을지 탐구하고 싶었습니다.

단순히 로그를 요약하는 것뿐만 아니라,

실제로 다음과 같은 작업을 수행하는 것입니다:

• 유사한 과거 장애 사례 검색 (retrieving similar historical incidents)
• 장애 심각도 분류 (classifying incident severity)
• 이벤트 타임라인 재구성 (reconstructing event timelines)
• 영향을 받은 서비스 식별 (identifying affected services)
• RCA 설명 생성 (generating RCA explanations)
• 복구 단계 제안 (suggesting remediation steps)

OpsMind AI의 등장

OpsMind AI는 SRE 및 DevOps 팀을 위한 AI 기반 관측성 어시스턴트(observability assistant)를 시뮬레이션합니다.

이 플랫폼은 다양한 운영 작업에 특화된 에이전트들을 조율하는 **LangGraph 기반 멀티 에이전트 워크플로우 (multi-agent workflow)**를 통해 관측성 로그 (observability logs)를 처리합니다.

단일한 거대 언어 모델 (LLM) 프롬프트에 의존하는 대신, 시스템은 장애 조사 과정을 여러 단계의 조정된 추론 단계로 분해합니다.

시스템 아키텍처 (System Architecture)

워크플로우는 다음과 같은 시뮬레이션된 모니터링 플랫폼으로부터 로그를 수집하며 시작됩니다:

• Datadog
• Grafana
• New Relic

로그는 정규화된 후 멀티 에이전트 오케스트레이션 파이프라인 (multi-agent orchestration pipeline)으로 전달됩니다.

아키텍처는 다음과 같이 구성됩니다:

검색 에이전트 (Retrieval Agent)

FAISS 벡터 유사도 검색 (vector similarity search)을 사용하여 과거의 장애 사례를 검색합니다.

장애 분류 에이전트 (Incident Classification Agent)

다음 사항을 식별합니다:

• 장애 유형 (incident type)
• 심각도 수준 (severity level)
• 모니터링 소스 (monitoring source)

RCA 에이전트 (RCA Agent)

LLM 추론을 사용하여 근본 원인 분석 (root cause analysis)을 수행하고 해결 권장 사항을 생성합니다.

타임라인 및 영향 분석 (Timeline & Impact Analysis)

운영 이벤트 시퀀스를 재구성하고 영향을 받는 다운스트림 서비스 (downstream services)를 식별합니다.

평가 레이어 (Evaluation Layer)

다음 사항을 측정합니다:

• 검색 정확도 (retrieval accuracy)
• RCA 품질 (RCA quality)
• 지연 시간 (latency)
• 장애 상관관계 신뢰도 (incident correlation confidence)

프론트엔드 대시보드는 운영 관측성 콘솔 (operational observability console)을 시뮬레이션하기 위해 Streamlit을 사용하여 구축되었습니다.

여기서 RAG가 중요했던 이유

이 프로젝트에서 가장 흥미로운 부분 중 하나는 검색 증강 생성 (RAG, Retrieval-Augmented Generation)을 통합한 것이었습니다.

운영 환경의 장애는 종종 반복되는 패턴을 보입니다:

• 데이터베이스 풀 고갈 (database pool exhaustion)
• API 속도 제한 (API rate limiting)
• Kubernetes OOM 크래시 (Kubernetes OOM crashes)
• 재시도 폭풍 (retry storms)
• 데드락 (deadlocks)

OpsMind AI는 매번 LLM에게 처음부터 추론하도록 요청하는 대신, FAISS 벡터 데이터베이스에서 의미론적으로 유사한 과거 장애 사례를 검색하고 이를 RCA 생성 과정에서 문맥적 메모리 (contextual memory)로 사용합니다.

이를 통해 생성된 분석의 일관성이 크게 향상되었습니다.

멀티 에이전트 워크플로우 구축하기

오케스트레이션 레이어는 LangGraph를 사용하여 장애 분석을 특화된 AI 에이전트들의 그래프로 모델링합니다.

이를 통해 워크플로우는 다음과 같은 특징을 갖게 되었습니다:

• 모듈화 (modular)
• 설명 가능성 (explainable)
• 시각화 용이성 (easier to visualize)

제가 특히 즐거웠던 점 중 하나는 각 에이전트가 순차적으로 실행되는 애니메이션 에이전트 실행 대시보드 (animated agent execution dashboard)를 구축한 것이었습니다:

• Retrieval Agent (검색 에이전트)
• Classification Agent (분류 에이전트)
• RCA Agent (장애 원인 분석 에이전트)
• Timeline Agent (타임라인 에이전트)
• Impact Analysis Agent (영향 분석 에이전트)

워크플로 (workflow)가 실시간으로 실행되는 것을 지켜보는 것은 이 시스템을 단순한 챗봇 인터페이스가 아닌, 실제 운영 AI 어시스턴트에 훨씬 더 가깝게 느껴지도록 만들었습니다.

실제 운영 환경의 장애 시뮬레이션

실제 기업의 관측 가능성 (observability) 데이터는 공개적으로 사용할 수 없기 때문에, 다음과 같은 상황에 대해 합성된 운영 스타일의 장애 로그 (synthetic production-style incident logs)를 생성했습니다:

• Kubernetes CrashLoopBackOff 실패
• 데이터베이스 연결 고갈 (database connection exhaustion)
• API 속도 제한 (rate limiting) 실패
• 다운스트림 게이트웨이 충돌 (downstream gateway crashes)

아키텍처 (architecture)는 추후 시뮬레이션된 커넥터 (connectors)를 실제 모니터링 API로 교체할 수 있도록 의도적으로 설계되었습니다.

놀라울 정도로 어려웠던 평가 (Evaluation)

개발 과정에서 예상치 못하게 깨달은 점이 하나 있습니다:

RCA 파이프라인 (pipeline)을 구축하는 것은 그것을 평가하는 것보다 쉬웠습니다.

설득력 있는 AI 설명을 생성하는 것은 매우 쉽습니다.

하지만 다음을 측정하는 것은 훨씬 더 어렵습니다:

• RCA가 실제로 정확한지 여부
• 검색 (retrieval)이 의미가 있는지 여부
• 심각도 분류 (severity classification)가 신뢰할 수 있는지 여부

그렇기 때문에 저는 다음과 같은 항목을 측정하는 평가 레이어 (evaluation layer)를 추가했습니다:

• Retrieval Accuracy (검색 정확도)
• RCA Match Accuracy (RCA 일치 정확도)
• Severity Accuracy (심각도 정확도)
• Average Latency (평균 지연 시간)
• Correlation Confidence (상관관계 신뢰도)

평가를 추가함으로써 이 프로젝트는 단순히 프롬프트 중심 (prompt-driven)인 프로젝트가 아니라, 훨씬 더 엔지니어링 중심적인 프로젝트라는 느낌을 주었습니다.

기술 스택 (Tech Stack)

• Python
• Streamlit
• LangGraph
• FAISS
• SentenceTransformers
• Groq LLM API
• Pandas

해커톤 제약 조건 하에서의 구축

OpsMind AI는 원래 AI 에이전트와 개발자 인프라 워크플로 (developer infrastructure workflows)에 초점을 맞춘 단기 엔지니어링 해커톤 기간 동안 구축되었습니다.

한 가지 흥미로운 도전 과제는 다음과 같은 요소들 사이의 균형을 맞추는 것이었습니다:

• 야심 찬 시스템 설계 아이디어
• 현실적인 구현 범위
• 평가 신뢰성
• UI 완성도
• 배포 제약 조건

저는 이 프로젝트가 단순한 LLM 래퍼 (LLM wrapper)처럼 느껴지기보다 실제 운영 인텔리전스 (operational intelligence) 플랫폼처럼 느껴지기를 원했습니다. 그래서 다음과 같은 요소들에 집중했습니다:

• 멀티 에이전트 오케스트레이션 (multi-agent orchestration)
• 검색 시스템 (retrieval systems)
• 평가 지표 (evaluation metrics)
• 워크플로우 시각화 (workflow visualization)
• 관찰 가능성 (observability) 중심의 아키텍처

제한된 일정 속에서도 합성 텔레메트리 (synthetic telemetry) 생성부터 에이전트 오케스트레이션 및 평가에 이르기까지 시스템을 엔드 투 엔드 (end-to-end)로 구축한 것은 믿을 수 없을 정도로 가치 있는 학습 경험이었습니다.

내가 배운 것들

이 프로젝트를 통해 다음과 같은 것들에 대해 많이 배웠습니다:

• 관찰 가능성 시스템 (observability systems)
• 멀티 에이전트 오케스트레이션 (multi-agent orchestration)
• RAG 파이프라인 (RAG pipelines)
• AI 평가 전략 (AI evaluation strategies)
• 운영 인텔리전스 워크플로우 (operational intelligence workflows)

더 중요한 것은, 이 프로젝트가 AI 시스템을 바라보는 저의 사고방식을 바꾸어 놓았다는 점입니다.

흥미로운 도전 과제는 텍스트를 생성하는 것이 아니었습니다.

그것은 다음과 같은 시스템을 설계하는 것이었습니다:

• 운영 데이터를 통해 추론하는 시스템
• 특화된 에이전트들을 조정하는 시스템
• 문맥적 메모리 (contextual memory)를 검색하는 시스템
• 실행 가능한 출력 (actionable outputs)을 생성하는 시스템

이것이 실제 세상의 AI 시스템이 진화할 방향에 훨씬 더 가깝다고 느껴집니다.

데모 및 저장소

GitHub 저장소

Anucool419 / OpsMind-AI

OpsMind AI — 멀티 에이전트 장애 원인 분석 (RCA) 아키텍처

# OpsMind AI — 멀티 에이전트 장애 원인 분석 (RCA) 아키텍처

문제 정의 (Problem Statement)

장애 발생 시, 엔지니어들은 근본 원인을 파악하기 위해 로그, 대시보드, 알림을 검색하는 데 귀중한 시간을 낭비합니다.

해결책: Datadog, Grafana 또는 New Relic과 같은 모니터링 도구에 연결하여 로그와 인시던트를 실시간으로 분석하고, 발생 가능한 근본 원인을 식별하며, 해결 방법을 즉시 제안하는 AI 에이전트입니다.

주요 기능 (Features)

• LangGraph를 사용한 멀티 에이전트 워크플로우 오케스트레이션
• 과거 인시던트 매칭을 위한 검색 증강 생성(RAG)
• FAISS 벡터 유사성 검색
• 모니터링 플랫폼 커넥터 아키텍처
• 자동화된 인시던트 타임라인 생성
• 영향받은 서비스 감지
• 동적 인시던트 메트릭 시각화
• AI 시스템 평가 대시보드
• 다운로드 가능한 인시던트 보고서
• Streamlit 기반 관측 가능성(Observability) 대시보드

아키텍처 (Architecture)

[

](https://private-user-images.githubusercontent.com/131336646/597310334-936108a1-80b8-43d0-a2bb-f0f3855cc2cf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Nzk2NDMwNDgsIm5iZiI6MTc3OTY0Mjc0OCwicGF0aCI6Ii8xMzEzMzY2NDYvNTk3MzEwMzM0LTkzNjEwOGExLTgwYjgtNDNkMC1hMmJiLWYwZjM4NTVjYzJjZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNTI0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDUyNFQxNzEyMjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02OTFiN2JhOTdlN2Q1ZWI1MGVmOTcxMWY0NzcwMGVjZmZmZWQ0ZDk0MDRjOThmNDc5ZDY1Y2VhY2I1NTA4ZTVkJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.tMYiVw0_Hr1iz_6kKQRDPbBZ1NqYPFHIRy-pAYtz5Zs