OpenNext: Vercel 없이 Next.js 자체 호스팅

2024년 초, Next.js를 프로덕션에서 실행한 지 거의 5년이 되었습니다. 그 대부분의 시간 동안 Vercel은 명백한 선택이었습니다 — 배포하고, 잊고, 계속 진행합니다. 하지만 2024년쯤 되어서, 송장들이 자동차 할부금처럼 보이기 시작했습니다. 마케팅 사이트의 호스팅 비용이 실제 클라우드 인프라 비용을 초과할 때, 뭔가 잘못된 것입니다. 그때 저는 OpenNext를 파고들기 시작했고, 지난 1년 동안 Vercel에서 세 개의 프로덕션 앱을 마이그레이션한 후, 저는 의견을 가지고 있습니다.

이것은 "Vercel 나쁨" 기사가 아닙니다. Vercel은 정말 훌륭합니다. 하지만 더 이상 유일한 선택지가 아니며, 많은 팀에게는 올바른 선택이 아닙니다. OpenNext를 통한 Next.js 자체 호스팅에 대해 학습한 모든 것을 안내해 드리겠습니다 — 좋은 것, 못생긴 것, 그리고 놀랍도록 저렴한 것.

OpenNext란 무엇이며 왜 존재하는가
2025-2026년 자체 호스팅 환경
배포 대상: SST를 통한 AWS
배포 대상: Cloudflare Workers
배포 대상: Docker를 사용한 VPS
비용 비교: Vercel vs 자체 호스팅
Vercel을 떠나야 할 때
마이그레이션 플레이북
일반적인 함정 및 피하는 방법
FAQ

OpenNext: Vercel 없이 AWS, Cloudflare 또는 VPS에서 Next.js 자체 호스팅

OpenNext란 무엇이며 왜 존재하는가

Next.js는 Vercel에서 실행되도록 설계되었습니다. 이것은 음모가 아닙니다 — 아키텍처입니다. ISR (Incremental Static Regeneration), 미들웨어, 이미지 최적화, 서버 액션과 같은 기능들 모두 Vercel 관련 구현이 구워져 있습니다. 무작위 서버에서 next start를 시도하면 Next.js가 할 수 있는 것의 일부만 얻게 됩니다.

OpenNext는 오픈소스 어댑터로, Next.js 빌드 출력을 다른 플랫폼에서 작동하는 배포 패키지로 변환합니다. 이것은 AWS Lambda에 초점을 맞춘 SST 커뮤니티 프로젝트로 시작했지만, v3 (2025년 현재의 주요 버전) 기준으로, Cloudflare Workers, 전통적인 Node.js 서버 등을 포함한 여러 배포 대상을 지원합니다.

다음은 OpenNext가 실제로 처리하는 것입니다:

ISR 및 재검증 — Vercel이 내부 인프라로 구현하는 태그 기반 재검증 시스템? OpenNext는 AWS에서 DynamoDB + SQS를 사용하거나 Cloudflare의 KV 저장소를 사용하여 이를 재현합니다.
이미지 최적화 — Next.js의 <Image> 컴포넌트는 최적화 API에 의존합니다. OpenNext는 Sharp 기반 옵티마이저를 패키징하거나 플랫폼별 솔루션으로 라우팅합니다.
미들웨어 — Vercel에서는 엣지에서 실행됩니다. OpenNext는 이것을 CloudFront Functions, Cloudflare Workers로 매핑하거나 VPS에서 인프로세스로 실행합니다.
서버 액션 — 완전한 지원, 적절한 서버 함수를 통해 라우팅됩니다.
스트리밍 및 부분 사전 렌더링 — OpenNext v3.x에서 지원이 크게 향상되었습니다.

OpenNext가 아닌 것

이것은 호스팅 플랫폼이 아닙니다. CDN도 아닙니다. 빌드 어댑터입니다 — Next.js의 출력과 인프라 간의 번역 계층입니다. 여전히 실제로 어딘가에 코드를 실행해야 합니다.

2025-2026년 자체 호스팅 환경

에코시스템이 처음 살펴본 이후로 폭발했습니다. 현재 상황은 다음과 같습니다:

