Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

들어가며: 관측성 데이터는 많아졌지만, 분석은 여전히 어렵습니다 안녕하세요. LY Corporation에서 Home 서비스의 안정성을 책임지고 있는 Home SRE(Site Reliability Engineering) 팀입니다. 장애 알림이 울렸을 때의 장면을 떠올려 보겠습니다. 먼저 대시보드를 열어 메트릭을 확인합니다.이어서 로그 플랫폼으로 이동해 같은 시간대의 에러 로그를 검색합니다.그래도 원인이 명확하지 않으면 트레이스 도구를 열어 어떤 요청이 문제였는지 살펴봅니다.필요하다면 프로파일도 확인합니다. 장애의 원인을 밝힐 수 있는 각각의 신호는 분명히 존재합니다. 문제는 그 신호들이 서로 다른 화면에 흩어져 있다는 점입니다. 메트릭은 에러율이 올랐다고 말하고, 로그는 특정 예외 메시지를 보여 주고, 트레이스는 어떤 요청이 오래 걸렸는지 알려 줍니다. 하지만 이 세 가지를 하나의 이야기로 엮어 "그래서 원인이 무엇인가"를 판단하는 일은 여전히 사람이 해야 했습니다. 저희는 이 과정을 줄이고 싶었습니다. 목표는 단순했습니다. "Grafana에서 자연어로 질문하면, 메트릭·로그·트레이스·프로파일을 함께 조회하고 원인 후보까지 정리해 주는 도구를 만들자." 그 결과물이 SRELens입니다. SRELens는 Grafana 애플리케이션 플러그인으로 작동하는 자연어 기반 관측 데이터 분석 도구입니다. 사용자가 ‘이 시간대에 왜 에러가 늘었는지 분석해 줘’라고 묻는다면, 대규모 언어 모델(LLM, Large Language Model) 기반 에이전트가 실제 관측성 데이터를 조회하고, 필요한 도구를 호출하며, 근거와 함께 분석 결과를 제시합니다. 또한, LLM에게 맡긴 분석이 실패할 수 있다는 것을 전제하여 어디까지 LLM에게 맡기고, 어디부터는 코드와 정책으로 통제할 수 있는지도 고민하였습니다. 이 글에서는 SRELens를 만든 배경과 오픈소스 PoC(Proof of Concept, 개념 검증)에서 확인한 한계, 운영 환경을 위해 직접 구현한 설계, 그리고 실제 분석 시나리오를 소개하겠습니다. SRE 팀이 마주한 문제 먼저 저희가 겪고 있던 문제를 조금 더 구체적으로 살펴보겠습니다. 메트릭, 로그, 트레이스가 서로 다른 화면에 있었습니다 저희 환경에서는 관측성 데이터가 종류별로 나뉘어 있었습니다. 메트릭은 Grafana 또는 사내 메트릭 플랫폼 IMON에서 확인합니다.로그는 사내 로그 플랫폼 LaaS, IU에서 검색합니다....