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

플랫폼보다 산출물을 먼저 확인하기

같은 JavaScript 프로젝트라도 build 결과는 다를 수 있습니다.

Vite 기반 SPA는 일반적으로 다음과 같은 정적 파일을 만듭니다.

dist/
├─ index.html
├─ assets/
│  ├─ app.js
│  └─ app.css
└─ images/

이 경우 서버에서 JavaScript 코드를 매 요청마다 실행하지 않아도 됩니다.

반면 Next.js 프로젝트는 사용 기능에 따라 서버 실행이 필요할 수 있습니다.

Next.js
├─ 정적 자산
├─ 미리 생성된 페이지
└─ 요청 시 실행되는 서버 코드
   ├─ Route Handler
   ├─ Server Action
   └─ 동적 렌더링

따라서 “Next.js니까 무조건 정적 Hosting” 또는 “Firebase니까 App Hosting”처럼 이름만 보고 고르면 안 됩니다.

Firebase Hosting

Firebase Hosting은 정적 웹 자산과 SPA를 빠르게 제공하는 데 잘 맞는 관리형 호스팅입니다.

Firebase 공식 문서 기준으로 Hosting은 글로벌 CDN과 SSL을 제공하고, 커스텀 도메인을 연결할 수 있습니다. firebase.json을 통해 redirects, rewrites, headers, 캐시 관련 동작도 설정할 수 있습니다.

정적 Vite 앱이라면 보통 다음 흐름으로 이해할 수 있습니다.

npm run build
↓
dist 생성
↓
firebase.json public이 dist를 가리킴
↓
firebase deploy --only hosting
↓
CDN에서 정적 파일 제공

예시 설정은 다음과 같습니다.

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ]
  }
}

이 설정은 Vite 같은 정적 결과물을 예로 든 것입니다. 프로젝트의 실제 output 디렉터리를 확인한 뒤 지정해야 합니다.

Firebase App Hosting

App Hosting은 Next.js와 Angular 같은 풀스택 프레임워크 앱의 빌드와 실행 환경을 관리하는 방향으로 설계되어 있습니다.

GitHub 저장소와 연결해 rollout을 만들고, 빌드와 런타임 환경변수 및 Secret을 구성할 수 있습니다.

핵심 차이는 다음처럼 생각하면 됩니다.

Hosting
→ 만들어진 웹 자산을 제공

App Hosting
→ 프레임워크 앱을 빌드하고 필요한 서버 런타임까지 운영

App Hosting에서는 apphosting.yaml을 통해 일부 런타임 설정과 환경변수 구성을 관리할 수 있고, 민감한 값은 Secret Manager의 Secret을 참조하는 방식으로 분리할 수 있습니다.

Hosting과 App Hosting 선택 기준

중요한 것은 이 표를 절대적인 규칙으로 외우는 것이 아니라 현재 프로젝트가 실제로 어떤 런타임을 요구하는지 확인하는 것입니다.

Firebase Hosting도 Cloud Functions나 Cloud Run과 rewrite로 동적 백엔드에 연결할 수 있습니다. 따라서 “Hosting은 동적 기능을 전혀 못 한다”라고 설명하면 정확하지 않습니다.

다만 풀스택 프레임워크 자체를 운영하는 목적이라면 App Hosting이 제공하는 프레임워크 중심 흐름을 먼저 검토하는 편이 자연스럽습니다.

SPA rewrite와 SSR을 혼동하면 안 되는 이유

SPA에서는 사용자가 /tasks/123으로 직접 접근했을 때 서버에 실제 tasks/123.html 파일이 없을 수 있습니다.

이 경우 모든 경로를 index.html로 보내고 브라우저 라우터가 화면을 선택하게 할 수 있습니다.

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

하지만 Next.js SSR에서 모든 경로를 정적 index.html로 보내는 것은 같은 해결책이 아닙니다.

SPA rewrite
서버는 index.html 제공
→ 브라우저 라우터가 URL 처리

SSR
요청 URL에 맞춰 서버 런타임이 페이지 결과 생성

이 차이를 모르고 SPA용 rewrite를 Next.js 서버 앱에 그대로 적용하면 라우팅 구조를 오히려 망가뜨릴 수 있습니다.

환경변수도 배포 모델에 영향을 줍니다

정적 빌드에서 브라우저에 포함되는 공개 값과 서버 런타임에서만 읽어야 하는 Secret은 구분해야 합니다.

브라우저 공개 가능
NEXT_PUBLIC_API_BASE_URL

서버 전용
DATABASE_URL
API_SECRET
SERVICE_ACCOUNT_PRIVATE_KEY

클라이언트 번들에 포함되는 공개 환경변수에 서버 비밀값을 넣으면 안 됩니다.

흔한 실수

프레임워크 이름만 보고 호스팅을 선택합니다

