기획 단계에서 비용 검증하기

📝 한줄 요약

기획 단계에서 “무료 플랜으로 충분할까?”를 검증해야 한다는 걸 배웠습니다. 저는 리마인더 기능을 Vercel의 크론으로 계획했다가, 무료 플랜의 제약을 발견하고 2시간 만에 다른 방법으로 수정했어요.

Before: 기술 스택을 그대로 믿고 구현 시작
After: 무료 플랜의 한계를 기획 단계에서 미리 확인, 대체 방법 준비

👥 이런 분께 추천

• 무료 또는 저비용 서비스로 개발하려는 분

• “이 기술로 될까?”를 구현 전에 빨리 검증하고 싶은 분

• 아키텍처 설계할 때 “만에 하나” 문제를 미리 예방하고 싶은 분

• AI와 함께 개발할 때 기술 결정의 위험 요소를 먼저 짚어야 한다고 생각하는 분

🙋 내 스펙 & 환경

진행 방법

1. 왜 비용 검증이 필요했나

기획하면서 리마인더 기능을 이렇게 설계했어요:

“미팅 전날 오후 12시에, 당일 오전 9시에 리마인더를 자동 발송한다”

그래서 기술 스택에는 “Vercel의 Cron 기능으로 시간을 정해서 실행”이라고 적었습니다. Vercel을 쓸 거니까 이미 있는 기능 아닌가, 라고 생각했거든요.

2. 발견한 문제: 무료 플랜의 제약

기획이 거의 끝났을 때, 공식 문서를 다시 읽어보니 이 문장이 있었어요:

“Vercel의 Cron Triggers는 Pro 이상의 플랜에서만 지원합니다. Hobby(무료) 플랜에서는 하루 1회 정도의 실행만 가능합니다.”

요약하면: 내가 원하는 건 하루 2회(전날 12시 + 당일 9시)인데, 무료 플랜은 안 된다는 뜻.

그리고 Vercel Pro는 월 20달러. 리마인더 하나 때문에 갑자기 비용이 생기는 건 말이 안 됐어요.

3. 해결 방법: Supabase pg_cron으로 대체

다른 방법을 찾았어요. 이미 프로젝트에서 Supabase를 DB로 쓰고 있었거든요.

Supabase는 PostgreSQL 기반인데, PostgreSQL에는 pg_cron이라는 확장 기능이 있습니다. 무료 플랜에서도 지원합니다.

구조는 이렇게 바꿨어요:

Before (Vercel Cron):

Vercel Cron → /api/reminders 호출 → DB 쿼리

After (Supabase pg_cron):

Supabase pg_cron → `/api/reminders` 호출 (주기적) → DB 쿼리

사실 매우 비슷합니다. 다만 “언제 실행할지”를 어디가 관리하는지가 다를 뿐.

4. 수정에 걸린 시간: 2시간

기획 문서를 수정했어요:

1. research.md에서 Vercel Cron 부분을 pg_cron으로 교체 (30분)

2. plan.md의 아키텍처 다이어그램 수정 (30분)

3. tasks.md의 “Cron 설정” 작업 설명 수정 (1시간)

만약 이걸 구현 후에 발견했다면?

• 이미 짠 코드를 뜯어고쳐야 함

• Vercel 설정을 다 빼고 Supabase 설정을 새로 추가

• 테스트를 다시 돌려야 함

• 최소 하루는 잡혀야 했을 거예요.

배운 점

💡 핵심 교훈

1. 무료 플랜의 제약은 기획 단계에서 확인해야 한다

“이 기술은 무료인가?”라는 질문을 먼저 해야 합니다. 구현 후에 발견하면 너무 늦어요.

좋은 체크리스트:

• 이 서비스의 무료 플랜 한계가 뭔가?

• 내 요구사항이 그 한계에 걸리는가?

• 유료 플랜으로 업그레이드하면 비용이 얼마나 든가?

• 대체 방법이 있는가?

2. 이미 도입한 기술을 먼저 살펴보자

저한테는 Supabase가 이미 있었어요. 그래서 또 다른 서비스를 추가하지 않고 기존 걸로 해결할 수 있었습니다.

새 기술을 추가할 때마다:

• 우리가 이미 쓰는 게 이 기능을 제공하지 않나?

• 추가 기술의 비용 vs 기존 기술 학습 비용

3. 기술 결정도 “검증 → 수정”의 사이클을 돈다

기획만이 아니라 기술 선택도 처음부터 완벽할 리 없습니다. 빨리 확인하고 바꾸는 게 낫습니다.

🔜 다음에 적용할 것

1. 모든 서비스의 무료 플랜 한계를 기획 문서에 명시하기 — “왜 이 기술을 골랐나”의 근거 중 하나로

2. 3가지 체크: 기능 한계, 비용, 대체 방법

3. 기획 검토 때 기술 리뷰도 함께 — “이 아키텍처가 무료 범위에서 동작하는가?”

솔직한 소감

처음엔 “무료라니까 당연히 다 되겠지”라고 생각했어요. 그런데 알고 보니 서비스마다 세부사항이 달라요.

다행히 기획 단계에서 발견했기 때문에, 문서 수정만으로 끝났습니다. 만약 구현 중간쯤에 알았다면 많이 흔들렸을 거고요.

비개발자로 시작했기 때문에 오히려 “이게 무료로 돼?” 질문을 자연스럽게 던질 수 있었던 것 같습니다. 개발자 경험이 있었다면 “당연히 있겠지” 넘어갔을 수도 있고요.

이번 경험으로 “기술 결정은 구현이 아니라 기획 단계에서 검증한다”는 게 얼마나 중요한지 배웠습니다.