장애 대응은 복구로 끝나지 않는다 ── 소규모 개발팀을 위한 포스트모템(재발 방지)의 틀

「지난달 고쳐주신 것과 같은 오류가 또 다른 화면에서 나왔는데요」──유지보수하고 있는 시스템에서 이런 말을 들었을 때, 할 말이 막힌 경험은 없으신가요.

장애 대응 그 자체, 즉 감지하고, 원인 위치를 특정하고, 고치고, 릴리스하고, 사과한다. 여기까지는 많은 팀이 제대로 해냅니다. 문제는 그 다음입니다. 복구된 순간 모두가 일상 업무로 돌아가고, 장애 기록은 누군가의 메일함과 채팅 로그에 흩어진 채 풍화됩니다. 반년 후, 같은 구조의 장애가 다른 곳에서 재발하고, 또 같은 조사를 처음부터 다시 합니다. 「고치고 사과하고 끝」인 장애 대응은 같은 수업료를 몇 번이고 지불하는 운영입니다.

이 블로그에서는 장애 조사의 기술적 측면으로 「Windows 크래시 덤프 수집 입문」이나 「예외의 catch・로그・에러 처리 실무」에서 「원인에 도달하는 방법」을 설명해 왔습니다. 이 글은 그다음 공정, 즉 원인을 알게 된 후, 같은 장애를 두 번 다시 일으키지 않기 위한 회고(포스트모템)를 어떻게 돌릴 것인가를 다룹니다. 대규모 웹 서비스 이야기가 아니라, 2~5명이 업무 앱・Windows 소프트웨어를 유지보수하는 작은 팀에서 실제로 지속할 수 있는 틀로 좁힙니다.

1. 먼저 결론

• 복구・원인 규명・재발 방지는 별개의 작업입니다. 복구는 「오늘의 업무를 되돌리는 것」, 원인 규명은 「왜 일어났는지 설명할 수 있게 하는 것」, 재발 방지는 「구조를 바꾸는 것」입니다. 섞으면 전부 어중간해집니다.
• 범인 찾기를 하지 않는(blameless) 것은 윤리가 아니라 실리입니다. 개인을 탓하는 자리에서는 정보가 나오지 않게 되어 원인에 도달할 수 없습니다. 「관계자는 가지고 있던 정보의 범위 안에서 올바르게 행동했다」고 가정하고 구조의 구멍을 찾는 것이, SRE에서 정착한 blameless postmortem의 원칙입니다.¹
• 재발 방지책은 「조심한다」가 아니라 구조(코드・테스트・모니터링・절차)로 옮깁니다. 사람의 주의력에 의존하는 대책은 담당자 교체로 사라집니다. 대책의 강도를 판정하는 판단표를 6장에서 제시합니다.
• 원인은 「직접 원인」과 「기여 요인」으로 나눕니다. 고칠 수 있는 것은 대개 기여 요인 쪽으로, 「왜왜 분석」을 사람의 행동에서 멈추지 않고 구조까지 파고드는 것이 요령입니다.
• 모든 장애에 풀 버전 포스트모템을 하지는 않습니다. 영향도×재발 가능성으로 트리아지하고(7장), 경미한 것은 한 단락의 기록만 남깁니다. 지속할 수 있는 분량으로 억제하는 것이 제도를 죽이지 않는 최대의 조건입니다.
• 포스트모템은 1시간이면 쓸 수 있는 분량으로 합니다. 4장에서 최소 템플릿을 제시합니다. 훌륭한 문서를 월 0건 쓰는 것보다, 거친 기록이라도 매번 남기는 쪽이 가치 있습니다.
• 수탁 개발에서는 고객용 장애 보고서와 목적을 분리하면서도, 내용은 포스트모템에서 전용합니다(8장). 책임 추궁 문서와 재발 방지 문서를 섞지 않는 것이 양쪽의 품질을 지킵니다.

2. 왜 같은 장애가 반복되는가

재발하는 장애에는 기술이 아니라 운영의 패턴이 있습니다.

복구된 순간 「끝난」 것이 된다. 장애 대응은 긴급 인터럽트이므로, 복구되면 모두가 밀린 평소 업무로 돌아갑니다. 회고 시간은 누구의 캘린더에도 들어 있지 않고, 「안정되면 하자」는 영원히 오지 않습니다.

