2026년 웹 개발의 지배적인 트렌드는 바이브 코딩(Vibe coding)입니다. 프롬프트를 입력하면 30초 만에 작동하는 앱을 얻고 배포할 수 있습니다. Lovable, Bolt, v0 등 유사한 도구들은 코드 한 줄 작성 없이도 웹 애플리케이션을 프로토타입화하고 배포하는 것을 가능하게 했습니다.
이 앱들은 보기 좋습니다. 브라우저에서 작동합니다. 그리고 AI 검색 엔진에게는 보이지 않습니다.
문제점
바이브 코딩 스택의 모든 도구는 기본적으로 클라이언트 측 렌더링(client-side rendered) SPA를 생성합니다. 서버는 <div id="root"></div>와 <script> 태그가 포함된 HTML 셸을 반환합니다. 브라우저는 이 스크립트를 다운로드하고 실행한 다음 콘텐츠를 렌더링합니다. 이는 브라우저에서는 작동하지만, 봇(bot)에게는 그렇지 않습니다.
GPTBot, ClaudeBot, PerplexityBot, Googlebot은 브라우저가 하는 방식대로 JavaScript를 실행하지 않습니다. 이들은 HTML을 가져와 파싱하고 다음 단계로 넘어갑니다. 콘텐츠가 HTML에 없으면 검색 추출 파이프라인(retrieval pipeline)에서 존재하지 않는 것입니다.
이는 새로운 문제가 아닙니다. React가 클라이언트 측 렌더링을 대중화한 이래 SPA를 괴롭혀 온 동일한 렌더링 문제입니다. 새롭게 달라진 것은 규모입니다. 2026년에는 수만 개의 사이트가 바이브 코딩 도구들에 의해 생성되고 있으며, 그 모든 사이트는 공통적으로 기본값(default)을 가지고 배포됩니다: 빈 HTML 셸과 JavaScript로 렌더링된 콘텐츠, 그리고 크롤러에게는 보이지 않는 것입니다.
확인 방법
curl -s https://your-vibe-coded-site.com | wc -c
만약 응답이 수백 바이트라면, 셸(shell)을 받고 있는 것입니다. 만약 몇 킬로바이트 이상이라면, 콘텐츠가 HTML에 포함되어 있다는 의미입니다.
또한 페이지 소스(page source)를 확인하여 봇이 무엇을 보는지 확인할 수도 있습니다. 렌더링된 DOM이 아닌 것을 봐야 합니다:
curl -s https://your-vibe-coded-site.com | grep -i "your main content text"
만약 grep 결과가 아무것도 반환하지 않는다면, 귀하의 콘텐츠는 JavaScript로 렌더링된 것입니다. 어떤 AI 검색 엔진도 이를 읽을 수 없습니다.
llms.txt 논쟁은 몇 달 동안 GEO 커뮤니티를 지배해 왔습니다. Google은 무시하라고 말합니다. Chrome Lighthouse는 이를 감사(audit)합니다. 네 개의 독립적인 연구가 AI 인용에 아무런 영향이 없다고 말합니다 (전체 데이터는 이 시리즈의 첫 번째 기사를 참조하십시오).
하지만 llms.txt가 완벽하게 작동하더라도 렌더링 문제를 해결하지 못할 것입니다. llms.txt 파일은 사용자의 페이지에 링크합니다. AI 봇이 이 링크들을 따라가면, 사용자의 HTML을 가져옵니다. 만약 사용자의 HTML이 비어 있다면, 봇은 파일을 읽고, 페이지를 방문하지만 아무것도 찾지 못합니다. 그 파일은 빈 방으로 가는 지도일 뿐입니다.
Ahrefs의 연구는 이러한 패턴을 확인했습니다: AI 봇은 보조 파일(auxiliary files)이 아닌 HTML 페이지를 가져옵니다. Limy의 연구는 5억 1,500만 건의 봇 이벤트를 추적했으며, 봇들이 압도적으로 직접 HTML을 요청한다는 것을 발견했습니다. 무엇을 인용할지 결정하는 검색 단계(retrieval step)는 사용자의 HTML을 읽습니다. 만약 사용자의 HTML에 내용이 없다면, 당신은 보이지 않습니다.
해결책 (The fix)
해결책은 AI와 특정된 것이 아닙니다. 이는 SPA가 인기를 얻으면서부터 존재했던 동일한 해결책입니다:
옵션 1: 정적 생성(Static generation). 빌드 시간(build time)에 완전한 HTML을 생성합니다. Astro, output: export를 사용한 Next.js, Gatsby, Elevento가 기본적으로 이를 수행합니다. 모든 페이지는 전체 HTML 파일입니다. 봇은 첫 번째 요청에서 모든 것을 얻습니다.
옵션 2: 서버 측 렌더링(Server-side rendering). 각 요청에 대해 서버에서 HTML을 렌더링합니다. App Router를 사용한 Next.js, Nuxt, SvelteKit이 이를 지원합니다. 서버는 완전한 HTML을 전송합니다. 봇은 그것을 읽을 수 있습니다.
옵션 3: 사전 렌더링(Prerendering). 페이지의 정적 스냅샷을 생성하여 봇에게 제공합니다. 이것은 복잡성을 추가하고, 사전 렌더링된 내용이 사용자가 보는 것과 다를 경우 클로킹(cloaking)으로 플래그 지정될 수 있는 우회책입니다. 다른 선택지가 없는 경우가 아니라면 피하십시오.
SPA를 생성하는 도구들은 정적 생성(SSG) 또는 서버 측 렌더링(SSR)을 기본값으로 설정해야 합니다. 현재는 작동하는 프로토타입에 가장 쉬운 경로이기 때문에 CSR로 기본 설정되어 있습니다. 사용자가 프롬프트를 입력하면, 도구가 React 앱을 생성하고 이 앱은 브라우저에서 작동합니다. 크롤러에게 보이지 않는다는 사실은 사용자가 분석(analytics)을 확인하고 왜 유기 트래픽이 0인지 의문을 품을 때까지는 눈에 띄지 않습니다.
일부 도구들은 이를 해결하기 시작했습니다. Lovable은 SSR 옵션을 추가했습니다. Bolt는 프리렌더링을 처리하는 플랫폼으로 배포를 지원합니다. 하지만 기본값은 여전히 CSR에 치우쳐 있으며, 대부분의 사용자는 기본값을 변경하지 않습니다.
더 광범위한 시사점
이 렌더링 문제는 AI 검색 가시성의 기반 계층입니다. 콘텐츠가 HTML에 없다면 다른 것은 중요하지 않습니다. LLM(대규모 언어 모델)도 마찬가지입니다. llms.txt도, 스키마(Schema)도, 콘텐츠 구조도, 인용할 만한 구절도 마찬가지입니다. 봇은 상위 수준의 신호들이 작동하기 전에 페이지를 읽을 수 있어야 합니다.
제가 유지 관리하는 감사 도구(geo-optimizer-skill)에서, 렌더링 확인이 우리가 테스트하는 첫 번째 신호입니다. 우리는 헤드리스 브라우저를 사용하고 사용하지 않은 상태로 페이지를 가져와 결과를 비교합니다. 만약 콘텐츠가 현저하게 다르다면, 우리는 이를 JS 의존적(JS-dependent)으로 플래그 지정합니다. 이것은 우리가 보는 가장 흔한 실패 모드이며, 해결책이 가장 명확한 경우입니다.
만약 여러분이 바이브 코딩을 하고 있다면, HTML 출력을 확인하세요. 비어 있다면 SSG 또는 SSR로 전환하세요. 앱의 모양은 사용자에게 동일하게 보일 것이며, 중요한 모든 검색 엔진과 AI 크롤러에게 가시적이 될 것입니다. 해결책은 GEO 전략이 아니라 단 하나의 설정 변경입니다.