MCP 서버 및 API 프록시: AI 에이전트를 위한 자동 IP 변경

전통적인 파서는 프록시 목록을 받아서 단순히 순환하며 사용하다가, 안티봇 시스템이 패턴을 감지하면 멈춥니다. 그러나 AI 에이전트는 다르게 작동합니다: 차단을 감지하면 스스로 IP를 변경하기로 결정하고, 헤더를 변경하며, 요청 속도를 조절합니다 — 이 모든 것이 사용자의 개입 없이 이루어집니다. 에이전트, MCP 서버 및 API 프록시를 연결하여 보호된 사이트에서도 세션을 유지할 수 있는 작업 흐름을 구축하는 방법을 알아보겠습니다.

MCP 서버란 무엇이며 파서에 필요한 이유

MCP (모델 컨텍스트 프로토콜)는 AI 에이전트(예: Claude 기반 또는 tool-calling을 지원하는 LLM)가 단일 인터페이스를 통해 외부 도구에 접근할 수 있도록 하는 개방형 프로토콜입니다. 이전에는 모델이 외부 API에 접근하기 위해 각 작업에 맞는 커스텀 래퍼를 작성해야 했습니다. MCP 서버는 이를 다르게 해결합니다: 에이전트가 필요할 때 스스로 호출할 수 있는 "도구"(tools) 세트를 설명합니다.

스크래핑의 맥락에서 이는 다음과 같이 작동합니다: 에이전트는 "마켓플레이스에서 500개의 상품 가격을 수집하라"는 작업을 받습니다. 그는 fetch_page 도구를 통해 요청을 시작하고, 403 응답이나 CAPTCHA를 감지하면 rotate_proxy 도구를 호출하여 새로운 IP를 받고 요청을 반복합니다 — 운영자의 개입 없이. 여기서 MCP 서버는 에이전트의 논리와 실제 프록시 인프라 간의 "다리" 역할을 합니다.

일반적인 타이머 기반 IP 변경 스크립트와의 주요 차이점은 에이전트가 응답 코드, 페이지 내용, 특정 도메인의 차단 속도에 따라 IP 변경 결정을 내린다는 것입니다. 그는 인증 세션을 위해 하나의 IP를 유지하고 데이터 수집을 위한 "차가운" 요청에 대해서만 IP를 변경할 수 있으며, 실시간으로 전략을 조합할 수 있습니다.

AI 에이전트가 IP 변경이 필요한 이유, 단순한 프록시 목록이 아닌

에이전트에게 정적인 50개의 프록시 목록을 제공하고 이를 순환하도록 요청하면, 일반적인 스크립트와 동일한 결과를 얻을 수 있습니다: 요청 패턴은 간격, 헤더 및 IP 순서에 따라 안티봇 시스템에 의해 빠르게 계산됩니다. Wildberries, Ozon, Avito 및 기타 대형 플랫폼은 행동 분석을 사용합니다 — 그들은 IP뿐만 아니라 User-Agent, 쿠키, TLS 핑거프린트 및 특정 주소와의 요청 속도 변화를 모니터링합니다.

AI 에이전트는 이 문제를 근본적으로 다르게 해결합니다. 그는:

응답 코드(403, 429, CAPTCHA 리디렉션)를 통해 현재 IP가 "소진"되었음을 감지하고, 해당 도메인에 대해 새로운 IP를 요청할 수 있습니다;
다단계 시나리오를 위해 하나의 IP에서 "끈적한" 세션(sticky session)을 유지할 수 있습니다 — 예를 들어, 인증 + 개인 대시보드 스크래핑;
사이트의 반응에 따라 요청 빈도를 조절할 수 있으며, 고정된 타이머에 따라 작동하지 않습니다;
IP 변경과 헤더 변경 및 브라우저 에뮬레이션을 결합할 수 있습니다. 예를 들어, 파싱이 헤드리스 브라우저를 통해 이루어질 경우, Dolphin Anty 또는 AdsPower와 같은 안티탐지 도구를 사용할 수 있습니다.

