웹 스크래핑에서 지문과 프록시는 어떻게 설정할까? 차단을 피하는 설정 설계

핵심 요약: 차단의 원인은 한 곳에 집중되는 일이 드물고, 대부분 프록시, 지문, 수집 리듬 세 층에 흩어져 있습니다. 파라미터 개수보다 설정 순서가 더 중요합니다. 먼저 각 작업의 프록시 출구를 고정합니다. 다음으로 환경에 논리적으로 일관된 지문 파라미터 세트를 부여합니다. 마지막으로 요청 빈도를 대상 사이트가 감당할 수 있는 범위로 낮춥니다. 이 글은 이 순서대로 설정 체크리스트를 제시하고, Local API로 환경 관리를 수집 스크립트에 연결하는 방법을 설명합니다.

“프록시를 열몇 개나 샀습니다.” 그런데 차단은 오히려 더 자주 왔습니다. 수집을 하는 팀은 예산을 프록시에 쏟아붓곤 하는데, 문제는 프록시 수량에 있지 않을 때가 많습니다. 같은 출구로 요청이 고빈도로 오가거나, 모든 세션이 동일한 브라우저 특성을 지니거나, 캡차가 뜬 뒤에도 원래 계획대로 돌아가는 상황이라면, 어느 한 층의 균형이 무너지는 것만으로도 돈 주고 산 출구까지 함께 끌려 내려갑니다.

제품 형태로 보면 MostMate는 지문 브라우저 계열의 도구입니다. 계정마다 독립된 브라우저 환경을 하나씩 배정하고, 프록시, 지문 파라미터, 로그인 상태를 모두 환경 안에서 관리합니다. 수집 맥락에 옮기면 하나의 환경이 하나의 수집 작업 실행 단위가 되고, 환경 사이에는 출구와 장치 특성이 공유되지 않습니다. 프록시는 요청이 어떤 회선으로 나가는지를, 지문은 대상 사이트가 어떤 장치를 보는지를 결정합니다. 이 두 층이 안정되어야 리듬 조절이 제 몫을 할 수 있습니다.

차단 신호는 세 층으로 나뉘고, 설정 순서도 여기서 정해집니다

안티봇이 한 번의 접속을 검사하는 방식은 대략 세 층으로 전개됩니다. 층마다 보는 대상이 다르고, 설정 동작도 다릅니다:

• 연결 층: 대상 사이트는 먼저 요청이 어느 IP에서 왔는지, 어떤 유형인지 봅니다. 같은 출구로 고빈도로 오가거나 표시된 대역에 속하면 가장 먼저 막힙니다.
• 장치 층: 페이지 스크립트는 Canvas, WebGL, 글꼴 목록, 시간대 같은 파라미터를 읽어 접속자가 실제하고 정상적인 장치인지 판단합니다.
• 행동 층: 요청 간격, 접속 경로, 로그인 후 동작 리듬입니다. 오래 기계적으로 일정한 패턴은 의심을 계속 높입니다.

세 층이 무너지는 순서가 설정 순서를 정합니다. 출구가 정해지지 않으면 언어, 시간대, 지리적 위치처럼 IP와 연동하는 파라미터가 붙을 곳이 없고, 장치 특성이 고정되지 않으면 리듬을 아무리 자연스럽게 조절해도 대상 사이트에는 같은 장치가 고빈도로 접속하는 것으로 보입니다. 그래서 작업 순서는 프록시 먼저, 다음 지문, 마지막 리듬이고, 아래 절들은 이 선을 따라 전개됩니다.

프록시 설정법: 수량보다 출구의 안정성이 중요합니다

수집 작업마다 독립된 출구를 하나씩 고정하는 편이, 로테이션 IP를 잔뜩 쌓는 것보다 안정적인 수집에 가깝습니다. 여러 작업이 같은 출구를 공유하면 한 작업이 리스크 관리에 걸릴 때 같은 출구의 나머지 작업도 흔히 함께 영향을 받습니다. 출구가 분리되면 작업 사이에는 최소한 연결 층에서 서로 영향이 없고, 문제를 점검할 때에도 어느 회선이 원인인지 바로 대조할 수 있습니다.

출구 유형은 리스크 강도에 맞춰 정합니다. 관대한 사이트라면 데이터센터 IP의 비용으로 충분합니다. 주요 전자상거래와 소셜미디어 사이트는 주거용 IP의 생존 시간이 통상 더 깁니다. 두 유형의 신뢰도 차이, 비용 구조와 적합한 용도는 주거용 IP와 데이터센터 IP 선택 가이드의 비교를 참고해 판단하고, 감이 아니라 근거로 고르면 됩니다.

