자율형 SRE 에이전트 구축: 로우 텔레메트리(Raw Telemetry)에서 안전한 AI 기반 복구까지

현대의 사이트 신뢰성 공학 (Site Reliability Engineering, SRE) 팀은 복잡한 상호 의존성을 가진 수백 개의 마이크로서비스 (microservices)를 관리합니다. 장애가 발생하면 엔지니어는 여러 관측성 (observability) 백엔드를 수동으로 쿼리하고, 계층 전반에 걸쳐 시그널을 상관 분석하며, 과거의 사후 분석 (post-mortems) 보고서를 참조하고, 런북 (runbooks)을 실행해야 합니다. 이러한 수동 프로세스는 높은 평균 복구 시간 (Mean Time to Recovery, MTTR), 알람 피로 (alert fatigue), 그리고 운영상의 고된 작업 (operational toil)을 초래합니다.

이를 해결하기 위해, 저는 전체 장애 루프(탐지 → 조사 → 진단 → 복구 → 학습)를 실행하는 AI 기반 신뢰성 시스템인 **자율형 SRE 에이전트 (Autonomous SRE Agent)**를 구축했습니다.

LLM 출력을 맹목적으로 실행하는 단순한 AI 래퍼 (wrappers)와 달리, 이 에이전트는 **하드코딩된 안전 가드레일 (hard-coded safety guardrails)**을 갖춘 엄격한 **육각형 아키텍처 (Hexagonal Architecture)**를 기반으로 구축되었습니다. 이를 통해 자율성은 기본적으로 부여되는 것이 아니라, 엄격한 단계적 배포를 통해 '획득'되도록 보장합니다.

다음은 자율형 SRE 에이전트의 목적, 아키텍처 및 구현에 대한 심층 분석입니다.

🎯 목적 및 핵심 역량

자율형 SRE 에이전트는 잘 알려진 인프라 장애의 분류(triage) 및 복구를 완전히 자동화하여, MTTR을 30초 미만의 진단 지연 시간으로 줄이도록 설계되었습니다.

현재 이 에이전트는 다섯 가지 핵심 장애 유형에 대해 엔드 투 엔드(end-to-end) 자율 해결을 지원합니다:

OOM Kills (Out of Memory Kills): 5분 이상 메모리 압박이 85%를 초과할 때 트리거됩니다. Pod 재시작을 통해 복구됩니다.
높은 지연 시간 (High Latency): p99 지연 시간이 2분 이상 3σ(표준편차의 3배)를 초과할 때 트리거됩니다. HPA 스케일 업 (scale-up)을 통해 복구됩니다.
에러율 급증 (Error Rate Spikes): 에러가 200% 이상 급증할 때 트리거됩니다. GitOps 배포 롤백 (rollbacks)을 통해 복구됩니다.
디스크 고갈 (Disk Exhaustion): 24시간 예측 시 사용량이 80%를 초과할 때 트리거됩니다. 로그 절단 (log truncation)을 통해 복구됩니다.
인증서 만료 (Certificate Expiry): 인증서가 14일 이내에 만료될 때 트리거됩니다. 인증서 갱신 트리거를 통해 복구됩니다.

🏗️ 시스템 아키텍처: 5개 계층

이 시스템은 로우 인프라 텔레메트리 (raw infrastructure telemetry)를 실행 가능한 장애 상황과 안전한 복구 조치로 변환하는 정교한 계층형 처리 파이프라인으로 설계되었습니다.

1. Observability Layer (Ingestion) (관측 가능성 계층 (수집))

이 계층은 고충실도(high-fidelity) 텔레메트리를 수집합니다. 애플리케이션 수준의 메트릭(metrics), 분산 트레이스(distributed traces), 구조화된 로그(structured logs)를 위해 **OpenTelemetry (OTel)**에 연결하며, 최소한의 오버헤드로 심층적인 커널 수준 가시성(네트워크 흐름, 시스템 호출(syscalls))을 확보하기 위해 eBPF를 활용합니다. 또한 트레이스 스팬(trace spans)을 지속적으로 분석하여 실시간 **서비스 의존성 그래프 (Service Dependency Graph)**를 구축하며, 이는 향후 모든 복구 조치의 영향 범위(blast radius)를 계산하는 데 필수적입니다.

2. Detection Layer (탐지 계층)

