Firebase Hosting App Hosting 차이: 정적 배포와 SSR 기준

• Firebase Hosting과 App Hosting을 먼저 어떻게 구분할까
• Firebase Hosting의 특징과 잘 맞는 프로젝트
• Firebase App Hosting의 특징과 잘 맞는 프로젝트
• 실무에서는 어떤 기준으로 선택하면 좋을까
• 결론
• 많이 받는 질문
• 같이 읽으면 좋은 글

Firebase Hosting과 App Hosting을 먼저 어떻게 구분할까

이 주제를 처음 정리할 때 가장 먼저 분리하는 기준은 기능 개수보다 배포 대상입니다. Firebase Hosting은 기본적으로 HTML, CSS, JavaScript, 이미지 같은 정적 파일을 빠르게 배포하는 데 강하고, SPA처럼 브라우저에서 동작하는 웹앱에도 잘 맞습니다. 반면 App Hosting은 Next.js 같은 현대 웹 프레임워크를 대상으로 빌드, 배포, 롤아웃, 서버 렌더링 운영까지 묶어서 다루는 쪽에 더 가깝습니다. 이름만 보면 비슷해 보이지만, 실제로는 정적 콘텐츠 CDN 배포와 SSR 포함 풀스택 운영이라는 출발점이 다르다고 이해하는 편이 훨씬 덜 헷갈립니다.

정적 export가 필요한 구조인지 먼저 보는 예시

const nextConfig = {
    output: 'export',
    images: { unoptimized: true }
};
export default nextConfig;

Next.js 프로젝트를 Firebase Hosting에 올릴 때는 이런 식으로 정적 결과물을 만들어 배포하는 흐름을 먼저 떠올리게 됩니다. 이 방식은 페이지를 미리 만들어 둘 수 있을 때 단순하고 빠르지만, 요청마다 서버에서 렌더링해야 하는 화면이 많아지면 점점 제약이 커집니다. 그래서 시작점은 늘 간단합니다. 앱이 미리 빌드된 파일만 배포하면 되는지, 아니면 요청 시점의 서버 실행이 필요한지부터 확인하면 됩니다.

Firebase Hosting의 특징과 잘 맞는 프로젝트

Firebase Hosting을 볼 때 가장 큰 장점은 단순함입니다. 정적 파일을 글로벌 CDN에 올리는 구조라서 배포 흐름이 비교적 가볍고, 홍보 페이지·이벤트 페이지·회사 소개 사이트·정적 블로그·Vite 기반 SPA처럼 브라우저 중심 화면에는 상당히 잘 맞습니다. 또한 리다이렉트, 리라이트, 헤더 설정, 프리뷰 채널 같은 기능이 있어 운영 환경에서도 생각보다 유연합니다. 다만 최신 웹 프레임워크 통합은 Firebase 문서에서도 실험용 CLI 기능으로 안내하고 있으므로, 정적 중심 배포인지 프레임워크 서버 실행까지 필요한지 구분해서 보는 편이 좋습니다. 즉, Hosting은 작고 빠르게 시작하기 좋은 선택지이고, 필요한 경우에만 Functions나 Cloud Run을 연결해 동적 기능을 추가하는 방식이 자연스럽습니다.

firebase.json으로 정적 배포를 다루는 기본 예시

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [{ "source": "**", "destination": "/index.html" }]
  }
}

SPA를 Hosting에 배포할 때는 위처럼 리라이트를 걸어 두는 구성이 자주 등장합니다. 사용자는 어떤 경로로 들어와도 결국 index.html을 받아서 클라이언트 라우터가 화면을 결정하게 됩니다. 이 흐름은 React, Vue, Vite 프로젝트에서 이해해 두면 활용 범위가 넓습니다. 다만 여기서 중요한 점은 이 구조는 어디까지나 정적 자산을 CDN으로 전달하는 데 최적화되어 있다는 것입니다. 서버에서 매 요청마다 HTML을 만들어야 하는 서비스와는 성격이 다릅니다.

구분	핵심 성격
Firebase Hosting	정적 파일·SPA 중심, CDN 배포가 강점
Firebase App Hosting	SSR 포함 프레임워크 앱의 빌드·배포·운영 자동화가 강점

Firebase App Hosting의 특징과 잘 맞는 프로젝트

runConfig:
  minInstances: 0
  maxInstances: 10
  concurrency: 80
