최근까지 오픈 웹상의 트래픽은 크게 두 가지 형태였다. 사람이 브라우징하는 경우, 즉 간헐적이고 주의력에 의존하며 한 사람이 한 자리에서 읽을 수 있는 페이지 수에 의해 상한이 정해지는 형태. 그리고 프로그래밍 방식의 스크래핑, 즉 대용량이고 팬아웃 구조이며 대체로 상태를 유지하지 않고 사용자에게는 대체로 보이지 않는 형태.
세 번째 형태가 빠르게 등장하고 있다. 브라우저를 사용하는 AI 에이전트, 즉 Anthropic의 Computer Use, OpenAI의 Operator, 그리고 다양한 오픈소스 자율 에이전트들이 사용자를 대신해 실제 브라우저를 구동해 일련의 페이지를 탐색한다. 이들이 생성하는 트래픽은 앞의 두 가지 중 어느 쪽과도 닮지 않았다. 스크래핑 방어에 성공적으로 대응해온 사이트들도 이 트래픽에 어떻게 대처해야 할지 아직 확신하지 못하고 있다. 그런 에이전트들 아래에 있는 인프라 제공업체들도 여전히 적절한 기본 구성 요소를 찾아가는 중이다.
이 글은 오늘날 프로덕션 환경에서 AI 에이전트 트래픽이 실제로 어떤 모습인지, 그리고 그것이 이를 뒷받침하는 인프라 스택을 어떻게 형성해왔는지를 보여주는 스냅샷이다.
트래픽이 실제로 어떤 모습인지
오늘날의 전형적인 AI 에이전트 흐름을 살펴보자. 사용자가 에이전트에게 “8월 말 뉴욕에서 도쿄로 가는 가장 저렴한 논스톱 항공편을 찾아줘”라고 요청한다. 에이전트는 헤드리스 Chromium을 실행해 Google Flights로 이동하고, 폼을 채워 제출한 뒤 결과를 파싱하고, 가장 저렴한 항공편을 따라 항공사 사이트로 이동해 예약 페이지로 넘어가 가용성을 확인하고 답을 반환한다.
이는 3090초에 걸쳐 815건의 HTTP 요청이 발생하는 과정이며, 다음과 같은 특성을 지닌다.
버스트성. 요청이 전혀 없거나, 지속적인 시퀀스가 이어지거나 둘 중 하나이며 그 중간의 안정 상태는 없다. 에이전트는 사용자가 요청할 때까지 대기하다가, 요청이 들어오면 1분 남짓 집중적으로 작동한다.
버스트 내에서 상태 유지. 에이전트의 흐름에는 쿠키, 세션, User-Agent가 존재한다. N+1번째 요청은 대상 사이트의 관점에서 N번째 요청의 연속처럼 보여야 한다. 흐름 도중 IP가 바뀌면 세션이 끊긴다.
이질적인 엔드포인트. 각 에이전트 실행은 여러 개의 서로 다른 사이트, 검색 엔진, 항공사 1, 항공사 2, 경우에 따라 비교 애그리게이터를 방문한다. 각 사이트는 저마다의 봇 방지 태세를 갖추고 있다.
사용자 위치에 고정된 지리적 정보. 사용자는 무작위 데이터센터가 아닌 JFK에서 출발하는 항공편을 원한다. 에이전트의 트래픽은 사용자가 요청하는 위치, 혹은 최소한 예약할 때 나타내고 싶은 위치로 그럴듯하게 지오로케이션되어야 한다.
지연 시간에 민감함. 사용자는 그 자리에서 기다리고 있다. 요청당 지연 시간이 200ms 대신 800ms이면 12건의 요청에 걸쳐 누적되어, “에이전트가 30초 만에 답했다”와 “에이전트가 1.5분 만에 답했다”의 차이를 만든다.
이러한 형태는 사람의 브라우징 모델(너무 빠르고, 기계적 속도로 상태를 유지한다는 점에서 다름)이나 스크래핑 모델(세션당 요청 수가 너무 적고, 세션에 너무 종속적이며, 사용자 위치에 너무 고정되어 있다는 점에서 다름) 어느 쪽과도 맞지 않는다.
단순한 인프라가 실패하는 이유
경험 많은 데이터 팀들이 성공적으로 사용해온 몇 가지 패턴은 그대로 옮겨지지 않는다.
대규모 레지덴셜 풀의 요청 단위 로테이션. 스크래핑의 기본 패턴이다. 에이전트에는 맞지 않는데, 세션이 IP 일관성, 로그인 쿠키, 검색 상태, 핑거프린트 바인딩을 필요로 하기 때문이다. 요청 단위 로테이션은 두 번째 요청에서 이미 세션을 끊어버린다.
속도를 위한 데이터센터 프록시. 지연 시간 특성 때문에 끌리는 선택이다. 하지만 에이전트가 방문하는 업스트림 대상(Google, 항공사, 이커머스, 은행)은 데이터센터 트래픽을 적극적으로 방어한다. 이 때문에 에이전트 실행의 절반이 CAPTCHA로 실패한다.
단일 고정 레지덴셜 IP. 일관성이 있어 보여 끌리는 선택이다. 하지만 여러 에이전트에 걸쳐 IP가 빠르게 소모된다. 하나의 IP가 수천 건의 에이전트 흐름을 처리하면 100회 실행 이후부터는 스크래퍼처럼 보이게 된다.
효과가 있는 형태는 레지덴셜 상에서의 스티키 세션에 더 가깝다. 즉 에이전트 실행마다 새로운 세션을 부여하고, 사용자의 의도에 맞는 지리적 타겟팅을 적용하며, 세션은 해당 실행의 자연스러운 수명에 맞춰 제한한다.
효과가 있는 패턴
프로덕션 환경에서 대부분의 에이전트 배포가 수렴하는 아키텍처는 다음과 같다.
user_request → agent.spawn( proxy_session_id=hash(user_id, request_id), # unique per user-run pair proxy_country=user_geo_or_intent, proxy_ttl=longer_than_expected_run, # don't expire mid-flow ) → browser navigates target sites through that session → agent returns result → proxy session expires naturally프록시 추상화는 요청 단위가 아니라 실행 단위다. 한 번의 실행 안에서 에이전트는 일관된 하나의 레지덴셜 IP를 사용한다. 실행마다 모든 에이전트 흐름은 (보통) 새로운 도시의 새로운 ISP로부터 새로운 IP를 부여받는다. 풀의 다양성은 반복되는 에이전트 트래픽으로 인해 특정 IP가 소모되는 것을 막아주고, 세션 일관성은 대상 사이트가 흐름 도중 에이전트를 의심스러운 것으로 플래그하는 것을 막아준다.
이는 기능적으로 가격 비교 쇼핑 봇이 사용하는 것과 동일한 패턴이다. 세션마다 스티키 레지덴셜 세션을 사용하고, 안정적인 sid에 고객별로 귀속시킨다. AI 에이전트의 경우 차이점은 볼륨이 극적으로 높다는 점(에이전트 실행을 촉발하는 모든 사용자 쿼리가 하나의 세션이 된다)과 지속 시간이 더 짧다는 점(대부분의 에이전트 흐름은 2분 미만이다)이다.
대역폭 기반 요금제의 레지덴셜 인프라는 이 구조에 자연스럽게 들어맞는다. 에이전트 실행은 동시성 기반이 아니라 대역폭 기반의 트랜잭션이기 때문이다. 에이전트가 이동시키는 GB당 요금을 지불하면 되며, 동시성은 프록시가 아니라 에이전트 런타임의 문제다.
대상 사이트들의 대응
아직까지는 별다른 대응이 없다. 대부분의 주요 사이트는 여전히 AI 에이전트 트래픽을 스크래핑 트래픽과 동일하게 취급하며, 동일한 봇 방지 규칙과 차단 방식을 적용한다. 이는 곧 두 가지 방향으로 빠르게 변화할 것이다.
에이전트 트래픽으로 이익을 얻는 사이트는 이를 수용할 것이다. 예약 흐름, 이커머스 결제, 가격 비교 쇼핑이 그렇다. 에이전트는 자동화 계층에 의해 서비스를 받는 실제 사용자이며, 전환은 여전히 실질적이다. 영리한 사이트들은 에이전트 친화적인 엔드포인트, 즉 “이 user-agent와 이 헤더를 가진 트래픽은 사람이 매개하는 에이전트로 간주하고 차단하지 말고 속도만 제한하라”고 알리는 robots 형식의 선언을 발행하기 시작했다.
에이전트 트래픽으로 손해를 보는 사이트는 방어를 강화할 것이다. 광고로 수익을 내는 모든 것은 실질적인 문제를 안고 있다. 에이전트는 광고를 보지도, 클릭하지도, 광고주에게 전환을 일으키지도 않는다. 뉴스 사이트, 무료 콘텐츠 사이트, 노출을 통해 수익을 내는 모든 것은 에이전트 트래픽을 특정해서 탐지하고 차단할 유인을 갖는다. 이는 봇 방지 경쟁의 다음 국면이 될 것이며, 스크래핑 때보다 더 치열한 대립이 될 것이다. 에이전트 계층에는 자신들의 에이전트가 차단당하면 손해를 보는 강력한 대기업 후원자들이 있기 때문이다.
그 중간에 위치한 인프라 계층, 즉 우리와 우리와 같은 레지덴셜 프록시 네트워크들은 흥미로운 위치에 서 있다. 우리는 사이트들이 아직 반기지 않는 에이전트들을 그 사이트에 도달할 수 있게 해주는 접근 계층이다. 사이트와 에이전트 제공업체 사이의 협상(아마도 계약, 결제 관계, 개정된 robots.txt 형식의 프로토콜이 혼합된 형태로 진행될 것이다)이 전개됨에 따라, 순수 인프라 제공업체의 역할은 “허용된” 경로에서는 좁아지고 “IP 수준의 다양성이 필요한” 경로에서는 넓어질 것이다.
2026년에 주목할 점
에이전트 기반 서비스를 구축하고 있다면 지켜볼 만한 몇 가지 신호가 있다.
흐름 도중 재인증이 필요한 에이전트 실행의 비율. 오늘날 적절한 스티키 세션 하에서는 거의 0에 가깝다. 이 비율이 상승하기 시작한다면, 대상 사이트들이 에이전트 핑거프린트를 탐지하는 법을 익혀 세션 도중에 챌린지를 제기하고 있다는 뜻이다. 이를 완화하려면 에이전트 측의 더 나은 브라우저 핑거프린팅이나 다른 프록시 전략이 필요하다.
다단계 에이전트 흐름의 p99 지연 시간. 오늘날 이는 대체로 네트워크와 대상 사이트의 응답 시간에 좌우된다. 동시 에이전트 부하 아래에서 프록시 게이트웨이가 병목이 되기 시작한다면, 인프라 계층은 확장이 필요하다.
에이전트 트래픽의 지리적 분포. 오늘날 대부분의 에이전트 트래픽은 에이전트 런타임이 호스팅되는 위치(대체로 US-East)로 지오로케이션된다. 에이전트가 실제 사용자 트랜잭션(쇼핑, 예약, 뱅킹)을 매개하기 시작하면, 사이트 로직이 올바르게 작동하려면 트래픽이 사용자의 실제 위치로 지오로케이션되어야 한다. 이는 도시/ASN 단위로 정밀한 레지덴셜 인프라가 기본값이 될 것이라는 낙관적 전망의 근거다.
에이전트 친화적인 사이트 선언. agents.txt와 유사한 형태나 “이러한 제약 조건 하에 에이전트 트래픽을 환영한다”는 구조화된 선언의 등장을 지켜볼 필요가 있다. 만약 이런 것이 등장한다면 프록시 계층의 역할은 좁아질 것이고, 등장하지 않는다면 프록시 계층은 계속해서 접근을 중개하는 역할을 맡게 될 것이다.
결론
AI 에이전트는 실질적으로 새로운 형태의 트래픽이다. 이는 스크래핑도, 브라우징도, RAG 검색도 아니다. 각각과 일부 특성을 공유하지만 어느 것과도 정확히 일치하지는 않는다. 그 밑에 있는 인프라는 실행 단위의 스티키 세션을 스크래핑 수준의 동시성으로, 사용자 위치에 고정된 지리적 정보와 스크래핑이 허용하는 것의 3분의 1 수준인 지연 시간 목표에 맞춰 지원할 수 있도록 유연해져야 한다.
인프라 제공업체에게 좋은 소식은, 제대로 구축된 레지덴셜 프록시 네트워크가 이미 바로 이 형태를 지원하고 있다는 점이다. 에이전트 실행마다 스티키 세션, 세션마다 새로운 IP, 지리적 정밀성, 사용량에 따라 확장되는 대역폭 기반 요금제. 스크래퍼와 비교 봇을 서비스하며 성숙해진 기본 구성 요소들이 바로 에이전트에게 필요한 것과 동일하다.
앞으로 2년간의 제품 관련 질문은 에이전트 트래픽이 실질적인 카테고리가 될 것인가가 아니다. 이미 그렇게 되었다. 질문은 인프라 스택과 대상 사이트 생태계가 양쪽 모두 받아들일 수 있는 조건으로 얼마나 매끄럽게 수렴할 것인가이다. 내년 출시 글에서는 더 선명한 그림을 볼 수 있을 것이다.