사이트가 죽으면 나한테 알리기

사이트가 멈추면 손님이 아니라 사장님 폰이 먼저 울리게 만드는 장치예요. 손님이 먼저 알고 사장님이 나중에 아는 게 이 세계의 최악이거든요.

쉽게 말하면

새벽에 가게 유리문이 깨지면, 경보기가 있는 가게는 그 자리에서 사장님 폰이 울려요. 경보기가 없는 가게는 아침에 출근해서야 알고요. 그사이에 지나간 손님들은 깨진 문만 보고 돌아갔겠죠. 사이트도 똑같아요. 감시 장치(모니터링)는 몇 분에 한 번씩 내 사이트 문을 두드려 보는 야간 경비원이에요. 문이 안 열리면 바로 사장님한테 전화를 걸어요.

사이트가 멈추는 것 자체는 사고예요. 그런데 멈춘 걸 모르는 건 사고가 아니라 방치예요. 손님이 "안 열리던데요"라고 알려주는 순간, 그 손님은 이미 몇 번째 헛걸음인지 몰라요. 알려주지 않고 조용히 떠난 손님은 셀 수도 없고요.

알림 없는 가게

사이트 다운 → 3시간 동안 아무도 모름 → 손님 DM으로 알게 됨

발견이 늦을수록 잃은 손님과 매출은 커져요. 그리고 손님한테서 듣는 건 신뢰까지 잃는 길이에요.

알림 있는 가게

사이트 다운 → 5분 안에 내 폰이 울림 → 손님보다 내가 먼저 앎

빨리 알면 빨리 고치거나, 최소한 공지라도 할 수 있어요. 대응의 시작은 언제나 "아는 것"이에요.

어떻게 작동하나

원리는 단순해요. 바깥에 있는 감시 서비스가 몇 분에 한 번씩 내 사이트 주소에 접속해 봐요. 정상 응답이 오면 조용히 넘어가고, 답이 없거나 오류가 뜨면 사장님한테 이메일이나 문자를 보내요. 이 "두드려 보기"를 개발자들은 핑(ping)이나 헬스체크라고 불러요.

1감시 서비스에 가입해요. 업타임 감시 서비스를 검색하면 여러 곳이 나와요. 몇 분 간격 확인은 무료로 시작할 수 있는 곳이 많아요.
2내 사이트 주소를 등록해요. 대문 주소 하나면 시작으로 충분해요.
3확인 주기를 정해요. 5분에 한 번이면 대부분의 가게에 충분해요. 1분에 한 번은 보통 유료예요.
4알림 수단을 정해요. 이메일은 기본이고, 자는 시간에도 알아야 하면 문자나 앱 알림을 켜요.
5일부러 틀린 주소를 하나 등록해서 알림이 진짜 오는지 시험해요. 경보기는 달고 나서 한 번 울려 봐야 믿을 수 있어요.

감시는 반드시 바깥에서

"내 서버가 스스로 자기 상태를 알리게 하면 되지 않나요?"라는 생각이 들 수 있는데, 함정이에요. 서버가 죽으면 그 안에 있는 경보기도 같이 죽어요. 불이 났을 때 소방서에 전화해 줄 사람이 건물 안에만 있으면 안 되는 것과 같아요. 그래서 감시는 내 서버 바깥, 남의 컴퓨터에서 해야 해요.

증상별로, AI에게 이렇게 말하세요

감시 서비스 가입 말고, 내 사이트 쪽에서 준비할 것들은 AI에게 시키면 돼요. 증상을 그대로 붙여 넣을 수 있게 문장으로 정리했어요.

증상	AI에게 할 말
사이트가 죽어도 알 방법이 없어요	"감시 서비스가 5분마다 들여다볼 수 있는 상태 확인 주소(헬스체크)를 만들어 줘. 정상이면 정상이라고 답하게 해 줘"
죽은 건 아닌데, 결제나 예약만 조용히 고장 날까 봐 걱정돼요	"상태 확인 주소가 겉만 보지 말고, 데이터베이스 연결과 결제 연결까지 확인해서 답하게 해 줘"
사이트가 죽었을 때 손님한테 최소한의 안내라도 하고 싶어요	"오류가 나면 하얀 화면 대신, 사과 문구와 연락처가 있는 안내 화면이 뜨게 해 줘"
손님은 안 된다는데 내 폰에서는 잘 돼요	"오류가 났을 때 언제 어떤 오류였는지 기록이 남게 해 줘. 내가 나중에 볼 수 있게"
느려지는 것도 미리 알고 싶어요	"페이지가 뜨는 데 걸리는 시간을 기록해서, 평소보다 눈에 띄게 느려지면 알 수 있게 해 줘"

표의 첫 줄에 나온 헬스체크 주소가 이 문서의 핵심 부품이에요. 감시 서비스가 두드릴 전용 문을 하나 만들어 두는 거예요. 대문(첫 화면)을 두드려도 되지만, 전용 문은 "살아 있음"만 가볍고 정확하게 답하니까 더 믿을 만해요.

