정식 상업용 프로젝트를 Vercel이나 Netlify로 경제적으로 운영하는 방법

vercelnetlifyhostingdeploymentcommercial-projectcost-optimizationstatic-siteserverless

Vercel과 Netlify는 프론트엔드 프로젝트를 빠르게 배포하기 좋은 플랫폼이다. GitHub와 연결해 자동 배포를 만들 수 있고, CDN, SSL, Preview Deployment, 서버리스 함수, 로그, 분석 기능까지 제공하기 때문에 작은 팀이나 프리랜서 개발자에게 특히 매력적이다.

하지만 정식 상업용 프로젝트라면 “무료로 배포할 수 있다”는 관점으로 접근하면 안 된다. 고객사 웹사이트, 회사 랜딩 페이지, 예약 서비스, SaaS, 쇼핑몰, 관리자 대시보드처럼 실제 사용자와 매출이 연결되는 프로젝트는 무료 플랜이 아니라 운영 비용을 예측하고 통제할 수 있는 유료 플랜을 기준으로 설계해야 한다.

핵심은 단순하다.

Vercel이나 Netlify를 싸게 쓰는 방법은 무료 플랜에 억지로 맞추는 것이 아니라, 동적 연산과 대용량 트래픽을 줄이고 정적 파일과 CDN 캐시를 최대한 활용하는 것이다.

이 글에서는 정식 상업용 프로젝트를 Vercel 또는 Netlify로 경제적으로 운영하는 방법을 정리한다. 가격과 한도는 2026년 6월 8일 기준 Vercel Pricing, Vercel Usage & Pricing 문서, Netlify Pricing, Netlify credit-based plans 문서를 기준으로 확인했다.

1. 상업용 프로젝트라면 무료 플랜을 기본값으로 잡지 않는다

개인 포트폴리오, 테스트 앱, 오픈소스 데모, 작은 정적 블로그라면 무료 플랜도 충분히 쓸 수 있다. 하지만 정식 상업용 프로젝트는 다르다.

상업용 프로젝트에서는 다음 요소가 중요하다.

  • 서비스 중단 위험
  • 트래픽 증가 대응
  • 고객 데이터 처리
  • 로그와 장애 분석
  • 보안 설정
  • 협업 권한 관리
  • 비용 예측
  • 고객사 신뢰

무료 플랜은 이런 요소를 안정적으로 보장하기 위한 플랜이 아니다. 특히 Vercel Hobby 플랜은 개인적, 비상업적 사용 성격이 강하므로 고객사나 회사 프로젝트라면 Pro 이상을 기준으로 잡는 것이 현실적이다.

Netlify는 신규 계정 기준 credit-based pricing을 사용한다. Free는 월 300 credits, Personal은 월 1,000 credits, Pro는 월 3,000 credits를 제공한다. 정식 운영에서는 Free 한도에 맞추기보다 Personal 또는 Pro 이상을 기준으로 비용을 계산하는 편이 안전하다.

2. 프론트엔드 운영 플랫폼으로 이해해야 한다

Vercel과 Netlify는 단순한 “서버 비용 절감 도구”가 아니라 프론트엔드 운영 플랫폼이다. 이 플랫폼들은 다음 작업에 강하다.

  • 정적 파일 배포
  • CDN 기반 전송
  • 프론트엔드 자동 배포
  • Preview Deployments
  • Next.js, Astro, SvelteKit, Nuxt 등 프레임워크 배포
  • 소규모 서버리스 함수
  • 간단한 API 라우트
  • Edge Middleware 또는 Edge Functions

반대로 다음 작업을 무겁게 처리하기에는 비용 효율이 떨어질 수 있다.

  • 대량 파일 다운로드
  • 이미지와 동영상 원본 호스팅
  • 무거운 백엔드 연산
  • 긴 실행 시간이 필요한 API
  • 실시간 WebSocket 서버
  • 대용량 데이터 처리
  • 크롤링과 배치 작업
  • 빈번한 서버리스 함수 호출

따라서 경제적인 구조는 역할 분리에서 시작한다.

역할권장 위치
프론트엔드, 정적 페이지, CDN 캐시Vercel 또는 Netlify
DB, 대용량 파일, 복잡한 API, 배치 작업별도 백엔드 또는 관리형 서비스

3. 가장 경제적인 구조는 정적 우선 아키텍처다

Vercel과 Netlify에서 비용이 적게 나오는 프로젝트는 대부분 정적 페이지 비중이 높다.