env:
  - variable: NEXT_PUBLIC_API_BASE_URL
    value: https://example.com

Firebase App Hosting은 단순히 Firebase 안의 또 다른 호스팅이라기보다, 프레임워크 앱용 관리형 배포 계층으로 보는 편이 맞습니다. App Hosting은 GitHub 저장소와 연결해 커밋 기준으로 빌드와 롤아웃을 수행하고, 내부적으로는 Cloud Build, Cloud Run, CDN 계층을 활용해 앱을 운영합니다. 또한 Firebase 문서 기준으로 Next.js와 Angular에는 기본 지원이 제공되고, 그 외 프레임워크는 어댑터를 통해 확장하는 방향으로 설명됩니다. 그래서 Next.js처럼 서버 컴포넌트, 동적 데이터 패칭, 서버 액션 같은 요소가 들어가기 시작하면 Firebase Hosting보다 App Hosting이 훨씬 자연스럽게 느껴집니다.

이런 프로젝트라면 App Hosting이 더 자연스럽습니다

type Post = {
    id: number;
    title: string;
};
export default async function Page() {
    const res = await fetch('https://api.example.com/posts', { cache: 'no-store' });
    if (!res.ok)
        throw new Error('게시글을 불러오지 못했습니다.');
    const posts: Post[] = await res.json();
    return (<ul>
      {posts.map((post) => <li key={post.id}>{post.title}</li>)}
    </ul>);
}

위와 같은 예시를 보면 정적 export보다 서버 실행 환경을 먼저 떠올리게 됩니다. 요청 시점마다 데이터를 다시 읽고, 화면을 서버에서 조합하고, 환경 변수나 비밀값 관리까지 안정적으로 가져가야 하기 때문입니다. 이럴 때 App Hosting은 프레임워크의 기본 설정을 비교적 자연스럽게 받아들이면서, 배포 파이프라인과 운영 구성을 따로 크게 짜지 않아도 되는 장점이 있습니다. 반대로 정적인 소개 페이지 수준이라면 이런 무게감이 오히려 과할 수도 있습니다.

실무에서는 어떤 기준으로 선택하면 좋을까

실무에서 판단할 때는 기술 이름보다 운영 질문을 먼저 던지게 됩니다. 첫째, 이 앱이 빌드 결과물만 올리면 끝나는가. 둘째, 요청마다 서버 렌더링이나 동적 데이터 조합이 필요한가. 셋째, GitHub 푸시 기준 자동 롤아웃, 로그 추적, 런타임 설정 같은 운영 편의가 중요한가. 이 세 가지에 대한 답이 대부분 선택을 정리해 줍니다. 정적 사이트, SPA, 소규모 마케팅 페이지라면 Hosting이 더 단순하고 비용 감각도 예측하기 쉽습니다. 반면 Next.js 기반 서비스, 인증 후 개인화 화면, SEO, 서버 액션, 점진적 운영 자동화가 필요하다면 App Hosting이 더 잘 맞습니다.

또 하나는 마이그레이션 관점입니다. 이미 Firebase Hosting으로 잘 운영되는 정적 프로젝트를 굳이 App Hosting으로 옮길 이유는 크지 않습니다. 하지만 정적 export를 유지하려고 Next.js 기능을 계속 포기하고 있다면, 그때는 App Hosting 검토 가치가 커집니다. 즉, “새로운 기능이 멋져 보인다”보다 “현재 구조가 프로젝트를 자꾸 제한하는가”를 기준으로 보는 편이 훨씬 실용적입니다.

결론

이 주제를 한 문장으로 정리하면 이렇습니다. Firebase Hosting은 정적 파일과 SPA를 빠르고 단순하게 배포하는 데 강하고, Firebase App Hosting은 Next.js 같은 현대 프레임워크 앱을 서버 렌더링까지 포함해 운영하기 쉬운 방향으로 설계되어 있습니다. 결국 선택 기준은 서비스 이름이 아니라 앱의 실행 방식입니다. 미리 만든 결과물을 전 세계 CDN에 뿌리는 구조라면 Hosting이 충분하고, 요청마다 서버가 개입해야 하는 웹앱이라면 App Hosting을 보는 편이 자연스럽습니다.

많이 받는 질문

Q. Next.js를 쓰면 무조건 App Hosting을 써야 하나요?
그렇지는 않습니다. 정적 export가 가능한 구조라면 Firebase Hosting으로도 충분합니다. 다만 SSR, 서버 액션, 요청 시점 데이터 패칭이 많아질수록 Firebase App Hosting이 더 자연스러워집니다.

