Vercel 무료 플랜, 어디까지 공짜인가 2026 — 트래픽·용량·함수 제한과 유료 넘어가는 순간

버셀의 무료 플랜 이름은 Hobby입니다. 이름 그대로 취미나 개인 프로젝트를 겨냥한 등급인데, 실제로는 꽤 많은 양의 트래픽과 빌드를 무료로 소화합니다. 무료와 유료를 가르는 축은 크게 다섯 가지로 정리할 수 있습니다. 한 달에 보낼 수 있는 데이터 양, 빌드를 몇 번 돌릴 수 있는지, 서버리스 함수와 엣지 함수가 얼마나 실행되는지, 상업적으로 써도 되는지, 그리고 팀 협업이 되는지입니다.

핵심은 무료가 결코 맛보기 수준이 아니라는 점입니다. 개인 블로그나 포트폴리오, 트래픽이 크지 않은 사이드 프로젝트라면 Hobby만으로도 몇 달, 길게는 1년 넘게 무료로 굴릴 수 있습니다. 유료로 올라가는 건 보통 트래픽이 상업 수준으로 커지거나, 여러 사이트를 동시에 돌려 빌드와 함수 사용이 누적될 때입니다.

버셀에서 가장 먼저 신경 쓰게 되는 한도가 대역폭, 즉 전송량입니다. 이건 방문자에게 내보낸 데이터의 총량을 말합니다. HTML 페이지, CSS, JavaScript 번들, 이미지, 폰트, API 응답까지 사용자 브라우저로 흘러간 모든 바이트가 여기에 합산됩니다. 무료 Hobby는 이 전송량에 월 단위 한도가 걸려 있고, 한도를 넘기면 추가 사용이 제한되거나 유료 전환 안내를 받습니다.

여기서 한국 개발자가 자주 오해하는 지점이 있습니다. 방문자 수가 적어도 전송량은 클 수 있다는 점입니다. 한 페이지에 고해상도 이미지가 여러 장 들어가 있으면, 방문자 한 명이 수 메가바이트를 가져갑니다. 반대로 텍스트 위주의 가벼운 페이지는 같은 방문자 수로도 전송량이 훨씬 적습니다.

• 전송량을 키우는 요소: 최적화 안 된 큰 이미지, 무거운 동영상, 캐시가 안 먹는 동적 응답, 압축 안 된 번들
• 전송량을 줄이는 요소: 이미지 최적화·WebP 변환, 정적 페이지 캐싱, gzip·brotli 압축, CDN 캐시 적중률 향상

저는 12개 사이트를 운영하면서, 전송량이 방문자 수보다 이미지 무게에 훨씬 더 좌우된다는 걸 명세에서 직접 확인했습니다. 텍스트 중심 사이트는 트래픽이 꽤 올라와도 무료 한도 안에서 버텼고, 이미지가 많은 사이트가 먼저 한도에 가까워졌습니다.

두 번째로 자주 부딪히는 한도가 빌드입니다. 버셀은 깃허브(GitHub)에 푸시할 때마다 자동으로 빌드를 돌려 새 버전을 배포합니다. 이게 무료 플랜에서는 양날의 검입니다. 편하긴 한데, 커밋을 자주 푸시할수록 빌드가 누적되어 무료 한도를 빠르게 갉아먹습니다.

저처럼 사이트가 여러 개인 경우 이 문제가 특히 두드러졌습니다. 자동 포스팅 스크립트가 하루에 여러 번 커밋을 올리면, 그때마다 빌드가 트리거되어 무료 빌드 한도가 금세 바닥났습니다. 사이트 하나만 운영할 때는 거의 체감하지 못하던 한도였는데, 사이트가 늘어나니 빌드가 가장 먼저 비명을 질렀습니다.

무료 빌드 한도가 막히면 보통 이런 신호가 옵니다.

• 새 푸시가 빌드 큐에서 대기하거나 실행이 지연됨
• 이번 달 무료 빌드 한도에 도달했다는 안내
• 유료 전환 또는 다음 달까지 대기 권유

그래서 저는 두 가지로 대응했습니다. 첫째, 의미 없는 커밋을 줄여 빌드 트리거 자체를 아꼈습니다. 둘째, 더 근본적으로는 버셀 서버 빌드를 건너뛰는 프리빌트 방식으로 배포 구조를 바꿨습니다. 이 방법은 뒤에서 따로 다루겠습니다.