정적 임계값(static thresholds) 방식에서 벗어나, 이 계층은 이동 통계적 베이스라인(rolling statistical baselines)을 계산합니다. 머신러닝 휴리스틱(예: Isolation Forests)을 사용하여 다차원적 이상 징후(예: 에러 급증과 상관관계가 있는 지연 시간 스파이크)를 탐지합니다. 알람 상관관계 엔진(Alert Correlation Engine)은 의존성 그래프를 사용하여 관련된 이상 징후들을 하나의 중복 제거된 Incident (장애)로 그룹화합니다.

3. Intelligence Layer (The Cognitive Brain) (지능 계층 (인지적 브레인))

이 계층은 진단 엔진 역할을 수행하며, 다단계 검색 증강 생성 (RAG, Retrieval-Augmented Generation) 파이프라인을 활용합니다.

유입되는 이상 징후 알람을 임베딩(embedding)하고, 과거의 사후 분석 보고서(post-mortems) 및 런북(runbooks)이 포함된 벡터 데이터베이스(Vector Database)를 대상으로 의미론적 유사도 검색(semantic similarity searches)을 수행합니다.
이렇게 확보된 근거 기반의 컨텍스트(grounded context)를 LLM (Anthropic Claude 또는 OpenAI GPT-4o)에 전달하여 근본 원인 가설(root-cause hypothesis)을 생성합니다.
**제2의 의견 검증기 (Second-Opinion Validator)**가 환각(hallucinations)을 방지하기 위해 LLM의 논리를 교차 검증하며, **신뢰도 점수 산출기 (Confidence Scorer)**가 구조적 증거를 평가합니다.
Cross-encoder 재순위화(reranking), 의미론적 진단 캐싱(semantic diagnostic caching), LLMLingua 증거 압축(evidence compression)과 같은 고급 토큰 최적화 (Token Optimization) 기술을 통해 컨텍스트 창(context window)의 팽창을 줄이고 API 비용을 낮춥니다.

4. Action & Guardrails Layer (조치 및 가드레일 계층)

이곳은 AI가 현실과 상호작용하는 "최종 단계 (final mile)"입니다. 재앙적인 조치를 방지하기 위해, 시스템은 **안전 가드레일 엔진 (Safety Guardrails Engine)**에 의존합니다.
복구 조치(Remediations)는 엄격한 정책(예: "전 세계 플릿(fleet)의 10% 이상을 동시에 재시작하지 말 것")을 통해 라우팅됩니다. 조치는 멱등성(idempotent)을 보장하는 클라우드 API를 통해 실행되거나, 배포 롤백을 위해 GitOps 풀 리퀘스트 (GitOps Pull Requests) (ArgoCD/Flux 사용)를 통해 실행됩니다. 복구 후 모니터(Post-Remediation Monitor)는 메트릭을 추적하며, 시스템 상태가 더욱 악화될 경우 자동 롤백(auto-rollbacks)을 트리거합니다.

5. Orchestration & Operator Layer (오케스트레이션 및 운영자 계층)

AI가 결코 "블랙박스 (black box)"가 되지 않도록, 운영자 계층(Operator Layer)은 React/Next.js 대시보드를 제공합니다. 이 대시보드는 실시간 장애 타임라인, 신뢰도 점수(confidence score) 상세 분석, 그리고 Severity 1 및 2 장애에 대한 "인간 참여형 (Human-in-the-Loop)" 승인을 위한 ChatOps 통합(Slack/MS Teams) 기능을 갖추고 있습니다. 또한 오케스트레이션 계층은 분산 락(distributed locks) (Redis/etcd)을 사용하여 **멀티 에이전트 조정 (Multi-Agent Coordination)**을 관리함으로써, SRE 에이전트와 다른 자율 엔티티(예: FinOps 또는 SecOps 에이전트) 간의 충돌을 방지합니다.

🧱 설계 철학: 육각형 및 안전 우선 (Hexagonal & Safety-First)

엄격한 육각형 아키텍처 (Ports & Adapters)

