← 전체 글
활용 사례 5분 읽기

50-Save 장벽에 걸리지 않고 채용 사이트 스크래핑하기

2026년 채용 사이트 스크래핑은 오픈 웹에서 가장 어려운 작업 중 하나가 되었습니다. 무엇이 달라졌으며, 인재 인텔리전스 팀이 데이터를 지속적으로 수집하는 방법을 알아봅니다.

job board scrapingtalent intelligenceanti-botweb scraping

도전 과제

2026년 6월 ApplyArc의 벤치마크에서는 200개의 실제 채용 정보 추출을 대상으로 5개의 LinkedIn 채용 정보 스크래퍼를 테스트했습니다. 3개는 약 50회 저장 후 계정에 플래그가 지정되거나 조용히 속도가 제한되었습니다. 단 2개만이 아무런 문제 없이 통과했습니다.

이 벤치마크가 모든 것을 말해줍니다. 과거에 채용 사이트는 쉬운 대상이었습니다. 이제는 오픈 웹에서 가장 어려운 대상 중 하나가 되었습니다.

채용 공고 데이터에 의존하는 서비스(인력 계획, 급여 벤치마킹, 인재 매핑, 주식 리서치를 위한 채용 신호 분석 등)를 구축하고 있다면, 여러분의 수집 레이어는 2년 전에는 존재하지 않았던 수많은 방어 체계와 싸우고 있는 것입니다. Indeed는 낯선 세션에 CAPTCHAs를 던집니다. LinkedIn은 IP 로테이션 전반에서 브라우저 측 신호를 상호 연관시킵니다. Glassdoor는 IP 단위가 아닌 ASN 단위로 rate limit를 적용합니다. ZipRecruiter는 headers가 스크립트가 아닌 사람처럼 보일 때만 렌더링되는 JavaScript에 급여 범위와 게시 날짜를 밀어 넣습니다.

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

채용 사이트 스크래핑이 점점 더 어려워지는 이유

2026년에 세 가지 변화가 생겼고, 이들이 겹쳐서 작용하고 있습니다.

첫 번째는 봇 탐지가 행동 기반으로 전환되었다는 점입니다. 과거에는 정적 검사(User-Agent, IP 평판, 초당 request 수)만으로도 취미로 하는 스크래퍼들을 막기에 충분했습니다. 이제는 그렇지 않습니다. 오늘날의 방어 체계는 사이트 내에서의 움직임을 감시합니다. 어떤 페이지를 어떤 순서로 로드하는지, 얼마나 머무르는지, 실제 브라우저라면 캐시했을 동일한 JS 번들을 다시 가져오는지 등을 확인합니다. 이 변화에 대해서는 Bot Detection Went Behavioral에서 다룬 바 있습니다. 채용 사이트는 방문자가 수행하는 반복적인 행동(검색, 클릭, 읽기, 저장)의 수가 적기 때문에 이를 빠르게 도입했습니다. 스크립트가 이 시퀀스의 절반을 건너뛰면 쉽게 발각됩니다.

두 번째는 proxy 풀 크기가 더 이상 중요하지 않게 되었다는 점입니다. 연결 레이어에서의 핑거프린트 상관관계 분석과 ASN 평판이 방어 수단으로 작동할 때는 5,000만 개의 IP를 가진 주거용 풀도 도움이 되지 않습니다. 이에 대해서는 Why Proxy Pool Size Stopped Mattering에서 다루었습니다. 중요한 것은 남들보다 더 많은 출구를 갖는 것이 아니라, 대상 사이트에 맞는 올바른 출구를 선택하는 것입니다.

세 번째는 법적인 문제입니다. Indeed와 LinkedIn 모두 소송을 제기하는 법무 팀을 보유하고 있습니다. 수집한 데이터를 판매할 계획이 있는 사람이라면 집 IP에서 공개 스크래퍼를 실행하는 시대는 끝났습니다.

현재의 데이터 수집 방식