플랫폼	OpenNext 지원	성숙도	최적의 대상
AWS (SST 경유)	최고 지원	프로덕션 준비 완료	이미 AWS를 사용하는 팀
Cloudflare Workers	공식 어댑터	안정적 (일부 엣지 케이스)	엣지 우선 앱, 비용 최적화
Docker/VPS	커뮤니티 + 공식	안정적	간단한 배포, 기존 인프라
Kubernetes	커뮤니티 Helm 차트	성숙 중	엔터프라이즈, 기존 K8s 클러스터
Netlify	내장 (고유 어댑터)	프로덕션 준비 완료	Netlify 전념 팀
Google Cloud Run	커뮤니티	실험적	GCP 상점

개인적으로 실전에서 테스트했고 보증할 수 있는 두 가지 경로는 SST를 통한 AWS와 VPS의 Docker입니다. Cloudflare는 매월 개선되고 있는 흥미로운 신참입니다.

배포 대상: SST를 통한 AWS

이것이 황금 경로입니다. SST (Serverless Stack)는 OpenNext로 구동되는 내장된 Next.js 지원을 갖추고 있으며, 대부분의 엔지니어링 노력이 여기에 투입되었습니다.

아키텍처 개요

SST를 통해 AWS에 Next.js를 배포할 때, 다음이 생성됩니다:

CloudFront 배포 — CDN, 정적 자산 및 라우팅 처리
Lambda 함수 — 서버측 렌더링, API 경로, 서버 액션
S3 버킷 — 정적 자산, 사전 렌더링된 페이지, ISR 캐시
DynamoDB 테이블 — ISR 태그 매핑 재검증용
SQS 큐 — 비동기 재검증 처리
CloudFront Function 또는 Lambda@Edge — 미들웨어 실행

많이 들립니다. 맞습니다. 하지만 SST는 이 모든 것을 약 20줄의 구성으로 추상화합니다.

SST 구성

다음은 내 프로덕션 프로젝트 중 하나의 실제 sst.config.ts입니다:

/// <reference path="./.sst/platform/config.d.ts" />

export default $config({
  app(input) {
    return {
      name: "my-nextjs-app",
      removal: input.stage === "production" ? "retain" : "remove",
      home: "aws",
      providers: {
        aws: {
          region: "us-east-1",
        },
      },
    };
  },
  async run() {
    const site = new sst.aws.Nextjs("Site", {
      domain: {
        name: "myapp.com",
        dns: sst.aws.dns(),
      },
      warm: 5, // 5개의 Lambda 인스턴스 활성 유지
      memory: "1024 MB",
      environment: {
        DATABASE_URL: process.env.DATABASE_URL!,
        NEXT_PUBLIC_API_URL: "https://api.myapp.com",
      },
    });

    return {
      url: site.url,
    };
  },
});

그런 다음 배포합니다:

npx sst deploy --stage production

첫 배포는 8-12분 소요 (CloudFront 배포 전파). 후속 배포는 2-4분입니다.

Lambda 고려사항

Lambda 기반 호스팅의 가장 큰 함정은 콜드 스타트입니다. Next.js 서버 함수는 작지 않습니다 — 종속성에 따라 20-80MB 번들을 보고 있습니다. 콜드 스타트는 800ms에서 3초 범위입니다.

제가 사용한 완화 방법:

프로비저닝된 동시성 — SST의 warm 파라미터는 인스턴스를 활성 상태로 유지합니다. 1GB 함수 5개를 따뜻하게 유지하는 것은 GB초당 $0.0000041667로 월 약 $15입니다.
더 작은 번들 — 서버측 종속성을 감사하세요. 저는 서버측에서 전체 lodash를 임포트하는 프로젝트를 찾았는데 lodash/get만 필요했습니다. 번들이 68MB에서 31MB로 떨어졌습니다.
지역별 배포 — 절대 필요하지 않으면 Lambda@Edge를 SSR에 사용하지 마세요. CloudFront 캐싱을 통한 단일 지역 Lambda는 95%의 앱에 적합합니다.

OpenNext: Vercel 없이 AWS, Cloudflare 또는 VPS에서 Next.js 자체 호스팅 - 아키텍처

배포 대상: Cloudflare Workers