MostMate에서는 프록시를 프록시 관리 목록에서 따로 관리합니다. HTTP, HTTPS, SOCKS5, SSH 네 가지 프로토콜 모두 입력 창이 마련되어 있고, 각 항목을 채운 뒤 Check proxy 버튼으로 연결성과 출구 소속을 그 자리에서 확인할 수 있습니다. 테스트가 통과되면 환경에 할당합니다. 환경 폼의 프록시 설정은 세 단계입니다: 프록시 사용 안 함, 사용자 지정 프록시, 프록시 선택. 수집 환경이라면 세 번째를 고르는 것을 권합니다. 모든 출구가 목록에 모여 하나로 관리되니 어느 작업이 어느 회선을 쓰는지 한눈에 확인됩니다.

프록시 층의 설정이 끝났으면 다음은 장치 특성 차례입니다.

지문 파라미터 정하는 법: 일관성 우선, 무작위는 신중하게

수집 환경의 지문 목표는 하나의 환경이 오랜 기간 동일한 정상 장치의 특성을 보여주는 것입니다. 이 목표를 기준으로 파라미터는 두 부류로 나눠 처리합니다. 출구와 연동하는 것은 자동 정렬에 맡기고, 장치 자체의 것은 한 세트로 고정해 오래 그대로 둡니다.

언어 설정, 인터페이스 언어, 시간대 설정, 지리적 위치 이 네 항목은 기본값이 IP 기반 설정입니다. 출구가 정해지면 값이 맞춰 따라갑니다. 출구를 바꿀 때 수작업 점검 한 판을 생략할 수 있습니다. 운영체제와 브라우저 버전은 조합 하나를 골라 고정하면 UA가 이에 맞춰 생성되고 작업 주기 내내 그대로 둡니다. 화면 해상도, CPU 코어 수, 장치 메모리, 글꼴 목록은 실제 값을 유지해 선언한 시스템과 같은 계보로 맞춥니다.

렌더링 계열 파라미터의 처리 방식이 더 주목할 만합니다. Canvas, WebGL 같은 영상과 오디오 출력에 대해 인터페이스가 제공하는 것은 노이즈 단계로, 실제 값 위에 가벼운 교란을 겹치면서 장치의 원래 논리는 그대로 둡니다. 검사 측이 받는 것은 여전히 스스로 맞는 한 세트의 출력입니다. 무작위 값이 오히려 왜 위험한지는 지문 파라미터는 무작위로 하지 마세요의 논증으로 이해할 수 있습니다.

수집 환경에서의 실천은 아주 구체적입니다. 렌더링 계열 파라미터는 노이즈 단계를 고르고 랜덤 단계는 쓰지 않습니다. 파라미터를 맞춘 뒤에도 감으로 대조할 필요가 없습니다. 환경 생성 폼 오른쪽에 지문 미리보기 패널이 있어 시간대, Canvas 단계 같은 값이 실시간으로 나란히 표시됩니다. 저장하기 전에 한 번 훑으면 눈에 띄는 어긋남은 그 자리에서 발견됩니다.

리듬과 로그인 상태: 행동 층의 불확실성 낮추기

새 작업의 시험 운전은 세 걸음으로 진행할 수 있습니다:

1. 출발점 정하기: 한 자릿수 동시성, 초 단위 간격으로 먼저 하루이틀 돌립니다. 캡차 발생 상황과 비정상 응답 비율을 기록합니다. 2. 경계 찾기: 캡차가 나타나는 순간 이전 단계 빈도로 물러납니다. 이 단계가 바로 그 출구의 현재 안전 경계입니다. 3. 물량 늘리기: 경계 안에서 며칠간 안정적으로 돌아간 뒤에 동시성을 조금씩 올립니다. 간격에는 기본값 위에 무작위 흔들림을 더해 반듯하게 일률적인 요청 리듬을 피합니다.

로그인 상태는 환경 안에 두고 유지합니다. 로그인해야 볼 수 있는 데이터는 한 번 로그인한 뒤 Cookie와 세션을 환경이 저장하고 다음에 열 때 이어서 씁니다. 반복 로그인의 검증 비용을 아끼는 동시에, 잦은 로그인이라는 행위 자체가 수상한 신호가 되는 일도 막습니다. 손대기 전에 수집 범위부터 확인하세요. robots 규약과 서비스 약관이 한 작업을 오래 돌릴 수 있는지를 결정하고, 규약 세부는 MDN의 robots.txt 항목을 참고할 수 있습니다. 이 항목은 모든 설정 파라미터보다 앞에 놓입니다.

Local API로 환경을 수집 스크립트에 연결하기

