"Supabase 무료 플랜 프로젝트 자동 일시 중지 왜 되는 건가요?"

"Supabase 무료 플랜은 7일 동안 DB 쿼리가 없으면 서버 자원 회수를 위해 프로젝트를 자동으로 일시 중지해요. 중지된 프로젝트를 복구하려면 Supabase 대시보드에서 직접 Restore 버튼을 눌러야 하며, 수분에서 수십 분이 걸릴 수 있어요."

"Supabase 무료 플랜 프로젝트 일시 중지 방지 자동화 방법 GitHub Actions로 설정하는 법"

"Supabase 무료 플랜 프로젝트 일시 중지 방지 자동화 방법 실전 설정은 GitHub Actions의 schedule 트리거로 5일마다 'SELECT 1' 더미 쿼리를 DB에 자동으로 날리는 방식이에요. DB 연결 문자열을 GitHub Secrets에 저장한 뒤 .github/workflows/keep-alive.yml 파일을 작성하면 되며, 전체 설정 시간은 15분 내외예요."

"GitHub Actions cron 스케줄 Supabase 비활성 방지 몇 일 간격이 안전한가요?"

"Supabase의 7일 비활성 정책 기준으로 이론상 6일 간격이면 충분하지만, GitHub Actions 큐 지연과 타임존 차이를 고려하면 5일 간격(cron '*/5')이 더 안정적이에요. 이 설정은 한 달에 약 여섯 번 쿼리를 실행해 프로젝트 활성 상태를 유지해요."

"Supabase 프로젝트 일시 중지 방지 GitHub Actions 말고 다른 방법 있나요?"

"cron-job.org 같은 외부 크론 서비스나 로컬 crontab, Vercel Cron Jobs 등을 사용할 수도 있어요. 다만 로컬 crontab은 PC가 항상 켜져 있어야 하고, 외부 서비스는 신뢰도가 변수라는 단점이 있어서 실행 로그가 남고 추가 비용 없이 쓸 수 있는 GitHub Actions가 사실상 표준으로 자리 잡고 있어요."

"Supabase 무료 플랜 프로젝트 일시 중지 방지 자동화 방법 실전 설정 사이드 프로젝트 말고도 쓸 수 있나요?"

"Supabase 무료 플랜 프로젝트 일시 중지 방지 자동화 방법 실전 설정은 개인 사이드 프로젝트뿐 아니라 트래픽이 간헐적인 사내 데모 환경에도 그대로 적용할 수 있어요. DB에 주기적으로 가벼운 쿼리만 날리는 방식이라 프로젝트 종류나 규모에 관계없이 동일하게 동작해요."

생산성

Supabase 무료 플랜 프로젝트 일시 중지 방지 자동화 방법 GitHub Actions 실전 설정

May 3, 2026 5 min read 한국어

어느 날 아침, 사이드 프로젝트 DB가 통째로 잠겨버린 적 있으세요? Supabase 무료 플랜은 7일 동안 DB 쿼리가 없으면 프로젝트를 자동 일시 중지해요. 개발자 커뮤니티에서 꾸준히 불만이 올라오는 이유가 바로 이거예요. 그런데 GitHub Actions 한 번 설정해두면 이 문제 완전히 사라져요.

핵심 요약
Supabase 무료 플랜은 7일 이상 비활성 상태인 프로젝트를 자동 일시 중지하며, 해제하려면 대시보드에서 수동 복구가 필요해요.
GitHub Actions의 schedule 트리거를 쓰면 매주 자동으로 DB에 더미 쿼리를 날려 활성 상태를 유지할 수 있어요.
cron 스케줄을 5~6일 간격으로 맞추면 7일 정책 안에서 안전하게 작동하고, 설정 소요 시간은 15분 내외예요.
이 방식은 무료 플랜 사용자뿐 아니라 트래픽이 간헐적인 개인 프로젝트, 사내 데모 환경에도 그대로 적용돼요.

Supabase 무료 플랜, 왜 이렇게 만들었을까요?

