장애 기록은 저장으로 끝나지 않는다: 검색되고 전파되고 대응을 시작해야 한다

실제 장애 기록 자동화와 외부 개발 플랫폼 장애를 함께 겪으며 든 질문을 정리했다. 특정 조직, 채널, 사람, 내부 시스템을 식별할 수 있는 정보는 걷어내고 기록 시스템의 완료 조건만 남겼다.

장애 채널의 대화를 모아 역할 수행과 기록 완성도를 평가하는 자동화를 만들고 있었다. 실시간 대응 채널이 아니라 과거 장애를 남기기 위한 기록용 채널도 있었다. 자동화는 이 채널을 실시간 대응 평가 대상에서 제외하고, 별도 문서에 결과를 보관했다.

구조만 보면 자연스럽다. 실시간 대응과 과거 기록은 목적이 다르니 같은 점수로 평가하면 안 된다.

그런데 같은 날 외부 개발 플랫폼에 장애가 발생했다. 여러 PR 검증과 배포 작업이 멈췄지만, 누가 상황을 추적하고 어떤 조건에서 대응을 시작할지 분명하게 보이지 않았다. 당장 고객 장애가 난 것은 아닐 수 있다. 그래도 신규 배포와 긴급 수정 능력이 사라진 상태라면 적어도 누군가는 영향을 확인하고, 상태를 선언하고, 다음 확인 시점을 알려야 한다.

이 장면을 보며 질문이 바뀌었다.

장애 기록을 잘 남기는 것만으로 실제 대응이 나아지는가?

검색되지 않고, 관련 팀에 전파되지 않고, 다음 장애의 대응 절차를 시작시키지 못한다면 기록은 쌓여도 대응 능력은 쌓이지 않는다.

배포 경로를 지키는 기술적 대비책은 GitHub Actions가 멈췄다: 모든 자동화 대신 중요한 배포만 이중화하기에서 따로 다뤘다. 여기서는 기록과 훈련이 실제 대응을 시작시키는 운영 구조에 집중한다.

TL;DR

• 장애 기록의 목적은 문서 수를 늘리는 것이 아니라 다음 장애의 인지·판단·복구 시간을 줄이는 것이다.
• 기록용 채널을 실시간 대응 점수에서 제외하는 것은 맞다. 대신 검색 가능성, 후속 조치, 재사용 여부를 평가해야 한다.
• 검색은 장애 제목보다 증상, 영향, 의존 서비스, 완화 방법을 중심으로 설계해야 한다.
• 기록은 검토·색인·전파·후속 조치까지 끝나야 완료다.
• 훈련을 반복해도 실제 신호가 선언 기준과 담당자에게 연결되지 않으면 대응은 시작되지 않는다.
• AI 검색과 요약은 보조 수단이다. 구조화된 메타데이터(metadata), 원문 링크, 책임자와 실행 가능한 런북(runbook)이 먼저다.
• 기록의 출력은 문서지만, 기록 시스템의 성과는 실전에서 다시 사용된 행동이다.

기록과 대응은 서로 다른 시스템이다

장애 대응 과정에는 서로 다른 단계가 있다.

신호 감지
-> 장애 여부 판단
-> 담당자와 역할 호출
-> 완화·복구
-> 타임라인과 결정 기록
-> 사후 분석
-> 검색 가능한 형태로 색인
-> 관련 팀에 전파
-> 런북·알림·시스템 개선

대화를 저장하고 문서를 만드는 자동화는 중간 이후를 담당한다. 반면 실제 장애를 인지하고 담당자를 부르는 일은 앞부분에 있다.

둘은 연결돼야 하지만 같은 것은 아니다.

• 대응 시스템은 지금 누가 무엇을 해야 하는지 정한다.
• 기록 시스템은 무엇이 있었고 왜 그런 결정을 했는지 남긴다.
• 학습 시스템은 과거 기록을 다음 알림, 런북, 설계 변경으로 되돌린다.

기록 시스템만 잘 만들어도 과거는 정리된다. 하지만 대응과 학습으로 연결되지 않으면 현재의 장애는 여전히 사람의 우연한 발견과 기억에 의존한다.

그래서 기록 자동화의 완료 조건을 “문서 생성 성공”으로 두면 너무 이르다.

기록용 채널에 같은 점수를 매기면 무엇이 왜곡될까

