차세대 AI를 잇는 웹 데이터 인프라

URL: https://www.youtube.com/watch?v=1UmZHb_E_SM 날짜: 2026-08-15 원본 발행일: 2026-08-14 채널: aiDotEngineer 발표자: Patricija Žemaitytė, Oxylabs Product Manager 원문 제목: How Web Data Infrastructure Powers the Next Generation of AI — Patricija Žemaitytė, Oxylabs

📌 핵심 질문 / 웹 데이터 인프라의 핵심 논점

==차세대 AI의 경쟁력은 더 좋은 모델만으로 결정되지 않고, 모델을 현실의 최신 정보와 연결하는 웹 데이터 인프라의 품질과 적응 속도로 결정된다.==

• 정적 학습 데이터만으로는 계속 변하는 현실과 사용자의 최신 질문을 따라갈 수 없다.
• 공개 웹 데이터는 이론상 누구에게나 열려 있지만, 실제로는 수집·우회·브라우저 실행·정규화·전달을 안정적으로 묶는 인프라가 필요하다.
• 제품 요구는 동영상 다운로드에서 자막·메타데이터·검색·SERP 전달로 계속 확장되며, 각 요구 변화가 새로운 제품과 아키텍처를 만든다.
• 낮은 지연 시간과 높은 처리량은 단순한 성능 지표가 아니라 AI 제품으로 구현할 수 있는 기능의 범위를 결정한다.

모델은 더 이상 고립된 지식 저장소가 아니다. 최신 공개 웹 데이터를 검색·검색결과 페이지(SERP)·리트리벌 파이프라인을 통해 받아들이는 연결 계층이 모델 주변에 붙어야 한다. Oxylabs가 제공하려는 가치는 프록시 하나가 아니라, AI 회사가 지능과 제품에 집중하는 동안 웹의 복잡하고 계속 변하는 유지보수를 맡는 운영 가능한 데이터 인프라다.

1. 모델에서 웹 데이터 인프라로 시선을 옮기기

모델의 지식은 학습 시점에 고정되므로, 현실과 연결되는 데이터 접근 계층이 모델의 유용성을 좌우한다.

1.1. Oxylabs가 해결하는 문제

1. 공개 데이터와 실제 접근성의 간극

   1. Oxylabs는 2015년에 설립됐고 스스로를 웹 인텔리전스 플랫폼이자 프리미엄 프록시 제공업체로 정의한다.
   2. 기업이 공개 웹 데이터를 대규모로 추출할 수 있도록 인프라를 구축한다.
   3. 공개 웹 데이터는 이론상 모두에게 열려 있지만, 실제 연결에는 프록시, 수집 로직, 브라우저, 안티봇 대응, 저장소, 전달 계층이 필요하다.
   4. AI 모델·에이전트·데이터베이스를 웹과 연결하려면 단순한 URL 호출이 아니라 이 전체 인프라 계층이 필요하다.

2. 정적 학습의 한계

   1. 산업은 정적 지식과 학습만으로 충분하다고 보는 방식에서 벗어나고 있다.
   2. 학습 자체는 여전히 중요하지만, 학습만으로는 유용성을 유지할 수 없다.
   3. 모델은 최신 정보, 실시간 검색, 외부의 실제 데이터를 받아야 현재 상황에 맞는 답과 행동을 만들 수 있다.
   4. 아무리 똑똑한 모델도 최신 데이터에 접근하지 못하면 자신이 알고 있는 범위에 갇힌다.

1.2. Patricia의 배경과 UX의 재정의

1. 엔지니어링에서 제품 관리로 이어진 경로

   1. Patricia는 현재 Oxylabs의 제품 관리자(Product Manager)로 일하지만, 출발점은 엔지니어링에 가까웠다.
   2. 서비스와 코어 서비스(core services)를 담당하는 팀을 이끌며 시스템의 운영 문제를 직접 다뤘다.
   3. 첫 번째 스쿼드가 가르쳐 준 핵심 단어는 UX였지만, 여기서 UX는 일반적인 사용자 경험(User Experience)만을 뜻하지 않았다.

