CSR이 GEO의 걸림돌인 이유

국내 기업들을 대상으로 GEO(Generative Engine Optimization) 분석 및 컨설팅을 진행하다 보면 가장 먼저 부딪히게 되는 문제가 있습니다. 웹사이트의 CSR(Client Side Rendering) 구조입니다. GEO의 꽃은 취약한 프롬프트를 찾아내 콘텐츠로 빈틈을 채워가는 과정인데요. CSR 구조는 GEO의 진입점을 막아서는 강력한 걸림돌 중 하나라고 할 수 있습니다. 특히 AI 크롤러의 정보 발견에 지대한 영향을 미치는 가림막이라고 부를 수 있습니다.

웹사이트의 CSR 구조란?

클라이언트 사이드 렌더링(Client-Side Rendering, 이하 CSR)은 "웹 페이지의 렌더링 과정을 사용자의 브라우저 내에서 직접 수행하는 기술적 메커니즘"을 말합니다(Clapton, J. 등. 2025). 이 방식은 서버가 기본적인 HTML 구조와 함께 자바스크립트 파일을 전송하면, 브라우저가 이를 해석하여 콘텐츠를 동적으로 생성하는 구조를 취하죠.

CSR은 SPA(Single Page Applications) 혁명의 시기가 도래하면서 꽃을 피우기 시작합니다. 웹 애플리케이션이 발전함에 따라 더욱 반응성이 뛰어나고 상호작용적인 사용자 인터페이스에 대한 필요성이 대두되면서 유행을 타기 시작했죠. 이를 뒷받침했던 기술이 바로 자바스크립트(Javascript)였습니다. jQuery(존 레식, 2006년), Backbone.js(2010년), 더 나아가 Angular.js(구글, 2010년), React(페이스북, 2013년), Vue.js 와 같은 도구들의 발전에 힘입어 황금기를 맞이하게 됩니다. 모바일앱에 준할 정도의 화려하고 반응성이 높은 웹이 CSR로 구현이 가능해졌습니다.

사실 CSR이 등장하기 전까지 웹은 SSR(Server Side Rendering)으로 주로 작동했습니다. 고정된 정적인 페이지를 웹 서버에서 잘 조립(렌더링)한 뒤에 브라우저로 보내주는 방식이었죠. 하지만 모바일앱의 활성화는 이 흐름을 완전히 바꿔놓습니다. 모바일앱만큼 화려한 웹이 가능하다고 봤고, 이를 구현하기 위해 다양한 라이브러리와 프레임워크가 등장하게 된 것이죠. CSR은 어쩌면 모바일앱을 따라가기 위한 웹의 몸부림이라고 할 수 있습니다.

하지만 CSR는 치명적인 약점이 한 가지 있었습니다. 검색 크롤러가 웹사이트의 주요 정보를 읽어가는데 부담을 준 것입니다. 소위 SEO 취약성입니다. 서버가 HTML을 렌더링해서 보내주는 SSR과 달리 CSR은 브라우저가 이 역할을 대신 맡아야 합니다. 일단 간단한 웹페이지 껍데기를 받고, 그 안에 포함된 주요 내용들을 파악하려면, CSR로 구축된 서버로부터 관련 자바스크립트 파일까지 다 받아와 직접 렌더링을 해야 합니다. 다 비용이고 시간이 들 수밖에 없죠. 매일 수억건의 페이지를 이런 방식으로 받아와야 하면 크롤러를 운영하는 기업 입장에선 돈이 들 수밖에 없습니다. 첫 방문 시 약간 느릴 수 있었죠. 저사양 디바이스에서도 지연 효과가 나타나곤 했습니다.

일리노이 시카고대 컴퓨터과학과의 크리스 카니치는 강의 자료를 통해 CSR의 한계를 다음과 같이 지적합니다.

• 초기 로딩 성능 : SPA는 사용자가 의미 있는 콘텐츠를 보기 전에 전체 애플리케이션의 JavaScript 번들을 다운로드하고 실행해야 하므로, 특히 네트워크 속도가 느리거나 모바일 기기에서 초기 로딩 시간이 느릴 수 있습니다.
• SEO 한계 : 검색 엔진은 과거에 자바스크립트가 실행되기 전에 페이지를 크롤링했기 때문에 클라이언트 측에서 렌더링된 콘텐츠를 색인화하는 데 어려움을 겪었습니다. 구글의 헤드리스 브라우징이나 동적 렌더링과 같은 도구가 이러한 문제를 해결하기 위해 등장했지만, 개발자들에게는 여전히 골칫거리였습니다.
• 자바스크립트 과다 사용 : SPA(단일 페이지 애플리케이션)가 복잡해짐에 따라 UI를 렌더링하고 업데이트하는 데 필요한 자바스크립트 양이 증가하여 최신 기기와 구형 기기 모두에서 성능 병목 현상이 발생했습니다.

