외부 호스팅 배포

Next.js 애플리케이션의 공식적인 권장 배포 플랫폼은 Vercel입니다.

Vercel은 Next.js 개발팀에서 직접 만들었기 때문에 가장 최적화된 성능과 기능을 제공합니다.

하지만 특정 요구사항이나 기존 인프라와의 통합을 위해 다른 호스팅 플랫폼에 Next.js 앱을 배포해야 하는 경우도 있습니다.

이 절에서는 Next.js 애플리케이션을 Vercel 외의 다른 인기 있는 호스팅 플랫폼에 배포하는 주요 방법과 각 플랫폼의 특징 및 고려사항에 대해 알아보겠습니다.

먼저 플랫폼 이름이 아니라 기능 지원 범위와 운영 부담을 기준으로 선택 흐름을 봅니다.

다양한 호스팅 옵션

먼저 호스팅 유형마다 SSR, Route Handler, 이미지 최적화, 정적 export 지원 범위가 어떻게 달라지는지 비교합니다.

Next.js는 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), Route Handler를 통한 서버 함수 등 다양한 실행 방식을 지원합니다.

따라서 선택하는 호스팅 플랫폼은 이러한 Next.js의 기능을 얼마나 잘 지원하는지에 따라 달라집니다.

주요 호스팅 플랫폼 유형

• 서버리스 플랫폼: 서버리스 함수 형태로 Next.js 기능 일부를 관리형으로 제공합니다. Netlify와 AWS Amplify처럼 플랫폼·Next.js 버전마다 지원 범위가 다르므로 공식 호환표를 먼저 확인합니다.
• Node.js 호스팅 플랫폼: 전통적인 Node.js 서버 환경을 제공하여 next start 명령어를 직접 실행합니다. (예: AWS EC2, Google Cloud Run, Azure App Service, Heroku, DigitalOcean Droplets)
• 정적 웹사이트 호스팅: SSG로 빌드된 정적 파일만 호스팅하는 경우. (예: GitHub Pages, Netlify, AWS S3 + CloudFront)

플랫폼을 고를 때는 지원 기능뿐 아니라 CI/CD 편의성, 운영 부담, 비용 구조를 함께 비교해야 합니다.

Netlify에 배포하기

Netlify는 Vercel과 유사한 기능을 제공하는 인기 있는 서버리스 기반 배포 플랫폼입니다.

CI/CD 통합, 글로벌 CDN, 자동 SSL 등이 강점입니다.

Netlify CLI 설치 및 프로젝트 설정

npm install -g netlify-cli
# 또는
yarn global add netlify-cli

프로젝트 루트에서 Netlify에 로그인하고 프로젝트를 초기화합니다.

netlify login
netlify init

netlify init 명령은 Netlify 프로젝트를 설정하고, netlify.toml 파일을 생성하여 빌드 설정, 배포 설정 등을 정의할 수 있도록 돕습니다.

Git 연동과 자동 감지

Netlify는 Next.js 13.5 이상을 OpenNext 기반 어댑터로 자동 감지합니다.

일반적인 프로젝트는 Git 저장소를 연결하고 빌드 명령을 npm run build로 두면 SSR, Route Handler, 이미지 최적화에 필요한 런타임을 함께 구성합니다.

.next나 .next/standalone을 publish 디렉터리로 직접 지정하거나 @netlify/plugin-nextjs를 수동 고정하지 않습니다.

모노레포의 기본 디렉터리나 별도 빌드 명령이 필요할 때만 netlify.toml에 해당 값을 추가합니다.

[build]
  base = "apps/web"
  command = "npm run build"

배포하기

Netlify 대시보드를 통해 Git 리포지토리를 연동하여 자동 배포를 설정하거나, CLI를 통해 수동으로 배포할 수 있습니다.

npm run build # 로컬에서 Next.js 빌드
netlify deploy --prod # 프로덕션 환경으로 배포 (이전에 netlify init으로 프로젝트 연결 필요)

AWS에 배포하기 (Amplify 또는 EC2)

AWS는 다양한 배포 서비스를 제공하며, Next.js 애플리케이션의 규모와 복잡성에 따라 선택지가 달라집니다.

AWS Amplify (지원 범위를 확인하는 관리형 배포)

AWS Amplify는 프론트엔드 웹 및 모바일 앱을 위한 통합 개발 플랫폼입니다.

Next.js 앱을 쉽게 호스팅하고, 백엔드 서비스(인증, API, 데이터베이스 등)를 통합할 수 있습니다.

다만 관리형 SSR 지원 버전과 기능 범위가 Next.js 최신 버전을 즉시 따라가지는 않습니다.

현재 AWS 공식 지원표는 관리형 Next.js 지원을 11부터 15까지로 안내하므로, 이 교재의 Next.js 16 프로젝트는 호환된다고 가정하지 말고 배포 전에 지원표를 다시 확인해야 합니다.