보고서가 「앞으로는 충분히 주의하겠습니다」로 끝난다. 고객이나 상사에게 제출하는 보고서의 재발 방지란에 「확인을 철저히 하겠습니다」, 「이중 확인을 실시하겠습니다」라고 써서 마무리합니다. 이 문구는 아무런 구조도 바꾸지 않기 때문에, 주의력이 옅어지는 몇 달 후 같은 구멍에 빠집니다.

개인의 책임으로 돌리고 구조를 고치지 않는다. 「그 사람이 테스트를 건너뛰었으니까」로 정리하면, 테스트를 건너뛸 수 있는 구조(릴리스 절차에 테스트 게이트가 없다, 마감 압박으로 생략이 묵인된다)는 그대로 남습니다. 다음에는 다른 사람이 같은 생략을 합니다.

기록이 남지 않아, 몇 년 후 같은 구멍에 빠진다. 소규모 팀의 유지보수는 「같은 사람이 계속 대응한다」는 바로 그 이유로, 기록이 없어도 당분간은 돌아가 버립니다. 하지만 그 사람의 기억은 몇 년이면 옅어지고, 퇴사나 교체로 사라집니다. 「이 오류, 전에도 본 것 같은데 대처법이 기억나지 않는다」는, 기록이 있었다면 10분이면 끝났을 조사를 하루 종일로 바꿔 놓습니다.

어느 쪽도 능력의 문제가 아니라, 회고가 업무로 정의되어 있지 않다는 것의 귀결입니다. 그렇기 때문에 틀(템플릿과 실시 기준)을 미리 정해 두는 데 가치가 있습니다.

3. 포스트모템이란 ── SRE의 틀을 소규모 유지보수로 옮기다

포스트모템(postmortem)은 인시던트의 기록으로서 영향・근본 원인・대응의 시계열・재발 방지 액션을 문서화하는 회고의 틀로, Google의 SRE(Site Reliability Engineering) 실천을 통해 널리 정착했습니다. 그 핵심이 blameless(비난하지 않는다) 원칙입니다. 「비난 없이 쓰인 포스트모템은, 관계자 전원이 선의로, 그 시점에 가지고 있던 정보에 근거해 올바르게 행동했다고 가정한다」──사람을 벌하는 대신, 올바른 행동을 방해한 구조 쪽을 고칩니다.¹

이 사고방식은 Google 고유의 것이 아니라, Microsoft의 아키텍처 가이던스(Azure Well-Architected Framework)에서도 포스트모템을 「관계된 팀 전원이 참여하는, 구조화된 비난 없는 리뷰」로 정의하고, 근본 원인 분석(RCA)의 결과를 대응 프로세스 개선・감지(가관측성) 강화・설계 개선이라는 형태로 시스템에 환원하는 것을 권장하고 있습니다.²

「우리는 대규모 웹 서비스가 아니니 상관없다」고 생각하기 쉽지만, 필자는 그 반대라고 생각합니다. 고객사 상주 없이 소수 인원으로 데스크톱 앱을 유지보수하는 체제야말로 포스트모템이 효과를 발휘합니다. 이유는 세 가지입니다.

1. 같은 사람이 계속 대응하기 때문에, 기록이 없으면 완전히 특정 인물에게 의존하게 된다. 큰 조직이라면 누군가가 기억하고 있겠지만, 2~3명 규모의 팀에서는 「기억하고 있는 사람」이 유일한 데이터베이스입니다. 포스트모템은 그 외부 기억이 됩니다.
2. 장애 간격이 길다. 웹 서비스와 달리 업무 앱의 중대 장애는 연간 몇 차례뿐입니다. 지난번 대응의 기억이 옅어질 무렵 다음이 찾아오기 때문에, 기록의 가치가 상대적으로 높아집니다.
3. 현장에 갈 수 없는 만큼, 증거와 기록이 생명선이 된다. 원격 유지보수에서는 「그때 무슨 일이 일어나고 있었는가」를 나중에 재구성하는 능력이 전부이며, 이는 포스트모템의 시계열 기록과 맞닿아 있습니다.

덧붙여, 포스트모템을 쓸 대상의 기준으로, SRE 책에서는 사용자에게 보이는 중단이나 데이터 손실, 온콜(긴급 대응)의 개입이 있었던 경우 등이 실시 기준의 예로 제시되고 있습니다.¹ 소규모 팀을 위한 기준은 7장에서 다시 정리합니다.

4. 최소 포스트모템 템플릿