CSR에서 SSR로의 회귀? 혹은 하이브리드?

AI 검색이 서서히 보편화하는 지금, CSR의 약점은 치명적으로 작용하기 시작했습니다. 구글의 Googlebot 정도를 제외하면, CSR로 구축된 웹페이지에서 중요한 콘텐츠 정보를 AI검색 크롤러들이 외면하기 시작한 겁니다. 스타트업으로 시작된 기업들이기에 전세계 웹사이트를 모두 돌아다니며 CSR 구조의 웹사이트까지 파악해 정보를 읽어내는 건 상당한 비용을 초래할 수밖에 없습니다. 그러다 보니 CSR로 제작된 웹사이트는 SEO에 이어 GEO에서도 불리한 조건에 처할 수밖에 없게 된 것이죠. SSR 중심으로 회귀하는 이유입니다.

앞서 언급했던 일리노이 시카고대 강의자료는 SSR로의 회귀 이유를 5가지로 설명합니다.

1. CSR에서는 브라우저가 전체 JavaScript 번들을 다운로드하고 초기화한 다음, 의미 있는 콘텐츠를 표시하기 전에 추가 데이터를 가져와야 합니다. 이로 인해 특히 네트워크 속도가 느린 경우 TTFP(최초 화면 표시 시간)가 느려집니다 . SSR(서버 측 렌더링)은 서버에서 HTML을 렌더링하고 미리 렌더링된 페이지를 클라이언트에 전달함으로써 사용자가 콘텐츠를 보는 데 걸리는 시간을 단축합니다 . 페이지를 상호 작용 가능하게 만들기 위해서는 클라이언트 측 하이드레이션(후술)이 여전히 필요하지만, 사용자는 훨씬 더 빠르게 의미 있는 콘텐츠를 볼 수 있습니다.
2. SEO 최적화: 서버 측 렌더링(SSR)은 서버 수준에서 HTML을 생성하므로 검색 엔진과 소셜 미디어 플랫폼이 JavaScript를 실행할 필요 없이 콘텐츠를 즉시 색인화할 수 있습니다. 콘텐츠가 많은 사이트나 SEO가 중요한 애플리케이션(예: 블로그, 전자상거래 사이트)의 경우 SSR은 CSR에 비해 상당한 이점을 제공합니다.
3. 저사양 기기에서의 성능 향상 : 일부 기기, 특히 휴대폰이나 구형 데스크톱은 대용량 클라이언트 측 JavaScript 번들을 처리하는 데 어려움을 겪습니다. 렌더링 작업의 대부분을 서버로 오프로드하면 이러한 기기에서 처리해야 하는 JavaScript 양이 줄어들어 애플리케이션 응답성이 향상되고 전반적인 사용자 경험이 개선됩니다.
4. 향상된 사용자 경험과 빠른 상호 작용 시간(TTI) : CSR은 동적이고 반응형 인터페이스를 구현하는 데 탁월하지만, JavaScript 프레임워크가 페이지를 로드(즉, 정적 HTML을 상호 작용 가능한 요소로 변환)하는 과정에서 초기 상호 작용 시 지연이 발생하는 경우가 많습니다. SSR은 사전 렌더링된 페이지를 제공하여 사용자가 콘텐츠를 빠르게 볼 수 있도록 하며, React 18에서 도입된 동시 렌더링 과 같은 기술을 결합하여 애플리케이션을 점진적으로 로드하고 로드함으로써 상호 작용 시간을 단축합니다.
5. 하이브리드 모델의 귀환: SSR과 CSR은 더 이상 상호 배타적이지 않습니다. 최신 웹 프레임워크는 개발자가 두 가지 접근 방식을 결합하여 양쪽의 장점을 모두 활용할 수 있도록 지원합니다. 예를 들어, Next.js 와 Nuxt.js 는 각각 React와 Vue를 기반으로 구축된 프레임워크입니다. 이 두가지 프레임워크는 서버 측에서 페이지를 렌더링하는 동시에 하이드레이션(Hydration)을 통해 클라이언트 측 상호 작용도 가능하게 합니다. 이러한 하이브리드 모델은 개발자에게 유연성을 제공하여 서버와 클라이언트 중 어느 쪽에서 렌더링할지 선택할 수 있도록 도와줍니다.

특히 주목해야 할 흐름 가운데 하나는 5번 CSR과 SSR을 결합한 '하이브리드 모델'입니다. 이는 Next.js(Vecel이 개발해 공개)라는 리액트(React) 프레임워크의 탄생 배경과 연결이 됩니다. 앞서 말씀드렸다시피 React는 전형적인 CSR용 라이브러리입니다. 이 문제가 지속되자 Vecel이 SSR이 가능한 프레임워크를 2016년에 내놓았는데요. 그게 바로 Next.js입니다. Next.js으로 리액트 기반으로도 SSR 개발이 가능한 길이 열리게 된 셈입니다. 한마디로 SSR와 CSR을 함께 제어할 수 있는 하이브리드 모델이 가능해진 것입니다.