2. 기업형 UX가 요구하는 실행 방식

   1. 고객은 매우 특수한 요구를 들고 오며, 이미 만들어진 제품으로 해결할 수 없는 경우가 많다.
   2. 일정은 고통스러울 정도로 짧고, 팀은 빠르게 무언가를 만들면서도 결과를 아름답고 안정적으로 작동시켜야 한다.
   3. 혁신은 정리된 로드맵보다 압박과 마감, 때로는 샌프란시스코에서 돌아온 영업팀의 출장 보고서 형태로 찾아온다.
   4. 불확실한 요구를 실행 가능한 시스템으로 바꾸는 과정 자체가 제품 경험의 일부가 된다.

2. 한 번의 동영상 API 요청이 제품군으로 자라난 과정

작은 기능 요청은 고객의 실제 파이프라인을 따라가면서 수집·저장·검색·전달을 모두 포함하는 인프라 제품으로 확장됐다.

2.1. 2주와 월 5페타바이트라는 출발점

1. 영업팀이 가져온 요구

   1. 샌프란시스코에서 돌아온 영업팀은 AI 학습을 위한 동영상 API 수요가 있다고 전했다.
   2. Patricia가 가장 묻기 두려워한 질문은 마감일이었고, 답은 2주였다.
   3. 필요한 규모는 월 최소 5페타바이트(5 PB)였다.
   4. 당시 팀은 그런 규모의 시스템을 한 번도 만들어 본 적이 없었기 때문에, 요청은 단순 기능보다 훨씬 크게 느껴졌다.

2. 기능이 인프라로 변하는 순간

   1. 고객이 원하는 것은 동영상 몇 개를 다운로드하는 기능이 아니었다.
   2. 수집(collection), 전송(transfer), 저장(storage), 전달(delivery)을 하나로 묶은 파이프라인이었다.
   3. AI 학습 워크로드가 감당할 수 있을 정도의 신뢰성과 처리 흐름이 함께 필요했다.
   4. 이 요구를 듣는 순간 ‘동영상 다운로드 기능’은 제품 기능이 아니라 인프라로 보이기 시작했다.

2.2. 첫 번째 버전과 반복되는 요구

1. 2주 안에 만든 첫 파이프라인

   1. 팀은 새로운 로직을 가진 전용 스크레이퍼를 만들었다.
   2. 새로운 저장소 통합과 이전에 구현해 본 적 없는 전달 플로우를 추가했다.
   3. 결과적으로 2주 안에 작동하는 첫 버전을 일정에 맞춰 완성했다.
   4. 그러나 첫 버전은 끝이 아니라 다음 요구를 부르는 출발점이었다.

2. 다운로더에서 자막·검색·메타데이터로

   1. 고객은 “다운로더는 좋지만 트랜스크립트는 어떻게 하느냐”고 물었다.
   2. 팀은 트랜스크립트 지원을 추가했지만, 고객의 모든 요청이 실패하는 현상을 발견했다.
   3. 원인은 구현 오류가 아니라 고객이 트랜스크립트가 아닌 자막(subtitles)을 원했다는 의미 차이였다.
   4. 팀은 다시 방향을 바꿔 자막 지원을 만들었다.
   5. 이어 필요한 언어의 동영상을 찾을 검색 기능과 메타데이터 지원 요청이 들어왔다.
   6. 채널 정보까지 더하면서 각 기능은 하나의 고객 요청에서 하나의 제품 계층으로 확장됐다.

3. 내부 라이브러리와 제품군

   1. 다운로더, 트랜스크립트, 자막, 메타데이터, 채널 정보를 이어 주는 자체 내부 라이브러리를 만들었다.
   2. 충분한 반복 끝에 일회성 기능 요청은 전체 제품군으로 성장했다.
   3. 약 3개월 만에 다운로더·트랜스크립트·자막·채널 정보를 지원하는 동영상 API 제품군이 완성됐다.
   4. 작은 기능을 만들고 끝내는 대신 고객이 실제로 처리하려는 데이터 흐름을 따라가자 제품의 경계가 다시 정의됐다.

