무료 호스팅부터 상시 서버까지: Vercel 대체 서비스 6곳 비교

무료 호스팅을 포함해 Vercel 대체 서비스를 고를 때는 앱에서 어떤 작업을 계속 실행해야 하는지부터 살펴봐야 합니다. 정적 사이트나 엣지 워크로드에는 Cloudflare Workers와 Pages, 상시 실행하는 풀스택 서비스에는 Render나 Railway, 관리형 Next.js 워크플로에는 Netlify가 유력합니다. 이 글에서 비교하는 6곳에는 인프라를 직접 제어하기 좋은 Fly.io와, 이미 AWS를 사용하면서 호환 요건을 충족하는 앱에 맞는 AWS Amplify도 포함됩니다. 앱은 잘 작동하고 비용만 문제라면, 이전에 앞서 Vercel의 현재 과금 방식과 지출 제어 기능을 확인하는 편이 좋습니다.

가격과 문서에 명시된 기능은 2026년 11월 3일 각 서비스의 공식 페이지를 기준으로 확인했습니다. 이 글은 문서에 근거한 비교이며, 직접 배포해 성능을 측정한 벤치마크는 아닙니다. 코드를 옮길 수 있는지와 기존 호스팅의 동작을 어떻게 대체해야 하는지를 구분해 추천합니다.

무료 호스팅부터 유료 서버까지, Vercel 대체 서비스 한눈에 비교

상시 실행하는 풀스택 앱이라면 Render를 우선 검토하고, 정적 사이트나 호환 가능한 엣지 워크로드라면 Cloudflare부터 살펴보는 것이 좋습니다. 일반적인 서버를 확보하는 것보다 관리형 Next.js 배포 워크플로를 유지하는 일이 중요하다면 Netlify도 후보에 넣어야 합니다.

아래의 시작 가격은 서로 다른 대상을 기준으로 합니다. 초소형 가상 머신, 일정량의 크레딧, 빌드 시간은 같은 프로덕션 환경을 뜻하지 않습니다. 가격은 모두 USD이며, 사용량과 추가 서비스, 적용되는 세금에 따라 실제 청구액이 늘어날 수 있습니다.

Next.js 호스팅, 업체보다 런타임을 먼저 결정해야 합니다

호스트가 수행해야 할 작업부터 정한 뒤, 같은 유형의 서비스를 비교해야 합니다. 정적 사이트는 미리 빌드한 파일을 전달합니다. 서버 사이드 렌더링, 즉 SSR은 요청이 들어올 때 응답을 생성합니다. 상시 실행 서비스는 애플리케이션 코드를 실행할 수 있도록 계속 가동되며, 백그라운드 워커는 방문자의 요청 처리와 별개로 작업을 수행합니다.

마케팅 사이트와 AI 제품을 함께 운영하는 창업자라면 이 작업들을 나눠서 볼 필요가 있습니다. 마케팅 페이지는 정적으로 제공할 수 있습니다. 채팅 엔드포인트는 응답을 스트리밍해야 합니다. 문서 수집·처리에는 고객이 브라우저를 닫은 뒤에도 계속 실행되는 별도 워커가 필요할 수 있습니다.

선택을 가르는 기준은 다음과 같습니다. 파일 전달이 핵심이면 Cloudflare, 관리형 Next.js 배포를 유지하려면 Netlify, 실행 중인 프로세스와 백그라운드 작업을 직접 관리하려면 Render나 Railway를 우선 검토합니다. 배치 위치와 인프라 제어가 요구 사항이라면 Fly.io를, AWS 연동이 중요하고 지원 기능이 앱과 맞는다면 Amplify를 고려할 만합니다.

이는 후보를 처음 추리는 기준이지, 엣지 플랫폼에서는 백그라운드 워크플로를 실행할 수 없다는 뜻은 아닙니다. 기존 앱을 옮긴다면 플랫폼의 별도 작업 시스템을 도입하는 데 드는 수고와 현재 워커를 서비스로 실행하는 데 드는 수고를 비교해야 합니다.

Cloudflare Workers와 Pages: 정적 사이트와 엣지 워크로드에 적합합니다

Cloudflare Workers는 Cloudflare 네트워크 전반에서 요청 처리 코드를 실행하는 플랫폼입니다. 앱의 의존성이 해당 런타임과 호환되는 가벼운 앱이라면 가장 먼저 검토할 만합니다. 주로 에셋을 전달하고, 인증을 확인하고, 외부 API를 호출하는 앱에 특히 매력적입니다. 다만 기존 Next.js 앱을 옮기려면 단순히 배포 대상을 바꾸는 데서 끝나지 않고, 어떤 호환 방식을 택할지 결정해야 합니다.

Cloudflare가 현재 권장하는 방식은 vinext입니다. JavaScript 빌드 도구인 Vite 위에서 Next.js API를 구현한 베타 버전입니다. 지원 목록에는 App Router, Server Actions, 스트리밍 SSR, 그리고 사이트 전체를 다시 빌드하지 않고 캐시된 페이지를 갱신하는 점진적 정적 재생성(ISR)이 포함됩니다. 일부 import와 이미지 처리 동작은 여전히 호환성을 검토해야 합니다. 기능 목록이 충분해 보여도 프로덕션 이전에서는 베타라는 점을 판단에 반영해야 합니다. Cloudflare Next.js 가이드.

