LLM에 AI 그라운딩을 위한 레지덴셜 프록시가 필요한 이유

지난 18개월 동안 하나의 패턴이 자리잡았다. 실제 프로덕션에서 쓸모 있는 작업을 수행하는 흥미로운 AI 시스템들은 단순히 모델에 질의하고 그 답변을 그대로 반환하지 않는다. 이들은 추론 시점에 실시간 데이터 소스에서 정보를 검색하고, 검색 결과를 컨텍스트로 모델에 전달하여, 모델이 가장 최신의 정보를 바탕으로 추론하게 한다.

이 패턴에는 이름이 있다. 가장 흔한 것은 RAG다. 도구 사용(tool-use), 함수 호출(function-calling), 웹 검색 기반 생성(web-search-grounded generation) 등도 있다. 명칭은 다양하지만 아키텍처는 동일하다. 모델 혼자서는 학습된 데이터만 알고 있다. 검색 기능이 있는 모델은 학습 마감 시점 이후의 질문에도 답할 수 있다.

아무도 다루지 않는 부분이 바로 이 검색 과정이다. 구체적으로는, 대상 사이트가 AI 시스템에 실제로 원하는 페이지를 제공하는지 여부를 결정하는 요인이다.

The retrieval failure mode

“amazon.com에서 이 제품의 현재 가격이 얼마인지”에 답해야 하는 프로덕션 AI 에이전트를 생각해보자. 에이전트는 검색어를 구성하고, 검색 인덱스에 요청을 보내고, URL을 받아온 뒤, 그중 하나를 가져와서, HTML을 파싱하고, 가격을 찾아 반환한다.

이 과정은 여섯 단계로 이루어지며 그중 어느 것이든 실패할 수 있다. 가장 자주 실패하면서도 엔지니어링 관심을 가장 적게 받는 단계는 바로 가져오기(fetch)다. 대상 사이트는 요청을 받으면 실제 페이지를 제공할지, 저하된 페이지를 제공할지, 아니면 아예 페이지를 제공하지 않을지를 판단하여 응답한다. 이 판단은 대체로 사이트가 상위(upstream) IP를 어떻게 인식하는가에 근거한다.

요청이 AWS / GCP / Azure의 이그레스(egress) IP에서 온 것이라면, 사이트는 이것이 봇일 가능성이 높다고 사전에 판단한다. Amazon, Google, Reddit, X 등 주요 뉴스 매체를 포함한 대형 사이트들은 데이터센터 트래픽에 대해 공격적인 방어 체계를 갖추고 있다. 돌아오는 페이지는 대개 빈 페이지, CAPTCHA 챌린지, 403 오류, 혹은 (가장 은밀하게는) 가격도 재고도 실제 콘텐츠도 없는 축소된 버전인 경우가 많다.

다운스트림에 있는 AI 시스템은 자신이 받은 페이지가 저하된 것인지 알지 못한다. 받은 내용을 파싱하고, 쓸모 있는 정보를 찾지 못하면, 답을 지어내거나 “그에 대한 최신 정보가 없습니다”라고 응답한다. 두 실패 유형 모두 아예 검색하지 않는 것보다 나쁘다.

Why residential changes the calculus

레지덴셜 IP는 본질적으로 실제 소비자 ISP가 실제 가정에 할당한 IP다. 그 뒤에는 수년간의 정상적인 트래픽, 즉 스트리밍, 브라우징, 화상 통화, 모바일 앱 사용 이력이 쌓여 있다. 대상 사이트의 관점에서 볼 때, 이 IP에서 오는 요청은 가정 방문자와 구분되지 않는다. 실제로 가정 방문자의 네트워크에서 오는 요청이기 때문이다.

데이터센터 트래픽에서 작동하는 방어 계층은 대부분 레지덴셜 트래픽에서는 작동하지 않는다. 돌아오는 페이지는 가정 방문자가 보는 바로 그 페이지다. 가져오기 이후 단계에 있는 AI 시스템은 실제 페이지의 실제 콘텐츠를 받는다.