CSR vs SSR vs 하이브리드 비교

CSR와 SSR은 웹의 발전 과정에서, 사용자들에게 어떻게 하면 더 좋은 경험을 줄 것인가를 고민하는 과정에 등장한 웹 구현 기술(아키텍처)이라고 할 수 있습니다. 등장한 배경이 다르고 주목한 페인포인트도 다릅니다. 그러다보니 저마다의 장점이 존재하고 차별성이 잘 드러나는 편입니다. 최근에는 CSR과 SSR의 퍼포먼스를 비교하는 논문들이 계속 발표되고 있는데요. 2가지의 결과를 소개하려고 합니다.

먼저 Gangishetti & Jain(2026)의 연구에 따르면 다음 5가지 측면에서 CSR와 SSR은 다른 성과를 냈습니다. 이를 항목별로 구분해서 설명을 드리겠습니다.

• 초기 로딩 성능과 사용자 인식 : 초기 로딩 속도는 사용자 이탈률과 직결되는 중요한 지표입니다. SSR은 서버에서 완전히 렌더링된 HTML을 브라우저로 전송하므로, 자바스크립트 실행을 기다릴 필요 없이 즉시 콘텐츠를 표시할 수 있다는 장점이 있습니다. 연구진은 "SSR은 서버에서 데이터를 미리 가져와 HTML을 생성한 뒤 전송하기 때문에, 저사양 기기나 느린 네트워크 환경에서도 최대 콘텐츠 페인트(Largest Contentful Paint)와 최초 콘텐츠 페인트(First Content Paint) 지표가 크게 개선된다"고 설명했습니다. 반면, CSR은 자바스크립트 번들 다운로드, 구문 분석, 데이터 비동기 호출, UI 동적 구성이라는 다단계 과정을 거쳐야 합니다. 이로 인해 초기 화면 표시가 지연될 가능성이 크며, 코드 분할이나 사전 로드와 같은 최적화 기법을 사용하더라도 자바스크립트 실행 비용에 따른 성능 저하를 완전히 피하기 어렵다는 분석입니다.
• 검색 엔진 최적화(SEO)와 GEO 가시성 : 콘텐츠 중심 플랫폼에서 SEO는 비즈니스 성패를 가르는 요소입니다. SSR은 요청 시점에 완성된 HTML을 제공하고 메타데이터를 포함해 넘겨줍니다. 따라서 검색 엔진 크롤러가 콘텐츠를 더 빠르고 정확하게 색인할 수 있습니다. 연구진은 "구글과 같은 현대적 검색 엔진이 자바스크립트를 실행할 수 있음에도 불구하고, CSR 기반 페이지는 여전히 색인 지연이나 효율성 저하를 겪을 수 있다"고 지적했습니다. CSR 플랫폼이 SEO를 보완하기 위해서는 동적 렌더링이나 사전 렌더링(Pre-Rendering) 서비스와 같은 추가 인프라가 필요합니다. 이는 운영 복잡성을 높이고 검색 엔진별로 색인 결과가 달라지는 불일치를 초래할 위험이 있습니다. 따라서 SEO가 중요한 진입점에는 SSR이나 정적 사이트 생성(SSG) 방식이 더 예측 가능하고 효율적이라는 평가입니다.
• 상호작용성과 확장성 : SSR은 초기 콘텐츠 전달에는 탁월하지만, 페이지 로드 후 자바스크립트를 실행해 연결하는 '하이드레이션(Hydration)' 과정이 필요합니다. 이 과정에서 CPU 자원이 소모되고 일시적인 반응 지연이 발생할 수 있습니다. 다만, 최근에는 선택적 하이드레이션이나 아일랜드 아키텍처(Islands Architecture, 상호작용이 필요한 부분만 '섬'처럼 자바스크립트를 추가하는 방식) 등을 통해 이러한 비용을 최소화하는 기술이 도입되고 있습니다. 확장성 측면에서 연구진은 SSG/ISR(Incremental Static Regeneration) 방식이 가장 우수하며, 그 뒤를 SSR, CSR 순으로 평가했습니다. 특히 ISR은 캐시 효율성을 유지하면서도 콘텐츠의 최신성을 보장할 수 있는 대안으로 주목받습니다. 반면, SSR은 트래픽 급증 시 서버 부하를 방지하기 위해 정교한 캐싱 전략이 필수적입니다.