지속하기 위한 가장 중요한 조건은 분량입니다. 초판을 1시간 안에 다 쓸 수 있을 것을 상한으로 설계한 Markdown 템플릿을 제시합니다. 저장소의 docs/postmortem/ 등에 날짜가 붙은 파일로 두고, 코드와 같은 장소에서 버전 관리할 것을 권장합니다.

# 포스트모템: 수주 목록에서 날짜가 걸친 데이터가 이중 표시 (2026-07-15)

- 상태: 완료 / 액션 진행 중 / 등록만 완료
- 작성자: 코무라
- 심각도: 중 (업무는 계속할 수 있었으나 수작업 대조가 발생)

## 개요 (3줄 이내)
월말 마감 처리를 실행하는 중에 수주 목록을 열면, 전날 분의
전표가 이중으로 표시되었다. 표시상의 문제로 DB상의 데이터는 정상.

## 영향 (누가・무엇이・얼마나)
- 영향받은 사람: 영업 사무 3명
- 영향 내용: 목록 화면의 이중 표시. 잘못하여 이중 출고할 뻔한 사례 1건
- 기간: 7/15 9:10경 ~ 11:40 (약 2시간 30분)

## 시계열
- 09:10 이용자로부터 "같은 전표가 2행 나온다"는 전화 (감지)
- 09:30 원격으로 화면 공유, 재현 조건 확인
- 10:15 잠정 대응: 마감 처리 중에는 목록을 열지 않도록 요청
- 11:40 수정판을 배포하고 복구 확인

## 직접 원인
마감 처리가 임시 테이블로 복사한 행을, 목록 쿼리가
본 테이블과 UNION ALL하고 있었다 (배타 제어 없음).

## 기여 요인
- 마감 처리와 화면 참조의 동시 실행이 테스트 시나리오에 없었다
- 임시 테이블의 존재가 설계서에 쓰여 있지 않아, 화면 쪽
  개수 시에 고려되지 않았다
- 이중 표시를 감지하는 구조가 없어, 발견이 이용자에게 의존했다

## 잘된 점
- 이용자가 조작 로그의 시각을 메모해 두어 재현 조건 특정이 빨랐다
- 배포 구조가 자동화되어 있어 수정판을 당일 배포할 수 있었다

## 재발 방지 액션 (담당과 기한)
- [ ] 목록 쿼리에 중복 감지 어서션 추가 (코무라, 7/22)
- [ ] 마감 처리와 참조계의 동시 실행 테스트 추가 (코무라, 7/29)
- [ ] 임시 테이블 방식을 폐지하고 스냅샷 분리를 검토 (코무라, 8월 말에 방침)

그대로 복제해서 쓸 수 있도록, 기입 전 빈 템플릿도 함께 둡니다. 저장소에 docs/postmortem/_template.md로 두고, 장애가 발생하면 날짜가 붙은 이름으로 복사하는 것이 간편합니다.

# 포스트모템: 한 줄로 현상 (YYYY-MM-DD)

- 상태: 등록만 완료 / 액션 진행 중 / 완료
- 작성자:
- 심각도: 상 / 중 / 하 (그렇게 판단한 이유를 한마디로)

## 개요 (3줄 이내)

## 영향 (누가・무엇이・얼마나)
- 영향받은 사람:
- 영향 내용:
- 기간: MM/DD HH:MM ~ HH:MM (약  시간)

## 시계열
- HH:MM  (감지: 누가・무엇으로 알아챘는가)
- HH:MM
- HH:MM  (잠정 대응)
- HH:MM  (복구 확인)

## 직접 원인

## 기여 요인
- (혼입을 허용한 조건)
- (놓친 조건)
- (피해를 키운 조건)

## 잘된 점
-

## 재발 방지 액션 (담당과 기한)
- [ ]  (담당, MM/DD)
- [ ]  (담당, MM/DD)

작성 시 주의할 점을 몇 가지 들겠습니다.