4. 30페타바이트와 미지급 대금의 농담

   1. 2026년이 되자 고객은 이미 30페타바이트의 데이터를 모아 둔 상태였다.
   2. 그런데 Oxylabs 팀은 아직 대금을 기다리고 있었다.
   3. 이 농담은 기술적 성공이 상업적 완결을 자동으로 보장하지 않는다는 현실을 드러낸다.
   4. 첫 번째 교훈은 기술적이면서 동시에 인간적이다. 혁신은 높은 압박 아래에서 반복적으로 적응하는 일이다.

2.3. 고객이 구매하는 것은 첫 버전이 아니라 적응 능력이다

1. 요구가 제품을 다시 만든다

   1. 고객은 첫 번째 제품 반복(iteration) 자체를 사는 것이 아니다.
   2. 요구가 바뀔 때마다 기능을 바꾸고, 새로운 데이터 형식과 파이프라인을 추가하고, 실패 원인을 다시 해석하는 능력을 산다.
   3. “트랜스크립트”가 실제로는 “자막”이었다는 사례처럼, 표면의 단어와 실제 워크로드를 구분해야 한다.

2. 혁신의 실무적 정의

   1. 혁신은 한 번의 거대한 발명보다 높은 압박 속에서 반복되는 적응에 가깝다.
   2. 새 요구를 기존 제품에 억지로 끼워 넣는 대신, 필요하면 제품군과 내부 플랫폼을 다시 설계해야 한다.
   3. 고객의 다음 질문을 처리할 수 있는 구조를 만들면 일회성 프로젝트가 재사용 가능한 인프라가 된다.

3. SERP 데이터가 AI 시스템의 실시간 감각이 되는 과정

검색결과 페이지 데이터는 SEO와 분석 도구를 넘어 검색·리트리벌·에이전트 답변을 최신 현실에 묶는 입력 계층으로 바뀌었다.

3.1. 검색 데이터의 역할 변화

1. 과거의 SERP와 현재의 SERP

   1. SERP(Search Engine Results Page)와 검색 데이터는 원래 분석, SEO, 모니터링, 시장 인텔리전스에 활용됐다.
   2. AI가 검색 데이터를 직접 사용하는 시대에는 SERP가 검색·리트리벌 파이프라인의 입력이 된다.
   3. 검색 결과는 보조 기능에 그치지 않고 답변을 근거 있게 만들며, 에이전트가 오래된 학습 메모리가 아니라 실시간 정보와 상호작용하게 한다.
   4. Google의 grounding 문서도 Google Search를 모델과 최신 공개 지식을 연결하는 방식으로 제시한다.

2. 모델 주변의 리트리벌 계층

   1. 모델 계층은 점점 주변의 실시간 리트리벌 계층과 함께 작동해야 한다.
   2. 이 구조에서 검색 데이터의 신선도와 전달 지연 시간은 모델의 지능과 별개의 핵심 품질이 된다.
   3. 검색 결과를 수 초 뒤에 전달하면 대화형 AI 에이전트의 흐름을 끊지만, 서브초 단위로 전달하면 AI 워크플로에 직접 들어가는 도구가 된다.

3.2. 2024년의 서브초 SERP 요구

1. 기존 기준과 고객 목표의 큰 차이

   1. 2024년 고객은 서브초(sub-second) SERP 전달을 요청했다.
   2. 기존 일반 검색 스크레이퍼의 평균 지연 시간은 약 4초였다.
   3. 4초에서 서브초로 줄이는 일은 설정을 조금 조정하는 최적화가 아니라 아키텍처를 다시 설계하는 일이다.
   4. 팀은 가능성을 확인하기 위해 먼저 도전했고 실제로 구현에 성공했다.

2. 초기 성공과 시장의 타이밍

   1. 고객은 결국 제품을 시험하지 않았고, 당시 시장은 서브초 검색 API를 받아들일 준비가 되지 않았다.
   2. 구현 결과는 선반에 올라갔지만, 실패한 것이 아니라 훗날 필요한 능력을 미리 축적한 셈이 됐다.
   3. 시장이 아직 준비되지 않았다는 사실은 기술적으로 가능하다는 사실과 제품-시장 타이밍이 다르다는 점을 보여 준다.

