AI SRE: 자율 에이전트가 온콜(On-call) 업무를 수행하는 실제 모습

6개월 전, 우리는 DevHelm의 프로덕션 인프라를 위한 온콜(On-call)을 처리하는 AI 에이전트를 배포했습니다. 이 에이전트는 Grafana 알람을 분류(Triage)하고, Sentry 및 배포 파이프라인의 신호들을 상관 분석(Correlate)하며, 문맥(Context)을 포함한 Linear 티켓을 생성합니다. 그리고 P0 및 P1 인시던트(Incident)의 경우, Claude를 사용하여 근본 원인을 진단하는 다회차 조사 세션(Multi-turn investigation sessions)을 시작합니다.

이것은 개념적인 이야기가 아닙니다. 우리는 두 개의 데이터 센터에서 모니터링 플랫폼을 운영하는 소규모 팀입니다. 우리가 Nighthawk라고 부르는 이 에이전트는 우리 스택의 모든 신뢰성 신호(Reliability signal)를 처리합니다. 우리가 무엇을 구축했는지, 비용은 얼마나 드는지, 그리고 아직 무엇을 할 수 없는지에 대해 설명하겠습니다.

AI SRE의 세 가지 모드

AI 지원 운영(AI-assisted operations)은 스펙트럼 상에 존재합니다. 대부분의 팀은 왼쪽에서 시작하여 신뢰가 쌓임에 따라 오른쪽으로 이동합니다.

1. 자문 모드 (Advisory mode) — 분류 및 라우팅 ($0/인시던트)

에이전트는 신호(알람 발생, 에러 급증, 배포 실패)를 수신하고, 결정론적 규칙(Deterministic rules)을 사용하여 심각도와 카테고리에 따라 이를 분류합니다. 그 후 구조화된 문맥(영향을 받는 서비스, 예상 원인, 관련 대시보드)과 함께 프로젝트 트래커에 티켓을 생성하고, 온콜(On-call) 채널로 알림을 보냅니다.

LLM(대규모 언어 모델)은 관여하지 않습니다. 이벤트당 비용도 발생하지 않습니다. 이것은 구조화된 출력을 가진 규칙 엔진(Rules engine)입니다. 이는 SRE 팀들이 수년 동안 PagerDuty 웹훅(Webhook)과 커스텀 Slack 봇을 통해 구축해 온 자동화 방식과 유사합니다. 여기서의 가치는 AI가 아니라, 분류 규칙과 라우팅 로직이 15개의 웹훅 통합 기능에 흩어져 있는 대신 한 곳에 모여 있다는 점에 있습니다.

2. 조사 모드 (Investigation mode) — LLM 기반 진단 (~$6/세션)

P0 또는 P1 알람이 발생하면, 에이전트는 자문 모드에서 조사 모드로 격상됩니다. 에이전트는 전체 인시던트 문맥(알람 페이로드, 최근 배포 이력, 다른 소스로부터의 상관 신호, 진단 도구에 대한 접근 권한(로그 검색, 메트릭 쿼리, 트레이스 조회))을 가지고 LLM 대화(우리는 Claude를 사용합니다)를 시작합니다.

조사는 멀티턴 세션 (multi-turn session)으로 진행됩니다. 에이전트는 질문을 던지고, 진단 명령을 실행하며, 결과를 분석하고, 가설을 세웁니다. 각 턴의 배치가 끝날 때마다 에이전트는 잠시 멈추고 발견된 사항을 인간 온콜 (on-call) 담당자에게 보고합니다. 인간은 추가적인 컨텍스트(예: "20분 전에 데이터베이스 마이그레이션을 배포했습니다")를 주입하거나 조사 방향을 유도(예: "쿼리 지연 시간(query latency)이 아니라 커넥션 풀 메트릭(connection pool metrics)을 확인하세요")할 수 있습니다.