• 「개요」는 3줄 이내. 훗날 이 문서를 찾는 것은 미래의 자신입니다. 검색으로 찾았을 때 3줄로 내용을 알 수 있는 것이, 목차의 아름다움보다 중요합니다.
• 시계열은 사실만을 시각과 함께 쓴다. 해석(~했어야 했다, ~했을 것이다)은 원인 절로 분리합니다. 시계열에 해석이 섞이면, 나중에 읽었을 때 무슨 일이 일어났는지 재구성할 수 없게 됩니다.
• 「잘된 점」을 반드시 쓴다. 회고가 반성회가 되는 것을 막고, 우연히 잘된 일(마침 로그가 있었다 등)을 구조로 승격시키는 입구가 됩니다.
• 액션에는 반드시 담당과 기한을 붙인다. 담당과 기한이 없는 액션은 실행되지 않습니다. 포스트모템의 실효성은 리뷰가 이루어지는 것과 액션이 추적되는 것으로 결정됩니다.¹

5. 원인 분석의 실무 ── 직접 원인과 기여 요인을 나누다

템플릿에서 원인란을 두 개로 나눈 데는 이유가 있습니다.

직접 원인(direct cause)은 그 장애를 직접 일으킨 기술적 사건입니다. 「NULL 체크 누락으로 인한 예외」, 「배타 제어 없는 UNION ALL」. 수정 패치가 고치는 것은 여기입니다.

기여 요인(contributing factors)은 직접 원인의 혼입・간과・피해 확대를 허용한 조건입니다. 「그 케이스의 테스트가 없었다」, 「설계서에 쓰여 있지 않았다」, 「감지가 이용자에게 의존했다」. 재발 방지책의 주된 전장은 이쪽이며, 보통 여러 개 존재합니다.

나누는 이유는 단순한데, 직접 원인만 고쳐도 기여 요인이 남아 있으면 다른 직접 원인이 같은 경로로 들어오기 때문입니다. 첫머리의 「같은 오류가 다른 화면에서」는 바로 이것입니다.

5.1 왜왜 분석은 「사람의 행동」에서 멈추지 않는다

원인을 파고드는 도구로서 「왜왜 분석(5 Whys)」은 유효하지만, 파는 방향을 잘못 잡으면 범인 찾기의 도구가 됩니다. 전형적인 실패는 「왜→담당자가 확인을 잊었기 때문에」에서 멈춰 버리는 것입니다. 거기서 멈추지 않고 한 단계 더 파고듭니다.

• 왜 확인을 잊을 수 있었는가 → 확인이 절차서에도 체크리스트에도 없어, 기억에 의존하고 있었기 때문에
• 왜 기억에 의존했는가 → 릴리스 절차가 문서화되어 있지 않아, 매번 그 자리에서 즉흥적으로 진행했기 때문에

사람의 행동이 답으로 나왔다면, 그것은 종점이 아니라 「구조를 묻는 다음 질문」의 입구입니다. 사람은 반드시 실수한다는 전제에 서면, 파고들어야 할 질문은 「왜 실수했는가」가 아니라 「왜 실수가 그대로 실제 운영 환경까지 도달했는가」로 바뀝니다.

5.2 증거가 없으면 분석은 시작되지 않는다

원인 분석의 질은, 장애 발생 시에 남아 있던 증거의 질로 상한이 정해집니다. 시계열을 재구성할 수 없는 포스트모템은 추측으로 쓴 작문이 됩니다. Windows 앱 유지보수라면, 최소한의 진용은 다음 세 가지입니다.

• 크래시 덤프: WER LocalDumps를 설정해 두면, 이용자에게 조작을 부탁하지 않아도 비정상 종료 시의 덤프가 남습니다. 설정 방법은 「Windows 크래시 덤프 수집 입문」, 읽는 법은 「WinDbg + SOS로 크래시 덤프 읽기」에서 설명하고 있습니다.
• 앱 로그: 시각・상관 지을 수 있는 ID・크리티컬 이벤트의 동기 기록. 크래시 시에도 로그를 확실히 남기는 설계는 「Windows 앱의 크래시 시 로그와 덤프를 남기는 설계」를 참조하십시오.
• 이벤트 로그: 자체 로그가 손상되어 있어도, OS 표준 이벤트 로그에는 앱의 크래시 기록(Application Error)이 남습니다. 활용 방법은 「Windows 이벤트 로그・ETW 입문」에 정리해 두었습니다.

포스트모템을 써 보고 시계열이 채워지지 않는다면, 그 자체가 「감지와 기록의 구조가 부족하다」는 기여 요인이며, 재발 방지 액션의 후보입니다.

6. 재발 방지책의 질 ── 강도 판단표

재발 방지 액션을 적어냈다면, 그 강도를 판정합니다. 판단의 축은 「사람의 주의력에 얼마나 의존하고 있는가」입니다.