이러한 이유로 "에이전트 + MCP 서버 + API 프록시" 조합은 정적인 회전 방식에 비해 차단 비율을 현저히 낮춥니다: IP 변경 결정은 차단 사실에 따라 이루어지며, 일정에 따라 이루어지지 않습니다.

연결 아키텍처: 에이전트 → MCP → API 프록시 → 파서

작업 흐름은 네 개의 계층으로 구성되어 있으며, 각 계층의 책임 영역을 이해하는 것이 중요합니다:

AI 에이전트 (tool-calling을 지원하는 LLM) — 어떤 페이지를 다음에 스크래핑할지, IP를 변경해야 할지, 속도를 늦춰야 할지를 결정합니다;
MCP 서버 — 에이전트에게 도구 세트를 제공합니다: get_page, rotate_ip, check_proxy_status;
API 프록시 제공업체 — 요청 시 새로운 IP를 제공하고, 지리적 위치 및 연결 유형(주거용, 모바일, 데이터 센터)을 표시합니다;
파서/HTTP 클라이언트 — 받은 프록시 매개변수로 목표 사이트에 실제 요청을 실행합니다.

중요한 점: MCP 서버는 사이트를 스크래핑하지 않습니다 — 그는 단지 에이전트에게 기능을 제공합니다. "403 응답 시 어떻게 할 것인가"라는 논리는 모델에 남아 있으며, MCP 서버는 명령을 실행하고 결과를 반환합니다. 이러한 분리는 프록시 제공업체나 파서를 변경할 수 있게 해주며, 에이전트의 논리를 다시 작성할 필요 없이 MCP 서버에서 도구 구현만 업데이트하면 됩니다.

실용적인 조언

에이전트에게 "원시" API 프록시 제공업체에 대한 직접 접근을 허용하지 마십시오 — 제한된 매개변수 세트(국가, IP 유형, session_id)로 별도의 MCP 도구로 감싸십시오. 이는 모델이 잘못된 요청을 생성하여 "소진"되는 위험을 줄입니다.

에이전트 스크래핑을 위한 프록시 유형 선택

프록시 유형은 에이전트가 rotate_ip를 호출해야 하는 빈도와 차단 없이 통과하는 요청 수에 직접적인 영향을 미칩니다. 아래는 에이전트 스크래핑에 적합한 작업에 대한 비교입니다.

프록시 유형	에이전트가 사용할 때	장점	단점
주거용 프록시	마켓플레이스, 안티봇 보호가 있는 사이트 스크래핑 (Wildberries, Ozon)	실제 사용자 IP, 낮은 차단 비율	데이터 센터보다 비쌈, 속도는 노드에 따라 다름
모바일 프록시	소셜 미디어 및 광고 대시보드와의 작업	사이트에서 최대한의 신뢰, 통신사와 같은 IP	비용이 더 높고, 회전 속도가 제한적임
데이터 센터 프록시	강력한 안티봇 보호가 없는 사이트에서 대량 데이터 수집	높은 속도, 낮은 IP 비용	쉽게 감지됨, 에이전트를 통해 회전이 더 자주 필요함

실제로 에이전트는 유형을 조합할 수 있습니다: 주거용 프록시를 통해 세션을 시작한 후, 기술적인 우회를 위해 데이터 센터 프록시로 전환할 수 있습니다 — MCP 도구가 요청 매개변수로 IP 유형을 지정할 수 있도록 허용하는 경우에 한합니다.

프록시 변경이 포함된 MCP 서버의 단계별 설정

Python에서 최소한의 작업 흐름을 살펴보겠습니다. MCP 서버는 페이지를 가져오고 API 프록시 제공업체를 통해 IP를 변경하는 두 가지 도구를 설명합니다.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("proxy-parser-agent")

