웹 페이지 구성 방식과 렌더링 방식에 대해 정리한 포스트 입니다.
해당 포스트를 읽으면 CS지식은 물론이고 요즘 트렌디한 Next.js를 왜 쓰는지에 대한 배경 지식도 학습이 가능 합니다.
틀린점이나 아쉬운 부분이 있다면 지적을 해주시면 매우 감사하겠습니다.
MPA(Multi Page Application), SPA(Single Page Application)는 웹 페이지의 구성 방식이고
CSR(Client-side Rendering, SSR(Sever-side Rendering), SSG(Static Site Gentation), ISR(Incremental Static Regeneration)은 렌더링 방식입니다.
1. 웹 페이지 구성 방식
MPA와 SSR을 동일시하거나, SPA와 CSR을 동일시하는 경우가 많지만 그렇지 않습니다.
SPA에서도 SSR을 사용할 수 있고, MPA에서도 CSR을 적용하는 방식이 불가능하지는 않습니다.
하지만 일반적으로 MPA는 SSR로, SPA는 CSR로 구현되는 경우가 많기에
MPA는 SSR렌더링 방식을 사용하고, SPA는 CSR렌더링 방식을 사용한다고 가정하고 설명하겠습니다.
1.1 MPA
MPA(Multi-Page Application)는 전통적인 웹 페이지 구성 방식입니다.
- 각 페이지마다 별도의 HTML 파일이 존재합니다.
- 사용자가 페이지를 이동할 때마다 서버에서 새로운 HTML을 요청하고 전체 페이지가 새로고침됩니다.
- 렌더링 방식은 주로 SSR로 구현이 됩니다. [ SSR 렌더링 방식의 설명은 추후 설명 ]
MPA 웹페이지의 가장 큰 장점은 다음과 같습니다.
1 : 검색 최적화(SEO)에 유리
- 서버에서 완성된 HTML을 반환하므로 검색 엔진 크롤러가 콘텐츠를 쉽게 크롤링 할 수 있습니다.
- 각 페이지는 독립적인 URL을 가지므로 SEO 전략이 효율적입니다.
2 : 빠른 초기 로딩
- 초기 요청 시 서버에서 완성된 HTML을 바로 반환하기 때문에 빠르게 콘텐츠를 렌더링할 수 있습니다
MPA 웹페이지의 단점은 다음과 같습니다
1 : 페이지 전환 속도 느림
- 페이지 전환 시마다 전체 페이지가 새로고침되기 때문에 사용자 경험(UX)이 떨어질 수 있습니다.
2 : 서버 부하 증가
- 매번 새로운 페이지를 서버에서 렌더링해야 하므로 서버의 부하가 커집니다.
- 사용자가 페이지를 많이 이동할 경우, 서버 요청이 많아집니다.
1.2 SPA
SPA(Single-Page Application)는 클라이언트 측에서 동적으로 페이지를 렌더링하는 방식입니다.
- 하나의 HTML 파일로 전체 애플리케이션을 구성합니다.
- 페이지 전환 시 서버에서 새로운 HTML을 요청하지 않고, JavaScript를 사용해 클라이언트에서 필요한 부분만 동적으로 교체합니다.
- 초기에 필요한 리소스(JS, CSS 등)를 모두 로드한 후, 이후 페이지 이동은 클라이언트에서 처리됩니다.
- 렌더링 방식은 보통 CSR(Client Side Rendering) 방식이 기본입니다.
AJAX로 클라이언트는 필요한 데이터만 서버를 통해 비동기적으로 받고, 페이지의 일부만 동적으로 업데이트 할 수 있다.
SPA 웹페이지의 가장 큰 장점은 다음과 같습니다.
1 : 빠른 페이지 전환
- 새로운 HTML을 요청하지 않고, 이미 로드된 리소스(JS, CSS)로 필요한 부분만 업데이트하므로 페이지 전환 속도가 빠릅니다. 따라서 부드러운 사용자 경험(UX)에 긍정적 경험을 제공 합니다.
2 : 성능 최적화 유리
- 초기 진입 시 필요한 모든 리소스를 한 번에 로드하지만, 이후에는 필요한 데이터만 요청합니다.
- 캐싱을 활용하여 서버 요청 횟수를 줄이고, 빠르게 콘텐츠를 제공할 수 있습니다.
SPA 웹페이지의 단점은 다음과 같습니다.
1 : SEO(검색 엔진 최적화)문제
- 클라이언트 측에서 페이지가 렌더링되기 때문에, 검색 엔진 크롤러가 콘텐츠를 제대로 인식하지 못하는 경우가 발생합니다.
다만, 구글이나 네이버같은 포털 사이트는 자체엔진을 통해 SPA로만 이루어진 페이지도 크롤링 할 수 있게 합니다.
2 : 초기 로딩 속도 지연
- 초기 진입 시 모든 리소스(JS, CSS 등)를 한 번에 로드하기 때문에 초기 로딩 시간이 길어질 수 있습니다.
2. 웹 페이지 렌더링 방식
2.1 SSR
SSR(Server Side Rendering)은 서버에서 사용자 요청마다 HTML을 동적으로 렌더링해 클라이언트에 전달하는 방식입니다.
클라이언트는 이를 즉시 렌더링해 빠르게 페이지를 표시할 수 있지만, 상호작용을 위한 JavaScript는 아직 로드되지 않은 상태입니다.
따라서 TTV(Time To View)는 굉장히 빠를 수 있지만, TTI(Time To Interact)와 간격이 존재합니다.
이는 사용자가 페이지를 빨리 보더라도, 실제로 클릭, 입력 등과 같은 상호작용이 지연될 수 있다는 의미입니다.
TTV(Time To View) : 사용자가 웹사이트를 보는데까지 걸리는 시간
TTI(Time To Interact) : 사용자가 웹 상호작용이 가능하기까지 걸리는 시간
웹 페이지 성능 관점에서 TTV만 빠르고 TTI가 매우 느리다면 사용자 경험에 매우 좋지 않기 때문에 여러가지 최적화 기법을 사용하는것을 고려해야합니다.
- Hydration을 점진적으로 수행하여 중요한 컴포넌트부터 활성화 시키기
Hydration : SSR,SSG,ISR 방식에서 초기 HTML은 정적인 상태입니다.
이 정적인 페이지에 동적이고 인터랙티브한 상태로 전환시키는 과정을 Hydration 이라고 합니다
메말라있는 페이지에 수분공급을 해준다고해서 Hydration이라고 생각하면 편한것 같습니다.
SSR은 SEO에서 매우 유리합니다. 서버에서 완성된 HTML을 즉시 반환하기 때문입니다.
이는 검색 엔진 크롤러가 JavaScript 실행 없이도 페이지 콘텐츠를 바로 인식하고 인덱싱할 수 있다는 의미입니다.
SSR은 언제 쓰는게 좋을까요?
Case1 ) 실시간 데이터가 필요한 경우
- 주식 차트, 부동산 거래 정보등 데이터가 자주 변경되어 실시간 정보가 필요할 때
Case2 ) 사용자마다 다른 데이터를 제공해야 하는 경우
- 사용자의 위치에 따라 다른 날씨 정보를 보여주는 페이지를 보여줘야 할 때
Case3 ) SEO가 중요한 페이지
- 전자상거래 페이지, 기사 페이지 등 검색 엔진에서 이점을 챙겨야 할 때
2.2 CSR
CSR(Client Side Rendering)은 초기 HTML을 클라이언트(브라우저)에서 JavaScript로 동적으로 렌더링하는 방식입니다.
서버는 최소한의 HTML(껍데기)을 반환하고, 클라이언트에서 JavaScript를 다운로드해 실행하여 콘텐츠를 렌더링합니다.
따라서 JavaScript가 실행되고 로드될때까지 페이지가 빈 상태이기 때문에 TTV까지의 시간이 있습니다. 이는 사용자가 페이지가 로드 되기 전까지 빈 화면을 계속 봐야한다는 의미입니다.
하지만 화면에 보여짐과 동시에 상호작용이 가능하기 때문에 TTV와 TTI는 거의 동일 합니다.
웹 페이지 성능 관점에서 사용자에게 빈 화면을 오랫동안 보여주는것은 사용자 경험에도 좋지않고 이탈률이 증가할 수 있으므로 코드 스플리팅이나 콘텐츠 비동기 로드 등 최적화 기법을 사용하는것을 고려해야합니다.
CSR은 SEO에서 매우 불리합니다. 초기 HTML이 비어있거나 최소한의 구조만 포함되어 있고, JavaScript가 실행된 후에야 페이지의 콘텐츠가 동적으로 렌더링되기 때문입니다. 이로 인해 검색 엔진 크롤러는 제대로 크롤링을 하지 못할 가능성이 높습니다.
CSR은 언제 쓰는게 좋을까요?
Case 1 ) SEO가 중요하지 않은 페이지
- 회원 전용 서비스 페이지, 프로필 페이지, 웹 애플리케이션 내부 기능 처럼 SEO가 필요 없을 때
Case 2 ) 인터랙티브한 요소가 많은 페이지
- 소셜 미디어를 예를 들어 댓글이나 좋아요를 눌러도 전체 페이지가 리로드 되지 않고 필요한 부분만 동적으로 업데이트 하는것이 필요 할 때
2.3 SSG
SSG(Static Site Generation)는 웹 개발에서 웹 페이지를 빌드 시점에 미리 생성하여 정적인 HTML 파일로 제공하는 방식입니다.
SSG 작동 방식
1.빌드 단계에서 HTML 생성 : 웹사이트는 소스 코드와 데이터를 기반으로 빌드 시점에 모든 페이지를 생성합니다.
2.배포 : 생성된 정적 파일(HTML, CSS, JavaScript)을 서버나 CDN에 배포합니다.
3.사용자 요청 : 사용자가 페이지를 요청하면 서버는 이미 생성된 HTML 파일을 즉시 반환합니다.
이미 모두 그려진 정적 파일을 제공 하기 때문에 렌더링 방식중에서 성능이 가장 좋습니다.
하지만 데이터들이 빌드 기준이기 때문에 변경이 잦은 페이지들은 SSG를 고려하지 않는편이 좋을 것 같습니다.
SSG는 SEO에서 매우 유리합니다. 페이지가 빌드 시점에 정적인 HTML 파일로 미리 생성되기 때문에, 크롤링에서 최적화된 환경이 갖춰 집니다.
SSG는 언제 쓰는게 좋을까요?
Case 1 ) 실시간 데이터 반영이 필요없는 페이지
- 데이터가 실시간 반영이 필요가 없는 마케팅 페이지, 포트폴리오 페이지, 문서 사이트 처럼 정적 요소를 가질 때
2.4 ISR
ISR(Incremental Static Regeneration)은 SSG의 단점인 데이터 갱신 문제를 해결하기 위해 도입된 방식입니다.
ISR은 정적인 페이지를 필요할 때마다 부분적으로 재생성 하는 방식입니다.
SSG의 동작 방식은 다음과 같았습니다.
1.빌드 단계에서 HTML 생성 : 웹사이트는 소스 코드와 데이터를 기반으로 빌드 시점에 모든 페이지를 생성합니다.
2.배포 : 생성된 정적 파일(HTML, CSS, JavaScript)을 서버나 CDN에 배포합니다.
3.사용자 요청 : 사용자가 페이지를 요청하면 서버는 이미 생성된 HTML 파일을 즉시 반환합니다.
여기서 한가지가 추가됩니다. 페이지에 시간을 설정하고, 시간이 되었다면 페이지는 새롭게 재생성 됩니다.
4.페이지 재생성 : 페이지가 일정 시간이 지나 새로운 데이터를 기반으로 새로운 페이지로 재 생성됩니다.
정적 사이트임에도 불구하고 실시간 데이터가 반영이 가능하다는 큰 장점을 가지고 있습니다.
당연히 정적 사이트라서 초기 로딩 속도는 빠르고, SEO에도 유리합니다.
또한 지속적으로 서버에 요청을 하는것이 아니라 일정 시간마다 갱신이 되는것이기 때문에 서버 부담도 크지 않습니다.
SSG는 언제 쓰는게 좋을까요?
Case 1 ) 데이터가 변경은 되지만, 실시간은 필요가 없는 경우.
- 블로그 페이지, 뉴스 페이지
Case 2 ) SEO가 중요하고, 데이터 갱신도 필요한 경우
- FAQ 페이지, 이벤트 페이지
3. 웹페이지 구성 방식과 렌더링 방식의 흐름 (with next.js)
아주 예전에는 정말 전통적인 MPA방식으로 웹페이지를 구성 했었습니다.
예를 들어 댓글 하나를 사용한다고 하면 전체 페이지가 새로고침되는 현상이 말이죠.
인스타그램을 저런 MPA방식으로 구현 했다고 가정해볼까요?
case1 => 친구의 게시글을 좋아요를 누르면 새로고침이 됩니다.
case2 => 친구의 게시글에 댓글을 달면 새로고침이 됩니다.
사용자 경험에 매우 안좋아 보입니다. 또한 많은 사용자가 사용할때 서버에도 많은 과중을 떠안게 됩니다.
이런 사용자 경험과 불필요한 리소스를 재요청하고 데이터 전송의 비효율성을 조금 더 보완하고자 AJAX이 도입이되어 새로운 HTML을 생성하지 않는 JSON 형태로 응답을 하게 됩니다.
여기서 더 나아가서 React,Vue 같은 프레임워크의 등장하며 사용이 더 쉬워지게 되었습니다.
하지만 CSR을 기반으로하는 SPA의 특성중 가장 큰 문제는 SEO에 매우 불리합니다. 아무리 구글이나 네이버의 크롤러가 SPA로 구현된 웹페이지의 인덱싱이 가능하게끔 기술을 적용한다고 해도 MPA의 많은 페이지를 인덱싱하는 것과 비교 했을때 불리한것은 자명하기 떄문입니다.
그렇다면 여러가지 렌더링 방식을 섞어서 사용 할 수 없을까요?
Next.js(Nuxt.js)
물론 Next.js를 사용했을때 다양한 렌더링 방식을 지원한다는 것 외의 장점은 많긴 합니다.
더욱 더 쉬운 라우팅 기법(폴더 기반 자동 라우팅), 라이브러리를 통한 쉬운 회원 인증 기능(Next-auth) 등
그렇지만 가장 큰 장점을 꼽아 보라고 하면 역시 다양한 렌더링 방식을 통해 각 상황에 맞게 적용 할 수 있다는점이 제일 큰 것 같습니다.
Next.js는 Pre-rendering 기법을 적용하여 SSR이나 SSG(또는 ISR)를 통해 서버에서 완성된 HTML을 제공하고, 각 페이지의 특성에 따라 SSR, SSG(ISR), CSR 등 다양한 렌더링 방식을 페이지별로 유연하게 적용할 수 있습니다.
- 로그인 및 회원가입 또는 장바구니 페이지는 SEO에 최적화 될 필요가 있을까요? 이런 경우에는 굳이 SSR을 고집할 필요가 없을것 같습니다.
- SEO에 중요한 뉴스페이지, 블로그 페이지, 제품 페이지 등 SEO가 최적화 될 수록 좋은 카테고리들 입니다. 이런 경우 CSR보다는 SSR또는 SSG(또는 ISR)이 좋아 보입니다.
정리하자면 사용자가 페이지에 접속할 경우 다음과 같은 흐름을 가지게 됩니다.
1. 첫 번째 단계 – Pre-rendering (사전 렌더링)
- 사용자가 페이지에 접속하면 SSR(서버사이드 렌더링) 또는 SSG(정적 사이트 생성)을 통해
미리 생성된 정적 HTML 페이지가 반환됩니다. - 이 단계에서는 자바스크립트 없이도 페이지가 즉시 렌더링됩니다.
- 페이지가 빠르게 로드되고, 검색 엔진 최적화(SEO)에도 유리합니다.
2. 두 번째 단계 – Hydration (수분화)
- 브라우저에서 자바스크립트가 실행되면서, 정적 HTML에 React가 연결됩니다.
- 이 과정을 통해 버튼 클릭, 폼 입력 등 동적인 상호작용이 활성화됩니다.
- Hydration이 완료되면 페이지는 완전히 인터랙티브한 상태가 됩니다.
결국 Next.js는 SSR, ISR, CSR 등 다양한 렌더링 방식을 통해 유연하게 웹 페이지를 구성할 수 있습니다.
A페이지(SSR), B페이지(ISR), C페이지(CSR)와 같이 서로 다른 방식으로 구현된 페이지 간에도,
Next.js의 라우터는 SPA처럼 부드럽게 전환되며, 사용자 경험을 저해하지 않고 자연스러운 client-side 페이지 이동을 할 수 있습니다.
4. 마치며
이번 포스트에서는 웹 페이지 구성 방식과 다양한 렌더링 방식에 대해 학습했습니다.
프로젝트의 페이지 특성에 맞는 렌더링 방식을 선택하고 구현하는 것이 중요하다는 점을 느낄 수 있었습니다. 이를 통해 성능 최적화, SEO 강화, 사용자 경험 개선 등 여러 측면에서 프로젝트에 유연하게 대응할 수 있을 것입니다.
특히, Next.js는 다양한 렌더링 방식을 손쉽게 적용할 수 있도록 지원하는 프레임워크라는 점에서 큰 매력을 느꼈습니다.
