meepin shield deploy entry
전체 개요
Next.js (SSR)
- dev, stage, prod 브랜치에 push
- Jenkins가 CI/CD 실행 (사내망에서 구동 중)
- Docker + Docker Compose로 컨테이너 빌드
- AWS EC2에 SSH 접속 → 컨테이너 실행 (SSR 서버)
React (SPA)
- dev, stage, prod 브랜치에 push
- Jenkins가 CI/CD 실행
- S3 + CloudFront에 업로드 및 캐시 무효화
Next.js 배포 상세
2.1 폴더 구조(예시)
next-project/ ┣ docker-compose.yml ┣ Dockerfile ┣ Jenkinsfile (옵션) ┣ .env.dev ┣ .env.stage ┣ .env.production ┣ package.json ┣ pages/ ┣ ... ┗ ...
• Dockerfile: Next.js 빌드 및 실행 방법 정의 • docker-compose.yml: Dockerfile을 이용해 컨테이너를 어떻게 실행할지, 포트나 볼륨 등을 정의 • .env.*: 환경별 ENV 파일 (dev, stage, production) • Jenkinsfile: (옵션) Jenkins 파이프라인 스크립트. 멀티브랜치 파이프라인이 아닌, 단일 파이프라인 Job일 경우 사용
실제로는 Jenkins에서 “스크립트”를 내부 설정으로 관리할 수도 있고, Git 레포에 Jenkinsfile을 두어도 됩니다.
2.2 Dockerfile 예시 (Next.js)
Dockerfile
-------------------------------------------------
1) Node.js 기반 이미지를 사용
FROM node:16
2) 작업 디렉토리 생성
WORKDIR /app
3) package.json, package-lock.json 복사
COPY package*.json ./
4) 의존성 설치
RUN npm install
5) ENV_FILE ARG: 빌드 시점에 .env.dev, .env.stage 등을 지정 가능
ARG ENV_FILE=.env.dev
6) 지정된 ENV_FILE을 .env로 복사
(주의: .env.* 파일들은 꼭 Docker 이미지 빌드 맥락에 포함되어야 함)
COPY ${ENV_FILE} .env
7) 소스 전체 복사
COPY . .
8) Next.js 빌드
RUN npm run build
9) 3000 포트 사용(SSR)
EXPOSE 3000
10) 서버 구동 명령
CMD ["npm", "run", "start"]
주석 설명 • FROM node:16 : Node.js 16 버전을 베이스 이미지를 사용한다는 의미 • WORKDIR /app : 컨테이너 내 작업 디렉토리를 /app으로 설정 • ENV_FILE ARG : 빌드 시 --build-arg ENV_FILE=.env.stage 등의 방식으로 다른 환경파일을 가져올 수 있음 • npm run build : Next.js를 빌드 (SSR용 .next 폴더 생성) • npm run start : 프로덕션 환경으로 서버 구동 (SSR)
2.3 docker-compose.yml 예시 (Next.js)
docker-compose.yml
-------------------------------------------------
version: '3.8'
services: nextapp: build: context: . dockerfile: Dockerfile args:
Jenkins나 CLI에서 override 가능
ENV_FILE: .env.dev container_name: nextapp ports:
- "3000:3000" restart: unless-stopped
주석 설명 • services.nextapp.build.context: . : 현재 디렉토리에서 Dockerfile을 탐색 • args.ENV_FILE: .env.dev : 디폴트로 dev 모드를 쓴다고 가정, Jenkins 등에서 docker-compose build --build-arg ENV_FILE=.env.stage로 재정의 가능 • ports: "3000:3000" : 호스트(EC2) 3000번 포트를 컨테이너 3000번 포트로 매핑 • restart: unless-stopped : 컨테이너가 예기치 못하게 중단되면 자동 재시작
2.4 Jenkins 파이프라인 (Next.js) 예시
// Jenkinsfile (Next.js 용 예시) // ------------------------------------------------- pipeline { agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Set Env') {
steps {
script {
if (env.BRANCH_NAME == 'dev') {
env.ENV_FILE = '.env.dev'
} else if (env.BRANCH_NAME == 'stage') {
env.ENV_FILE = '.env.stage'
} else {
env.ENV_FILE = '.env.production'
}
}
}
}
stage('Build Docker Image') {
steps {
script {
sh """
docker-compose build --build-arg ENV_FILE=${ENV_FILE}
"""
}
}
}
stage('Deploy to EC2') {
steps {
// SSH 플러그인이나 sshagent 플러그인을 사용한다 가정
sshagent(['EC2_SSH_CREDENTIALS']) {
sh """
ssh -o StrictHostKeyChecking=no ec2-user@<EC2_PUBLIC_IP> 'bash -s' << 'ENDSSH'
cd /home/ec2-user/next-project
git pull origin ${env.BRANCH_NAME} || true
# Docker-compose pull or re-build
docker-compose down || true
docker-compose up -d --build
ENDSSH
"""
}
}
}
}
}
주석 설명 • env.BRANCH_NAME: Jenkins 멀티브랜치 파이프라인에서 현재 빌드 중인 브랜치 이름 • docker-compose build --build-arg ENV_FILE=${ENV_FILE}: 브랜치별 다른 .env 파일 사용 • Deploy to EC2 단계에서 • EC2에 SSH 접속 후 • docker-compose down → docker-compose up -d --build로 컨테이너 재시작
실제로는 EC2에서 소스코드 pull 할지, 혹은 Jenkins가 Docker 이미지를 빌드·푸시(ECR) → EC2에서 docker pull 할지 전략을 결정해야 합니다.
- React (SPA) 배포 상세
3.1 폴더 구조(예시)
react-admin/ ┣ Jenkinsfile (옵션) ┣ .env.dev ┣ .env.stage ┣ .env.production ┣ package.json ┣ src/ ┣ public/ ┗ ...
S3 + CloudFront 배포 시에는 “정적 빌드 결과”만 S3에 올리면 되므로, Docker를 굳이 사용하지 않아도 됩니다. (단, 빌드 환경 표준화를 위해 Dockerfile을 사용해도 됨.)
3.2 Jenkins 파이프라인 (React) 예시
// Jenkinsfile (React SPA 용) // ------------------------------------------------- pipeline { agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Set Env') {
steps {
script {
if (env.BRANCH_NAME == 'dev') {
env.ENV_FILE = '.env.dev'
env.S3_BUCKET = 'my-react-dev-bucket'
} else if (env.BRANCH_NAME == 'stage') {
env.ENV_FILE = '.env.stage'
env.S3_BUCKET = 'my-react-stage-bucket'
} else {
env.ENV_FILE = '.env.production'
env.S3_BUCKET = 'my-react-prod-bucket'
}
}
}
}
stage('Install & Build') {
steps {
script {
sh """
# .env 파일 적용 (CRA 기준)
cp ${ENV_FILE} .env
# 의존성 설치
npm install
# 빌드
npm run build
"""
}
}
}
stage('Upload to S3') {
steps {
script {
// build 폴더가 생겼다고 가정 (CRA는 build 폴더, Vite는 dist 폴더)
sh """
aws s3 sync build s3://${S3_BUCKET} --delete
"""
}
}
}
stage('CloudFront Invalidation') {
when {
expression { env.BRANCH_NAME == 'production' }
}
steps {
script {
sh """
# 배포ID는 CloudFront 설정에서 확인
aws cloudfront create-invalidation --distribution-id ABCDEFG123456 --paths "/*"
"""
}
}
}
}
}
주석 설명 • .env.* 파일을 복사해 npm run build 시 환경변수를 반영(예: REACT_APP_API_URL 등). • 빌드 후 생성된 build/ 폴더를 S3 버킷에 업로드. • 프로덕션 배포 시 CloudFront 캐시 무효화로 새 파일을 즉시 적용.
- 개선/주의 사항
- AWS 권한 • Jenkins가 aws s3 sync, aws cloudfront create-invalidation, ssh 등 명령을 실행하려면, • Jenkins 서버에 AWS CLI가 설치되어 있어야 함 • IAM User/Role 자격 증명을 설정해야 함 (Access Key, Secret Key 또는 EC2 Role)
- 보안 • .env.* 파일 안에 민감정보(예: API Key, DB Password 등)를 넣지 않도록 주의 • 꼭 필요한 경우 AWS Parameter Store나 Secrets Manager로 안전하게 관리
- EC2 디렉토리 구조 • Next.js를 배포할 EC2에서 /home/ec2-user/next-project 같은 폴더를 만들어서 git clone해 두고, docker-compose.yml을 배치 • Jenkins → SSH → cd /home/ec2-user/next-project && git pull && docker-compose up -d 하는 식
- 도메인 연결 • Next.js EC2의 퍼블릭 IP 또는 ELB(로드 밸런서)에 Route53 도메인(A 레코드) 매핑 • React S3의 경우, CloudFront를 통해 커스텀 도메인 사용하려면 ACM 인증서(HTTPS)와 CNAME 설정 필요
- 브랜치별 리소스 분리 • dev/stage/prod 각각 EC2, S3 버킷을 분리할 수도 있고, 하나의 EC2에서 여러 컨테이너(port)로 구동할 수도 있음(규모와 예산에 따라 결정)

