크롤링 9년 하고 내린 결론 — 차단을 이기지 말고 이유를 없애세요

01핵심 개요

02핵심 기능/내용 구조

1. 왜 막히는가 — 새 브라우저(깡통 브라우저)의 정체: 셀레늄으로 파이썬을 켜고 크롬 드라이버를 맞춰 띄우는 브라우저는 로그인 기록·쿠키·마우스 움직임 흔적이 전혀 없는 "방금 태어난" 브라우저다. navigator.webdriver 값이 자동화로 켜졌다는 사실을 자바스크립트 한 줄로 스스로 신고하며, 화면 크기·설치 폰트 목록·그래픽카드 렌더링 방식·오디오 장치 수치 등 지문(fingerprint)이 비정상적으로 "깨끗해서" 오히려 자동화의 증거가 된다.
2. 탐지 기술의 비대칭 구조: 2019년경에는 헤더 몇 줄만 고쳐도 크롤링이 통했지만, 지금은 차단 기술을 파는 전문 회사들이 전 세계 트래픽의 상당 부분을 거치며 수십억 건의 접속 데이터로 사람과 봇 패턴을 계속 학습한다. 개인이 어제 짠 우회 코드는 이미 그쪽에서 학습된 패턴이라 애초에 이길 수 없는 싸움이라는 진단.
3. 공식 API의 한계: 공식 API가 있으면 최선이지만 대부분 없거나, 있어도 필요한 항목이 빠져 있고, 승인까지 몇 주가 걸리며, 호출 수마다 과금된다. 카페 글 목록 하나 보려고 제휴 신청서를 쓸 수는 없다는 현실적 장벽.
4. 전통적 우회 시도의 소모전: 유저 에이전트 조작 → 막힘, 스텔스 플러그인 설치 → 이틀 뒤 막힘, 프록시 구매 → 비용 지출 후 막힘, 헤드리스 해제+마우스 랜덤 흔들기+클릭 딜레이 추가로 코드가 200줄을 넘어가도 사이트가 구조를 살짝 바꾸면 전부 무용지물이 된다. 크롤러는 "만들 때보다 살려둘 때" 유지보수 비용이 더 크다는 점이 강조된다.
5. 캡차의 진화: 최근 캡차는 그림 선택이 아니라 체크박스 클릭 전 마우스 움직임 패턴으로 이미 판정이 끝나 있는 방식이라, 코드로 흉내 내는 것 자체가 오래가지 못한다.
6. 발상의 전환 — "왜 새 브라우저를 띄우는가": 사용자 컴퓨터에는 이미 네이버 로그인·쿠키·몇 년 치 사용 기록이 쌓인 "완벽한 브라우저"가 있다. 이 브라우저는 지문이 지저분하기 때문에(=사람 컴퓨터의 정상적 특성) 오히려 차단 대상이 되지 않는다.
7. 원격 디버깅의 함정과 핵심 기법: 크롬 원격 디버깅 기능으로 새 창을 띄우면 기본 프로필을 물고 오지 않아 결국 또 깡통 브라우저가 되는 경우가 많다. 핵심은 "새로 만드는" 게 아니라 "쓰던 프로필을 그대로 붙잡는" 것. 동작 순서는 (1) 쓰던 브라우저를 붙잡음 → (2) 클로드가 그 안에서 페이지를 엶 → (3) 화면에 실제로 렌더링된 내용을 읽음(소스 코드 파싱이 아닌 사람이 보는 화면 기준) → (4) 다음 페이지 버튼 클릭 반복 → (5) 결과를 정리해 저장, 5단계로 요약된다.
8. 결과물 시연 3종: ① 네이버 카페 글 목록 수집(제목·작성자·날짜·링크, 여러 페이지 자동 순회, 차단 화면 미발생), ② 쇼핑몰 상품 목록 수집(상품명·가격·할인율·재고, 이미지 지연 로딩도 사람처럼 대기 후 읽음, 엑셀 저장), ③ 반응(평판) 수집(제품명으로 카페·블로그 검색 결과를 모아 그 자리에서 불만/칭찬 요약까지 완료, 수집과 분석이 한 번에 끝나는 것이 예전 크롤러와의 핵심 차이).

03기술적 맥락

