Playwright를 사용하여 웹 스크래핑을 하는 개발자들은 전체 Chromium 인스턴스를 실행하고, 실제 User-Agent를 설정하며, 사람과 유사한 지연 시간을 삽입했음에도 불구하고 첫 번째 요청이 거부되는 현상을 겪고 있습니다. 서버는 TLS 핸드셰이크 단계에서 요청을 차단하는데, 이를 TLS 핑거프린팅(TLS fingerprinting)이라고 합니다.

TLS 핑거프린팅 설명

브라우저가 HTTPS 연결을 열 때 ClientHello 메시지를 보냅니다. 이 패킷에는 TLS 버전, 지원되는 암호화 스위트(cipher suites), 일련의 확장 기능(타원 곡선, 서명 알고리즘) 및 기타 몇 가지 필드가 나열됩니다. 이 정확한 조합이 네트워킹 스택을 고유하게 식별합니다.

연구자들은 이러한 원시 필드들을 JA3(또는 그 최신 버전인 JA4)라고 불리는 압축된 식별자로 해싱합니다. 실제 Chrome 브라우저는 하나의 해시를 생성하지만, Python HTTP 라이브러리는 다른 해시를 생성합니다. 서버의 해시가 주장된 User-Agent와 일치하지 않으면, 해당 요청을 스크립트에 의한 것으로 간주합니다.

왜 순정 Playwright 브라우저도 차단될 수 있는가

Playwright의 기본 Chromium 빌드는 보통 올바른 Chrome 핑거프린트를 생성하지만, 많은 스크래퍼가 일관성을 깨뜨리는 단계를 추가합니다:

  1. 혼합된 요청 전략 – 개발자들은 종종 Playwright가 무거운 페이지를 렌더링하게 두는 동시에, 가벼운 HTTP 클라이언트를 사용하여 보조 리소스(JSON, 이미지 등)를 가져오게 합니다. 이러한 빠른 호출은 Chrome이 아닌 라이브러리의 핑거프린트를 전달하며, 서버는 이 불일치를 즉시 감지합니다.
  2. TLS 종료 프록시(TLS-terminating proxies) – 일부 프록시 서비스는 TLS 스트림을 복호화하여 트래픽을 검사하거나 수정하고, 다시 암호화합니다. 서버는 최종적으로 프록시의 핑거프린트를 보게 되며, 이를 브라우저가 아닌 클라이언트로 판단하여 차단할 수 있습니다.
  3. 기타 프로토콜 계층 – 안티 스크래핑 시스템은 HTTP/2 설정, 헤더 순서 및 IP 평판도 비교합니다. 어떤 계층에서든 불일치가 발생하면 차단이 트리거될 수 있습니다.

JA3에서 JA4로: 군비 경쟁

JA3는 널리 채택된 최초의 TLS 핑거프린트였습니다. 현재 Chrome은 실행할 때마다 확장 기능의 순서를 무작위로 변경하므로, 실제 브라우저에 대한 JA3 해시가 불안정해졌습니다. JA4는 해싱하기 전에 확장 기능 목록을 정렬함으로써 이 문제를 해결하며, Chrome이 순서를 섞더라도 안정적인 식별자를 생성합니다. JA4를 채택한 탐지 도구는 실제 Chrome 인스턴스와 정적인 JA3 해시를 단순히 복사한 스크립트 클라이언트를 확실하게 구분할 수 있습니다.

개발자가 오늘 할 수 있는 일

서버를 영원히 속일 수 있는 "마법의 문자열"은 없습니다. 신뢰할 수 있는 접근 방식은 요청의 모든 계층이 동일한 정보를 전달하도록 만드는 것입니다:

  • User-Agent, TLS 핸드셰이크, HTTP/2 설정 및 헤더 순서를 동일한 브라우저 버전 및 OS와 일치시키십시오.
  • 전체 브라우저 자동화 도구와 별도의 HTTP 클라이언트를 혼용하지 마십시오. 속도가 중요하다면 사소한 호출을 포함하여 모든 네트워크 호출을 Playwright가 처리하도록 하십시오.
  • 연결을 종료하지 않고 TLS를 그대로 통과시키는(pass TLS through) 프록시를 선택하거나, 원래의 TLS 핸드셰이크를 변경 없이 전달하도록 구성하십시오.
  • IP 평판 서비스를 모니터링하십시오. 깨끗한 IP 풀을 사용하면 과거의 남용 기록에 기반한 차단 가능성을 줄일 수 있습니다.

핑거프린트 일관성을 무시할 때 발생하는 비용

스크래퍼가 핸드셰이크 단계에서 차단되면 페이지 로직에 도달하지 못하므로 데이터를 수집할 수 없고 JavaScript를 실행하는 데 시간을 소비하지도 않습니다. 대규모 데이터 수집에 의존하는 기업은 재시도 루프가 돌아감에 따라 클라우드 컴퓨팅 비용이 상승하는 것을 경험하게 됩니다. 반복적인 차단은 동일한 네트워크에서 발생하는 다른 합법적인 트래픽에도 영향을 미치는 IP 차단으로 이어질 수 있습니다.

반론: 사이트들이 TLS 핑거프린팅을 사용하는 이유

사이트 소유자는 TLS 핑거프린팅을 정당한 방어 수단으로 간주합니다. 자동화된 스크래핑은 서버에 과부하를 주거나, 유료 결제 벽(paywalls)을 우회하거나, 개인 데이터를 대규모로 수집할 수 있습니다. TLS 핑거프린트가 주장된 브라우저와 일치하는지 확인함으로써, 사이트는 실제 사용자에게 피해를 주지 않으면서도 대량의 저효율 봇을 걸러낼 수 있습니다. 이 기술은 CAPTCHA보다 덜 침해적이어서 사용자 경험을 보존합니다.

향후 주목해야 할 사항

  • JA4 채택 – 향후 몇 달 내에 더 많은 보안 벤더와 CDN 제공업체가 JA4 기반 탐지를 도입할 것으로 예상됩니다.
  • 브라우저 수준의 무작위화 – Chrome 및 기타 브라우저는 TLS 파라미터를 계속 변경할 수 있으며, 이로 인해 핑거프린팅 도구는 트래픽 타이밍이나 JavaScript 실행 패턴과 같은 더 복잡한 신호로 이동하게 될 것입니다.
  • 프록시 시장의 대응 – 스크래핑 커뮤니티의 '변경되지 않은 핸드셰이크' 요구를 충족하기 위해 "TLS 투명(TLS-transparent)" 라우팅을 약속하는 서비스들이 등장할 가능성이 높습니다.

시사점

페이지가 로드되기도 전에 Playwright 스크레이퍼가 거부된다면, 그 원인은 거의 확실히 TLS 핑거프린트의 불일치에 있습니다. 이는 간단한 패치로 해결될 문제가 아니며, 선언된 브라우저 프로필에 맞춰 모든 프로토콜 계층을 엄격하게 일치시켜야 합니다. User-Agent, TLS 핸드셰이크, HTTP/2 설정, 헤더 순서 및 프록시 동작 전반에 걸쳐 일관성을 유지하는 것만이 현대적인 안티 스크레이핑 방어 체계의 탐지를 피할 수 있는 유일하고 확실한 방법입니다.