장애 사후분석에서 가장 먼저 봐야 할 것은?

타임라인의 정확도, 근본 원인과 유발 요인의 구분, 그리고 폭발 반경(blast radius)의 추정이다. 이 세 가지가 선명해야 재발 방지 조치의 우선순위와 구체 내용이 결정된다.

사후분석은 "무엇이 깨졌다"라는 증상에서 출발해 "그것이 왜, 어떤 연쇄 로직으로 깨졌다"는 경로를 시간 순서대로 복원하고, 그 경로 위에서 인과관계를 끊을 수 있는 지점을 찾는 작업이다. 단순히 오류 메시지를 수집하는 것은 사후분석이 아니다. 다음 판단 축들이 명확해질 때까지 가설을 세우고 기각해야 한다.

타임라인은 어느 정도 세밀해야 한다는 건가?

감지 시각(detection)과 영향 시작 시각(blast initiation)의 차이를 분(분 단위)으로 구분할 수 있어야 한다. 많은 팀이 "오류가 터진 시점"으로만 기록하는데, 실제로는 그 오류가 프로덕션에 영향을 미친 시각이 먼저일 수 있다.

구체적으로는:

  • 변경 적용 시각 (배포, 설정 변경, 의존성 업그레이드)
  • 첫 오류 로그 (애플리케이션 수준 감지)
  • 감시 알림 발화 (모니터링 시스템이 임계값 초과 감지)
  • 영향 확대 시작 (캐시 고갈, 연쇄 재시도, 타임아웃 폭주)
  • 사람의 개입 시작 (온콜 엔지니어가 호출되고 조사 착수)
  • 완화 조치 (트래픽 차단, 롤백, 서킷브레이커 활성화)
  • 완전 복구 (모든 메트릭이 정상 범위로)

이 지점들을 정확히 기록해야 MTTR(평균 복구 시간), 감지 지연, 대응 지연을 각각 평가할 수 있다. 예를 들어 변경 적용부터 영향 시작까지 10초인데 감시 알림은 3분 후에 나왔다면, 감시 설정의 지연(evaluation window, aggregation lag)이 문제일 가능성이 있다.

근본 원인과 유발 요인을 어떻게 구분한다는 건가?

근본 원인(root cause)은 "그게 없었으면 장애가 일어나지 않았을 조건", 유발 요인(trigger)은 "그 조건을 활성화한 사건"이다.

예를 들어, 데이터베이스 커넥션 풀이 소진되어 서비스가 응답하지 않았다고 하자.

  • 근본 원인 후보들:

    • 풀 크기가 예상 부하에 충분하지 않게 설정됨
    • 커넥션 누수 (반환되지 않는 커넥션)
    • 데이터베이스 쿼리 성능 저하로 커넥션 점유 시간이 길어짐
    • 업스트림 서비스의 부하 증가로 동시 요청이 급증

  • 유발 요인 후보들:

    • 신규 배포로 인해 쿼리 패턴이 변경됨
    • 특정 지역 이벤트로 트래픽이 10배 증가
    • 데이터베이스 인덱스 손상으로 느린 쿼리 발생
    • 정기 백업 작업이 락을 유지하며 진행 중

가설 기각 과정에서는 로그, 메트릭, 데이터베이스 슬로우 쿼리 로그, 배포 기록, 트래픽 그래프 등을 시간순으로 대조한다. 각 후보마다 "만약 이게 원인이었다면, 어떤 신호가 보여야 하는가?"를 명시한 후 그 신호를 찾아본다. 신호가 없으면 그 가설을 기각한다.

중요한 건 근본 원인이 여러 개일 수 있다는 점이다. 풀 크기가 작았고 동시에 커넥션 누수가 있었고, 동시에 새 배포가 느린 쿼리를 도입했다면, 셋 다 근본 원인이다. 이 경우 우선 제거 비용과 재발 확률을 함께 고려해 재발 방지 조치를 설계한다.

폭발 반경은 왜 중요한가?

폭발 반경이 작으면 같은 근본 원인이 있어도 피해 규모가 다르고, 따라서 재발 방지 투자 수준이 달라진다.

폭발 반경은 다음 차원에서 평가한다:

  • 고객 수: 전체 대비 몇 %가 영향받았나
  • 기능 범위: 특정 엔드포인트만, 아니면 전체 서비스인가
  • 지역 범위: 특정 가용성 존(AZ)만, 아니면 멀티리전까지 영향받았나
  • 시간 범위: 5분 vs 1시간
  • 연쇄 영향: 이 서비스 장애가 다운스트림 서비스 장애를 유발했나

