Vercel vs AWS Amplify vs ECS, 어떤 배포 방식을 선택할까

웹 서비스를 배포할 곳을 찾다 보면 Vercel과 AWS가 자주 후보에 오른다. 그런데 이 둘을 단순히 같은 종류의 호스팅 서비스로 비교하면 선택하기가 더 어려워진다.

Vercel과 AWS Amplify Hosting은 프런트엔드 애플리케이션을 빠르게 배포하기 위한 관리형 플랫폼에 가깝다. 반면 ECS는 Docker 컨테이너를 직접 운영하는 인프라 계층이다. 해결하려는 문제가 서로 다르다.

먼저 결론부터 정리하면 다음과 같다.

• Next.js 중심이고 빠른 출시가 중요하다면 Vercel
• AWS 안에서 프런트엔드를 간단하게 배포하려면 Amplify Hosting
• Docker, WebSocket, Worker, 복잡한 백엔드까지 통제하려면 ECS/Fargate

세 서비스는 어디까지 관리해 줄까

배포 서비스를 비교할 때 가장 먼저 볼 것은 "내가 어디까지 운영해야 하는가"다.

같은 Next.js 애플리케이션도 어디에 배포하느냐에 따라 우리가 책임지는 범위가 달라진다.

Vercel — 프런트엔드 개발 경험을 최우선으로

Vercel의 대표적인 배포 흐름은 매우 짧다.

GitHub 연결
  → PR 생성
  → Preview Deployment 자동 생성
  → main 브랜치에 병합
  → Production 자동 배포

Git 저장소를 연결하면 각 커밋과 Pull Request마다 고유한 배포 URL이 생성된다. 프로덕션 브랜치(보통 main)가 아닌 커밋과 PR은 Preview 배포로 만들어지고, 프로덕션 브랜치에 병합하면 Production 배포가 된다. 변경 사항을 실제 URL에서 확인한 뒤 병합하면 프로덕션 배포가 만들어진다. 특정 배포를 다시 프로덕션으로 승격하거나 이전 상태로 되돌리는 작업도 간단하다.

장점

• Next.js 기능과 가장 빠르고 자연스럽게 통합된다.
• 별도의 CI/CD 구성 없이 Preview와 Production 환경을 제공한다.
• CDN, 이미지 최적화, 캐싱, Functions, 로그를 한곳에서 관리할 수 있다.
• 인프라 담당자가 없는 작은 팀도 운영하기 쉽다.
• 트래픽 변화에 맞춰 서버 측 함수가 자동 확장된다.

Vercel Functions는 서버를 직접 관리하지 않고 요청에 따라 서버 측 코드를 실행한다. 현재 신규 프로젝트에는 여러 요청을 하나의 함수 인스턴스가 함께 처리할 수 있는 Fluid Compute가 기본 적용된다.

고려할 점

• 플랫폼이 제공하는 런타임과 실행 제한에 맞춰야 한다.
• 지속 실행 프로세스나 복잡한 컨테이너 환경에는 적합하지 않다.
• 데이터 전송, 이미지 최적화, 함수 실행량이 커지면 비용을 세밀하게 확인해야 한다.
• Vercel에 특화된 기능을 많이 사용할수록 다른 플랫폼으로 이전하기 어려워질 수 있다.

블로그, 커머스 프런트엔드, SaaS 대시보드, 마케팅 사이트처럼 요청 단위로 처리되는 Next.js 애플리케이션에 잘 맞는다.

AWS Amplify Hosting — AWS 안의 관리형 프런트엔드 배포

Amplify Hosting의 사용 경험은 Vercel과 비슷하다.

GitHub 연결
  → 프레임워크와 빌드 설정 감지
  → 브랜치별 빌드 및 배포
  → CloudFront CDN을 통해 서비스

정적 사이트와 SPA뿐 아니라 Next.js SSR도 자동 감지한다. Nuxt, Astro, SvelteKit 같은 프레임워크도 어댑터를 통해 배포할 수 있다.

장점