Cloudflare는 심각한 움직임을 보이고 있습니다. 이들의 Workers 런타임은 이제 Next.js가 실제로 거기서 실행될 수 있을 만큼 충분한 Node.js API를 지원하며, OpenNext Cloudflare 어댑터는 매우 안정적으로 되었습니다.

OpenNext Cloudflare로 설정

npm install @opennext/cloudflare

wrangler.toml에 추가합니다:

name = "my-nextjs-app"
main = ".open-next/worker.js"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat_v2"]

[assets]
directory = ".open-next/assets"
binding = "ASSETS"

[[kv_namespaces]]
binding = "NEXT_CACHE_KV"
id = "your-kv-namespace-id"

빌드 및 배포:

npx @opennext/cloudflare build
npx wrangler deploy

Cloudflare 트레이드오프

장점:

콜드 스타트 없음 — Workers는 5ms 이내에 전역적으로 스핀업됩니다
기본적으로 글로벌 엣지 — SSR이 300개 이상의 위치에서 실행됩니다
황당한 가격 — 유료 플랜에서 1000만 요청에 $5/월

단점:

메모리 제한 — 무료로 128MB, 유료로 256MB. 큰 Next.js 앱이 이를 초과할 수 있습니다.
CPU 시간 제한 — 유료 플랜에서 30초. 무거운 SSR 페이지는 문제가 될 수 있습니다.
Node.js 호환성 격차 — 대부분의 것이 작동하지만, sharp와 같은 네이티브 Node 모듈을 직접 사용하는 경우 해결 방법이 필요합니다. Cloudflare Images가 대신 최적화를 처리할 수 있습니다.
일부 Next.js 기능이 지원되지 않음 — 2025년 초 현재, Cloudflare의 부분 사전 렌더링 지원은 여전히 실험적입니다.

콘텐츠가 풍부한 사이트 및 마케팅 페이지의 경우, Cloudflare Workers는 매우 흥미롭습니다. 무거운 서버측 논리가 있는 복잡한 웹 앱의 경우, 여전히 AWS 또는 Docker로 기울어집니다.

배포 대상: Docker를 사용한 VPS

때때로 당신은 그냥 서버를 원합니다. Lambda 함수 없음, 엣지 런타임 없음, 47개 서비스 아키텍처 다이어그램 없음. 코드를 실행하는 상자. 존경합니다.

Dockerfile

다음은 내가 사용하는 프로덕션 Dockerfile입니다. 멀티 스테이지, 최적화되어 있으며, 실제로 작동합니다:

# 스테이지 1: 종속성
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable pnpm && pnpm install --frozen-lockfile

# 스테이지 2: 빌드
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_TELEMETRY_DISABLED=1
ENV NODE_ENV=production

RUN corepack enable pnpm && pnpm build

# 스테이지 3: 프로덕션
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

CMD ["node", "server.js"]

중요: next.config.js에 output: 'standalone'이 필요합니다:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

VPS 권장사항

이 설정을 여러 공급자에서 실행했습니다:

공급자	사양	월 비용	참고
Hetzner CAX21	4 vCPU ARM, 8GB RAM	€7.49 (~$8)	최고 가치, EU 데이터 센터
DigitalOcean Droplet	2 vCPU, 4GB RAM	$24	좋은 US 커버리지
Fly.io (machine)	2 vCPU, 4GB RAM	~$30	자동 스케일링, 글로벌 지역
Railway	사용량 기반	$5-50	가장 쉬운 설정, Vercel과 유사한 DX
AWS EC2 t4g.medium	2 vCPU, 4GB RAM	~$25	이미 AWS에 있음

간단한 Docker 배포의 경우, Hetzner는 터무니없이 좋은 가치입니다. 저는 Cloudflare의 무료 CDN 계층 뒤에 월 2백만 이상의 페이뷰를 제공하는 Next.js 앱을 €7.49 Hetzner ARM 인스턴스에서 실행합니다. 서버는 거의 땀도 흘리지 않습니다.

Docker/VPS로 잃는 것

Vercel 또는 SST 설정과 비교하여 VPS에서 next start가 제공하지 않는 것에 대해 솔직합시다:

