소규모 팀을 위한 온콜 로테이션: 단계별 설정 가이드
Sang Lee
August 13, 2026
소규모 팀의 온콜 로테이션은 특정 엔지니어가 정해진 시간 동안 운영 환경의 알림에 대응하도록 지정하고, 정해진 주기에 따라 업무를 교대하는 방식입니다. 이러한 체계가 없으면 알림을 먼저 발견한 사람이 대응하게 되는데, 이는 알림 누락, 대응 지연, 그리고 특정 인원에게 업무가 과도하게 집중되는 결과를 초래합니다. 이 가이드에서는 4~10명 규모의 팀을 위해 첫 온콜 로테이션을 단계별로 설정하는 방법을 안내합니다.
핵심 요약: 소규모 팀의 온콜 로테이션이란 운영 환경의 알림에 대응할 담당자를 명확히 지정하고, 정해진 주기에 따라 다음 담당자에게 업무를 인계하는 공개된 일정표를 의미합니다. 4~10명 규모의 팀이라면 1명의 주 담당자와 1명의 보조 담당자를 두고, 문서화된 에스컬레이션 경로와 합의된 대응 시간 목표를 설정하는 것이 가장 효율적입니다. 공유 캘린더와 페이징 도구만 있으면 오후 시간 내에 구축할 수 있으며, 팀이 성장함에 따라 점차 체계화해 나갈 수 있습니다.
개요
이 가이드에서는 다음 내용을 순서대로 다룹니다:
- 소규모 팀이 예상보다 빨리 온콜 로테이션을 도입해야 하는 이유
- 1단계: 로테이션 참여 인원 결정하기
- 2단계: 팀 규모에 맞는 로테이션 주기 선택하기
- 3단계: 주 담당자, 보조 담당자 및 에스컬레이션 경로 정의하기
- 4단계: 현실적인 대응 시간 목표 설정하기
- 5단계: 업무 인계 절차 및 런북 작성하기
- 6단계: 페이징 도구 선택 및 알림 연동하기
- 7단계: 사기 저하 없이 지속 가능한 온콜 환경 만들기
- 첫 로테이션 설정 시 피해야 할 사항
- 자주 묻는 질문(FAQ) 및 방법론 참고 사항
소규모 팀이 예상보다 빨리 온콜 로테이션을 도입해야 하는 이유
흔히들 "우리 팀은 규모가 작아서 공식적인 온콜(on-call) 체계가 필요 없다"고 말합니다. 하지만 이는 완전히 잘못된 생각입니다. 소규모 팀일수록 여유 인력이 부족하기 때문에, 관리되지 않는 장애가 발생하면 그 타격이 훨씬 큽니다. 온콜 로테이션이 없으면 결국 눈에 띄는 사람이 모든 일을 떠맡게 됩니다. 결과적으로 책임감 강한 한두 명의 팀원이 새벽 3시마다 울리는 호출을 모두 감당하다가 결국 번아웃되어 퇴사하는 상황이 벌어집니다.
소규모 팀이 로테이션을 도입하면 세 가지 이점이 있습니다. 첫째, 대응 체계가 예측 가능해집니다. 둘째, 대응 시간을 측정할 수 있게 됩니다. 셋째, 업무 부하를 분산시켜 특정 개인이 단일 장애 지점이 되는 것을 방지합니다. 이는 관료주의를 더하는 것이 아닙니다. 암묵적이고 불공정한 관행을 명확하고 공정한 체계로 바꾸는 것입니다.
2027년이 되면 온콜 책임제는 대기업만의 성숙도 지표가 아니라, 수익과 직결된 서비스를 운영하는 모든 팀에게 필수적인 기본 요건이 될 것입니다.
1단계: 로테이션에 참여할 인원 확정하기
운영 환경의 장애 알림에 실질적으로 대응할 수 있는 모든 엔지니어를 나열하세요. 여기서 '실질적'이라는 기준이 중요합니다. 호출을 확인하고, 초기 진단 단계를 수행하며, 직접 해결하거나 상위 단계로 에스컬레이션할 수 있는 사람이어야 합니다. 아직 배포나 대시보드 확인이 익숙하지 않은 신입 사원은 로테이션에 바로 투입하기보다, 충분히 섀도잉(shadowing) 과정을 거친 뒤에 참여시켜야 합니다.
팀원이 4~10명이라면 최소 4명은 기본 로테이션에 포함하는 것을 목표로 하세요. 4명 미만이면 온콜 주기가 너무 잦아져 휴가나 질병 시 대응할 여력이 없어집니다. 만약 자격을 갖춘 인원이 3명뿐이라면 로테이션은 유지하되 교대 주기를 짧게 잡고, 대응 공백이 발생할 수 있음을 인정하고 이에 대한 계획을 명확히 세워야 합니다.
2단계: 팀 규모에 맞는 로테이션 주기 정하기
로테이션 주기는 한 사람이 다음 담당자에게 넘기기 전까지 온콜을 유지하는 기간을 의미합니다. 보통 주 단위와 일 단위 중 선택하며, 알림 발생 빈도에 따라 적절한 방식을 결정해야 합니다.
알림 빈도가 낮거나 보통 수준인 소규모 팀에는 주 단위 로테이션이 기본입니다. 일주일간 담당하면 장애 발생 시 끝까지 추적할 수 있는 연속성이 확보되며, 4~6명 규모의 팀이라면 각 엔지니어는 4~6주에 한 번씩 온콜을 맡게 됩니다. 일 단위 로테이션은 알림이 너무 잦아 일주일 내내 담당하는 것이 현실적으로 불가능할 때만 고려하세요.
대부분의 소규모 팀에게는 4~6명의 담당자로 구성된 주 단위 로테이션이 가장 적합합니다. 일 단위 로테이션이나 팔로 더 선(follow-the-sun) 방식은 알림이 너무 많거나 지리적 요인으로 인해 반드시 필요한 경우에만 도입하세요.
3단계: 1차 담당자, 백업, 에스컬레이션 경로 정의하기
백업 없이 한 명만 로테이션을 도는 것은 로테이션이 아니라, 스케줄만 정해진 단일 장애 지점일 뿐입니다. 모든 교대 근무에는 최소 두 단계의 안전장치가 필요합니다.
1차 담당자는 가장 먼저 호출을 받는 엔지니어입니다. 백업(2차 담당자)은 1차 담당자가 보통 5~15분 이내에 호출을 확인하지 않을 경우 자동으로 호출됩니다. 백업 위에는 에스컬레이션 경로가 존재해야 합니다. 1차와 백업 모두 연락이 닿지 않을 때 누구에게 연락할지 정하는 것입니다. 소규모 팀의 경우 보통 엔지니어링 매니저나 지정된 시니어 엔지니어가 이 역할을 맡습니다.
에스컬레이션 경로를 이름과 단계별 확인 제한 시간까지 포함하여 명확히 문서화하세요. "그때그때 주변에 있는 사람에게 연락한다"는 것은 에스컬레이션 경로가 아닙니다.
4단계: 실제로 달성 가능한 대응 시간 목표 설정하기
알림을 확인한 후 실제 작업에 착수하기까지의 속도에 대해 합의하고, 현실적인 목표를 세우세요. 5명 규모의 스타트업에 60초 이내의 SLO(내부 서비스 수준 목표)는 필요하지 않습니다. "5분 이내 확인, 15분 이내 조사 시작" 정도의 목표가 대부분의 소규모 팀에게는 솔직하고 달성 가능한 수준입니다.
첫날부터 두 가지 지표를 추적하세요. 바로 '확인까지 걸리는 시간'과 'MTTR(평균 해결 시간, 알림 발생부터 사고 종료까지의 평균 시간)'입니다. 아직 대시보드는 필요 없습니다. 사고가 발생할 때마다 스프레드시트에 기록하는 것만으로도 현재의 온콜 로테이션이 제대로 작동하는지, 혹은 알림을 놓치고 있지는 않은지 파악하기에 충분합니다.
5단계: 핸드오프 문서와 런북 작성하기
온콜 로테이션에서 가장 위험한 순간은 호출기가 한 사람에게서 다음 사람으로 넘어가는 핸드오프 시점입니다. 우리는 여기서 발생하는 문제를 다음과 같이 부릅니다. 침묵의 핸드오프 공백(Silent Handoff Gap): 교대하는 엔지니어가 불안정한 데이터베이스 복제본에 대해 언급하는 것을 잊어버리면, 새로 교대받은 엔지니어가 새벽 3시에 아무런 정보도 없이 해당 알림을 받게 됩니다. 결국 앞선 사람이 이미 알고 있던 내용을 다시 파악하느라 20분을 허비하게 됩니다.
교대 근무가 끝날 때마다 2분 정도 투자해 서면으로 핸드오프를 진행하세요. 현재 성능이 저하된 부분, 자주 울리는 알림, 다음 담당자에게 넘길 업무 등을 정리하면 됩니다. 여기에 특정 알림에 대응하는 방법을 담은 짧은 문서인 '런북'을 함께 활용하세요. 런북이 완벽할 필요는 없습니다. "이 알림은 보통 X를 의미함; Y 대시보드 확인; 지연 시간이 N을 초과하면 Z 서비스 재시작"과 같은 간단한 지침만으로도 당황스러운 호출을 체크리스트 기반의 작업으로 바꿀 수 있습니다.
6단계: 호출 도구 선택 및 알림 연결하기
공유 캘린더는 누가 온콜 담당인지 알려줄 뿐, 잠을 깨워주지는 못합니다. 이를 위해서는 모니터링 스택에서 알림을 수집하여 누군가 확인할 때까지 전화, 문자, 푸시 알림을 보내는 호출 도구가 필요합니다.
PagerDuty, Opsgenie, incident.io 등이 검증된 선택지입니다. 최근 등장한 AI 기반 플랫폼들은 한발 더 나아가 사람이 호출되기 전에 알림을 먼저 조사하기도 합니다. Vibe OnCall의 경우, 'Tier 0' AI 에이전트 계층을 운영하여 알림을 먼저 분류하고 정보를 보강합니다. 덕분에 새벽 3시에 호출된 엔지니어는 알림 내용만 덩그러니 받는 대신, 무엇이 문제이고 어떻게 해결해야 할지 이미 파악한 상태로 대응을 시작할 수 있습니다. 호출 한 번이 팀원의 소중한 잠을 앗아가는 소규모 팀에게는, 대시보드의 화려한 기능보다 불필요한 호출을 줄이는 것이 훨씬 가치 있습니다.
어떤 도구를 선택하든 알림 라우팅은 특정 개인이 아닌 로테이션 그룹으로 설정하세요. 만약 알림이 '현재 담당자'가 아닌 특정 개인에게 직접 전달되도록 설정하면, 그 사람이 휴가를 가는 순간 온콜 일정은 무너지고 맙니다.
7단계: 온콜을 사기 저하의 원인이 아닌 지속 가능한 업무로 만들기
소규모 팀의 온콜이 실패하는 가장 큰 이유는 도구의 문제가 아니라 번아웃 때문입니다. 특히 주의해야 할 패턴은 다음과 같습니다. 영웅의 함정(Hero Trap) : 뛰어난 엔지니어 한 명이 모든 문제를 조용히 해결하면 팀은 그 사람에게 의존하게 되고, 결국 온콜 업무가 한 사람에게 집중되는 현상입니다. 이 방식은 그 사람이 회사를 떠나기 전까지는 효율적으로 보일 뿐입니다.
의도적으로 피하세요. 적절한 경우 고위직이나 관리자를 포함하여 공정하게 순번을 정하세요. 급여, 대체 휴무, 또는 최소한 힘든 밤을 보낸 후의 보호 휴식 시간 등을 통해 온콜 근무에 대한 보상을 제공하세요. 또한 모든 소음성 알림이나 오탐지 알림을 견뎌야 할 배경 소음이 아닌, 해결해야 할 버그로 취급하세요. 알림 피로가 쌓이면 사람들이 호출기를 무시하기 시작하기 때문입니다.
지속 가능한 온콜은 설계 목표이지, 가장 헌신적인 엔지니어의 성격적 특성이 아닙니다.
첫 온콜 순번을 정할 때 하지 말아야 할 것
다음과 같은 몇 가지 안티 패턴은 다른 무엇보다도 첫 온콜 순번을 실패하게 만듭니다:
- 알림을 특정 개인이 아닌 역할에 할당하세요. 특정인을 지정하면 첫 휴가부터 문제가 발생합니다. 항상 "현재 담당자"에게 호출이 가도록 하세요.
- 혼자서 순번을 돌리지 마세요. 백업이나 에스컬레이션 절차가 없으면, 호출을 한 번이라도 놓치는 순간 사고 대응이 불가능해집니다.
- "모두가 어떻게 작동하는지 안다"는 이유로 런북을 건너뛰지 마세요. 모두가 알고 있다고 생각하지만, 정작 그 내용을 아는 사람이 연락되지 않으면 아무것도 할 수 없습니다.
- 알림 소음이 쌓이게 두지 마세요. 오탐지로 가득 찬 순번은 사람들이 실제 호출조차 무시하게 만듭니다.
- 온콜 근무를 무급, 무보상, 그리고 눈에 보이지 않는 업무로 만들지 마세요. 그렇게 하면 순번제에 가장 필요한 엔지니어들을 잃게 됩니다.
자주 묻는 질문
온콜 순번을 운영하려면 몇 명이 필요한가요?
지속 가능한 순번을 위해서는 최소 4명의 숙련된 대응자가 필요합니다. 4명 미만이면 각자의 온콜 빈도가 너무 잦아지고 휴가나 질병 시 대응할 여력이 없습니다. 만약 3명뿐이라면 순번제는 유지하되 교대 근무 시간을 단축하고, 공백 기간에 대한 계획을 명확히 세우세요.
1차 온콜과 2차 온콜의 차이점은 무엇인가요?
1차 담당자는 알림이 발생했을 때 가장 먼저 호출되는 엔지니어입니다. 2차 담당자(백업)는 1차 담당자가 보통 5~15분 이내에 알림을 확인하지 않을 경우 자동으로 호출됩니다. 2차 담당자는 모든 사고에 즉시 대응해야 하는 사람이 아니라, 호출을 놓치는 상황을 방지하기 위한 안전장치입니다.
소규모 팀의 온콜 교대 근무 시간은 어느 정도가 적당한가요?
알림 발생 빈도가 낮거나 보통 수준인 소규모 팀의 경우, 1주일 단위의 교대 근무가 가장 일반적입니다. 알림이 너무 잦아 일주일 내내 호출을 받는 것이 엔지니어에게 과도한 피로를 주거나 다른 업무에 지장을 줄 정도일 때만 일 단위 교대로 전환하는 것이 좋습니다.
소규모 팀도 온콜 근무에 대한 수당을 지급해야 하나요?
네, 어떤 형태로든 보상이 필요합니다. 직접적인 수당 지급, 대체 휴무, 또는 업무 강도가 높았던 근무 이후의 충분한 휴식 시간 보장 등이 방법이 될 수 있습니다. 보상 없는 온콜 근무는 소규모 팀에서 번아웃과 이직을 유발하는 가장 빠른 길이며, 한 명의 대응 인력만 잃어도 전체 로테이션이 무너질 수 있습니다.
소규모 팀도 전용 호출 도구가 꼭 필요한가요, 아니면 캘린더만으로도 충분한가요?
캘린더만으로는 부족합니다. 캘린더는 누가 온콜 담당자인지 기록할 뿐, 담당자를 깨울 수는 없기 때문입니다. 호출 도구는 알림을 수신하여 담당자가 확인할 때까지 전화, 문자, 푸시 알림을 통해 에스컬레이션하며, 스케줄에 따라 현재 1차 담당자에게 자동으로 연결해 줍니다.
