LLM에게 로그만 주면 RCA(Root Cause Analysis)를 할 수 있을까?

Intro

안녕하세요. 블록체인 개발자 최원혁입니다.

이번에 OP Stack을 활용해 Layer 2 체인을 구축하는 프로젝트에 합류하게 되었습니다. 이번 프로젝트는 특성상 DevOps / SRE와 밀접한 업무가 많았고, 그 과정에서 알림이나 장애, 이슈가 발생했을 때 문제의 원인을 파악하는 RCA(Root Cause Analysis) 과정을 AI Ochestration를 설계하여 개선해보았습니다.

Google SRE의 운영 철학을 바탕으로 AI 에이전트가 여러 조사를 병렬로 수행하고, 가설을 형성하고 검증하면서 RCA를 진행해 문제의 원인과 해결 방안을 제시하는 방식입니다. 이번 글에서는 실제로 이러한 접근을 적용했던 사례에 대한 이야기를 풀어보겠습니다.

직면한 문제

이번 프로젝트에서는 인프라 구성부터 각 노드의 구축과 동기화, 그리고 운영까지 하나의 블록체인 네트워크 전체를 구축하는 업무를 담당하게 되었습니다.

문제는 팀 자체가 신설된 지 얼마 되지 않아 인원이 많지 않았고, OP Stack을 다뤄본 경험 역시 거의 없었다는 점입니다. 따라서 OP Stack에 대한 스터디와 블록체인 인프라 구축을 동시에 진행해야 했습니다. 하지만 문제가 발생하면 원인을 분석하는 데만 하루를 넘어가는 경우도 있어서 일정안에 프로젝트 완수를 장담하기 힘든 상황이였습니다.

이런 상황에서 문제가 발생할 때마다 사람이 처음부터 원인을 추적하는 방식으로는 한계가 있다고 판단했고, 문제를 분석하고 원인을 찾아는 RCA 과정을 AI를 활용해 자동화해야겠다고 생각했습니다.

AI RCA pipelin

Google SRE는 크게 5단계의 흐름으로 업무를 수행하며, 그중 RCA는 관측 데이터를 바탕으로 가설을 반복적으로 검증하면서 장애에 기여한 구조적인 원인을 찾아내는 과정으로 설명합니다. 단순히 원인을 발견하는 데서 끝나는 것이 아니라, 확인된 원인을 수정해 같은 형태의 장애가 다시 발생하지 않도록 만드는 것까지 포함합니다.

여기서 중요한 점은 RCA가 단순히 하나의 “원인”을 찾는 작업이 아니라는 점입니다. 발생한 문제 상황에 대해 여러 가설을 세우고, 관측 가능한 데이터를 통해 각 가설을 단계적으로 검증하거나 기각하면서 원인을 좁혀가는 과정입니다. 실제로 Google SRE Book에서도 RCA를 통해 하나의 명확한 원인만을 도출하려는 접근은 위험할 수 있다고 설명합니다.

따라서 “가설을 만들고 → 증거를 수집하고 → 가설을 검증하거나 기각한다”는 방식으로 RCA에 접근하는 방법론을 권장합니다. 저 역시 이 흐름을 AI에 적용해서 RCA Skill이 트리거되면 먼저 프롬프트를 통해 가능한 가설을 설계하고, 이후 관측 데이터를 수집해 각 가설을 증명하거나 기각할 수 있도록 AI RCA pipeline을 구성했습니다.

RCA를 위한 하네스 설계

RCA는 똑똑한 LLM 모델 보다 양질의 데이터가 훨신 중요하다.

Coroot의 리서치 아티클을 보면 “LLM을 더 똑똑하게 만드는 것보다, LLM이 판단하기 좋은 Context를 만들어주는 Observability / RCA Pipeline을 설계하는 것이 더 어렵다”는 것입니다. 실제로 RCA에 필요한 Context를 동일하게 제공했을 때 Claude Opus 4.8, GPT-5.5, Gemini 3.1 등 여러 LLM이 문제의 원인을 제대로 찾아냈습니다.