ISR 재검증은 기본 — 파일 시스템 캐시만. 여러 인스턴스 간 분산 캐시 없음. 단일 서버를 실행 중인 경우, 이것은 정상입니다. 다중 서버? Redis 또는 공유 캐시 계층이 필요합니다.
엣지 미들웨어 없음 — 미들웨어는 인프로세스에서 실행되며, 이것은 대부분의 사용 사례에 완전히 문제없습니다.
이미지 최적화 — Sharp를 통해 작동하지만, 단일 원점에서 최적화된 이미지를 제공합니다. 앞에 Cloudflare 또는 CDN을 배치하세요.
원자성 배포 없음 — 무중단 배포를 직접 처리해야 합니다 (헬스 체크가 있는 Docker Compose, 또는 Caddy/Traefik와 같은 역프록시).

Social Animal의 대부분의 앱, 특히 우리의 headless CMS development 작업을 통해 수행하는 헤드리스 CMS 빌드의 경우, 앞에 CDN이 있는 단일 VPS는 완벽하게 적절합니다.

비용 비교: Vercel vs 자체 호스팅

돈에 대해 이야기합시다. 이것은 ISR, 이미지 최적화, 그리고 중간 정도의 서버측 렌더링을 하는 약 5백만 요청/월을 수행하는 Next.js 앱의 실제 청구 데이터를 기반으로 합니다.

비용 요소	Vercel Pro	Vercel Enterprise	AWS/SST	Cloudflare	Hetzner VPS
기본 플랫폼	$20/사용자/월	사용자 정의 (~$3k+/월)	$0	$5/월	€7.49/월
컴퓨팅/요청	$150-400/월	포함됨	$40-80/월	$0-15/월	포함됨
대역폭 (100GB)	포함됨	포함됨	$8.50 (CloudFront)	포함됨	포함됨
이미지 최적화	$50-200/월	포함됨	$5-15/월 (Lambda)	$5/월 (CF Images)	포함됨 (Sharp)
ISR/캐시	포함됨	포함됨	$2-5/월 (DynamoDB)	$0-5/월 (KV)	$0
예상 총합	$300-700/월	$3,000+/월	$55-110/월	$10-25/월	$8-15/월

Vercel 수치는 가정이 아닙니다. 송장을 봤습니다. Pro 계층의 사용자당 가격 책정, 함수 실행 초과량 및 대역폭 요금은 5명 이상의 팀에 대해 빠르게 증가합니다.

AWS/SST 수치는 프로비저닝된 동시성을 가진 중간 정도의 트래픽을 가정합니다. Cloudflare의 가격 책정은 진정으로 엉뚱합니다 — 뭔가 이국적인 것을 하지 않는 한 거기에 실제 돈을 쓰기 어렵습니다.

Vercel을 떠나야 할 때

할 수 있다고 해서 떠나지 마세요. 해야 한다고 해서 떠나세요. 제 프레임워크는 다음과 같습니다:

Vercel에 머물러야 할 경우:

팀이 작습니다 (1-3명 개발자) 그리고 개발자 시간이 가장 비싼 리소스입니다
Vercel에서 월 $100 이하를 지출하고 있습니다
인프라 작업을 즐기는 사람이 없습니다
빠르게 반복하고 있으며 모든 PR에 대한 즉시 미리보기가 필요합니다
Analytics, Speed Insights 또는 Vercel AI SDK 통합과 같은 Vercel 관련 기능을 사용하고 있습니다

Vercel을 떠나야 할 경우:

월 청구가 $500을 초과하고 증가 중입니다
규정 준수를 위해 특정 지역의 인프라가 필요합니다 (GDPR, 데이터 상주)
이미 중요한 AWS/GCP/Cloudflare 인프라를 실행 중입니다
서버리스의 콜드 스타트가 사용 사례에 허용되지 않습니다
Vercel의 함수 크기 제한 또는 실행 시간 제한에 도달했습니다
Vercel의 모델에 맞지 않는 사용자 정의 캐싱 전략이 필요합니다

심각하게 고려해야 할 경우:

Vercel Enterprise 가격 책정을 사용 중이고 계약 갱신이 방금 도착했습니다
앱이 주로 정적/ISR이고 동적 SSR 가격을 지불하고 있습니다
프론트엔드를 같은 인프라의 백엔드와 함께 실행하고 싶습니다

