ChatGPT, Gemini, DeepSeek의 네트워크 트래픽을 캡처하여 그들의 '출처'가 어디에서 오는지 확인했습니다

AI 어시스턴트가 질문에 답변하며 '출처 (sources)' 블록을 보여줄 때, 어디서나 똑같은 것처럼 보입니다. 즉, 모델이 의존한 링크 목록처럼 보이죠. 하지만 실제로는 각 시스템이 해당 블록을 다르게 구현합니다. 각자만의 전송 (transport) 방식, 응답 형식 (response format), 그리고 인터페이스가 인용 (citation) 정보를 읽어오는 고유한 필드 (fields)를 가지고 있습니다. 우리는 ChatGPT, Gemini, DeepSeek 세 가지 시스템의 웹 클라이언트 네트워크 교환 (network exchange)을 해부하였으며, 인용의 기술적 구조와 이 시스템들이 실제로 무엇을 인용하는지 이해하기 위해 각 시스템에 동일한 쿼리 세트를 10회씩 병렬로 실행했습니다.

먼저 공개합니다: 저는 AI 답변에서 브랜드 가시성을 관리하는 플랫폼인 RankCaster AI의 창립자입니다. 우리는 우리가 운영하는 카테고리를 연구합니다. 스스로 채점하는 오류를 피하기 위해, 모든 표를 집계하기 전 저희 도메인을 제외했으며, 방법론의 한계는 전체 연구에 설명되어 있습니다. 이 기사는 기술적인 부분, 즉 네트워크 상에서 인용이 실제로 어떻게 작동하는지에 관한 것입니다.

왜 네트워크 트래픽을 살펴보는가

원래 질문은 마케팅적인 것이었습니다: 만약 어떤 사이트가 Google이나 Bing의 상위 10위(top-10)에 오른다면, ChatGPT가 동일한 쿼리에 대해 인용하는 출처 중에도 나타날 것인가?

짧은 답변을 드리자면 — 거의 그렇지 않습니다. 4개의 쿼리 × 2개의 검색 엔진 × 3개의 AI 시스템 (총 120개의 top-10 순위)을 조사한 결과, 4개의 URL 일치를 발견했습니다. 이는 3.3%에 불과합니다. 양상은 이봉형 (bimodal)입니다. 12개의 엔진×AI 쌍 중 8개는 일치 항목이 전혀 없었고, 나머지 4개는 각각 정확히 하나의 URL만 생성했습니다. 4개의 일치 항목 모두 Bing 측에서 발생했으며, Google 측은 zero였습니다. ChatGPT는 두 엔진 모두와 일치하는 항목이 없었습니다.

하지만 일치 항목을 정확히 세기 위해서는, 먼저 네트워크 레벨 (wire level)에서 각 시스템의 '출처'가 무엇인지 이해해야 합니다. 그렇지 않으면 비교할 수 없는 엔티티 (entities)를 비교하게 될 위험이 있습니다. 이것이 마케팅 질문이 세 플랫폼에 걸친 개발자 도구 (devtools) 세션으로 변하게 된 이유입니다.

방법 요약: AI 언급 모니터링 도구에 관한 4개의 영어 B2B 쿼리를 각 시스템당 10회씩 실행했습니다 (웹 검색 활성화, 로그아웃된 세션, 모든 측정은 단일 날짜에 수행). 인용 안정성(Citation stability)은 APR (Answer Presence Rate, 답변 출현율)로 측정했습니다. 즉, 10회의 실행 중 출처가 답변에 포함된 횟수를 의미합니다. APR이 20% 이상인 출처만 표에 포함되었습니다. N=10일 때, 각 지점의 신뢰 구간(confidence interval)은 대략 ±15~20%포인트이므로, 우리는 개별 수치가 아닌 전체적인 그림의 질적인 형태에 의존합니다.