이 지점에서 진정한 가치가 나타납니다. 인간이 대시보드를 열고, 로그를 읽고, 배포 이력을 교차 참조하는 등 컨텍스트 스위칭 (context-switching)에 45분이 소요되는 P1 조사를 에이전트는 3~5분간의 자율적인 작업만으로 수행합니다. 발견된 결과에 대해 무엇을 할지는 여전히 인간이 결정하지만, 진단을 위한 기초 작업은 자동화됩니다.

3. 자율적 복구 (Autonomous remediation) — 아직은 미개척 분야

논리적인 다음 단계는 에이전트가 문제를 진단할 뿐만 아니라 수정 사항을 직접 실행하는 것입니다. 충돌이 발생한 포드 (pod)를 재시작하거나, 잘못된 배포를 롤백 (roll back)하거나, 데이터베이스 커넥션 풀을 확장하는 작업 등이 이에 해당합니다. 기술은 이미 준비되어 있습니다. 현대적인 LLM의 도구 사용 (tool use) 능력은 제한된 범위의 작업(scoped operations)을 수행하기에 충분히 신뢰할 만합니다. 문제는 신뢰와 폭발 반경 (blast radius)입니다. 포드를 재시작할 수 있는 에이전트는 잘못된 포드를 재시작할 수도 있습니다. 배포를 롤백할 수 있는 에이전트는 잘못된 배포를 롤백할 수도 있습니다.

우리는 아직 자율적 복구를 활성화하지 않았습니다. 현재 우리는 조사 결과가 인간의 승인으로 넘어가는 단계에 있으며, 대부분의 팀이 이 지점부터 시작해야 한다고 생각합니다.

우리 에이전트가 실제로 하는 일

Nighthawk는 우리 쿠버네티스 (Kubernetes) 클러스터 내의 배포 형태로 실행됩니다. 모든 신뢰성 신호 (reliability signals)는 에이전트의 웹훅 (webhook) 엔드포인트를 통해 흐릅니다.

신호 소스	포함 내용
Grafana (38개 이상의 경고 규칙)	메트릭 임계값 위반: 높은 에러율, 지연 시간 급증, 디스크/메모리 압박, 복제 지연 (replication lag)
...

모든 신호는 동일한 파이프라인 (pipeline)을 거칩니다:

중복 제거 (Deduplication). 동일한 알람이 2분 내에 5번 발생하면, 에이전트는 5개의 티켓을 생성하는 대신 이를 하나의 인시던트 (incident)로 상관 관계를 분석하여 통합합니다.
심각도 분류 (Severity classification). 신호 메타데이터를 인시던트 심각도 레벨 (incident severity levels) (P0–P3)로 매핑하는 규칙 기반 (rules-based) 매핑을 수행합니다. Grafana의 크리티컬 (critical) 알람은 P0로 매핑됩니다. 분당 100개 이상의 이벤트가 발생하는 Sentry 에러 급증은 P1으로 매핑됩니다. 빌드 실패는 P2로 매핑됩니다.
컨텍스트 보강 (Context enrichment). 에이전트는 최근 배포 이력, 지난 30분 동안의 관련 신호, 그리고 관련 대시보드 및 런북 (runbooks) 링크를 첨부합니다.
라우팅 (Routing). Linear 티켓을 생성합니다. 한 단락의 요약이 포함된 Telegram 알림을 보냅니다. P0/P1의 경우: 조사 세션 (investigation session)을 자동으로 시작합니다.

어드바이저리 파이프라인 (advisory pipeline)은 2초 이내에 신호를 처리합니다. 조사 세션은 일반적으로 3~~8분에 걸쳐 5~~15회의 턴 (turn) 동안 실행됩니다.

경제성 (The economics)

비용 모델은 누구나 가장 먼저 묻는 질문이므로, 실제 수치를 공개합니다:

어드바이저리 모드 (Advisory mode): 인시던트당 $0. LLM 호출이 없습니다. 분류 및 라우팅 로직은 결정론적인 (deterministic) Python으로 작동합니다. 우리는 한계 비용(marginal cost) 없이 하루에 50~200개의 신호를 처리합니다.