마이그레이션 플레이북

저는 이것을 이제 3번 했습니다. 다음은 고통스러운 경험을 통해 정제한 프로세스입니다.

단계 1: Next.js 기능 감사

무엇이든 건드리기 전에, 실제로 사용하는 Next.js 기능을 카탈로그합니다:

# 미들웨어 찾기
find . -name "middleware.ts" -o -name "middleware.js"

# API 경로 찾기
find ./app -name "route.ts" -o -name "route.js" | head -20

# ISR 확인
grep -r "revalidate" ./app --include="*.ts" --include="*.tsx" | head -20

# 서버 액션 확인
grep -r "use server" ./app --include="*.ts" --include="*.tsx" | head -20

# 특수 기능의 next.config 확인
cat next.config.js

단계 2: 대상 선택

감사를 기반으로:

무거운 ISR + 미들웨어 + 이미지 최적화 → AWS/SST
간단한 SSR + 콘텐츠 사이트 → Cloudflare 또는 VPS
이미 Docker/K8s 인프라를 소유 중 → VPS/Docker
금요일까지 해야 함 → Railway 또는 Fly.io의 Docker

Next.js 또는 Astro를 빌드하는 경우, 대상 플랫폼 선택은 아키텍처 결정에 크게 영향을 미칩니다.

단계 3: CI/CD 설정

Vercel의 CI/CD는 정말 훌륭합니다. 그것을 놓칠 겁니다. GitHub Actions로 복제하세요:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm test

      # SST의 경우:
      - run: npx sst deploy --stage production
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      # Docker/VPS (대체):
      # - run: docker build -t myapp .
      # - run: docker push registry.example.com/myapp:latest
      # - run: ssh deploy@server 'cd /app && docker compose pull && docker compose up -d'

단계 4: 미리보기 배포

이것은 Vercel에서 사람들이 가장 놓치는 것입니다. SST의 경우, 스테이지를 사용합니다:

# PR CI 워크플로우에서
npx sst deploy --stage pr-${{ github.event.pull_request.number }}

Docker의 경우, Coolify (자체 호스팅) 또는 Railway와 같은 도구가 미리보기 배포를 잘 처리합니다.

단계 5: DNS 전환

실제 마이그레이션 순간. 항상 권장합니다:

Vercel과 나란히 새 인프라에 배포
스테이징 도메인으로 철저히 테스트
스테이징 1일 전에 DNS TTL을 60초로 낮춤
저트래픽 시간 중에 DNS 전환
48시간 동안 Vercel 배포를 폴백으로 실행
에러율, TTFB 및 Core Web Vitals를 밀접하게 모니터링

단계 6: Vercel 제거

확신하면 (최소 1주일 기다림), Vercel 구독을 취소하고 프로젝트를 제거합니다. 좀비 프로젝트를 요금이 청구되도록 두지 마세요.

일반적인 함정 및 피하는 방법

환경 변수가 사라집니다. Next.js에는 NEXT_PUBLIC_ 접두사 변수 (빌드 시 번들됨)와 서버만의 변수 (런타임에 사용 가능)가 있습니다. Vercel에서는 이 구분이 다소 흐릿합니다. 자체 호스팅에서는 엄격합니다. 모든 NEXT_PUBLIC_ 변수가 CI의 빌드 시에 사용 가능한지 확인하세요.

ISR 캐시가 유지되지 않습니다. Docker에서, .next/cache 디렉토리는 지속된 볼륨에 있어야 합니다. 그렇지 않으면 모든 컨테이너 재시작이 캐시된 페이지를 잃습니다:

# docker-compose.yml
services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - next-cache:/app/.next/cache

volumes:
  next-cache:

Sharp 설치 실패. sharp 이미지 최적화 라이브러리는 플랫폼별 바이너리가 필요합니다. Docker에서, 런타임과 동일한 아키텍처 내에 종속성을 설치하는지 확인하세요. 위의 Dockerfile은 동일한 기본 이미지를 사용하여 멀티 스테이지 빌드를 통해 이를 처리합니다.

