5편 · 약 26분

온콜 운영과 번아웃 방지: 에스컬레이션, 로테이션, 알림 피로

온콜은 운이 아닌 설계다

새벽 3시에 울리는 호출음이 DBA나 플랫폼 엔지니어의 일상에서 낯선 일이 아니다. 데이터베이스는 사람이 자는 시간에도 멈추지 않고, 파이프라인은 야간 배치 중에 실패한다. 문제는 온콜 자체가 아니라 온콜 운영 방식이다.

잘못 설계된 온콜은 세 가지 결과를 만든다. 첫째, 엔지니어가 빠르게 소진된다. 2024 State of Engineering Management Report에 따르면 65%의 엔지니어가 지난 1년 내에 번아웃을 경험했다고 응답했다. 둘째, 알림 피로(alert fatigue)가 쌓이면 진짜 중요한 신호를 놓친다. 셋째, 온콜 부담이 특정 몇 사람에게 집중되면 버스 팩터(bus factor)가 낮아지고 팀 전체가 취약해진다.

구조를 잡으면 달라진다. 로테이션, 알림 품질, 런북, 에스컬레이션 정책, 문화적 안전망을 체계적으로 갖추면 온콜이 소수의 영웅 의존에서 팀이 지속 가능하게 운영하는 시스템으로 바뀐다.

온콜 로테이션 모델

로테이션 설계는 커버리지 범위, 팀 규모, 지역 분포에 따라 달라진다.

Primary / Secondary 모델

가장 일반적인 구조다. Primary(1차)가 먼저 호출을 받고, 설정된 시간(보통 5~15분) 안에 응답하지 않으면 Secondary(2차)로 에스컬레이션된다.

Primary: 해당 주의 직접 대응 담당자
Secondary: 백업이자 Escalation 대상
Tertiary(3차): 매니저 또는 스페셜리스트

Primary/Secondary 구조는 단일 온콜의 부담을 분산하고 업무 지식이 여러 사람에게 퍼지도록 강제한다.

Follow-the-Sun 모델

글로벌 팀이 있을 때 사용한다. 지역(예: APAC, EMEA, AMER)이 시간대를 나눠 각자 업무 시간대에 온콜을 맡는다. 새벽 호출이 없어지고 에스컬레이션이 자연스럽게 다음 지역으로 흐른다.

단점은 인수인계(handoff) 품질에 크게 의존한다는 점이다. 지역 간 컨텍스트 공유가 부실하면 진행 중인 장애 대응이 단절된다.

Shadow 온콜

신규 엔지니어나 팀 합류자를 위한 학습 모드다. Shadow는 Primary와 함께 모든 호출을 받지만 직접 대응하지는 않는다. Google SRE 권고에 따르면 최소 5건 이상의 인시던트를 Shadow로 경험한 후에야 Primary로 전환한다. 이 접근법은 예상 불안(anticipatory anxiety)을 80% 수준 감소시키는 것으로 알려져 있다.

최소 팀 규모

Google SRE 북은 구체적인 수치를 제시한다.

단일 사이트 24/7 커버리지: 최소 8명
복수 사이트 Follow-the-Sun: 사이트당 최소 5명

5명 미만이 24/7을 커버하면 개인당 호출 빈도가 급격히 늘어 번아웃이 가속된다.

알림 피로(Alert Fatigue)

알림 피로는 의미 없는 호출이 반복될 때 온콜 엔지니어가 신호를 무시하게 되는 상태다. 노이즈가 신뢰성 문제보다 더 위험한 이유가 여기에 있다.

측정 기준

알림 피로 지표

actionable rate = 실제 조치가 필요한 알림 수 / 전체 알림 수 × 100

- < 10%: 심각한 노이즈 — 알림 전체 감사 필요
- 30~50%: 건강한 수준
- > 70%: 알림 설계가 잘 된 상태

일부 팀은 주간 2,000건 이상의 알림을 받으며 그 중 3%만이 즉각 조치를 요구한다. Google SRE Workbook은 온콜 한 교대(shift)에서 최대 2~3건의 actionable 인시던트를 지속 가능한 수준으로 본다.

