이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
장애 대응 경험은 개인 프로젝트 서버가 예상치 못하게 다운됐을 때 처음 제대로 겪었습니다. 증상 확인 → 원인 추적 → 임시 조치 → 근본 해결 순서로 접근하면서, 당황하지 않고 단계별로 진행하는 것이 빠른 복구의 기본이라는 것을 배웠습니다. 장애 후 포스트모템을 작성하는 연습을 하면서 단순히 이 버그를 수정했다 는 것보다 왜 배포 전에 발견되지 않았는가 를 묻는 방식이 재발 방지에 더 효과적이라는 것을 이해했습니다.
타임라인 기록을 상세히 남기면 같은 상황이 반복됐을 때 이전 대응 내용을 참고해 해결 시간이 단축됩니다. 문제의 범인을 찾는 것보다 시스템이 왜 취약했는지 구조적 원인을 찾는 것이 포스트모템의 핵심이라고 생각합니다. 이 접근 방식이 장애를 두려움이 아닌 개선 기회로 보게 하는 시작이었습니다.
팀 프로젝트에서 새벽에 서비스가 갑자기 느려지는 장애가 발생했을 때 처음에는 혼자 해결하려고 로그를 두 시간 넘게 뒤졌습니다. 원인을 좁히지 못한 채 시간만 흐르다가, 팀원에게 상황을 공유했더니 'DB 커넥션 풀이 고갈되는 패턴이 있다' 는 걸 유사 사례를 기억하는 팀원이 바로 짚어줬습니다. 그 힌트로 pg_stat_activity를 확인하니 오래된 커넥션이 반환되지 않고 쌓인 것이 원인이었습니다. 복구 후 포스트모템을 함께 작성하면서, 혼자 두 시간을 소모한 것이 가장 큰 비효율이었다는 결론이 나왔습니다. 이후 팀에서 15분 규칙을 만들었습니다. 장애 대응 중 원인을 15분 안에 좁히지 못하면 반드시 다른 사람에게 공유하기로 합의한 것입니다.
장애는 혼자 끌어안을수록 MTTR이 늘어난다는 걸 이 경험에서 배웠습니다.
포스트모템을 처음 작성했을 때는 타임라인 정리에 그쳤는데, 그 다음 장애에서 비슷한 패턴이 반복됐습니다. 원인은 찾았지만 개선이 연결되지 않았던 것이었습니다. 이후 포스트모템 양식에 액션 아이템 섹션을 추가하고 각 항목에 담당자와 마감일을 반드시 적도록 바꿨습니다. '모니터링 알람 임계값 조정 — OO, 2주 내'처럼 모호하지 않게 기록했습니다. 스프린트 시작 시 지난 포스트모템 액션 아이템 완료 여부를 짧게 체크하는 루틴도 만들었습니다. 그 결과 3개월 뒤 동일 패턴의 장애가 사라졌고, 반복 장애 건수가 절반으로 줄었습니다.
MTTR이 줄어드는 것도 중요하지만 재발을 막는 것이 포스트모템의 진짜 목적이라는 걸 이 경험으로 이해했습니다. 기록이 절차가 되고, 절차가 개선이 되는 흐름을 만드는 것이 핵심이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부스터즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.