새벽 3시 11분에 페이저(Pager)가 울립니다. 오늘 밤 벌써 다섯 번째이며, 내용은 동일합니다: 설계된 대로 메모리 매핑 캐시(memory-mapped cache)를 실행 중인 노드에서 발생한 HighMemoryUsage 알람입니다. 당신은 12분 후에 다시 울릴 것을 알면서도 반쯤 잠든 상태로 이를 확인(ack)합니다. 에러 예산(error budget)을 조용히 갉아먹고 있는 느린 API 성능 저하라는 진짜 장애가 4시 40분에 나타날 때쯤, 당신은 너무 지쳐서 상황을 명확히 파악할 수 없습니다. 이것은 도구의 실패가 아닙니다. 설계의 실패이며, 우리 대부분이 경험해 온 일입니다.

저는 프로덕션 환경의 OpenStack, Kubernetes, Terraform, 그리고 이 모든 것을 감시하는 관측성(observability) 스택을 운영합니다. 저는 제 자신의 알람들과 싸우며 생각보다 많은 밤을 보냈습니다. 그래서 모든 벤더의 발표 자료에 "SRE를 위한 AI"가 등장하기 시작했을 때, 저의 첫 반응은 지친 거절이었습니다. 온콜(on-call) 담당자에게 가장 필요 없는 것은, 새벽 3시에 직감만으로 내 데이터베이스를 재시작하기로 결정하는 자율적인 봇입니다.

하지만 자율성과는 전혀 상관없는, 실제로 작동하는 방식이 있습니다. 그것은 AI가 진정으로 잘하는 좁은 범위의 작업들—노이즈 클러스터링(clustering noise), 장애 폭풍(storms) 요약, 가설 초안 작성, 적절한 런북(runbook) 제시—에 AI를 사용하는 것입니다. 이 과정에서 인간은 최종 의사 결정권자로 남습니다. AI는 분류(triage)하고 제안합니다. 어떤 사람에게 페이지를 보낼지, 무엇을 수정할지는 당신이 결정합니다. 이것이 제가 말하는 AI의 _인간화(humanizing)_입니다. 기계를 더 인간처럼 만드는 것이 아니라, 기계를 사용하여 온콜 담당 인간이 휴식을 취하고, 집중하며, 통제권을 유지할 수 있도록 하는 것입니다.

진짜 문제는 도구가 아니라 신호(signal)입니다

알람 피로도(Alert fatigue)는 대시보드가 너무 적어서 발생하는 것이 아닙니다. 인간의 의사 결정과 연결되지 않는 알람 때문에 발생합니다. 모든 페이지는 단 하나의 질문에 답해야 합니다: 지금 당장 사람이 무언가를 해야 하는가? 만약 답이 "아니오" 또는 "아직은 아님"이라면, 페이지를 울려서는 안 됩니다. 우리 모두 이 사실을 알고 있습니다. 하지만 좋은 알람 규칙을 작성하는 것은 어렵고, 이를 조정(tuning)하는 것은 아무도 우선순위를 두지 않는 번거로운 일이기 때문에 우리는 끊임없이 이 원칙을 어깁니다.

AI가 개입하기 전의 정직한 기준점은 규칙 위생(rule hygiene)입니다. 만약 알림이 사용자 경험에 기반하고(symptom-based), 사용자에게 노출되는 SLO(Service Level Objective)와 연결되어 있으며, 합리적인 임계값(threshold)을 가지고 있다면, 이미 대부분의 잡음(noise)을 제거한 것입니다. 저는 거짓으로 페이지를 보내지 않는 알림 규칙 설계하기에 대해 길게 작성한 적이 있으며, 요약하자면 이렇습니다. 개별 기계가 무엇을 하는지에 알림을 보내지 말고, 사용자가 어떻게 느끼는지에 알림을 보내야 합니다. 노드의 메모리가 92%라는 것은 장애(incident)가 아닙니다. 하지만 결제 흐름(checkout flow)의 성공률이 92%인 것은 장애입니다.

여기에 증상 기반의 다중 창(multi-window) 소모율 알림을 소개합니다. 이는 모든 작은 변동에 페이지를 보내기보다 에러 예산(error budget)을 존중하는 방식입니다:

groups:
  - name: slo-burn-rate
    rules:
...