연구진은 CSR과 SSR이 상호 배타적인 해결책이 아니라 서로 다른 최적화 우선순위를 가진 기술이라고 강조했습니다. 대규모 플랫폼은 경로와 컴포넌트 수준에서 두 전략을 결합하고, 지능적인 캐싱과 현대적인 하이드레이션 기법을 활용할 때 가장 우수한 성능을 확보할 수 있습니다. 결국 검색 엔진 노출을 위한 SSR/SSG와 사용자 상호작용을 위한 CSR의 적절한 조화가 현대 웹 아키텍처의 핵심이라는 분석입니다.

Nordström & Dixelius(2023)의 연구도 결론은 다르지 않았습니다. 속도 관점에서 테스트를 한 연구였는데요. 이미지의 용량에 따라 속도를 측정했을 때, SSR 방식이 더 빠르다는 걸 확인할 수 있었다고 합니다. 이들 연구의 결과를 표로 보여드리면 다음과 같습니다.

왜 GEO 실행이 어려운가

여기서부턴 제 경험을 전달해 보도록 하겠습니다. 규모가 크건 작건 CSR로 구축된 웹사이트가 생각보다 많았습니다. 제가 진행한 GEO 컨설팅 기업의 60~70%가 CSR로 구축된 웹사이트를 보유하고 있었습니다. 그러다 보니 웹사이트 인용률이 매우 낮게 나타날 수밖에 없었죠.

저희는 DUCA라는 프레임워크로 GEO 컨설팅을 진행하는데요. 여기서 D가 바로 발견(Discovery)입니다. 이 문턱을 넘어야 U(Understanding) - C(Ciation) - A(Action)로 나아갈 수 있는데, D를 위해 많은 시간을 할애해야 하는 상황이 자주 발생합니다. 그나마 Next.js, Nuxt.js를 활용하고 있는 기업이라면 유연하고 빠르게 대응할 수 있습니다. 개발팀이 도와주기만 한다면 말이죠. 예를 들면 CSR와 SSR을 동시 적용하는 하이브리드 렌더링(Hybrid Rendering) 기법으로 GEO에 대응할 수가 있는 거죠.

동적 렌더링(Dynamic Rendering)을 임시방편으로 권유하기도 했습니다. 동적 렌더링은 특정 AI 크롤러에겐 SSR로 정보를 렌더링해서 주는 방식입니다. 이를 통해 구조 전체를 뒤바꾸는 작업 없이도 GEO를 진행할 수 있었습니다.

보시다시피, GEO는 마케팅 부서만의 단일 업무가 아닐 수밖에 없습니다. 'ChatGPT에 우리 제품이 등장하도록 해달라'는 작은 부탁은, 이미 여러 부서의 연결된 도움이 없으면 실행하기가 쉽지 않습니다. 심지어 위의 경처럼 개발팀의 협조 없이는 한 발짝도 나아가기 어려운 사례가 참 많습니다. 그저 robots.txt 하나 바꾼다고 변화하는 건 아니라는 겁니다.

또다른 난관계 부딪히는 경우도 있습니다. 회사의 보안상의 이유로 웹사이트가 아닌 방화면 레벨에서 모든 AI 크롤러를 차단하는 경우입니다. CSR 의 약점을 해결하고 robots.txt의 선언을 바꾸놓는다고 하더라도 WAF와 같은 상위 헤더 수준에서 봇을 막으면 이전 GEO 작업은 무용지물이 됩니다. 이땐 왜 AI 크롤링 봇을 방화벽 수준에서 허용하는지 인프라 보안 담당자를 직접 설득해야 하기도 합니다.

결국 GEO는 마케팅의 목적을 달성하기 위해 마케터와 홍보, 개발 부서가 협업할 때 가장 높은 성과를 낼 수 있습니다. 그걸 블루닷 인텔리전스 기반의 GEO 컨설팅을 진행하며 배우고 있는 것이죠. 개발에 대한 이해가 없이, 그러면서도 콘텐츠에 대한 경험이 없다면 GEO 컨설팅을 소기의 성과를 달성하기 어려울 것이라고 확신합니다.  저희 블루닷 인텔리전스 컨설팅팀이 자랑스러운 이유이기도 합니다.

GEO 컨설팅이 필요하다면 블루닷 인텔리전스 컨설팅팀에 도움을 청해 보세요.

참고 문헌

• Clapton, J., Bastos, H., Batisteli, J. P. O., Seufitelli, D. B., & Tavares, C. (2025, November). Client-Side vs Server-Side Rendering: Impacts on Performance and User Experience in Web Applications. In Simpósio Brasileiro de Qualidade de Software (SBQS) (pp. 165-172). SBC.
• Gangishetti, S., & Jain, V. (2026). Comparative Analysis of Client-Side vs. Server-Side Rendering for Large-Scale Content Platforms. International Journal of AI, BigData, Computational and Management Studies, 7(1), 74-80.
• Nordström, C., & Dixelius, A. (2023). Comparisons of server-side rendering and client-side rendering for web pages.