MTTD·MTTR 완전정복: 장애 대응 속도를 2배 끌어올리는 법

🚨 왜 MTTD·MTTR가 중요한가?

서비스가 멈추는 순간, 사용자는 단 3초 만에 떠난다고 합니다. MTTD(Mean Time to Detect)와 MTTR(Mean Time to Recovery)는 ‘얼마나 빨리 발견하고, 얼마나 빨리 복구했는가’를 숫자로 증명해 주는 핵심 지표입니다. 쿠팡, 토스, 배달의민족 같은 국내 빅테크들도 SRE 팀의 KPI로 가장 먼저 챙기는 항목이죠.

---

1. MTTD ― 장애를 눈치채는 속도

• 정의: 장애가 발생한 시점부터 모니터링 시스템이 경고를 띄우거나 엔지니어가 인지할 때까지 걸린 평균 시간.
• 공식: Σ(감지 시간 − 발생 시간) / 장애 건수.
• 팁
  1. 풀스택 모니터링: 애플리케이션 로그 + 인프라 메트릭 + 사용자 RUM(Real-User Monitoring)을 한 대시보드로 합치면 경계시간이 짧아집니다.
  2. AI 알림 필터링: Kagiso·PagerDuty의 노이즈 억제 기능을 쓰면 중요 알림만 살려 MTTD를 줄일 수 있습니다.

---

2. MTTR ― 서비스가 다시 숨 쉬는 시간

• 정의: 장애 감지 시점부터 정상 운영 재개까지의 평균 시간. “Repair”·“Resolve” 두 용어가 혼용되지만, 목표는 동일—빨리 복구.
• 공식: Σ(복구 완료 시간 − 감지 시간) / 장애 건수.
• 4단계 분해
  1. Triaging: 원인 범주를 추려내는 1차 분류
  2. Diagnosing: 로그·메트릭·트레이스 분석으로 근본 원인 파악
  3. Fixing: 코드 롤백, 설정 변경, 스케일 아웃 등 실제 조치
  4. Validating: 모니터링 지표 정상화 확인 후 트래픽 100% 전환
     단계별 자동화가 많을수록 MTTR이 기하급수적으로 줄어듭니다.

---

3. 실무 사례로 보는 지표 개선 🔍

• 토스 페이먼츠: 카드결제 API 장애를 겪은 뒤, MTTD 30초 → 5초, MTTR 18분 → 3분으로 단축.
  • 비결:
    • A/B 테스트 트래픽 모니터링으로 ‘비정상 패턴’ 빠르게 탐지
    • K8s 롤백용 GitOps 파이프라인을 구축해 1-클릭 복구
• 배달의민족: 라이더 매칭 지연 이슈를 발견하고 MTTD 1분, MTTR 8분에 해결.
  • 비결:
    • Kafka 지연률을 SLO로 관리, 임계값 초과 시 Slack·전화·SMS 동시 알림
    • 미리 준비한 ‘스케줄러 재시작 플레이북’으로 인시던트 대응

---

4. MTTD·MTTR를 낮추는 5가지 실천 팁

1. SLO-기반 알림: 임계값(예: 성공률 99.9%)을 넘길 때만 알림을 쏴 알림 피로도를 줄인다.
2. 플레이북 자동화: 자주 터지는 장애 패턴은 Runbook Automation(Action Run)이 대응한다.
3. 블루-그린/카나리 배포: 문제 버전을 실시간으로 격리해 MTTR을 최소화.
4. 카오스 엔지니어링: 실전 같은 장애 연습으로 Triaging 속도를 단축.
5. 사후 분석(포스트모템): ‘누구 잘못’ 대신 ‘프로세스 개선’에 초점을 맞춰 재발 방지.

---

5. 결론 ✍️

MTTD와 MTTR는 단순 수치가 아니라 팀 문화와 자동화 수준을 비추는 거울입니다.

• MTTD를 줄이려면? 모든 계층의 메트릭을 한눈에 보여주는 관측 가능성(Observability) 강화.
• MTTR를 줄이려면? 반복 가능한 절차를 스크립트·파이프라인으로 자동화하라.
  두 지표를 꾸준히 개선하면 서비스 신뢰도가 상승하고, 결국 매출과 고객 충성도로 돌아옵니다.