기능 지원과 운영 노력을 함께 비교해
| 플랫폼 | SSR | ISR | Edge | 운영 노력 |
|---|---|---|---|---|
| Vercel | 지원 | 전 세계 CDN | 지원 | 설정이 가장 적음 |
| Netlify | 지원 | DPR로 지원 | 지원 | 쉬움 |
| AWS Amplify | 지원 | 지원 | 제한적 | 중간 |
| Cloudflare Pages | 지원 | 제한적 | 지원 | 중간 |
| Railway·Fly.io | 지원 | 지원 | 미지원 | 쉬움 |
| 임의 클라우드의 Docker | 지원 | 지원 | 미지원 | 직접 운영 |
떠날 때 되찾아야 하는 운영 기능이 있어
- ISR 캐시가 전 세계가 아니라 한 region에만 남을 수 있어.
- 이미지 최적화에
sharp나 사용자 loader가 필요해. - 자동 preview 주소 대신 staging 환경을 직접 만들어야 해.
- SSL, 확장, 관측이 모두 앱 팀의 책임으로 돌아와.
플랫폼 가격만 비교하지 마
인프라 청구액이 낮아져도 운영 시간과 장애 복구 부담이 커질 수 있어. 규정, 지역, 비용처럼 실제 제약이 Vercel의 편의를 넘어설 때 이동하고, 잃는 기능마다 새 주인을 정해.
대안 플랫폼에서 실제 앱의 SSR, 서버 액션, ISR, 이미지, preview를 작은 배포로 검증해. 지원 체크표만 보지 말고 cache가 여러 region과 인스턴스에서 어떻게 공유되는지, framework upgrade가 누가 관리하는지, 장애 로그에 얼마나 빨리 닿는지 기록해. 이식성 검증은 컨테이너가 한 번 뜨는 데서 끝나지 않아. 트래픽이 있는 동안 인스턴스를 교체하고, 캐시를 비우고, 이미지 변환과 예약 작업을 실행해 봐. 그 과정에서 세션과 업로드가 유지되고 로그가 한곳에 모여야 실제 운영 대안이 돼. 복구 시간을 재고 담당자를 적어 두면 플랫폼 편의의 가격과 자체 운영 비용을 같은 단위로 비교할 수 있어.
Vercel을 떠나는 이유가 단순 단가라면 운영 인건비와 잃는 preview 속도까지 합쳐 봐. 반대로 규정과 데이터 지역성처럼 돈으로 해결할 수 없는 제약은 편의보다 우선해. 플랫폼 선택은 기능 우승자가 아니라 현재 제약의 주인을 정하는 결정이야. 같은 작은 앱을 후보 플랫폼 두 곳에 배포해 preview 생성 시간, SSR 위치, ISR 공유, 이미지 응답, 로그 접근을 직접 비교해. 인스턴스를 늘리고 한 region 캐시를 갱신해 다른 region 결과가 언제 바뀌는지도 보면 지원 체크표 뒤의 운영 차이가 드러나.