예를 들어 다음 유형은 비용 효율이 좋다.

  • 회사 소개 사이트
  • 브랜드 랜딩 페이지
  • 마케팅 페이지
  • 제품 소개 페이지
  • 문서 사이트
  • 정적 블로그
  • 채용 페이지
  • 이벤트 페이지

이런 프로젝트는 페이지를 빌드 시점에 HTML, CSS, JavaScript로 만들어 CDN에 올릴 수 있다. 사용자가 페이지를 볼 때마다 서버가 계산하지 않기 때문에 비용이 안정적이다.

권장 방식은 다음과 같다.

  • Next.js라면 Static Generation 또는 ISR을 우선 사용한다.
  • Astro, Eleventy, Hugo 같은 정적 사이트 생성기를 고려한다.
  • CMS 데이터는 빌드 시점 또는 ISR로 가져온다.
  • 모든 페이지를 SSR로 만들지 않는다.
  • 관리자 페이지와 공개 페이지를 분리한다.

특히 회사 홈페이지나 고객사 랜딩 페이지라면 SSR이 거의 필요 없다. 이런 사이트를 매 요청마다 서버에서 렌더링하는 것은 불필요한 비용이 될 수 있다.

4. SSR은 필요한 곳에만 사용한다

Next.js나 Nuxt를 사용하다 보면 모든 페이지를 서버 렌더링으로 처리하고 싶어질 수 있다. 하지만 상업용 프로젝트를 경제적으로 운영하려면 SSR은 반드시 필요한 곳에만 써야 한다.

SSR이 필요한 경우는 대략 다음과 같다.

  • 로그인 사용자별로 완전히 다른 화면이 필요한 경우
  • 실시간에 가까운 데이터가 필요한 경우
  • SEO에 필요한 데이터가 요청 시점마다 달라지는 경우
  • 권한에 따라 서버에서 콘텐츠를 제어해야 하는 경우

반대로 다음 페이지는 대부분 정적으로 처리할 수 있다.

  • 메인 랜딩 페이지
  • 회사 소개
  • 서비스 소개
  • 가격 안내
  • 블로그 글
  • FAQ
  • 고객 사례
  • 이용약관
  • 개인정보처리방침

경제적인 운영을 위한 기준은 명확하다.

기본값은 Static, 정말 필요한 페이지만 ISR, 개인화가 필요한 영역만 client fetching 또는 SSR.

SSR은 편리하지만 요청 수가 늘어날수록 compute 비용과 origin 관련 사용량이 증가할 수 있다. 정식 운영에서는 편의성보다 비용 구조를 먼저 봐야 한다.

5. 서버리스 함수는 가벼운 접착제로만 사용한다

Vercel Functions나 Netlify Functions는 간단한 API를 만들기에 편하다. 하지만 모든 백엔드를 서버리스 함수로 처리하는 것은 경제적이지 않을 수 있다.

서버리스 함수에 적합한 작업은 다음 정도다.

  • 문의 폼 전송
  • 외부 API 토큰 숨기기
  • 간단한 webhook 처리
  • 결제 성공 콜백 처리
  • 이메일 발송 요청
  • 짧은 데이터 조회

반대로 다음 작업은 별도 백엔드나 전문 서비스를 고려하는 편이 낫다.

  • 이미지 리사이징 대량 처리
  • PDF 생성
  • 엑셀 파일 대량 생성
  • 장시간 크롤링
  • 대량 DB 업데이트
  • 실시간 채팅
  • 복잡한 검색
  • AI 응답 생성처럼 실행 시간이 길고 비용 변동이 큰 작업

서버리스 함수는 작은 기능을 빠르게 붙이는 도구이지, 모든 백엔드를 대신하는 무제한 서버가 아니다.

6. 이미지와 파일을 그대로 올리지 않는다

상업용 프로젝트에서 비용을 크게 만드는 대표적인 원인은 이미지와 파일이다.

다음 경우는 특히 위험하다.

  • 고해상도 이미지를 원본 그대로 업로드
  • 제품 이미지가 수천 장 이상
  • PDF, ZIP, 동영상 파일을 직접 호스팅
  • 사용자가 파일을 업로드하고 다운로드함
  • 썸네일을 요청 시점마다 생성함

Vercel과 Netlify 모두 CDN을 제공하지만 대역폭은 결국 비용과 연결된다. 이미지와 파일이 커질수록 트래픽 비용은 빠르게 증가한다.