실시간 대응이 아닌 기록용 채널에 실시간 대응 점수를 매기면 당연히 낮은 점수가 나온다. 역할 선언도 없고, 상태 업데이트도 없고, 복구 의사결정도 없기 때문이다.

이 점수를 다른 실시간 장애와 평균 내면 지표가 왜곡된다. 반대로 “기록용이니 평가하지 않는다”로 끝내면 그 기록이 쓸모 있는지는 알 수 없다.

채널의 성질을 먼저 구분해야 한다.

기록 전용 채널에는 다른 질문을 해야 한다.

• 발생 시각과 영향 범위가 남아 있는가
• 증상과 원인이 구분돼 있는가
• 어떤 결정을 왜 했는지 알 수 있는가
• 완화 방법과 롤백 방법이 재사용 가능한가
• 관련 서비스와 외부 의존성이 표시돼 있는가
• 후속 조치에 담당자와 완료 조건이 있는가
• 다음 장애에서 검색할 표현이 포함돼 있는가
• 원문 대화와 모니터링 근거로 돌아갈 수 있는가

실시간 대응이 없어서 낮은 점수를 받은 기록과, 핵심 정보가 빠져서 쓸 수 없는 기록은 서로 다른 실패다.

검색은 장애 제목이 아니라 증상에서 시작한다

과거 장애 기록의 제목은 원인을 알고 난 뒤 붙인 이름인 경우가 많다. 하지만 새로운 장애를 처음 보는 사람은 원인을 모른다.

과거 기록 제목
  "외부 CI 제어면 장애로 인한 배포 중단"

현재 사람이 검색하는 말
  "workflow가 queued에서 안 움직임"
  "배포 버튼 눌렀는데 시작 안 함"
  "runner는 살아 있는데 job이 안 잡힘"
  "PR check pending"

제목과 근본 원인(root cause)만 저장하면 이런 검색어와 잘 연결되지 않는다.

장애 기록에는 최소한 다음 메타데이터가 필요하다.

incident_id: stable-id
occurred_at: timestamp
detected_at: timestamp
resolved_at: timestamp
services: []
external_dependencies: []
symptoms: []
customer_impact: none-or-description
internal_impact: []
severity: level
status: resolved
owners: []
mitigations: []
rollback: []
root_causes: []
followups: []
search_terms: []
related_incidents: []
source_links: []

특히 symptoms, internal_impact, external_dependencies, mitigations가 중요하다. 다음 장애가 발생했을 때 가장 먼저 검색하게 되는 정보이기 때문이다.

의미 기반 검색을 추가하면 표현이 다른 기록도 찾기 쉬워진다. 하지만 임베딩(embedding)만 믿으면 서비스명·날짜·심각도·담당자에 대한 정확한 필터링이 약해질 수 있다. 구조화된 필터와 원문 검색을 기본으로 두고, 의미 기반 검색은 후보를 넓히는 역할로 사용하는 편이 안전하다.

검색 결과도 문서 목록만 보여줘서는 부족하다.

유사 장애 3건
1. 공통 증상: job이 queued 상태에서 시작되지 않음
2. 당시 영향: 배포와 PR 필수 검증 중단
3. 당시 판단: 외부 상태 페이지 확인 후 배포 동결
4. 사용한 완화: 기존 정상 산출물(artifact) 재배포
5. 다른 점: 당시에는 Git push와 API가 정상

왜 비슷하다고 판단했는지와 이번 장애에서 먼저 확인해야 할 차이를 함께 보여줘야 한다.

쌓인 기록이 지식이 되려면 검토가 필요하다

Google SRE의 사후 분석(postmortem) 문화 문서는 검토되지 않은 사후 분석은 사실상 존재하지 않는 것과 같다고 표현한다. 기록이 완성되려면 초안 작성 뒤에 검토, 공유, 저장소 편입과 후속 조치가 이어져야 한다.

자동 생성된 기록도 마찬가지다. Slack 대화를 요약해 문서를 만들었다고 해서 모든 내용이 사실로 확정되는 것은 아니다.

• 타임라인 순서가 정확한가
• 추정과 확인된 원인이 구분됐는가
• 고객 영향과 내부 영향이 과장되거나 누락되지 않았는가
• 대응 중 번복된 결론이 최종 원인처럼 남지 않았는가
• 후속 조치가 “주의한다” 같은 문장으로 끝나지 않았는가
• 민감한 사용자 정보와 인증 정보가 제거됐는가