Supabase는 Firebase 대안으로 2020년에 등장한 오픈소스 BaaS예요. PostgreSQL 기반이라 관계형 DB의 모든 기능을 쓸 수 있고, 인증, 실시간 구독, 스토리지까지 한 번에 붙여줘요. Logto 블로그의 2026년 분석에 따르면, AI 스타트업들이 빠른 프로토타이핑 단계에서 Supabase를 선택하는 비율이 빠르게 늘고 있어요. 그만큼 “일단 무료로 시작해보자"는 개발자가 많다는 뜻이기도 하죠.

문제는 무료 플랜 정책에 있어요. 7일 동안 DB 쿼리가 없으면 프로젝트가 자동으로 일시 중지돼요. 프로젝트당 월 500MB DB, 5GB 스토리지, 50,000 MAU라는 넉넉한 혜택을 제공하는 대신, 비활성 프로젝트에 쓰이는 서버 자원을 회수하는 거예요. 사업적으로는 이해가 되는 결정이지만, 사이드 프로젝트를 주말마다만 건드리는 개발자한테는 꽤 불편한 제약이에요.

실제 개발자 커뮤니티 반응도 비슷해요. yangdongi.com 블로그에서 분석한 것처럼, 잠든 프로젝트를 복구하려면 대시보드에서 Restore 버튼을 눌러야 하는데, 수분에서 최대 수십 분 걸리기도 해요. 팀 데모 전날 밤에 DB가 잠겨버리면 그때야말로 진짜 난감하죠.

타임라인 정리:

2022년 이전: 비활성 정책 없음
2022년: 7일 비활성 자동 중지 정책 도입
2023~2024년: 커뮤니티에서 GitHub Actions 우회법 확산
2026년 현재: 정책 유지 중, 공식 해결책 없음

GitHub Actions로 자동화하는 실전 설정

핵심 원리: “DB를 깨어있게 만드는 가장 작은 쿼리”

Supabase의 활성 여부 판단 기준은 단순해요. DB에 쿼리가 날아오면 활성 상태로 간주해요. 아주 가벼운 SELECT 1 하나면 충분하다는 뜻이죠. GitHub Actions는 이 쿼리를 주기적으로 자동 실행해주는 스케줄러 역할을 해요.

설정은 크게 세 단계예요.

1단계: Supabase DB 연결 정보 확인

Supabase 대시보드 → Project Settings → Database → Connection String에서 DATABASE_URL을 복사해요. 형식은 이렇게 생겼어요:

postgresql://postgres:[PASSWORD]@db.[PROJECT_REF].supabase.co:5432/postgres

2단계: GitHub Secrets에 저장

레포 Settings → Secrets and variables → Actions → New repository secret에서 SUPABASE_DB_URL로 등록해요. 연결 문자열에 비밀번호가 들어가 있으니 절대 코드에 직접 쓰면 안 돼요.

3단계: Workflow 파일 작성

.github/workflows/keep-alive.yml 파일을 만들어요:

name: Supabase Keep Alive

on:
  schedule:
    - cron: '0 9 */5 * *'  # 5일마다 오전 9시 실행
  workflow_dispatch:        # 수동 실행도 가능하게

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - name: Ping Supabase DB
        run: |
          psql "${{ secrets.SUPABASE_DB_URL }}" -c "SELECT 1;"

이게 전부예요. 15분이면 충분히 할 수 있어요.

cron 스케줄, 얼마나 자주 맞춰야 할까요?

7일 정책이니까 6일 간격이면 이론상 안전해요. 그런데 타임존 차이나 GitHub Actions 큐 지연을 고려하면 5일 간격(*/5)이 더 안정적이에요. */5는 매달 1, 6, 11, 16, 21, 26, 31일에 실행하는 방식이에요. 한 달에 여섯 번 정도 쿼리가 날아가는 셈이에요.

방법 비교: GitHub Actions vs 다른 선택지들

