장애 사후검토에서 학습 신호를 복원하는 질문 설계

1. ‘실수한 사람’을 찾는 순간 왜 다음 장애의 단서가 사라질까?

서비스 장애 뒤에는 빠르게 설명을 만들고 싶은 압력이 생긴다. 고객 영향, 경영 보고, 야간 대응의 피로가 겹치면 “변경을 승인한 사람은 누구인가”, “왜 확인하지 않았는가”처럼 개인에게 향하는 질문이 가장 짧은 설명처럼 보인다. 그러나 이 질문은 사건의 원인을 찾기보다, 이미 결과를 아는 사람이 과거의 선택을 평가하는 경로가 되기 쉽다. 결과를 알고 난 뒤에는 위험 신호가 명백해 보이지만, 당시 담당자가 볼 수 있던 대시보드·알림·런북·배포 속도·권한은 지금과 같지 않았다.

SRE의 블레임리스 사후검토 원칙은 책임을 지우자는 뜻이 아니다. 사람이 당시 가진 정보와 도구, 업무 압박, 시스템의 기본값 안에서 왜 그렇게 행동했는지를 설명할 수 있어야 재발 방지의 표면적을 넓힐 수 있다는 뜻이다. “누군가 설정을 잘못 바꾸었다”로 끝나면 대응자는 다음에도 더 조심하라는 요구만 받는다. 반대로 “변경 영향 범위를 보여 주는 프리뷰가 없었고, 롤백 런북은 권한이 없는 계정에서는 실행되지 않았으며, 알림은 오류율이 아니라 고객 영향 뒤에 발생했다”라고 쓰면 제품·권한·관측성·절차를 바꿀 지점이 생긴다.

그렇다면 심리적 안전감을 추상적인 태도로 남기지 않고, 실제 증거가 더 많이 나오게 하는 회의 구조는 어떻게 만들 수 있을까? 첫 단계는 사건의 이야기를 원인으로 압축하지 않는 것이다.

2. ‘원인은 하나’라는 결론을 미루려면 어떤 시간선을 만들어야 할까?

사후검토의 가장 중요한 산출물은 매끄러운 원인 서사가 아니라, 검증 가능한 사건 시간선이다. 시간선은 최소한 네 개의 흐름을 나란히 둔다. 첫째는 서비스에서 실제로 일어난 변화다. 배포, 설정 변경, 의존성 지연, 큐 적체처럼 측정 가능한 이벤트를 적는다. 둘째는 고객 영향이다. 오류율, 지연 시간, 결제 실패, 기능 사용 불가가 언제부터 어느 범위에 나타났는지 구분한다. 셋째는 탐지다. 자동 알림, 고객 문의, 내부 관측 중 무엇이 먼저 문제를 드러냈는지 기록한다. 넷째는 대응이다. 누가 어떤 대시보드를 보고 어떤 가설을 세웠고, 어떤 조치 뒤에 지표가 변했는지를 남긴다.

시간        10:02          10:07              10:11              10:18
사건        설정 배포      의존성 지연 증가   오류율 경보 발생    롤백 완료
고객 영향   일부 요청 지연  결제 실패 시작     실패 범위 확대      점진적 회복
탐지        -             대시보드 미확인     온콜 알림           고객 문의 감소
대응        -             -                   트래픽 우회 가설    롤백·캐시 제거

각 칸에는 ‘관측 사실’과 ‘해석’을 구분한다.
관측 사실: p99가 10:07부터 상승했다.
해석: 새 설정이 직접 원인이다.
검증 가설: 설정을 이전 값으로 되돌리면 오류율이 10분 내 하락한다.

이 구분이 없으면 상관관계가 곧 원인이 된다. 배포 직후 장애가 시작됐다는 사실은 중요하지만, 배포 내용·트래픽 변화·의존성 상태·캐시 예열 실패가 서로 어떻게 결합했는지는 별도 검증이 필요하다. 반대로 회의 참여자가 말한 “그때 이 알림은 평소에도 자주 떠서 우선순위를 낮게 봤다”는 정보는 변명으로 처리할 내용이 아니다. 알림의 신뢰도와 분류 규칙이 실제 의사결정에 어떻게 작동했는지 보여 주는 운영 데이터다.

여기서 한 걸음 더 들어가야 한다. 시간선이 있다고 해서, 참여자들이 불편한 사실을 자동으로 말하는 것은 아니다. 질문의 형태가 방어적 서술과 관측 가능한 세부사항 사이를 가른다.

3. ‘왜 안 했나?’ 대신 어떤 질문이 정보를 더 끌어낼까?

