아무도 다시 읽지 않는 포스트모템
온콜을 운영하는 팀이라면 어디든 포스트모템 폴더가 있다. 그 안에는 수십 개의 문서가 쌓여 있고, 각각은 밤새 프로덕션 화재와 씨름한 누군가가 마감에 쫓기며 작성한 것들이다. 각 문서에는 근본 원인 섹션, 영향 범위 요약, 타임라인, 그리고 액션 아이템 목록이 있다. 그리고 각 문서는 발행된 뒤, 많아야 두 번 더 열려보고는 영원히 아카이브 속으로 사라진다.
이건 규율의 문제가 아니다. 이 문서를 쓰는 팀은 게으르거나 무심하지 않다 — 시간을 비워두고, 템플릿을 채우고, 리뷰 미팅까지 진행한다. 포스트모템은 분명 진심으로 작성된다. 문제는 작성이 끝난 뒤 아무 일도 일어나지 않는다는 것이고, 거의 아무도 그 이유를 묻지 않는다. 글을 쓰는 행위 자체가 마치 일의 완료처럼 느껴지기 때문이다.
문서는 섬이다
구조적으로 보면 포스트모템은 스냅샷이다 — 무엇이 고장났는지를 서술한 한 단락짜리 글이, 누군가 그걸 적을 만한 여력이 있던 그 순간에 고정된 것이다. 이 스냅샷은 위키 페이지나 구글 문서, 노션 데이터베이스 어딘가에 놓여, 형식은 거의 똑같지만 내용은 완전히 단절된 수백 개의 다른 스냅샷 옆에 나란히 놓인다. 이 인시던트의 근본 원인이 그것을 유발한 배포, 드리프트된 설정 값, 혹은 지난 1년간 같은 취약점에서 비롯된 다른 세 건의 인시던트와 연결되는 곳은 어디에도 없다. 문서는 “이것이 저것을 일으켰고, 저것이 이것을 일으켰다”는 리니지를 담고 있지만, 그걸 시스템이 순회할 수 있는 구조가 아니라 산문으로 담아낸다.
이 차이는 보기보다 훨씬 중요하다. “근본 원인은 3월 스키마 마이그레이션에서 도입된 레이스 컨디션이었고, 그에 상응하는 인덱스 업데이트 없이 배포됐다”라는 문장은 그 순간에 읽는 사람에게는 더없이 명확하다. 하지만 스택의 다른 모든 시스템 입장에서는 완전히 무의미하다. 배포 도구는 이 문장의 존재를 모른다. 알림 시스템도 모른다. 6개월 뒤 그 스키마를 건드리게 될, 이 인시던트를 기억하지 못하는 엔지니어는 정확히 같은 단어로 정확히 같은 위키 공간을 검색하지 않는 한 이 문장을 마주칠 방법이 없다.
아무도 거꾸로 읽지 않는다
불편한 진실은, 포스트모템이 이미 지나간 순간을 위해 쓰인다는 것이다. 그것은 팀 전체가 고개를 끄덕이며 액션 아이템을 배정하는 리뷰 미팅에서 딱 한 번 읽히고, 그 뒤로는 사실상 다시 읽히지 않는다 — 누구의 일상 워크플로도 그 문서를 다시 가리키지 않기 때문이다. 화요일 오후에 패턴을 찾으려고 포스트모템 아카이브를 뒤적이는 사람은 없다. 디버깅을 시작하기 전에 이번 주 알림을 작년 문서와 대조해보는 사람도 없다. 그 정보가 다시 가치를 갖는 순간은 정확히 그것이 필요한 순간 — 다음 인시던트가 터졌을 때 — 뿐인데, 바로 그 순간 아무도 증상과 일치할지도 모르는 산문 문서 아카이브를 뒤질 여유가 없다.
그래서 같은 실패 유형이, 때로는 다른 이름을 달고 반복된다. 옛 문서가 했던 말과 본질적으로 같은 내용을, 다른 단어로 담은 새 포스트모템이 또 쓰인다. 팀이 교훈을 배우지 못해서가 아니다. 교훈은 처음부터 정확히 기록되어 있었다. 다만 그 기록이 문서 자체 이외의 어떤 것과도 연결되지 않았기 때문에, 그것을 배우려면 누군가가 그 문서의 존재를 기억하고, 찾아내고, 지금 상황과의 유사성을 알아채야 한다 — 이 세 단계가 모두 인시던트 압박 속에서, 새벽 3시에, 이미 끝난 작업의 혜택을 보기도 전에 일어나야 한다.
주소 없는 액션 아이템
액션 아이템 섹션은 이 문제를 미묘하게 더 악화시킨다. “X에 대한 모니터를 추가한다”, “Y에 대한 런북 단계를 추가한다”, “Z의 불안정한 테스트를 후속 조치한다” — 이런 문장들은 약속처럼 읽히지만, 주소가 없는 약속이다. 이들은 해당 코드 옆에 살지 않는다. 완료되지 않아도 배포를 막지 않는다. 포스트모템 문서 안에, 때로는 한두 스프린트 안에 우선순위가 밀려버리는 티켓에 복사된 채로만 존재하고, “이 인시던트가 일어났다”와 “이 특정 인프라 조각은 여전히 취약하다” 사이의 연결고리는 조용히 증발해버린다. 6개월 뒤, 누군가는 그 취약한 인프라를 건드리면서 그것이 장애를 일으킨 문서화된 이력이 있다는 어떤 표시도 마주치지 못한다.
대부분의 조직에서 특정 유형의 인시던트가 꽤 예측 가능한 주기로 재발하는 이유가 여기에 있다 — 엔지니어들이 부주의하게 같은 실수를 반복해서가 아니라, 이전 실수의 기록이 다음 실수가 일어날 그 자리에 붙어 있지 않았기 때문이다. 문서 저장소에 사는 포스트모템과 저장소(repository)에 사는 코드베이스는, 실질적으로는 같은 시스템을 서술하면서도 서로 전혀 다른 세계에 속해 있다.
인시던트 사이에서 사라지는 것
진짜 비용은 아무도 읽지 않는 문서를 쓰는 데 든 한 시간이 아니다. 그 한 시간이 사서 얻었어야 할 모든 것 — 인시던트를 거듭할수록 구조적으로 더 부서지기 어려워지는 조직, 매 실패가 뭔가 지속되는 것을 가르쳐주는 조직 — 이 사라지는 것이다. 글쓰기가 시스템 자체가 실행에 옮길 수 있는 무언가로 이어지지 않을 때, 그 축적은 결코 일어나지 않는다. 아카이브에 아무리 잘 쓰인 문서가, 곧 다시 벌어질 일과 거의 정확히 같은 내용을 담은 채로 쌓여 있어도, 모든 인시던트는 그 앞의 것과 거의 같은 백지에서 다시 출발한다.
팀은 정확히 이름 붙이지 못하더라도 이걸 감지한다. 포스트모템 리뷰 미팅에서 낮게 깔린 좌절감으로 드러난다 — 이런 일이 벌어질 줄 다들 이미 알고 있었다는 느낌, 이 대화가 낯익다는 느낌, 팀이 배우는 시늉을 하면서 동시에 자신들이 배우지 못하고 있다는 사실을 스스로 서술하고 있다는 느낌. 문서는 제 역할을 다했다. 문제는 그 역할이 문서가 제출되는 순간 끝나버렸고, 그 이후로 아무것도 그 뒤를 이어받지 않았다는 데 있다.