예를 들어 API 게이트웨이의 메모리 누수로 1AZ의 인스턴스 3개가 OOM(Out of Memory)으로 종료되었다면, 나머지 AZ는 정상이므로 폭발 반경은 1/3 정도다. 하지만 로드밸런서가 교대로 재시도하면서 나머지 인스턴스들이 과부하를 받으면 폭발 반경이 전체로 확대될 수 있다.

폭발 반경이 좁을수록 같은 근본 원인도 수용(tolerance)할 여지가 있다. 예를 들어 배치 작업의 메모리 누수는 주간 재시작으로 관리하는 게 정상이지만, 프로덕션 API 게이트웨이의 누수라면 즉시 수정해야 한다. 폭발 반경을 모르면 이 우선순위를 정할 수 없다.

SLO와 에러버짓으로 복구 우선순위를 어떻게 정하는가?

SLO(Service Level Objective)는 "이달 동안 이 서비스는 99.9% 가용성을 목표로 한다"는 선언이고, 에러버짓은 "그 목표를 달성하기 위해 허용되는 다운타임"이다.

2026년 기준, 대부분의 클라우드 네이티브 서비스는 SLO를 분기 단위(또는 월 단위)로 책정한다. 예를 들어:

  • 99.0% SLO = 월 약 7시간 허용 다운타임
  • 99.9% SLO = 월 약 43분 허용 다운타임
  • 99.99% SLO = 월 약 4.3분 허용 다운타임

이달 이미 20분의 에러버짓을 소진했다면, 남은 23분 안에 일어날 수 있는 장애에 대비해야 한다. 이는 다음을 의미한다:

  1. 예정된 정비(planned maintenance)를 연기하거나 더 보수적으로 진행한다 (배포 승인이 까다로워진다).
  2. 카나리 배포, 기능 토글 같은 저위험 배포 방식을 강제한다.
  3. 더 공격적인 자동 복구(auto-remediation) 규칙을 활성화한다.

가설 기각 과정에서도 에러버짓을 고려한다. 어떤 모니터링 임계값을 1초에서 10초로 완화할지 판단할 때, "이 변경으로 월간 에러버짓이 몇 분 줄어드는가"를 계산하면 비용-편익을 정량화할 수 있다.

재발 방지 조치는 어떤 카테고리로 나눠 정리한다는 건가?

재발 방지 조치(corrective action)는 즉시 / 단기 / 장기로 구분하거나, 기술 / 프로세스 / 감시로 구분하는 게 일반적이다. 둘을 조합하면 더 명확하다:

타입 예시
즉시 기술 롤백(이미 했음), 서킷브레이커 임계값 변경, 캐시 플러시
즉시 프로세스 온콜 에스컬레이션 정책 재검토, 보고 주기 단축
단기 기술 커넥션 풀 크기 증가, 슬로우 쿼리 인덱싱, 타임아웃 값 조정
단기 감시 새로운 대시보드 추가, 알림 규칙 정의, SLI(Service Level Indicator) 추가
장기 기술 아키텍처 재설계(예: 마이크로서비스 분리), 데이터베이스 샤딩
장기 프로세스 배포 검증 자동화 강화, 카오스 엔지니어링 도입, 변경관리 거버넌스 정립

각 조치는 다음 세 가지를 명시해야 한다:

  1. 소유자: 누가 이 조치를 수행할 책임이 있나
  2. 완료 기한: 언제까지 완료해야 하나 (즉시는 48시간 내, 단기는 1개월 내, 장기는 분기 단위)
  3. 검증 방법: 조치가 정말 효과가 있었는지 어떻게 확인할 것인가

사후분석을 작성할 때 자주 빠뜨리는 건 뭔가?

반사실적 질문(counterfactual)"이 빠진다. 많은 사후분석은 "이게 일어났다"와 "우리가 이렇게 고쳤다"로만 끝난다.

하지만 중요한 건 "만약 우리가 이미 X를 했었다면, 이 장애가 일어났을까?"이다. 예를 들어:

  • "만약 우리가 이미 느린 쿼리 자동 감지를 켜둔 상태였다면, 배포 후 1분 내에 감지했을까?"
  • "만약 우리가 이미 데이터베이스 커넥션 풀 메트릭을 모니터링했다면, 폭발 반경을 어디까지 막을 수 있었을까?"

이 질문들의 대답은 재발 방지 조치의 투자 순위를 정한다. 감지 지연이 최대 문제였다면 감시에 투자하고, 복구 지연이 문제였다면 자동화에 투자한다.

또한 많은 팀이 인적 오류만 언급하고 시스템 설계 문제를 간과한다. "엔지니어가 잘못된 변수를 설정했다"는 근본 원인이 아니다. 진짜 근본 원인은 "그 변수가 잘못된 값으로 설정되는 것을 방지하는 검증 로직이 없었다"다. 전자는 인간 문제(훈련, 체크리스트)로, 후자는 시스템 문제(설계, 자동화)로 본다.