• AWS 서비스 중 프런트엔드를 가장 간단하게 배포할 수 있는 방법 중 하나다.
• Git 기반 CI/CD와 브랜치별 환경, PR Preview를 제공한다.
• CloudFront 기반의 글로벌 CDN을 사용한다.
• Cognito, AppSync, Lambda, S3 같은 AWS 서비스와 연결하기 편하다.
• IAM과 결제를 기존 AWS 계정 안에서 통합할 수 있다.
• 좌석보다는 빌드와 호스팅 사용량을 중심으로 비용이 발생한다.

고려할 점

• Next.js의 최신 기능에 대한 지원 속도와 밀착도는 Vercel이 유리한 편이다.
• SSR 문제를 디버깅할 때 Amplify 내부 실행 구조를 알아야 할 수 있다.
• AWS IAM과 Service Role에 대한 기본 지식이 필요하다.
• 임의의 서버를 그대로 실행하는 것이 아니라 Amplify의 배포 규격에 맞춰야 한다.

Amplify의 SSR 배포 결과물은 크게 정적 파일, Compute 코드, 배포 Manifest로 구성된다. 즉, Docker 이미지를 자유롭게 실행하는 ECS와 달리 Amplify가 정의한 실행 계약 안에서 동작한다.

이미 AWS를 사용하고 있으며 표준적인 React, Next.js 또는 SSR 프런트엔드를 별도 인프라 운영 없이 배포하고 싶을 때 적합하다.

AWS ECS/Fargate — 컨테이너와 인프라를 직접 통제

ECS는 Docker 컨테이너를 배포하고 운영하는 서비스다. Fargate를 함께 사용하면 EC2 인스턴스 자체는 관리하지 않아도 되지만, 컨테이너를 둘러싼 네트워크와 배포 구조는 직접 설계해야 한다.

일반적인 배포 과정은 다음과 같다.

GitHub Actions 또는 CodePipeline
  → Docker 이미지 빌드
  → ECR에 이미지 Push
  → ECS Task Definition 갱신
  → ECS Service 배포
  → ALB가 새 컨테이너로 트래픽 전달

실제 서비스에서는 여러 AWS 리소스가 함께 사용된다.

장점

• Docker에서 동작하는 애플리케이션을 거의 그대로 실행할 수 있다.
• Node.js, Spring, Go, Python 등 특정 프레임워크에 종속되지 않는다.
• WebSocket, 스트리밍, Queue Consumer, Worker, 장시간 작업에 적합하다.
• CPU, 메모리, 포트, 헬스 체크와 스케일링 정책을 세밀하게 설정할 수 있다.
• VPC, Private Subnet, Security Group 등 기업 네트워크 요구 사항에 대응하기 좋다.
• Rolling, Blue/Green, Linear, Canary 같은 배포 전략을 선택할 수 있다.

고려할 점

• ECR, ECS, ALB, VPC, IAM, CloudWatch, Auto Scaling을 함께 이해해야 한다.
• PR마다 Preview 환경을 만드는 기능은 직접 자동화해야 한다.
• Task가 계속 실행되는 동안 트래픽이 없어도 컴퓨팅 비용이 발생한다.
• Fargate 외에 ALB, NAT Gateway, 로그, 공인 IPv4와 데이터 전송 비용이 추가될 수 있다.
• 컨테이너 종료, 메모리 부족, 헬스 체크 실패 등을 직접 관측하고 대응해야 한다.

ECS의 기본 Rolling Update는 기존 Task를 새 Task로 점진적으로 교체한다. Blue/Green은 기존 환경과 새 환경을 동시에 실행한 뒤 트래픽을 전환한다. 빠른 롤백과 무중단 배포에 유리하지만, 배포 중에는 두 환경이 함께 실행되어 일시적으로 더 많은 자원이 필요하다.

API 서버, WebSocket 서버, AI 추론 서버, Worker, Spring 기반 백엔드처럼 실행 환경을 직접 통제해야 하는 서비스에 잘 맞는다.

