웹 스크래핑 제한 시 해결: IP 차단, CAPTCHA, 로그인 문제 점검

403/429, 핑거프린팅, CAPTCHA, 동적 페이지, 로그인 세션의 관점에서 웹 스크래핑이 제한되는 실제 이유를 설명하고, API 우선, 속도 제한과 백오프, 증분 캐시, 컴플라이언스를 갖춘 계정 환경 접근 방식을 제시합니다.

웹 스크래핑 작업이 403, 429, CAPTCHA, 반복되는 로그인 실패에 부딪혔을 때, 올바른 대응은 IP를 로테이션하거나 핑거프린트를 위장하거나 "실제 사람처럼" 흉내 내는 것이 아닙니다. 이러한 신호는 보통 요청 빈도, 접근 범위, 인증 방식, 자동화 행동이 사이트가 허용하는 경계를 넘었음을 의미합니다. 회피를 계속하면 일시적 제한이 더 커지고, 이용약관, 계약, 저작권, 데이터 보호 규정을 위반할 수도 있습니다.

더 안정적인 길은 먼저 권한과 사용 가능한 인터페이스를 확인하고, 이어서 트래픽을 줄이며, 캐시와 백오프를 적용하고, JavaScript 렌더링이나 사람 로그인이 정말 필요한 페이지에 한해 브라우저 자동화를 사용하는 것입니다. CAPTCHA는 돌파해야 할 기술적 장벽이 아니라 "멈추라는 신호"로 다루세요.

증상부터 좁혀 들어가기

증상	일반적인 원인	컴플라이언스 차원의 대응
429 Too Many Requests	요청이 너무 빠르거나 동시성이 높거나 중복 수집	속도를 낮추고, Retry-After를 따르며, 지수 백오프 적용
403 Forbidden	권한 없는 경로, 정책 차단, 세션 누락	권한, 약관, robots.txt, 인증 방식 확인
CAPTCHA 등장	사이트가 사람 확인을 요구하거나 자동화를 차단	작업을 일시 중지하고 수동 처리하거나 API 요청
로그인이 계속 실패	쿠키 만료, 다중 사용자가 세션을 덮어씀, 인증 실패	공식 OAuth 또는 서비스 계정 사용, 세션 인계를 정리
페이지에는 내용이 있지만 스크립트가 가져올 수 없음	JavaScript 렌더링, 비동기 API 로딩	공식 API 사용; 허가를 받은 경우 브라우저 렌더링 후 DOM 읽기
선택자가 갑자기 동작하지 않음	DOM 변경, A/B 테스트, 언어 변경	시맨틱 로케이터, 구조 테스트, 알람 활용, 하드코딩된 계층 회피
데이터 중복 또는 누락	페이지네이션, 커서, 시간대, 갱신 윈도우 오류	고유 키, 증분 워터마크, 재실행 메커니즘 구축

한 번에 하나의 변수만 바꾸고 로그를 남기세요. IP, User-Agent, 계정, 파서를 동시에 바꾸면 우연히 성공해도 원인을 구분할 수 없습니다.

1단계: 해당 데이터를 수집할 권한이 있는지 확인

시작하기 전에 다음 네 가지에 답하세요.

데이터가 공개인가요, 아니면 로그인 후·유료 후·특정 역할에게만 제공되나요?
사이트가 API, 내보내기, 피드, 웹훅 또는 파트너용 데이터 인터페이스를 제공하나요?
이용약관, robots.txt, 계약, 현지 법령이 의도된 용도를 허용하나요?
데이터에 개인정보, 저작권 보호 콘텐츠 또는 기타 민감 필드가 포함되나요?

robots.txt는 사이트가 자동 클라이언트에 허용·금지 경로를 표현하는 표준 메커니즘입니다. RFC 9309는 Robots Exclusion Protocol의 문법과 매칭 규칙을 정의하며, 동시에 robots.txt가 접근 권한이 아님을 분명히 합니다. 즉 robots.txt에 허용되었다고 해서 데이터의 복제·처리·상업적 사용에 대한 모든 권리를 얻은 것은 아니며, 금지된 경로를 다른 경로로 우회해서는 안 됩니다.