이를 바탕으로 저자는 “올바른 Context가 이미 준비되어 있다면 LLM의 RCA Reasoning은 상당 부분 해결된 문제에 가깝다”고 주장합니다.

Google SRE Book에서도 문제를 분석할 때 메트릭이나 로그 하나에만 의존하지 않습니다. 메트릭과 로그를 시작으로 분산 트레이싱, 현재 시스템 상태와 설정, 최근 배포 및 변경 사항, 직접 수행한 테스트 요청 등 다양한 관측 정보를 활용해 가설을 검증하고 문제의 범위를 좁혀갑니다.

결국 핵심은 꽤 명확합니다. AI 기반 Root Cause Analysis에서 가장 어려운 문제는 더 이상 LLM의 추론 능력 자체가 아니라, LLM에게 어떤 데이터를 어떤 형태로 제공할 것인지 결정하는 ‘Harness’를 설계하는 것입니다.

4 Layer Harness

앞서 살펴본 내용을 바탕으로, 저는 AI 에이전트가 RCA를 수행하는 데 충분한 정보를 제공할 수 있는 환경, 즉 Harness를 구축해봤습니다. MCP, CLI Tool, 내부 시스템 등 다양한 도구와 파이프라인을 연결해 AI가 RCA에 필요한 정보를 직접 수집하고 조회할 수 있도록 AI Orchestration을 설계했습니다.

특히 AI가 스스로 증거를 수집하고 가설을 검증할 수 있도록 필요한 데이터를 크게 Observability / On-chain Data / Source Code / Domain의 4개 Layer로 구성해봤습니다.

Layer 1 : Observability

Observability(관측 가능성)는 시스템이 외부로 내보내는 신호를 바탕으로 내부에서 어떤 일이 발생하고 있는지를 설명할 수 있는 성질입니다. 이를 위해 로그와 메트릭 등 시스템에서 생성되는 데이터를 수집하고, 현재 시스템의 상태를 시각적으로 실시간 확인할 수 있도록 모니터링 환경을 구축했습니다.

Grafana LGTM

저희 환경에서는 자체 호스팅(Self-hosted) 방식으로 Grafana를 구축했고, Grafana에서 주로 사용되는 LGTM 아키텍처를 기반으로 모니터링 환경을 설계했습니다.

• Loki : 로그 원본 저장/처리
• Tempo : 분산 트레이스 저장/처리
• Pyroscope : 프로파일 저장/처리
• Prometheus(Metrics) : 메트릭 저장/처리

각 구성 요소는 모두 Docker Container로 실행되며, 사용하는 프로토콜과 데이터의 특성에 따라 데이터를 직접 전송하는 Push 방식과 데이터를 가져오는 Pull 방식을 함께 사용합니다.

이렇게 수집된 정보는 Grafana에서 대시보드 형태로 구성하고 시각화해 시스템의 상태를 실시간으로 모니터링하는 데 활용합니다. 또한 수집된 정보를 바탕으로 운영 정책과 임계치를 설정하고, 특정 조건을 만족할 경우 알림이 발생하도록 구성하였습니다. 특히 Tempo와 Pyroscope 는 블록체인 노드에서 발생하는 이벤트를 중심적으로 관리하는데요.

Tempo는 op-reth가 남기는 Engine API 처리 경로를 Span 단위로 수집해 Trace 정보를 저장합니다. 해당 Span에는 하나의 블록이 노드 내부에서 처리되는 과정(EVM 실행 → State Root 계산 → DB 쓰기)과 각 단계별 소요 시간이 기록되어 있어, 블록 처리 과정에서 어느 구간이 지연되고 있는지 확인할 수 있습니다.

Pyroscope는 OP Stack의 합의 레이어인 op-node의 프로파일 정보를 저장합니다. 이를 통해 CPU·Heap·Goroutine·Lock 경합 등을 함수 단위로 확인할 수 있으며, 자원이 어떤 함수와 처리 과정에서 사용되고 있는지를 파악할 수 있습니다.

Grafana MCP

Grafana는 공식 MCP를 제공하고 있습니다. 이를 stdio 방식으로 LLM에 연결해, AI가 앞서 구분한 4개 Layer 중 Observability(관측 가능성) 정보를 AI 에이전트 스스로 조회할 수 있도록 도구를 구성했습니다.

