[배포] AWS와 Vercel 비교

2023.01.05(금)

이전 국비지원 교육을 받으며 React로 개발했을 당시 AWS로 배포를 진행했었다.

당시에는 흔히 듣던 말이 “프론트는 S3에 파일 올려주시기만 하면 됩니다 ~ “ 였다. 그래서 아 프론트 쪽은 배포에 그렇게 크게 신경을 쓰지 않아도 되는구나? 하고 넘어갔던 기억이있다.

하지만 헬핏 프로젝트를 Next.js 로 개발하면서 이 생각들이 많이 바뀌게 되었다. 이전과 마찬가지로 S3에 배포를 올리니 정말 많은 라우트 에러가 발생하였고 이 문제를 해결하기 위해 정말 많은 삽질을 했었다. ( 제출 기한 이틀 전이였기 때문에 몇가지는 해결하지 못하고 제출 )

이후 OnMyTicket 프로젝트도 Next.js 로 개발했기 때문에 이러한 배포 문제를 걱정했었다.

💡Next.js 와 S3 , EC2

Next.js로 개발하는 목적은 기본적으로 SSR을 통해 SEO를 향상하기 위함이고 이는 내부적으로 instance를 만들어 실행하기 때문에 SEO향상이 목적이라면 S3 + Cloudfront에서는 사용할 수가 없다고 한다.

1. AWS S3:

   • 정적 사이트 호스팅: Next.js 프로젝트가 정적 사이트(서버 측 렌더링 또는 동적 콘텐츠 생성 없음)인 경우 AWS S3에 배포하는 것이 일반적이고 비용 효율적인 선택입니다.

   • 단순성: S3는 정적 웹사이트에 대해 설정이 간단하며 전 세계적으로 더 빠른 콘텐츠 전송을 위해 Amazon CloudFront와 같은 콘텐츠 전송 네트워크(CDN)와 작동하도록 구성할 수 있습니다.

2. AWS EC2:

   • 서버 측 렌더링(SSR) 또는 API 경로: Next.js 프로젝트가 서버 측 렌더링을 포함하거나 API 경로를 사용하는 경우 동적 콘텐츠를 처리하기 위해 서버가 필요할 수 있습니다. 이러한 경우 EC2 인스턴스에 배포하는 것이 적합한 옵션입니다.

   • 사용자 정의 서버 로직: 애플리케이션에 사용자 정의 서버 로직이나 특정 서버 측 구성이 필요한 경우 EC2에 배포하면 더 많은 제어력과 유연성을 얻을 수 있습니다.

3. 하이브리드 접근 방식:

   • 정적 자산이 S3/CloudFront에서 제공되고 동적 콘텐츠 또는 서버 측 렌더링이 EC2 인스턴스 또는 다른 서버리스 솔루션에서 처리되는 하이브리드 접근 방식을 채택할 수도 있습니다.

💡 AWS

Amazon Web Services 의 약자로 아마존이 제공하는 클라우드 컴퓨팅 서비스이다.

AWS 배포 진행 Link

자유도가 높다. 내가 원하는데로 커스터마이징이 가능하다. 하지만 보안이나 AWS설정을 잘 모르고 건들이게 될 경우 과금이 되는 경우들도 있다.

처음 써보는 Linux 명령어들에 당황스럽고 뭔가 정해진 틀대로 하지 않으면 에러가 잘 발생하는 것 같다.

처음 사용할 때 접근성이 좋지 않다..? 왜나면 혼자 삽질을 굉장히 많이 했기 때문에..

배포 속도가 느리다.. AWS와 Vercel 배포 모두 경험해본 나로써는 Vercel 배포가 훨씬 빨랐다.

이렇게 말하니 단점밖에 적지 않은 것 같은데 기능을 모두 다 해보지는 않았기 때문에 아직까지 내가 느끼는 부분은 이것이 전부다.

AWS는 분명 Vercel 보다 광범위한 서비스를 제공하고 있는 광범위한 클라우드 컴퓨팅 플랫폼이기 때문에 내가 느끼지 못한 장점이 훨씬 많을 것이라고 생각한다.

+) AWS 내 프론트엔드 배포 서비스

1. Amazon S3

객체 스토리지 서비스. 정적파일을 저장하고 배포하는데 사용한다. 동적 콘텐츠를 처리할 수는 없다.

1. Amazon CloudFront

CDN 서비스. 정적 파일 & 동적 파일을 전 세계로 빠르게 전송이 가능하다. 원본을 기반으로 한 콘텐츠를 캐싱하고 전달할 수 있다.

1. Amazon Amplify

AWS에서 풀 스택 웹 및 모바일 앱을 구축하는 데 필요한 모든 것을 제공. 프런트엔드를 구축 및 호스팅하고, 인증 및 스토리지와 같은 기능을 추가하고, 실시간 데이터 소스에 연결하고, 수백만 명의 사용자에게 배포하고 확장할 수 있다.

💡 Vercel

Next.js 를 개발한 스타트업에서 만든 클라우드 컴퓨팅 서비스이다.

주로 정적 웹사이트 및 SPA를 위한 특정한 서비스를 제공하고 프론트엔드 빌드 및 배포에 초점을 맞춘 플랫폼이다.

Vercel 배포 진행했던 Link

장점 )

UI가 아주 간결하다. 새로운 배포를 하고 싶을 때도 Add New를 눌러서 원하는 레포랑 연결만 하면 CI/CD를 알아서 구축해준다.

기본 배포는 vercel.app으로 되는데, 도메인을 따로 구입해서 연결할 수도 있다. 상당히 개발자 친화적이라고 느껴졌다.

또한 서버리스 아키텍쳐 기반이다. 서버리스 아키텍쳐란, 서버가 없다는 것이 아니라 서버 관리는 해당 아키텍쳐가 알아서 다 해주고 개발자는 서버 관리와 확장에 신경쓰지 않고 애플리케이션 코드에 집중할 수 있게 해주는 아키텍쳐이다. 이 때 Vercel은 정적파일을 CDN을 통해 전 세계 여러 위치에 제공해 빠른 로딩 속도와 확장성을 제공한다.

단점 )

AWS 보다 기능이 적다. 정말 프론트엔드 배포에만 최적화된 느낌…? vercel은 주로 정적 파일과 프론트엔드에만 초점을 맞춘 플랫폼이라 백엔드 기능이 필요할 때는 별도로 구성을 해주어야 한다.

또한, Vercel은 SPA 배포에 최적화되어있기 때문에, Next.js 같은 MPA 배포를 하려면 Next.js의 라우팅 설정과 Vercel의 라우팅 설정을 잘 설정해줘야한다. 실제로 vercel로 Next.js 배포를 시도했다가 에러에 허덕이는 친구들을 종종 볼 수 있었다

💡 결론

나처럼 규모가 작은 개인프로젝트 같은 것들은 Vercel로 배포하는것이 훨씬 간단하고 편리한 것 같다. 하지만 보통의 회사에서는 규모가 큰 작업들을 진행하기 때문에 얼른 AWS에도 적응하고 배포 연습을 계속 해봐야겠다.