이때 현실적인 규칙은 「약한 대책을 금지한다」가 아니라 「약한 대책으로 끝내지 않는다」는 것입니다. 공지는 당일에 할 수 있는 잠정 대응으로서 의미가 있지만, 항구 대책란에 써도 되는 것은 중 이상, 가능하면 강 대책입니다.

약한 대책밖에 나오지 않을 때는, 다음 질문으로 다시 물어봅니다.

• 「새로 들어온 사람이 같은 상황에 놓여도 이 장애는 일어나지 않는가?」──아니오라면 구조가 되어 있지 않은 것입니다.
• 「이 실수를 컴파일러・테스트・CI 중 어느 하나가 감지하게 할 수 없는가?」──예를 들어 「종료 시 예외를 삼켜버리고 있었다」라면, 공지가 아니라 「상정하지 않은 예외가 발생했을 때의 체크리스트」에서 정리한 것과 같은 방침을 코드의 공통 예외 핸들러로 구현하는 것이 강한 대책입니다.
• 「애초에 실수할 수 없게 만들 수는 없는가? 실수를 빨리 알아챌 수 있게 만들 수는 없는가?」──방지에 비용이 많이 든다면 감지(모니터링・알림・대조 배치)로 방향을 트는 것도 훌륭한 강한 대책입니다. 장애의 교훈을 감지 강화와 설계 개선으로 환원한다는 정리는, Microsoft의 가이던스에서도 같은 구도로 권장되고 있습니다.²

강한 대책은 공수가 들기 때문에, 「이번 주에 할 중간 정도의 대책」과 「다음 달에 할 강한 대책」을 둘 다 액션에 올려, 기한으로 관리하는 것이 실무적입니다.

7. 어느 장애에 실시할 것인가 ── 실시 트리아지

풀 버전 포스트모템을 모든 장애에 의무화하면, 3개월이면 아무도 쓰지 않게 됩니다. 영향도×재발 가능성으로 실시 수준을 정합니다.

운영의 포인트는 세 가지입니다.

• 「같은 종류의 장애 재발」은 영향도와 관계없이 한 단계 올린다. 재발한 시점에서, 지난번 대책이 구조가 되어 있지 않았다는 증거이기 때문입니다.
• 경미해도 기록만은 반드시 남긴다. 한 단락이면 충분합니다. 「날짜・현상・원인・대처」의 네 가지가 있으면, 몇 년 후의 자신이 검색으로 구원받습니다. 작은 장애의 기록이 쌓이면 「이 화면만 장애가 많다」는 구조적인 편향도 보이게 됩니다.
• 망설여지면 쓰는 쪽으로 기울인다, 단 분량은 줄인다. 풀 버전으로 할지 말지 망설이는 시간이 있다면, 간이판을 쓰기 시작하는 쪽이 더 빨리 끝납니다.

7.1 「구조적」을 어떻게 판정하는가

표의 가로축 「재발하기 쉬움/구조적」은 판단 기준을 정해 두지 않으면 쓸 수 없습니다. 다음 중 하나라도 해당하면 구조적으로 취급한다는 정도의 단순한 기준으로 해 두는 것이 실무적입니다.

• 같은 화면・같은 모듈에서 두 번째. 시기가 떨어져 있어도, 같은 곳에서 두 번 일어났다면 우연이 아닙니다.
• 원인의 「유형」이 과거 장애와 같음. NULL 체크 누락, 배타 제어 누락, 날짜 경계 처리. 장소가 달라도 같은 유형이라면, 그 유형이 아직 막히지 않았다는 증거입니다.
• 그 장애를 재현하는 테스트를 작성할 수 없다/작성해도 돌아가지 않는다. 감지의 그물에 구조적인 구멍이 있는 상태이므로, 다음에도 그대로 빠져나갑니다.
• 「정해진 순서로 조작하면 일어나지 않는다」류의 장애. 운영 절차에 의존하고 있는 것은, 사람이 바뀌면 재발합니다.
• 같은 코드가 다른 고객・다른 환경에서도 동작하고 있다. 영향 범위가 이번 한 건으로 끝나지 않기 때문에, 취급을 한 단계 올립니다.

반대로 「일과성」이라고 단언해도 되는 것은, 원인이 외부 요인(특정 하드웨어 고장, 의존 서비스의 일시적 장애)에 국한되어 있고, 게다가 자사 쪽 설계・절차에서 구멍이 발견되지 않은 경우뿐입니다. 망설여지면 구조적 쪽으로 기울입니다. 과하게 써서 곤란해지는 경우는 거의 없습니다.