버셀에서 API 라우트나 동적 렌더링은 서버리스 함수로 실행됩니다. Next.js의 API 라우트, 서버 컴포넌트의 동적 데이터 패칭, 미들웨어 같은 것들이 여기에 해당합니다. 무료 Hobby는 이 함수 실행에도 한도가 있는데, 보통 실행 횟수와 실행 시간, 그리고 함수가 쓰는 메모리·연산량 기준으로 계산됩니다.

정적 페이지만 내보내는 사이트라면 함수 한도는 거의 신경 쓸 일이 없습니다. 빌드 시점에 HTML을 다 만들어 두고, 방문자는 CDN에서 정적 파일만 받아 가기 때문입니다. 반대로 매 요청마다 데이터베이스를 조회하거나 외부 API를 호출하는 동적 사이트라면 함수 실행이 빠르게 쌓입니다.

제 사이트들은 대부분 정적 생성(SSG) 위주라 함수 한도보다 전송량과 빌드 한도가 먼저 문제였습니다. 슈퍼베이스(Supabase)로 데이터를 다루더라도, 빌드 시점에 데이터를 가져와 정적 페이지로 굳히면 방문자 요청마다 함수를 호출하지 않게 됩니다. 함수 한도가 걱정된다면, 매 요청 동적 호출을 빌드 시점 정적 생성으로 옮기는 설계가 가장 확실한 절약법이었습니다.

여기서부터는 제 직접 경험입니다. 저는 처음 한두 사이트를 운영할 때는 무료 Hobby로 아무 문제 없이 버텼습니다. 트래픽도 빌드도 무료 한도 안에서 충분히 돌아갔습니다. 결정적으로 유료로 넘어가게 된 계기는 세 가지가 겹친 시점이었습니다.

1. 사이트 개수가 늘었습니다. 한 계정으로 여러 사이트를 돌리니 빌드와 전송량이 합산되어 한도에 빠르게 닿았습니다.
2. 상업적 사용 영역에 들어갔습니다. 광고가 붙은 사이트는 개인용을 넘어선 상업적 운영이라, 정책상 Pro 등급이 맞았습니다.
3. 자동 발행으로 빌드가 누적됐습니다. 매일 자동으로 글을 올리는 구조라 빌드 트리거가 잦았고, 무료 빌드 한도가 가장 먼저 막혔습니다.

이 세 가지 중 어느 하나만 있었다면 좀 더 무료로 버텼겠지만, 셋이 동시에 오니 Pro로 올리는 게 합리적이었습니다. 특히 상업적 사용 정책은 광고나 제휴 수익이 있는 사이트라면 한도와 무관하게 챙겨야 하는 부분이라, 이 점은 트래픽이 작더라도 미리 확인해 두시길 권합니다.

한 가지 분명히 해 둘 것은, 버셀이 무료 한도를 넘겼다고 바로 사이트를 꺼 버리지는 않는다는 점입니다. 보통은 경고와 함께 유료 전환을 권하고, 일정 유예나 사용량 기반 안내를 줍니다. 그래서 갑자기 사이트가 죽는 사고보다는, 대시보드의 사용량 그래프가 한도에 가까워지는 신호를 미리 보고 결정할 시간이 있었습니다.

유료 Pro는 사용자당 월 구독 방식으로 책정됩니다. 여기에 더해, 포함된 사용량을 넘기면 초과분에 대해 종량제로 추가 요금이 붙는 구조입니다. 즉 기본 구독료 자체는 고정이지만, 전송량이나 함수 실행이 포함량을 크게 초과하면 그달 청구액이 더 올라갈 수 있습니다.

한국에서 결제할 때 신경 써야 할 부분은 표시가격이 보통 미국 달러 기준이라는 점입니다. 한국 카드로 결제하면 청구 시점 환율로 원화가 확정되고, 카드 명세서에는 해외 결제 항목으로 찍힙니다. 부가세(VAT)는 버셀이 한국 사업자 정보를 받지 않은 개인 결제라면 표시가격에 별도로 부과되는 방식이 일반적이고, 사업자 등록 정보를 입력하면 처리 방식이 달라질 수 있습니다.

