AI 및 LLM 학습을 위한 웹 데이터 수집과 레지덴셜 프록시

모든 모델은 자신의 데이터에 거는 내기다. 처음부터 사전학습을 하든, 특정 도메인에 맞춰 파인튜닝을 하든, 검색용 코퍼스를 구축하든, 평가 세트를 만들든, 웹에서 수집한 데이터의 품질과 폭이 모델이 할 수 있는 것의 상한선을 정한다. 그리고 모델이 필요로 하는 규모로 웹 데이터를 수집하는 일, 수백만 개의 페이지와 여러 지역에 걸친 수집은 대규모 크롤러가 공통적으로 부딪히는 인프라 문제와 마주친다. IP별 속도 제한, 지역에 따라 달라지는 콘텐츠, 그리고 자동화된 크롤러처럼 보이는 모든 것을 점점 더 차단하는 사이트들이 그것이다. 레지덴셜 프록시는 이러한 크롤링을 가능하게 하는 수집 계층이며, 바로 이 지점이 레지덴셜 프록시가 맞아떨어지는 부분이다. 이 프록시가 해결하지 못하는 부분도 함께 다루는데, AI 데이터에서는 이 부분이 평소보다 더 중요하다.

AI 팀이 실제로 수집하는 것

수집의 형태는 목표에 따라 달라진다. 사전학습 및 지속 사전학습용 코퍼스는 공개 웹의 넓은 범위에 걸쳐 광범위하고 대량으로 텍스트를 끌어오는 작업이다. 도메인 파인튜닝은 더 좁고 깊은 작업으로, 특정 과업에 중요한 사이트들을 집중적으로 크롤링한다. RAG 시스템용 검색 코퍼스는 큐레이션되며 일정에 따라 갱신되어 인덱스가 오래된 상태로 표류하지 않도록 한다. 평가 및 벤치마크 세트는 규모는 작지만 대표성이 있고 깨끗해야 한다. 멀티모달 작업은 텍스트 위에 이미지 및 기타 자산을 추가한다. 이 모든 것이 공유하는 것은 그 밑에 깔린 수집 계층이다. 공개된 페이지들을 실제로 존재하는 곳에서 신뢰성 있게 대량으로 가져오는 것이다. 이 계층은 그 위에 무엇이 올라가든 동일하며, 이 글의 나머지 부분에서 다룰 내용이 바로 이것이다.

규모: 하나의 IP로 웹을 크롤링할 수 없는 이유

웹은 단일 주소가 수백만 개의 페이지를 끌어가는 것을 원하지 않는다. 대부분의 사이트는 IP별 속도 제한을 시행하며, 모든 것을 한 곳에서 보내는 크롤러는 몇 분 안에 속도 제한에 걸리고 이후 차단당해 크롤링은 모델에 필요한 규모에 한참 못 미치는 수준에서 멈춘다. 제한이 관대한 경우에도 하나의 연결은 수백만 건의 문서로 측정되는 코퍼스 앞에서 병목이 된다.

크롤링을 여러 레지덴셜 IP에 분산시키는 것이 느린 흐름을 하나의 코퍼스로 바꾸는 방법이다. 각 IP는 자체 IP별 제한 안에 편안하게 머무르는 동시에 전체 처리량은 풀 규모에 맞춰 확장되는데, 이것이 대용량 수집기가 의존하는 로드 밸런싱 로직이며, 무제한 동시 연결이 존재하는 이유다. 핵심은 어떤 단일 사이트를 압도하려는 것이 아니라, 크고 정중한 크롤링을 충분히 많은 주소에 분산시켜 어떤 개별 대상도 그 중 한 곳으로부터 평범한 수준 이상의 트래픽을 보지 않도록 하는 것이다.

대표성: 코퍼스는 수집한 곳만큼만 넓다

이 부분은 학습 데이터에 특히 해당되며 잘못하기 쉬운 부분이다. 모델은 자신에게 주어진 것의 분포를 학습하므로, 한 지역에서만 전적으로 수집한 코퍼스는 그 지역이 보는 웹의 단면만을 물려받는다. 많은 사이트가 지역별로 다른 콘텐츠를 제공한다. 현지화된 페이지, 다른 언어, 지역별 카탈로그, 가격, 재고 상황, 그리고 때로는 완전히 다른 첫 화면까지 다르다. 단일 국가에서 웹을 크롤링하면 그 국가가 보지 못하는 모든 것을 체계적으로 덜 표본화하게 되고, 그 편향은 모델에 그대로 굳어진다.

