AI 시대를 위한 캐시를 다시 생각해야 하는 이유

Cloudflare 네트워크 트래픽의 **32%**는 이미 자동화된 트래픽에서 발생한다. 검색 엔진 crawler, uptime checker, 광고 네트워크에 더해, 이제는 RAG 기반 응답을 위해 웹을 읽는 AI agent와 scraper까지 이 흐름에 합류했다. 문제는 이들이 사람과 달리 고빈도·병렬·전수 스캔 방식으로 요청을 보내 캐시를 빠르게 흔든다는 점이다.

특히 AI crawler는 한 사이트의 인기 페이지보다 문서, 이미지, 지식 문서처럼 넓고 흩어진 콘텐츠를 순차적으로 긁어가며, training용 트래픽은 이러한 특성이 더 강하다. Cloudflare와 ETH Zurich의 분석에 따르면 AI crawler 트래픽은 높은 unique URL 비율, 콘텐츠 다양성, 비효율적인 crawling이 결합돼 있어 캐시 miss를 크게 늘린다. 404나 redirect를 유발하는 요청도 적지 않고, 여러 독립 인스턴스가 세션을 공유하지 않아 같은 콘텐츠가 반복해서 새 방문처럼 보이기도 한다.

이런 패턴은 기존 LRU cache와 prefetching, cache speculation 같은 방식의 효율을 떨어뜨린다. AI agent는 RAG 루프를 반복하면서 정확도를 높이지만, 매번 새로운 long-tail 자산을 가져오므로 재사용률이 낮고 cache churn만 커진다. 결과적으로 cache hit rate는 내려가고, miss는 origin 요청으로 이어져 응답 지연과 egress 비용, origin 부하를 키운다.

실제 영향도 이미 여러 사이트에서 드러났다. Wikipedia는 대량 이미지 scraping으로 multimedia bandwidth 사용량이 50% 증가했고, SourceHut은 LLM crawler로 서비스 불안정과 지연을 겪었다. Read the Docs는 대용량 파일이 하루 수백 번 다운로드되며 bandwidth가 크게 늘었고, Fedora와 Diaspora도 인간 사용자의 응답 속도 저하와 downtime을 경험했다.

이 대응으로는 단순 차단만이 아니라 AI-aware caching이 필요하다. 실시간 Q&A나 요약처럼 지연 민감도가 높은 AI traffic은 더 큰 용량과 적당한 지연을 허용하는 cache tier로 보내고, training용 대량 수집은 더 깊은 cache나 origin-side SSD cache, queue-based admission, rate limiting으로 완화할 수 있다. Cloudflare는 AI Index와 Markdown for Agents 같은 도구를 이미 제공하고 있으며, ETH Zurich와 함께 AI-aware cache algorithm과 새로운 cache layer를 실험해 AI traffic을 분리하는 방향을 모색하고 있다.