또 다른 방식은 Next.js 빌드 결과를 다른 플랫폼에 맞게 변환하는 어댑터인 OpenNext입니다. Cloudflare는 기존 OpenNext 앱을 위한 문서를 제공합니다. 스트리밍과 ISR을 지원하지만, 지원 표에서 Node.js 미들웨어는 여전히 제외됩니다. 미들웨어는 요청이 페이지에 도달하기 전에 실행되는 코드입니다. 앱의 미들웨어가 해당 런타임에 의존한다면 DNS를 변경하기 전에 호환성 문제부터 해결해야 합니다. Cloudflare OpenNext 지원 범위.

Cloudflare Pages는 더 단순한 경우에 적합합니다. Next.js 앱을 정적으로 내보낼 수 있다면 사용할 수 있습니다. 공식 프리셋은 out 디렉터리에 파일을 빌드하며, Git 기반 재빌드와 미리보기를 제공합니다. 정적 내보내기에서는 요청 시 실행되는 Server Actions나 ISR을 유지할 수 없습니다. 실제로 동작하는 앱 백엔드가 필요하다면 다른 곳에서 실행해야 합니다. Pages의 정적 Next.js 배포 가이드, Next.js 정적 내보내기 제한.

과금 방식: Workers는 요청 수와 CPU 작업량을 측정하며, 추가로 도입한 서비스에는 별도 과금 기준이 적용됩니다. 네트워크 응답을 기다리는 시간은 Worker CPU 시간을 소모하지 않습니다. 모델 응답을 기다리는 AI 엔드포인트에서는 이 차이가 중요할 수 있지만, 모델 호출이나 나머지 스택까지 무료가 된다는 뜻은 아닙니다. 직접 제공하는 정적 에셋은 Worker나 Workers Caching을 거치는 트래픽과 과금 방식이 다릅니다. Workers 요금, 런타임 제한.

적합한 용도: 정적 사이트, 가벼운 API 프런트엔드, 엣지 런타임과 호환되는 Next.js 앱입니다.
주요 강점: 정적 콘텐츠 전달과 서버 코드를 같은 플랫폼 생태계에서 운영할 수 있습니다.
요금: Workers Free는 $0, Workers Paid는 월 $5부터이며 포함된 제공량을 초과하면 사용량에 따라 과금됩니다. 공식 요금.
무료 체험: 한시적인 체험만 제공하는 방식이 아니라, 계속 사용할 수 있는 Free 티어를 제공합니다.

판단: 호환성을 입증할 수 있고 콘텐츠 전달 방식이 워크로드에 이점을 줄 때 Cloudflare를 선택합니다. 광고에 나온 저렴한 시작 가격만 보고 프레임워크 이전까지 감수해서는 안 됩니다.

1. 1

   프로덕션 브랜치의 호환성을 확인합니다

   이전 작업용 브랜치에서 Cloudflare 문서의 npx vinext check 절차를 실행하고 결과를 살펴봅니다. 지원되는 배포 방식이 실제 미들웨어, 이미지 처리, 서버 의존성과 맞는지 대조합니다.

2. 2

   매출에 직접 연결되는 동작을 검증합니다

   미리보기를 배포한 뒤 로그인, 인증된 페이지 로드, Server Action, AI 스트리밍, 콘텐츠 재검증을 확인합니다. 빌드 성공은 인수 테스트의 시작일 뿐입니다.

3. 3

   변경 범위가 더 작은 이전 방식을 선택합니다

   실제로 정적 내보내기가 가능한 앱에는 Pages를 사용합니다. 요청 시 실행되는 코드에는 호환되는 Workers 방식을 사용합니다. 어댑터에 맞추는 변경이 기대 효과보다 크다면 프로덕션 트래픽을 전환하기 전에 일반적인 Node 배포와 비교합니다.

Render: 상시 실행 앱과 백그라운드 워커에 적합합니다

Render는 웹 서비스, 워커, 데이터베이스를 위한 관리형 플랫폼입니다. AI 앱에 일반적인 서버가 필요할 때 제가 가장 먼저 후보에 올리는 서비스입니다. 문서 분석 제품이라면 Next.js 웹 서비스와 업로드 파일을 처리하는 워커를 따로 실행할 수 있습니다. 이렇게 분리하면 방문자가 전체 작업이 끝날 때까지 기다리지 않아도 요청에 대해 작업 접수 응답을 보낼 수 있습니다.

유지되는 Next.js 기능: Render 문서는 전체 Next.js 앱을 Node.js 웹 서비스로 실행하거나, 정적 내보내기 결과를 정적 사이트로 배포하는 방법을 안내합니다. Node 방식에서는 프레임워크의 서버 코드를 그대로 사용할 수 있습니다. 다만 런타임 캐시, 배포 동작, 추가 프로세스가 어떻게 함께 작동할지는 직접 결정해야 합니다. Render의 Next.js 배포 안내.

이 차이는 규모를 늘릴 때 드러납니다. ISR은 페이지를 갱신해 재사용할 수 있다는 뜻이지, 독립된 서버 인스턴스끼리 갱신 결과를 저절로 공유한다는 뜻은 아닙니다. 복제 인스턴스를 두는 배포에는 캐시 전략과 일관된 무효화 처리가 필요합니다. 즉, 저장된 콘텐츠가 오래되었다는 사실을 모든 인스턴스에 알려야 합니다. Next.js는 셀프 호스팅 시 이러한 책임을 문서에 명시하고 있습니다. Next.js 셀프 호스팅 가이드.