국가별, 그리고 필요한 경우 도시 수준 타겟팅을 통해 각 지역의 실제 사용자가 보는 버전의 페이지를 수집할 수 있으며, 이를 통해 코퍼스가 크롤러가 어디서 실행되었는지의 우연이 아니라 실제로 원하는 지리적, 언어적 분포를 반영하게 된다. 다국어 커버리지나 지역 균형이 목표라면, 이는 있으면 좋은 정도가 아니라 대표성 있는 데이터셋과 편향된 데이터셋을 가르는 차이다. 지역에 따라 달라지는 콘텐츠에 합법적으로 접근하는 것과 동일한 지오 타겟팅이 처음부터 데이터에 폭을 만들어 넣는 방법이다.

사이트가 크롤러에 대한 방어를 강화하는 상황에서 접근성 유지하기

사이트들은 자동화된 수집에 대해 눈에 띄게 더 방어적으로 변했으며, 그러한 강화의 상당 부분은 AI 크롤러를 정면으로 겨냥하고 있다. 알려진 데이터센터 IP 대역과 명백한 봇 신호는 빠르게 차단되며, 일부 대형 사이트는 이제 평범한 인간 방문자처럼 보이지 않는 트래픽에 대해 챌린지를 걸거나 거부한다. 데이터센터 주소에서 실행되는 크롤링은 콘텐츠 대신 차단과 챌린지 페이지를 점점 더 많이 돌려받는다.

레지덴셜 프록시는 요청을 실제 가정용 IP를 통해 라우팅하므로, 각 요청은 데이터센터의 서버가 아니라 평범한 방문자처럼 보이며, 평판이 좋은 깨끗한 주소는 플래그가 붙은 주소가 챌린지를 받는 곳을 통과한다. 하지만 이것만으로는 충분하지 않다. IP는 문을 열어줄 뿐이고, 나머지는 실제 클라이언트처럼 행동하는 것이다. 즉 합리적인 요청 속도, 차단을 유발하는 신호에 대한 정직한 처리, 그리고 할 수 있다는 이유만으로 대상을 두드리지 않는 것을 의미한다. 목표는 브라우저가 하듯이 공개 데이터를 수집하는 것이지, 크롤링당하고 싶지 않다고 결정한 사이트를 강제로 뚫고 지나가는 것이 아니다.

신선도: 코퍼스는 낡는다

데이터셋은 스냅샷이고, 웹은 움직인다. 특히 검색 코퍼스는 인덱스가 출처의 현재 상태를 반영하도록 정기적인 갱신 크롤링이 필요하며, 지속 사전학습은 새로운 것을 끌어오는 데 의존한다. 그렇기 때문에 수집은 일회성 작업이 아니라 지속적인 파이프라인이 되어야 하며, 지속적인 파이프라인은 시간이 지나면서 성능이 저하되는 경로들을 견뎌내야 한다. 특정 IP에서 차단, 타임아웃, 챌린지를 감지하면 그 경로를 은퇴시키고 새로운 경로로 계속 진행하는데, 이것이 장기 실행 크롤링을 유지시키는 페일오버 패턴이다. 이 모든 것은 맹목적으로 실행되어서는 안 되므로, 파이프라인을 모니터링해야 한다. 소스별 성공률, 커버리지, 오류 패턴을 보면 대상이 방어 체계를 바꿨는지, 아니면 크롤링의 일부가 조용히 실패하고 있는지를 다음 학습 실행에서 데이터 누락으로 드러나기 전에 알 수 있다.

책임감 있게 수집하기