방법	비용	설정 난이도	안정성	유지보수
GitHub Actions	무료 (공개 레포)	⭐⭐☆ 보통	✅ 높음	거의 없음
Vercel Cron Jobs	유료 플랜 필요	⭐☆☆ 쉬움	✅ 높음	거의 없음
로컬 crontab	무료	⭐⭐⭐ 복잡	⚠️ PC 켜져 있어야 함	가끔 필요
외부 크론 서비스 (cron-job.org)	무료 플랜 있음	⭐☆☆ 쉬움	⚠️ 신뢰도 변수	모니터링 필요
수동 복구	무료	없음	❌ 잊으면 끝	매번 해야 함

GitHub Actions가 사실상 표준 방법으로 자리 잡은 건 이유가 있어요. 레포가 이미 있으면 추가 비용 없이 바로 붙일 수 있고, 실행 로그가 남아서 “정말 돌았나?” 확인도 쉬워요. 반면 로컬 crontab은 PC가 꺼져 있으면 그냥 실패예요. 외부 크론 서비스는 무료 플랜의 실행 빈도 제한이 생각보다 빡빡한 경우가 있어요.

실전에서 자주 막히는 지점들

`psql` 명령어가 없다고 나와요

ubuntu-latest runner에는 기본적으로 psql이 설치돼 있어요. 간혹 버전 이슈로 안 될 때는 apt-get install postgresql-client -y 단계를 앞에 추가해주면 돼요:

- name: Install psql
  run: sudo apt-get install -y postgresql-client

DB URL에 특수문자 포함된 비밀번호가 문제예요

Supabase가 자동 생성한 비밀번호에 @, # 같은 특수문자가 들어가면 URL 파싱이 깨져요. 이럴 때는 URL 인코딩된 형태로 바꾸거나, Supabase 대시보드에서 비밀번호를 영문+숫자만으로 재설정하는 게 제일 빠른 방법이에요.

공개 레포라서 민감한 정보가 걱정돼요

SUPABASE_DB_URL을 GitHub Secrets에 넣는 한 코드에는 노출 안 돼요. Secrets는 로그에서도 자동 마스킹돼요. workflow_dispatch로 수동 실행할 때도 마찬가지예요.

이 설정, 어디까지 쓸 수 있을까요?

개인 사이드 프로젝트라면 지금 당장 적용하는 게 맞아요. 주말 해커톤 결과물, 포트폴리오용 풀스택 앱, 개인 대시보드 — 전부 해당돼요.

팀 데모 환경도 좋은 케이스예요. 스테이징 DB가 데모 당일 아침에 잠겨서 허겁지겁 복구하는 상황, 한 번쯤 겪어봤을 거예요. 이 자동화 하나면 그런 돌발 상황이 없어져요.

단, 주의할 점: 이 방식은 Supabase 정책의 허점을 파고드는 게 아니에요. 실제로 DB를 “사용 중"인 상태를 유지하는 거니까 정책 위반도 아니에요. Supabase 공식 포럼에서도 이런 방식에 대한 제재 언급은 없어요.

앞으로 Supabase가 무료 플랜 정책을 어떻게 바꿀지는 미지수예요. 비활성 판단 기준을 더 엄격하게 만들거나, 반대로 무료 플랜 혜택을 늘리는 방향으로 갈 수도 있어요. 2026년 현재 Supabase의 Series C 이후 상업화 압력이 커지고 있다는 점은 고려해둘 필요가 있어요.

정리하면

7일 비활성 정책은 사라지지 않을 가능성이 높아요. 비용 구조상 당연한 결정이니까요.
GitHub Actions + SELECT 1 조합은 현재 가장 안정적이고 비용 없는 방법이에요.
5일 간격 cron으로 설정하면 타임존 오차에도 안전 마진이 확보돼요.
한 번만 설정하면 끝이에요. 이후 신경 쓸 게 없어요.

Supabase 무료 플랜을 쓰는 사이드 프로젝트가 지금 몇 개나 잠들어 있는지 확인해봤나요? 대시보드 열어서 확인하는 데 30초, 자동화 설정에 15분이면 다시는 이 문제 안 만나도 돼요.

참고자료

Photo by Akshat Sharma on Unsplash