조사 세션 (Investigation sessions): Claude Opus 사용 시 세션당 약 $6. 한 세션은 최대 25회의 턴(하드 예산)으로 실행되며, 호출 사이클당 5회의 턴이 진행됩니다. 대부분의 조사는 10~15회의 턴 내에 해결됩니다. 토큰 사용량은 턴당 평균 입력 토큰 15,000개 및 출력 토큰 3,000개입니다.

일일 비용 제어 (Daily cost controls):

일일 $10에서 서킷 브레이커 (Circuit breaker) 작동 — 총 조사 비용이 이 금액을 초과하면, 새로운 조사는 자동 시작되는 대신 사람의 승인을 위해 대기열에 추가됩니다.
최대 2개의 동시 조사 실행 — 상관 관계가 있는 알람들이 연쇄적으로 발생하여 예산을 소진하는 것을 방지합니다.
P0 및 P1 인시던트만 자동 조사 수행 — P2 및 P3는 어드바이저리(advisory) 전용 처리를 받습니다.

실제로 우리는 조사(investigation)에 월 30~60달러를 지출합니다. 이는 보수적인 추정치로도 한 달에 인간의 온콜(on-call) 업무 시간을 반나절도 절약하지 못한 수준입니다. 가치는 단순히 시간 절약에만 있는 것이 아닙니다. 인간이 깨어나서 상황을 파악할 때까지 기다리는 대신, 새벽 3시에도 즉시 조사가 시작된다는 점에 있습니다.

AI SRE가 아직 할 수 없는 것들

한계에 대해 지적으로 정직하게 대하는 것이 중요합니다. 우리가 배운 점은 다음과 같습니다:

상충하는 인시던트(incident) 사이의 우선순위를 정할 수 없습니다. 서로 다른 서비스에서 세 개의 알람이 동시에 발생하면, 에이전트는 이를 독립적으로 조사합니다. 인간 엔지니어라면 세 가지 모두가 단일 근본 원인(데이터베이스 속도 저하)의 하류 효과(downstream effects)임을 인지하고 그에 따라 트리아지(triage, 우선순위 분류)를 수행할 것입니다. 우리는 상관관계 휴리스틱(correlation heuristics)을 구축하고 있지만, "이것이 근본 원인인가 아니면 증상인가?"라는 판단에는 여전히 인간의 패턴 인식(pattern recognition)이 필요합니다.

비즈니스 영향(business impact)을 평가할 수 없습니다. 에이전트는 결제 오류율이 급증했다는 사실은 압니다. 하지만 오늘이 제품 출시 캠페인의 마지막 날이며, 결제 실패 하나당 발생하는 손실이 평소 매출의 10배라는 사실은 알지 못합니다. 심각도 분류(severity classification)는 비즈니스 컨텍스트(context)가 아닌 기술적 신호(technical signals)를 기반으로 이루어집니다.

진단 결과에 대해 환각(hallucination)을 일으킵니다. 조사 세션의 약 5%에서, 실제 지표는 사용률 30%를 나타내고 있음에도 에이전트가 "커넥션 풀(connection pool)이 고갈되었습니다"라고 자신 있게 주장합니다. 우리는 에이전트가 모든 주장마다 구체적인 지표 값이나 로그 라인을 인용하도록 요구함으로써 이를 완화하고 있습니다. 만약 증거를 제시하지 못하면 해당 결과는 미검증(unverified)으로 플래그(flag) 처리됩니다.

인시던트 간의 학습이 이루어지지 않습니다. 각 조사 세션은 처음부터 다시 시작됩니다. 에이전트는 지난주의 P1 인시던트가 동일한 데이터베이스 마이그레이션 패턴으로 인해 발생했다는 사실을 기억하지 못합니다. 우리는 관련 있는 과거 조사 내용을 노출해 주는 "학습(learnings)" 저장소를 구축하고 있지만, 아직 프로덕션(production) 단계에 적합한 수준은 아닙니다.

자신만의 어드바이저리(advisory) 에이전트를 구축하는 방법