이 방식의 기술적 핵심은 "브라우저 지문(fingerprinting)"에 대한 이해다. 안티봇 시스템은 navigator.webdriver 플래그, 화면 해상도, 설치된 폰트 목록, GPU 렌더링 특성(캔버스/WebGL 지문), 오디오 컨텍스트 지문 등 다수의 신호를 조합해 자동화 여부를 판별한다. 새로 띄운 브라우저는 이 모든 값이 기본값·초기값으로 지나치게 "깨끗하기" 때문에 역설적으로 탐지된다. 반면 사용자가 실제로 쓰던 브라우저 프로필(로그인 세션, 쿠키, 방문 기록, 확장 프로그램, 자동완성 등)을 그대로 재사용하면 이런 신호들이 자연스러운 사용자 패턴과 동일해진다. 또한 크롤러가 DOM/소스 코드를 파싱하는 대신 "화면에 렌더링된 내용을 사람이 보는 방식으로" 읽는다는 점도 중요한 차이로, 사이트의 HTML 구조(클래스명 등)가 바뀌어도 시각적으로 인식 가능한 요소는 계속 읽을 수 있어 유지보수 부담이 줄어든다. 크롬 원격 디버깅 프로토콜을 사용하되 새 프로필이 아닌 기존 사용자 프로필을 그대로 붙잡는 것이 구현의 핵심 포인트로 언급된다.

04전략적 의미

첫째, 차단 기술과 우회 기술 사이의 자원 비대칭(회사 대 개인)을 인정하고 "이기려는" 접근을 포기한 것이 발상 전환의 출발점이다. 이는 안티봇 탐지가 갈수록 정교해지는 산업 전반의 흐름에서, 개별 우회 스크립트의 수명이 구조적으로 짧아질 수밖에 없다는 것을 시사한다. 둘째, "가짜 신원을 정교하게 위장"하는 대신 "진짜 신원을 그대로 활용"하는 방향 전환은 크롤링뿐 아니라 AI 에이전트가 웹을 다루는 방식 전반(에이전틱 브라우징)에 적용 가능한 원칙이다. 셋째, 소스 코드 파싱 대신 렌더링된 화면을 사람처럼 읽는 방식은 사이트 구조 변경에 대한 내성을 높여, 유지보수 비용이라는 크롤러의 고질적 문제를 상당 부분 해소한다. 넷째, 수집과 분석(요약)이 한 번의 명령으로 동시에 처리되는 것은 LLM 기반 자동화가 전통적 파이프라인(수집→저장→별도 분석 코드 작성)을 압축하는 사례로 볼 수 있다.

05핵심 워크플로우 또는 비교표

06활용 시나리오

1. 경쟁사 모니터링: 경쟁사 쇼핑몰의 상품명·가격·할인율·재고를 매일 아침 자동 수집해 가격 변동을 추적하는 용도로, 로그인 없이도 접근 가능한 공개 페이지에서 특히 유용하다.
2. 브랜드 평판 관리: 자사 제품명으로 카페·블로그를 검색해 언급을 모으고, 그 자리에서 불만/칭찬 요약까지 AI에게 맡겨 고객 피드백 파악 소요 시간을 줄일 수 있다.
3. 채용 공고·공공기관 공고 비교 수집: 여러 채용 사이트나 공공기관 공지사항 페이지를 조건별로 정리해 놓치는 공고 없이 비교표를 만드는 데 활용할 수 있다.
4. 부동산 매물·중고거래 시세 추적: 조건별 매물 목록이나 중고 거래 시세를 주기적으로 수집해 가격 추이를 파악하는 개인용 자동화로 쓸 수 있다.
5. 로그인 기반 커뮤니티 데이터 수집: 네이버 카페처럼 로그인이 전제된 폐쇄형 커뮤니티에서, 기존에는 API도 없고 셀레늄으로는 차단됐던 데이터를 사용자 본인 계정의 정상 브라우징처럼 수집할 수 있다(단, 원래 로그인 없이 못 보는 자료는 동일하게 접근 불가).

07현황 및 전망

발표자는 자신이 만든 "크롤링 스타터킷"을 배포 중이며, 설치는 파일을 폴더에 넣고 클로드를 재시작하면 스킬 목록에 자동으로 나타나는 방식으로 복잡한 터미널 조작이 필요 없다고 설명한다. 코딩 지식 없이 한국어 명령만으로 작동하며 윈도우에서도 동일하게 동작한다고 언급된다. 실전 팁으로는 (1) 한 번에 전체 작업을 시키지 말고 먼저 한 페이지로 결과 형태를 확인할 것, (2) 저장 형식(엑셀 등)을 미리 지정할 것, (3) 오래 걸리는 작업은 자리를 비울 때 실행하고 브라우저를 동시에 쓰지 말 것, (4) 로그인이 풀리면 창에서 직접 재로그인하면 되고 코드 수정이 불필요하다는 점, (5) 결과가 이상하면 브라우저가 눈앞에 떠 있으므로 어디서 멈췄는지 직접 확인 가능하다는 점을 든다. 발표자는 로그인 정보가 외부로 전송되지 않고 로컬 브라우저의 쿠키가 원래 자리에 그대로 유지된다는 점, 작업 중에는 해당 브라우저 창을 다른 용도로 쓰지 말아야 한다는 점을 FAQ 형태로 답한다. 결론으로 "차단을 이기려 하지 말고 차단당할 이유를 없애라"는 원칙을 9년간 크롤러를 만들며 가장 늦게 깨달은 교훈으로 제시한다.

08용어 사전