1. 새벽 3시의 전화 — 왜 자율 SRE인가

새벽 3시에 전화가 울렸다.

"서버 응답이 안 됩니다." 잠을 깨고 노트북을 열었다. VPN 붙이고, Grafana 띄우고, 어떤 서버인지 확인했다. SSH 접속. top, df -h, journalctl. 디스크가 가득 찼다. 로그 파일이 폭주한 거다. find로 오래된 로그를 찾아 지우고, systemctl restart로 서비스를 재시작했다. 정상 복구 확인. 시계를 보니 새벽 4시 반이었다.

다음 날 포스트모템을 썼다. 원인: 로그 로테이션 미설정. 재발 방지: logrotate 설정 추가.

한 달 뒤, 비슷한 장애가 또 터졌다. 이번엔 다른 파티션이었다. 또 새벽이었다.

서버 운영을 10년 넘게 하면서 이 패턴이 바뀐 적이 없다. 서버가 천 대, 만 대가 되면 반복의 빈도만 비례해서 늘어난다. 사람이 직접 판단하고 직접 실행하는 구조는, 규모가 커질수록 한계에 부딪힌다.

그래서 LLM을 들여다보기 시작했다.

반복의 늪, 토일

Google SRE 책에 나오는 토일(Toil)이라는 개념이 있다. 수동적이고, 반복적이며, 자동화 가능한데 아직 안 된 작업. 시스템 엔지니어의 일상에서 이게 차지하는 비중이 생각보다 크다.

디스크 80% 알림이 오면 SSH 접속해서 로그를 정리한다. 서비스 응답이 느리면 프로세스를 확인하고 재시작한다. SSL 인증서가 만료되면 갱신한다. 배포 후 헬스체크가 실패하면 롤백한다.

전부 "알림 → 접속 → 확인 → 조치 → 확인"의 반복이다. 각 단계에서 판단이 필요하긴 한데, 그 판단도 대부분 패턴화되어 있다. "디스크 85%면 /var/log에서 30일 넘은 gz 파일을 지운다." 이미 머릿속에 매뉴얼이 있는 거다.

문제는 이 매뉴얼이 사람 머릿속에만 있다는 것이다. Confluence에 Runbook을 써놓아도, 새벽 3시에 잠결에 그걸 찾아 읽을 여유가 없다. 결국 경험 많은 엔지니어의 직감에 의존하게 되고, 그 사람이 퇴사하면 지식도 같이 사라진다.

알림 200건, 진짜 장애 5건

서버가 수천 대면 알림도 하루에 수백 건씩 쏟아진다. 대부분은 일시적 스파이크거나, 이미 아는 이슈거나, 다른 알림과 중복이다. 하지만 그 속에 진짜 장애 신호가 섞여 있다.

서버를 운영해본 사람은 알 거다. 하루 200건의 알림 중 실제 조치가 필요한 건 5건이 안 된다. "또 이 알림이야" 하면서 무시하다가 진짜 장애를 놓치는 일이 생긴다. 연관된 알림 5개가 동시에 오는데, 이게 하나의 장애인지 별개인지 판단이 안 되는 경우도 많다.

알림 시스템은 "뭔가 수치가 이상하다"는 건 알려주는데, "왜 이상한지", "어떤 알림끼리 연관되어 있는지", "지금 당장 뭘 해야 하는지"는 안 알려준다. 그 해석은 전적으로 사람 몫이다.

야간 온콜의 진짜 비용

온콜 수당이 비용의 전부가 아니다.

수면 중단으로 인한 다음 날 생산성 저하. 장기적 번아웃과 이직. 경험 많은 시니어에게 편중되는 온콜 로테이션. 주니어는 온콜을 두려워하고, 시니어는 온콜에 지친다.

서버 1,000대를 10명이 운영하면, 1~2주에 한 번은 야간 당직을 서야 한다. 그런데 실제로 야간에 호출되면, 대부분은 위에서 말한 반복적인 토일이다. 진짜 복잡한 장애는 드물다.

반복적인 야간 호출의 80%를 자동화할 수 있다면? 온콜의 부담은 극적으로 줄어든다. 이게 자율 SRE라는 개념을 파고들기 시작한 계기다.

AIOps랑 뭐가 다른가

"AI로 운영을 자동화한다"는 이야기는 AIOps라는 이름으로 몇 년 전부터 있었다. 관련 솔루션들을 찾아보면 대부분 비슷한 접근을 한다.