“왜 확인하지 않았나요?”는 행동이 비합리적이었다는 전제를 담는다. 이런 질문을 받은 사람은 자신의 의도를 증명하거나 책임을 줄이는 설명을 준비하기 쉽다. 같은 장면을 조사하려면 “그 시점에 어떤 신호가 보였나요?”, “무엇을 정상으로 판단하게 한 근거가 있었나요?”, “다른 선택지를 시도하지 못하게 한 제약은 무엇이었나요?”처럼 당시의 의사결정 환경을 묻는다. 답은 사람의 성격이 아니라 시스템의 정보 구조를 향한다.

▲ 사후검토의 핵심 작업은 기억을 평가하는 일이 아니라, 로그·알림·조치의 순서를 함께 재구성하는 일이다.

다음 질문 템플릿은 회의 진행자가 바로 사용할 수 있다.

심리적 안전감은 회의에서 누구도 불편하지 않은 상태와 다르다. 문제를 숨기지 않고 말해도 개인의 능력이나 의도가 단정되지 않는다는 예측 가능성에 가깝다. 그래서 진행자는 발언을 즉시 반박하거나 ‘정답’으로 고정하지 않아야 한다. 서로 다른 기억이 나오면 한쪽을 교정하기보다 로그, 티켓, 채팅 기록, 대시보드 스냅샷으로 확인할 항목에 넣는다. 기억의 불일치는 회의 실패가 아니라 관측 경로가 달랐다는 신호다.

정량 지표도 함께 둔다. 아래 수치는 보편적 성능 수치가 아니라, 팀이 전후 변화를 판정하기 위한 측정 설계 예시다. 한 번의 문서 품질보다 여러 건의 사후검토에서 패턴이 바뀌는지를 보는 편이 중요하다.

하지만 질문만 바꿔서는 충분하지 않다. 회의가 끝난 뒤 조직이 실제로 바꾸는 것이 없다면 다음 사건에서 참여자들은 다시 말을 아끼게 된다. 사후검토의 신뢰는 후속조치가 만든 피드백으로 완성된다.

4. ‘다음부터 주의’가 왜 재발 방지 조치가 될 수 없을까?

개인의 주의력에 기대는 액션 아이템은 장애 조건이 복잡할수록 약하다. 야간·배포 압박·여러 알림·불완전한 정보가 겹치는 순간, 사람은 매번 같은 수준의 확인을 수행할 수 없다. 따라서 후속조치는 기억을 더 요구하는 방향이 아니라, 위험한 행동이 어렵고 안전한 행동이 쉬워지는 방향으로 설계해야 한다.

예를 들어 “배포 전에 설정을 한 번 더 확인한다”는 조치 대신, 변경 영향 범위를 보여 주는 diff 프리뷰와 고위험 설정의 2인 승인 규칙을 추가할 수 있다. “알림을 빨리 본다” 대신, 고객 영향 지표와 의존성 오류를 한 경보에 연결하고 런북 첫 화면에 우회·롤백 권한을 명시할 수 있다. “장애 대응을 숙지한다” 대신, 분기마다 의존성 지연과 권한 실패를 주입해 런북이 실제 계정과 환경에서 작동하는지 확인한다.

후속조치의 우선순위는 영향도와 실행 난이도만으로 정하지 않는다. 탐지 이전에 막을 수 있는가, 고객 영향 전에 격리할 수 있는가, 복구 시간을 단축하는가, 대응자의 인지부하를 줄이는가를 함께 본다. 이 기준은 작은 UI 개선이나 런북 정리가 인프라 교체보다 먼저 선택되는 이유도 설명한다. 가장 값비싼 해결책이 아니라, 다음 의사결정에서 더 나은 정보를 제공하는 해결책이 먼저일 수 있다.

5. ‘다음 검토부터 바꾸려면?’ 3단계 운영 로드맵

사후검토가 성숙한 조직은 장애가 없어서 조용한 조직이 아니다. 작은 실패와 불편한 신호가 개인의 평판 위협 없이 시스템 데이터로 바뀌는 조직이다. 그때 ‘비난 없음’은 친절한 회의 규칙을 넘어, 누락된 관측치를 더 많이 얻고 다음 대응의 선택지를 넓히는 엔지니어링 역량이 된다.

사람에게 더 조심하라고 요구하는 시스템은 같은 압박에서 같은 실패를 반복한다. 더 나은 사후검토는 사람의 기억을 심문하지 않고, 다음에는 더 안전하게 행동할 수 있는 환경을 만든다.

공식 참고 자료

• Google SRE Book — Postmortem Culture
• Google SRE Workbook — Postmortem Culture
• Google re:Work — Understand team effectiveness