배포 방식의 차이

세 서비스에서 코드가 프로덕션에 도달하는 과정도 다르다.

Vercel과 Amplify에서는 애플리케이션 코드가 중심이다. ECS에서는 애플리케이션뿐 아니라 이미지, Task, Service, Load Balancer와 네트워크도 배포 시스템의 일부가 된다.

비용은 어느 쪽이 더 저렴할까

어느 서비스가 항상 저렴하다고 단정할 수는 없다. 트래픽 패턴과 팀의 운영 비용까지 함께 봐야 한다.

트래픽이 작거나 변화가 큰 경우

요청이 거의 없는 시간대가 길다면 Vercel이나 Amplify가 유리할 가능성이 크다. 관리형 함수는 실제 사용량을 중심으로 비용이 발생하지만, ECS Task는 실행 중인 CPU와 메모리에 계속 비용이 발생하기 때문이다.

트래픽이 꾸준히 많은 경우

서버 사용률이 일정하고 높다면 ECS에서 리소스를 직접 최적화하는 편이 유리해질 수 있다. ARM 아키텍처, Fargate Spot, Compute Savings Plans 같은 선택지도 있다. 대신 운영 인력과 장애 대응 비용도 계산해야 한다.

놓치기 쉬운 비용

• Vercel: 데이터 전송, 함수 실행, 이미지 최적화, 팀 플랜
• Amplify: 빌드 시간, 저장 용량, 데이터 전송, SSR 요청
• ECS: Fargate Task, ALB, NAT Gateway, CloudWatch Logs, 공인 IPv4, 데이터 전송

특히 ECS를 Private Subnet에 배치한 뒤 외부 통신을 위해 NAT Gateway를 사용하면, 작은 서비스에서는 NAT 비용의 비중이 컨테이너 비용보다 커질 수도 있다.

비용을 비교할 때는 클라우드 청구액뿐 아니라 배포 파이프라인 구축, 모니터링, 보안 패치와 장애 대응에 들어가는 개발자의 시간도 포함해야 한다. 그런 의미에서 작은 팀에게는 단가가 조금 높더라도 Vercel이 전체적으로 더 저렴할 수 있다.

상황별 선택 기준

하나만 선택할 필요는 없다

프런트엔드와 백엔드에 같은 플랫폼을 써야 하는 것은 아니다. 실무에서는 다음 조합도 자주 고려할 수 있다.

이 구조는 Vercel의 프런트엔드 개발 경험과 AWS 백엔드의 통제력을 함께 얻는다. 반대로 권한, 결제, 보안 정책을 AWS 계정 하나로 통합하는 것이 중요하다면 Amplify + API Gateway/Lambda 또는 Amplify + ECS가 관리하기 편할 수 있다.

마무리

Vercel, Amplify, ECS의 차이는 성능 순위가 아니라 추상화 수준과 운영 책임의 차이다.

• Vercel은 프런트엔드 개발자가 인프라보다 제품에 집중하도록 돕는다.
• Amplify는 비슷한 경험을 AWS 생태계 안에서 제공한다.
• ECS는 더 많은 운영 책임을 받는 대신 실행 환경과 네트워크에 대한 통제권을 준다.

처음부터 가장 자유로운 인프라를 선택할 필요는 없다. 현재 서비스에 필요한 기능과 팀이 감당할 수 있는 운영 범위를 기준으로 선택하는 것이 좋다. 빠른 검증 단계라면 Vercel이나 Amplify로 시작하고, 상시 실행 프로세스나 네트워크 요구 사항이 명확해질 때 ECS를 도입하는 방식도 충분히 현실적이다.

참고 자료

• Vercel Git 배포
• Vercel Functions
• Vercel Fluid Compute
• Vercel 가격
• AWS Amplify Hosting 시작하기
• Amplify SSR 애플리케이션 배포
• Amplify Hosting 배포 규격
• AWS Amplify 가격
• Amazon ECS 배포 전략
• ECS 서비스의 로드 밸런싱
• AWS Fargate 가격