SRE 실무 #4 온콜 운영: 로테이션, 에스컬레이션, 부담 관리

경보 시스템이 아무리 좋아도, 그 페이지를 받는 것은 결국 사람입니다. 온콜(on-call)은 SRE 실무에서 가장 사람 냄새 나는 영역이고, 잘못 운영하면 가장 확실하게 사람을 태워 버리는 영역이기도 합니다. 이번 편은 온콜을 지속 가능한 제도로 만드는 설계 요소들을 다룹니다.

로테이션: 최소 인원부터 계산합니다 #

온콜 로테이션의 첫 질문은 “몇 명이 필요한가"입니다. 답은 생각보다 큽니다.

• 24시간 365일을 한 사람이 감당하는 것은 로테이션이 아니라 인질극입니다. 휴가, 병가, 퇴사를 고려하면 한 로테이션에 최소 5〜6명이 현실적인 하한입니다. 그보다 적으면 온콜 주기가 너무 빨리 돌아와서 소진이 시작됩니다.
• 인원이 안 되는 작은 팀은 로테이션을 억지로 만들기보다, 여러 팀이 서비스 그룹을 묶어 공동 온콜을 서거나, 업무 시간 외에는 페이지 대상을 최소화하는 쪽이 정직한 선택입니다.

근무 편성은 두 형태가 기본입니다.

• 주 단위 교대(일 통짜): 한 사람이 일주일간 24시간 온콜. 단순하지만 야간 페이지 부담이 크므로, 야간 페이지가 드문 팀에 적합합니다.
• 일과·야간 분리 또는 시간대 분산(follow-the-sun): 지역이 분산된 조직이라면 각 지역이 자기 낮 시간만 커버하는 것이 이상적입니다. 야간 호출 자체가 사라집니다.

어느 형태든 1차(primary)와 2차(secondary)를 둡니다. 1차가 응답하지 못하는 상황(이동 중, 중복 장애)의 백업이자, 신규 멤버가 2차로 먼저 경험을 쌓는 훈련 경로가 됩니다.

에스컬레이션: 막혔을 때의 경로를 미리 그립니다 #

에스컬레이션 정책은 “누가, 언제, 누구에게 도움을 요청하는가"의 사전 합의입니다.

1. 자동 에스컬레이션: 페이지에 N분간 응답(ack)이 없으면 호출 도구가 자동으로 2차 → 팀 리드 순으로 올립니다. 사람이 잠들었거나 신호가 없는 상황은 반드시 생기므로, 이 체인은 도구 설정으로 강제되어야 합니다.
2. 판단 에스컬레이션: 응답은 했지만 30분간 진전이 없거나 영향 범위가 커지면, 다른 팀·상위 대응 체계를 부릅니다. 여기서 중요한 문화가 하나 있습니다. 에스컬레이션은 실패가 아니라 절차입니다. “혼자 더 붙잡고 있었어야 했는데"라는 분위기가 있는 조직에서는 장애 시간이 늘어납니다.
3. 인시던트 지휘 체계: 영향이 큰 장애에서는 역할을 분리합니다. 지휘자(incident commander)는 조율과 의사결정만, 실무자는 조치만, 커뮤니케이터는 상황 공유만 맡습니다. 조치하는 사람이 동시에 보고 문서를 쓰는 구조는 양쪽 다 망칩니다.

핸드오프: 교대는 문서로 넘깁니다 #

교대가 바뀔 때 구두 인사만으로 넘기면, 진행 중이던 이슈의 맥락이 사라집니다. 핸드오프는 짧더라도 형식을 갖춥니다.

• 진행 중인 인시던트와 현재 상태, 다음 확인 시점
• 이번 교대에 울린 페이지 요약과 처리 결과
• 예정된 위험 요소(대형 배포, 마이그레이션, 트래픽 이벤트)
• 조용했던 경우에도 “조용했음"을 명시 (기록이 없는 것과 문제가 없는 것은 다릅니다)