사장님이 실제로 겪는 장면

장면 1 · 단골손님이 인스타 DM을 보냈다

“사장님, 예약 페이지가 안 열려요. 저 말고도 안 된다는 사람 있던데요?”

확인해 보니 세 시간 전부터 죽어 있었어요. 이 장면의 뼈아픈 점은 고장이 아니라 시간이에요. 감시 알림이 있었다면 세 시간이 오 분이었을 거예요. 그리고 손님에게 듣기 전에 사장님이 먼저 공지를 올릴 수 있었을 거고요.

장면 2 · 새벽 3시에 문자가 왔다

“[감시 알림] 사이트 응답 없음. 그리고 5분 뒤: [감시 알림] 복구됨.”

이런 짧은 딸꾹질은 생각보다 흔해요. 호스팅 쪽이 잠깐 출렁했거나, 순간적으로 접속이 몰렸거나요. 스스로 복구됐고 반복되지 않으면 새벽에 일어나 뭘 하지 않아도 돼요. 아침에 기록을 한 번 보는 정도면 충분해요. 벌떡 일어나야 하는 건 "복구됨"이 안 오고 알림이 이어질 때예요.

알림이 진짜 왔을 때, 순서대로

1내 폰으로 직접 접속해 봐요. 정말 죽었는지, 감시 쪽 오탐인지부터 확인해요.
2호스팅 서비스의 상태 페이지를 봐요. 호스팅 회사 자체에 장애가 났다면 내 잘못도 아니고 내가 고칠 수도 없어요. 기다리는 게 답일 때도 있어요.
3최근에 뭘 바꿨는지 떠올려요. 새로 게시한 직후에 죽었다면 그 변경이 범인일 확률이 높아요. 직전 판으로 되돌리는 게 가장 빠른 응급처치예요.
4AI에게 증상을 그대로 말해요. "몇 시부터 사이트가 안 열리고, 화면에 이런 문구가 떠"처럼요. 오류 문구는 요약하지 말고 그대로 붙여 넣는 게 좋아요.
5복구되면 손님 공지를 판단해요. 몇 분짜리면 조용히 넘어가도 되지만, 결제가 얽혔거나 길었다면 짧게라도 알리는 쪽이 신뢰를 지켜요.

고치는 법은 다른 문서가 맡아요

이 문서는 "빨리 아는 법"까지예요. 장애가 났을 때 침착하게 대응하는 순서는 장애가 났을 때 대응하기에, 오류 문구를 읽어 내는 법은 오류 메시지 읽는 법에 있어요. 아는 것과 고치는 것은 다른 근육이에요.

지금은 신경 쓰지 않아도 되는 때

겁을 줘서 뭔가 달게 만드는 건 정직하지 않아요. 그래서 분명히 말할게요. 아직 손님이 없다면 감시 장치는 필요 없어요. 만드는 중인 연습 사이트, 지인한테만 보여 주는 시안, 주소를 아무한테도 안 알린 사이트가 죽어 봤자 잃는 게 없거든요. 경보기는 지킬 것이 생겼을 때 다는 거예요.

상황	판단
만드는 중이고 손님이 없어요	아직 필요 없어요. 만들기에 집중하세요
지인 몇 명한테만 보여 주는 단계예요	아직 필요 없어요. 죽으면 지인이 웃으며 알려줘요
주소를 공개했고 모르는 손님이 들어와요	이제 달 때예요. 무료 구간으로 시작해도 충분해요
예약이나 결제를 받기 시작했어요	반드시 다세요. 죽은 시간이 곧 잃은 돈이에요
광고를 돌리기 시작했어요	반드시 다세요. 죽은 사이트에 돈 내고 손님을 보내는 셈이 돼요

기준은 하나예요. 이 사이트가 세 시간 죽어 있으면 아까운 게 있는가. 있으면 달고, 없으면 아직이에요. 다는 데 삼십 분도 안 걸리니까, "이제 아깝다"는 느낌이 드는 그날 달면 늦지 않아요.

자주 묻는 것

