내가 아는 창업자라면 누구나 한 번쯤은 ‘검증된’ 연락처 1만 개짜리 리스트를 사 놓고도 답장률이 사실상 0%에 머무르는 걸 본 적이 있다. 나도 커리어 초반에 똑같은 실수를 했고, 그 경험 덕분에 빨리 깨달은 게 하나 있었다. 이메일이 아무리 많아도 그 자체로는 파이프라인이 되지 않는다는 사실이다. 실제로 딜을 움직이는 건 어떤 회사가 대화할 가치가 있는지, 그리고 왜 그런지를 아는 일이다. 이건 인터넷에서 이름만 긁어오는 것과는 완전히 다른 문제다.
웹 스크래핑은 흔히 “금요일까지 리드 1만 개 뽑기” 같은 지름길로 소개되지만, 2026년에 실제로 성과를 내는 도구들은 훨씬 더 실용적인 목적을 위해 만들어졌다. 바로 진짜 구매 신호가 보이는 시점에, 실제 근거가 붙은 유효한 계정을 찾아내는 것이다. Thunderbit에서 사람들이 세일즈용 데이터를 어떻게 스크래핑하는지 오래 고민해 왔는데, 가장 좋은 결과를 내는 팀들은 행(row)을 가장 많이 긁는 팀이 아니라, 맥락이 붙은 올바른 행을 긁는 팀이었다.
웹 스크래핑으로 B2B 리드를 찾는다는 건 정확히 무슨 뜻일까?
대부분의 사람들은 “리드를 스크래핑한다”는 말을 들으면, 디렉터리 페이지를 긁어와 이름, 직함, 이메일이 들어 있는 CSV를 뱉어내는 도구를 떠올린다. 하지만 그건 리드 생성이 아니라 연락처 수집이다. 그리고 많은 세일즈 팀이 반송률은 높고 전환율은 낮은 리스트를 떠안게 되는 이유가 바로 여기에 있다.
진짜 리드 기록에는 이름만으로는 부족하다. 회사명과 표준 도메인을 포함한 계정 식별 정보, 그 회사가 정말 이상적인 고객 프로필에 맞는지 보여주는 근거, 왜 지금 연락해야 하는지를 설명하는 시점이 찍힌 신호, 허용된 연락 방법, 데이터 출처 기록, 나중에 다시 검토할 수 있는 상태 값이 필요하다. 말은 길지만 핵심은 단순하다. 공개적으로 허용된 출처에서 시작해, 회사의 정체성을 확인하고, 적합성 근거를 모으고, 트리거 이벤트를 기록하고, 최소한의 연락 경로를 찾고, 검증하고, 중복 제거한 뒤 CRM으로 보내는 순서다. 한 단계라도 건너뛰면 결국 모두가 싫어하는 것, 즉 낯선 사람들 이름만 잔뜩 적힌 스프레드시트가 남는다.
왜 지금 이게 더 중요해졌을까
AI 덕분에 스크래핑은 시작하기는 엄청 쉬워졌고, 동시에 대규모로 엉망으로 만들기도 훨씬 쉬워졌다. 몇 년 전만 해도 스크래퍼를 만들려면 개발자를 고용하거나 주말 내내 XPath 셀렉터와 씨름해야 했다. 지금은 누구나 AI 스크래퍼를 페이지에 올려 몇 분 만에 구조화된 데이터를 얻을 수 있다. 생산성 면에서는 훌륭하지만, 그만큼 더 많은 세일즈 팀이 검증되지 않은 부적격 데이터를 CRM에 빠르게 쏟아붓고 있다는 뜻이기도 하다. 나중에 이를 정리하는 데 드는 비용은 처음부터 제대로 하는 것보다 훨씬 크다.
동시에, 도구가 똑똑해졌다고 해서 규제 환경까지 달라진 것은 아니다. 영국의 개인정보감독기구(ICO)는 공개된 비즈니스 연락처 데이터라도 여전히 UK GDPR의 적용을 받을 수 있다고 분명히 밝히고 있으며, B2B 상황이라도 직접 마케팅에 대한 이의 제기는 반드시 존중해야 한다고 한다. 미국에서도 FTC의 CAN-SPAM 가이던스는 B2B 이메일이라고 예외를 두지 않는다. 모든 상업성 메시지는 정확한 헤더, 작동하는 수신 거부 기능, 그리고 10영업일 이내의 수신 거부 반영이 필요하다. 이건 보기 드문 법률 잡학이 아니라, 알고 있든 모르고 있든 당신이 따라야 하는 기본 기준이다.
시작하기 전에: 분위기와 이용약관부터 읽자
솔직히 말하자면, 아무리 스크래퍼가 좋아도 모든 사이트가 대상이 될 수 있는 건 아니다. Google Maps의 이용약관은 Maps 콘텐츠의 내보내기나 대량 스크래핑을 명시적으로 금지한다. LinkedIn의 사용자 계약은 스크래핑과 무단 자동화를 아예 금지한다. Clutch의 현재 약관도 수동이든 자동이든 스크래핑을 금지한다. 이런 조항은 숨겨진 문구가 아니라, 어떤 도구를 사이트에 적용하기 전에 가장 먼저 확인해야 할 내용이다. 이 주제는 특히 LinkedIn 스크래핑과 관련해 자주 나와서, 나는 따로 더 자세히 다룬 적도 있다.
robots.txt는 이해할 가치는 있지만, 그것만으로 법적 허가가 된다고 보면 안 된다. IETF 자체 명세에 따르면, robots.txt는 크롤링 지침이지 허가 시스템이나 접근 통제 장치가 아니다. 어떤 사이트는 robots.txt에서는 크롤링을 허용하더라도, 이용약관에서는 스크래핑을 금지할 수 있고, 분쟁이 생기면 보통 이용약관이 우선한다. 내 기준은 이렇다. 데이터 확인을 위해 로그인이 필요하거나, CAPTCHA가 앞을 막고 있거나, 약관 어디엔가 “no scraping”이라고 명시돼 있다면 그건 풀어야 할 퍼즐이 아니라 건너뛰어야 할 소스다.
B2B 리서치에 비교적 안전하고 유용한 공개 소스는 회사 웹사이트, 정부 공시, 허용된 참가사·파트너 디렉터리, 채용 페이지, 뉴스룸 등이 있다. 예를 들어 SEC의 EDGAR API는 API 키 없이도 무료 공개 JSON 공시와 XBRL 데이터를 제공한다. 단, SEC의 속도 제한 안내에 맞춰 자동 요청을 초당 10건 이하로 유지해야 한다.
전체 파이프라인: 원본 스크랩에서 CRM 준비 완료 리드까지
내가 실제로 추천하는 순서는 다음과 같다. ‘스크래핑’이라기보다, 스크래퍼를 중심에 둔 작은 리서치 프로세스에 가깝다.
첫째, 허용된 공개 소스를 하나 고르고 조직 단위 필드만 가져온다. 회사명, 도메인, 소스 URL, 카테고리, 위치, 그리고 처음 관심을 갖게 만든 신호(채용 공고, 보도자료, 행사 목록 등)만 수집한다. 둘째, 가능성이 있어 보이는 계정은 실제 웹사이트로 가서 그 회사가 무엇을 하는지, 어디에 본사가 있는지, 공개된 연락 경로가 무엇인지 확인한다. 셋째, 이미 자격 기준을 통과한 계정에만 검증과 보강을 적용한다. 아직 검증도 안 된 회사에 보강 비용을 낭비할 필요는 없다. 넷째, CRM에 넣기 전에 기존 데이터와 중복 여부를 확인한다. 다섯째, 세일즈 팀이 무엇이 검토 완료인지, 무엇을 더 봐야 하는지 알 수 있도록 상태 필드를 붙여 넣는다.
마지막 단계는 사람들이 생각하는 것보다 훨씬 중요하다. 나는 candidate_account, qualified_account, contact_ready, needs_review, rejected 같은 식으로 모든 레코드를 태깅하길 권한다. SDR 팀이 “이 회사가 우리 ICP에 맞는지 누가 실제로 확인했나요?”라고 물을 때, 어깨를 으쓱하는 대신 답을 줄 수 있다면 그 태그들은 전혀 과하지 않다.
고신호 B2B 계정은 어디서 찾을까
좋은 신호는 숨어 있는 게 아니라, 대부분의 팀이 체계적으로 확인하지 않을 뿐 여기저기 흩어져 있다. 회사 채용 페이지는 누가 어떤 포지션을 뽑고 있는지 보여주고, 이는 그 회사가 어디에 투자하고 있는지를 짐작하게 해 주는 꽤 괜찮은 지표다. 뉴스룸과 보도자료는 투자 유치, 확장, 제품 출시 소식을 알려준다. 파트너·참가사 페이지(스크래핑이 허용되는 경우)는 특정 생태계에서 누가 활발히 움직이는지 보여준다. 공시 자료는 특히 대기업일수록, 링크드인 게시물로는 절대 얻을 수 없는 방식으로 재무 상태와 전략 우선순위를 드러낸다.
이런 신호 하나만으로 구매 의도를 증명할 수는 없다. “VP of Sales” 채용 공고가 있다고 해서 내일 당장 당신 제품을 살 준비가 됐다는 뜻은 아니기 때문이다. 하지만 이런 신호를 함께 보고, 자사 ICP 기준과 대조하면, 6개월 전에 사서 이미 20%쯤 낡아버린 리드 마켓플레이스 리스트보다 훨씬 좋은 필터가 된다.
AI 기반 스크래핑이 계산을 어떻게 바꾸는가
여기서부터는 내가 5~6년 전 하던 스크래핑과 정말 달라진다. 예전 방식은 페이지 레이아웃마다 셀렉터를 일일이 작성해야 했고, 사이트가 HTML을 조금만 바꿔도 스크래퍼가 바로 깨졌다. 반면 AI 기반 스크래핑 도구는 사람처럼 페이지를 읽는다. CSS 경로에 매달리는 대신, 문맥을 보고 “이건 회사명, 이건 위치, 이건 직함”이라고 이해한다.
이 변화 덕분에 Thunderbit 같은 도구는 리스트 페이지를 보고도 AI Suggest Fields로 적절한 열을 자동 제안할 수 있고, 사용자가 모든 필드를 손으로 매핑할 필요가 없다. 원하는 내용을 그냥 영어로 입력해도 된다. 예를 들어 “회사명, 웹사이트, 업종, 위치를 가져와”라고 하면 AI가 알아서 추출 방법을 정리해 준다. 예전에는 사이트 하나 설정하는 데 반나절씩 쓰던 팀들이 이제는 몇 번의 클릭과 검토만으로 끝낸다. 이게 규정이 바뀌어서가 아니다. 규정은 그대로다. 단지 제대로 하려면 넘어야 했던 기술 장벽이 크게 낮아졌기 때문이다. 이 변화가 더 넓은 AI 스크래핑 시장에서 어떻게 작동하는지 더 보고 싶다면, AI 웹 스크래핑과 기존 규칙 기반 방식의 차이를 정리한 글도 참고할 만하다.
하위 페이지 문제: 리스트 페이지만으로는 왜 절반도 못 가는가
초반에 거의 সবাই 걸리는 함정이 하나 있다. 리스트 페이지가 전부가 아니라는 점이다. 디렉터리 페이지는 회사명과 링크 정도만 주고 끝나는 경우가 많지만, 실제로 필요한 근거 — 회사가 무엇을 하는지, 본사가 어디인지, 어떤 산업을 상대하는지 — 는 보통 한 번 더 들어가야 나오는 회사 상세 페이지나 웹사이트에 있다.
디렉터리에서 수백 개 행을 스크랩해 놓고, 나중에 보니 절반의 “리드”에서 자격 판단에 가장 중요한 필드가 빠져 있었다는 사례를 정말 많이 봤다. 바로 이 때문에 하위 페이지 스크래핑은 있으면 좋은 옵션이 아니라, 하나의 기능 카테고리로 존재한다. 좋은 스크래퍼는 리스트 페이지에서 회사별 상세 페이지 링크를 가져온 다음, 그 링크를 자동으로 따라가 더 깊은 필드를 추출하고, 모든 정보를 하나의 깔끔한 행으로 합칠 수 있어야 한다. 이 단계를 빼면, 회사명 하나와 추측만으로 리드를 평가하게 된다.
단계별 가이드: Thunderbit으로 B2B 리드 찾기
실제로 내가 타깃 디렉터리와 커피 한 잔 앞에 두고 앉아 있다면 이렇게 진행할 것이다.
1단계: Thunderbit 설치 후 타깃 디렉터리 열기
Thunderbit Chrome Extension을 설치하고, 허용된 공개 소스로 이동한다. 참가사 목록, 업계 디렉터리, 채용 게시판 등 ICP에 맞는 곳이면 된다. 더 진행하기 전에 해당 사이트 이용약관이 이런 용도를 허용하는지 확인하자. 이 단계는 2분이면 끝나고, 나중에 골치 아플 일을 줄여 준다.
2단계: “AI Suggest Fields” 클릭하기
페이지를 일일이 클릭해서 열을 정의하는 대신, AI가 페이지 구조를 보고 회사명, 웹사이트, 위치, 카테고리 같은 필드를 제안하도록 하자. 필요하면 직접 수정하거나 새 항목을 추가할 수 있다. 예를 들어 “이 회사가 제공하는 산업군을 추출해 줘” 같은 자연어 지시도 잘 먹힌다.
3단계: 스크래핑 실행하기
추출을 시작하고, 리스트 페이지 전체와 여러 페이지로 구성된 디렉터리라면 페이지네이션까지 돌리자. 이것은 ‘원본’ 수집 단계다. 아직 개인 연락처로 볼 만한 것은 아니라는 뜻이다.
4단계: 하위 페이지 스크래핑으로 보강하기
가능성이 높은 행에는 하위 페이지 스크래핑을 적용해 회사 사이트나 상세 페이지로 들어가고, 무엇을 하는지, 어디에 기반을 두는지, 공개된 연락 경로가 있는지 같은 더 깊은 필드를 가져오자. 이 단계가 있어야 단순한 디렉터리 행이 실제로 자격을 갖춘 계정 레코드로 바뀐다.
5단계: 검증하고 정리하기
CRM에 넣기 전에 샘플을 직접 확인한다. 도메인이 실제로 열리는지, 자격 판단 근거가 정말 맞는지, 애매한 항목은 추측하지 말고 needs_review로 표시한다. 합법적인 공개 연락 경로를 찾았다면 Hunter 같은 서비스로 이메일 검증을 돌릴 수도 있다. 다만 “유효한 이메일”이 곧 그 사람에게 마케팅해도 된다는 동의는 아니라는 점은 잊지 말자.
6단계: 내보내기 후 CRM에 반영하기
Thunderbit은 CSV, Excel, Google Sheets, Airtable, Notion 같은 형식으로 무료 내보내기를 지원한다. HubSpot이나 Salesforce로 가져가기 전에, 회사의 기본 키는 회사명보다 도메인으로 정규화하자. HubSpot의 가져오기 가이드도 회사는 도메인, 연락처는 이메일을 기준으로 삼으라고 권장한다. Salesforce도 중복 규칙 때문에, 이를 무시하면 가져오기가 조용히 차단되거나 플래그될 수 있다. 전체 가져오기 전에 20~30행 정도의 테스트 배치를 돌려보는 것만으로도, 나중에 더 지저분한 정리를 막은 적이 여러 번 있다.
팁과 흔한 함정
이 과정을 지금 시작하는 사람에게 꼭 해 주고 싶은 말이 몇 가지 있다. 스크랩한 직함이나 역할을 곧바로 구매 의도의 증거로 보지 말자. 그것은 힌트일 뿐, 초록불이 아니다. AI가 뽑아낸 필드라고 해서 자동으로 맞는 것은 아니다. 규모를 키우기 전에 샘플을 꼭 확인하자. B2B라고 해서 개인 데이터가 개인정보 규제를 자동으로 비껴가는 것은 아니므로, 이름이 있는 연락처와 직접 이메일은 회사 단위 리서치와는 별도로 더 엄격하게 관리되는 데이터 영역에 두자. 그리고 “도구가 기술적으로 가능하다”는 말이 곧 당신의 컴플라이언스 정책이 되게 두지 말자. 첫 번째가 아니라 매번, 소스의 약관을 확인해야 한다.
웹 스크래핑 vs 리드 데이터베이스 구매
두 방식 모두 쓰임새가 있고, 하나가 무조건 더 낫다고 말하는 건 조금 불성실하다.
| 항목 | 웹 스크래핑(허용된 소스) | 리드 데이터베이스 구매 |
|---|---|---|
| 최신성 | 마지막 스크래핑 시점만큼 최신 | 몇 주 만에 낡는 경우가 많음 |
| 신호 품질 | 높음 — 트리거와 맥락을 직접 통제 가능 | 낮음 — 보통 정적인 기업 속성 데이터에 그침 |
| 커버리지 범위 | 더 좁지만 소스에 따라 맞춤 가능 | 더 넓고 표준화되어 있음 |
| 비용 구조 | 주로 시간 + 도구 구독료 | 레코드당 또는 좌석당 지속 비용 |
| 컴플라이언스 리스크 | 소스와 필드를 신중히 고르면 관리 가능 | 공급자의 데이터 수집 방식에 크게 좌우됨 |
| 적합한 용도 | 타깃이 분명하고 신호 기반의 아웃바운드 | 시장 전반 매핑, 초기 TAM 산정 |
내 솔직한 생각은 이렇다. 맥락과 타이밍이 필요하면 스크래핑하자. 특정 행사 참가사 리스트, 경쟁사의 새로 출시된 제품 페이지, 방금 세일즈 채용 공고를 세 개 올린 회사처럼 말이다. 반대로 넓고 표준화된 커버리지가 필요하고, 최신성 검증을 직접 할 의향이 있다면 Apollo 같은 구매형 또는 보강형 제공자를 쓰자. 둘은 서로 배타적이지 않다. 많은 팀이 신호는 스크래핑으로 잡고, 자격을 통과한 계정은 나중에 보강하는 방식으로 두 방법을 함께 쓴다.
현실적인 사례
예를 들어 당신이 차량 관리 소프트웨어를 판매하고 있고, 성장 중인 물류 회사를 찾고 싶다고 하자. 주 교통부(DOT)의 공개 운송업체 등록부나 업계 협회 회원 디렉터리를 스크래핑하면 회사명, 위치, 차량 규모 범주를 얻을 수 있다. 모두 공개 정보이고, 모두 허용된 소스다. 이어서 각 회사의 사이트에 들어가 실제 운영 중인지 확인하고, 일반 문의 연락처를 확보한다. 그렇게 하면 5,000명의 검증되지 않은 이름 대신 200개의 자격 있는 계정을 얻게 된다. 하지만 그 200개는 모두 SDR의 시간을 들일 가치가 있다. 그게 진짜 목표다.
B2B 리드용 스크래핑은 리스트를 만드는 작업으로 보지 않고, 더 좋은 도구를 쓴 리서치로 볼 때 가장 잘 작동한다. 나는 세일즈 팀이 1만 개의 구매 연락처보다 150개의 잘 선별된 계정에서 더 많은 파이프라인을 만드는 걸 봤다. 이유는 간단하다. 아웃리치가 일반론이 아니라 관련성 있게 느껴졌기 때문이다. AI 스크래핑이 더 큰 세일즈 모션에서 어디에 들어맞는지 고민 중이라면, AI가 리드 생성 방식을 어떻게 바꾸고 있는지, 그리고 세일즈 팀이 실제 업무에서 AI를 어떻게 쓰는지 정리한 글도 읽어 볼 만하다. 스크래핑 단계를 넘어선 워크플로까지 더 깊게 다루고 있다.
이런 파이프라인을 만드는 데는 연락처 리스트를 다운받는 것보다 약간 더 세팅이 필요하다. 하지만 최종적으로 얻게 되는 계정들은 실제로 당신의 이야기를 들을 준비가 되어 있다. 수년간 허공에 냉담한 이메일을 수없이 보내 본 사람으로서 말하자면, 그 정도 추가 세팅 시간은 충분히 가치 있다.
자주 묻는 질문
웹에서 B2B 회사 데이터를 스크래핑하는 건 합법인가요?
완전히 출처에 달려 있다. 공개된 회사 웹사이트, 정부 공시, 그리고 명시적으로 허용된 디렉터리는 보통 리서치 목적으로 스크래핑해도 무방하다. 반면 LinkedIn이나 Google Maps 같은 사이트는 기술적으로 가능하더라도 이용약관에서 스크래핑을 명시적으로 금지한다. 스크래핑하기 전에 항상 해당 사이트의 이용약관을 확인하고, robots.txt는 법적 허가가 아니라 크롤링 지침으로 보자.
이 문맥에서 “리드”와 “연락처”의 차이는 무엇인가요?
연락처는 그저 이름과 연락 방법이다. 반면 제대로 만든 리드는, 이상적인 고객 프로필에 부합한다는 근거가 붙은 회사 레코드에다가, 왜 지금 연락하는지 설명하는 시점이 찍힌 신호까지 포함한다. 맥락 없이 대량 연락처만 긁어오는 방식이 수많은 콜드 아웃리치 캠페인을 실패로 만드는 이유다.
AI 스크래핑 도구가 데이터의 정확성을 보장할 수 있나요?
아니요. 그렇게 말하는 도구가 있다면 한 번쯤 의심해 볼 필요가 있다. AI 추출은 지저분한 페이지를 구조화하는 데 아주 강하지만, 애매한 필드를 잘못 읽을 수도 있다. 어떤 도구를 쓰든, 규모를 키우기 전에 샘플을 직접 확인하는 습관은 꼭 유지하는 게 좋다.
이메일은 직접 스크래핑하는 게 좋나요, 아니면 나중에 보강 도구를 쓰는 게 좋나요?
보강 도구는 페이지에서 직접 긁는 것보다 이름이 있는 연락처 이메일을 찾고 검증하는 데 더 신뢰할 수 있는 경우가 많고, 검증 상태도 보통 명확하게 문서화되어 있다. 내 추천은 먼저 회사 단위 자격 판단용 데이터를 스크래핑하고, 그다음 이미 적합성 기준을 통과한 계정만 보강하는 방식이다. 더 효율적이고, 컴플라이언스 노출도 줄어든다.
CRM에 중복 리드가 들어가지 않게 하려면 어떻게 해야 하나요?
가져오기 전에 회사명보다 회사 도메인을 기본 식별자로 정규화하자. 회사명은 변형이 너무 많아 중복 제거가 쉽지 않다. HubSpot과 Salesforce 모두 매칭 규칙이 어떻게 동작하는지 문서가 있으며, 전체 가져오기 전에 작은 테스트 배치를 돌리면 대부분의 문제를 미리 잡을 수 있다.