3.3. 일반 검색 스크레이퍼와 AI용 빠른 검색 API의 차이

1. 일반 스크레이퍼가 수집하는 넓은 정보

   1. 일반 스크레이퍼는 가능한 한 많은 정보를 가져오도록 설계된다.
   2. 광고, 위젯, 리치 결과(rich results), AI가 생성한 결과, 여러 화면 레이아웃까지 함께 처리한다.
   3. 이 포괄성은 사람에게 보이는 화면을 재현하는 데 유용하지만, 모든 정보를 AI 파이프라인에 넣어야 하는 것은 아니다.

2. AI 시스템에 필요한 좁고 빠른 표면

   1. AI용 빠른 검색 API는 AI 시스템에 실제로 필요한 정보만 취한다.
   2. 주로 자연 검색 결과(organic results), 주요 뉴스(top stories), 뉴스 데이터에 집중한다.
   3. 무거운 화면 레이아웃을 잘라 내면 낮은 지연 시간을 목표로 삼을 수 있다.
   4. 작은 범위라도 낮은 지연 시간으로 전달되면 검색 결과가 AI 워크플로의 동작 구성요소가 된다.

4. 800밀리초를 향한 재설계와 브라우저의 역설

낮은 지연 시간과 현실적인 웹 접근성은 서로 충돌하므로, 마법의 최적화보다 전체 경로의 작은 지연을 합산해 줄이는 설계가 필요하다.

4.1. 2025년 고객 요구

1. 새로운 계약 조건

   1. 2025년 새로운 고객은 데이터 보존 제로(zero data retention)를 요구했다.
   2. 목표 지연 시간은 서브초였고, 납기는 다시 2주였다.
   3. 지역 위치(geolocation)와 검색 질의 파라미터를 다양하게 지원해야 했다.
   4. 결과를 800밀리초 안에 전달하면서 2주보다 짧은 기간 안에 시험 가능한 솔루션을 내놓아야 했다.

2. 최적화가 아닌 재설계

   1. 기존 기준선이 4초인 상태에서는 단순한 최적화로 목표에 도달할 수 없다.
   2. 팀은 처음부터 새로 시작했고, 2주 이내에 첫 버전을 작동시켰다.
   3. 첫 버전은 P90 기준 약 650밀리초를 기록했다.
   4. 수치만 보면 훌륭한 성공이지만, 진짜 문제는 고객과 테스트를 시작하는 다음 통화에서 나타났다.

4.2. 고객 통화에서 드러난 현실

1. 개발 환경과 현실의 차이

   1. 고객과 새 제품을 시험하려던 통화 중 시스템이 차단됐다.
   2. 그것도 부분적인 오류가 아니라 매우 심하게 차단됐다.
   3. 개발 환경에서 작동하는 시스템, 테스트에서 작동하는 시스템, 현실을 견디는 시스템은 서로 다르다.
   4. 팀은 결국 “아무것도 작동하지 않는다”고 판단하고 두 번째 반복을 시작해야 했다.

2. 브라우저가 주는 모순

   1. 두 번째 반복에서는 브라우저에 크게 의존해야 했다.
   2. 브라우저는 매우 유용하고 놀라운 도구지만 느리고, 비싸고, 복잡하다.
   3. 브라우저의 특성은 낮은 지연 시간을 바라는 설계와 본질적으로 충돌한다.
   4. 고객은 서브초 결과를 원했지만 현실은 브라우저를 필요로 했고, 브라우저는 약 4초를 요구하는 것처럼 행동했다.

4.3. 지연 시간을 쪼개는 방법

1. 마법의 해결책이 없는 시스템

   1. 단번에 모든 시간을 없애는 마법 같은 요령은 없었다.
   2. 팀은 레이아웃, 파서, 세션, 프록시를 하나씩 검토했다.
   3. 각 단계에서 1초, 2초, 3초, 4초를 줄일 수 있는 지점을 찾았다.
   4. 브라우저 실행과 안티봇 대응처럼 불가피한 비용을 인정하면서도 전체 경로를 재구성했다.