알림 피로의 원인

원인	설명	해결 방향
임계값 너무 낮음	CPU 70% 초과마다 알림	SLO burn rate 기반으로 전환
자동 복구 없는 알림	일시적 오류에도 페이지	auto-resolve 설정, flap detection
알림 중복	같은 증상에 여러 알림	알림 그루핑, correlation
정보 부재 알림	무엇을 봐야 하는지 모름	런북 링크 필수화
비업무 시간 낮은 심각도 알림	야간에 P3 알림 전송	심각도별 시간대 라우팅

SLO 기반 알림과 Burn Rate Alert

증상 기반 알림("CPU > 80%")은 사람이 행동해야 하는 시점을 정확히 포착하지 못한다. SLO 기반 알림은 에러 버짓이 얼마나 빠르게 소진되는지를 본다.

Burn Rate = 실제 에러 소비율 / 허용 에러 소비율

SLO = 99.9% (에러 버짓 = 0.1%)
28일 기준 정상 소비율 = 1x (burn rate = 1)

burn rate = 14 → 에러 버짓이 1시간 내 소진될 속도
burn rate = 1  → 정상 소비

멀티 윈도우 알림 전략

구글이 권장하는 방식이다. 긴 윈도우로 검출하고 짧은 윈도우로 최신성을 확인한다.

알림 종류	윈도우	burn rate	페이지 여부
빠른 번 (P0/P1)	1h / 5m	≥ 14x	즉각 페이지
느린 번 (P2)	6h / 30m	≥ 6x	업무 시간 알림
주간 번 (P3)	3d / 6h	≥ 3x	티켓 생성

에스컬레이션 정책 설계

에스컬레이션 정책은 "누구에게, 언제, 어떤 순서로 연락하는가"를 정의한다.

🔔 알림 발생

→

Primary 온콜
0~5분

→

응답 없음
5분 경과

→

Secondary 온콜
5~15분

→

응답 없음
15분 경과

→

매니저/TL
15~30분

에스컬레이션 원칙

✓ P0은 병렬 에스컬레이션
✓ 각 단계에 명확한 SLA
✓ auto-escalate 설정
✓ 휴가/부재 시 자동 대체
✓ 에스컬레이션 이력 기록

에스컬레이션 정책 흐름

병렬 에스컬레이션

P0/SEV1 인시던트에서는 순차 에스컬레이션이 시간을 낭비한다. Primary가 응답하지 않을 때를 기다리는 5분은 치명적일 수 있다. P0에는 Primary와 Secondary를 동시에 호출하고 먼저 응답한 사람이 IC(Incident Commander) 역할을 맡는다.

MTTA / MTTR 측정과 목표

온콜 운영 품질은 시간 지표로 측정한다.

지표	정의	P1 목표
MTTD (Mean Time to Detect)	문제 발생 → 알림 수신	알림 설정으로 결정
MTTA (Mean Time to Acknowledge)	알림 수신 → 담당자 확인	업무 시간 < 3분, 야간 < 8분
MTTR (Mean Time to Resolve)	알림 수신 → 정상 복구	P1 목표 60분 이내

MTTR 60분의 일반적인 시간 분포:

MTTR 분해 (P1 중앙값 기준)
─────────────────────────────────
탐지 후 컨텍스트 수집    12분   (20%)
원인 진단               20분   (33%)
완화 조치 실행           4분   ( 7%)
사후 정리 및 검증        12분   (20%)
기타 (협의, 커뮤니케이션) 12분   (20%)
─────────────────────────────────
합계                    60분

잘 갖춰진 팀은 컨텍스트 수집 시간을 2~3분으로 줄인다. 서비스 카탈로그(소유자, 의존성, 최근 배포, 건강 지표)를 자동으로 불러오는 환경이 이를 가능하게 한다.

런북(Runbook) 설계

런북은 온콜 엔지니어가 알림을 받은 직후 따라갈 수 있는 절차서다. 좋은 런북은 "내가 잠에서 깨어나 처음 30초 안에 무엇을 할지"를 알려준다.