필요한 정보에 따라 LogQL·PromQL·TraceQL·Pyroscope Query를 직접 작성하고, 그 결과를 JSON 형태로 받아 문제를 분석하고 가설을 증명하는데 활용합니다.

{
    "metric": {
        "__name__": "reth_transaction_pool_pending_pool_transactions",
        "component": "op-reth",
        "instance": "seq-1",
        "role": "sequencer"
    },
    "value": [
        1786495336.63,
        "0"
    ]
}

이때 반환되는 JSON은 데이터 자체가 일정한 구조를 가지고 있기 때문에 AI가 내용을 해석하기에 충분한 정보를 제공합니다. 특히 Prometheus는 _total은 누적 카운터, _seconds는 초 단위처럼 표준화된 명명 규칙을 사용하기 때문에 AI가 별도의 설명 없이도 메트릭의 의미와 구조를 파악할 수 있습니다.

다만 이러한 구조와 명명 규칙만으로는 해당 메트릭이 실제로 무엇을 의미하는지 판단하기 어려운 경우도 있습니다. 이런 경우에는 결국 해당 지표가 어떤 로직에서 생성되고 어떤 상황을 나타내는지 확인하기 위해 소스 코드까지 함께 살펴볼 필요가 있습니다.

Layer2 : Source Code

AI가 로그를 분석하고 메트릭을 확인할 수 있다고 해도, 그것만으로 문제가 발생한 정확한 원인을 찾아내기에는 한계가 있습니다. 따라서 Observability Layer에서 특정 로그나 에러 메시지를 발견하면, 해당 메시지가 어떤 코드에서 발생했고 어떤 조건에서 실행되는지 소스 코드 레벨까지 추적해 더 정확한 원인을 찾을 수 있도록 Harness를 구성했습니다.

Codegraph — 코드 지식 그래프(Code Knowledge Graph)

colbymchenry/codegraph는 한마디로 말하면 AI 코딩 에이전트가 코드베이스를 파일 단위로 뒤지는 대신, 미리 만들어 둔 코드 지식 그래프(Code Knowledge Graph)를 질의하게 만드는 정적 분석 도구입니다.

CodeGraph를 활용하면 소스코드의 Symbol뿐만 아니라 Import, Call, Inheritance 등의 코드 관계를 분석해 SQLite 기반 Knowledge Graph에 저장합니다. 이렇게 만들어진 그래프를 통해 특정 함수가 어디에서 호출되고 어떤 코드와 연결되어 있는지를 빠르게 추적할 수 있습니다.

또한 이러한 관계를 조회하기 위한 CodeGraph MCP를 함께 제공하기 때문에, LLM이 별도의 복잡한 탐색 과정 없이 Knowledge Graph를 활용해 필요한 코드를 찾아갈 수 있습니다.

이를 통해 Observability Layer에서 발견한 로그나 메트릭을 출발점으로 관련 소스 코드와 호출 경로를 추적하고 문제 원인을 뒷받침할 증거까지 수집할 수 있도록 구성했습니다.

https://github.com/colbymchenry/codegraph#why-codegraph

이러한 구조는 단순히 필요한 코드를 빠르게 찾는 것뿐만 아니라, LLM이 불필요한 소스 코드까지 읽지 않도록 해 토큰 사용량도 줄여주며, 특히 코드베이스가 큰 Monorepo에서 효과적이라고 합니다.

OP Stack의 경우 여러 컴포넌트가 하나의 Monorepo에 구성되어 있을 뿐만 아니라 Go, Rust, Solidity 등 다양한 프로그래밍 언어가 통합되어 있기에, LLM이 전체 코드를 직접 탐색하며 관계를 파악하기에는 부담이 큽니다. 그래서 OP Stack의 소스 코드를 Knowledge Graph(지식 그래프)로 변환하고, 이를 통해 AI가 필요한 코드만 효율적으로 탐색하면서 함수와 모듈 간의 관계까지 빠르게 파악할 수 있도록 설계했습니다.

Layer3 : Onchain Data