# 현재 프록시 세션 저장소
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """프록시 제공업체의 API를 통해 새로운 IP를 요청합니다."""
    response = httpx.get(
        "https://api.proxycove.com/v1/get-endpoint",
        params={"country": country, "type": "residential"},
        headers={"Authorization": "Bearer YOUR_API_KEY"},
    )
    data = response.json()
    return f"http://{data['username']}:{data['password']}@{data['host']}:{data['port']}"

@mcp.tool()
def rotate_ip(country: str = "ru") -> str:
    """에이전트를 위한 도구: 지정된 국가에서 새로운 IP 주소로 변경합니다."""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP가 업데이트되었습니다, 지역: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """에이전트를 위한 도구: 현재 프록시를 통해 페이지를 가져옵니다."""
    if not current_session["proxy_url"]:
        current_session["proxy_url"] = get_new_proxy(current_session["country"])

    proxies = {"http://": current_session["proxy_url"], "https://": current_session["proxy_url"]}
    try:
        r = httpx.get(url, proxies=proxies, timeout=15)
        return {"status_code": r.status_code, "content": r.text[:3000]}
    except httpx.RequestError as e:
        return {"status_code": 0, "error": str(e)}

if __name__ == "__main__":
    mcp.run()

논리는 간단합니다: 에이전트가 fetch_page를 호출하고, status_code: 403 응답을 확인한 후, 스스로 rotate_ip를 호출하기로 결정합니다. "10번 요청 후 IP 변경"과 같은 하드코딩된 규칙은 없습니다 — 모델은 서버의 실제 응답에 따라 조정됩니다.

프로덕션 환경에서는 이 코드에 다음을 추가하는 것이 좋습니다: 타임스탬프가 있는 각 회전의 로깅, 분당 회전 수 제한(모델이 IP 변경에만 집중하지 않도록), 그리고 "끈적한" IP가 필요한 시간보다 더 오래 유지되지 않도록 세션 수준에서 타임아웃을 설정합니다.

Claude, LangChain 및 AutoGPT와의 통합

MCP는 원래 Claude Desktop 및 Claude API를 위한 프로토콜로 홍보되지만, 개방형 사양 덕분에 타사 프레임워크에서도 지원됩니다. LangChain에서 에이전트를 구축하는 경우, MCP 서버는 langchain-mcp-adapters를 통해 연결되며, 이는 MCP 도구를 일반 LangChain 도구로 변환합니다 — 에이전트는 이를 다른 함수와 동일하게 인식합니다.

MCP에 대한 기본 지원이 없는 AutoGPT 유사 에이전트의 경우, 로컬 HTTP 브릿지를 설정할 수 있습니다: MCP 서버는 일반 REST 서비스처럼 작동하며, 에이전트는 자신의 표준 함수 호출 메커니즘을 통해 엔드포인트를 호출합니다. 이는 다소 우아하지 않지만, 특정 스택에 이미 연결된 팀을 위한 작업 가능한 옵션입니다.

안티탐지 브라우저와의 연결에 대해서도 언급할 필요가 있습니다. 스크래핑이 직접 HTTP 요청을 통해 이루어지지 않고, 헤드리스 Chrome/Playwright를 통해 이루어지는 경우(무거운 JS 보호가 있는 사이트에 필요), MCP 서버는 프록시뿐만 아니라 브라우저 프로필도 관리할 수 있습니다 — 에이전트에게 Dolphin Anty 또는 Octo Browser에서 이미 연결된 프록시 엔드포인트로 프로필을 실행할 수 있는 도구를 전달합니다. 이 경우 에이전트는 어떤 프로필과 어떤 국가를 사용할지 지정하기만 하면 되며, 모든 기술적인 부분은 MCP 도구 뒤에 숨겨져 있습니다.

실제 사례: Wildberries, Ozon, SMM 분석

Wildberries에서 가격 모니터링. 에이전트는 2000개의 SKU 목록을 받고, 상품 카드들을 순회하며 CAPTCHA나 빈 응답을 받을 경우 스스로 주거용 프록시를 통해 IP를 변경하고 지연을 두고 요청을 반복합니다. 고정된 회전을 가진 정적 스크립트와는 달리, 이러한 조합은 플랫폼 측의 보호가 강화되더라도 안정적인 수집 속도를 유지합니다 — 에이전트는 단순히 차단 패턴에 "느리게" 반응하여 요청 빈도를 줄입니다.

