재크롤링 문제: RAG 파이프라인의 최신성 유지하기

도전 과제

버티컬 AI 스타트업들은 모두 출시 2개월 차쯤에 동일한 장벽에 부딪힙니다. 이들은 고객 지원 코파일럿, 법률 조사 어시스턴트, 또는 컴플라이언스 봇을 출시합니다. 첫 데모는 고객의 마음을 사로잡습니다. 하지만 이후 데이터가 노후화되면서 답변이 현실과 동떨어지기 시작합니다.

우리는 많은 팀이 AI 영역은 깔끔하게 구축하면서도 데이터 영역은 나중에 생각하는 것을 보아왔습니다. 데이터 수집 파이프라인은 누군가의 노트북에서 실행되는 단 하나의 Python 스크립트일 뿐입니다. 이 스크립트는 200개의 소스 URL을 한 번 스크랩하고, 깔끔한 Markdown을 벡터 스토어에 저장하며, 모두가 이를 자축합니다. 6주 후, 답변의 절반은 삭제된 페이지, 지원 중단된 API, 또는 3월에 출시되었다가 5월에 다시 출시된 제품 기능을 참조하게 됩니다.

해결책은 간단해 보입니다. 매주 모든 소스를 리크롤링하는 것입니다. 하지만 현실은 더 가혹합니다. 2026년까지 신뢰할 수 있는 사이트의 약 60%가 AI 크롤러를 차단(2023년 말 23%에서 증가)하며, 이러한 보호 조치는 더 이상 단순한 User-Agent 확인 수준이 아닙니다. 이들은 세션 동작, request 리듬, 핸드셰이크 수준의 신호를 분석합니다. 1월에 잘 작동하던 단순한 스크립트가 3월에는 아무런 에러 없이 빈 페이지를 반환하게 됩니다.

설상가상으로, 일부 사이트는 이제 임베딩을 오염시킬 때까지 타르핏(tarpit) 콘텐츠(실제 글처럼 읽히는 마르코프 생성 노이즈 텍스트)를 제공합니다. 결국 엔지니어들은 제품을 배포하는 대신 일주일의 절반을 스크래퍼를 패치하는 데 허비하게 됩니다. 검색 품질이 떨어지고, 고객이 이를 알아차리며, AI를 구축하기 위해 채용한 팀은 스크래퍼 유지보수 부서로 전락합니다.

해결 방법

리크롤링 문제는 모든 request마다 결정해야 하는 세 가지 구체적인 판단으로 나뉩니다.

렌더링 여부 대부분의 문서 포털은 깔끔한 HTML을 제공합니다. 하지만 점차 늘어나는 비율(Next.js로 구축된 모든 것, 클라이언트 사이드 렌더링을 사용하는 모든 것)의 사이트들은 유용한 콘텐츠를 반환하기 위해 전체 브라우저 렌더링이 필요합니다.
어떤 proxy를 사용할 것인가? 주거용(residential), 데이터센터, 모바일, 지오핀(geo-pinned), ISP 전용 등 대상에 따라 적절한 선택이 달라집니다.
실제로 작동했는가? 본문이 비어 있는 200 응답이나 CAPTCHA HTML 페이지는 HTTP request 관점에서는 성공이지만, 크롤링 관점에서는 실패입니다.

FourA와 같은 플랫폼은 이러한 각각의 문제를 최우선 과제로 처리합니다.

렌더링 결정의 경우, 비용이 저렴하고 빠른 케이스에는 Single을 호출하고, JS가 많은 대상에는 Browser를 호출합니다. 호출의 body는 동일한 형태이므로, 수집 코드는 수백 개의 사이트별 특이성을 처리하는 대신 소스별 플래그에 따라 한 번만 분기하면 됩니다.

proxy 선택의 경우, 모든 Single, Browser, Auto 호출의 일부로 Proxy Finder가 실행됩니다. 플랫폼은 request당 작동하는 출구를 선택하고, 응답 meta.proxy에 불투명 ID를 반환하며, 동일한 출구를 유지해야 할 때 후속 호출에서 해당 ID를 재사용합니다. 크롤러는 자체적인 proxy 순위 지정 알고리즘을 가질 필요가 없습니다. (풀 크기가 더 이상 차별화 요소가 되지 않는 이유에 대해서는 2026년에 proxy 풀 크기가 중요하지 않게 된 이유에서 다루었습니다.)