2. 작은 결정의 누적

   1. 시스템 속도는 거대한 돌파구 하나보다 작은 결정이 합쳐져 만들어진다.
   2. 어떤 레이아웃을 버릴지, 어떤 결과만 파싱할지, 어느 세션과 프록시를 재사용할지 같은 결정이 지연 시간을 줄인다.
   3. 각각은 작아 보이지만 누적되면 제품이 실시간 AI 워크플로에 들어갈 수 있는 수준이 된다.

3. 현재의 빠른 검색 API

   1. 빠른 검색 API는 최신 검색 결과와 데이터를 AI 워크플로에 직접 전달한다.
   2. 평균 지연 시간은 550밀리초까지 내려갔다.
   3. 4초짜리 파이프라인은 느린 검색 기능에 머물지만, 서브초 전달은 AI 워크플로 안에서 상호작용하는 기능을 만들 수 있다.
   4. 따라서 속도는 성능을 장식하는 숫자가 아니라 어떤 제품이 존재할 수 있는지를 결정하는 제품 속성이다.

5. 400백만에서 60,000 RPS, 다시 100,000 RPS로 확장하기

속도를 제품에 넣은 뒤에는 같은 파이프라인을 얼마나 많은 요청에 안정적으로 적용할 수 있는지가 진짜 시험이 된다.

5.1. 일일 요청량과 운영 모델의 변화

1. 대규모 일일 트래픽

   1. Oxylabs의 규모는 하루 4억 요청에서 거의 60억 요청으로 커졌다.
   2. 이 변화는 단순한 성장률이 아니라 운영 모델 자체의 변화다.
   3. 비용 구조, 관측 가능성(observability), 장애 도메인을 생각하는 방식이 달라진다.
   4. 같은 코드에 서버만 더 붙이는 방식으로는 데이터 수집·브라우저 실행·프록시·파싱·전달 전체의 복잡도를 감당할 수 없다.

2. 웹과 차단 우회 계층의 공격적 확장

   1. 새로운 수요는 웹 수집과 차단 우회 계층을 공격적으로 확장하도록 압박했다.
   2. 초기 작업량은 약 10,000 RPS(requests per second)였다.
   3. 수요가 생긴 지 2개월도 안 되어 60,000 RPS까지 확장해야 했다.
   4. 내부 프로젝트 이름 ‘Project 60’은 이 60,000 RPS 목표에서 나왔다.

5.2. RPS 숫자 뒤에 있는 엔드투엔드 작업

1. 단순 HTTP 요청이 아닌 전체 수집 작업

   1. 60,000 RPS는 단순한 HTTP 요청을 60,000번 처리한다는 뜻이 아니다.
   2. 실제 한 건의 작업에는 라우팅, 렌더링, 프록시 처리, 브라우저 실행, 파싱, 재시도, 정규화, 전달이 포함된다.
   3. 각 단계가 서로 다른 병목과 실패 조건을 만들며, 어느 한 단계의 지연이 전체 결과를 늦춘다.

2. 서버 숫자만으로 해결되지 않는 문제

   1. 이런 부하에 서버 2,000대를 추가해도 문제를 해결할 수 없다.
   2. 신뢰할 수 있는 중앙 구성요소와 전체를 조율하는 아키텍처가 필요하다.
   3. 실제 상태를 숨기지 않고 알려 주는 관측 가능성이 필요하다.
   4. 합성 트래픽이 아니라 현실을 충분히 닮은 테스트가 필요하다.

5.3. 합성 부하와 유기적 데이터 테스트

1. 진짜 병목은 트래픽 생성이 아니다

   1. 합성 트래픽을 만드는 일은 현실과 비교하면 상대적으로 쉽다.
   2. 어려운 부분은 실제 고객 사용량처럼 행동하는 유기적 데이터 테스트다.
   3. 서로 다른 쿼리, 지역, 프록시, 브라우저 실행 경로가 섞여야 부하 테스트가 실제 장애 가능성을 드러낸다.