한 가지 주의사항이 더 있습니다: 세 시스템 중 어느 것도 내부 응답 스키마 (response schemas)를 공개하지 않습니다. 아래의 모든 내용은 공개된 네트워크 교환 및 JSON 구조를 관찰한 결과입니다. 난독화된 필드 이름 (obfuscated field names)에 대한 해독은 공식 문서가 아닌 클라이언트 동작을 기반으로 구축된 가설입니다. 엔드포인트 (Endpoint) 및 헤더 (header) 이름은 당사의 세션에서 기록되었으며, 빌드, 지역 및 계정에 따라 다를 수 있습니다.

ChatGPT: 인용은 텍스트 파편에 결합되어 있음

전송 (Transport). 웹 클라이언트는 /conversation과 같은 엔드포인트로 JSON POST 요청을 보내고, 답변을 서버 전송 이벤트 (Server-Sent Events) 스트림으로 받습니다. 모든 것은 chatgpt.com에서 이루어지며, 세 가지 경로 접두사(path prefixes)가 있습니다: /backend-api (기본), /backend-alt, 그리고 /backend-anon입니다. 마지막 경로는 로그아웃된 사용자를 위한 것이지만, "로그아웃"이 "식별되지 않음"을 의미하지는 않습니다. 모든 요청에는 여전히 특정 장치 및 세션과 교환을 연결하는 장치 식별자(device identifier)와 Cloudflare/Sentinel 토큰이 포함되어 있습니다. 이 모드는 사용자로서의 신원을 숨길 뿐, 플랫폼이 클라이언트를 구별할 수 없게 만들지는 않습니다.

요청 흐름 (Request flow). 주요 교환이 이루어지기 전, 클라이언트는 준비 요청을 보내고 토큰(당사의 임시 명칭: conduit_token)을 받습니다. 그 후 메시지는 두 개의 비표준 헤더와 함께 /conversation으로 전송됩니다. 이는 다른 연구자들이 설명한 Sentinel 계열의 메커니즘과 동작 방식이 유사합니다. 즉, 준비 요청은 세션에 결합된 클라이언트 작업 증명(proof of client work)을 발행하며, 이것이 없으면 메인 호출은 실패합니다.

일부 세션에서는 동일한 준비 요청이 추가적으로 Cloudflare Turnstile 토큰을 요구했습니다. 이 안티봇 검사는 별도의 도전 페이지가 아니라 conduit_token을 발행하는 바로 그 요청의 조건으로 도착했습니다. 두 가지 방어 메커니즘이 하나의 단계로 통합된 것입니다.

인용(Citations). 출처는 annotations[] 배열 안에 있으며, url_citation 객체 내에 url, title, start_ix, end_ix 필드를 가집니다. 마지막 두 개(start_ix/end_ix)는 생성된 텍스트 내의 오프셋입니다. 이는 해당 출처가 첨부되는 답변 조각(answer fragment)의 경계를 나타냅니다. 공개 Responses API와 유사하게, 여기서 start_index/end_index는 UTF-16 코드 단위로 문서화되어 있으며, JavaScript 문자열은 UTF-16 인덱싱을 사용하므로, 이 오프셋 역시 거의 확실히 UTF-16입니다. 브라우저에서 text.slice(start_ix, end_ix)를 실행하면 정확히 인용된 조각이 반환됩니다. 이를 파싱하는 사람에게 실질적인 결과는 다음과 같습니다: 이모지나 일부 CJK 문자는 두 개의 단위(surrogate pairs)를 차지하며, 바이트 또는 코드 포인트를 세면 인용 위치가 어긋납니다.

ChatGPT의 핵심 시사점: 출처는 답변 전체에 첨부되는 것이 아니라 특정 조각에 첨부됩니다. 어떤 브랜드가 url_citation에 등장하려면, 모델은 해당 특정 조각을 생성하는 동안 그와 관련된 콘텐츠를 사용해야 합니다.

인용 내용. 개념적 질의