그리고 "실제로 작동했는가"라는 질문에 대해, 모든 request는 validate 블록을 지원합니다. 허용되는 상태 코드, 필수 header 값, 포함되거나 포함되지 않아야 하는 body 문자열 등 성공으로 간주할 기준을 선언합니다. FourA는 7가지 결과 중 하나를 반환하며, 오직 success에 대해서만 비용이 청구됩니다. 콘텐츠 규칙을 통과하지 못한 200 응답은 application_fail로 표시되며 데이터 세트에 절대 들어가지 않습니다.

다음은 JS 렌더링이 필요한 문서 포털에 대한 리크롤링 호출의 예시입니다. Auto가 이를 오케스트레이션하도록 하여, 적절한 제품(Single, Proxy, 또는 Browser)을 선택하고, 봇 방어를 처리하며, 다음 리크롤링이 동일한 출구를 유지할 수 있도록 세션 트리플을 반환합니다.

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

대상 사이트가 Cloudflare 인터스티셜(대기 화면)을 띄우면, validate.data.fail 규칙이 이를 감지합니다. 사용량에 기록되는 결과는 application_fail입니다. 이에 대한 비용은 지불하지 않으며, 수집 코드는 "Just a moment..." 페이지를 임베딩에 주입하는 대신 다른 proxy로 재시도해야 함을 인지하게 됩니다.

더 넓은 말뭉치(corpus)의 경우, 기존 작업 대기열(job queue)에 동일한 패턴을 래핑하면 됩니다. 우리가 대화 나눈 팀들은 이전 크롤링과 매일 밤 diff를 실행하고, 실제로 변경된 문서만 다시 임베딩하며, 몇 시간 만에 500개 소스의 말뭉치를 갱신합니다. 작업 대기열은 귀사의 것을 그대로 유지합니다. proxy 교체, 렌더링 결정, 성공 판정은 저희가 처리합니다.

결과

인프라가 더 이상 병목이 되지 않을 때 최신성 루프(freshness loop)가 어떻게 작동하는지 보여주는 예시입니다 (버티컬 AI 팀들에서 관찰한 패턴을 기반으로 한 가상의 시나리오).

매주 500개의 소스 URL 리크롤링 (출시 시점의 200개 URL 일회성 크롤링 대비)
스크래퍼에 소요되는 엔지니어링 시간: 주당 2시간 미만 (기존 1~2일에서 단축)
검색 데이터의 노후화 기간: 5~7일 (기존의 무제한에서 단축)
벡터 스토어 내 가비지 데이터 비율 제로에 수렴, Cloudflare 인터스티셜 및 타르핏 페이지가 임베딩 모델에 도달하기 전에 validate 레이어에서 거부되기 때문
소스당 예측 가능한 비용, 실패한 크롤링은 청구서에 포함되지 않기 때문

중요한 점은 이 중 어느 것도 마법이 아니라는 것입니다. 핵심은 이 과정이 지루할 정도로 평범하다는 점입니다. 그리고 프로덕션 AI에 필요한 것이 바로 이 지루함입니다. (호스팅된 LLM 추출의 비용 효율성이 떨어지는 시점에 대해 자세히 알아보려면 LLM 추출의 비용 효율성이 떨어지는 시점을 참고하세요.)

핵심 요약

버티컬 AI를 구축하는 대부분의 팀은 프롬프트, 모델 선택, 또는 검색 알고리즘이 진입 장벽(moat)이라고 생각합니다. 하지만 그렇지 않습니다. 진짜 진입 장벽은 최신성 루프입니다. 매주 지식 베이스의 정확성을 유지하는 보이지 않는 인프라가 바로 그것입니다.

2026년까지 버티컬 AI 분야에서 승리할 팀은 가장 똑똑한 프롬프트를 작성하는 팀이 아닐 것입니다. 데이터가 항상 최신 상태로 유지되기에, 사용자가 데이터의 최신 여부조차 의식하지 못하게 만드는 팀이 승리할 것입니다.