엔터프라이즈 프로젝트는 데이터 출처, 접근 근거, 용도, 필드, 보존 기간, 삭제 메커니즘을 문서로 남겨야 합니다. 집계 데이터로 문제를 해결할 수 있다면 개인을 식별할 수 있는 정보를 수집하지 마세요.

2단계: 안정적인 데이터 진입점을 우선

일반적인 우선순위는 다음과 같습니다.

공식 API, 웹훅, 데이터 내보내기;
공개 피드, 사이트맵, 배치 파일;
사용이 허가된 일반 HTTP 페이지;
JavaScript를 반드시 렌더링해야 할 때만 브라우저 자동화;
사람 계정과 상호작용이 필요한 페이지는 마지막에 처리.

API는 보통 필드 정의, 페이지네이션, 속도 제한, 오류 코드를 함께 제공하므로 UI를 파싱하는 것보다 유지보수 비용이 낮습니다. 웹 페이지는 사람 눈을 위한 인터페이스이며 언제든 변경될 수 있으므로 안정적인 데이터베이스로 취급해서는 안 됩니다.

적절한 인터페이스가 없다면 먼저 데이터 소유자에게 용도, 빈도, 필드, 상업적 규모를 설명하세요. 명확한 데이터 라이선스는 보통 제한과 장기적으로 싸우는 것보다 저렴합니다.

3단계: 429와 IP 차단은 "출처 숨기기"가 아니라 "부하 줄이기"

속도와 동시성 상한 설정

단일 워커와 긴 간격부터 시작해 응답 시간과 오류율을 관찰합니다. 서버가 Retry-After를 반환하면 그 시간만큼 기다리고, 반환하지 않으면 지수 백오프와 랜덤 지터를 사용해 여러 작업이 동시에 재시도하지 않도록 합니다.

예시 정책:

대기 = min(상한, 기본 × 2^재시도횟수) + 랜덤지터

최대 재시도 횟수에 도달하면 멈추고 알람을 발생시키세요. 무한 루프를 돌리지 마세요.

캐시와 증분 갱신

같은 URL을 캐시하고, 지원한다면 ETag나 Last-Modified를 활용한 조건부 요청을 보내세요. 마지막 갱신 시각이나 커서를 기록해 신규·변경분만 가져옵니다. 전체 수집 작업과 일상적인 증분 작업을 분리하면 요청량을 크게 줄일 수 있습니다.

클라이언트를 정직하게 식별

컴플라이언스를 지킨 크롤러는 안정적이고 실제 User-Agent를 사용하고, 용도를 명시하며, 연락처 페이지나 이메일을 제공합니다. 일반 브라우저로 위장하거나 신원을 자주 바꾸면 사이트가 정상 트래픽과 비정상 트래픽을 구분하기 어려워져 결국 차단될 가능성이 커집니다.

특정 IP가 제한되었다면 작업을 멈추고 원인을 확인하세요. 접근을 계속하려고 프록시를 로테이션하는 것은 접근 통제 우주로 간주될 수 있으며 해결책이 아닙니다.

4단계: 핑거프린팅과 행동 분석에 대응

브라우저 핑거프린트는 User-Agent, 운영체제, 언어, 시간대, 해상도, Canvas, WebGL 같은 신호를 조합합니다. 사이트는 추가로 요청 간격, 내비게이션 경로, 세션 행동을 분석할 수도 있습니다. OWASP는 Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing 등을 별도의 자동화 위협 카테고리로 분류하며, 이것이 사이트가 여러 신호를 결합해 자동화 위험을 판단하는 이유입니다.

인가된 작업의 목표는 "사람처럼 보이는" 신원을 대량으로 만드는 것이 아니라, 환경을 안정적이고 설명 가능하게 유지하는 것입니다.

