장애 Alert의 원인을 스스로 찾다: SRE Observer 개발기

들어가며 안녕하세요. LINE Plus에서 Home 서비스의 안정성을 책임지고 있는 Home SRE(Site Reliability Engineering) 팀입니다. SRE Observer는 Alert를 받으면 여러 관측 신호를 연결해 원인을 분석하고, 대응에 필요한 정보를 정리해 주는 자동 대응 파이프라인입니다. 이 글에서는 SRE Observer를 만들게 된 배경과 주요 설계 과정을 소개하겠습니다. 새벽 3시. 장애 알림이 울렸습니다. 담당자는 보통 다음과 같은 순서로 원인을 추적하기 시작할 것입니다. 알림을 확인한다.대시보드를 열어 메트릭을 확인한다.로그 플랫폼으로 이동해 같은 시간대에 발생한 에러를 검색한다.트레이스를 열어 어떤 요청이 문제였는지 확인한다.필요하면 프로파일까지 확인한다. Alert의 초기 대응은 여전히 사람의 몫이었습니다. 원인을 찾는 데 필요한 관측 신호는 이미 각 도구에 존재합니다. 문제는 그 신호들이 서로 다른 화면에 흩어져 있어, 이를 하나의 흐름으로 엮고 ‘그래서 원인이 무엇인가’를 판단하는 과정을 담당자가 직접 수행해야 한다는 점입니다. 알림을 인지하고 여러 도구를 오가며 신호를 연결하는 최초의 몇 분은 장애 대응에서 매우 중요한 시간입니다. 이 시간을 줄이기 위해 초기 대응의 시작점부터 자동화하고 싶었습니다. 목표는 단순했습니다. ‘Alert를 수신하면, 사람이 개입하기 전에 시스템이 먼저 상관분석을 수행하고, 근본 원인을 찾아 Slack에 보고까지 마친다.’ 이 목표를 구현한 결과물이 SRE Observer입니다. 자체 관측성 스택(LGTM-P)과 Slack, Kubernetes 등의 데이터 소스를 기반으로 LLM(Large Language Model, 대규모 언어 모델)과 MCP(Model Context Protocol)를 활용해 근본 원인을 분석합니다. SRE Observer를 도입한 결과, 초기 Alert 노이즈의 85~95%를 실시간으로 차단하고 평균 장애 식별 시간(MTTR)을 50% 단축하는 성과를 거두었습니다. 이 성과는 기존 장애 대응 과정에서 반복적으로 마주한 문제를 정리하는 데서 출발했습니다. SRE 팀이 마주한 문제 크게 세 가지 어려움이 있었습니다. 알림이 너무 많이 쏟아졌고, 원인을 찾는 과정은 여전히 사람의 수동 판단에 의존했으며, 기존 도구만으로는 운영 환경에 맞는 수준의 제어권을 확보하기 어려웠습니다. Alert 노이즈 폭탄 하나의 장애가 하나의 ...