렌더링 방식의 차이

Introduction

웹 페이지의 HTML을 어디서, 언제 만들 것인가. 렌더링 방식의 선택은 결국 이 한 문장으로 요약된다. 서버가 매 요청마다 만들 수도 있고(SSR), 브라우저가 직접 그릴 수도 있고(CSR), 빌드 시점에 미리 만들어 둘 수도 있다(SSG). 이 선택은 초기 로딩 속도, 검색 노출, 서버 비용을 통째로 바꾸는데, 응답 하나를 만드는 데 수십 초가 걸리는 AI 서비스가 등장하면서 그 트레이드오프는 훨씬 날카로워졌다. 이 글은 다섯 가지 렌더링 방식의 원리를 정리한 뒤, 두 가지 실제 시나리오에 적용해 본다.

Server-Side Rendering (SSR)

그림 1. SSR의 동작 흐름.

SSR(Server-Side Rendering, 서버 측 렌더링)은 클라이언트의 요청이 서버에 도달하는 즉시 서버 환경(주로 Node.js)에서 애플리케이션 로직을 실행한다. 이 과정에서 필요한 데이터 페칭(data fetching)이 완료되어야만 HTML 생성을 마무리하고 응답을 보낼 수 있는 것이 전통적인 SSR의 특징이다.

SSR은 SEO(Search Engine Optimization, 검색 엔진 최적화)에 유리하고 초기 로딩 속도를 향상시켜 주지만, 기본적으로 블로킹 방식이기 때문에 AI 서비스에는 치명적이다. LLM(Large Language Model, 대형 언어 모델)이 답변을 생성하는 데 10초가 걸린다면, 사용자는 10초 동안 빈 화면만을 보게 된다.

Client-Side Rendering (CSR)

그림 2. CSR의 동작 흐름.

CSR(Client-Side Rendering, 클라이언트 측 렌더링) 아키텍처에서 서버는 내용이 거의 비어 있는 HTML 뼈대(shell)와 거대한 자바스크립트 번들 파일에 대한 링크만을 제공한다. 브라우저는 이 번들을 다운로드하고 실행한 후, 클라이언트 측에서 API 서버로 데이터를 요청하여 화면을 그린다. 렌더링의 부하가 전적으로 사용자의 디바이스로 전가되는 것이다 (브라우저가 이 부하를 어떤 파이프라인으로 처리하는지는 브라우저의 내부 구조 참고).

CSR은 서버 비용 측면에서 가장 효율적이다. 서버의 컴퓨팅 자원을 렌더링에 소모하지 않아 서버 비용이 거의 발생하지 않으며, 단순 정적 파일 호스팅(S3/CDN) 비용만 발생하기 때문이다. 또한 AI 모델과의 연결(WebSocket 등)을 클라이언트가 직접 맺으므로 미들웨어 서버의 병목을 피할 수 있다. 그러나 치명적인 단점은 SEO와 초기 로딩 속도다. Perplexity나 ChatGPT와 같은 AI 검색 엔진의 크롤러(crawler)들은 자바스크립트를 실행하지 않고 원시 HTML만 수집하는 경우가 많다. 따라서 CSR로 구현된 AI 챗봇의 대화 내용을 "공유"했을 때, 미리보기(Open Graph)¹나 내용 인덱싱이 불가능해져 바이럴 마케팅과 유입에 실패하게 된다.

Static Site Generation (SSG)

그림 3. SSG의 동작 흐름.

SSG(Static Site Generation, 정적 사이트 생성)는 빌드 타임에 모든 경로에 대한 HTML을 미리 생성한다. 그러다 요청이 들어오면 이미 만들어진 정적 파일을 그대로 전달한다. 하지만 내용이 자주 바뀐다면 그때마다 전체 페이지를 다시 만들어야 한다는 문제가 존재한다. 이는 내용이 미리 결정되지 않는 AI 서비스의 특성상 치명적인 약점으로 작용한다.

Incremental Static Regeneration (ISR)

그림 4. ISR의 동작 흐름.

ISR(Incremental Static Regeneration, 증분 정적 재생성)은 SSG에서 확장된 개념으로, 런타임에 특정 페이지의 유효기간(revalidation time)이 만료되면 백그라운드에서 해당 페이지를 재생성하여 정적 캐시를 갱신한다. 따라서 사이트 전체를 다시 빌드할 필요 없이 정적 컨텐츠를 제공할 수 있게 되고, 서버의 부하를 줄일 수 있다.

사용자의 입력(prompt)에 따라 매번 다른 결과가 나오는 AI 챗봇에는 입력의 경우의 수가 무한하기 때문에 SSG/ISR을 적용할 수 없다. 그러나 AI 이미지 갤러리나 프롬프트 공유 커뮤니티와 같이 한 번 생성되면 변하지 않거나 수정 빈도가 낮은 콘텐츠에는 ISR이 서버의 부하를 획기적으로 낮출 수 있다.

Streaming SSR

그림 5. Streaming SSR의 동작 흐름.

