브라우저와 프록시 운영을 API 사업으로 만든 피에르 드 울프

개발자의 반복적인 운영 부담을 API 사업으로 만들다

피에르 드 울프(Pierre de Wulf)는 케빈 사힌(Kevin Sahin)과 함께 웹 스크래핑 API 서비스 ScrapingBee를 만들었다. 웹페이지에서 데이터를 수집할 때 필요한 브라우저 실행과 프록시 처리를 대신 맡아 주는 제품이다. 2022년 4월 공개된 인터뷰에서는 연간 반복매출인 ARR 100만 달러에 도달한 사례로 소개됐으며, 두 공동창업자가 이전 사업의 실패를 거쳐 성장시켰다는 점이 주목받았다.

가격 추적 서비스를 만들다가 발견한 문제

ScrapingBee에 앞서 두 사람은 소비자용 가격 추적 확장 프로그램 ShopToList를 운영했다. 사용자가 관심 상품을 저장하면 가격 변화를 확인할 수 있는 서비스였지만, 이용자 규모와 수익 구조가 맞지 않았다. 피에르는 훗날 이 사업을 회고하며 손익분기점에 도달하려면 실제 확보한 이용자보다 훨씬 많은 사람이 필요했다고 설명했다.

다음 제품인 PricingBot은 전자상거래 사업자를 위한 경쟁 상품 가격 추적 도구였다. 기업 고객에게 판매하면 수익화가 쉬워질 것으로 기대했지만, 약 9개월 동안 충분한 성장을 만들지 못했다. 두 사람은 전자상거래 업계의 사정과 고객이 모이는 장소, 실제 구매 동기를 충분히 이해하지 못했다. PricingBot은 매각했고, 다음 제품에서는 자신들이 잘 아는 고객을 상대하기로 했다.

PricingBot을 개발하면서 사용했던 외부 스크래핑 도구들이 새로운 사업의 단서가 됐다. 피에르는 기존 도구의 속도와 성능에 불만이 있었고, 이미 유료 사업이 성립하는 시장에서 개선할 여지가 있다고 판단했다. 두 사람은 개발자였으며, 케빈은 웹 스크래핑에 관한 책까지 쓴 경험이 있어 이번에는 고객의 작업과 불편을 직접 이해할 수 있었다.

브라우저와 프록시 운영을 상품화하다

ScrapingBee의 사용자는 수집할 웹페이지 주소와 필요한 옵션을 API에 전달한다. 서비스는 화면 없이 실행되는 브라우저로 자바스크립트를 처리하고, 프록시를 관리하며, 페이지 내용이나 추출된 데이터를 돌려준다. 상품 가격, 검색 결과, 채용 공고처럼 여러 웹사이트에서 반복적으로 정보를 모아야 하는 작업에 사용할 수 있다. 고객은 수집 인프라를 직접 운영하는 부담을 줄이고, 확보한 데이터를 자신의 제품이나 업무에 연결한다.

수익 모델은 월 구독료에 API 크레딧과 동시 요청 한도를 묶는 방식이다. 요청에 필요한 기능에 따라 크레딧 소모량을 달리해, 처리 비용이 큰 작업에는 더 많은 이용량을 부과한다. 예를 들어 2026년 9월 확인한 공식 안내에서는 일반 프록시를 사용하는 기본 요청이 1크레딧, 자바스크립트 렌더링을 포함하면 5크레딧, 프리미엄 프록시와 렌더링을 함께 사용하면 25크레딧이다. 이 구조에서는 요청 수와 처리 난도가 고객의 요금제 선택에 함께 영향을 준다.

초기 제품은 스크래핑 포럼과 관련 커뮤니티에서 모집한 약 10명의 무료 시험 사용자에게 제공했다. 2019년 6월에는 무료 시험을 종료하고 계속 사용하려면 구독하도록 안내했다. 첫 안내 이메일을 보낸 지 50분 만에 첫 결제가 발생하면서, 개발 중인 도구에 실제 지불 의사가 있다는 신호를 얻었다.

검색으로 고객을 모으고, 외부 자금으로 여유를 확보하다

고객 확보에서는 기술 콘텐츠가 일찍 성과를 냈다. 2019년 8월 공개한 웹 스크래핑 차단 문제 해결 가이드는 여러 곳에 공유된 뒤 빠르게 약 2만 명의 방문자를 모았다. 개발자가 당장 해결하려는 문제를 자세히 설명하는 글이 제품을 알리는 통로가 됐다.

사용자 인터뷰에도 제품의 이용량을 활용했다. 15분 동안 스크래핑 요구사항을 이야기해 주는 사람에게 API 호출 1만 회를 제공하자, 3개월이 채 지나기 전에 약 100명과 대화할 수 있었다. 인터뷰에 응할 이유를 마련해 고객의 실제 사용 목적과 불편을 빠르게 수집한 것이다.

2020년 봄에는 TinySeed의 두 번째 액셀러레이터 프로그램에 합류해 외부 투자를 받았다. TinySeed는 창업자의 경영 통제와 자본 효율적인 성장을 중시하면서 자금, 멘토링, 창업자 커뮤니티를 제공하는 프로그램이다. ScrapingBee는 공동창업과 투자 지원을 결합해 성장한 소규모 SaaS라는 성격을 갖는다.