2. 20,000 RPS에서 만난 벽

   1. 한 부하 테스트에서 시스템은 약 20,000 RPS에서 한계에 부딪혔다.
   2. 시스템이 작동하는지에 대해서는 의심할 필요가 없었다. 시스템은 실제로 작동하고 있었다.
   3. 더 중요한 질문은 시스템이 그 이상으로 갈 수 있다는 사실을 알고 있는가였다.
   4. 최대 처리량을 모른다는 불확실성 자체가 진짜 병목이 됐다.

5.4. 관측 가능성도 부하가 된다

1. 로그와 지표의 양면성

   1. 모든 팀이 이론상 관측 가능성을 좋아하지만, 대규모 관측 가능성은 별도의 작업이다.
   2. 로그를 수집하는 일은 어렵고, 로그를 처리하는 일은 더 어렵다.
   3. 지표도 필수적이지만 대규모 부하에서는 지표를 만드는 텔레메트리 자체가 부하의 일부가 된다.
   4. 로그·지표·실패 도메인을 무작정 늘리면 장애를 관찰하기 위한 시스템이 장애의 복잡도를 키울 수 있다.

2. 점진적 확장과 운영 트래픽

   1. 팀은 부하를 점진적으로 올리며 시스템의 한계를 확인했다.
   2. 결국 실제 검증은 운영 트래픽으로 해야 한다는 피할 수 없는 결론에 도달했다.
   3. 다행히 운영 트래픽을 통한 검증은 완전히 정상적으로 진행됐다.
   4. 하지만 확장은 끝나지 않았다. Project 60은 이미 Project 150으로 커지고 있었다.
   5. 다음 목표는 약 100,000 RPS였고, 한 목표에 도달하면 다음 목표가 나타났다.

6. 프록시 제공업체를 넘어 적응하는 데이터 인프라로

Oxylabs의 핵심 가치는 공개 웹의 복잡성을 AI 시스템이 연결할 수 있는 운영 계층으로 바꾸는 데 있다.

6.1. Oxylabs가 맡는 전체 계층

1. 프록시는 필수지만 충분하지 않다

   1. Oxylabs는 단순한 프록시 제공업체가 아니다.
   2. 프록시는 중요하지만 가장 어렵고 큰 일은 그 위에 인프라 계층을 만드는 것이다.
   3. 인프라는 열린 웹에 도달하고, 데이터를 안정적으로 수집하고, 안티봇 시스템을 다루고, 필요할 때 브라우저를 실행한다.
   4. 수집·추출한 데이터를 정리하고 전달해 AI 회사가 자신의 시스템에 연결할 수 있게 한다.

2. AI 회사가 집중할 수 있게 만드는 분업

   1. 고객은 지능과 제품을 구축한다.
   2. Oxylabs는 데이터 접근과 그 아래의 지저분한 유지보수를 맡는다.
   3. 웹의 대상, 페이지 레이아웃, 탐지 방식, 시장, 고객 요구는 계속 변한다.
   4. 따라서 데이터 수집은 한 번 만들고 끝나는 사업이 아니라 영원히 적응하는 사업(adapt-forever business)이다.

6.2. 적응 속도가 곧 혁신이다

1. 변화하는 요구를 새 인프라로 전환하기

   1. 요구가 바뀌는 순간마다 제품·아키텍처·시스템을 충분히 빠르게 바꿀 수 있어야 한다.
   2. 요구 변화가 새로운 인프라로 전환될 때 조직은 고객의 다음 요구를 선점할 수 있다.
   3. 동영상 API 사례는 다운로드에서 자막·메타데이터·검색·채널 정보로 확장됐고, SERP 사례는 4초에서 550밀리초로 내려간 아키텍처 전환을 보여 준다.

2. 유지보수 부담을 맡는 것이 제품 가치가 되는 이유

   1. 대상과 레이아웃이 바뀌면 기존 수집기는 깨지고, 탐지 규칙이 바뀌면 프록시와 브라우저 전략도 바뀌어야 한다.
   2. 시장과 고객이 바뀌면 필요한 데이터 형식과 지연 시간도 바뀐다.
   3. AI 회사가 제품 개발을 계속하는 동안 이 유지보수 부담을 인프라 제공업체가 맡으면 고객은 모델과 지능에 집중할 수 있다.
   4. 차세대 AI의 기반은 모델 하나가 아니라 모델과 현실 사이의 지속적으로 관리되는 다리다.

