Dev 서버 테스트 가능 여부

권장 로컬 테스트 순서

Phase별로 각각 독립적으로 테스트하는 것이 효율적입니다.

1. vercel dev 실행
   → http://localhost:3000/api/rss-register 에 curl로 직접 POST 테스트

2. vitepress dev 실행
   → 폼 UI에서 실제 제출 테스트 (vercel dev와 동시 실행)

3. 이메일 수신 확인
   → 운영자/사용자 이메일 템플릿 육안 확인

4. 승인 링크 클릭
   → REVIEW_BASE_URL이 localhost를 가리키므로 로컬에서 바로 처리

5. ts-node로 generate-configs.ts 직접 실행
   → config 파일 생성 결과 확인

6. 스크래퍼 실행
   → 생성된 config로 md 파일 정상 생성 확인

결론부터

일부는 가능, 일부는 대체 방법이 필요합니다.

컴포넌트별 로컬 테스트 가능 여부

컴포넌트	로컬 테스트	방법
VitePress 신청 폼 UI	✅ 완전 가능	vitepress dev
Neon DB 연결	✅ 완전 가능	로컬에서 직접 접속 (Neon은 클라우드 DB)
Edge Function	✅ 가능	vercel dev 로컬 실행
Resend 이메일	⚠️ 제한적	테스트 모드 or 실제 발송
GitHub Actions	❌ 직접 불가	act로 로컬 시뮬레이션 가능
Vercel 빌드	⚠️ 부분 가능	vitepress build로 대체

로컬 테스트 환경 구성

기본 구성

vitepress dev       ← 폼 UI 확인
vercel dev          ← Edge Function 로컬 실행
Neon DB             ← 로컬/클라우드 공용 (별도 test 브랜치 권장)

Neon DB는 브랜치 기능을 제공합니다. main 브랜치를 건드리지 않고 dev 브랜치를 따로 만들어 테스트용 DB로 사용할 수 있습니다.

Neon DB
├── main   ← 운영 데이터
└── dev    ← 테스트 전용 (언제든 초기화 가능)

환경변수 분리

# .env.local (로컬 전용, .gitignore 등록 필수)
DATABASE_URL=neon://dev-branch-url    # dev 브랜치
RESEND_API_KEY=re_test_xxxx           # Resend 테스트 키
ADMIN_EMAIL=본인이메일@gmail.com
REVIEW_BASE_URL=http://localhost:3000  # 로컬 review 링크

Resend 로컬 테스트

Resend는 실제 API Key로 발송하되, 수신자를 본인 이메일로 고정하면 됩니다. 별도 목(mock) 서버 없이 실제 이메일로 템플릿을 바로 확인할 수 있어 오히려 편합니다.

GitHub Actions 로컬 시뮬레이션

act 도구를 사용하면 Actions를 로컬에서 실행할 수 있습니다.

# act 설치
brew install act  # macOS

# 스크래퍼 워크플로우 로컬 실행
act -j scrape --secret-file .secrets

다만 act는 Docker가 필요하고 완전히 동일하게 재현되지 않을 수 있어, config 생성 스크립트만 단독으로 ts-node로 직접 실행하는 방식이 더 간편합니다.

npx ts-node scripts/generate-configs.ts

유일하게 로컬에서 재현 안 되는 것

Vercel의 푸시 감지 → 자동 빌드 트리거입니다. 이 부분만 실제 커밋을 push해서 Vercel 대시보드에서 확인해야 합니다. 나머지는 모두 로컬에서 검증 가능합니다.