7.2 리뷰 회의(30분) 진행 방법

영향 대 장애에서 진행하는 리뷰 회의는, 시간을 정해 정해진 틀대로 돌리는 것이 요령입니다.

• 참가자는 3~5명. 대응한 당사자, 같은 코드를 다룰 가능성이 있는 다른 멤버, 고객 창구를 담당하는 사람. 책임 판단을 하는 입장의 사람은 넣지 않습니다. 넣는 순간 발언이 방어적이 되어, 기여 요인이 나오지 않게 됩니다. 필요하다면 결과 공유로 충분합니다.
• 초판을 사전에 배포한다. 그 자리에서 쓰기 시작하지 않을 것. 다만 전원이 미리 읽어 오는 것을 전제로 하면 무너지기 쉬우므로, 첫머리에 읽는 시간을 넣어 둡니다.
• 30분의 배분. (1) 0~5분: 각자 말없이 읽는다 (2) 5~10분: 시계열의 사실 확인. 인식 차이나 빠진 시각을 채운다 (3) 10~20분: 기여 요인 추가. 여기가 본론 (4) 20~28분: 액션의 강도 판정(6장의 표)과 담당・기한 확정 (5) 28~30분: 다음에 진척을 확인할 날짜를 정한다.
• 확인할 관점은 두 가지뿐. 「다른 어디에서 알아챌 수 있었는가」와 「같은 구멍이 다른 곳에 없는가」. 이 두 질문을 전원에게 던지면, 대응한 당사자만으로는 나오지 않는 기여 요인이 나옵니다.
• 진행자는 대응한 당사자 이외가 맡는다. 개인 이름이 주어인 발언이 나오면, 진행자가 구조를 주어로 바꿔 놓습니다. 「A씨가 확인을 잊었다」→「확인이 절차에 들어 있지 않았다」. 이 바꿔 말하기를 기계적으로 하는 것만으로 자리의 분위기가 바뀝니다.
• 미확정 액션을 남기지 않는다. 그 자리에서 정할 수 없는 것은, 「◯월 ◯일까지 방침을 정한다」는 액션으로 바꾸어 기한을 붙여서 마무리합니다.

7.3 장애 관리 대장을 어디에 둘 것인가

지금까지 몇 번 나온 「장애 관리 대장」은 전용 도구를 사서 갖추자는 이야기가 아닙니다. 충족해야 할 요건은 세 가지뿐입니다. 몇 년 후에도 전문 검색할 수 있을 것, 장애 1건이 1행으로 늘어날 것, 팀 전원이 쓸 수 있을 것. 이것을 충족하면 형식은 묻지 않습니다.

열은 「날짜 / 시스템・화면 / 현상 / 영향도 / 직접 원인 / 대처 / 포스트모템 링크 / 재발 여부」가 있으면 충분합니다. 중요한 것은 도구가 아니라, 경미한 장애라도 반드시 1행이 늘어난다는 것과, 몇 년 후에 「같은 현상」으로 검색할 수 있다는 것 두 가지입니다. 채팅 스레드와 메일만으로 끝내고 있는 상태는, 이 두 가지 중 어느 쪽도 충족하지 못합니다.

8. 수탁 개발에서의 취급 ── 고객용 장애 보고서와의 관계

수탁이나 유지보수 계약에서는 장애 후에 고객으로부터 「장애 보고서」를 요구받습니다. 이때 포스트모템과 보고서의 관계를 정리해 두면, 이중 수고를 방지할 수 있습니다.

내용의 8할은 전용할 수 있습니다. 개요・영향・시계열・직접 원인・재발 방지책은 고객용 보고서의 구성 요소 그 자체입니다. 먼저 내부용 포스트모템을 쓰고, 거기서부터 고객용으로 편집하는 순서로 하면, 보고서만을 위한 작문이 없어집니다.

다만, 목적이 다른 두 개의 문서라는 것은 의식하여 나눕니다.

8.1 실제로 어떻게 바뀌는가

추상적이면 이해하기 어려우므로, 4장의 템플릿 예시를 그대로 사용하여, 내부 서술이 고객용으로 어떻게 바뀌는지를 나란히 놓아 봅니다.

바꿔 쓰는 원칙은 세 가지입니다.

