GitHub에서 "linkedin scraper"를 검색하면 2026년 4월 기준으로 대략 가 나옵니다. 그중 대부분은 시간을 낭비하게 만들 가능성이 높아요. 너무 매섭다고요? 그럴 수도 있습니다. 하지만 GitHub에서 눈에 띄는 저장소 8개를 직접 점검하고, 수십 개의 GitHub 이슈 스레드를 읽고, Reddit과 스크래핑 포럼의 커뮤니티 보고까지 대조해본 뒤 얻은 결론이 바로 그렇습니다. 패턴은 늘 비슷해요. 스타 수가 많은 저장소는 관심을 끌고, LinkedIn의 봇 차단 팀은 코드를 분석하고, 탐지 방어가 패치되고, 사용자는 깨진 셀렉터, CAPTCHA 루프, 혹은 계정 차단을 맞게 됩니다. 한 Reddit 사용자는 현재 상황을 단호하게 요약했어요. LinkedIn이 "더 엄격한 속도 제한, 더 나은 봇 탐지, 세션 추적, 잦은 변경"을 도입했고, 예전 도구들은 이제 "금방 깨지거나 계정/IP가 플래그된다"는 거죠. 세일즈 담당자, 리크루터, 운영 관리자가 스프레드시트에 LinkedIn 데이터를 넣고 싶다면, 지난달에 클론한 저장소는 이미 죽어 있을 수도 있습니다. 이 가이드는 어떤 GitHub 프로젝트가 실제로 볼 만한지, 어떻게 하면 계정이 날아가는 일을 피할 수 있는지, 그리고 언제는 코드를 아예 건너뛰는 편이 더 합리적인지 판단하는 데 도움을 주기 위해 만들었습니다.
GitHub의 LinkedIn 스크래퍼란 무엇인가요?
GitHub의 LinkedIn 스크래퍼 프로젝트는 보통 Python, 때로는 Node.js로 작성된 오픈소스 스크립트로, LinkedIn 페이지에서 구조화된 데이터를 자동으로 추출합니다. 대표적인 대상은 다음과 같습니다.
- 사람 프로필: 이름, 헤드라인, 회사, 위치, 기술, 경력
- 채용 공고: 제목, 회사, 위치, 게시일, 채용 URL
- 회사 페이지: 개요, 직원 수, 산업, 팔로워 수
- 게시물과 참여도: 본문 텍스트, 좋아요, 댓글, 공유
내부적으로는 대부분의 저장소가 두 가지 방식 중 하나를 사용합니다. 브라우저 기반 스크래퍼는 Selenium, Playwright, Puppeteer를 사용해 페이지를 렌더링하고, 흐름을 클릭하며, CSS 선택자나 XPath로 데이터를 추출합니다. 일부는 LinkedIn의 내부(문서화되지 않은) API 엔드포인트를 직접 호출하려고 시도하기도 해요. 그리고 GitHub에서는 아직 드물지만 점점 늘고 있는 최신 방식은 브라우저 자동화와 GPT-4o mini 같은 LLM을 결합해, 취약한 셀렉터 없이 페이지 텍스트를 구조화된 필드로 파싱하는 접근입니다.
여기에는 근본적인 사용자층 불일치가 있습니다. 이런 도구는 가상 환경, 브라우저 의존성, 프록시 설정에 익숙한 개발자들이 만들어요. 그런데 "linkedin scraper github"를 검색하는 사람 상당수는 리크루터, SDR, RevOps 관리자, 창업자처럼 스프레드시트에 행만 있으면 되는 경우가 많습니다.
그 격차가 이슈 스레드에 쏟아지는 좌절의 대부분을 설명합니다.
사람들은 왜 LinkedIn 스크래핑을 위해 GitHub를 찾을까요?
이유는 명확합니다. 무료. 커스터마이즈 가능. 벤더 종속 없음. 데이터 파이프라인을 완전히 통제 가능. SaaS 도구가 가격을 바꾸거나 서비스를 종료해도, 코드는 남아 있으니까요.
| 사용 사례 | 필요한 사람 | 일반적으로 추출하는 데이터 |
|---|---|---|
| 리드 생성 | 세일즈 팀 | 이름, 직함, 회사, 프로필 URL, 이메일 단서 |
| 후보자 소싱 | 리크루터 | 프로필, 기술, 경력, 위치 |
| 시장 조사 | 운영 및 전략 팀 | 회사 데이터, 직원 수, 채용 공고 |
| 경쟁 인텔리전스 | 마케팅 팀 | 게시물, 참여도, 회사 업데이트, 채용 신호 |
하지만 "무료"는 라이선스 표기일 뿐, 운영 비용이 아닙니다. 실제 비용은 다음과 같아요.
- 설정 시간: 친절한 저장소라도 환경 설정, 브라우저 의존성, 쿠키 추출, 프록시 구성에 보통 30분~2시간 이상 걸립니다
- 유지보수: LinkedIn은 DOM과 봇 차단 방어를 자주 바꿉니다. 오늘 작동하는 스크래퍼가 다음 주에는 깨질 수 있어요
- 프록시 비용: residential 프록시 대역폭은 제공업체와 요금제에 따라 정도입니다
- 계정 위험: 가장 비싼 자산은 LinkedIn 계정입니다. 프록시 IP처럼 갈아끼울 수 있는 게 아니에요
저장소 건강 점수표: 어떤 LinkedIn 스크래퍼 GitHub 프로젝트든 이렇게 평가하세요
대부분의 "최고의 LinkedIn 스크래퍼" 목록은 스타 수로 저장소를 순위 매깁니다. 하지만 스타 수는 과거의 관심도를 보여줄 뿐, 현재의 동작 여부를 보장하지 않아요. 2022년 이후 커밋이 없는 스타 3,000개짜리 저장소는 프로덕션 도구가 아니라 박물관 전시품입니다.
git clone을 하기 전에 아래 기준을 적용하세요.
| 기준 | 중요한 이유 | 위험 신호 |
|---|---|---|
| 마지막 커밋 날짜 | LinkedIn은 DOM을 자주 바꿈 | 브라우저 기반 저장소에서 6개월 이상 지남 |
| 열려 있는 이슈 / 닫힌 이슈 비율 | 유지보수자의 대응 속도 | 열린 이슈가 닫힌 이슈보다 3:1 이상, 특히 최근에 "blocked"나 "CAPTCHA" 보고가 많음 |
| 탐지 회피 기능 | LinkedIn은 차단을 강하게 시행함 | README에 쿠키, 세션, 속도 조절, 프록시 언급이 없음 |
| 인증 방식 | 2FA와 CAPTCHA가 로그인 흐름을 깨뜨림 | 비밀번호 기반 헤드리스 로그인만 지원 |
| 라이선스 유형 | 상업적 사용 시 법적 노출 | 라이선스가 없거나 조건이 모호함 |
| 지원 데이터 유형 | 사용 사례에 따라 필요한 저장소가 다름 | 여러 데이터가 필요한데 하나만 지원 |
가장 시간을 아껴주는 단 하나의 요령은 이겁니다. 어떤 저장소든 커밋 전에 Issues 탭에서 "blocked", "banned", "CAPTCHA", "not working"을 검색하세요. 최근 이슈가 그런 말들로 가득하고 유지보수자의 응답이 없다면, 그냥 넘어가세요. 그 저장소는 이미 싸움에서 진 겁니다.
2026년 감사에서 실제로 확인된 내용
GitHub에서 가장 눈에 띄는 LinkedIn 스크래퍼 저장소 8개에 이 점수표를 적용해봤습니다. 결과는 기대에 못 미쳤어요.
| 저장소 | 스타 수 | 마지막 커밋 | 2026년에 작동하나? | 주요 범위 | 핵심 메모 |
|---|---|---|---|---|---|
| joeyism/linkedin_scraper | 약 3,983 | 2026년 4월 | ✅ 단, 주의 필요 | 프로필, 회사, 게시물, 채용 | Playwright 기반 재작성, 세션 재사용 — 하지만 최근 이슈에는 보안 차단과 깨진 채용 검색이 보임 |
| python-scrapy-playbook/linkedin-python-scrapy-scraper | 약 111 | 2026년 1월 | ✅ 튜토리얼/공개 데이터용 | 사람, 회사, 채용 | ScrapeOps 프록시 통합; 무료 플랜은 월 1,000 요청, 1개 스레드 허용 |
| spinlud/py-linkedin-jobs-scraper | 약 472 | 2025년 3월 | ⚠️ 채용만 | 채용 | 쿠키 지원, 실험적 프록시 모드 — 공개 채용 공고만 필요하다면 유용 |
| madingess/EasyApplyBot | 약 170 | 2025년 3월 | ⚠️ 잘못된 도구 | Easy Apply 자동화 | 데이터 스크래퍼가 아님 — 채용 지원을 자동화함 |
| linkedtales/scrapedin | 약 611 | 2021년 5월 | ❌ | 프로필 | README에 여전히 "2020년에 작동"이라고 적혀 있음; 이슈에는 핀 검증과 HTML 변경이 보임 |
| austinoboyle/scrape-linkedin-selenium | 약 526 | 2022년 10월 | ❌ | 프로필, 회사 | 예전에는 유용했지만, 2026년 기준으로는 너무 오래됨 |
| eilonmore/linkedin-private-api | 약 291 | 2022년 7월 | ❌ | 프로필, 채용, 회사, 게시물 | 비공개 API 래퍼; 문서화되지 않은 엔드포인트는 예측 불가하게 바뀜 |
| nsandman/linkedin-api | 약 154 | 2019년 7월 | ❌ | 프로필, 메시징, 검색 | 역사적으로 흥미롭지만, 시간당 약 900 요청 이후 속도 제한 경고가 문서화됨 |
2026년 독자가 별도 주의 문구 없이 의미 있게 활용할 수 있어 보인 저장소는 8개 중 2개뿐이었습니다. LinkedIn을 GitHub로 스크래핑할 때는 이런 비율이 오히려 흔합니다.
차단 방지 플레이북: 프록시, 속도 제한, 계정 안전
계정 차단은 가장 큰 운영 리스크입니다. 기술적으로 능숙한 스크래퍼도 여기서 실패해요. 코드는 동작하지만, 계정은 그렇지 않습니다. 사용자들은 프록시와 긴 지연을 써도 만에 플래그가 걸렸다고 보고합니다.
속도 제한: 커뮤니티가 보고하는 내용
절대적으로 안전한 숫자는 없습니다. LinkedIn은 단순 요청량만 보는 게 아니라, 세션 경과 시간, 클릭 간격, 버스트 패턴, IP 평판, 계정 행동을 함께 평가합니다. 커뮤니티 데이터는 대체로 아래 범위에 모입니다.
- 한 사용자는 프록시와 33초 간격에도 40~80개 프로필 이후 탐지가 발생했다고 보고
- 다른 사용자는 계정당 하루 30개 프로필 정도를 권장
- 보다 공격적인 운영자는 하루 전체에 분산해 을 처리했다고 주장
- 는 약 1시간에 900 요청 후 내부 속도 제한 경고를 문서화
실무적으로는 계정당 하루 50개 미만의 프로필 조회가 상대적으로 덜 위험한 구간입니다. 하루 50~100개는 세션 품질이 매우 중요해지는 중간 위험 구간이고, 하루 100개 초과는 점점 더 공격적인 영역입니다.
프록시 전략: residential vs. datacenter
LinkedIn에서는 residential 프록시가 표준입니다. 일반 사용자 트래픽처럼 보이기 때문이에요. Datacenter IP는 더 저렴하지만, 정교한 사이트에서는 더 빨리 플래그가 걸립니다. LinkedIn은 바로 그런 종류의 정교한 사이트죠. 저렴한 트래픽은 금방 눈에 띕니다.
현재 가격 참고:
- : 요금제에 따라 GB당 $3.00–$4.00
- : 요금제에 따라 GB당 $4.00–$6.00
회전은 요청마다 하지 말고 세션마다 하세요. 요청마다 프록시를 바꾸면 어느 IP 하나보다도 더 강하게 "프록시 인프라"라는 흔적이 드러납니다.
버너 계정 운영 원칙
커뮤니티 조언은 이 문제에 대해 아주 직설적입니다. 본인의 주 LinkedIn 계정을 소모성 스크래핑 인프라처럼 다루지 마세요.
계정 기반 스크래핑을 꼭 해야 한다면:
- 주 업무용 본계정과 분리된 계정을 사용하세요
- 프로필을 완전히 채우고, 스크래핑 전에 며칠 동안 사람처럼 행동하게 두세요
- 실제 전화번호를 스크래핑 계정에 절대 연결하지 마세요
- 스크래핑 세션은 실제 아웃리치와 메시징과 완전히 분리하세요
참고로 LinkedIn의 은 2025년 11월 3일 기준으로 허위 신원과 계정 공유를 명시적으로 금지합니다. 버너 계정 전술은 운영상 흔하지만 계약상으로는 깔끔하지 않습니다.
CAPTCHA 처리
CAPTCHA는 단순한 귀찮음이 아닙니다. 이미 세션이 감시 대상이라는 신호예요. 선택지는 다음과 같습니다.
- 수동으로 완료해 세션을 계속 진행
- 로그인 흐름을 매번 다시 돌리지 말고 쿠키 재사용
- 같은 솔버 서비스 사용(이미지 CAPTCHA 1,000개당 약 $0.50–$1.00, reCAPTCHA v2 1,000회 해결당 약 $1.00–$2.99)
하지만 워크플로에서 CAPTCHA가 자주 뜬다면, 솔버 서비스 비용은 가장 작은 문제입니다. 스택이 은밀성 싸움에서 지고 있다는 뜻이니까요.
위험 스펙트럼
| 규모 | 위험 수준 | 권장 접근법 |
|---|---|---|
| 하루 50개 미만 프로필 | 낮음 | 브라우저 세션 또는 쿠키 재사용, 느린 속도 조절, 공격적 자동화 없음 |
| 하루 50~500개 프로필 | 중간~높음 | residential 프록시, 충분히 익은 계정, 세션 재사용, 랜덤 지연 |
| 하루 500개 초과 | 매우 높음 | 상용 API 또는 내장 탐지 회피 기능이 있는 유지관리 도구; 공개 GitHub 저장소만으로는 보통 부족 |
오픈소스의 역설: 왜 인기 있는 LinkedIn 스크래퍼 GitHub 저장소는 더 빨리 깨질까
사용자들이 제기하는 우려는 타당합니다. "오픈소스 버전을 만들면 LinkedIn이 당신이 뭘 하는지 들여다보고 차단해버릴 수 있다"는 거죠. 그 걱정은 편집증이 아니라 구조적으로 맞는 말입니다.
가시성 문제
스타 수가 많다는 건 사용자에게는 신뢰, LinkedIn 보안팀에게는 표적이라는 두 가지 신호를 동시에 보냅니다. 저장소가 인기를 얻을수록, LinkedIn이 그 방식을 직접 겨냥해 막을 가능성도 커집니다.
이 생명주기는 감사 데이터에서도 보입니다. linkedtales/scrapedin은 2020년에 LinkedIn의 "새 웹사이트"에서도 동작한다고 내세울 만큼 눈에 띄었습니다. 하지만 이후의 인증 및 레이아웃 변경을 따라잡지 못했어요. nsandman/linkedin-api는 한때 유용한 요령을 문서화했지만, 마지막 커밋은 현재의 봇 차단 환경보다 한참 전이었습니다.
커뮤니티 패치의 장점
오픈소스의 진짜 장점도 있습니다. 활발한 유지관리자와 기여자들은 LinkedIn이 방어를 바꿀 때 빠르게 패치할 수 있어요. 이번 감사에서 대표적인 예는 joeyism/linkedin_scraper입니다. 여전히 차단된 인증과 깨진 검색 이슈가 나오지만, 적어도 움직이고는 있습니다. 포크는 원본 저장소보다 새로운 회피 기법을 더 빨리 구현하는 경우가 많아요.
어떻게 대응할까?
- 하나의 공개 저장소에 영구 인프라를 맡기지 마세요
- 새 회피 기법을 구현하는 활발한 포크를 지켜보세요
- 프로덕션용으로는 비공개 포크를 유지하는 것도 고려하세요(그래야 여러분만의 적응 방식이 공개되지 않습니다)
- LinkedIn이 탐지나 UI 동작을 바꾸면 방법도 바뀔 거라 예상하세요
- 하나의 도구에 전부 걸기보다 접근 방식을 분산하세요
AI 기반 추출 vs. CSS 셀렉터: 실용 비교
2026년에 더 흥미로운 기술 구분은 GitHub냐 노코드냐가 아닙니다. 셀렉터 기반 추출과 의미 기반 추출의 차이예요. 그리고 이 차이는 대부분의 요약 글이 인정하는 것보다 훨씬 중요합니다.
CSS 셀렉터는 어떻게 동작하고, 왜 깨질까?
전통적인 스크래퍼는 LinkedIn의 DOM을 살펴 각 필드를 CSS 셀렉터나 XPath 표현식에 매핑합니다. 페이지 구조가 안정적일 때는 아주 뛰어납니다. 정확도 높고, 추가 비용이 적고, 파싱도 매우 빨라요.
실패 방식도 분명합니다. LinkedIn이 클래스명, 중첩 구조, 지연 로딩 동작을 바꾸거나, 다른 인증 벽 뒤에 콘텐츠를 가리면 스크래퍼는 즉시 깨집니다. 저장소 감사의 이슈 제목들이 그 이야기를 말해요. "changed HTML", "broken job search", "missing values", "authwall blocks" 같은 것들 말이죠.
AI/LLM 추출은 어떻게 동작할까?
새로운 패턴은 개념적으로 더 단순합니다. 페이지를 렌더링하고, 보이는 텍스트를 모은 다음, 모델에게 구조화된 필드를 내보내라고 요청하는 방식이에요. 많은 노코드 AI 스크래퍼와 몇몇 최신 커스텀 워크플로가 바로 이런 논리를 따릅니다.
현재 을 기준으로 보면($0.15/100만 input 토큰, $0.60/100만 output 토큰), 한 프로필에 대한 텍스트 전용 추출 한 번은 보통 프로필당 $0.0006–$0.0018 정도입니다. 중간 규모 워크플로에서는 사실상 무시해도 될 수준이죠.
정면 비교
| 항목 | CSS 셀렉터 / XPath | AI/LLM 추출 |
|---|---|---|
| 설정 난이도 | 높음 — DOM을 살피고 필드별 셀렉터를 작성해야 함 | 낮음 — 원하는 출력만 자연어로 설명하면 됨 |
| 레이아웃 변경 시 깨짐 | 즉시 깨짐 | 자동 적응(의미를 읽음) |
| 구조화된 필드 정확도 | 셀렉터가 맞으면 약 99% | 약 95~98%(가끔 LLM 해석 오류) |
| 비정형/가변 데이터 처리 | 커스텀 로직 없이는 약함 | 강함 — AI가 문맥을 해석함 |
| 프로필당 비용 | 거의 0원(컴퓨팅 비용만) | 약 $0.001–$0.002(API 토큰 비용) |
| 라벨링/분류 | 별도 후처리 필요 | 한 번에 분류, 번역, 라벨링 가능 |
| 유지보수 부담 | 계속 셀렉터를 고쳐야 함 | 거의 없음 |
무엇을 선택해야 할까?
매우 대규모이고 구조가 안정적이며 엔지니어링 팀이 직접 운영하는 파이프라인이라면, 셀렉터 기반 파싱이 여전히 비용 면에서 유리할 수 있습니다. 하지만 수백 개 수준의 프로필을 스크래핑하는 대부분의 중소 규모 사용자에게는 AI 추출이 장기적으로 더 나은 투자입니다. LinkedIn의 레이아웃 변경에 드는 개발자 시간 비용이, 모델 토큰 비용 절감보다 크기 때문이죠.
GitHub 저장소가 과한 경우: 노코드 경로
"linkedin scraper github"를 검색하는 사람 대부분은 브라우저 자동화 유지보수자가 되고 싶어 하지 않습니다.
원하는 건 표의 행입니다.
사용자들은 GitHub 스크래퍼의 사용성에 대해 이슈 스레드에서 직접 불만을 표합니다. "2FA를 처리하지 못하고, UI도 없어서 사용하기 쉽지 않다"는 식이죠. 대상은 리크루터, SDR, 운영 관리자이지 Python 개발자만이 아닙니다.
직접 만들기 vs. 구매하기
| 요소 | GitHub 저장소 | 노코드 도구(예: Thunderbit) |
|---|---|---|
| 설정 시간 | 30분~2시간 이상(Python, 의존성, 프록시) | 2분 이내(확장 프로그램 설치 후 클릭) |
| 유지보수 | LinkedIn이 바뀌면 직접 수정 | 도구 제공업체가 업데이트 처리 |
| 탐지 회피 | 프록시, 지연, 세션을 직접 설정 | 도구에 내장 |
| 데이터 구조화 | 파싱 로직 직접 작성 | AI가 자동으로 필드 제안 |
| 내보내기 옵션 | 내보내기 파이프라인 직접 구축 | Excel, Google Sheets, Airtable, Notion으로 원클릭 내보내기 |
| 비용 | 무료 저장소 + 프록시 비용 + 내 시간 | 무료 플랜 제공; 대량 사용은 크레딧 기반 |
Thunderbit가 코드 없이 LinkedIn 스크래핑을 처리하는 방식
은 GitHub 저장소와는 다른 방식으로 이 문제를 다룹니다. 셀렉터를 작성하거나 브라우저 자동화를 설정하는 대신 다음처럼 하시면 돼요.
- 을 설치합니다
- LinkedIn의 아무 페이지나 이동합니다(검색 결과, 프로필, 회사 페이지)
- "AI 필드 추천"을 클릭합니다. Thunderbit의 AI가 페이지를 읽고 이름, 직함, 회사, 위치 등의 구조화된 열을 제안합니다
- 필요하면 열을 조정한 뒤 추출을 클릭합니다
- Excel, Google Sheets, , 또는 Notion으로 바로 내보냅니다
Thunderbit는 매번 AI로 페이지를 의미적으로 읽기 때문에, LinkedIn의 DOM이 바뀌어도 쉽게 깨지지 않습니다. 커스텀 Python 스크립트에 GPT를 붙인 방식과 같은 장점이 있지만, 여러분이 직접 유지보수해야 하는 코드베이스가 아니라 노코드 확장 프로그램으로 제공된다는 점이 다릅니다.
— 검색 결과 목록에서 개별 프로필로 들어가 데이터를 보강하는 작업 — 도 Thunderbit가 자동으로 처리합니다. 브라우저 모드는 별도 프록시 설정 없이 로그인 필요한 페이지에서도 작동합니다.
그래도 GitHub 저장소를 써야 하는 경우는?
다음과 같은 경우에는 GitHub 저장소가 여전히 맞을 수 있습니다.
- 깊은 커스터마이징이나 특이한 데이터 유형이 필요한 개발자
- 단가 비용이 중요할 정도로 매우 대량 스크래핑하는 팀
- CI/CD 파이프라인이나 서버에서 스크래핑을 돌려야 하는 사용자
- LinkedIn 데이터를 더 큰 자동화 워크플로에 통합하려는 사람
그 외, 특히 세일즈·리크루팅·운영 팀이라면 가 설정과 유지보수의 전 과정을 없애줍니다.
단계별: GitHub의 LinkedIn 스크래퍼를 평가하고 사용하는 방법
GitHub가 맞는 경로라고 판단했다면, 아래 단계별 워크플로로 시간 낭비와 계정 위험을 줄이세요.
1단계: 저장소 검색 및 후보 추리기
GitHub에서 "linkedin scraper"를 검색하고 다음 기준으로 필터링하세요.
- 최근 업데이트됨(지난 6개월 이내)
- 본인 스택과 맞는 언어(Python이 가장 흔함)
- 실제 필요와 맞는 범위(프로필 vs. 채용 vs. 회사)
살아 있는 것처럼 보이는 저장소 3~5개를 추립니다.
2단계: 저장소 건강 점수표 적용
앞서 소개한 점수표로 각 저장소를 검토하세요. 다음이 있으면 제외합니다.
- 지난 1년간 커밋 없음
- 해결되지 않은 "blocked" 또는 "CAPTCHA" 이슈
- 비밀번호 기반 인증만 지원
- 세션, 쿠키, 프록시 언급 없음
3단계: 환경 설정
이번 감사에서 확인한 일반적인 설정 명령어는 다음과 같습니다.
1pip install linkedin-scraper
2playwright install chromium
3pip install linkedin-jobs-scraper
4LI_AT_COOKIE=<cookie> python your_app.py
5scrapy crawl linkedin_people_profile반복적으로 부딪히는 문제는 다음과 같습니다.
session.json파일 누락- 브라우저 드라이버 버전 불일치(Chromium/Playwright)
- 브라우저 DevTools에서 쿠키 추출
- 프록시 인증 시간 초과
4단계: 작은 테스트 스크래핑 실행
처음엔 10~20개 프로필로 시작하세요. 다음을 확인합니다.
- 필드가 제대로 파싱되는가?
- 데이터가 완전한가?
- 보안 체크포인트에 걸렸는가?
- 출력 형식이 실제로 쓸 만한가, 아니면 원시 JSON 잡음인가?
5단계: 신중하게 확장
랜덤 지연(요청 사이 5~15초), 동시성 축소, 세션 재사용, residential 프록시를 추가하세요. 갓 만든 계정으로 하루에 수백 개 프로필을 바로 시도하지 마세요.
6단계: 데이터 내보내기 및 구조화
대부분의 GitHub 저장소는 원시 JSON 또는 CSV를 출력합니다. 여전히 다음 작업이 필요합니다.
- 중복 레코드 제거
- 직함과 회사명 정규화
- CRM 또는 ATS에 맞게 필드 매핑
- 규정 준수를 위한 데이터 출처 문서화
(Thunderbit는 이 단계를 건너뛰고 싶다면 구조화와 내보내기를 자동으로 처리합니다.)
LinkedIn 스크래퍼 GitHub vs. 노코드 도구: 전체 비교
| 항목 | GitHub 저장소(CSS 셀렉터) | GitHub 저장소(AI/LLM) | 노코드 도구(Thunderbit) |
|---|---|---|---|
| 설정 시간 | 1~2시간 이상 | 1~3시간 이상(+ API 키) | 2분 이내 |
| 기술 숙련도 | 높음(Python, CLI) | 높음(Python + LLM API) | 없음 |
| 유지보수 | 높음(셀렉터가 깨짐) | 중간(LLM은 적응하지만 코드 업데이트는 필요) | 없음(제공업체가 유지) |
| 탐지 회피 | 직접 해결(프록시, 지연) | 직접 해결 | 내장 |
| 정확도 | 작동 시 높음 | 높음, 가끔 LLM 오류 | 높음(AI 기반) |
| 비용 | 무료 + 프록시 비용 + 시간 | 무료 + LLM API 비용 + 프록시 비용 | 무료 플랜; 대량 사용은 크레딧 기반 |
| 내보내기 | 직접 처리(JSON, CSV) | 직접 처리 | Excel, Sheets, Airtable, Notion |
| 가장 적합한 대상 | 개발자, 커스텀 파이프라인 | 유지보수 부담을 줄이고 싶은 개발자 | 세일즈, 리크루팅, 운영 팀 |
법적·윤리적 고려 사항
짧게 다루겠지만, 건너뛰면 안 되는 부분입니다.
LinkedIn의 은 2025년 11월 3일 기준으로 소프트웨어, 스크립트, 로봇, 크롤러, 브라우저 플러그인을 사용해 서비스를 스크래핑하는 것을 명시적으로 금지합니다. LinkedIn은 여기에 집행으로 대응해왔어요.
- : LinkedIn이 Proxycurl에 대해 법적 조치를 취했다고 발표
- : 해당 사건이 해결됐다고 발표
- : Law360는 LinkedIn이 산업 규모 스크래핑과 관련해 추가 피고를 상대로 소송을 제기했다고 보도
hiQ 대 LinkedIn 사건 계열은 공개 데이터 접근에 대해 어느 정도 여지를 만들었지만, 는 계약 위반 이론에서 LinkedIn에 유리했습니다. "공개적으로 보인다"는 것이 "상업적 재사용을 위해 대규모로 스크래핑해도 분명히 안전하다"는 뜻은 아니에요.
EU 관련 워크플로에는 됩니다. 프랑스 데이터 당국의 는 스크래핑한 LinkedIn 데이터를 규제 대상 개인정보로 다루는 예시입니다.
Thunderbit 같은 유지관리형 도구를 쓴다고 해서 법적 의무가 사라지는 건 아닙니다. 다만 보안 대응을 우발적으로 촉발하거나 속도 제한을 위반해 LinkedIn의 주목을 받는 위험은 줄어듭니다.
2026년에 통하는 것과 통하지 않는 것
통하는 것
- 어떤 저장소를 쓰기 전 저장소 건강 점수표를 적용하기
- 반복적인 자동 로그인 대신 쿠키/세션 재사용하기
- 계정 기반 스크래핑이 꼭 필요할 때는 residential 프록시 사용하기
- 더 작고 느리며 사람처럼 보이는 스크래핑 워크플로 사용하기
- 적응성이 토큰의 작은 비용보다 중요할 때 AI 보조 추출 사용하기
- 실제 필요가 스프레드시트 출력이라면 사용하기
- 하나의 공개 저장소에 올인하지 말고 접근 방식을 다양화하기
통하지 않는 것
- 유지보수 상태나 최근 이슈를 확인하지 않고 스타 많은 저장소를 클론하기
- LinkedIn에 datacenter 프록시나 무료 프록시 목록을 사용하기
- 속도 제한이나 탐지 회피 없이 하루 수백 개 프로필로 확장하기
- 유지보수 계획 없이 CSS 셀렉터에 장기 의존하기
- 실제 LinkedIn 계정을 소모성 인프라로 취급하기
- "공개적으로 접근 가능"을 "계약상 또는 법적으로 문제 없다"와 혼동하기
자주 묻는 질문
LinkedIn 스크래퍼 GitHub 저장소는 2026년에도 아직 작동하나요?
일부는 작동하지만, 극히 일부만 그렇습니다. 눈에 띄는 저장소 8개를 감사한 결과, 2026년 독자가 별도 주의 문구 없이 실제로 사용할 만해 보인 건 2개뿐이었습니다. 핵심은 스타 수가 아니라 유지보수 활동과 이슈 상태로 저장소를 평가하는 것입니다. 설정에 시간을 쓰기 전에 저장소 건강 점수표를 사용하세요.
차단되지 않으려면 하루에 LinkedIn 프로필을 몇 개나 스크래핑할 수 있나요?
LinkedIn은 단순량이 아니라 세션 행동을 평가하기 때문에, 확실히 안전한 수치는 없습니다. 커뮤니티 보고에 따르면 계정당 하루 50개 미만은 저위험, 50~100개는 인프라 품질이 중요한 중간 위험, 100개 초과부터는 점점 공격적입니다. 5~15초의 랜덤 지연과 residential 프록시는 도움이 되지만, 위험을 완전히 없애주지는 않습니다.
LinkedIn 스크래퍼 GitHub 프로젝트의 노코드 대안이 있나요?
네. 는 AI 기반 필드 탐지, 브라우저 기반 인증(별도 프록시 설정 불필요), Excel, Google Sheets, Airtable, Notion으로의 원클릭 내보내기를 통해 몇 번의 클릭만으로 LinkedIn 페이지를 스크래핑할 수 있게 해줍니다. 코드를 유지보수하지 않고 데이터를 얻고 싶은 세일즈, 리크루팅, 운영 팀을 위해 설계되었습니다. 에서 사용해볼 수 있어요.
LinkedIn 데이터 스크래핑은 합법인가요?
점점 더 날카로운 경계가 있는 회색지대입니다. LinkedIn의 사용자 계약은 스크래핑을 명시적으로 금지하고 있으며, LinkedIn은 스크래퍼에 대해 법적 조치를 진행했습니다. 공개 데이터 접근에 관한 hiQ 대 LinkedIn 판례는 최근 판결로 범위가 좁아졌습니다. GDPR은 수집 방식과 상관없이 EU 거주자의 개인정보에 적용됩니다. 상업적 사용이라면 구체적인 상황에 맞는 법률 자문을 받으세요.
AI 추출과 CSS 셀렉터 중 무엇을 LinkedIn 스크래핑에 써야 하나요?
CSS 셀렉터는 작동할 때 레코드당 더 빠르고 저렴하지만, LinkedIn이 DOM을 자주 바꾸기 때문에 계속 고쳐야 하는 유지보수 부담이 생깁니다. AI/LLM 추출은 프로필당 비용이 조금 더 들지만(현재 기준 약 $0.001–$0.002), 레이아웃 변경에 자동 적응합니다. 수백 개 수준의 프로필을 스크래핑하는 대부분의 비대기업 사용자에게는 AI 추출이 장기적으로 더 나은 투자예요. Thunderbit의 내장 AI 엔진은 여러분이 코드를 작성하거나 유지보수하지 않아도 이 장점을 제공합니다.
더 알아보기