레지덴셜 프록시가 2012년경 상업용 제품으로 처음 등장했을 때, 지배적인 가격 책정 모델은 “포트” 또는 “채널”이었다. 예를 들어 100개의 포트를 제공하는 플랜을 구매하는 식이었다. 각 포트는 하나의 동시 연결이었다. 더 많은 동시성이 필요하면 더 큰 플랜을 구매했다.
이 모델은 한동안 시장에 맞았다. 당시 고객들이 규모를 생각하는 방식과 맞아떨어졌다. 청구서를 예측 가능하게 만들었다. 업계 대부분이 2010년대 중반까지 이 모델을 유지할 만큼 충분히 잘 작동했다.
그러나 이 모델은 점진적으로, 그러다가 갑자기 더 이상 의미가 없어졌다.
처음에 포트가 합리적이었던 이유
레지덴셜 프록시의 초기 사용 사례는 좁았다. 스니커 봇, 티켓팅 봇, 틈새 스크레이퍼. 알려진 수의 병렬 세션을 실행하고 각 세션이 서로 다르게 보여야 하는 워크로드였다. 포트 기반 플랜은 그 사고방식에 직접적으로 대응했다. 하나의 포트, 하나의 세션, 예측 가능한 동작.
프록시 네트워크 자체도 작았다. 수십만 개 규모의 IP 풀이 소수의 국가에 집중되어 있었다. 운영자들은 현실적으로 무제한 동시성을 지원할 수 없었으므로, 동시성을 과금 가능한 축으로 노출했다.
그리고 포트는 경제적으로도 방어 가능했다. 100개의 포트를 가진 고객은 10개를 가진 고객과 의미 있게 다른 규모였다. 가격은 고객의 겉으로 드러난 규모를 따라갔다.
포트 모델이 무너진 이유
거의 동시에 세 가지 일이 일어나면서 포트 기반 플랜은 잘못된 기본 단위가 되었다.
풀이 자릿수 단위로 커졌다. 레지덴셜 프록시 시장은 통합되고 확장되었다. 선두 제공업체들은 수십만 개의 IP에서 1억 개 이상으로 이동했다. 동시성은 네트워크 수준에서 더 이상 의미 있는 제약이 아니게 되었다. 1,000개의 동시 연결을 요청하는 고객은 네트워크가 쉽게 제공할 수 없는 것을 요청하는 게 아니었다.
워크로드가 포트 사고방식에서 벗어났다. 현대의 데이터 수집은 한 달 내내 꾸준히 실행되는 100개의 병렬 스크레이퍼가 아니다. 그것은 급증하는 팬아웃이다. 월요일 오전 9시에 가격 갱신을 위해 천 건의 요청이 몰리고, 다음 월요일까지는 거의 트래픽이 없다. 또는 이벤트 트리거 스크레이핑이다. 웹훅이 발동되면 90초 동안 50개의 동시 요청이 필요하고, 그 후 다시 제로로 돌아간다. 고정된 포트 할당은 두 형태 모두에 잘 맞지 않았다. 과잉 프로비저닝(유휴 용량에 대해 비용 지불)을 하거나 스로틀링을 당했다.
고객들은 더 이상 그것을 생각하고 싶어하지 않게 되었다. 구매자가 실제로 관심 있는 질문은 “이걸 통해 얼마나 많은 데이터를 옮길 수 있는가”이다. 대역폭이 자연스러운 단위이다. 워크로드에 맞춰 확장된다. AWS처럼 보이는 청구서, 즉 예측 가능한 단위당 비용, 실제 사용량에 의해 결정되는 총 비용에 대응한다.
전환
대역폭 가격 책정으로의 전환은 레지덴셜 프록시 시장 대부분에서 약 5년(2019~2024년)이 걸렸다. 누군가 그것을 숨겨서가 아니었다. 순전히 관성 때문이었다. 대형 고객들은 포트 플랜으로 다년 계약을 맺고 있었고, 마이그레이션 계획을 작성하기가 어려웠으며, 대부분의 제공업체들은 기존 구매자들에게 출구를 제공할 만큼 두 모델을 충분히 오래 유지하고 싶어했다.
2024년까지, 업계의 모든 진지한 레지덴셜 네트워크는 대역폭 기반 가격 책정을 기본값으로 제공했다. Shifter도 포함된다. 우리는 자사 스택을 그것에 맞춰 구축한 고객들을 위해 기존 포트 플랜을 계속 제공했으며, 그 기존 약속은 여전히 유효하다. 하지만 새로운 것은 모두 대역폭 기준으로 가격이 책정되었다.
대역폭 가격 책정이 실제로 바꾸는 것
몇 가지는 더 쉬워지고 한 가지는 더 어려워진다.
더 쉬워짐, 구매. “월 약 200 GB의 페이지를 스크레이핑해야 한다”는 고객이 아무것도 구축하기 전에 쓸 수 있는 문장이다. “80개의 포트가 필요하다”는 그것을 알아내려면 워크로드를 먼저 실행해야 하는 문장이다.
더 쉬워짐, 예측. 대역폭은 옮기는 데이터에 비례해서 선형적으로 확장된다. 스크레이핑 빈도를 두 배로 늘리면 대역폭도 두 배가 된다. 세 배로 늘리면 세 배가 된다. 임계값 절벽도 없고, 피크 시 동시성 병목도 없다.
더 쉬워짐, 청구. 청구서에 숫자 하나. “동시성의 110%를 사용했지만 트래픽은 40%만 사용했으니 이렇게 계산합니다” 같은 것이 없다. 고객은 자신이 무엇에 대해 비용을 지불하는지 안다.
더 어려워짐, 규율. 대역폭은 열린 수도꼭지다. HTML 본문만 필요한데 전체 페이지 자산을 다운로드하도록 잘못 구성된 스크레이퍼는 추가로 유용한 데이터를 전혀 생성하지 않으면서 대역폭을 네 배로 늘릴 수 있다. 포트 방식에서는 그 스크레이퍼가 동시성 벽에 부딪혔을 것이고 운영자가 알아챘을 것이다. 대역폭 방식에서는 누군가 아웃바운드 트래픽을 감사할 때까지 그냥 청구서를 늘려간다.
이를 완화하는 방법은 요청 형태에 신중해지는 것이다. 제품 데이터만 원할 때 이미지를 가져오지 마라. Accept-Encoding: gzip을 사용하라(대부분의 클라이언트가 기본적으로 이렇게 하지만 확인할 가치가 있다). 자산 번들을 트리거하는 쿼리 매개변수를 제거하라. 응답 코드만 필요하다면 GET 전에 HEAD를 가져와라.
업계가 여기서 어디로 향하는가
대역폭 가격 책정은 레지덴셜 시장에서 승리했다. 다음 차별화의 축은 더 이상 가격 모델이 아니다. 무엇이 번들로 제공되는지, 어떤 기능이 무료로 제공되는지, 무엇이 대역폭 미터에 반영되는지이다.
2026년 제공업체들이 차별화하고 있는 몇 가지 예시:
스티키 세션 가격 책정. 일부 제공업체는 스티키 세션 대역폭에 프리미엄을 부과한다. 우리는 그렇지 않다. 스티키 세션은 요청당 로테이션과 동일한 요율로 청구된다.
기능으로서의 지오 타겟팅. 일부 제공업체는 도시 수준 또는 ASN 수준 타겟팅을 업그레이드로 가격을 책정한다. 우리는 그렇지 않다. 모든 지오 정밀도는 모든 플랜에 포함되어 있다.
동시성 상한. 일부 제공업체는 여전히 대역폭 할당량 위에 동시성 제한을 부과한다. 우리는 그렇지 않다. 모든 플랜에서 무제한 동시 연결이 가능하다.
API와 대시보드. 이제 대역폭이 미터가 되었으니, 고객들은 가시성을 원한다. 엔드포인트별, 지오별, 세션별로 시간 단위로 얼마나 많은 GB가 사용되는지. 이것은 이제 프리미엄 기능이 아니라 기본 요건이다.
구매자에게 주는 교훈은 다른 어떤 인프라 카테고리에서든 동일했다. 무엇이 청구되고 무엇이 번들되는지 세부 조항을 읽어라. GB당 표면적인 요율은 실제로 사용할 기능의 절반이 추가 요금을 유발한다면 의미가 없다.
앞으로의 전망
대역폭 가격 책정이 최종 형태는 아니다. 워크로드가 계속해서 수백만 건의 저가치 요청으로 팬아웃하는 스크레이퍼보다는 소수의 고가치 요청을 하는 AI 에이전트 쪽으로 이동함에 따라, 요청 단위 또는 성공률 단위 가격 모델이 특정 버티컬에서 다시 등장할 가능성이 있다.
하지만 지금으로서는, 대역폭이 올바른 단위로 자리잡았다. 포트 시대는 그 목적을 다했고, 이제 끝났다.