일반적인 IT 도메인과 달리, OP Stack 기반의 Layer 2 블록체인 네트워크에서는 문제의 원인이 온체인 데이터에 존재하는 경우도 있습니다.

Batch Poster의 동작, Challenge를 위한 Fault Proof, Bridge의 입출금 기록 등은 노드 로그에서도 일부 흔적을 확인할 수 있지만, 실제 트랜잭션의 상태나 이벤트, 컨트랙트 실행 결과와 같은 온체인 데이터를 직접 조회해야 정확하게 확인할 수 있습니다.

Blockscout MCP Server

그래서 AI가 온체인에서도 RCA에 필요한 증거를 직접 수집할 수 있도록 Blockscout MCP를 연결했습니다. Blockscout는 Explorer 형태의 UI/UX뿐만 아니라, 내부 인덱서가 수집한 데이터를 조회할 수 있는 API도 제공합니다. Blockscout MCP는 이 API를 LLM과 연결해주는 역할을 합니다.

여기에 현재 체인에서 사용하는 주요 지갑과 시스템 컨트랙트 주소도 함께 제공해, AI가 트랜잭션·이벤트·컨트랙트·주소 등의 정보를 직접 조회할 수 있도록 구성했습니다.

실제로 잘 동작하던 브릿지에서 동일한 지갑과 거의 동일한 조건으로 30분 간격을 두고 입금 트랜잭션을 여러 차례 호출한 적이 있습니다. 그런데 어떤 트랜잭션은 정상적으로 처리된 반면, 어떤 트랜잭션은 실패하는 현상이 발생했습니다.

겉으로 보기에는 특별히 달라진 조건이 없었기 때문에, 단순히 노드 로그만 확인해서는 원인을 파악하기 어려운 상황이었습니다.

이 문제를 MCP를 통해 AI 에이전트에게 분석시켰고, 실제로 상당히 깊은 단계까지 온체인 데이터와 컨트랙트 실행 흐름을 추적하면서 원인을 찾아냈습니다.

만약 Onchain Data를 조회할 수 있는 MCP가 없었다면, Observability Layer에서는 단순히 “브릿지 입금 과정에서 실패했다”는 증상까지만 파악할 수 있었을 것입니다. 이후의 정확한 원인은 사람이 직접 온체인 데이터와 컨트랙트 코드를 추적하며 찾아야 했고, 특히 이 정도 깊이의 문제는 시간도 오래 걸렸을겁니다.

Layer 4 : Domain

Domain은 구축한 Paychain 프로젝트 자체에 대한 고유한 정보를 의미합니다. 예를 들어 네트워크를 구성하는 인스턴스 아키텍처, 각 노드 컨테이너의 실행 옵션 등이 이에 해당합니다.

실제로 RCA 결과를 받아보면 Observability나 Source Code만으로는 특정 가설을 끝까지 검증하지 못하는 경우가 있었습니다. AI 역시 필요한 프로젝트 정보가 없으면 해당 부분을 불확실한 요소로 남기거나, 가설을 검증하기 위해 추가로 확인해야 할 정보를 제시합니다.

이 과정을 보면서 RCA에 필요한 Domain 정보를 AI가 직접 조회할 수 있는 도구가 필요하다고 판단했고, 스스로 도메인 정보를 조회할 수 있도록 별도의 CLI Tool을 만들기로 결정했습니다.

CLI Tool

이 CLI는 단순히 AI RCA만을 위해 만든 도구는 아닙니다. 15대 이상의 노드를 대상으로 블록 동기화 상태를 병렬로 조회하거나, 인스턴스에 직접 요청을 보내 정보를 조회하는 등 Layer 2 네트워크 운영 전반을 지원하기 위해 팀 내부에서 사용하는 TUI 도구입니다.

구축된 블록체인 인스턴스는 Bastion을 통해서만 접근할 수 있으며, 대부분의 노드는 VPC 내부에 존재했습니다. 따라서 각 노드의 정보를 직접 확인하려면 SSH 접속 권한을 가진 Key(.pem)가 필요하고, 허용된 IP의 로컬 PC에서만 접근할 수 있습니다.

