프론트엔드 프레임워크계의 춘추 전국 시대가 열렸습니다.
각 프레임워크들은 렌더링 방식으로 분류할 수 있습니다.
어떤 렌더링 방식이 있는지 해당 렌더링에 맞는 인프라는 무엇이 있는지 살펴보겠습니다.
프레임워크
우선 프레임워크부터 살펴보겠습니다.
위키백과에서는 프레임워크를 다음과 같이 정의하고 있습니다.
"컴퓨터 프로그래밍에서 소프트웨어 프레임워크는 복잡한 문제를 해결하거나 서술하는 데 사용되는 기본 개념 구조이다. 간단히 뼈대, 골조, 프레임워크라고도 한다. 이렇게 매우 폭넓은 정의는 이 용어를 버즈워드로서, 특히 소프트웨어 환경에서 사용할 수 있게 만들어 준다." - 위키백과, 소프트웨어 프레임워크
개발자는 다음과 같은 욕망들에 마주하게 됩니다.
HTTP 모듈을 정형화하여 API를 작성하고 싶습니다.
컴포넌트 방식의 UI를 작성하고 싶습니다.
개발자는 만들고 싶은 것은 제로부터 쌓아올릴 수 있지만, 다른 개발자의 개발물에 덧대어서 쌓을 수 있습니다.
이런 관점에서 본다면 라이브러리와 프레임워크는 비슷하게 보입니다.
하지만, 구현의 위치가 다릅니다.
예를 들어, CRA를 사용하여 프로젝트를 시작하면 그 위에 다른 개발물을 쌓아올려야합니다.
antd 같은 디자인된 컴포넌트 라이브러리는 우리가 구현해야할 결과가 이미 나타나 있습니다. (라이브러리는 구현체이기 때문에 추상체(래핑 or DI)를 통한 관리가 필요합니다. 이는 다음에 자세히 서술토록 하겠습니다.)
렌더링 방식과 프론트엔드 프레임워크
프레임워크들은 주로 언어 혹은 라이브러리에 결합됩니다.
메타 프레임워크라고도 불리는 react 라이브러리를 간단히 설명 드리자면...
html, css, js 를 이용한 개발은 페이지 단위의 개발 방식입니다.
페이지 단위의 개발 방식은 관심사의 분리가 되지 않아 유지보수에 어려움이 있었습니다.
react 라이브러리는 컴포넌트 단위로 개발하는데에 최적화 되어 있습니다.
CRA 는 이러한 react를 이용하여 시작할 수 있는 가장 쉬운 방식의 프레임워크입니다.
해당 프레임워크는 Single Page Application(이하 SPA), Client Side Rendering(이하 CSR) 의 특징을 가지고 있습니다.
SPA 와 CSR은 react 초기에 개발된 클래스형 컴포넌트의 라이프 사이클 메소드와도 잘 결합할 수 있는 특성입니다.
CSR 은 유저 입장에서 하나의 html 만 받아오니 이는 크롤링 봇들에게도 마찬가지였습니다.
CSR을 지원하지 않는 크롤링 봇들은 받아온 페이지에서 필요한 정보들을 분석하지 못한채 탐색 활동을 중단할 것입니다.
물론, CSR을 지원하는 크롤링 봇들도 있겠지만 그걸 알 수 있는 사람은 크롤링 봇을 개발한 사람만일 것입니다.
어느 크롤링 봇에게도 잘 보이기 위해 우리가 할 수 있는 것은 Search Engine Optimization(이하 SEO) 입니다.
SEO 를 위해 나타난 것이 Server Side Rendering(이하 SSR)과 Static Site Generation(이하 SSG) 입니다.
이 두가지의 공통점은 이미 html 을 그려서 사용자에게 주기 때문에 크롤링 봇 입장에서 분석하기 쉽다는 점입니다.
차이점은 언제 html을 생성하냐입니다.
SSR은 사용자의 요청이 들어올 때, html 을 생성합니다.
그래서 바뀌기 쉬운 정보들은 SSR 렌더링을 하는 것이 좋습니다.
커뮤니티 게시판이나 DB 와 연동된 장바구니 같은 페이지는 SSR 이 유리합니다.
SSG는 사용자의 요청이 들어오기 전, html 을 생성해놓습니다.
이는 사용자의 요청때 html 을 생성하는 비용을 소모하지 않는다는 장점이 있습니다.
바뀌지 않을 정보들이라면 SSG 렌더링을 하는 것이 좋습니다.
현재 보고 계시는 블로그 글이라던지, 신문 기사 같은 것들은 SSG 가 유리합니다.
여담으로 CSR, SSG 로 렌더링 해도 될 것 들을 SSR 로 할 수는 있지만 SSR 로 렌더링 해야하는 것은 CSR 과 SSG 로는 할 수 없습니다.
그래서, 추후 서비스가 어떻게 바뀔지 모르는 상태에서는 모든 렌더링을 포함할 수 있는 프레임워크를 사용하는 것이 좋겠습니다.
그럼 어떤 프레임워크를 써야하나?
두가지 관점에서 프레임워크를 결정할 수 있을 것 같습니다.
- SEO 가 잘 되어야한다.
- 정보가 자주 바뀐다.
1, 2 둘다 해당하면 SSR 프레임워크를 사용하시면 됩니다. (ex. Next, Nuxt 등)
1만 해당 하시면 SSG 프레임워크를 사용하시면 됩니다. (ex. Docusaurus 등)
1에 해당되지 않으면 CSR 을 사용하시면 됩니다. (ex. CRA, Vue 등)
아직 잘 모르겠다 하시면 나중에 변경비용이 적게 1, 2 둘다 지원가능하게 만드는 것이 좋겠습니다.
인프라
가장 배포하기 쉬운 방식은 CSR 과 SSG 입니다.
둘다 정적 파일만을 이용하기 때문에 정적 파일 서버를 통해 배포할 수 있습니다.
관련 클라우드 서비스로는 AWS S3, GCP CloudStorage, Azure Storage 등이 있습니다.
다만, 이러한 서비스는 정말 저장만을 위해 존재하기 때문에 사용자 경험을 위해 빠른 전송을 해야한다면 CDN 에서 전송되게 할 수 있습니다.
그러한 역할을 해주는 것이 AWS CloudFront, GCP CloudCDN, Azure CDN 등의 서비스가 있습니다.
반면에 SSR 은 html 을 그려주는 것 까지 해야하기 때문에 정적 파일 전송만으로는 배포할 수 없습니다.
그래서 컴퓨팅 자원을 소모해야하므로 AWS EC2, GCP ComputeEngine, Azure VirtualCompute 등의 서비스를 이용해야합니다. (혹은, serverless 서비스 를 이용하는 방법도 있습니다.)
이러한 컴퓨팅 자원은 한정된 자원을 가지고 있으므로 부하 분산을 위한 로드밸런싱을 구성할 수 있습니다.
또한, 각 프레임워크별 서버 listening 을 통해 대기하게 만들어주어야 합니다.
마무리
SSR 프레임워크를 사용할 때는 SEO, 자주 바뀌는 정보가 있을 때이며 컴퓨팅 관련 인프라가 필요합니다.
SSG 프레임워크를 사용할 때는 SEO, 안 바뀌는 정보가 있을 때이며 정적 파일 관련 인프라가 필요합니다.
CSR 프레임워크를 사용할 때는 그 외이며 정적 파일 관련 인프라가 필요합니다.
질문 사항이나 틀린 사항 있을 시 피드백 주시면 감사하겠습니다.