페이지 속도와 렌더링 방식은 AI 색인의 '문지기'다. 정확히 말하면, 콘텐츠 품질을 평가하기 이전 단계에서 'AI가 당신의 글을 아예 읽을 수 있는가'를 결정한다. AI 검색이 어떤 페이지를 인용하려면 그 페이지가 먼저 후보군(candidate pool)에 들어가 있어야 하는데, 느리거나 자바스크립트로만 그려지는 페이지는 크롤러 단계에서 빈 껍데기로 수집되거나 아예 수집되지 못한다. 그러면 본문이 아무리 좋아도 검색→재랭킹→생성으로 이어지는 인용 파이프라인의 출발선에조차 서지 못한다. 이 글은 그 '왜'를 RAG 메커니즘 수준에서 끝까지 파고든다.
먼저, AI는 페이지를 두 단계로 읽는다: 가져오기(fetch)와 렌더링(render)
사람이 브라우저에서 웹페이지를 볼 때는 두 가지가 자동으로 일어난다. ① 서버에서 HTML을 받아오고(fetch), ② 그 안의 자바스크립트를 실행해 화면을 완성한다(render). 우리는 이 둘을 구분하지 않지만, AI 크롤러에게는 이 두 단계가 완전히 별개의 비용이고, 많은 크롤러가 두 번째 단계를 건너뛴다.
비유하자면 이렇다. fetch는 '편지 봉투를 받는 일'이고, render는 '봉투 안의 조립 설명서대로 가구를 직접 조립하는 일'이다. 봉투를 받는 건 싸고 빠르다. 하지만 설명서(자바스크립트)를 받아 실제로 가구(완성된 페이지)를 조립하는 일은 시간과 연산이 많이 든다. 검색엔진 Googlebot은 비싼 조립 라인(렌더링 큐)을 따로 운영하지만, 다수의 AI 전용 크롤러는 봉투만 열어보고 그 안에 이미 완성된 가구가 들어 있길 기대한다. 봉투 안에 '조립하면 가구가 됩니다'라는 설명서만 들어 있으면, 그들에게 당신의 페이지는 빈 상자다.
그래서 렌더링 방식이 문제의 핵심이 된다. 콘텐츠가 서버에서 HTML로 미리 완성되어 오는지(SSR·정적 생성), 아니면 브라우저에서 자바스크립트가 실행되어야만 나타나는지(CSR)에 따라, 같은 글이라도 AI에게 '읽히는 글'과 '존재하지 않는 글'로 갈린다.
RAG 복습: 후보군에 못 들면 그 뒤는 전부 의미가 없다
왜 '읽히느냐'가 그렇게까지 결정적인지 이해하려면 AI 검색이 답을 만드는 구조를 봐야 한다. 오늘날 ChatGPT 검색·Perplexity·구글 AI·네이버 AI 브리핑은 대부분 RAG(Retrieval-Augmented Generation) 구조를 쓴다. RAG는 Lewis 등이 2020년 제안한 개념으로(arXiv:2005.11401), 모델이 학습 때 외운 지식(파라메트릭 메모리)만으로 답하지 않고, 외부 문서를 그때그때 검색해 와서(비파라메트릭 메모리) 그 근거 위에서 답을 생성하는 방식이다.
이 파이프라인은 세 단계로 흐른다.
- 검색(retrieval): 사용자의 질문과 의미가 가까운 문서 청크들을 색인에서 끌어온다. 의미 기반 검색(Dense Passage Retrieval, Karpukhin 등 2020, arXiv:2004.04906)은 키워드가 정확히 일치하지 않아도 뜻이 통하는 문서를 찾아낸다.
- 재랭킹(reranking): 1차로 끌어온 후보들을 질문과 나란히 다시 읽어 정밀하게 순위를 매긴다. 교차 인코더(cross-encoder) 재랭킹은 까다로운 질의에서 순위 품질(NDCG)을 눈에 띄게 끌어올린다.
- 생성(generation): 상위로 추려진 소수의 청크만 LLM의 맥락창에 들어가 최종 답변과 인용으로 합성된다.
여기서 잔인한 진실이 하나 있다. 이 세 단계는 모두 '색인에 들어와 있는 문서'만을 대상으로 한다. 검색은 색인을 뒤지는 일이고, 색인에 없는 문서는 검색의 대상 자체가 아니다. 즉 당신의 페이지가 크롤러에게 빈 껍데기로 수집되어 본문이 색인되지 않았다면, retrieval이 아무리 똑똑해도 그 글을 찾을 수 없고, reranking이 아무리 정교해도 없는 걸 위로 올릴 수 없으며, generation은 인용할 문장 자체를 갖지 못한다. 페이지 속도·렌더링은 콘텐츠 품질 경쟁(2~3단계) 이전에, 0단계인 '입장 자격'을 결정한다.
렌더링 문제: 자바스크립트로만 그려지는 페이지는 '내용 없는 페이지'다
CSR이 AI에게 빈 상자가 되는 메커니즘
SPA(Single Page Application) 프레임워크로 만든 사이트는 흔히 다음과 같은 HTML을 서버에서 내려보낸다.
<!-- 크롤러가 fetch로 받는 실제 HTML -->
<body>
<div id="root"></div>
<script src="/bundle.js"></script>
</body>사람이 브라우저로 열면 bundle.js가 실행되어 #root 안에 제목·본문·표가 채워진다. 하지만 자바스크립트를 실행하지 않는 크롤러가 받는 건 위의 거의 빈 <div> 하나뿐이다. 본문 텍스트가 0바이트인 문서가 색인에 들어가는 셈이다. 검색 단계에서 의미 임베딩을 만들 텍스트가 없으니, 이 페이지는 어떤 질문에도 끌려오지 않는다.
반대로 서버 사이드 렌더링(SSR)이나 정적 생성(SSG)은 같은 페이지를 이렇게 내려보낸다.
<!-- SSR/정적 생성: 본문이 HTML에 이미 들어 있다 -->
<body>
<article>
<h1>페이지 속도가 AI 색인에 미치는 영향</h1>
<p>페이지 속도와 렌더링은 AI 색인의 문지기다...</p>
...전체 본문...
</article>
</body>이 경우 크롤러는 fetch 한 번으로 본문 전체를 손에 넣는다. 조립 설명서가 아니라 이미 조립된 가구가 봉투 안에 들어 있는 것이다.
약한 예 / 강한 예 — 같은 글, 다른 운명
| 구분 | 크롤러가 실제로 받는 본문 |
|---|---|
| ❌ 약한 예 (CSR 의존) | <div id="app"></div> — 텍스트 0바이트. "Loading..." 스피너만 HTML에 존재. 본문은 JS 실행 후에야 등장. |
| ✅ 강한 예 (SSR/정적) | <article><h1>...</h1><p>직답 문장...</p>...</article> — 첫 응답 HTML에 제목·직답·표·본문이 전부 포함. |
중요한 건, 이 차이가 콘텐츠 작가의 노력과 무관하게 발생한다는 점이다. 작가가 완벽한 직답형 문단과 구조화된 표를 썼더라도, 렌더링 설정 하나 때문에 크롤러는 그 노력을 0바이트로 받는다. 본문 품질은 입장한 다음의 경쟁이고, 렌더링은 입장권 그 자체다.
'사람 눈으로 보이니까 괜찮다'는 착각
가장 흔한 함정은 직접 브라우저로 페이지를 열어보고 "내용 잘 나오는데?"라고 판단하는 것이다. 당신의 브라우저는 자바스크립트를 실행하므로 당연히 잘 보인다. 크롤러가 보는 것을 확인하려면 자바스크립트를 끈 상태의 원본 HTML을 봐야 한다. 가장 빠른 점검법:
# 크롤러가 받는 '날것의 HTML'을 그대로 출력한다
curl -sL https://example.com/article | grep -o '본문 핵심 문장'
# 결과가 비어 있으면 → 그 문장은 JS 실행 후에만 존재 → 크롤러에겐 없는 문장curl로 받은 HTML에 본문 핵심 문장이 들어 있지 않다면, 그것이 곧 AI가 받는 현실이다.
속도 문제: 느린 페이지는 크롤러가 기다려 주지 않는다
타임아웃과 크롤 예산이라는 보이지 않는 마감 시계
크롤러는 인내심이 무한하지 않다. 모든 봇은 한 요청에 대해 응답을 기다리는 시간 한도(타임아웃)와, 한 사이트에 쓸 수 있는 시간·요청 총량(크롤 예산, crawl budget)을 가진다. 페이지가 응답을 너무 늦게 시작하거나, 본문이 다 도착하기 전에 한도를 넘기면 크롤러는 그 페이지를 포기하거나 불완전하게 수집한다.
비유하자면 크롤러는 마감 시간이 빡빡한 자료조사원이다. 도서관에 가서 책 100권을 훑어야 하는데, 한 권이 펼쳐지는 데 10초씩 걸리면 정해진 시간 안에 30권밖에 못 본다. 빨리 펼쳐지는 책일수록 더 많이, 더 자주 읽힌다. 느린 페이지는 '오늘은 그냥 넘어가자'의 대상이 되고, 재방문 주기도 늘어진다. 그 사이 콘텐츠를 갱신해도 색인에 반영되는 속도가 느려진다.
구체적인 타임아웃 임계값은 크롤러마다 공개되어 있지 않아 단정할 수 없다. 다만 일반 웹 성능 연구에서 응답 지연이 길수록 봇·사람 모두의 이탈이 증가한다는 경향은 일관되게 관찰된다. 따라서 정량 수치를 못 박기보다, '느릴수록 수집 누락·갱신 지연 위험이 커진다'는 방향성으로 이해하는 것이 정직하다.
속도가 무너지는 흔한 지점들
| 문제 | 크롤러에게 미치는 영향 |
|---|---|
| 서버 첫 바이트 지연(TTFB) 과다 | fetch 자체가 늦게 시작 → 본문 도착 전 타임아웃 위험 |
| 거대한 JS 번들로만 본문 구성 | 크롤러가 JS 실행 안 하면 본문 0바이트, 실행해도 렌더링 비용·시간 폭증 |
| 본문보다 먼저 로드되는 무거운 위젯·광고 스크립트 | 렌더링 큐에서 본문 표시가 뒤로 밀려 수집 시점에 비어 있을 수 있음 |
| 이미지·폰트로 메인 콘텐츠 표시가 지연 | 핵심 텍스트의 가독·수집 타이밍 악화 |
약한 예 / 강한 예 — 본문 전달 우선순위
- ❌ 약한 예: "화려한 인터랙션을 먼저 로드하고, 본문은 나중에 fetch해서 채운다." → 크롤러가 수집하는 순간 본문 자리가 비어 있을 확률이 높다.
- ✅ 강한 예: "제목·직답·본문 텍스트를 첫 HTML 응답에 즉시 포함하고, 장식·인터랙션은 그 뒤에 점진적으로 얹는다." → 크롤러는 가장 중요한 텍스트를 첫 바이트 묶음에서 확보한다.
원칙은 단순하다. 가장 인용되길 바라는 텍스트일수록 가장 먼저, 가장 싸게 전달되어야 한다.
속도·렌더링과 '청크 친화 구조'는 한 몸이다
여기서 한 단계 더 들어가 보자. 페이지가 잘 수집됐다고 끝이 아니다. RAG는 문서를 통째로 인용하지 않고 청크(chunk)라는 작은 조각으로 잘라 검색·인용한다. 그래서 수집된 HTML이 의미 단위로 깔끔하게 잘릴 수 있는 구조인지가 인용 품질을 좌우한다.
Anthropic이 2024년 공개한 'Contextual Retrieval' 연구는 이 지점을 정량적으로 보여준다. 청크를 그냥 자르는 대신 각 청크에 맥락 한 줄을 덧붙였더니 검색 실패율이 35% 줄었고(5.7%→3.7%), 여기에 BM25 키워드 검색을 결합하니 49%, 재랭킹까지 더하니 67% 감소했다(https://www.anthropic.com/news/contextual-retrieval). 이들은 상위 20개 청크(top-20)를 맥락에 넣을 것을 권한다. 시사점은 분명하다. 잘 수집되고, 의미 단위로 잘 잘리고, 키워드와 의미 양쪽으로 검색되는 구조가 인용 확률을 복리로 끌어올린다.
실제로 공개 벤치마크들을 종합하면 검색 recall@10은 의미 단독 약 78%, 키워드(BM25) 단독 약 65%인 데 비해, 둘을 합친 하이브리드(RRF)는 약 91%까지 올라간다. 비유하면 하이브리드 검색은 '도서관의 키워드 색인 카드'와 '주제를 꿰뚫고 있는 사서'를 동시에 쓰는 것이다. 카드만으로는 표현이 다른 글을 놓치고, 사서만으로는 정확한 고유명사를 놓치는데, 둘을 합치면 빈틈이 메워진다. 그런데 이 모든 정교한 검색은 — 다시 강조하지만 — 페이지가 제대로 수집되어 텍스트가 색인에 들어와 있을 때만 작동한다. 렌더링이 막히면 이 복리 효과의 출발점이 0이 된다.
또 하나. 본문이 길고 무겁더라도, 핵심은 앞과 끝에 배치하는 편이 안전하다. Liu 등의 2023년 'Lost in the Middle' 연구(arXiv:2307.03172)는 LLM이 긴 맥락의 '중간'에 놓인 정보를 잘 놓친다는 U자형 경향을 보고했다. 페이지 속도 관점에서도, 핵심 직답을 문서 맨 앞 HTML에 두면 크롤러가 일찍 확보하고 LLM도 잘 활용한다 — 속도·구조·생성 활용이 같은 방향을 가리킨다.
입장권을 막는 또 하나의 문: robots.txt와 AI 크롤러 허용
아무리 빠르고 SSR로 잘 그려지는 페이지여도, robots.txt가 AI 크롤러를 막고 있으면 후보군 진입 자체가 0이다. 속도·렌더링을 손보기 전에 이 문이 열려 있는지부터 확인해야 한다. 주요 AI 크롤러의 User-agent는 다음과 같다.
| 운영 주체 | 크롤러 User-agent |
|---|---|
| OpenAI | GPTBot, OAI-SearchBot |
| Anthropic | ClaudeBot, anthropic-ai |
| Perplexity | PerplexityBot |
| Google(생성형 학습/응답) | Google-Extended |
# 이 봇들이 막혀 있으면 빠른 SSR 페이지도 후보군에 못 든다
User-agent: GPTBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: ClaudeBot
Allow: /이 세 가지 — robots.txt 허용, 자바스크립트 없이도 본문이 보이는 렌더링, 충분히 빠른 응답 — 가 모두 통과해야 비로소 당신의 글이 retrieval→reranking→generation의 출발선에 선다.
엔진·플랫폼마다 보수성이 다르다
모든 AI가 부실하게 수집된 페이지를 똑같이 대하지는 않는다. 인용 패턴 분석들을 보면 엔진마다 선호 출처와 보수성이 뚜렷이 갈린다. 한 대규모 인용 분석에서 ChatGPT와 Perplexity가 인용한 도메인의 중복은 약 11%에 그쳤고, 인용의 약 90%가 엔진마다 달랐다. ChatGPT는 위키백과(약 47.9%)를, Perplexity는 Reddit(약 46.7%) 같은 커뮤니티를 상대적으로 선호하는 경향이 보고됐다(출처: Profound/Discovered Labs 등). 특히 Claude는 근거가 약한 콘텐츠를 보수적으로 걸러내는 성향이 알려져 있어, 수집·구조가 부실한 페이지는 후보에 들어도 최종 인용에서 탈락하기 쉽다.
즉, 느리고 빈약하게 수집된 페이지는 ① 보수적인 엔진에서 더 빨리 탈락하고, ② 어느 엔진에서든 재랭킹 단계에서 밀린다. 속도·렌더링 정비는 특정 엔진 한 곳이 아니라 모든 엔진에서 동시에 '입장 가능성'을 끌어올리는 가장 저변의 작업이다.
네이버: 다른 규칙의 운동장
국내라면 네이버를 빼놓을 수 없다. 네이버는 외부 크롤러를 차단하는 폐쇄형이라, 글로벌 AI들은 네이버 콘텐츠를 직접 읽지 못하고 나무위키·위키백과·티스토리 같은 경로로 우회한다. 네이버 자체 AI는 별도 알고리즘(C-Rank: 출처 신뢰·전문성, D.I.A.+: 문서 의도)으로 동작한다. 네이버 AI 브리핑은 통합검색 쿼리의 20% 이상에 적용되며, 2026년 4월 기준 인용이 월 약 3.558억 건에 이른다는 집계가 있다. 한 표본분석(272건)에서는 인용 출처의 약 58%가 블로그였고, 약 49%가 통합검색 Top10 밖에서 인용됐다. 네이버 환경에서도 '읽기 쉬운 구조'와 '최신성'은 공식적으로 강조되는 원칙이며, 이는 빠른 표시·명료한 구조라는 본문의 주제와 그대로 맞닿는다.
실무 체크리스트
- 날것의 HTML 확인:
curl -sL또는 JS 끈 브라우저로 본문 핵심 문장이 첫 응답에 들어 있는지 확인. 비어 있으면 SSR/정적 생성으로 전환. - 본문 우선 전달: 제목·직답·핵심 본문을 첫 HTML 응답에 포함. 인터랙션·광고·위젯은 그 뒤로.
- TTFB 단축: 서버 응답 시작을 빠르게. 캐싱·CDN으로 첫 바이트 지연 축소.
- robots.txt 점검: GPTBot·OAI-SearchBot·PerplexityBot·ClaudeBot·anthropic-ai·Google-Extended 허용 여부 확인.
- 청크 친화 구조: 명확한 제목 위계와 직답형 문단으로 의미 단위가 깔끔히 잘리게.
- 핵심은 앞·끝에: 긴 본문이라도 직답과 결론을 양 끝에 배치.
Citeon은 이 원리를 제품에 담았다
지금까지의 이야기를 한 문장으로 줄이면 이렇다. 아무리 좋은 글도, 빠르게 수집되고 자바스크립트 없이 읽히지 않으면 AI 검색의 후보군에 들지 못한다. 문제는 이걸 '느낌'이 아니라 '측정'으로 확인해야 한다는 것이다.
Citeon은 정확히 이 입장권 단계를 점검한다. 사이트 진단엔진이 당신의 URL을 받아 SEO·AEO·GEO 관점에서 0~100점으로 평가하고, 크롤러가 실제로 무엇을 받는지 — 본문이 첫 HTML에 들어 있는지, 구조가 인용에 친화적인지 — 를 한국어 처방으로 돌려준다. 그리고 ChatGPT·Gemini·Perplexity·Claude 4개 엔진의 실제 인용을 측정(SOV)해, 입장권을 손본 결과가 실제 인용으로 이어지는지를 추적한다. 경쟁사 역추적으로 같은 카테고리에서 누가 인용되는지 확인하고, 주간 모니터로 추이를 본다. 측정은 한 번이 아니라 추이로 봐야 한다 — AI 응답은 같은 조건에서도 흔들리기 때문이다.
지금 당신의 페이지가 AI에게 '읽히는 글'인지 '빈 상자'인지, 무료 진단(₩0)으로 먼저 확인해 보라. citeon.cloud에서 무료 진단 시작하기 →
자주 묻는 질문
우리 사이트는 React/Vue SPA인데, AI 검색에서 완전히 배제되는 건가요?
반드시 그렇지는 않습니다. 핵심은 '크롤러가 받는 첫 HTML에 본문이 들어 있는가'입니다. 같은 React/Vue여도 서버 사이드 렌더링(SSR)이나 정적 생성(SSG)을 적용하면 첫 응답 HTML에 본문이 포함되어 크롤러가 자바스크립트 실행 없이도 읽을 수 있습니다. 순수 클라이언트 렌더링(CSR)만 쓰는 경우가 위험합니다. curl -sL로 받은 HTML에 본문 핵심 문장이 있는지부터 확인하세요.
페이지 속도를 올리면 AI 인용이 바로 늘어나나요?
속도는 '필요조건'이지 '충분조건'이 아닙니다. 빠르고 잘 수집되는 페이지는 후보군에 들 자격을 얻지만, 실제 인용은 그 뒤의 검색·재랭킹·생성 단계에서 콘텐츠의 직답성·구조·근거 품질로 결정됩니다. 속도·렌더링 정비는 '경쟁에 참가할 자격'을 확보하는 작업이고, 인용을 따내는 건 그다음 콘텐츠 경쟁입니다. 다만 자격이 없으면 콘텐츠 경쟁 자체가 시작되지 않습니다.
구글 SEO에서 페이지 속도가 중요하다는 건 알았는데, AI 색인에서도 같은 이유인가요?
겹치지만 강조점이 다릅니다. 구글 SEO에서 속도(Core Web Vitals)는 주로 '랭킹 신호'로 작동합니다. AI 색인에서 속도·렌더링은 그보다 앞단인 '수집 성공 여부'에 더 직접적으로 영향을 줍니다. 자바스크립트를 실행하지 않는 AI 크롤러에게 CSR 페이지는 랭킹이 깎이는 정도가 아니라 본문이 0바이트로 수집되는 문제이기 때문입니다. 즉 AI 쪽에서는 '순위'보다 '존재 자체'의 문제에 가깝습니다.
측정해 봤더니 인용이 측정할 때마다 다른데, 우리 페이지 문제인가요?
꼭 그렇지는 않습니다. LLM 출력은 temperature=0에서도 GPU 연산·배치 처리 특성상 결과가 흔들리는 비결정성이 있습니다. 인용은 멱법칙처럼 출렁이기 때문에 단일 측정은 노이즈에 가깝습니다. 그래서 여러 번 측정해 추이로 보고, 신뢰구간으로 해석하는 것이 정확합니다. Citeon의 주간 모니터가 단일 측정이 아니라 추이를 보여주는 이유가 이것입니다.
당장 무엇부터 손대야 하나요?
순서는 ① robots.txt에서 AI 크롤러 허용 여부 확인(막혀 있으면 전부 무의미), ② curl로 본문이 첫 HTML에 있는지 확인(없으면 SSR/정적 전환), ③ 첫 바이트 응답(TTFB) 단축, ④ 제목 위계·직답 구조 정비 순입니다. 1~2번은 '입장 가능 여부', 3~4번은 '입장 후 경쟁력'에 해당합니다.
참고자료
- Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Karpukhin et al. (2020), Dense Passage Retrieval for Open-Domain Question Answering
- Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts
- Aggarwal et al. (2023), GEO: Generative Engine Optimization (KDD 2024)
- Anthropic (2024), Introducing Contextual Retrieval