💡 사실 GCP나 Azure에도 좋은 기능들이 많이 존재하는데, 궁금하다면 꼭 따로 알아보자~
글에 앞서서,
아티팩트: CI/CD 파이프라인에서 각 단계를 거친 뒤 다음 단계를 넘어갈 준비가 된 코드 묶음을 일컫습니다.
번들링: 개발 생산성 등을 위해 흩어져 있던 파일과 코드들을 압축, 난독화 등을 통해 하나로 묶는 것. 이때 생성된 아티팩트를 코드 번들이라고 말합니다.
트랜스파일링: 특정 언어로 되어 있는 코드를 다른 언어로 변환하는 작업. 프론트엔드의 경우 TS → JS 의 과정을 주로 말합니다.
컴파일링: 특정 언어를 기계가 이해할 수 있는 바이너리 코드로 변환하는 작업.
빌드: 소스 코드를 실행 가능한 형태로 변환하는 과정. 일반적으로 컴파일 이후에 수행하는 작업.
그러나 애플리케이션 개발에서 흔히 빌드는 위의 모든 과정들을 통합하는 과정으로 이해된다. 따라서 아래 글에서도 코드를 빌드한다 ⇒ 위에서 필요한 과정들을 거쳐 소스코드가 실행 가능한 형태로 변환되는것으로 이해하면 좋을 것 같다.
Client-Side Rendering Based(Static Site)
💡 동적으로 HTML을 생성해서 제공하는 서버가 존재하지 않고, 순수 HTML + CSS + JS 파일들을 제공하는 경우 사용 가능합니다.일반적으로 SSR을 사용하지 않은 채 번들링을 하거나, Next.js의 output: 'export' 옵션을 사용하는 경우 추출되는 정적 파일을 아티팩트로 사용합니다.
S3 + Cloudfront
Static Site 제공을 해야한다면 Cloudflare Page와 함께 가장 먼저 떠오르는 방법
단점이라면 Cloudflare Pages에 비해 Data transfer 비용을 감수해야한다. 관련하여 다음을 참고.
https://aws.amazon.com/ko/s3/pricing/
도메인과 관련한 작업이 필요한 경우 가장 베스트라고 생각한다(Route53을 DNS로 사용).
- 가장 기본적이고 심플한 정적 파일 배포 방법
- S3: 코드 번들을 저장하는 저장소
- Cloudfront: CDN을 제공 (이외에 다양한 기능이 있으나, 가장 주된 기능)
- CDN을 사용하지 않는다면 S3 Public Access만으로도 구현할 수 있음
- S3 Object Lambda 와 같은 기능을 이용해서 프록시 설정이 가능함 (Lambda@Edge 활용)
- Cloudfront를 이용한다면 OAC를 적극 활용하기. OAI는 deprecated
- 모든 AWS 리전에서 S3 접근 – OAC는 기존 리전과 향후 추가될 모든 리전을 포함한 모든 AWS 리전에서 S3에 접근하는 것을 지원합니다. 반면 OAI는 기존 AWS 리전과 2022년 12월 이전에 출시된 리전에서만 지원됩니다.
Amplify
Vercel과 비슷한 기능들을 제공해주려고 노력하는 모습이 멋진 서비스…(?)
Amplfiy 백엔드까지 활용하면 풀스택 애플리케이션을 빠르게 만들어낼 수 있다.
- S3 + Cloudfront를 제공하는 AWS 자체 서버리스 서비스.
- 위의 장점을 모두 가져가고, 서버리스 서비스인 만큼 관리가 확실히 된다.
- 이외에도 개발 생산성을 위한 pr review와 같은 기능들을 많이 제공한다. 핵심적으로 제공하는 기능들이 Vercel과 유사하지만, 개인적으로는 Vercel의 사용자 경험이 조금 더 낫다. 그래두 AWS 기반 아키텍쳐에서는 충분히 활용하기 좋다.
- 프로덕션에서 쓰기는 좀,,,(단점은 아래에서). 주된 배포 플랫폼으로 사용되는 실 사례를 보기 어려웠다.
Vercel
사용자 경험이 매우 좋은 플랫폼. 개인 작업인 경우 사용하기 매우 좋다.
- 사용자 경험을 비롯한 전반적인 서비스만 보면 프론트엔드 배포 플랫폼이 나아가야할 방향이라고 생각한다.
- 개인 계정에 한해 무료로 매우 좋은 기능들을 활용할 수 있고, 사용자 경험이 좋아 간단한 개인 프로젝트 배포 용으로 자주 사용함.
- 팀 계정부터 비쌈…
- Storage 서비스나 KV 등등 Cloudflare와 유사하게 기능들을 제공해준다. 기능 자체로 보면 매우 뛰어난 편.
- CDN 서비스를 제공하지만, Cloudfront나 Cloudflare 만큼 서비스를 제공하지는 않고 세세하게 컨트롤 하기 어렵다.
Cloudflare Pages (Cloudflare R2 + Worker,,,)
마찬가지로 Static Site제공시 가장 먼저 떠오르는 방법
단점이라면 Enterprise 이상의 플랜이 아닌 경우 도메인과 관련한 작업에서 상당한 제약이 걸린다. 이 때 Cloudflare 생태계에 조금 격리되는 느낌이 개인적으로 들었다…
그게 아니라면 Cloudflare 네트워크를 포기해야한다.도메인과 관련한 작업이 들어가지 않는다면, 베스트 옵션이라고 생각된다.
-
기본적이고 심플한 정적 파일 배포 방법
-
Cloudflare의 강력한 네트워크 베이스를 누릴 수 있다.
-
Free Plan으로도 강력한 기능들을 많이 누릴 수 있다.
-
Cloudflare Pages가 많이 활성화되지 않았을 때에는 R2를 활용하는 의견도 있었지만, 지금은 Pages만으로도 충분히 좋은 서비스를 제공할 수 있다.
-
이외에도 Cloudflare에 있는 Worker, R2, KV 등을 연계하여 사용하기 시작하면 빠져나오기 어렵다..(물론 KV 대신 DAX 쓰면 되긴 하다)
Other
Netlify
- 사실 사용한지 조금 오래되었다…
- 최근에도 사용 중이신 분들 후기 남겨주세요…
Server-Side Rendering Based
💡 위에서 다룬 Static Site 이외에 사용자의 요청을 기반 동적으로 코드를 생성하여 제공하는 방식.💡 동적으로 제공할 문서를 제작하기 위한 서버가 구동되어있어야한다.
일반적인 Next, Remix, Nuxt 와 같은 프레임워크에서 제공하는 서비스.
Cloudflare Page ( + Cloudflare Worker )
SSR이 필요한 경우를 비롯해 거의 대부분의 경우 개인적으로 가장 베스트
도메인 관련 디테일한 작업이 필요하거나, Cloudflare에 격리되지 않은 도메인 제공이 필요한 경우를 제외하고 가장 좋다.
만일 도메인에서 자유롭고 싶다면 지갑을 열자.
-
정확히 말하면 기존의 Cloudflare Page를 통해 Static Site를 제공하고, SSR이 필요한 부분에서 내부적으로 Cloudflare Worker가 동작하여 파일을 제공하는 형태. 아래 글을 참고하면 초기애는 Static Site만 제공하는 형태에서 Worker를 통합하여 SSR을 지원하기 시작했음을 알 수 있다.
-
굳이 Next.js와 같은 프레임워크를 사용하지 않더라도,
renderToPipeStream과 같은 react server API들을 활용해 직접 SSR을 구현하는 경우에는 Cloudflare Worker를 적극 활용하면 좋다. -
이외에도 앞서 언급한 것처럼 Cloudflare KV를 연계하거나 CDN 관련 세부 설정들(SSL, HSTS,,,)을 다룰 수 있는 것이 매우 큰 이점으로 다가온다.
-
단점이라면, Next.js 14 를 배포하는데 마주한 문제가 꽤 있다는 점. Next.js에서 아직 최적화를 못 해서 발생하는 문제다.
-
아직 Next.js 14를 Edge runtime으로 배포하는 과정에서 opengraph-image를 불러오지 못하던 문제가 해결되지 않아 못 쓰는 중.
Vercel
Next.js 배포하기 매우 좋다.
TurboRepo 기반 Next.js 모노레포를 배포하기 매우 좋다.자사 제품과의 호환이 잘 되고, 자사 제품이 뛰어난 성능을 가졌기에 좋게 평가한다.
마찬가지로 개인 프로젝트에서 사용하기 좋고, 이외에는 지갑을 열자
-
도메인과 관련한 세세한 작업 등을 해야하는 경우(와일드카드 등,,,) DNS 이전이 필요한 경우가 생기는데, 그러한 경우를 빼면 나쁘지 않다.
-
Next.js 개발사인 만큼 Next.js 나 TurboRepo를 배포하는 과정에서의 사용자 경험이 무시하지 못할 정도로 좋다.
-
커밋마다의 배포, 테스팅, PR Preview 등등 개발자 친화적인 기능들을 매우 많이 제공한다. 이외에도 기타 설정들이나 웹훅 등 부가적인 기능에서 나쁜 사용자 경험을 느낀 적이 거의 없었다.
-
개인적으로 플랫폼 엔지니어링의 선두주자 느낌. Lee Robinson 의 회사는 역시 다르다…
-
Cold Start 문제가 없는 것은 아니다. 그러나 Edge Function 등의 기능을 통해 해결하고자 노력한다. 어차피 팀 플랜은 비싸니 프로덕션으로는 안 쓰,,,
Lambda@Edge (Lambda + Cloudfront)
조금 더 큰 번들의 코드를 배포할 수 있는 Cloudfront Function 느낌
DNS를 Route53에 두고 있거나 AWS 리소스를 적극 활용하고자 할 때 사용하기 좋다.
-
서버리스 서비스의 나름 근본..?
-
Next.js, Nest.js 등등 다양한 서버를 온디맨드로 비용을 청구하면서도 CDN의 이점까지 누릴 수 있어 좋은 서비스라고 생각하며 자주 사용함.
-
단점이 있다면, 도커 기반 런타임은 제공하지 않는 기능이어서 직접 코드를 업로드해야한다.
-
Lambda Layer를 활용하면 더욱 무겁거나 다각화된 작업들도 수행할 수 있다.
-
AWS 리소스를 연동하기 매우 좋다.
-
굳이 단점이라면 GCP의 Cloud Function은 Public HTTP 트리거를 제공하는데, Lambda는 그렇지 않아서 API Gateway나 Cloudfront를 연동해야한다…
-
또한 Cold Start를 신경써야하는 부분이 있으나, 앞단에 CDN이 있기도 하고 프로비저닝된 동시성 등 옵션이 다수 존재.
Lambda + API Gateway ( + Cloudfront )
API Gateway 를 이용해 여러 개의 Lambda 함수 혹은 서비스들을 함께 제공하고자 할 때 사용
-
API Gateway를 이용해 리버스 프록시를 구현하고 트래픽을 Lambda로 전달하는 방식
-
Lambda@Edge와 더불어 Lambda를 배포하는 가장 전형적인 방식이다.
-
마찬가지로 Lambda Layer를 활용하면 무거운 애플리케이션도 배포할 수 있다.
-
위의 옵션과 마찬가지로 Cold Start를 신경써주어야한다.
Amplify
자잘하거나 치명적인 문제가 있어,,,개인적으로 프로덕션 배포에서는 피한다.
이외에 여러 툴들 사용을 위해 개발 환경 배포는 할만 한 듯 하다.
-
Vercel처럼 손쉽게 Next.js 기반의 SSR 애플리케이션을 배포할 수 있고, 다양한 기능을 제공한다.
-
기본적인 WAF나 액세스 제어 등의 설정은 참 좋다...
-
단점이라면 성능모드 활성화 시 캐시 초기화가 되지 않고, 이를 Cloudfront 콘솔 등에서 세세하게 관리할 수가 없다. 전략도 설정하기 어렵다(Amplify 내부적으로 S3 + Cloudfront를 사용하는데, Cloudfront 관련 설정을 직접 하지 못한다…). 프로덕션 배포에 사용하기 꺼려지는 것이 사실이다.
Cloudfront Function
AWS 버전의 Cloudflare Worker
간단한 기능을 하는 함수를 배포하기 좋다.
- 프론트엔드 애플리케이션을 배포하는 용도라기 보다는, 프록시와 같은 설정을 위해서 Cloudflare Worker와 비슷한 용도로 사용한다.
- 사실 둘 중 뭐 쓸거냐고 하면 특수한 상황이 아니면 Cloudflare Worker를 쓸 것 같다.
App Runner(Google cloud run)
-
사실 나는 Google Cloud Run는 자주 사용했지만(GCF가 Gen2로 넘어오면서 cloud run 연계가 잘 되는 것이 한 몫 했다), App runner또한 매우 좋은 완전관리형 서비스임에는 틀림없다.
-
Cloudfront 연결해서 쓰면 되겠지만, 내가 안 익숙하다는 이슈로 사용 경험이 거의 없는 서비스
-
좋은 사용 경험을 가지신 분들은 공유 부탁드립니다.
EC2, ECS, EB,,, etc.
기본적으로 SSR은 서버만 있으면 된다. 서버를 띄울 수 있는 어떤 옵션들도 사용 가능하다.
- 도커라이징 된 서비스의 경우는 ECS에도 많이 배포하는 것 같다.
- 손수 SSR을 수행하는 서버를 띄운다.
- 위의 서비스들을 잘 알고 있다면 충분히 사용할만하다!
Conclusion
위에서 언급하는 서비스들을 제공하는 회사들 모두가 영리 기관이기 때문에,지속적으로 업데이트를 진행해 경쟁력을 가져가고자 노력하고 있다.
따라서 본 글의 내용들은 주기적으로 업데이트 될 예정이므로, 틀렸거나 수정이 필요한 내용이 있다면 언제든지 댓글 혹은 kand1002@naver.com 으로 연락 부탁드립니다.
