Supabase Free 프로젝트 7일 비활성, Workers Cron으로 관리하기

Supabase Free 프로젝트는 최근 7일 동안 사용자 데이터베이스 활동이 충분하지 않으면 일시정지 대상이 될 수 있어요. 정확히 7일마다 멈춘다는 뜻은 아니고, 플랫폼이 지난 1주간의 활동을 보고 판단한다는 의미예요. 일시정지된 API 요청은 540 상태로 응답할 수 있으니, 백엔드에서는 단순 장애와 구분해 두는 편이 좋아요.

직접 만들어 보니 이 문제는 화면 접속 여부보다 DB 요청의 흐름으로 관리하는 편이 명확했어요. Workers Cron이 정해진 시간에 실행되고, 인증된 내부 엔드포인트가 가벼운 쿼리 1개를 수행하도록 나누면 역할도 분명해집니다.

Workers Cron→인증된 API 엔드포인트→가벼운 DB 쿼리→실행 로그 확인

구성은 3단계로 잡을 수 있어요. 먼저 Worker의 scheduled() 핸들러에 Cron Trigger를 연결해요. Cron Trigger는 UTC 기준으로 동작하므로, 운영 기준 시간이 한국 시간이라면 표현식을 계산할 때 시차를 확인해야 해요. 다음으로 Worker는 외부에 열린 테이블을 바로 호출하지 않고, 별도의 인증된 API 경로를 요청해요. 이 경로에서는 Bearer 토큰을 검증한 뒤 읽기 전용의 짧은 쿼리만 실행합니다.

적용해 봤더니 토큰을 코드나 설정 파일에 넣지 않는 원칙이 특히 중요했어요. Worker의 secret 저장소에 인증 값을 두고, 요청 대상도 필요한 경로만 허용하는 방식이 안전합니다. DB 권한은 keepalive 전용으로 최소화하고, 쓰기 쿼리나 사용자 데이터를 조회하는 쿼리는 넣지 않는 편이 좋아요.

테스트해 보면 Cron이 실행됐다는 기록만으로는 충분하지 않아요. Worker 실행 로그, API의 인증 성공 로그, DB 요청 결과까지 3곳을 함께 확인해야 합니다. 실패 시에는 재시도 횟수를 제한하고, 연속 실패를 알림으로 보내면 일시적인 네트워크 오류와 설정 오류를 나눠 볼 수 있어요.

• ✓최소 권한 토큰
• ✓읽기 전용 쿼리 1개
• ✓Cron과 DB 로그 동시 확인

돌려 보니 keepalive는 가용성 보장 장치가 아니라 개발용 프로젝트를 관리하는 보조 수단에 가까웠어요. Supabase도 하루에 몇 건의 DB 요청이 일반적으로 도움이 된다고 안내하지만, 일시정지 방지를 보장하지는 않아요. 중단 없이 운영해야 하는 서비스라면 유료 플랜 전환과 백업·장애 대응을 별도로 검토해야 합니다. 라이프케어로그의 플랜씨(plan-c)처럼 로그인 없이 쓰는 서비스도 이런 인프라 기준을 먼저 정리해 두면 운영 판단이 수월해져요.