하루 90억 건의 cdnjs가 엣지 워커로 갈아탄 이유

월요일 아침 8시반, 모니터링 Dashboard에 찍힌 글로벌 트래픽 그래프를 보고 눈을 의심했습니다. 우리가 서비스하는 앱의 static 자원 CDN 요청량이 비정상적인 스파이크를 그리고 있었기 때문입니다. 처음엔 심각한 DDOS 공격인가 싶어 심장이 철렁했습니다. 하지만 네트워크 패킷을 하나씩 뜯어보니 범인은 외부 공격자가 아니었습니다. 최근 개발팀에서 적극적으로 도입한 AI 코딩 에이전트들이 생성해 낸 프론트엔드 보일러플레이트 코드 속에 cdnjs의 <script> 태그 URL이 수천 개씩 포함되어 동시에 엣지 서버로 몰려들고 있었던 겁니다.

"요즘 시대에 웹팩이나 바이트(Vite) 같은 모듈 번들러를 쓰고 ES Modules가 표준화되었는데, 도대체 왜 10년도 더 된 <script src="https://cdnjs.cloudflare.com/..."> 태그 트래픽이 줄어들기는커녕 계속 늘어나는 걸까?" 다들 한 번쯤 던져봤을 이 질문의 해답은 바로 우리가 매일 쓰는 ChatGPT, Claude, Cursor 같은 LLM에 있었습니다. 15년 동안 스택오버플로우와 GitHub에 축적된 cdnjs 경로가 LLM의 가장 강력한 학습 데이터가 되었고, 프롬프트 한 줄로 HTML 데모를 만들어낼 때마다 cdnjs 서버로는 매 순간 폭발적인 트래픽이 쏟아집니다.

전 세계 웹사이트의 약 12%가 의존하며 자바스크립트 CDN 시장의 48.3%를 차지하는 cdnjs는 하루 평균 90억 건, 초당 10만 8천 건의 요청을 330개 이상의 엣지 데이터센터에서 처리합니다. 그리고 지난 2026년 6월 23일, 이 공룡 같은 레거시 CDN 시스템이 기존 전용 VM 인프라를 완전히 벗 던져버리고 100% 서버리스 엣지 개발 플랫폼인 Cloudflare Workers, Workflows, D1, R2, Containers 기반으로 완전 이관되었습니다. 오늘 글을 한 줄로 요약하면 이겁니다. 레거시 중앙집중식 서버 아키텍처를 버리고 100% 엣지 개발 플랫폼으로 전환한 cdnjs의 독식(Dogfooding) 잔혹사야말로 우리가 구현할 차세대 백엔드 아키텍처의 가장 확실한 이정표입니다.

1. 거대한 중앙 물류창고를 없애고 동네 편의점 330곳을 연결하다

기존의 cdnjs 서비스 방식은 마치 도시 중앙에 대형 중앙 물류창고(기존 전용 Origin 서버 및 DB)를 두고, 전 세계 손님이 물건을 주문할 때마다 배달 기사가 중앙 창고까지 왕복하는 구조였습니다. 아무리 엣지 캐시(Cache)를 앞단에 둔다 한들, 새로운 오픈소스 라이브러리 패키지가 npm에 업로드되거나 캐시가 퍼지(Purge)되면 결국 모든 트래픽의 병목은 중앙 오리진 서버에 몰릴 수밖에 없었습니다.

반면 이번에 단행된 엣지 개발 플랫폼 전환은 중앙 물류창고를 아예 없애버린 격입니다. 전 세계 330개 데이터센터에 있는 '동네 편의점'들이 스스로 재고를 파악하고, 물품을 비동기로 수급하며, 손님 바로 앞에서 제품을 전달합니다. 컴퓨팅부터 데이터베이스, 분산 큐, 개체 스토리지까지 모든 백엔드 컴포넌트가 엣지 위에서 도는 구조로 바뀐 것입니다.

• Workers (Edge Compute): 중앙 응답 서버 없이 엣지 단에서 라우팅과 비즈니스 로직을 즉시 실행합니다.
• D1 (Distributed Relational DB): 중앙 SQL 서버 대신 SQLite 기반 엣지 DB를 통해 패키지 메타데이터를 밀리초 단위로 조회합니다.
• R2 & KV (Global Asset & Key-Value Storage): 이중화된 정적 자원 저장소로 egress 비용 없이 파일 패키지를 무제한에 가깝게 공급합니다.
• Workflows & Queues (Async Orchestration): npm 패키지 수집과 검증 프로세스를 중앙 워커가 아닌 엣지 분산 큐와 워크플로우 이벤트로 자동 처리합니다.

