Vercel이 Data Cache를 Runtime Cache로 통합하는 플랫폼 개편을 발표했다. 이제 Next.js, SvelteKit, Nuxt 등 모든 프레임워크가 하나의 캐싱 서비스를 사용할 수 있으며, 개발자는 코드를 수정하지 않고도 이 변화의 혜택을 받는다.

이원화에서 단일화로

그동안 Vercel은 캐싱을 이원화해 운영했다. Next.js fetch 캐싱과 unstable_cache는 Data Cache를, 그 외 프레임워크는 getCache API를 통해 Runtime Cache를 사용했다. 개발자는 설정과 저장소 할당량을 따로 관리해야 했다. Vercel은 이번 통합으로 이같은 복잡성을 제거하고, 개발자와 코딩 에이전트 모두에게 단일한 인터페이스를 제공한다.

Runtime Cache의 아키텍처

Vercel의 Runtime Cache는 분산 캐싱 인프라다. 각 지역에 Redis 플릿을 배치하고, Go로 작성된 API 레이어가 요청을 처리한다. 시간당 4억 4천만 건 이상의 읽기를 처리하고 18TB 이상의 데이터를 이동하는 규모다. 캐시 읽기는 코드가 실행되는 지역의 캐시 서비스로의 편도 왕복이므로 지연 시간을 최소화했다.

데이터 무효화 방식도 특징이다. 캐시된 각 항목에 태그를 붙이고 쓰기 시간을 기록한다. 예를 들어 모든 상품 데이터에 'catalog' 태그를 달면, 카탈로그 변경 시 백만 개 항목을 일일이 삭제할 필요 없이 태그 하나의 무효화 타임스탬프만 갱신한다. Vercel은 이 타임스탬프를 글로벌 푸시 파이프라인으로 배포하며, 보통 수백 밀리초 이내에 모든 지역에 전파된다. CDN 캐싱과도 같은 태그 인프라를 공유한다.

올해의 성능 개선 성과

올해 Vercel이 실시한 세 가지 성능 개선이 나타났다. 8월에는 트래픽 급증 시 캐시 읽기 지연을 크게 줄였다. 문제는 태그 저장소의 일부 샤드가 느려지면 캐시 값 자체는 신선해도 읽기가 지연되는 것이었다. 회로 차단기(circuit breaker)를 도입해 메모리에 캐시된 태그 타임스탬프로 신선도를 일시적으로 확인하도록 했다. 최대 트래픽 시간대 p99 캐시 서비스 읽기 지연이 이전의 약 5분의 1로 단축됐다. 온콜 경보도 사라졌다.

6월과 10월에는 저장소 할당량을 늘렸다. Pro 프로젝트는 이전의 Data Cache 팀 공유 풀의 8배, Enterprise는 10배 규모를 지원받는다. Enterprise에서 빈번한 제거가 발생하던 프로젝트 중 다수는 하루 내에 캐시 미스율이 절반으로 떨어졌다.

Vercel은 또한 관찰성을 강화했다. Runtime Cache 뷰에 배포 마커, 무효화 사유, 쓰기 사용률이 추가됐다. 개발자는 릴리스와 캐시 동작 변화를 비교하고, 항목이 왜 새로고쳐지는지 파악하며, 읽혀도 거의 안 되는 데이터를 식별할 수 있다.

플랫폼 통합의 의의

이번 통합은 기술적으로도 전략적으로도 의의가 있다. 기술 측면에서는 모든 캐싱을 Runtime Cache로 단일화하면서 인프라 관리를 간소화했다. 에이전트 중심의 AI 시대에, 개발자나 AI 에이전트가 명시적으로 캐싱 정책을 일일이 선언하기보다는 플랫폼이 자동으로 학습하고 최적화하는 방향성을 보여준다.

Next.js fetch 캐싱이나 unstable_cache를 쓰는 개발자는 코드를 바꿀 필요가 없다. Vercel이 자동 마이그레이션을 처리한다. 기존 팀은 마이그레이션 일정과 청구 세부사항을 사전에 받는다. 다만 마이그레이션 전에 캐시 사용 현황을 검토하고, 불필요한 읽기와 쓰기를 줄이는 최적화를 먼저 진행할 것을 Vercel은 권고했다.

개발자 플랫폼의 진화 신호

과거 개발자가 여러 서비스를 조합하던 모습에서, 단일 플랫폼이 다양한 요구사항을 한 번에 충족하는 통합으로 나아가고 있다. 특히 런타임 캐싱이라는 기초 기능을 모든 프레임워크가 동등하게 접근할 수 있도록 한 것은, Next.js 의존도를 낮추고 플랫폼의 중립성을 강화하는 움직임이기도 하다.