환경이 늘어난 뒤에는 하나씩 수작업으로 켜고 끄는 방식이 스크립트 속도를 따라가지 못합니다. MostMate는 Local API를 제공합니다. 로컬 인터페이스에 API 키를 더하고 보안 검증을 켜면 요청마다 Key를 함께 보내야 합니다. 수집 스크립트는 이를 통해 환경을 시작하고 끄며 상태를 조회하고, 어느 환경으로 돌릴지라는 판단을 코드에 맡길 수 있습니다. 창 동기화, RPA, API가 각각 어느 장면에 맞는지는 멀티 계정 자동화 선택 가이드에서 비교했고, 순수 스크립트 수집에 해당하는 것은 주로 API 계열입니다.

페이지 단위 수집은 흔히 자동화 프레임워크로 브라우저를 구동합니다. Playwright의 설치와 시작은 공식 문서에 전부 나와 있습니다. 조합 방식은 단순합니다. 스크립트가 먼저 Local API로 지정 환경을 열고, 자동화 프레임워크가 이 환경의 페이지 조작을 인수하며, 수집이 끝나면 환경을 닫습니다.

페이지 요청은 온전한 브라우저 환경에서 나가며 Cookie, 저장소, 지문 파라미터가 환경 안에 남습니다. 맨 HTTP 요청보다 남기는 특성이 훨씬 온전합니다. 환경, 프록시, 지문 같은 개념이 제품 안에서 어떤 관계인지는 MostMate란 무엇인가 페이지에 체계적으로 정리되어 있으니 스크립트를 쓰기 전에 한 번 훑어두면 인터페이스가 돌려주는 필드를 이해하는 속도가 훨씬 빨라집니다.

Local API 호출 횟수에는 요금제 기준이 있으며, 인터페이스에는 반년 이상 요금제에서 열린다고 표기됩니다. 스크립트를 쓰기 전에 요금제 주기를 먼저 확인하세요. 흐름을 다 짜고 나서야 호출이 제한되는 사실을 알게 되는 일을 막을 수 있습니다.

자주 묻는 질문

수집 작업마다 프록시를 따로 하나씩 배정해야 하나요?

대상 사이트의 리스크 강도와 작업량으로 판단합니다. 리스크가 심하고 작업량이 많은 사이트라면 독점 출구 하나가 값어치를 합니다. 저빈도의 소규모 작업은 하나를 함께 써도 되지만, 함께 쓰는 작업들은 가급적 서로 무관한 업무여야 합니다. 하나가 표시되면 같은 출구의 나머지 작업이 함께 휩쓸리기 쉽습니다.

지문 파라미터는 주기적으로 바꿔야 하나요?

아닙니다. 같은 환경의 파라미터를 오래 고정해 두는 것이 목표이고, 자주 바꾸면 장치 특성의 연속성이 무너집니다. 출구를 교체하거나 파라미터 어긋남을 점검해 낼 때만 해당 항목 하나만 손댑니다.

requests로 바로 요청하면 안 되나요?

단순한 인터페이스라면 됩니다. requests 같은 요청 라이브러리는 페이지 스크립트를 실행하지 않아 온전한 브라우저 특성을 얻지 못합니다. 이런 라이브러리는 렌더링이 필요 없는 공개 인터페이스에만 적합합니다. 페이지 단위 수집이나 리스크가 심한 사이트는 온전한 브라우저 환경으로 돌리는 편이 더 안정적입니다.

데이터가 갑자기 텅 비어 오면 무엇부터 확인하나요?

먼저 빈도 문제로 취급합니다. 빈도를 낮춰 하루이틀 지켜보고, 여전히 이상하면 출구와 지문의 일관성을 대조한 뒤 브라우저 환경으로 같은 페이지를 수작업으로 열어봅니다. 사이트 구조가 바뀐 것인지 접속이 막힌 것인지를 가르고, 출구 교체는 맨 나중에 고려합니다.

맺음말

수집을 오래 돌릴 수 있는지는 세 층의 설정이 동시에 성립하는가에 달려 있습니다. 출구의 안정, 지문의 일관, 리듬의 절제입니다. 어느 한 층이 무너지면 나머지 두 층의 비용이 함께 커집니다. MostMate는 프록시, 지문, 로그인 상태를 각 환경에 담아 두고, 환경이 곧 작업의 실행 단위가 되며, Local API와 함께하면 기존 수집 스크립트에 바로 연결할 수 있습니다.

첫 수집 작업을 세우고 싶다면 MostMate 내려받기부터 시작해 무료 버전의 환경으로 작은 사이트 하나의 모니터링을 돌려본 뒤, 다른 작업으로 차례로 복제해 가면 됩니다.