주요 발언 모음

“학습만으로는 더 이상 충분하지 않다. 모델이 유용한 상태를 유지하려면 최신 정보, 실시간 검색, 실제 외부 데이터에 접근해야 한다.”

“혁신은 깔끔한 로드맵으로 오지 않는다. 압박과 마감, 때로는 샌프란시스코에서 온 출장 보고서로 온다.”

“고객은 첫 번째 제품 반복을 사는 것이 아니라, 적응할 수 있는 능력을 산다.”

“기준선이 4초라면 최적화를 말하는 것이 아니다. 재설계를 말하는 것이다.”

“브라우저는 놀랍고 매우 유용하지만 느리고, 비싸고, 복잡하며, 낮은 지연 시간이라는 꿈과 깊이 충돌한다.”

“시스템은 거대한 돌파구가 아니라 합쳐지는 작은 결정들로 빨라진다.”

“하루 4억 요청에서 60억 요청으로 가는 일은 단순한 변화나 성장이 아니라 운영 모델의 변화다.”

“스케일은 결승선이 아니다. 적어도 우리에게는 그렇다.”

“이 사업은 한 번 만들고 끝나는 사업이 아니라 영원히 적응하는 사업이다.”

“차세대 AI는 더 나은 모델만으로 움직이지 않는다. 모델을 둘러싼 더 나은 인프라로 움직인다.”

핵심 데이터 & 수치

• 2015년: Oxylabs 설립 시점.
• 2주: AI 학습용 동영상 API의 최초 납기와 2025년 빠른 검색 API 요구의 납기.
• 월 5페타바이트: 최초 동영상 API 고객이 요구한 최소 처리 규모.
• 3개월: 다운로더에서 트랜스크립트·자막·채널 정보까지 갖춘 동영상 API 제품군으로 확장한 기간.
• 30페타바이트: 2026년 고객이 이미 모은 데이터 규모.
• 약 4초: 기존 일반 검색 스크레이퍼의 평균 지연 시간.
• P90 약 650밀리초: 2주 안에 처음 만든 SERP 시스템의 초기 성능.
• 800밀리초 이하: 2025년 고객이 요구한 결과 전달 목표.
• 평균 550밀리초: 현재 빠른 검색 API가 AI 워크플로에 전달하는 평균 지연 시간.
• 하루 4억 → 거의 60억 요청: 운영 모델을 바꾼 일일 요청량 확장.
• 10,000 → 60,000 RPS: 2개월이 안 되는 기간에 확장한 웹 수집·차단 우회 계층의 처리량.
• 약 20,000 RPS: 유기적 데이터 부하 테스트에서 처음 만난 처리량의 벽.
• 약 100,000 RPS: Project 60에서 Project 150으로 이어진 다음 확장 목표.
• 2,000대 서버: 추가만으로는 엔드투엔드 수집 문제를 해결할 수 없다고 제시된 규모.

결론 및 시사점