과금 방식: 워크스페이스 요금제와 서비스별 컴퓨트 비용은 별도입니다. 웹 서버, 워커, 데이터베이스는 각각 별도 리소스이며, 대역폭과 빌드 사용량에도 제공량과 초과 요금이 있습니다. 유료 웹 서비스의 시작 가격은 웹 앱, 워커, 프로덕션 데이터베이스를 모두 합친 비용이 아닙니다. Render 요금.

무료 서비스는 이전을 미리 검증하는 데 유용하지만, 들어오는 트래픽이 15분 동안 없으면 절전 상태로 전환됩니다. 고객 대상 AI 앱에서 한동안 접속이 없었다는 이유로 다음 고객이 예기치 않은 기동 지연을 겪어서는 안 됩니다. 언제든 즉시 응답할 수 있어야 한다면 유료 컴퓨트 비용을 예산에 반영해야 합니다. Render Free 제한.

빌드에서도 알아둘 점이 있습니다. Render는 Next.js의 .next/cache 디렉터리를 자동으로 보존하지 않습니다. 공식 가이드는 Render의 영구 빌드 캐시 위치를 통해 빌드 캐시를 재사용하는 방법을 안내합니다. 이는 페이지를 제공하는 런타임 캐시와 별개입니다. 한쪽을 설정했다고 다른 쪽까지 구성되지는 않습니다.

적합한 용도: 상시 서비스, 백그라운드 작업, 별도 배포 백엔드가 필요한 Next.js 앱입니다.
주요 강점: 웹 서비스와 백그라운드 워커가 명확히 구분된 배포 유형으로 제공됩니다.
요금: 무료 컴퓨트가 있으며, 유료 웹 컴퓨트는 512 MB 기준 월 $7부터입니다. 해당되는 워크스페이스 요금과 다른 리소스 비용은 별도입니다. 공식 요금.
무료 체험: Free 티어의 웹 서비스는 절전 상태로 전환되므로, 항상 즉시 응답하는 프로덕션 환경과 동등하지 않습니다.

판단: Vercel을 떠나는 이유가 상시 백엔드라면 Render를 선택합니다. 첫 이전의 범위는 작게 잡습니다. 기존 앱을 웹 서비스로 배포해 검증한 뒤, 작업 프로세스를 따로 옮깁니다. 앱을 다시 작성하면서 데이터베이스까지 동시에 바꾸면 장애 원인을 분리하기가 더 어려워집니다.

Railway: 소규모 풀스택 앱을 함께 구성하기 좋습니다

Railway는 서비스와 그 연결 관계를 프로젝트 단위로 묶는 배포 플랫폼입니다. 앱, 데이터베이스, 워커를 함께 구성하는 소규모 팀에 잘 맞습니다. 각 구성 요소가 어떻게 연결되는지 확인하면서 함께 개선하고 싶은 개발자에게 특히 유용합니다. 주요 고려 사항은 리소스 사용량에 따라 비용이 달라진다는 점입니다. 빠르게 배포한 다음에는 실제로 발생하는 비용도 꼼꼼히 살펴봐야 합니다.

유지되는 Next.js 기능: Railway 가이드는 GitHub, CLI, Dockerfile을 통한 배포를 안내합니다. Next.js 워크플로에서는 서버 실행에 필요한 파일을 묶은 standalone 출력을 설명하고, DATABASE_URL 참조로 PostgreSQL을 연결하는 방법을 보여 줍니다. 데이터베이스 마이그레이션을 위한 배포 전 명령도 지원합니다. Railway Next.js 가이드.

AI 리서치 앱을 출시하는 창업자라면 역할을 이렇게 나눌 수 있습니다. 웹 서비스는 인터페이스와 요청을 처리하고, 다른 서비스는 데이터 가져오기를 맡고, PostgreSQL은 오래 보관해야 하는 앱 데이터를 저장합니다. 서비스 참조는 이들을 연결하는 데 도움이 됩니다. 하지만 가져오기 작업을 재시도하거나 배포로 데이터베이스 스키마가 바뀔 때의 동작은 직접 정해야 합니다.

과금 방식: 구독료는 같은 금액의 리소스 사용량을 포함하는 최소 사용 약정입니다. 컴퓨트 사용액 전부에 구독료를 다시 더하는 방식이 아닙니다. 포함된 금액을 넘으면 리소스 소비량에 따라 청구액이 정해집니다. 메모리, CPU, 볼륨, 서비스에서 외부로 나가는 트래픽은 각각 별도로 측정됩니다. Railway 요금, 리소스 요금 페이지.

주의할 점은 앱에 요청이 없어도 리소스는 계속 실행될 수 있다는 사실입니다. 메모리를 점유하는 웹 프로세스, 데이터베이스, 워커의 존재는 방문자 수와 별개입니다. 페이지 트래픽이 적다고 프로젝트 전체 비용도 낮을 것이라 가정해서는 안 됩니다. 미리보기 환경을 포함해 계속 실행할 모든 서비스의 리소스 점유량을 비교해야 합니다.

Vercel에서 달라지는 점: 프레임워크의 각 동작을 Vercel이 구성해 주는 방식에서 Node·컨테이너 방식으로 옮기는 것입니다. 복제 인스턴스를 추가한다면 Next.js 캐시 동기화를 계획하고, 공개 엔드포인트를 통해 스트리밍 응답을 확인하고, 배포 후에도 업로드 파일이 남도록 저장 위치를 정해야 합니다. 프레임워크는 옮길 수 있지만, 프로덕션 운영의 전제는 다시 검토해야 합니다.

