클라우드플레어(Cloudflare)가 자사의 서버리스(serverless) 플랫폼인 워커스(Workers)에 '워커스 캐시(Workers Cache)' 기능을 새롭게 출시했습니다. 이 기능은 워커스 애플리케이션 앞에 계층형 캐시를 두어, 캐시된 요청에 대해서는 워커스 코드를 실행하지 않고 클라우드플레어 네트워크에서 직접 응답을 반환합니다. 이는 개발자가 단 한 줄의 설정과 익숙한 HTTP 캐시-컨트롤(Cache-Control) 헤더만으로 손쉽게 캐싱을 제어할 수 있게 하여, 서버 렌더링(Server-Side Rendering, SSR) 애플리케이션의 성능과 비용 효율성을 크게 개선할 것으로 기대됩니다.
기존 워커스 아키텍처에서는 워커가 캐시와 오리진(origin) 서버 앞에 위치하여 요청을 변환하는 역할을 했습니다. 하지만 Astro, Next.js, Remix 등 최신 웹 프레임워크들이 워커스를 오리진 서버처럼 사용하는 경향이 늘면서, 모든 요청마다 워커 코드가 실행되어 불필요한 CPU 시간과 지연 시간(latency)이 발생했습니다. 워커스 캐시는 이러한 문제를 해결하기 위해 클라우드플레어의 캐시가 워커 앞에 위치하도록 아키텍처를 변경했습니다. 캐시 적중(cache hit) 시 워커는 실행되지 않아 CPU 비용이 발생하지 않으며, 캐시 미스(cache miss) 시에만 워커가 실행되어 응답을 생성하고 캐시에 저장합니다. 이후 동일한 요청은 전 세계 어디에서든 캐시에서 바로 제공됩니다. 개발자는 응답 헤더에 'Cache-Control'을 설정하고, 필요에 따라 태그(tag) 또는 경로(path) 기반으로 캐시를 직접 삭제(purge)할 수 있습니다.
이러한 변화는 서버 렌더링 애플리케이션 개발에 있어 중요한 전환점을 제공합니다. 이전에는 빌드 시 모든 페이지를 미리 렌더링하는 정적 사이트 생성(Static Site Generation, SSG) 방식과 매 요청마다 페이지를 렌더링하는 방식 중 하나를 선택해야 했습니다. SSG는 빠르지만 콘텐츠 변경 시 전체 재빌드가 필요하고, 매 요청 렌더링은 최신 콘텐츠를 제공하지만 성능 저하와 비용 증가를 감수해야 했습니다. 워커스 캐시는 이 두 가지 방식의 장점을 결합하여, 요청 시 서버 렌더링하되 렌더링된 응답을 캐시하여 정적 사이트와 같은 속도를 제공합니다. 특히 'stale-while-revalidate' 지시어를 통해 캐시가 만료되어도 오래된 콘텐츠를 즉시 제공하고 백그라운드에서 새로운 콘텐츠를 가져와 사용자 경험을 저해하지 않습니다. 이는 복잡한 프레임워크별 증분 정적 재생성(Incremental Static Regeneration) 없이 순수한 HTTP 캐싱만으로 높은 성능과 최신성을 동시에 달성할 수 있게 합니다.