search-indexing

2 개의 포스트

cloudflare

내 사이트, 내 규칙: 모든 고객을 위한 새로운 AI 트래픽 옵션 (새 탭에서 열림)

AI 트래픽은 더 이상 “차단할 것인가, 허용할 것인가”의 단순한 문제가 아니며, 웹사이트 운영자는 봇의 목적에 따라 접근을 세분화해 관리해야 한다는 글입니다. Cloudflare는 AI 트래픽을 **검색(Search), 에이전트(Agent), 학습(Training)**으로 분류하고, 각 유형을 개별적으로 허용하거나 차단할 수 있는 기능을 모든 고객에게 제공합니다. 특히 광고가 표시되는 페이지에서는 2026년 9월 15일부터 학습·에이전트 봇은 기본 차단하고, 검색 봇은 기본 허용할 예정입니다. ## AI 봇을 일괄 차단하기 어려운 이유 - 기존에는 AI 기업이 콘텐츠를 학습에 사용하면서도 웹사이트에 방문자나 보상을 돌려주지 않는 문제가 컸습니다. - 이에 Cloudflare는 2025년부터 다음과 같은 대응책을 제공했습니다. - 한 번의 설정으로 AI 봇을 차단하는 **“Block AI Bots”** - 크롤링 건별로 콘텐츠 사용료를 받는 **Pay-Per-Crawl** 마켓플레이스 - 그러나 모든 자동화 트래픽을 차단하면 소규모 사이트는 검색 결과에서 발견될 기회까지 잃을 수 있습니다. - 검색 노출을 얻기 위해 AI 학습까지 허용해야 하는 상황은 대형 검색 사업자에게 유리한 구조를 만들고, 신규 사업자가 봇의 정체를 숨기도록 유도할 수 있습니다. ## AI 대신 봇의 행동을 기준으로 분류 - AI 기술의 범위는 빠르게 변하므로, 봇을 단순히 “AI 봇”인지 아닌지로 구분하는 방식은 오래 유지되기 어렵습니다. - 대신 다음 질문을 기준으로 봇을 평가합니다. - 사이트에서 무엇을 하는가? - 콘텐츠를 어디에 저장하는가? - 나중에 콘텐츠를 어떻게 재공유하는가? - 하나의 봇이 여러 목적을 수행한다면 대표 목적 하나만 기록하지 않고, **모든 목적을 함께 추적**하는 방향을 채택합니다. ## 검색·에이전트·학습의 3가지 분류 ### 검색(Search) - 사이트 콘텐츠를 수집하거나 색인해 나중에 질문에 답하는 데 사용하는 자동화입니다. - 검색 엔진이나 AI 답변 엔진이 사이트 데이터를 미리 데이터베이스화하는 행위가 해당됩니다. - 사이트 운영자는 검색 유입이나 그에 상응하는 보상을 기대할 수 있습니다. - Google 검색처럼 결과 페이지에서 직접 답변을 제공하는 서비스도 이 범주와 관련됩니다. ### 에이전트(Agent) - 사용자를 대신해 실시간으로 작업을 수행하는 자동화입니다. - 예시: - ChatGPT-User 같은 채팅 기반 가져오기 봇 - Gemini 또는 Claude가 브라우저를 조작하는 브라우저 에이전트 - 일반적으로 사람이 요청한 작업을 완료하기 위해 웹 애플리케이션을 방문합니다. - 콘텐츠를 장기적으로 학습하기보다는 특정 시점에 필요한 정보를 조회하거나 거래를 수행하는 것이 핵심입니다. ### 학습(Training) - 콘텐츠를 모델 학습이나 파인튜닝에 사용하기 위해 수집하는 크롤러입니다. - 사이트 데이터가 AI 모델의 내부 구조에 영구적으로 흡수되어 모델의 능력을 개선하는 것이 특징입니다. - 검색처럼 방문자를 되돌려 보내는 목적이 명확하지 않기 때문에, 사이트 운영자가 별도로 차단하거나 보상을 요구할 수 있어야 합니다. ## 목적별로 분리된 크롤러의 필요성 - 하나의 기업이 검색 색인 구축, 사용자 대신 작업 수행, 모델 학습을 모두 한다면 각 목적에 맞는 크롤러를 분리하는 것이 권장됩니다. - 크롤러를 분리하면 사이트 운영자가 다음을 더 명확히 파악할 수 있습니다. - 어떤 이유로 방문했는지 - 어떤 콘텐츠 접근 권한이 필요한지 - 검색은 허용하면서 학습은 차단할 수 있는지 - 일부 크롤러는 여러 목적을 동시에 수행할 수 있으며, Googlebot·Applebot·BingBot처럼 검색과 학습 목적이 결합된 봇이 그 예입니다. ## Cloudflare의 새로운 AI 트래픽 관리 옵션 - Cloudflare는 기존의 일괄적인 **“Block AI Bots”** 설정을 세분화합니다. - 모든 요금제, 무료 요금제를 포함한 고객이 다음 유형을 각각 관리할 수 있습니다. - Search 크롤러 - Agent 크롤러 - Training 크롤러 - 이를 통해 사이트 운영자는 다음과 같은 정책을 설정할 수 있습니다. - 검색 봇은 허용하고 학습 봇은 차단 - 에이전트 접근은 허용하되 특정 콘텐츠에서는 제한 - 모든 유형을 허용하거나 차단 - Cloudflare는 광고 검증, 피드 수집, 에이전트 기반 거래 등 다른 자동화 유형도 분류하고 있지만, 이번 변경의 중심은 세 가지 AI 사용 사례입니다. ## 2026년 9월 15일부터 적용되는 기본값 - 새로 Cloudflare에 등록되는 도메인의 광고 표시 페이지에는 다음 기본 정책이 적용됩니다. - **Training:** 기본 차단 - **Agent:** 기본 차단 - **Search:** 기본 허용 - 광고는 사람이 페이지를 방문해 콘텐츠를 보고 관심을 갖는 것을 전제로 하는 수익 신호입니다. - 따라서 광고 페이지에서는 사람의 관심을 방해하거나 콘텐츠를 재사용할 수 있는 학습·에이전트 봇을 차단하고, 방문자를 유도할 가능성이 높은 검색 봇은 허용한다는 논리입니다. - 여러 목적을 가진 크롤러는 모든 목적에 대한 규칙을 적용받으며, 가장 제한적인 규칙이 우선합니다. - 따라서 Training을 차단한 고객은 검색과 학습을 함께 수행하는 Googlebot, Applebot, BingBot도 차단될 수 있습니다. - 운영자는 9월 15일 이전에 Cloudflare 보안 설정에서 새 기본값을 적용하지 않도록 선택할 수 있습니다. 사이트 운영자는 모든 AI 자동화를 일괄 차단하기보다 검색·에이전트·학습 목적을 구분해 정책을 설정하는 것이 좋습니다. 특히 검색 유입이 중요한 사이트는 Search를 허용하되 Training과 Agent를 별도로 차단하고, Googlebot처럼 다목적 봇이 어떤 규칙을 적용받는지 사전에 점검해야 합니다.

