분석 & 통합 · 2026-06-05

크론 아키텍처 — 6개 → 2개 통합

"크론 몇 종류 도나? 상호배타는 나누고, 의존성 있는 건 묶자"는 점검. 분석 결과 하비 플랜 2-크론 한도를 6개가 초과(대부분 안 돌 위험) + 유령 크론 + 의존성 타이밍 문제를 발견 → 코칭/커뮤니티 2배치로 통합.

Before · 통합 전

크론 6개(+유령) · 발견된 문제 4

🚨 가장 심각 — 하비 2-크론 한도 초과

remap 라우트 주석에 직접 "Hobby 크론 수 절약"이라 적혀 있다(=하비 플랜). 하비는 크론 2개·하루 1회 제한 → 6개 등록 시 대부분이 조용히 안 돌았을 가능성. (코칭만 실측 확인됨.)

상호배타 vs 의존 — 크론들은 대부분 독립(코칭 ↔ 커뮤니티). 유일한 의존 = tip-ranking → coach(coach_letters.context를 읽음). 그런데 별도 크론 30분 뒤라, 스케일되면 coach가 안 끝난 채 tip-ranking이 어제 데이터로 계산.
coach 내부는 이미 의존 그룹화됨 — backfillUnmappedMenus(메뉴→식재료 매핑) → 영양 분석 → 편지. 한 함수 안.

After · 통합 후

vercel.json 크론 2개(하비 한도 충족). 각 배치가 의존 작업을 self-fetch 체이닝으로 순서 보장. 라우트 파일은 보존(수동 트리거·백필).

보상(주간 톱10/월간, 월·1일만 발동) 실행 → 끝에 drip(매일 코치 PICK 공식 글 게시) 체이닝. 둘 다 커뮤니티·서로 독립이라 한 배치.

(backfill →) 편지·질문·휴면 복귀·회유 알림톡 → 끝에 tip-ranking(coach_letters 갱신 직후) 체이닝. 의존성·타이밍 문제 제거.

제거

enrich(no-op·큐 비어있음) · moderate-comments(유령 라우트) · tip-ranking/drip 스케줄(배치에 체이닝). → 라우트는 남겨 수동 호출 가능(드립 백필 ?n=20 등).

체이닝 = 같은 배포 URL로 fetch(new URL('/api/cron/...', req.url)) + authorization 포워드(둘 다 동일 CRON_SECRET 가드). 실패해도 본 배치는 정상 반환(try/catch).

Cost · 운영 비용

항목	단가	현재(활성 ~1명)	활성 1,000명 가정
코칭 편지·질문 LLM	`claude-haiku-4-5`(초저가)	월 수백 원	~월 40만 원
tip-ranking·drip·rewards	LLM 0(결정론·DB만)	0	0(쿼리비 무시)
알림톡(편지·회유)	₩8/건	₩0(도먼트)	~월 24만(전원 수신 가정)
Vercel	하비=무료	0	Pro 전환 시 $20

요약

크론 운영비를 끌어올리는 건 사실상 코칭 편지 LLM(하이쿠) 하나뿐. 커뮤니티 크론(드립·보상·랭킹)은 LLM을 안 써서 공짜에 가깝다. 알림톡은 켤 때만 비용 발생(₩8/건). 현재 사용자 규모에선 월 1,000원 미만.