적합한 용도: 앱, 데이터베이스, 백그라운드 서비스를 함께 만드는 소규모 팀입니다.
주요 강점: 프로젝트 단위 서비스 연결과 문서화된 데이터베이스 마이그레이션 워크플로입니다.
요금: Hobby는 월 $5부터이며 $5의 리소스 사용량을 포함합니다. 추가 사용량은 별도로 과금됩니다. 공식 요금.
무료 체험: 30일 후 만료되는 $5 체험 크레딧을 제공합니다. 요금 페이지의 체험 조건.

판단: 소규모 풀스택 프로젝트를 빠르게 구성하고 변경하고 싶다면 Railway를 선택합니다. 후보가 이 두 컨테이너 중심 플랫폼으로 좁혀졌다면 Railway와 Render 비교에서 차이를 더 자세히 확인할 수 있습니다.

Netlify: 익숙한 관리형 Next.js 워크플로를 유지하기 좋습니다

Netlify는 관리형 웹 배포 플랫폼입니다. 미리보기와 관리형 Next.js 배포 워크플로를 유지하려는 팀이라면 이 목록에서 가장 가까운 선택지입니다. 임의의 워커를 상시 실행하려는 경우보다, 콘텐츠가 많고 인증된 페이지가 있는 SaaS 사이트를 운영할 때 선택 이유가 더 분명합니다. Next.js 지원 범위는 넓지만, 크레딧을 함께 사용하는 과금 구조와 런타임 실행 위치는 자세히 확인해야 합니다.

유지되는 Next.js 기능: Netlify의 OpenNext 어댑터는 App Router, SSR, ISR, React Server Components, Server Actions, 응답 스트리밍, 이미지 최적화, Cache Components를 지원합니다. 실질적인 기능들입니다. 이전한다고 해서 서버 렌더링이나 AI 응답 스트리밍을 자동으로 포기해야 하는 것은 아닙니다. Netlify Next.js 지원 범위.

달라지는 점: 엣지 런타임을 사용하도록 설정된 Next.js SSR 페이지도 Netlify의 함수 리전에서 Node.js로 실행됩니다. 엣지 설정을 유지하면 실행 위치도 같을 것이라 가정해서는 안 됩니다. Netlify는 미들웨어 실행 순서의 차이도 문서화하고 있으며, Node.js 미들웨어에서는 파일 시스템 접근과 C++ 애드온을 지원하지 않습니다. 인증이나 요청 라우팅이 이런 동작에 의존한다면 특히 주의해야 합니다.

배포 중에도 고객이 앱을 사용한다면 버전 불일치 방지 기능인 skew protection을 검토할 만합니다. 브라우저 세션을 처음 연결된 서버 배포 버전과 맞춰 유지하는 기능입니다. Netlify에서는 선택적으로 활성화할 수 있습니다. 문서에 따르면 일반적인 클라이언트 fetch 호출에는 배포 식별자가 자동으로 포함되지 않으므로, 직접 작성한 API 호출은 별도로 신경 써야 합니다. 유용한 기능이지만 앱의 실제 요청 경로를 확인하는 일을 대신해 주지는 않습니다. 호환성과 skew protection 안내.

과금 방식: 프로덕션 배포, 컴퓨트, 대역폭, 요청이 크레딧을 소모하며 추가 플랫폼 서비스도 크레딧을 사용할 수 있습니다. 자주 배포하고 큰 파일을 제공하는 콘텐츠 사이트와, 트래픽은 적지만 서버 작업을 수행하는 앱은 제공량을 소비하는 방식이 다릅니다. 따라서 Netlify에서는 워크로드를 기준으로 계산해야 하며, 이전만으로 비용이 줄어든다고 볼 수 없습니다. Netlify 요금.

Netlify 무료 호스팅: 크레딧 한도가 서비스 가용성을 좌우합니다

무료 요금제에서 중요한 경계는 크레딧을 모두 소진했을 때의 동작입니다. Netlify 요금 FAQ는 프로젝트가 일시 중지되며, 한 프로젝트의 한도 초과로 계정 내 모든 프로젝트가 중지될 수 있다고 설명합니다. 유료 요금제에서는 자동 충전을 사용할 수 있지만 기본적으로 비활성화되어 있습니다. 추가 지출을 막는 것과 트래픽 급증에도 서비스를 유지하는 것 중 무엇을 우선할지 명확히 정해야 합니다.

창업자가 판단할 문제는 구체적입니다. 마케팅 사이트가 예상치 못하게 주목받았을 때 같은 계정의 앱까지 중단되어도 되는지 생각해야 합니다. 워크로드를 한곳으로 모으기 전에 계정 구조와 크레딧 정책을 검토해야 합니다.

적합한 용도: 관리형 Next.js 배포와 검토 워크플로를 유지하려는 팀입니다.
주요 강점: OpenNext 어댑터를 통한 폭넓은 프레임워크 지원과 배포 미리보기입니다.
요금: Free는 월 $0에 300크레딧을 제공합니다. 유료 요금제와 추가 사용량에는 현재 크레딧 요금표가 적용됩니다. 공식 요금.
무료 체험: 매월 제공량이 있는, 기간 제한 없는 Free 요금제입니다.