솔직한 부분이며, AI 데이터에서는 선택 사항이 아니다. 레지덴셜 프록시는 수집 인프라이지 허가가 아니다. 책임감 있게 코퍼스를 구축한다는 것은 공개 데이터만 수집하고, 각 사이트의 robots 지침과 이용약관을 존중하며, 속도 제한과 백오프를 두어 의존하는 사이트를 절대 저하시키지 않도록 정중하게 크롤링한다는 뜻이다. 마찬가지로 중요한 것은, 기술적으로 페이지를 가져올 수 있는지 여부와는 별개로 권리에 관한 질문이다. 데이터를 수집할 수 있는 능력이 그것을 학습에 사용할 권리와 같은 것은 아니며, 저작권, 라이선스, 개인정보 규칙은 수집 계층 위에 자리하는 실질적인 제약이고 이를 올바르게 처리하는 것은 팀의 책임이다. 개인 및 민감 데이터는 신중하게, 그리고 법의 범위 안에서 다루어야 한다. 프록시는 대규모로 공개 페이지에 접근하는 방법의 문제를 해결하지만, 무엇을 그리고 해도 되는지는 여전히 스스로 결정해야 할 문제이며, 이를 진지하게 다루는 것이 방어 가능한 데이터셋과 부채가 되는 데이터셋을 가른다.

최소한의 정중한 크롤링

로테이팅 레지덴셜 프록시는 크롤러에게 평범한 프록시처럼 보인다. 타겟팅은 게이트웨이의 사용자명에 담겨 있으므로, 세션 식별자가 없는 US 종료점은 요청마다 회전하며 크롤링을 풀 전체에 분산시킨다:

import time
import requests

PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
proxies = {"http": PROXY, "https": PROXY}

def fetch(url):
    r = requests.get(url, proxies=proxies, timeout=20,
                     headers={"User-Agent": "research-crawler/1.0"})
    r.raise_for_status()
    return r.text

for url in urls:                 # your queue of public pages
    try:
        html = fetch(url)
        store(html)              # persist for the corpus
    except requests.HTTPError:
        retry_later(url)         # on a block or timeout, back off and requeue
    time.sleep(1.0)              # be polite; do not hammer a single origin

큐를 분산시켜 어떤 단일 사이트도 하나의 IP에서 오는 폭주를 보지 않도록 하고, 오류가 나면 강하게 재시도하는 대신 백오프를 적용하며, 다국어 또는 지역별 커버리지가 필요하면 동일한 크롤링을 다른 국가 타겟으로 실행한다. 일반적인 클라이언트 패턴은 Python으로 레지덴셜 프록시 사용하기 가이드에서 그대로 이어지며, 코퍼스가 세션 일관성이 있는 다중 페이지 가져오기를 필요로 할 때는 스티키 세션이 그 시퀀스 동안 하나의 IP를 유지해준다.

결론

AI 및 LLM 학습용 웹 데이터 수집은 세 가지에 의해 제약된다. 모델이 필요로 하는 규모, 이는 단일 IP로는 도달할 수 없다. 좋은 코퍼스에 요구되는 대표성, 이는 단일 지역으로는 포착할 수 없다. 그리고 점점 높아지는 안티 크롤러 방어의 벽, 이는 데이터센터 주소로는 점점 더 통과할 수 없다. 레지덴셜 프록시는 이 세 가지 모두에 답한다. 크롤링을 대규모 풀에 분산시켜 각 IP가 정중함을 유지하면서 전체 처리량이 확장되게 하고, 국가와 도시를 타겟팅하여 코퍼스가 실제로 원하는 지리와 언어를 반영하게 하며, 깨끗한 가정용 IP를 통해 라우팅하여 요청이 평범한 방문자처럼 보이게 하고, 모니터링과 함께 페일오버하여 지속적인 갱신 크롤링이 계속 실행되게 한다. 그런 다음 프록시가 하지 않는 부분을 직접 하면 된다. 공개 데이터만 수집하고, robots와 이용약관을 존중하고, 정중하게 크롤링하며, 라이선스와 프라이버시는 수집 계층 위, 마땅히 있어야 할 곳에 두는 것이다.

그 수집 계층이 바로 레지덴셜 프록시가 존재하는 이유다. 실제 가정용 IP로 이루어진 대규모 풀에 국가 및 도시 타겟팅, 그리고 시퀀스가 필요할 때의 스티키 세션이 함께 제공된다. GB당 가격 책정은 실제로 끌어온 데이터에 대해서만 비용을 지불한다는 의미이며, 이는 집중적인 도메인 크롤링부터 수백만 페이지로 측정되는 코퍼스에 이르기까지 다양한 작업 부하에 적합하다.