이 전환을 통해 cdnjs는 98.6%라는 경이로운 캐시 히트율(Cache Hit Rate)을 유지하면서도, 오리진 장애 발생 시 시스템 전체가 마비되던 고질적인 단일 실패 지점(SPOF)을 완벽히 제거했습니다. TTFT(첫 바이트 응답 시간) 역시 글로벌 평균 40% 이상 단축되었고, 백엔드 유지보수에 들어가던 인프라 공수를 월 60시간 이상 절감할 수 있었습니다.

2. 90억 건 트래픽 속에서 마주한 엣지 전환 잔혹사

하지만 이론상 완벽해 보이는 엣지 네이티브 아키텍처 전환 과정이 결코 순탄치만은 않았습니다. 우리 팀 역시 과거 cdnjs와 유사하게 백엔드 서비스를 엣지 인프라로 일부 이관할 때 스케일의 벽에 부딪혀 밤을 지새운 적이 있었습니다. 90억 건의 요청을 견디는 과정에서 터져 나온 실무 잔혹사의 핵심은 바로 '분산 일관성'과 '엣지 리소스 제약'이었습니다.

첫 번째 잔혹사는 D1 엣지 데이터베이스의 분산 전파 지연 문제였습니다. 오픈소스 라이브러리의 신규 버전이 npm에 등록되면 Workflows가 이를 감지하여 D1 DB에 패키지 버전 정보를 기록합니다. 하지만 전 세계 330개 데이터센터로 D1 DB 상태가 전파되기 전에 사용자가 동시다발적으로 신규 버전을 요청하자, 특정 지역 엣지 노드에서 '404 Not Found' 에러가 터져 나왔습니다. 캐시 레이어가 비어 있는 상태에서 DB 메타데이터가 엣지별로 파편화되어 나타난 문제였습니다.

• 동기화 시차 이슈: 중앙 DB가 없는 엣지 DB 특성상 Eventual Consistency(최종 일관성) 지연 시간 동안 읽기 캐시가 무효화되어 터지는 캐시 스탬피드(Cache Stampede) 현상이 발생했습니다.
• 해결 방안: KV 레이어와 Workers Cache를 2중 결합하여 신규 버전에 대해 'Write-Through' 형태의 임시 캐시 락(Lock)을 걸고, 전파가 완벽히 완료될 때까지 비동기 Queues로 요청을 제어하는 오케스트레이션 로직을 구축해야 했습니다.

두 번째 잔혹사는 엣지 컨테이너 및 워커의 메모리 버스트 한계였습니다. 압축된 대용량 JS/CSS 파이프라인 패키지를 엣지 노드에서 실시간으로 해제하고 검증할 때 순간적으로 메모리 초과(Memory Exceeded) 버그가 발생하며 엣지 프로세스가 강제 종료되었습니다. 무거운 백엔드 Docker 컨테이너에서 처리하던 일들을 무작정 미니멀한 엣지 스크립트로 가져오려 했던 야심이 불러온 참사였습니다.

이를 해결하기 위해 빌드 및 파싱 같은 헤비한 작업은 백엔드 전용 엣지 컨테이너(Containers)로 분리하고, 일반 요청 처리(Fetch Event)는 초경량 Workers가 담당하도록 역할을 명확히 쪼개는 계층형(Tiered) 엣지 아키텍처로 재설계해야 했습니다.

3. 내일 출근해서 적용하는 차세대 엣지 백엔드 구축 전략

cdnjs의 전격적인 엣지 플랫폼 이관 성공 사례는 우리 같은 실무 소프트웨어 아키텍트들에게 중요한 메시지를 던집니다. 우리가 구축하는 시스템도 더 이상 단일 AWS EC2나 RDS 중심의 모놀리식/MSA 구조에 고착될 필요가 없다는 뜻입니다. 현장에서 즉시 적용해 볼 수 있는 엣지 네이티브 전환 3단계 가이드라인을 공유합니다.

Step 1: Read-Heavy 아키텍처의 엣지 분리

서비스 레이어 중 읽기 비중이 80% 이상인 API(예: 공지사항, 상품 메타데이터, 라이브러리 자원, 정적 설정값)를 선별하세요. 중앙 데이터베이스로 진입하기 전에 엣지 Key-Value 저장소나 엣지 DB(D1, Turso 등)를 배치하여 중앙 DB의 읽기 부하를 제로에 가깝게 만듭니다.

Step 2: 비동기 파이프라인의 엣지 오케스트레이션

