📖 약 4분 읽기
1편에서 AI가 사이트를 이용하는 경로를 셋으로 나누었습니다. 이번 글은 그중 AI 검색의 수집·색인(경로 ②)과 AI 에이전트의 실시간 조회(경로 ③)가 실제로 어떻게 다르게 동작하는지 살펴봅니다. 같은 페이지라도 경로에 따라 AI가 얻는 정보가 크게 달라지는 이유가 여기에 있습니다.
기준 1. 화면을 그리는가
리액트나 뷰 같은 화면 프레임워크로 만든 페이지는 서버가 처음 보내는 원본 HTML에 본문이 비어 있습니다. 브라우저가 스크립트를 실행한 뒤에야 상품 정보나 수치가 채워집니다. 이를 클라이언트 측 렌더링(CSR)이라고 부릅니다.
| 구분 | 해당하는 쪽 | 화면 프레임워크 페이지에서 받는 것 |
|---|---|---|
| 화면을 그리지 않음 | 대부분의 AI 학습·검색 수집기, 대화 중 실시간 조회 도구 | 원본 HTML만 받습니다. 본문이 비어 있습니다. |
| 화면을 그림 | Googlebot(구글 AI 답변의 기반), 일부 검색엔진 수집기, 화면 조작형 에이전트, AI 브라우저 | 화면을 그린 뒤의 본문까지 받습니다. 다만 늦어지거나 실패할 수 있습니다. |
표 1. 화면 실행 여부에 따른 차이(본문 기준 정리)
기준 2. 가져간 뒤 무엇을 보관하는가
두 번째 기준은 덜 알려져 있지만 결과를 크게 좌우합니다. 미리 수집하는 쪽은 원본 HTML을 그대로 보관합니다. 반면 대화 중 조회 도구는 페이지를 대화창에 넣기 위해 글자로 바꾸며, 이 과정에서 스크립트·스타일 영역을 지우는 경우가 많습니다. 구조화 데이터(JSON-LD)는 스크립트 영역 안에 있으므로 함께 사라집니다.
| 구분 | 해당하는 쪽 | 구조화 데이터 | 메타 설명 | 본문 텍스트 |
|---|---|---|---|---|
| 원본째 보관 | 학습·검색 색인 수집기 | 전달됨 | 전달됨 | 원본에 있는 만큼 |
| 글자만 추림 | 대화 중 실시간 조회 도구 | 지워지는 경우가 많음 | 전달됨(실측 1종 기준) | 원본에 있는 만큼 |
표 2. 보관 방식에 따른 차이(본문 기준 정리, 조회 도구별 처리 방식은 공개되어 있지 않아 실제 도구로 확인이 필요합니다)
두 기준을 합치면
| 유형 | 화면 실행 | 구조화 데이터 | 본문 속 상품 수치 | 식별 방법 |
|---|---|---|---|---|
| 학습용 수집 | 안 함 | ○ | ✕ | 접속 이름, 업체 공개 IP 대역 |
| 검색 색인(구글 외) | 안 함 | ○ | ✕ | 접속 이름, IP 대역 |
| 검색 색인(구글) | 함 | ○ | ○(지연 위험) | 접속 이름, 역방향 DNS |
| 대화 중 실시간 조회 | 안 함 | ✕(지워짐) | ✕ | 접속 이름(-User) |
| 화면 조작형 에이전트·AI 브라우저 | 함 | ○ | ○ | 어려움(일반 브라우저로 보임) |
표 3. 화면 프레임워크 페이지 기준 결과(본문 기준 정리)
표에서 보듯 화면 프레임워크로 만든 페이지에서 대화 중 실시간 조회는 구조화 데이터도, 본문 수치도 얻지 못합니다. 메타 설명 정도만 전달됩니다.
실측 사례: 화면을 그리는 수집기도 오래 기다려야 합니다
1편에서 소개한 진단 사례(사명 비공개)에서 화면을 그리는 수집기의 조건을 흉내 내어 상품 수치가 화면에 나타나기까지의 시간을 쟀습니다.
그림 1. 화면을 그리는 수집기 조건에서의 표시 시간
같은 사례에서 화면 폭이 1280px 이하이면 스크립트가 모바일 주소로 이동시켰고, 모바일 페이지는 다시 PC 주소를 대표 주소로 지정하고 있었습니다. 화면을 그리는 수집기가 대표 주소를 읽으려다 다른 주소로 이동하게 되어, 어느 주소를 기준으로 삼을지 신호가 엇갈립니다.
실시간 조회는 왜 “에이전트의 진입”인가
실시간 조회는 지금 질문한 사람을 위해 AI가 대신 페이지를 여는 일입니다. 사람이 브라우저로 방문하던 일을 AI가 대신하는 것이므로, 실제 이용에 해당합니다. 결과가 그 자리에서 답변에 쓰이므로 사이트가 바뀌면 바로 차이가 드러납니다.
| 진입 형태 | 동작 | 식별 난이도 |
|---|---|---|
| 단순 조회 | 주소 하나를 읽고 답합니다(ChatGPT-User, Claude-User, Perplexity-User 등). | 낮음 — 접속 이름에 표시됩니다. |
| 다단계 조회·실행 | 여러 페이지와 API를 이어서 읽고 비교하거나 신청까지 진행합니다. | 중간 — 이어진 요청을 하나의 활동으로 묶어야 행동이 보입니다. |
| 화면 조작형 | 사람처럼 브라우저를 열고 버튼을 누르고 양식을 채웁니다. | 높음 — 접속 이름이 일반 크롬과 같습니다. |
표 4. 에이전트 진입의 세 형태(본문 기준 정리)
예를 들어 ChatGPT의 에이전트 기능은 접속 이름에 봇 표시가 없고 일반 크롬처럼 보이며, HTTP 메시지 서명 헤더(Signature-Agent 등)로만 구분된다는 실측 보고가 있습니다. 이름만 보는 방식으로는 이런 에이전트의 방문이 기록되지 않습니다.
그래서 점검 기준이 달라집니다
| 경로 | 점검할 질문 |
|---|---|
| ② 학습·검색 수집 | 원본 HTML 안에 핵심 사실이 있는가, 수집기가 막히지 않는가 |
| ② 화면을 그리는 수집 | 핵심 사실이 화면에 나타나기까지 얼마나 걸리는가, 다른 주소로 이동하지 않는가 |
| ③ 실시간 조회 | 글자로 바뀐 뒤에도 핵심 사실이 보이는가, 조회 도구가 거부되지 않는가 |
| ③ 에이전트 실행 | 에이전트가 기능을 찾고, 쓰고, 그 이용이 측정되는가 |
표 5. 경로별 점검 질문(본문 기준 정리)
“구조화 데이터를 넣을까, 본문을 고칠까”를 고르는 문제가 아닙니다. 경로마다 같은 사실을 읽을 수 있는지를 각각 확인해야 하며, 사이트 구조에 따라 답이 달라집니다.
용어 풀이
클라이언트 측 렌더링(CSR): 브라우저가 스크립트를 실행해 화면 내용을 채우는 방식입니다. 원본 HTML에는 본문이 비어 있습니다.
헤드리스 브라우저: 화면 없이 실행되는 브라우저입니다. 화면을 그리는 수집기의 동작을 흉내 낼 때 씁니다.
HTTP 메시지 서명: 요청을 보낸 쪽이 누구인지 서명으로 증명하는 방식(RFC 9421)입니다. 일부 AI 에이전트가 자신을 밝히는 데 쓰기 시작했습니다.
다음 글에서는 AI 봇이 실제로 어디서 막히는지, 그리고 에이전트에게 사이트의 기능·API·MCP 위치를 알리는 수단에는 무엇이 있는지 정리합니다. → 3편: AI 봇이 막히는 지점과 에이전트에게 길을 알리는 방법
우리 사이트, 경로마다 무엇이 전달되고 있을까요?
화면 구조와 보안 설정이 다르면 결과도 다릅니다. GEOcare.ai가 수집기·실시간 조회 도구·화면을 그리는 수집기 조건으로 직접 점검해 드립니다.
출처: Simon Willison, “ChatGPT agent’s user-agent”(2025-08-04, simonwillison.net) / IETF RFC 9421 HTTP Message Signatures / 비즈스프링 GEOcare 진단 실측(사명 비공개, 특정 시점·환경의 측정값)
자주 묻는 질문 (FAQ)
구조화 데이터(JSON-LD)를 넣으면 AI가 모두 읽나요?
올려도 됩니다. 학습·검색 수집기에는 원본 HTML의 구조화 데이터가 그대로 전달됩니다. 다만 대화 중 실시간 조회 도구는 페이지를 글자로 바꾸며 구조화 데이터를 지우는 경우가 많아, 이 경로에서는 보이지 않을 수 있습니다.
실시간 조회는 AI 검색 수집과 같은 것 아닌가요?
같은 경로가 아닙니다. 수집·색인은 사람이 기다리지 않는 사전 작업이고, 실시간 조회는 지금 질문한 사람을 위해 AI가 대신 페이지를 여는 일입니다. 받아 가는 내용과 점검 기준이 다릅니다.
리액트로 만든 페이지는 AI가 읽지 못하나요?
구글 수집기처럼 화면을 그리는 쪽은 읽을 수 있지만 시간이 걸리고 실패할 수 있습니다. 대부분의 AI 수집기와 실시간 조회 도구는 화면을 그리지 않아 본문을 얻지 못합니다.