← 블로그로 돌아가기
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

2026년 AI 에이전트를 위한 프록시: Playwright MCP 설정, 브라우저 사용 및 클라우드 브라우저

AI 에이전트는 20단계에서 CAPTCHA에 부딪히고, Chromium의 로그인과 비밀번호가 있는 프록시는 단순히 무시합니다. Playwright MCP, browser-use 및 클라우드 브라우저를 위한 작업 구성 파일을 분석합니다: 비밀번호 대신 IP로 인증, --proxy-server 및 --proxy-bypass 플래그, 회전과 고정 세션 간의 선택, 다섯 가지 전형적인 함정.

📅2026년 8월 4일
2026년 AI 에이전트를 위한 프록시: Playwright MCP 설정, 브라우저 사용 및 클라우드 브라우저
```html

AI-에이전트가 웹사이트를 스스로 탐색하는 Claude는 Playwright MCP, browser-use, 클라우드 Browserbase와 함께 일반 파서가 직면하는 동일한 문제에 부딪힙니다: 한 주소에서 수십 개의 요청을 보내면 페이지 대신 Cloudflare의 챌린지가 나타납니다. 차이점은 에이전트가 감정을 느끼지 못하고 단순히 루프에 빠져 "없는 버튼을 누르려는" 시도로 토큰을 소모한다는 것입니다.

이 문제는 프록시로 해결할 수 있습니다. 하지만 에이전트에 프록시를 연결하는 것은 생각보다 명확하지 않습니다: 인터넷의 절반은 Chromium이 무시하는 구문을 제안합니다. 아래는 2026년 가장 일반적인 스택을 위한 작동하는 구성과 모두가 걸려 넘어지는 함정에 대한 설명입니다.

누가 필요로 하는가

에이전트를 이미 실행하고 다음과 같은 증상 중 하나를 경험한 사람들을 위한 가이드입니다:

  • 에이전트가 10-20단계를 수행한 후, 다음 단계마다 CAPTCHA 또는 "당신이 인간인지 확인하십시오" 페이지가 반환됩니다;
  • 에이전트가 당신이 보는 것과 다른 콘텐츠를 봅니다: 가격, 검색 결과 및 재고는 서버 IP에 따라 표시되며, 필요한 국가가 아닙니다;
  • 에이전트가 클라우드(VPS, GitHub Actions, 컨테이너)에서 실행되고 있으며, 호스팅 제공자의 데이터 센터 주소가 이미 봇으로 표시되었습니다;
  • 로그인과 비밀번호가 포함된 프록시를 설정했지만 브라우저가 마치 프록시가 없는 것처럼 시작됩니다.

아직 "왜 에이전트가 차단되는가" 단계에 있다면, 먼저 안티봇 시스템이 에이전트 브라우저와 인간을 어떻게 구별하는지에 대한 분석를 읽어보십시오: 거기에는 감지 신호에 대한 내용이 있고, 여기에는 연결의 실제적인 방법이 있습니다.

함정 №1: Chromium은 프록시 문자열에서 로그인과 비밀번호를 수용하지 않습니다

가장 흔한 실수이며, 이는 사람들에게 몇 시간의 디버깅을 요구합니다. 공급자의 전형적인 문자열 형식은 user:pass@host:port입니다. 이를 브라우저 실행 플래그에 넣습니다:

--proxy-server="http://user:[email protected]:8080"

그리고 아무것도 작동하지 않습니다. Chromium은 --proxy-server 플래그 내에서 자격 증명의 전달을 지원하지 않습니다: 콘솔에 지원되지 않는 프록시 오류가 나타나고 트래픽은 우회합니다. 자격 증명을 제거하고 host:port만 남기면, 브라우저는 일반 모드에서 로그인과 비밀번호를 요청하는 시스템 창을 표시하지만, 이는 headless 모드에서는 창이 없기 때문에 아무도 클릭할 수 없습니다.

여기서 세 가지 작동하는 경로가 나오며, 선택은 신중하게 해야 합니다:

  1. IP를 통한 인증(화이트리스트). 에이전트가 실행되는 머신의 주소를 공급자의 대시보드에 화이트리스트에 추가하여, 로그인과 비밀번호 없이 host:port로 연결합니다. --proxy-server 플래그는 의도한 대로 작동하기 시작하며, headless 모드는 더 이상 아무것도 묻지 않습니다. ProxyCove는 두 가지 방법을 모두 지원합니다 — 로그인:비밀번호와 IP 화이트리스트를 동시에 사용할 수 있어, 에이전트에는 화이트리스트를 설정하고 수동 작업에는 비밀번호를 남길 수 있습니다.
  2. API 레벨에서 자격 증명을 전달합니다. Playwright, Puppeteer 및 browser-use는 username 및 password를 개별 필드로 수용할 수 있습니다 — 이는 명령줄 플래그와는 다른 메커니즘이며 작동합니다. 에이전트 코드를 직접 작성할 때 적합합니다.
  3. 로컬 릴레이. 비밀번호 없이 프록시를 설정하여 요청을 비밀번호가 있는 업스트림으로 포워딩하고, 에이전트에 로컬 주소를 지정합니다. 화이트리스트가 접근할 수 없는 경우에 적합한 옵션입니다: 예를 들어, 머신의 IP가 변동하는 경우입니다.

Playwright MCP: 실제로 작동하는 구성

Microsoft의 Playwright MCP는 진짜 브라우저가 필요한 에이전트의 사실상 표준입니다. 프록시는 MCP 클라이언트 구성에서 서버 인수로 설정됩니다:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

여기서 중요한 사항은 다음과 같습니다:

  • --proxy-server는 HTTP 및 SOCKS5 주소를 socks5://host:port 형식으로 수용합니다. 자격 증명 없이 — 위의 함수를 참조하십시오.
  • --proxy-bypass는 프록시를 우회하는 도메인의 목록입니다. 장식적인 옵션이 아닙니다: 에이전트에 내부 서비스나 로컬 API가 있는 경우, 이를 레지던트 채널을 통해 전송하는 것은 기가바이트당 비용이 추가되는 불필요한 트래픽입니다.
  • --isolated는 메모리 내에서 프로필을 유지하며 디스크에 기록하지 않습니다. 각 작업이 깨끗한 상태에서 시작해야 할 때 유용합니다. 단점은 쿠키가 재시작을 견디지 못하고, 각 세션이 사이트에 대해 새로운 방문자로 보인다는 것입니다.
  • --user-data-dir는 반대로 영구적인 프로필입니다. 인증이 필요한 시나리오에서는 이를 사용하고 격리를 피하며, 반드시 IP를 고정해야 합니다(아래의 sticky 섹션을 참조하십시오).
  • --storage-state는 저장된 쿠키와 localStorage를 격리된 세션에 삽입할 수 있게 해줍니다 — 두 가지 이전 옵션 간의 절충안입니다.
  • --allowed-origins 및 --blocked-origins는 에이전트가 접근할 수 있는 곳을 제한합니다. 과소평가된 절약: 분석 및 광고 도메인에 빠진 에이전트는 트래픽 소비를 쉽게 세 배로 늘릴 수 있습니다.
  • --device (예: "iPhone 15") 및 --user-agent는 에이전트가 어떤 브라우저로 나타나는지를 변경합니다. 프록시 유형과 일관되게 설정하십시오: 모바일 User-Agent가 데이터 센터 IP 위에 있는 것은 모순이며, 안티봇 시스템은 이를 즉시 감지합니다.

--cdp-endpoint에 대해 별도로 설명하자면, 이는 MCP를 이미 실행 중인 브라우저에 연결합니다. 이 경우 프록시는 MCP 플래그가 아니라 해당 브라우저 시작 시 설정됩니다 — "프록시가 설정되었지만 IP가 동일하다"는 전형적인 이유입니다.

browser-use: ProxySettings를 통한 프록시

에이전트가 browser-use로 구성된 경우, 구성은 설정 객체로 전송되며, 여기서 로그인과 비밀번호를 API를 통해 전달할 수 있습니다:

from browser_use import Browser, ProxySettings
proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1')
browser = Browser(proxy=proxy)

server 필드는 필수이며, 나머지는 선택적입니다. 동일한 원칙이 순수 Playwright에서도 적용됩니다: 프록시는 브라우저 시작 시 전역적으로 설정되거나 browser.newContext({ proxy: { server: ... } })를 통해 각 컨텍스트에 대해 개별적으로 설정됩니다. 후자는 병렬 에이전트의 열쇠입니다: 각 컨텍스트는 고유한 출력 주소를 가지며, 열 개의 작업이 하나의 IP를 공유하지 않습니다.

클라우드 브라우저: 세션 수준의 프록시

Browserbase 및 유사 서비스에서는 브라우저가 다른 클라우드에서 실행되므로 시작 플래그를 사용할 수 없습니다 — 프록시는 일반적으로 http://로그인:비밀번호@게이트:포트 형식의 세션 매개변수에 설정됩니다. Chromium의 제한은 여기서 문제가 되지 않습니다: 클라우드 제공자가 문자열을 해석하고 내부에서 브라우저를 설정합니다.

실용적인 세부 사항: 클라우드 브라우저는 자체 프록시 풀을 가지고 있으며, 모든 고객이 공유합니다. 주소의 평판에 민감한 작업(예: 계정 로그인, 이미 익숙한 플랫폼에서 작업 등)을 수행할 경우, 자신의 채널이 일반적인 것보다 예측 가능성이 높습니다.

회전 또는 고정: 작업 유형에 따라 선택하십시오

초보자의 실수는 각 요청마다 회전을 활성화하고 에이전트가 로그아웃되는 이유에 놀라는 것입니다. 에이전트 시나리오는 두 가지 모드가 있으며, 서로 대체할 수 없습니다:

  • 각 요청마다 회전 (ProxyCove에서는 포트 824) — 탐색을 위해: 100개의 상품 카드를 우회하고, 검색 결과를 수집하고, 다양한 지역의 가격을 확인합니다. 각 요청은 새로운 주소에서 전송되며, 이들을 서로 연결하기 어렵습니다.
  • 고정 세션 (포트 10000+, 변경 간격 1~120분) — 단계로 구성된 모든 작업에 적합합니다: 로그인, 장바구니, 다단계 양식, 긴 인터페이스 대화. IP가 체인 중간에 변경되면, 사이트는 최선의 경우 재인증을 요청하고, 최악의 경우 세션을 의심스러운 것으로 표시합니다.

에이전트는 거의 항상 두 번째 모드에서 작동합니다: 정의상으로 단계 순서를 수행하며, 단일 요청이 아닙니다. 간격 선택에 대한 세부 사항과 일반적인 실수는 sticky 세션이 필요한 시기와 설정 방법에 대한 가이드에서 설명되어 있습니다.

다섯 가지 잠재적 문제

  1. Chromium에서의 인증이 있는 SOCKS5. Playwright에서 socks5:// 구문이 있지만, "SOCKS5와 로그인 및 비밀번호" 조합은 Chromium 기반 브라우저에서 역사적으로 문제가 있습니다 — 해당 요청은 2021년 11월부터 Playwright 트래커에 열려 있습니다. 선택할 수 있다면, 에이전트에는 HTTP(S) 채널을 사용하는 것이 더 예측 가능합니다.
  2. DNS 및 WebRTC 유출. 트래픽은 프록시를 통해 흐르지만, 이름은 직접 해석되거나 WebRTC가 실제 주소를 반환하여 모든 마스킹이 의미를 잃습니다. 이를 에이전트를 실행하기 전에 확인해야 합니다: 프록시를 통해 작업할 때 WebRTC를 숨기는 방법.
  3. 지리적 및 로케일 비동기화. 독일의 IP, 모스크바의 시간대, 영어 인터페이스 언어 — 자동화처럼 보이는 조합입니다. Playwright에서 로케일과 시간대는 컨텍스트 매개변수로 설정되며, 이를 프록시 국가와 일치시켜야 합니다.
  4. 원하지 않는 트래픽. 에이전트는 페이지를 전체적으로 열며, 이미지, 글꼴 및 광고 스크립트도 포함됩니다. 레지던트 채널에서 기가바이트당 비용이 발생하는 경우, 이는 상당한 비용이 됩니다 — 불필요한 도메인을 차단하고 가능한 경우 미디어 로드를 비활성화하십시오.
  5. 프록시가 브라우저가 시작되는 곳에 설정되지 않았습니다. --cdp-endpoint, 도커 래퍼 또는 클라우드 서비스를 통해 작업할 때, MCP 플래그는 실제 연결에 영향을 미치지 않습니다. 설정 후 가장 먼저 해야 할 일은 에이전트가 IP 확인 서비스를 열도록 하여 주소와 국가가 올바른지 확인하는 것입니다.

에이전트에 적합한 프록시 유형

규칙은 간단합니다: 작업이 실제 사용자와 가까울수록, 주소는 "더 인간적"이어야 합니다.

  • 레지던트 프록시 — 에이전트의 기본입니다. 이는 가정용 공급자의 주소이며, 사이트에서 에이전트는 일반 방문자로 보입니다. Cloudflare, 지역 가격 및 안티봇의 모든 힌트가 있는 곳에서 필요합니다.
  • 모바일 프록시 — 소셜 미디어 및 계정에 특히 민감한 플랫폼을 위한 강력한 무기입니다. 하나의 모바일 주소 뒤에는 수천 명의 실제 가입자가 있기 때문에, 이를 전체적으로 차단하는 것은 플랫폼에 비용이 많이 듭니다.
  • 데이터 센터 프록시 — 내부 API, 테스트 스탠드 및 보호가 없는 공개 소스를 위한 것입니다. 빠르고 저렴하지만, 보호된 사이트에서는 에이전트가 거의 즉시 챌린지에 부딪힙니다.

에이전트 시나리오에 유용한 세부 사항: ProxyCove에서 프로토콜 변경은 연결 문자열의 접두사를 변경하여 수행됩니다 — HTTP, HTTPS 및 SOCKS5는 동일한 프록시에서 사용할 수 있으며, 프록시를 재구성할 필요가 없습니다. 풀에는 195개 이상의 국가가 있으므로 "에이전트에게 로컬 검색 결과를 보여주기"는 구매 시 국가 선택으로 해결됩니다.

결론

AI 에이전트에 프록시를 연결하는 것은 한 줄이 아니라 세 가지 연속적인 해결책입니다: 어떻게 인증할 것인가(헤드리스 에이전트의 경우 거의 항상 IP 화이트리스트, 비밀번호가 아님), 프록시를 어디에 설정할 것인가(MCP 플래그, 설정 객체 또는 클라우드 세션 매개변수 — 하지만 실제로 브라우저가 시작되는 곳에서 설정해야 함) 및 어떤 모드로 작업할 것인가(다단계 시나리오의 경우 — 고정 주소, 각 요청마다 회전하지 않음). 또한 전투 시작 전에 DNS 및 WebRTC 유출을 반드시 확인해야 합니다.

이 작업을 한 번 신중하게 수행하면, 에이전트는 CAPTCHA와의 대화에 토큰을 낭비하지 않게 됩니다. ProxyCove의 레지던트 프록시는 Playwright MCP 및 browser-use에 몇 분 안에 연결되며, 트래픽에 따라 요금이 부과되고, 헤드리스 모드에 대한 IP 화이트리스트가 대시보드에서 활성화됩니다.

```