AIOps는 주로 통계/머신러닝 기반이다. 시계열 데이터에서 이상치를 탐지하고, 알림을 클러스터링한다. "CPU 사용률이 평소 패턴에서 2σ 벗어났다"는 건 잘 잡는다.

근데 이걸 못 한다.

"이 에러 로그가 무슨 뜻인지 해석해줘." "이 상황에서 Runbook 3번을 실행해야 하는 이유를 설명해줘." "이 장애의 근본 원인을 추론하고, 조치 계획을 세워줘."

AIOps는 숫자를 분석한다. 하지만 운영의 많은 부분은 숫자가 아니라 텍스트다. 로그 메시지, 에러 메시지, 설정 파일, 매뉴얼. 그리고 최종 판단은 "이 상황에서 뭘 해야 하는가"라는 추론이 필요하다. AIOps에는 이 능력이 없다.

LLM이 가져온 변화가 바로 이 지점이다.

기존 AIOps:
  알림 수치 → 통계 모델 → "이상입니다" → 사람이 해석하고 조치
 
자율 SRE:
  로그 + 알림 + 설정 파일 → LLM →
  "OOM이 발생했고, 원인은 배치 작업의 메모리 제한 미설정으로
   추정됩니다. MemoryLimit=4G 추가를 권장합니다."
  → 사람이 승인(또는 자동 실행)

LLM은 로그를 읽고, 맥락을 이해하고, 원인을 추론하고, 조치를 제안할 수 있다. 더 중요한 건, 한국어 Runbook을 읽고 실행 단계를 추출할 수 있다는 점이다. Confluence에 한국어로 써놓은 장애 대응 절차를 LLM이 이해하고, 해당 상황에 맞는 절차를 자동으로 선택해서 제안할 수 있다. 기존 자동화 스크립트로는 불가능했던 유연성이다.

자율 SRE는 AIOps를 대체하는 게 아니라 보완하는 거다.

┌──────────────────────────────────────────────┐
│              자율 SRE 아키텍처                │
├──────────────────────────────────────────────┤
│                                              │
│  [메트릭/알림] ─→ AIOps (Prometheus, ML)     │
│       │              │                       │
│       │         숫자 기반 이상 탐지            │
│       │              │                       │
│  [로그/설정]  ─→   LLM                       │
│       │              │                       │
│       │         텍스트 이해 + 추론             │
│       │              │                       │
│       └──────────→ 통합 판단                  │
│                      │                       │
│                 조치 제안 / 자동 실행           │
│                      │                       │
│                 포스트모템 / 지식 축적          │
└──────────────────────────────────────────────┘

Prometheus가 "CPU 90%"를 감지하면, LLM이 해당 시점의 로그를 읽어서 "배포 직후 발생한 일시적 스파이크인지, 진짜 장애인지"를 판단한다. 이 조합이 핵심이다.

Google은 이미 하고 있다

Google Cloud SRE팀이 2026년 1월에 공개한 사례가 있다. Gemini CLI(Gemini 3 기반)를 실제 장애 대응에 투입한 거다.

이들이 집착하는 지표는 MTTM(Mean Time to Mitigation)이다. "복구까지의 시간"이 아니라 "고통을 멈추기까지의 시간." SRE에게는 5분 안에 알림을 확인해야 하는 SLO가 있고, 그 직후 완화를 시작해야 한다는 극심한 압박이 있다.

Gemini CLI는 이 과정 전체를 보조한다.

장애가 발생하면, Gemini CLI가 알림 데이터를 수집하고 시계열 상관관계를 분석해서 증상을 분류한다. 그리고 적절한 완화 플레이북을 선택한다. Google SRE의 표현을 빌리면, "증상을 분류하고 완화 플레이북을 선택하는 것은 LLM에게 완벽한 작업"이라고 한다.

플레이북에는 실행할 명령, 변경이 문제를 해결하고 있는지 검증하는 방법, 롤백 지침이 포함된다. 완화 후에는 근본 원인을 분석하고, 마지막으로 포스트모템을 자동 생성한다. 대화 이력, 메트릭, 로그를 스크랩해서 타임라인을 만들고, 마크다운 문서를 생성하고, 액션 아이템을 제안하고, 이슈 트래커에 버그까지 등록한다.

가장 흥미로운 부분은 이거다. 생성된 포스트모템이 다시 Gemini의 학습 데이터가 된다. 오늘의 장애 조사 결과가 내일의 해결책을 위한 입력이 되는 선순환 구조다.

