실수에 대해 부검하는, 포스트 모템(Postmortem)에 대해 아시나요?

최근에 회사에서 '포스트 모템(Postmortem)' 을 작성해야한다는 말을 들었다. 

 

내가 속한 개발 팀에서 운영 배포를 한 이후 웹사이트에서 기존의 다른 중요한 기능이 정상적으로 동작하지 않았었는데, 회귀 테스트를 진행하지 않아서 해당 오류를 하루 이틀 정도 늦게 발견하게 되어, 이를 방지하기 위해 포스트 모템(Postmortem)을 작성해야한다는 것이었다. 

 

해당 개념을 처음 접해보아서 정확히 어떤 개념인지 와닿지 않아서 어휘의 뜻을 찾아보았는데, 

포스트모텀(Postmortem)은 우리 말로 부검 또는 검시라고 한다. 

Post는 '후', 모르템은 '죽음'이라는 뜻이다. 

즉, 피해자를 사망에 이르게 한 원인을 사후에 총제적으로 알아내기 위한 방법이라고 한다. 

 

쉽게 말해 실수를 부검 한다고 생각하면 되는데, 

 

즉 오류가 발생했을 때 정확히 어떠한 원인으로 발생을 하게 되었고, 어떻게, 어느 시점에서 오류가 발생을 했고, 해당 오류 재발 방지를 위해서 어떤 액션을 앞으로 취해야하는 지에 대해 작성을 하는 것이다. 

 

 

우리 팀에서 작성했던 포스트 모템 양식은 다음과 같다.

 

• Summary : 어떤 이슈가 발생했는지 간단히 요약한다. 
  • ex)  2023.11.12 배포 : internal API 작업 배포 이후 2023년 11월 14일 1시 경에 aaaa 기능이 동작하지 않은 이슈를 확인함 
• Timeline : 어느 시간 대에, 어떤 활동으로 이슈가 발생했는지 적는다. 
  • ex) 2023.11.12 19:03 
            - internal API 인증 관련 개선 작업 배포  
           2023.11.13 14:10 
            - aaaa 기능이 동작하지 않는 이슈를 고객 센터 티켓 인입으로 확인 
           2023.11.13 15:00
            - internal API 인증 관련 작업 배포 롤백 
            - 발생했던 aaaa 기능이 동작하지 않았던 버그들이 더 이상 발생하지 않는 것을 확인 
• Impact : 해당 이슈가 사용자들에게 또는 웹사이트 자체에 어떠한 영향을 끼쳤는지에 대해 적는다.
  
  • ex) - 배포 이후 aaaa 기능이 동작하지 않아서 사용자들이 해당 게시판에 글을 작성하거나 게시글을 확인하지 못함 
           - 11.01 20:30 ~ 11.02 15:00 와 믹스 패널 이벤트를 비교 
                - 게시글 작성 : 5454회 / 게시글 읽음 : 69.05K회 (11.01 20:30 ~ 11.02 15:00)
                - 게시글 작성 : 5521회 / 겟글 읽음 : 68.33K회 (11.12 20:30 ~ 11.13 15:00)
          - 게시글 작성에 대한 이벤트가 큰 차이는 없는 것으로 보아 해당 오류 케이스가 일반적이지 않은 것으로 추정되고 영향도가 크지 않았을 것으로 판단됨. 
• Root Causes : 해당 이슈가 발생한 근본적인 원인에 대해 적는다. 
  • ex) 외부 서비스를 호출하기 위핸 internal service 클라이언트에서 인증 토큰의 캐시 ttl을 설저할 때 second 단위가 아니라 millisecond 단위로 지정하여 ttl이 의도대로 동작하지 않아 401 에러가 지속적으로 발생했음 
  • ex) 게시글 작성을 확인하는 유닛테스트가 부재하거나 유의미하지 않았음
  • ex) 회귀 테스트를 충분히 하지 않았음 
• Triggers : 이슈가 재현되는 지점에 대해 적는다. 
  • ex) v12.0.3 을 배포할 시 재현이 됨. 
• Resolutions : 어떻게 이슈를 재발하지 않을지에 대한 해결법을 적는다. 
  • ex) 변경사항 확인을 위한 명확한 테스트 체크리스트가 필요하다. 
  • ex) 작업자가 변경사항에 대해 영향 범주 파악 충분히 필요하다. 
  • ex) 회귀 테스트를 위해 서비스별로 반드시 동작을 확인해야 하는 기능 목록을 만들어야 한다. 
• Detection : 어떻게 이슈를 발견하였는지에 대해 적는다.  
  • ex) sentry 오류 모니터링
  • ex) 고객 센터 티켓 인입
• Action Items : 구체적으로 어떤 활동을 통해서 이슈 재발 방지를 할 지 적는다. 
  • ex) Immediate actions : 회귀테스트 시나리오 초안 만들기, 변경 사항 중요도에 따라 릴리즈 버전을 나누기 
  • ex) Long-term Actions : 배포 이후 sentry 오류 지속적인 모니터링 
    
    

 

모스트 모템은 단순히 작성하고 해결법을 도출하는데에서 끝나지 않는다. 

이 문서를 조직원 모두와 공유하는 것 또한 중요하다. 

전체 회사와 공유함으로써, 어떤 실수가 얼마만큼 큰 손실을 가져올 수 있는지 다 같이 이해한다면 실수를 예방하는 일 역시 모두의 것이 된다. 

 

이슈가 처음부터 발생을 하지 않는다면 베스트겠지만, 사실 그건 애초에 불가능한 가정인 것 같다. 이슈가 덜 발생하는 것도 중요하겠지만, 그것보다도 중요한 것은 해당 이슈를 어떻게 바라보고, 어떻게 앞으로 대처할 지 인 것 같다는 생각이 든다. 

 

 

아래 글에서 포스트모템의 구체적인 설명과 사례가 잘 적혀있어서, 참고해도 좋을 듯 하다. https://brunch.co.kr/@svillustrated/13#comment