문제점
2026년 6월 ApplyArc의 벤치마크에서는 5개의 LinkedIn 채용 공고 스크래퍼를 대상으로 200회의 실제 공고 수집 테스트를 진행했습니다. 3개는 약 50건을 저장한 후 계정이 플래그 처리되거나 조용히 스로틀링되었습니다. 단 2개만이 차단 없이 살아남았습니다.
이 벤치마크가 모든 것을 설명합니다. 과거 채용 사이트는 손쉬운 대상이었습니다. 하지만 지금은 오픈 웹에서 가장 까다로운 대상 중 하나가 되었습니다.
채용 공고 데이터에 의존하는 서비스(인력 계획, 급여 벤치마킹, 인재 맵핑, 주식 리서치를 위한 채용 동향 분석 등)를 개발하고 있다면, 여러분의 수집 계층은 2년 전에는 존재하지 않았던 일련의 방어 체계와 싸우고 있는 것입니다. Indeed는 익숙하지 않은 세션에 인증 페이지를 표시합니다. LinkedIn은 IP가 바뀌어도 브라우저 측 시그널을 교차 대조합니다. Glassdoor는 IP 단위가 아니라 ASN 단위로 rate limit를 겁니다. ZipRecruiter는 헤더가 스크립트가 아닌 실제 사람처럼 보일 때만 렌더링되는 JavaScript 내에 급여 범위와 게시 날짜를 숨깁니다.
따라서 50건 수집의 벽은 LinkedIn만의 문제가 아닙니다. 채용 사이트 카테고리 전체의 특성입니다.
채용 사이트 수집이 계속 어려워지는 이유
2026년에 세 가지 변화가 발생했고, 이들이 복합적으로 작용했습니다.
첫 번째는 봇 탐지가 행동 기반으로 바뀌었다는 점입니다. 과거에는 정적 검사(User-Agent, IP 평판, 초당 request 수)만으로도 취미 수준의 스크래퍼를 막기에 충분했습니다. 이제는 아닙니다. 최신 방어 체계는 사이트 내 탐색 방식을 감시합니다. 어떤 순서로 페이지를 로드하는지, 얼마나 머무르는지, 실제 브라우저라면 캐시했을 동일한 JS 번들을 다시 fetch하는지 등을 확인합니다. 이 변화에 대해서는 봇 탐지의 행동 기반 전환에서 다룬 바 있습니다. 채용 사이트는 방문자가 수행하는 반복 가능한 작업이 적기 때문에(검색, 클릭, 확인, 저장) 시퀀스의 절반을 건너뛰는 스크립트를 쉽게 감지할 수 있어 이를 일찍 도입했습니다.
두 번째는 proxy 풀 크기가 더 이상 중요하지 않다는 점입니다. 연결 계층에서의 핑거프린트 상관관계 분석과 ASN 평판이 방어 수단으로 사용되는 상황에서는 5천만 개의 주거용 IP 풀도 도움이 되지 않습니다. 이에 대해서는 Proxy 풀 크기가 더 이상 중요하지 않은 이유에서 설명했습니다. 중요한 것은 다른 누구보다 많은 출구를 확보하는 것이 아니라, 대상 사이트에 적합한 출구를 선택하는 것입니다.
세 번째는 법적 문제입니다. Indeed와 LinkedIn은 모두 적극적으로 소송을 제기하는 법무팀을 보유하고 있습니다. 수집한 데이터를 상업적으로 활용하려는 사람이라면 가정용 IP로 공개 스크래퍼를 실행하던 시대는 끝났습니다.
현재의 데이터 수집 방식
2026년 인재 인텔리전스 작업에서 지속적으로 작동하는 패턴은 분할 스택입니다. 보호된 사이트를 위한 실제 브라우저 렌더링 기반 fetch와, 다른 모든 봇과 동일한 제공업체에서 유입되지 않도록 정교하게 출구를 선택하는 방식을 결합하는 것입니다.
FourA와 같은 플랫폼에서는 두 가지 제품이 서로 통신하는 구조를 의미합니다.
Browser는 렌더링 영역을 처리합니다. unblocker: true과 함께 URL을 전송하면 실제 브라우저 세션에서 렌더링된 HTML, cookie 및 스크린샷을 반환받습니다. JS가 실행되고, 지연 로딩 필드가 채워지며, 대부분의 기본 클라이언트를 차단하는 연결 계층 검사를 통과합니다. 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회 저장 제한은 대부분 풀(pool) 문제가 아니라 세션 문제입니다. 신중하게 순환되는 실제 브라우저 세션은 원시 HTTP 클라이언트보다 rate limit에 걸리기 전까지 훨씬 더 오래 유지됩니다. 또한 response에는 원시 exit 대신 불투명한 proxy id가 포함되므로, 코드를 단순하게 유지할 수 있고 어떤 exit이 어떤 request를 처리했는지 추적할 필요가 없습니다.
두 번째 참고 사항은 코드 스니펫에 포함되지 않은 내용에 관한 것입니다. 여러 채용 플랫폼 간의 중복 제거(LinkedIn, Indeed, 기업 자체 채용 페이지에 조금씩 다른 세 가지 직책명으로 등록된 동일한 데이터 엔지니어 포지션)는 수집 계층이 아닌 개발팀이 해결해야 할 문제입니다. 이를 과소평가하는 팀들을 자주 보았습니다. 정규화는 데이터 fetch보다 더 많은 엔지니어링 시간을 소모하며, 대부분의 인재 인텔리전스 제품이 실질적으로 경쟁하는 영역이기도 합니다.
결과
3개 채용 플랫폼에서 200개 기업을 추적하는 인재 인텔리전스 팀은 검색 결과, 채용 공고 상세 페이지, 비정기적인 기업 페이지 갱신을 포함해 주당 약 50,000건의 페이지 fetch가 필요합니다. 해당 워크로드에서 달성해야 하는 수치는 다음과 같습니다.
- Indeed 수준의 대상을 기준으로 95% 이상의 성공률. 여기서 성공이란 급여 범위와 게시일이 채워진 렌더링된 HTML을 의미합니다.
- 렌더링 및 exit 선택을 포함하여 엔드투엔드 기준 공고당 비용 $0.004 미만.
- 채용 신호 대시보드가 시장에 뒤처지지 않도록 활성 채용 공고에 대해 6시간에서 12시간 주기의 갱신 간격.
이 수치들은 해당 분할 스택 패턴을 운영하는 팀들의 보고를 기반으로 한 예시입니다. 실제 비용은 대상 플랫폼과 신규 채용 공고 필터링 강도에 따라 달라집니다.
핵심 요약
채용 플랫폼의 난이도는 이제 일반 이커머스보다 애드테크나 티켓팅 서비스에 더 가까워졌습니다. 이는 실질적인 변화이며, 2024년에 작동하던 스크래핑 라이브러리가 2026년에 들어서 동일한 장벽에 계속 부딪히는 이유를 설명해 줍니다.
이 장벽을 넘어 확장하는 팀들은 스크래퍼 자체를 단일 작업 단위로 생각하지 않습니다. 세션, exit, 중복 제거를 세 가지 별개의 관심사로 분리해 취급하며, 앞의 두 가지는 인프라를 도입하여 해결함으로써 엔지니어가 세 번째 작업에 집중할 수 있도록 합니다. 가장 저렴한 채용 공고 데이터는 플래그 지정 후 다시 수집할 필요가 없는 데이터입니다.