"우리 React 앱은 크롤러에서 잘 렌더링돼요." 프론트엔드 팀 미팅에서 한 번쯤은 들어봤을 말이다. 틀린 말은 아니다—단, 그 크롤러가 Googlebot일 때 한해서. Googlebot은 2019년경부터 JavaScript 렌더링 2-pass를 도입했고, 이제는 SPA도 꽤 잘 읽는다. 문제는 ChatGPT, Claude, Perplexity 같은 AI 검색 생태계를 먹여 살리는 크롤러들이 Googlebot이 아니라는 점이다.
dev.to에 공개된 현장 분석 리포트에 따르면, GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot은 사실상 1998년의 curl처럼 작동한다. HTTP GET 요청을 보내고, 응답받은 HTML을 파싱하고, 끝이다. JavaScript는 실행되지 않는다. Hydration도 일어나지 않는다. <div id="root"></div> 한 줄만 덩그러니 남은 SPA 셸이 그대로 인덱싱된다. AI 생태계에서 당신의 사이트가 어떻게 보이는지 궁금하다면, 브라우저 DevTools가 아니라 curl -A "GPTBot" https://yoursite.com으로 확인하는 게 맞다.
왜 AI 크롤러는 헤드리스 브라우저를 쓰지 않을까? 답은 단순하다: 비용과 지연 시간. 헤드리스 브라우저는 페이지당 수백 밀리초에서 수 초가 걸리고, 메모리 비용도 raw HTTP 방식보다 수십 배 높다. ChatGPT 검색이 사용자 질의마다 수천 개의 페이지를 실시간으로 fetch해야 하는 상황에서, OpenAI가 모든 URL에 헤드리스 렌더링을 돌리는 건 경제적으로 불가능하다. 기술적 선택이 아닌 비용 구조의 문제다. 그리고 이 구조는 당분간 바뀌지 않는다.
여기서 프론트엔드 개발자가 눈여겨봐야 할 미묘한 함정이 하나 있다. Bingbot은 Chromium 기반으로 JavaScript를 실행한다. 즉, SPA로 만든 사이트도 Bing 인덱스에는 잡힐 수 있다. ChatGPT 검색은 Bing 인덱스를 후보군으로 사용하기 때문에, SPA 사이트가 검색 결과 후보 목록에는 오를 수 있다. 그런데 실제로 사용자에게 답변을 생성할 때 OAI-SearchBot이 해당 URL을 live-fetch하면—빈 껍데기만 돌아온다. 검색 결과에는 뜨지만 AI 답변에는 내 콘텐츠가 포함되지 않는 기묘한 상황이 벌어지는 것이다. SERP에 노출되면서도 AI 합성 단계에서 완전히 투명인간이 되는 셈이다.
실험 결과는 냉혹하다. Next.js SSR 빌드, Next.js SSG 빌드, Vite SPA(SSR 없음), Remix SSR 빌드, 순수 정적 HTML, 그리고 above-the-fold만 서버 렌더링하고 아래는 lazy-load하는 하이브리드—총 여섯 가지 구성을 동일한 콘텐츠로 만들어 각 AI 검색 플랫폼에 노출시킨 결과, SSR/SSG 없는 순수 SPA는 AI 생태계의 절반에 기능적으로 보이지 않았다. 그리고 lazy-load된 below-the-fold 콘텐츠는 어떤 AI 크롤러도 읽지 못했다. 이는 단순한 SEO 점수 하락이 아니라, AI 검색이 답변을 조합할 때 그 사이트의 정보를 완전히 배제한다는 의미다.
프론트엔드 개발자 입장에서 이 상황을 실무에 대입하면 렌더링 전략 선택의 무게가 달라진다. 과거에는 SSR/SSG 도입의 주요 근거가 "초기 로딩 성능"이나 "SEO 점수"였다. 지금은 여기에 "AI 검색 생태계에서의 가시성"이라는 축이 추가됐다. v0.dev나 AI 도구로 빠르게 프로토타입을 뽑을 때도, Vite SPA로 시작한 뒤 나중에 SSR을 얹겠다는 전략은 이제 리스크를 동반한다. AI 크롤러가 프로덕션 배포 직후부터 방문하기 시작하며, 그 초기 인상이 훈련 데이터나 검색 결과에 반영될 수 있기 때문이다.
실용적인 체크포인트를 정리하면 이렇다. 첫째, 핵심 콘텐츠—사업 설명, 제품 정보, 주요 텍스트—는 반드시 first-paint HTML에 포함되어야 한다. JavaScript가 실행된 뒤에야 나타나는 콘텐츠는 AI 크롤러에게 존재하지 않는 것과 같다. 둘째, Next.js를 쓴다면 App Router의 기본 동작인 RSC(React Server Components)가 이미 server-rendered HTML을 내려주므로, 기본값을 유지하는 것만으로도 AI 크롤러 친화적인 구조가 된다. 셋째, lazy-load나 Intersection Observer로 뒤늦게 불러오는 섹션에 중요한 정보를 넣지 말 것. above-the-fold 서버 렌더링 + below-the-fold 클라이언트 lazy-load 구조는 절반짜리 가시성만 제공한다. 넷째, JSON-LD 구조화 데이터는 HTML에 인라인으로 삽입되기 때문에 AI 크롤러가 읽을 수 있는 몇 안 되는 부가 정보 채널이다. 적극 활용할 이유가 생겼다.
조금 더 큰 그림으로 보면, 이 이슈는 "AI 시대의 웹 존재론"에 가까운 질문을 던진다. 검색 엔진이 웹의 주요 진입점이었을 때, Googlebot이 읽지 못하는 콘텐츠는 사실상 존재하지 않는 것이나 마찬가지였다. 지금은 그 진입점이 AI 어시스턴트로 이동하고 있고, AI 어시스턴트를 먹이는 크롤러들은 JavaScript를 이해하지 못한다. 렌더링 전략은 더 이상 성능 팀의 최적화 과제가 아니라, "이 제품이 AI 검색 생태계에서 발견 가능한가"를 결정하는 아키텍처 결정이 됐다.
Next.js App Router, Remix, Astro처럼 서버 렌더링을 기본값으로 설계된 프레임워크들이 단순히 성능 때문에 주목받는 게 아닌 이유가 여기 있다. AI 크롤러 생태계가 성숙해지면서 headless 렌더링 지원이 추가될 가능성을 완전히 배제할 수는 없다. 하지만 비용 구조가 근본적으로 변하지 않는 한, HTML-first 전략이 AI 검색 가시성의 안전망으로 기능하는 현실은 당분간 이어질 것이다. 지금 당장 배포하는 모든 프로젝트에서—렌더링 전략을 결정하기 전에—"이 HTML을 curl로 받았을 때 핵심 내용이 있는가"를 먼저 물어볼 것을 권한다.