Q. 바이브캠퍼스에서 만든 사이트도 죽을 수 있나요?: 어떤 호스팅이든 100%는 없어요. 호스팅 자체 장애 말고도 도메인 기간 만료, 연결해 둔 외부 서비스(결제사·데이터베이스)의 장애, 새로 게시한 코드의 오류처럼 죽는 이유는 여러 갈래예요. 그래서 "어디서 만들었나"와 무관하게, 손님을 받는 사이트라면 감시가 있는 게 맞아요.
Q. 감시 서비스는 돈이 드나요?: 몇 분 간격 확인과 이메일 알림 정도는 무료로 시작할 수 있는 곳이 많아요. 1분 간격 확인, 문자·전화 알림, 여러 주소 감시 같은 건 유료로 넘어가는 경우가 흔하고요. 손님 받는 가게 하나 지키는 데는 무료 구간으로도 대부분 충분해요.
Q. 알림이 너무 자주 오면 어떡하죠?: 경보가 잦으면 무시하게 되고, 무시하는 경보는 없는 것보다 나빠요. 대부분의 감시 서비스에는 "연속 2회 실패했을 때만 알림" 같은 설정이 있어요. 이걸 켜면 몇 초짜리 딸꾹질은 걸러지고 진짜 장애만 울려요.
Q. 밤에 죽으면 새벽에 일어나서 고쳐야 하나요?: 가게 성격에 달렸어요. 새벽 손님이 없는 가게면 아침에 고쳐도 돼요. 알림의 가치는 "즉시 일어나기"가 아니라 "내가 모르는 시간을 없애기"예요. 새벽 알림이 부담이면 방해 금지 시간대를 두고, 아침에 기록으로 확인하는 방식도 괜찮아요.
Q. 상태 페이지라는 것도 있던데, 그건 뭐가 다른가요?: 감시 알림은 사장님한테 오는 것이고, 상태 페이지는 손님에게 보여 주는 게시판이에요. "지금 점검 중이에요" 같은 걸 올리는 곳이죠. 규모가 커지면 유용하지만, 작은 가게는 장애 때 SNS나 안내 화면으로 공지하는 정도면 충분해요.
Q. 감시를 달면 사이트가 느려지지 않나요?: 아니요. 5분에 한 번 손님 한 명이 들어와 보는 것과 같은 무게예요. 사이트는 그 정도를 느끼지도 못해요.

확인해 보세요

사이트를 지키는 경보기(감시 장치)는 어디에 두는 게 맞을까요?

하나 더

새벽 3시에 "사이트 다운" 문자가 오고, 5분 뒤 "복구됨" 문자가 왔어요. 어떻게 할까요?

직접 해보기

내 사이트에 전용 문(헬스체크)부터 달아 보세요

스튜디오에서 이렇게 말해 보세요. "감시 서비스가 5분마다 들여다볼 상태 확인 주소를 만들어 줘. 정상이면 정상이라고 답하게 해 줘." 이 문 하나가 준비되면, 감시 서비스 등록은 주소 붙여 넣기만 남아요.

스튜디오 열기

더 깊이 (안 읽어도 괜찮아요)

겉만 보는 확인과 속까지 보는 확인 · 대문이 열리는지만 확인하는 감시는 "문은 열리는데 계산대가 고장"인 상황을 놓쳐요. 화면은 뜨는데 결제나 예약만 조용히 죽어 있는 경우요. 그래서 규모가 커지면 상태 확인 주소가 데이터베이스 연결, 결제 연결까지 짚어 보고 답하게 만들어요. 다만 속까지 보는 확인은 그만큼 무거워서, 너무 자주 두드리면 그 자체가 부담이 돼요. 겉 확인은 자주, 속 확인은 드문드문이 균형이에요.

가동률 99.9%의 진짜 뜻 · 호스팅 소개에 나오는 가동률 숫자는 감으로 읽으면 안 돼요. 한 달을 기준으로 계산해 보면 99.9%는 약 43분의 다운을 허용한다는 뜻이고, 99%면 약 7시간이에요. 소수점 하나가 시간 단위로 벌어져요. 그리고 이 숫자는 호스팅 쪽 사정만이에요. 내 코드 오류나 도메인 만료로 죽는 건 별도고, 그건 오직 내 감시 장치만 잡아 줘요.

경보 피로라는 병 · 감시를 달아 본 사람들이 그다음에 앓는 병이 경보 피로예요. 오탐과 딸꾹질 알림이 쌓이면 어느 날부터 알림을 안 보게 되고, 진짜 장애가 그 틈으로 지나가요. 양치기 소년 이야기 그대로예요. 그래서 잘 다는 것보다 잘 조율하는 게 중요해요. 연속 실패에만 울리게 하고, 중요도에 따라 이메일과 문자를 나누고, 한동안 오탐이 잦으면 원인을 고치거나 기준을 손봐요. 좋은 경보는 조용하다가 정확히 한 번 우는 경보예요.

이것만 기억하세요

·손님이 먼저 알고 사장님이 나중에 아는 게 최악이에요. 감시는 그 순서를 뒤집는 장치예요
·감시는 내 서버 바깥에서 해요. 서버가 죽으면 안의 경보기도 같이 죽어요
·AI에게는 "5분마다 확인할 상태 확인 주소를 만들어 줘"라고 말하면 돼요
·짧은 딸꾹질 알림은 흔해요. 연속 실패에만 울리게 조율하세요
·손님이 없는 연습 단계면 아직 필요 없어요. 잃을 게 생기는 날 달면 돼요