판단: 유지하고 싶은 것이 배포 워크플로라면 Netlify를 후보에 올립니다. 최종 선택에는 Vercel과 Netlify 비교를 활용하고, 절감액을 추정하기 전에 계정의 현재 요금제를 확인합니다.

Fly.io: 컨테이너의 실행 리전을 직접 제어하기 좋습니다

Fly.io는 Machines라는 가상 머신에서 앱을 실행하는 플랫폼입니다. 컨테이너로 구성한 앱이 어디에서 실행될지 직접 제어하려는 개발자에게 적합합니다. 운영에 최대한 관여하지 않으려는 경우보다 구체적인 배치 위치 요구 사항이 있는 앱에 더 잘 맞습니다. 이때 중요한 것은 앱의 데이터도 같은 배치 전략을 따를 수 있는지입니다.

유지되는 Next.js 기능: Fly.io는 fly launch, 자동 생성된 Dockerfile, fly.toml 설정을 사용하는 Next.js 배포 방법을 문서화하고 있습니다. 런타임 패키징에는 standalone 출력을 권장합니다. 일반적인 서버 배포 방식을 사용하면서 실행 환경을 더 직접적으로 제어할 수 있습니다. Fly.io Next.js 가이드.

일반적인 런타임을 사용한다고 이전의 모든 세부 문제가 해결되는 것은 아닙니다. 공개 Next.js 환경 변수는 빌드 시점에 고정되므로 프로덕션 설정을 바꾸려면 재빌드가 필요할 수 있습니다. 여러 Machines를 운영할 때도 프레임워크 캐시와 배포 상태의 일관성을 유지해야 합니다. 해결할 수 있는 엔지니어링 작업이지만, 이전 비용 추산에는 포함해야 합니다.

데이터베이스에서 멀리 떨어진 고객에게 서비스를 제공하는 앱을 생각해 볼 수 있습니다. 웹 프로세스를 고객 가까이 옮겨도 각 페이지는 여전히 먼 곳의 데이터베이스 쿼리를 기다릴 수 있습니다. 리전은 전체 요청 경로를 기준으로 선택해야 합니다. 지도에 앱 실행 위치가 더 많이 표시된다는 사실만으로 고객 경험이 빨라졌다고 볼 수는 없습니다.

과금 방식: Machine 컴퓨트는 실행 중일 때 과금되며 사양과 리전에 따라 단가가 달라집니다. 볼륨, 외부로 나가는 네트워크 트래픽, 기타 리소스는 별도입니다. 표시된 최소 월 예상액은 소형 컴퓨트의 최저 비용일 뿐, Next.js 앱에 필요한 메모리 사양을 권장하는 값이 아닙니다. 프로세스가 중지되어도 저장된 리소스에는 비용이 계속 발생할 수 있습니다. Fly.io 요금.

상태를 저장하는 앱에서 가장 주의할 점은 볼륨이 자동으로 복제되지 않는다는 것입니다. 볼륨은 Machine에 연결된 로컬 스토리지이며, 전 세계에서 동기화되는 데이터베이스가 아닙니다. 로컬 상태를 사용한다면 앱이나 데이터베이스 설계에서 복제와 복구를 처리해야 합니다. Fly.io 볼륨 문서.

적합한 용도: 리전별 배치와 컨테이너 제어가 필요한 개발자입니다.
주요 강점: 인프라 설정을 명시적으로 다루는 Next.js 컨테이너 배포 방식이 문서화되어 있습니다.
요금: 표시된 최소 256 MB Machine은 월 환산 $2.19부터입니다. 리전별 단가, 더 큰 사양, 스토리지와 트래픽에 따라 총액이 달라집니다. 공식 요금.
무료 체험: VM 총 실행 시간 2시간 또는 7일 중 먼저 도달하는 시점에 종료됩니다. Fly.io 체험 안내.

판단: Fly.io가 제공하는 제어 권한이 필요할 때 선택합니다. 인프라 고민에서 벗어나고 싶다면, 바로 그 제어 권한이 다른 업체에 맡기고 싶은 운영 업무가 될 수 있습니다.

AWS Amplify: 이미 AWS를 쓰는, 호환 요건에 맞는 앱에 적합합니다

AWS Amplify는 Amazon Web Services의 앱 호스팅·개발 서비스입니다. 이미 AWS 서비스를 사용하고 있으며, 호스트가 지원하는 Next.js 기능 범위 안에서 동작하는 앱을 운영하는 기업에 적합합니다. 인증, 데이터, 스토리지가 이미 해당 스택에 있다면 조직 운영 측면에서 합리적인 선택일 수 있습니다. 다만 스트리밍 AI 앱에서는 생태계의 편의성보다 호환성을 먼저 확인해야 합니다.

유지되는 Next.js 기능: Amplify Hosting의 현재 문서는 컴퓨트 기반 호스팅에서 Next.js 버전 12부터 15까지 지원한다고 명시합니다. 지원 기능에는 SSR, 정적 페이지, API 라우트, ISR, 이미지 최적화가 포함됩니다. 이는 문서에 명시된 범위이지, 앱이 현재 사용하는 어떤 버전이든 지원한다는 약속은 아닙니다. Amplify Next.js 지원 범위.

유지할 수 없는 기능: 같은 문서는 Next.js 스트리밍, 온디맨드 ISR, Edge API 라우트를 지원하지 않는다고 명시합니다. 온디맨드 ISR은 변경된 상품 설명을 발행하는 등의 이벤트에 맞춰 캐시된 콘텐츠를 무효화하는 기능입니다. 주기적 또는 일반적인 ISR을 지원한다고 해서 이런 이벤트 기반 동작까지 된다는 뜻은 아닙니다.