자동화는 초안을 빠르게 만든다. 사람은 사실관계와 책임 범위를 확정한다.

기록에는 상태가 필요하다.

draft
-> reviewed
-> indexed
-> shared
-> follow-ups-tracked
-> superseded 또는 archived

draft와 reviewed가 검색 결과에서 동일한 신뢰도로 취급되면 잘못된 과거 판단이 다음 대응에 재사용될 수 있다. 검색 결과에는 기록의 검토 상태와 마지막 갱신일이 함께 보여야 한다.

전파는 모두에게 알리는 일이 아니다

장애 기록을 전사 채널에 한 번 공유했다고 전파가 끝나는 것은 아니다. 대부분의 사람은 모든 장애 문서를 계속 읽을 수는 없다.

전파는 지식이 필요한 곳으로 보내는 일이다.

• 해당 서비스 담당 팀
• 같은 외부 의존성을 사용하는 팀
• 동일한 배포·인증·데이터 경로를 공유하는 팀
• 당직 담당자(on-call)와 장애 대응 책임자(incident commander)
• 해당 런북의 소유자
• 유사한 후속 조치를 가진 플랫폼 팀

예를 들어 외부 CI 장애로 여러 서비스의 배포가 막혔다면, 단순히 “외부 서비스 장애가 있었다”는 회고를 공유하는 것으로 부족하다.

각 팀은 다음을 알아야 한다.

• 자신의 필수 워크플로 중 무엇이 같은 제어면에 묶여 있는가
• 고객 장애 중 롤백이나 핫픽스가 가능한가
• 외부 상태 페이지를 누가 추적하는가
• 어떤 조건에서 배포 동결을 선언하는가
• 복구 뒤 대기 중인 워크플로를 어떤 순서로 정리하는가
• 별도의 개선 작업이 필요한가

좋은 전파는 읽을 문서를 하나 더 보내는 것이 아니라 각 팀의 다음 행동을 바꾼다.

기록은 다음 장애의 시작 화면으로 돌아와야 한다

사후 기록 저장소와 실시간 대응 도구가 분리돼 있으면 과거 지식은 대응 중에 자동으로 드러나지 않는다. 사람이 검색을 기억해야만 한다.

이 연결을 자동화할 수 있다.

알림 또는 수동 장애 선언
-> 서비스·증상·외부 의존성 추출
-> 유사 장애와 관련 런북 검색
-> 담당 당직자와 역할 후보 제시
-> 확인할 항목과 과거 완화 방법 표시
-> 실시간 채널과 기록 문서 연결

여기서 AI가 할 수 있는 일은 많다.

• 긴 타임라인 요약
• 증상과 영향 후보 추출
• 유사 기록 검색
• 후속 조치 중복 탐지
• 역할 누락과 상태 업데이트 지연 알림

하지만 AI가 장애 여부와 심각도를 단독으로 결정하게 해서는 안 된다. 고객 영향이 없더라도 긴급 배포 능력을 잃은 상황처럼 조직마다 판단 기준이 다른 사건이 있다. 자동화는 근거와 후보를 보여주고, 선언과 종료는 책임자가 승인해야 한다.

훈련을 백 번 해도 실전이 시작되지 않는 이유

훈련은 역할과 절차를 익히는 데 필요하다. 하지만 실제 장애 신호가 훈련한 대응 절차로 연결되지 않으면 사람은 배운 역할을 시작할 기회조차 얻지 못한다.

훈련에서 존재하는 것
  - 명확한 시작 선언
  - 준비된 시나리오
  - 지정된 역할
  - 종료 조건

실전에서 자주 빠지는 것
  - 이 상태를 누가 장애 후보로 올리는가
  - 고객 영향이 없을 때도 누가 추적하는가
  - 외부 의존성 장애의 담당 팀은 누구인가
  - 언제 단순 모니터링에서 장애 대응으로 전환하는가
  - 다음 상태 공유 시각은 언제인가

훈련이 부족해서가 아니라 훈련과 실전 사이의 대응 시작 경로(activation path)가 없어서 대응이 시작되지 않을 수 있다.

외부 플랫폼 장애로 배포가 멈췄지만 고객 영향이 아직 없다면 반드시 높은 심각도의 장애를 선언해야 한다는 뜻은 아니다. 대신 최소한 다음 상태는 명시돼야 한다.