0.1%의 에러 예산에 대한 14.4 배수는 전형적인 급격한 소모 임계값(fast-burn threshold)입니다. 이 속도로는 약 2일 만에 30일치 예산을 소진할 것이므로, 지금 인간의 개입이 필요하다는 의미입니다. 여기에 더 느린 창을 결합하여 점진적으로 실패하는 경우를 대비합니다. 다중 창 소모율(multi-window burn rate) 알림이 생소하다면, 이 워크스루가 제가 팀에 계속 건네주는 가장 실용적인 참고 자료입니다.

_전문 팁: AI가 단 하나의 알림이라도 만지기 전에, 현재 페이지 중 얼마나 많은 것이 실제로 조치 가능한지 감사(audit)해 보세요. 한 달간의 페이지 기록을 가져와서 다음과 같이 분류합니다:

이곳은 AI를 활용하기에 가장 최적의 장소입니다. 왜냐하면 이것은 요약(summarization) 및 클러스터링(clustering) 문제이며, 이는 대규모 언어 모델(Large Language Models, LLM)이 매우 잘하는 분야이기 때문입니다. 모델에 발생한 알람(alerts), 최근 배포(deploys), 그리고 관련 토폴로지(topology) 정보를 입력하고, 시니어 SRE가 본능적으로 수행하는 작업을 요청하십시오. 즉, 폭풍처럼 쏟아지는 알람들을 하나의 근본 원인(root cause)과 그로 인한 하위 영향(downstream effects)으로 압축하도록 하는 것입니다.

인간화된 좋은 출력 결과는 다음과 같습니다:

알람 폭풍 요약 — 41개 알람, 최근 6분간 발생
가장 가능성 높은 근본 원인 (신뢰도: 높음): ingress-nginx 롤아웃(배포 #4821) 90초 후인 03:08 UTC에 노드 worker-prod-07이 NotReady 상태가 되었습니다. 41개 알람 중 38개가 이 노드에서 축출(evicted)되었거나 이 노드를 통해 라우팅되는 포드(pods)와 관련이 있습니다.
하위 영향 (별개의 사고 아님):

1. checkout p99 지연 시간(latency) +400ms — 포드 재스케줄링(rescheduling)
2. payment-worker 큐 깊이(queue depth) 상승 — 컨슈머(consumers) 재시작 중
3. 6x KubePodCrashLooping — 모두 worker-prod-07에서 발생
   권장 다음 확인 사항: kubectl describe node worker-prod-07 및 03:07 전후의 kubelet 로그 확인. 권장 런북(runbook): node-notready-triage. 이 요약은 권고 사항입니다. 어떠한 조치도 취해지지 않았습니다.

마지막 문장이 중요합니다. AI는 41개의 알람을 하나의 근본 원인과 세 가지 하위 영향으로 클러스터링하고, 신뢰 수준을 첨부하며, 다음 진단 단계를 제시했습니다. AI는 노드를 격리(cordon)하거나, 무언가를 재시작하거나, 배포를 롤백(roll back)하지 않았습니다. AI는 저에게 가설과 시작점을 전달했을 뿐이며, 그것이 맞는지 결정하는 것은 저의 몫입니다. 이를 통해 저의 이해 시간(time-to-understanding)은 "40개의 알람을 읽는 것"에서 "하나의 주장을 검증하는 것"으로 단축됩니다. 이것이 바로 AI가 당신의 시간을 아껴주길 원하는 지점이며, 그 절약된 시간은 MTTA 및 MTTR을 직접적으로 개선합니다. (어떤 사고 지표가 실제로 중요한지 엄격하게 따져보고 싶다면, 알람 피로도(alert fatigue)가 조용히 망가뜨리는 지표는 바로 MTTA입니다.)

기계적인 클러스터링(clustering)은 Alertmanager에서 수행될 수 있으며, 수행되어야만 합니다. AI는 클러스터를 평이한 언어로 설명하는(explains) 계층이고, Alertmanager는 중복된 페이지(pages)를 억제하여(suppresses) 애초에 당신을 깨우지 않도록 하는 계층입니다.

Alertmanager가 억제하게 하고, AI가 설명하게 하세요

LLM(대규모 언어 모델)에게 라우팅 엔진(routing engine) 역할을 맡기지 마세요. 결정론적인 그룹화(grouping) 및 억제(inhibition) 규칙은 신뢰할 수 있고, 감사 가능하며, 비용이 들지 않습니다. 폭풍이 인간에게 도달하기 전에 이를 접어(fold) 줄이기 위해 이 규칙들을 사용하고, 남은 것들을 AI가 요약하게 하세요.

route:
  receiver: oncall-pager
  group_by: ['alertname', 'cluster', 'node']
...

해당 억제 규칙 하나만으로도 가장 흔한 폭풍 패턴, 즉 노드 장애(node failure)가 뒤따라오는 20개의 포드(pod) 알람을 끌고 오는 현상을 제거할 수 있습니다. equal: ['node'] 절은 억제의 범위를 제한하여, 다른 노드에서 발생하는 진정으로 관련 없는 크래시루프(crashloop)는 여전히 페이지를 보낼 수 있게 합니다. 이것이 결정론적인 바닥(deterministic floor)입니다. AI는 이를 대체하는 것이 아니라, 그 위에 자리 잡고 남아 있는 소수의 알람을 설명합니다. 알람 노이즈를 줄이고 엔지니어가 실제로 신뢰할 수 있는 알람 설계하기에서 이 그룹화를 올바르게 수행하는 것에 대한 더 많은 세부 사항을 다루고 있으며, 이는 이 접근 방식과 잘 어우러집니다.

전문가 팁: 모든 AI 요약은 결론이 아닌, 신뢰 점수(confidence score)를 가진 하나의 가설로 취급하세요. 모델이 "다음 확인 사항(next check)"—즉, 인간이 1분 이내에 이를 확인하거나 반박하기 위해 실행할 수 있는 구체적인 명령어나 쿼리—를 출력하도록 요구하세요. 빠르게 검증할 수 없는, 확신에 찬 어조의 근본 원인(root cause)은 제안이 아예 없는 것보다 더 나쁩니다. 왜냐하면 지친 당신의 뇌를 잘못된 경로로 고착시키기 때문입니다.

우선순위 지정: 새벽 3시에 실제로 인간의 개입이 필요한 것은 무엇인가

클러스터링(Clustering)은 무엇이 일어나고 있는지를 알려줍니다. 우선순위 지정(Prioritization)은 _이것이 아침까지 기다릴 수 있는 일인지_를 알려줍니다. 이것은 온콜(on-call) 엔지니어를 번아웃시키는 판단의 영역이며, AI가 결정하기보다는 순위를 매기고 권장하는 방식으로 진정으로 도움을 줄 수 있는 또 다른 영역입니다.

우선순위 지정을 위해 AI가 합성(synthesizing)을 잘 수행할 수 있는 신호는 다음과 같습니다:

• 영향 범위 (Blast radius): 알람 라벨(alert labels)과 토폴로지(topology)에서 추출한 정보로, 얼마나 많은 사용자, 서비스 또는 SLO가 영향을 받는지 나타냅니다.
• 예산 소진 속도 (Budget velocity): 에러 예산(error budget)이 빠르게 소진되고 있는가, 느리게 소진되고 있는가, 아니면 전혀 소진되지 않고 있는가? 빠른 소진은 페이지(page)를 발생시키고, 느린 소진은 티켓(ticket)을 생성합니다.
• 비즈니스 컨텍스트 (Business context): 피크 시간대에 결제 기능이 중단되었는가, 아니면 새벽 4시에 내부 배치 작업(batch job)이 지연되고 있는가?
• 최근 변경 사항과의 상관관계 (Recent change correlation): 지난 30분 이내에 배포(deploy), 설정 푸시(config push) 또는 Terraform 적용(apply)이 있었는가?

이러한 신호들을 모델에 입력하고, 추론 근거(reasoning)를 포함한 심각도(severity)와 라우팅 결정(routing decision)을 제안하도록 요청하세요. 출력 결과는 클릭 한 번으로 무시할 수 있는 권장 사항처럼 읽혀야 합니다:

권장 사항: 티켓 생성, 페이지 호출 금지 (신뢰도: 중간).
BatchExportLatencyHigh가 발생 중이지만, 이는 SLO가 없고 사용자 영향이 없는 내부 야간 내보내기(export) 작업입니다. 사용자 대상 API의 에러 예산(error budget)은 영향을 받지 않았습니다. 연관된 배포 내역도 없습니다. 아침 시간대에 티켓을 생성할 것을 제안합니다; 2회 재시도 후에도 계속 발생할 경우 재평가하십시오.

사람인 당신은 이를 훑어보고 동의하거나,

• 이 알람의 runbook 어노테이션(annotation)과 일치하는 런북(runbook) 링크 및 관련 형제 링크들.
• 한 단락 분량의 이력: "이 알람은 지난 30일 동안 2회 발생했습니다. 두 번 모두 노드 드레인(draining the node)을 통해 해결되었으며, 평균 해결 시간은 14분이었습니다."
• 현재의 관련 상태: 최근 배포(deploys), 진행 중인 변경 사항(open changes), 현재 채널에 참여 중인 인원.

생성해서는 안 되는 것: 실행된 복구 조치(remediation). 모델은 kubectl drain 명령어를 초안하고 그 이유를 설명할 수 있습니다. 사람은 이를 읽고, 노드를 점검(sanity-check)한 뒤, 명령어를 실행합니다. "여기 명령어가 있습니다"와 "당신을 위해 명령어를 실행했습니다" 사이의 간극이 바로 이 접근 방식이 가진 전체 안전 마진(safety margin)입니다. 잘못된 노드를 드레인하면 하나의 장애를 두 개의 장애로 만들게 됩니다.

프로 팁: 위에서 언급한 번레이트(burn-rate) 예시의 runbook: 필드처럼, 런북 링크를 알람 어노테이션(annotation)에 직접 연결하세요. 모든 알람이 이미 정식 포인터(canonical pointer)를 가지고 있을 때 AI 검색(retrieval)은 훨씬 더 신뢰할 수 있습니다. 즉, 모델에게 어떤 런북이 적용되는지 추측하게 하는 것이 아니라, 이미 알고 있는 문서를 가져와 요약하도록 요청하는 것입니다. 잘못된 검색 결과가 들어가면, 확신에 차 있지만 틀린 요약 결과가 나옵니다.

봇이 대신 닫아주지 않는, 루프(loop) 닫기

모두가 건너뛰는 부분은 사후 조치(follow-through)입니다. 폭풍이 끝나고 장애가 해결되면, "해당 노드 알람 조정", "억제 규칙(inhibition rule) 추가", "프로브 타임아웃(probe timeout) 수정"과 같은 실행 항목(action items)들은 아무도 다시 읽지 않는 Slack 스레드 속으로 증발해 버립니다. 그러고 나면 다음 달에 똑같은 폭풍이 당신을 깨울 것입니다.

AI 역시 자신의 영역에서 이 과정을 도와줄 수 있습니다. 알람과 채팅 이력을 바탕으로 사후 분석(postmortem) 타임라인을 초안하고, 실행 항목을 추출하며, 폭풍을 방지할 수 있었던 구체적인 알람 규칙 변경 사항을 제안할 수 있습니다. 하지만 각 항목의 책임은 사람에게 있으며, 규칙 변경을 병합(merge)하는 것도 사람입니다. 장애 실행 항목에 대한 루프를 실제로 닫는 규율이야말로 어젯밤의 고통을 다음 달의 평온함으로 바꾸는 핵심입니다. AI는 수정안을 초안할 수는 있지만, 그것이 배포되는 것에 대해 신경 쓸 수는 없습니다. 그 부분은 여전히 우리의 몫입니다.

이것이 시간이 흐름에 따라 전체 시스템을 인간적으로 만드는 피드백 루프 (feedback loop)입니다. 무시된 모든 AI 권장 사항, 무시하도록 조정한 모든 잘못된 페이지 (false page), 클러스터링(cluster)한 모든 장애 폭풍은 더 나은 규칙, 더 나은 억제 (inhibition), 더 나은 라우팅 (routing)이라는 인코딩된 지식이 됩니다. AI는 더 선명한 그림을 얻게 되고, 인간은 더 평온한 밤을 보내며, 에러 예산 (error budget)은 정직하게 유지됩니다. 이러한 패턴에 대해 더 자세히 살펴보고 싶다면, 사이트의 장애 대응 카테고리 (incident response category)에서 제가 실제로 실행하는 워크플로 (workflows)를 확인할 수 있습니다.

넘지 말아야 할 선