2026년 10월 13일, 웹 데이터 수집 세계의 다섯 개 회사가 이제 Source라는 공통의 이름 아래에서 운영된다고 발표했습니다. 이 그룹에는 Oxylabs, Decodo(구 Smartproxy), Webshare, ScrapingBee 및 Honeygain이 포함됩니다. 많은 고객들이 수년간 이 브랜드들 중에서 '주 공급자'와 '예비 공급자'를 선택하며 경쟁자로 간주해왔습니다. 이제 공식적으로: 이들은 하나의 그룹입니다. 무엇이 통합되었는지, 왜 이것이 예비 프록시 풀을 보유한 모든 사람과 관련이 있는지, 그리고 한 시간 안에 귀하의 예비 공급자가 실제로 주 공급자와 독립적인지 확인하는 방법을 알아보겠습니다.
무슨 일이 일어났는가: 다섯 개 브랜드, 하나의 소유자
Proxyway에 따르면, Source는 자신을 '데이터 생태계'라고 설명합니다. 본사는 빌니우스에 위치하며, Proxyway는 이 회사가 더 넓은 Tesonet 생태계에 속한다고 언급합니다. 그룹이 스스로에 대해 제공하는 숫자는 다음과 같습니다:
- 800명 이상의 직원, 그 중 350명 이상의 개발자 및 엔지니어;
- 180개 이상의 특허 및 215개 상표;
- 분산 시스템에서 초당 150만 건의 요청;
- AI 에이전트 및 AI 제품에 대한 수요가 1년 만에 약 4배 증가했습니다.
이 그룹은 Oxylabs에서 성장했습니다. 2026년 7월, Oxylabs는 Warburg Pincus로부터 1억 3천만 달러를 유치하며 36억 달러의 가치를 평가받았으며, 이는 첫 외부 라운드였습니다. 브랜드 간의 관계는 수년간 형성되었습니다: Webshare는 2022년에 Oxylabs에 인수되었고, ScrapingBee는 2025년에 인수되었으며, Honeygain은 2021년부터 Oxylabs의 주요 파트너로서 주거 IP를 수집하는 역할을 하고 있습니다. Decodo와 Oxylabs 간의 관계는 Source가 출범하기 전까지는 공개적으로 그렇게 명확하지 않았습니다. 주목할 만한 점은 Source의 CEO인 비타우타스 사비츠카스가 2026년 3월까지 Decodo를 이끌었다는 것입니다.
브랜드가 시장을 어떻게 나누는가
- Oxylabs — 대규모 비즈니스 및 AI 연구소;
- Decodo — 중간 시장;
- ScrapingBee — 개발자를 위한 API;
- Webshare — 고급 개인 및 소규모 팀;
- Honeygain — 일반 사용자에게 '여분'의 트래픽에 대해 보상하는 애플리케이션.
형식적으로 브랜드는 여전히 독립적입니다: 각자의 팀, 가격, 제품 및 고객이 있습니다. Source는 스스로 아무것도 판매하지 않으며, 특허, 구매, 채용 및 컴플라이언스를 중앙 집중화한다고 주장합니다. 브랜드 간에 IP 풀이나 인프라가 공유되는지는 Source나 관련 매체에서 언급하지 않습니다. 그러나 구매자에게는 이것이 가장 중요한 질문입니다.
왜 이것이 귀하의 예비 풀에 영향을 미치는가
예비 프록시 풀은 주 공급자가 작동을 멈출 경우 필요합니다: 목표 사이트가 공급자의 서브넷을 차단했거나, 공급자에 사고가 발생했거나, 조건이나 가격이 변경되었을 때입니다. 우리는 예비 프록시 풀이 실제로 계정을 구하는 방법에 대한 분석에서 시나리오와 아키텍처에 대해 자세히 설명했습니다. 그곳의 주요 규칙은 간단합니다: 예비 공급자는 다른 공급자여야 하며, 이상적으로는 다른 IP 출처에서 제공되어야 합니다.
하나의 소유자 아래 통합되면 이 규칙이 보이는 것보다 복잡해집니다. 세 가지 수준의 의존성이 있으며, 웹사이트의 브랜드는 첫 번째 수준만 반영합니다:
- 법적. 회사의 소유자는 누구이며, 누가 가격, 규칙 및 서비스의 운명을 결정하는가.
- IP 출처. 주거 주소는 어디서 오는가: 자체 애플리케이션 또는 SDK, Honeygain과 같은 파트너 프로그램, 다른 공급자로부터의 도매 구매.
- 인프라. 트래픽이 흐르는 게이트웨이, 그들의 호스팅 및 네트워크.
두 개의 '다른' 공급자가 어떤 수준에서 일치할 수 있습니다. IP 출처가 일치하면, 목표 사이트의 안티봇이 이러한 주소를 인식하게 되어 두 개의 풀을 동시에 차단하게 되고, 예비 풀은 구매한 목적에 맞지 않게 됩니다.
공유된 풀은 공통 소유자 없이도 발생할 수 있다
이 뉴스를 음모론으로 변질시키지 않는 것이 중요합니다. IP의 교차는 아무런 관련이 없는 회사에서도 발생합니다: 주거 프록시 시장은 다단계로 구성되어 있으며, 많은 브랜드가 대규모 도매 네트워크의 주소를 재판매하며, 이러한 네트워크는 동일한 애플리케이션 및 SDK를 통해 트래픽을 구매합니다. 따라서 '소유자는 누구인가'뿐만 아니라 '주소는 어디서 오는가'와 '실제로 교차하는가'를 확인해야 합니다.
예비 공급자가 독립적인지 확인하는 방법: 5단계
확인하는 데 약 한 시간이 걸리며, 몇 백 메가바이트의 트래픽이 소모됩니다. 예비가 필요하기 전에 수행하십시오.
단계 1. 법인 및 소유자
두 공급자의 이용 약관 및 개인정보 보호정책을 열어보십시오: 그곳에 법인, 등록 국가 및 주소가 명시되어 있습니다. 그 다음에는 해당 국가의 기업 등록부와 '회사 소개' 또는 보도 자료 섹션을 확인하십시오. 일치하는 주소, 동일한 이사 또는 공통 그룹에 대한 언급은 공급자를 동일한 공급자로 간주할 이유가 됩니다. 결제 설명서도 확인하는 것이 유용합니다: 종종 실제 법인 이름을 나타내며, 브랜드가 아닐 수 있습니다.
단계 2. 주거 IP 출처
지원팀에 직접 물어보십시오: "주거 IP를 어떻게 얻습니까? 자체 애플리케이션, 다른 애플리케이션의 SDK, 파트너 또는 도매 구매?" 정상적인 공급자는 적어도 일반적인 개요를 제공할 것입니다. 두 공급자가 동일한 트래픽 수익화 프로그램을 언급하거나 답변을 회피하는 경우, 출처는 공통으로 간주하십시오. 이 질문은 보안 측면에서도 중요합니다: 10월 16일, GBHackers는 GreyNoise를 인용하여 D-Link NAS, 비디오 레코더 및 SAP NetWeaver의 취약점을 통해 공격자가 타인의 장치에 합법적인 애플리케이션인 Pawns.app을 몰래 설치하고 상업적인 주거 노드로 전환한 캠페인에 대해 설명했습니다. 최소 34개국에서 143대 이상의 장치가 영향을 받았습니다. IPRoyal은 Pawns.app을 주거 IP 수집의 직접적인 파트너로 언급하고 있으며, 이 캠페인이 공급자 중 누구에 의해 지시되었다는 데이터는 없습니다. 구매자에게의 결론: IP의 출처에 대한 투명성은 귀하가 받는 주소의 청결성에 대한 문제이기도 합니다.
단계 3. 출구 IP의 교차
이것은 주요 기술 테스트입니다. 두 공급자로부터 동일한 국가에서 로테이션을 가져와서 500~1000개의 요청을 서비스에 보내 귀하의 IP를 반환받습니다. 목록을 저장하고 비교하십시오:
- 정확한 IP의 일치 — 공통 풀의 직접적인 징후;
- /24 서브넷의 일치 — 공통 출처 또는 공통 운영자의 징후;
- ASN의 분포 — 두 목록에서 동일한 운영자 네트워크가 유사한 비율로 지배하는 경우, 출처가 가까울 가능성이 높습니다.
Python의 최소 스크립트:
import requests
def collect(proxy_url, n=500):
ips = set()
for _ in range(n):
try:
r = requests.get("https://api.ipify.org",
proxies={"http": proxy_url, "https": proxy_url},
timeout=15)
ips.add(r.text.strip())
except requests.RequestException:
pass
return ips
a = collect("http://login:[email protected]:port")
b = collect("http://login:[email protected]:port")
net24 = lambda s: {".".join(ip.split(".")[:3]) for ip in s}
print("고유한 IP 수:", len(a), len(b))
print("공통 IP 수:", len(a & b))
print("공통 /24 수:", len(net24(a) & net24(b)))받은 주소의 ASN은 어떤 IP 지리 위치 서비스나 로컬 데이터베이스를 통해 확인할 수 있습니다. 샘플에서 고유 주소 수를 올바르게 해석하는 방법에 대해서는 1000개의 요청으로 실제 프록시 풀 크기를 확인하는 방법에서 다루었습니다. 간단한 규칙: 큰 풀에서 몇 퍼센트의 공통 /24는 한 국가에서 정상적인 배경이며, 수십 퍼센트의 공통 정확한 IP는 사실상 하나의 풀입니다.
단계 4. 게이트웨이 및 인프라
두 공급자의 게이트웨이 호스트가 어디로 해석되는지(명령어 dig 또는 nslookup)와 이 주소들이 어떤 네트워크에 속하는지 확인하십시오. 동일한 호스팅은 아무것도 증명하지 않지만, 게이트웨이 주소의 공통 범위, 동일한 포트 구조 및 로그인 형식, 유사한 인증 오류 응답은 서로 다른 이름 아래 동일한 플랫폼이 있을 수 있다는 신호입니다. 이 경우 게이트웨이의 사고는 두 서비스를 동시에 중단시킬 수 있습니다.
단계 5. 공동 차단 테스트
가장 실용적인 확인 방법입니다. 주 공급자가 이미 CAPTCHA 또는 차단을 겪고 있는 목표 사이트를 선택하고, 예비를 통해 동일한 시나리오를 동일한 헤더와 동일한 브라우저 프로필로 실행하십시오. 예비가 동일한 빈도로 동일한 단계에서 차단된다면, 이 사이트에 대해서는 예비가 아니며, 소유자가 다르더라도 마찬가지입니다. 매달 테스트를 반복하십시오: 풀은 변경됩니다.
다양한 작업에 적합한 예비 선택 방법
- 데이터 수집 및 가격 모니터링. IP 출처 및 게이트웨이의 독립성이 가장 중요합니다. 합리적인 계획은 다른 유형의 예비를 사용하는 것입니다: 주 풀의 주거 프록시가 있다면, 예비는 데이터 센터 프록시로, 그 반대도 가능합니다.
- 다중 계정 및 소셜 미디어. 여기서 예비는 주 공급자와 유형이 일치해야 하며, 그렇지 않으면 플랫폼이 네트워크의 '프로필' 변경을 감지합니다. 모바일 시나리오의 경우, 주 풀에 없는 운영자의 모바일 프록시를 예비로 유지하는 것이 합리적입니다.
- SLA가 있는 중요한 작업. 서로 다른 소유자와 서로 다른 IP 출처를 가진 두 공급자를 유지하고, 최소한 분기마다 단계 3 및 5에서 교차를 확인하십시오.
통합이 변화시키는 것
통합에는 두 번째 측면도 있습니다. 그룹은 공통의 목소리가 '공공 웹 데이터에 대한 책임 있는 접근'을 보호하기 위해 필요하다고 주장하며, Wilson's Media는 Oxylabs가 2025년 10월에 Reddit에 제기된 소송의 피고로 남아 있다고 상기시킵니다. 이는 고객에게 간단한 의미를 가집니다: 한 브랜드의 법적 및 평판 위험이 이제 전체 그룹에 잠재적으로 영향을 미칩니다. 이용 규칙, 가격 및 허용된 목적에 대한 결정도 조정될 수 있습니다.
그럼에도 불구하고 브랜드는 여전히 개별 서비스로 판매되며, 이들 중 어떤 것이든 사용하는 데는 아무런 문제가 없습니다. 단 하나의 변화는: 두 개를 '주 및 예비'로 선택하는 것이 더 이상 검증 없이 이루어져서는 안 된다는 것입니다.
결론
Source의 출범은 예비 예약 계획을 재검토할 좋은 기회입니다. 브랜드 이름은 공급자의 독립성을 나타내지 않으며, 소유자, IP 출처 및 인프라가 중요합니다. 법인을 확인하고, 주소의 출처에 대해 문의하고, 출구 IP 및 서브넷을 비교하고, 공동 차단 테스트를 실행하십시오. 교차가 크다면, 두 개의 공급자가 아니라 두 개의 계정을 가진 하나의 공급자가 있는 것입니다. 이것을 지금 아는 것이 좋습니다, 주 풀의 작동이 중단되는 날보다.