상태: 모니터링
영향: 신규 배포와 일부 PR 검증 중단
고객 영향: 현재 확인되지 않음
담당자: 외부 상태와 내부 영향 추적
대응 기준: 긴급 배포 필요 또는 영향 확산 시 장애 대응 전환
다음 업데이트: 정해진 시각

아무 선언도 없는 침묵과, 영향이 제한적이라 모니터링하기로 한 결정은 다르다. 후자는 책임자와 다음 판단 시점을 남긴다.

기록 시스템의 성과를 무엇으로 볼까

문서 수, 평균 글자 수, 자동 평가 점수만 보면 기록 시스템은 금방 성공한 것처럼 보인다. 하지만 이런 수치는 다음 장애 대응이 빨라졌는지 알려주지 않는다.

더 직접적인 질문이 필요하다.

검색

• 당직 담당자가 증상만으로 유사 장애를 몇 분 안에 찾았는가
• 상위 검색 결과에 실제로 도움이 된 기록이 포함됐는가
• 원문과 근거 링크까지 이동할 수 있었는가

재사용

• 새로운 장애 채널에서 과거 기록이 링크됐는가
• 과거 완화 방법이나 런북이 실제로 사용됐는가
• 검색 결과가 잘못돼 무시된 이유는 무엇인가

전파

• 같은 의존성을 가진 팀이 결과를 받았는가
• 공유 뒤 런북, 알림, 설계가 바뀌었는가
• 읽기만 하고 끝난 기록은 몇 개인가

실행

• 후속 조치에 담당자와 기한이 있는가
• 재발 방지 작업이 완료됐는가
• 완료된 작업이 실제 위험을 줄였는지 검증했는가

활성화

• 선언 조건을 만족한 사건에 담당자가 배정됐는가
• 모니터링 상태라도 다음 업데이트 시점이 정해졌는가
• 훈련에서 검증한 절차가 실전에서도 호출됐는가

결국 가장 중요한 지표는 기록이 다음 장애에서 다시 사용됐는가다.

작은 도구라면 여기까지가 MVP다

장애 기록 자동화를 처음부터 거대한 지식 시스템으로 만들 필요는 없다. 다만 다음 흐름은 있어야 한다.

1. 채널 유형을 실시간 대응·훈련·기록 전용으로 구분한다.
2. 공통 메타데이터 스키마로 기록을 정규화한다.
3. 자동 초안 뒤 담당자의 검토 상태를 표시한다.
4. 증상과 영향으로 검색할 수 있게 한다.
5. 관련 팀과 런북 소유자에게 결과를 전파한다.
6. 후속 조치의 담당자와 완료 상태를 추적한다.
7. 새 장애가 시작될 때 유사 기록을 다시 제시한다.
8. 실제로 재사용된 기록과 실패한 검색을 측정한다.

여기까지 연결되지 않는다면 자동 문서 생성의 정확도를 더 높이기 전에 사용 흐름부터 다시 봐야 한다.

기록의 완료 조건

장애 기록은 필요하다. 실시간 채널은 빠르게 흘러가고, 대응 중의 판단은 나중에 기억과 다르게 재구성되기 쉽다. 타임라인과 근거를 보존하지 않으면 같은 문제를 처음부터 다시 조사하게 된다.

하지만 기록을 남겼다는 사실만으로 조직이 학습한 것은 아니다.

저장됐다
-> 검토됐다
-> 검색된다
-> 관련 팀에 전달된다
-> 후속 조치가 실행된다
-> 다음 장애에서 다시 사용된다

이 흐름을 끝까지 통과해야 기록이 대응 자산이 된다.

장애 훈련을 반복해도 실제 신호가 선언 조건과 담당자에게 연결되지 않으면 대응은 시작되지 않는다. 사후 분석 기록이 많이 쌓여도 다음 사람이 찾지 못하면 같은 조사를 반복한다. 자동 평가 점수가 정교해도 그 결과가 런북과 알림을 바꾸지 않으면 행동은 그대로다.

장애 기록의 출력은 문서다. 장애 기록 시스템의 성과는 다음 장애에서 달라진 행동이다.

참고 자료

• Google SRE: Managing Incidents
• Google SRE: Postmortem Culture, Learning from Failure
• Google SRE Workbook: Postmortem Culture
• PagerDuty Incident Response: Postmortem Process