Q. Firebase Hosting은 동적 기능을 아예 못 쓰나요?
아닙니다. Functions나 Cloud Run과 연결해서 동적 콘텐츠나 API를 붙일 수 있습니다. 다만 기본 성격은 정적 콘텐츠 CDN 배포라는 점을 먼저 이해하는 것이 중요합니다.

Q. App Hosting은 어떤 경우에 특히 검토할 가치가 큰가요?
GitHub 연동 자동 배포가 필요하고, Next.js 같은 프레임워크의 서버 렌더링 기능을 자연스럽게 살리고 싶으며, 빌드와 런타임 운영 구성을 Firebase 쪽에서 비교적 일관되게 관리하고 싶을 때 검토 가치가 큽니다.

dist, out, 서버 빌드 결과를 같은 폴더로 취급하지 않기

프로젝트	실제 산출물	설정 판단
Vite SPA	기본 dist/index.html 및 자산	firebase.json public을 dist로, 클라이언트 라우팅에만 SPA fallback
Next.js 정적 export	기본 out 아래 경로별 HTML	public을 out로, 생성된 페이지 경로와 trailingSlash를 대조
요청마다 쿠키·서버 API를 쓰는 Next.js	서버 런타임을 포함한 빌드	정적 폴더만 업로드하지 않고 App Hosting 등 서버 지원 배포

이 글의 next.config.mjs에 있는 output: export와 firebase.json의 public: dist는 같은 앱에 동시에 적용하는 한 세트가 아닙니다. dist 예제는 Vite SPA용입니다. Next.js 정적 export를 선택했다면 out이 생성되는지부터 확인하고, index.html로 모든 요청을 돌리는 SPA 규칙을 무조건 붙이지 않습니다. export의 /about 페이지는 빌드된 HTML 파일로 제공될 수 있기 때문입니다.

예를 들어 회사 소개·문서처럼 모든 페이지를 빌드 시 만들 수 있는 사이트는 정적 export 후보입니다. 요청 쿠키를 읽어 개인 주문을 서버에서 렌더링하는 페이지는 서버가 필요합니다. 인증을 브라우저에서만 한다면 정적 호스팅도 가능하지만, 그 경우 데이터 접근 권한은 API·보안 규칙에서 강제해야 합니다. 로그인 기능의 유무만으로 SSR 필요 여부를 결정하지 마세요.

선택을 검증하려면 빌드 뒤 출력 폴더에 index와 실제 하위 페이지 파일이 있는지 보고, 로컬 미리보기에서 /about을 주소창으로 직접 열어 봅니다. 홈은 200인데 하위 경로만 404라면 산출물과 라우팅 규칙을 비교합니다. 모든 경로가 홈 화면으로 바뀌면 무조건 fallback을 적용한 것은 아닌지 확인합니다. API 주소가 HTML을 반환하면 Content-Type과 응답 본문도 확인하세요.

App Hosting의 apphosting.yaml은 저장소 루트의 서버 실행·환경 설정을 설명합니다. 본문의 example.com API는 실제 서비스가 아닌 자리표시자이므로 해당 fetch 예제를 실행하려면 본인 API와 응답 스키마가 필요합니다. 여기서는 클라우드 빌드·과금·SSR 배포를 실행하지 않았습니다. 기능·지원 버전·비용은 연결 직전 공식 문서를 확인하고, 실패가 이미 발생했다면 오류 허브에서 빌드/런타임/라우팅을 구분합니다.

공식 문서 확인일: 2026-09-13. nextjs.org 공식 자료 1 · firebase.google.com 공식 자료 2 · firebase.google.com 공식 자료 3

관련 글을 대표 허브 기준으로 이어서 보기

이 글과 비슷한 문제는 프론트엔드 배포 오류 체크리스트에서 전체 흐름을 먼저 확인하면 검색 의도와 해결 순서를 더 분명하게 나눌 수 있습니다.

• 대표 허브: 프론트엔드 배포 오류 체크리스트
• 프론트엔드 배포 로드맵
• Vercel Next.js 배포 실패 체크리스트
• Vercel 404 NOT_FOUND 오류 해결
• Next.js 환경변수 적용 오류 해결
• Vite import.meta.env undefined 해결