TLS Handshake는 Bot 탐지의 기본선입니다
98.6%.
이는 CatBoost 모델이 JA4 기능만을 사용하여 달성한 분류 정확도입니다. header도 없었습니다. IP도 없었습니다. 행동 분석도 없었습니다. 오직 TLS handshake의 형태만 분석했습니다. arXiv 논문이 2026년 2월에 발표되었으며, 이 결과는 이례적인 것이 아닙니다. Cloudflare, AWS, VirusTotal, Akamai는 모두 프로덕션 환경에서 JA4(또는 이전 버전인 JA3)를 실행하고 있습니다. 2026년에 일반 HTTP 클라이언트로 scraping을 하고 있다면, request가 애플리케이션 레이어에 도달하기도 전에 이미 판정이 내려진 것입니다.
이것은 봇 탐지 튜토리얼들이 생략하는 부분입니다. 안티 봇 우회에 관한 대부분의 글은 여전히 User-Agent 로테이션, cookie, CAPTCHA에만 집중하고 있습니다. 이들은 쉬운 레이어에 속합니다. 하지만 TLS 레이어는 header만으로는 속일 수 없는 영역입니다.
JA4가 실제로 보는 것
JA4는 TLS ClientHello의 fingerprint입니다. 프로토콜(TCP 또는 QUIC), TLS 버전, SNI 존재 여부, 정렬된 암호화 스위트(cipher suites), 확장(extensions), 서명 알고리즘(signature algorithms), ALPN을 인코딩합니다. 출력 결과는 t13d1516h2_8daaf6152771_e5627906d626과 같은 간결한 문자열입니다. 동일한 브라우저라고 주장하는 두 클라이언트는 동일한 JA4 해시를 생성합니다. Chrome이라고 주장하는 Python requests 스크립트는 전 세계에서 스크레이퍼 외에는 그 어디에도 존재하지 않는 JA4를 생성합니다.
JA4 제품군(JA3를 만든 FoxIO 그룹이 개발)은 Chromium이 단순한 fingerprinting을 무력화하기 위해 2023년에 도입한 확장 순열(extension permutation)이라는 JA3의 가장 큰 약점을 해결했습니다. JA4는 확장을 정렬하고 개수를 세기 때문에 무작위화(randomization)는 도움이 되지 않습니다. 쉬운 탈출구는 없습니다.
Akamai는 크로스 레이어(cross-layer) 분석을 통해 92%에서 98%의 봇 분류 정확도를 달성했다고 밝혔습니다. 여기서 크로스 레이어 분석이 핵심입니다. TLS 자체만으로도 강력한 신호가 되지만, 이를 HTTP/2 프레임 순서, header 순서, request 타이밍과 결합하면 오탐률(false-positive rate)이 대부분의 스크레이퍼가 감당할 수 없을 정도로 낮아집니다.
포스트 퀀텀의 반전
이것은 아무도 예상하지 못한 부분이었습니다. 2026년 1월 31일, Akamai는 모든 연결에 포스트 퀀텀 키 교환을 기본값으로 설정했습니다. 2026년 초까지 실제 브라우저가 시작한 연결의 57.4%에 X25519MLKEM768 키 공유가 포함되어 있습니다. Chrome의 PQ 지원 비율은 약 93%에 달합니다. Firefox 132는 85%입니다. Safari는 순차적으로 적용 중입니다.
PQ 키 공유는 크기가 큽니다. 기존 X25519의 36바이트에 비해 1,124바이트에 달합니다. ClientHello 크기는 300~500바이트에서 1,400바이트 이상으로 늘어났습니다. 이러한 크기 증가는 JA4, 패킷 캡처, WAF의 수동적 관찰(passive observation)에서 그대로 드러납니다.
만약 여러분의 스크래핑 클라이언트에 PQ 키 공유가 포함되어 있지 않다면, 현재의 Chrome이나 Firefox라면 하지 않을 주장을 하고 있는 셈입니다. 2026년 1분기에 발표된 두 개의 CVE가 바로 이 불일치를 지적합니다. CVE-2026-26995(패딩 확장)는 request당 25~50%의 탐지 확률을 보이며, CVE-2026-27017(ECH 및 GREASE 불일치)은 약 50%에 달합니다. 세션 전체로 합산하면 노출 확률은 거의 확실한 수준으로 치솟습니다.
이는 12개월짜리 문제가 3개월짜리 문제로 단축되고 있음을 의미합니다. 대부분의 오픈소스 스크래핑 스택은 아직 PQ 호환 TLS를 지원하지 않습니다. 지원하는 스택조차 실제 Chromium보다 몇 주 뒤처져 있습니다.
proxy가 이를 해결하지 못하는 이유
더 큰 proxy 풀을 사용하면 현대적인 봇 탐지를 해결할 수 있다는 위안이 되는 이야기가 돌고 있습니다. 하지만 그렇지 않습니다. Security Boulevard가 보도한 2026년 1월의 암표 거래(scalping) 사건에서는 390만 개의 고유 IP를 통해 1,600만 개의 request가 사용되었습니다. IP별 차단은 무용지물이었습니다. 효과가 있었던 방어 수단은 대부분 TLS 및 행동 fingerprinting이었습니다.
주거용(residential) proxy의 경제성 또한 이번 분기에 무너졌습니다. Help Net Security는 2026년 4월에 지난 1월 IPIDEA 네트워크의 중단으로 인해 업계의 주거용 대역폭 용량이 하룻밤 사이에 약 40% 감소했다고 보도했습니다. Bright Data와 Oxylabs의 특허 분쟁(대법원은 2026년 2월 23일에 Bright Data의 청구를 기각했으며, 재판은 5월 18일로 예정됨)은 이러한 용량 타격에 비하면 지엽적인 사건에 불과합니다. fingerprinting에 대한 방어책으로 주거용 IP를 쫓는 구매자들은 WAF가 신경 쓰지도 않는 해결책에 더 많은 비용을 지불하고 있는 셈입니다.
proxy는 여전히 중요하지만, 대부분의 사람들이 생각하는 이유 때문은 아닙니다. 지리적 분포와 ISP 유형은 라우팅 결정과 rate limit 프로필을 결정합니다. 하지만 handshake 단계에서 살아남는 데는 도움이 되지 않습니다.
데이터 팀에 이것이 의미하는 바
2026년에 스크래핑 인프라를 구축하거나 구매할 때 세 가지 변화가 생깁니다.
첫째, 이제 TLS 스택은 필수 요구사항입니다. 실제 브라우저의 TLS handshake(PQ 키 공유, 확장 순서, ALPN, 서명 알고리즘)를 모방하지 않는 클라이언트는 높은 확률로 봇으로 분류되는 fingerprint를 생성합니다. Python requests를 더 나은 header로 감싸는 것은 아무것도 해결하지 못합니다. 전송(transport) 계층이 바로 단서가 되기 때문입니다.
둘째, headless 브라우저 탐지는 개선되기는커녕 더 까다로워졌습니다. Browserless의 'State of Web Scraping 2026' 보고서에 따르면 headless Chromium과 일반(headed) Chromium 간의 격차가 벌어지고 있습니다. 안티 봇 벤더들은 fingerprint 차이점을 카탈로그화했으며 고객 사이트 전반에 걸쳐 위협 인텔리전스를 거의 실시간으로 공유합니다. 12월에 작동했던 headless 인스턴스가 5월에는 봇으로 분류될 수 있습니다. 행동 신호는 TLS 위에 쌓이며, 이 두 가지 모두 계속해서 변화하는 대상입니다.
셋째, 자체 구축과 외부 구매 간의 득실 계산이 달라졌습니다. 지속적으로 변화하는 대상(몇 주마다 PQ 업데이트를 배포하는 Chromium, 마이너 버전 간에 변경되는 확장 순서, 암호화 스위트 선호도 변화)에 맞춰 TLS fingerprint를 유지하는 것은 이제 전담 업무가 되었습니다. 2024년에 엔지니어 리소스의 20%를 스크레이퍼 유지 관리에 사용했던 팀들은 2026년에 0.5인분 이상의 인력을 투입하고 있습니다. 저희는 이전에 웹 스크레이퍼가 계속 고장 나는 이유에 대해 글을 쓴 적이 있습니다. 2026년에는 그 원인이 "DOM"보다는 "TLS"인 경우가 더 많습니다.
가장 비용 효율적인 스크레이퍼는 분류되지 않는 스크레이퍼입니다
흥미로운 예측은 안티 봇 벤더들이 계속해서 기준을 높일 것인가의 여부가 아닙니다. 그들은 그렇게 할 것입니다. 진짜 흥미로운 예측은 98%의 정확도가 기본 탐지 기준선이 된 시장에서 어떤 스크래핑 도구가 살아남을 것인가입니다.
대부분은 살아남지 못할 것입니다. 하지만 살아남는 도구들은 TLS handshake를 단순한 전송 세부 사항이 아닌 request의 일부로 취급할 것입니다. 그리고 구매자들은 12개월 전만 해도 평가 체크리스트에 없었던 질문을 벤더들에게 던지기 시작할 것입니다. "어떤 TLS fingerprint를 제공하며, 얼마나 빠르게 업데이트하나요?"
request가 자신의 정당성을 입증할 기회를 얻기도 전에, handshake 단계에서 이미 모든 것이 결정됩니다.