프로젝트의 실제 build 결과와 서버 기능을 먼저 확인합니다.

Hosting rewrite를 SSR 대체 수단으로 생각합니다

SPA fallback과 서버 렌더링은 목적이 다릅니다.

public 디렉터리를 추측합니다

Vite라면 dist인 경우가 흔하지만 프로젝트 설정에 따라 다를 수 있습니다. 실제 build 결과를 확인합니다.

Emulator 성공을 Production 성공으로 봅니다

로컬 Hosting Emulator는 설정 검증에 유용하지만 실제 DNS, HTTPS, Production 환경변수까지 대신 검증하지는 않습니다.

학습 완료 체크리스트

• 정적 산출물과 서버 런타임의 차이를 설명할 수 있습니다.
• Firebase Hosting과 App Hosting의 주요 역할을 구분할 수 있습니다.
• SPA rewrite와 SSR을 구분할 수 있습니다.
• 현재 프로젝트의 build output을 먼저 확인할 수 있습니다.
• 서버 Secret을 브라우저 환경변수와 구분할 수 있습니다.

# TaskFlow Deployment Plan


## Build
- package manager: npm
- install: npm ci
- build: npm run build


## Primary deployment
- platform: Vercel
- environment: Production


## Alternative deployment
- Firebase Hosting: static output일 때 검토
- Firebase App Hosting: server runtime이 필요할 때 검토


## Verification
- Production URL 응답
- 주요 화면 확인
- 환경변수 확인
- 주요 route 확인
- 현재 commit 확인
- rollback 가능 여부 확인

## Runtime decision


- static-only: no
- server runtime required: yes
- reasons:
  - Route Handler
  - server-side environment variables


## Primary
Vercel Production


## Firebase alternative
App Hosting 우선 검토


## Static variant
정적 결과물로 분리할 경우 Firebase Hosting 검토

# TaskFlow Deployment Plan


## Build
- package manager: npm
- install: npm ci
- build: npm run build


## Primary deployment
- platform: Vercel
- environment: Production


## Alternative deployment
- Firebase Hosting: static output일 때 검토
- Firebase App Hosting: server runtime이 필요할 때 검토


## Verification
- Production URL 응답
- 주요 화면 확인
- 환경변수 확인
- 주요 route 확인
- 현재 commit 확인
- rollback 가능 여부 확인

## Runtime decision


- static-only: no
- server runtime required: yes
- reasons:
  - Route Handler
  - server-side environment variables


## Primary
Vercel Production


## Firebase alternative
App Hosting 우선 검토


## Static variant
정적 결과물로 분리할 경우 Firebase Hosting 검토

# 배포·서버 02 — deploy-step-02-artifact-strategy

이 ZIP은 배포 준비·운영 문서와 해당 회차 설정/코드 조각을 누적한 적용 자료입니다. 실행 앱 전체는 포함하지 않습니다. 기존 deploy-step-00-build-ready 프로젝트에 해당 파일을 검토하여 적용하세요. 이 ZIP 루트에서 npm ci/build를 실행하는 구조가 아닙니다.

이 자료에는 실제 배포·DNS 변경·SSH 접속·메일/알림·롤백 결과가 없습니다. 운영 작업은 독자가 본인 환경과 권한을 확인한 후 수행해야 합니다. 문서의 확인 항목은 수행할 체크리스트이며 이미 통과했다는 기록이 아닙니다.

deploy-step-01-roadmap

Server Component 사용 여부
Route Handler 사용 여부
Server Action 사용 여부
서버 전용 환경변수 사용 여부
요청 시 동적 렌더링 필요 여부

## Runtime decision

- static-only: no
- server runtime required: yes
- reasons:
  - Route Handler
  - server-side environment variables

## Primary
Vercel Production

## Firebase alternative
App Hosting 우선 검토

## Static variant
정적 결과물로 분리할 경우 Firebase Hosting 검토

deploy-step-02-artifact-strategy

다음 학습

다음 글에서는 관리형 플랫폼이 대신 처리해 주는 서버 접속과 파일 전송의 기본 개념을 SSH, SFTP, FTP를 통해 정리합니다.

다음 글: SSH SFTP FTP 차이: 서버 접속과 파일 전송 기준 잡기

다음 회차 확인 과제: 03회차에서 SSH·SFTP 역할을 선택 학습으로 확인한 뒤, 04회차의 관리형 Vercel 배포에는 01·02회차 판단 결과를 가져갑니다.

공식 문서

공식 문서 확인 기준: 2026-09-21

• https://firebase.google.com/docs/app-hosting/costs
• https://firebase.google.com/docs/hosting
• https://firebase.google.com/docs/hosting/quickstart
• https://firebase.google.com/docs/hosting/full-config
• https://firebase.google.com/docs/app-hosting
• https://firebase.google.com/docs/app-hosting/configure