조사(investigation) 세션부터 시작할 필요는 없습니다. 신호 라우팅(signal routing), 분류(classification), 티켓 생성(ticket creation), 알림(notification)과 같은 어드바이저리(advisory) 계층만으로도 업무 노가다(toil)의 80%를 처리할 수 있으며, 실행 비용도 들지 않습니다. 시작하는 방법은 다음과 같습니다:

1단계: 신호 라우팅 통합

모든 신뢰성 신호(reliability signals)를 수신하는 단일 웹훅(webhook) 엔드포인트를 선택하세요. Grafana 알림, Sentry 웹훅, CI/CD 알림, 그리고 커스텀 상태 확인(health checks)이 모두 하나의 라우터를 통해 흐르도록 해야 합니다. 이렇게 하면 분류 로직을 추가할 수 있는 단일 지점이 생기며, "Slack 채널이 12개나 되는데 어느 것이 중요한지 아무도 모른다"는 문제를 방지할 수 있습니다.

2단계: 심각도 분류 규칙 정의

신호 메타데이터(metadata)를 심각도 수준(severity levels)에 매핑하세요. 간단하게 시작하십시오:

severity=critical인 Grafana 알림 → P0
에러 발생 횟수가 분당 100회 초과인 Sentry 신규 이슈 → P1
배포 상태 확인(deploy health check) 실패 → P2
그 외 모든 것 → P3

실제로 사용자에게 미치는 영향과 상관관계가 있는 것이 무엇인지 파악함에 따라 규칙을 정교화하세요. 처음에는 규칙이 틀릴 수도 있지만, 괜찮습니다. 2주 동안 사람이 분류 내용을 검토하는 것만으로도 교정(calibrate)에 필요한 충분한 수정 사항을 생성할 수 있습니다.

3단계: 티켓 생성 자동화

분류된 모든 신호에 대해 프로젝트 트래커(project tracker)에 구조화된 필드(심각도, 영향을 받은 서비스, 타임스탬프, 요약, 관련 대시보드 링크)를 포함한 티켓을 생성하세요. 이것이 바로 MTTR을 줄이는 지렛대입니다. 사람이 조사를 시작하기 전에 이미 컨텍스트(context)가 첨부된 티켓이 존재하게 됩니다.

4단계: 준비가 되면 조사 기능 추가

분류와 라우팅을 신뢰할 수 있게 되면(어드바이저리 전용 운영 약 30일 후), P0/P1 인시던트(incident)에 대해 LLM 기반의 조사 기능을 추가하세요. 에이전트에게 로그(logs), 메트릭(metrics), 배포 이력(deploy history)에 대한 읽기 권한을 부여하십시오. 처음에는 보수적인 턴 예산(turn budget, 최대 10턴)으로 시작하고, 첫 한 달 동안은 모든 조사 결과물을 검토하십시오.

외부 모니터링의 역할

내부 신호(internal signals)를 처리하는 AI SRE 에이전트에게는 사각지대가 있습니다. 바로 인프라 외부에서 발생하는 문제를 감지할 수 없다는 점입니다. 클라우드 제공업체의 API 성능이 저하되거나, 데이터베이스 호스트에 네트워크 파티션(network partition)이 발생하거나, 파이프라인이 의존하는 제3자 서비스(third-party service)가 다운되는 경우 — 이러한 문제들은 하류 효과(downstream effects)가 지표(metrics)로 전이되어 연쇄적으로 나타나기 전까지는 내부 알림(internal alerting) 시스템에서 보이지 않습니다.

외부 업타임 모니터링(External uptime monitoring) — 인프라 외부에서 실행되며 30초마다 엔드포인트 가용성(endpoint availability)을 확인하는 체크 — 이 격차를 메워줍니다. 이는 내부 모니터링이 놓치는 부분을 포착하는 신호원(signal source) 역할을 합니다. app.devhelm.io에서 가장 중요한 외부 의존성(external dependencies)에 대한 체크부터 시작한 다음, 그 결과를 Grafana 및 Sentry와 함께 에이전트의 신호 라우터(signal router)에 입력하십시오.

원문은 DevHelm에 게시되었습니다.