무료 Supabase는 7일 놀면 잠든다 — 3일마다 깨웠는데도 잠들었다

오늘 배울 것 무료 Supabase의 '7일 규칙'은 마감일이 아니라 하루치 활동량의 문제이고, 경보는 일부러 한 번 울려 봐야 믿을 수 있어요.

결과부터 — 3일마다는 실패, 하루 4번은 복구 뒤 16일 넘게 무사

무료 Supabase 데이터베이스는 일주일 동안 조용하면 잠들어요. 저는 업무용을 포함한 7개 프로젝트를 3일마다 한 번씩 깨웠어요. 그런데도 그중 2개가 잠들었어요.

그래서 깨우는 횟수를 하루 4번(6시간마다)으로 올렸어요. 바꾼 다음 날 하나가 더 잠들었지만, 잠든 셋 중 다시 켜진 둘은 10월 3일 낮 실행부터 16일 넘게 59번 모두 대답했어요. 처음 잠든 둘 중 하나와 다음 날 잠든 하나예요.

다만 둘을 16일 지켜본 결과일 뿐, 하루 4번이 늘 통한다는 증명은 아니에요. 예약이 밀려 실제로는 하루 2~5번(평균 3.5번쯤) 돌았어요.

아직 끝은 아니에요. 복구되지 않은 하나 때문에 실행 기록은 10월 20일 현재도 매번 '실패'로 찍혀요. 하나라도 대답이 없으면 조용히 넘어가지 않게, 일부러 그렇게 만들었어요.

무엇이 문제였나

데이터베이스는 정리된 서랍장 같은 곳이에요. 정확히는 프로그램이 정보를 저장하고 찾아 쓰는 전용 창고예요. 서랍장과 달리, 여러 사람이 동시에 열어도 내용이 섞이지 않게 관리해 줘요.

Supabase(수파베이스)는 이 서랍장을 인터넷에 빌려주는 서비스예요. 무료 요금제는 지난 일주일 동안 데이터베이스 활동이 충분하지 않으면 프로젝트를 일시 정지해요.

잠들면 서버 주소가 통째로 사라져요. 9월 15일 업무용 프로젝트 하나가 이렇게 잠들어, 서비스와 자동 배포가 한꺼번에 멈췄어요.

잠든 프로젝트는 사람이 관리 화면(대시보드)에서 'Resume project'(다시 켜기)를 눌러야 깨어나요. 1년이 지나면 되살릴 수 없어요.

그래서 유료로 바꾸는 대신 3일마다 가볍게 깨우기로 했어요. 이렇게 깨우는 걸 핑(ping)이라고 해요. 문을 똑똑 두드리고 "계세요?" 하고 묻는 것과 같아요. 정확히는 데이터베이스에 아주 작은 조회 요청을 보내고 대답을 받는 일이에요. 진짜 노크와 달리, 이 요청은 데이터베이스가 일한 기록으로 남아요.

AI가 만든 도구는 GitHub Actions(깃허브 액션)에서 돌아요. GitHub은 코드를 맡겨 두는 인터넷 보관소예요. 정해진 시각이 되면 GitHub의 컴퓨터가 제 대신 7개 프로젝트의 문을 차례로 두드려요. 주기는 3일마다, 한국 시각 오전 6시였어요.

왜 몰랐나 — 마감만 보고 주기를 잡았다

숫자만 보면 3일은 넉넉해 보여요. 7일 안에 두 번은 두드리니까요. 처음 설계도 '7일 안에 한 번'을 기준으로 잡았어요.

9월 20일 아침 실행에서 두 프로젝트는 정상 응답을 돌려줬어요. 3일 뒤 9월 23일 아침 실행에서는 둘 다 "주소를 찾을 수 없음(ENOTFOUND)"이었어요. 문을 두드리고 대답까지 들었는데, 사흘 만에 잠든 거예요.

Supabase 공식 문서는 날마다 사용자 요청이 몇 번씩 있으면 보통 충분하다고 해요. 3일에 한 번은 하루 0.33번이에요. 기준은 마감이 아니라 하루치 활동량이었어요.

그때 기록은 살아남은 5개를 실제로 쓰는 곳으로, 잠든 2개를 개발이 멈춰 아무도 안 쓰는 곳으로 봤어요. 그래서 결론도 "생존은 핑이 아니라 실사용 덕"이었어요.

그런데 어떻게 알아챘을까요? AI가 작업을 마무리하기 전에 실행 기록을 확인했더니, 최근 두 번이 '실패'로 찍혀 있었어요. 하나라도 대답이 없으면 실행 전체를 실패로 끝내게 만들어 둔 덕분이에요.