피에르는 이후 인터뷰에서 투자금이 만들어 준 심리적 여유를 강조했다. 조달한 자금을 직접 소진하지 않았더라도, 충분한 현금이 있다는 사실 덕분에 작은 지출을 두려워하며 결정을 미루는 상황에서 벗어날 수 있었다. 투자금과 함께 확보한 전문가 조언, 멘토링, 동료 창업자들과의 연결도 중요한 지원이었다고 회고했다.

성장 과정에서 케빈은 마케팅을, 피에르는 제품과 기술을 맡으며 역할을 나눴다. 콘텐츠 제작에는 글을 쓸 수 있는 개발자를 참여시키고, 편집자가 문장과 구성을 다듬는 체계를 만들었다. 피에르가 설명한 당시 발행량은 월 3~4편 정도였으며, 언어·프레임워크·라이브러리별로 깊이 있는 튜토리얼을 쌓았다. 창업자 두 사람이 모든 글을 직접 작성하던 방식에서 벗어나면서 검색 유입을 확대할 수 있었다.

제품 개선은 처음 사용하는 개발자의 불편을 줄이는 데 집중됐다. 2020년에는 Python·JavaScript SDK, 7개 언어의 코드 예제, API 요청 생성기를 마련했다. 검색으로 찾아온 개발자가 실제 수집 결과를 확인하기까지의 과정을 짧게 만드는 작업이었다.

ARR 100만 달러에서 500만 달러로

2020년 말 월간 반복매출인 MRR 1만 달러에 도달하기까지는 약 18개월이 걸렸다. 이 수준에서 두 창업자는 이전 직장과 비슷한 보수를 받을 수 있었고, 사업도 흑자를 냈다. 이후 매출을 MRR 2만 달러로 늘리는 데는 약 3개월이 걸렸으며, ARR 100만 달러의 실제 도달 시점은 2021년 11월이었다. 2022년에 소개된 성장 사례는 출시 약 2년 반 만에 달성한 이 기록을 다룬 것이다.

피에르는 2025년 공개 글에서 전년도인 2024년에 ARR 500만 달러를 넘겼다고 밝혔다. 당시 핵심 팀은 공동창업자 2명, 개발자 1명, 고객지원 담당자 2명, 검색엔진 최적화 담당자 1명으로 구성된 6명이었다. 디자인, 전문적인 인프라 업무, 콘텐츠 제작 등에서는 외부 프리랜서와도 협업했다. 따라서 이 성과는 소수의 상근 인력과 외부 전문 인력을 함께 활용한 운영 구조에서 나왔다.

작은 팀을 유지하는 데도 비용은 있었다. 피에르는 2024년 인터뷰에서 인원이 적으면 공동창업자의 시간과 체력에 부담이 집중되고, 여러 업무를 동시에 맡으면서 품질에도 한계가 생긴다고 말했다. 그는 수익성 일부를 양보하더라도 인력을 늘려 운영을 개선할 필요가 있다고 설명했다. 높은 매출과 적은 직원 수만으로 창업자의 실제 업무 부담까지 판단하기는 어려웠다.

매각을 가능하게 만든 운영 정비

매각 준비 과정에서는 웹 스크래핑 사업 특유의 위험도 드러났다. 피에르의 설명에 따르면, 첫 매각 절차를 진행하던 중 대형 기술기업으로부터 스크래핑 중단 등을 요구하는 통지를 받으면서 거래 추진을 멈춰야 했다. 이후 다시 매각을 시도하기까지 추가 채용, 업무 표준화, 운영 문서화, 회계 자료 정비를 진행했다. 제품의 성능과 매출 외에도 인수자가 검토할 수 있는 운영 체계와 위험 대응이 필요했다.

두 창업자가 매각을 결정한 배경에는 장기간 같은 분야에서 일하며 쌓인 피로와 삶의 우선순위 변화가 있었다. 매출과 성장 상태가 양호할 때 선택권을 행사하고 싶었다는 설명도 덧붙였다. 여러 인수 제안 가운데 Oxylabs를 선택한 이유에는 스크래핑 업계의 특성과 위험을 이해하는 사업자라는 점, 그리고 전액 현금 거래라는 조건이 포함됐다.

2025년 6월 19일 TinySeed는 ScrapingBee가 Oxylabs 그룹에 인수됐다고 발표했다. 거래는 달러 기준 8자리 금액의 전액 현금 매각으로 공개됐으며, 최소 1,000만 달러 규모에 해당한다. 정확한 인수 금액과 공동창업자 각각의 수령액은 공개 자료에서 확인되지 않는다.

매각 발표에서는 ScrapingBee가 별도 제품과 법인으로 계속 운영되고, 피에르와 케빈도 회사에 남는다고 밝혔다. 회사는 그룹의 인프라와 전문성을 활용해 성능을 개선하고, 고객지원 인력을 늘리는 방향을 설명했다. 소규모 팀이 만든 제품을 더 큰 운영 조직 안에서 확장하는 거래였다.

ScrapingBee는 범위가 좁은 API도 고객의 반복적인 운영 부담을 충분히 줄여 주면 규모 있는 소프트웨어 사업으로 성장할 수 있음을 보여 준다. 성장기에는 사용하기 쉬운 제품과 지속적인 고객 확보가 중요했고, 매각 단계에서는 운영 문서·회계·위험 대응까지 갖춘 사업의 완성도가 필요했다. 두 창업자는 개발 역량에 콘텐츠 제작, 전문 인력, 투자자의 지원을 차례로 더하며 그 조건을 갖춰 갔다.