Cloudflare가 cdnjs를 자사 플랫폼으로 이전한 이유
Cloudflare는 하루 90억 건의 요청을 처리하는 오픈소스 JavaScript/CSS CDN 서비스인 cdnjs를 자사 Developer Platform으로 완전히 마이그레이션했다. cdnjs는 전 세계 수많은 웹 서비스가 jQuery, React, Bootstrap 같은 라이브러리를 빠르게 제공받기 위해 의존하는 인프라다. 이번 이전의 핵심 목표는 단순한 플랫폼 교체가 아니라, 퍼블리싱(패키지 등록 및 배포)과 딜리버리(실제 요청 처리) 인프라를 하나의 통합된 스택으로 묶는 것이었다.
기존 아키텍처는 퍼블리싱 파이프라인과 딜리버리 레이어가 분리되어 있어 운영 복잡도가 높았다. 마이그레이션을 통해 유지보수 부담을 줄이고, Cloudflare 자체 기술 스택 위에서 확장성과 신뢰성을 동시에 확보하는 구조로 전환했다.
새 아키텍처를 구성하는 핵심 컴포넌트
새 아키텍처는 Cloudflare Developer Platform의 여러 프리미티브를 조합해 설계됐다.
- Workers: 엣지에서 HTTP 요청을 처리하는 서버리스 런타임. 딜리버리 레이어의 핵심이다.
- R2: 오브젝트 스토리지. 실제 JS/CSS 파일을 저장한다. S3 호환 API를 제공하므로 기존 도구와의 통합이 용이하다.
- KV: 글로벌 분산 키-값 스토어. 패키지 메타데이터나 URL 매핑처럼 읽기 빈도가 높은 데이터를 캐싱하는 데 활용된다.
- Workflows / Queues: 패키지 퍼블리싱 파이프라인의 비동기 작업을 오케스트레이션한다. 새 버전이 등록될 때 처리 단계를 순차적으로 실행한다.
- Durable Objects: 상태를 갖는 엣지 컴퓨팅 단위. 동시성 제어나 일관성이 필요한 작업에 사용된다.
- Containers: 컨테이너 기반 워크로드를 Worker 환경과 통합해 더 복잡한 빌드/처리 로직을 수용한다.
Java 백엔드 관점에서 이 아키텍처는 마이크로서비스의 각 관심사(스토리지, 캐시, 메시지 큐, 상태 관리)를 클라우드 매니지드 프리미티브로 위임한 구조와 유사하다. Spring 생태계에서 Redis, S3, SQS, Kafka를 조합하는 방식과 본질적으로 같은 설계 철학이다.
무중단 마이그레이션에서 배울 수 있는 점
이번 마이그레이션에서 실무적으로 주목할 부분은 하위 호환성 보장이다. 기존 패키지 콘텐츠, URL 구조, SRI(Subresource Integrity) 해시가 완전히 보존됐다.
# 기존 cdnjs URL 구조가 마이그레이션 후에도 동일하게 유지됨
https://cdnjs.cloudflare.com/ajax/libs/jquery/3.7.1/jquery.min.js
SRI 해시는 브라우저가 외부 스크립트의 무결성을 검증하는 보안 메커니즘이다. 만약 마이그레이션 과정에서 파일이 조금이라도 변경됐다면 전 세계 수많은 사이트의 SRI 검증이 실패했을 것이다. 이는 데이터 마이그레이션 시 콘텐츠 불변성(content immutability) 을 최우선 제약으로 설정해야 한다는 원칙을 잘 보여준다.
백엔드 서비스를 이전할 때도 동일한 원칙이 적용된다. API 응답 구조, 공개 엔드포인트 경로, 외부 시스템이 의존하는 식별자(ID, 해시, 토큰 등)는 마이그레이션 전후로 절대 달라져서는 안 된다.
정리
- 퍼블리싱과 딜리버리를 통합된 플랫폼 스택으로 일원화하면 운영 복잡도를 낮추고 확장성을 확보할 수 있다.
- Workers + R2 + KV + Queues 조합은 Java 진영의 서버리스/클라우드 아키텍처 설계 시 유사한 레퍼런스 패턴으로 참고할 수 있다.
- 대규모 마이그레이션에서 URL, 해시, 콘텐츠 등 외부 의존성이 있는 계약(contract)은 반드시 불변으로 보존해야 한다.