전통적인 블로킹 방식의 SSR은 AI 서비스에 치명적이지만, 최신 프레임워크(Next.js App Router 등)에서 도입된 Streaming SSR은 이 문제를 해결한다. 서버는 데이터가 준비되지 않은 부분(AI 답변 영역)을 Suspense² 경계로 감싸고, 준비된 정적 UI(헤더, 사이드바)를 먼저 HTML로 전송(flush)한다. 이후 AI 추론이 진행됨에 따라 생성된 텍스트 덩어리를 동일한 HTTP 연결을 통해 지속적으로 내려보내고, 클라이언트의 런타임이 이를 받아 DOM에 반영하고 하이드레이션(hydration)³한다.

그림 6. Streaming SSR이 정적 UI를 먼저 흘려보내고 준비되는 대로 나머지를 채우는 과정.

이 과정을 통해 서버는 렌더링을 논블로킹 방식으로 처리하게 되면서 사용자가 체감하는 지연 시간을 획기적으로 줄일 수 있게 된다. 그리고 점진적으로 UI를 만들어가는 방식이기 때문에 모바일이나 느린 네트워크 환경과 같이 컴퓨팅 자원이 부족한 상황에서 더욱 좋은 효과를 거둘 수 있다.

실제 상황

이번에는 여러 가지 실제 상황을 보며 어떤 렌더링 방식이 더 적합한지 생각해 보자.

AI 검색 서비스 → Streaming SSR

Perplexity와 같은 인공지능 검색 서비스를 구현한다면 어떤 렌더링 방식을 선택해야 할까? 요구사항은 다음과 같다.

실시간성: 사용자 질의에 대해 지연 없이 답변을 스트리밍해야 한다.
SEO & 공유: 사용자가 검색 결과를 공유했을 때, 제목과 요약 내용이 소셜 미디어와 검색 엔진에 노출되어야 한다.
인용(citation): 답변의 근거가 되는 웹 소스들이 정확하게 렌더링되어야 한다.

CSR은 개발 속도가 가장 빠르지만 SEO와 공유 과정에서 불리한 점이 많다. 웹 크롤러가 컨텐츠를 제대로 보지 못하고, 트위터나 슬랙에 공유해도 미리보기가 뜨지 않으며, 구글 인덱싱도 느리다. SSG와 ISR은 답변이 언제든지 달라질 수 있는 AI 서비스의 특성과 맞지 않는다. 순수한 SSR은 SEO 방면에서 최적이지만, LLM이 답변을 다 쓸 때까지(약 15~30초) 브라우저가 로딩 상태에 머물러 처음 결과를 보기까지의 시간이 너무 길다.

결국 답은 Streaming SSR이다. 정적 UI를 먼저 보내 체감 대기 시간을 없애면서, 봇에게는 완성된 텍스트를 제공하는 방식으로 SEO 문제까지 해결할 수 있다.

AI 생성 이미지 커뮤니티 → ISR + CSR

Civitai는 AI로 생성된 이미지 모델을 공유하고 다운로드할 수 있는 온라인 플랫폼이다. 사용자들이 다양한 AI 모델을 업로드하고 검색할 수 있으며, 커뮤니티를 통해 정보를 교환하고 모델에 대한 평가와 리뷰를 남길 수 있는 공간을 제공한다. 이런 커뮤니티를 만들기 위해서는 어떤 렌더링 방식을 선택해야 할까? 요구사항은 다음과 같다.

대규모 트래픽: 초당 수백 건의 새로운 이미지가 생성되고 공유된다.
이미지 불변성: 한 번 생성된 이미지는 변하지 않지만, 좋아요/댓글 등은 실시간으로 변한다.
검색 유입: 구체적인 프롬프트(예: "Cyberpunk cat in neon city") 검색으로 유입되는 트래픽이 중요하다.

SSR을 택하면 수백만 개의 이미지에 대해 매번 DB 쿼리와 HTML 생성을 수행해야 하는데, 이미지는 변하지 않으므로 HTML을 매번 새로 만드는 것은 막대한 낭비다. SSG를 택하면 사용자가 이미지를 업로드하고 URL을 공유했는데 404 에러가 나거나, 빌드 큐가 밀려서 1시간 뒤에나 페이지가 생기는 일이 벌어질 수 있다. 실시간 커뮤니티에 SSG를 그대로 적용할 수는 없다.

그래서 페이지의 핵심(이미지, 프롬프트, 모델 정보)은 ISR로 구현하는 것이 효율적이다. 최초 요청 시에는 SSR처럼 동작하거나 폴백(fallback)을 보여주고 백그라운드에서 정적 페이지를 생성하며, 이후 요청부터는 CDN(Content Delivery Network, 콘텐츠 전송 네트워크)에 캐시된 HTML을 준다. 반면 변동성이 큰 데이터(좋아요 수, 댓글, 연관 이미지)는 CSR로 처리한다. 클라이언트에서 SWR이나 React Query 같은 캐시 관리 라이브러리로 가져와서 채우는 것이다.

인프라 비용

