서비스에 장애가 발생했습니다.
긴급 대응 끝에 서비스는 정상화되었고, 팀은 안도의 한숨을 내쉽니다.
하지만 진짜 중요한 일은 지금부터 시작입니다.
“왜 이 장애가 발생했는가?”
“어떻게 하면 다시는 이런 일이 일어나지 않도록 막을 수 있을까?”
이 질문에 답하며, 장애를 팀의 귀중한 자산으로 바꾸는 과정이 바로 ‘장애 회고(Post-mortem)’입니다.
이 글에서 다루는 것
- 장애 회고의 개념과 ‘비난 없는 문화’
- QA의 장애 회고 참여 역할
- 근본 원인 분석과 재발 방지 대책 검증
- 성공적인 장애 회고를 위한 실무 팁
‘장애 회고(Post-mortem)’, 정확히 무엇인가요?
‘장애 회고’는 장애가 발생한 후, 관련된 모든 팀원이 모여 장애의 원인부터 대응 과정, 그리고 개선점까지 모든 것을 투명하게 되짚어보는 공식적인 회의입니다.
‘Post-mortem’은 원래 의학에서 ‘사후 검증’을 의미하는 단어입니다.
이처럼, 장애라는 사건을 객관적으로 분석하여 교훈을 얻는 것을 목표로 합니다.
가장 중요한 원칙: ‘비난 없는 문화(Blameless Culture)’
성공적인 ‘장애 회고’의 가장 중요한 전제 조건은, 특정 개인의 실수를 비난하지 않는 것입니다.
- 잘못된 질문: “누가 이 버그를 만들었죠?”
- 올바른 질문: “어떤 시스템과 프로세스의 허점이 있었기에, 이 버그가 만들어지고 배포까지 될 수 있었을까요?”
‘장애’는 한 사람의 실수가 아닌, 우리 팀의 시스템과 프로세스가 가진 약점에서 비롯되었다고 믿는 것.
이 ‘비난 없는 문화’가 있어야만, 팀원들은 숨기지 않고 솔직하게 문제점을 공유하며 진짜 ‘근본 원인’을 찾아낼 수 있습니다.
‘장애 회고’에서 QA의 역할은 무엇인가요?
QA는 ‘장애’의 원인 분석과 재발 방지 대책 수립 과정에서 핵심적인 역할을 수행합니다.
- 1. 객관적인 타임라인 재구성:
- QA는 JIRA 티켓, 배포 기록, 모니터링 데이터, 테스트 결과 등 객관적인 자료를 바탕으로, 장애가 처음 인지된 시점부터 해결되기까지의 정확한 타임라인을 재구성하는 데 기여합니다.
- 2. ‘왜 테스트에서 걸러지지 못했는가’ 분석:
- 이것이 ‘장애 회고’에서 QA의 가장 중요한 질문입니다.
- QA는 다음과 같은 관점에서 원인을 분석해야 합니다.
- 테스트 케이스의 누락: 해당 예외 상황을 검증하는 테스트 케이스 자체가 없었는가?
- 테스트 환경의 한계: 실제 운영 환경과 테스트 환경의 차이 때문에 발견할 수 없었는가?
- 테스트 자동화의 부재: 회귀 테스트 범위에 포함되었다면 막을 수 있었던 문제인가?
- 잘못된 테스트 전략: 리스크 분석이 잘못되어, 해당 기능의 테스트 우선순위가 너무 낮게 책정되었는가?
- 3. 재발 방지 대책 검증:
- ‘장애 회고’를 통해 “앞으로 OOO 테스트를 추가하자”는 재발 방지 대책이 결정됩니다.
- QA는 이 대책이 실제로 실행 가능한지 검토하고, 이를 구체적인 ‘테스트 케이스’나 ‘자동화 스크립트’로 만들어, 동일한 장애가 다시는 발생하지 않음을 보증하는 역할을 합니다.
현직 QA의 실제 경험담
제가 경험한 한 장애 회고에서는, 특정 API의 타임아웃 설정 값이 테스트 서버와 운영 서버가 서로 달랐던 것이 ‘근본 원인’으로 밝혀졌습니다.
테스트 환경에서는 문제가 없었지만, 더 많은 트래픽을 받는 운영 환경에서는 이 작은 차이가 대규모 장애를 유발했던 것입니다. 이 회고를 통해 우리 팀은 ‘모든 환경의 설정 값을 자동으로 동기화하고 검증하는’ 프로세스를 도입하여, 이후 비슷한 유형의 장애를 원천적으로 예방할 수 있었습니다.
결론: 실패로부터 배우는 조직의 힘
‘장애 회고’는 실패를 책망하는 자리가 아니라, 실패를 통해 배우고 성장하는 자리입니다.
QA가 ‘장애 회고’에 적극적으로 참여하여, 테스트 프로세스의 약점을 찾아내고 개선하는 것은 매우 중요합니다.
이는 단순히 하나의 버그를 수정하는 것을 넘어, 우리 팀의 품질 시스템 전체를 더 튼튼하게 만드는 과정입니다.
가장 빠르게 성장하는 팀은, 장애를 숨기지 않고 투명하게 공유하며, 그 경험을 통해 더 나은 시스템을 만들어나가는 팀입니다.
부록: 장애 회고 QA 미니 체크리스트 ✅
- 이번 장애를 재현하는 자동화 테스트 케이스를 회귀 테스트 스위트에 추가했는가?
- 장애의 근본 원인이 테스트 환경의 문제였다면, 환경 개선 계획이 수립되었는가?
- 유사한 다른 기능에도 동일한 잠재적 위험은 없는지 교차 검증을 수행했는가?
- 장애 탐지 시간을 단축하기 위한 모니터링 및 알림 시스템 개선안이 논의되었는가?
- 장애 회고의 결과(Action Item)가 JIRA 등에 기록되고, 실제 개선으로 이어지는지 추적하고 있는가?
참고 자료 (References)
- Google SRE – Postmortem Culture: Learning from Failure (구글의 장애 회고 문화에 대한 공식 문서)
- 우아한형제들 기술블로그 – 장애는 예고 없이 찾아온다 (국내 기업의 장애 회고 사례)