경쟁사가 어떤 포지션을 채용하고 있는지, 특정 지역의 평균 연봉이 어떻게 변화하는지, 원격 근무 비중이 얼마나 확대되고 있는지 — 이 질문에 답하려면 채용 공고 데이터가 필요합니다. 하지만 Indeed, LinkedIn Jobs, Glassdoor 같은 주요 잡 보드는 강력한 안티봇 시스템을 운영하고 있어, 데이터 수집은 기술적·전략적 도전입니다.
이 가이드에서는 HR-tech 창업자와 인력 분석 팀이 잡 보드 스크래핑 파이프라인을 설계·운영하는 데 필요한 전략적 프레임워크를 제공합니다. 소스 선택, 프록시 전략, 아키텍처 설계, ROI 계산, 법적 고려사항까지 실전 관점에서 다룹니다.
채용 공고 데이터 수집이 어려운 이유
잡 보드는 자사 데이터를 보호하기 위해 다층적 안티봇 방어를 배치합니다. 그 이유는 간단합니다 — 공고 데이터는 잡 보드의 핵심 자산이며, 경쟁 aggregator나 데이터 분석 회사가 무단으로 수집하면 비즈니스 모델이 침식됩니다.
구체적인 방어 수단은 다음과 같습니다:
- Rate limiting & IP 차단: 단일 IP에서 일정 요청 수를 초과하면 CAPTCHA를 띄우거나 차단
- 브라우저 핑거프린팅: headless 브라우저 탐지(TLS fingerprint, canvas fingerprint, WebDriver 속성)
- 로그인 월: LinkedIn Jobs는 로그인해야 전체 공고 열람 가능
- 동적 렌더링: JavaScript로 콘텐츠를 동적 로드하여 단순 HTTP 요청 차단
이 때문에 적절한 프록시 인프라 없이는 대규모 데이터 수집이 사실상 불가능합니다. 특히 LinkedIn과 Indeed는 업계에서 가장 공격적인 안티봇 시스템을 운영하는 것으로 알려져 있습니다.
주요 잡 보드 및 수집 가능 데이터
글로벌 소스
대부분의 HR-tech 팀이 우선적으로 타겟하는 글로벌 잡 보드와 각 소스의 특성을 정리합니다.
| 잡 보드 | 월간 공고 규모(추정) | 안티봇 강도 | 추천 프록시 | 비고 |
|---|---|---|---|---|
| Indeed | 수천만 건 | 높음 | Residential | Cloudflare + 커스텀 봇 탐지 |
| LinkedIn Jobs | 수백만 건 | 매우 높음 | Residential / Mobile | 로그인 필수, 행동 기반 탐지 |
| Glassdoor | 수백만 건 | 높음 | Residential | 리뷰 + 공고 혼합 구조 |
| Monster | 수십만 건 | 중간 | Datacenter 가능 | 비교적 관대한 편 |
| ZipRecruiter | 수백만 건 | 중간 | Datacenter 가능 | API 접근 옵션 존재 |
지역 리더
- Xing(독일): DACH 지역 전문, LinkedIn보다 안티봟이 상대적으로 약하지만 로그인 필요한 영역 존재
- Naukri(인도): 인도 취업 시장의 70%+ 점유, 중간 수준 안티봇
- StepStone(유럽): 독일·프랑스·영국 커버, Cloudflare 배포
- Seek(호주): 호주·뉴질랜드 시장, 중간 안티봟
- Liepin·BOSS Zhipin(중국): 중국 시장, 강력한 안티봇 + 로그인 월
수집 가능 데이터 필드
대부분의 잡 보드에서 공통적으로 수집 가능한 필드:
- 직무 제목 (job title)
- 회사명 (company)
- 근무지 (location) — 도시, 주/도, 국가
- 공고 본문 (description) — HTML 또는 플레인 텍스트
- 급여 정보 (salary) — 공개 시에만, 약 30-40% 공고에 포함
- 게시일 (posting date)
- 시니어리티 (seniority level) — entry, mid, senior, lead 등
- 원격 근무 여부 (remote status) — remote, hybrid, on-site
- 고용 형태 (employment type) — full-time, part-time, contract
급여 정보는 소스 간 편차가 큽니다. Indeed는 급여 범위를 비교적 자주 표시하지만, LinkedIn은 약 20% 공고에만 포함됩니다. 이 필드의 누락률은 보간 모델 설계 시 핵심 고려사항입니다.
프록시 선택 전략: 소스별 차별화 접근
모든 잡 보드에 동일한 프록시를 적용하면 비효율적입니다. 안티봇 강도에 따라 프록시 타입을 달리해야 비용과 성공률의 균형을 맞출 수 있습니다.
Residential 프록시: LinkedIn, Indeed, Glassdoor
이 세 소스는 실제 사용자 트래픽과 봇 트래픽을 정교하게 구분합니다. Datacenter IP는 거의 즉시 차단되며, CAPTCHA 해제 비용만 누적됩니다.
Residential 프록시의 핵심 장점:
- ISP가 할당한 실제 IP로, 잡 보드 입장에서 일반 사용자와 구분 어려움
- 지역 타겟팅이 가능해 지역별 공고 수집에 유리
- 세션 스티키 기능으로 로그인 상태 유지 가능
ProxyHat Residential 프록시 설정 예시:
# 미국 IP로 Indeed 스크래핑 - HTTP 프록시export HTTP_PROXY="http://user-country-US:password@gate.proxyhat.com:8080"
# 독일 IP로 Xing 스크래핑 - 스티키 세션export HTTP_PROXY="http://user-country-DE-session-xing01:password@gate.proxyhat.com:8080"Datacenter 프록시: Monster, ZipRecruiter, 지역 소스
안티봇이 상대적으로 약한 소스는 Datacenter 프록시로도 충분합니다. 비용이 Residential의 1/5~1/10 수준이므로, 대규모 수집에 경제적 이점이 큽니다.
Mobile 프록시: 최강 안티봟 돌파
LinkedIn의 모바일 웹 버전은 데스크톱보다 안티봇이 약간 느슨한 편입니다. Mobile 프록시로 접근하면 성공률을 높일 수 있지만, 비용이 가장 높으므로 LinkedIn 전용으로 제한적으로 사용하는 것이 현명합니다.
프록시 타입별 비용-성공률 매트릭스
| 프록시 타입 | GB당 비용(추정) | Indeed 성공률 | LinkedIn 성공률 | Monster 성공률 |
|---|---|---|---|---|
| Datacenter | $0.5-1 | 10-20% | <5% | 80-90% |
| Residential | $5-15 | 85-95% | 70-85% | 95%+ |
| Mobile | $15-30 | 95%+ | 85-95% | 95%+ |
결론: LinkedIn과 Indeed에는 Residential, 나머지는 Datacenter로 시작하고, 성공률 모니터링 후 필요 시 업그레이드하는 점진적 접근이 비용 효율적입니다.
아키텍처 설계: 확장 가능한 스크래핑 파이프라인
다중 소스 채용 공고 수집 시스템의 핵심 과제는 정규화와 중복 제거입니다. 각 소스의 스키마와 포맷이 다르기 때문에, 원시 데이터를 그대로 사용하면 분석이 불가능합니다.
원칙: 소스당 하나의 스크래퍼
모든 잡 보드를 하나의 스크래퍼로 처리하려는 유혹을 피하세요. 각 소스는 고유한 HTML 구조, 안티봇 대응 로직, 렌더링 방식을 가집니다. 소스당 독립 스크래퍼를 운영하면:
- 한 소스의 구조 변경이 다른 소스에 영향을 주지 않음
- 소스별로 다른 프록시 타입과 rate limit 적용 가능
- 장애 격리(failure isolation)가 보장됨
정규화 레이어
모든 스크래퍼의 출력을 공통 스키마로 변환하는 정규화 레이어가 필요합니다:
- 직무 제목 정규화: "Sr. Software Engineer" ↔ "Senior Software Eng." ↔ "SWE (Senior)" → 표준 직무 분류 코드(예: O*NET SOC 코드)로 매핑
- 위치 정규화: "NYC" ↔ "New York City, NY" → ISO 3166-2 코드로 통일
- 급여 정규화: 시급/연봉/월급, 통화 단위, 범위 → 연봉 USD 기준 중간값
- 시니어리티 매핑: 각 소스의 라벨을 Entry/Mid/Senior/Lead/Executive 5단계로 통일
중복 제거 전략
같은 공고가 Indeed와 LinkedIn에 동시 게재되는 경우가 빈번합니다. 중복 제거 없이는 공고 수 카운트가 30-50% 과대 산정됩니다.
추천 중복 제거 로직:
- 1차 — 해시 기반: (회사명 정규화 + 직무제목 정규화 + 도시) 조합으로 fuzzy hash 생성
- 2차 — 본문 유사도: 공고 본문의 Jaccard similarity가 0.85 이상이면 동일 공고로 판단
- 3차 — 수동 검토: 임계값 경계 케이스는 대시보드에서 수동 리뷰
안티봇 핸들링: 소스별 전략
- Indeed: 요청 간 3-8초 랜덤 지연, 검색 결과 페이지는 최대 10페이지까지만 순차 접근, CAPTCHA 발생 시 해당 IP 세션 폐기 후 새 세션으로 교체
- LinkedIn: 로그인 세션당 시간당 80-120개 공고로 제한, 스크롤 시뮬레이션 필수, 프로필 접근 절대 금지(계정 정지 위험)
- Glassdoor: 검색 API 대신 페이지네이션 URL 직접 구성, 급여 데이터는 별도 엔드포인트에서 수집
공통 원칙: 성공률 모니터링을 실시간으로 수행하고, 특정 소스의 성공률이 70% 이하로 떨어지면 자동으로 rate를 낮추고 프록시 풀을 교체하는 자동 복구 메커니즘을 구현하세요.
실제 유스케이스와 ROI 계산
유스케이스 1: 노동시장 인텔리전스 플랫폼
HR-tech 스타트업 A사는 미국 기술 직군의 노동시장 대시보드를 구축합니다. 8개 잡 보드에서 주 200만 건의 공고를 수집합니다.
비용 구조(월간):
- Residential 프록시(Indeed + LinkedIn + Glassdoor): 약 $2,500
- Datacenter 프록시(Monster + ZipRecruiter + 기타): 약 $200
- 인프라(스토리지, 컴퓨팅): 약 $800
- 개발/유지보수 인건비: 약 $8,000
총 월비용: ~$11,500
수익: B2B SaaS 구독 기업 45개사 × 월 $500 평균 = 월 $22,500
ROI: (22,500 - 11,500) / 11,500 = 95.6% — 첫해부터 흑자 가능
유스케이스 2: 경쟁사 채용 시그널 모니터링
PE 펀드의 due diligence 팀이 타겟 기업의 채용 패턴을 분석합니다. 특정 기업명으로 필터링하여, 어느 부서에서 어떤 역할을 채용 중인지 추적합니다.
핵심 인사이트 예시:
기업 X가 최근 3개월간 AI/ML 엔지니어 채용을 400% 증가시켰고, 동시에 하드웨어 엔지니어 채용은 60% 감소 → 전략적 방향 전환 시그널
이 유스케이스는 전체 공고 수집이 아닌 타겟 기업 필터링이므로 데이터 볼륨이 작고, Datacenter 프록시로도 충분한 경우가 많습니다.
유스케이스 3: 급여 벤치마킹
보상 컨설팅 firm이 직무-지역-시니어리티 교차 테이블로 급여 분포를 구축합니다. 급여 데이터가 포함된 공고 비율이 낮기 때문에, 대량 수집 후 보간 모델이 필요합니다.
유스케이스 4: 잡 어그리게이터 비즈니스
직접적인 잡 보드 경쟁 서비스를 구축하려면, 실시간 수집과 중복 제거가 핵심 경쟁력입니다. 이 경우 데이터 신선도가 수익에 직결되므로, 프록시 비용을 아끼면 안 됩니다.
법적 고려사항: TOS, GDPR, 그리고 경계선
이용약관(TOS) 리스크
대부분의 잡 보드 TOS는 스크래핑을 명시적으로 금지합니다. 하지만 TOS 위반이 곧 불법은 아닙니다(미국 법원 판례: hiQ Labs v. LinkedIn — 공개 데이터 스크래핑은 CFAA 위반이 아니다). 그러나:
- 계정을 만들고 로그인한 상태에서 스크래핑하면 TOS 계약 위반이 됨
- CFAA(미국), Computer Misuse Act(영국) 등의 법률 under which 무단 접속 혐의 가능
- EU에서는 데이터베이스 권리(database right)가 존재하여, 대량 추출 자체가 권리 침해 가능
실무 권고: 공개 접근 가능한 페이지만 수집하고, 로그인이 필요한 영역은 피하세요. 로그인 영역의 데이터가 꼭 필요하다면 공식 API나 파트너십을 먼저 탐색하세요.
GDPR과 후보자 데이터
이 가이드의 범위는 채용 공고 수집이며, 후보자 프로필 수집은 다루지 않습니다. 이 구분이 중요한 이유:
- 채용 공고는 기업이 게시한 것으로, 개인 데이터가 아님
- 후보자 프로필(이력서, 연락처)은 GDPR 상 개인 데이터이며, 합법적 근거 없이 수집하면 최대 매출 4% 또는 €2천만 벌금
공고 내에 포함된 채용 담당자 이름이나 이메일은 개인 데이터에 해당할 수 있으므로, 수집 시 해당 필드를 마스킹하거나 제외하는 것이 안전합니다.
robots.txt 준수
법적 구속력은 약하지만, robots.txt를 존중하는 것은 좋은 실무입니다. 특히 EU 투명성 규정 하에서는 robots.txt 준수 여부가 "선의"의 증거로 작용할 수 있습니다.
Build vs. Buy: 인프라 결정 프레임워크
스크래핑 인프라를 자체 구축할지, 서드파티 데이터 제공업체를 사용할지는 초기 전략 결정입니다.
| 기준 | 자체 구축(Build) | 서드파티 구매(Buy) |
|---|---|---|
| 초기 비용 | 높음 ($20K-50K) | 낮음 ($2K-10K/월) |
| 데이터 제어권 | 완전 | 제한적(제공업체 스키마 따름) |
| 데이터 신선도 | 실시간 가능 | 일/주 단위 업데이트가 보통 |
| 유지보수 부담 | 높음(소스 구조 변경 대응) | 낮음(제공업체 책임) |
| 확장성 | 소스 추가 시 개발 필요 | 제공업체 커버리지에 의존 |
| 경쟁 우위 | 독점적 데이터 파이프라인 가능 | 경쟁사도 동일 데이터 접근 가능 |
권장 접근: 초기에는 서드파티로 빠르게 검증(MVP)하고, 데이터가 핵심 경쟁우위라면 자체 구축으로 전환하세요. 혼합 모델(핵심 소스 자체 + 보조 소스 구매)도 효과적입니다.
프록시 운영 Best Practices
- 프록시 풀 회전: 동일 IP로 연속 요청하지 마세요. ProxyHat의 국가별 라우팅으로 자연스러운 지역 분산을 구현합니다
- 요청 패턴 인간화: 고정 간격이 아닌 랜덤 지연(2-8초)을 적용하세요
- User-Agent 로테이션: 최신 Chrome/Firefox UA 문자열을 순환 적용
- 성공률 대시보드: 소스별 성공률, 평균 응답 시간, CAPTCHA 발생률을 실시간 모니터링
- 비용 알림: 프록시 대역폭 비용이 일일 임계값 초과 시 알림 설정
ProxyHat으로 글로벌 잡 보드 스크래핑을 구성하는 기본 패턴:
# Python - requests + ProxyHat residential proxy
import requests
proxy = "http://user-country-US:password@gate.proxyhat.com:8080"
proxies = {"http": proxy, "https": proxy}
headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"}
resp = requests.get("https://www.indeed.com/jobs?q=software+engineer&l=New+York",
proxies=proxies, headers=headers, timeout=30)
print(f"Status: {resp.status_code}, Length: {len(resp.text)}")핵심 요약
Key Takeaways
- 잡 보드 스크래핑은 소스별 안티봇 강도에 따라 프록시 타입을 차별화하세요 — LinkedIn/Indeed는 Residential, 나머지는 Datacenter
- 소스당 독립 스크래퍼 + 공통 정규화 레이어 + 중복 제거 파이프라인이 확장 가능한 아키텍처의 핵심
- 급여 데이터는 약 30-40% 공고에만 포함되므로, 보간 모델 설계가 필수
- 공개 페이지만 수집하고, 후보자 프로필은 절대 수집하지 마세요 — GDPR 리스크가 매우 큽니다
- Build vs. Buy는 데이터가 핵심 경쟁우위인지에 따라 결정하세요 — 혼합 모델도 유효
- 성공률 모니터링과 자동 복구 메커니즘 없이는 프로덕션 운영이 불가능합니다
채용 공고 데이터는 노동시장 인텔리전스의 원천입니다. 올바른 프록시 전략과 아키텍처로 무장하면, 경쟁사보다 빠르고 정확한 인사이트를 확보할 수 있습니다.
ProxyHat의 글로벌 프록시 로케이션과 유연한 요금제로 잡 보드 스크래핑 인프라를 시작하세요. 추가적인 스크래핑 전략은 웹 스크래핑 모범 사례 가이드에서 확인할 수 있습니다.
