프론트엔드 배포 로드맵: Vercel, Firebase Hosting, App Hosting 기준

이 글은 프론트엔드 배포 오류 체크리스트: Vercel, Vite, Expo 문제 해결의 세부 항목입니다. 전체 설정 흐름과 관련 오류 해결 순서는 대표 허브 글에서 함께 확인할 수 있습니다.

Firebase 글은 있지만 Vercel, Firebase, SSH/SFTP 방식이 어떤 상황에서 갈리는지 한 번에 비교하는 글이 부족합니다.

이 글에서 확인할 내용

아래 섹션 링크를 통해 필요한 내용을 바로 확인할 수 있습니다.

배포 도구보다 먼저 프로젝트 성격을 봅니다
정적 배포와 SSR 배포는 운영 방식이 다릅니다
Firebase Hosting과 App Hosting은 Firebase 사용 여부와 렌더링 방식으로 나눕니다
Vercel은 Next.js 중심 프로젝트에서 선택지가 단순해집니다
VPS와 직접 서버는 직접 관리해야 할 때 등장합니다
기능을 붙이는 순서는 오류를 줄이는 순서이기도 합니다
마지막에는 독자가 바로 적용할 기준을 남깁니다
발행 전에는 중복과 연결 흐름을 한 번 더 봅니다
읽는 순서를 정하면 글도 덜 흩어집니다

배포 도구보다 먼저 프로젝트 성격을 봅니다

프론트엔드 배포를 고를 때 Vercel이 좋은지 Firebase Hosting이 좋은지부터 비교하면 판단이 흔들립니다. 먼저 프로젝트가 정적 사이트인지, 서버 렌더링이 필요한 Next.js 앱인지, Firebase 기능과 강하게 연결된 앱인지 나눠야 합니다. 같은 React 앱이라도 랜딩 페이지와 로그인/데이터/파일 업로드가 있는 서비스는 배포 기준이 다릅니다.

정적 배포와 SSR 배포는 운영 방식이 다릅니다

정적 사이트는 빌드 결과물을 CDN에 올려 빠르게 제공하는 구조와 잘 맞습니다. Firebase Hosting이나 Vercel 모두 이런 프로젝트에 적합합니다. 하지만 요청마다 서버에서 HTML을 만들어야 하는 페이지가 많다면 런타임 지원과 서버 기능을 같이 봐야 합니다. Next.js 블로그나 상품 상세 페이지처럼 SEO와 동적 데이터가 중요하면 정적/SSR 경계를 먼저 확인해야 합니다. Next.js 성능 기준은 Next.js 성능 최적화와 연결됩니다.

Firebase Hosting과 App Hosting은 Firebase 사용 여부와 렌더링 방식으로 나눕니다

Firebase Hosting은 정적 파일과 SPA 배포에 잘 맞고, Cloud Functions나 Cloud Run rewrite를 붙이면 동적 콘텐츠나 마이크로서비스도 같은 Hosting 도메인에서 다룰 수 있습니다. Firebase Auth, Firestore, Storage를 함께 쓰는 프로젝트라면 Firebase 생태계 안에서 관리하기 편합니다. 반면 Next.js나 Angular처럼 풀스택·동적 웹앱을 관리형으로 배포하려는 경우에는 Firebase App Hosting을 검토할 수 있습니다. 두 방식의 차이는 Firebase Hosting App Hosting 차이에서 더 자세히 이어볼 수 있습니다.

공식 문서 기준으로 Firebase Hosting은 정적 콘텐츠뿐 아니라 Cloud Functions 또는 Cloud Run과 연결해 동적 콘텐츠를 제공할 수 있고, Firebase App Hosting은 Next.js와 Angular 같은 동적 웹앱을 위한 관리형 배포 흐름을 제공합니다. Firestore는 기본 쿼리와 인덱스 기준도 함께 봐야 합니다. 자세한 기준은 Firebase Hosting 문서, Hosting과 Cloud Functions 문서, Firebase App Hosting 문서, Firestore 쿼리 문서, Vercel Next.js 문서를 함께 확인하면 좋습니다.

Vercel은 Next.js 중심 프로젝트에서 선택지가 단순해집니다

Next.js를 중심으로 만들고, 배포 설정을 최소화하고 싶다면 Vercel은 자연스러운 선택입니다. preview 배포, 라우팅, 서버리스 함수, 이미지 최적화 같은 흐름이 Next.js와 잘 맞습니다. 다만 Firebase Auth나 Firestore와 강하게 연결된 프로젝트라면 인증/데이터/배포 운영이 어디에서 나뉘는지도 같이 봐야 합니다. 배포 도구를 하나로 통일할지, 역할을 나눌지는 팀 운영 방식에 따라 달라집니다.

VPS와 직접 서버는 직접 관리해야 할 때 등장합니다

