이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 프로덕션 장애 대응에 보조로 참여했습니다. 저는 타임라인 복원을 담당했는데, 로그와 메트릭을 시간순으로 붙여보니 배포 8분 후 에러율 급등이라는 패턴이 명확해졌습니다. 5 Why 분석으로 파고드니 배포 중 구버전과 신버전이 공존하는 순간에 세션 토큰 형식 불일치가 원인이었고, 배포 전략이 롤링이라 일부 요청만 오류가 나고 있었습니다. 개선책으로 카나리 릴리즈 단계에서 세션 호환성 검증 스텝을 CI에 추가하도록 제안했고, 팀에서 다음 스프린트에 반영했습니다. 장애 대응에서 RCA는 증상이 아니라 구조적 취약점을 찾는 것이 목적이라는 점을 이 경험에서 확실히 배웠습니다.
장애 대응에서 복구 후 다시는 안 나오게 하자는 다짐이 실제 지표로 이어지지 않는 경우를 봤습니다. RCA에서 원인을 찾고 개선안을 도출했지만, 어떤 지표가 얼마나 개선됐는지 추적하지 않으면 같은 원인이 다른 형태로 반복됩니다. 그래서 이후부터는 Action Item을 정의할 때 MTTR이나 특정 에러율을 함께 목표로 명시했습니다. Circuit Breaker 설정을 도입한 이후 같은 의존성 장애에서 서비스 전파 시간이 절반 아래로 줄었는지를 다음 장애 시 측정 기준으로 미리 잡았습니다.
개선됐다는 느낌이 아니라 수치로 전·후를 비교할 수 있어야, RCA가 형식이 아닌 실제 예방으로 이어진다고 봅니다.
장애 대응에서 감지보다 격리가 더 어려울 때가 있었습니다. DB 슬로우 쿼리로 API 응답이 전체적으로 느려지는 장애였는데, 어느 쿼리가 원인인지 찾기 전에 서비스 전체가 느려진 상황이었습니다. 먼저 Feature Flag로 해당 API 경로를 일시 비활성화해 다른 서비스에 전파되는 걸 막고, 그 다음에 느린 쿼리를 분석했습니다.
복구를 먼저, 원인 분석은 그 다음이라는 순서를 이 경험으로 몸에 익혔습니다. 원인은 전체 테이블 풀 스캔이 발생하는 인덱스 미사용이었고, 인덱스 추가 후 해당 API P99 응답이 8초에서 200ms로 줄었습니다. RCA로 얻은 패턴은 팀 내 코드 리뷰 체크리스트에 추가해 재발 방지 구조를 만들었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.