Next.js를 AWS 환경에 배포하는 전체적인 과정
1. Vercel vs AWS
2. AWS 서비스 개요
• EC2
• Lambda
• Amplify
3. 서버리스(Serverless) 개념
• On-premises vs On-demand
4. AWS로 Next.js 프로젝트 배포 시나리오
• 전반적인 플로우(그림/시각 자료 포함)
- Vercel vs AWS
Vercel • 장점 • Next.js 프레임워크를 만든 회사답게, Next.js와의 호환성이 가장 뛰어남. • vercel CLI로 손쉽게 배포 가능. • 서버리스 플랫폼과 CDN 구성, 배포 파이프라인이 자동화되어 있어 설정이 매우 간단. • 무료 플랜으로도 어느 정도 이용 가능. • 단점 • AWS와 비교하면 커스터마이징(확장성, 네트워킹 등)에 제약이 있을 수 있음. • 기업 규모가 커질수록 특정 서비스 아키텍처 요구 사항을 만족시키지 못할 수도 있음. (예: 전용 VPC, 특정 레거시 시스템 연동 등)
AWS • 장점 • 다양한 서비스(EC2, ECS, Lambda, RDS, S3 등)를 이용해서 원하는 아키텍처 설계 가능. • 대규모 트래픽 처리, 고가용성, 보안 등 엔터프라이즈급 요구사항을 충족시키기 용이. • 글로벌 인프라를 기반으로 리전(Region) 선택 가능. • 단점 • 서비스 종류가 매우 다양하기 때문에 처음 접하면 학습 곡선이 가파름. • 세부적인 설정(네트워킹, IAM, 보안 그룹 등)을 신경 써야 할 부분이 많음. • 무료 티어가 있지만, 다양한 서비스를 쓰다 보면 비용 관리가 까다로울 수 있음.
정리하자면, Vercel은 Next.js 배포에 최적화된 “매우 간단한 서버리스 플랫폼”이고, AWS는 인프라부터 서버리스까지 폭넓게 활용할 수 있는 “클라우드 종합 서비스”입니다.
- AWS 서비스 개요
2.1 EC2 (Elastic Compute Cloud) • 개념: AWS에서 가상 서버(Instance)를 생성해서 사용하는 서비스. • 특징: • 사용자가 직접 OS를 설치, 패키지를 설정하고 Next.js 서버 환경(node.js, nginx 등)을 구성해야 함. • 자체적으로 서버를 관리해야 하므로, 서버 관리(보안 패치, 스케일링 등)에 대한 부담이 있음. • 장점: • 원하는 대로 커스터마이징 가능. • 한 번 세팅해두면 기존 On-premises(사내 서버)에 익숙한 운영 방식을 거의 그대로 가져갈 수도 있음. • 단점: • 서버 관리 부담이 큼(서버 업데이트, 보안, 스케일링 등).
2.2 Lambda (서버리스 컴퓨팅) • 개념: 서버를 직접 관리할 필요 없이, 함수(코드)만 배포하면 자동으로 실행, 스케일링되는 서버리스 서비스. • 특징: • Next.js를 람다로 실행하기 위해서는 보통 Serverless Framework 또는 AWS SAM(Serverless Application Model) 등을 사용. • Lambda + API Gateway 구성을 통해 서버리스 REST API를 제공하거나, Lambda@Edge를 통해 CDN 레벨에서 Edge 로직을 수행할 수도 있음. • 장점: • 서버 관리를 최소화함(패치, 용량 확장, 장애 대응 등). • 사용한 만큼만 비용을 지불 (on-demand). • 단점: • 장기적으로 CPU 자원이 많이 필요한 연산(영상 처리, 머신러닝 등)에는 부적합할 수 있음(실행 시간 제한). • 서버리스 특성상 초기 기동(Cold Start) 지연이 발생할 수 있음.
2.3 Amplify • 개념: 프론트엔드 애플리케이션(React, Vue, Angular, 그리고 Next.js 등)을 손쉽게 배포하고 CI/CD 파이프라인까지 지원하는 서비스. • 특징: • Git 리포지토리와 연동하여 코드 Push 시 자동으로 빌드 후 배포할 수 있음. • Amplify Hosting을 이용하면, 정적 웹사이트 호스팅(SSR, SSG 지원)도 가능. • 인증, GraphQL API, 파일 저장, 분석 등 다양한 프론트엔드 기능을 손쉽게 연결할 수 있는 “Amplify Libraries” 제공. • 장점: • AWS 내 다른 서비스 연계가 매우 쉬움(IAM, Cognito 등). • Next.js의 SSR 기능도 지원(특정 설정 필요). • 단점: • 세부적으로 직접 제어하려면 설정이 조금 복잡해질 수 있음. • 제한된 구조 안에서만 동작하므로, 더 복잡한 아키텍처 요구사항이 있으면 별도의 세팅이 필요함.
- AWS로 Next.js 프로젝트 배포 플로우
아래는 크게 두 가지 시나리오로 구분해서 볼 수 있습니다.
- EC2에 직접 배포(수동 방식)
- Amplify Hosting 활용(자동 CI/CD)
아래 그림은 EC2 혹은 Amplify로 배포하는 큰 흐름을 시각화한 것입니다.
┌────────────┐ │ Git Repository | │ (GitHub, GitLab 등) │ └────────────┘ │ ▼ ┌────────┐ │ 로컬 개발 │ │ Next.js 개발 │ └────────┘ │ (1) npm run build │ (2) 빌드 결과 │ ▼ ──────────────────────────────────────────────────────────────── (시나리오 A) EC2 배포 플로우 ──────────────────────────────────────────────────────────────── ▼ ┌──────────────┐ │ EC2 인스턴스 생성 │ │ (Amazon Linux, Ubuntu) │ └──────────────┘ │ (3) SSH 접속 ▼ ┌─────────────┐ │ Node.js 환경 구성 │ │ PM2 or Nginx 설정 │ └─────────────┘ │ (4) 프로젝트 업로드 ▼ ┌──────────────┐ │ Next.js 실행 & 확인 │ │ PM2 start ecosystem │ └──────────────┘ │ ▼ 배포 완료
──────────────────────────────────────────────────────────────── (시나리오 B) Amplify Hosting 플로우 ──────────────────────────────────────────────────────────────── ▼ ┌─────────────┐ │ AWS Amplify Console │ │ (Git 연동 설정) │ └─────────────┘ │ (3) 자동 빌드 & 배포 ▼ ┌─────────────┐ │ Amplify 에서 사이트 │ │ URL 제공 │ └─────────────┘ │ ▼ 배포 완료
4.1 EC2에 직접 배포 (시나리오 A)
- EC2 인스턴스 생성 • AWS 콘솔에 접속 → EC2 → 인스턴스 시작 • OS 선택 (Amazon Linux, Ubuntu 등) • 키 페어, 보안 그룹 설정(80, 443 포트 오픈)
- SSH로 접속하여 환경 구성 • ssh -i <키페어.pem> ec2-user@<EC2 퍼블릭 IP> • Node.js 설치
예시(Ubuntu인 경우)
curl -fsSL https://deb.nodesource.com/setup_16.x | sudo -E bash - sudo apt-get install -y nodejs
PM2 설치 (Next.js 애플리케이션을 데몬으로 돌리기 위함)
sudo npm install -g pm2
• (옵션) Nginx 설치 후 리버스 프록시 설정
sudo apt-get install nginx sudo systemctl start nginx sudo systemctl enable nginx
/etc/nginx/sites-available/default 수정
proxy_pass http://localhost:3000;
3. Next.js 프로젝트 업로드
• Git을 이용하거나, FTP/SCP 등을 이용해서 소스 파일을 EC2로 복사
• 또는 GitHub에서 직접 pull
git clone <레포지토리 주소> cd project
4. Next.js 빌드 및 실행
• 환경 변수 설정(.env 등)
• 빌드 후 서버 실행
npm install npm run build pm2 start npm --name "nextjs" -- start
• pm2 로그/상태 확인
pm2 logs pm2 status
• 브라우저에서 http://EC2 퍼블릭 IP:3000 (또는 Nginx 설정 시 80/443 포트)로 접근해 정상 동작 여부 확인
5. 도메인 연결(선택 사항)
• Route53에서 도메인 구입 또는 도메인 레코드 등록
• EC2 퍼블릭 IP(또는 Elastic IP)를 A 레코드에 매핑
• Nginx SSL 설정 시 Certbot 등을 사용해 HTTPS 구성 가능
이 과정을 통해 EC2에서 Next.js 서버가 구동됩니다.
4.2 Amplify Hosting 활용 (시나리오 B)
- Git 리포지토리 준비 • GitHub, GitLab, Bitbucket 등 어느 것이든 사용 가능 • Next.js 프로젝트 소스가 push되어 있어야 함.
- Amplify 콘솔에서 앱 생성 • AWS 콘솔 → Amplify → “호스팅 시작” • Git 제공업체(GitHub 등)와 연결 → 레포지토리 & 브랜치 선택 • Amplify가 빌드 명령어(npm run build), 시작 명령어(npm run start) 등을 자동으로 인식하거나 직접 설정할 수 있음.
- 자동 빌드 & 배포 • Amplify는 해당 브랜치에 push가 감지되면 CI/CD 파이프라인을 실행 • 빌드가 완료되면 Amplify Hosting에 배포
- 배포 결과 확인
• Amplify가 제공하는 도메인(예: https://
.amplifyapp.com)에서 사이트 확인 • 커스텀 도메인을 연결하고 싶다면 Amplify 콘솔에서 “도메인” 탭에서 설정 가능
Amplify를 쓰면 서버 설치나 SSH 접속 없이 자동으로 Next.js를 빌드 & 배포할 수 있고, CI/CD까지 간단하게 해결 가능합니다.
아래 내용은 Next.js와 일반 React(vite+react-router) 두 개의 프론트엔드 프로젝트를 AWS에 배포할 때, 주로 언급하신 EC2와 Amplify(및 Docker 활용)에 대한 비교와 최적의 선택을 안내해 드리는 내용입니다.
- 전반적인 시나리오 요약 • 두 개의 프론트엔드 프로젝트(Next.js / React)를 동일한 방식으로 배포를 원함. • AWS를 이미 백엔드에서 사용 중이므로, 프론트엔드도 AWS를 활용. • 주요 후보: • EC2 (직접 서버 세팅 or Docker로 컨테이너화) • Amplify (서버리스 호스팅, CI/CD)
핵심 포인트
Next.js가 SSR(Server-Side Rendering) 또는 SSG(Static Site Generation), ISR(Incremental Static Regeneration) 중 어떤 방식을 쓰는지.
일반 React + react-router는 기본적으로 정적 파일(Static) 형태로 빌드 가능.
Docker를 이용하면, 로컬 환경과 동일하게 컨테이너 단위로 배포·운영 가능.
Amplify는 Docker가 필요 없고, CI/CD 파이프라인을 자동으로 구성.
배포 방법별 개념 정리
2.1 EC2 + Docker
- Dockerfile을 만들어서 Next.js(SSR 포함 가능)나 React(vite 빌드 산출물 포함)를 컨테이너로 패키징.
- EC2에 Docker 엔진 설치 후, 이미지를 pull(또는 빌드)하여 컨테이너 구동.
- 필요하다면 NGINX 등을 reverse proxy로 세팅하거나, 또는 Docker Compose 등으로 동시에 여러 컨테이너를 운영.
장점 • 인프라 제어권: OS, 네트워크, 패키지 버전 등 세세한 커스터마이징이 가능. • 일관성: 로컬에서 동작하는 Docker 이미지를 그대로 배포하면 되므로, 환경 편차 적음. • 유연성: • 프로젝트 2개를 각각 컨테이너로 나누어 구동하기 쉽다. • Next.js SSR도 무리 없이 컨테이너로 묶어 배포 가능.
단점 • 서버 관리 부담: • EC2 인스턴스 OS 업데이트, 보안 패치, Docker 엔진 관리 등을 직접 해야 함. • Auto Scaling이나 무중단 배포 전략도 직접 구성해야 함(예: AWS Auto Scaling Group, ALB). • 비용: • EC2 인스턴스 비용(24시간 상시 구동)이 발생. • 인스턴스 사양에 따라 월 수~십 달러 이상. • 학습 곡선: • Docker, 네트워크, EC2 보안 그룹, IAM, SSL(Nginx+Certbot) 등 설정 필요.
2.2 AWS Amplify Hosting
- Amplify Console에서 Git 리포지토리(예: GitHub)와 연동.
- Amplify가 자동으로 빌드 명령(npm run build), SSR인 경우 Next.js 설정 등을 수행.
- 빌드 완료 후, Amplify가 제공하는 URL에 호스팅. 커스텀 도메인도 연결 가능.
장점 • 서버 관리가 사실상 필요 없음: • 서버 패치, Docker 설치, Nginx 설정 등이 불필요. • 자동 CI/CD: • Git push → 자동 빌드 & 배포 파이프라인. • SSR 지원: • Amplify는 2021년 말부터 Next.js SSR 지원을 공식화. • (단, Next.js 버전에 따라 일부 설정이 필요할 수 있음.) • 비용: • 일정 수준의 무료 호스팅 용량/빌드 시간 존재. • 사용량에 따라 과금되나, 소규모/중규모 트래픽이면 EC2보다 저렴할 가능성이 큼(특히 서버리스 구조이므로).
단점 • 제한된 커스터마이징: • Docker 기반의 복잡한 설정이나 OS 레벨 최적화가 필요한 경우엔 제약이 있을 수 있음. • 특수한 서버 구성 필요 시: • 예: Next.js + WebSocket(독립 서버) + 특정 라이브러리 설치 + OS 권한 등… 이런 케이스에서는 Amplify가 한계가 있을 수 있음. • SSR 성능/설정: • 대규모 트래픽 상황에서 SSR/ISR 등 세부 튜닝이 필요하다면, Amplify 설정만으로는 한계가 있을 수 있음(물론 AWS Lambda@Edge, CloudFront 등과 병행 가능).
- 두 프로젝트(Next.js & 일반 React) 각각 어떻게 되는가?
3.1 Next.js • EC2 + Docker: • Dockerfile 작성:
FROM node:16 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build EXPOSE 3000 CMD ["npm", "run", "start"]
• EC2에 Docker 설치 후, 위 이미지 빌드 → 컨테이너 실행.
• 필요 시 Nginx reverse proxy 도입.
• Amplify Hosting:
• Amplify 콘솔에서 Next.js 프로젝트 선택 시, 프레임워크를 자동 인식.
• SSR 옵션 켜주고(기본적으로 “빌드 후 서버리스 SSR” 형태) 깃 푸시만 하면 끝.
3.2 일반 React (Vite + react-router) • EC2 + Docker: • 정적 사이트이므로 npm run build 후 나온 dist 폴더를 Nginx 컨테이너로 서빙하거나, 간단하게 serve 패키지를 써도 됨.
FROM node:16 AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build # vite build
FROM nginx:alpine COPY --from=builder /app/dist /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]
• 이 컨테이너 이미지를 EC2 상에서 실행하면 정적 사이트 호스팅 가능.
• Amplify Hosting:
• React(vite) 프로젝트도 Amplify에서 정적 호스팅 가능.
• 빌드 커맨드(npm run build), 빌드 아웃풋(dist)만 설정해주면 자동으로 업로드.
- 비용 비교
4.1 EC2 • t2.micro나 t3.micro 같은 작은 인스턴스 기준, 프리티어 기간(1년) 이후 월 $8~$10 정도(리전, 탄력적 IP 유무, 디스크 용량 등에 따라 상이). • 트래픽 증가 시, 수동/자동 확장(ELB + 오토스케일링) 고려 → 비용 상승. • 추가로 Docker를 쓰더라도 Docker 자체 이용료는 없지만, EC2 리소스( CPU, RAM )는 컨테이너가 사용하는 만큼 필요하므로 인스턴스 스펙이 올라가면 비용 증가.
4.2 Amplify
• 무료 사용량:
• 매월 5GB(호스팅 전송량), 빌드 시간 1000분 제공(변동 가능).
• 추가 과금:
• 호스팅 전송 비용: $0.20/GB 정도 (리전에 따라 상이)
• 빌드 시간이 초과될 경우 $0.01/분
• 사이트가 소규모 트래픽이라면 실제 비용이 15달러 내외로 해결될 수도 있음(무료 사용량을 넘지 않으면 거의 무료에 가깝).
- 두 가지 방식을 동시에 고려했을 때의 장단점
구분 EC2 + Docker Amplify Hosting 서버 관리 OS, Docker 업데이트, 보안 패치 직접 수행 AWS가 서버리스로 관리, 사용자는 설정 최소화 배포 편의성 Docker 이미지를 직접 빌드/푸시 → 배포 자동화 가능(Jenkins, GitHub Actions 등) Git Push → Amplify가 자동 빌드 & 배포(CI/CD 내장) 확장성 오토 스케일링 설정 필요(Load Balancer 등) Amplify가 자동 스케일링(서버리스) 커스터마이징 높은 자유도(특수 라이브러리, OS 설정 가능) 제한적(Amplify가 제공하는 환경 내에서 동작) Docker 활용 가능(직접 설치 후 컨테이너 구동) 기본적으로 필요 없음(Docker 숨겨져 있음) 비용 구조 EC2 상시 과금(인스턴스 크기+트래픽) 서버리스 과금(빌드 시간+트래픽) 학습 난이도 Docker, Nginx, 보안 그룹, OS 레벨 지식 필요 Amplify 콘솔 세팅, Git 연동 지식이면 충분
최적의 선택 가이드
- 규모가 작거나, 인프라 관리 부담을 줄이고 싶다 • Amplify 권장 • 이유: CI/CD 자동화, 서버 관리 필요 없음, 트래픽이 커지면 자동 스케일링 • Next.js SSR도 Amplify로 충분히 가능
- 이미 Docker를 심도 있게 사용 중이고, 인프라를 세세하게 제어하고 싶다 • EC2 + Docker 권장 • 이유: Docker 이미지 한 번 만들어서 어디든 이식 가능(ECS, EKS 등 확장성) • Node 버전, 리눅스 패키지, Nginx 등 완전 커스터마이징 가능
- 하이브리드 • 실제로는 Amplify가 제공하는 CI/CD를 쓰되, 백엔드는 EC2/ECS로 Docker를 돌릴 수 있음. • 프론트는 Amplify, 백엔드는 EC2(or ECS, Lambda 등)로 분리.
결론 • 가장 간단하고 운영 부담이 적은 방법: Amplify로 두 프로젝트(Next.js, 일반 React) 모두 호스팅 • GitHub(또는 다른 Git)과 연동 → 자동 빌드 & 배포 → Amplify 제공 도메인(또는 커스텀 도메인)으로 접근 • 서버 관리는 AWS에서 알아서 해주므로, 학습 비용과 운영 부담이 크게 줄어듦 • 소규모~중규모 트래픽이라면 비용도 저렴 • Next.js의 SSR, SSG, ISR도 지원 • **Docker를 써야 하는 명확한 이유(특수 환경, 큰 커스터마이징 필요)**가 있다면: • EC2에 Docker로 배포 • 로컬과 서버 환경이 동일해 유지보수 편함 • 하지만 서버 운영(보안/패치/스케일링)도 직접 해야 함
정리:
- 운영 편의 & 빠른 배포 → Amplify
- 유연성 & Docker 기반 인프라 통합 관리 → EC2 + Docker
대부분의 일반적인 프론트엔드(SSR + SPA) 프로젝트라면 Amplify가 더 “쉬우면서 저렴”하고, 이미 사내에 Docker 기반 배포 파이프라인이 잘 잡혀 있거나 커스터마이징 요구사항이 많다면 EC2(혹은 ECS) + Docker가 적합합니다.