리뷰 모니터링은 겉보기에는 리포팅 문제처럼 보이지만 실제로는 데이터 수집 문제로 동작한다. 리뷰는 공개되어 있고 페이지는 읽기 쉽지만, 첫 본격적인 수집을 시작하면 이 작업을 만만치 않게 만드는 두 가지 요소에 부딪히게 된다. 리뷰 페이지가 보여주는 내용은 요청이 어디서 오는지에 따라 달라지고, 매일 같은 페이지를 요청하는 것은 안티봇 시스템이 탐지하도록 조정된 바로 그 트래픽 패턴이다.
이 글에서는 프록시가 이 문제에 어떻게 들어맞는지, 무엇을 수집해야 하는지, 그리고 리뷰 파이프라인이 일정에 따라 돌아가기 시작한 이후에도 안정적으로 유지하는 방법을 다룬다.
프록시 없이는 실제로 무엇이 깨지는가
지역화부터 시작하자. Google 리뷰, 앱 스토어, Trustpilot의 국가별 도메인, 그리고 대형 마켓플레이스들은 모두 요청자의 지역에 따라 출력을 다르게 한다. 별점 평균이 다를 수 있고, 리뷰 세트 자체가 다르며, 번역된 버전이 어떤 지역에서는 나타나고 다른 지역에서는 나타나지 않는다. 마켓플레이스에서는 특정 국가에서 아예 해당 상품이 존재하지 않을 수도 있다. 한 사무실 IP에서 모니터링하는 팀은 글로벌한 그림을 보고 있는 것이 아니다. 한 국가의 그림을 보면서 그것을 글로벌이라고 부르고 있는 것이다.
다음은 물량이다. 수백 개의 제품이나 수백 개의 매장 위치를 추적하는 브랜드는 매일, 안정된 하나의 주소에서 수천 개의 페이지를 요청하게 된다. 이는 지문이 된다. 그 반응은 대개 처음부터 완전한 차단이 아니라 성능 저하로 나타난다. 응답 속도 저하, 인터스티셜, 잘린 리뷰 목록, 유효한 200 응답을 반환하지만 데이터가 없는 챌린지 페이지 등이다. 이를 확인하지 않는 파이프라인은 조용히 0을 기록하고, 대시보드에는 실제로는 일어나지 않은 리뷰 가뭄이 나타난다.
프록시는 이 두 가지 문제를 모두 해결한다. 지오 타겟팅은 원하는 리뷰가 있는 시장에 요청을 위치시키고, 대규모 레지덴셜 풀에 트래픽을 분산시키면 어떤 단일 주소도 사이트가 신경 쓰기 시작하는 속도보다 훨씬 낮게 유지된다.
어떤 프록시 유형이 어떤 대상에 맞는가
소비자 리뷰 표면이 가장 까다로운 경우다. Google, Trustpilot, G2, Capterra, App Store와 Play Store, Amazon과 지역 마켓플레이스는 모두 성숙한 봇 관리 체계 뒤에 있다. 이들은 레지덴셜 IP를 필요로 하는데, 이 주소들이 실제 소비자 연결에 속하며 해당 사이트가 평가하는 신뢰 프로필을 갖고 있기 때문이다. 이것이 대부분의 리뷰 프로그램의 대다수를 차지한다.
ISP 프록시는 흐름에 상태가 있는 경우 제 역할을 한다. 매장을 선택하거나, 배송 위치를 설정하거나, 소유한 판매자 계정에 로그인한 후에만 리뷰가 나타난다면, 그 단계들 전반에 걸쳐 안정된 주소가 로테이션보다 더 가치 있다. ISP 주소는 고정적이면서도 소비자 라우팅 방식이며, 이는 이런 시나리오에 필요한 조합이다.
데이터센터 프록시는 여전히 롱테일에서는 합리적이다. 틈새 산업 리뷰 사이트, 포럼, 공개 피드처럼 방어가 약한 대상들이다. 요청당 비용이 낮고 신뢰 페널티도 물지 않는다. Google 리뷰에 데이터센터 프록시를 보내는 것은 팀들이 돈을 낭비하는 지점인데, 챌린지 페이지를 반환하는 저렴한 요청은 결코 저렴하지 않기 때문이다.
성숙한 대부분의 설정은 하나의 유형을 선택하기보다 대상별로 라우팅한다. 까다로운 소비자 플랫폼은 레지덴셜로, 상태를 가진 흐름은 스티키로, 나머지 쉬운 부분은 가장 저렴한 곳으로 보낸다. 스크래핑 시 차단을 피하는 방법에 관한 글에서는 같은 문제의 요청 단위 측면을 다룬다.
로테이션, 세션, 페이싱
대부분의 리뷰 수집은 단순한 페이지 읽기다. URL을 요청하고, 리뷰를 파싱하고, 다음으로 넘어간다. 매 요청마다 로테이션하는 것이 올바른 기본값이며, 이는 로테이팅 레지덴셜 엔드포인트가 별다른 작업 없이도 해주는 일이다.
스티키 세션은 예외적인 경우에 중요하다. 리뷰 목록의 페이지네이션은 종종 사이트가 세션에 발급한 커서에 의존하며, 위치 제한이 걸린 리뷰는 그 세션에 저장된 선택값에 의존한다. 흐름 중간에 IP를 바꾸면 그 상태가 초기화되어 다시 첫 페이지를 받거나 빈 결과를 받게 된다. 세션은 그 흐름의 길이만큼만 유지한 뒤 끊어야 한다.
페이싱은 팀들이 과소투자하는 부분이다. 리뷰 수는 천천히 변한다. 기저 데이터가 주 단위로 움직이는데 매시간 제품 페이지를 두드릴 이유가 없으며, 그렇게 했을 때의 대가는 실제로 중요한 페이지에서의 차단률 상승이다. 크롤링 빈도는 해당 대상에서 리뷰가 쌓이는 속도에 맞춰야 한다. 고물량 마켓플레이스 목록과 앱 스토어는 매일, 대부분의 B2B 소프트웨어 디렉터리는 매주, 그리고 급증이 예상되는 출시와 캠페인 시점에는 이벤트 기반으로 조정한다.
무엇을 수집할지 정하기
본능적으로는 모든 것을 가져오고 싶어진다. 더 유용한 파이프라인은 의사결정을 뒷받침하는 필드만 수집하고 나머지는 버린다.
제품별, 위치별, 시장별 평점과 리뷰 수는 추세선을 알려준다. 리뷰 텍스트, 날짜, 언어는 내용을 알려주며, 언어는 불만을 읽을 수 있는 팀으로 라우팅할 수 있게 해준다. 구매 확인 플래그와 리뷰어 이력은 실제 신호와 캠페인을 구분해준다. 판매자나 리스팅 정체성은 마켓플레이스에서 중요한데, 위조업자가 판매하는 동일 제품에는 알아야 할 리뷰가 달리지만 자신의 평균에는 섞이면 안 되기 때문이다.
두 가지는 저항할 가치가 있다. 분석에 필요한 것보다 더 많은 개인 데이터를 저장하는 것은 아무 이득 없이 리뷰 파이프라인을 데이터 보호 문제로 만들며, 리뷰어 이름은 거의 그 가치를 하지 못한다. 그리고 리뷰 텍스트는 다른 사람이 쓴 것이므로, 분석을 위해 집계하는 것과 사이트 콘텐츠로 재게시하는 것은 별개의 문제다.
리뷰에 대한 관심이 분석적이라기보다 평판 관리적인 팀에게는, 브랜드 보호와 소셜 리스닝이 같은 불만이 대개 먼저 나타나는 인접 표면들을 다룬다.
파이프라인 구축하기
메커니즘은 평범하다. 스케줄러가 시장별 URL 워크리스트를 구동하고, 각 요청은 해당 행에 맞게 국가가 설정된 프록시 엔드포인트를 통해 나가며, 응답은 파서로 가고, 파싱된 리뷰는 플랫폼, 제품, 시장별로 키가 지정된 저장소에 저장되어 같은 리뷰가 두 번 집계되지 않도록 한다.
실제로 프로덕션 환경에서 살아남을지를 결정하는 부분은 덜 명확하다.
상태 코드를 신뢰하기보다는 응답을 검증해야 한다. 챌린지 페이지는 200을 반환하고 파싱하면 리뷰 0개가 나온다. 어제 400개의 리뷰가 있던 페이지에서 갑자기 리뷰가 없다고 나오는 실행은 수집 실패이지 비즈니스 이벤트가 아니며, 파이프라인은 그렇게 표시해야 한다.
저렴하게 가져와라. 리뷰 페이지에는 파싱에 아무 기여도 하지 않는 이미지, 폰트, 분석 스크립트가 붙어 있다. 이를 차단하면 대역폭이 크게 줄어들고, 대역폭 기준 요금제에서는 이것이 한 달에 몇 GB와 논쟁할 만한 청구서 사이의 차이가 된다.
필요할 때만 렌더링하라. 일부 리뷰 섹션은 서버에서 렌더링되어 있어 단순 HTTP 요청만으로 충분하다. 다른 것들은 헤드리스 브라우저가 필요한데, 이는 대역폭과 시간 모두에서 훨씬 더 큰 비용이 든다. 모든 대상을 기본적으로 브라우저로 처리하지 말고 대상별로 확인하라.
원본 응답을 짧은 기간 동안 보관하라. 플랫폼이 마크업을 변경해 파서가 깨질 때, 그리고 그런 일은 반드시 일어나는데, 어제의 HTML을 갖고 있으면 재크롤링 대신 10분 만에 수정할 수 있다.
이 모든 것을 유지 관리할 여력이 없는 팀이라면, 스크래핑 API가 구조화된 출력을 반환하고 로테이션, 렌더링, 재시도 로직을 더 높은 요청당 비용으로 대신 처리해준다. 이 트레이드오프는 돈과 엔지니어링 시간 사이의 것이며, 하루에 수천 페이지를 돌리는 리뷰 프로그램에서는 프로그램이 작을 때만 대체로 공정한 거래다.
비용은 얼마나 드는가
리뷰 모니터링은 프록시 워크로드 중 상대적으로 저렴한 편인데, 자산 다운로드를 멈추면 페이지가 작아지고 크롤링 빈도도 낮기 때문이다.
$1.00/GB부터 시작하는 레지덴셜 요금제에서, 매일 수천 개의 제품 페이지와 여러 시장을 훑는 작업은 일반적으로 월 대역폭 수치가 한 자릿수 GB 정도다. 이를 움직이는 변수는 헤드리스 브라우징, 이미지 로딩, 과도하게 빈번한 크롤링 순이다. 이 세 가지는 모두 가격 결정이 아니라 엔지니어링 결정이며, 프록시 청구서를 탓하기 전에 알아두면 유용한 사실이다.
Shifter가 여기서 맞는 이유는 평범한 것들이다. 195개 이상의 국가에 걸친 2억 500만 개 이상의 레지덴셜 IP, 도시 단위 및 ASN 타겟팅, 동일 계정에서의 로테이팅 및 스티키 세션, 그리고 마켓 스와입을 순차적이 아니라 병렬로 실행할 수 있게 해주는 무제한 동시 연결이다. 네트워크 동작에 관한 독립적인 수치는 여기서 주장하기보다 벤치마크 페이지에 있다.
인프라가 아닌 부분
수집은 쉬운 절반이다. 리뷰는 그 결과로 뭔가가 일어날 때만 모니터링할 가치가 있으며, 성과를 내는 프로그램은 부정적인 리뷰를 아무도 열어보지 않는 대시보드가 아니라 해당 제품을 담당하는 팀으로 라우팅한다.
이는 무엇이 조치를 촉발하는지 미리 결정하는 것을 의미한다. 특정 시장에서 평점이 임계값 아래로 떨어지는 것, 한 단어를 언급하는 리뷰의 급증, 알지 못하는 판매자 밑에 리스팅이 나타나는 것, 지켜야 할 카테고리에서 경쟁사의 평점이 앞서는 것 등이다. 프록시 계층은 이러한 신호가 판매하는 모든 시장에 걸쳐 완전하고 최신인 상태를 유지하도록 존재한다. 그것들에 대해 무엇을 하느냐가 진짜 작업이다.
다음 글 추천: 프록시로 지역 비즈니스 데이터를 스크래핑하는 방법. 같은 수집 문제의 위치 단위 버전을 다룬다.