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

해결해야 할 과제

여러분은 B2B SaaS 제품을 개발하고 있습니다. 고객이 기업 이름 목록을 업로드합니다. 이들은 매출 규모, 직원 수, 기술 스택, 투자 유치 단계, 주요 연락처, 최근 뉴스 등이 포함된 깔끔한 레코드를 돌려받기를 기대합니다. 며칠이 아닌 몇 분 만에 결과가 나오기를 기대합니다. 그리고 그 데이터가 정확하기를 기대합니다.

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

모든 소스는 제각각의 방식으로 망가집니다. Crunchbase는 봇으로 의심되면 다시 렌더링되는 무거운 클라이언트 사이드 앱을 제공합니다. LinkedIn은 공격적으로 rate-limit을 적용하며, 개발자가 셀렉터를 패치하는 것보다 더 빠르게 DOM을 변경합니다 (인기 있는 커뮤니티 글에 따르면, 순수 Python 스크래퍼는 안티봇 장벽에 막히기 전까지 약 50개의 프로필만 수집할 수 있다고 합니다). 기업 웹사이트는 정적 HTML부터 콘텐츠를 표시하기 위해 전체 브라우저가 필요한 싱글 페이지 앱까지 다양합니다. 지역 디렉터리는 분기마다 레이아웃을 변경하고 국가별 차단으로 접근을 제한합니다. GroupBWT의 2026년 업계 보고서에 따르면, 일부 업종의 크롤러 중 10~15%는 안티봇 업데이트와 DOM 변화에 대응하기 위해 매주 수정 작업을 거쳐야 합니다.

그 결과 처음에는 5개의 소스를 사용하는 깔끔한 구조로 시작했던 인리치먼트 파이프라인이 구축됩니다. 하지만 6개월이 지나면 반쯤 망가진 스크래퍼, 재시도 큐, 그리고 아무도 열어보지 않는 #scraper-alerts라는 이름의 Slack 채널이 뒤엉킨 난장판이 됩니다 (이전에 자체 스크래퍼 유지보수의 숨겨진 비용에 대해 작성한 적이 있습니다). 데이터 품질에 대한 불만이 지원 대기열에 쌓이기 시작합니다. 팀원들은 회사 이름을 "다섯 개의 스크래퍼와 기도"로 지었어야 했다며 농담을 던지기 시작합니다.

해결 방법

잠시 스크래퍼는 잊어버리세요. 인리치먼트에서 어려운 부분은 추출이 아닙니다. 바로 라우팅입니다. 어떤 소스에 어떤 도구, 어떤 proxy, 어떤 재시도 정책을 적용할지, 그리고 무엇을 "성공적인" response로 간주할지 결정하는 일입니다.

A platform like FourA는 여러분이 마주하게 될 세 가지 유형의 소스에 직접 매핑되는 세 가지 제품을 제공합니다.

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

JavaScript가 많은 SPAs. Crunchbase, LinkedIn 스타일의 앱, 심지어 중간 규모의 기업 사이트도 일반 HTTP response로는 원하는 데이터를 반환하지 않습니다. 이들은 클라이언트에서 렌더링됩니다. 이것이 바로 Browser입니다. 전체 브라우저가 페이지를 실행하고 JS를 실행한 다음, 렌더링된 HTML, cookies, 스크린샷을 돌려줍니다. Single과 마찬가지로 백그라운드에서 Proxy Finder를 통해 라우팅되므로, 개발자 측에서 별도로 프록시를 선택하는 단계가 필요하지 않습니다.

검증이 포함된 혼합 소스. FourA의 API에 대한 모든 request는 validate 블록을 허용합니다. 특정 status codes, header 일치 또는 body의 substring matches를 요구할 수 있습니다. 만약 response가 소프트 페일(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
  }'

라우팅 로직은 여러분의 파이프라인에 위치합니다. 안정성은 저희 파이프라인이 책임집니다. 여러분은 소스에 어떤 도구를 적용할지만 결정하면 됩니다. 저희는 그 도구가 실제로 통과하도록 보장합니다.

결과

퍼블릭 beta 기간 동안 몇몇 팀이 자체 구축한 스크래퍼에서 FourA 라우팅 파이프라인으로 전환하는 과정을 지켜보았습니다. 패턴은 일관적이었습니다 (아래 수치는 beta 참여 그룹 전체에서 관찰된 결과를 바탕으로 한 예시입니다):

**인리치먼트 지연 시간(latency)**이 기업당 3~6초에서 cached-residential 경로 기준 중앙값 1.5초 미만으로 단축됩니다
validate 블록이 데이터베이스에 도달하기 전에 소프트 페일을 잡아내면서, 자동 실패율(silent-failure rate)(데이터가 비어 있는 200 response)이 약 8%에서 1% 미만으로 감소합니다
스크래퍼 유지보수에 소요되는 엔지니어링 시간이 정규직 엔지니어 1~2명 분량에서 대부분 조용한 상태를 유지하는 Slack 채널 하나 수준으로 줄어듭니다
unblocker: true와 깨끗한 proxy id를 함께 사용할 때, 보호된 디렉터리에 대한 **첫 시도 성공률(first-pass success rate)**이 90%대 후반까지 상승합니다

주목할 만한 수치가 하나 더 있습니다. 첫 시도의 정확성(올바른 기업의 올바른 데이터)이 첫 시도의 성공보다 약 4포인트 정도 뒤처지는 것을 확인했습니다. 여기서 얻을 수 있는 교훈은 스크래핑이 어렵다는 것이 아닙니다. 실제로 요청한 기업과 반환된 레코드가 일치하는지 여전히 검증해야 한다는 점입니다 (이 패턴에 대해서는 웹 스크래퍼가 계속 망가지는 이유에서 다룬 적이 있습니다).

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

핵심 요약

인리치먼트 파이프라인은 서서히 망가집니다. 화요일에 처음 작성한 스크래퍼는 아무 문제가 없어 보입니다. 하지만 세 번째 소스를 추가할 때쯤이면 밤 11시에 셀렉터를 패치하고 있게 됩니다. 열 번째 소스에 이르면 고객 기반의 성장에 비례하여 늘어나는 유지보수 부채를 떠안게 됩니다. 스무 번째 소스에 도달하면 팀원 중 누구도 다음 소스를 담당하고 싶어 하지 않기 때문에, 슬그머니 새로운 소스 추가를 중단하게 됩니다.

병목 현상은 결코 소스 자체에 있지 않았습니다. 문제는 라우팅이었습니다. 매번 모든 URL에 대해 올바른 도구, 올바른 proxy, 올바른 검증 규칙을 선택하는 것이 핵심입니다. 이 레이어를 한 번만 구축하여 이미 이 역할을 수행하고 있는 시스템에 맡기면, 여러분의 팀은 화요일 밤에 셀렉터 오류를 해결하는 대신 제품 개발에 시간을 쏟을 수 있습니다.