새벽 2시 40분. 결제 서비스 응답 지연 알림이 터지고, 워룸 채널에 사람들이 모입니다. 로그는 분당 수천 줄씩 쏟아지고, 모두가 같은 화면을 스크롤하며 "뭐가 문제야?"를 반복합니다.
A 운영자는 로그를 처음부터 눈으로 훑습니다. 20분이 지나도 "에러가 많긴 한데…"에서 멈춰 있습니다.
B 운영자는 마스킹한 로그 300줄을 AI에게 붙여넣고 묻습니다. "이 로그에서 가장 많이 반복되는 에러와, 처음 에러가 튄 시각을 표로 정리해 줘." 10초 뒤, connection timeout이 02:31부터 급증했고 그 직전 배포 로그가 한 줄 있다는 요약이 돌아옵니다. B는 이걸 답으로 믿지 않습니다. 대신 "그럼 02:31 전후 원본 로그와 배포 이력을 직접 보자"로 범위를 좁혀, 담당자에게 "2시 30분 배포 뭐였어요?"를 묻습니다. 원인이 5분 만에 좁혀집니다.
차이는 AI를 쓰고 안 쓰고가 아닙니다. B는 AI를 **'먼저 볼 곳을 좁혀 주는 도구'**로 썼고, 확정은 원본 로그와 담당자 확인으로 했습니다. 이 모듈은 그 경계 — AI로 빠르게 초안을 뽑되, 원인은 사람이 확정하는 흐름 — 을 다룹니다.
- 1장애 대응에서 AI가 잘하는 일(로그 요약·핵심 에러 추출·타임라인 골격·원인 후보 분류·고객 안내문/RCA 초안)을 구분해 설명할 수 있다
- 2AI 출력은 항상 "원인 후보"이며 확정은 사람이 원본 로그와 담당자 확인으로 한다는 원칙을 적용할 수 있다
- 3외부 AI 도구에 로그를 넣기 전 민감정보 마스킹과 사내 정책 확인을 먼저 수행할 수 있다
- 4로그 요약·원인후보 분류·고객 안내문·RCA 초안을 뽑는 프롬프트를 직접 작성할 수 있다
- 5AI 출력 검증 체크리스트(사실 확인·원인 단정 금지·민감정보)로 초안을 확정 전 걸러낼 수 있다
AI는 장애에서 무엇을 잘하나 — 그리고 무엇을 절대 못 하나
AI가 잘하는 것: 빠른 초안. AI가 못 하는 것: 사실 확정
장애 대응은 시간 싸움입니다. 그런데 시간의 상당 부분이 "긴 로그를 읽고 정리하는" 단순노동에 들어갑니다 — 수천 줄에서 반복 에러를 세고, 시각순으로 타임라인을 짜고, 고객 안내문 문장을 다듬고, 보고서 양식을 채우는 일. AI는 바로 이 반복적 정리·요약·초안 작성을 매우 빠르게 합니다.
하지만 AI가 만든 것은 전부 초안이자 후보입니다. AI는 그럴듯한 문장을 생성할 뿐, 그 문장이 사실인지 알지 못합니다. 로그에 없는 에러를 지어내거나(환각), 동시에 일어난 두 사건을 인과로 단정하거나, 시각을 한두 칸 틀리게 적을 수 있습니다. 그래서 ITSM에서 AI의 자리는 명확합니다.
| 작업 | AI가 잘하는 부분(초안) | 사람이 반드시 하는 부분(확정) |
|---|---|---|
| 로그 요약 | 반복 에러 집계, 핵심 패턴 추출, 노이즈 제거 | 요약이 원본 로그와 일치하는지 라인 대조 |
| 타임라인 작성 | 시각순 사건 골격을 표로 배열 | 각 시각·수치가 실제 로그/모니터링과 맞는지 |
| 원인 후보 분류 | "배포·부하·외부의존성·설정" 등으로 후보 나열 | 어느 후보가 진짜인지 원본·담당자 확인으로 확정 |
| 고객 안내문 | 톤·구조를 갖춘 안내 문장 초안 | 영향 범위·복구 시각·사실관계 검증 후 발송 |
| RCA 초안 | 보고서 양식·5 Whys 질문·항목 골격 | 원인·영향·조치의 모든 사실을 근거로 검증 |
한 줄 원칙: AI는 "먼저 볼 곳"을 좁혀 주는 도구이지, "원인을 확정하는" 권한이 없습니다. 확정의 책임은 언제나 사람에게 있습니다.
그림: AI 장애 대응 보조의 4단계 흐름 — 1~3단계(요약·타임라인·원인 후보)는 AI가 빠르게 초안을 만들지만 모두 "후보"이고, 4단계 확정은 사람이 원본 근거와 담당자 확인으로 책임진다.
절대 원칙 — AI는 원인을 확정하지 않는다
이 모듈에서 다른 모든 내용을 잊어도 이 한 가지는 남겨야 합니다.
AI는 원인 후보를 정리할 뿐, 확정은 사람이 원본 로그와 담당자 확인으로 한다.
왜 이렇게까지 강조할까요. AI 요약은 너무 깔끔해서 검증을 건너뛰고 싶게 만들기 때문입니다. 새벽 3시, 피곤하고 윗선은 원인을 묻습니다. AI가 "근본 원인은 커넥션 풀 고갈로 보입니다"라고 깔끔하게 적어 주면, 그대로 보고서에 박고 싶은 유혹이 생깁니다.
그러나 그것이 상관관계를 인과로 착각한 것이라면 — 실제 원인은 그 뒤의 DB 슬로우쿼리였는데 — 잘못된 재발방지책(풀만 키움)이 나가고, 같은 장애가 다시 납니다. 틀린 원인은 틀린 처방을 부릅니다.
그래서 흐름은 항상 이렇게 고정됩니다.
- 빠른 초안(AI) → AI로 요약·타임라인·원인 후보를 10초 만에 뽑는다.
- 사람 검증 → 각 사실을 원본 로그 라인·모니터링 그래프·담당자 증언으로 대조한다.
- 확정(사람) → 검증된 것만 "확정 원인"으로, 검증 안 된 것은 "확인 중"으로 보고한다.
AI는 1단계의 속도를 주고, 사람은 2·3단계의 책임을 집니다. 이 순서를 뒤집어 AI가 확정까지 하게 두면, 그건 AI 활용이 아니라 책임 회피입니다.
민감정보 — 로그를 외부 AI에 넣기 전에
마스킹과 사내 정책 — 입력 전 필수 점검
외부 AI 챗봇은 편리하지만, 본질적으로 데이터가 사외로 나가는 통로입니다. 그런데 장애 로그만큼 민감정보가 빽빽한 데이터도 드뭅니다. 요약을 얻으려다 개인정보를 유출하면, 장애보다 훨씬 큰 사고가 됩니다.
로그에서 자주 새는 민감정보와 처리 방법은 이렇습니다.
| 종류 | 로그 속 예 | 입력 전 처리 |
|---|---|---|
| 고객 개인정보 | 이메일, 전화번호, 주문번호, 이름 | 치환(user@example.com → [EMAIL]) |
| 인증·비밀정보 | 토큰, 세션ID, API 키, 비밀번호 | 통째 삭제 또는 [REDACTED] |
| 결제정보 | 카드번호 일부, 거래ID | 삭제 또는 마스킹 |
| 내부 인프라 | 내부 IP, 호스트명, 경로, 포트 | 일반화(10.0.x.x → [INTERNAL_IP]) |
입력 전 점검은 두 단계입니다.
- 정책 확인: 사내 보안정책·고객사 계약상 "외부 AI 도구에 운영 데이터 입력"이 허용되는가? 금지면 사내 도구(폐쇄망 LLM)만 쓰거나, AI 없이 처리합니다. 허용 여부를 모르면 입력하지 않습니다.
- 마스킹: 허용되더라도, 필요한 패턴(에러 메시지·시각·스택)만 남기고 식별정보는 치환·삭제한 뒤 넣습니다. 에러 원인 파악에 고객 이메일은 필요 없습니다.
감각적으로: **"이 화면을 캡처해 외부에 보내도 되는가?"**를 스스로 물어 안 되면, AI에도 넣지 않습니다. 외부 AI 입력은 외부 전송과 같습니다.
프롬프트 — 빠른 초안을 뽑는 산출물 예시
로그 요약·원인후보 프롬프트 예시
핵심은 AI에게 **"원인을 확정해 줘"가 아니라 "후보를 정리해 줘"**로 시키는 것입니다. 프롬프트 자체에 "단정하지 말고 후보로", "근거 라인을 같이"를 넣으면 검증이 쉬워집니다. 모두 마스킹한 로그를 전제로 합니다.
로그 요약·원인후보 프롬프트:
아래는 결제 서비스의 마스킹된 로그 일부다. (개인정보·토큰은 이미 치환됨)
1) 가장 많이 반복되는 에러 메시지를 빈도순으로 5개까지 표로 정리해 줘.
2) 시간순으로 "처음 이상이 나타난 시각"과 그 전후 5분의 주요 이벤트를 타임라인 표로 만들어 줘.
3) 가능한 "원인 후보"를 배포/부하/외부의존성/설정/인프라 범주로 나눠 나열하고,
각 후보마다 "근거가 된 로그 라인"을 같이 적어 줘.
규칙:
- 원인을 단정하지 말고 반드시 "후보"로만 제시해.
- 로그에 없는 내용은 추측하지 말고 "로그에 근거 없음"이라고 표시해.
- 확정·조치 판단은 사람이 한다. 너는 후보 정리까지만 해.
(여기에 마스킹된 로그 붙여넣기)
고객 안내문 초안 프롬프트:
아래 사실관계로 고객 공지 초안을 작성해 줘.
- 영향 서비스: 결제 (일부 사용자)
- 증상: 결제 응답 지연 / 일부 실패
- 발생 시각: (확인된 시각만 입력)
- 현재 상태: 원인 조사 및 복구 진행 중
규칙:
- 아직 확정되지 않은 원인은 언급하지 마. "조사 중"으로만.
- 사과 + 영향 범위 + 현재 조치 + 다음 안내 시점, 4문단으로.
- 과장·확약 금지(예: "재발 없음" 같은 단정 금지).
초안일 뿐이며, 발송 전 담당자가 사실관계를 검증한다.
RCA 초안 프롬프트:
아래 검증된 타임라인과 사실을 바탕으로 RCA 보고서 초안의 골격을 만들어 줘.
- 항목: 요약 / 영향 / 타임라인 / 직접 원인 / 근본 원인(5 Whys) / 재발방지 조치
- 5 Whys는 "왜?"를 이어가는 질문 형태로 비워 둬. 답은 내가 검증해 채운다.
- 확정되지 않은 원인은 "확인 필요"로 표시해.
빈칸과 구조만 잡아 줘. 사실 확정은 사람이 한다.
세 프롬프트의 공통점은 명확합니다 — AI에게 확정 권한을 주지 않고, "후보·초안·골격"까지만 시키며, 검증은 사람 몫임을 프롬프트 안에 못 박습니다.
언제 AI를 쓰고, 언제 손을 떼나 — 판단 기준
직접 해보기 — 마스킹·요약·후보 분류·검증
아래 흐름을 종이 위에서 직접 따라가 보세요. 정답 방향과 검증 체크리스트는 ObserveBlock에 있습니다.
(1) 마스킹: 아래 로그에서 외부 AI에 넣기 전 가려야 할 항목을 모두 표시하고,
무엇으로 치환할지 적어 보세요.
02:31:05 ERROR payment user=hong@gmail.com order=ORD-99213 token=eyJ... connection timeout to db 10.0.3.21:5432
02:31:07 ERROR payment user=kim@naver.com order=ORD-99214 connection timeout to db 10.0.3.21:5432
02:30:40 INFO deploy payment-api v2.3.1 applied by jdoe
(2) 프롬프트: "로그 요약·원인후보" 프롬프트를 위 마스킹 로그에 맞춰 한 벌 적어 보세요.
(반드시 "단정 금지, 후보로만, 근거 라인 포함" 규칙 포함)
(3) 가정된 AI 출력: AI가 "근본 원인은 02:30:40 배포(v2.3.1)다"라고 단정해 돌려줬다고 하자.
이 출력의 문제점을 한 줄로 지적하고, 확정을 위해 무엇을 더 확인해야 하는지 2가지 적어 보세요.
(4) 안내문: 위 사실로 고객 공지 초안에 "절대 넣으면 안 되는 문장" 한 개를 적어 보세요.
마스킹 → 프롬프트 → 후보 → 검증 체크리스트- 마스킹 정답: user 이메일 두 건 → [EMAIL], order 번호 → [ORDER], token=eyJ... → [REDACTED], 내부 IP 10.0.3.21:5432 → [INTERNAL_DB]. 배포자 jdoe도 내부 식별정보면 일반화. 에러 메시지·시각·배포 버전은 원인 파악에 필요하므로 남긴다
- 프롬프트 정답 방향: "반복 에러 빈도 + 타임라인 + 원인 후보(범주별, 근거 라인 포함)"를 요청하되, "원인 단정 금지·후보로만·로그에 없으면 추측 금지·확정은 사람" 규칙이 들어가야 한다
- AI 단정의 문제: "근본 원인은 배포다"는 상관관계(배포 직후 에러)를 인과로 단정한 것 — 후보일 뿐 확정이 아니다. 더 확인할 것 예: (a) v2.3.1 변경 내역에 DB 커넥션 관련 변경이 있었는지 담당자 확인, (b) 배포 롤백 시 에러가 멈추는지 / DB 측 슬로우쿼리·리소스 지표 대조
- 안내문 금지 문장 예: "원인은 배포 오류이며 재발하지 않습니다" — 확정 안 된 원인 단정 + 재발 없음 확약. 둘 다 검증 전엔 절대 금지. "현재 원인 조사 및 복구 중"으로만
- 핵심 감각: AI는 02:31 전후로 "먼저 볼 곳"을 좁혀 줬을 뿐 — 좁혀진 곳을 사람이 원본 로그·담당자·지표로 파고들어 확정한다. AI가 준 건 지도, 확정은 발로 뛴 결과다
AI 출력 검증 체크리스트
확정 전, 이 체크리스트를 통과시킨다
AI가 뽑은 어떤 초안도 — 요약이든 타임라인이든 원인 후보든 안내문이든 RCA든 — 사람에게 넘어오는 순간 아래를 통과해야 '확정' 라벨을 붙일 수 있습니다.
| 점검 축 | 질문 | 통과 기준 |
|---|---|---|
| 사실 확인 | 요약·타임라인의 시각·수치·에러가 원본 로그와 일치하는가 | 모든 핵심 사실을 원본 라인으로 대조 완료 |
| 원인 단정 금지 | 검증되지 않은 원인을 "확정 원인"으로 적지 않았는가 | 미검증은 "후보/확인 중"으로 표기 |
| 환각 점검 | 로그에 없는 에러·이벤트를 AI가 지어내지 않았는가 | 근거 라인이 없는 항목은 삭제 또는 보류 |
| 담당자 확인 | 원인 후보를 해당 변경·서비스 담당자에게 확인했는가 | 담당자 증언으로 후보를 확정 또는 기각 |
| 민감정보 | 출력·보고서에 마스킹했어야 할 정보가 다시 들어가지 않았는가 | 개인정보·토큰·내부정보 없음 |
| 외부 발송 | 고객 안내문에 미확정 원인·과장·확약이 없는가 | 사실+현재상태+다음안내만, 단정 없음 |
이 체크리스트가 AI 활용의 안전장치입니다. 통과하지 못한 항목은 보고서에서 빼거나 "확인 중"으로 내립니다. 체크리스트를 통과한 사실만이 확정이고, 그 확정의 책임은 AI가 아니라 서명한 사람에게 있습니다.
위 표를 한 장의 게이트로 보면, AI가 내놓은 것은 무엇이든 통과 전에는 "후보" 라벨이 붙어 있습니다. 여섯 축을 모두 통과한 항목만 "확정"이 되며, 통과하지 못한 항목은 삭제하거나 "확인 중"으로 내립니다. 확정의 서명은 사람이 하므로, 책임도 사람에게 남습니다.
현장에서 자주 보는 함정
증상: 새벽 장애 때 AI가 로그 요약과 함께 "근본 원인: 트래픽 급증으로 인한 커넥션 풀 고갈"이라고 깔끔하게 정리해 줬습니다. 피곤하고 윗선 보고는 급해서, 그대로 RCA 보고서의 근본 원인란에 넣고 재발방지로 "커넥션 풀 2배 증설"을 적어 마감했습니다. 2주 뒤, 같은 장애가 또 났습니다.
원인: AI는 "커넥션 풀 고갈 에러가 많다"는 현상을 보고 그것을 근본 원인으로 단정했지만, 실제 근본 원인은 그 뒤에 있던 특정 슬로우쿼리였습니다. 슬로우쿼리가 커넥션을 오래 점유해 풀이 고갈된 것이라, 풀을 키워도 쿼리가 그대로면 다시 고갈됩니다. AI는 상관관계(풀 고갈 에러 다수)를 인과(근본 원인)로 착각했고, 사람이 그 단정을 검증 없이 그대로 옮겨 적었습니다. 틀린 원인이 틀린 처방을 낳았습니다.
해결 방향:
- AI 출력의 "근본 원인"은 항상 후보로 받는다 — "커넥션 풀 고갈"은 증상일 수 있으니 "왜 고갈됐나"를 한 단계 더 묻는다(5 Whys).
- 검증 체크리스트를 적용: 원본 로그·DB 지표·슬로우쿼리 로그를 대조하고, DB 담당자에게 "그 시각 무거운 쿼리 있었나"를 확인한다.
- 확정된 근본 원인(슬로우쿼리)에 맞는 재발방지(쿼리 튜닝·인덱스)로 보고서를 고친다.
- 교훈을 절차로: **"AI가 정리한 원인은 검증 통과 전까지 보고서에 '확정'으로 못 박지 않는다"**를 팀 RCA 규칙에 추가한다. AI는 초안을 빠르게 줄 뿐, 재발을 막는 건 사람의 검증이다.
한국의 운영·SI·SM 현장에서 AI는 빠르게 "장애 대응 보조 도구"로 들어오고 있습니다. 새벽 장애 워룸에서 로그 요약·타임라인·고객 공지 초안·RCA 초안을 AI로 10분 만에 뽑아내면, 의사결정자에게 올라가는 보고의 속도가 확 빨라집니다. 발주사·원청 관리자 자리에서 이 속도는 분명한 무기입니다.
그러나 바로 그 자리에서 관리자가 지켜야 할 선이 이 모듈의 원칙입니다. 장애보고서·RCA에 서명하는 사람은 관리자이고, 그 안의 원인·영향·재발방지에 대한 책임은 AI가 아니라 서명자에게 있습니다. AI가 정리한 원인을 검증 없이 고객사에 보고했다가 그것이 틀렸다면, "AI가 그렇게 말했다"는 변명이 되지 않습니다. 그래서 관리자는 AI를 초안 속도용으로 쓰되, 확정은 협력사 엔지니어·담당자 확인과 원본 근거로 하도록 절차를 잡아야 합니다.
또 하나, 관리자가 통제해야 할 것은 민감정보와 정책입니다. 협력사 엔지니어가 급한 마음에 고객 로그를 외부 AI에 통째로 붙여넣는 일이 실제로 일어납니다. "외부 AI 입력 전 마스킹·정책 확인"을 팀 규칙으로 못 박고, 폐쇄망 도구 사용 범위를 정하는 것까지가 관리자의 몫입니다. 결국 이 자리에서 AI 역량이란 "AI를 잘 시키는 법"과 "AI 출력을 의심하고 검증하는 법", 그리고 "AI에 무엇을 넣으면 안 되는지 아는 법"의 묶음입니다.
관련 모듈로 더 깊이:
- 근본원인분석(RCA) 기법 — AI가 던진 원인 후보를 사람이 검증할 때 쓰는 근본원인분석 기법
- RCA 보고서 작성 — AI 초안을 확정 가능한 RCA 보고서로 다듬는 작성 표준
- AI로 RFP·RFI 분석 — 같은 '확정은 사람' 원칙을 사업 단계의 RFP 분석으로 옮기는 다음 단계
다음 모듈에서는 장애 대응을 넘어 사업 단계로 올라가, AI로 RFP·RFI 분석 — 발주 문서에서 요구사항·평가항목·리스크를 빠르게 뽑아내고 제안 전략의 초안을 잡는 흐름을, 역시 '확정은 사람'의 원칙 위에서 다룹니다.