전송 (Transport). Google의 내부 JavaScript 프레임워크인 Wiz(Docs, Maps, Photos를 구동하는 프레임워크) 내부의 스트리밍 응답(streaming response)입니다. batchexecute 엔드포인트는 원격 호출을 배치(batching) 처리하기 위한 Wiz의 표준 메커니즘입니다. 기본 주소는 https://gemini.google.com/_/BardChatUi/data/입니다. 메시지 전송 시 rpcid hNvQHb를 관찰했습니다(rpcid 값은 빌드마다 순환합니다). 서버 측에서는 BardFrontendService 계열의 핸들러가 처리합니다.

본문 형식 (Body format). 외부적으로는 두 개의 의미 있는 필드를 가진 application/x-www-form-urlencoded 형식을 사용합니다: f.req (페이로드) 및 at=<SNlM0e> (CSRF 토큰). f.req 필드는 JSPB/PBLite 페이로드를 포함하는 JSON 봉투(envelope) [null,"<envelope-string>"] 형태입니다. 이는 JSON 배열로 직렬화된 Protobuf 메시지로, 필드가 이름이 아닌 위치(position)에 의해 식별됩니다. 네트워크 전송 시(on the wire) 필드 이름은 전혀 존재하지 않으며, 난독화(obfuscation)는 정확히 인덱스 레이아웃(index layout)에 적용되어 있습니다. 이 엔드포인트에 대한 공개된 .proto 정의는 존재하지 않으므로, 모든 필드 대응 관계는 경험적으로 도출되었습니다.

인용 (Citations). 출처는 짧게 마스킹된 필드 이름 세트로 설명됩니다. 여기서 두 가지 계층을 구분해야 합니다: 스트림 내에 필드가 존재한다는 것은 관찰된 사실이며, 각 이름의 의미는 가설입니다. 우리가 작업한 디코딩 결과는 다음과 같습니다:

sourceUrl — 출처 URL (URL 문자열 자체가 직접적으로 보임)
Mf — 아마도 출처 제목 (source title)
SR — 아마도 짧은 요약 (short summary)
rs — 아마도 reliability_score (내부 도메인 신뢰도 추정치)
ls — 아마도 last_seen_date (마지막 확인 날짜)
y6 — 아마도 인용된 구절 자체
K1b — 아마도 URL 유효성 플래그 (URL-validity flag)
GK — 답변 내의 문자 범위 (ChatGPT의 start_ix/end_ix와 기능적으로 유사)
tM — 병합 유형 (merge type) (MERGED와 같은 값이 네트워크상에 나타남)

두 글자로 된 이름들은 다른 그럴듯한 해석(rs — ranking_signal? retrieval_score?)도 가능하며, Google의 내부 문서 없이는 확정적으로 선택할 수 없습니다. 하지만 질적인 결론은 디코딩 정확도에 의존하지 않습니다. 모든 소스(source)와 함께, Gemini는 권위(authority)와 상관관계가 있는 일련의 내부 신호(internal signals)를 함께 전송합니다. 이러한 필드들의 존재 여부는 각 약어의 정확한 의미보다 더 중요합니다.

무엇을 인용하는가. Gemini는 대규모 마케팅 및 SaaS 도메인(Semrush, HubSpot, Zapier)과 자신의 카테고리에 속하는 제품들을 체계적으로 노출합니다. 한 번의 쿼리(query)에서 단일 경쟁사 도메인의 서로 다른 4개 URL이 상위에 올랐습니다. 흥미로운 세부 사항은, 모든 실행 과정에서 Google의 자산은 Gemini의 상위 소스에 단 하나도 포함되지 않았다는 점입니다. 또한 SEO 상위 10위(top-10)와 일치하는 모든 결과 중 상당 부분은 Bing × Gemini 조합이 차지했습니다.

DeepSeek: 서브 쿼리(sub-queries)의 부록으로서의 소스

