1. citation이 약하다면, 여기서 시작한다

2편에서 A사(국내 주류 1위 브랜드)의 실측 데이터를 봤다. ChatGPT 기준으로 35개 답변 중 33개에서는 — 약 94% — mention도 citation도 없었다. 국내 점유율 1위 브랜드가 그렇다. 더 중요한 질문은 그다음이다. 왜 그런가.

citation이 안 나오는 이유를 많은 마케터가 '콘텐츠 품질 문제'로 먼저 본다. 글이 부족해서, FAQ가 없어서, Schema 마크업이 빠져서. 그래서 콘텐츠부터 손댔다.

틀린 방향은 아니다. 그런데 콘텐츠를 아무리 잘 써도 citation이 안 나오는 경우가 있다. AI가 우리 사이트에 아예 들어오지 못하는 상태일 때다.

RAG 게임에는 두 가지 병목이 있다. 첫 번째는 AI 봇이 사이트에 못 들어오는 입구 문제, 두 번째는 봇이 들어왔는데도 가져갈 단위가 없는 구조 문제다. 둘 중 하나라도 막히면 citation은 안 나온다. 그리고 두 병목은 해결 방법이 다르다.

이 편은 citation이 약한 쪽을 위한 편이다. mention이 약한 쪽은 5편에서 다룬다.

2. 두 병목이 생기는 지점

RAG는 이렇게 작동한다. ChatGPT가 질문을 받으면 Bing 인덱스를 검색하고, 가져온 페이지를 청크(chunk, 답변 생성에 쓰이는 텍스트 조각) 단위로 잘라 읽는다. 그 청크에서 답을 조합하고 출처 URL을 단다.

여기서 막힐 수 있는 지점이 두 군데다. Bing이 우리 페이지를 인덱스에 갖고 있는가 — 입구 문제. 가져온 페이지에서 청크를 뽑아낼 수 있는가 — 구조 문제. 어느 쪽이 막혔느냐에 따라 작업 방향이 달라진다.

3편은 ChatGPT처럼 Bing 인덱스를 쓰는 RAG 엔진을 기준으로 한다. Google AI Search는 같은 Google 인덱스를 쓰는 별도 영역이라 작동 방식이 다르다 — Google 쪽 이야기는 1.5편에서 다뤘다.

3. 병목 1 — 입구 문제: AI 봇이 못 들어오는 경우

입구 문제는 인식하지 못한 채 방치되어 있는 경우가 많다. 사이트가 Google에 잘 잡히니 AI도 당연히 볼 것이라는 가정 때문이다.

그런데 Google 봇과 AI 봇은 다르다. ChatGPT는 Bing 인덱스를 쓰기 때문에 Bing이 우리 사이트를 제대로 크롤하고 있는지가 별도로 중요하다. Google 서치콘솔에 잘 잡힌다고 ChatGPT RAG에서 자동으로 보이지 않는다.

그리고 이건 생각보다 흔하다. 2025년 7월 1일부터 Cloudflare는 신규 도메인에 대해 알려진 AI 크롤러를 기본값으로 차단하기 시작했다. Cloudflare가 전 세계 웹의 약 5분의 1을 보호하니, 사이트 주인이 따로 결정하지 않아도 인프라 단에서 AI 봇이 막혀 있을 수 있다는 뜻이다. 실제로 Cloudflare가 상위 1만 도메인의 robots.txt를 분석했더니, AI 크롤러(GPTBot·ClaudeBot·CCBot)가 가장 자주 차단되는 대상이었다. 의도적으로 막은 곳도 있지만, 자기도 모르게 막혀 있는 경우가 적지 않다.

입구 문제의 대표적 원인은 세 가지다.

robots.txt 차단

robots.txt는 사이트 루트에 있는 텍스트 파일로, 어떤 봇이 어떤 페이지에 접근할 수 있는지 지정하는 규칙이다. 오래된 사이트일수록 언제 설정했는지 기억도 못 하는 규칙이 남아 있다. 확인 방법은 간단하다. 브라우저 주소창에 우리사이트주소/robots.txt를 직접 입력하면 된다. Disallow: /가 루트에 걸려 있으면 봇이 사이트 전체에 못 들어오는 상태다. 참고로 AI 크롤러는 학습용·검색용·실시간용으로 역할이 나뉘는데, ChatGPT citation에 직접 관여하는 건 검색 인덱싱 봇(OAI-SearchBot)이다. 어떤 봇이 정확히 어떤 상태인지 세부 해석은 기술 진단 영역이지만, robots.txt에 'Disallow'가 걸려 있는지 정도는 마케터가 직접 확인할 수 있다.

