Teams 알람 기반 RCA 멀티 에이전트 설계

이 글은 운영 사례가 아니라 설계 단계의 아키텍처를 정리한 기록이다.

모니터링 시스템은 "5XX 발생", "Redis Timeout"과 같은 알람을 Teams 채널로 전송한다. 이후 대상 서비스를 식별하고 관련 로그와 메트릭을 확인하는 작업은 운영자가 직접 수행해야 했다. 이 초기 조사 과정을 Teams의 봇 멘션으로 시작할 수 있도록 RCA(Root Cause Analysis) 멀티 에이전트 워크플로우를 설계했다.

전체 흐름

목표는 알람 전달에 그치지 않고, Teams 멘션을 시작점으로 관련 데이터 수집과 원인 후보 분석까지 이어가는 것이다.

모니터링 알람(Azure Monitor / Whatap / Jennifer 등)
  → Teams 운영 채널에 알람 메시지
  → 메시지에서 @RCA Bot 멘션 감지 (Webhook 트리거)
  → Alert Parser: 알람 메시지 파싱
  → Context Extractor: 서비스/리소스·심각도·시간·태그 추출
  → Target Resolver: 대상 서비스와 연관 구성요소 식별
  → RCA Orchestrator: 규칙 기반으로 전문 에이전트 분배
  → 전문 에이전트들이 로그·메트릭·이벤트 수집·분석
  → Evidence Correlation: 근거 상관관계 분석
  → Teams Reply: 원인·증거·영향·권장 조치를 알람 스레드에 응답

오케스트레이터를 규칙 기반으로 설계한 이유

RCA Orchestrator는 LLM의 자율 판단에 맡기지 않고 사전에 정의한 규칙과 조건으로 동작하도록 설계했다. 알람 유형·태그·대상 서비스·심각도에 따라 호출할 전문 에이전트와 실행 순서를 결정한다. 운영 자동화에서는 같은 입력에 대해 일관된 조사 절차가 실행돼야 하기 때문이다. LLM은 수집한 자료를 해석하고 원인 후보를 정리하지만, 조사 범위와 호출 순서는 규칙이 담당한다.

영역별 전문 에이전트

분석 역할은 인프라·네트워크·보안·데이터·운영 영역으로 분리했다.

각 에이전트는 담당 영역의 로그·메트릭·이벤트·구성 정보를 수집하고, LLM을 이용해 원인 후보와 추가 점검 항목을 정리한다. 팀별 운영 절차와 서비스별 점검 기준은 사전 지식으로 제공할 계획이다.

공통 도구로는 로그/쿼리, 메트릭/APM, 정책/시크릿, API/권한, 변경 이력/구성, 과거 장애 이력(Knowledge DB) 조회를 둔다.

응답과 오류 처리

분석 결과는 응답 레이어에서 정리한 뒤 원래 알람이 발생한 Teams 스레드에 게시한다. 응답에는 원인 후보, 주요 근거, 영향받은 서비스, 권장 조치와 추가 확인 항목을 포함한다.

실패 처리도 별도의 경로로 정의했다. 권한 부족·인증 실패·데이터 부족이 발생하면 근거가 부족한 RCA를 생성하지 않고, 수집하지 못한 정보와 실패 원인을 응답한다. 오류 상황도 조사 이력에 저장해 후속 확인이 가능하도록 한다. 운영 도구에서는 분석할 수 없는 상태를 명확히 알리는 것이 중요하다.

이력을 남기는 이유

모든 RCA 실행에서 조사 단계별 로그, 분석 결과와 조치 내용, 관련 장애 이력을 저장한다. 누적된 이력은 유사 장애의 재발 여부를 확인하고 이후 분석의 근거를 찾는 데 활용한다.

기대하는 것

• 알람 기반 RCA 대응 시간 단축
• 서비스별 전문 분석으로 원인 파악 정확도 향상
• 로그·메트릭·이벤트·변경 이력의 통합 분석
• 표준화된 Teams 응답과 조사 이력 기반 재발 방지

현재는 설계 단계이므로 대응 시간과 분석 정확도에 대한 운영 수치는 없다. 구현 후에는 알람 유형별 조사 소요 시간, 근거 수집 성공률과 운영자 수정 비율을 측정해 구조의 실효성을 확인할 예정이다.

참고

• Azure Monitor
• Microsoft Teams — Webhooks
• AKS
• Istio
• Kyverno