핵심 정리

  • 타임라인은 변경·감지·영향·대응·복구 각 시점을 분 단위로 기록해야 감지/대응 지연의 근본 원인을 찾을 수 있다.

  • 근본 원인(조건)과 유발 요인(사건)을 구분하고, 각 가설에 대해 "보여야 할 신호"를 명시한 후 로그·메트릭으로 검증하거나 기각한다.

  • 폭발 반경(고객 수, 기능, 지역, 시간, 연쇄 영향)이 같은 근본 원인도 재발 방지 투자 수준을 크게 좌우한다.

  • SLO와 에러버짓을 기반으로 이달의 회복 전략을 조정한다. 에러버짓이 소진되면 배포 정책을 강화하고 자동 복구를 활성화한다.

  • **재발 방지 조치는 (즉시/단기/장기) × (기술/프로세스/감시)**로 행렬화하고, 각 조치마다 소유자·기한·검증 방법을 명시한다.

  • 반사실적 질문("만약 우리가 이미 X를 했다면?")으로 감시·자동화·설계 중 어디에 투자할지 우선순위를 정한다.

  • 인적 오류 뒤에 숨은 시스템 문제(검증 부재, 설정 가능성 노출 등)를 찾아야 같은 문제가 다른 누군가에게 재발하는 것을 방지할 수 있다.

자주 묻는 질문

장애가 진행 중일 때 사후분석을 시작해도 되나?

아니다. 진행 중인 장애에서는 타임라인의 정보가 불완전하고, 스트레스 상황에서 기억에 의존하면 오류가 늘어난다. 복구가 완료되고 최소 수 시간이 지난 후, 차분한 마음으로 시작해야 한다. 다만 진행 중 채팅·로그·메트릭은 실시간으로 수집해둬야 나중에 타임라인을 정확히 복원할 수 있다.

가설 기각에 필요한 근거가 없으면 어떻게 하나?

그 근거를 수집하는 것 자체가 재발 방지 조치가 된다. 예를 들어 "데이터베이스 커넥션 풀 고갈이 원인일 수도 있다"고 의심되지만 풀 메트릭을 기록하지 않았다면, 풀 메트릭 로깅을 추가하는 것이 즉시 기술 조치가 된다. 추측이 아니라 다음에는 근거로 판단할 수 있게 된다.

사후분석 문서를 공개해야 하나?

조직 문화에 따라 다르다. 투명성을 중시하는 팀은 고객에게도 공개한다. 다만 보안 정보(실제 계정명, API 키 패턴 등)는 숨기고, 기술적 원인과 재발 방지 계획은 명확하게 남긴다. 내부 용도라도 표준 템플릿을 사용해 형식을 일관되게 유지하면 시간이 지나 패턴을 분석할 수 있다.

재발 방지 조치의 효과를 어떻게 측정하나?

같은 원인으로 다시 장애가 일어나면 조치가 실패한 것이다. 하지만 장애가 일어나지 않으면 인과관계를 증명하기 어렵다. 따라서 (1) 조치 전후 같은 신호(예: 느린 쿼리 수)가 줄었는지, (2) 같은 상황을 의도적으로 만들어 자동 복구가 작동하는지(카오스 테스트)를 검증한다.

여러 팀이 장애에 기여했을 때, 누가 사후분석을 주도하나?

가장 영향받은 팀(서비스 소유자)이 주도하되, 데이터베이스·네트워크·배포 등 각 계층의 담당자가 해당 부분의 타임라인과 가설을 제공해야 한다. 사후분석 미팅은 진행자(moderator)를 두고, 책임 추궁이 아니라 근인 원인 규명에만 집중한다. 책임 문제는 별도 프로세스에서 다룬다.

사후분석 리뷰는 얼마나 자주 해야 하나?

심각도별로 다르다. 고객 영향이 큰 장애(P1)는 배포 후 1주일 내 추적 미팅을 갖고, 조치 진행도를 확인한다. 중간 정도(P2)는 월 1회, 경미한(P3)는 분기 1회 정도면 충분하다. 다만 같은 원인의 반복 장애가 2회 이상 나타나면 즉시 심각도를 올려 검토한다.

사후분석을 쓴 후 팀의 태도가 방어적으로 변했다면?

사후분석이 "누가 실수했는가"를 찾는 도구로 인식되고 있다는 뜻이다. 이를 바꾸려면 경영진이 명확히 선언해야 한다: "사후분석은 시스템을 개선하는 도구이지, 사람을 평가하는 도구가 아니다." 실제로 사후분석에서 나온 기술 조치가 배포되고 평가될 때, 팀의 신뢰가 회복된다.