[Vibe Stack #1] localhost:3000을 카톡으로 보냈더니 안 열린다고? 배포 플랫폼 제대로 고르는 법

localhost:3000을 카톡으로 보냈더니 안 열린다

Cursor로 앱을 만들었다. npm run dev를 치면 브라우저에 멀쩡하게 뜬다. 친구한테 보여주고 싶어서 주소창을 복사해 카톡으로 보냈는데, 친구 폰에서는 아무것도 안 열린다.

당연한 결과다. localhost는 "내 컴퓨터"라는 뜻이다. 친구 폰에서 localhost를 열면 친구 기기를 가리키니 거기엔 아무 앱도 없다. 아파트 호수를 "내 방"이라고 알려준 꼴이다.

다른 사람도 볼 수 있으려면 배포를 해야 한다. 내 컴퓨터에서만 돌아가는 앱을 인터넷 어딘가의 서버에 올려서, 주소만 알면 누구든 접속할 수 있게 만드는 과정이다. 서버라는 건 결국 24시간 켜져 있는 컴퓨터다. 내 노트북을 영원히 켜놓을 수는 없으니 대신 켜놓을 컴퓨터를 빌리는 것이다.

문제는 선택지가 너무 많다는 것이다. Vercel, Netlify, Cloudflare Pages, Railway, Render. 이름만 들어도 머리가 복잡해진다. 하지만 앱 구조에 따라 정리하면 생각보다 단순하다.

먼저 확인: 내 앱에 서버가 필요한가?

배포 방법을 가르는 기준은 앱 구조다. 크게 세 가지로 나뉜다.

도시락형(정적 사이트): HTML, CSS, JavaScript 파일을 그대로 넘기면 끝이다. 주방 없이 포장만 하면 된다. 포트폴리오, 랜딩 페이지, 블로그가 여기에 해당한다.

공유 주방형(서버리스): 주문이 들어올 때마다 잠깐 주방을 빌려서 요리하고, 음식이 나오면 주방을 반납한다. 상시 주방은 없다. Next.js의 API Routes나 서버 컴포넌트가 이 방식이다. 요청 하나당 실행하고 끝낸다.

식당형(풀스택): 주방이 항상 열려 있고 냉장고(DB)도 24시간 돌아간다. 손님이 없어도 유지비가 나간다. 회원가입, 결제, 실시간 채팅처럼 서버가 뭔가를 계속 관리해야 하는 앱이다.

내 앱이 어느 쪽인지 모르겠으면 세 가지만 확인하면 된다.

• 내가 만든 DB에 뭔가 저장하나?
• 직접 만든 API 서버가 있나?
• 로그인 후 사용자마다 다른 데이터를 보여줘야 하나?

하나라도 해당하면 서버가 필요하다. 셋 다 아니면 정적 또는 서버리스로 충분하다.

A. 정적 사이트라면: Cloudflare Pages

포트폴리오, 랜딩 페이지, 문서 사이트, 바이브 코딩으로 뚝딱 만든 소개 페이지라면 Cloudflare Pages가 첫 번째 선택지다.

이유는 하나다. 무료 플랜에서 대역폭 제한이 없다. Vercel이나 Netlify는 무료 플랜에서 월 100GB를 넘으면 과금이 시작된다. 포트폴리오가 갑자기 SNS에서 퍼지거나 채용 담당자들이 몰아서 방문하면, 어느 날 아침 예상치 못한 청구서를 받을 수 있다. Cloudflare Pages는 그 상황에서도 그냥 무료다.

무료 플랜 기준으로 받을 수 있는 것들이다.

• 대역폭: 무제한
• 빌드: 월 500회
• Workers(간단한 서버리스 로직): 하루 10만 건 요청
• 팀원: 제한 없음

처음 설정할 때 GitHub 계정으로 로그인하고 저장소를 연결한다. 빌드 명령어(npm run build 등)와 출력 디렉토리(out, dist, build 중 해당하는 것)를 입력하면 끝이다. 화면이 Vercel보다 항목이 조금 많아서 복잡해 보이는데, 10분이면 충분하다.

이후 git push할 때마다 자동으로 빌드하고 배포한다. 기본 도메인은 프로젝트명.pages.dev 형태로 발급된다.

B. 프론트엔드 + 서버리스라면: Vercel 또는 Netlify

정적 파일만 있는 게 아니라 서버에서 뭔가를 실행해야 하는데, 상시 서버를 두기는 부담스러울 때의 선택지다. Next.js의 서버 컴포넌트나 API Routes처럼 "요청이 들어오면 잠깐 실행하고 끝내는" 구조에 잘 맞는다.

Vercel

Next.js를 만든 회사가 운영하는 플랫폼이다. v0나 Cursor로 만든 앱이 Next.js 기반이라면 가장 자연스러운 선택이다. Next.js 기능을 가장 잘 지원하고, 인터넷에서 찾을 수 있는 배포 가이드 대부분이 Vercel을 기준으로 쓰여 있다.

무료 플랜 기준이다.

• 대역폭: 월 100GB
• 서버리스 함수: 하루 10만 건 요청
• 빌드 시간: 월 6,000분

GitHub 저장소를 연결하면 Next.js를 자동으로 감지해서 설정을 잡아준다. 코드를 push할 때마다 자동 빌드, 자동 배포. PR을 올리면 미리보기 URL도 자동으로 만들어준다.

Next.js 앱이면 고민할 것 없이 Vercel이다. GitHub 연결하고 3분이면 배포가 끝난다.

Netlify

Vercel과 하는 일이 거의 같다. 차이가 있다면 Vercel은 Next.js에 특화된 반면 Netlify는 프레임워크를 가리지 않는다. React, Vue, Svelte, Hugo, 정적 HTML까지 뭐든 받는다.

Netlify에만 있는 기능이 하나 있다. Forms 기능이 무료로 내장돼 있다. 문의 폼, 뉴스레터 구독 폼처럼 사용자 입력을 받아야 할 때 별도 서버 없이 Netlify가 대신 받아준다. Formspree 같은 외부 서비스를 붙일 필요가 없다.

무료 플랜 기준이다.

• 대역폭: 월 100GB
• 서버리스 함수: 월 12만 5천 건 요청
• 빌드 시간: 월 300분(Vercel의 절반)
• Forms: 무료 내장

Vercel이냐 Netlify냐

사이드 프로젝트 수준에서는 솔직히 큰 차이가 없다. 이렇게 결정하면 된다.

• Next.js 앱이면 → Vercel
• 다른 프레임워크거나 폼 기능이 필요하면 → Netlify
• 트래픽 폭발이 걱정되면 → Cloudflare Pages(대역폭 무제한)
• 그래도 모르겠으면 → Vercel(레퍼런스가 가장 많다)

C. 백엔드 + DB가 필요하다면: Railway

DB가 있고 상시 서버가 돌아가야 하고 사용자마다 다른 데이터를 관리해야 한다면, 지금까지 얘기한 세 플랫폼으로는 안 된다. 이때 진입 장벽이 가장 낮은 선택지가 Railway다.

"배포가 이렇게 쉬워도 되나?" 싶을 정도다. GitHub 저장소를 연결하면 코드를 분석해서 언어와 프레임워크를 알아서 감지한다. PostgreSQL, MySQL, Redis 같은 DB도 버튼 하나로 추가된다. 서버와 DB를 한 화면에서 관리할 수 있다.

중요한 점 하나: Railway에는 완전 무료 플랜이 없다. 최소 월 $5 구독이 필요하다. 처음 가입하면 $5 트라이얼 크레딧을 주는데, 카드 등록 없이도 쓸 수 있다. 크레딧이 소진되면 서비스가 멈춘다. 갑자기 큰 금액이 청구되지는 않으니 과금 폭탄 걱정은 없지만, 무료로 계속 쓸 수는 없다.

GitHub 연결 → 자동 감지 → 필요하면 DB 추가 → 배포. 환경변수(API 키, DB 비밀번호 등)는 웹 UI에서 바로 입력한다.

백엔드 + DB가 필요한 앱을 가장 쉽게 배포하는 곳이다. 다만 유료다.

Railway 대신 Render를 고를 때

Render는 Railway와 비슷한 포지션인데, 세 가지가 다르다.

첫째, 정적 사이트는 무제한 무료다. 백엔드가 필요 없는 앱이라면 Render에서 그냥 무료로 쓸 수 있다.

둘째, 웹 서비스 무료 플랜에는 슬립이 있다. 15분 동안 요청이 없으면 서버가 잠든다. 다음 요청이 들어오면 깨어나는데 30초에서 1분쯤 걸린다. 데모할 때 첫 로딩에서 상대방이 "뭔가 고장났나?" 할 수 있다.

셋째, PostgreSQL은 90일만 무료다. 이후엔 유료로 전환하거나 다른 방법을 찾아야 한다.

• 처음 백엔드를 배포해보는 거라면 → Railway(더 간단하다)
• 슬립을 감수하더라도 무료로 시작하고 싶다면 → Render
• Docker를 쓸 줄 알고 서비스 유형을 세밀하게 나누고 싶다면 → Render

D. GPU, ML 모델은 이 글의 범위 밖

GPU가 필요하거나 무거운 ML 모델을 돌리거나 트래픽이 수만 명 단위인 앱은 지금까지 얘기한 플랫폼으로는 한계가 있다. AWS, GCP, Azure를 직접 다루거나 Fly.io처럼 세밀한 설정이 가능한 플랫폼이 필요하다. 다만 그건 이 글의 주제가 아니다. 만약 지금 만든 앱이 그 수준이라면, 배포보다 인프라 설계부터 공부하는 게 순서다.

무료 티어 한눈에 보기

바이브 코더가 자주 하는 실수

localhost 주소를 공유한다. 위에서 얘기했다. localhost는 내 컴퓨터다. 배포 주소를 공유해야 한다.

환경변수를 빠뜨린다. .env 파일에 있는 API 키들은 git에 올리지 않는다(올리면 절대 안 된다). 배포 플랫폼 웹 UI에서 따로 입력해야 한다. 이걸 빠뜨리면 앱이 배포는 됐는데 기능이 안 돌아간다. "로컬에서는 되는데 배포하면 안 돼요"라는 질문의 절반 이상이 여기서 나온다.

빌드 에러를 확인 안 한다. 로컬에서는 잘 됐는데 배포하면 빌드 에러가 난다. 대부분 패키지 버전 차이나 환경변수 누락이다. 플랫폼 대시보드의 빌드 로그를 확인하면 원인이 나온다.

무료 티어 한계를 모른다. Render의 슬립, Netlify의 빌드 시간 300분 한도를 모르고 쓰다가 갑자기 서비스가 멈추면 당황스럽다. 각 플랫폼의 Usage 페이지를 한 번은 열어봐야 한다.

Git 없이 배포하려 한다. 모든 플랫폼이 GitHub 연결을 기본으로 한다. GitHub 계정과 저장소가 없다면 배포 전에 먼저 만들어야 한다. Cursor나 Claude Code로 작업하면서 git commit을 한 번도 안 했다면, 지금이라도 해두는 게 낫다.

의사결정 흐름

내 앱에 서버가 필요한가?
  │
  ├─ 아니오 (HTML/CSS/JS만)
  │   └─→ Cloudflare Pages (트래픽 걱정 없이 무료)
  │
  ├─ 서버리스 정도면 됨 (API 있거나 Next.js 서버 컴포넌트)
  │   ├─ Next.js인가? → Vercel
  │   └─ 다른 프레임워크? → Netlify
  │
  └─ 자체 DB, 상시 서버 필요
      ├─ 유료 괜찮음 → Railway ($5/월부터)
      └─ 무료로 시작하고 싶음 → Render (슬립 감수)

일단 올려봐야 감이 온다

어떤 플랫폼이 맞을지 고민하는 시간이 길어질수록 배포는 점점 거대한 일처럼 느껴진다. 실제로 해보면 GitHub 저장소 연결하고 버튼 몇 번 누르는 게 전부다.

빈 페이지라도 좋으니 일단 올려보자. 배포한 주소를 브라우저에 입력해서 내 앱이 뜨는 걸 보면, 그때 "아, 이게 배포구나" 하고 감이 잡힌다. 그 감각을 한번 느끼고 나면 다음 배포는 훨씬 쉬워진다.

플랫폼을 잘못 골랐다 싶으면 옮기면 된다. 코드가 GitHub에 있으니 새 플랫폼에서 저장소만 다시 연결하면 끝이다. 처음부터 완벽하게 골라야 하는 게 아니다.