미들웨어 동작 차이. Vercel은 엣지 네트워크에서 미들웨어를 실행합니다. AWS/SST에서는 CloudFront Function으로 실행됩니다 (10ms 실행, 2MB 크기로 제한됨). 복잡한 미들웨어는 서버 함수로 이동해야 할 수 있습니다. 이 제한 때문에 인증 미들웨어를 리팩토링해야 했습니다.

누락된 헤더 및 재쓰기. vercel.json을 헤더, 리디렉션 또는 재쓰기에 사용했다면, 이를 next.config.js 또는 CDN/역프록시 구성으로 이동해야 합니다.

이 모든 것이 압도적으로 느껴진다면, 이것이 정확히 Social Animal에서 처리하는 인프라 작업입니다. 가격을 확인하거나 연락하세요 — 우리는 이 마이그레이션을 충분히 많이 수행하여 정제된 프로세스를 가지고 있습니다.

FAQ

OpenNext는 2025년에 프로덕션 준비가 되어 있나요?

예. OpenNext v3.x는 수천 개 회사의 프로덕션 워크로드를 실행 중입니다. SST/AWS 경로는 가장 실전에서 테스트된 것으로, Cloudflare 지원이 바짝 뒤따릅니다. Google Cloud 또는 베어 Kubernetes 지원이 성숙하다고 하지는 않겠지만, AWS와 Cloudflare는 견고합니다.

OpenNext는 Next.js App Router 및 Server Components를 지원하나요?

완전한 지원. App Router, Server Components, Server Actions, 스트리밍 및 Suspense 모두 작동합니다. OpenNext 팀은 Next.js 릴리스를 밀접하게 추적하지만, 일반적으로 주요 Next.js 버전 이후 OpenNext가 따라잡기까지 1-3주의 지연이 있습니다.

Vercel을 떠남으로써 실제로 얼마나 절약할 수 있나요?

사용 패턴에 크게 달려 있습니다. 중간 정도의 트래픽 앱을 실행하는 5명 개발자 팀의 경우, 저는 팀이 Vercel Pro에서 월 $600-800에서 AWS/SST의 월 $30-80 또는 VPS에서 $20 미만으로 이동하는 것을 봤습니다. 절약은 실제이지만 추가 유지보수 부담도 실제입니다.

Vercel 없이도 ISR (Incremental Static Regeneration)을 사용할 수 있나요?

절대적으로. AWS/SST에서, ISR은 태그 캐시의 DynamoDB 및 비동기 재검증의 SQS를 사용합니다 — revalidateTag() 및 revalidatePath()를 통한 온디맨드 재검증을 포함하여 완전히 작동합니다. VPS에서, ISR은 파일 시스템 캐시로 작동하는데, 이것은 단일 서버 배포에 적합합니다.

Vercel의 미리보기 배포를 복제할 수 있나요?

80%의 경험을 얻을 수 있습니다. SST는 스테이지 기반 배포를 지원하므로, 각 PR은 자신의 스택을 얻을 수 있습니다. Coolify 및 유사 도구는 Docker 기반 설정에 대한 미리보기 배포를 제공합니다. Vercel의 시각적 주석 시스템과 배포 상태를 위한 긴밀한 GitHub 통합을 쉽게 복제할 수 없습니다. 대부분의 팀은 트레이드오프가 허용할 만하다고 생각합니다.

헤드리스 CMS 사이트에 Cloudflare 또는 AWS를 사용해야 하나요?

콘텐츠가 많은 헤드리스 CMS 사이트 (Sanity, Contentful, Storyblok)의 경우, Cloudflare Workers는 훌륭한 선택입니다. 이 사이트는 ISR이 무거운 경향이 있으며 상대적으로 가벼운 서버측 논리를 가집니다 — Cloudflare의 가격 책정 모델에 완벽합니다. Cloudflare가 아직 지원하지 않는 기능이 필요하거나 AWS 에코시스템에 깊이 있는 경우만 AWS로 이동합니다.

Next.js 자체 호스팅이 Astro 또는 Remix 자체 호스팅보다 어렵나요?