같은 업무 계정에는 고정된 환경과 정상 인증을 사용;
브라우저 파라미터는 실제 지역·단말과 일치;
차단을 피하려고 핑거프린트를 무작위로 바꾸지 않음;
수집 빈도, 작업 ID, 책임자를 로그에 기록;
사이트와 허용 계정 수, 동시성, 데이터 범위를 합의.

인가된 작업이 사이트에서 여전히 오탐된다면, 시각, User-Agent, 송출 IP, 요청 샘플을 제공해 화이트리스트 등록이나 전용 인터페이스 제공을 요청하세요.

5단계: CAPTCHA가 나타나면 자동화를 멈춘다

CAPTCHA는 사람을 확인하거나 의심스러운 자동화를 차단하기 위한 것입니다. OCR, CAPTCHA 풀이 서비스, CAPTCHA 우회 플러그인 등 어떤 자동 우회 수단도 사용하지 마세요.

올바른 절차는 다음과 같습니다.

현재 계정과 작업 큐를 즉시 일시 중지;
트리거 직전의 요청 빈도, 경로, 오류 로그 저장;
권한 있는 인물이 공식 페이지에서 필요한 검증을 수행;
요청이 너무 빨랐는지, 세션이 만료되었는지, 허용되지 않은 경로에 접근했는지 확인;
장기적인 자동화가 필요하면 사이트에 API, 서비스 계정, 화이트리스트 신청.

CAPTCHA를 사람이 한 번 해결했다고 해서 이후 무제한 자동 요청을 보낼 권리가 생기는 것은 아닙니다. 먼저 발생 원인을 고치세요.

6단계: 로그인과 다중 계정은 정식 권한으로

로그인 뒤의 데이터는 공개 페이지보다 민감합니다. OAuth, 서비스 계정, API 토큰, 플랫폼 공식 팀이 부여한 권한을 우선하고, 스크립트에 개인 메인 비밀번호를 저장하지 마세요.

브라우저 세션이 꼭 필요할 때는:

하나의 정당한 업무 계정에 안정적인 환경 하나를 매핑;
쿠키는 암호화해 저장하고 만료·폐기 수단을 마련;
MFA를 켜고 자동화가 2차 인증을 우회하지 못하게 할 것;
여러 사람이 동시에 비밀번호를 재설정하거나 쿠키를 복사하지 못하게 할 것;
누가 언제 어떤 작업을 시작했는지 기록;
퇴사, 프로젝트 종료, 권한 변경 시 즉시 접근을 폐기.

다중 계정은 실제로 소유하거나 사용을 허가받은 계정에만 적용할 수 있습니다. 사이트가 1 주체 1 계정으로 제한한다면 환경 격리를 그 제한을 깨는 데 사용하지 마세요.

7단계: 동적 페이지 파싱을 변경에 강하게

시맨틱하고 안정적인 속성 사용

제목, 헤더, 접근성 속성, 사이트가 공개한 테스트 식별자를 우선 사용하세요. div:nth-child(7) 같은 깨지기 쉬운 계층은 피하세요. 페이지가 새로고침된 뒤에는 DOM을 다시 읽고, 예전 노드가 남아 있을 것이라고 가정하지 마세요.

추출과 비즈니스 로직 분리

수집 계층은 페이지를 구조화된 필드로 바꾸는 역할만 하고, 검증 계층이 타입, 범위, 고유 키, 필수 항목을 검사합니다. 이렇게 분리하면 디자인이 바뀌어도 파서만 조정하면 되고 하류 분석은 망가지지 않습니다.

샘플과 알람 구축

컴플라이언스를 지킨 소수의 HTML 또는 구조 스냅샷을 테스트 샘플로 보관하세요. 완전한 계정 페이지나 민감 데이터는 저장하지 마세요. 필드 누락률, 레코드 수, 중복률, 페이지 제목을 모니터링하고, 이상이 감지되면 운영 데이터 쓰기를 멈춥니다.

