Neon 할당량 제한을 피하기 위한 Vercel Cron 비활성화

요약 (TL;DR):

Neon의 무료 티어 (free tier) 할당량 초과를 막기 위해 vercel.json에서 매일 밤 실행되던 /api/cron/sync 크론 (cron)을 제거했습니다. 이 변경 사항은 Vercel이 매일 아침 동기화 엔드포인트 (sync endpoint)를 호출하는 것을 중단시키는 단 한 줄의 수정입니다.

문제 (The Problem)

제 pcview 앱은 외부 API로부터 최신 데이터를 가져와 Neon 데이터베이스에 기록하기 위해 매일 밤 실행되는 동기화 엔드포인트 (/api/cron/sync)를 사용합니다. 7월 28일에 앱에서 다음과 같은 오류가 발생하기 시작했습니다:

2026-07-28 09:15:23 UTC | neon | ERROR | Quota exceeded: 500 write requests per hour

Vercel이 15 9 * * * 시간에 크론 (cron)을 실행할 때마다 쓰기 제한 (write-limit)에 걸려 동기화가 실패했습니다. 로그에는 Neon으로부터 반복적인 429 응답이 나타났으며, 이로 인해 전체 동기화 파이프라인 (sync pipeline)이 중단되었습니다.

처음 시도했던 방법들 (What I Tried First)

1. Neon 플랜 업그레이드 (Increase Neon Plan) – Neon 대시보드를 확인해보니 무료 티어 (free tier)를 사용 중이었습니다. 업그레이드하려면 월 5달러가 비용이 발생하는데, 작은 개발 프로젝트를 위해 지불하고 싶지 않았습니다.
2. 재시도 로직 추가 (Add Retry Logic) – 동기화 핸들러 (sync handler)에 지수 백오프 (exponential backoff)를 적용했지만, 할당량 오류가 즉각적으로 발생했기 때문에 재시도는 도움이 되지 않았습니다.
3. 쓰기 속도 제한 (Throttle Writes) – 쓰기 작업을 더 작은 청크 (chunks)로 배치 (batching) 처리하려고 시도했지만, 외부 API가 데이터를 단일 페이로드 (payload)로만 제공했기 때문에 여전히 500회 쓰기 제한에 걸렸습니다.

이 방법들은 모두 효과가 없었는데, 근본 원인은 페이로드 (payload) 크기가 아니라 크론 (cron)의 **실행 빈도 (frequency)**였기 때문입니다.

구현 (The Implementation)

해결책은 크론 (cron)을 완전히 비활성화하는 것이었습니다. Vercel의 크론 (cron) 설정은 vercel.json에 위치합니다. 원래 파일은 다음과 같았습니다:

{
  "crons": [{ "path": "/api/cron/sync", "schedule": "15 9 * * *" }]
}

저는 Vercel에 예약된 작업이 없음을 알리기 위해 이를 빈 객체로 교체했습니다:

-{ 
-  "crons": [{ "path": "/api/cron/sync", "schedule": "15 9 * * *" }]
-}
...

이 커밋(chore: disable nightly cron sync — preventive, before hitting Neon quota)을 푸시한 후, Vercel은 동기화 엔드포인트(sync endpoint)를 호출하는 것을 중단했습니다. Vercel 대시보드의 Scheduled Functions 항목에서 더 이상 크론 잡(cron job)이 나타나지 않는 것을 확인했습니다.

왜 빈 객체인가요?

Vercel은 crons 키가 없는 상태를 "크론 잡 없음"으로 처리합니다. 이를 {}로 설정함으로써 이전의 모든 설정을 명시적으로 덮어쓰고(override), 제가 다시 추가하기 전까지 플랫폼이 동기화를 다시 시도하지 않도록 보장합니다.

핵심 요약 (Key Takeaway)

예약된 작업(scheduled job)이 외부 할당량 위반(quota violations)을 일으키고 있다면, 가장 빠른 기술적 해결책은 vercel.json에서 크론 설정을 제거하거나 비활성화하는 것입니다.

이 접근 방식은 문제를 일으키는 트래픽을 즉시 중단시키고, 작업을 재설계(예: 큐(queue)에 의해 트리거되는 서버리스 함수(serverless function)로 이동하거나 다른 스케줄로 변경)할 시간을 벌어주며, 더 높은 티어(tier)를 결제하는 상황을 방지합니다.

다음 단계

1. 동기화를 수동 트리거로 재구현 – CI 파이프라인이나 관리자 UI의 수동 버튼을 통해 호출할 수 있는 보호된 /api/cron/sync 엔드포인트를 노출합니다.
2. 큐 레이어(queue layer) 추가 – Cloudflare Workers KV나 간단한 Redis 큐와 같은 것을 사용하여 동기화 요청을 배치(batch) 처리하고 Neon의 쓰기 제한(write limits)을 준수합니다.
3. Neon 사용량 모니터링 – 쓰기 할당량 임계값(write-quota thresholds)에 대한 알림을 설정하여, 한도에 다시 도달하기 전에 알림을 받을 수 있도록 합니다.

동기화를 자동 크론에서 분리하여 제어 가능한 온디맨드(on-demand) 프로세스로 전환함으로써, 추가 비용 발생 없이 앱의 신뢰성을 유지할 수 있습니다.

vibecoding #buildinpublic #vercel #cron #neon #prisma #fullstack #devops #serverless #latamdevs

제 Build in Public 시리즈의 일부 — 멕시코 플라야 델 카르멘(Playa del Carmen)에서 SaaS 프로젝트를 구축하는 실제 과정을 공유합니다.

Repo: zaerohell/pcview · 2026-07-29

#playadev #buildinpublic