채팅 제품에서 스트리밍은 답변이 완성된 뒤 한꺼번에 나타나는 대신 텍스트가 조금씩 도착하게 합니다. 기존 Next.js 라우트가 이 동작에 의존한다면 Amplify Hosting은 그대로 옮겨 갈 수 있는 대체재가 아닙니다. 스트리밍 백엔드를 별도로 호스팅하는 아키텍처도 가능하지만, 이는 프런트엔드 저장소를 가져오는 것보다 더 큰 변경입니다.

과금 방식: Amplify는 빌드 시간(분), 호스팅 스토리지, 데이터 전송량, SSR 요청 수, SSR 실행 시간을 측정합니다. 백엔드 AWS 서비스는 자체 과금 체계를 가진 추가 리소스입니다. 요금 페이지에는 인증용 Amazon Cognito, 파일 저장용 Amazon S3 등의 연동 서비스가 나옵니다. 기존 서비스를 재사용하는 것은 합리적일 수 있지만, 그 비용이 하나의 호스팅 구독료에 모두 포함되는 것은 아닙니다. Amplify 요금.

이미 AWS를 운영하는 팀의 창업자라면 익숙한 접근 제어, 청구 관리 주체, 백엔드 서비스가 여러 항목으로 나뉘는 요금의 불편함보다 중요할 수 있습니다. 반면 Vercel 비용만 줄이려는 개인 개발자에게는 이런 조직적 이점이 없을 수 있습니다. AWS 서비스 목록의 방대함보다 앱에 필요한 아키텍처를 비교해야 합니다.

적합한 용도: AWS 중심으로 운영되며 호환 가능한 Next.js 앱을 보유한 기업입니다.
주요 강점: 기존 AWS 백엔드와 계정 체계 안에서 호스팅을 운영할 수 있습니다.
요금: 표준 빌드는 분당 $0.01부터이며, 호스팅·SSR·백엔드 리소스는 별도로 측정해 과금합니다. 공식 요금.
무료 체험: AWS Free Tier 자격과 크레딧은 계정 및 가입 조건에 따라 달라집니다.

판단: 지원 목록이 앱의 요구 사항을 충족하는지 확인한 뒤에만 Amplify를 선택합니다. 이미 AWS에 비용을 지출하고 있다는 것은 검토할 이유이지, 필요한 프로덕션 기능이 빠져 있어도 넘어갈 이유는 아닙니다.

Vercel을 계속 쓰는 편이 나은 경우는 언제일까요?

앱이 잘 작동하고 문제가 요금에 대한 오해나 지출 관리 부족에 있다면, 떠나려던 배포 플랫폼인 Vercel이 여전히 더 나은 선택일 수 있습니다. 업체를 옮기면 개발 작업과 회귀 오류의 위험, 새로운 운영 책임이 생깁니다. 그 비용을 감수할 만한 구체적인 개선이 있어야 합니다.

Vercel 요금: 이전 전에 현재 요금제부터 점검합니다

실제 청구서와 현재 Vercel 요금 분석을 함께 확인합니다. Vercel의 현재 요금에는 Pro의 Flat Rate CDN 옵션이 포함되어 있습니다. 따라서 GB당 전송 요금만 기준으로 삼은 오래된 비교는 지금의 청구 구조를 제대로 설명하지 못할 수 있습니다. 대안을 비교하기 전에 비용 부담이 큰 항목이 콘텐츠 전송인지, 컴퓨트인지, 빌드인지, 사용자 좌석인지, 별도 서비스인지 파악해야 합니다. Vercel 현재 요금.

Spend Management는 알림, 웹훅, 그리고 팀의 모든 프로덕션 배포를 일시 중지하는 선택 기능을 지원합니다. 알림만으로는 사용량이 멈추지 않습니다. 일시 중지를 선택하면 고객도 해당 앱에 접근할 수 없으며, 지출 확인은 임계액 도달보다 몇 분 늦을 수 있습니다. 가용성을 희생할 수 있는 비용 제어 기능이지, 한도에 도달하는 즉시 정확히 차단하는 장치는 아닙니다. Vercel Spend Management.

프런트엔드를 옮기지 않고도 비싼 작업을 없애거나 캐시하거나 별도 서비스로 분리할 수 있다면 Vercel을 유지합니다. 상시 프로세스, 런타임 제약, 명확한 이식성 요구가 이전 작업을 정당화한다면 옮깁니다.

Vercel 대체 무료 호스팅, 제공량은 어떻게 봐야 할까요?

무료 제공량은 적합성을 검증하는 데 유용하지만, 그 자체가 프로덕션 아키텍처는 아닙니다. Netlify는 크레딧을 소진하면 프로젝트가 중지될 수 있습니다. Render의 Free 웹 서비스는 절전 상태로 전환됩니다. Railway와 Fly.io는 제한된 체험을 제공합니다. AWS 자격은 계정 조건에 따라 달라집니다. Cloudflare도 정적 콘텐츠 제공량이 넉넉하더라도 무료 런타임에는 실행 제한이 있습니다.

무료 옵션으로는 앱의 빌드, 인증, 스트리밍, 복구가 올바르게 작동하는지 확인합니다. 그다음 실제 프로덕션에 필요한 리소스를 기준으로 지속적인 워크로드를 추산합니다.

