• Firebase Hosting과 App Hosting을 먼저 어떻게 구분할까
• Firebase Hosting의 특징과 잘 맞는 프로젝트
• Firebase App Hosting의 특징과 잘 맞는 프로젝트
• 실무에서는 어떤 기준으로 선택하면 좋을까
• 정리
• FAQ

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

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

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

// Next.js 결과물을 정적 파일로 내보내도록 설정합니다.
const nextConfig = {
  // SSR 대신 정적으로 빌드된 파일을 생성합니다.
  output: 'export',
  images: {
    // Next Image 최적화 서버를 사용하지 않고 원본 이미지를 그대로 처리합니다.
    unoptimized: true,
  },
};

// 설정 객체를 기본 내보내기로 전달합니다.
export default nextConfig;

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

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

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

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

{
  // Firebase Hosting 설정 시작
  "hosting": {
    // 배포할 정적 파일 폴더입니다.
    "public": "dist",
    // 배포 대상에서 제외할 파일과 폴더입니다.
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    // SPA 라우팅을 위해 모든 요청을 index.html로 보냅니다.
    "rewrites": [
      {
        // 어떤 경로로 접속해도
        "source": "**",
        // index.html을 응답하도록 설정합니다.
        "destination": "/index.html"
      }
    ]
  }
}

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

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

# 앱 실행 환경의 인스턴스 동작 방식을 설정합니다.
runConfig:
  # 유휴 상태일 때 유지할 최소 인스턴스 수입니다.
  minInstances: 0
  # 동시에 늘어날 수 있는 최대 인스턴스 수입니다.
  maxInstances: 10
  # 한 인스턴스가 동시에 처리할 수 있는 요청 수입니다.
  concurrency: 80

# 런타임에서 사용할 환경 변수를 정의합니다.
env:
  - variable: NEXT_PUBLIC_API_BASE_URL
    # 클라이언트와 서버에서 참조할 기본 API 주소입니다.
    value: https://example.com

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

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

export default async function Page() {
  // 요청 시점마다 최신 데이터를 가져오도록 API를 호출합니다.
  const res = await fetch('https://api.example.com/posts', {
    // 정적 캐시를 사용하지 않고 항상 새로 가져오게 설정합니다.
    cache: 'no-store',
  });

  // 응답 본문을 JSON으로 변환합니다.
  const posts = await res.json();

  // 화면에서 사용할 수 있도록 필요한 필드만 추려 반환합니다.
  return posts.map((post: { id: number; title: string }) => ({
    // 게시글 고유 번호입니다.
    id: post.id,
    // 게시글 제목입니다.
    title: post.title,
  }));
}

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

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

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

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

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