AWS EC2 micro에서 Vercel(Hobby)로 이전하며 얻은 것과 잃은 것
배경
Next.js 기반 개인 프로젝트인 economins를 한동안 AWS EC2 micro 인스턴스 환경에서 직접 운영해왔습니다.
Docker 컨테이너 기반으로 CI/CD를 구성하고, GitHub Actions를 통해 이미지를 빌드한 뒤, ECR에 업로드하고, EC2에서는 docker-compose로 서비스를 실행하는 구조였습니다.
이 구조는 “실제 서비스처럼 운영해보자”는 목적에는 충분히 의미가 있었습니다. 배포 자동화, 실행 환경 고정, 인프라 운영을 직접 경험할 수 있었기 때문입니다. 다만 프로젝트가 안정화 되고 외부 유입과 홍보를 고려하면서 운영 비용과 복잡도가 현재 단계에 비해 과도하다는 판단이 들었습니다.
그 결과, 인프라 운영의 책임과 비용을 줄이고 서비스와 데이터에 더 집중할 수 있는 선택지로, Vercel(Hobby 플랜) 을 선택해 옮겼습니다.
이전 전 구조 (EC2 micro)
배포 흐름
1
2
3
4
5
Git tag push
→ GitHub Actions
→ Docker build
→ ECR upload
→ EC2 (docker-compose up)
특징
- Docker 기반 컨테이너 직접 운영
- nginx + HTTPS 인증서 직접 관리
- 서버 리소스, 배포 실패, 롤백 모두 수동 책임
변경 후 구조 (Vercel Hobby)
배포 흐름
1
2
3
GitHub master branch push
→ Vercel build
→ 자동 배포
특징
- 배포 과정에서 사람 개입 최소화
- 인프라 운영에 필요한 설정 애플리케이션과 분리 가능
- 자동 롤백
데이터 전달 구조 변경: Presigned URL에서 CloudFront로
Vercel로 플랫폼을 이전하면서, 데이터 전달 경로 또한 함께 재설계했습니다. 기존 구조는 S3 Presigned URL을 기반으로 했으나, Managed Platform 환경과 SSR 전제에서는 불필요한 책임과 복잡도를 포함하고 있었습니다.
서비스가 SSR 기반이기 때문에, 데이터 조회는 서버에서만 이루어지며, 클라이언트에 Presigned URL이나 접근 토큰을 전달할 필요가 없습니다. 이 전제 덕분에 데이터 전달 경로를 서버를 중심으로 보다 단순화할 수 있었습니다.
CloudFront를 통해 데이터를 제공하면서, S3 origin 접근은 OAC로 제한하고 캐시와 전달 책임을 CDN계층으로 분리했습니다. Vercel에서도 AWS Credential을 애플리케이션에 주입하지 않고 안전하게 데이터 조회할 수 있습니다.
이전 전 구조
1
2
3
4
Client / SSR (EC2)
→ EC2 Backend
→ S3 (Presigned URL 발급)
→ Client / SSR
이전 후 구조
1
2
3
4
SSR (Vercel)
→ CloudFront
→ (OAC)
→ S3
특징
- Vercel 애플리케이션은 AWS Credential을 보유하지 않음
- S3는 CloudFront OAC를 통해서만 접근 가능
- 데이터 전달 책임이 CDN 계층으로 이동
- 캐시 및 확장성은 CloudFront가 담당
얻은 것 (엔지니어링 관점)
1. 인프라 운영 부담 제거
Vercel은 다음을 플랫폼 레벨에서 처리합니다.
- HTTPS 인증서 발급/갱신
- 기존에는 certbot을 사용해 Let’s Encrypt 인증서를 발급하고, 크론잡을 통해 주기적으로 갱신을 관리해야 했습니다. Vercel로 이전한 이후에는 인증서 발급과 갱신이 플랫폼 레벨에서 자동으로 처리됩니다.
- CDN 설정
아래 항목이 자동으로 캐시 됩니다.
1 2 3 4
/_next/static/* public/* 이미지 정적 json
- 서버리스 실행 환경
- 배포 실패 시 자동 롤백
2. 배포 워크플로 단순화
기존에는:
- Git tag 관리
- Docker 이미지 버전 관리
- ECR 업로드
- EC2 재배포
현재는:
- master branch push로 배포 과정이 단순해지면서, 배포 속도가 개선되었습니다.
3. 자동 스케일링과 트래픽 대응
EC2 micro 환경에서는 트래픽 증가에 대한 부담이 항상 존재했습니다. 서버 리소스 한계가 명확했기 때문에 홍보나 외부 노출에 소극적이었습니다.
반면 Vercel에서는 트래픽 증가 시 자동 스케일링이 기본으로 제공되고, 정적 자산은 글로벌 CDN 캐시를 통해 처리되어 갑작스러운 유입에 대한 부담 없이 서비스 자체에 더 집중할 수 있는 환경이 되었습니다.
4. 비용 구조 개선 (Hobby 플랜)
- AWS EC2 micro 기준
- EC2 인스턴스 비용: 약 $11.5 / month
- VPC 및 부가 비용: 약 $3.5 / month
- 총 월 고정 비용: 약 $15
- Vercel Hobby 플랜
- 비용: 무료
트래픽이 거의 없는 개인 사이트 기준에서는 고정 비용이 발생하는 EC2 구조보다 Vercel의 무료 플랜이 비용 효율 측면에서 압도적으로 유리합니다.
5. 개발 생산성 향상
- Preview Deployment
- 배포 히스토리 및 롤백
- 빌드/런타임 로그 UI 제공
개발–배포–확인 사이클이 훨씬 짧아졌습니다.
잃은 것 (트레이드 오프)
1. 인프라 제어권
EC2에서는 아래 기능을 모두 직접 제어할 수 있습니다.
- OS
- 네트워크
- 컨테이너
- 런타임 설정
반면 Vercel에서는 이런 영역이 대부분 추상화되어 있습니다.
2. 리소스 및 사용량 제한
Vercel의 Hobby 플랜에는 서버리스 함수 실행량, 대역폭, 빌드/로그 제한 등의 명확한 리소스 제한이 있습니다.
트래픽이 일정 수준을 초과할 경우 일시적인 서비스 중단이 발생하거나, 유료 플랜으로의 전환이 필요합니다. 다만 개인 프로젝트 단계에서는 이러한 제한이 실제 병목으로 작용할 가능성은 낮다고 판단했고, 제한이 도달하는 시점이 곧 인프라를 재설계 하거나 유료 플랜으로 전환할 지표가 될 수 있다고 생각합니다.
3. 상업적 사용 제한
Hobby 플랜은 기본적으로 개인 / 비상업적 사용에 적합합니다. 수익화나 비즈니스 용도로 확장한다면 Pro 이상의 플랜 검토가 필요합니다.
4. 플랫폼 종속성
Vercel의 빌드/배포/실행 모델은 플랫폼에 최적화되어 있어, 다른 환경으로 이전할 경우 구조를 일부 재조정해야할 가능성이 있습니다. 다만 이미 Docker 기반 배포와 GitHub Actions를 구성해두었고, 어플리케이션 실행 환경과 배포 로직을 분리해두었기 때문에, 언제든 다시 되돌아갈 수 있습니다.
정리: 엔지니어링 관점에서의 판단
제가 운영하는 economins는 Next.js 기반의 데이터 시각화 서비스이지만, 본질적으로는 데이터 흐름을 제어하는 ETL 성격의 백엔드 기능이 더 중요한 프로젝트라고 생각하고 있습니다.
이번 Vercel로의 이전은 단순한 호스팅 변경이 아니라, 인프라 운영에 사용되던 비용과 에너지를 줄이고 그만큼 백엔드 로직과 데이터 확장에 집중하기 위한 선택이었습니다. 운영 부담을 낮춘 대신, 더 많은 지표와 더 깊은 데이터 흐름을 설계할 수 있는 여유를 확보하고자 했습니다.
엔지니어링의 성숙도는 복잡한 시스템을 만드는 데서 오지 않는다고 생각합니다. 불필요한 복잡함을 제거할 수 있는 판단에서 나온다고 믿습니다.
인프라 운영을 플랫폼에 위임하고, 데이터와 서비스에 더 집중할 수 있는 구조를 선택했습니다. 이번 선택은 더 나은 방향으로 나아가기 위한 결정입니다.
예시코드
모든 코드는 깃헙에 있습니다.