국내 기업들을 대상으로 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를 렌더링하고 업데이트하는 데 필요한 자바스크립트 양이 증가하여 최신 기기와 구형 기기 모두에서 성능 병목 현상이 발생했습니다.

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

AI 검색이 서서히 보편화하는 지금, CSR의 약점은 치명적으로 작용하기 시작합니다. 구글의 구글봇 정도를 제외하면, 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를 기반으로 구축된 프레임워크로, 개발자가 서버 측에서 페이지를 렌더링하는 동시에 하이드레이션을 통해 클라이언트 측 상호 작용도 가능하게 합니다. 이러한 하이브리드 모델은 개발자에게 유연성을 제공하여 서버와 클라이언트 중 어느 쪽에서 렌더링할지 선택할 수 있도록 합니다.

왜 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.