주간 단위 로테이션이라면 팀 회의에서 5분짜리 안건으로 고정하는 것이 가장 지속 가능한 형태입니다.

부담 관리: 페이지 건수에 상한을 둡니다 #

온콜이 무너지는 것은 극적인 대형 장애 때문이 아니라, 잔잔한 페이지가 매일 밤 이어지는 만성 상태 때문입니다. 그래서 부담을 숫자로 관리합니다.

• 교대당 페이지 건수를 추적합니다. 이 숫자가 지속적으로 임계값(예: 12시간 교대에 2건)을 넘으면, 개인의 인내가 아니라 시스템의 문제로 취급합니다. 원인은 둘 중 하나입니다. 경보 품질이 나쁘거나(3편의 오탐 정리 대상), 시스템의 신뢰성 부채가 실제로 크거나(엔지니어링 투자 대상).
• 온콜 중에는 프로젝트 업무를 기대하지 않습니다. 온콜 교대의 산출물은 대응, 그리고 대응 과정에서 발견한 문제의 기록입니다. 온콜자에게 평소와 같은 스프린트 커밋을 요구하는 조직은 둘 중 하나를 몰래 포기하게 만듭니다.
• 후속 작업 시간을 제도화합니다. 온콜 주간에 발견된 문제(부정확한 런북, 반복되는 수동 복구)를 갚는 시간을 다음 스프린트에 명시적으로 배정합니다. 이것이 없으면 같은 페이지가 매달 반복됩니다.

보상도 부담 관리의 일부입니다. 야간·주말 대기가 무급 봉사인 조직에서 온콜 기피는 도덕 문제가 아니라 합리적 선택입니다. 온콜 수당, 대체 휴가 등 형태는 조직마다 다르지만, 대기의 비용을 조직이 인정하는 것 자체가 제도의 지속 가능성을 결정합니다.

온콜자의 30분: 런북이 있어야 하는 이유 #

페이지를 받은 온콜자의 첫 30분은 대략 정해져 있습니다. 확인(ack) → 영향 파악(SLI 대시보드) → 최근 변경 확인(배포, 설정) → 완화(롤백, 스케일 아웃, 트래픽 차단) → 필요시 에스컬레이션. 이 흐름에서 온콜자가 갖춰야 할 것은 시스템 전체에 대한 깊은 지식이 아니라, 경보별 런북과 진단의 순서입니다.

런북에 최소한 담을 것은 세 가지입니다. 이 경보의 의미(어느 SLI가 왜), 첫 확인 항목(대시보드 링크, 최근 배포 확인 명령), 그리고 검증된 완화 수단(롤백 절차, 기능 플래그). 완벽한 원인 규명은 낮에 해도 됩니다. 새벽의 목표는 진단이 아니라 사용자 영향의 중단입니다.

정리 #

• 로테이션은 최소 5〜6명이 하한입니다. 인원이 안 되면 공동 온콜이나 커버 범위 축소가 정직한 답입니다. 1차·2차 구조는 백업이자 훈련 경로입니다.
• 에스컬레이션은 자동(무응답 시)과 판단(진전 없음)의 두 층으로 설계하고, 에스컬레이션을 실패로 여기지 않는 문화를 만듭니다.
• 핸드오프는 짧은 형식 문서로 고정합니다. 조용했다는 기록도 기록입니다.
• 교대당 페이지 건수에 상한을 두고, 초과가 지속되면 경보 품질 또는 신뢰성 부채의 문제로 승격합니다. 온콜 중 프로젝트 업무를 기대하지 않고, 후속 작업 시간을 제도화합니다.
• 새벽 대응의 목표는 원인 규명이 아니라 영향 중단입니다. 그래서 런북이 필수입니다. 다음 편은 그 장애가 끝난 뒤의 일, 포스트모템입니다.