이것이 바로 레지덴셜 프록시 네트워크가 하나의 제품 카테고리로 존재하는 이유다. 또한 신선한 웹 데이터가 필요한 프로덕션 AI 시스템들, 이제 수천 개에 달하는 이들이 공개된 아키텍처 다이어그램에 언급하지 않으면서도 조용히 레지덴셜 프록시 인프라에 비용을 지불하는 이유이기도 하다.

Three classes of AI workload, three different shapes

검색 패턴은 표면적으로 비슷해 보이지만, 프록시 요구사항은 워크로드 유형에 따라 크게 갈린다.

Search-grounded chat. 사용자가 질문하면 모델은 웹 검색으로 확장하여 상위 3~10개 결과를 병렬로 가져와 요약한다. 거대한 레지덴셜 풀 전체에 걸친 요청 단위 로테이션이 적합한 기본 방식이며, 가져오기마다 새로운 IP를 사용하고, 세션이 필요 없으며, 지리적/ISP 다양성이 최대화된다. 워크로드는 돌발적이고 예측하기 어렵다. 총 대역폭이 질문량에 비례해 확장되므로 대역폭 기반 요금제가 적합하다.

Comparative shopping agents. 에이전트는 사용자가 여러 벤더 간 가격을 비교하도록 돕는다. 각 벤더 방문은 검색 결과, 제품 상세, 리뷰, 때로는 결제 시뮬레이션까지 여러 페이지를 필요로 할 수 있다. 스티키 세션(sticky session)이 적합한 기본 방식이다. 벤더 세션당 약 5분간 하나의 레지덴셜 IP를 유지하여, 벤더 사이트가 수천 개의 스크레이퍼가 아니라 일관된 한 명의 쇼핑객으로 인식하게 한다. 벤더 가격이 도시별로 달라지기 때문에 지리적 정밀도가 중요하다. 사용자가 기다리고 있기 때문에 지연 시간도 중요하다.

Continuous data pipelines. 모니터링 시스템이 N분마다 가격, 뉴스, 규제 신고 자료, 소셜 언급을 검색한다. 대용량이고, 예측 가능하며, 대부분 병렬로 처리된다. 요청 단위 로테이션을 사용하며, 사이트에 일관된 세션이 필요할 때는 작업 단위로 큰 sid 풀을 사용하고, 대역폭 예산을 공격적으로 관리한다. 전통적인 스크레이핑과 가장 유사한 워크로드이며, 프록시 스택에서 가장 성숙한 영역이다.

당신의 AI 시스템에 검색 기능이 있는데 이 세 가지 형태 중 어디에 해당하는지 의식적으로 생각하고 있지 않다면, 기본 설정은 이 중 적어도 하나에 대해서는 잘못되어 있을 가능성이 크다.

What this looks like in code

레지덴셜 프록시를 감싼 최소한의 grounded-fetch 래퍼는 다음과 같다:

import os, requests
from urllib.parse import urlparse

SHIFTER_USER = os.environ["SHIFTER_USER"]
SHIFTER_PASS = os.environ["SHIFTER_PASS"]

def grounded_fetch(url, country="us", session_id=None, timeout=20):
    """Fetch a URL through a residential IP. Returns response.text or raises."""
    auth_user = f"customer-{SHIFTER_USER}-country-{country}"
    if session_id:
        auth_user += f"-sid-{session_id}"
    proxy = f"http://{auth_user}:{SHIFTER_PASS}@p.shifter.io:443"
    resp = requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        timeout=timeout,
        headers={"User-Agent": "Mozilla/5.0 (Macintosh) AppleWebKit/537.36"},
    )
    resp.raise_for_status()
    return resp.text

# Use case 1: search-grounded chat, fresh IP per fetch
for url in search_results:
    html = grounded_fetch(url, country="us")
    # ... parse and feed to LLM

