인시던트 대응 체계 이해 검증
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
장애 발생 시 저는 감지 → 격리 → 완화 → 복구 → 재발 방지 순서로 접근합니다. 먼저 장애 범위를 빠르게 파악해 영향을 격리합니다. 전체가 영향을 받기 전에 해당 컴포넌트나 트래픽을 분리하는 것이 우선입니다. 그 다음으로 롤백 가능한 경우에는 이전 안정 버전으로 복원하고, 롤백이 어렵다면 기능 플래그나 트래픽 우회로 서비스 가용성을 먼저 회복합니다. 완전한 원인 분석은 서비스가 안정된 이후에 진행합니다.
온콜 대응에서 가장 중요한 원칙은 빠른 복구를 위해 근본 원인 분석을 나중으로 미루는 것입니다. 복구 후에는 타임라인을 기록하고 팀 내에서 재발 방지 조치를 논의합니다. 포스트모텀 없이 끝내면 같은 장애가 반복될 수 있기 때문입니다. 앞으로도 장애 대응을 할 때 복구 우선 → 원인 분석 나중의 순서를 지키겠습니다.
온콜에서 가장 나쁜 것은 복구를 미루고 원인을 먼저 파는 것이라고 생각합니다.
장애 상황에서 저는 격리와 복구의 우선순위를 RTO 기준으로 판단합니다. 서비스별로 허용 다운타임이 다르기 때문에, 같은 장애라도 어떤 서비스냐에 따라 접근 방식이 달라집니다. 배포 후 에러율이 급등했을 때, Circuit Breaker가 열리기 전에 Feature Flag를 OFF로 내리는 게 먼저라고 판단했습니다. 근본 원인을 파기 전에 트래픽 영향을 차단하는 것이 우선이었습니다. 복구 이후엔 재현 조건을 기록하고 타임라인을 팀과 공유했습니다.
롤백이 가능한지 여부보다 현재 상태가 더 나쁜지를 먼저 판단하는 것, 그 기준이 장애 대응 속도를 결정한다고 생각합니다. RPO 시점 기준으로 스냅샷을 복원할지 앞으로 완화할지도 그 판단의 연장선입니다.
경험상 탐지가 느릴 때 장애 피해가 가장 커집니다. 이상 징후가 있었는데 알림 임계값이 느슨하게 설정돼 대응이 늦어진 적이 있었고, 그 이후로는 탐지 단계의 알림 기준을 가장 먼저 점검합니다. 격리는 blue-green 구조에서 구 버전으로 스위칭하거나 특정 기능을 Feature Flag로 차단하는 방식을 우선 고려합니다. DB 마이그레이션이 포함된 경우엔 RPO 시점 기준으로 스냅샷을 복원할지, 앞으로 완화할지를 먼저 결정합니다. 복구 후 포스트모텀은 24~48시간 내에 작성하는 게 원칙이었는데, 이 시간이 빠를수록 타임라인이 더 정확했습니다.
격리 → 진단 → 복구 → 재발 방지 순서를 지키는 것이 이후 장애에서도 판단 속도를 높여줬습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 채널톡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.