data-fetching

AI 시대를 위해 캐시를 재고하는 이유 (새 탭에서 열림)

AI 트래픽의 급격한 증가는 인간 사용자의 행동 패턴을 기반으로 설계된 기존 CDN 캐시 아키텍처에 큰 도전 과제를 던지고 있습니다. AI 크롤러와 에이전트는 일반적인 인간 사용자와 달리 웹사이트 전체를 순차적으로 스캔하거나 방대한 양의 '롱테일(비인기)' 콘텐츠를 집중적으로 요청하며, 이는 기존 캐시 적중률을 떨어뜨리고 원본 서버의 부하를 가중시키는 결과를 초래합니다. Cloudflare는 이러한 AI 시대의 독특한 데이터 접근 패턴에 대응하기 위해 CDN 캐시 설계의 근본적인 재검토가 필요하다고 주장합니다. ### AI 트래픽과 인간 트래픽의 차이점 * **높은 고유 URL 요청 비율:** AI 에이전트는 정보를 정제하고 정확도를 높이기 위해 반복적인 루핑(looping)을 수행하며, 이 과정에서 요청의 70~100%가 중복되지 않는 고유 URL로 구성됩니다. * **콘텐츠 접근의 광범위성:** 인기 페이지에 집중하는 인간과 달리, AI는 훈련 데이터 수집이나 검색 증강 생성(RAG)을 위해 기술 문서, 이미지, 블로그 등 웹사이트의 거의 모든 콘텐츠를 훑어갑니다. * **크롤링 비효율성:** AI 크롤러는 브라우저 측 캐싱이나 세션 관리를 제대로 활용하지 않으며, 독립적인 인스턴스를 여러 개 실행하여 동일한 콘텐츠를 중복 요청하거나 잘못된 URL 처리로 인해 많은 404 오류를 발생시키기도 합니다. ### 기존 캐시 알고리즘(LRU)의 한계와 영향 * **캐시 오염(Cache Churn):** 대규모 AI 스캔이 발생하면 인간 사용자가 자주 찾는 인기 콘텐츠가 캐시에서 밀려나고, 그 자리를 AI가 일회성으로 긁어가는 비인기 콘텐츠가 차지하게 됩니다. * **캐시 적중률(Hit Rate) 하락:** 가장 오래전에 사용된 데이터를 먼저 삭제하는 LRU(Least Recently Used) 알고리즘은 AI의 공격적인 스캔 패턴 아래에서 효율이 급격히 떨어지며, 이는 곧 캐시 미스 증가로 이어집니다. * **원본 서버 및 비용 부담:** 캐시 미스가 발생하면 모든 요청이 원본(Origin) 서버로 직접 전달되어 서버 부하가 커지고, 데이터 전송에 따른 이그레스(Egress) 비용이 상승하며 응답 속도는 느려집니다. ### AI 시대의 웹 운영을 위한 새로운 방향 * **운영자의 이분법적 선택:** 웹 운영자는 이제 자원 보호를 위해 AI 크롤러를 차단할 것인지, 아니면 AI 모델의 최신 정보를 유지하기 위해 이들을 수용할 것인지 선택해야 하는 상황에 놓여 있습니다. * **차세대 캐시 전략의 필요성:** 기존의 단순한 프리페칭(Prefetching)이나 캐시 만료 정책은 더 이상 유효하지 않으며, AI 에이전트의 반복적인 루핑과 롱테일 접근 패턴을 반영한 지능적인 캐시 설계가 필수적입니다. * **연구 및 협업:** Cloudflare는 ETH Zurich 연구진과 협력하여 AI 트래픽 패턴을 모델링하고, 이를 기반으로 CDN이 AI 시대에 어떻게 적응해야 할지에 대한 기술적 방향성을 제시하고 있습니다. 웹 운영자는 자신의 콘텐츠가 AI 검색 결과나 학습 데이터에 포함되기를 원한다면, AI 트래픽의 특성을 이해하고 이를 효율적으로 처리할 수 있는 도구를 도입해야 합니다. 단순히 트래픽을 차단하는 것을 넘어, 'Pay per crawl'과 같은 수익화 모델이나 AI 전용 캐시 계층을 고려하는 등 변화하는 환경에 맞춘 유연한 대응 전략이 권장됩니다.

