배포 플랫폼은 어디가 좋을까요? Vercel·Netlify·Railway 비교

바이브코딩으로 웹서비스를 만들고 나면 마지막에 이런 질문이 생깁니다.

이 프로젝트는 어디에 배포해야 하지?
Vercel, Netlify, Railway 중에 뭐가 제일 좋을까?

AI에게 물어보면 Next.js니까 Vercel을 쓰라는 답도 나오고, 다른 AI는 Netlify나 Railway를 추천하기도 해요. 셋 다 웹 프로젝트를 배포할 수 있기 때문에 틀린 답은 아닙니다. 하지만 어떤 프로젝트를 배포하느냐에 따라 편한 선택이 달라져요.

이 글에서는 가격표의 숫자보다 먼저 봐야 할 차이를 정리해볼게요. 가격과 무료 제공량은 바뀔 수 있지만, 프로젝트가 작동하는 방식은 배포 플랫폼을 고르는 더 오래가는 기준이 됩니다.

아직 배포라는 말부터 낯설다면 localhost와 배포의 차이를 먼저 읽어도 좋아요.

먼저 결론부터

• 일반적인 Next.js 웹서비스라면 Vercel이 가장 무난한 출발점입니다.
• 웹페이지 중심 프로젝트와 프론트엔드 배포 흐름을 중요하게 본다면 Netlify도 좋은 선택입니다.
• 계속 실행되는 서버, 별도 백엔드, 작업 처리 프로그램이 필요하다면 Railway가 더 자연스럽습니다.
• 화면과 서버의 요구가 다르면 Vercel 또는 Netlify에 화면을, Railway에 서버를 나눠 배포할 수도 있어요.

다만 “Next.js는 무조건 Vercel”, “Netlify는 정적 사이트만”, “Railway는 백엔드만”이라고 외우면 실제 프로젝트에서 금방 예외를 만납니다. Next.js는 세 플랫폼 모두에 배포할 수 있고, Netlify도 서버 기능을 지원하며, Railway에서도 웹 화면을 운영할 수 있어요.

따라서 플랫폼 이름보다 먼저 내 프로젝트가 어떤 방식으로 실행되어야 하는지를 확인해야 합니다.

가장 중요한 질문: 서버가 계속 켜져 있어야 하나요?

웹서비스의 서버는 크게 두 가지 방식으로 생각해볼 수 있어요.

첫 번째는 방문자의 요청이 들어올 때 서버 기능이 실행되고, 답을 돌려준 뒤 쉬는 방식입니다.

방문자가 요청한다
→ 필요한 서버 기능이 실행된다
→ 결과를 돌려준다
→ 요청이 없으면 쉬거나 줄어든다

회원가입, 문의 저장, 결제 확인처럼 요청 하나를 받아 처리하고 끝나는 작업에 잘 맞아요. Vercel Functions는 요청에 따라 실행되고 자동으로 확장되며, 사용하지 않을 때는 실행 규모를 줄이는 구조입니다. Netlify Functions도 웹 요청을 받아 서버 코드를 실행하는 방식이에요. (Vercel Functions 문서 (새 탭에서 열림), Netlify Functions 문서 (새 탭에서 열림))

두 번째는 프로그램이 시작된 뒤 계속 켜져 있으면서 요청이나 작업을 기다리는 방식입니다.

서버 프로그램을 시작한다
→ 계속 실행된 상태로 기다린다
→ 요청, 메시지, 예약 작업을 처리한다

실시간 연결을 오래 유지하거나, 작업 목록을 계속 확인하거나, 별도 백엔드 프로그램을 운영할 때 이런 방식이 필요할 수 있어요. Railway의 서비스는 컨테이너라는 실행 환경 안에서 프로그램을 계속 실행하는 구조라 이러한 프로젝트에 더 잘 맞습니다. (Railway Services 문서 (새 탭에서 열림))

이 차이를 아주 간단히 줄이면 다음과 같습니다.

요청이 올 때 필요한 일을 처리하는 웹서비스
→ Vercel 또는 Netlify부터 검토

계속 살아 있어야 하는 서버 프로그램
→ Railway부터 검토

Vercel: Next.js 프로젝트의 가장 무난한 출발점

Vercel은 Next.js를 만든 회사가 운영하는 배포 플랫폼입니다. 그래서 Next.js 프로젝트를 연결하면 복잡한 설정 없이 화면과 서버 기능을 함께 배포하기 편해요.

GitHub 저장소를 연결해두면 코드를 올릴 때마다 새 버전을 만들고, 실제 반영 전에 확인할 수 있는 미리보기 주소도 제공합니다. Next.js가 화면을 빠르게 보여주기 위해 사용하는 여러 기능도 플랫폼에 맞게 연결됩니다.