경제적인 운영 방식은 다음과 같다.

  • 이미지는 WebP 또는 AVIF로 변환한다.
  • 업로드 전 원본 이미지를 압축한다.
  • 썸네일 사이즈를 명확히 분리한다.
  • 동영상은 YouTube, Vimeo, Cloudflare Stream 같은 외부 서비스를 사용한다.
  • 대용량 다운로드 파일은 S3, Cloudflare R2 같은 오브젝트 스토리지를 사용한다.
  • 이미지가 많은 서비스는 별도 이미지 CDN을 검토한다.

일반적인 회사 홈페이지라면 플랫폼의 이미지 최적화 기능으로 충분할 수 있다. 하지만 쇼핑몰, 갤러리, 매물 사이트, 여행 사이트처럼 이미지가 핵심인 서비스라면 별도 이미지 전략이 필요하다.

7. 빌드 비용도 관리한다

많은 개발자가 트래픽 비용만 생각하지만, 정식 운영에서는 빌드 비용도 중요하다.

특히 다음 프로젝트는 빌드 비용이 커질 수 있다.

  • 페이지 수가 많은 정적 블로그
  • 상품 상세 페이지가 수천 개 이상인 쇼핑몰
  • 다국어 페이지가 많은 사이트
  • 이미지 최적화가 빌드 중에 많이 발생하는 사이트
  • 모노레포에서 불필요한 앱까지 함께 빌드되는 구조

빌드 비용을 줄이는 방법은 다음과 같다.

  • main 브랜치 production deploy를 남발하지 않는다.
  • Preview Deploy와 Production Deploy를 구분한다.
  • CMS 수정마다 전체 사이트를 다시 빌드하지 않는다.
  • ISR 또는 on-demand revalidation을 사용한다.
  • 모노레포에서는 변경된 앱만 빌드되도록 설정한다.
  • 의존성 설치 시간을 줄인다.
  • 불필요한 빌드 플러그인을 제거한다.

Netlify의 credit-based plan에서는 successful production deploy 1회가 15 credits를 사용한다. 작은 텍스트 수정마다 production deploy를 반복하면 credits가 낭비될 수 있다.

Vercel도 빌드 시간, 빌드 머신, 원격 캐시, 배포 구조에 따라 비용과 성능이 달라질 수 있다. 상업용 프로젝트라면 CI/CD 전략도 비용 설계의 일부로 봐야 한다.

8. 캐싱 전략이 곧 비용 전략이다

Vercel과 Netlify에서 경제적으로 운영되는 서비스는 캐싱이 잘 되어 있다.

캐싱이 없으면 다음 문제가 생긴다.

  • 같은 데이터를 계속 서버에서 계산한다.
  • 같은 API를 반복 호출한다.
  • 같은 이미지를 계속 변환한다.
  • CDN이 아니라 origin이나 function으로 요청이 몰린다.
  • 트래픽 증가 시 비용이 선형적으로 증가한다.

권장 캐싱 전략은 다음과 같다.

  • 정적 asset은 긴 cache-control을 적용한다.
  • 자주 바뀌지 않는 API 응답은 캐시한다.
  • CMS 콘텐츠는 ISR 또는 revalidation을 사용한다.
  • 이미지 변환 결과를 재사용한다.
  • 외부 API 응답을 서버에서 캐시한다.
  • 로그인하지 않은 사용자의 공개 페이지는 최대한 CDN 캐시한다.

마케팅 사이트나 콘텐츠 사이트에서는 요청마다 서버에서 데이터를 가져오는 구조를 피해야 한다. 공개 콘텐츠는 미리 만들거나 캐시해야 한다.

9. 프로젝트 유형별 추천 구조

프로젝트 유형에 따라 비용 효율적인 구조는 다르다.

프로젝트 유형추천 구조
회사 홈페이지, 브랜드 사이트Astro, Next.js SSG, Nuxt generate + CMS + CDN
블로그, 콘텐츠 미디어SSG + ISR + 이미지 압축 + 별도 검색 서비스
쇼핑몰프론트엔드는 Vercel/Netlify, 상품/주문/결제는 Shopify, Medusa, Commerce Layer 또는 자체 백엔드
SaaS, 대시보드프론트엔드는 Vercel/Netlify, 인증/DB/API/파일/모니터링은 전문 서비스와 별도 백엔드
고객사 랜딩 페이지 여러 개고객사별 프로젝트와 비용 책임 분리, 트래픽이 큰 고객은 별도 팀 또는 계정

SaaS에서 Vercel이나 Netlify는 전체 서버가 아니라 프론트엔드 배포 계층으로 쓰는 것이 안전하다. 고객사 프로젝트라면 한 고객의 광고 캠페인으로 트래픽이 폭증할 때 다른 고객 프로젝트에 영향이 가지 않도록 비용과 책임 범위를 분리해야 한다.

