1. 봇이 살아 있는지 10분마다 봅니다
서비스가 멈춰 있으면 자동으로 다시 켜고, 되살아났는지까지 확인합니다. 사람이 아침에 로그를 열어 보는 방식이면 밤새 멈춘 걸 다음 날 알게 됩니다. 10분 주기는 너무 촘촘하지도, 늦지도 않은 간격입니다.
2. 되살리지 못하면 사람을 부릅니다
재시작으로 해결되면 알림을 보내지 않습니다. 실패한 경우에만 알림이 갑니다. 같은 문제로 알림이 쏟아지지 않도록 한 시간 간격을 두고, 무엇이 왜 실패했는지 한 줄로 알려 줍니다.
3. 아침에 한 통으로 정리합니다
매일 08시 30분에 운영 상태를 한 통으로 보냅니다. 고객이 늘어도 사장님이 읽는 양은 그대로입니다. 세팅한 지 얼마 안 된 고객은 매일 표시하고, 오래 안정적으로 돌아간 고객은 이상이 있을 때만 표시합니다. 이상이 없는 날은 아예 보내지 않습니다.
4. 데이터는 매일 따로 보관합니다
설정·토큰·발행 이력처럼 다시 만들 수 없는 것만 골라 매일 백업하고, 주기적으로 서버 밖으로도 복사합니다. 영상·이미지처럼 다시 만들 수 있는 것은 제외해 용량을 줄입니다. 백업이 실패하면 그 사실도 알림으로 옵니다.
“자동화의 진짜 위험은 멈추는 것이 아니라, 멈춘 걸 아무도 모르는 것입니다.”
무인 운영의 진짜 위험은 멈춤이 아니라 조용함입니다
봇은 요란하게 죽지 않습니다. 토큰이 만료되거나 한도를 넘으면 그냥 아무 일도 일어나지 않습니다. 에러 화면도 없고 알림도 없습니다. 며칠 뒤에 '요즘 글이 안 올라오네' 하고 알아차립니다. 그래서 감시를 나중에 붙이는 기능이 아니라 처음부터 구조로 넣습니다.
1차 복구는 기계가, 호출은 실패했을 때만
겪어 보면 멈춤의 대부분은 다시 켜면 해결됩니다. 그걸 전부 사람에게 알리면 알림이 하루에 수십 통이 되고, 결국 알림을 끄게 됩니다. 자동으로 되살리고 실패한 경우에만 부르는 구분이 있어야 알림이 살아남습니다.
쿨다운과 침묵이 알림을 살립니다
같은 문제로 10분마다 알림이 오면 사람은 그 채널을 음소거합니다. 한 시간에 한 번으로 묶고, 정상인 날은 아예 보내지 않습니다. 조용한 날이 많아야 울릴 때 봅니다. 알림 설계에서 가장 중요한 건 내용보다 빈도입니다.
감시 대상에서 빠진 것이 결국 사고가 됐습니다
처음에는 콘텐츠 봇만 감시 대상에 넣었습니다. 홈페이지 문의를 받는 쪽은 빠져 있었고, 그쪽에서 문제가 생겼을 때 하루가 넘게 몰랐습니다. 그 뒤로 감시 목록에 사이트 기능까지 넣었습니다. 새 서비스를 만들면 감시 목록에 추가하는 것을 배포 절차의 일부로 두는 게 안전합니다.
- 사람 없이 도는 시스템이 하나라도 있는 곳
- 고객 서버를 맡아 운영하는 경우
- 토큰·API를 쓰는 연동이 있는 곳
- 사람이 매일 직접 실행하는 업무만 있는 경우
구축 범위에 따라 달라집니다. 서버·AI 사용료는 고객 명의로 결제하며 우리 월 고정비는 없습니다.
왜 중요한가
자동화를 맡기실 때 가장 많이 듣는 걱정이 '고장 나면 모르는 것'입니다. 맞는 걱정입니다. 사람이 하던 일은 안 하면 티가 나지만, 시스템이 하던 일은 멈춰도 티가 안 납니다. 그래서 저희는 봇을 만들 때 감시와 백업을 같이 만듭니다. 10분마다 점검해 스스로 되살리고, 실패했을 때만 사람을 부르고, 매일 데이터를 따로 보관합니다. 고객이 문제를 겪기 전에 저희가 먼저 알고 연락하는 게 목표입니다. 이 구조는 고객 서버에도 그대로 들어갑니다. 고객 서버에서 우리 쪽으로 오는 것은 '살아 있다'는 신호와 실패 기록뿐이고, 콘텐츠나 계정 정보는 오지 않습니다.