Making fetch happen: Building a general-purpose query and render scheduler (새 탭에서 열림)

데이터독(Datadog)은 복잡한 대시보드의 성능 최적화를 위해 쿼리와 렌더링 작업을 효율적으로 관리하는 범용 스케줄러를 개발했습니다. 기존의 복잡한 규칙 기반 시스템을 단순화하고 브라우저 네이티브 API를 활용함으로써, UI 응답성을 높이고 백엔드 부하를 안정화하는 성과를 거두었습니다. 이 글은 기존 스케줄러의 한계를 극복하고 모든 애플리케이션에 적용 가능한 유연한 스케줄링 모델로 전환한 과정을 다룹니다. ### 기존 스케줄러(v1)의 문제점 * **지나친 복잡성:** 약 20여 개의 매개변수가 얽힌 복잡한 휴리스틱(heuristics)으로 운영되어, 개발자가 시스템의 동작 방식을 예측하거나 추론하기 어려웠습니다. * **로직의 결합:** 쿼리(데이터 호출)와 렌더링(화면 표시) 스케줄링이 명확히 분리되지 않았습니다. 예를 들어, 렌더링 대기 작업이 많다는 이유로 연관 없는 쿼리 요청이 지연되는 등의 비효율이 발생했습니다. * **낮은 범용성:** 대시보드 환경에만 특화되어 설계되었기 때문에, 데이터독의 다른 제품군이나 일반적인 위젯 컴포넌트에서 재사용하기 어려운 구조적 한계가 있었습니다. ### 데이터 쿼리 스케줄링의 단순화 * **가시성 기반 우선순위:** 화면에 보이는(visible) 위젯의 쿼리는 요청 즉시 실행하고, 화면 밖(offscreen) 위젯은 별도의 대기열에 추가하여 지연 처리합니다. * **고정 시간 윈도우 알고리즘:** 복잡한 계산 대신 2,000ms라는 고정된 시간 창(window) 동안 최대 10개의 태스크만 실행하도록 제한하여 작업 분포를 평탄화했습니다. * **대기열 관리 최적화:** 백엔드에 펜딩된 요청이 너무 많으면 실행을 일시 중단하며, 화면 밖 작업들은 대기열에 들어온 순서대로 처리하여 공정성을 유지합니다. * **도입 결과:** 로직이 단순해졌음에도 불구하고 서버의 '429(Too many requests)' 에러가 크게 감소했으며, 쿼리 재시도 횟수가 줄어들어 전체적인 데이터 로딩 속도가 향상되었습니다. ### Browser Scheduling API를 활용한 렌더링 최적화 * **자원 상태 인지:** 기존 스케줄러는 브라우저의 CPU나 메모리 가용 상태를 알지 못한 채 작업을 할당했으나, 새로운 시스템은 브라우저 네이티브 기능을 활용합니다. * **우선순위 세분화:** 최신 `Browser Scheduling API`의 `postTask` 메서드를 도입하여 작업의 성격에 따라 우선순위(user-blocking, user-visible, background)를 부여합니다. * **효율적인 메인 스레드 사용:** 브라우저가 직접 작업의 우선순위를 제어하게 함으로써, 중요한 UI 업데이트는 즉시 처리하고 덜 중요한 렌더링은 브라우저가 유휴 상태일 때 실행하도록 최적화했습니다. 복잡한 웹 애플리케이션에서 성능을 확보하려면 스케줄링 로직을 최대한 단순화하고 브라우저가 제공하는 표준 API를 적극적으로 활용해야 합니다. 이는 개발자에게는 시스템에 대한 통제력을 제공하며, 사용자에게는 더 매끄러운 인터랙션 경험을 선사합니다.