DeepSeek는 세 모델 중 가장 투명합니다. 웹 클라이언트는 시스템이 사용자의 질문을 분해하여 생성한 서브 쿼리(sub-queries)에 결합된 search_results[] 배열을 반환합니다. 대리 쌍(surrogate pairs)을 이용한 오프셋 산술(offset arithmetic)이나 마스킹된 약어도 없습니다. 하지만 소스 선택(source-selection) 특성은 세 모델 중 가장 두드러집니다.

무엇을 인용하는가. DeepSeek는 뉴스 매체와 보도 자료(press releases)에 기반합니다: TMCnet, MarketScreener, GlobeNewswire, B2B 뉴스 네트워크 등 보도 자료 배포 서비스에 의해 생성된 계층입니다. DeepSeek는 중국어 소스(BusinessNext, Alibaba Cloud)를 일관되게 인용하는 유일한 시스템이었습니다. 또한 전체 샘플에서 최대 안정성을 보이는 세 지점을 생성했습니다: 하나는 문서 서브도메인(10/10)이었고, 나머지 두 개는 SEO 상위 10위나 다른 시스템에서는 나타나지 않는 도구 사이트(각각 10/10)였습니다.

세 가지 시스템 — "소스"에 대한 세 가지 서로 다른 모델

	ChatGPT	Gemini	DeepSeek
전송 (Transport)	JSON + Server-Sent Events	Wiz / batchexecute, JSPB	JSON, `search_results[]`
...

실질적인 결과:

"Google에 최적화하면 AI가 따라올 것이다"라는 전략은 우리가 연구한 카테고리에서는 통하지 않았습니다. 중복률은 3.3%였으며, Google 측에서는 0%였습니다. 각 시스템은 SEO 순위나 서로의 규칙과도 일치하지 않는 자신만의 규칙에 따라 소스(source)를 선택합니다.

ChatGPT의 경우, 모델이 답변의 특정 파편(fragment)에서 사용하고자 하는 콘텐츠가 효과를 발휘합니다. 즉, 파편 수준의 결합(fragment-level binding) 때문에 "일반적인 브랜드 인지도"는 무용지물입니다.

Gemini의 경우, 필드(field)들을 살펴보면 내부적인 도메인 평가(internal domain evaluation)가 존재하는 것으로 보입니다. 만약 reliability_score 가설이 맞다면, 신뢰 이력이 있는 도메인이 단발성으로 운 좋게 걸린 기사보다 우위에 있게 됩니다.

DeepSeek의 경우, 배포 채널은 보도 자료(press releases)와 뉴스 와이어(news wires)입니다. 이는 SEO 전문가들이 오래전부터 저질 채널(junk channel)로 치부하며 포기했던 영역입니다.

한계점 (Limitations)

솔직하게 목록으로 말씀드리자면 다음과 같습니다: 4개의 쿼리(query) 모두 단일 제품 카테고리(자사 제품 — 샘플링 편향(sampling bias)을 명시함)에서 추출되었습니다. 쿼리 문구(query phrasings)를 외부 레지스트리에서 가져온 것이 아니라 직접 작성했습니다. N=10회 실행 결과는 포인트당 ±15–20%p의 오차를 가집니다. 이 측정은 단 하루 동안의 스냅샷이며, 세 가지 웹 클라이언트가 끊임없이 업데이트되므로 특정 필드 및 엔드포인트(endpoint) 이름은 스냅샷일 뿐 표준(canon)이 아닙니다. 이 결론을 다른 카테고리에 자동으로 적용하지 마십시오.

4개 쿼리에 대한 모든 테이블, 방법론, 소스 유형론(source typology)을 포함한 전체 연구 결과는 여기에서 확인할 수 있습니다: Source Overlap Between Search Engines and AI Recommendations.

만약 여러분의 개발자 도구(devtools) 세션에서 다른 필드 이름이 나타나거나, 다른 쿼리 카테고리의 데이터를 가지고 계신다면 댓글을 통해 의견을 나누고 싶습니다.