1. 모델의 사전 학습 품질과 현실 연결 능력을 별개의 계층으로 설계해야 한다.
2. 최신 공개 웹 데이터는 수집, 안티봇 대응, 브라우저, 저장, 정규화, 전달을 통합한 인프라 없이는 AI 시스템에 안정적으로 들어오지 않는다.
3. 고객의 첫 기능 요청을 고정된 범위로 해석하지 말고, 실제 데이터 파이프라인의 끝까지 추적해야 재사용 가능한 제품이 된다.
4. 트랜스크립트와 자막처럼 고객 용어가 실제 워크로드와 다를 수 있으므로 실패 요청을 구현 오류로 단정하지 말고 사용 목적을 다시 확인해야 한다.
5. 4초에서 서브초로 내려가는 작업은 미세 조정이 아니라 아키텍처 재설계이며, 지연 시간은 제품이 존재할 수 있는지를 결정한다.
6. 브라우저·프록시·렌더링·파싱·재시도·전달을 포함한 엔드투엔드 경로에서 작은 시간을 누적해 줄이는 방식이 현실적인 최적화 전략이다.
7. 합성 부하 테스트만으로는 실제 고객 행동과 유기적 데이터의 복잡성을 재현할 수 없으므로 운영 트래픽에 가까운 검증이 필요하다.
8. 대규모 관측 가능성은 로그와 지표를 공짜로 얻는 기능이 아니며, 텔레메트리 자체가 부하와 복잡도를 만든다는 점을 설계에 반영해야 한다.
9. 하루 수억 건에서 수십억 건으로 올라가면 서버 증설보다 중앙 아키텍처, 신뢰성, 진실을 보여 주는 관측 가능성, 현실적인 테스트가 중요해진다.
10. 스케일에는 고정된 결승선이 없으므로 확장 목표에 도달한 뒤 나타날 다음 목표를 감당할 운영 구조를 준비해야 한다.
11. 웹 데이터 인프라는 대상·레이아웃·탐지·시장·고객 요구의 변화에 계속 대응해야 하므로 ‘적응 영구’ 사업으로 봐야 한다.
12. 차세대 AI의 핵심 경쟁력은 모델을 현실과 연결하고, 웹 데이터를 파이프라인·데이터베이스·에이전트·AI 도구로 밀어 넣는 지속 가능한 다리다.

핵심 요약 (20줄)

모델의 사전 학습만으로는 계속 변하는 현실과 최신 질문을 따라갈 수 없다. 실시간 검색과 외부 공개 웹 데이터가 모델의 유용성을 유지하는 입력 계층이 된다. Oxylabs는 2015년부터 공개 웹 데이터를 대규모로 추출하는 웹 인텔리전스와 프록시 인프라를 구축했다. 공개 데이터는 이론상 열려 있어도 실제 사용에는 수집·안티봇·브라우저·저장·전달 계층이 필요하다. Patricia의 제품 경험은 정리된 로드맵보다 압박과 마감에서 혁신이 시작된다는 교훈을 남긴다. AI 학습용 동영상 API 요청은 2주 납기와 월 5페타바이트라는 전례 없는 규모로 시작됐다. 동영상 다운로드 기능은 수집·전송·저장·전달 파이프라인을 요구하면서 인프라 제품으로 확장됐다. 트랜스크립트 요청이 실제로 자막 요청이었다는 발견은 고객 용어보다 워크로드를 확인해야 함을 보여 준다. 언어 검색과 메타데이터·채널 정보가 더해지면서 일회성 기능은 3개월 만에 동영상 API 제품군이 됐다. 고객이 구매하는 가치는 첫 제품 버전보다 변화하는 요구에 적응하는 능력이다. SERP 데이터는 SEO 분석을 넘어 리트리벌 파이프라인과 근거 있는 AI 답변의 실시간 입력이 됐다. 2024년 4초 평균 지연을 서브초로 줄인 SERP 구현은 시장이 준비되지 않아 한때 선반에 보관됐다. 2025년 고객은 데이터 보존 제로와 800밀리초 이하 전달을 2주 안에 요구했다. 팀은 아키텍처를 처음부터 다시 설계해 2주 이내 P90 약 650밀리초를 만들었지만 실제 통화에서 차단을 만났다. 브라우저의 유용성·느림·비용·복잡성이 낮은 지연 시간과 충돌하므로 작은 지연을 모두 찾아 줄여야 한다. 현재 빠른 검색 API는 평균 550밀리초로 최신 데이터를 AI 워크플로에 직접 넣는다. 웹 수집 계층은 2개월이 안 되어 10,000 RPS에서 60,000 RPS로 확장됐고 Project 60이라는 이름을 얻었다. 유기적 데이터 부하 테스트는 약 20,000 RPS에서 벽을 드러냈으며 텔레메트리 자체도 부하가 됐다. Project 60은 Project 150과 약 100,000 RPS 목표로 이어져 스케일에 결승선이 없음을 보여 준다. 차세대 AI는 더 나은 모델과 현실을 연결하는 더 나은 인프라, 그리고 영원히 적응하는 운영 능력으로 움직인다.