다음과 같은 프로젝트라면 Vercel부터 생각해볼 만해요.

• 회사나 서비스 소개 사이트
• 블로그와 콘텐츠 사이트
• 신청, 예약, 주문을 받는 Next.js 서비스
• 로그인과 데이터베이스를 연결한 작은 웹 앱
• 관리자 화면이 포함된 Next.js 프로젝트

Vercel에서도 서버 기능을 만들 수 있습니다. “Vercel은 화면만 올리는 곳”은 아니에요. 다만 Vercel Functions에는 실행 시간과 메모리 같은 한도가 있고, 프로그램을 끝없이 실행하는 용도로 설계되지는 않았습니다. (Vercel Functions 제한 문서 (새 탭에서 열림), Vercel 런타임 문서 (새 탭에서 열림))

따라서 AI가 만든 프로젝트에 계속 실행되어야 하는 작업 프로그램, 오래 유지되는 실시간 연결, 특별한 실행 환경이 들어 있다면 Vercel만으로 충분한지 따로 확인해야 해요.

Netlify: 웹페이지 중심의 배포 흐름이 강한 선택지

Netlify는 정적 웹사이트 배포로 많이 알려졌지만 지금은 그보다 범위가 넓습니다. Next.js의 App Router, 서버 렌더링, 이미지 최적화 같은 주요 기능도 지원해요. 따라서 “Next.js라서 Netlify에는 배포할 수 없다”는 말은 맞지 않습니다. (Netlify Next.js 문서 (새 탭에서 열림))

Netlify도 GitHub와 연결한 자동 배포, 변경 사항을 미리 확인하는 주소, 서버 기능, 전 세계 가까운 곳에서 실행되는 Edge Functions 등을 제공합니다. 예약된 시간에 실행하거나 비교적 오래 걸리는 작업을 위한 함수 방식도 따로 마련되어 있어요. (Netlify Functions 문서 (새 탭에서 열림), Netlify Scheduled Functions 문서 (새 탭에서 열림), Netlify Edge Functions 문서 (새 탭에서 열림))

다음과 같은 상황에서 Netlify를 검토할 수 있어요.

• 소개 페이지, 행사 사이트, 콘텐츠 사이트처럼 웹페이지가 중심인 프로젝트
• 다양한 프론트엔드 도구로 만든 사이트를 한곳에서 배포하고 싶은 경우
• 변경 사항을 미리 보여주고 검토하는 흐름을 중요하게 보는 경우
• 이미 팀이나 프로젝트가 Netlify를 사용하고 있는 경우
• Netlify의 폼, 함수, Edge 기능이 프로젝트와 잘 맞는 경우

Vercel과 Netlify의 경계는 생각보다 많이 겹칩니다. 일반적인 웹사이트나 Next.js 서비스라면 둘 다 가능한 경우가 많아요. 이때는 사용하는 프레임워크와 필요한 기능, 기존 계정과 팀의 경험, 예상 비용을 함께 보고 선택하면 됩니다.

Railway: 계속 실행되는 서버가 필요할 때

Railway는 코드를 하나의 실행 환경으로 만들어 서버 프로그램을 돌리는 방식에 가깝습니다. Next.js뿐 아니라 Node.js 백엔드, Python API, 작업 처리 프로그램, 데이터베이스처럼 서로 다른 서비스를 한 프로젝트 안에서 운영할 수 있어요.

다음과 같은 요구가 있다면 Railway가 더 자연스러울 수 있습니다.

• 화면과 분리된 백엔드 API 서버가 있다.
• Python, Node.js 등으로 만든 서버 프로그램을 계속 실행해야 한다.
• 메시지나 작업 목록을 계속 확인하는 프로그램이 있다.
• 실시간 연결을 오래 유지해야 한다.
• 서버를 시작하는 방법이나 실행 환경을 직접 정해야 한다.
• 서버와 데이터베이스를 가까이 두고 함께 관리하고 싶다.

Railway는 GitHub 저장소나 Dockerfile로 서비스를 배포하고, 시작 명령·상태 확인·재시작 방식 등을 설정할 수 있습니다. 데이터베이스 템플릿과 데이터를 유지하기 위한 볼륨도 지원합니다. (Railway 배포 문서 (새 탭에서 열림), Railway 데이터 저장 문서 (새 탭에서 열림))

대신 선택할 수 있는 범위가 넓은 만큼 Vercel이나 Netlify보다 알아야 할 운영 개념이 늘어날 수 있어요. 또 Railway의 기본 저장 공간은 새로 배포할 때 유지된다고 가정하면 안 됩니다. 파일을 계속 보관해야 한다면 볼륨이나 별도 파일 저장 서비스를 사용해야 해요. (Railway Volumes 문서 (새 탭에서 열림))

