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

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

장애 대응 자체, 즉 감지하고, 원인 위치를 특정하고, 고치고, 릴리스하고, 사과하기. 여기까지는 많은 팀이 제대로 합니다. 문제는 그다음입니다. 복구되는 순간 모두가 일상 업무로 돌아가고, 장애 기록은 누군가의 메일함과 채팅 로그에 흩어진 채 흐려집니다. 반년 뒤, 같은 구조의 장애가 다른 지점에서 다시 일어나고, 같은 조사를 처음부터 다시 합니다. 「고치고 사과하고 끝」인 장애 대응은, 같은 수업료를 여러 번 내는 운영입니다.

이 블로그에서는 장애 조사의 기술 측면으로 「Windows 크래시 덤프 수집 입문」과 「예외의 catch·로그·오류 처리 실무」에서 「원인까지 가는 방법」을 다뤄 왔습니다. 이 글은 그다음 단계, 원인을 파악한 뒤에 같은 장애를 다시 만들지 않기 위한 회고(포스트모템)를 어떻게 돌릴지를 다룹니다. 대규모 웹 서비스 이야기가 아니라, 2~5명이 업무 앱·Windows 소프트웨어를 유지보수하는 작은 팀에서 실제로 이어 갈 수 있는 틀로 범위를 좁힙니다.

1. 먼저 결론

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

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 16건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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

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

복구되는 순간 「끝났다」가 됩니다. 장애 대응은 긴급 인터럽트라서, 복구되면 모두가 밀린 일상 업무로 돌아갑니다. 회고 시간은 누구의 캘린더에도 들어 있지 않고, 「한가해지면 하자」는 영원히 오지 않습니다.

보고서가 「앞으로는 충분히 주의하겠습니다」로 끝납니다. 고객이나 상사에게 내는 보고서의 재발 방지란에 「확인을 철저히 하겠습니다」「더블 체크를 하겠습니다」라고 쓰고 닫습니다. 이 문장은 아무 체계도 바꾸지 않으므로, 주의력이 느슨해지는 몇 달 뒤에 같은 구멍에 빠집니다.

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

기록이 남지 않아, 몇 년 뒤 같은 구멍에 빠집니다. 소규모 팀의 유지보수는 「같은 사람이 계속 대응한다」는 이유로, 기록이 없어도 당장은 굴러갑니다. 그러나 그 사람의 기억은 몇 년이면 흐려지고, 퇴사나 교체로 사라집니다. 「이 오류, 전에도 본 것 같은데 대처가 기억나지 않는다」는, 기록만 있었으면 10분이면 끝날 조사를 하루 종일로 바꿉니다.

어느 것이든 능력의 문제가 아니라, 회고가 업무로 정의되어 있지 않은 결과입니다. 그래서 틀(템플릿과 실시 기준)을 먼저 정해 두는 가치가 있습니다.

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

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

이 생각은 Google만의 것이 아닙니다. Microsoft의 아키텍처 가이드(Azure Well-Architected Framework)에서도 포스트모템은 「관련 팀 전원이 참여하는, 구조화된 비난 없는 리뷰」로 정의되고, 근본 원인 분석(RCA) 결과를 대응 프로세스 개선·감지(observability) 강화·설계 개선의 형태로 시스템에 되돌릴 것이 권장됩니다.²

「우리는 대규모 웹이 아니니 해당 없다」고 생각하기 쉽지만, 필자는 반대라고 봅니다. 고객사 상주 없이 소수 인원으로 데스크톱 앱을 유지보수하는 체제일수록 포스트모템이 효과가 있습니다. 이유는 세 가지입니다.

1. 같은 사람이 계속 대응하므로, 기록이 없으면 한 사람에게만 남습니다. 큰 조직이면 누군가 기억하지만, 2~3명 팀에서는 「기억하는 사람」이 유일한 데이터베이스입니다. 포스트모템이 그 외부 기억이 됩니다.
2. 장애 간격이 깁니다. 웹 서비스와 달리 업무 앱의 중대 장애는 1년에 몇 번입니다. 지난 대응의 기억이 흐려질 때쯤 다음이 오므로, 기록의 가치가 상대적으로 커집니다.
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하고 있었다 (배타적 제어 없음).

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

## 잘된 점
- 이용자가 조작 로그의 시각을 적어 두어 재현 조건 파악이 빨랐다
- 배포 장치가 자동화되어 있어 수정본을 당일 배포할 수 있었다

## 재발 방지 액션 (담당과 기한)
- [ ] 목록 쿼리에 중복 감지 assertion 추가 (코무라, 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 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. 수탁 개발에서의 취급 ── 고객용 장애 보고서와의 관계

수탁이나 유지보수 계약에서는, 장애 뒤에 고객에게서 「장애 보고서」를 요구받습니다. 이때 포스트모템과 보고서의 관계를 정리해 두면, 이중 작업을 막을 수 있습니다.

내용의 80%는 가져와 쓸 수 있습니다. 개요·영향·타임라인·직접 원인·재발 방지책은 고객용 보고서의 구성 요소 그 자체입니다. 먼저 내부용 포스트모템을 쓰고, 거기서 고객용으로 편집하는 순서로 하면, 보고서만을 위한 작문이 사라집니다.

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

8.1 실제로 어떻게 바뀌는가

추상적이면 알기 어려우므로, 4장의 템플릿 예를 그대로 써서, 내부 서술이 고객용으로 어떻게 바뀌는지를 나란히 둡니다.

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

• 기술 용어는 업무의 말로 옮깁니다. 다만 사실은 옅게 하지 않습니다. 「UNION ALL」「assertion」은 고객 담당자가 그 상사에게 설명할 수 있는 말로 바꿉니다. 한편 「표시만일 뿐 데이터는 정상」처럼, 영향 범위를 확정하는 정보는 반드시 남깁니다. 여기를 모호하게 하면, 오히려 문의가 늘어납니다.
• 사내 절차 미비도, 사실로는 씁니다. 「설계서에 기재가 없었다」를 지우면, 재발 방지책의 이유가 사라져 「왜 그것으로 고쳐지는가」가 전해지지 않습니다. 표현을 정중히 할 뿐, 없었던 일로 만들지 않습니다.
• 담당자 이름은 빼고, 기일은 남깁니다. 사내 담당자 이름은 고객용으로는 필요 없습니다. 반대로 실시 예정일은 약속으로 남기고, 끝나면 보고합니다.

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

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

9. 정리

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

관련 글

• Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg
• WinDbg + SOS로 크래시 덤프 읽기 ── 수집한 뒤의 실무 분석 입문
• Windows 앱의 크래시 때 로그와 덤프를 남기는 설계
• Windows 이벤트 로그·ETW 입문 ── 업무 앱 로그를 OS 표준 장치에 올리기
• 예외의 catch·로그·오류 처리 실무
• 예상 밖 예외에서 종료할지 계속할지 판단표

관련 상담 영역

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

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

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

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

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

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

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

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

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

저자 프로필

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

Go Komura

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

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