Google이 쓰는 내부 도구를 우리가 그대로 쓸 수는 없다. 하지만 패턴은 똑같다. Gemini CLI 대신 Claude API나 로컬 LLM을 쓰고, 내부 도구 대신 Grafana, Prometheus, PagerDuty를 MCP로 연결하면 같은 구조를 만들 수 있다. 이 시리즈가 그 방법을 다룬다.

성숙도 모델 — 지금 우리 팀은 어디에 있나

자율 SRE는 하루 아침에 되는 게 아니다. 단계가 있다.

Level 0        Level 1        Level 2         Level 3         Level 4
수동           보조           반자율          자율            자가치유
─────────────────────────────────────────────────────────────────────
사람이         LLM이          LLM이 분석 +    LLM이 판단 +    장애 발생
모든 것을      정보를         조치 제안       실행, 사람은     전에 예방
판단하고       정리해줌       사람이 승인     감독
실행                         → 자동 실행
─────────────────────────────────────────────────────────────────────
         ▲                          ▲                    ▲
      대부분의 팀              이 시리즈의 목표          미래 비전

• Level 0이 대부분의 팀이다. 모니터링 도구는 갖춰져 있는데, 알림 이후 모든 과정이 수동이다. 솔직히 대부분의 운영팀이 여기서 크게 벗어나지 못하고 있다.
• Level 1은 LLM이 정보를 정리해주는 수준이다. 알림이 오면 LLM이 관련 로그를 요약해서 보여준다. 판단과 실행은 사람이 한다. "똑똑한 어시스턴트" 역할이다.
• Level 2가 되면 LLM이 원인 분석을 하고 "이렇게 조치하겠습니다. 승인하시겠습니까?"라고 제안한다. 사람이 승인 버튼만 누르면 실행된다.
• Level 3에서는 반복적이고 위험도가 낮은 장애를 LLM이 자동으로 해결한다. 사람은 사후에 리뷰한다. 복잡한 장애만 사람에게 에스컬레이션한다.
• Level 4는 장애가 발생하기 전에 예방하는 단계다. 지금 기술로는 완전한 구현이 어렵지만, 방향은 보인다.

이 시리즈의 목표는 Level 2~3이다. 모든 장애를 자동화하겠다는 게 아니다. 반복적인 토일의 80%를 자동화하고, 복잡한 장애는 사람의 판단을 돕는 수준. 그것만으로도 새벽 3시 전화의 빈도는 상당히 줄어든다.

자주 나오는 우려들

"LLM이 환각을 일으키면 장애를 더 키우는 거 아니야?"

맞는 우려다. 그래서 이 시리즈에서 안전장치를 핵심으로 다룬다. Read-Only부터 시작한다. LLM이 제안만 하고 실행은 사람이 한다. 위험도별로 권한을 분리하고, 환각 탐지 장치를 넣고, Dry-run 모드를 구현한다. 5편과 6편에서 집중적으로 다룬다.

"우리 팀은 모니터링도 제대로 안 되어 있는데?"

Level 0에서 바로 Level 3으로 갈 수는 없다. 하지만 Level 0에서 Level 1로 가는 건 지금 당장 할 수 있다. LLM에게 로그를 넣어서 분석시키는 것, 그것만으로도 Level 1이다. 8편에서 점진적 도입 전략을 다룬다.

"비용이 너무 많이 들지 않나?"

시니어 엔지니어의 야간 온콜 수당과 비교해보면 된다. 한 번 야간 호출에 드는 실질 비용(수당 + 다음 날 생산성 저하)은 상당하다. LLM이 월 1~2건의 야간 호출만 줄여줘도 ROI가 나온다. 8편에서 경로별 비용 비교와 ROI 계산법을 다룬다.

이 시리즈에서 다루는 것

총 8편이다. 자율 SRE를 처음부터 끝까지 설계한다.

두 가지 경로를 병행한다. 보안 요구에 따라 선택하면 된다.

• 경로 A는 Claude API 단독이다. 데이터를 외부에 보낼 수 있는 환경이면 이쪽이 빠르고 간단하다.
• 경로 B는 로컬 빅모델(Llama, Qwen 등)을 사내 GPU에 올리는 방식이다. 데이터가 밖으로 나가면 안 되는 환경이면 이쪽을 선택한다.

아키텍처와 프롬프트 설계는 동일하다. 달라지는 건 "누가 추론하는가"뿐이다.

다음 편에서는 Claude와 로컬 빅모델을 SRE 업무 관점에서 비교한다. "내 로그가 몇 토큰인가", "70B 모델이 실제로 장애를 분석할 수 있는가", "GPU별로 어떤 모델까지 올릴 수 있는가" 같은 질문에 답한다.