한눈에 비교하면

이 표는 “가능하다, 불가능하다”를 나누는 표가 아니에요. 어디에 놓았을 때 덜 복잡하고 자연스러운지를 비교한 표입니다.

프로젝트별로 고르면 이렇게 됩니다

1. 소개 페이지와 문의 폼을 만든 경우

Next.js로 만든 소개 페이지가 있고 문의 내용을 Supabase에 저장한다고 해볼게요. 서버 기능은 문의가 들어올 때만 잠깐 실행되면 됩니다.

이 경우에는 Vercel이 가장 무난하고, Netlify도 충분히 가능합니다. Supabase는 별도 데이터베이스로 연결하면 돼요. 서버를 따로 계속 켜둘 이유는 크지 않습니다.

Supabase가 화면과 서버 사이에서 어떤 역할을 하는지는 바이브코딩할 때 Supabase를 추천하는 이유에서 더 자세히 볼 수 있어요.

2. 행사 안내나 콘텐츠 사이트를 만든 경우

대부분의 내용이 웹페이지에 있고 복잡한 서버 기능이 없다면 Vercel과 Netlify 모두 잘 맞습니다. Next.js라면 Vercel이 익숙한 기본 선택이 될 수 있고, 여러 프론트엔드 도구와 배포 흐름을 한곳에서 관리해왔다면 Netlify가 편할 수 있어요.

3. Next.js 화면과 Python 서버를 함께 만든 경우

화면은 Next.js인데 추천 기능이나 데이터 처리를 별도 Python 서버가 맡는다면 역할을 나누는 편이 자연스러울 수 있습니다.

Next.js 화면과 간단한 웹 요청
→ Vercel 또는 Netlify

계속 실행되는 Python API와 작업 프로그램
→ Railway

사용자에게는 하나의 서비스처럼 보이지만, 안에서는 각 역할에 맞는 플랫폼을 사용할 수 있어요.

4. 실시간 채팅이나 계속 돌아가는 작업이 있는 경우

서버가 연결을 오래 유지하거나 새 작업이 있는지 계속 확인해야 한다면 Railway 쪽이 더 자연스럽습니다. 화면은 Vercel에 두고 실시간 서버만 Railway에 둘 수도 있고, 프로젝트가 단순하다면 모두 Railway에서 실행할 수도 있어요.

5. Next.js 하나로 화면과 서버 기능을 함께 만든 경우

로그인, 예약, 결제처럼 요청이 들어올 때 처리하면 되는 기능을 Next.js 한 프로젝트에 넣었다면 우선 Vercel을 검토해보세요. Netlify도 주요 Next.js 기능을 지원하므로 팀의 경험이나 필요한 부가 기능에 따라 선택할 수 있습니다.

Next.js가 화면과 서버를 함께 다룬다는 말이 아직 헷갈린다면 Next.js는 도대체 무엇인지 설명한 글을 참고하세요.

하나만 골라야 하는 것은 아니에요

바이브코딩을 하다 보면 “배포 플랫폼을 하나 정했으니 모든 것을 그곳에 넣어야 한다”고 생각하기 쉬워요. 하지만 실제 서비스는 역할에 따라 나누기도 합니다.

사용자가 보는 Next.js 웹서비스
→ Vercel

오래 실행되는 백엔드와 작업 프로그램
→ Railway

사용자 정보와 서비스 데이터
→ Supabase

이미지와 큰 파일
→ 파일 저장 서비스

무조건 나누는 것이 좋은 것은 아닙니다. 서비스가 나뉘면 주소, 비밀 키, 오류 기록, 비용을 여러 곳에서 관리해야 하니까요. 처음에는 한 플랫폼으로 충분한지 확인하고, 분리해야 할 이유가 생겼을 때 역할을 나누는 것이 좋습니다.

비용은 무료 요금보다 ‘무엇에 따라 늘어나는지’를 보세요

무료 제공량과 정확한 가격은 바뀔 수 있어서 글의 숫자만 믿고 선택하면 위험합니다. 대신 비용이 생기는 기준을 살펴보세요.

• Vercel과 Netlify는 데이터 전송량, 요청 수, 서버 기능의 실행, 빌드 같은 사용량이 비용에 영향을 줍니다.
• Railway는 실행하는 서비스의 컴퓨팅 자원과 저장 공간 같은 사용량이 비용에 영향을 줍니다.
• 방문자가 없어도 계속 실행되어야 하는 서버인지, 요청이 있을 때만 실행되는 기능인지에 따라 비용의 모양이 달라질 수 있어요.
• 이미지와 동영상이 많거나, 파일 업로드가 크거나, 서버 작업이 오래 걸리면 어느 플랫폼이든 예상보다 사용량이 빨리 늘 수 있습니다.