런북에 반드시 포함할 요소

항목	내용
알림 설명	이 알림이 의미하는 것
즉각 확인 대시보드	링크 1~2개
첫 번째 체크 포인트	확인할 명령어 또는 쿼리
완화 옵션	빠른 임시 조치(재시작, 트래픽 이동 등)
에스컬레이션 기준	언제 다음 단계로 넘길지
관련 포스트모텀	과거 유사 사례 링크

런북 품질 유지

알림이 발화할 때마다 런북 링크를 알림 메시지에 포함한다
분기마다 런북을 리뷰하고 오래된 명령어나 링크를 수정한다
인시던트 후 "런북이 충분했는가"를 포스트모텀에서 점검한다
최소 상위 10개 인시던트 유형에 대한 런북을 먼저 갖춘다

지속 가능한 온콜 문화

Google SRE 50% 규칙

Google SRE 북은 SRE 엔지니어의 온콜 업무가 전체 시간의 25% 이하여야 한다고 명시한다. 나머지 75%는 프로젝트 작업, 자동화, 시스템 개선에 써야 한다. 온콜이 50%를 초과하면 구조적으로 문제가 있는 것이다.

이 원칙을 지키는 방법은 단순히 팀을 늘리는 게 아니다. 알림 노이즈를 줄이고, 반복 인시던트를 자동화하고, 토일을 제거하는 것이 먼저다.

온콜 보상과 인정

비업무 시간 호출에 대한 보상이 없는 팀은 암묵적으로 "너의 시간은 중요하지 않다"는 메시지를 보낸다. 보상 방식은 조직마다 다르지만 명확한 정책이 있어야 한다.

시간 보상: 야간 호출 1건당 N시간 대체 휴가
금전 보상: 온콜 수당
노출 제한: 연속 온콜 주 제한 (예: 월 2주 초과 금지)

인수인계(Handoff) 프로토콜

온콜 교대 시 정보가 끊기지 않도록 구조화된 핸드오프가 필요하다.

온콜 핸드오프 체크리스트
─────────────────────────
□ 진행 중인 인시던트 현황
□ 최근 배포 / 변경 사항
□ 현재 조용히 진행 중인 이슈 (눈에 띄지 않지만 주시 중인 것)
□ 예정된 유지보수 작업
□ 이번 주 주의해야 할 용량/트래픽 변화
□ 런북 or 에스컬레이션 경로 변경사항
─────────────────────────

온콜 부하 측정

지표	설명	경보 수준
주간 페이지 수 / 1인	Primary 1명이 받는 주간 호출 수	> 5건 재검토 필요
야간(22~06시) 페이지 비율	전체 페이지 중 야간 비율	> 20% 위험
자동 해결 비율	사람 개입 없이 auto-resolve된 비율	< 40% 재설계
중복 페이지 비율	같은 원인의 반복 알림 비율	> 15% 알림 정비

DBA·데이터 엔지니어 온콜 특수 고려사항

데이터베이스와 파이프라인 온콜은 일반 서비스 온콜과 다른 점이 있다.

데이터 손실 위험 판단: 장애가 데이터 손실을 수반하는지 즉시 판단해야 한다. 판단 기준(WAL 유실 여부, binlog 간격 확인 절차 등)을 런북에 미리 명시한다.

복구 시간의 불확실성: 백업 복구나 PITR은 데이터 크기에 따라 수 시간이 걸릴 수 있다. 초기 예상 시간을 팀과 공유하되 보수적으로 제시한다.

읽기/쓰기 분리 고려: 복제 지연이 있을 때 replica에서 읽던 서비스가 영향을 받는지, primary에서 읽도록 전환할 수 있는지를 런북에 포함한다.

배치 파이프라인 실패: 새벽 배치가 실패한 경우 즉각 대응이 필요한지 아침까지 기다려도 되는지 기준을 미리 정한다. SLA가 없는 파이프라인에서 새벽 호출을 없애는 것만으로도 온콜 부하가 크게 줄 수 있다.