# Use case 2: comparative shopping, sticky IP per vendor
for vendor_url in vendors:
    domain = urlparse(vendor_url).netloc
    session = f"agent-{user_id}-{domain}"
    html = grounded_fetch(vendor_url, country="us", session_id=session)
    # ... navigate within session

# Use case 3: continuous pipeline, per-request rotation, country fan-out
for country in ["us", "uk", "de", "jp"]:
    for url in monitoring_urls:
        html = grounded_fetch(url, country=country)
        # ... feed to indexer

세 가지 패턴의 차이는 파라미터 하나뿐이다. 그라운딩 시스템은 프록시의 작동 메커니즘을 알 필요 없이, 자신의 워크로드 유형에 맞는 세션 고정(session-stickiness) 방식으로 grounded_fetch를 호출하기만 하면 된다.

Things to watch for

레지덴셜 프록시 네트워크 위에 AI 그라운딩을 구축하고 있다면, 프로덕션 사고의 대부분은 다음 세 가지 실패 유형에서 비롯된다:

Silent content degradation. 대상 사이트가 축소된 페이지를 200 응답으로 반환한다. 파이프라인은 오류를 내지 않고 그저 쓸모없는 데이터를 모델에 입력한다. 완화 방법: LLM에 전달하기 전에 응답 형태를 검증한다. 페이지가 해당 도메인의 중간값 페이지보다 80% 더 짧다면, 이를 소프트 실패로 간주하고 다른 IP로 재시도한다.

Geo drift. country=us로 요청하여 미국 레지덴셜 IP를 통해 라우팅했지만, 대상 사이트의 지리적 위치 조회 결과 해당 IP가 캐나다로 판별되었다. 페이지는 CAD 통화와 캐나다 재고 정보로 돌아왔다. 완화 방법: 지리적 정밀도가 중요할 때는 도시 단위 타겟팅을 사용하고, 응답을 사용하기 전에 요청한 로케일과 일치하는지 확인한다.

Session expiry mid-flow. 다단계 에이전트 흐름이 레지덴셜 IP A에서 시작되었는데, 세션 TTL이 만료되어 다음 요청이 레지덴셜 IP B로 전달되면, 대상 사이트가 이를 감지하고 재인증(re-auth) 챌린지를 던진다. 완화 방법: 예상되는 가장 긴 흐름을 포괄하도록 세션 TTL을 늘리거나, 재인증 챌린지를 감지하여 의식적으로 로테이션한다.

The bigger point

AI 시스템은 이제 레지덴셜 프록시 인프라의 가장 큰 고객 범주 중 하나다. 그 이유는 AI가 특별해서가 아니라, AI가 잘못된 검색의 비용을 배가시키기 때문이다. 챗봇 답변 하나에 잘못된 가격이 하나 있으면 그것은 하나의 나쁜 답변이다. 백만 개의 챗봇 답변에 백만 개의 잘못된 가격이 있으면 그것은 고객 신뢰의 문제가 된다.

인프라 계층은 이미 존재하고 있었다. 스크레이핑, 광고 검증, 가격 정보 수집을 위해 구축된 것이었다. AI 그라운딩은 그 위에 올라온 가장 새롭고 가장 큰 워크로드 유형이지만, 그 요구사항은 지난 10년간 진지한 데이터 팀이라면 누구나 가지고 있던 것과 동일하다. 진짜 레지덴셜 IP, 진짜 지리적 분산, 진짜 세션 제어, 예측 가능한 비용.

당신의 AI 시스템이 실시간 웹에 근거를 두고 있다면, 레지덴셜 프록시 요금제를 구매할 때 실제로 사는 것은 대상 사이트가 당신의 시스템에 보여주는 페이지가 실제 사용자에게 보여주는 것과 같은 페이지라는, 그다지 화려하지 않은 보장이다. 그것이 기반이다. 그 위에 있는 모든 것, 임베딩, 검색, 프롬프팅, 파인튜닝은 이 기반이 제대로 작동해야만 함께 작동한다.