주기적인 배치 작업이나 외부 API 동기화 작업을 모놀리식 서버의 Cron Job으로 돌리지 마세요. Edge Workflows와 Queues를 활용하여 메시지를 분산 처리하면, 중앙 서버의 CPU 점유율을 획기적으로 낮출 수 있습니다.

Step 3: LLM 친화적 캐싱 및 불변 URL 설계

AI 코딩 도구가 쏟아내는 자동 생성 코드의 타겟이 되는 API나 static 자원은 URL 구조를 철저히 정적이고 불변(Immutable)하도록 설계하세요. 버전을 URL 경로에 명시하고 캐시 헤더를 max-age=31536000, immutable로 설정하면 엣지 캐시 히트율을 99% 근처까지 극대화할 수 있습니다.

이제 백엔드 엔지니어의 역할은 단순히 EC2 인스턴스를 띄우고 DB 인덱스를 잡는 것에 머물지 않습니다. 중앙 집중식 인프라와 글로벌 엣지 플랫폼의 최적 접점을 찾고, 90억 건의 요청 속에서도 흔들리지 않는 가동성을 확보하는 것이 실무 아키텍트의 진짜 역량입니다.

오늘부터 여러분의 백엔드 서비스 중에서 가장 병목이 심한 읽기 API 하나를 골라 엣지 워커 기반으로 포팅해 보는 실험을 시작해 보세요. 작은 변화가 모여 전체 인프라 비용을 절반 이하로 줄이고 서비스 속도를 몇 배나 끌어올리는 놀라운 경험을 하게 될 것입니다.

# [실무 무기 팩] 엣지 아키텍처 전환 점검 체크리스트 & 프롬프트 템플릿

## 엣지 아키텍처 마이그레이션 점검 체크리스트 (Self-Checklist)

[ ] 트래픽 패턴 분석
    - [ ] 서비스 전체 API 중 Read 대 Write 비율이 8:2 이상인 엔드포인트가 식별되었는가?
    - [ ] Static 자원 및 메타데이터 API의 글로벌 캐시 히트율 목표(95% 이상)가 설정되었는가?

[ ] 데이터 일관성 및 저장소 설계
    - [ ] 엣지 DB(D1/Turso 등) 적용 시 Eventual Consistency(최종 일관성) 시차에 대한 예외 처리가 되어 있는가?
    - [ ] 엣지 KV 및 R2 스토리지의 Egress 비용 및 Request Limit 요금이 계산되었는가?

[ ] 장애 격리 및 롤백 전략
    - [ ] 엣지 컴퓨팅 메모리/시간 제한(예: Workers 128MB, CPU Time) 초과 시 Fallback 오리진 서버 지정이 되어 있는가?
    - [ ] 엣지 스크립트 배포 시 Canary 배포 및 즉각적인 Rollback 파이프라인이 CI/CD에 포함되어 있는가?

---

## LLM / AI 코딩 도구 맞춤형 Static API 설계 프롬프트 템플릿

 아래 프롬프트를 Copilot / Claude / ChatGPT에 입력하여 엣지 네이티브에 최적화된 API 및 캐싱 아키텍처 코드를 생성하세요.

[역할 정의]
너는 글로벌 엣지 컴퓨팅(Cloudflare Workers / AWS CloudFront Functions) 및 백엔드 아키텍처에 정통한 10년 차 수석 엔지니어이다.

[배경 및 상황]
현재 작성 중인 API는 LLM(ChatGPT, Claude, Cursor 등)이 자동으로 코드 작성 시 자주 호출하는 오픈소스 메타데이터/자원 제공 엔드포인트이다. 하루 수억 건의 요청에 견딜 수 있도록 엣지 네이티브 구조로 설계해야 한다.

[요청 사항]
1. Cloudflare Workers 또는 Hono 프레임워크 기반으로 엣지에서 작동할 비동기 API 핸들러 코드를 작성해 줘.
2. 엣지 KV/D1을 1차 캐시로 조회하고, 캐시 미스(Cache Miss) 발생 시만 비동기 Queue를 통해 오리진을 호출하는 스튜어드 패턴을 적용해 줘.
3. HTTP 응답 헤더에 Cache-Control(immutable, max-age 적용) 및 CORS 설정 포맷을 완벽히 포함해 줘.
4. 발생 가능한 메모리 초과 및 동기화 지연 예외 상황에 대한 Try-Catch Fallback 로직을 작성해 줘.

[출력 형식]
- TypeScript 기반 작성
- 주석으로 각 엣지 컴포넌트(KV, D1, Queue)의 역할 명시