50-Save 장벽을 피하는 구인 게시판 스크래핑

과제

2026년 6월 ApplyArc의 벤치마크는 200개의 실제 채용 공고 수집에서 5개의 LinkedIn 구인 스크래퍼를 테스트했습니다. 그중 3개는 약 50번의 저장 후 계정이 차단되거나 조용히 스로틀링(throttled)되었습니다. 2개만이 깨끗하게 살아남았습니다.

이 벤치마크가 모든 것을 말해줍니다. 구인 게시판은 과거에 쉬운 타겟이었습니다. 이제는 오픈 웹에서 가장 방어력이 높은 곳 중 하나입니다.

구인 데이터(인력 계획, 연봉 벤치마킹, 인재 매핑, 주식 조사를 위한 채용 신호)에 의존하는 서비스를 구축하고 있다면 데이터 수집 계층은 2년 전에는 없던 다양한 방어 시스템과 싸워야 합니다. Indeed는 낯선 세션에 CAPTCHA를 띄웁니다. LinkedIn은 IP 로테이션 전반에 걸쳐 브라우저 측 신호를 상호 연관시킵니다. Glassdoor는 IP가 아닌 ASN 단위로 rate limit을 적용합니다. ZipRecruiter는 헤더가 스크립트가 아닌 사람처럼 보일 때만 렌더링되는 JavaScript에 연봉 구간과 게시일을 넣습니다.

따라서 50-save 장벽은 LinkedIn만의 문제가 아닙니다. 이는 해당 카테고리 전체의 특성입니다.

구인 게시판 스크래핑이 계속 어려워지는 이유

2026년에 3가지 변화가 일어났고 이들이 중첩되었습니다.

첫째, 봇 탐지가 행동 기반으로 바뀌었습니다. 과거에는 취미 수준의 스크래퍼를 막는 데 정적 검사(User-Agent, IP 평판, 초당 요청 수)만으로 충분했습니다. 이제는 다릅니다. 오늘날의 방어 시스템은 사이트 내 이동 방식을 감시합니다. 어떤 페이지를 어떤 순서로 로드하는지, 얼마나 머무는지, 실제 브라우저라면 캐시할 동일한 JS 번들을 다시 가져오는지 확인합니다. 우리는 봇 탐지의 행동 기반 전환에서 이러한 변화를 다루었습니다. 구인 게시판 방문자는 적은 수의 반복 가능한 작업(검색, 클릭, 읽기, 저장)을 수행하므로 스크립트가 그 과정의 절반을 건너뛸 때 쉽게 눈에 띄기 때문에 이를 일찍 도입했습니다.

둘째, proxy 풀의 크기가 더 이상 중요하지 않게 되었습니다. 연결 계층의 지문 상관관계와 ASN 평판이 결합된 방어 시스템 앞에서는 5천만 개의 주거용 IP 풀도 소용없습니다. 이는 Proxy 풀 크기가 더 이상 중요하지 않은 이유에서 설명했습니다. 중요한 것은 남들보다 많은 출구(exit)를 갖는 것이 아니라 대상 사이트에 맞는 올바른 exit를 선택하는 것입니다.

셋째, 법적 문제입니다. Indeed와 LinkedIn은 모두 소송을 제기할 수 있는 법무팀을 보유하고 있습니다. 수집한 데이터를 판매하려는 목적이라면 집 IP로 공개 스크래퍼를 실행하던 시대는 끝났습니다.

현재의 데이터 수집 방식

2026년 인재 인텔리전스 작업에서 계속 효과를 발휘하는 패턴은 분할된 스택입니다. 보호된 게시판을 위해 실제 브라우저에서 렌더링된 fetch를 사용하고, 다른 모든 봇과 동일한 공급자에서 오지 않도록 신중하게 exit를 선택해야 합니다.

FourA와 같은 플랫폼에서는 두 제품이 서로 통신하는 구조입니다.