• 기술 용어는 업무 언어로 번역한다. 다만 사실은 흐리지 않는다. 「UNION ALL」, 「어서션」은 고객 담당자가 그 상사에게 설명할 수 있는 말로 바꿉니다. 한편 「표시상의 문제일 뿐 데이터는 정상」과 같이, 영향 범위를 확정하는 정보는 반드시 남깁니다. 이 부분을 모호하게 하면 오히려 문의가 늘어납니다.
• 사내 절차 미비도 사실로서는 쓴다. 「설계서에 기재가 없었다」를 지우면, 재발 방지책의 이유가 사라져 「왜 그것으로 고쳐지는가」가 전달되지 않게 됩니다. 표현을 정중하게 할 뿐, 없었던 일로 하지는 않습니다.
• 담당자 이름은 빼고, 기일은 남긴다. 사내 담당자 이름은 고객용으로는 불필요합니다. 반대로 실시 예정일은 약속으로 남기고, 완료되면 보고합니다.

나누는 가장 큰 이유는, 책임 추궁・보상 논의와 재발 방지 논의를 섞으면 양쪽 모두 왜곡되기 때문입니다. 책임 문제가 얽힌 문서에서는 관계자가 아무래도 방어적으로 씁니다. 방어적인 문서에서는 기여 요인이 사라지고, 재발 방지가 「주의하겠습니다」로 퇴화합니다. 반대로 솔직한 내부 포스트모템을 그대로 고객에게 내밀면, 맥락 없는 부분이 독자적으로 퍼져 나가는 일이 있습니다. 「솔직하게 쓰는 내부 문서」와 「정확하게 전달하는 외부 문서」를 나누어, 전자로부터 후자를 만드는 일방통행으로 하는 것이 안전합니다.

덧붙여, 고객용 보고서에 실시 예정인 재발 방지책을 적었다면, 그것은 고객과의 약속입니다. 포스트모템의 액션란과 같은 구조로 기한을 관리하고, 완료되면 보고합니다. 이 한 번의 왕복이 장애를 오히려 신뢰를 쌓는 기회로 바꿉니다.

9. 정리

• 장애 대응은 복구로 끝나지 않습니다. 복구・원인 규명・재발 방지는 별개의 작업으로 하여, 회고(포스트모템)를 업무에 편입시킵니다.
• 포스트모템은 blameless(비난하지 않는다)가 원칙입니다. 사람을 탓하면 정보가 나오지 않게 되어 원인에 도달할 수 없습니다. 사람의 행동에서 분석을 멈추지 않고, 구조의 구멍(기여 요인)까지 파고듭니다.¹
• 문서는 1시간이면 쓸 수 있는 최소 템플릿(개요・영향・시계열・직접 원인・기여 요인・잘된 점・담당과 기한이 붙은 액션)으로 충분합니다. 시계열을 채우기 위한 전제로, 크래시 덤프・로그・이벤트 로그의 증거 보전을 미리 마련해 둡니다.
• 재발 방지책은 「조심한다」(약)가 아니라 절차서(중), 가능하다면 테스트・어서션・모니터링・설계 변경으로 기계적으로 방지한다(강)로 끌어올립니다. 교훈을 감지와 설계로 환원하는 구도는 SRE・Microsoft 양쪽의 가이던스에 공통됩니다.¹²
• 모든 장애에 풀 실시는 하지 않습니다. 영향도×재발 가능성으로 트리아지하고, 경미한 것도 한 단락의 기록만은 반드시 남깁니다.
• 수탁 개발에서는 내부 포스트모템을 먼저 쓰고, 고객용 장애 보고서는 그것을 편집해 만듭니다. 책임・보상 문서와 재발 방지 문서를 나누는 것이 양쪽의 품질을 지킵니다.

관련 글

• Windows 앱의 크래시 덤프 수집 입문 - 우선 WER / ProcDump / WinDbg를 어떻게 구분해서 쓸까
• WinDbg + SOS로 크래시 덤프 읽기 ── 수집 이후 실무 분석 입문
• Windows 앱이 프로그램 실수에 의한 예외로 떨어져도 확실히 로그를 남기려면 - in-process에 걸지 않는 설계와 WER / 최종 로그 / 감시 프로세스의 베스트 프랙티스
• Windows 이벤트 로그·ETW 입문 ── 업무 앱의 로그를 OS 표준 체계에 올리기
• 어디서 예외를 catch하고 로그를 내며 에러 처리해야 하는가 - 호출 계층의 경계와 책무를 실무용으로 정리
• 상정하지 않은 예외가 발생했을 때의 체크리스트 - 앱을 종료시킬지 계속할지, 먼저 보는 판단표

