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

B2B 기업 데이터 보강 파이프라인 구축

매일 디렉토리, 웹사이트, 언론 매체에서 수천 개 기업의 데이터를 보강해야 합니까? 매주 망가지지 않는 B2B 데이터 보강 파이프라인 구축 방법을 소개합니다.

b2blead generationdata enrichmentcompany enrichmentuse case

당면 과제

B2B SaaS 제품을 구축 중이라고 가정해 보겠습니다. 고객은 기업명 목록을 업로드하고, 매출 규모, 직원 수, 기술 스택, 투자 라운드, 주요 연락처, 최근 뉴스 등 깔끔하게 정리된 기록을 돌려받기를 원합니다. 며칠이 아니라 단 몇 분 만에 결과를 기대하며, 그 데이터가 정확하기를 바랍니다.

데이터는 존재합니다. Crunchbase, 기업 소개 페이지, LinkedIn 기업 페이지, Google Maps, Glassdoor, 지역 기업 등록부, TechCrunch 아카이브 등에 있습니다. 문제는 이 데이터에 안정적으로 접근하는 것입니다.

각 소스는 저마다 다른 방식으로 차단됩니다. Crunchbase는 봇이 의심될 경우 다시 렌더링하는 무거운 클라이언트 측 앱을 제공합니다. LinkedIn은 공격적으로 rate limit을 적용하고 선택자를 수정하는 속도보다 빠르게 DOM을 변경합니다(한 유명 커뮤니티 게시물에 따르면 기본 Python 스크래퍼는 안티 봇 차단벽이 작동하기 전까지 약 50개의 프로필을 수집합니다). 기업 웹사이트는 정적 HTML부터 콘텐츠를 표시하기 위해 전체 브라우저가 필요한 단일 페이지 앱(SPA)까지 다양합니다. 지역 디렉토리는 분기마다 레이아웃을 바꾸고 국가별 차단 기능을 통해 접근을 통제합니다. GroupBWT의 2026 산업 보고서에 따르면, 특정 분야의 크롤러 중 10~15%는 안티 봇 업데이트와 DOM 변화에 대응하기 위해 매주 수정이 필요합니다.

따라서 초기 데이터 보강 파이프라인은 5개의 소스를 사용하는 깔끔한 설계로 시작됩니다. 6개월 후, 이 파이프라인은 반쯤 망가진 스크래퍼, 재시도 대기열, 아무도 열어보지 않는 #scraper-alerts라는 Slack 채널로 뒤엉키게 됩니다(이전에 자체 스크래퍼 유지보수의 숨겨진 비용에 대해 작성한 바 있습니다). 고객 지원 대기열에는 데이터 품질에 대한 불만이 쌓입니다. 팀원들은 회사 이름이 "5개의 스크래퍼와 기도"였어야 했다고 농담하기 시작합니다.

접근 방식

스크래퍼는 잠시 잊으십시오. 데이터 보강에서 가장 어려운 부분은 데이터 추출이 아닙니다. 핵심은 라우팅(routing)입니다. 즉, 어떤 소스에 어떤 도구, 어떤 proxy, 어떤 재시도 정책이 필요한지 결정하고 무엇을 "유효한" response로 간주할지 판단하는 것입니다.

FourA와 같은 플랫폼은 여러분이 마주하게 될 3가지 소스 유형에 직접 매핑되는 3가지 제품을 제공합니다.

정적 HTML 디렉토리 및 등록부. 대부분의 지역 기업 등록부와 수많은 오래된 B2B 디렉토리는 서버 렌더링 방식을 사용합니다. 이들은 깨끗한 IP에서 오는 빠르고 오버헤드가 적은 HTTP request를 요구합니다. 이것이 바로 Single입니다. 하나의 URL을 입력하면 하나의 response가 출력됩니다. unblocker: true을 추가하면 기본 HTTP 클라이언트를 차단하는 핸드셰이크 수준의 차단을 통과할 수 있습니다. Single은 자동으로 Proxy Finder를 통해 라우팅되며 response의 최상위 레벨에 proxy id를 반환합니다(r.proxy). 세션 연속성이 필요할 때 후속 호출에서 이를 proxy:"<id>"로 다시 전달하여 동일한 출구를 유지할 수 있습니다.

JavaScript 비중이 높은 SPA. Crunchbase, LinkedIn 스타일 앱, 심지어 중견 기업 사이트도 일반적인 HTTP response에서는 원하는 데이터를 반환하지 않습니다. 클라이언트에서 렌더링되기 때문입니다. 이를 위한 솔루션이 Browser입니다. 전체 브라우저가 페이지를 실행하고 JS를 구동한 후 렌더링된 HTML, cookie 및 스크린샷을 반환합니다. Single과 마찬가지로 내부적으로 Proxy Finder를 통해 라우팅되므로 별도의 선택 단계가 필요하지 않습니다.