JS 렌더링 의존

핵심 텍스트가 JavaScript로 그려지면 봇이 빈 페이지를 볼 수 있다. 사람은 브라우저가 JavaScript를 실행하니 글이 다 보이지만, AI 봇은 실행하지 않거나 다 그려지기 전에 가져가는 경우가 많다. 크롬 개발자도구(F12)에서 JavaScript를 끈 채 사이트를 열어, 주요 텍스트가 그대로 보이는지로 방향을 잡을 수 있다. 정확한 렌더링 검증은 기술 진단 영역이다.

사이트 속도·구조 문제

페이지가 너무 느리거나 3~4단계 깊이에 묻혀 있으면 크롤 우선순위에서 밀린다. 참고로 상위 1만 도메인 중 robots.txt 파일이 있는 곳은 약 37%뿐이다 — 그만큼 입구 관리 자체가 방치되어 있다는 뜻이기도 하다.

4. 병목 2 — 구조 문제: 들어왔는데 가져갈 게 없는 경우

봇이 들어와도 청크로 뽑아낼 단위가 없으면 citation은 안 나온다. RAG 연구들이 공통적으로 지적하는 게 이 지점이다 — 청킹 품질이 RAG 성능을 좌우한다(Stankovic, 2026). 구조 문제는 세 가지로 나타난다.

단락이 청크 단위로 안 쪼개져 있다

한 단락에 여러 주제가 섞여 있으면 AI가 깔끔한 청크로 뽑지 못한다. 한 단락 = 한 주제가 기본이다.

결론이 뒤에 있다 (BLUF 부재)

BLUF(Bottom Line Up Front)는 핵심 결론을 맨 앞에 두는 구조다. 서론부터 길게 깔고 결론이 마지막에 나오면, AI가 답을 조합할 때 그 청크를 고르기 어렵다. 첫 문장에 답이 있어야 인용 가능성이 올라간다. 구체적인 Before/After 변환 예시는 4편에서 다룬다.

수치·데이터가 없다

같은 주제의 두 청크 중 AI는 수치·통계·구체적 데이터가 있는 쪽을 우선 인용한다. Princeton GEO 논문이 실험으로 확인한 패턴이다. "효과가 있다"보다 "3.2배 효과가 있다"가, "많은 기업이 적용한다"보다 "3,981개 도메인 분석 결과"가 더 인용되기 쉽다.

5. 마케터가 직접 볼 수 있는 것, 기술 진단이 필요한 것

직접 확인 가능

기술 진단 필요

방향은 마케터도 잡을 수 있다. 정밀 진단은 다르다. 특히 봇이 실제로 들어오고 있는지는 서버 로그가 있어야 알 수 있고, 그건 기술 진단 없이는 어렵다.

6. 순서가 있다

입구 문제와 구조 문제는 동시에 있을 수 있다. 입구 문제가 있다면 구조 작업 전에 먼저 해결해야 한다. 봇이 못 들어오는 상태에서 콘텐츠를 다듬어도 RAG에 반영이 안 된다. robots.txt를 직접 열어보는 게 첫 단계인 이유다 — 5분짜리 확인이 몇 주치 콘텐츠 작업의 낭비를 막는다.

7. 이 글의 한 줄

citation이 약한 이유는 두 가지 병목 중 하나다 — AI 봇이 사이트에 못 들어오는 입구 문제, 아니면 들어와도 가져갈 단위가 없는 구조 문제. 입구부터 열고, 그다음 구조를 다듬는다. RAG 게임은 우리 사이트 안에서 끝난다.

다음 편(4편, 6월 19일)에서는 구조 문제를 실제로 고치는 방법 — 기존 콘텐츠를 RAG 친화적으로 바꾸는 5가지 변환 패턴을 Before/After로 보여준다.

참고 자료