10. Vercel을 경제적으로 쓰는 기준

Vercel은 Next.js 프로젝트에 특히 강하다. App Router, ISR, Edge Middleware, Server Actions, Image Optimization 등을 자연스럽게 사용할 수 있다.

Vercel을 경제적으로 쓰려면 다음 기준이 필요하다.

  • 상업용이면 Pro 이상을 사용한다.
  • 모든 페이지를 SSR로 만들지 않는다.
  • 정적 페이지와 ISR을 적극 사용한다.
  • 서버리스 함수는 짧고 가벼운 작업에만 사용한다.
  • 이미지 최적화 사용량을 확인한다.
  • Web Analytics, Speed Insights 이벤트 사용량을 확인한다.
  • Spend Management를 설정한다.
  • 비용 알림과 webhook을 설정한다.
  • 트래픽이 큰 파일은 별도 스토리지로 분리한다.

Vercel Pro는 월 $20부터 시작하며, 공식 Pricing 기준으로 월 $20 usage가 포함된다. Pro 팀은 사용량과 지출을 관리하기 위한 dashboard, 알림, webhook, project pause 같은 spend management 기능을 활용할 수 있다.

11. Netlify를 경제적으로 쓰는 기준

Netlify는 정적 사이트, Jamstack, Deploy Preview, Forms, Functions 기반 워크플로우에 강하다.

Netlify를 경제적으로 쓰려면 현재 credit-based pricing을 이해해야 한다. Production deploy, bandwidth, compute, web requests가 credits를 소모한다. 따라서 배포 횟수, 트래픽, 함수 실행, 요청 수가 모두 비용 변수다.

Netlify 운영 기준은 다음과 같다.

  • 상업용이면 Personal 또는 Pro 이상을 검토한다.
  • Production deploy를 불필요하게 반복하지 않는다.
  • 정적 사이트 중심으로 설계한다.
  • Functions는 간단한 작업에만 사용한다.
  • 이미지와 파일 용량을 줄인다.
  • 대역폭이 큰 콘텐츠는 외부 스토리지를 사용한다.
  • credits 사용량을 정기적으로 확인한다.
  • 팀 협업이 필요하면 Pro를 검토한다.

Netlify는 회사 홈페이지, 랜딩 페이지, 정적 블로그, 문서 사이트, Jamstack 프로젝트에 특히 적합하다. 반면 서버리스 API가 많은 SaaS나 대용량 이미지 서비스라면 비용 구조를 더 신중하게 봐야 한다.

12. 저렴한 운영을 위한 체크리스트

정식 상업용 프로젝트를 Vercel이나 Netlify에 올리기 전에는 아래 항목을 점검해야 한다.

  • 상업용 플랜을 사용하고 있는가?
  • 월 예상 방문자 수를 계산했는가?
  • 평균 페이지 용량을 측정했는가?
  • 월 예상 bandwidth를 계산했는가?
  • SSR 페이지와 정적 페이지를 구분했는가?
  • 서버리스 함수 호출 수를 예상했는가?
  • 이미지와 파일을 압축했는가?
  • 대용량 파일을 별도 스토리지로 분리했는가?
  • production deploy 횟수를 관리하고 있는가?
  • 비용 알림을 설정했는가?
  • 프로젝트별 사용량을 볼 수 있는가?
  • 트래픽 폭증 시 대응 방법이 있는가?
  • 고객사별 비용 책임 범위가 명확한가?
  • 장애 분석을 위한 로그와 모니터링이 있는가?

이 체크리스트를 통과하지 못한 상태에서 상업용 서비스를 공개하면, 비용 문제보다 운영 책임 문제가 먼저 발생할 수 있다.

13. 비용을 계산하는 간단한 방법

정확한 비용은 플랫폼의 Usage Dashboard나 Pricing Calculator로 확인해야 한다. 하지만 초기 견적은 다음 방식으로 대략 계산할 수 있다.

월 bandwidth 예상치 =
월 방문자 수 × 방문자당 평균 페이지뷰 × 평균 페이지 전송 용량

예를 들어 다음과 같은 사이트가 있다고 가정해보자.

월 방문자 수: 30,000명
방문자당 평균 페이지뷰: 3회
평균 페이지 전송 용량: 1.5MB

그러면 월 전송량은 대략 다음과 같다.

30,000 × 3 × 1.5MB = 135,000MB
약 135GB

