외부 호스팅 배포

Vercel은 Next.js 개발사에서 운영하며 프레임워크 기능을 긴밀하게 통합한 배포 플랫폼입니다.

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

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

다양한 호스팅 옵션

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

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

Netlify·Amplify는 관리형 어댑터, EC2·Cloud Run·Heroku는 직접 Node.js 서버를 실행할 수 있는 환경, GitHub Pages·S3는 정적 호스팅의 예입니다. Netlify처럼 여러 방식을 제공하는 플랫폼도 있습니다.

요구 기능으로 호스팅 고르기 상품 목록이 빌드할 때 확정되고 로그인·서버 쓰기가 없는 사이트와, 요청 쿠키로 사용자마다 주문 목록을 보여 주고 Server Action으로 주문을 저장하는 사이트를 각각 배포하려고 합니다. 두 사이트를 같은 out 디렉터리 업로드 방식으로 처리할 수 있을까요? Next.js 16의 두 번째 사이트를 Amplify Hosting compute로 바로 옮겨도 될까요?

하위 경로를 점검하기 프로젝트 사이트의 접두사가 /repository-name이고 파일은 public/logo.png라면 문자열로 지정하는 이미지 주소는 무엇이어야 할까요? 같은 사이트에서 /about을 직접 열었을 때 404가 난다면 빌드 성공만으로 어떤 설정까지 확인했다고 할 수 있을까요?

지원 기능을 확인한 뒤 CI/CD 편의성과 비용 구조를 비교합니다.

Netlify에 배포하기

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

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

Netlify CLI 설치 및 프로젝트 설정

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

위의 Yarn 명령은 Yarn Classic의 전역 설치 문법입니다. 사용 중인 패키지 관리자에 맞는 설치 명령을 선택한 뒤 프로젝트 루트에서 Netlify에 로그인하고 초기화합니다.

netlify login
netlify init

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

Git 연동과 자동 감지

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

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

프레임워크가 제안하는 빌드·publish 설정을 우선 사용합니다. .next/standalone을 일반 정적 사이트처럼 업로드하거나 필요 없이 어댑터 버전을 수동 고정하지 않습니다.

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

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

배포하기

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

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

현재 Netlify CLI의 deploy는 기본적으로 Netlify 빌드를 실행합니다. 위 첫 명령은 별도의 로컬 Next.js 빌드 확인이며, 이어서 실행하면 빌드가 반복될 수 있습니다.

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

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

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

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

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

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

현재 AWS 공식 지원표는 Hosting compute의 Next.js 지원을 12부터 15까지로 안내합니다. 이전 Classic의 Next.js 11 지원과 구분하며, 이 교재의 Next.js 16 프로젝트는 호환된다고 가정하지 말고 배포 전에 지원표를 다시 확인합니다.

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

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

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

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

AWS EC2 (Traditional Server Hosting)

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

Node.js 서버의 설정과 배포를 직접 제어할 수 있지만, TLS·프로세스·캐시·확장 등 인프라 운영도 맡아야 합니다.

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

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

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_ 접두사에 유의하고, 각 플랫폼의 보안 가이드라인을 따릅니다.