2026년 인재 인텔리전스 작업에서 계속해서 효과를 발휘하는 패턴은 분할 스택(split stack)입니다. 보호된 사이트에는 실제 브라우저로 렌더링된 fetch를 사용하고, 다른 봇들과 동일한 제공업체에서 접속하는 것처럼 보이지 않도록 출구를 신중하게 선택하는 것입니다.

FourA와 같은 플랫폼을 사용하면, 이는 서로 통신하는 두 개의 제품이 됩니다.

Browser가 렌더링 측면을 처리합니다. unblocker: true와 함께 URL을 전송하면 실제 브라우저 세션으로부터 렌더링된 HTML, cookies, 스크린샷을 받아옵니다. JS가 실행되고, 지연 로딩(lazy-loaded)되는 필드들이 채워지며, request는 대부분의 기본적인 클라이언트를 잡아내는 연결 레이어 검사를 통과합니다. Proxy 선택은 백그라운드에서 실행됩니다. 플랫폼은 request당 출구를 선택하고 response에 불투명한 base36 ID를 반환하므로(Single/Browser의 최상위 r.proxy 또는 Auto의 r.session.proxy), 세션 연속성이 필요할 때 후속 호출에서 동일한 출구를 재사용할 수 있습니다. 대부분의 채용 사이트 작업에서는 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에는 원시 출구 대신 불투명한 proxy ID가 포함되므로 코드가 단순하게 유지되며 어떤 출구가 어떤 request를 처리했는지 추적할 필요가 없습니다.

두 번째 참고 사항은 코드 스니펫에 포함되지 않은 내용에 관한 것입니다. 여러 사이트 간의 중복 제거(LinkedIn, Indeed 및 회사의 자체 채용 페이지에 올라온 동일한 데이터 엔지니어 채용 공고가 서로 약간 다른 세 가지 제목으로 올라와 있는 경우)는 수집 레이어가 아닌 여러분이 해결해야 할 문제입니다. 저희는 많은 팀이 이 작업을 과소평가하는 것을 보았습니다. 정규화(Normalisation)는 데이터를 가져오는 것보다 더 많은 엔지니어링 시간을 소모하며, 대부분의 인재 인텔리전스 제품이 결국 경쟁하게 되는 지점이기도 합니다.

결과

3개의 채용 사이트에서 200개 기업을 추적하는 인재 인텔리전스 팀은 주당 약 50,000회의 페이지 fetch가 필요합니다(검색 결과, 채용 상세 페이지, 가끔씩 발생하는 회사 페이지 새로고침 등). 이 워크로드에서 달성하고자 하는 목표 수치는 다음과 같습니다.

  • Indeed 수준의 대상에 대해 95% 이상의 성공률 (여기서 성공이란 급여 범위와 게시 날짜가 채워진 렌더링된 HTML을 의미합니다).
  • 렌더링 및 출구 선택을 포함하여 엔드투엔드로 채용 공고당 비용 $0.004 미만.
  • 활성 채용 공고의 경우 **6~12시간의 업데이트 주기(Refresh cadence)**를 유지하여 채용 신호 대시보드가 시장보다 뒤처지지 않도록 합니다.

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

핵심 요약

채용 사이트는 이제 일반적인 이커머스보다는 광고 기술(ad-tech)이나 티켓팅 사이트에 가까운 난이도를 가집니다. 이는 실질적인 변화이며, 2024년에 작동했던 스크래핑 라이브러리들이 2026년에 왜 계속 동일한 장벽에 부딪히는지 설명해 줍니다.

이 장벽을 극복하고 확장해 나가는 팀들은 더 이상 "스크래퍼"를 단일 작업 단위로 생각하지 않습니다. 이들은 세션, 출구, 중복 제거를 세 가지 별개의 관심사로 생각하며, 앞의 두 가지를 위한 인프라는 구매하고 엔지니어들은 세 번째 작업에 시간을 집중할 수 있도록 합니다. 가장 비용이 적게 드는 채용 공고 데이터는 차단(flag)된 후 다시 수집할 필요가 없는 데이터입니다.