한 연구자가 ChatGPT의 화면이 아니라 '네트워크 트래픽'을 열어봤다. 거기서 result_source, turn_use_case, fan-out 같은 내부 필드들이 튀어나왔다. AI가 무엇을 읽고, 무엇을 인용하고, 무엇을 아예 무시하는지 — 열 개의 파란 링크가 하나의 답변으로 접히는 시대에, '출처로 뽑히는 법'의 실제 작동 원리를 역사·논문·아키텍처까지 파고들어 쉽게 풀었다.
2026년 어느 날, Suganthan Mohanadasan이라는 한 SEO 연구자가 이상한 실험을 했다. ChatGPT에게 질문을 던지고 답변을 읽은 게 아니라, 브라우저 개발자 도구를 열어 ChatGPT가 서버와 주고받는 날것의 네트워크 트래픽(JSON 덩어리)을 들여다본 것이다.
그가 발견한 것은 화면에서는 절대 보이지 않는 세계였다. 모든 웹 결과마다 result_source라는 꼬리표가 붙어 있었고, 모든 질문은 turn_use_case라는 필드로 여섯 개의 서랍 중 하나에 분류되고 있었으며, 사용자의 질문 하나는 뒤에서 조용히 15~40개의 하위 질문으로 쪼개져 웹을 긁고 있었다.
그가 내린 결론은 도발적이다.
"ChatGPT는 검색엔진이 아니다. 그러니 검색엔진에 맞춰 최적화하는 짓을 멈춰라."
이 글은 그 관찰 기록을 출발점으로 삼는다. 하지만 단순한 요약이 아니라, 왜 이런 개념이 세상에 나오게 됐는지(역사), 학계는 뭐라고 말하는지(논문), 그리고 그 내부가 실제로 어떻게 생겼는지(아키텍처)까지 하나씩 뜯어본다. 생소한 용어는 그때그때 쉽게 풀 테니, 검색이든 AI든 처음이어도 괜찮다.
⚠️ 먼저 정직하게 짚고 갈 것. 이 관찰은 한 연구자가 자기 Pro 계정 하나의 트래픽을 며칠간 들여다본 기록이다.
result_source같은 필드가 존재한다는 사실은 확신할 수 있지만(구조적 사실), "Reddit이 몇 % 인용된다" 같은 수치는 방향성일 뿐 통계가 아니다. 이 글도 그 구분을 지키며 쓴다.
우리가 20년간 알던 검색엔진은 단순했다. 질문을 넣으면 열 개의 파란 링크(ten blue links)가 순서대로 나왔다. 무엇을 읽고 무엇을 믿을지는 사람이 클릭해서 직접 판단했다. 이 세계에서 웹사이트가 살아남는 법이 바로 SEO(검색엔진 최적화)였다 — "구글의 정렬 목록에서 위로 올라가기".
핵심은 이거다. 옛 검색에서 당신의 경쟁 상대는 '2페이지'였지, 소멸이 아니었다. 3등이든 8등이든, 목록 어딘가에 이름은 남았다.
2020년, Lewis 등이 발표한 RAG(Retrieval-Augmented Generation, 검색 증강 생성)가 판을 바꿨다. 아이디어는 이렇다.
LLM(대형 언어 모델)은 학습한 지식만으로 답하면 틀리거나 오래된 정보를 뱉는다(이걸 환각, hallucination이라 부른다). RAG는 답하기 직전에 관련 문서를 검색해서 모델의 눈앞에 들이밀고, "이걸 근거로 답해"라고 시킨다. Gao 등(2024)의 서베이는 RAG가 Naive → Advanced → Modular로 발전해왔다고 정리하는데, 지금 모든 'AI 검색'의 기술적 뼈대가 바로 이 RAG다. (더 깊은 내용은 RAG 완전 가이드와 Advanced RAG에서 다뤘다.)
Perplexity, Google AI Overviews, 그리고 ChatGPT Search 같은 생성엔진(Generative Engine)은 여기서 한 발 더 나간다. 열 개의 링크를 사람 대신 읽고 요약해서, 각주 몇 개가 달린 단 하나의 답변을 내놓는다.
여기서 조용하지만 무시무시한 변화가 일어난다.
정리하면 이렇다. SEO는 목록에서 위로 가는 게임, GEO는 답변 안에 들어가는 게임. 그리고 이 글의 주제는 후자의 실제 작동 원리다.
대부분의 사람은 AI가 뭘 하는지 알고 싶을 때 답변(출력)을 분석한다. 하지만 답변은 이미 가공된 결과다. Suganthan의 접근은 달랐다 — 모델이 서버와 주고받는 원본 데이터를 봤다.
| 시도했지만 실패한 방법 | 실제로 통한 방법 |
|---|---|
| 패킷 스니핑 — TLS 암호화에 막혀 내용을 못 봄 | 브라우저 DevTools의 Network 패널 — 복호화된 뒤의 HTTP를 그대로 관찰 |
| 자동화 크롬 — Cloudflare가 봇으로 차단 | 콘솔 스크립트로 대화 API 데이터에 직접 접근 |
| 답변 텍스트만 읽기 — 가공된 결과라 원리가 안 보임 | 추론 모델의 사고 과정(chain-of-thought)을 직접 열람 |
이렇게 열어 본 JSON 안에는 화면에 없던 필드들이 있었다. 이 글의 나머지는 그중 네 개의 핵심 필드를 해부하는 여정이다.
turn_use_case: 질문을 여섯 서랍에 넣는다가장 먼저, ChatGPT는 당신의 질문을 여섯 개 서랍(use case) 중 하나에 집어넣는다. 이 분류가 그다음 모든 걸 결정한다 — 심지어 웹을 검색할지 말지까지.
text는 웹을 안 탄다여기서 제일 중요한 사실. text로 분류된 질문은 웹 검색을 전혀 하지 않는다. 오직 학습 데이터만으로 답한다.
예를 들어 "파이썬에서 리스트 뒤집는 법"이나 "고구려 건국 연도" 같은 사실형 질문은 text 서랍에 들어가고, ChatGPT는 웹을 한 번도 열지 않은 채 답을 뱉는다. 즉, 당신이 그 주제로 아무리 완벽한 페이지를 만들어 뒀어도 출처로 뽑힐 기회 자체가 0이다.
💡 GEO 실전 1번 교훈: 최적화하기 전에 "이 질문이 검색을 하긴 하나?"부터 확인하라.
text버킷 질문에 콘텐츠 예산을 쓰는 건 켜지지도 않은 무대에 조명을 다는 격이다.
result_source: 네 갈래의 출처 파이프라인질문이 웹을 타기로 결정되면, 이제 ChatGPT는 여러 경로로 웹을 긁어온다. 그리고 가져온 모든 결과에 result_source라는 꼬리표를 붙인다. 관찰된 값은 네 가지다.
| 파이프라인 | 정체 | 주로 담당하는 질의 | 특징 |
|---|---|---|---|
| serp | 열린 웹 baseline | 일반·뉴스 | 가장 기본 채널. 누구나 들어올 수 있는 문 |
| labrador | 라이선스 허용목록 | 뉴스·지식 | Reuters·WSJ·FT·Guardian·위키·arXiv 등. ~1,080자 스니펫 제공. 계약으로 닫힌 문 |
| bright | Bright Data 스크레이퍼 | 쇼핑·금융·날씨·로컬 | 실시간 데이터를 긁어오는 스크랩 티어 |
| oxylabs | Oxylabs 스크레이퍼 | 지역·로컬 언론·열린 웹 | 또 다른 스크랩 채널. 지역성 강한 결과 담당 |
용어를 잠깐 풀어보자.
labrador는 OpenAI가 라이선스 계약을 맺은 매체들만 들어오는, 돈과 계약으로 닫힌 문이다.labrador는 약 1,080자를 준다.핵심 통찰은 이거다. 당신의 질의 유형에 따라, 애초에 어느 파이프라인에서 경쟁하는지가 갈린다.
labrador(라이선스 티어)의 문은 SEO로 못 연다. 그건 영업·계약의 영역이다.serp/oxylabs의 열린 웹에서 승부해야 한다.fan-out: 하나의 질문이 40개로 터진다
당신은 질문을 하나 던졌다고 생각한다. 하지만 특히 thinking(추론 모델) 버킷에서는, ChatGPT가 그 질문을 뒤에서 여러 개의 하위 질문(sub-query)으로 쪼개 동시에 웹을 긁는다. 이걸 fan-out(팬아웃, 부챗살처럼 퍼짐)이라 부른다.
Suganthan의 관찰에서, 한 비교 과제 하나가 15~40개의 하위 질문을 낳았다. 그 안에는 이런 것들이 섞여 있었다.
site:domain.com/pricing 처럼 특정 페이지를 콕 집어 찌른다업계 관측치도 이를 뒷받침한다. 단순한 질문은 하위 질문 4~8개, 복잡한 비교·조사형 질문은 12~20개 이상으로 퍼지며, 2025년 하반기엔 팬아웃 개수보다 각 질문의 정교함(길이)이 배로 늘었다는 분석도 있다.
💡 GEO 실전 2번 교훈: 당신은 사용자의 원래 질문 하나가 아니라, 그 질문이 낳는 수십 개의 하위 질문 전부에 대해 노출을 다투고 있다. "우리 제품 가격"만 최적화할 게 아니라,
site:탐침·경쟁 비교·"○○ 대안" 같은 파생 질문에도 걸리도록 페이지를 설계해야 한다.
fetched / cited / mentioned: 세 가지 운명이제 마지막 장치. ChatGPT가 어떤 페이지를 '가져왔다(fetch)'고 해서 그걸 '인용(cite)'하는 건 아니다. 관찰된 상태는 세 가지로 나뉜다.
fetched가 중요한 이유: 가져오기까지 했는데 인용 안 됐다면, 당신 페이지가 검색엔 걸렸지만 인용될 만큼 쓸모 있지 않았다는 뜻이다. 이건 SEO 목록에서 '순위 낮음'과는 완전히 다른 신호다.
지금까지 본 네 장치(turn_use_case → fan-out → result_source → 인용 판정)가 실제로 어떻게 맞물리는지, 아래에서 질문을 하나씩 골라 단계별로 따라가 보자. text형 질문은 아예 웹을 안 타는 것부터, 뉴스가 labrador로, 쇼핑이 bright로 갈리는 것까지 직접 보인다.
Suganthan의 표본(SaaS·테크 질의 위주, 약 1,240개 소스 레코드)에서 가장 눈에 띈 대비가 이거였다.
가져온 횟수는 Reddit 278 : YouTube 201로 엇비슷하다. 그런데 인용은 Reddit 11회, YouTube 0회. 더 큰 규모의 관측(Ahrefs의 140만 프롬프트 연구)에서도 Reddit 인용률 1.93%, YouTube 0.51%로 방향이 같았다.
왜? 신비로운 알고리즘 편애가 아니라 지극히 기계적인 이유다.
Reddit을 가져오면 → 페이지에 사람이 쓴 읽을 수 있는 본문 텍스트가 그득하다. 그래서 '의견'의 출처로 인용된다.
여기서 이 특집 전체를 관통하는 한 문장이 나온다.
ChatGPT는 파싱 가능한 당신 페이지에서 '사실'을 읽고, 제3자(Reddit·리뷰 등)에서 '의견'을 인용한다.
추론 모델의 사고 과정을 열어 봤더니, 결정적인 한계가 드러났다. 가격표가 JavaScript로 늦게 그려지는 페이지를 만나면, 모델은 그걸 "못 읽겠다"고 판단하고 그냥 포기한다. 그러고는 G2 같은 제3자 사이트로 가격 출처를 넘겨버린다.
💡 GEO 실전 3번 교훈: 핵심 사실(가격·스펙·수치)은 JavaScript가 아니라 순수 HTML 텍스트로, 이미지가 아니라 글자로 넣어라. 이미지 속 가격표는 모델에게 그냥 그림일 뿐이다. (HTML의 놀라운 효용에서 다룬 원리와 통한다.)
관찰이 "무엇이 일어나는가"라면, 논문은 "무엇을 하면 더 인용되는가"를 통제된 실험으로 답한다. Aggarwal·Murahari·Rajpurohit 등의 GEO: Generative Engine Optimization(KDD 2024)이 그것이다.
그들은 GEO-Bench라는 벤치마크(약 1만 개의 다양한 질의 + 관련 웹 소스)를 만들고, 콘텐츠에 여러 조작을 가한 뒤 생성엔진 답변에서의 노출(visibility)이 얼마나 변하는지 측정했다. 노출은 "답변에서 그 소스가 얼마나, 어디에 인용됐나"를 정량화한 지표다.
논문의 결론은 두 가지로 요약된다.
여기에 후속 연구가 붙인 한 문장이 결정적이다. LLM은 사람이 중시하는 '신뢰의 겉표지'(중립적 어조·권위적 표현)보다, 키워드 겹침·의미 유사성 같은 텍스트 관련성을 우선한다. 심지어 문서 앞에 질문을 살짝 얹는 단순한 조작만으로도 인용 확률이 올라갔다.
즉, 트래픽 관찰(3~7부)과 논문 실험(8부)이 같은 방향을 가리킨다 — 읽히게 만들고, 근거를 얹어라.
이 모든 걸 실전 체크리스트로 접으면 이렇다. SEO를 버리라는 게 아니라, GEO라는 새 층을 얹으라는 것.
| 낡은 SEO 사고 | 2026 GEO 사고 | 근거(이 글의 어느 부분) |
|---|---|---|
| 목록에서 순위 올리기 | 답변 각주 3~5칸에 들어가기 | 1부 — 목록이 답변으로 접힘 |
| 모든 질문에 콘텐츠 뿌리기 | 검색을 타는 질문만 공략 | 3부 — text는 웹을 안 탐 |
| 키워드 밀도 높이기 | 순수 HTML 텍스트로 사실 노출 | 7부 — JavaScript 함정 |
| 내 사이트만 관리 | Reddit·리뷰 등 제3자 언급 확보 | 7부 — 의견은 제3자에서 인용 |
| 얇은 페이지 여러 개 | 주장 하나당 강한 페이지 하나 | 도메인 단위 중복 제거 |
| 화려한 권위적 어조 | 통계·인용·출처를 본문에 삽입 | 8부 — GEO 논문 결과 |
turn_use_case 관찰)site:)까지 커버이 특집의 진짜 교훈은 "GEO 팁 6가지"가 아니다. 그건 결과일 뿐이다.
진짜 교훈은 관찰의 방법에 있다. 모두가 AI의 출력을 분석할 때, 한 사람은 브라우저 개발자 도구를 열어 배관을 봤다. 그러자 result_source, turn_use_case, fan-out 같은, 마케팅 블로그 백 편이 추측만 하던 것들이 관찰 가능한 사실로 바뀌었다.
물론 이건 한 계정의 며칠짜리 관찰이고, 서버 안쪽의 정렬 공식은 여전히 유리창 너머에 있다. OpenAI가 파이프라인을 바꾸면 필드 이름도 바뀔 수 있다. 그래서 구조적 사실(필드가 존재한다)과 방향성 관찰(몇 %가 인용된다)을 끝까지 구분하는 태도가 중요하다.
그럼에도 방향은 분명하다. 열 개의 파란 링크가 하나의 답변으로 접히는 시대에, 살아남는 콘텐츠는 기계가 읽을 수 있고(파싱 가능), 근거가 붙어 있고(인용 가능), 남들이 말해주는(평판) 콘텐츠다. 검색엔진이 아니라 — 읽고 나서 답하는 독자를 위해 쓰는 것. 그게 2026년의 글쓰기다.
참고 자료
- Suganthan Mohanadasan, How ChatGPT Picks Sources (2026) — 이 글의 출발점이 된 트래픽 관찰
- Aggarwal et al., GEO: Generative Engine Optimization, KDD 2024 (arXiv:2311.09735)
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020)
- Gao et al., Retrieval-Augmented Generation for Large Language Models: A Survey (2024)
- 코어닷투데이 관련 글: RAG 완전 가이드 · Advanced RAG · HTML의 놀라운 효용