이러한 제약 때문에 외부 도구를 그대로 사용하기보다는 내부 환경에 맞는 자체 CLI Tool를 구축했고, golang.org/x/crypto/ssh SDK를 통해 CLI가 각 인스턴스에 직접 SSH 요청을 보내고 필요한 정보를 조회할 수 있도록 구성했습니다.

이를 통해 사람뿐만 아니라 AI 에이전트 역시 특정 인스턴스에서 ‘docker inspect’ 또는 ‘cat’ 명령어로 도메인 정보를 조회하면서, RCA 과정에 필요한 프로젝트 고유의 정보를 직접 확인할 수 있습니다.

SSH 명령어를 자유롭게 사용할 수 있도록 허용한 것은 아닙니다. AI LLM에게 이러한 권한을 그대로 부여하는 것은 위험하다고 판단했기 때문입니다. 대신 cat, docker inspect처럼 필요한 작업을 미리 CLI 명령어로 정의하고, 정해진 명령어만 실행할 수 있도록 제한했습니다. 이처럼 실행 가능한 작업의 범위를 명확하게 통제할 수 있다는 점 역시 별도의 CLI를 만들어 사용할 때 얻을 수 있는 장점입니다.

실제 분석 시나리오

현재 SRE Orchestration에는 각 Layer의 도구를 언제, 어떻게 사용해야 하는지에 대한 지침과 가이드가 CLAUDE.md에 작성되어 있습니다. AI는 이를 바탕으로 스스로 판단하며 가설을 세우고 필요한 데이터를 수집합니다.

실제로 AI Agent가 RCA를 수행했던 사례 하나를 재구성하면 다음과 같습니다.

1. CPU 사용률 95% 도달 알림 발생
2. Prometheus에서 CPU 사용률 증가 시점 확인
3. Loki 로그 확인 — 다수의 트랜잭션과 Gateway Server의 Limit exceeded 로그 반복 발생
4. Blockscout MCP로 트랜잭션 분석 — 특정 규칙성이 없어 DDoS 가능성 배제
5. Domain 정보 조회 — 해당 시점에 정책상 허용된 RPS 초과 요청 발생

이처럼 AI Agent는 먼저 가설을 세우고, 해당 가설을 검증하기 위한 여러 현상과 증거를 각 Layer 및 구축된 도구(MCP/CLI)를 활용해 수집합니다. 앞서 RCA를 위한 하네스 설계에서 이야기했던 것처럼, 관측 가능한 정보가 많을수록 AI가 더 다양한 증거를 활용해 가설을 검증하고, 보다 정확한 원인 분석을 시도하는 것을 확인할 수 있었습니다.

———————————————————————

지금까지는 AI 에이전트가 RCA에 필요한 데이터를 직접 수집할 수 있도록 구성한 4개의 Layer 설계를 살펴봤습니다. 이제부터는 원인 분석이 끝난 이후, 그 결과를 어떻게 후속 조치로 연결했는지에 대해 설명하겠습니다.

LLM WIKI 기반의 Postmortem

Google SRE에서 RCA를 했다면 같은 문제가 다시 발생하지 않도록 조치하고, 혹시 다시 발생하더라도 어떻게 대응해야 하는지를 Postmortem 문서로 정리하는 후속조치를 중요하게 강조합니다. 그리고 해당 문서를 구성원들이 함께 학습하면서 조직의 경험과 지식을 지속적으로 축적해 나가는 것이 중요합니다.

이제 프로젝트를 수행하는 구성원은 사람만 있는 것이 아닙니다. AI 에이전트 역시 실제 업무를 수행하는 하나의 구성원이기 때문에, Postmortem 역시 사람이 읽고 쓰는 것뿐만 아니라 LLM이 읽고 활용하는 것까지 고려할 필요가 있습니다.

그래서 Google SRE가 강조하는 Postmortem의 핵심인 “장애를 조직의 지식으로 축적하고, 이후 발생하는 장애 대응에 활용한다”는 과정을 LLM WIKI를 활용하여 AI Orchestration 안에도 포함시켰습니다.

