이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 장애 탐지는 왜 사용자 영향 기준으로 정리해야 하는가?
- Severity는 어떤 기준으로 분류해야 하는가?
- Spring 백엔드 장애에서 탐지 신호와 Severity를 어떻게 연결하는가?
개요
장애 탐지는 시스템이 이상하다는 사실을 운영자가 알아차리는 과정이다.
Severity 분류는 그 이상이 얼마나 급하고 넓은 영향을 가지는지 결정하는 과정이다.
두 작업은 원인 분석보다 먼저 일어난다.
원인을 모르는 상태에서도 사용자가 결제하지 못하는지, 로그인하지 못하는지, 일부 API만 느린지 판단해야 한다.
백엔드 개발자는 로그나 stack trace를 보는 데서 멈추지 않고 사용자 기능과 연결해 설명해야 한다.
탐지 신호의 종류
운영에서 장애 탐지는 여러 신호를 함께 본다.
- 사용자 신고: 특정 기능이 실패한다고 사용자가 먼저 알린다.
- 오류율 증가: 4xx/5xx 중 비정상 패턴이 증가한다.
- 응답 시간 증가: p95, p99가 평소보다 커진다.
- 처리량 변화: 주문, 결제, 회원가입 같은 핵심 이벤트 수가 급감한다.
- 큐 적체: consumer가 따라가지 못해 메시지가 쌓인다.
- 외부 의존성 오류: 결제, 인증, 파일 저장, 메일 발송 연동이 실패한다.
- 배치 실패: 정산, 알림, 데이터 보정 작업이 실패한다.
하나의 신호만으로 Severity를 확정하지 않는다.
오류율이 낮아도 결제 API만 실패하면 높은 Severity일 수 있다.
사용자 영향 기준
Severity는 내부 구현보다 사용자 영향으로 정한다.
예시 기준은 다음과 같다.
SEV-1: 핵심 서비스 전체 중단, 데이터 손실, 결제/로그인 전체 실패
SEV-2: 핵심 기능 일부 실패, 큰 고객군 영향, 우회가 제한적
SEV-3: 제한된 기능 실패, 우회 가능, 일부 사용자 영향
SEV-4: 내부 도구 문제, 사용자 영향 없음, 업무 시간 내 처리 가능이 기준은 조직마다 달라질 수 있지만 문서에는 반드시 숫자와 사례가 있어야 한다.
“심각해 보인다”가 아니라 “주문 생성 실패율이 15분간 20%이고 우회가 없다”처럼 판단해야 한다.
Spring 백엔드 관점
Spring 백엔드에서는 다음 신호가 Severity 판단에 자주 쓰인다.
http.server.requests에서 특정 endpoint의 실패율이 증가한다.- controller까지 요청이 도달하지 못한다.
- DB connection pool 사용량이 포화된다.
- 특정 transaction에서 timeout이 반복된다.
- 외부 API client의 retry가 증가한다.
- 스케줄 작업이나 batch job이 실패한다.
- outbox event나 message consumer가 밀린다.
중요한 것은 기술 신호를 기능 영향으로 번역하는 것이다.
예를 들어 DB timeout은 원인 후보이고, 주문 생성 실패는 사용자 영향이다.
Severity 문서에는 둘 다 필요하지만 우선순위는 사용자 영향이 결정한다.
탐지 예시
탐지 시각: 2026-07-01 10:12 KST
탐지 경로: 주문 생성 실패율 증가 알림
사용자 영향: 주문 생성 API 10분간 실패율 18%, 결제 승인 이후 주문 저장 실패 가능
영향 범위: 모바일 앱 전체, 웹 주문은 정상
임시 분류: SEV-2
근거: 핵심 기능 영향, 우회 제한, 데이터 정합성 확인 필요
다음 확인: 최근 배포, DB connection pool, 결제 승인 로그, 주문 저장 로그이 기록은 완벽한 원인 분석이 아니다.
장애 초기에 필요한 것은 현재 판단을 공유하고 다음 확인 대상을 줄이는 것이다.
Severity 조정
Severity는 한 번 정하면 끝나는 값이 아니다.
새 정보가 나오면 올리거나 내릴 수 있다.
- 영향 범위가 일부 사용자에서 전체 사용자로 넓어지면 올린다.
- 데이터 손실 가능성이 확인되면 올린다.
- 우회 경로가 안정적으로 동작하면 내릴 수 있다.
- 핵심 기능 실패가 내부 관리자 기능 문제로 확인되면 내릴 수 있다.
- 장애가 장시간 지속되면 같은 증상도 더 높은 긴급도가 된다.
Severity 변경 시에는 변경 시각과 근거를 남긴다.
운영 체크리스트
- 탐지 시각과 장애 시작 추정 시각을 구분한다.
- 사용자가 못 하는 일을 한 문장으로 적는다.
- 영향 기능, 영향 사용자군, 우회 가능성을 확인한다.
- 오류율과 응답 시간보다 핵심 이벤트 성공률을 같이 본다.
- 최근 배포, 설정 변경, 배치 실행을 시간대에 맞춰 확인한다.
- 임시 Severity와 다음 업데이트 시간을 공유한다.
- Severity 변경 시 변경 근거를 타임라인에 남긴다.
장애 신호
- 내부 지표는 정상인데 사용자 신고가 반복된다.
- 전체 오류율은 낮지만 특정 핵심 API만 실패한다.
- 알림이 너무 많아 실제 장애 신호가 묻힌다.
- 담당자마다 Severity 기준이 달라 대응 우선순위가 흔들린다.
- 장애 시작 시각과 탐지 시각이 크게 벌어진다.
- 복구 후에도 영향을 받은 사용자 수를 설명하지 못한다.
이 신호는 탐지 체계와 Severity 기준을 개선해야 한다는 뜻이다.
안전한 완화 조치
- Severity가 불명확하면 낮게 잡기보다 사용자 영향 기준으로 보수적으로 올린다.
- 원인 분석이 길어지면 먼저 영향 기능을 제한하거나 우회 경로를 안내한다.
- 알림이 과도하면 대응 채널에는 대표 신호와 사용자 영향만 고정한다.
- 핵심 이벤트 성공률을 별도로 계산해 복구 판단 근거로 쓴다.
- 데이터 손실 가능성이 있으면 관련 쓰기 작업을 멈추고 범위를 확인한다.
완화는 원인 확정보다 사용자 영향 축소에 초점을 둔다.
하지 말아야 할 대응
- stack trace가 복잡하다는 이유만으로 Severity를 높이지 않는다.
- 사용자 영향이 큰데 내부 지표가 적다는 이유로 Severity를 낮추지 않는다.
- 여러 사람이 각자 다른 채널에서 Severity를 선언하지 않는다.
- 원인을 확정하기 전까지 아무 조치도 하지 않는 상태로 두지 않는다.
- 탐지 시각을 장애 시작 시각처럼 기록하지 않는다.
인프라 담당자와 공유할 자료
- 탐지 시각, 시작 추정 시각, 임시 Severity
- 사용자 영향 설명과 핵심 기능 여부
- 오류율, 응답 시간, 처리량, 큐 적체 등 대표 신호
- 최근 배포와 설정 변경 시간
- 의심 endpoint, DB, 외부 의존성
- 현재 완화 조치와 기대하는 회복 신호
공유 자료는 “무언가 이상하다”가 아니라 “이 기능이 이 범위에서 실패한다”로 정리되어야 한다.
확인 질문
확인 질문
- Severity를 내부 원인보다 사용자 영향으로 정해야 하는 이유는 무엇인가?
- 대응 우선순위는 기술 난이도가 아니라 실제 서비스 영향과 긴급도로 결정되기 때문이다.
- 탐지 시각과 장애 시작 시각을 구분해야 하는 이유는 무엇인가?
- 탐지 지연을 알 수 있고 영향 범위와 Postmortem 분석이 정확해지기 때문이다.
- Spring 백엔드 장애에서 기술 신호를 어떻게 번역해야 하는가?
- DB timeout, API 실패율, 큐 적체를 주문 실패, 로그인 실패, 발송 지연 같은 사용자 영향으로 연결해야 한다.
리뷰 체크포인트
- Severity 기준에 사용자 영향 사례가 들어 있는가?
- 탐지 신호와 사용자 기능 영향이 연결되어 있는가?
- Severity 변경 기준과 기록 방식이 있는가?
- 장애 시작 시각과 탐지 시각을 따로 남기는가?
- 복구 판단에 사용할 대표 신호가 정해져 있는가?