책임 추궁 없는 회고

Blameless Postmortem

관행

사고를 되짚을 때 누가 잘못했는지 대신 어떤 구조가 그 실수를 통과시켰는지를 찾아 고치는 회고 방식입니다.

등장 배경

장애가 나면 가장 먼저 나오는 질문은 오래도록 "누가 그랬어요" 였습니다. 원인을 사람 하나로 좁히면 조치도 간단해 보입니다. 그 사람을 주의 주고, 다음부터 조심하기로 하고, 회의를 끝냅니다. 회의록에는 담당자 교육이라는 한 줄이 남고 몇 달 뒤 같은 장애가 다시 납니다.

문제는 그 다음부터 벌어집니다. 한 번 불려 나가는 자리를 본 사람은 다음 사고에서 자기가 무엇을 눌렀는지 정확히 적지 않습니다. "설정을 변경했습니다" 처럼 뭉뚱그린 문장이 기록에 남고, 그런 기록에서는 왜 그 설정이 확인 없이 바뀔 수 있었는지가 끝내 드러나지 않습니다. 사고를 가장 가까이서 본 사람이 입을 닫는 것이 이 방식의 실제 비용입니다.

페이지덱도 한 번 겪었습니다. 금요일 저녁 배포 뒤 문서 저장이 30분간 막혔고, 월요일 회의에서 태오가 자기가 설정을 잘못 건드렸다고 말하면서 논의가 거기서 끝났습니다. 두 달 뒤 다른 사람이 같은 설정을 같은 방식으로 건드려 같은 장애가 났을 때에야, 그 설정에 검토 절차도 되돌리기 버튼도 없다는 사실이 안건에 올랐습니다.

진행 순서

사람 이름을 지우고 시간부터 세우는 것으로 시작합니다. 몇 시 몇 분에 무엇이 일어났는지를 줄줄이 적고, 그 위에서 판단이 갈린 지점을 찾아 내려갑니다. 순서는 대개 다섯 단계입니다.

  1. 시간 순 기록을 만듭니다. 배포 시각, 오류가 처음 찍힌 시각, 알림이 울린 시각, 사람이 알아챈 시각, 복구된 시각을 분 단위로 적습니다. 오류가 21시 04분에 시작됐는데 온콜 당번이 21시 38분에 알아챘다면, 그 34분이 이 사고의 절반입니다.
  2. 각 시점에 그 사람에게 무엇이 보였는지를 복원합니다. 지금 와서 보면 뻔한 원인도 그때 화면에는 없었을 수 있습니다. 결과를 아는 상태로 과거를 판단하지 않기 위한 단계입니다.
  3. 왜 그 행동이 그 순간에는 합리적이었는지 묻습니다. 답이 나오지 않으면 대개 2번에서 복원이 덜 된 것입니다. 이 질문이 "왜 그렇게 했어요" 와 다른 점은 답하는 사람을 변명하는 자리에 세우지 않는다는 데 있습니다.
  4. 근본 원인 분석으로 내려갑니다. 증상이 아니라 그 뒤의 조건을 찾는 작업입니다. 설정을 잘못 건드렸다는 답에서 멈추지 않고, 그 설정이 왜 확인 없이 바뀔 수 있었는지, 왜 바뀐 직후에 아무 알림도 울리지 않았는지까지 내려갑니다.
  5. 액션 아이템을 적습니다. 담당자와 기한까지 붙은 후속 조치인데, 여기서 문장 형태가 결과를 가릅니다. 조심하겠다는 문장은 사람의 주의력에 기대는 것이라 다음 사고를 막지 못합니다. 설정 변경에 승인 단계를 붙이는 일처럼 사람이 실수해도 통과되지 않게 만드는 조치를 적습니다.

참여자와 시점

대응에 직접 관여한 사람이 모두 들어옵니다. 당번, 코드를 배포한 사람, 연락을 받고 합류한 사람, 고객 문의를 받은 쪽까지입니다. 진행은 그 사고에 관여하지 않은 사람이 맡습니다. 관여한 사람이 진행까지 하면 자기 판단을 설명하는 데 시간을 쓰게 되고, 기록은 그만큼 한쪽으로 기웁니다.

