왜 AWS Amplify로 배포하였나 (with. EKS and Vercel)

블로그를 만든다는 것

프로젝트를 생성하고 개발을 한 뒤, 배포하기까지 긴 터널을 지나기 앞서 어떤 것들을 고려사항으로 가져갈지 큰 갈레를 정해보았다. 정보 공유와 정리, 나만의 사이트 구축을 위해 만들어질 블로그는 최소 몇 년 이상 길게 가져가고픈데, 그만큼 시작을 신중하게 하고 싶은 마음이다.

읽기 편한 사이트

가장 먼저, 블로그는 웹(web)과 로그(log)를 합친 단어인만큼 읽기 쉬워야한다. 읽기 쉽다는 것은 웹 페이지가 가진 가장 본질적인 특성이면서도 사용성을 위해 기본적으로 고려되어야하는 부분이다. 컨텐츠를 읽기 쉽다는 것은 페이지 테마 컬러, 자간, 행간과 같은 텍스트 속성, 이미지 로드가 얼마나 빠른지를 의미하고, 페이지 사용성이 좋다는 것은 페이지 전환 속도, 초기 로드 속도 및 그 외 UX 측면에서의 개선사항을 의미한다. 그렇기 때문에 이 부분에 대해 신경을 썼고, 더 나아가서는 개발을 하는 필자 입장에서 개발하기 쉬운 프로젝트를 만드는 것까지가 고려사항이었다.

유지보수하기 편리한 프로젝트 구축

React, Next.js를 활용하여 정적 사이트 생성을 기반으로 블로그를 구성하되, 개발자 입장에서 오랜 시간 유지보수가 편한 구조로 만드는 것이 중요하다. 단순히 작동하는 코드가 아닌, 구조적으로 명확하고 확장 가능한 형태로 구성하는 것이 목표였다. 이를 위한 고려사항은 다음 세 가지로 잡아보았다.

MDX 기반 콘텐츠 작성: Markdown의 직관성과 JSX의 유연함을 동시에 활용하여 글을 작성하는 입장에서 효율적으로 작업하고자 한다.
SSG 기반 빌드: SEO와 퍼포먼스를 동시에 고려하여 안정적으로 페이지를 제공한다.
점진적인 도입: 테마(다크/라이트 모드)기능과 댓글, 조회수 등 게시글 열람 외 기능에 대한 욕심도 있으나, 당장 게시글 기능부터 짜야하기 때문에 블로그 방향이 명확해짐에 따라 점진적으로 여러 기능을 붙여 확장시키는 방식을 선택했다.

이러한 사항들을 기준으로 연휴 첫째날, 발빠르게 프로젝트를 생성하였다. 그렇다면 빌드 배포는 어떤 방식으로 해야할까?

Amazon EKS

가장 먼저 생각난 것은 Kubernetes를 활용한 클러스터 배포 방식이다.

이유는 현재 회사에서 개발중인 경험을 통해 추가적인 기술을 리서치할 시간이 생략되기 때문이다. 지금 생각해보면 이 방식 자체를 실제로 시도해본건 시간 낭비였다. 클러스터에서 운영하고 배포할 애플리케이션(블로그)의 크기, 부하 등을 전혀 고려하지 못했다. 비용 측면에서 크게 비효율적이라는 것.

ref:dzone.com/articles/deploying-a-kubernetes-cluster-with-amazon-eks

일단 aws 계정을 먼저 만들었다. 회사에서 쓰는 Azure 클라우드가 익숙하지만 최근 여러 프론트엔드 포지션들에서 aws를 우대사항으로 요구했기에 이 참에 aws 공부를 해보자는 생각이었다.

aws console : 비용 및 결제 관리

IAM과 오하이오 Region을 기본으로 설정하고, 예제를 위한 EC2 인스턴스 생성과 EKS 클러스터 생성도 해보았다. 그렇게 첫 날 스터디를 마무리를 하고 다음 날부터 클러스터 세팅을 들어가던 찰나, 문득 '비용'에 대해 궁금하여 청구 및 결제 항목을 조회했다. 그 결과, 현재 클러스터 하나만 실행 중임에도 여태까지의 사용량을 기준으로 월간 지불해야할 비용이 46달러나 나왔다😳. 비용이 상당히 크게 나온 원인은 EKS 프로메테우스 서비스와 EC2 인스턴스의 크기 때문이었는데, 더 나은 방식을 찾다가 결국 비용 효율적인 플랫폼을 활용해보자는 생각으로 우선 AWS에서 벗어났다.

그렇게 AWS 콘솔을 빠져나와서 다른 기술 블로그 선배님들은 어떤 방식으로 배포하였는지 리서치를 시작했다.

Vercel

그렇게 찾아본 것이 바로 Vercel.

Vercel은 React 기반의 SSR 프레임워크인 Next.js를 개발한 회사로 많이 알려져있다. Next.js 애플리케이션을 쉽게 배포하고 관리할 수 있는 플랫폼인 Vercel은 서버리스 환경을 제공하고 CI/CD까지 자동화 지원을 해주어 코드 변경 시마다 자동으로 배포를 수행한다. 실제로 기술 블로그를 직접 배포한 선배님들 중에서는 Vercel을 활용한 사례가 적지 않았다.

