Neon의 “Compute Quota Exceeded” 오류를 방지하기 위한 Vercel Cron 비활성화

요약 (TL;DR):

Neon DB의 무료 티어 컴퓨팅 할당량(compute quota)을 초과하던 야간 Vercel cron 작업을 제거했습니다. 변경 사항은 vercel.json의 한 줄 수정이었지만, 이를 통해 비용이 발생하는 오류를 방지하고 우리의 동기화 전략을 재고할 기회를 얻었습니다.

문제 상황

Vercel에서 tvview를 실행하면서, 매일 UTC 기준 09:05에 /api/cron/sync를 호출하도록 예약된 cron 작업을 설정했습니다:

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

이 엔드포인트는 우리의 Neon PostgreSQL 인스턴스와 대량 동기화(bulk sync)를 수행합니다. 무료 티어(free tier)에서 Neon은 컴퓨팅 사용량을 하루 1,000,000ms로 제한합니다. cron을 며칠 동안 실행한 후, 로그에 다음과 같은 메시지가 나타나기 시작했습니다:

2026-07-29 09:05:12 UTC - Neon: Compute quota exceeded

이 오류가 Vercel로 전달되면서 cron 작업이 실패하고 배포가 “errored” 상태로 진입했습니다. 사이트를 계속 운영하기 위해 cron을 중단해야 했지만, 이는 야간 데이터 동기화(data sync)를 포기해야 함을 의미했습니다.

처음 시도했던 방법들

1. Neon 컴퓨팅 할당량 증설 – 무료 티어에서는 불가능한 옵션이었습니다.
2. 동기화 속도 조절 (Throttle) – /api/cron/sync 내부에 짧은 sleep 루프를 추가했지만, 전체 실행 시간(total runtime)이 여전히 작업당 1ms를 초과했기 때문에 할당량 초과 문제는 여전했습니다.
3. 동기화를 별도의 서버리스 함수(serverless function)로 이동 – setImmediate를 사용하여 작업을 지연시키는 새로운 /api/cron/async-sync를 만들었지만, Vercel은 여전히 함수 전체 실행 시간에 대해 비용을 청구했으므로 할당량 초과 문제는 해결되지 않았습니다.
4. cron 스케줄 조정 – 09:05 대신 02:00 UTC에 실행하도록 시도해 보았지만, 전체 실행 시간은 변하지 않았기 때문에 여전히 할당량이 초과되었습니다.

이러한 시도 끝에, 가장 간단한 해결책은 **cron을 완전히 비활성화(disable)**하고 동기화를 수동으로 처리하거나 다른 트리거를 통해 처리하는 것임을 깨달았습니다.

구현 방법

1단계: vercel.json 수정

crons 섹션을 완전히 제거하여 빈 설정 객체로 남겨두었습니다:

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

커밋 해시 (Commit hash): ad42e116. 커밋 메시지 (Commit message): chore: disable nightly cron sync — Neon free tier compute quota exceeded.

2단계: 배포 확인 (Verify Deployment)

변경 사항을 푸시(push)한 후, Vercel은 예약된 작업(scheduled jobs) 없이 tvview를 재배포했습니다. 배포 로그를 통해 크론(cron)이 예약되지 않았음을 확인했습니다:

2026-07-29 10:02:45 UTC - Vercel: No crons configured

3단계: 문서 업데이트 (Update Documentation)

새로운 동기화 전략을 반영하기 위해 README를 업데이트했습니다. 크론에 의존하는 대신, 수동 트리거 엔드포인트 (manual trigger endpoint)를 추가했습니다:

// pages/api/cron/manual-sync.ts
import { syncDatabase } from '@/lib/sync';

...

이제 동기화는 보안 웹훅 (secure webhook) 또는 수동 HTTP 호출을 통해 호출될 수 있습니다.

핵심 요약 (Key Takeaway)

예약된 작업이 제공업체의 할당량 (quota)에 반복적으로 도달할 때, 안정성을 확보하는 가장 빠른 방법은 트리거를 제거하고 이를 제어 가능한 온디맨드 (on-demand) 메커니즘으로 교체하는 것입니다.

이 사례의 경우, 단 한 줄의 JSON 수정으로 프로젝트가 지속적인 실패를 겪는 것을 막을 수 있었지만, 동시에 컴퓨팅 사용량을 모니터링하고 작업 빈도를 할당량 제한에 맞추는 것이 얼마나 중요한지를 보여주었습니다.

다음 단계 (What's Next)

1. 큐 기반 동기화 구현 (Implement a queue-based sync) – 무거운 동기화 로직을 속도 제한 (rate-limited) 및 안전한 재시도 (retry)가 가능한 백그라운드 워커 (background worker, 예: BullMQ 사용)로 이동합니다.
2. 메트릭 추가 (Add metrics) – Neon 컴퓨팅 사용량을 보고하는 /metrics 엔드포인트를 노출하고, 이를 Prometheus에 연결하여 알림 (alerting)을 설정합니다.
3. 유료 Neon 티어 검토 (Explore paid Neon tier) – 동기화가 매일 필수적이 된다면, 더 높은 컴퓨팅 제한을 가진 티어로 업그레이드하는 것을 고려합니다.
4. 크론 재활성화 자동화 (Automate cron re-enable) – 기능 플래그 (feature flag)를 사용하여 데이터베이스 플래그에 따라 크론을 켜거나 끌 수 있도록 하여, 할당량이 증설되면 야간 동기화를 다시 재개할 수 있도록 합니다.

하드코딩된 크론에서 유연하고 모니터링 가능한 동기화 프로세스로 전환함으로써, 컴퓨팅 제한에 다시 도달하는 것을 방지하고 데이터 파이프라인을 견고하게 유지할 수 있을 것입니다.

vibecoding #buildinpublic #vercel #cron #neon #free-tier #nodejs #serverless #devops

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

Repo: zaerohell/tvview · 2026-07-29

#playadev #buildinpublic