가장 중요한 아키텍처 결정(ADR-001)은 육각형 아키텍처(Hexagonal Architecture)를 채택한 것이었습니다. 핵심 도메인 로직(domain/)은 kubernetes, boto3, 또는 openai와 같은 외부 SDK를 직접 절대로 임포트하지 않습니다.
대신, 교체 가능한 adapters/ (예: OtelProvider, CloudWatchLogsAdapter, PostgresIncidentStore)에 의해 구현되는 추상 인터페이스(ports/)에 의존합니다. 이는 핵심 추론 엔진이 AWS, Azure, Kubernetes 전반에 걸쳐 높은 이식성(portability)을 유지하도록 보장합니다.

부여되는 것이 아닌, 획득하는 자율성

에이전트는 운영자의 신뢰를 구축하기 위해 엄격한 단계별 출시 상태 머신(Phased Rollout State Machine)을 활용합니다.

Phase 1 (Observe, 관찰): 에이전트가 섀도우 모드(Shadow Mode)로 실행되며, 텔레메트리(Telemetry)를 분석하고 실제 실행은 하지 않은 채 의도된 작업 내용을 감사 로그(Audit Log)에 기록합니다.
Phase 2 (Assist, 보조): 에이전트가 장애를 진단하고 Slack/PagerDuty를 통해 복구 계획을 제안하며, 진행을 위해서는 인간의 승인(Human-in-the-Loop)이 필요합니다.
Phase 3 (Autonomous, 자율): 높은 진단 정확도를 수학적으로 증명한 후, 에이전트는 영향 범위(Blast-radius) 제한을 엄격히 준수하는 조건 하에 낮은 심각도(Sev 3-4) 장애에 대해 자율적으로 작업을 실행할 수 있는 권한을 부여받습니다.

🛠️ 구현 및 기술 스택 (Implementation & Technology Stack)

구현 방식은 견고하며 확장성을 고려하여 설계되었습니다:

언어 및 핵심 (Language & Core): 비동기 우선(Async-first) API 인터페이스를 위한 FastAPI와 정형 데이터 모델(Canonical Data Models)의 엄격한 런타임 검증을 위한 Pydantic v2를 사용하는 Python 3.11+ 기반입니다.
지속성 (Persistence, ADR-006): 데이터 전략을 PostgreSQL 중심으로 통합했습니다. 이는 기본 운영 저장소 역할을 수행하며, 대용량 텔레메트리 메트릭을 위해 TimescaleDB 확장을, 프로덕션 환경의 HNSW 벡터 임베딩(Vector Embeddings)을 위해 pgvector 확장을 활용합니다.
이벤트 및 조정 (Eventing & Coordination): Redis Streams가 내부 이벤트 버스(Event Bus) 역할을 수행하며, 감사 추적(Audit Trails)이 완벽하게 보존되도록 최소 한 번(At-least-once) 전달 트랜잭션 아웃박스 패턴(Transactional Outbox Pattern)을 사용합니다. Redis와 etcd는 멀티 에이전트 펜싱(Multi-agent Fencing)을 위한 분산 잠금(Distributed Locking)을 관리합니다.
테스트 엄격성 (Testing Rigor): 이 에이전트는 인프라를 변경하므로 엄격한 60/30/10 테스트 피라미드가 필요합니다. 도메인 로직에 대해 100% 코드 커버리지를 유지하며, 통합 테스트 중에 AWS 인프라를 동적으로 에뮬레이션하기 위해 Testcontainers와 LocalStack Pro에 크게 의존합니다.

🚀 향후 과제 (The Path Forward)

자율형 SRE 에이전트는 **Phase 4: 예측 기능(Predictive Capabilities)**을 향해 빠르게 나아가고 있습니다. 이 미래 단계에서 에이전트는 장기적인 성능 저하 추세를 모니터링하고, 이상 징후 임계값(Anomaly Threshold)이 돌파되기 전에 시스템을 자동으로 확장하거나 아키텍처 전환을 권장하게 될 것입니다.

인지적 추론 엔진(Cognitive Reasoning Engine)을 인프라 어댑터(Infrastructure Adapters)로부터 분리하고, 안전(Safety)을 타협 불가능한 궁극적인 제약 조건으로 설정함으로써, 저는 "인상적인 AI 데모"와 진정한 기업용 Tier-0 인프라 자동화 사이의 간극을 메우고 있습니다.

만약 여러분이 플랫폼 엔지니어링(Platform Engineering), AI 인프라, 또는 SRE 분야에서 일하고 계신다면, 이 아키텍처와 안전 패턴(Safety Patterns)에 대한 여러분의 피드백을 댓글로 듣고 싶습니다!