LLM Wiki는 Karpathy가 제안한 패턴으로, 사람이 아니라 LLM이 읽고 쓰는 것을 전제로 한 지식 저장소입니다. LLM이 필요할 때마다 문서를 처음부터 검색해 답을 찾는 대신, 한 번 읽고 이해한 지식을 구조화된 형태로 저장해 지속적으로 축적하고 관리하는 방식입니다.

여기서 중요한 것은 각각의 지식이 어떤 관계를 가지고 있는지 정의하고 서로 연결해 하나의 Knowledge Graph로 만드는 것입니다.

https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing?hl=en

이러한 관계를 표현하는 구성 형식은 Google이 공개한 Open Knowledge Format(OKF)을 따릅니다. 각 회사나 Agent가 서로 다른 방식으로 Knowledge Base를 구축하면 구조가 달라지고 호환하기 어려워집니다. 이를 일정한 형식으로 표현하기 위한 것이 OKF이며, YAML Front Matter와 Markdown 본문으로 구성된 평문 파일을 디렉터리 구조로 관리합니다.

wiki/
├── index.md      전체 카탈로그
├── log.md        적재 이력 (append-only)
├── logs/         로그 시그니처별 발생 사례
├── postmortem/   원인 분석 결과
├── incident/     이슈 티켓
├── runbook/      대응 절차
└── glossary/     용어 정리

저희는 SRE와 Postmortem을 위한 지식 저장소가 목적이었기 때문에 위와 같은 구조로 구성했습니다. RCA 과정에서 확인된 로그와 원인, 대응 방법 등의 데이터를 각 디렉터리의 역할에 맞게 구조화해 저장하고, 각 문서의 Front Matter에는 다른 문서와의 관계를 정의해 서로 연결되도록 만들었습니다.

그 결과, 축적된 데이터를 Knowledge Graph로 시각화하면 위와 같이 서로 연결된 구조로 나타납니다.

이 구조의 핵심은 AI 에이전트가 SRE 업무의 한 구성원으로서 과거에 발생했던 장애와 분석 사례를 Postmortem을 통해 빠르게 학습하고, 이후 RCA에서 동일하거나 유사한 원인을 찾는 데 활용할 수 있도록 만드는 것입니다.

예를 들어 re-org와 관련된 문제가 새롭게 발생했다면, AI는 re-org와 연결된 Knowledge Graph를 따라가면서 과거의 로그 발생 사례와 Incident, 원인 분석 결과, 대응 방법 등을 빠르게 찾아 현재 RCA에 활용할 수 있습니다.

MTTI(Mean Time to Identify) 개선

MTTI(Mean Time to Identify)는 장애나 문제가 발생한 뒤, 문제의 원인을 식별하기까지 걸리는 평균 시간을 의미합니다. RCA 자동화를 적용하기 전에는 실제로 두 건의 이슈를 분석하는 데 각각 하루 이상이 소요되었습니다. 반면 SRE Orchestration을 구축한 이후에는 대부분 15~30분 이내에 원인 분석을 마칠 수 있었습니다.

특히 이러한 개선 효과는 경험과 인력이 충분하지 않은 신생 조직이나 소규모 조직에서 더욱 크게 체감했습니다. 사람이 하나씩 데이터를 확인하고 필요한 지식을 찾아가며 분석해야 했던 과정을 AI가 여러 도구를 활용해 대신 수행하면서, 문제의 원인에 도달하는 시간을 크게 줄일 수 있었습니다.

AI가 빠르게 수행하는 것은 원인을 분석하고 증거를 제시하는 과정까지이며, 실제로 어떤 해결 방안을 선택하고 적용할지는 여전히 사람의 판단이 필요한 영역입니다. 대신 원인 분석에 사용하던 시간을 줄인 만큼, 사람은 해당 문제를 학습하고 해결 방법을 검토하는 데 더 많은 시간을 사용할 수 있게 되었습니다.

Reference

• Google SRE Book
• The hard part of AI root cause analysis is no longer the model
• Google SRE Book: Effective Troubleshooting
• Optimisum(OP Stack) Github
• Google: Introducing the Open Knowledge Format
• karpathy llm wiki
• codegraph github