figma

딥 서치 심층 분석 | 피 (새 탭에서 열림)

Figma의 Deep Search는 파일명이나 폴더명을 몰라도 파일 내부의 텍스트와 내용을 검색할 수 있도록 만든 기능이다. 일반 검색이 데이터베이스의 메타데이터를 색인하는 것과 달리, Deep Search는 S3에 저장된 `.fig` 파일을 직접 읽고 객체 트리를 순회해야 한다. 이를 위해 기존 Design System Analytics 인프라를 확장하고, 처리 비용과 최신성 사이에서 타협해 변경 사항을 시간 단위로 모아 색인하는 방식을 선택했다. ## 브라우저 기반 제품이 제공하는 검색 가능성 - Figma는 데스크톱 애플리케이션이 아닌 브라우저 기반 도구이므로, 사용자가 접근할 수 있는 파일에 대한 풍부한 정보를 수집하고 분석할 수 있다. - 파일의 조회 빈도, 컴포넌트 사용량, 파일 구조 등 웹 환경에 적합한 데이터를 활용할 수 있다. - 이러한 특성은 협업을 강화한다. - 별도 파일을 내보내지 않아도 이해관계자가 진행 중인 작업을 확인할 수 있다. - 프로토타입 공유와 핸드오프가 간소화된다. - 작업 중인 결과물을 쉽게 공유할 수 있다. - Deep Search는 파일명보다 프로젝트의 아이디어, 문구, 해결하려던 문제를 기억하는 사용자의 검색 방식에 맞춘 기능으로 기획됐다. ## Design System Analytics에서 얻은 기술적 기반 - Figma는 앞서 Design System Analytics(DSA)를 출시해 팀 간 디자인 시스템과 공유 라이브러리의 사용 현황을 분석했다. - DSA와 Deep Search 모두 다음과 같은 공통 처리가 필요했다. - 최근 수정된 파일을 식별한다. - 스토리지에서 파일을 내려받는다. - 파일 내부를 순회한다. - 목적에 맞는 정보를 추출한다. - DSA는 공유 라이브러리 사용량을 추출하고, Deep Search는 파일 내부의 텍스트를 추출한다. - Figma는 DSA를 위해 만든 파일 분석 인프라와 워커를 일반화해 Deep Search의 기반으로 활용했다. ## 일반 검색의 색인 파이프라인 - 기존 Unified Search를 포함한 일반 검색은 데이터베이스에 저장된 메타데이터를 대상으로 한다. - 예시로 파일 ID, 폴더 ID, 팀 ID, 파일명, 폴더명, 생성자 등의 정보를 사용한다. - 처리 과정은 다음과 같다. - 데이터베이스의 관련 테이블 변경 사항을 감시한다. - 변경된 항목의 ID를 메시징 시스템으로 전달한다. - 검색 색인기가 최신 데이터를 데이터베이스에서 가져온다. - 가져온 메타데이터를 Elasticsearch 클러스터에 색인한다. - 데이터베이스 조회는 비교적 저렴하기 때문에 변경될 때마다 빠르게 색인을 갱신할 수 있다. ## Deep Search가 더 복잡한 이유 - Figma 파일의 실제 표현은 데이터베이스가 아니라 Amazon S3에 저장된 `.fig` 문서다. - `.fig` 파일은 트리 구조로 구성된다. - 각 노드는 타원, 프레임, 벡터, 텍스트 같은 Figma 객체를 나타낸다. - 노드에는 객체의 속성과 콘텐츠가 함께 저장된다. - Deep Search는 파일의 메타데이터만 확인하는 것이 아니라, S3에서 파일을 가져온 뒤 전체 객체 트리를 순회해야 한다. - 하나의 파일에 수천 개의 노드가 있을 수 있어 파일을 읽고 분석하는 작업은 일반적인 데이터베이스 조회보다 훨씬 계산 비용이 크다. ## 처리 비용과 검색 최신성 사이의 타협 - Figma 파일은 편집 중에도 약 30초마다 자동 저장될 수 있다. - 저장될 때마다 Deep Search 색인을 갱신하면 같은 파일을 반복적으로 내려받고 분석하게 되어 서버 비용이 크게 증가한다. - Figma는 이를 해결하기 위해 파일 변경 사항을 한 시간 동안 중복 제거한다. - 이후 변경된 파일을 파일 분석 워커로 보내 주기적으로 처리한다. - 그 결과 Deep Search 결과가 일반 검색보다 잠시 오래된 상태일 수 있지만, 반복적인 파일 분석을 줄여 상당한 서버 자원을 절약할 수 있다. - 이는 검색 결과의 즉시성보다 시스템 비용과 확장성을 우선한 제품·인프라상의 결정이다. ## 실용적인 결론 대용량 문서나 복잡한 구조를 검색할 때는 모든 변경을 즉시 처리하기보다 변경 사항을 모아 중복 작업을 제거하는 방식이 효율적이다. 검색 결과가 수초 또는 수분 정도 지연되어도 괜찮다면, 배치 처리와 주기적 색인을 통해 계산 비용과 인프라 부담을 크게 줄일 수 있다.