Next.js 16 관리형 SSR 지원이 확인되기 전에는 이 절의 콘솔 절차를 그대로 적용하지 않고, EC2·컨테이너 같은 자체 Node.js 호스팅이나 아래의 정적 export를 선택합니다.

장점: 지원되는 버전과 기능 범위 안에서는 Git 기반 배포와 AWS 백엔드 통합을 한곳에서 관리하기 쉽습니다.

간편한 CI/CD 파이프라인을 제공합니다.

단점: AWS 문서가 부르는 Edge API Routes(Edge runtime Route Handler)·Edge middleware(현재 Proxy 계층에 해당), 온디맨드 ISR, 스트리밍 등 공식 미지원 기능이 있으며, 버전 호환성과 비용을 함께 관리해야 합니다.

AWS EC2 (Traditional Server Hosting)

EC2(Elastic Compute Cloud)는 가상 서버(인스턴스)를 프로비저닝하여 직접 Node.js 서버를 실행하는 방식입니다.

Next.js의 모든 기능을 완벽하게 제어할 수 있지만, 인프라 관리 부담이 큽니다.

장점: 완벽한 제어권, 유연한 인프라 구성, 복잡한 커스텀 설정 가능.

단점: 인프라 설정 및 관리 부담이 큼, 높은 운영 지식 요구, 비용 관리의 복잡성.

Heroku에 배포하기

Heroku는 클라우드 플랫폼으로서 애플리케이션 배포를 간소화하는 PaaS(Platform as a Service)입니다.

Next.js 앱을 쉽게 배포할 수 있습니다.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start -p $PORT"
  }
}

# Procfile (프로젝트 루트에 생성)
web: npm run start

git add .
git commit -m "Initial Heroku deploy"
git push heroku main # 또는 master

장점: 매우 간편한 배포, 관리형 서비스.

단점: 과거의 상시 무료 dyno는 종료되었으며 Eco나 Basic 등 현재 유료 실행 계획과 데이터 서비스 비용을 함께 계산해야 합니다.

Vercel 전용 기능과 동일한 이미지 최적화 구성을 자동 제공하지는 않으므로 운영 방식을 직접 정해야 합니다.

정적 웹사이트 호스팅 (SSG 전용)

Next.js의 output: 'export' 설정과 next build를 사용해 HTML, CSS, JavaScript 파일만 내보내 배포하는 경우입니다.

이 경우 요청 시 SSR, Server Action, 동적 Route Handler처럼 서버 실행이 필요한 기능은 사용할 수 없습니다.

빌드 때 결과를 확정할 수 있는 GET Route Handler는 정적 파일로 내보낼 수 있습니다.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  output: 'export', // 정적 HTML 파일로 내보내기
  trailingSlash: true, // /about/index.html 형태로 내보내기
  images: { unoptimized: true }, // 기본 이미지 최적화 서버를 사용하지 않음
};

export default nextConfig;

장점: 매우 빠르고 저렴하며, 높은 확장성을 가집니다.

단점: 요청 시 SSR, Server Action, 동적 Route Handler, 기본 next/image 최적화 서버 등 Next.js의 서버 실행 기능은 사용할 수 없습니다.

환경 변수 및 보안 고려사항

다른 호스팅 플랫폼에 배포할 때도 환경 변수 관리는 매우 중요합니다.

• 플랫폼별 환경 변수 설정: 각 호스팅 플랫폼은 환경 변수를 설정하는 고유한 방법을 제공합니다 (예: AWS Systems Manager Parameter Store, Heroku Config Vars, Netlify 환경 변수 설정). 해당 플랫폼의 문서를 참조하여 설정해야 합니다.
• 빌드 시간 vs. 런타임: NEXT_PUBLIC_ 접두사가 붙은 값은 빌드할 때 클라이언트 번들에 인라인되어 이후 변경해도 기존 빌드에는 반영되지 않습니다. 접두사가 없는 서버 전용 값은 동적으로 렌더링하는 서버 코드에서 런타임에 읽을 수 있으므로 플랫폼의 런타임 환경 변수 기능으로 관리합니다. 정적 export에는 런타임 서버가 없다는 점도 구분합니다.
• 보안: 민감한 정보는 절대로 클라이언트 번들에 노출되지 않도록 NEXT_PUBLIC_ 접두사에 유의하고, 각 플랫폼의 보안 가이드라인을 따릅니다.

Vercel은 Next.js에 최적화된 가장 간편한 배포 경험을 제공하지만, 상황에 따라 다른 플랫폼이 더 적합할 수 있습니다.

각 플랫폼의 장단점과 Next.js 기능 지원 여부를 신중하게 고려하여 최적의 배포 전략을 선택해야 합니다.

Vercel 외 플랫폼을 고를 때는 SSR 지원, 이미지 최적화, 서버리스 함수, 환경 변수, 운영 비용을 같은 기준으로 비교해야 합니다.

아래 다이어그램은 AWS Amplify, EC2, Heroku, 정적 호스팅이 Next.js 기능 지원 범위에서 어떻게 갈리는지 보여줍니다.