정직하게? 예. Next.js는 ISR, 미들웨어, 이미지 최적화 및 부분 사전 렌더링 기능 때문에 모든 프레임워크 중 가장 복잡한 빌드 출력을 가집니다. Astro와 Remix는 훨씬 더 간단한 배포 이야기를 가집니다. 새 프로젝트를 시작하고 있고 자체 호스팅이 우선순위라면, Astro를 고려하세요 — 호스팅이 훨씬 더 간단합니다. 하지만 이미 Next.js에 있다면, OpenNext는 마이그레이션을 실용적으로 만듭니다.

OpenNext가 유지보수 대상이 되지 않으면 어떻게 되나요?

OpenNext는 SST의 지원을 받으며 주요 후원자가 있는 활동적인 커뮤니티를 가지고 있습니다. 즉, 이것은 합법적인 오픈소스 종속성 문제입니다. 완화는 Docker/standalone 접근식 (next start)이 OpenNext 없이도 전혀 작동한다는 것입니다 — ISR 태그 재검증 및 엣지 미들웨어와 같은 더 고급 기능을 잃을 뿐입니다. 이것은 절벽이 아닌 우아한 성능 저하입니다.

OpenNext: AWS, Cloudflare, VPS에서 Vercel 없이 Next.js 자체 호스팅하기

목차

OpenNext란 무엇이며 왜 존재하는가

OpenNext가 아닌 것

2025-2026년 자체 호스팅 환경

배포 대상: SST를 통한 AWS

아키텍처 개요

SST 구성

Lambda 고려사항

배포 대상: Cloudflare Workers

OpenNext Cloudflare로 설정

Cloudflare 트레이드오프

배포 대상: Docker를 사용한 VPS

Dockerfile

VPS 권장사항

Docker/VPS로 잃는 것

비용 비교: Vercel vs 자체 호스팅

Vercel을 떠나야 할 때

마이그레이션 플레이북

단계 1: Next.js 기능 감사

단계 2: 대상 선택

단계 3: CI/CD 설정

단계 4: 미리보기 배포

단계 5: DNS 전환

단계 6: Vercel 제거

일반적인 함정 및 피하는 방법

FAQ

OpenNext는 2025년에 프로덕션 준비가 되어 있나요?

OpenNext는 Next.js App Router 및 Server Components를 지원하나요?

Vercel을 떠남으로써 실제로 얼마나 절약할 수 있나요?

Vercel 없이도 ISR (Incremental Static Regeneration)을 사용할 수 있나요?

Vercel의 미리보기 배포를 복제할 수 있나요?

헤드리스 CMS 사이트에 Cloudflare 또는 AWS를 사용해야 하나요?

Next.js 자체 호스팅이 Astro 또는 Remix 자체 호스팅보다 어렵나요?

OpenNext가 유지보수 대상이 되지 않으면 어떻게 되나요?

Let's build
something together.

목차

OpenNext란 무엇이며 왜 존재하는가

OpenNext가 아닌 것

2025-2026년 자체 호스팅 환경

배포 대상: SST를 통한 AWS

아키텍처 개요

SST 구성

Lambda 고려사항

배포 대상: Cloudflare Workers

OpenNext Cloudflare로 설정

Cloudflare 트레이드오프

배포 대상: Docker를 사용한 VPS

Dockerfile

VPS 권장사항

Docker/VPS로 잃는 것

비용 비교: Vercel vs 자체 호스팅

Vercel을 떠나야 할 때

마이그레이션 플레이북

단계 1: Next.js 기능 감사

단계 2: 대상 선택

단계 3: CI/CD 설정

단계 4: 미리보기 배포

단계 5: DNS 전환

단계 6: Vercel 제거

일반적인 함정 및 피하는 방법

FAQ

OpenNext는 2025년에 프로덕션 준비가 되어 있나요?

OpenNext는 Next.js App Router 및 Server Components를 지원하나요?

Vercel을 떠남으로써 실제로 얼마나 절약할 수 있나요?

Vercel 없이도 ISR (Incremental Static Regeneration)을 사용할 수 있나요?

Vercel의 미리보기 배포를 복제할 수 있나요?

헤드리스 CMS 사이트에 Cloudflare 또는 AWS를 사용해야 하나요?

Next.js 자체 호스팅이 Astro 또는 Remix 자체 호스팅보다 어렵나요?

OpenNext가 유지보수 대상이 되지 않으면 어떻게 되나요?

Let's build something together.

Let's build
something together.