Vercel 무료 요금제와 무료 체험은 목적이 다릅니다

Vercel의 Hobby 요금제는 개인의 비상업적 용도입니다. Pro 체험은 대상 유료 기능을 평가하는 수단이지, 프로덕션에서 계속 사용할 수 있는 권리가 아닙니다. 창업자가 상업용 배포 비용을 비교할 때는 의도한 용도를 허용하지 않는 무료 요금제를 기준으로 삼아서는 안 됩니다. Vercel 요금제 안내.

앱을 망가뜨리지 않고 Vercel 대체 서비스로 옮기는 방법

비용이 크거나 호환되지 않는 워크로드부터 옮깁니다. 앱 전체 이전은 더 큰 문제를 해결할 때만 선택합니다. AI 앱은 기존 프런트엔드를 유지하면서 별도 API로 작업을 접수하고, 큐에 대기 작업을 보관하고, 워커로 처리할 수 있습니다. 영구 보관해야 하는 데이터는 교체 가능한 앱 배포 환경 밖에 두어야 합니다.

큐는 워커가 브라우저 요청과 독립적으로 처리할 수 있는 작업 대기 목록입니다. 예를 들어 업로드 요청에는 작업 식별자를 반환하고, 워커가 텍스트를 추출해 결과를 저장한 뒤, 앱이 나중에 상태를 조회할 수 있습니다. 이때 모든 마케팅 페이지와 로그인 화면까지 동시에 옮길 필요는 없습니다.

저장소를 옮길 수 있다는 것은 시스템 이식성의 일부에 불과합니다. 업체 전용 스토리지 호출, 환경 변수, 예약 작업, 인증 콜백, 배포 URL을 목록으로 정리합니다. 그대로 둘 서비스, 대체할 서비스, 데이터를 내보내야 할 서비스를 결정합니다. 프런트엔드 호스트를 바꾼다고 이 항목들이 자동으로 옮겨지지는 않습니다.

1. 1

   대표 워크플로 하나를 고릅니다

   로그인, 문서 업로드, 처리 시작, 스트리밍 답변 수신, 저장된 결과 재확인처럼 사업상 중요한 경로를 사용합니다. 호스팅을 바꾸기 전에 기대하는 동작을 적어 둡니다.

2. 2

   빌드 시점 설정과 런타임 비밀 정보를 구분합니다

   이전 대상에 서버 비밀 정보를 다시 설정하고, 어떤 공개 설정이 빌드 과정에서 포함되는지 확인합니다. 미리보기 환경에 사용 권한을 의도적으로 부여한 경우가 아니라면 프로덕션 자격 증명을 이전 검증용 미리보기에 넣지 않습니다.

3. 3

   스트리밍과 캐시 무효화를 테스트합니다

   공개 URL에서 응답 청크가 점진적으로 도착하는지 확인합니다. 콘텐츠를 바꾼 뒤 의도한 페이지가 갱신되는지 검증합니다. 복제 인스턴스를 추가했다면 모든 인스턴스에서 갱신된 상태를 확인합니다. Next.js는 프록시 버퍼링과 캐시 동기화를 셀프 호스팅의 고려 사항으로 명시하고 있습니다.

4. 4

   트래픽 전환 전에 장애와 롤백을 테스트합니다

   작업 도중 워커를 재시작하고, 요청을 재시도하고, 브라우저 세션이 열린 상태에서 배포합니다. 재시도가 고객에게 보이는 작업을 중복 실행하지 않는지 확인합니다. 데이터베이스 마이그레이션을 위험하게 되돌리지 않으면서 앱을 롤백할 방법을 정합니다.

5. 5

   같은 워크로드로 비교하고 단계적으로 전환합니다

   각 비용 추산에 앱, 워커, 데이터베이스, 파일 스토리지, 트래픽, 빌드, 모니터링을 포함합니다. 인수 검증을 통과한 뒤에만 트래픽을 바꾸고, 롤백 경로를 유지하며, 새 구성이 안정되면 사용하지 않는 리소스를 정리합니다.

이 검증 항목의 프레임워크 관련 세부 사항은 Next.js 셀프 호스팅 가이드에 나와 있습니다. 이 체크리스트는 인수 검증 계획이며, 이번 비교 과정에서 해당 앱들을 실제로 배포했다는 뜻은 아닙니다.

어떤 기준으로 선정했나요?

프로덕션 Next.js 앱이나 AI 앱에 현실적인 이전 경로를 제공하는 서비스를 우선했습니다. 판단 기준은 런타임 적합성, 문서로 확인되는 프레임워크 호환성, 과금 단위, 배포 워크플로, 그리고 사용자가 새로 맡아야 할 운영 업무입니다.

여섯 서비스를 2026년 11월 3일 각 업체의 요금 및 기술 문서를 기준으로 평가했습니다. 추천은 그 사실을 정적 콘텐츠 전달, 관리형 요청 처리, 상시 서비스, 기존 환경 유지라는 워크로드 선택에 연결한 것입니다. 실제 워크로드를 측정하지 않은 상태에서 합성 성능 점수나 비용 절감 수치를 제시하지 않습니다.

직접 관리하는 가상 서버는 운영 방식이 다르므로 이번 후보에서 제외했습니다. 역량이 있는 개발자라면 선택할 수 있지만, 누군가는 업데이트, 백업, 복구, 서버의 외부 공개 상태를 책임져야 합니다. 목록에 이름을 더한다고 이런 책임이 사라지지는 않습니다.

