Highlights
이전에는 조직(Organization)이 한 사람만 담을 수 있는 단일 행에 불과했습니다. 이제는 직접 관리할 수 있는 페이지로 개편되었습니다. 동료를 초대하고, 역할을 부여하며, 회사가 비용을 부담하는 키를 직접 생성하도록 지원할 수 있습니다. Proxy Finder 또한 "시도 횟수 초과(out of tries)"라는 모호한 응답 대신 직면한 차단 요인을 명시하기 시작했으며, Browser는 한 주 동안 동일한 페이지에 일관된 정보를 전달하도록 개선 작업을 진행했습니다.
What's New
직접 관리 가능한 조직 기능
이전에는 동료를 추가하려면 당사에 이메일을 보내야 했기에, 팀 단위에서는 별도의 구독을 두 개씩 구매하곤 했습니다.
이제 Dashboard에 조직 전용 페이지가 제공되며, 3단계 역할 체계가 적용됩니다. 소유자(Owner)는 키 사용량이 청구되는 구독을 보유하므로 정확히 한 명만 존재하며, 소유권 이전을 통해 변경할 수 있습니다. 관리자(Admin)는 사용량, 결제 및 멤버를 관리합니다. 멤버(Member)는 서비스를 이용합니다. 초대는 이메일 주소로 발송되며, 아직 가입하지 않은 사용자에게도 유효합니다.
조직에 속한 누구나 조직 소유의 키를 생성하거나 개인 키를 조직으로 이전할 수 있으므로, 개발자가 회사 업무로 인해 개인 비용이 청구되는 키를 사용할 필요가 없습니다. 조직 키의 사용량은 소유자의 플랜으로 청구되며, 모든 확인 안내에 어느 플랜에서 결제되는지 명시됩니다. 모든 멤버는 키 이름을 변경할 수 있습니다. 키 재생성, 비활성화 및 삭제 권한은 소유자와 관리자에게만 유지되는데, 이는 실행 즉시 해당 키를 사용하는 모든 동료의 작업이 중단되기 때문입니다.
단일 소유자 필터가 개요(Overview), 세부 지표(Detailed Metrics), 최근 활동(Recent Activity) 및 키 목록 전체에 적용됩니다. 사용량 및 한도(Usage & Limits)와 결제(Billing)는 개인 영역으로 유지되며, 멤버가 소유자의 쿼터를 조회할 수는 없습니다.
추측을 멈춘 Proxy Finder
"Download maxTry limit reached"라는 메시지는 모든 출구(exit)가 차단되었든, 모든 출구의 연결이 끊어졌든, 혹은 실제 페이지를 정상 수신했으나 사용자가 설정한 규칙에 의해 폐기되었든 동일하게 표시되었습니다. 이 세 가지 경우는 각각 정반대의 해결책이 필요합니다.
이제 실패한 작업에는 attemptReport 정보가 포함됩니다. 응답하지 않은 출구 수, 식별된 방어 시스템에 의해 거부된 횟수 및 해당 공급업체, 사용자의 validate.status에 의해 거부된 횟수, 그리고 방어 시스템 없이 HTTP 200을 반환했으나 사용자의 validate.data만 통과하지 못한 횟수가 표시됩니다. 명확한 요약 문장도 함께 제공됩니다.
특히 마지막 수치가 핵심입니다. 일치하지 않는 콘텐츠 규칙은 기존의 모든 측정 기준에서 차단된 것과 동일하게 보이며, 이는 재시도로는 절대 해결되지 않습니다. (validate 규칙이 성공을 결정하는 방식에 대한 추가 정보 참조.)
따라서 나머지 절반은 프로필에 달려 있습니다. Proxy Finder는 출구만 순환하고 클라이언트 서명은 순환하지 않았기 때문에, 특정 브라우저 프로필을 거부하는 사이트는 풀 내의 모든 출구에서 해당 요청을 거부했습니다. 이제 거부가 발생하면 기존 재시도 주기 내에서 프로필을 함께 전환하므로 작업당 요청 수와 크레딧 소모량은 변하지 않습니다. profile 설정을 직접 고정(Pin)한 경우에는 아무것도 변경되지 않습니다. 난이도가 가장 높은 대상의 경우, 전송하는 프로필보다 도달하는 출구 IP가 여전히 더 중요합니다.
일관성을 확보한 Browser
Browser에 User-Agent를 요청하는 것은 차라리 요청하지 않는 것보다 못했습니다. 세 개의 레이어가 각자 요청의 주체를 다르게 인식하여, 단일 요청이 Windows와 Mac, 그리고 플릿에서 실행되지도 않는 버전을 동시에 가리키는 일이 발생하기도 했습니다. 이제는 하나의 값이 한 번 결정되어 실행, 페이지, 페이지가 시작하는 worker 전체에 일관되게 전달됩니다.
Client hints는 이 문자열에서 파생되므로 sec-ch-ua, 플랫폼, navigator.platform이 모두 일치합니다. 응답에는 실제 전송된 문자열이 기록되어 반환되며, clearance cookie는 exit과 User-Agent 모두에 바인딩되므로 이는 매우 중요합니다. renderer 관련 질의 역시 document와 worker에서 동일하게 응답하며, 이는 누적되는 미세 신호 중 하나를 해결합니다.
여기에 세 가지 개선 사항이 추가되었습니다.
- 시계가 exit을 따릅니다. Browser는 exit이 위치한 국가의 표준시로 실행되므로, 현지 시간을 렌더링하는 페이지는 해당 지역 방문자가 보는 화면을 그대로 표시합니다. 국가를 알 수 없는 경우 시계는 변경되지 않습니다.
- WebRTC가 다른 트래픽과 동일한 경로를 유지합니다. proxy 설정은 브라우저가 TCP를 통해 전송하는 트래픽만 처리합니다. WebRTC는 이 경로에 있지 않으므로, 페이지가 ICE candidate를 요청하면 다른 응답을 받게 됩니다. Browser는 요청에 exit이 포함될 때마다 이를 비활성화합니다.
- 앵커 URL이 정상적으로 처리됩니다.
#reviews로 끝나는 URL은 매번 타임아웃을 유발했습니다. 이제 정상 속도로 복구되었습니다.
더 저렴해진 라우팅 및 정확해진 Dashboard 집계
Imperva는 차단 페이지뿐만 아니라 정상 페이지에도 스크립트를 삽입합니다. Auto는 둘을 구분하지 못해 정상 페이지가 불필요하게 브라우저로 에스컬레이션되었습니다. 한 렌터카 사이트의 경우 6회 시도 동안 75 크레딧과 27.5초가 소요되었으나, 이제는 단 1회 시도로 10 크레딧, 약 6.5초 만에 완료됩니다. 일부 사이트는 세션 없는 요청에 대한 거부 응답 내에 세션을 전달하는데, 이제 4개 엔진 모두가 에스컬레이션하기 전에 이를 즉시 다시 전송합니다.
Overview의 크레딧 카드에는 소비된 모든 항목이 표시되고 billed로 라벨링되어 있었습니다. 성공 건당 과금 방식에서는 이 둘이 다르며 그 차이는 실제 비용으로 이어집니다. 따라서 카드에는 두 항목이 모두 표시됩니다. billed가 메인 숫자로 표시되고, 제품별 및 총합 spent가 그 아래에 표시됩니다. Requests 카드도 동일하게 분리됩니다. 기간 및 세부 설정 컨트롤도 분리되어 30분부터 1년까지, 그리고 커스텀 범위까지 지원하며, "1D"로 표시되어 30일을 열던 기존 필터는 제거되었습니다.
Playground의 carry 버튼은 이제 마지막 응답의 프로필을 제공하므로, 직접 입력하지 않은 프로필로 전송된 요청도 정상 작동했던 버전으로 다시 실행할 수 있습니다. 모든 파라미터는 API reference에 설명되어 있습니다.
내부 구조
Proxy Finder는 호스트당 더 많은 히스토리를 유지합니다. 기존 12개 내외에서 32개 exit으로 늘렸습니다. 라이브 A/B 테스트 결과, 쉬운 타깃에서는 성능이 동일했고 까다로운 타깃에서는 더 나은 결과를 보였습니다. 전체 플릿 레이턴시의 변동 없이 페이지 도달 시간 중앙값이 5.5초에서 3.8초로 단축되었습니다. 한 타깃은 반대 결과를 보였는데 아직 원인을 파악하지 못해 별도 측정을 진행하고 있습니다.
실패할 작업은 어떤 방식으로든 실패합니다. 차이는 티켓을 1분 만에 닫느냐, 아니면 엉뚱한 대상을 측정하느라 오후를 통째로 날리느냐에 있습니다.