인사 평가 권한을 가진 사람이 그 자리에 앉는지가 실제로 결과를 가릅니다. 평가에 쓰일 수 있다고 느끼면 아무리 규칙을 붙여도 사람은 방어적으로 말합니다. 대표나 팀장이 들어와야 한다면 그 자리에서 무엇을 듣기만 할지를 미리 정해 두고 시작합니다.

시점은 복구 직후가 아니라 며칠 뒤입니다. 밤을 새워 복구한 사람에게 그날 회고를 시키면 기억보다 피로가 먼저 말합니다. 반대로 2주를 넘기면 화면과 로그를 본 감각이 사라져 기록이 뭉뚱그려집니다. 보통 사흘에서 닷새 사이에 잡고, 그 사이에 각자 기억나는 것을 문서에 미리 적어 둡니다.

기록은 관여한 사람들만 보는 문서로 두지 않습니다. 전사에 열어 두면 다른 팀이 같은 조건을 자기 쪽에서 미리 찾아냅니다. 이 공개가 가능하려면 문서에 사람 이름이 잘못의 주어로 등장하지 않아야 합니다.

실무 용례

"이건 태오 잘못이 아니라 그 설정이 확인 없이 바뀔 수 있는 구조의 문제입니다."

원인을 사람에서 조건으로 옮기자는 말입니다.

"오늘은 책임 추궁 없이 갑니다. 무엇을 눌렀는지 기억나는 대로 다 적어 주세요."

정확한 기록을 받기 위해 먼저 안전을 보장하는 말입니다.

"액션 아이템에 더 조심하겠다는 못 씁니다. 안 조심해도 되게 고칠 걸 적어 주세요."

사람의 주의력이 아니라 구조를 고치는 조치만 후속으로 인정하겠다는 뜻입니다.

앞서 같은 장애를 두 번 겪은 뒤 페이지덱은 진행 방식을 바꿨습니다. 두 번째 회고에서 규원이 먼저 꺼낸 말은 오늘 이 자리에서 나온 어떤 내용도 평가에 쓰지 않는다는 선언이었고, 진행은 그 주에 휴가였던 지현이 맡았습니다. 태오가 설정 화면을 그대로 띄워 보여 주자 왜 실수가 나왔는지가 곧 드러났습니다. 운영 환경과 테스트 환경의 설정 화면이 글자 하나만 다르고 색까지 같았습니다.

그날 나온 액션 아이템은 셋이었습니다. 운영 환경 화면의 배경색을 바꾸는 것, 설정 변경에 다른 사람의 승인을 붙이는 것, 변경 직후 알림이 울리게 하는 것. 셋 다 사람의 주의력이 아니라 화면과 절차를 고치는 항목이었고, 그 뒤로 같은 장애는 나지 않았습니다.

흔한 오해

아무에게도 책임을 묻지 않는 방식이라고 읽는 경우가 가장 많습니다. 이름에 책임 추궁 없음이 들어가 있으니 자연스러운 오해입니다. 하지만 이 방식이 지우는 것은 개인 처벌이지 책임 자체가 아닙니다. 회고 문서에는 개선 항목마다 담당자와 기한이 남고, 다음 점검에서 그 항목이 처리됐는지를 확인합니다. 처벌이 사라진 자리를 후속 조치가 대신 채우지 않으면 회고는 그냥 위로하는 자리가 되고, 같은 사고가 다음 분기에 돌아옵니다.

좋은 태도만 가지면 저절로 된다는 생각도 흔합니다. 회의 시작에 서로를 탓하지 말자고 한마디 붙이는 것으로 충분해 보이기 때문입니다. 실제로는 진행자를 누구로 두는지, 문서 형식이 사람 이름을 주어로 쓰게 돼 있는지, 심리적 안전감이 평소에 쌓여 있는지가 결과를 가릅니다. 평소에 실수를 말하면 불이익이 오던 팀에서는 그날만 안전을 선언해도 아무도 믿지 않고, 회고는 다시 뭉뚱그린 문장으로 채워집니다.

같이 보면 좋은 페이지

  • 장애 대응

    이 회고가 장애 한 건의 흐름에서 어느 자리에 오는지 봅니다

  • 포스트모템

    회고에서 나온 내용을 어떤 문서로 남기는지 봅니다

  • 심리적 안전감

    이 방식이 작동하려면 평소에 무엇이 쌓여 있어야 하는지 봅니다

마지막 업데이트 2026-09-16