이 사이트가 대부분 정적 페이지라면 비용은 비교적 예측 가능하다. 하지만 같은 트래픽에서 서버리스 함수가 페이지마다 실행되거나, 이미지가 원본 그대로 제공되거나, 외부 API를 매 요청마다 호출한다면 비용은 더 커질 수 있다.

비용 견적은 방문자 수만 보면 안 된다. 페이지뷰 수, 페이지 용량, 이미지 용량, 함수 호출 수, 함수 실행 시간, 빌드 횟수, 분석 이벤트 수, 파일 다운로드 수를 함께 봐야 한다.

14. 고객사 프로젝트라면 비용을 견적에 포함한다

프리랜서나 에이전시가 Vercel 또는 Netlify로 고객사 프로젝트를 운영한다면, 호스팅 비용을 애매하게 처리하면 안 된다.

권장 방식은 다음과 같다.

  • 개발비와 운영비를 분리한다.
  • 도메인, 호스팅, CMS, 이메일, 스토리지 비용을 별도 항목으로 명시한다.
  • 기본 트래픽 한도를 계약서에 포함한다.
  • 초과 트래픽 발생 시 추가 비용 조건을 명시한다.
  • 고객사 계정으로 결제하도록 구성한다.
  • 개발자 개인 계정에 고객사 프로젝트를 계속 묶어두지 않는다.

가장 나쁜 방식은 개발자의 개인 Vercel 또는 Netlify 계정에 여러 고객사 프로젝트를 무료 또는 저가로 계속 올려두는 것이다. 단기적으로는 편하지만 장애, 비용, 소유권 문제가 생겼을 때 책임이 복잡해진다.

고객사 프로젝트라면 고객사 소유 계정을 만들고, 개발자를 팀 멤버로 초대하고, 도메인과 결제 수단은 고객사가 보유하는 구조가 더 안전하다.

15. Vercel과 Netlify 중 무엇을 선택해야 할까?

선택 기준은 가격만 보면 안 된다. 프로젝트 성격을 먼저 봐야 한다.

프로젝트 유형더 자연스러운 선택
Next.js 중심 앱Vercel
정적 사이트, JamstackNetlify
Astro, Eleventy, Hugo 블로그Netlify 또는 Vercel
회사 랜딩 페이지둘 다 가능
SaaS 프론트엔드Vercel 또는 Netlify + 별도 백엔드
Form 중심 사이트Netlify
Next.js App Router 적극 사용Vercel
팀 협업과 프리뷰 리뷰 중심둘 다 가능
비용 예측을 단순화하고 싶은 소규모 팀Netlify Personal/Pro 검토
Next.js 기능 최적화를 우선하는 팀Vercel Pro 검토

현실적으로는 다음처럼 판단하면 된다.

  • Next.js를 깊게 쓴다: Vercel 우선
  • 정적 사이트와 form 중심이다: Netlify 우선
  • 비용이 가장 중요하다: 정적화, CDN, 외부 스토리지 구조 우선
  • 백엔드가 무겁다: 둘 중 하나만으로 해결하려 하지 말 것

결론: 경제적인 운영의 핵심은 플랫폼 선택보다 아키텍처다

Vercel과 Netlify는 상업용 프로젝트를 운영하기에 충분히 좋은 플랫폼이다. 하지만 저렴하게 운영하려면 무료 플랜에 억지로 맞추는 방식이 아니라, 비용이 적게 나오는 구조로 설계해야 한다.

가장 중요한 원칙은 다음과 같다.

  1. 상업용 프로젝트는 유료 플랜을 기본값으로 잡는다.
  2. 공개 페이지는 최대한 정적으로 만든다.
  3. SSR은 필요한 곳에만 쓴다.
  4. 서버리스 함수는 짧고 가볍게 사용한다.
  5. 이미지와 대용량 파일은 별도 전략을 세운다.
  6. 캐시를 적극적으로 활용한다.
  7. 비용 알림과 사용량 대시보드를 반드시 확인한다.
  8. 고객사 프로젝트는 계정, 결제, 책임 범위를 분리한다.

결국 Vercel이나 Netlify를 경제적으로 쓰는 가장 좋은 방법은 무조건 싼 플랜을 고르는 것이 아니다. 서비스 구조를 정적으로 만들고, 동적 연산을 줄이고, 대용량 트래픽을 분리하고, 사용량을 계속 관찰하는 것이다.

상업용 프로젝트에서 인프라 비용은 0원이 되는 것이 목표가 아니다. 예측 가능하고, 감당 가능하고, 장애 없이 운영되는 것이 목표다.

Related