2026년 9월 7일, CipherCue 연구자들은 유럽 웹에서 자동화된 방식으로 활동하는 모든 사람에게 읽어볼 가치가 있는 측정을 발표했습니다. 44,143개의 유럽 기업 중 CDN을 감지할 수 있었던 기업에서 89.6%가 Cloudflare 뒤에 있습니다. "시장 리더가 압도적으로 우세하다"는 것이 아니라 거의 전체 시장을 차지하고 있습니다. 스크래핑, 멀티 계정 및 모든 자동화에 대해 이것은 간단한 의미를 갖습니다: EU의 10개 사이트 중 9개에 접근하는 것은 동일한 알고리즘에 의해, 동일한 기준으로, 동일한 순간에 이루어집니다.
무엇을 계산했는가
표본은 독일, 영국, 네덜란드, 폴란드, 프랑스, 이탈리아, 스페인 및 아일랜드의 기업으로, 웹사이트에서 최소한 하나의 CDN 구성 요소가 감지된 기업들입니다. 감지는 HTTP 응답 및 서버 지문을 통해 이루어졌습니다: Cloudflare의 경우 cf-ray 헤더와 server: cloudflare, Fastly의 경우 캐시 마커가 있는 x-served-by, CloudFront의 경우 x-amz-cf-id입니다. 관찰 날짜는 2026년 9월 7일입니다.
공급자별 분포:
- Cloudflare — 39,547개 기업 (89.6%)
- Amazon CloudFront — 3,112
- Fastly — 1,299
- Akamai — 396
국가별로 분포가 뚜렷하지만, 어디서나 높은 수치입니다:
- 네덜란드 — 95.6% (7,587개 중 7,939개)
- 영국 — 93.2% (15,846개 중 17,007개)
- 폴란드 — 92.6% (2,682개 중 2,896개)
- 프랑스 — 86.2% (3,456개 중 4,008개)
- 이탈리아 — 85.4% (3,126개 중 3,661개)
- 독일 — 81.4% (4,650개 중 5,715개)
- 스페인과 아일랜드 — 각각 78.8%
저자들은 스스로 제한 사항을 언급하며, 이는 정직합니다: 한 기업이 여러 공급자에 동시에 포함될 수 있으며(이중 계산), 표본은 소규모 및 중소기업 쪽으로 치우쳐 있습니다. 즉, 89.6%는 감지된 CDN을 가진 기업 중에서의 비율이며, 모든 유럽 법인 중에서의 비율이 아닙니다.
독립적인 규모 확인이 있습니다: 2026년 9월 기준 W3Techs에 따르면 Cloudflare를 사용하는 사이트는 전체 알려진 리버스 프록시 사이트의 84.7%로, 이는 그들의 인덱스에 있는 모든 사이트의 25.2%입니다. 다양한 방법론, 다양한 표본이 있지만, 결론은 하나입니다: 웹의 4분의 1과 인식 가능한 CDN 설치의 압도적인 다수는 하나의 중개인 앞에 있습니다.
자동화에 있어 이것이 "단순한 시장 점유율"이 아닌 이유
필터가 많을 때, 하나의 지문에서 오류가 발생하면 하나의 사이트에 대한 접근이 차단됩니다. 필터가 사실상 하나일 때, 오류는 전체 세그먼트에 대한 접근을 차단하게 되며 — 이는 작업의 경제성을 변화시킵니다.
Cloudflare는 요청에 대해 1에서 99까지의 봇 점수를 부여합니다: 점수가 낮을수록 사이트 앞에 자동화가 있을 가능성이 높습니다. 이 점수를 계산하는 모델은 회사의 설명에 따르면 초당 4,600만 개 이상의 HTTP 요청을 처리하며, 귀하의 특정 요청뿐만 아니라 전체 네트워크의 글로벌 통계도 고려합니다: IP, ASN 및 주소 유형(데이터 센터 / 거주자 / 모바일)의 평판, 헤더의 일관성, TLS 지문, 행동적 특성. 감지는 다층적이며 — 휴리스틱과 ML이 결합되어 있으며, 기계 학습이 결정의 대부분을 차지합니다.
실질적인 결과: 귀하의 풀과 지문은 사이트가 아닌 네트워크에 의해 평가됩니다. 하나의 리소스에서 발각되면 — 평판 신호는 다음 다른 요청 시 이미 고려됩니다. 이 네트워크에 아홉 개의 유럽 사이트가 존재하는 세상에서 "다른 목표로 전환하고 기다리는 것"은 더 이상 전략이 아닙니다.
거주자 IP는 더 이상 면죄부가 아니다
오래된 논리 "거주자 주소를 사용하면 사람처럼 통과한다"는 필터 공급자가 이 기법을 오래전부터 감지하고 있다는 사실에 부딪힙니다. Cloudflare는 거주자 프록시를 통해 오는 봇에 대한 별도의 모델을 공개적으로 설명했습니다: 처음에는 네트워크 신호(여분의 홉, 지연)를 시도했지만, 위성 인터넷에서의 잘못된 경고로 인해 포기하고 행동 분석으로 전환했습니다 — IP 주소의 활동에서 나타나는 특이한 급증. 그들의 출판물에서는 그들이 목격한 현상의 규모가 제시되었습니다: 약 시간당 1,700만 개의 고유 IP가 거주자 프록시를 통해 공격에 사용되며, 45,000개의 ASN과 237개 국가 및 지역(이 숫자는 2024년 3월 기준이며, 더 최근의 데이터는 제공되지 않았습니다). 분산 공격에 대한 고객의 분류 정확도는 95%로, 클라우드 네트워크에서의 봇 탐지 증가율은 20%입니다.
중요한 세부 사항: 모델은 의도적으로 IP 차단에 기반하지 않습니다 — 동일한 네트워크의 실제 사용자를 차단하지 않기 위해서입니다. 이는 거주자 주소에서의 정직한 트래픽에 대한 좋은 소식이며, "집"이 자동으로 녹색 신호를 준다고 믿는 사람들에게는 나쁜 소식입니다. 작동하는 것은 주소 유형이 아니라 "주소 유형 + 행동 + 지문"의 조합입니다. 우리는 Cloudflare, DataDome, Akamai 및 Kasada의 안티봇 시스템 비교에서 벽 사이의 차이에 대한 자세한 분석을 했으며, 현재 유럽의 첫 번째 줄에 비례적으로 많은 무게가 실렸다는 점을 고려하여 다시 돌아가야 합니다.
역설: 하나가 떨어지면 모두가 떨어진다
모노컬처에는 차단이 아닌 접근 가능성에 대한 두 번째 측면이 있습니다. 지난 1년 반 동안 세 가지 주목할 만한 에피소드가 있었습니다:
- 2025년 11월 18일 — 전 세계적인 장애로, 추정상 약 5분의 1의 웹 페이지와 10,000개 가장 인기 있는 사이트 및 서비스의 3분의 1에 영향을 미쳤습니다. 회사의 분석에 따르면 원인은 ClickHouse 클러스터의 권한 변경으로, ML 모델이 봇 점수를 매기기 위해 사용하는 특성 파일에서 행이 중복되는 결과를 초래했습니다. 아이러니하게도: 사람이냐 아니냐를 결정하는 메커니즘이 인터넷의 상당 부분을 마비시켰습니다.
- 2025년 12월 5일 — UTC 8:47에 약 25분 동안 발생한 장애로, 네트워크를 통해 전달되는 전체 HTTP 트래픽의 약 28%를 차지하는 고객의 하위 집합에 영향을 미쳤습니다.
- 2026년 2월 20일 — UTC 17:48에 BYOIP(자체 IP 범위)를 사용하는 일부 고객의 경로가 주소 온보딩 파이프라인의 변경으로 인해 BGP를 통해 철회되었습니다.
연구 저자들의 설명은 정확합니다: 한 공급자가 시장의 대부분 앞에 서 있을 때, 그의 오류는 더 이상 그의 문제가 아니라 모두의 문제가 됩니다. 데이터 수집 파이프라인에 있어 이는 "목표 사이트가 다운되었다"와 "전체 지역이 다운되었다"의 구분이 잘 이루어지지 않게 되며 — 특정 도메인에 설정된 알림이 잘못된 정보를 제공하게 됩니다.
실제로 이 문제를 어떻게 해결할 것인가
아래는 필터의 모노컬처를 사실로 받아들일 경우 작업 프로세스에서 실제로 변화하는 것입니다.
- 하나의 사이트에서만 테스트하지 마십시오. 귀하의 지문이 세 개의 리소스를 통과하면, 아마도 동일한 필터를 세 번 확인한 것입니다. 테스트 세트에 CloudFront, Fastly, Akamai 및 CDN이 없는 리소스를 포함하세요. 그렇지 않으면 표본이 아무것도 증명하지 않습니다.
- 프로젝트별로 풀을 분리하십시오, 사이트별로는 아닙니다. 평판이 네트워크에 의해 평가되므로, "각 도메인에 대해 별도의 풀"은 아무것도 격리하지 않습니다. 격리는 프로젝트 및 프로필 수준에서 의미가 있습니다: 하나의 프로젝트는 자신의 주소 풀, 자신의 지문 세트, 자신의 속도를 가집니다.
- 주소의 유형과 출처를 살펴보십시오. ASN 및 주소 카테고리는 점수 매기기로의 직접적인 접근입니다. 민감한 목적에는 거주자 프록시와 모바일 주소가 의미가 있으며; 대량의 기술적 작업(가용성 확인, 자체 API, 강력한 안티봇이 없는 플랫폼 작업)은 데이터 센터 프록시를 사용하여 더 저렴하고 정직하게 처리할 수 있습니다.
- 서브넷을 태우지 마십시오. 행동 모델은 주소에서의 활동 급증을 감지합니다. 넓은 풀에서의 고른 속도는 좁은 풀에서의 짧고 공격적인 발사보다 점수를 더 잘 견딥니다.
- 지문을 전체적으로 정리하십시오. TLS 지문, 헤더의 순서 및 구성, HTTP 버전, JS 행동 — 함께 평가됩니다. 지문이 없는 HTTP 클라이언트의 거주자 IP는 정직한 브라우저 스택을 가진 깔끔한 데이터 센터 주소보다 더 나쁜 결과를 제공합니다.
- "우리가 차단당했다"와 "그들에게 장애가 발생했다"를 구분하십시오. 간단한 규칙: 오류가 대량으로 증가할 때, 먼저 여러 관련 없는 목표에서 모두 다운되었는지 확인하고 공급자의 상태 페이지가 무엇을 보여주는지 확인하십시오. 전 세계적인 장애가 발생하는 순간 재시도는 풀을 무의미하게 소모하는 방법입니다.
- 필터가 다운될 날을 대비한 계획 B를 마련하십시오. 대기할 수 있고 놓친 것을 보충할 수 있는 작업 대기열은 개발 비용이 더 비싸지만, 데이터 손실 없이 25분의 비가용성을 견딥니다.
결론
89.6%라는 숫자는 Cloudflare가 나쁘다는 것이 아니라 유럽 웹이 닫혔다는 것이 아닙니다. 이는 목표의 다양성이 더 이상 장애물의 다양성을 의미하지 않는다는 것을 의미합니다. 하나의 점수 매기기, 하나의 모델, 하나의 평판 데이터베이스 — 그리고 그 결과, 하나의 공통적인 실패 모드: 당신이 봇으로 인식될 때와 공급자가 경로를 스스로 떨어뜨릴 때 모두 동일합니다.
실무를 위한 결론은 지루하지만 실용적입니다: "사이트에 맞춰 우회 최적화"를 중단하고 행동을 최적화하기 시작하십시오 — 주소의 품질, 고른 속도, 일관된 지문, 장애 진단의 정직함. 이것이 89.6%의 저편과 이편 모두에서 동일하게 잘 작동하는 유일한 방법입니다.