APM이란? 서버 모니터링으로 못 잡는 장애에 대한 원인(RCA) 을 찾을 수 있어요

AI로 운영하는 APM — 프롬프트로 묻고, AI 에이전트가 분석한다

지금까지의 APM이 “데이터를 잘 모아 사람이 읽는” 도구였다면, 최근의 변화는 그 데이터를 자연어로 묻고 AI가 대신 분석하는 방향으로 넘어가고 있습니다. 운영자가 대시보드 메뉴를 차례로 열고 SQL을 짜는 대신, “지금 결제가 왜 느려?”라고 한 문장으로 물으면 AI가 트랜잭션·SQL·스레드 데이터를 읽어 원인 가설과 다음 점검 항목을 돌려줍니다. 이렇게 자연어 프롬프트로 운영 데이터를 질의하고 장애를 분석하는 운영 방식을 VibeOps(바이브옵스, 자연어 프롬프트로 운영하는 패러다임)라고 부릅니다. AI 연구자 안드레이 카파시(Andrej Karpathy)가 제안한 바이브 코딩(VibeCoding)을 운영 영역으로 옮긴 개념입니다.

VibeOps에는 짝이 되는 거버넌스 개념이 하나 따라붙습니다. PromptOps(프롬프트옵스)는 운영에 쓰는 프롬프트를 코드처럼 다루는 체계입니다. 프롬프트마다 버전을 매기고, 변경 시 검증을 거치고, 승인된 사람만 운영에 반영하며, 모든 실행을 감사 로그로 남깁니다. “AI로 편하게 운영한다”를 “AI로 안전하게, 추적 가능하게 운영한다”로 받쳐 주는 장치입니다. 두 용어가 아직 공식 분석기관의 표준 어휘로 굳어진 단계는 아니지만, 자연어로 운영을 다룬다는 흐름의 방향은 분명합니다.

APM에 들어온 AI 엔진, CogentAI. OPENMARU APM은 이 자연어 운영을 CogentAI(코전트AI)라는 통합 AI 엔진으로 제품 안에 넣었습니다. CogentAI는 세 가지를 하나로 묶은 구조입니다 — 자연어를 이해하는 LLM(Large Language Model, 대규모 언어 모델), 운영 매뉴얼·장애 이력 같은 근거 문서를 함께 읽는 RAG(Retrieval-Augmented Generation, 검색 증강 생성), 그리고 APM의 메트릭·로그·트레이스를 실시간으로 끌어오는 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 연동입니다. LLM 혼자서는 그럴듯하지만 사실과 다른 답(할루시네이션)을 만들 수 있으므로, RAG로 조직의 운영 기준을, MCP로 지금 이 순간의 실측 데이터를 함께 물려 응답에 근거를 붙입니다.

APM 화면 안에서 이 AI 에이전트가 실제로 해 주는 일은 이렇습니다.

• 시스템 전체 진단: 헤더의 “AI 진단” 버튼 한 번으로 선택한 앱 그룹 전체를 점검해, 이상 징후와 먼저 봐야 할 지표를 구조화된 보고로 돌려줍니다.
• 느린 SQL 진단: 느린 트랜잭션 안의 SQL을 골라 실행계획을 분석하고, 병목(풀스캔·누락 인덱스)을 짚어 다시 쓴 SQL과 권장 인덱스까지 제안합니다. 콘솔의 진단은 EXPLAIN과 통계 조회만 하고 쿼리를 실제로 실행하지 않아 운영 DB 부담이 거의 없습니다.
• 스레드 덤프 분석: “살아 있는데 응답이 없는” 상황에서 스레드 덤프를 떠 데드락 여부, 스레드 풀 고갈, 오래 걸리는 호출 대상을 표로 추려 줍니다.
• 이벤트 원인 진단: 임계치 초과 같은 이벤트 한 건을 그 자리에서 AI에게 넘겨 “왜 났고 무엇부터 봐야 하는지”를 자연어로 받습니다.

AI가 답해도, 조치는 사람이 결정합니다. 여기서 지켜야 할 원칙이 Human-in-the-Loop(사람 개입 유지)입니다. AI의 답은 어디까지나 출발점이고, 재시작·설정 변경·트래픽 라우팅 변경처럼 돌이키기 어려운 조치는 사람이 근거를 확인한 뒤 실행합니다. 여기에 개인정보 자동 마스킹(주민등록번호·연락처 같은 식별자를 AI에 넘기기 전에 가리는 처리)과 감사 추적(어떤 질의가 어떤 근거로 어떤 답을 냈는지 남기는 기록)이 더해져, ISMS-P·CSAP 같은 국내 인증이 요구하는 “AI 자동 조치에 대한 인적 통제”와도 맞물립니다. AI로 운영하기의 값은 사람을 빼는 데 있지 않고, 사람이 더 빨리·더 근거 있게 판단하도록 돕는 데 있습니다.

한 가지 실제 장면으로 정리하면, WAS의 OOM(Out Of Memory, 메모리 부족) 장애가 그렇습니다. OOM은 힙을 키운다고 사라지는 “메모리 상태”가 아니라, 특정 비즈니스 로직이 만들어 내는 “흐름의 결과”인 경우가 많습니다. VibeOps 방식의 AI 진단은 APM이 모아 둔 트랜잭션 지연·과도한 DB 페치·GC 부하를 함께 읽어, 어떤 로직이 문제의 객체 할당을 촉발했는지를 시스템이 무너지기 전에 짚어 냅니다(AI 기반 VibeOps — WAS OOM 분석의 패러다임을 바꾸다). VibeOps 개념 자체를 더 보고 싶다면 VibeOps란 무엇인가요?에서 이어 읽을 수 있습니다.