Serverless Deployment : Vercel은 서버리스 방식으로 애플리케이션을 배포하기 때문에 리소스 관리를 신경 쓸 필요없이 애플리케이션의 각 경로가 독립적인 함수로 실행된다.

Vercel 문서를 찾아보면서 느낀 장점과 단점은 다음과 같다.

vercel: 프로젝트 생성 과정에서 Git 연동

장점:

빠른 배포 및 간단한 설정: Vercel은 Next.js와 긴밀하게 통합되어 있어 손쉽게 애플리케이션을 배포할 수 있다. Github 연동을 통하여 Vercel 사이트를 통해서 Git 리포지토리를 만들 수 있고, Vercel이 자체적으로 사용자들의 니즈에 따라 블로그면 블로그, 쇼핑몰이면 쇼핑몰 등 여러 퀄리티 좋은 템플릿들을 제공해준다. 디자인은 생각보다 공수가 많이 드는 영역이라 상당히 감탄스러웠다.
자동화된 CI/CD: Git 저장소와의 자동 연동으로 코드 업데이트 시마다 즉각적인 빌드와 배포가 가능하다.
서버리스 아키텍처: 서버나 인프라 관리에 신경 쓸 필요가 없다. 일부 템플릿은 데이터베이스에 대한 스팩도 기입되어있는 것을 보기도 했다.

vercel: 제공되는 템플릿

단점:

비용: 개인 프로젝트나 소규모 블로그 운영에는 적합할 수 있으나, 트래픽이 많아질 경우 비용이 증가한다.
제한된 서버 환경: 소규모나 특정 용도를 제외하고는 서버리스이기 때문에 확장을 위해서는 한계점을 가진다.

Vercel을 찾고 직접 웹을 배포했을 때에는 눈이 돌아갈 정도로 간편해서 문서를 읽어보다가 조금씩 콩깍지가 벗져겼다. 먼저, 이미 작성된 코드를 수정하는 것보다 내가 직접 처음부터 짜는 공수가 더 효율적이여보였다. 템플릿이 제공된다는 장점이 있으나, 이미 제공되는 기술스택을 마이그레이션해야한다는 번거로운 일이 발생한다. 그리고 무엇보다 이 블로그를 길게 보는 관점에서는 굉장히 제한적인 플랫폼이다. 결국 나는 나중에 코멘트, 피드백과 같은 여러 서버와 통신할 사이트를 만들고 싶은데 이를 위해서 백엔드와 데이터베이스를 붙여야하고, 결과적으로는 인프라 환경을 구축할 수 있는 확장성을 가진 플랫폼을 선택하기로 했다.

AWS Amplify

AWS에서 제공해주지만 내가 모르는 기능에 대해 먼저 찾아보았다. 프론트와 백을 각각 어떻게 배포하도록 제공해주는지 알아본 결과, 프론트엔드는 Amazon CloudFront, Amplify, 백엔드는 AWS Lambda와 API Gateway, 데이터베이스는 RDS 또는 DynamicDB를 지원한다. 즉, 내가 원하는 프론트/백 모두 자유도 높게 개발/배포가 가능하다는 것.

Amplify vs CloudFront

Amplify를 에 대한 장점을 요약하면 다음과 같다.

자동화된 CI/CD: Amplify는 Git과 연동해 코드 푸시 시 자동으로 빌드 및 배포가 이루어지지만, CloudFront는 CI/CD 기능이 없어 추가 설정이 필요하다는 강력한 차이점이 있다.
백엔드 서버와의 통합: Amplify는 Lambda, GraphQL API 등 서버리스 백엔드를 쉽게 연결할 수 있지만, CloudFront는 CDN 역할에 집중되어 백엔드 통합을 직접 구현해야 한다.
자동 스케일링: Amplify는 트래픽 증가에 따른 스케일링을 자동으로 처리해 관리 부담이 적다고 하다. 이 부분은 현재 직접 경험해본 바가 없어서 추후에 확인히 되어보인다.

aws : amplify 배포중..!

현재 두 번째 게시글을 포스팅하고 있는 시점에서, Amplify에 대한 장점을 굉장히 체감하는 중이다. 물론 Github Action으로 구현해보는 CI/CD는 아직 경험하지 못하였으나 git push를 때리면 자동으로 배포해주는게 얼마나 편리한건지 느끼는 중이다.

이렇게 연휴 동안 EKS, Vercel, Amplify를 모두 비교해보며 블로그 배포 방법을 고민하였다. 이 과정을 통해서 최종적으로는 AWS Amplify로 배포하게 되었는데, 기술적으로 깊이 있게 다룬 포스팅은 아니지만 방향성을 잡는 과정에 대한 기록이라는 의미를 두며 여러 고민거리가 흐려지기 전에 빠르게 기록해보았다.