전통적인 웹호스팅이나 직접 관리하는 서버에 파일을 올려야 하는 경우에는 SSH, SFTP, FTP 같은 접속 방식이 필요합니다. 이 방식은 자유도가 높지만 배포 자동화, 권한 관리, 백업, 보안 업데이트까지 신경 써야 합니다. 단순 프론트엔드 앱이라면 관리형 배포가 편할 때가 많고, 서버 운영 경험이 필요하거나 기존 호스팅 환경을 유지해야 한다면 직접 접속 방식이 필요합니다. 접속 방식 차이는 SSH SFTP FTP 차이와 같이 보면 됩니다.

기능을 붙이는 순서는 오류를 줄이는 순서이기도 합니다

Firebase 프로젝트에서 가장 흔한 실수는 화면부터 만들고 나중에 권한을 붙이는 것입니다. 처음에는 빠르게 동작하지만, 로그인한 사용자만 수정해야 하는 데이터나 본인 파일만 볼 수 있는 규칙이 뒤늦게 들어오면 구조를 다시 바꾸게 됩니다. Auth 흐름을 먼저 보고 Firestore Rules와 Storage Rules를 같이 설계해야 하는 이유가 여기에 있습니다.

데이터와 파일도 처음부터 분리해서 생각해야 합니다. Firestore 문서에는 조회, 필터, 정렬에 쓸 필드와 인덱스 기준을 두고, Storage에는 실제 파일을 두며, Functions에는 클라이언트에 두면 안 되는 로직을 둡니다. 전문 검색처럼 기본 쿼리만으로 부족한 기능은 Enterprise text search 같은 별도 검색 기능이나 인덱스 전략을 함께 검토해야 합니다. 이 구분이 흐려지면 권한 오류가 났을 때 Firestore Rules 문제인지 Storage Rules 문제인지 찾기 어려워집니다.

배포 단계에서는 Hosting 설정만 보는 것이 아니라 환경변수, 보안 규칙 배포 여부, Functions 배포 순서까지 같이 확인합니다. Firebase는 작은 서비스에 빠르게 붙이기 좋은 도구지만, 기능이 서로 연결되어 있기 때문에 순서를 정해두는 편이 유지보수에 훨씬 유리합니다.

마지막에는 독자가 바로 적용할 기준을 남깁니다

배포 도구를 고를 때는 먼저 앱이 정적 사이트인지, SSR이 필요한 Next.js 앱인지, Firebase Auth와 Firestore 같은 백엔드 기능에 강하게 묶여 있는지 나눕니다. 이 기준이 정리되면 Vercel, Firebase Hosting, Firebase App Hosting 중 어디부터 볼지 훨씬 분명해집니다.

빌드 결과물이 정적 파일만으로 충분한가?
요청마다 서버에서 렌더링해야 하는 페이지가 있는가?
Firebase Auth, Firestore, Storage, Functions를 함께 운영해야 하는가?
Preview 배포, 이미지 최적화, 서버리스 함수가 Next.js 흐름과 맞아야 하는가?
직접 서버를 운영해야 할 만큼 SSH, 백업, 보안 업데이트를 관리할 이유가 있는가?

발행 전에는 중복과 연결 흐름을 한 번 더 봅니다

배포 선택을 끝내기 전에는 로컬 빌드, 환경변수, 라우팅, 보안 규칙, 배포 후 도메인을 한 번에 확인합니다. 정적 배포에서는 빌드 결과물과 rewrite가 중요하고, SSR 배포에서는 런타임과 서버 기능 지원이 더 중요합니다.

Firebase를 함께 쓰는 프로젝트라면 Hosting만 볼 것이 아니라 Auth, Firestore Rules, Storage Rules, Functions 배포 순서까지 같이 봐야 합니다. Vercel을 쓰더라도 Firebase 기능을 연결한다면 인증과 데이터 운영 경계가 어디인지 정리해 두는 편이 좋습니다.

읽는 순서를 정하면 글도 덜 흩어집니다

프론트엔드 배포 로드맵의 핵심은 모든 개념을 한 번에 외우는 것이 아니라, 실제 작업에서 마주치는 순서대로 판단 기준을 세우는 데 있습니다. 먼저 작은 화면이나 문제 하나를 기준으로 시작하고, 필요한 순간에 다음 글로 넘어가면 학습 흐름이 끊기지 않습니다.

함께 확인하면 좋은 기준

이 글과 관련해 실제 작업에서 같이 확인하면 좋은 기준입니다.

Firebase Documentation: 적용 전 현재 문서의 권장 API, 설정 옵션, 제한 사항이 글의 설명과 맞는지 확인합니다.
비슷한 오류를 구분할 때는 발생 위치, 실행 환경, 재현 조건을 먼저 분리해 확인합니다.
프로젝트에 적용할 때는 기존 코드 구조, 의존성 버전, 배포 환경에서 같은 기준이 유지되는지 확인합니다.

이 글이 마음에 드세요?

RSS 피드를 구독하세요!