그 장치가 정말 울리는지도 처음에 시험해 뒀어요. AI가 없는 주소, 틀린 기준, 못 쓰게 막아 둔 관리자 열쇠를 일부러 넣어 돌렸고, 전부 '실패'로 나왔어요. GitHub에서도 하나를 일부러 망가뜨려 '실패'가 뜨는 걸 확인했어요. 일지에는 이 시험을 건너뛰었다면 7개 중 5개 성공인 채로 조용히 통과했을 거라고 적혀 있어요.

어떻게 풀었나

바꾼 설정은 이렇게 생겼어요.

# 전: 3일마다 한 번 (세계 표준시 UTC 21시 = 한국 오전 6시)
- cron: '0 21 */3 * *'
# 후: 6시간마다 = 하루 4번
- cron: '0 */6 * * *'

1. 깨우는 횟수를 하루 4번으로 올린다. 위의 cron(크론)은 '언제 실행할지'를 적는 알람 시각 표기예요. GitHub이 세는 사용 시간은 한 달 2시간 안팎으로, 무료 한도 2,000분의 10분의 1도 안 돼요. 한 번에 20초 남짓 걸려도 1분으로 세거든요. 이렇게 보이면 성공: 실행 기록에 하루 여러 번 실행이 쌓여요.

2. 이미 잠든 프로젝트는 관리 화면에서 직접 복구한다. 핑으로는 깨어나지 않아요. 이렇게 보이면 성공: 다음 실행에서 그 프로젝트 줄이 FAIL에서 OK로 바뀌어요.

3. 일부러 한 번 실패시켜 경보를 확인한다. 없는 주소를 하나 넣고 돌려 봐요. 이렇게 보이면 성공: 실행이 '실패'로 끝나고 GitHub이 실패 알림 메일을 보내요. 확인했으면 되돌리고 '성공'을 다시 봐요.

4. 복구 뒤 7일이 넘도록 기록을 직접 연다. 이렇게 보이면 성공: 복구한 프로젝트가 7일 넘게 매번 OK예요.

바꾼 다음 날(9월 28일), 새 주기로 두 번 돈 뒤의 낮 실행에서 업무용 프로젝트 하나가 더 잠들어 있었어요. 그때 기록이 사용자가 있다고 본 곳인데, 왜 그때였는지는 확인하지 못했어요. Supabase 문서도 쓰고 있어도 사용량이 모자라면 정지될 수 있다고 하니, '실사용 덕'이라는 판단도 틀렸을 수 있어요.

다시 켜진 둘은 10월 3일 낮부터 10월 20일 새벽까지 59번 내내 대답했어요. 처음 정해 둔 '복구 뒤 7일 무정지' 기준의 두 배가 넘는 16일이에요.

FAIL 업무용 프로젝트        ERROR   32ms
       ↳ ENOTFOUND
OK   102.builder-portfolio  200     968ms
OK   109.Yeoro              200     913ms
성공 6/7

10월 20일 새벽 마지막 실행 기록의 일부예요(업무용 이름은 가렸어요). OK는 대답이 왔다는 뜻이고, 200은 '정상' 응답 번호, ms는 걸린 시간(1,000분의 1초)이에요. 102는 이 블로그, Yeoro는 제 여행 계획 사이트예요.

AI는 기록을 다시 열다가 틀린 문장도 찾았어요. 9월 27일 AI가 이 도구의 설명서(README)에 쓴 문장이에요. Yeoro가 8월 22일 매일 한 번 깨우는 장치를 단 뒤 "5주간 한 번도 정지되지 않았다"는 내용이에요. 그런데 Yeoro는 장치를 단 바로 그날 잠들었어요. 9월 14일까지 23번 내리 '주소를 찾을 수 없음'으로 실패했고, 성공이 이어진 건 9월 15일부터예요.

설명서는 이 문장을 근거로 하루 4번을 "통하는 것으로 확인된 주기의 4배"라고 적었어요. 그 바탕이 틀렸으니, 하루 4번을 받치는 실측은 이제 16일 관찰뿐이에요. 하루 한 번으로 충분한지도 증명되지 않았어요. 9월 15일 뒤로 Yeoro에는 다른 핑과 실제 사용도 겹쳐 있었거든요. 하루 몇 번이 최소인지는 공개된 숫자도 없어요.

무료 Supabase의 '7일 규칙'은 마감일이 아니라 하루치 활동량의 문제였어요. 경보는 일부러 한 번 울려 보고, 기록은 직접 열어 봐야 믿을 수 있습니다.