관련 상담 영역

합동회사 코무라소프트에서는 재현이 어려운 결함의 조사・원인 분석부터, 증거 보전(로그・덤프 수집) 체계 구축, 재발 방지를 포함한 유지보수 운영 체제 정비까지를 다루고 있습니다. 「같은 장애가 반복되고 있다」, 「장애 보고서의 재발 방지책이 형식적으로 변해 있다」와 같은 단계부터의 상담도 환영합니다.

• 결함 조사・원인 분석
• 기존 Windows 소프트웨어의 개수・유지보수
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

포스트모템이란 무엇인가요? 장애 보고서와는 다른가요?

포스트모템은 장애 복구 후에 진행하는 구조화된 회고 문서이자 활동으로, SRE(Site Reliability Engineering) 분야에서 정착한 기법입니다. 개인을 탓하지 않는다(blameless)는 것을 전제로, 시계열・직접 원인・기여 요인・재발 방지 액션을 기록합니다. 고객용 장애 보고서가 「무슨 일이 일어났고, 어떻게 대처했는가」에 대한 설명 책임을 다하는 문서인 데 비해, 포스트모템은 「다음에 같은 일이 일어나지 않도록 구조를 어떻게 바꿀 것인가」를 정하기 위한 내부 문서입니다. 다만 내용의 대부분이 겹치므로, 포스트모템을 먼저 쓰고 거기서부터 고객용 보고서를 편집해 만드는 운용이 효율적입니다.

재발 방지책이 「앞으로는 충분히 주의하겠습니다」뿐이 되어 버립니다. 어떻게 하면 좋을까요?

「주의한다・공지한다」는 사람의 기억과 선의에 의존하기 때문에, 시간이 지나고 담당자가 바뀌면 반드시 효과가 사라집니다. 대책을 생각할 때는 「새로 들어온 사람이 같은 상황에 놓여도 이 장애는 일어나지 않는가」를 다시 물어보십시오. 답이 아니오라면 구조가 되어 있지 않은 것입니다. 강한 대책은 테스트・어서션・타입이나 설계에 의한 제약・모니터링 알림 등, 사람이 주의하지 않아도 기계적으로 감지・방지되는 것입니다. 바로 강한 대책을 세울 수 없는 경우에는 체크리스트나 절차서를 중간 단계로 두고, 항구 대책을 기한이 있는 액션으로 기록합니다.

소수 인원의 수탁 개발에서 모든 장애에 포스트모템을 쓸 여유가 없습니다.

모든 장애에 풀 버전 포스트모템을 쓸 필요는 없으며, 그렇게 하려고 하면 제도 자체가 지속되지 않습니다. 영향도와 재발 가능성으로 실시 여부를 트리아지하여, 업무 중단이나 데이터 파손을 동반하는 장애, 같은 종류의 장애가 재발했을 때는 풀 실시하고, 경미한 것은 장애 관리 대장에 한 단락의 기록만 남기는 식으로 농도를 조절합니다. 중요한 것은 「경미해도 기록은 반드시 남긴다」는 것으로, 몇 년 후 같은 현상이 일어났을 때 과거 기록을 검색할 수 있는지 여부에 따라 조사 시간이 크게 달라집니다.

범인 찾기를 하지 않는다(blameless)는 것은 책임을 흐지부지하는 것 아닌가요?

아닙니다. blameless는 「누가 실수했는가」가 아니라 「왜 그 사람이 실수할 수 있는 구조였는가」로 초점을 옮기기 위한 원칙입니다. 오퍼레이터가 조작을 잘못했다면, 잘못하기 쉬운 UI나 절차에 기여 요인이 있는 것입니다. 개인을 처벌하는 조직에서는 다음 장애가 발생했을 때 정보가 감춰져 원인에 도달할 수 없게 됩니다. 한편 고객에 대한 설명 책임(무슨 일이 일어났고 어떻게 보상할 것인가)은 별도의 문서・별도의 프로세스로 이행해야 할 것으로, blameless한 회고와 모순되지 않습니다. 책임 추궁의 문서와 재발 방지의 문서를 나누는 것이 실무상의 핵심입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.