브라우저는 렌더링 측면을 처리합니다. unblocker: true(으)로 URL을 보내고 실제 브라우저 세션에서 렌더링된 HTML, 쿠키, 스크린샷을 돌려받습니다. JS가 평가되고 지연 로드(lazy-load) 필드가 채워지며, request는 대부분의 기본 클라이언트를 차단하는 연결 계층 검사를 통과합니다. Proxy 선택은 백그라운드에서 실행됩니다. 플랫폼은 request당 exit를 선택하고 response에서 불투명한 base36 id를 반환하므로(Single/Browser의 경우 최상위 r.proxy, Auto의 경우 r.session.proxy), 세션 연속성이 필요할 때 후속 호출에서 동일한 exit를 재사용할 수 있습니다. 대부분의 구인 게시판 작업에서 적합한 진입점은 Auto입니다. 각 대상에 필요한 항목을 기반으로 Single, Proxy, Browser를 조율하므로 코드에서 직접 처리할 필요가 없습니다.

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["data-testid=\"job-card\""],
                       "fail":   ["Just a moment", "captcha"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.

이 방식을 통해 얻을 수 있는 두 가지 이점을 설명합니다.

ApplyArc 스타일의 50-save 장벽은 대부분 풀이 아니라 세션 문제입니다. 신중하게 로테이션되는 실제 브라우저 세션은 단순 HTTP 클라이언트보다 rate limit에 걸리기 전까지 훨씬 더 오래 유지됩니다. 또한 response는 원본 exit 대신 불투명한 proxy id를 전달하므로 코드가 단순하게 유지되며, 어떤 exit가 어떤 request를 처리했는지 추적할 필요가 없습니다.

두 번째 참고 사항은 스니펫에 없는 내용에 관한 것입니다. 여러 게시판(LinkedIn, Indeed, 회사 자체 채용 페이지에서 세 가지 약간 다른 직함으로 표시된 동일한 데이터 엔지니어 역할)의 데이터 중복 제거는 수집 계층이 아닌 여러분이 해결해야 할 과제입니다. 우리는 팀들이 이 점을 과소평가하는 것을 보아왔습니다. 정규화(Normalisation)는 fetch 작업보다 더 많은 엔지니어링 시간을 소모하며, 대부분의 인재 인텔리전스 제품이 궁극적으로 경쟁하는 영역입니다.

결과

세 개의 게시판에서 200개 회사를 추적하는 인재 인텔리전스 팀은 검색 결과, 구인 세부 정보 페이지, 가끔씩 업데이트되는 회사 페이지 등 일주일에 약 50,000번의 페이지 fetch가 필요합니다. 해당 워크로드에서 달성해야 할 목표 수치는 다음과 같습니다.

Indeed급 대상의 성공률 95% 이상 (성공은 연봉 구간과 게시일이 포함된 렌더링된 HTML을 의미합니다).
렌더링 및 exit 선택을 포함한 엔드투엔드 작업당 비용 $0.004 미만.
활성 역할에 대한 6~12시간의 갱신 주기 (채용 신호 대시보드가 시장에 뒤처지지 않도록).

이 수치는 분할 스택 패턴을 실행하는 팀의 보고를 기반으로 한 예시입니다. 실제 비용은 어떤 게시판을 타겟팅하고 새 게시물을 얼마나 적극적으로 필터링하는지에 따라 달라집니다.

핵심 요약

이제 구인 게시판의 난이도는 일반적인 이커머스보다는 애드테크나 티켓팅에 더 가깝습니다. 이는 실질적인 변화이며, 2024년에 작동했던 스크래핑 라이브러리가 2026년에도 계속 같은 장벽에 부딪히는 이유를 설명해 줍니다.

이를 넘어 확장하는 팀은 스크래퍼를 하나의 작업 단위로 생각하지 않습니다. 이들은 세션, exit, 중복 제거를 세 가지 별개의 관심사로 고려하며, 엔지니어들이 세 번째 항목에 시간을 쏟을 수 있도록 처음 두 항목에 대한 인프라를 구매합니다. 가장 저렴한 구인 데이터는 차단(flag) 후 다시 수집할 필요가 없는 데이터입니다.