심야의 알람을 AI와 함께 극복하는 기술 — “읽기 전용”부터 시작하는 AI 인시던트 대응 실전 가이드 (가설 기반 트리아지 / 블래스트 반경

새벽 3시. 스마트폰이 진동하며 화면에 「결제 API의 에러율 급상승」 알림이 뜹니다.

이때 머릿속은 대개 하얘지곤 하죠. 로그를 열어야 할지, 대시보드를 열어야 할지, 아니면 선배를 깨워야 할지. 손은 떨리는데 판단만은 서둘러야 합니다. 온콜 (On-call, 대기 당번)의 밤은 기술력 이전에, 우선 이 고독함이 견디기 힘듭니다.

최근에는 「AI에게 장애 대응을 맡기면 된다」는 분위기도 있습니다. 실제로 2026년에는 AI SRE라고 불리는 툴이 급격히 늘어났습니다. 알람, 메트릭스 (Metrics), 최근의 코드 변경, 과거의 인시던트 (Incident)를 횡단하여 읽고, 노이즈를 제거하여 원인을 짚어줍니다. 매우 든든합니다.

하지만 솔직히 말하자면, 여기서 순서를 틀리면 운영 환경이 불타버립니다.

「AI가 고치게 하자」며 갑자기 운영 서버 조작을 AI에게 통째로 맡겨버리는 것. 이것이 가장 위험합니다. 장애 대응에서 정말 효과적인 것은 속도보다 순서입니다. 오늘은 그 「사고 치지 않는 순서」와, 내일의 온콜부터 바로 사용할 수 있는 패턴, 프롬프트 (Prompt), 코드를 통째로 전달해 드리겠습니다.

먼저 용어만 가볍게 다져놓겠습니다.

인시던트 (Incident)… 서비스가 평소처럼 작동하지 않게 된 사건. 에러 급증, 응답 지연, 전체 다운 등.
온콜 (On-call)… 「장애가 발생하면 호출되는」 대기 당번. 심야든 휴일이든, 울리면 대응하는 사람.
SRE (Site Reliability Engineering)… 서비스를 안정적으로 계속 작동시키기 위한 사고방식 및 직종. Google에서 시작되었으며, 「장애는 제로로 만들 수 없다는 전제하에, 어떻게 하면 더 빠르고 똑똑하게 복구할 것인가」를 설계하는 사람들.

이 기사는 「무지의 무지」, 즉 아직 온콜 자체가 무서운 사람을 위해 쓰고 있습니다. 전문 용어는 나올 때마다 풀어서 설명할 테니, 너무 긴장하지 않으셔도 됩니다.

결론부터 말씀드리면, AI에게 무언가를 맡기기 전에 먼저 인시던트 대응을 5가지 페이즈 (Phase)로 나누어 지도를 갖는 것이 좋습니다.

왜냐하면, 「AI에게 장애 대응을 맡겨도 되는가?」라는 질문은 너무 막연해서 답을 내기 어렵기 때문입니다. 페이즈마다 「AI에게 안전하게 맡길 수 있는 범위」가 완전히 다르거든요.

2026년의 AI SRE 설계에서도 대략 이 5가지로 나뉩니다.

페이즈	무엇을 하는 시간인가	AI에게 안전하게 맡기기 쉬운 범위
탐지 (Detection)	「이상 발생」을 인지함	알람 요약, 관련 알람의 상관관계 분석
분류 (Triage)	중요도를 판단하고 어디부터 볼지 결정함	로그 요약, 영향 범위 정리, 원인 가설 나열
조사 (Investigation)	원인을 좁혀나감	read-only (읽기 전용) 로그·메트릭스 조사
복구 (Remediation)	실제로 고침	후보 제안까지. 실행은 인간의 승인 후 진행
에스컬레이션 (Escalation)	감당할 수 없다고 판단하여 인원을 늘림	상황 요약 자동 생성, 연락처 제시

포인트는, 왼쪽의 탐지·분류·조사는 AI가 점점 더 도와주는 영역이고, 오른쪽의 복구·에스컬레이션은 인간이 고삐를 쥐는 영역이라는 온도 차가 있다는 점입니다.

「트리아지 (Triage)」는 응급 현장에서 사용하는 용어죠. 환자가 많이 실려 왔을 때, 어떤 사람부터 진료할지 결정하는 그것 말입니다. 인시던트에서도 마찬가지로, 「지금 이것이 고객 전체에 영향을 주고 있는가, 일부인가, 아니면 사내뿐인가」를 먼저 분류합니다. 이 단계를 건너뛰고 원인 규명으로 돌진하면 대개 길을 잃게 됩니다.

지도를 갖는다. 그것만으로도 심야의 하얘진 머릿속에 첫걸음이 보이기 시작합니다.

지도를 갖췄다면, 다음은 AI에게 어디까지 맡길 것인가를 단계별로 생각합니다.

2026년의 AI SRE에는 이해하기 쉬운 성숙도의 계단이 있습니다. 아래에서부터 순서대로 다음과 같습니다.

읽기 전용 (read-only insights)… AI는 보기만 함. 로그를 요약하고 가설을 내놓지만, 아무것도 실행하지 않음.
조언 (advised actions)… AI가 「이렇게 하면 좋을 것 같다」고 제안함. 실행은 하지 않음.
승인 기반 복구 (approval-based remediation)… AI가 복구 액션을 준비하고, 인간이 GO를 내리면 실행함.
가드레일이 있는 자율 (autonomous with guardrails)… 정해진 범위 내라면 AI가 스스로 실행함.

여기서 가장 중요한 것은, 첫 단계는 반드시 「읽기 전용」부터 시작해야 한다는 것입니다.

왜라고 생각하시나요?

처음 만난 사람에게 갑자기 집 열쇠를 건네주지는 않죠. 우선 현관에서 대화를 나누고, 신뢰할 수 있다고 판단되면 조금씩 할 수 있는 일을 늘려갑니다. AI에 대한 권한도 이와 완전히 같다고 생각합니다.

「읽기 전용 (read-only)」이라면, 최악의 경우 AI가 실수하더라도 피해는 제로입니다. 아무것도 실행하지 않았으니까요. 잘못된 가설을 내놓더라도 사람이 "아니, 그건 아니야"라고 버리면 그만입니다. 실패 비용이 거의 제로인 곳에서 시작하는 것 —— 이것이 AI를 장애 대응에 투입할 때 가장 안전한 입구입니다.

그리고 좋은 AI SRE인지 아닌지를 판별하는 질문도 여기에 있습니다.

• 그것은 read-only (읽기 전용) 인가, 아니면 write (쓰기·실행) 가 가능한가?
• 고려한 증거, 제외한 가설, 최종적인 답에 대한 확신도 (confidence level) 를 제대로 보여주는가?

"자신만만하게 대답하지만, 왜 그렇게 판단했는지 보여주지 않는 AI"는 조사 단계에서 가장 위험합니다. 근거와 확신도를 출력하게 만드세요. 이는 이후의 프롬프트에서도 철저히 적용할 것입니다.

자, 이제부터가 실전입니다. 읽기 전용 AI를 파트너로 삼아, 가설 기반 트리아지 (hypothesis-driven triage) 를 해봅시다.

로그는 많으면 많을수록 불안해지기 마련이죠. 하지만 전부 읽을 필요는 없습니다. 하는 일은 간단하며, 다음과 같은 루프를 따릅니다.

• 관측 (observation)… 현재 파악된 사실만을 수집한다 (에러율, 발생 시점, 어떤 서비스인지, 최근의 변경 사항)
• 가설 (hypothesis)… "원인은 이것일지도 모른다"를 3가지 제시한다 (하나로 단정 짓지 않는다)
• 검증 (verification)… 가설마다 "이것이 사실이라면, 로그의 이 부분에 이렇게 나타날 것이다"를 read-only로 확인한다

여기서 AI가 엄청난 위력을 발휘합니다. 사람이 새벽 3시에 1,000줄의 로그를 노려보는 것보다, AI에게 요약을 시키고 가설을 3가지 나열하게 하는 것이 훨씬 빠릅니다.

이를 위한 프롬프트가 바로 이것입니다. 복사해서 로그를 붙여넣기만 하면 바로 사용할 수 있습니다.

당신은 숙련된 SRE입니다. 이것은 운영 환경 인시던트의 1차 트리아지입니다.
당신은 「읽기 전용」입니다. 커맨드 실행, 재시작, 롤백 (rollback) 등의 조작은 절대로 제안하지 마십시오.
# 상황
...

이 프롬프트의 핵심은 세 가지입니다.

첫째, 「당신은 읽기 전용입니다」라고 처음에 제약을 거는 것입니다. 이를 통해 AI가 멋대로 "서버를 재시작합시다"라고 말하는 것을 방지합니다. 둘째, 가설을 3가지 제시하게 하는 것입니다. 하나로 단정 짓게 하면 AI는 아무렇지 않게 "그럴듯한 오답"으로 돌진하기 때문에, 여러 개를 나열하고 사람이 선택하게 합니다. 셋째, 제외한 가설도 함께 제시하게 하는 것입니다. "무엇을 의심했고, 왜 버렸는지"가 보이면 AI의 사고를 신뢰할 수 있는지 판단할 수 있습니다.

여기서 등장하는 블래스트 반경 (blast radius) 은 원래 「폭발의 피해가 미치는 범위」라는 의미입니다. 인시던트에서는 "이 장애가 어디까지 영향을 미치고 있는가?"의 범위를 가리킵니다. 모든 사용자에게 영향을 주는지, 특정 지역만인지, 혹은 특정 기능만인지 말이죠. 이것을 알면 심각도 판단과 고객 통지 필요 여부를 즉시 결정할 수 있습니다.

그리고 AI에게 조사 커맨드를 출력하게 한다면, 읽기 전용 커맨드만 통과시키는 울타리를 사람 측에서 반드시 세워두어야 합니다. 이것이 코드 예시 ①입니다.

import shlex
import subprocess
# 「읽기 전용」임을 확인할 수 있는 커맨드만 허용 리스트에 넣는다.
...

이 울타리가 있는 것만으로도, 조사 단계에서 AI가 손을 움직이게 하더라도 「읽기 전용」의 범위를 절대 벗어나지 않습니다. 안심하고 맡길 수 있다는 것은 바로 이런 상태를 말합니다.

조사가 진행되어 원인이 보이기 시작했습니다. 이제 복구 (remediation) 단계입니다.

여기서 많은 사람이 저지르는 실수는 "AI님, 그럼 고쳐주세요"라며 복구까지 AI에게 통째로 맡겨버리는 것입니다. 그 마음은 이해합니다. 빨리 자고 싶으니까요. 하지만, 고치기 전에 「멈추는 울타리」를 먼저 세워야 합니다. 이 순서가 바뀌면 사고가 납니다.

복구 액션에는 다음과 같은 원칙을 둡니다.

• bounded (범위 제한)… 영향 범위를 한정한다. 전체 서버가 아니라 1대부터 시작한다.
• reversible (되돌릴 수 있음)… 롤백 (rollback)이나 피처 플래그 (feature flag)를 통해 즉시 원래대로 되돌릴 수 있는 방법부터 선택한다.
• audited (감사 가능)… 누가, 언제, 무엇을 실행했는지 반드시 기록한다.

그리고 조작을 세 가지 유형으로 구분합니다.

종류	예	AI의 취급
읽기 전용 (read-only)	로그 열람, 메트릭 (metrics) 취득, get / describe	AI가 자유롭게 수행 가능 (코드 예시 ①의 울타리 안에서)
가역적 조작 (reversible)	feature flag를 OFF, 1대만 재시작, 배포 롤백 (rollback)	AI는 제안까지만. 실행은 인간의 승인 + 감사 로그 (audit log)
파괴적·비가역적 (destructive)	DB의 DELETE / DROP, 데이터 삭제, 운영 설정의 전면 변경	기본적으로 거부. 인간의 이중 확인 없이는 절대 실행하지 않음

이 선긋기를 코드의 "게이트 (gate)"로 만듭니다. AI나 자동화가 파괴적인 조작을 호출하면, 일단 멈추고 인간의 확인 토큰 (confirmation token)을 요구하는 메커니즘입니다.

type RiskLevel = "read_only" | "reversible" | "destructive";
interface ActionRequest {
command: string;
...

confirmToken

이 없는 동안, AI가 아무리 "재시작해야 합니다"라고 주장해도, 실행되는 것은 "계획"뿐입니다. 인간이 내용을 읽고, 납득하고, 비로소 토큰을 부여합니다. 이 한 박자가 심야 3시의 돌이킬 수 없는 실수를 방지합니다.

그리고 AI에게 "이 조작은 어떤 종류인가"를 분류하게 하는 것이 편리합니다.

당신은 SRE 리뷰어입니다. 다음 복구 액션 후보를 리스크에 따라 분류하십시오.
당신은 실행하지 않습니다. 분류와 인간이 확인해야 할 점만 출력하십시오.
# 복구 액션 후보
...

"더 안전한 대안"을 반드시 내놓게 하는 것이 요령입니다. AI는 "롤백합시다"라고 일직선으로 말하기 쉽지만, "먼저 flag로 OFF 하여 영향을 확인하자"와 같이 훨씬 더 가역적이고 작은 한 걸음을 찾아내는 경우가 많습니다.

한 가지, AI에게 로그를 통째로 넘기기 전에 지워두어야 할 것이 있습니다.

운영 로그에는 꽤 높은 확률로 PII (개인 식별 정보: 이메일 주소, 전화번호 등) 나, credential (API 키, 토큰, 비밀번호) 등이 섞여 있습니다. 이를 그대로 외부 AI에 보내면 정보가 유출됩니다. 장애를 고치려다 또 다른 사고를 일으키게 되는 것입니다.

따라서 AI에게 전달하기 전에 마스킹 (masking, 글자 가리기) 하는 단계를 반드시 거칩니다.

import re
# 흔한 PII/cred 패턴. 자신의 서비스에 맞춰 추가해 나간다.
PATTERNS = {
...

완벽한 정규 표현식은 존재하지 않으므로, 이것은 "0을 100으로 만드는" 도구가 아니라, "가공되지 않은 상태로 전달하는 사고를 현실적으로 줄이는" 도구입니다. 걱정된다면 애초에 민감한 로그는 AI에게 전달하지 않는다는 선긋기 또한 훌륭한 설계입니다. 무엇을 전달하지 않을지 결정하는 것은 언제나 인간의 일입니다.

장애가 수습되었다. 드디어 잘 수 있다. ……하지만, 여기서 가장 중요한 일이 남아 있습니다.

포스트모템 (postmortem) 입니다. 직역하면 "검시". 인시던트가 끝난 후에 "무엇이 일어났고, 왜 일어났으며, 다음에는 어떻게 방지할 것인가"를 되돌아보고 남기는 문서를 말합니다.

왜 이것이 가장 중요하다고 생각하십니까?

장애 그 자체는 언젠가 반드시 다시 일어납니다. 하지만 제대로 되돌아보고 기록해 둔다면, 다음에 같은 구멍에 빠지는 사람을 줄일 수 있습니다. 포스트모템은 미래의 자신과, 다음에 온콜 (on-call)에 들어갈 누군가에게 주는 선물입니다.

여기서 절대 빠뜨려서는 안 되는 것이 블레임리스 (blameless, 비난 없는) 원칙입니다. Google이나 Netflix가 퍼뜨린 SRE 문화로, "누가 저질렀는가"가 아니라 "무엇이 그 실패를 가능하게 만들었는가"를 보는 것입니다.

이유는 간단합니다. 사람은 비난받으면 사실을 말하지 않게 되기 때문입니다. "네 잘못이야"라고 하는 순간, 모두가 정보를 숨기거나 책임을 떠넘기려 하여 진정한 원인에 도달할 수 없게 됩니다. 반대로 비난하지 않는 분위기가 있으면, 사람들은 "사실 그때 이렇게 해버려서..."라고 솔직하게 말해줍니다. 그래서 근본 원인에 닿을 수 있습니다.

원인을 파헤칠 때는 **Five Whys (5번의 왜)**를 사용합니다. "왜 떨어졌지?"를 반복하며 표면적인 증상에서부터 망가진 프로세스까지 내려가는 기법입니다. 여기에 철칙이 하나 있습니다.

"사람"을 근본 원인으로 삼아서는 안 됩니다. "인적 오류 (human error)", "A 씨의 부주의", "B 팀의 실수"는 답으로 인정하지 않습니다.

"A 씨가 설정을 실수했다"에서 멈추지 않고, "왜 실수할 수밖에 없는 구조였는가", "왜 리뷰에서 알아채지 못했는가"까지 내려갑니다. 원인은 사람이 아니라, 사람이 실수할 수 있었던 프로세스에 있다는 관점입니다.

참고로 **MTTR(Mean Time To Resolution, 평균 복구 시간)**은 "감지부터 완전 복구까지 걸린 평균 시간"을 의미합니다. P1(최중대) 장애의 업계 중앙값은 약 45~60분 정도라고 합니다. 포스트모템(Postmortem)에 이 수치를 남겨두면, 나중에 개선 효과가 있었는지 측정할 수 있습니다.

이 초안을 AI에게 쓰게 합니다. "백지 상태의 문제"——무엇부터 써야 할지 몰라 손이 멈춰버리는 그 현상——을 단번에 해결할 수 있습니다.

당신은 SRE입니다. 다음 인시던트 기록으로부터 블레임리스 포스트모템(Blameless Postmortem)의 초안을 작성해 주세요.
# 절대 규칙
- 특정 개인이나 팀을 "원인"으로 지목하지 말 것 (사람을 범인으로 만들지 말 것).
...

그리고 나온 초안이 "제대로 블레임리스(Blameless)한가"를 기계적으로도 체크합니다. 타임라인의 골격을 데이터로 가지고 있으면, 나중에 검색도 가능해져서 편리합니다.

# postmortem.yml — 구조화하여 관리하면 나중에 검색 및 집계가 가능함
incident: "결제 API의 5xx 에러율 상승"
severity: "Sev-2"
...

import yaml
# "사람을 범인으로 만들고 있지 않은가"를 투박하지만 기계적으로 감시함
BLAME_WORDS = ["~의 탓", "~가 잘못", "담당자의 실수", "부주의", "게을리함", "~씨의 실수"]
...

완벽한 검사는 아니지만, "무의식중에 누군가를 비난하는 문장이 섞여 있지 않은가"를 멈춰 서서 재검토하는 계기가 됩니다. 포스트모템은 기억이 생생한 영업일 기준 5~7일 이내에 팀원 모두가 함께 완성하는 것을 추천합니다.

여기까지를 요약하면, 새벽 3시에 "누가 무엇을 결정할 것인가"는 다음과 같이 나뉩니다.

국면	AI에게 맡길 것	인간이 반드시 쥐어야 할 것
감지·분류	알람 요약, 연관 관계 설정, 영향 범위 정리	심각도(Sev)의 최종 판정
...

대략 말하자면, AI는 "읽기·요약하기·나열하기·초안 작성하기" 담당. 인간은 "심각도·파괴적 작업·고객에 대한 약속·최종 책임"을 쥐는 담당입니다. 이 선만 잘 그어두었다면, AI를 마음껏 사용해도 두렵지 않습니다.

그리고, 도입해 보고 "이것은 물러나야 한다"라는 신호도 알고 있어야 합니다.

철수 라인	대응
AI가 근거(증거·제외 가설·확신도)를 제시하지 못함	조사 주역에서 제외. 요약 역할로 강등
...

마지막 항목이 은근히 중요합니다. AI가 유창하게 대답하면 사람은 무심코 그대로 믿어버리기 쉽습니다. AI는 가설을 "확장"하기 위해 사용하고, "결정"하는 것은 인간입니다. 이 역할을 무너뜨리지 않는 것이 결국 가장 강력한 안전장치가 됩니다.

길어졌습니다. 마지막으로 딱 하나만 말씀드리겠습니다.

장애 대응 로그나 타임라인, 포스트모템. 그거 작성하는 중에는 좀 귀찮죠. 빨리 자고 싶으니까요. 하지만 잠시만 생각해 봐 주셨으면 합니다.

그것은 내일의 나에게 보내는 "고마워요(あざっす)"입니다.

새벽 3시, 엉망이 된 정신으로 남긴 한 줄의 메모가 다음 주에 온콜(On-call)에 들어가는 누군가——어쩌면 미래의 나 자신——를 구합니다. "그때 남겨줘서 고마워요"라고 말이죠. 미래의 나로부터 그런 말을 들을 수 있는 오늘을 사는 것. 이것은 장애 대응에 국한되지 않고, 제가 모든 선택의 축으로 삼고 있는 생각입니다.

블레임리스(Blameless, 비난 없는) 또한 뿌리는 같다고 생각합니다. "누구의 탓인가"를 찾는 비난의 축이 아니라, "다음에 어떻게 도울 것인가"라는 배려의 축입니다. 비난하지 않기에 사람은 진실을 말합니다. 진실이 남기에 미래가 구원받습니다. 기술 이야기인데 결국 이곳에 도달한다는 점이 흥미로운 부분입니다.

AI는 그 "남기는 행위"를 엄청나게 가볍게 만들어주는 파트너입니다. 읽게 하고, 요약하게 하고, 가설을 나열하게 하고, 초안을 쓰게 합니다. 하지만 고삐는 반드시 인간이 쥐어야 합니다. 읽기 전용(Read-only)부터 시작해서, 신뢰할 수 있는 만큼 조금씩 맡기는 범위를 넓혀가는 것입니다.

이번 주의 첫걸음은 이 정도로 충분합니다.

• 다음 온콜을 위해, **프롬프트 예시 ①(가설 기반 트리아지)**를 수중에 복사해 두기
• AI에게 조사를 시키려면, 코드 예시 ①의 read-only allowlist를 하나만 준비하기
• 최근의 작은 인시던트에 대해, 프롬프트 예시 ③으로 포스트모템 초안을 한 편 써보기
• 그 포스트모템을, "사람을 범인으로 만들고 있지는 않은가"만 재검토하기

100점이 아니어도 됩니다. 65점이라도, 내일의 내가 "무리하지 않고 남겨줘서 고마워요"라고 말해준다면 그것으로 충분합니다.

그 작은 발걸음을 조금씩 쌓아 나갑시다.