Ozon Seller API 및 웹 인터페이스에서 데이터 수집. 여기서 에이전트는 두 가지 모드를 조합합니다: 인증된 요청은 "끈적한" IP를 통해 하루 종일 진행되며(재인증을 유발하지 않기 위해), 공개 상품 카드 스크래핑은 각 요청마다 회전을 통해 이루어집니다.

Instagram 및 TikTok의 경쟁자에 대한 SMM 분석. 에이전트는 경쟁자 계정 목록에 대한 공개 통계(좋아요, 댓글, 도달)를 수집하며, 요청을 모바일 프록시를 통해 분산시켜 애플리케이션 사용자 트래픽을 모방합니다. 데이터 센터 IP를 사용하는 봇이 아닙니다.

세 가지 경우 모두 팀의 시간 절약은 스크래핑 자체에서 오는 것이 아니라, 복잡한 수동 재시도, 백오프 및 회전 규칙을 작성하고 유지할 필요가 없기 때문입니다. 에이전트는 코드 수정 없이 스스로 사이트 보호 변경에 적응합니다.

AI 에이전트와 프록시 연결 시 자주 발생하는 오류

너무 잦은 회전. 에이전트에게 매번 IP를 변경할 수 있도록 허용하면, 사이트는 비정상적인 주소 변경 속도로 인해 서브넷 범위를 차단할 수 있습니다.
IP에 대한 쿠키 연결 부족. 에이전트가 IP를 변경하지만 이전 세션의 쿠키를 계속 사용하면, 안티봇 시스템은 즉시 지리적 위치와 세션 불일치를 감지합니다.
회전 수에 대한 제한 없음. 제한이 없으면 모델이 오류 루프에 빠져 시스템 문제(예: 사이트가 전체적으로 다운됨)로 인해 쓸모없는 시도로 모든 트래픽 한도를 소진할 수 있습니다.
TLS 핑거프린트 무시. HTTP 클라이언트를 변경하지 않고 IP를 변경하는 것은 사이트가 TLS 핸드셰이크 서명을 통해 봇을 식별하는 경우 도움이 되지 않습니다 — 이 경우 헤드리스 브라우저와의 연결이 필요합니다.
에이전트의 "원시" 프록시 자격 증명에 대한 직접 접근. 모델에게 API 프록시의 로그인/비밀번호에 대한 직접 접근을 허용하면 대화 로그에서 유출될 위험이 있습니다 — MCP 도구를 중개로 사용하십시오.

결론

AI 에이전트와 MCP 서버 및 API 프록시의 조합은 스크래핑의 논리를 변화시킵니다: 타이머에 따른 엄격한 회전 규칙 대신, 에이전트는 차단 사실에 따라 IP 변경 결정을 내리고, "끈적한" 세션과 일회성 세션을 조합하며, 코드 수정 없이 특정 사이트에 적응합니다. 이는 특히 안티봇 보호가 활발한 플랫폼(마켓플레이스, 소셜 미디어, 광고 플랫폼)에서 두드러집니다.

마켓플레이스 및 강력한 보호가 있는 사이트를 스크래핑하기 위해서는 주거용 프록시를 아키텍처에 포함시키는 것이 좋습니다 — 이는 에이전트에게 IP 소진 없이 더 많은 "공간"을 제공합니다. 소셜 미디어 및 모바일 애플리케이션과 관련된 작업의 경우, 모바일 프록시에 주목하십시오 — 이는 안티봇 시스템에서 의심을 덜 받습니다. 그리고 덜 보호된 출처에서 대량의 기술적 데이터 수집을 위해서는 빠르고 저렴한 데이터 센터 프록시가 적합하며, 에이전트는 예산 최적화를 위해 주거용 IP와 조합하여 사용할 수 있습니다.