어떤 선택을 피해야 할까요?

모든 상황에서 특정 브랜드를 배제하기보다, 서비스와 워크로드가 맞지 않는 조합을 피해야 합니다.

• 스트리밍 Next.js AI 앱을 변경 없이 AWS Amplify Hosting으로 이전하는 선택입니다. 문서에 명시된 스트리밍 미지원은 실제 이전을 가로막는 제약입니다.
• 요청 시 실행되는 자체 Server Actions나 ISR이 필요한 앱에 Cloudflare Pages 정적 내보내기를 쓰는 선택입니다. 호환되는 서버 런타임을 고르거나 백엔드를 분리해야 합니다.
• 항상 즉시 응답해야 하는 앱에 Render Free를 쓰는 선택입니다. 절전 동작이 요구 사항과 맞지 않습니다.
• 부하가 큰 워크로드에서 Netlify를 정액제 대체재라고 가정하는 선택입니다. 공유 크레딧 사용량과 소진 시 동작부터 계산해야 합니다.
• 인프라 결정을 피하려고 Fly.io를 고르는 선택입니다. 리전별 데이터 배치, 볼륨, 복구는 책임 주체를 정해 관리해야 합니다.

Railway를 비롯한 리소스 종량제 플랫폼을 최소 구독료만 보고 선택하는 일도 피해야 합니다. 시작 가격이 매력적이라고 해서 아직 배포하지 않은 서비스 비용까지 계산된 것은 아닙니다.

자주 묻는 질문

Vercel은 호스팅 서비스인가요?

그렇습니다. Vercel은 웹 애플리케이션을 호스팅하고 배포합니다. 이 글의 대안들은 정적 파일 제공부터 상시 애플리케이션 서버 실행까지, 그 역할의 서로 다른 부분을 대체합니다.

Vercel과 GoDaddy는 무엇이 다른가요?

도메인 등록과 애플리케이션 배포는 별개의 일입니다. GoDaddy는 도메인 등록을 판매하고, Vercel은 앱을 호스팅합니다. 도메인을 GoDaddy에 등록해 둔다고 앱 호스팅도 반드시 그곳에서 해야 하는 것은 아닙니다.

Vercel보다 나은 서비스는 무엇인가요?

상시 실행하는 풀스택 서비스에는 Render나 Railway가 더 잘 맞을 수 있습니다. 정적 사이트나 호환 가능한 엣지 워크로드라면 Cloudflare가 유력한 우선 후보입니다. Netlify는 관리형 Next.js 배포 워크플로에 적합합니다. 런타임과 워크로드를 정하지 않으면 모든 경우에 가장 좋은 서비스를 고를 수 없습니다.

Netlify는 Vercel을 사용하나요?

Netlify는 자체 배포 플랫폼을 제공합니다. 자체 OpenNext 어댑터를 통해 Next.js를 실행하며, 이는 앱을 Vercel에서 호스팅하는 것과 별개의 배포입니다.

Vercel과 Netlify 중 어느 쪽이 더 좋나요?

프레임워크 동작과 크레딧 모델이 앱에 맞는다면 Netlify는 충분히 검토할 만한 대안입니다. 이전에 드는 작업이 기대되는 개선 효과보다 크다면 Vercel을 유지하는 편이 나을 수 있습니다. 현재 청구액과 필수 기능을 비교하되, 특히 미들웨어, 실행 위치, 배포 동작을 확인해야 합니다.

Netlify의 단점은 무엇인가요?

여러 유형의 사용량이 하나의 크레딧 풀을 공유하며, 이를 소진하면 계정의 다른 프로젝트도 중지될 수 있습니다. Next.js 엣지 런타임 SSR의 실행 위치와 일부 미들웨어 동작은 독립 실행형 배포와 다릅니다. skew protection을 사용할 때는 직접 작성한 클라이언트 요청에도 주의해야 합니다.

Netlify보다 나은 대안도 있나요?

정적 콘텐츠 전달과 호환 가능한 엣지 코드에는 Cloudflare를 검토할 만합니다. 상시 서비스나 일반적인 백그라운드 워커가 필요하다면 Render나 Railway부터 살펴보는 편이 좋습니다. 관리형 웹 배포가 핵심이라면 Netlify도 여전히 유력한 선택입니다.

Netlify는 평생 무료인가요?

Netlify는 현재 월별 크레딧 제공량이 있는, 기간 제한 없는 Free 요금제를 제공합니다. 사용량이 무제한이거나 약관이 영원히 바뀌지 않는다는 보장은 아닙니다. 제공량을 소진하면 사이트가 중지될 수 있습니다.

GitHub와 Netlify 중 어느 쪽이 더 좋나요?

GitHub Pages는 저장소 파일로 정적 사이트를 제공합니다. Netlify는 어댑터를 통해 Next.js 서버 기능도 지원합니다. 사이트에 서버 런타임이 필요한지를 기준으로 선택해야 합니다. 소스 코드를 GitHub에 보관하더라도 앱은 다른 곳에 배포할 수 있습니다. GitHub Pages 문서.

다음 주에 이전을 시작하기 전에 AI 비즈니스 워크플로 점검 체크리스트로 프런트엔드, 작업, 데이터, 지출 한도를 정리합니다. 가장 먼저 옮길 가치가 있는 워크로드 하나를 찾는 데 활용할 수 있습니다.