배포 직전에는 각 플랫폼의 최신 가격 페이지와 사용량 알림 기능을 확인하세요. Vercel도 대시보드에서 사용량과 알림을 확인할 수 있습니다. (Vercel 가격 문서 (새 탭에서 열림), Vercel 사용량 관리 문서 (새 탭에서 열림))

AI에게 배포를 맡기기 전에 확인할 것

AI는 익숙한 템플릿이나 이전 설정을 보고 배포 플랫폼을 바로 추천할 수 있어요. 추천을 받기 전에 다음 항목을 프로젝트에서 확인하게 하세요.

• 어떤 프레임워크로 만들었는가?
• 화면을 미리 만들어 전달하는가, 요청할 때마다 서버가 만들어주는가?
• 서버 기능이나 별도 API가 있는가?
• 계속 실행되어야 하는 프로그램이 있는가?
• 실시간 연결을 오래 유지하는가?
• 정해진 시간에 실행하거나 오래 걸리는 작업이 있는가?
• 서버의 로컬 파일에 계속 보관해야 하는 데이터가 있는가?
• 어떤 데이터베이스를 사용하며, 배포할 때 별도 준비 작업이 필요한가?
• API 키와 비밀 값은 어디에 설정해야 하는가?
• 사용자가 많은 지역과 서버 지역이 너무 멀지는 않은가?
• 예상 방문자 수와 이미지·동영상·업로드 용량은 어느 정도인가?

첫 화면은 빠른데 로그인이나 예약 같은 서버 기능만 느리다면 서버와 데이터베이스 Region이 속도에 미치는 영향도 함께 점검하세요.

비밀 키를 배포 환경에 넣는 이유는 API 키와 환경변수 설명에서 확인할 수 있어요.

아래 문장을 그대로 AI에게 보내도 됩니다.

이 프로젝트를 Vercel, Netlify, Railway 중 어디에 배포하는 것이
가장 단순하고 안전한지 읽기 전용으로 점검해줘.

다음을 실제 프로젝트 파일을 근거로 확인해줘.
1. 프레임워크와 빌드·실행 명령
2. 정적 페이지와 서버에서 만들어지는 페이지
3. API와 서버 기능
4. 계속 실행되어야 하는 서버나 작업 프로그램
5. 실시간 연결, 예약 작업, 오래 걸리는 작업
6. 로컬 파일을 계속 보관해야 하는 기능
7. 데이터베이스와 배포 시 준비 작업
8. 필요한 환경변수와 비밀 값
9. 예상되는 플랫폼 제한과 비용 요인

결과는 '요구사항 / 프로젝트에서 찾은 근거 / 플랫폼 선택에 미치는 영향' 표로 정리하고,
Vercel, Netlify, Railway 각각의 장단점을 비교한 뒤 하나를 추천해줘.
확실하지 않은 내용은 추측하지 말고 확인이 필요하다고 표시해줘.
아직 코드나 설정은 변경하지 마.

중요한 것은 AI가 플랫폼 이름만 말하게 하지 않고, 프로젝트 안에서 찾은 근거와 함께 설명하게 하는 것입니다.

정리

• 일반적인 Next.js 웹서비스는 Vercel이 가장 무난한 출발점입니다.
• Netlify도 Next.js와 서버 기능을 지원하며, 웹페이지 중심의 배포 흐름에 강점이 있습니다.
• 계속 실행되는 서버, 별도 백엔드, 작업 프로그램이 필요하면 Railway가 더 자연스럽습니다.
• 세 플랫폼은 겹치는 기능이 많아서 프로젝트의 실행 방식과 팀의 경험, 예상 비용을 함께 봐야 합니다.
• 화면은 Vercel이나 Netlify, 서버는 Railway처럼 역할에 따라 나눌 수도 있습니다.
• 무료 제공량의 숫자보다 무엇이 비용을 늘리는지 확인하는 편이 안전합니다.

처음 만든 Next.js 프로젝트에 특별한 서버 요구가 없다면 Vercel로 시작해도 좋습니다. 반대로 AI가 별도 백엔드, 실시간 서버, 계속 돌아가는 작업을 만들었다면 습관적으로 Vercel을 선택하기 전에 Railway가 더 맞는지 확인해보세요.

좋은 배포 플랫폼은 가장 유명한 곳이 아니라, 내 프로젝트가 필요한 방식으로 가장 단순하게 실행되는 곳입니다.

직접 배포해보고 싶다면 바이브코딩 가이드 13장의 배포 실습을 따라가 보세요.