유효성 검사가 포함된 혼합 소스. FourA의 API에 대한 모든 request는 validate 블록을 허용합니다. 특정 상태 코드, header 일치, 또는 본문의 부분 문자열 일치를 요구할 수 있습니다. response가 소프트 실패(soft-fail, CAPTCHA가 있는 200 페이지, 빈 데이터 셸, 또는 "죄송합니다"라는 안내 페이지)인 경우 검사기가 이를 거부합니다. 그러면 파이프라인은 동일한 URL을 Browser를 통해 대신 라우팅할 수 있습니다. 이 단일 기능은 데이터 보강 작업에서 가장 비용이 많이 드는 버그 유형인, 데이터베이스에 쓰레기 데이터를 기록하는 조용한 실패(silent failure)를 제거합니다.

단일 소스 호출의 형태는 다음과 같습니다.

curl -X POST https://api.foura.ai/api/single \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://registry.example.com/company/123",
    "unblocker": true,
    "followRedirects": 5,
    "validate": {
      "status": { "accept": [200] },
      "data":   { "fail":   ["captcha", "blocked", "access denied"] }
    }
  }'

JavaScript 비중이 높은 기업 사이트를 위한 Browser 버전은 다음과 같습니다.

curl -X POST https://api.foura.ai/api/browser \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://www.example-saas.com/about",
    "unblocker": true
  }'

라우팅 로직은 자체 파이프라인에 있습니다. 안정성은 당사에서 제공합니다. 여러분은 어떤 소스에 어떤 도구를 적용할지 결정하기만 하면 됩니다. 도구가 실제로 데이터를 가져오는 것은 당사에서 보장합니다.

결과

퍼블릭 베타 기간 동안 여러 팀이 사내 스크래퍼에서 FourA 라우팅 파이프라인으로 전환하는 것을 지켜보았습니다. 패턴은 일관되었습니다(베타 코호트에서 관찰한 내용을 바탕으로 한 예시 수치입니다).

  • 보강 지연 시간은 캐시된 가정용(cached-residential) 라우팅에서 기업당 3~6초에서 중앙값 1.5초 미만으로 감소합니다.
  • 조용한 실패율(빈 데이터가 포함된 200 response)은 validate 블록이 데이터베이스에 도달하기 전에 소프트 실패를 포착하면 약 8%에서 1% 미만으로 떨어집니다.
  • 스크래퍼 유지보수에 소요되는 엔지니어링 시간은 1~2명의 전담 엔지니어에서 대부분 조용한 상태를 유지하는 Slack 채널로 줄어듭니다.
  • 보호된 디렉토리의 첫 시도 성공률은 unblocker: true를 깨끗한 proxy id와 함께 사용할 때 90% 후반까지 상승합니다.

또 하나 주목할 만한 수치가 있습니다. 첫 시도 정확도(올바른 데이터, 올바른 회사)가 첫 시도 성공률보다 약 4포인트 뒤처진다는 점입니다. 여기서 얻을 수 있는 교훈은 스크래핑이 어렵다는 것이 아닙니다. 요청한 회사와 기록이 일치하는지 여전히 유효성 검사를 수행해야 한다는 것입니다(이 패턴에 대해서는 웹 스크래퍼가 계속 고장나는 이유에서 설명한 바 있습니다).

중요한 수치는 proxy 풀 크기나 request 횟수가 아닙니다. 데이터 보강 endpoint가 첫 시도에 올바른 데이터를 반환하는 비율, 그리고 향후 6개월간 스크래퍼 유지보수 그래프의 기울기입니다.

핵심 요약

데이터 보강 파이프라인은 서서히 실패합니다. 처음 작성한 스크래퍼는 화요일에는 괜찮아 보입니다. 세 번째 소스에 이르면 밤 11시에 선택자를 패치하게 됩니다. 열 번째가 되면 고객 기반과 함께 증가하는 유지보수 부채를 떠안게 됩니다. 스무 번째에 이르면 팀원 중 아무도 다음 소스를 담당하고 싶어 하지 않기 때문에 조용히 새로운 소스 추가를 중단하게 됩니다.

병목 현상은 결코 소스 자체가 아니었습니다. 문제는 라우팅이었습니다. 즉, 모든 URL에 대해 매번 올바른 도구, 올바른 proxy, 올바른 유효성 검사 규칙을 선택하는 것입니다. 이 계층을 한 번 구축하여 이미 이를 수행하는 서비스에 맡기면, 팀은 화요일에 선택자 오류를 분류하는 대신 제품 개발에 시간을 쏟을 수 있습니다.