소규모 엔지니어링 팀을 위한 온콜(On-Call) 설정: 실무 가이드 (2026)
Tanny Kang
August 5, 2026
소규모 팀의 온콜 설정이란 임시방편식 대응을 체계적인 로테이션으로 바꾸는 것을 의미합니다. 즉, 정해진 일정, 명확한 알림 기준, 에스컬레이션 경로, 그리고 담당자에게 자동으로 알림을 보내는 도구를 갖추는 것입니다. 엔지니어가 10명 정도 되고 유료 고객이 생기기 시작하면, 문제 발생 시 눈에 띄는 사람이 대응하는 방식은 더 이상 통하지 않습니다. 이는 서비스 장애와 팀의 번아웃으로 이어질 뿐입니다. 이 가이드에서는 엔터프라이즈급의 복잡한 절차 없이도 지속 가능한 첫 온콜 로테이션을 구축하는 방법을 안내합니다.
요약: 소규모 팀의 온콜 설정 단계: (1) 무엇이 즉각적인 대응이 필요한지 결정하기, (2) 모니터링 시스템과 알림 도구 연결하기, (3) 최소 4~5명의 엔지니어로 1차/2차 로테이션 구성하기, (4) 3단계 에스컬레이션 경로 정의하기, (5) 복구 시간 보장 및 런북 작성하기. 2026년 추천 도구로는 Better Stack, Squadcast, incident.io, Rootly, PagerDuty가 있으며, 성장에 맞춰 도입할 수 있는 AI 기반 옵션으로 Vibe OnCall이 있습니다.
개요
이 가이드의 내용:
- 엔지니어 10명이 넘어가면 비공식적인 대응 방식이 무너지는 이유
- 온콜 라이프사이클의 시작부터 끝까지
- 첫 로테이션 구축을 위한 5단계
- 즉시 알림을 보내야 할 상황과 아침까지 기다려도 되는 상황 구분하기
- 2026년 소규모 팀을 위한 도구 추천
- 온콜 설정 시 피해야 할 실수
- 자주 묻는 질문(FAQ)
소규모 팀의 온콜 설정이 다른 이유
엔터프라이즈용 온콜 가이드는 20명 규모의 로테이션, 전담 SRE 조직, 상근 인시던트 매니저가 있다는 전제하에 작성됩니다. 하지만 여러분에게는 그런 환경이 없습니다. 여러분의 팀은 기능을 개발하면서 온콜까지 담당하는 소수의 엔지니어로 구성되어 있으며, 이들이 장애 대응에 시간을 쏟는 매 순간은 제품 개발 시간이 줄어든다는 것을 의미합니다.
이러한 제약 조건이 아래의 모든 결정에 영향을 미칩니다. 목표는 구글의 SRE 플레이북을 그대로 복사하는 것이 아닙니다. 호출기를 담당하는 네 명의 사기를 꺾지 않으면서, 최소한의 요소로 안정적인 운영 체계를 갖추는 것입니다.
현재 여러분은 아마도 초기 단계의 기본 방식을 따르고 있을 것입니다. 무언가 고장 나면 눈에 띄는 사람이 즉시 뛰어들고, 해결될 때까지 모두가 달라붙는 방식이죠. 엔지니어가 다섯 명일 때는 잘 작동합니다. 하지만 이제 체계화가 필요하다는 신호는 간단합니다. 유료 고객이 장애를 체감하고 있고, 항상 같은 한두 명의 사람이 모든 문제를 해결하고 있다면 말이죠. 이럴 때는 거창한 프로세스가 필요하지 않습니다. 아래 다섯 가지 항목을 가볍게 적용해 보고, 시스템이 실제로 어떻게 작동하는지 파악하면서 점차 깊이를 더해 가면 됩니다.
영웅의 함정: 규모가 작을 때는 시스템을 가장 잘 아는 한두 명의 엔지니어에게 업무가 자연스럽게 집중됩니다. 그들이 번아웃되거나, 휴가를 떠나거나, 퇴사하여 운영에 대한 유일한 지식까지 가지고 나가기 전까지는 효율적으로 보이죠. 제대로 된 온콜 로테이션은 단순히 일정을 채우는 것이 아니라, 이러한 단일 실패 지점을 없애기 위해 존재합니다.
스타트업이 온콜을 일찍 고민해야 하는 이유
온콜은 다음 투자 유치 이후나 팀 규모가 두 배로 커진 뒤에 고민해도 될 '나중 일'로 치부하기 쉽습니다. 하지만 실제로는 정반대입니다. 시스템이 머릿속에 다 들어올 만큼 작고 로테이션 인원이 적을 때 습관을 들이는 것이 가장 비용이 적게 듭니다. 장애가 발생한 상황에서 번아웃된 팀에게 프로세스를 억지로 끼워 맞추는 것은 지금 가볍게 시작하는 것보다 훨씬 어렵습니다.
일찍 시작하면 좋은 세 가지 이유:
- 번아웃은 생각보다 빨리 찾아옵니다. '항상 대기 중'이라는 심리적 압박은 창립 엔지니어들을 빠르게 지치게 합니다. 예방 가능한 피로로 핵심 인력을 잃는 것은 어떤 도구보다 훨씬 큰 손실입니다. 로테이션은 한 사람이 짊어지는 부담의 빈도를 제한해 줍니다.
- 지식이 고르게 분산됩니다. 처음부터 온콜을 돌아가며 맡으면, 팀원 전체가 운영 환경이 실제로 어떻게 돌아가는지 더 많이 배우게 됩니다. 너무 오래 기다리면 그 지식은 항상 문제를 해결해 온 한두 명에게만 갇히게 됩니다.
- 고객 신뢰가 쌓입니다. 유료 고객이 생기면, 장애를 얼마나 빠르고 차분하게 처리하느냐도 제품의 일부가 됩니다. 기본적인 로테이션이 있으면 누군가 항상 책임을 지게 되므로, 고객이 이메일을 보낼 때까지 장애가 방치되는 일을 막을 수 있습니다.
이러한 이점을 얻기 위해 거창한 프로그램이 필요한 것은 아닙니다. 아래의 다섯 가지 가벼운 단계만으로도 충분히 시작할 수 있습니다.
소규모 팀을 위한 온콜 설정 단계별 가이드
1단계: 호출할 가치가 있는 문제를 정의하세요
도구를 건드리기 전에 여기서부터 시작하세요. 새로운 로테이션을 가장 빨리 망치는 방법은 모든 알림을 연결해 밤새 15번씩 사람을 깨우는 것입니다. 그러면 일주일도 안 되어 호출기를 무시하게 될 것입니다.
심각도 단계를 정의하고, 처음에는 가장 높은 단계에 대해서만 호출(page)하세요:
- 즉시 호출 (SEV1): 전체 서비스 중단, 데이터 손실 위험, 결제 또는 로그인 불가, 보안 침해.
- 알림만 전송, 호출 안 함 (SEV2): 성능 저하, 오류율 상승, 중요하지 않은 단일 서비스 중단.
- 티켓 생성만 (SEV3): 업무 시간까지 기다려도 되는 모든 문제.
"메인 앱 URL이 200 응답을 반환하는가?"와 같이 명확하고 신호가 확실한 체크 하나로 시작하세요. 고객이 실제로 불편을 겪는 상황이 무엇인지 파악한 후에 알림을 추가하는 것이 좋습니다. 알림 피로가 쌓인 뒤에 신뢰를 회복하는 것보다, 필요한 신호를 하나씩 추가하는 편이 훨씬 쉽습니다.
2단계: 알림을 한곳으로 모으기
시작부터 완벽한 관측성(observability) 스택을 갖출 필요는 없습니다. 초기에는 고객의 이메일이나 메인 URL을 확인하는 기본적인 가동 시간 체크만으로도 호출을 시작하기에 충분합니다. 어떤 도구를 사용하든(가동 시간 모니터링, 하트비트 체크, 혹은 추후 도입할 Datadog이나 Grafana 등), 알림은 이메일, SMS, 여러 대시보드로 흩어지지 않게 하나의 알림 도구로 통합해야 합니다. 알림 도구의 유일한 역할은 문제 발생 시 누구에게 어떻게 알릴지 결정하는 것이므로, 이를 감지 도구와 분리해서 관리하세요. 어떤 신호가 실제로 중요한지 파악한 후에 더 정교한 모니터링을 추가하면 됩니다.
3단계: 1차 및 2차 온콜 로테이션 구축하기
로테이션이란 특정 인원에게 업무가 몰리지 않도록 돌아가며 호출을 담당하는 것을 의미합니다. 소규모 팀에서는 다음 두 가지가 가장 중요합니다:
- 로테이션 인원을 4~5명으로 구성하세요. 인원이 이보다 적으면 온콜 주기가 너무 잦아져 본업보다 온콜이 주 업무가 되어버립니다. 4주에 1회 정도가 적당하며, 장기적으로는 6주에 1회가 가장 이상적입니다. 현재 가능한 엔지니어가 3명뿐이라면 일단 시작하고, 채용을 통해 인원을 늘려가세요. 미루지 않는 것이 중요합니다.
- 2차 담당자를 지정하세요. 1차 담당자가 호출을 받지 못할 경우를 대비해 2차 담당자가 자동으로 백업 역할을 수행합니다. 소규모 팀에서는 이를 통해 신입 엔지니어가 부담 없이 업무를 익힐 수 있는 기회가 되기도 합니다.
매주 같은 요일에 짧게 미팅을 하며 업무를 인수인계하는 방식이 가장 간단하고 효과적입니다. 이 정도 규모의 팀에서는 매일 로테이션을 바꾸는 것은 피하세요. 인수인계에 드는 비용이 얻는 이점보다 큽니다.
4단계: 3단계 에스컬레이션 경로 정의
에스컬레이션은 담당자의 전화가 무음일 때 문제를 해결해 주는 안전장치입니다. 간단하고 신뢰할 수 있는 경로는 다음과 같습니다.
- 1차 담당자에게 호출을 보냅니다. 5~10분 내에 응답이 없으면,
- 2차 담당자에게 호출을 보냅니다. 여전히 응답이 없으면,
- 에스컬레이션 책임자 (보통 이 규모에서는 엔지니어링 리드나 CTO)에게 호출을 보냅니다.
도구에서 이 설정을 한 번만 구성해 두면 자동으로 작동합니다. 핵심은 특정 인원이 오프라인 상태가 되더라도 장애 처리가 방치되지 않도록 하는 것입니다.
5단계: 회복 시간 보장 및 런북 작성
일정표가 활성화되었다고 해서 온콜 준비가 끝난 것은 아닙니다. 지속 가능한 운영을 위한 두 가지 습관이 필요합니다.
- 회복 시간. 야간에 호출을 받은 엔지니어에게 오전 9시 정각에 업무 복귀를 기대해서는 안 됩니다. 불만이 쌓이기 전에 이를 당연한 문화로 정착시키세요.
- 실질적인 런북. 장애가 발생할 때마다 무엇이 문제였는지, 어떻게 진단했는지, 어떻게 해결했는지 기록하고 알림에서 해당 문서로 연결하세요. 목표는 다음 온콜 담당자가 처음 해결했던 전문가를 깨우지 않고도 동일한 문제를 해결할 수 있게 하는 것입니다. 이것이 바로 '영웅주의의 덫'을 완전히 없애는 방법입니다.
소규모 팀을 위한 온콜(On-call) 도구: 2026년 비교
적합한 도구는 현재 운영 중인 시스템의 규모와 통합하고자 하는 기능의 범위에 따라 달라집니다. 2026년 8월 기준 공개된 가격 페이지를 바탕으로, 소규모 팀의 효율적인 운영 환경에 가장 적합한 순서대로 주요 옵션을 비교했습니다.
Vibe OnCall은 사람이 깨어나기 전에 AI가 먼저 경고를 조사하기를 원하는 팀에게 가장 적합합니다. 단순히 안정적인 호출 기능이 필요한 팀에게는 Better Stack과 같은 올인원 도구나 Squadcast와 같은 저비용 전용 호출 도구가 기본 기능을 저렴하게 제공하며, PagerDuty는 라우팅 복잡성이 높아져 인당 비용을 지불할 가치가 있을 때 선택하는 대규모 서비스입니다.
"온콜"의 의미 자체를 바꾸는 구조적인 차이점 하나를 짚고 넘어가야 합니다.
기존의 호출 도구는 사람을 먼저 깨운 뒤 아무런 정보 없는 알림을 전달하지만, Vibe OnCall과 같은 AI 네이티브 도구는 호출 전에 경고를 먼저 조사하므로 엔지니어는 미스터리한 상황이 아닌 맥락이 파악된 상태에서 대응을 시작할 수 있습니다. Vibe OnCall은 중견 기업 고객사에서 MTTR(평균 복구 시간)을 60% 단축했다고 보고했지만, 10명 규모의 엔지니어 팀에게는 앞서 언급한 더 단순한 도구들이 첫 단계로 적합한 경우가 많습니다.
온콜 설정 시 피해야 할 사항
- 첫날부터 모든 경고를 연결하지 마세요. 경고 피로(Alert fatigue)는 새로운 온콜 로테이션이 실패하는 가장 흔한 원인입니다. 범위를 좁게 시작하세요.
- 2인 로테이션은 운영하지 마세요. 그것은 로테이션이 아니라 두 사람이 영구적으로 온콜 상태인 것입니다. 인접한 엔지니어를 포함해서라도 최소 4~5명으로 구성하세요.
- 보조 담당자(Secondary)를 생략하지 마세요. 백업이 없는 로테이션은 전화 한 통을 놓치는 순간 장애 대응 실패로 이어집니다.
- 런북(Runbook)을 선택 사항으로 여기지 마세요. 문서화되지 않은 장애는 '영웅주의의 덫'을 유지하게 만들며, 새벽 3시에 똑같은 문제를 다시 겪게 될 것임을 보장합니다.
- "안전을 위해" 엔터프라이즈 등급을 구매하지 마세요. 소규모 팀이 당분간 사용하지도 않을 복잡한 라우팅 기능을 위해 인당 비용을 지불하는 것은 자금을 낭비하는 일입니다.
자주 묻는 질문
온콜(on-call) 로테이션에는 몇 명의 엔지니어가 필요한가요?
최소 4~5명은 필요합니다. 그보다 적으면 한 사람이 너무 자주 온콜을 맡게 되어 지속 가능하지 않습니다. 대략 2~3주에 한 번꼴이 되기 때문이죠. 4~5명이 있으면 엔지니어당 4주에 한 번으로 조정할 수 있고, 팀이 성장함에 따라 6주에 한 번을 목표로 할 수 있습니다.
프라이머리(primary)와 세컨더리(secondary) 온콜의 차이점은 무엇인가요?
프라이머리는 알림을 가장 먼저 받고 인시던트를 책임집니다. 세컨더리는 프라이머리가 정해진 시간 내에 응답하지 않을 경우 자동으로 알림을 받는 백업 역할을 합니다. 두 역할을 모두 운영하면 전화 한 통을 놓쳐서 인시던트가 방치되는 일을 방지할 수 있습니다.
어떤 경우에 즉시 알림(page)을 보내고, 어떤 경우에 아침까지 기다려야 하나요?
전체 서비스 중단, 데이터 손실 위험, 보안 사고 발생 시에만 즉시 알림을 보내세요. 서비스 성능 저하가 발생했지만 작동 중인 상태라면 알림 없이 통보만 하고, 그 외의 모든 사항은 티켓으로 처리해야 합니다. 긴급하지 않은 문제로 계속 알림을 보내면 사람들이 알림을 무시하게 됩니다.
소규모 팀도 PagerDuty 같은 도구가 필요한가요, 아니면 Slack만으로 충분한가요?
Slack 알림은 유료 고객이 없고 SLA(서비스 수준 협약)가 없을 때까지는 유효합니다. 하지만 놓친 알림이 곧 매출 손실로 이어지는 시점이 오면, 보장된 에스컬레이션, 응답 추적, 감사 추적이 필요합니다. Better Stack, Squadcast, PagerDuty와 같은 전용 도구들이 바로 이러한 기능을 제공합니다.
소규모 팀에서 온콜 번아웃을 방지하려면 어떻게 해야 하나요?
온콜 빈도를 4주에 1회로 제한하고, 항상 세컨더리를 운영하며, 야간 근무 후에는 반드시 회복 시간을 보장하세요. 또한 특정 한두 명의 전문가에게만 업무가 쏠리지 않도록 런북(runbook)을 체계화하는 데 투자해야 합니다.