인가된 스크래핑에서 PurpleMark의 적절한 역할

팀이 여러 인가 계정, 여러 클라이언트 환경, 여러 리전 환경을 동시에 유지해야 할 때, PurpleMark 웹 앱에서 업무 계정마다 독립적인 브라우저 환경을 만들고 해당 쿠키, 로그인 후 기본으로 열릴 페이지, 평소 네트워크 설정을 함께 저장할 수 있습니다. 같은 환경을 다시 열면 브라우저가 직전 세션과 작업 페이지로 돌아가므로 여러 사람이 같은 쿠키를 공유하거나 매번 다시 로그인하는 번거로움을 피할 수 있습니다.

계정을 클라이언트·플랫폼·리전 단위로 구분해야 한다면 환경 그룹으로 업무 계정을 묶고, 멤버 권한·공유·이전을 통해 누가 어떤 환경을 열 수 있는지 통제할 수 있습니다. 작업 로그에는 어떤 환경이 언제, 누구에 의해 열렸는지 또는 변경되었는지가 기록되므로, 인가된 스크래핑에 대한 문의가 있을 때 구체적인 계정과 책임자까지 빠르게 추적할 수 있습니다.

PurpleMark은 "계정·환경·세션·책임"을 한 작업 공간에서 장기간 관리하도록 돕지만, IP 차단, CAPTCHA, 계정 수 제한, 사이트의 자동화 방어를 우회하는 데 사용되어서는 안 됩니다. 먼저 권한을 확보한 다음에 자동화를 이야기하세요.

유지보수 가능한 스크래핑 아키텍처

시스템을 다섯 계층으로 나누는 것을 권장합니다.

스케줄링 계층: 빈도, 동시성, 작업 우선순위, 일시 중지 제어;
접근 계층: API, HTTP, 인가된 브라우저 세션;
파싱 계층: 응답을 구조화된 필드로 변환;
품질 계층: 중복 제거, 타입 검증, 누락 알람, 버전 기록;
거버넌스 계층: 권한, 출처, 용도, 보존 기간, 삭제.

각 레코드에는 출처 URL, 수집 시각, 파서 버전을 함께 보관하세요. 문제가 생겼을 때 사이트 전체를 다시 수집하는 대신, 영향 받은 레코드만 식별해 재실행할 수 있습니다.

자주 묻는 질문

프록시를 로테이션하면 IP 차단이 해결되나요?

송출 주소만 잠시 바뀔 뿐 빈도·권한·행동 문제는 해결되지 않습니다. 접근을 유지하기 위한 프록시 로테이션은 우주로 간주될 수 있습니다. 먼저 작업을 멈추고, 요청을 줄이고, 사이트에 연락하세요.

CAPTCHA를 자동으로 풀 수 있나요?

해서는 안 됩니다. CAPTCHA는 일시 중지 또는 사람 확인을 요구하는 신호입니다. 지속적인 자동화가 필요하면 API, 서비스 계정, 화이트리스트를 신청하세요.

robots.txt에 허용되어 있으면 항상 수집할 수 있나요?

핑거프린트 브라우저는 스크래핑을 "들키지 않게" 할 수 있나요?

보장할 수 없으며 그것이 목표여서도 안 됩니다. 정당한 계정 세션과 팀 권한을 분리하고, 쿠키 혼용과 실수를 줄이는 데 더 적합합니다.

마무리

웹 스크래핑 제한은 단순한 "봇 차단 기술" 문제가 아닙니다. 403, 429, 핑거프린팅, CAPTCHA, 다중 계정 제한은 모두 권한·부하·신원 관리로 귀결됩니다.

안정적인 해법은 항상 API 우선, 명확한 인가, 절제된 요청, 증분 캐시, 테스트 가능한 파싱, 감사 가능한 계정으로 돌아옵니다. CAPTCHA나 차단이 발생하면 자동화 출처를 계속 숨기는 대신, 작업을 멈추고 프로세스를 바로잡으세요.