제가 한국 카드로 결제했을 때는 달러 표시가격이 그달 환율로 원화 환산되어 청구됐고, 환율이 출렁이면 같은 구독이라도 원화 청구액이 조금씩 달라졌습니다. 정확한 금액은 환율과 버셀의 가격 정책, 그리고 그달 초과 사용량에 따라 변하므로, 2026년 6월 기준이라는 단서를 붙여 말씀드리고 결제 직전 공식 가격 페이지에서 현재 구독료와 초과 단가를 다시 확인하시길 권합니다.

제가 여러 사이트를 운영하며 가장 큰 효과를 본 노하우가 프리빌트(Prebuilt) 배포입니다. 기본 흐름은 깃허브에 푸시하면 버셀이 서버에서 빌드를 돌려 배포하는 방식인데, 이 서버 빌드가 빌드 한도를 소모합니다. 프리빌트는 빌드를 내 로컬 컴퓨터에서 끝낸 뒤, 결과물만 버셀에 업로드하는 방식입니다. 버셀 서버 빌드를 건너뛰니 빌드 크레딧을 거의 쓰지 않게 됩니다.

흐름을 단순화하면 이렇습니다. 내 컴퓨터에서 환경 변수를 동기화하고, 로컬에서 빌드를 돌린 뒤, 이미 빌드된 결과물을 프리빌트 플래그로 업로드합니다. 명령으로 보면 다음과 같습니다.

여기서 마지막 줄의 archive 옵션이 중요합니다. 파일이 수만 개로 많은 큰 사이트는 업로드 파일 개수 한도에 걸릴 수 있는데, 결과물을 압축해 묶어 올리면 이 한도를 우회할 수 있습니다. 저는 이 옵션이 없으면 대형 사이트 업로드가 실패하는 경우를 직접 겪었기 때문에, 프리빌트 배포에는 압축 묶음 업로드를 기본으로 둡니다.

프리빌트로 바꾼 뒤 달라진 점은 분명했습니다. 깃허브 푸시가 더 이상 자동으로 서버 빌드를 트리거하지 않도록 설정하고, 배포가 필요할 때만 위 명령으로 직접 올리니, 무료 또는 유료 빌드 한도와 무관하게 배포 비용을 통제할 수 있었습니다. sitemap, RSS, 검색 인덱스 같은 빌드 시점 산출물도 로컬 빌드가 똑같이 만들어 주므로, 서버 빌드와 결과물 차이가 없었습니다.

정리하면, 푸시는 소스 이력 동기화 전용으로 두고, 실제 배포는 프리빌트로만 진행하는 구조입니다. 사이트가 하나라면 굳이 이렇게까지 할 필요는 없지만, 여러 사이트를 굴리거나 빌드가 잦은 자동화 환경이라면 빌드 크레딧 절약 효과가 큽니다.

지금까지 본 한도를 사람 기준으로 정리하면 선택이 쉬워집니다. 저는 다음 질문에 하나라도 강하게 해당하면 Pro를 권하고, 그렇지 않으면 무료 Hobby로 버티라고 말합니다.

1. 광고·제휴 등 상업적 수익이 있는가? 그렇다면 트래픽과 무관하게 Pro 정책이 맞습니다.
2. 한 계정으로 여러 사이트를 돌리는가? 빌드와 전송량이 합산되어 무료 한도가 빨리 막힙니다.
3. 월 전송량이 무료 한도에 자주 닿는가? 대시보드 그래프가 한도 근처라면 Pro가 안전합니다.
4. 매 요청 동적 함수 실행이 많은가? 함수 한도가 먼저 문제가 되면 Pro 포함량이 필요합니다.
5. 팀원과 협업하거나 비밀번호 보호·역할 관리가 필요한가? 협업 기능은 유료 영역입니다.

반대로 개인 블로그, 포트폴리오, 트래픽이 크지 않은 비상업 사이드 프로젝트라면 무료 Hobby만으로도 충분히 오래 버틸 수 있습니다. 저도 비상업 실험용 사이트는 여전히 무료로 두고, 수익이 붙은 사이트만 Pro로 올려 두었습니다. 무료로 시작해 신호가 보일 때 올리는 순서가, 처음부터 유료로 시작하는 것보다 훨씬 합리적이라고 느꼈습니다.

참고 자료

• 버셀 공식 한도 문서 (vercel.com/docs/limits) — 플랜별 대역폭·빌드·함수 한도
• 버셀 가격 안내 (vercel.com/pricing) — Hobby·Pro 구독료와 초과 종량 단가
• 버셀 CLI 배포 문서 (vercel.com/docs/cli/deploy) — prebuilt·archive 옵션 사용법