AI 서비스를 구축할 때 가장 간과하기 쉬운 것이 렌더링 방식에 따른 인프라 비용의 변화다. 특히 Vercel이나 Netlify 같은 관리형 플랫폼은 편리하지만, AI 스트리밍과 같은 장시간 연결에 대해 가혹한 과금 모델을 가지고 있다. 다음과 같은 서비스를 가정해 보자.

일간 활성 사용자(DAU, Daily Active User): 10,000명
인당 평균 요청: 10회
평균 스트리밍 지속 시간: 30초
총 요청 수: 100,000회/일 = 3,000,000회/월
총 컴퓨팅 시간: 3,000,000회 × 30초 = 90,000,000초 = 1,500,000분 = 25,000시간

Vercel Serverless Functions (Pro 요금제)

Vercel은 요청을 서버리스 함수로 처리하며, GB-hours⁴ 단위로 과금한다(Pro 요금제 기준). 기본 메모리 1GB를 가정하면 위 서비스의 컴퓨팅 시간은 25,000 GB-hours로, 기본 제공량(1,000 GB-hours)을 훨씬 초과한다. 초과분 24,000 GB-hours × $0.18(예상 단가) ≈ **월$ 4,320**이고, 여기에 데이터 전송료(data transfer)는 별도다.

CSR + 자체 GPU 서버 직결

웹 서버(Vercel)는 HTML 껍데기만 서빙하므로 비용이 거의 들지 않는다. 클라이언트는 GPU 추론 서버(예: RunPod, EC2)에 직접 연결한다. GPU 서버는 어차피 추론을 위해 켜져 있어야 하므로, WebSocket 연결 유지에 따른 추가 비용은 메모리 오버헤드 정도로 미미하다.

결론

AI 검색, 챗봇, 실시간 에이전트처럼 실시간으로 렌더링이 잘 되어야 한다면 Streaming SSR이 적합하다. 사내 도구, B2B SaaS, 앱처럼 컴퓨팅 자원 비용을 낮추고 서버의 부하를 분산시켜야 한다면 CSR이 적합하다. 이미지 갤러리, 커뮤니티, 아카이브처럼 조회 속도를 높이고 데이터베이스 부하를 낮춰야 한다면 ISR과 CSR을 잘 조합하는 것이 최선이다.

한편 서버 컴포넌트(async function) 내에서 직접 LLM을 호출하고 Generative UI를 렌더링하는 RSC(React Server Components)를 통해 서버 사이드 데이터에 접근하거나 UI를 서버에서 그려줄 수 있고, PPR(Partial Prerendering, 부분 사전 렌더링)을 사용해 동적 컴포넌트도 스트리밍으로 제공할 수 있다. 둘 다 실험적인 기능이지만 미래를 생각한다면 고려할 만하다.

출처

Grigoryan, A. (2017) The Benefits of Server Side Rendering Over Client Side Rendering. Available at: https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8 (Accessed: 26 August 2026).
Microsoft Community Hub (2025) The importance of streaming for LLM-powered chat applications. Available at: https://techcommunity.microsoft.com/blog/azuredevcommunityblog/the-importance-of-streaming-for-llm-powered-chat-applications/4459574 (Accessed: 26 August 2026).
Surana, P. (no date) The future of rendering in React. Available at: https://prateeksurana.me/blog/future-of-rendering-in-react/ (Accessed: 26 August 2026).
Vercel (2026) How to implement Incremental Static Regeneration (ISR). Available at: https://nextjs.org/docs/app/guides/incremental-static-regeneration (Accessed: 26 August 2026).
박창조 (2025) [React] Streaming SSR. Available at: https://velog.io/@pcjo1202/React-Streaming-SSR (Accessed: 26 August 2026).

*[SSR]: Server-Side Rendering *[CSR]: Client-Side Rendering *[SSG]: Static Site Generation *[ISR]: Incremental Static Regeneration *[SEO]: Search Engine Optimization *[LLM]: Large Language Model

Open Graph는 페이스북이 제안한 메타데이터 프로토콜로, <meta property="og:..."> 태그에 담긴 제목·요약·이미지를 소셜 미디어와 메신저가 읽어 링크 미리보기를 만든다. 크롤러는 자바스크립트를 실행하지 않으므로 이 태그들이 원시 HTML에 들어 있어야 한다. ↩
Suspense는 React에서 아직 준비되지 않은 컴포넌트 영역에 대체 UI를 보여주도록 경계를 지정하는 컴포넌트다. Streaming SSR에서는 이 경계 단위로 HTML을 나눠 보낼 수 있다. ↩
하이드레이션(hydration)은 서버가 보낸 정적 HTML에 클라이언트 JavaScript가 이벤트 핸들러와 상태를 붙여 상호작용 가능한 페이지로 만드는 과정이다. 서버 렌더링 결과에 "물을 부어 되살린다"는 비유에서 나온 용어다. ↩
GB-hours는 함수에 할당된 메모리 용량(GB)에 실행 시간(시간)을 곱한 서버리스 과금 단위다. 1GB 메모리로 1시간을 실행하면 1 GB-hour가 된다. ↩